title: “Risk Schema” description: “Machine-readable representation of AI-related risks within the AIGO Framework.”
Risk Schema
The Risk Schema defines the machine-readable representation of AI-related risks within the AIGO Framework. It provides a structured way to record, relate, assess, treat, monitor, and review risks associated with governed AI systems. The schema should be used together with the AIGO risk-management model, risk-assessment procedure, control framework, evidence model, and related governance schemas.Purpose
The Risk Schema supports consistent representation of risk information throughout the AI governance lifecycle. A risk record can provide the structured basis for: * risk identification * risk analysis * risk evaluation * risk treatment * control selection * residual-risk assessment * risk acceptance * monitoring * reassessment * assurance * governance reporting * continuous improvement The schema provides the structure for the record. It does not itself determine whether a risk has been adequately assessed or treated.Risk within the AIGO governance model
Risk management connects the characteristics and context of an AI system to governance decisions. A simplified relationship is: AI System → Risk → Treatment → Control → Evidence → Assessment → Decision The relationship may contain multiple risks and multiple controls. For example:What a risk record represents
A risk record represents a defined risk associated with an AI system, activity, use case, process, or governance context. Depending on the canonical schema and implementation, risk information may include concepts such as: * risk identity * description * source * cause * event or condition * potential impact * affected stakeholders * likelihood * severity or consequence * inherent risk * existing controls * treatment * residual risk * risk owner * status * review information * acceptance information * related evidence The canonical JSON Schema is the authoritative source for the actual fields, types, required properties, and constraints.Risk identification
Risk identification establishes what could produce an undesirable governance, operational, technical, legal, safety, security, or other relevant outcome. AI-related risks can arise from factors such as: * system behavior * data * intended use * deployment context * human interaction * model limitations * security threats * privacy concerns * discrimination or unfair outcomes * reliability * transparency * accountability * operational dependencies * changes in the system or environment The organization should determine the relevant risk categories according to its governance model and applicable requirements.Risk analysis
Risk analysis considers the characteristics and potential significance of an identified risk. Depending on the organization’s methodology, this may consider: * likelihood * impact * severity * exposure * affected stakeholders * duration * detectability * existing safeguards * uncertainty AIGO does not require every organization to use an identical risk-scoring methodology unless a specific AIGO requirement defines one. The organization’s approved risk methodology should be applied consistently.Inherent and residual risk
A risk-management implementation may distinguish between risk before and after treatment. Conceptually: Inherent Risk → Risk Treatment → Residual Risk Inherent risk represents the assessed risk before considering the effect of relevant controls or treatments. Residual risk represents the remaining risk after applicable treatment and controls have been considered. The distinction helps governance decision-makers determine whether additional treatment or formal risk acceptance is required.Risk treatment
Risk treatment determines what should be done about an identified risk. Possible treatment approaches can include: * reducing the risk * avoiding the relevant activity * modifying the system or intended use * implementing additional controls * transferring or sharing aspects of the risk where appropriate * accepting residual risk where authorized The selected treatment should be recorded and traceable to the relevant risk.Relationship to controls
Controls are a primary mechanism for treating AI-related risks. A typical relationship is: Risk → Control → Evidence → Assessment A risk record can therefore be related to one or more controls. This relationship enables an organization to determine: * which controls address a risk * whether those controls have been implemented * whether evidence supports their operation * whether the controls are effective * whether residual risk remains acceptable See Control Schema.Relationship to evidence
Risk decisions should be supported by appropriate evidence where required. Evidence may include: * risk assessments * test results * monitoring results * incident records * technical documentation * control assessments * assurance findings * stakeholder analysis * approvals * external requirements Evidence provides traceability for the conclusions recorded in the risk record. See Evidence Schema.Relationship to assessment
Risk information may be evaluated through formal assessment activities. A simplified relationship is: Risk → Assessment → Finding / Decision Assessments can determine whether: * the risk has been sufficiently analyzed * treatment is appropriate * controls are adequate * residual risk has been correctly determined * additional action is required See Assessment Schema.Relationship to approval
Some risk decisions require formal governance approval. Examples may include: * approval of a high-significance risk treatment * acceptance of residual risk * approval of operation subject to risk conditions * approval following a material change * approval of an exception A simplified relationship is: Risk → Assessment → Decision → Approval The appropriate decision authority depends on the organization’s governance model and applicable requirements. See AI Governance Approval.Risk acceptance
Residual risk that remains after treatment may require formal acceptance. Risk acceptance should identify: * the residual risk * the basis for acceptance * the authorized decision-maker * conditions or limitations * review period * supporting evidence * circumstances that require reassessment Risk acceptance should not be treated as a mechanism for bypassing mandatory legal, regulatory, safety, security, or organizational requirements. See Risk Acceptance.Risk monitoring
Risk information should remain current throughout the AI system lifecycle. Monitoring may identify: * increasing risk exposure * new risk sources * changes in likelihood * changes in impact * control weaknesses * incidents * emerging threats * changes in stakeholders * changes in applicable requirements Monitoring results can trigger risk reassessment. See AI Monitoring.Risk reassessment
Risk should be reassessed when relevant conditions change. Potential triggers include: * changes to the AI system * changes to intended use * changes to deployment context * changes to data * changes to stakeholders * changes to controls * significant incidents * changes in applicable requirements * emerging risks * monitoring findings * assurance findings A reassessment should preserve traceability to the reason for the reassessment and the resulting governance decision.Risk and change management
A material change to an AI system may alter its risk profile. A simplified relationship is: Change → Impact Assessment → Risk Reassessment → Control Review → Approval For example, a significant change in intended use may create new risks or change the significance of existing risks. See AI Change Management.Risk and incident management
Incidents can reveal previously unidentified risks or demonstrate that existing risk assumptions are no longer valid. A significant incident may therefore trigger: * risk reassessment * control reassessment * classification review * monitoring changes * approval review * assurance * improvement A simplified relationship is: Incident → Investigation → Risk Reassessment → Corrective Action See AI Incident Management.Risk and assurance
Assurance can evaluate whether risk-management activities are appropriate and operating as intended. Assurance may examine: * risk identification * risk assessment * risk treatment * control effectiveness * residual-risk decisions * evidence * approvals * monitoring * reassessment Assurance findings can become inputs to corrective action and continuous improvement. See AI Governance Assurance.Risk lifecycle
A practical risk lifecycle can be represented as:Machine-readable evaluation
Risk records can provide structured inputs to the AIGO evaluation layer. The evaluation architecture separates governance data from evaluation rules: Governance Records → Rules → Evaluation → Results For example:Example risk record
An implementation may represent a risk conceptually as:Implementation sequence
A practical implementation can connect the risk schema to the governance workflow:Validation
Risk records can be validated against the canonical JSON Schema. Validation can identify structural problems such as: * missing required properties * invalid data types * invalid values * malformed objects * invalid arrays * schema violations The repository’s broader validation layer may also evaluate relationships and other implementation artifacts. A successful validation result provides evidence that the tested artifact satisfies the implemented validation checks. It does not establish that the risk assessment itself is substantively correct, complete, legally sufficient, or acceptable to an authorized decision-maker.Canonical source
Machine-readable schema:schemas/02-risk/02-AIGO-Risk-Schema-v0.1.json
Schema documentation:
schemas/02-risk/02-AIGO-Risk-Schema-Documentation-v0.1.md
Operational risk assessment guidance:
docs/risk-assessment.mdx
Canonical risk assessment procedure:
guidance/02-procedures/03-AIGO-AI-Risk-Assessment-Procedure-v0.1.md