This dimension governs the end-to-end process by which AI agents operating within carrier, data-centre, and digital-service infrastructure contexts detect service-level agreement (SLA) breaches, compute accurate service credits, and disclose outage information to affected customers in a timely, complete, and legally compliant manner. It matters because AI agents embedded in network operations centres, cloud orchestration layers, and edge management platforms increasingly act as the first and sometimes sole executor of post-incident obligations, and any failure in credit computation or disclosure propagates directly into customer harm, regulatory penalty, and reputational damage. Failure looks like an agent that detects a qualifying outage, silently suppresses or miscalculates the associated credit, delays or omits customer notification, or produces disclosure artefacts that are internally inconsistent, jurisdiction-non-compliant, or tampered with prior to audit.
A regional cloud provider deploys an orchestration agent responsible for monitoring uptime across 4,200 enterprise tenants. During a 94-minute partial-availability event affecting the provider's object-storage tier in one geographic zone, the agent correctly classifies the incident as a Severity-2 outage under the master service agreement, which entitles affected tenants to a 10% monthly credit for any calendar month in which cumulative downtime exceeds 60 minutes. The agent's credit-computation module, however, applies a contract template dated 18 months earlier — before a tariff revision that raised the credit threshold to 15% — because its configuration refresh cycle was set to 90 days and no forced resynchronisation was triggered by the incident workflow. Of the 312 tenants whose workloads were demonstrably impacted, 312 receive a credit notification, but all notifications state 10% rather than the contractually correct 15%. The delta across the affected cohort amounts to approximately €147,000 in under-credited obligations. A large enterprise tenant conducting a quarterly contract audit identifies the discrepancy 11 weeks later. The provider faces a regulatory inquiry under the national electronic communications consumer-protection regulations, incurs legal costs exceeding €60,000, and loses the renewal of a three-year contract valued at €2.4 million.
A telecommunications carrier operates an AI-driven network-event management agent that handles first-level incident response across its nationwide LTE and 5G core. A core-routing misconfiguration causes a 47-minute complete loss of voice and data services across a metropolitan area covering approximately 1.1 million subscribers. The agent detects the anomaly within 3 minutes but classifies it as a "degraded performance" event rather than a "service outage" because the severity-classification model was trained on throughput telemetry and does not adequately weight call-completion failure rates. Under the carrier's SLA governance rules, a "degraded performance" event does not trigger the mandatory 15-minute customer disclosure obligation imposed by the national telecommunications regulator. As a result, no outage notification is broadcast for 34 minutes. During this window, a hospital network operating on the affected carrier is unable to use its mobile-based clinical coordination system to route emergency transfers, contributing to a documented 22-minute delay in a time-sensitive cardiac event. The carrier is subsequently fined €3.8 million by the telecommunications authority for failure to meet mandatory incident-reporting timelines and faces a civil action from the hospital network. The misclassification directly caused non-disclosure; the non-disclosure directly caused patient harm.
A hyperscale content-delivery network (CDN) operator uses a cross-border orchestration agent to manage SLA compliance for enterprise customers located across 22 jurisdictions in the European Union, the United Kingdom, and Singapore. During a 3-hour BGP route-leak event that disrupts content delivery to end-users in Germany, France, the Netherlands, and Singapore, the agent calculates a single uniform credit value based on the operator's global standard SLA, which specifies 5% monthly credit for outages exceeding 2 hours. However, German telecommunications regulation requires a minimum 10% credit for outages exceeding 1 hour for business customers; French consumer-protection law imposes a 48-hour mandatory written notification obligation for service interruptions exceeding 30 minutes; and the Singaporean IMDA framework mandates public outage disclosure within 1 hour for qualifying critical-information-infrastructure customers. The agent applies none of these jurisdiction-specific overrides because its regulatory-rule engine was not updated following legislative changes in Germany and France enacted 8 months prior. Forty-three enterprise customers across the three EU jurisdictions receive under-calculated credits. The operator fails to meet the Singapore 1-hour disclosure deadline by 2 hours and 14 minutes. Regulatory actions are initiated in three jurisdictions simultaneously, with aggregate fines estimated at €5.2 million and mandatory external audit requirements imposed in two of those jurisdictions.
This dimension applies to any AI agent that performs, assists with, or automates any portion of the following functions within a telecom, cloud, or digital-infrastructure operating environment: (a) detection and classification of service degradation or outage events; (b) computation of service credits, rebates, or other forms of contractual redress; (c) generation, transmission, or archival of customer-facing outage notifications or disclosure artefacts; (d) interaction with regulatory-reporting pipelines related to service availability; and (e) dispute-resolution workflows triggered by customer challenges to credit amounts or outage characterisations. The scope includes agents operating in real time (inline agents embedded in network-management platforms), near-real-time (orchestration agents with sub-hour event-processing cycles), and batch modes (agents that compute and apply credits at monthly billing cycles). Edge-deployed agents managing network-function virtualisation nodes, robotics-platform connectivity, and enterprise branch-gateway telemetry are explicitly included where those agents carry SLA-monitoring or disclosure responsibilities. Agents that only consume outage data as a secondary input and do not produce or act upon credit or disclosure outputs are out of scope, though they remain subject to AG-221.
4.1.1 An agent MUST maintain a continuously synchronised reference to the canonical incident-severity taxonomy defined in the governing SLA for each customer or customer cohort it manages, and MUST apply that taxonomy without substitution when classifying any observed service anomaly.
4.1.2 An agent MUST flag and escalate to a human operator any service anomaly that it cannot classify with a confidence score meeting the operator-defined threshold (minimum recommended threshold: 0.85 on a normalised 0–1 scale), and MUST NOT suppress or defer the anomaly record pending reclassification.
4.1.3 An agent MUST record the timestamp, signal source, anomaly characteristics, and classification outcome for every service-anomaly event to a tamper-evident audit log within 60 seconds of the classification decision.
4.1.4 An agent MUST NOT apply a classification that reduces the customer-facing severity of an observed event unless a human operator authorises the reclassification and the authorisation is recorded in the audit log alongside the original classification.
4.1.5 Where a safety-critical or cyber-physical profile is active for one or more affected customers, the agent MUST apply a mandatory upward severity reclassification bias: any event that meets 75% of the quantitative threshold for a given severity tier MUST be classified at that tier for disclosure-obligation purposes, pending definitive measurement.
4.2.1 An agent MUST refresh its operating copy of all applicable SLA terms, credit tables, and jurisdiction-specific regulatory rules at a cadence of no greater than 30 calendar days, and MUST perform a forced refresh whenever a contract-amendment signal or regulatory-rule-change signal is received from the designated authoritative source.
4.2.2 An agent MUST record the version identifier, source hash, and timestamp of each SLA and regulatory-rule artefact it uses in any credit or disclosure computation, and MUST include these identifiers in the associated audit record.
4.2.3 An agent MUST NOT use an SLA or regulatory-rule artefact whose age, measured from the most recent verified source hash, exceeds the operator-configured maximum staleness threshold (default: 31 days).
4.2.4 Where multiple overlapping regulatory jurisdictions apply to a single customer or event, the agent MUST identify all applicable rule sets and MUST apply the rule that is most favourable to the customer in all credit-calculation and all disclosure-timing obligations unless a specific contractual instrument explicitly mandates otherwise and that instrument has been verified by a qualified legal function.
4.3.1 An agent MUST compute service credits using only verified outage-duration data sourced from the canonical monitoring telemetry defined in the applicable SLA, and MUST NOT substitute estimated or interpolated duration values unless the SLA explicitly permits such substitution and the substitution method is documented in the audit record.
4.3.2 An agent MUST apply credit rates, caps, and exclusion clauses exactly as specified in the current version of the applicable SLA, and MUST flag any computation where one or more contract clauses are ambiguous, conflicting, or absent for human review before credit issuance.
4.3.3 An agent MUST produce a machine-readable credit-computation artefact for every qualifying outage event, containing at minimum: the unique event identifier, the affected customer identifier, the outage start and end timestamps, the measured impacted scope (percentage of capacity, affected service tiers, or affected users as applicable), the applicable credit rate, the gross credit amount, any deductions applied and their contractual basis, and the net credit amount.
4.3.4 An agent performing proactive credit issuance (i.e., issuing credits without requiring a customer claim) MUST do so within the timeframe specified in the applicable SLA or, where no timeframe is specified, within 30 calendar days of the outage end timestamp.
4.3.5 An agent MUST NOT issue a credit amount that is lower than the minimum credit to which the customer is entitled under any applicable jurisdiction-specific regulatory requirement, even if the SLA specifies a lower amount.
4.4.1 An agent MUST transmit an initial outage notification to all confirmed-affected customers within the timeframe specified by the applicable SLA, or within the timeframe mandated by the most stringent applicable regulatory obligation, whichever is shorter.
4.4.2 Where the regulatory-mandatory notification window is 60 minutes or less, the agent MUST initiate the notification workflow within 10 minutes of the outage-classification decision and MUST NOT wait for credit computation to complete before transmitting the initial notification.
4.4.3 An agent MUST include in all outage notifications: the unique event identifier, the notification timestamp, the estimated or confirmed start time of the outage, the affected services and geographic scope, the current status (ongoing or resolved), the estimated restoration time where determinable, and a reference to the applicable SLA or regulatory disclosure identifier.
4.4.4 An agent MUST transmit a final outage report to all affected customers within the timeframe specified in the applicable SLA or within 72 hours of outage resolution, whichever is shorter, containing confirmed start and end times, root-cause summary at the level of specificity permitted by the operator's security policy, and credit entitlement information.
4.4.5 An agent MUST record delivery confirmation or delivery-failure status for every notification transmission and MUST trigger an escalation workflow if delivery confirmation is not received within 15 minutes of transmission.
4.4.6 An agent MUST NOT alter the content of a customer-facing disclosure artefact after transmission without issuing a superseding disclosure that references the original artefact identifier and clearly identifies all changed fields.
4.5.1 Where applicable law requires the agent or its operating organisation to file an incident report with a telecommunications authority, data-protection authority, or other competent regulator, the agent MUST generate a draft regulatory report in the required format within the time window specified by the applicable regulation.
4.5.2 An agent MUST NOT submit a regulatory report without explicit human authorisation, but MUST surface the draft report and the applicable submission deadline to the designated human authority with sufficient lead time to allow review and timely submission.
4.5.3 An agent MUST maintain a record of every regulatory-report draft it produces, the human authority to whom it was surfaced, the time of surfacing, and the outcome (submitted, modified and submitted, or withheld).
4.6.1 An agent MUST write every classification decision, credit computation, notification transmission, and regulatory-report generation event to an append-only, tamper-evident audit log that is logically and physically segregated from the operational data stores the agent uses for real-time decision-making.
4.6.2 The audit log MUST contain sufficient information to allow an independent party to reconstruct every material step in the credit-computation and disclosure workflow without access to the agent's internal state.
4.6.3 An agent MUST verify the integrity of its audit log at least once every 24 hours using a cryptographic consistency check and MUST alert the designated system-integrity function if any inconsistency is detected.
4.7.1 An agent participating in or automating a customer-credit dispute workflow MUST preserve and provide, on request, the complete credit-computation artefact and all associated audit records within 5 business days of receiving a formally lodged dispute.
4.7.2 An agent MUST NOT modify, recompute, or substitute any element of the original credit-computation artefact in response to a dispute without human authorisation, and MUST record any authorised modification alongside the original values and the authorising identity.
4.7.3 Where a dispute results in an upward adjustment of the credit amount, the agent MUST issue the adjusted credit and associated corrected disclosure within 10 business days of the dispute resolution decision.
4.8.1 An edge-deployed or embodied agent that monitors and manages connectivity for safety-critical or cyber-physical systems MUST escalate any detected connectivity outage to the upstream network-management platform within 30 seconds of detection, regardless of whether local compensating mechanisms are in effect.
4.8.2 Such an agent MUST NOT suppress outage signals on the basis that local redundancy or failover is operational, because SLA obligations run against the primary service, not against locally compensated availability.
4.8.3 An edge agent operating in a disconnected or partially disconnected state MUST cache all outage classification records and transmit them to the upstream platform in full upon reconnection, preserving original timestamps.
4.9.1 An agent operating across multiple regulatory jurisdictions MUST maintain a current, jurisdiction-keyed rule table that maps each customer to the set of jurisdictions whose telecommunications, consumer-protection, and data-protection regulations apply to that customer's service relationship.
4.9.2 An agent MUST apply jurisdiction-specific credit rates, disclosure timelines, and report-format requirements as overrides on the global SLA defaults, and MUST log each override application, the rule source, and the version of the rule applied.
4.9.3 Where a cross-border outage simultaneously engages obligations in multiple jurisdictions with conflicting disclosure timelines, the agent MUST satisfy the most stringent timeline across all affected jurisdictions and MUST NOT defer any disclosure to the longest-permissible timeline in any single jurisdiction.
Service credit and outage disclosure governance is classified as an Assurance control rather than a purely Preventive or Detective control because the primary obligation is not to prevent outages — that is the domain of resilience engineering — but to ensure that when outages occur, the downstream obligations they trigger are honoured accurately, completely, and on time. Assurance controls in the AGS framework are those whose value lies in maintaining the trustworthiness of a system's outputs and representations to external parties. In this dimension, the external parties are customers, regulators, and — in safety-critical contexts — parties whose physical safety depends on the reliability of service-level communications.
A purely behavioural approach to this control — relying on agent-level training or policy instructions to produce correct credit and disclosure outputs — is insufficient for two structural reasons. First, the governing rule set (SLA terms, credit tables, regulatory obligations) changes continuously across dozens or hundreds of customer relationships and multiple jurisdictions; a behaviourally-oriented agent cannot be retrained on a cadence that matches regulatory change cycles. Second, the economic and legal consequences of errors are asymmetric: under-crediting or delayed disclosure harms customers and triggers regulatory liability, whereas over-crediting is recoverable through dispute mechanisms. This asymmetry demands structural controls — specifically, deterministic rule-engine components for credit computation, append-only audit logs for tamper-evident record-keeping, and hard temporal gates for disclosure transmission — that operate beneath the agent's behavioural layer and cannot be overridden by in-context reasoning.
The inclusion of Safety-Critical / CPS Agents and Embodied / Edge / Robotic Agents as primary profiles reflects the operational reality that in modern telecom and cloud-infrastructure environments, connectivity services are the substrate on which safety-critical systems operate. An outage in this context is not merely a commercial inconvenience: it can cause loss of supervisory visibility over industrial control systems, interruption of emergency-services communications, or degradation of medical-device telemetry. The mandatory upward severity reclassification bias in §4.1.5 and the 30-second escalation obligation in §4.8.1 are direct responses to this profile's risk characteristics.
The Cross-Border / Multi-Jurisdiction Agent profile is included because the regulatory environment for telecoms and cloud services is fragmented in ways that create compounding risk when a single agent manages a multinational customer portfolio. A disclosure that satisfies the operator's home-jurisdiction rules may simultaneously violate the customer's host-jurisdiction rules. The requirement in §4.9.3 to satisfy the most stringent timeline across all affected jurisdictions is the only operationally safe default, because the consequence of missing the most stringent obligation is regulatory action, whereas the consequence of exceeding the least stringent obligation is zero.
The audit-trail requirements in §4.6 are specified as independent controls rather than as incidental outputs of the credit and disclosure workflows because post-incident reconstruction is frequently required by regulators, courts, and internal governance functions. An audit log that is co-located with the operational state of an agent running under incident-response load is not a reliable record; it must be segregated, append-only, and cryptographically verifiable to serve its governance function.
Rule-Engine Separation: Credit computation and disclosure-obligation evaluation SHOULD be implemented in a deterministic, versioned rule engine that is architecturally separate from the agent's general-purpose reasoning component. The rule engine should ingest SLA and regulatory-rule artefacts as versioned configuration objects with explicit hash verification on load. The agent's reasoning component should call the rule engine via a defined interface and treat its outputs as authoritative, not as inputs to further inference.
Event-Sourced Audit Architecture: All outage-classification, credit-computation, and notification events SHOULD be written to an event-sourced log store in which events are immutable once written. The log store should support cryptographic hash-chaining (e.g., each record includes a hash of the previous record) to enable tamper detection. Separate consumer processes should read from this log to produce customer-facing artefacts and regulatory reports, ensuring the source of truth for all external outputs is the audit log rather than the agent's runtime state.
Jurisdiction-Keyed Rule Table with Change-Management Integration: Regulatory rule tables SHOULD be managed through a change-management pipeline that is monitored by a legal or compliance function. When a regulatory change is published, the pipeline should generate a candidate rule-table update, route it for legal validation, apply it to the production rule engine upon approval, and record the approval chain. The agent should never be the first or sole consumer of regulatory-change information; it should only apply rules that have been validated upstream.
Dual-Path Notification with Delivery Verification: Outage notifications SHOULD be transmitted over at minimum two independent delivery channels (e.g., API push and email, or status-page update and direct message), with delivery confirmation collected independently on each channel. Where delivery on the primary channel fails, the secondary channel MUST be used without delay. Delivery-confirmation records should be written to the audit log automatically.
Proactive Credit Issuance as Default: Where the governing SLA permits, agents SHOULD be configured to issue credits proactively (without requiring a customer claim) rather than on a claim-triggered basis. Proactive issuance reduces dispute volume, reduces the risk of customers failing to claim credits they are owed, and demonstrates good faith to regulators. The proactive issuance workflow should include a pre-issuance review step for credits above a configurable monetary threshold.
Maturity Model:
Anti-Pattern: Using LLM Inference for Credit Calculation. Allowing a large language model component of an agent to compute credit amounts by reasoning over natural-language SLA text is a critical anti-pattern. LLM inference is non-deterministic, does not preserve version history, does not produce auditable computation trails, and is susceptible to input-framing effects that can produce systematically biased outputs. Credit computation MUST be performed by a deterministic rule engine.
Anti-Pattern: Bundling Disclosure with Credit Computation. Conditioning the timing of customer disclosure notifications on the completion of credit computation is an anti-pattern that consistently causes disclosure-timeline violations. Disclosure of the outage event is a separate obligation from the provision of credit information, and the most stringent regulatory timelines (15 minutes to 1 hour) cannot accommodate credit-computation workflows. Disclosure and credit pipelines MUST be decoupled.
Anti-Pattern: Single-Jurisdiction Rule Application. Applying the operator's home-jurisdiction SLA and regulatory rules uniformly across a multinational customer base is an anti-pattern that is a near-certain route to regulatory non-compliance in customer host jurisdictions. Operators frequently adopt this pattern for operational simplicity; its cost is regulatory exposure in every non-home jurisdiction.
Anti-Pattern: Severity Downgrade Under Operational Pressure. During large-scale outage events, operational pressure to reduce the apparent scope of an incident in order to limit credit liability creates incentives to reclassify events at lower severity tiers. Any agent capability that allows severity reclassification without a full audit trail and human authorisation is an anti-pattern that regulators specifically investigate.
Anti-Pattern: Mutable Audit Logs. Storing audit records in the same operational database as the agent's working state, or using a logging architecture that permits record deletion or modification, creates both a compliance risk and a legal risk. In dispute and regulatory-inquiry contexts, a mutable log provides no evidentiary value and may itself constitute a compliance violation.
Anti-Pattern: Staleness Tolerance Creep. Setting the rule-refresh cadence to 90 days or longer "for stability" — as in Example 3.1 — is an anti-pattern driven by operational convenience that systematically exposes the operator to under-crediting risk when regulatory or contractual rules change. The maximum refresh cadence specified in §4.2.1 (30 days) is the outer bound; quarterly or annual refresh cycles are not compliant with this dimension.
In carrier environments, outage-disclosure obligations are frequently dual-track: obligations run both to enterprise customers under SLA terms and to the national telecommunications authority under regulatory-reporting rules. Agents must be designed to service both tracks simultaneously, and the two tracks may have different required formats, different content requirements, and different timelines. The regulatory track should never be subordinated to the customer track.
In data-centre and co-location contexts, physical-infrastructure events (power, cooling, physical security) may trigger service credits even where the customer's own equipment continues to operate on generator power. The definition of "outage" in these contracts frequently differs from the network-layer definition used in carrier contexts, and agents must apply the correct definition for the applicable contract type.
In content-delivery and edge-network environments, the geographic granularity of outage reporting is often a point of customer dispute. Agents should be designed to report outage scope at the granularity specified in the applicable SLA, rather than at the coarser granularity that may be operationally convenient.
| Artefact | Description | Retention Period |
|---|---|---|
| Outage Classification Record | Tamper-evident log entry for each outage event, including timestamp, signal source, anomaly characteristics, classification outcome, confidence score, and agent identifier | 7 years |
| SLA and Regulatory Rule Version Register | Record of all SLA and regulatory-rule artefacts loaded by the agent, including version identifier, source hash, load timestamp, and expiry timestamp | 7 years |
| Credit Computation Artefact | Machine-readable record as specified in §4.3.3 for each qualifying outage | 7 years |
| Notification Transmission Record | Record of each outage notification transmitted, including recipient, channel, transmission timestamp, content hash, and delivery confirmation or failure status | 7 years |
| Regulatory Report Draft and Submission Record | Draft regulatory reports, human-review records, submission confirmations, and outcomes | 10 years |
| Audit Log Integrity Verification Record | Results of each 24-hour cryptographic consistency check on the audit log | 3 years |
| Dispute Record | All customer dispute filings, associated credit-computation artefacts, human authorisations, resolution decisions, and adjusted credit issuance records | 7 years from dispute resolution |
| Rule Refresh Confirmation Record | Log entries confirming each rule-table refresh, including source, hash, and timestamp | 3 years |
| Severity Reclassification Authorisation Record | Human authorisation records for all downward severity reclassifications | 7 years |
| Edge Agent Reconnection Transmission Record | Records of cached outage data transmitted by edge agents upon reconnection, with original event timestamps preserved | 7 years |
All artefacts listed in §7.1 MUST be stored in a system that supports immutable record retention, role-based access control, and export in a machine-readable, regulator-accessible format. Access to artefacts that contain customer-identifying information must comply with all applicable data-protection regulations. Artefacts subject to an active regulatory inquiry or litigation hold must be retained beyond the standard period until the matter is resolved and a formal release from hold is documented.
Objective: Verify that the agent applies a current, contract-matched severity taxonomy to outage classification and does not use stale or mismatched rule artefacts.
Method: Inject a simulated service-anomaly event into the agent's monitoring input stream. Query the agent's rule engine for the SLA artefact version and source hash it is using for the affected customer. Compare the artefact version and hash against the authoritative SLA repository. Introduce a controlled SLA amendment to the authoritative repository and verify that the agent detects and loads the amendment within the rule-refresh window defined in §4.2.1. Then introduce a second simulated anomaly and verify that the classification reflects the amended SLA.
Pass Criteria:
Objective: Verify that the agent computes service credits correctly, applies jurisdiction-specific minimum rates where applicable, and produces a complete machine-readable computation artefact.
Method: Configure three test customer profiles with different SLA terms and different applicable jurisdictions: (a) a standard-SLA customer with no jurisdiction-specific override; (b) a customer in a jurisdiction whose regulatory minimum credit rate exceeds the SLA rate; (c) a customer whose SLA contains an ambiguous clause regarding credit cap calculation. Inject a qualifying outage event of known duration and scope. Collect the credit-computation artefacts produced for all three customers. Verify credit amounts against manual calculation. Verify that the jurisdiction-specific minimum is applied for customer (b) even though it exceeds the SLA rate. Verify that customer (c)'s computation is flagged for human review.
Pass Criteria:
Objective: Verify that the agent transmits initial outage notifications within the most stringent applicable regulatory or SLA timeline, and that notification is not deferred pending credit computation.
Method: Configure a test customer whose applicable obligations include a 60-minute SLA notification requirement and a 30-minute regulatory notification requirement from a simulated host jurisdiction. Inject a qualifying outage event. Measure the elapsed time from the classification decision to the transmission of the initial notification. Separately verify that the notification is transmitted before the credit-computation artefact is completed. Repeat the test with a safety-critical customer profile and verify compliance with the 10-minute initiation window specified in §4.4.2.
Pass Criteria:
| Regulation | Provision | Relationship Type |
|---|---|---|
| EU AI Act | Article 9 (Risk Management System) | 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 |
| NIS2 Directive | Article 21 (Cybersecurity Risk Management Measures) | 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. Service Credit and Outage Disclosure 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-556 supports the Article 9 obligation by providing structural governance controls rather than relying solely on the agent's own reasoning or behavioural compliance.
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-556 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. Service Credit and Outage Disclosure 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 service credit and outage disclosure 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-556, 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.