title: “AI Incident Management” description: “Identify, assess, respond to, investigate, and learn from AI-related incidents within the AIGO governance lifecycle.”
AI Incident Management
Incident management provides a structured process for identifying, assessing, responding to, documenting, investigating, and learning from AI-related incidents. Within AIGO, an incident is not only an operational event. A significant incident can provide evidence that an AI system’s risks, controls, governance decisions, or operating conditions have changed. Incident management therefore connects operational response with: * risk management * control management * change management * approval * monitoring * assurance * evidence * continual improvement The objective is to ensure that incidents are handled consistently and that their governance consequences are addressed.Purpose
AI incidents can reveal: * previously unknown risks * control weaknesses * ineffective controls * incorrect assumptions * governance failures * unexpected system behavior * changes in the operating environment * failures in human oversight * data problems * security or privacy issues * changes in stakeholder impact Incident management provides a controlled mechanism for responding to the immediate event while determining whether broader governance action is required.What is an AI incident?
An AI incident is an event or condition involving an AI system that may require investigation, response, remediation, escalation, or governance action. Organizations should define their own incident criteria according to their governance scope and risk environment. Potential examples include: * harmful or unexpected AI system behavior * significant model failure * incorrect or materially misleading outputs * unauthorized use * privacy-related events * security events affecting an AI system * significant data quality problems * failures of required human oversight * control failures * violation of approved system use * material deviation from intended behavior * significant stakeholder harm * failure to satisfy an approval condition * regulatory or policy-related events * repeated monitoring failures Not every operational anomaly necessarily constitutes a formal incident. The organization should establish criteria for determining when an event enters the formal incident-management process.Incident lifecycle
A practical AIGO incident-management lifecycle is: 1. Detect and report 2. Record the incident 3. Perform initial assessment 4. Classify and prioritize 5. Escalate where required 6. Contain and respond 7. Preserve evidence 8. Investigate 9. Assess governance impact 10. Implement corrective actions 11. Verify remediation 12. Close the incident 13. Feed lessons into improvement The exact workflow may vary according to organizational policy, incident severity, and applicable requirements.1. Detect and report
Incidents may be identified through: * users * system operators * monitoring * automated alerts * testing * assurance activities * internal audits * external reports * affected stakeholders * suppliers * security processes * privacy processes * governance reviews Organizations should provide an appropriate mechanism for reporting suspected incidents. Incident reporting should capture sufficient initial information to support triage.2. Record the incident
Each formal incident should have a controlled record. The incident record should identify, where applicable: * incident identifier * affected AI system * date and time * detection source * reporting party * incident description * affected environment * initial severity * affected stakeholders * immediate actions * assigned owner * current status The incident identifier should remain stable throughout the incident lifecycle.3. Perform initial assessment
The initial assessment determines the immediate significance of the incident. Assessment may consider: * actual impact * potential impact * affected stakeholders * system criticality * system classification * duration * scope * likelihood of recurrence * security implications * privacy implications * safety implications * legal or regulatory implications * governance implications The initial assessment should support appropriate prioritization and escalation.4. Classify and prioritize
Organizations should define an incident classification and prioritization approach. Factors may include: * severity * scope * urgency * affected population * potential harm * operational disruption * security significance * privacy significance * regulatory significance * likelihood of recurrence Higher-significance incidents may require additional governance involvement and more extensive evidence and assurance.5. Escalate where required
Incidents should be escalated according to predefined criteria. Escalation may involve: * system owners * risk owners * governance functions * security functions * privacy functions * legal or compliance functions * executive management * assurance functions * external stakeholders where required Escalation requirements should be established before an incident occurs.6. Contain and respond
The immediate response should seek to reduce ongoing or potential harm. Depending on the incident, response may include: * restricting system access * suspending functionality * disabling a model or feature * increasing human oversight * reverting to an earlier version * isolating affected components * correcting data * notifying relevant stakeholders * implementing temporary controls * initiating emergency change procedures Emergency actions should still be documented. Where an emergency change is required, the organization should apply its change-management process retrospectively or concurrently as appropriate. See AI Change Management.7. Preserve evidence
Relevant evidence should be preserved according to the organization’s evidence and retention requirements. Potential evidence includes: * system logs * model outputs * input records where appropriate * monitoring results * alerts * configuration information * version information * deployment records * access records * communications * screenshots * investigation notes * approval records * relevant governance records Evidence should be handled in accordance with applicable privacy, security, confidentiality, and retention requirements.8. Investigate
The investigation should establish what happened and why. Depending on the incident, investigation may examine: * system behavior * model behavior * data * infrastructure * configuration * human actions * operating procedures * controls * monitoring * governance decisions * third-party dependencies The investigation should distinguish between: * observed facts * assumptions * hypotheses * confirmed causes * contributing factorsRoot-cause analysis
Where appropriate, organizations should perform root-cause analysis. Potential causes may include: * technical failure * data problem * inadequate testing * inadequate monitoring * ineffective control * human error * process failure * governance failure * supplier failure * environmental change * inappropriate system use The purpose of root-cause analysis is not merely to explain the incident. It should help determine what must change to reduce recurrence.9. Assess governance impact
A significant incident should trigger an assessment of whether existing governance decisions remain valid. Potential reassessment areas include: * AI system classification * risk assessment * risk treatment * controls * control effectiveness * approval status * approval conditions * monitoring * assurance * intended use * deployment context * stakeholder impacts * applicable requirements A representative relationship is: incident → investigation → governance impact assessment → risk/control/change action Not every incident requires every downstream governance activity. The required response should be proportionate to the incident and its governance significance.10. Reassess risk
Incidents may reveal that existing risk assessments are incomplete or no longer accurate. Risk reassessment may result in: * existing risks being updated * new risks being recorded * likelihood or impact being changed * new treatment actions * additional controls * changes to residual risk * risk acceptance being reconsidered See Risk Assessment.11. Review controls
Where an incident involves a control failure, the organization should determine whether the control: * was absent * was incorrectly designed * was not implemented * was not operating effectively * was bypassed * was insufficient for the changed environment Control remediation should be recorded and tracked. Where appropriate, control effectiveness should be reassessed after remediation. See Control Assessment.12. Determine whether change management is required
An incident may require changes to the AI system or its operating environment. Examples include: * model changes * configuration changes * data changes * deployment changes * additional safeguards * changes to human oversight * changes to intended use * changes to monitoring * changes to controls Where a material change is required, the organization should use its change-management process. See AI Change Management.13. Review approval status
A significant incident may affect the validity of an existing governance approval. The organization should determine whether: * approval remains valid * approval conditions must change * additional approval is required * deployment must be restricted * the system must be suspended * the system must undergo reassessment before continued operation Any resulting governance decision should be recorded. See AI Governance Approval.14. Corrective action
Corrective actions should address the causes and governance consequences identified during the investigation. Actions may include: * technical remediation * control changes * policy changes * procedure changes * additional testing * additional monitoring * training * role changes * supplier actions * governance reassessment * system changes * retirement of affected functionality Each significant action should have an owner and appropriate completion criteria.15. Verify remediation
Incident closure should not depend solely on completing an action. Where appropriate, remediation should be verified. Verification may include: * testing * control assessment * monitoring * assurance * evidence review * stakeholder confirmation * governance approval The verification should establish whether the corrective action actually addressed the identified problem.16. Close the incident
An incident should be closed when the organization’s closure criteria have been satisfied. The closure record should establish: * what happened * impact * root cause or contributing factors * response actions * corrective actions * evidence * governance consequences * residual issues * responsible owners * verification results * final disposition Outstanding actions should remain traceable even after the incident itself is closed.Incident traceability
Significant incidents should be traceable to the affected AI system and related governance records. A representative governance chain is: AI system → incident → evidence → investigation → risk → control → change → approval → monitoring → assurance → improvement This allows an organization to reconstruct the governance history associated with an incident.Machine-readable representation
AIGO provides a machine-readable Incident Schema for representing governed incident records. The incident record can be related to: * AI systems * risks * controls * assessments * changes * approvals * monitoring * assurance * evidence * improvementsCanonical schema
schemas/07-incident/07-AIGO-Incident-Schema-v0.1.json
Schema documentation
schemas/07-incident/07-AIGO-Incident-Schema-Documentation-v0.1.md
Machine-readable incident records can support:
* incident registries
* workflow systems
* governance platforms
* evidence management
* traceability
* automated evaluation
* monitoring integrations
* assurance processes
Relationship to monitoring
Monitoring is one of the primary mechanisms through which incidents may be detected. A representative relationship is: monitoring → signal → incident → investigation → corrective action Not every monitoring signal becomes an incident. The organization should establish thresholds and criteria for determining when a signal requires formal incident management. See AI Monitoring.Relationship to assurance
Assurance activities may identify incidents or weaknesses that require formal incident treatment. Similarly, incident records can become evidence for subsequent assurance activities. This creates a two-way governance relationship: assurance → finding → incident or corrective action and: incident → evidence → assurance See AI Assurance.Relationship to continual improvement
Incident management should contribute to continual improvement. Incident analysis can identify opportunities to improve: * controls * procedures * governance criteria * monitoring * assurance * training * system design * risk assessment * change management The resulting improvements should be recorded and tracked through the organization’s improvement process. See Continuous Improvement.Incident artifacts
A practical implementation may produce: 1. incident report 2. initial assessment 3. classification and priority decision 4. response record 5. evidence record 6. investigation record 7. root-cause analysis 8. governance impact assessment 9. risk reassessment 10. control remediation 11. change record where required 12. approval decision where required 13. monitoring updates 14. assurance follow-up 15. corrective action record 16. closure decision Organizations may combine records where appropriate, provided required traceability is preserved.Implementation resources
The canonical procedure is:guidance/02-procedures/08-AIGO-AI-Incident-Management-Procedure-v0.1.md
The corresponding implementation template is:
guidance/03-templates/10-AIGO-AI-Incident-Template-v0.1.md
The machine-readable structure is:
schemas/07-incident/07-AIGO-Incident-Schema-v0.1.json