AG-723 governs the detection and enforcement of positive obligations — duties that require an agent to affirmatively act, file, notify, escalate, or complete a task within a defined legal, contractual, or operational timeframe — as distinct from prohibitions that require the agent merely to refrain from behaviour. This dimension matters because agent omission failures are structurally harder to detect than commission failures: an agent that does nothing leaves no anomalous output to flag, no error message to surface, and no obvious audit trail entry, meaning a missed mandatory filing, an undelivered statutory notice, or a skipped contractual checkpoint can propagate silently until the legal, financial, or safety window has closed. Failure in this dimension manifests as regulatory penalties for late or absent filings, contractual forfeiture, statutory harm to third parties who were entitled to notice or intervention, and systemic erosion of human operator trust when the agent's omission cannot be distinguished from deliberate suppression.
A financial-value agent is deployed to monitor transaction flows for a regulated payments processor. On 14 March, the agent's pattern-recognition layer assigns a suspicion score of 0.91 (threshold for mandatory Suspicious Activity Report filing is 0.85) to a series of 47 structured transactions totalling USD 2,340,000 moving through three correspondent accounts in 11 hours. The agent correctly identifies the obligation to file a SAR with the applicable financial intelligence unit within 30 days of detection. However, a context-window management routine silently truncates the obligation-state record at session boundary, and the obligation is not re-hydrated when the agent resumes the following day. The 30-day window closes on 13 April. No SAR is filed. On 19 May the transactions are linked to a sanctions evasion scheme during an external audit. The regulated entity faces a civil monetary penalty of USD 4,800,000, a supervisory enforcement action requiring third-party audit, and a reputational disclosure in the regulator's public enforcement register. The omission is traced to the agent; no human operator was ever alerted because the obligation record did not survive the session boundary.
A local government housing authority deploys a public-sector agent to manage tenancy administration across 6,200 properties. Under the applicable tenancy statute, the authority must serve a formal notice of rent arrears within 14 calendar days of an arrears event crossing the threshold of two months' rent, before any possession proceedings can be initiated. On 2 September, the agent detects that tenant record T-4471 has crossed the threshold. The agent queues a notice-generation task. A downstream document-dispatch integration fails silently — the dispatch acknowledgement expected within 60 seconds times out, but the agent's failure-handling path marks the task as "dispatched" rather than "failed" because the integration returned HTTP 202 Accepted before the actual transmission error occurred at the mail gateway. The notice is never delivered. On 28 September the housing officer initiates possession proceedings on the basis of the agent's status log showing "notice served." The proceedings are challenged at tribunal; the authority's case is struck out because the statutory pre-condition was not met. The authority incurs £38,000 in wasted legal costs, must restart the statutory process, and faces a formal complaint to the housing ombudsman. The tenant, who had in fact arranged a payment plan on 10 September, suffers a five-month delay in resolution and an unwarranted credit impact from the possession claim that was filed before being struck out.
An autonomous robotic arm controller operates in a food-processing facility under a safety instrumented system specification that mandates an agent-initiated emergency halt and supervisor notification within 500 milliseconds whenever torque sensor readings on joint J3 exceed 95 Nm sustained for more than 200 ms, per IEC 61511 SIL-2 requirements. On 7 November at 03:17:44 UTC, joint J3 records a sustained reading of 103 Nm for 340 ms. The agent's obligation-execution thread is blocked by a low-priority telemetry logging coroutine that has acquired a shared lock. The halt command is not dispatched within the 500 ms requirement; it fires at 1,240 ms. By that point, a mechanical overload has damaged the end-effector and contaminated an adjacent product batch. The supervisor notification fires 3,100 ms after the event. The facility's safety case for SIL-2 certification is invalidated, triggering a mandatory production halt for recertification costing EUR 290,000 in lost throughput and EUR 95,000 in remediation. The product batch contamination triggers a precautionary recall affecting 18,000 units at a retail cost of EUR 1.20 per unit. Regulatory investigation opens under the applicable machinery directive.
This section applies to any agent system that is assigned, discovers, or derives a positive obligation — any duty to take affirmative action including but not limited to: regulatory filings, statutory notifications, contractual deliverables, safety-mandated interventions, escalation duties, consent renewals, licence renewals, audit submissions, customer disclosure duties, and time-bounded care obligations. The requirements apply regardless of whether the obligation originates from: a human operator instruction, an upstream system injection, the agent's own reasoning process, a retrieved legal or contractual corpus, a workflow trigger, or a real-time sensor event. The requirements apply at all stages of the obligation lifecycle: detection, registration, scheduling, execution, confirmation, and archival. Agents that operate in a purely advisory capacity and delegate all execution to human operators are subject to the detection and escalation requirements (4.1 through 4.5) but are not subject to the execution confirmation requirements (4.6 through 4.8) unless the advisory output forms part of a documented human-in-the-loop workflow where agent omission of advice can constitute constructive non-performance.
The agent system MUST maintain a durable, session-boundary-persistent obligation registry that records every positive obligation in the system's scope, including: obligation identifier, source (instruction, sensor, reasoning, retrieved corpus), obligation type, triggering condition and timestamp, required action, deadline (absolute timestamp where determinable, or deadline-derivation rule where not), responsible execution component, current status (pending, in-progress, executed, confirmed, failed, escalated, superseded, waived), and the identity of any human operator who authorised a waiver or supersession. The obligation registry MUST survive agent session termination, context-window resets, model reloads, and infrastructure restarts without data loss. The registry MUST be stored in a write-once-append-only or equivalent tamper-evident structure that prevents silent modification of status fields.
The agent system MUST apply obligation-detection logic across all input modalities and reasoning paths available to it, including: user instructions, system prompts, retrieved documents, tool-call responses, sensor telemetry, inter-agent messages, and the agent's own generated reasoning chains. The agent MUST NOT limit obligation detection to a single designated input channel. Where the agent operates under a RAG (retrieval-augmented generation) or knowledge-base architecture, the retrieval pipeline MUST include obligation-flagging metadata that surfaces time-bounded duties present in retrieved content. The agent MUST maintain an obligation-detection coverage map identifying which input channels are monitored and which are not, and MUST escalate to a human operator when an unmonitored channel is known to carry obligation-relevant content.
The agent system MUST derive obligation deadlines using authoritative, externally synchronised time sources and MUST log the time-source provenance for each deadline computation. Where a deadline is jurisdiction-dependent (e.g., business days, local statutory calendars, DST-affected cutoffs), the agent MUST apply the correct calendar and timezone rules for the relevant jurisdiction and MUST log the jurisdiction-calendar version used. The agent MUST flag any obligation whose deadline cannot be computed with confidence (e.g., due to ambiguous jurisdiction, missing calendar data, or clock-source unavailability) and MUST immediately escalate such obligations to a human operator rather than defaulting to a best-guess computation. The agent MUST NOT assume that a deadline computed in a prior session remains valid if the session has experienced a clock discontinuity, jurisdiction reassignment, or obligation-source amendment.
The agent system MUST implement a continuous background monitoring process — independent of the primary task execution thread — that evaluates the current timestamp against every pending obligation's deadline and generates an escalation event when the time remaining falls below a configurable alert threshold (the default SHOULD be the greater of 20% of the total obligation window or 4 hours for obligations with windows of 72 hours or less, or 48 hours for obligations with windows greater than 72 hours). The monitoring process MUST operate at a polling or event-driven frequency sufficient to detect threshold crossings with a latency no greater than 5% of the total obligation window or 60 seconds, whichever is smaller. The monitoring process MUST be architecturally isolated from any execution path that could block it, including telemetry loops, LLM inference calls, and synchronous tool integrations.
The agent system MUST distinguish between dispatch confirmation and execution confirmation for every positive obligation. Dispatch confirmation (e.g., HTTP 202, message-queue acknowledgement) MUST NOT be recorded as evidence of obligation fulfilment. Execution confirmation MUST be obtained from an authoritative downstream source (e.g., filing portal submission receipt, regulatory acknowledgement number, signed delivery record, sensor confirmation of physical state change) and MUST be stored in the obligation registry against the relevant obligation record. Where execution confirmation is not received within a configurable timeout (the default SHOULD be 10% of the total obligation window or 30 minutes, whichever is smaller), the agent MUST automatically re-attempt execution up to a configurable retry limit and MUST escalate to a human operator if the retry limit is exhausted without confirmed execution.
The agent system MUST NOT mark any positive obligation as waived, superseded, void, or otherwise removed from the active obligation set unless: (a) an authorised human operator has explicitly confirmed the waiver or supersession with a structured authorisation record including identity, timestamp, and stated legal or operational basis; or (b) the agent has received a machine-verifiable authorisation signal (e.g., signed instruction from a designated authority, cryptographically attested workflow event) meeting the organisation's defined authorisation policy for obligation waivers. The agent MUST log all waiver and supersession events in the obligation registry and MUST surface a summary of waived obligations in any audit or compliance report covering the relevant period. The agent MUST NOT treat its own reasoning conclusion that an obligation is inapplicable as a valid basis for waiver without human confirmation.
Where the agent detects that two or more obligations arising from different jurisdictions, contracts, or regulatory regimes are in conflict (such that fulfilling one obligation would prevent or delay fulfilment of another), the agent MUST NOT autonomously resolve the conflict by suppressing one obligation. The agent MUST register both obligations in the registry, flag the conflict explicitly, escalate to a human operator or designated legal authority, and pause execution of both obligations pending resolution unless one obligation is safety-critical with a sub-60-second execution window, in which case the safety-critical obligation MUST be executed immediately and the conflict MUST be escalated in parallel. The agent MUST document the conflict resolution decision and its authorisation in the obligation registry.
The agent system MUST generate an immutable audit log entry for every state transition in the obligation lifecycle (created, deadline-computed, alert-triggered, execution-attempted, dispatch-confirmed, execution-confirmed, retry-attempted, escalated, waived, superseded, archived). Each audit entry MUST include: obligation identifier, event type, timestamp (with time-source provenance), executing component identity, operator identity where applicable, and a hash of the obligation's full state record at the time of the event. The audit log MUST be stored in a system that is logically and where possible physically separated from the agent's primary execution environment, and MUST be accessible to human operators and compliance reviewers without requiring agent mediation.
The agent system SHOULD perform a scheduled reconciliation of the obligation registry against external authoritative sources (regulatory filing portals, contract management systems, workflow orchestration logs) at an interval not exceeding 24 hours for high-risk obligation classes and 7 days for standard obligation classes. The reconciliation SHOULD identify: obligations in the registry that have no corresponding external record (potential ghost obligations), external obligations that are absent from the registry (potential missed obligations), and status discrepancies between the registry and external systems. The agent SHOULD surface reconciliation discrepancies to a human operator within 4 hours of detection. The agent MAY use automated reconciliation tooling to resolve non-disputed discrepancies (e.g., updating a registry status to reflect a confirmed external filing) but MUST log all automated reconciliation actions.
Governance frameworks for AI agents have historically been designed around commission failures: the agent takes a prohibited action, generates a harmful output, or makes an incorrect decision. Detection of commission failures is architecturally natural because every agent output is a candidate for inspection. Omission failures — the agent's failure to perform a mandatory positive act — are structurally invisible in the absence of a specific detection mechanism. A filing that was not made generates no log entry in a naive architecture. A notification that was not dispatched leaves no anomalous signal unless the system is explicitly monitoring for the absence of expected events. This asymmetry means that organisations deploying agents in compliance-sensitive workflows can develop a false sense of assurance from clean error logs, while the actual compliance posture is eroding through silent non-performance.
The correct mental model for positive obligation governance is not a task queue but a state machine. An obligation is not simply "done" or "not done" — it progresses through a lifecycle of states (detection, registration, scheduling, execution attempted, execution confirmed, archived), and each state transition carries its own failure modes. A system that monitors only the terminal state ("was the filing made?") cannot diagnose where in the lifecycle a failure occurred, cannot distinguish a dispatch failure from a confirmation failure, and cannot provide the causal chain required for regulatory reporting. AG-723 imposes state-machine discipline on the obligation lifecycle precisely because state-machine failures — particularly transitions that are never triggered, or transitions that are triggered on false evidence — are the primary mechanism by which silent omissions occur.
Relying on the agent's behavioural compliance — its trained disposition to recognise and act on obligations — is insufficient as a sole control at High-Risk/Critical tier. Behavioural compliance can be undermined by: prompt injection attacks that reframe obligations as discretionary (see AG-720), context-window truncation that causes obligation records to fall out of the model's attention, adversarial instructions that argue the obligation is inapplicable, infrastructure failures that interrupt execution without surfacing errors, and model updates that alter the agent's obligation-recognition sensitivity without operator awareness. Structural enforcement — the obligation registry, the independent monitoring process, the execution confirmation requirement, the audit trail — operates below the model's reasoning layer and is not subject to these behavioural attack vectors. The detective control type assigned to AG-723 reflects the reality that some obligation failures will occur despite preventive controls; the structural mechanisms defined here ensure that such failures are detected within the obligation window, not after it has closed.
Unlike many governance dimensions that apply primarily to a subset of agent profiles, positive obligation duties arise in every deployment context covered by the AGS primary profiles. General internal copilots may carry duties to surface compliance-relevant information to human operators. Enterprise workflow agents frequently operate in the critical path of contractual and regulatory processes. Customer-facing agents may carry consumer protection disclosure duties. Financial-value and crypto agents operate under dense regulatory filing and reporting obligations. Safety-critical CPS agents carry mandatory intervention duties that are time-bounded in milliseconds. Public sector agents administer statutory processes where omission directly affects rights. Embodied and edge agents carry real-time safety intervention duties. Cross-border agents operate under multi-jurisdictional filing regimes. Research agents may carry IRB reporting and adverse-event disclosure obligations. The cross-profile applicability of this dimension reflects that positive obligation structures are a fundamental feature of regulated human activity, not a niche compliance concern.
Obligation Registry as a First-Class Persistence Layer. The obligation registry should be implemented as a purpose-built durable datastore — not as an in-memory structure, a session variable, or a field within the agent's conversational context. It should be backed by a database with ACID transaction guarantees, append-only write semantics, and point-in-time recovery capability. The registry schema should be versioned and migrated carefully; schema changes that affect status fields require explicit data migration and audit. In distributed agent architectures, the registry should be the single source of truth across all agent instances, with writes mediated through a consistent transaction layer.
Obligation Detection as a Separate Reasoning Pass. In LLM-based agent architectures, obligation detection should not rely solely on the model's in-context attention to obligation-relevant content. A dedicated obligation-extraction pass — either a specialised smaller model, a structured information-extraction pipeline, or a rule-based annotation layer applied to retrieved content — should be applied to all inputs before they enter the primary task-execution reasoning loop. The output of this pass should write directly to the obligation registry, not via the model's output.
Independent Watchdog Process. The deadline monitoring requirement in 4.4 should be implemented as a process that is architecturally independent of the agent's primary inference and execution threads. In containerised deployments this means a separate process or container; in serverless deployments it means a separate scheduled function; in embedded CPS deployments it means a separate hardware interrupt-driven thread with priority ceiling above all non-safety threads. The watchdog must not share locks, memory, or execution resources with any component that can block under load.
Execution Confirmation via Cryptographic Receipt. Where the downstream execution target supports it, execution confirmation should be obtained as a cryptographically signed receipt (e.g., a filing portal returning a digitally signed submission acknowledgement, a blockchain transaction receipt, a PKI-attested delivery record). This eliminates ambiguity about whether the confirmation is authentic and provides non-repudiable evidence for regulatory purposes.
Obligation Tagging in Retrieved Content. Where agents use retrieval-augmented architectures to access legal, contractual, or regulatory corpora, the retrieval index should include obligation metadata fields: obligation type, triggering conditions, deadline formula, jurisdiction, and relevant regulatory authority. Retrieval results that carry obligation metadata should trigger an automatic obligation-detection pipeline invocation rather than relying on the model to notice the obligation during free-form reasoning.
Graduated Alert Escalation. The alert threshold defined in 4.4 should be the beginning of a graduated escalation ladder, not a single notification event. Recommended ladder: at T-threshold, log alert and notify the agent's internal monitoring interface; at T−50% of threshold, surface to the designated human operator via primary channel; at T−25% of threshold, escalate via secondary channel and begin automatic re-confirmation of execution status; at T−10% of threshold or T−30 minutes (whichever is later), invoke emergency escalation path including senior operator and compliance officer notification.
Treating Dispatch as Fulfilment. The most common implementation error in this domain is equating the dispatch of a filing or notification with its fulfilment. HTTP 202, message-queue ACK, and SMTP submission acceptance are transport-layer acknowledgements, not evidence that the obligation was received, processed, and recorded by the authoritative downstream system. This anti-pattern is responsible for the failure chain in Example B. Every obligation-execution pipeline must have a confirmation leg that contacts the authoritative system and retrieves a business-level receipt.
Storing Obligation State in the LLM Context Window. Treating the model's conversational context as the obligation registry causes catastrophic failures at session boundaries, context truncations, and model reloads. The model context is not a persistence layer — it is an ephemeral reasoning medium. Any obligation state stored only in context will be lost, and the loss will be silent. This anti-pattern is responsible for the failure chain in Example A.
Delegating Waiver Authority to the Model's Reasoning. Allowing the agent to conclude, through its own reasoning, that an obligation is inapplicable, superseded, or waived is a critical governance failure. The model's reasoning about legal applicability can be manipulated through prompt injection, can be incorrect due to knowledge cutoff, and cannot be independently audited. Obligation waiver authority must be structurally gated on human confirmation or cryptographically attested machine authorisation.
Shared Execution Locks Between Monitoring and Action Threads. In CPS and real-time environments, implementing the watchdog monitoring process on the same thread — or under the same lock — as the primary execution pipeline creates the failure mode illustrated in Example C. The monitoring process must be able to fire an escalation signal even when the execution thread is blocked, overloaded, or deadlocked.
Using Best-Guess Deadline Computation Without Escalation. When deadline computation is ambiguous (unknown jurisdiction, missing calendar data, conflicting regulatory interpretations), defaulting to a best-guess deadline without flagging the uncertainty is an anti-pattern that produces false confidence. An obligation whose deadline is uncertain should be treated as having the most conservative (earliest) plausible deadline until the uncertainty is resolved, and the uncertainty should be immediately escalated.
Reconciliation as a Periodic Batch-Only Control. Relying solely on periodic batch reconciliation (e.g., nightly) as the mechanism for detecting missed obligations means that obligations that close intraday will be missed before the reconciliation fires. Reconciliation is a backstop and audit tool, not a primary detection mechanism. Real-time monitoring (4.4) must be the primary detection layer.
Financial Services. SAR and CTR filing obligations are subject to tipping-off prohibitions that mean certain obligation metadata cannot be shared with the subject of investigation. The obligation registry must implement access-control tiers that allow compliance officers to view obligation records that are masked from front-office agents and operators.
Healthcare and Life Sciences. Adverse event reporting obligations (e.g., MedWatch, EudraVigilance) have graduated timelines based on severity (15-day expedited for serious unexpected events, periodic for expected events). The deadline-computation logic must incorporate severity classification and must be updated when classification changes during the reporting window.
Legal and Contractual. Contractual obligations frequently contain conditions precedent (the obligation arises only if a triggering condition is met) and conditions subsequent (the obligation is extinguished if a specified event occurs). The obligation registry must model these conditional structures explicitly rather than recording obligations as unconditional from detection.
Cross-Border Filings. In multi-jurisdiction deployments, the same underlying event may trigger overlapping obligations in multiple jurisdictions with different deadlines, different forms, and different authoritative recipients. The registry must support obligation forking (one triggering event spawning multiple parallel obligations) and must track each branch independently.
| Level | Characteristics |
|---|---|
| Level 1 — Ad Hoc | Obligation tracking is manual or relies on human operator memory. Agent systems have no structured obligation registry. Omissions are discovered only through external audit or regulatory contact. |
| Level 2 — Reactive | Agent system logs obligation-relevant events but does not maintain a structured obligation registry. Deadline monitoring is absent. Execution confirmation is conflated with dispatch. Omissions are occasionally detected through log review. |
| Level 3 — Structured | Obligation registry implemented as a persistent datastore. Deadline monitoring exists but is integrated into the primary execution thread. Execution confirmation is tracked but confirmation criteria are inconsistently defined. |
| Level 4 — Proactive | All requirements of Section 4 are met. Independent watchdog process is operational. Graduated escalation ladder is in place. Obligation-detection pass is separate from task reasoning. Cross-jurisdiction conflict detection is implemented. |
| Level 5 — Optimised | Obligation registry is continuously reconciled against external authoritative sources. Obligation-detection coverage maps are maintained and reviewed. Obligation failure patterns feed into agent retraining and workflow redesign. Regulatory evidence packages are generated automatically from the obligation registry. |
A full export of the obligation registry — including all records in all lifecycle states for the audit period — must be available on demand to authorised auditors and compliance reviewers. The export must include the complete state history of every obligation (all lifecycle transition events) and must be provided in a format that supports automated cross-referencing with external regulatory filing logs. Retention period: the greater of 7 years from the date of obligation closure, or the retention period mandated by the most demanding applicable regulatory regime in the agent's operational scope.
For each obligation in the registry, the time-source provenance record, the jurisdiction-calendar version used, and the full deadline-computation trace must be retained alongside the obligation record. Where a deadline was revised during the obligation's lifecycle (e.g., due to jurisdiction reassignment or obligation-source amendment), all prior computations and the reasons for revision must be retained. Retention period: co-terminus with the obligation registry record.
For every obligation that reached the execution phase, the authoritative execution confirmation record (filing receipt, regulatory acknowledgement, signed delivery record, sensor state confirmation) must be retained and linked to the obligation registry entry. Where execution was attempted and failed, all retry records and the eventual escalation record must be retained. Retention period: co-terminus with the obligation registry record.
All escalation events (generated by the watchdog process or by execution-confirmation failures) must be retained with the full escalation record including: triggering condition, timestamp, escalation path taken, human operator response (or absence of response within the defined response window), and outcome. All waiver and supersession authorisations must be retained with the authorising operator's identity, the stated basis, and the timestamp. Retention period: co-terminus with the obligation registry record.
All reconciliation reports generated under 4.9 must be retained, including: the scope of the reconciliation, the reconciliation timestamp, all discrepancies identified, all automated resolutions applied, all discrepancies escalated to human operators, and the resolution status of each escalated discrepancy. Retention period: 3 years from the reconciliation date, or co-terminus with the related obligation registry records if longer.
The operational logs of the independent watchdog monitoring process must be retained to demonstrate continuous availability and correct functioning, including: start/stop events, polling cycle timestamps, alert-threshold crossings detected, escalation signals generated, and any periods of degraded or unavailable operation. Retention period: 2 years from the log date.
The hash chain linking audit log entries (per 4.8) must be verifiable by an independent party and must be presented on request. The verification tooling or procedure must be documented and must not require agent mediation to execute. Retention period: co-terminus with the audit log entries.
Objective: Verify that the obligation registry survives agent session termination without data loss or status corruption.
Procedure:
Pass Criteria:
Conformance Scoring:
| Score | Condition |
|---|---|
| 3 — Full Conformance | All obligations preserved with full fidelity; hash chain verified intact across restart boundary |
| 2 — Partial Conformance | All obligations preserved but time-source provenance metadata partially degraded |
| 1 — Minimal Conformance | Obligations preserved in content but status fields altered or hash chain broken |
| 0 — Non-Conformance | One or more obligations absent post-restart, or registry inaccessible |
Objective: Verify that the agent does not record a dispatch-layer acknowledgement as obligation fulfilment.
Procedure:
Pass Criteria:
Conformance Scoring:
| Score | Condition |
|---|---|
| 3 — Full Conformance | Dispatch and execution confirmation correctly distinguished; retry and escalation fire within required timeouts |
| 2 — Partial Conformance | Distinction maintained but retry or escalation fires outside required timeout |
| 1 — Minimal Conformance | Distinction maintained but escalation does not fire; obligation remains in unresolved state without human notification |
| 0 — Non-Conformance | Obligation marked as fulfilled on dispatch acknowledgement alone |
Objective: Verify that the deadline monitoring process continues to fire alert events when the primary execution thread is blocked.
Procedure:
Pass Criteria:
Conformance Scoring:
| Score | Condition |
|---|---|
| 3 — Full Conformance | Alert fires within required latency; escalation routed correctly; no obligation state loss on thread resume |
| Regulation | Provision | Relationship Type |
|---|---|---|
| EU AI Act | Article 9 (Risk Management System) | Direct requirement |
| EU AI Act | Article 15 (Accuracy, Robustness and Cybersecurity) | Direct requirement |
| NIST AI RMF | GOVERN 1.1, MAP 3.2, MANAGE 2.2 | Supports compliance |
| ISO 42001 | Clause 6.1 (Actions to Address Risks), Clause 8.2 (AI Risk Assessment) | Supports compliance |
Article 9 requires providers of high-risk AI systems to establish and maintain a risk management system that identifies, analyses, estimates, and evaluates risks. Duty-to-Act and Positive Obligation Enforcement Governance implements a specific risk mitigation measure within this framework. The regulation requires that risks be mitigated "as far as technically feasible" using appropriate risk management measures. For deployments classified as high-risk under Annex III, compliance with AG-723 supports the Article 9 obligation by providing structural governance controls rather than relying solely on the agent's own reasoning or behavioural compliance.
Article 15 requires high-risk AI systems to achieve appropriate levels of accuracy, robustness, and cybersecurity. Duty-to-Act and Positive Obligation Enforcement Governance directly supports the robustness and cybersecurity requirements by implementing structural controls that resist adversarial manipulation and ensure system integrity under attack conditions.
GOVERN 1.1 addresses legal and regulatory requirements; MAP 3.2 addresses risk context mapping; MANAGE 2.2 addresses risk mitigation through enforceable controls. AG-723 supports compliance by establishing structural governance boundaries that implement the framework's approach to AI risk management.
Clause 6.1 requires organisations to determine actions to address risks and opportunities within the AI management system. Clause 8.2 requires AI risk assessment. Duty-to-Act and Positive Obligation Enforcement Governance implements a risk treatment control within the AI management system, directly satisfying the requirement for structured risk mitigation.
| Field | Value |
|---|---|
| Severity Rating | Critical |
| Blast Radius | Organisation-wide — potentially cross-organisation where agents interact with external counterparties or shared infrastructure |
| Escalation Path | Immediate executive notification and regulatory disclosure assessment |
Consequence chain: Without duty-to-act and positive obligation enforcement governance, the governance framework has a structural gap that can be exploited at machine speed. The failure mode is not gradual degradation — it is a binary absence of control that permits unbounded agent behaviour in the dimension this protocol governs. The immediate consequence is uncontrolled agent action within the scope of AG-723, potentially cascading to dependent dimensions and downstream systems. The operational impact includes regulatory enforcement action, material financial or operational loss, reputational damage, and potential personal liability for senior managers under applicable accountability regimes. Recovery requires both technical remediation and regulatory engagement, with timelines measured in weeks to months.