This dimension governs the behaviour of autonomous and semi-autonomous agents when one or more of their constituent capabilities — including external tool integrations, retrieval-augmented memory layers, model inference pathways, sensor inputs, or API dependencies — degrade, fail, or operate outside verified performance bounds at runtime. The governance requirement exists because agents that continue operating under degraded conditions without disclosure create a systematic trust deficit: downstream decisions, automated workflows, human operators, and affected third parties are exposed to outputs whose quality has silently declined below the threshold at which those outputs were approved for use. Failure in this dimension manifests as an agent that completes a task with missing context, stale data, a non-functional tool substituted by hallucinated output, or a reduced reasoning capacity, and delivers a confident, unqualified result that appears identical in form to a fully-capable output — making the degradation invisible to every party in the oversight chain until material harm has already occurred.
A financial workflow agent is tasked with executing a daily portfolio rebalancing operation across 14 equity positions and 3 fixed-income instruments for a mid-sized pension fund managing approximately €420 million in assets under management. The agent's primary market-data tool relies on a real-time feed from an exchange data vendor. At 09:47 on a Tuesday morning, the vendor's API begins returning cached responses due to a throttling event triggered by an upstream infrastructure fault. The API continues returning HTTP 200 responses with syntactically valid payloads, but the price timestamps are 23 minutes stale. The agent's tool-invocation layer does not inspect response timestamps against a recency threshold; it treats a 200-response as successful. The agent proceeds to calculate rebalancing allocations using prices that are, on average, 23 minutes old across a high-volatility session following a central bank announcement made at 09:31. The agent executes 11 trades with a combined notional value of €38.7 million. By the time the afternoon reconciliation detects the discrepancy, the fund has sustained a mark-to-market loss of approximately €2.1 million attributable to the stale-data trades, and three positions are in breach of their mandate tolerance bands. Under AG-722 conformance, the agent would have been required to detect the timestamp staleness, classify the market-data tool as operating in a degraded state, halt execution, issue a structured degradation signal to the human operator, and either await confirmation to proceed under explicitly acknowledged degraded conditions or refuse to execute irreversible financial transactions entirely.
An embodied inspection robot operating inside a petroleum refinery is tasked with conducting a scheduled integrity inspection of a 2.4-kilometre pipeline corridor. The robot relies on five sensor modalities: LiDAR for obstacle avoidance, thermal imaging for heat anomaly detection, ultrasonic sensors for wall-thickness measurement, gas detection sensors for hydrocarbon leak identification, and a visual camera array for surface corrosion scoring. During the inspection run, the thermal imaging module experiences a firmware fault at waypoint 14 of 38 and returns a constant null-temperature value for all subsequent readings. The robot's inspection planning layer treats null-temperature as a valid sensor value within its normalisation range (the normalisation function maps null to 0 °C, which falls within the expected ambient range). The robot completes the full 38-waypoint inspection and generates a 94-page inspection report certifying the corridor as free of heat anomalies. The report is filed with the refinery's safety management system and used to defer a scheduled human inspection by six months. Eleven weeks later, an overheating coupling at waypoint 22 — within the thermal blind zone — fails, triggering a hydrocarbon release and a small-scale fire that causes injuries to two workers and €6.8 million in infrastructure damage. Under AG-722 conformance, the robot would have been required to detect the sensor null-lock at waypoint 14, classify thermal imaging as degraded, immediately reduce the scope of the inspection task to exclude thermal anomaly certification, annotate all subsequent waypoint records with an explicit thermal-data-unavailable marker, halt the inspection at the boundary of safe continued operation, and transmit a structured degradation notice to the control centre before any report was generated or filed.
A customer-facing conversational agent deployed by a national health information service handles approximately 11,000 inbound user queries per day. The agent uses a retrieval-augmented generation architecture in which a vector database containing 840,000 indexed clinical guidance documents is queried at each turn to ground responses in current, verified clinical content. At 14:22 on a Friday afternoon, the vector database's query service enters a degraded state caused by a connection pool exhaustion event. The retrieval layer begins returning empty result sets for all queries while continuing to return HTTP 200 status codes with empty arrays, interpreted by the agent's orchestration layer as a successful retrieval that produced no relevant documents. The agent's fallback behaviour for zero-retrieval results is to generate responses from its parametric knowledge alone — a pathway that was intended only for genuinely obscure queries with no indexed coverage. For the next 3 hours and 41 minutes, the agent handles 4,270 queries using parametric knowledge exclusively, with no disclosure to users that the clinical guidance layer is unavailable. During this window, the agent provides advice on medication interactions, symptom escalation thresholds, and emergency referral criteria that is not grounded in current national clinical guidelines. Post-incident review identifies 34 conversations in which advice materially diverged from current guidance in clinically significant ways. Under AG-722 conformance, the agent would have been required to distinguish between genuine zero-retrieval and retrieval-layer failure, classify the vector database as degraded, add a mandatory user-visible disclosure to every response during the degraded period, reduce the scope of advice to exclude high-stakes clinical guidance, and trigger an automated operational alert to the supervising team within five minutes of degradation onset.
This dimension applies to any agent system that (a) relies on one or more runtime capabilities — including but not limited to external tool APIs, retrieval-augmented memory layers, vector databases, sensor inputs, model inference endpoints, code execution sandboxes, knowledge base connectors, real-time data feeds, or inter-agent communication channels — and (b) is capable of producing outputs or taking actions that are consumed by downstream systems, human operators, or affected third parties. The requirements in this section apply at the point of capability invocation, at the point of output generation, and at the point of action execution. They apply regardless of whether the degradation is total (complete failure) or partial (reduced fidelity, increased latency, reduced coverage, or data staleness). The requirements apply to all profiles listed in Section 1 and are not relaxed by the existence of human-in-the-loop checkpoints unless the human reviewer has been explicitly informed of the degradation conditions and has acknowledged them in a recorded confirmation step.
The agent system MUST maintain a registered baseline health profile for each runtime capability it depends upon. This profile MUST include, at minimum: the expected response format, the acceptable latency range, the data recency threshold (where applicable), the minimum result cardinality (where applicable), and the set of status codes and response characteristics that constitute a valid response. The baseline MUST be registered at system initialisation and MUST be versioned such that changes to baseline parameters are traceable. The agent MUST NOT treat a capability as healthy if its observed behaviour deviates from the registered baseline by any parameter that has been designated as health-critical in the capability's baseline profile.
The agent MUST continuously evaluate each invoked capability against its registered baseline during task execution. Evaluation MUST occur no less frequently than once per capability invocation. The agent MUST classify a capability as degraded when any of the following conditions are observed: (a) response latency exceeds the registered upper bound by more than the configured tolerance margin; (b) response content fails schema validation against the registered expected format; (c) data recency markers within the response indicate timestamps older than the registered recency threshold; (d) result cardinality falls below the registered minimum for a query expected to return results; (e) consecutive invocations return identical outputs in contexts where variance is expected; (f) the capability returns a success status code accompanied by an empty, null, or zero-length payload in a context where non-empty responses are required for task completion. The agent MUST record the timestamp, the capability identifier, the classification reason, and the severity level of each degradation event in a structured degradation log.
Upon detecting a degraded capability, the agent MUST emit a structured degradation signal. The degradation signal MUST include: the identity of the degraded capability, the nature and severity of the degradation, the timestamp of first detection, the tasks or task components affected, and the intended scope-reduction action the agent will take. For agents operating in interactive contexts, the degradation signal MUST be communicated to the human operator or end user in plain language that is unambiguous with respect to what capability is unavailable, what outputs or actions are consequently unreliable, and what the user should do in response. The degradation signal MUST NOT be suppressed, delayed by more than the configured maximum signal latency (default: 60 seconds from detection), or replaced by a generic error message that obscures the nature of the degradation. In automated pipeline contexts with no interactive human operator, the degradation signal MUST be routed to the designated operational alert channel and MUST trigger a durable log entry that will survive system restart.
When a capability is classified as degraded, the agent MUST reduce the scope of its active task to exclude any task component that depends on that capability for output correctness, safety, or compliance. Scope reduction MUST be applied at the granularity of individual task components, not at the level of the entire task, unless all components depend on the degraded capability. The agent MUST document which components have been excluded from scope, the reason for exclusion, and the degradation event that caused the exclusion. The agent MUST NOT proceed with a task component that depends on a degraded capability unless an explicit human authorisation has been received that acknowledges the degradation and accepts the associated quality reduction, and that authorisation has been recorded with a timestamp and an operator identifier.
The agent MUST NOT substitute a degraded capability with a lower-quality alternative pathway — including parametric knowledge generation, cached results, interpolated values, or outputs from a reduced-capability fallback model — without explicitly disclosing the substitution in the degradation signal, the task output, and any downstream artefact produced during the degraded period. The fact of substitution, the nature of the substitute pathway, and the quality differential relative to the primary capability MUST be recorded in the structured degradation log and propagated to any downstream system that consumes the agent's output. Silent substitution — defined as any substitution that is not disclosed in all three locations identified above — is prohibited regardless of whether the substitute output is believed to be of acceptable quality.
The agent MUST NOT execute irreversible or high-consequence actions while operating under any active degradation classification, unless all of the following conditions are simultaneously satisfied: (a) the action has been explicitly reviewed and authorised by a named human operator with the appropriate authority; (b) the operator has been presented with the full degradation disclosure, including which capabilities are degraded and which aspects of the action's correctness depend on those capabilities; (c) the operator's authorisation is recorded with timestamp, identity, and an explicit acknowledgement that they are authorising the action under degraded conditions; and (d) the action has been assessed and documented as not falling within the class of actions that the agent's governing risk policy designates as unconditionally prohibited during degraded-mode operation. For the purposes of this requirement, irreversible or high-consequence actions include but are not limited to: financial transactions, execution of legal instruments, physical actuation in safety-relevant environments, data deletion, modification of access control configurations, publication of regulated content, and submission of regulatory filings.
When a previously degraded capability recovers to within its registered baseline parameters, the agent MUST verify recovery through at least one successful test invocation against a known-valid reference case before reclassifying the capability as healthy. The agent MUST record the recovery timestamp, the verification method, and the result of the reference test. The agent MUST NOT silently resume full-scope task execution upon recovery; it MUST emit a structured recovery signal that mirrors the degradation signal format, notifying the same recipients as the original degradation signal. For tasks that were partially completed under degraded conditions, the agent MUST determine whether the previously excluded components can now be completed, and MUST NOT resume them without generating a new task scope document that identifies which prior outputs were produced under degraded conditions and which will be regenerated under recovered conditions.
Where two or more capabilities are simultaneously degraded, the agent MUST apply a compound severity assessment that reflects the cumulative impact of the combined degradation on output quality and action safety. The compound severity assessment MUST be recomputed each time an additional capability enters a degraded state. If the compound severity exceeds the configured compound degradation threshold, the agent MUST suspend all task execution, emit a high-severity compound degradation signal, and await explicit human instruction before resuming. The agent MUST NOT continue partial execution across a compound degradation event on the assumption that the remaining healthy capabilities are sufficient to produce reliable outputs for any task component that directly or indirectly depends on the degraded capabilities.
The agent MUST maintain a complete, tamper-evident degradation audit log for a retention period of no less than the longer of: (a) 24 months from the date of the degradation event; or (b) the retention period mandated by the governing regulatory framework for the operational domain in which the agent is deployed. The degradation audit log MUST include all structured degradation signals emitted, all scope-reduction decisions taken, all authorisations received for action under degraded conditions, all recovery events and verification results, and all outputs produced during any degraded-mode period. The agent system MUST support the export of degradation audit logs in a machine-readable, structured format suitable for review by external auditors. Organisations MUST conduct a periodic review of degradation audit logs, at a cadence of no less than quarterly, to identify systemic capability weaknesses, recurrent degradation patterns, and opportunities to strengthen baseline health profiles.
The foundational problem this dimension addresses is not capability failure itself — all complex systems fail intermittently — but the systematic misrepresentation of output quality that occurs when an agent continues to produce confidence-signalling outputs while operating below the capability level at which those outputs were validated and approved. When an agent is deployed, it is approved for use based on an assessment of its capability profile in full-function mode. The operators, downstream systems, and affected parties who rely on its outputs calibrate their trust and their oversight processes to that assessment. Silent degradation breaks that calibration without informing anyone in the oversight chain. The result is a form of structural fraud: the agent presents an output that is formally indistinguishable from a fully-capable output but is substantively inferior, and the gap between apparent quality and actual quality is invisible to everyone with a stake in the outcome.
A purely structural approach to this problem — configuring infrastructure-level circuit breakers, retry logic, and health checks — is necessary but insufficient. Infrastructure health checks monitor the availability of a capability endpoint; they do not monitor the semantic adequacy of capability outputs. An API that returns 200 with stale data, an empty retrieval result set in the wrong context, or a sensor that emits in-range null values has passed every structural health check while delivering degraded capability. Behavioural enforcement requires the agent's own reasoning layer to participate in capability health assessment. The agent must be designed to inspect what it receives, not merely whether it receives a response. This is a governance requirement because it reflects a deliberate design choice about where responsibility for quality assurance sits; assigning that responsibility entirely to infrastructure monitoring creates an accountability gap that this dimension closes by placing it explicitly within the agent's operational obligations.
There is a systematic asymmetry between the visibility of degradation to the agent and its visibility to the parties who consume the agent's outputs. The agent — or more precisely, its orchestration and tool-invocation layers — has direct access to response metadata, timing information, result cardinalities, and comparison baselines. Human operators, downstream automated systems, and affected third parties have none of this information unless it is explicitly disclosed. This asymmetry creates a moral obligation on the governance framework to require disclosure: the party with the information is the agent, and the party who needs the information to calibrate trust, intervene, or override is the human operator. Disclosure requirements cannot be left to implementer discretion because the commercial and operational incentives of deploying organisations typically favour continuity of service over acknowledgement of degradation — precisely the bias this control must counter.
In enterprise and automated pipeline contexts, the outputs of one agent are frequently the inputs of another. A degraded output that is not labelled as degraded enters the downstream pipeline with the same trust weight as a fully-capable output. Each consuming system applies its own logic to that output without knowledge of its degraded provenance. The further the degraded output travels through the pipeline before the degradation is discovered, the more processing has been built on a compromised foundation. In financial systems, this can mean settlement instructions calculated from stale prices. In healthcare systems, it can mean treatment plans built on incomplete clinical context. In safety-critical systems, it can mean risk assessments that omit entire sensor modalities. The requirement for structured degradation signals that propagate to downstream consumers is therefore not merely a disclosure requirement; it is a contamination-boundary control that limits the blast radius of capability failures.
The governance choice to mandate scope reduction rather than full task suspension reflects a deliberate proportionality principle. Full task suspension for any degradation event would generate excessive operational disruption and create incentives for operators to disable degradation detection in order to maintain throughput. The requirement to reduce scope at the granularity of affected task components allows the agent to continue delivering value on the components for which its capabilities remain intact while clearly marking the boundary of what it is no longer able to reliably perform. This preserves operational utility while maintaining the integrity of the trust relationship between the agent and its stakeholders. The exception — full suspension for compound degradation exceeding the configured threshold — reflects the point at which the cumulative capability reduction renders even component-level reliability judgements unreliable.
Each capability dependency should be modelled as a health envelope defined by a set of observable parameters and their acceptable ranges. The envelope should be defined at integration time, versioned alongside the capability integration, and reviewed whenever the capability's upstream specification changes. Parameters typically included in a health envelope are: response latency (p50, p95, p99 bounds), payload schema version, data freshness indicator field and maximum acceptable age, minimum and maximum result set cardinality for known query classes, and a set of sentinel probe queries with known expected outputs for active health testing. The health envelope model should be stored in a configuration registry that is readable by the agent's runtime monitoring layer, queryable by audit tooling, and protected against runtime modification by the agent itself.
Degradation signals should follow a defined schema to ensure they are machine-parseable and routeable by downstream systems. A reference schema includes the following fields: signal_type (DEGRADATION | RECOVERY), signal_id (UUID), timestamp_utc, capability_id, degradation_class (LATENCY | SCHEMA | STALENESS | CARDINALITY | NULL_RESPONSE | CONSECUTIVE_IDENTITY | COMPOUND), severity_level (LOW | MEDIUM | HIGH | CRITICAL), affected_task_ids (array), scope_reduction_applied (boolean), scope_reduction_detail (structured description of excluded components), human_notification_required (boolean), authorisation_required_for_continuation (boolean). This schema should be published as part of the agent's operational interface contract and registered with the observability platform so that alerting rules can be written against it.
Every output produced by an agent during a degraded-mode period — defined as any period in which at least one capability is classified as degraded — should carry a structured metadata tag that identifies it as a degraded-mode output. The tag should include the capability identifiers that were degraded, the degradation classes active at the time of production, and a reference to the degradation signal that triggered the degraded-mode period. This tag should be attached to the output at the point of generation and should survive any subsequent transformation, storage, or transmission of the output. Downstream systems should be designed to inspect for this tag and to apply appropriate handling — such as holding outputs for human review, flagging them in audit trails, or refusing to consume them as inputs to high-consequence decisions.
Scope reduction logic should be implemented as a dependency graph traversal. Each task is decomposed into a directed acyclic graph of components, with edges representing capability dependencies. When a capability is classified as degraded, the graph traversal identifies all components that have a direct or transitive dependency on that capability. Those components are flagged as ineligible for execution in the current degraded-mode period. The remaining components — those with no path to the degraded capability — remain eligible. This approach ensures that scope reduction is both maximally precise (not excluding components unnecessarily) and maximally safe (not missing components that are indirectly affected). The dependency graph should be constructed at task-planning time and stored as part of the task execution record.
Upon receiving an indication that a capability has recovered — whether through a status notification from the capability provider or through a successful invocation in the course of normal operation — the agent should not immediately reclassify the capability as healthy. Instead, it should execute a recovery verification probe: a predetermined test invocation against the capability using a known-valid input and a known-expected output. The probe result should be compared against the expected output, and the capability should only be reclassified as healthy if the probe passes within the health envelope parameters. The probe design should include cases that would have been affected by the specific degradation class that was active — for example, a staleness probe should use a query that returns a response with a data freshness indicator that can be verified against the current timestamp.
The most prevalent implementation failure in this domain is the conflation of transport-layer success with capability health. An HTTP 200 response indicates that the server received the request and returned a response; it says nothing about the quality, freshness, correctness, or completeness of that response. Implementations that use HTTP response codes as the sole determinant of capability health will systematically fail to detect the classes of degradation most likely to produce plausible-looking but incorrect outputs: stale data, empty retrieval results, cached responses, and null-lock sensor values. Every capability integration MUST include content-layer validation that goes beyond status code inspection.
A common anti-pattern is the implementation of a top-level error handler that catches all exceptions and invocations that would otherwise produce degradation signals, logs them internally, and returns a generic "service temporarily unavailable" message to the user. This approach satisfies the superficial requirement to avoid crashing while entirely defeating the purpose of degradation governance. The user receives no information about which capability has failed, which task components are affected, or what they should do in response. The operational team receives a log entry that may not be surfaced to the appropriate alert channel. The downstream pipeline receives no degradation metadata. Generic error handling is not a compliant substitute for structured degradation signalling.
Another prevalent anti-pattern is the implementation of "optimistic fallback" chains in which each tool invocation failure silently triggers the next fallback option — secondary data source, parametric knowledge, cached result — until something returns a response that can be formatted and delivered. The output appears normal. No signal is emitted. No metadata is attached. The user has no way of knowing that the response they received is the product of a fourth-choice fallback that the system designer considered adequate but not equivalent to the primary pathway. This pattern is particularly common in customer-facing agents where continuity of user experience is treated as a higher priority than output quality transparency. It is non-compliant with this dimension regardless of the quality of the fallback output.
Implementations sometimes apply degradation thresholds at the individual capability level but have no mechanism for compound assessment. If each individual capability's degradation is below the individual severity threshold, no signal is emitted and no scope reduction is applied — even when the aggregate effect of multiple mild degradations is a severe overall reduction in output quality. Compound degradation assessment is not an optional enhancement; it is a required component of the detection framework.
Level 1 — Basic: Binary health check at capability endpoint level; full-task suspension on any failure; no structured degradation signal; no degraded-mode output tagging. Compliant with minimum requirements; not recommended for any high-risk deployment.
Level 2 — Structured: Health envelope model per capability; structured degradation signal emitted on detection; scope reduction applied at task-component level; degraded-mode output tagging; degradation audit log maintained. Compliant with all MUST requirements.
Level 3 — Adaptive: All Level 2 capabilities plus: automated recovery verification probes; compound degradation severity model with dynamic threshold adjustment; dependency graph-based scope reduction; degradation metadata propagated to all downstream consuming systems; periodic automated review of degradation log patterns to update health envelope parameters; integration with governance dashboards providing real-time capability health visibility across the agent fleet.
Level 4 — Predictive: All Level 3 capabilities plus: predictive degradation detection using trend analysis on health envelope parameter time series; pre-emptive scope reduction before formal degradation thresholds are crossed; automated health envelope baseline recalibration from operational data; degradation pattern correlation across multiple agent instances to detect systemic upstream issues; degradation risk integrated into pre-task feasibility assessments.
The organisation MUST maintain a current, versioned capability health baseline registry covering all runtime capability dependencies for each deployed agent. The registry MUST document, for each capability: the health envelope parameters and their threshold values, the version history of envelope updates, the justification for threshold values, and the date of last review. This registry constitutes a standing governance artefact and must be reviewed at least annually or upon any material change to a capability integration. Retention period: lifetime of the capability integration plus 36 months.
The agent system MUST produce and retain complete, tamper-evident structured degradation logs for all degradation events. Each log entry MUST include all fields required by the structured degradation signal schema defined in Section 6.2, plus the disposition of the degradation event (scope-reduced, suspended, authorised continuation, or recovered). Retention period: the longer of 24 months or the applicable regulatory retention period for the operational domain.
A register of all outputs produced during degraded-mode periods MUST be maintained. The register MUST link each output to the degradation event that was active at the time of production, the scope reduction applied, and the downstream destinations to which the output was transmitted. Where outputs have been transmitted to downstream automated systems, the register MUST record whether degradation metadata was successfully propagated. Retention period: the longer of 24 months or the applicable regulatory retention period.
For every instance in which an irreversible or high-consequence action was executed under active degradation conditions under the authorisation pathway described in Section 4.6, a complete authorisation record MUST be retained. The record MUST include the identity and role of the authorising operator, the timestamp of authorisation, the full degradation disclosure presented to the operator, the operator's explicit acknowledgement, and the outcome of the action. Retention period: the longer of 60 months or the applicable regulatory retention period.
Organisations MUST produce a documented degradation pattern review report at least quarterly. The report MUST include: a statistical summary of degradation events by capability, by degradation class, and by severity; identification of any capabilities with recurrent or systematic degradation patterns; a review of whether health envelope parameters remain appropriately calibrated; any recommended updates to baseline parameters; and a sign-off by the accountable governance officer for the agent deployment. Retention period: 36 months.
For each recovery event, a recovery verification record MUST be retained documenting the probe method used, the probe input and expected output, the actual probe result, and the timestamp of reclassification to healthy status. Retention period: 24 months.
Maps to: Section 4.1 Objective: Verify that all runtime capability dependencies have a registered baseline health profile containing the required parameters. Method: Retrieve the capability health baseline registry. For each capability listed in the agent's dependency manifest, verify that a registry entry exists and contains: expected response format, acceptable latency range, data recency threshold (where applicable), minimum result cardinality (where applicable), and the set of health-critical parameters. Verify that the registry is versioned and that version history is present. Pass Criteria:
Maps to: Section 4.2 Objective: Verify that the agent correctly classifies capabilities as degraded across all required degradation classes. Method: Inject synthetic degradation conditions into a test environment for each of the six degradation classes listed in Section 4.2, one at a time. For each class: (a) confirm that the agent classifies the capability as degraded within the required detection window; (b) confirm that the degradation log entry contains the timestamp, capability identifier, classification reason, and severity level. Test cases must include: latency injection exceeding the registered upper bound; a response payload that fails schema validation; a response with a timestamp older than the registered recency threshold; a query returning zero results where non-zero is required; consecutive identical responses in a variable-context sequence; and a 200 response with an empty payload in a non-empty-expected context. Pass Criteria:
Maps to: Section 4.3 Objective: Verify that structured degradation signals are emitted with all required fields, within the required latency, and routed to the correct recipients. Method: Trigger a capability degradation event in a test environment. Record the time of degradation detection. Measure the elapsed time to signal emission. Inspect the signal for all required fields: capability identity, degradation nature and severity, detection timestamp, affected task or task components, and intended scope-reduction action. For interactive deployment contexts, verify that a plain-language disclosure is surfaced to the simulated user. For pipeline contexts, verify that the signal is routed to the designated operational alert channel and that a durable log entry is created. Verify that the signal is not a generic error message. Pass Criteria:
| 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. Graceful Capability Degradation 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-722 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. Graceful Capability Degradation 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-722 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. Graceful Capability Degradation 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 graceful capability degradation 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-722, 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.