{ "schema_version": "1.0.0", "generator": "build-proofmap.mjs", "description": "Per-obligation evidence proof chains for each framework with a published coverage manifest. Composes coverage/*.json with the domain control matrices: obligation -> addressing controls -> each control's validation_objective + evidence_required + blocking_effect + mapping fit/basis -> verdict + gap. Deterministic; regenerated by npm run rehash. Verdicts derive from the human-curated coverage manifests; per-control evidence and fit are read live from the matrices.", "meta": { "frameworks": 5, "obligations": 243, "note": "Verdict at the obligation level is authoritative (from the coverage manifest). 'supported' means Apeiris controls directly address the obligation; 'partial' means partial coverage with a stated gap; 'unsupported'/'out-of-scope' carry the manifest's reasoning. This maps to public controls only \u2014 not a compliance determination." }, "frameworks": [ { "framework": "eu_ai_act", "label": "EU AI Act", "source_id": "eu_ai_act", "anchored": true, "currency": { "version": "2024/1689", "published_on": "2024-08-01", "status": "current", "retrieved_on": null }, "total_requirements": 65, "summary": { "supported": 51, "partial": 14, "unsupported": 0, "out-of-scope": 0, "controls_involved": 122, "evidence_artifacts": 551, "automatable_evidence": 138 }, "obligations": [ { "requirement_id": "EU-AIA-ART05-01a", "section": "Art. 5(1)(a)", "title": "Prohibited AI \u2014 subliminal manipulation", "text": "AI systems that deploy subliminal techniques beyond a person's consciousness or purposefully manipulative or deceptive techniques with the objective to materially distort the behaviour of a person or a group of persons are prohibited.", "verdict": "supported", "coverage": "direct", "notes": "EF-05 (EU AI Act Prohibited Practices Governance) directly operationalizes Art. 5 \u2014 it requires a prohibited-practice register, design-time review gate, and documented evidence that no deployed system falls within any Art. 5(1) category. HI-02 (Human Dignity and Autonomy Preservation) requires positive design controls against techniques that bypass rational agency. HI-06 (Consent and Agency Preservation) enforces that AI interactions maintain informed user consent at every point. GV-07 (Protect humans from being deceived by an agent) closes the agentic enforcement gap, requiring output review for deceptive framing or hidden influence channels.", "control_count": 4, "proof_chain": [ { "control": "apeiris://ethics/controls/EF-05", "id": "EF-05", "domain": "ethics", "name": "EU AI Act Prohibited Practices Governance (Art. 5)", "validation_objective": "Every AI system developed, deployed, or procured by the organization must have an Art. 5 screening record confirming evaluation against the current Prohibited Practices Register before intake resources were allocated. Any system that triggers a potential-match flag must have a formal Art. 5 Clearance determination with written legal opinion and ethics officer countersignature completed within 10 business days of the flag before any further development, deployment, or procurement proceeds.", "blocking_effect": "blocks-deployment", "evidence_required": [ "prohibited_practices_register document version-controlled with last_updated_date within 30 days of any EAIA or national supervisory authority Art. 5 guidance publication, mapping each Art. 5(1) prohibition to its definitional elements and organizational legal interpretation", "art_5_screening_record for each AI system in the intake registry, including screening_date, register_version_used, screener_identity, and screening_outcome (clear / potential-match / deferred)", "art_5_clearance_determination document for flagged systems including written_legal_opinion, ethics_officer_countersignature, determination_date within 10 business days of flag_date, and determination outcome (cleared / rejected)", "vendor_contract_art_5_compliance_provisions confirming Art. 5 compliance representations and audit rights in contracts for all AI system vendors", "annual_portfolio_audit_record showing Art. 5 re-screening completion date for all production systems against the current register version" ], "evidence": [ { "id": "EF-05-E1", "description": "prohibited_practices_register document version-controlled with last_updated_date within 30 days of any EAIA or national supervisory authority Art. 5 guidance publication, mapping each Art. 5(1) prohibition to its definitional elements and organizational legal interpretation", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-05-E2", "description": "art_5_screening_record for each AI system in the intake registry, including screening_date, register_version_used, screener_identity, and screening_outcome (clear / potential-match / deferred)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-05-E3", "description": "art_5_clearance_determination document for flagged systems including written_legal_opinion, ethics_officer_countersignature, determination_date within 10 business days of flag_date, and determination outcome (cleared / rejected)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-05-E4", "description": "vendor_contract_art_5_compliance_provisions confirming Art. 5 compliance representations and audit rights in contracts for all AI system vendors", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-05-E5", "description": "annual_portfolio_audit_record showing Art. 5 re-screening completion date for all production systems against the current register version", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "This control is specifically designed to operationalize EU AI Act Art. 5 prohibited practices compliance. Every element of the Prohibited Practices Register, screening process, and clearance determination is structured to demonstrate that the organization has implemented systematic controls to prevent deployment of Art. 5 prohibited systems." }, { "control": "apeiris://ethics/controls/HI-02", "id": "HI-02", "domain": "ethics", "name": "Human Dignity and Autonomy Preservation", "validation_objective": "No AI system may be deployed or continue operating if a red-team evaluation has identified unresolved high-severity dignity violations or autonomy-undermining patterns within the control's defined remediation SLA. All production AI systems must have a current red-team evaluation on record (within the prior 90 days), and production user research must show autonomy-pressure indicators below the 5% threshold.", "blocking_effect": "blocks-deployment", "evidence_required": [ "red_team_evaluation_report per AI system, conducted within the prior 90 days, scored against the dignity and autonomy rubric with all findings categorized by severity and tracked to remediation status", "prohibited_patterns_registry document listing current prohibited patterns with definitions, illustrative examples, and most recent review date confirming currency within 18 months", "optimization_objective_audit_record demonstrating that model training objectives were reviewed for engagement or dependency metrics that could proxy for manipulation or autonomy-undermining behavior", "user_research_results showing autonomy-preservation indicators including percentage of users reporting pressure, rate of AI suggestions accepted without modification, measurement methodology, and sample demographics", "remediation_tracker showing all open red-team findings with severity classification, assigned owner, SLA due date, and current resolution status" ], "evidence": [ { "id": "HI-02-E1", "description": "red_team_evaluation_report per AI system, conducted within the prior 90 days, scored against the dignity and autonomy rubric with all findings categorized by severity and tracked to remediation status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-02-E2", "description": "prohibited_patterns_registry document listing current prohibited patterns with definitions, illustrative examples, and most recent review date confirming currency within 18 months", "evidence_type": "human-review-record", "verification": "human" }, { "id": "HI-02-E3", "description": "optimization_objective_audit_record demonstrating that model training objectives were reviewed for engagement or dependency metrics that could proxy for manipulation or autonomy-undermining behavior", "evidence_type": "human-review-record", "verification": "human" }, { "id": "HI-02-E4", "description": "user_research_results showing autonomy-preservation indicators including percentage of users reporting pressure, rate of AI suggestions accepted without modification, measurement methodology, and sample demographics", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-02-E5", "description": "remediation_tracker showing all open red-team findings with severity classification, assigned owner, SLA due date, and current resolution status", "evidence_type": "red-team-report", "verification": "third-party" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 5(1)(b) prohibits AI systems that exploit vulnerabilities or use subliminal techniques to materially distort behavior in ways that harm users \u2014 a direct prohibition on autonomy-undermining manipulation. This control's prohibited patterns registry implements the Article 5 prohibition operationally." }, { "control": "apeiris://ethics/controls/HI-06", "id": "HI-06", "domain": "ethics", "name": "Consent and Agency Preservation for AI Interactions", "validation_objective": "All AI-mediated interactions must be preceded by plain-language disclosure of the AI's nature, capability category, data use, and consequential outputs; consent records must be version-tagged to the capability state at the time of consent; and users must be able to exit or modify AI interactions without experiencing service penalties. A passing state requires 100% of active user consent records carrying a capability_version_tag and 100% of material capability changes having a documented consent refresh assessment.", "blocking_effect": "requires-review", "evidence_required": [ "consent_record_export with fields for user_id, consent_timestamp, capability_version_tag, consent_granularity_tier, and revocation_status for every consented user, with no records lacking a version tag", "disclosure_readability_assessment_report showing Flesch-Kincaid reading ease score at or above 60 for all pre-interaction disclosure content, assessed after each material capability update", "capability_change_governance_log listing each AI capability release, its materiality determination (material or non-material), the assessment rationale, and the consent refresh decision and notification record where triggered", "agency_preservation_test_report documenting opt-out flow testing with screen-recorded evidence that users can exit AI-mediated interactions without friction, penalty prompts, or service degradation" ], "evidence": [ { "id": "HI-06-E1", "description": "consent_record_export with fields for user_id, consent_timestamp, capability_version_tag, consent_granularity_tier, and revocation_status for every consented user, with no records lacking a version tag", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-06-E2", "description": "disclosure_readability_assessment_report showing Flesch-Kincaid reading ease score at or above 60 for all pre-interaction disclosure content, assessed after each material capability update", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-06-E3", "description": "capability_change_governance_log listing each AI capability release, its materiality determination (material or non-material), the assessment rationale, and the consent refresh decision and notification record where triggered", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-06-E4", "description": "agency_preservation_test_report documenting opt-out flow testing with screen-recorded evidence that users can exit AI-mediated interactions without friction, penalty prompts, or service degradation", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 50 mandates that AI systems interacting with humans disclose their AI nature and provides transparency obligations for certain AI-generated content. This control implements the disclosure and consent infrastructure required to meet these obligations." }, { "control": "apeiris://security/controls/GV-07", "id": "GV-07", "domain": "security", "name": "Protect humans from being deceived by an agent", "validation_objective": "All agent-generated content shown to human approvers or end users is clearly labeled as AI-generated and includes independent, system-sourced facts about the action being approved; the approval channel cryptographically prevents agent impersonation of named individuals; and no agent can manufacture an on-behalf-of claim without an out-of-band verification step.", "blocking_effect": "requires-review", "evidence_required": [ "approval_ui_design_artifact showing the agent-output label and an independent fact panel (resource identifiers, current auth scope, prior action history) displayed alongside any agent-provided summary", "impersonation_block_log recording instances where an agent attempted to assert a named human identity or forge an on-behalf-of header, and the system's rejection response", "channel_integrity_configuration showing the approval workflow is delivered over a path the agent cannot write to, inject into, or intercept", "user_disclosure_audit confirming AI-disclosure notices are rendered at every interaction surface where an end user may encounter agent-generated content", "red_team_exercise_report testing social-engineering and impersonation paths through the agent, with findings and remediation status" ], "evidence": [ { "id": "GV-07-E1", "description": "approval_ui_design_artifact showing the agent-output label and an independent fact panel (resource identifiers, current auth scope, prior action history) displayed alongside any agent-provided summary", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-07-E2", "description": "impersonation_block_log recording instances where an agent attempted to assert a named human identity or forge an on-behalf-of header, and the system's rejection response", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "GV-07-E3", "description": "channel_integrity_configuration showing the approval workflow is delivered over a path the agent cannot write to, inject into, or intercept", "evidence_type": "human-review-record", "verification": "human" }, { "id": "GV-07-E4", "description": "user_disclosure_audit confirming AI-disclosure notices are rendered at every interaction surface where an end user may encounter agent-generated content", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-07-E5", "description": "red_team_exercise_report testing social-engineering and impersonation paths through the agent, with findings and remediation status", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "EU-AIA-ART05-01b", "section": "Art. 5(1)(b)", "title": "Prohibited AI \u2014 exploitation of vulnerabilities", "text": "AI systems that exploit any of the vulnerabilities of a natural person or a specific group of persons due to their age, disability or a specific social or economic situation are prohibited.", "verdict": "supported", "coverage": "direct", "notes": "EF-05 covers the legal prohibition governance gate. HI-03 (Vulnerable Population Protection) requires explicit identification of vulnerable groups in the AI system's intended population, risk controls, and documented evidence that the system cannot be directed toward exploitation. HI-07 (Child and Minors Safety Controls) extends this specifically to minors, with age-gating and interaction controls. FA-07 (Bias Remediation Governance) ensures that bias toward vulnerable groups discovered in evaluation triggers a mandatory remediation track before deployment approval.", "control_count": 4, "proof_chain": [ { "control": "apeiris://ethics/controls/EF-05", "id": "EF-05", "domain": "ethics", "name": "EU AI Act Prohibited Practices Governance (Art. 5)", "validation_objective": "Every AI system developed, deployed, or procured by the organization must have an Art. 5 screening record confirming evaluation against the current Prohibited Practices Register before intake resources were allocated. Any system that triggers a potential-match flag must have a formal Art. 5 Clearance determination with written legal opinion and ethics officer countersignature completed within 10 business days of the flag before any further development, deployment, or procurement proceeds.", "blocking_effect": "blocks-deployment", "evidence_required": [ "prohibited_practices_register document version-controlled with last_updated_date within 30 days of any EAIA or national supervisory authority Art. 5 guidance publication, mapping each Art. 5(1) prohibition to its definitional elements and organizational legal interpretation", "art_5_screening_record for each AI system in the intake registry, including screening_date, register_version_used, screener_identity, and screening_outcome (clear / potential-match / deferred)", "art_5_clearance_determination document for flagged systems including written_legal_opinion, ethics_officer_countersignature, determination_date within 10 business days of flag_date, and determination outcome (cleared / rejected)", "vendor_contract_art_5_compliance_provisions confirming Art. 5 compliance representations and audit rights in contracts for all AI system vendors", "annual_portfolio_audit_record showing Art. 5 re-screening completion date for all production systems against the current register version" ], "evidence": [ { "id": "EF-05-E1", "description": "prohibited_practices_register document version-controlled with last_updated_date within 30 days of any EAIA or national supervisory authority Art. 5 guidance publication, mapping each Art. 5(1) prohibition to its definitional elements and organizational legal interpretation", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-05-E2", "description": "art_5_screening_record for each AI system in the intake registry, including screening_date, register_version_used, screener_identity, and screening_outcome (clear / potential-match / deferred)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-05-E3", "description": "art_5_clearance_determination document for flagged systems including written_legal_opinion, ethics_officer_countersignature, determination_date within 10 business days of flag_date, and determination outcome (cleared / rejected)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-05-E4", "description": "vendor_contract_art_5_compliance_provisions confirming Art. 5 compliance representations and audit rights in contracts for all AI system vendors", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-05-E5", "description": "annual_portfolio_audit_record showing Art. 5 re-screening completion date for all production systems against the current register version", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "This control is specifically designed to operationalize EU AI Act Art. 5 prohibited practices compliance. Every element of the Prohibited Practices Register, screening process, and clearance determination is structured to demonstrate that the organization has implemented systematic controls to prevent deployment of Art. 5 prohibited systems." }, { "control": "apeiris://ethics/controls/HI-03", "id": "HI-03", "domain": "ethics", "name": "Vulnerable Population Protection", "validation_objective": "Every AI system in production must have a completed vulnerability impact screening record identifying which vulnerable population categories are in scope, their exposure frequency, and the resulting vulnerability risk score. All systems scoring above the defined threshold must have documented and verified enhanced safeguards implemented, and user testing results from representative vulnerable population participants must be on file prior to deployment and refreshed within 12 months.", "blocking_effect": "blocks-deployment", "evidence_required": [ "vulnerability_impact_screening_record per AI system listing all vulnerable population categories assessed, exposure frequency estimates, vulnerability risk score, and scoring rationale, with completion date before initial deployment", "enhanced_safeguard_implementation_record for each system scoring above the vulnerability risk threshold, documenting each required safeguard (simplified language options, WCAG 2.1 AA compliance, human review gates for high-stakes decisions, crisis detection and escalation pathways) with implementation verification evidence", "user_testing_results from sessions conducted with representative members of each identified vulnerable population category including comprehension scores, consent quality observations, and rights-exercise assessments", "model_performance_disaggregation_report showing evaluation metrics separately for each vulnerable population category with identified performance gaps and applied bias mitigation measures", "wcag_compliance_audit_report for all user-facing interfaces confirming WCAG 2.1 AA conformance or documenting known exceptions with assigned remediation timelines" ], "evidence": [ { "id": "HI-03-E1", "description": "vulnerability_impact_screening_record per AI system listing all vulnerable population categories assessed, exposure frequency estimates, vulnerability risk score, and scoring rationale, with completion date before initial deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-03-E2", "description": "enhanced_safeguard_implementation_record for each system scoring above the vulnerability risk threshold, documenting each required safeguard (simplified language options, WCAG 2.1 AA compliance, human review gates for high-stakes decisions, crisis detection and escalation pathways) with implementation verification evidence", "evidence_type": "human-review-record", "verification": "human" }, { "id": "HI-03-E3", "description": "user_testing_results from sessions conducted with representative members of each identified vulnerable population category including comprehension scores, consent quality observations, and rights-exercise assessments", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-03-E4", "description": "model_performance_disaggregation_report showing evaluation metrics separately for each vulnerable population category with identified performance gaps and applied bias mitigation measures", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "HI-03-E5", "description": "wcag_compliance_audit_report for all user-facing interfaces confirming WCAG 2.1 AA conformance or documenting known exceptions with assigned remediation timelines", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 9(2)(b) explicitly requires that risk management measures account for the reasonably foreseeable misuse and the heightened vulnerability of specific groups, including children and persons with disabilities. This control operationalizes that requirement through structured vulnerability screening and proportionate safeguard implementation." }, { "control": "apeiris://ethics/controls/HI-07", "id": "HI-07", "domain": "ethics", "name": "Child and Minors Safety Controls", "validation_objective": "Every AI system with a child exposure classification above the minimum threshold must have documented age-appropriate design controls implemented, active CSAM detection safeguards validated through testing, and a signed child safety review completed before deployment. A passing state requires 100% of generative AI systems to have active CSAM detection instrumentation and zero above-threshold systems deployed without a dated, signed child safety review record.", "blocking_effect": "blocks-deployment", "evidence_required": [ "child_exposure_assessment_record for each AI system showing estimated minor user percentage based on empirical data, classification tier, assessment methodology, and assessment date within the past 12 months", "age_appropriate_design_control_manifest per above-threshold system listing content filter calibration level (youngest likely user cohort), prohibited engagement mechanics inventory, and parental oversight pathway URL", "CSAM_detection_safeguard_validation_record confirming detection mechanisms are active and have been tested against synthetic prohibited content test cases with zero false negatives and documented true positive rates", "child_safety_review_sign_off record with reviewer identity, developmental psychologist consultation reference or report, approval date predating the system's production deployment date, and any open findings with remediation status" ], "evidence": [ { "id": "HI-07-E1", "description": "child_exposure_assessment_record for each AI system showing estimated minor user percentage based on empirical data, classification tier, assessment methodology, and assessment date within the past 12 months", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-07-E2", "description": "age_appropriate_design_control_manifest per above-threshold system listing content filter calibration level (youngest likely user cohort), prohibited engagement mechanics inventory, and parental oversight pathway URL", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-07-E3", "description": "CSAM_detection_safeguard_validation_record confirming detection mechanisms are active and have been tested against synthetic prohibited content test cases with zero false negatives and documented true positive rates", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "HI-07-E4", "description": "child_safety_review_sign_off record with reviewer identity, developmental psychologist consultation reference or report, approval date predating the system's production deployment date, and any open findings with remediation status", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 5(1)(a) prohibits AI systems that deploy subliminal or manipulative techniques, with heightened application to systems targeting minors. The control's prohibition on manipulative engagement mechanics targeting children directly implements this provision." }, { "control": "apeiris://ethics/controls/FA-07", "id": "FA-07", "domain": "ethics", "name": "Bias Remediation Governance", "validation_objective": "The organization's Bias Remediation Governance Process (BRGP) is documented, operational, and demonstrably functions: every bias finding is classified by severity, escalated within defined SLAs, assigned to a remediation owner, resolved through a verified fix, and closed only after a verification re-test confirms resolution without introducing new disparities.", "blocking_effect": "requires-review", "evidence_required": [ "bias_finding_register with fields: finding_id, severity_class, escalation_timestamp, escalation_target, remediation_owner, remediation_method, verification_retest_result, and closure_timestamp for each finding", "escalation_audit_log showing timestamped escalation events for each critical and high finding with receiving party and resolution pathway", "remediation_verification_report per closed finding, including re-test results on held-out verification dataset and confirmation that no new disparities were introduced on other protected characteristics", "root_cause_analysis_document for each critical and high finding, including structural corrective actions approved by the ethics officer", "ethics_review_board_minutes showing board convened within required cadence with attendance record, findings reviewed, and decisions made" ], "evidence": [ { "id": "FA-07-E1", "description": "bias_finding_register with fields: finding_id, severity_class, escalation_timestamp, escalation_target, remediation_owner, remediation_method, verification_retest_result, and closure_timestamp for each finding", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-07-E2", "description": "escalation_audit_log showing timestamped escalation events for each critical and high finding with receiving party and resolution pathway", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-07-E3", "description": "remediation_verification_report per closed finding, including re-test results on held-out verification dataset and confirmation that no new disparities were introduced on other protected characteristics", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "FA-07-E4", "description": "root_cause_analysis_document for each critical and high finding, including structural corrective actions approved by the ethics officer", "evidence_type": "human-review-record", "verification": "human" }, { "id": "FA-07-E5", "description": "ethics_review_board_minutes showing board convened within required cadence with attendance record, findings reviewed, and decisions made", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 9(1) requires a risk management system that includes ongoing risk control measures throughout the AI system lifecycle. The BRGP is the ongoing corrective measure component of the risk management system for fairness risks." } ] }, { "requirement_id": "EU-AIA-ART05-01c", "section": "Art. 5(1)(c)", "title": "Prohibited AI \u2014 social scoring by public authorities", "text": "AI systems by or on behalf of public authorities for the evaluation or classification of natural persons based on their social behaviour or predicted personal or personality characteristics leading to detrimental or unfavourable treatment are prohibited.", "verdict": "supported", "coverage": "direct", "notes": "EF-05 maintains the prohibited-practice compliance gate. FA-02 (Algorithmic Bias Impact Assessment) would surface any classification scheme that segments populations in ways analogous to social scoring. FA-06 (Disparate Impact Analysis) detects when AI-driven classifications systematically disadvantage specific demographic groups in a manner inconsistent with the system's stated purpose. EG-02 (AI Ethics Policy Framework) requires that organizational policy explicitly prohibit deployment of social scoring mechanisms.", "control_count": 4, "proof_chain": [ { "control": "apeiris://ethics/controls/EF-05", "id": "EF-05", "domain": "ethics", "name": "EU AI Act Prohibited Practices Governance (Art. 5)", "validation_objective": "Every AI system developed, deployed, or procured by the organization must have an Art. 5 screening record confirming evaluation against the current Prohibited Practices Register before intake resources were allocated. Any system that triggers a potential-match flag must have a formal Art. 5 Clearance determination with written legal opinion and ethics officer countersignature completed within 10 business days of the flag before any further development, deployment, or procurement proceeds.", "blocking_effect": "blocks-deployment", "evidence_required": [ "prohibited_practices_register document version-controlled with last_updated_date within 30 days of any EAIA or national supervisory authority Art. 5 guidance publication, mapping each Art. 5(1) prohibition to its definitional elements and organizational legal interpretation", "art_5_screening_record for each AI system in the intake registry, including screening_date, register_version_used, screener_identity, and screening_outcome (clear / potential-match / deferred)", "art_5_clearance_determination document for flagged systems including written_legal_opinion, ethics_officer_countersignature, determination_date within 10 business days of flag_date, and determination outcome (cleared / rejected)", "vendor_contract_art_5_compliance_provisions confirming Art. 5 compliance representations and audit rights in contracts for all AI system vendors", "annual_portfolio_audit_record showing Art. 5 re-screening completion date for all production systems against the current register version" ], "evidence": [ { "id": "EF-05-E1", "description": "prohibited_practices_register document version-controlled with last_updated_date within 30 days of any EAIA or national supervisory authority Art. 5 guidance publication, mapping each Art. 5(1) prohibition to its definitional elements and organizational legal interpretation", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-05-E2", "description": "art_5_screening_record for each AI system in the intake registry, including screening_date, register_version_used, screener_identity, and screening_outcome (clear / potential-match / deferred)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-05-E3", "description": "art_5_clearance_determination document for flagged systems including written_legal_opinion, ethics_officer_countersignature, determination_date within 10 business days of flag_date, and determination outcome (cleared / rejected)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-05-E4", "description": "vendor_contract_art_5_compliance_provisions confirming Art. 5 compliance representations and audit rights in contracts for all AI system vendors", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-05-E5", "description": "annual_portfolio_audit_record showing Art. 5 re-screening completion date for all production systems against the current register version", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "This control is specifically designed to operationalize EU AI Act Art. 5 prohibited practices compliance. Every element of the Prohibited Practices Register, screening process, and clearance determination is structured to demonstrate that the organization has implemented systematic controls to prevent deployment of Art. 5 prohibited systems." }, { "control": "apeiris://ethics/controls/FA-02", "id": "FA-02", "domain": "ethics", "name": "Algorithmic Bias Impact Assessment", "validation_objective": "Every AI system subject to fairness evaluation must have a completed Algorithmic Bias Impact Assessment (ABIA) covering all protected characteristics in the FA-01 register, addressing both training data composition bias and model prediction disparities, completed before initial deployment and re-run after any material model or data change.", "blocking_effect": "blocks-deployment", "evidence_required": [ "algorithmic_bias_impact_assessment_report with per-characteristic findings, methodology description, direct discrimination and disparate impact pathways assessed, and risk rating for each finding", "training_data_composition_report showing demographic representation across protected groups relative to the reference deployment population", "model_prediction_disaggregation_report showing predicted outcome rates by protected characteristic with confidence intervals and statistical significance testing", "feedback_loop_risk_analysis documenting whether biased model outputs could influence future training data collection or labeling", "abia_reviewer_sign_off_record with reviewer credentials and date confirming independence from the model development team" ], "evidence": [ { "id": "FA-02-E1", "description": "algorithmic_bias_impact_assessment_report with per-characteristic findings, methodology description, direct discrimination and disparate impact pathways assessed, and risk rating for each finding", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E2", "description": "training_data_composition_report showing demographic representation across protected groups relative to the reference deployment population", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E3", "description": "model_prediction_disaggregation_report showing predicted outcome rates by protected characteristic with confidence intervals and statistical significance testing", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E4", "description": "feedback_loop_risk_analysis documenting whether biased model outputs could influence future training data collection or labeling", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E5", "description": "abia_reviewer_sign_off_record with reviewer credentials and date confirming independence from the model development team", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "Article 9(2)(b) of the EU AI Act requires that risk management for high-risk AI systems include testing procedures to identify and address foreseeable risks, explicitly including bias. A pre-deployment ABIA is the primary mechanism for satisfying this requirement." }, { "control": "apeiris://ethics/controls/FA-06", "id": "FA-06", "domain": "ethics", "name": "Disparate Impact Analysis", "validation_objective": "Every AI system subject to fairness requirements must have a completed statistical disparate impact analysis that disaggregates decision outcomes by each protected characteristic in the FA-01 register using the metrics selected in FA-03, includes intersectional subgroup analysis, applies multiple comparisons correction, and documents a threshold sensitivity analysis to confirm findings are not threshold-specific.", "blocking_effect": "blocks-deployment", "evidence_required": [ "disparate_impact_analysis_report with adverse_impact_ratio computed per protected characteristic and per intersectional subgroup, using selected fairness metrics with statistical significance testing and multiple comparisons correction applied", "disaggregated_outcome_dataset showing predicted decision rates per demographic group with confidence intervals and group sample sizes", "four_fifths_rule_analysis_record for employment and credit contexts showing selection rate ratios by protected characteristic relative to the most-favored group", "intersectional_subgroup_analysis_report confirming that pairwise combinations of protected characteristics were evaluated for all subgroups with sample size \u2265 30", "threshold_sensitivity_analysis documenting outcome disparity ratios tested across a range of decision thresholds to verify findings are not an artifact of a single threshold value" ], "evidence": [ { "id": "FA-06-E1", "description": "disparate_impact_analysis_report with adverse_impact_ratio computed per protected characteristic and per intersectional subgroup, using selected fairness metrics with statistical significance testing and multiple comparisons correction applied", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-06-E2", "description": "disaggregated_outcome_dataset showing predicted decision rates per demographic group with confidence intervals and group sample sizes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-06-E3", "description": "four_fifths_rule_analysis_record for employment and credit contexts showing selection rate ratios by protected characteristic relative to the most-favored group", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-06-E4", "description": "intersectional_subgroup_analysis_report confirming that pairwise combinations of protected characteristics were evaluated for all subgroups with sample size \u2265 30", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-06-E5", "description": "threshold_sensitivity_analysis documenting outcome disparity ratios tested across a range of decision thresholds to verify findings are not an artifact of a single threshold value", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 10(5) requires that testing datasets for high-risk AI systems enable monitoring for bias. Disaggregated disparate impact analysis across demographic groups is the primary mechanism for monitoring the output bias that Art. 10(5) requires." }, { "control": "apeiris://ethics/controls/EG-02", "id": "EG-02", "domain": "ethics", "name": "AI Ethics Policy Framework", "validation_objective": "The enterprise must maintain a comprehensive, current AI ethics policy framework with a top-level policy approved at C-suite or board level, domain-specific sub-policies covering fairness, transparency, privacy, and safety, a documented prohibited use register, and evidence that all AI systems in production have completed policy compliance sign-off at each lifecycle gate. The control passes if no AI system is in production without documented ethics policy review and sign-off at design, pre-deployment, and post-deployment monitoring gates.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Top-level AI Ethics Policy document with C-suite or board approval signature, current version number, and most recent review date within the past 12 months", "Domain-specific ethics sub-policy documents for fairness and non-discrimination, transparency and explainability, privacy, safety, and environmental impact, each with version history and last-reviewed date", "Prohibited AI use register listing explicitly prohibited use cases with sufficient specificity to enable compliance determination, approved at ethics officer and legal counsel level and reviewed within the past 12 months against current regulatory requirements", "AI system policy compliance sign-off records showing documented ethics policy review at design gate, pre-deployment gate, and post-deployment monitoring gate for all AI systems in production with the reviewing team lead's attestation", "Policy distribution records confirming all AI product teams have access to the ethics policy framework, with read confirmation or training completion records as applicable" ], "evidence": [ { "id": "EG-02-E1", "description": "Top-level AI Ethics Policy document with C-suite or board approval signature, current version number, and most recent review date within the past 12 months", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EG-02-E2", "description": "Domain-specific ethics sub-policy documents for fairness and non-discrimination, transparency and explainability, privacy, safety, and environmental impact, each with version history and last-reviewed date", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EG-02-E3", "description": "Prohibited AI use register listing explicitly prohibited use cases with sufficient specificity to enable compliance determination, approved at ethics officer and legal counsel level and reviewed within the past 12 months against current regulatory requirements", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EG-02-E4", "description": "AI system policy compliance sign-off records showing documented ethics policy review at design gate, pre-deployment gate, and post-deployment monitoring gate for all AI systems in production with the reviewing team lead's attestation", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "EG-02-E5", "description": "Policy distribution records confirming all AI product teams have access to the ethics policy framework, with read confirmation or training completion records as applicable", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Articles 9 and 13 require high-risk AI providers to implement risk management systems and transparency measures. A formal ethics policy framework with prohibited use registers and transparency requirements directly supports these obligations." } ] }, { "requirement_id": "EU-AIA-ART05-01d", "section": "Art. 5(1)(d)", "title": "Prohibited AI \u2014 real-time remote biometric identification in public spaces", "text": "AI systems for real-time remote biometric identification of natural persons in publicly accessible spaces for law enforcement purposes are prohibited, subject to limited enumerated exceptions.", "verdict": "partial", "coverage": "partial", "notes": "EF-05 provides the governance gate for Art. 5 prohibited practices. PC-06 (AI Privacy Impact Assessment) and DC-02 (Special Category Data Classification) provide controls for biometric data governance. IF-05 (eIDAS 2.0 Qualified Attestation for EU Operations) covers EU identity infrastructure. Partial: the narrow law-enforcement exception process and judicial/administrative authorization requirements are specific procedural obligations that fall outside Apeiris controls and require dedicated legal and operational workflows.", "control_count": 4, "proof_chain": [ { "control": "apeiris://ethics/controls/EF-05", "id": "EF-05", "domain": "ethics", "name": "EU AI Act Prohibited Practices Governance (Art. 5)", "validation_objective": "Every AI system developed, deployed, or procured by the organization must have an Art. 5 screening record confirming evaluation against the current Prohibited Practices Register before intake resources were allocated. Any system that triggers a potential-match flag must have a formal Art. 5 Clearance determination with written legal opinion and ethics officer countersignature completed within 10 business days of the flag before any further development, deployment, or procurement proceeds.", "blocking_effect": "blocks-deployment", "evidence_required": [ "prohibited_practices_register document version-controlled with last_updated_date within 30 days of any EAIA or national supervisory authority Art. 5 guidance publication, mapping each Art. 5(1) prohibition to its definitional elements and organizational legal interpretation", "art_5_screening_record for each AI system in the intake registry, including screening_date, register_version_used, screener_identity, and screening_outcome (clear / potential-match / deferred)", "art_5_clearance_determination document for flagged systems including written_legal_opinion, ethics_officer_countersignature, determination_date within 10 business days of flag_date, and determination outcome (cleared / rejected)", "vendor_contract_art_5_compliance_provisions confirming Art. 5 compliance representations and audit rights in contracts for all AI system vendors", "annual_portfolio_audit_record showing Art. 5 re-screening completion date for all production systems against the current register version" ], "evidence": [ { "id": "EF-05-E1", "description": "prohibited_practices_register document version-controlled with last_updated_date within 30 days of any EAIA or national supervisory authority Art. 5 guidance publication, mapping each Art. 5(1) prohibition to its definitional elements and organizational legal interpretation", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-05-E2", "description": "art_5_screening_record for each AI system in the intake registry, including screening_date, register_version_used, screener_identity, and screening_outcome (clear / potential-match / deferred)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-05-E3", "description": "art_5_clearance_determination document for flagged systems including written_legal_opinion, ethics_officer_countersignature, determination_date within 10 business days of flag_date, and determination outcome (cleared / rejected)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-05-E4", "description": "vendor_contract_art_5_compliance_provisions confirming Art. 5 compliance representations and audit rights in contracts for all AI system vendors", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-05-E5", "description": "annual_portfolio_audit_record showing Art. 5 re-screening completion date for all production systems against the current register version", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "This control is specifically designed to operationalize EU AI Act Art. 5 prohibited practices compliance. Every element of the Prohibited Practices Register, screening process, and clearance determination is structured to demonstrate that the organization has implemented systematic controls to prevent deployment of Art. 5 prohibited systems." }, { "control": "apeiris://privacy/controls/PC-06", "id": "PC-06", "domain": "privacy", "name": "AI Privacy Impact Assessment", "validation_objective": "For every AI system that processes personal data, a completed AI-specific Privacy Impact Assessment exists, produced before deployment, explicitly addressing model memorization risk with empirical test results, inference attack exposure, training data leakage scenarios, and automated decision effects. The assessment must carry DPO review sign-off and documented risk acceptance by the business owner for any residual risk above threshold.", "blocking_effect": "blocks-deployment", "evidence_required": [ "AI_PIA_report with system identifier, assessment date, scope of personal data processed, model architecture summary, assessor identity, and completion timestamp predating deployment_date", "memorization_risk_test_results showing membership inference attack test outcomes (e.g., canary token insertion and recovery rates, membership inference AUC) and mitigations applied with effectiveness evidence", "training_data_exposure_analysis documenting data lineage, anonymization or pseudonymisation techniques applied, and residual re-identification risk score with methodology", "automated_decision_effect_analysis listing each decision type the AI makes with documented human review trigger conditions, appeal mechanism reference, and explanation capability status", "DPO_review_record and business_owner_risk_acceptance for any residual risks above the acceptable threshold, with acceptance date and accepted_risk_items listed" ], "evidence": [ { "id": "PC-06-E1", "description": "AI_PIA_report with system identifier, assessment date, scope of personal data processed, model architecture summary, assessor identity, and completion timestamp predating deployment_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PC-06-E2", "description": "memorization_risk_test_results showing membership inference attack test outcomes (e.g., canary token insertion and recovery rates, membership inference AUC) and mitigations applied with effectiveness evidence", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "PC-06-E3", "description": "training_data_exposure_analysis documenting data lineage, anonymization or pseudonymisation techniques applied, and residual re-identification risk score with methodology", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "PC-06-E4", "description": "automated_decision_effect_analysis listing each decision type the AI makes with documented human review trigger conditions, appeal mechanism reference, and explanation capability status", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PC-06-E5", "description": "DPO_review_record and business_owner_risk_acceptance for any residual risks above the acceptable threshold, with acceptance date and accepted_risk_items listed", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "PC-06 partially addresses EU AI Act Art 27 by producing a fundamental rights impact assessment as a distinct document for high-risk AI systems; Art 27(4) allows the FRIA to build on the GDPR Art 35 DPIA that PC-06 extends to AI-specific privacy risks." }, { "control": "apeiris://privacy/controls/DC-02", "id": "DC-02", "domain": "privacy", "name": "Special Category Data Classification", "validation_objective": "Every AI training dataset and inference input stream must be scanned for GDPR Art 9 special category data and CCPA sensitive personal information before processing begins. Any dataset containing detected special category data must have a corresponding classification registry entry with a documented Art 9(2) basis and DPO acknowledgment before the pipeline is permitted to execute.", "blocking_effect": "blocks-deployment", "evidence_required": [ "special_category_classification_registry \u2014 export of all datasets classified as containing special category data with fields: detected_categories[], art9_basis, dpo_acknowledgment_date, access_restriction_profile, and registry_expiry", "classifier_scan_report \u2014 most recent automated classification scan output across active AI training datasets showing coverage percentage, detected categories, and confidence scores", "heightened_access_audit_log \u2014 access log for special category datasets showing every access attributed to an authorized processor role with documented purpose within the review period", "dpia_records \u2014 completed Data Protection Impact Assessments for all AI systems processing Art 9 data, including scope matching classification registry entries" ], "evidence": [ { "id": "DC-02-E1", "description": "special_category_classification_registry \u2014 export of all datasets classified as containing special category data with fields: detected_categories[], art9_basis, dpo_acknowledgment_date, access_restriction_profile, and registry_expiry", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "DC-02-E2", "description": "classifier_scan_report \u2014 most recent automated classification scan output across active AI training datasets showing coverage percentage, detected categories, and confidence scores", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "DC-02-E3", "description": "heightened_access_audit_log \u2014 access log for special category datasets showing every access attributed to an authorized processor role with documented purpose within the review period", "evidence_type": "audit-log", "verification": "automated" }, { "id": "DC-02-E4", "description": "dpia_records \u2014 completed Data Protection Impact Assessments for all AI systems processing Art 9 data, including scope matching classification registry entries", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://identity/controls/IF-05", "id": "IF-05", "domain": "identity", "name": "eIDAS 2.0 Qualified Attestation for EU Operations", "validation_objective": "AI agents authenticating to EU-regulated services within the eIDAS 2.0 mandatory acceptance scope must present Qualified Electronic Attestations of Attributes issued by a QTSP currently listed on an EU member state national Trusted List. Receiving services must validate QEAA signatures against the unified EU Trusted List, reject expired QEAAs regardless of signature validity, and accept cross-border QEAAs through unified Trusted List lookup rather than domestic-only TSL.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "eidas2_scope_assessment documenting which AI agent deployments fall within eIDAS 2.0 mandatory acceptance scope, with justification per deployment and review date by EU legal counsel", "qtsp_verification_records confirming each QTSP's listing on the applicable EU national Trusted List with verification date, listing URL, and next-scheduled reverification date", "regulatory_watch_entries in regulatory-watch.json tracking eIDAS 2.0 implementing act publication status, relevant-to-deployment flags, and scheduled control review dates", "qeaa_validation_test_results showing expired QEAA rejection and cross-border recognition via unified EU Trusted List for each QTSP used" ], "evidence": [ { "id": "IF-05-E1", "description": "eidas2_scope_assessment documenting which AI agent deployments fall within eIDAS 2.0 mandatory acceptance scope, with justification per deployment and review date by EU legal counsel", "evidence_type": "human-review-record", "verification": "human" }, { "id": "IF-05-E2", "description": "qtsp_verification_records confirming each QTSP's listing on the applicable EU national Trusted List with verification date, listing URL, and next-scheduled reverification date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "IF-05-E3", "description": "regulatory_watch_entries in regulatory-watch.json tracking eIDAS 2.0 implementing act publication status, relevant-to-deployment flags, and scheduled control review dates", "evidence_type": "human-review-record", "verification": "human" }, { "id": "IF-05-E4", "description": "qeaa_validation_test_results showing expired QEAA rejection and cross-border recognition via unified EU Trusted List for each QTSP used", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "EU-AIA-ART05-01e", "section": "Art. 5(1)(e)", "title": "Prohibited AI \u2014 emotion recognition in workplace and education", "text": "AI systems used for emotion recognition in the workplace and educational institutions are prohibited.", "verdict": "supported", "coverage": "direct", "notes": "EF-05 directly covers this prohibition in the prohibited-practice register and design-time review gate. HI-02 (Human Dignity and Autonomy Preservation) requires controls against surveillance that infringes dignity or autonomy in institutional contexts. PC-06 (AI Privacy Impact Assessment) flags emotion-inference systems processing personal data without lawful basis. EG-02 requires explicit organizational policy prohibiting deployment of emotion-recognition systems in employment or educational settings.", "control_count": 4, "proof_chain": [ { "control": "apeiris://ethics/controls/EF-05", "id": "EF-05", "domain": "ethics", "name": "EU AI Act Prohibited Practices Governance (Art. 5)", "validation_objective": "Every AI system developed, deployed, or procured by the organization must have an Art. 5 screening record confirming evaluation against the current Prohibited Practices Register before intake resources were allocated. Any system that triggers a potential-match flag must have a formal Art. 5 Clearance determination with written legal opinion and ethics officer countersignature completed within 10 business days of the flag before any further development, deployment, or procurement proceeds.", "blocking_effect": "blocks-deployment", "evidence_required": [ "prohibited_practices_register document version-controlled with last_updated_date within 30 days of any EAIA or national supervisory authority Art. 5 guidance publication, mapping each Art. 5(1) prohibition to its definitional elements and organizational legal interpretation", "art_5_screening_record for each AI system in the intake registry, including screening_date, register_version_used, screener_identity, and screening_outcome (clear / potential-match / deferred)", "art_5_clearance_determination document for flagged systems including written_legal_opinion, ethics_officer_countersignature, determination_date within 10 business days of flag_date, and determination outcome (cleared / rejected)", "vendor_contract_art_5_compliance_provisions confirming Art. 5 compliance representations and audit rights in contracts for all AI system vendors", "annual_portfolio_audit_record showing Art. 5 re-screening completion date for all production systems against the current register version" ], "evidence": [ { "id": "EF-05-E1", "description": "prohibited_practices_register document version-controlled with last_updated_date within 30 days of any EAIA or national supervisory authority Art. 5 guidance publication, mapping each Art. 5(1) prohibition to its definitional elements and organizational legal interpretation", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-05-E2", "description": "art_5_screening_record for each AI system in the intake registry, including screening_date, register_version_used, screener_identity, and screening_outcome (clear / potential-match / deferred)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-05-E3", "description": "art_5_clearance_determination document for flagged systems including written_legal_opinion, ethics_officer_countersignature, determination_date within 10 business days of flag_date, and determination outcome (cleared / rejected)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-05-E4", "description": "vendor_contract_art_5_compliance_provisions confirming Art. 5 compliance representations and audit rights in contracts for all AI system vendors", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-05-E5", "description": "annual_portfolio_audit_record showing Art. 5 re-screening completion date for all production systems against the current register version", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "This control is specifically designed to operationalize EU AI Act Art. 5 prohibited practices compliance. Every element of the Prohibited Practices Register, screening process, and clearance determination is structured to demonstrate that the organization has implemented systematic controls to prevent deployment of Art. 5 prohibited systems." }, { "control": "apeiris://ethics/controls/HI-02", "id": "HI-02", "domain": "ethics", "name": "Human Dignity and Autonomy Preservation", "validation_objective": "No AI system may be deployed or continue operating if a red-team evaluation has identified unresolved high-severity dignity violations or autonomy-undermining patterns within the control's defined remediation SLA. All production AI systems must have a current red-team evaluation on record (within the prior 90 days), and production user research must show autonomy-pressure indicators below the 5% threshold.", "blocking_effect": "blocks-deployment", "evidence_required": [ "red_team_evaluation_report per AI system, conducted within the prior 90 days, scored against the dignity and autonomy rubric with all findings categorized by severity and tracked to remediation status", "prohibited_patterns_registry document listing current prohibited patterns with definitions, illustrative examples, and most recent review date confirming currency within 18 months", "optimization_objective_audit_record demonstrating that model training objectives were reviewed for engagement or dependency metrics that could proxy for manipulation or autonomy-undermining behavior", "user_research_results showing autonomy-preservation indicators including percentage of users reporting pressure, rate of AI suggestions accepted without modification, measurement methodology, and sample demographics", "remediation_tracker showing all open red-team findings with severity classification, assigned owner, SLA due date, and current resolution status" ], "evidence": [ { "id": "HI-02-E1", "description": "red_team_evaluation_report per AI system, conducted within the prior 90 days, scored against the dignity and autonomy rubric with all findings categorized by severity and tracked to remediation status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-02-E2", "description": "prohibited_patterns_registry document listing current prohibited patterns with definitions, illustrative examples, and most recent review date confirming currency within 18 months", "evidence_type": "human-review-record", "verification": "human" }, { "id": "HI-02-E3", "description": "optimization_objective_audit_record demonstrating that model training objectives were reviewed for engagement or dependency metrics that could proxy for manipulation or autonomy-undermining behavior", "evidence_type": "human-review-record", "verification": "human" }, { "id": "HI-02-E4", "description": "user_research_results showing autonomy-preservation indicators including percentage of users reporting pressure, rate of AI suggestions accepted without modification, measurement methodology, and sample demographics", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-02-E5", "description": "remediation_tracker showing all open red-team findings with severity classification, assigned owner, SLA due date, and current resolution status", "evidence_type": "red-team-report", "verification": "third-party" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 5(1)(b) prohibits AI systems that exploit vulnerabilities or use subliminal techniques to materially distort behavior in ways that harm users \u2014 a direct prohibition on autonomy-undermining manipulation. This control's prohibited patterns registry implements the Article 5 prohibition operationally." }, { "control": "apeiris://privacy/controls/PC-06", "id": "PC-06", "domain": "privacy", "name": "AI Privacy Impact Assessment", "validation_objective": "For every AI system that processes personal data, a completed AI-specific Privacy Impact Assessment exists, produced before deployment, explicitly addressing model memorization risk with empirical test results, inference attack exposure, training data leakage scenarios, and automated decision effects. The assessment must carry DPO review sign-off and documented risk acceptance by the business owner for any residual risk above threshold.", "blocking_effect": "blocks-deployment", "evidence_required": [ "AI_PIA_report with system identifier, assessment date, scope of personal data processed, model architecture summary, assessor identity, and completion timestamp predating deployment_date", "memorization_risk_test_results showing membership inference attack test outcomes (e.g., canary token insertion and recovery rates, membership inference AUC) and mitigations applied with effectiveness evidence", "training_data_exposure_analysis documenting data lineage, anonymization or pseudonymisation techniques applied, and residual re-identification risk score with methodology", "automated_decision_effect_analysis listing each decision type the AI makes with documented human review trigger conditions, appeal mechanism reference, and explanation capability status", "DPO_review_record and business_owner_risk_acceptance for any residual risks above the acceptable threshold, with acceptance date and accepted_risk_items listed" ], "evidence": [ { "id": "PC-06-E1", "description": "AI_PIA_report with system identifier, assessment date, scope of personal data processed, model architecture summary, assessor identity, and completion timestamp predating deployment_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PC-06-E2", "description": "memorization_risk_test_results showing membership inference attack test outcomes (e.g., canary token insertion and recovery rates, membership inference AUC) and mitigations applied with effectiveness evidence", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "PC-06-E3", "description": "training_data_exposure_analysis documenting data lineage, anonymization or pseudonymisation techniques applied, and residual re-identification risk score with methodology", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "PC-06-E4", "description": "automated_decision_effect_analysis listing each decision type the AI makes with documented human review trigger conditions, appeal mechanism reference, and explanation capability status", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PC-06-E5", "description": "DPO_review_record and business_owner_risk_acceptance for any residual risks above the acceptable threshold, with acceptance date and accepted_risk_items listed", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "PC-06 partially addresses EU AI Act Art 27 by producing a fundamental rights impact assessment as a distinct document for high-risk AI systems; Art 27(4) allows the FRIA to build on the GDPR Art 35 DPIA that PC-06 extends to AI-specific privacy risks." }, { "control": "apeiris://ethics/controls/EG-02", "id": "EG-02", "domain": "ethics", "name": "AI Ethics Policy Framework", "validation_objective": "The enterprise must maintain a comprehensive, current AI ethics policy framework with a top-level policy approved at C-suite or board level, domain-specific sub-policies covering fairness, transparency, privacy, and safety, a documented prohibited use register, and evidence that all AI systems in production have completed policy compliance sign-off at each lifecycle gate. The control passes if no AI system is in production without documented ethics policy review and sign-off at design, pre-deployment, and post-deployment monitoring gates.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Top-level AI Ethics Policy document with C-suite or board approval signature, current version number, and most recent review date within the past 12 months", "Domain-specific ethics sub-policy documents for fairness and non-discrimination, transparency and explainability, privacy, safety, and environmental impact, each with version history and last-reviewed date", "Prohibited AI use register listing explicitly prohibited use cases with sufficient specificity to enable compliance determination, approved at ethics officer and legal counsel level and reviewed within the past 12 months against current regulatory requirements", "AI system policy compliance sign-off records showing documented ethics policy review at design gate, pre-deployment gate, and post-deployment monitoring gate for all AI systems in production with the reviewing team lead's attestation", "Policy distribution records confirming all AI product teams have access to the ethics policy framework, with read confirmation or training completion records as applicable" ], "evidence": [ { "id": "EG-02-E1", "description": "Top-level AI Ethics Policy document with C-suite or board approval signature, current version number, and most recent review date within the past 12 months", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EG-02-E2", "description": "Domain-specific ethics sub-policy documents for fairness and non-discrimination, transparency and explainability, privacy, safety, and environmental impact, each with version history and last-reviewed date", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EG-02-E3", "description": "Prohibited AI use register listing explicitly prohibited use cases with sufficient specificity to enable compliance determination, approved at ethics officer and legal counsel level and reviewed within the past 12 months against current regulatory requirements", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EG-02-E4", "description": "AI system policy compliance sign-off records showing documented ethics policy review at design gate, pre-deployment gate, and post-deployment monitoring gate for all AI systems in production with the reviewing team lead's attestation", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "EG-02-E5", "description": "Policy distribution records confirming all AI product teams have access to the ethics policy framework, with read confirmation or training completion records as applicable", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Articles 9 and 13 require high-risk AI providers to implement risk management systems and transparency measures. A formal ethics policy framework with prohibited use registers and transparency requirements directly supports these obligations." } ] }, { "requirement_id": "EU-AIA-ART05-01f", "section": "Art. 5(1)(f)", "title": "Prohibited AI \u2014 biometric categorization by protected characteristics", "text": "Biometric categorisation systems that categorise individually natural persons based on their biometric data to deduce or infer their race, political opinions, trade union membership, religious or philosophical beliefs, sex life or sexual orientation are prohibited.", "verdict": "supported", "coverage": "direct", "notes": "EF-05 provides the prohibition governance gate. FA-01 (Protected Characteristic Identification and Scope) requires explicit mapping of all protected characteristics in scope and prohibits inference pipelines that derive protected characteristics without lawful authority. DC-02 (Special Category Data Classification) applies strict controls to biometric data inputs. FA-02 (Algorithmic Bias Impact Assessment) would detect if a model architecture is extracting protected-characteristic proxies from biometric inputs.", "control_count": 4, "proof_chain": [ { "control": "apeiris://ethics/controls/EF-05", "id": "EF-05", "domain": "ethics", "name": "EU AI Act Prohibited Practices Governance (Art. 5)", "validation_objective": "Every AI system developed, deployed, or procured by the organization must have an Art. 5 screening record confirming evaluation against the current Prohibited Practices Register before intake resources were allocated. Any system that triggers a potential-match flag must have a formal Art. 5 Clearance determination with written legal opinion and ethics officer countersignature completed within 10 business days of the flag before any further development, deployment, or procurement proceeds.", "blocking_effect": "blocks-deployment", "evidence_required": [ "prohibited_practices_register document version-controlled with last_updated_date within 30 days of any EAIA or national supervisory authority Art. 5 guidance publication, mapping each Art. 5(1) prohibition to its definitional elements and organizational legal interpretation", "art_5_screening_record for each AI system in the intake registry, including screening_date, register_version_used, screener_identity, and screening_outcome (clear / potential-match / deferred)", "art_5_clearance_determination document for flagged systems including written_legal_opinion, ethics_officer_countersignature, determination_date within 10 business days of flag_date, and determination outcome (cleared / rejected)", "vendor_contract_art_5_compliance_provisions confirming Art. 5 compliance representations and audit rights in contracts for all AI system vendors", "annual_portfolio_audit_record showing Art. 5 re-screening completion date for all production systems against the current register version" ], "evidence": [ { "id": "EF-05-E1", "description": "prohibited_practices_register document version-controlled with last_updated_date within 30 days of any EAIA or national supervisory authority Art. 5 guidance publication, mapping each Art. 5(1) prohibition to its definitional elements and organizational legal interpretation", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-05-E2", "description": "art_5_screening_record for each AI system in the intake registry, including screening_date, register_version_used, screener_identity, and screening_outcome (clear / potential-match / deferred)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-05-E3", "description": "art_5_clearance_determination document for flagged systems including written_legal_opinion, ethics_officer_countersignature, determination_date within 10 business days of flag_date, and determination outcome (cleared / rejected)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-05-E4", "description": "vendor_contract_art_5_compliance_provisions confirming Art. 5 compliance representations and audit rights in contracts for all AI system vendors", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-05-E5", "description": "annual_portfolio_audit_record showing Art. 5 re-screening completion date for all production systems against the current register version", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "This control is specifically designed to operationalize EU AI Act Art. 5 prohibited practices compliance. Every element of the Prohibited Practices Register, screening process, and clearance determination is structured to demonstrate that the organization has implemented systematic controls to prevent deployment of Art. 5 prohibited systems." }, { "control": "apeiris://ethics/controls/FA-01", "id": "FA-01", "domain": "ethics", "name": "Protected Characteristic Identification and Scope", "validation_objective": "Every AI system must have a documented protected characteristic register that enumerates all characteristics protected under each applicable jurisdiction's law, including identified proxy variables that may encode those characteristics, updated whenever jurisdictional scope or system use case changes.", "blocking_effect": "blocks-deployment", "evidence_required": [ "protected_characteristic_register listing each characteristic with jurisdiction_applicability, regulatory_basis (statute or directive citation), and proxy_variable_mapping", "jurisdictional_scope_analysis document identifying all operating jurisdictions and the applicable non-discrimination statutes for each", "proxy_variable_review_record showing assessment of training features for potential encoding of protected characteristics", "legal_or_compliance_sign_off_record confirming register completeness for current jurisdictional scope and use context" ], "evidence": [ { "id": "FA-01-E1", "description": "protected_characteristic_register listing each characteristic with jurisdiction_applicability, regulatory_basis (statute or directive citation), and proxy_variable_mapping", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-01-E2", "description": "jurisdictional_scope_analysis document identifying all operating jurisdictions and the applicable non-discrimination statutes for each", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-01-E3", "description": "proxy_variable_review_record showing assessment of training features for potential encoding of protected characteristics", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-01-E4", "description": "legal_or_compliance_sign_off_record confirming register completeness for current jurisdictional scope and use context", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "Article 10(5) of the EU AI Act requires that providers of high-risk AI systems process special categories of personal data only to the extent strictly necessary for bias monitoring and correction. Identifying which characteristics constitute special categories within each jurisdiction is a prerequisite for compliant data handling." }, { "control": "apeiris://privacy/controls/DC-02", "id": "DC-02", "domain": "privacy", "name": "Special Category Data Classification", "validation_objective": "Every AI training dataset and inference input stream must be scanned for GDPR Art 9 special category data and CCPA sensitive personal information before processing begins. Any dataset containing detected special category data must have a corresponding classification registry entry with a documented Art 9(2) basis and DPO acknowledgment before the pipeline is permitted to execute.", "blocking_effect": "blocks-deployment", "evidence_required": [ "special_category_classification_registry \u2014 export of all datasets classified as containing special category data with fields: detected_categories[], art9_basis, dpo_acknowledgment_date, access_restriction_profile, and registry_expiry", "classifier_scan_report \u2014 most recent automated classification scan output across active AI training datasets showing coverage percentage, detected categories, and confidence scores", "heightened_access_audit_log \u2014 access log for special category datasets showing every access attributed to an authorized processor role with documented purpose within the review period", "dpia_records \u2014 completed Data Protection Impact Assessments for all AI systems processing Art 9 data, including scope matching classification registry entries" ], "evidence": [ { "id": "DC-02-E1", "description": "special_category_classification_registry \u2014 export of all datasets classified as containing special category data with fields: detected_categories[], art9_basis, dpo_acknowledgment_date, access_restriction_profile, and registry_expiry", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "DC-02-E2", "description": "classifier_scan_report \u2014 most recent automated classification scan output across active AI training datasets showing coverage percentage, detected categories, and confidence scores", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "DC-02-E3", "description": "heightened_access_audit_log \u2014 access log for special category datasets showing every access attributed to an authorized processor role with documented purpose within the review period", "evidence_type": "audit-log", "verification": "automated" }, { "id": "DC-02-E4", "description": "dpia_records \u2014 completed Data Protection Impact Assessments for all AI systems processing Art 9 data, including scope matching classification registry entries", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://ethics/controls/FA-02", "id": "FA-02", "domain": "ethics", "name": "Algorithmic Bias Impact Assessment", "validation_objective": "Every AI system subject to fairness evaluation must have a completed Algorithmic Bias Impact Assessment (ABIA) covering all protected characteristics in the FA-01 register, addressing both training data composition bias and model prediction disparities, completed before initial deployment and re-run after any material model or data change.", "blocking_effect": "blocks-deployment", "evidence_required": [ "algorithmic_bias_impact_assessment_report with per-characteristic findings, methodology description, direct discrimination and disparate impact pathways assessed, and risk rating for each finding", "training_data_composition_report showing demographic representation across protected groups relative to the reference deployment population", "model_prediction_disaggregation_report showing predicted outcome rates by protected characteristic with confidence intervals and statistical significance testing", "feedback_loop_risk_analysis documenting whether biased model outputs could influence future training data collection or labeling", "abia_reviewer_sign_off_record with reviewer credentials and date confirming independence from the model development team" ], "evidence": [ { "id": "FA-02-E1", "description": "algorithmic_bias_impact_assessment_report with per-characteristic findings, methodology description, direct discrimination and disparate impact pathways assessed, and risk rating for each finding", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E2", "description": "training_data_composition_report showing demographic representation across protected groups relative to the reference deployment population", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E3", "description": "model_prediction_disaggregation_report showing predicted outcome rates by protected characteristic with confidence intervals and statistical significance testing", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E4", "description": "feedback_loop_risk_analysis documenting whether biased model outputs could influence future training data collection or labeling", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E5", "description": "abia_reviewer_sign_off_record with reviewer credentials and date confirming independence from the model development team", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "Article 9(2)(b) of the EU AI Act requires that risk management for high-risk AI systems include testing procedures to identify and address foreseeable risks, explicitly including bias. A pre-deployment ABIA is the primary mechanism for satisfying this requirement." } ] }, { "requirement_id": "EU-AIA-ART05-01g", "section": "Art. 5(1)(g)", "title": "Prohibited AI \u2014 predictive policing based on profiling", "text": "AI systems used by or on behalf of law enforcement authorities for making individual risk assessments of natural persons in order to predict the risk of a natural person of offending or reoffending based solely on profiling are prohibited.", "verdict": "supported", "coverage": "direct", "notes": "EF-05 maintains the prohibited-practice register covering this category. FA-02 and FA-06 (Disparate Impact Analysis) identify when profiling-based predictive outputs systematically disadvantage protected groups \u2014 a defining feature of prohibited predictive policing. HI-01 (Fundamental Rights Impact Assessment Content Governance) requires assessment of any AI system that could affect liberty or legal rights before deployment.", "control_count": 4, "proof_chain": [ { "control": "apeiris://ethics/controls/EF-05", "id": "EF-05", "domain": "ethics", "name": "EU AI Act Prohibited Practices Governance (Art. 5)", "validation_objective": "Every AI system developed, deployed, or procured by the organization must have an Art. 5 screening record confirming evaluation against the current Prohibited Practices Register before intake resources were allocated. Any system that triggers a potential-match flag must have a formal Art. 5 Clearance determination with written legal opinion and ethics officer countersignature completed within 10 business days of the flag before any further development, deployment, or procurement proceeds.", "blocking_effect": "blocks-deployment", "evidence_required": [ "prohibited_practices_register document version-controlled with last_updated_date within 30 days of any EAIA or national supervisory authority Art. 5 guidance publication, mapping each Art. 5(1) prohibition to its definitional elements and organizational legal interpretation", "art_5_screening_record for each AI system in the intake registry, including screening_date, register_version_used, screener_identity, and screening_outcome (clear / potential-match / deferred)", "art_5_clearance_determination document for flagged systems including written_legal_opinion, ethics_officer_countersignature, determination_date within 10 business days of flag_date, and determination outcome (cleared / rejected)", "vendor_contract_art_5_compliance_provisions confirming Art. 5 compliance representations and audit rights in contracts for all AI system vendors", "annual_portfolio_audit_record showing Art. 5 re-screening completion date for all production systems against the current register version" ], "evidence": [ { "id": "EF-05-E1", "description": "prohibited_practices_register document version-controlled with last_updated_date within 30 days of any EAIA or national supervisory authority Art. 5 guidance publication, mapping each Art. 5(1) prohibition to its definitional elements and organizational legal interpretation", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-05-E2", "description": "art_5_screening_record for each AI system in the intake registry, including screening_date, register_version_used, screener_identity, and screening_outcome (clear / potential-match / deferred)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-05-E3", "description": "art_5_clearance_determination document for flagged systems including written_legal_opinion, ethics_officer_countersignature, determination_date within 10 business days of flag_date, and determination outcome (cleared / rejected)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-05-E4", "description": "vendor_contract_art_5_compliance_provisions confirming Art. 5 compliance representations and audit rights in contracts for all AI system vendors", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-05-E5", "description": "annual_portfolio_audit_record showing Art. 5 re-screening completion date for all production systems against the current register version", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "This control is specifically designed to operationalize EU AI Act Art. 5 prohibited practices compliance. Every element of the Prohibited Practices Register, screening process, and clearance determination is structured to demonstrate that the organization has implemented systematic controls to prevent deployment of Art. 5 prohibited systems." }, { "control": "apeiris://ethics/controls/FA-02", "id": "FA-02", "domain": "ethics", "name": "Algorithmic Bias Impact Assessment", "validation_objective": "Every AI system subject to fairness evaluation must have a completed Algorithmic Bias Impact Assessment (ABIA) covering all protected characteristics in the FA-01 register, addressing both training data composition bias and model prediction disparities, completed before initial deployment and re-run after any material model or data change.", "blocking_effect": "blocks-deployment", "evidence_required": [ "algorithmic_bias_impact_assessment_report with per-characteristic findings, methodology description, direct discrimination and disparate impact pathways assessed, and risk rating for each finding", "training_data_composition_report showing demographic representation across protected groups relative to the reference deployment population", "model_prediction_disaggregation_report showing predicted outcome rates by protected characteristic with confidence intervals and statistical significance testing", "feedback_loop_risk_analysis documenting whether biased model outputs could influence future training data collection or labeling", "abia_reviewer_sign_off_record with reviewer credentials and date confirming independence from the model development team" ], "evidence": [ { "id": "FA-02-E1", "description": "algorithmic_bias_impact_assessment_report with per-characteristic findings, methodology description, direct discrimination and disparate impact pathways assessed, and risk rating for each finding", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E2", "description": "training_data_composition_report showing demographic representation across protected groups relative to the reference deployment population", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E3", "description": "model_prediction_disaggregation_report showing predicted outcome rates by protected characteristic with confidence intervals and statistical significance testing", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E4", "description": "feedback_loop_risk_analysis documenting whether biased model outputs could influence future training data collection or labeling", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E5", "description": "abia_reviewer_sign_off_record with reviewer credentials and date confirming independence from the model development team", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "Article 9(2)(b) of the EU AI Act requires that risk management for high-risk AI systems include testing procedures to identify and address foreseeable risks, explicitly including bias. A pre-deployment ABIA is the primary mechanism for satisfying this requirement." }, { "control": "apeiris://ethics/controls/FA-06", "id": "FA-06", "domain": "ethics", "name": "Disparate Impact Analysis", "validation_objective": "Every AI system subject to fairness requirements must have a completed statistical disparate impact analysis that disaggregates decision outcomes by each protected characteristic in the FA-01 register using the metrics selected in FA-03, includes intersectional subgroup analysis, applies multiple comparisons correction, and documents a threshold sensitivity analysis to confirm findings are not threshold-specific.", "blocking_effect": "blocks-deployment", "evidence_required": [ "disparate_impact_analysis_report with adverse_impact_ratio computed per protected characteristic and per intersectional subgroup, using selected fairness metrics with statistical significance testing and multiple comparisons correction applied", "disaggregated_outcome_dataset showing predicted decision rates per demographic group with confidence intervals and group sample sizes", "four_fifths_rule_analysis_record for employment and credit contexts showing selection rate ratios by protected characteristic relative to the most-favored group", "intersectional_subgroup_analysis_report confirming that pairwise combinations of protected characteristics were evaluated for all subgroups with sample size \u2265 30", "threshold_sensitivity_analysis documenting outcome disparity ratios tested across a range of decision thresholds to verify findings are not an artifact of a single threshold value" ], "evidence": [ { "id": "FA-06-E1", "description": "disparate_impact_analysis_report with adverse_impact_ratio computed per protected characteristic and per intersectional subgroup, using selected fairness metrics with statistical significance testing and multiple comparisons correction applied", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-06-E2", "description": "disaggregated_outcome_dataset showing predicted decision rates per demographic group with confidence intervals and group sample sizes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-06-E3", "description": "four_fifths_rule_analysis_record for employment and credit contexts showing selection rate ratios by protected characteristic relative to the most-favored group", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-06-E4", "description": "intersectional_subgroup_analysis_report confirming that pairwise combinations of protected characteristics were evaluated for all subgroups with sample size \u2265 30", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-06-E5", "description": "threshold_sensitivity_analysis documenting outcome disparity ratios tested across a range of decision thresholds to verify findings are not an artifact of a single threshold value", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 10(5) requires that testing datasets for high-risk AI systems enable monitoring for bias. Disaggregated disparate impact analysis across demographic groups is the primary mechanism for monitoring the output bias that Art. 10(5) requires." }, { "control": "apeiris://ethics/controls/HI-01", "id": "HI-01", "domain": "ethics", "name": "Fundamental Rights Impact Assessment Content Governance", "validation_objective": "Every high-risk AI system subject to EU AI Act Art. 27 must have a completed FRIA with explicit impact ratings for all relevant EU Charter rights (Art. 1-54), documented population-level analysis for each protected group in scope, and signed ethics officer and legal counsel approval before production authorization is issued. No Annex III system may enter production without satisfying this gate.", "blocking_effect": "blocks-deployment", "evidence_required": [ "completed_fria document per high-risk AI system with explicit impact ratings (none/low/moderate/high/critical) for each EU Charter article, population-level analysis for all protected groups in scope, and documented mitigation for each impact rated moderate or higher", "fria_signoff_record showing ethics officer and legal counsel reviewer names, dates, and explicit production authorization confirmation for each high-risk system", "fria_registry showing version-controlled FRIA history per system with initial assessment date, reassessment dates triggered by material changes, and current version status", "mitigation_closure_evidence linking each FRIA-identified mitigation commitment to its corresponding risk register entry and documented closure verification with timestamp", "deployment_gate_record confirming FRIA completion check was executed in the AI governance workflow and the gate was satisfied before production authorization was granted" ], "evidence": [ { "id": "HI-01-E1", "description": "completed_fria document per high-risk AI system with explicit impact ratings (none/low/moderate/high/critical) for each EU Charter article, population-level analysis for all protected groups in scope, and documented mitigation for each impact rated moderate or higher", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-01-E2", "description": "fria_signoff_record showing ethics officer and legal counsel reviewer names, dates, and explicit production authorization confirmation for each high-risk system", "evidence_type": "human-review-record", "verification": "human" }, { "id": "HI-01-E3", "description": "fria_registry showing version-controlled FRIA history per system with initial assessment date, reassessment dates triggered by material changes, and current version status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-01-E4", "description": "mitigation_closure_evidence linking each FRIA-identified mitigation commitment to its corresponding risk register entry and documented closure verification with timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-01-E5", "description": "deployment_gate_record confirming FRIA completion check was executed in the AI governance workflow and the gate was satisfied before production authorization was granted", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 27 directly mandates FRIA completion by deployers of high-risk AI systems, specifying the categories of fundamental rights that must be assessed. This control operationalizes that requirement through structured governance gates and assessment methodology. Non-compliance constitutes a regulatory violation subject to supervisory enforcement." } ] }, { "requirement_id": "EU-AIA-ART05-01h", "section": "Art. 5(1)(h)", "title": "Prohibited AI \u2014 facial recognition scraping", "text": "AI systems that create or expand facial recognition databases through the untargeted scraping of facial images from the internet or CCTV footage are prohibited.", "verdict": "partial", "coverage": "partial", "notes": "EF-05 covers the prohibition governance gate. DC-01 (Personal Data Inventory) and TG-03 (Data Rights, Lawful Authority and Permitted Use) require that all training data sources are inventoried and have documented lawful authority \u2014 scraping without authority would fail TG-03 gates. RT-05 (Data-loss prevention to agent egress) prevents agents from bulk-extracting biometric data. Partial: operational controls for scraping prevention (network-level blocking, web-facing API policies) are implementation-specific and extend beyond Apeiris's AI governance control plane.", "control_count": 4, "proof_chain": [ { "control": "apeiris://ethics/controls/EF-05", "id": "EF-05", "domain": "ethics", "name": "EU AI Act Prohibited Practices Governance (Art. 5)", "validation_objective": "Every AI system developed, deployed, or procured by the organization must have an Art. 5 screening record confirming evaluation against the current Prohibited Practices Register before intake resources were allocated. Any system that triggers a potential-match flag must have a formal Art. 5 Clearance determination with written legal opinion and ethics officer countersignature completed within 10 business days of the flag before any further development, deployment, or procurement proceeds.", "blocking_effect": "blocks-deployment", "evidence_required": [ "prohibited_practices_register document version-controlled with last_updated_date within 30 days of any EAIA or national supervisory authority Art. 5 guidance publication, mapping each Art. 5(1) prohibition to its definitional elements and organizational legal interpretation", "art_5_screening_record for each AI system in the intake registry, including screening_date, register_version_used, screener_identity, and screening_outcome (clear / potential-match / deferred)", "art_5_clearance_determination document for flagged systems including written_legal_opinion, ethics_officer_countersignature, determination_date within 10 business days of flag_date, and determination outcome (cleared / rejected)", "vendor_contract_art_5_compliance_provisions confirming Art. 5 compliance representations and audit rights in contracts for all AI system vendors", "annual_portfolio_audit_record showing Art. 5 re-screening completion date for all production systems against the current register version" ], "evidence": [ { "id": "EF-05-E1", "description": "prohibited_practices_register document version-controlled with last_updated_date within 30 days of any EAIA or national supervisory authority Art. 5 guidance publication, mapping each Art. 5(1) prohibition to its definitional elements and organizational legal interpretation", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-05-E2", "description": "art_5_screening_record for each AI system in the intake registry, including screening_date, register_version_used, screener_identity, and screening_outcome (clear / potential-match / deferred)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-05-E3", "description": "art_5_clearance_determination document for flagged systems including written_legal_opinion, ethics_officer_countersignature, determination_date within 10 business days of flag_date, and determination outcome (cleared / rejected)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-05-E4", "description": "vendor_contract_art_5_compliance_provisions confirming Art. 5 compliance representations and audit rights in contracts for all AI system vendors", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-05-E5", "description": "annual_portfolio_audit_record showing Art. 5 re-screening completion date for all production systems against the current register version", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "This control is specifically designed to operationalize EU AI Act Art. 5 prohibited practices compliance. Every element of the Prohibited Practices Register, screening process, and clearance determination is structured to demonstrate that the organization has implemented systematic controls to prevent deployment of Art. 5 prohibited systems." }, { "control": "apeiris://privacy/controls/DC-01", "id": "DC-01", "domain": "privacy", "name": "Personal Data Inventory", "validation_objective": "Every personal data category processed by AI systems must have a corresponding catalog entry with a documented lawful basis, originating source, and named data steward before that data is admitted to any training or inference pipeline. Pipeline admission gates must reject any training dataset or inference input referencing an unregistered data category.", "blocking_effect": "blocks-deployment", "evidence_required": [ "data_inventory_export \u2014 machine-readable export of all registered personal data categories with fields: data_type, lawful_basis_article, source_id, ai_processing_purpose, retention_schedule, and data_steward", "ropa_extract \u2014 GDPR Art 30 Records of Processing Activities countersigned by the DPO covering all AI system processing activities in the audit period", "pipeline_admission_gate_log \u2014 structured log showing dataset ID, inventory registration lookup result (pass/reject), and timestamp for every pipeline execution in the audit period", "data_flow_scan_report \u2014 automated scan output mapping all personal data ingestion paths to their inventory registration IDs with coverage percentage" ], "evidence": [ { "id": "DC-01-E1", "description": "data_inventory_export \u2014 machine-readable export of all registered personal data categories with fields: data_type, lawful_basis_article, source_id, ai_processing_purpose, retention_schedule, and data_steward", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "DC-01-E2", "description": "ropa_extract \u2014 GDPR Art 30 Records of Processing Activities countersigned by the DPO covering all AI system processing activities in the audit period", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "DC-01-E3", "description": "pipeline_admission_gate_log \u2014 structured log showing dataset ID, inventory registration lookup result (pass/reject), and timestamp for every pipeline execution in the audit period", "evidence_type": "audit-log", "verification": "automated" }, { "id": "DC-01-E4", "description": "data_flow_scan_report \u2014 automated scan output mapping all personal data ingestion paths to their inventory registration IDs with coverage percentage", "evidence_type": "automated-test-result", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://model/controls/TG-03", "id": "TG-03", "domain": "model", "name": "Data Rights, Lawful Authority and Permitted Use", "validation_objective": "For every dataset used in training, a specific and documented legal basis exists \u2014 identifying the consent mechanism, contractual right, statutory authority, or license entitlement that permits collection and use for the declared training purpose \u2014 and no training run may proceed on a dataset whose legal basis record is absent, expired, or jurisdiction-mismatched.", "blocking_effect": "blocks-deployment", "evidence_required": [ "data_rights_record for each training dataset specifying the legal basis type (consent, legitimate interest, contract, statutory authority, or license), the jurisdiction(s) covered, the permitted purpose scope, and any opt-out or withdrawal obligations", "purpose_limitation_compliance_record confirming that the declared training purpose falls within the scope of the legal basis established for the dataset, with documented mapping between use case and authorized purpose", "opt_out_enforcement_log showing that data subjects who exercised withdrawal or opt-out rights had their records removed from training datasets before any training run that included the affected dataset", "legal_basis_expiry_alert showing that datasets with time-limited legal bases (e.g., consents with expiry dates, contracts with end dates) are flagged for renewal review before expiry and blocked from training if the basis lapses" ], "evidence": [ { "id": "TG-03-E1", "description": "data_rights_record for each training dataset specifying the legal basis type (consent, legitimate interest, contract, statutory authority, or license), the jurisdiction(s) covered, the permitted purpose scope, and any opt-out or withdrawal obligations", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-03-E2", "description": "purpose_limitation_compliance_record confirming that the declared training purpose falls within the scope of the legal basis established for the dataset, with documented mapping between use case and authorized purpose", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-03-E3", "description": "opt_out_enforcement_log showing that data subjects who exercised withdrawal or opt-out rights had their records removed from training datasets before any training run that included the affected dataset", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-03-E4", "description": "legal_basis_expiry_alert showing that datasets with time-limited legal bases (e.g., consents with expiry dates, contracts with end dates) are flagged for renewal review before expiry and blocked from training if the basis lapses", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "DRR operationalizes EU AI Act data governance requirements for high-risk AI" }, { "control": "apeiris://security/controls/RT-05", "id": "RT-05", "domain": "security", "name": "Apply data-loss prevention to agent egress and interactions", "validation_objective": "A DLP engine must inspect all agent egress and interaction outputs in real time, blocking or redacting credentials, regulated data, and proprietary content before they cross the agent boundary. The engine must operate as a second enforcement layer behind network egress filtering, apply per-agent data class baselines, and maintain session logs of all blocked and redacted events tied to agent identity and session.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "dlp_event_log with entries for each inspection event showing agent_id, session_id, egress_content_class, dlp_match type, and redaction_action taken", "dlp_coverage_attestation confirming the engine is applied to all agent output channels \u2014 API responses, tool call results, and interaction outputs \u2014 not only file-transfer or email egress paths", "dlp_test_report showing a planted credential and a planted regulated data record were blocked or redacted when the agent attempted to emit them, with the events appearing in the event log", "data_class_policy_document mapping each agent to the set of data classes it is authorized to emit, used as the per-agent DLP baseline" ], "evidence": [ { "id": "RT-05-E1", "description": "dlp_event_log with entries for each inspection event showing agent_id, session_id, egress_content_class, dlp_match type, and redaction_action taken", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-05-E2", "description": "dlp_coverage_attestation confirming the engine is applied to all agent output channels \u2014 API responses, tool call results, and interaction outputs \u2014 not only file-transfer or email egress paths", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-05-E3", "description": "dlp_test_report showing a planted credential and a planted regulated data record were blocked or redacted when the agent attempted to emit them, with the events appearing in the event log", "evidence_type": "audit-log", "verification": "automated" }, { "id": "RT-05-E4", "description": "data_class_policy_document mapping each agent to the set of data classes it is authorized to emit, used as the per-agent DLP baseline", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "EU-AIA-ART09-01", "section": "Art. 9(1)", "title": "Risk management system \u2014 establishment and maintenance", "text": "A risk management system shall be established, implemented, documented and maintained in relation to high-risk AI systems throughout their entire lifecycle.", "verdict": "supported", "coverage": "direct", "notes": "PV-01 (Operating Intent Declaration) establishes the scope and intent boundary as the foundation of any risk management system. AG-03 (Agentic AI Risk Assessment Framework) provides the structured risk assessment methodology covering identification, likelihood, impact, and treatment decisions. RF-01 (EU AI Act High-Risk AI System Classification) maps the system to the high-risk category under Annex III to confirm scope. CG-01 (Compliance Governance Structure) embeds the risk management function within the organizational governance structure, ensuring it is maintained rather than performed once.", "control_count": 4, "proof_chain": [ { "control": "apeiris://authority/controls/PV-01", "id": "PV-01", "domain": "authority", "name": "Operating Intent Declaration", "validation_objective": "Every active AI system deployment must have a machine-readable, cryptographically signed intent declaration registered in the authority control registry before production activation. The deployment pipeline must block agent activation when no valid, unexpired declaration with all required schema fields is present.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Signed intent declaration artifact with canonical_id, authorized_action_types, context_scope, principal_id, valid_from, and valid_until fields for every active AI deployment", "Deployment gate rejection logs demonstrating that agent activations without a registered, unexpired declaration were blocked, with fields for system_id, attempted_at, and rejection_reason", "Authority control registry export cross-referencing each active deployment to its current declaration record and cryptographic signature", "Principal authorization verification record confirming the signing identity has organizational authority to bind the enterprise to the declared scope", "Renewal audit trail linking declaration version history to deployment lifecycle events and authorizing principal identity" ], "evidence": [ { "id": "PV-01-E1", "description": "Signed intent declaration artifact with canonical_id, authorized_action_types, context_scope, principal_id, valid_from, and valid_until fields for every active AI deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PV-01-E2", "description": "Deployment gate rejection logs demonstrating that agent activations without a registered, unexpired declaration were blocked, with fields for system_id, attempted_at, and rejection_reason", "evidence_type": "audit-log", "verification": "automated" }, { "id": "PV-01-E3", "description": "Authority control registry export cross-referencing each active deployment to its current declaration record and cryptographic signature", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "PV-01-E4", "description": "Principal authorization verification record confirming the signing identity has organizational authority to bind the enterprise to the declared scope", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PV-01-E5", "description": "Renewal audit trail linking declaration version history to deployment lifecycle events and authorizing principal identity", "evidence_type": "audit-log", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "The signed intent declaration is one input feeding a risk management system, not the full Art. 9 system." }, { "control": "apeiris://agentic/controls/AG-03", "id": "AG-03", "domain": "agentic", "name": "Agentic AI Risk Assessment Framework", "validation_objective": "Every production AI agent has a completed, current risk assessment evaluated against all five framework dimensions, with the resulting consequence tier documented and linked to the deployment approval and control mitigation plan.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "Annual risk reassessment records for all Critical-tier agents" ], "evidence": [ { "id": "AG-03-E1", "description": "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E2", "description": "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E3", "description": "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E4", "description": "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E5", "description": "Annual risk reassessment records for all Critical-tier agents", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 9 requires a documented risk management system with iterative risk identification and analysis, and Annex III defines high-risk classification criteria including autonomous decision-making systems. The framework's tier thresholds must align with these regulatory classification criteria to satisfy deployer obligations." }, { "control": "apeiris://compliance/controls/RF-01", "id": "RF-01", "domain": "compliance", "name": "EU AI Act High-Risk AI System Classification", "validation_objective": "Every AI system in the enterprise's development or production inventory must have a classification record in the EU AI Act classification register with a verdict (prohibited, high-risk, general-purpose, or not-in-scope), documented rationale citing the specific Annex III entries evaluated, a named classification owner, and legal counsel sign-off for all high-risk and borderline determinations. No system may be deployed without a classification record.", "blocking_effect": "blocks-deployment", "evidence_required": [ "EU AI Act classification register export with system_id, classification_verdict, annex_iii_entries_evaluated[], classification_owner, classification_date, and legal_sign_off_date for each system", "AI system inventory cross-reference report confirming coverage parity between the full system inventory and the classification register, with unexplained gaps listed as open findings", "Legal review opinion records for all high-risk and borderline classification decisions citing the specific Annex III category and classification rationale", "Re-evaluation trigger log showing change management events (model version, deployment domain, user population changes) linked to re-evaluation workflow initiations with response timestamps", "Annual classification review completion records for all systems confirming review occurred regardless of trigger events" ], "evidence": [ { "id": "RF-01-E1", "description": "EU AI Act classification register export with system_id, classification_verdict, annex_iii_entries_evaluated[], classification_owner, classification_date, and legal_sign_off_date for each system", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "RF-01-E2", "description": "AI system inventory cross-reference report confirming coverage parity between the full system inventory and the classification register, with unexplained gaps listed as open findings", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RF-01-E3", "description": "Legal review opinion records for all high-risk and borderline classification decisions citing the specific Annex III category and classification rationale", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RF-01-E4", "description": "Re-evaluation trigger log showing change management events (model version, deployment domain, user population changes) linked to re-evaluation workflow initiations with response timestamps", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "RF-01-E5", "description": "Annual classification review completion records for all systems confirming review occurred regardless of trigger events", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "Art. 6 establishes the classification rule for high-risk AI systems and cross-references Annex III, which enumerates the specific product and standalone AI system categories. Enterprises must determine whether their systems fall within these categories before any other conformity obligation applies." }, { "control": "apeiris://compliance/controls/CG-01", "id": "CG-01", "domain": "compliance", "name": "Compliance Governance Structure", "validation_objective": "The organization must have a formally chartered Compliance Committee with documented meeting minutes showing quorum was achieved in at least 80% of scheduled sessions in the last 12 months, a CCO or equivalent with a documented direct reporting channel to the board Audit and Risk Committee that bypasses management for material issues, and a current escalation matrix reviewed within 12 months covering all material compliance issue types including AI regulatory incidents.", "blocking_effect": "requires-review", "evidence_required": [ "compliance_committee_charter signed and approved by the board with defined membership composition, quorum rules, meeting cadence, decision authority scope, and AI regulatory obligation coverage", "cco_role_documentation including the CCO written authority scope, direct reporting line to the Audit and Risk Committee as documented in board resolution or equivalent formal governance instrument, and organizational chart placement", "compliance_committee_meeting_minutes for the last 12 months showing attendees, quorum status at each session, agenda items including AI compliance matters, and action item tracking with completion status", "escalation_matrix covering all material compliance issue types \u2014 regulatory inquiry, enforcement action, material AI risk event, data breach \u2014 with defined escalation paths, response timeframes, and responsible parties for each tier", "board_resolution or formal charter ratification record establishing the compliance governance structure with effective date and scope of authority" ], "evidence": [ { "id": "CG-01-E1", "description": "compliance_committee_charter signed and approved by the board with defined membership composition, quorum rules, meeting cadence, decision authority scope, and AI regulatory obligation coverage", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-01-E2", "description": "cco_role_documentation including the CCO written authority scope, direct reporting line to the Audit and Risk Committee as documented in board resolution or equivalent formal governance instrument, and organizational chart placement", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-01-E3", "description": "compliance_committee_meeting_minutes for the last 12 months showing attendees, quorum status at each session, agenda items including AI compliance matters, and action item tracking with completion status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-01-E4", "description": "escalation_matrix covering all material compliance issue types \u2014 regulatory inquiry, enforcement action, material AI risk event, data breach \u2014 with defined escalation paths, response timeframes, and responsible parties for each tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-01-E5", "description": "board_resolution or formal charter ratification record establishing the compliance governance structure with effective date and scope of authority", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 17 requires providers of high-risk AI systems to implement a quality management system that includes clear responsibilities, documented governance, and senior accountability. A formal compliance governance structure is the organizational prerequisite for meeting this article." } ] }, { "requirement_id": "EU-AIA-ART09-02", "section": "Art. 9(2)", "title": "Risk management \u2014 identification and analysis of known and reasonably foreseeable risks", "text": "The risk management system shall consist of a continuous iterative process identifying and analysing known and reasonably foreseeable risks to health, safety or fundamental rights associated with each high-risk AI system.", "verdict": "supported", "coverage": "direct", "notes": "AG-03 defines the risk identification and analysis methodology as a continuous, structured process updated on each deployment change. CA-06 (Compliance Obligation Gap Analysis) surfaces regulatory and rights-related risk gaps. PV-02 (Operating Intent Boundary Validation) continuously checks that system behavior stays within declared intent boundaries, catching drift-driven risk accumulation. HI-01 (Fundamental Rights Impact Assessment) formalizes the health, safety, and fundamental rights dimensions of risk analysis required by this article.", "control_count": 4, "proof_chain": [ { "control": "apeiris://agentic/controls/AG-03", "id": "AG-03", "domain": "agentic", "name": "Agentic AI Risk Assessment Framework", "validation_objective": "Every production AI agent has a completed, current risk assessment evaluated against all five framework dimensions, with the resulting consequence tier documented and linked to the deployment approval and control mitigation plan.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "Annual risk reassessment records for all Critical-tier agents" ], "evidence": [ { "id": "AG-03-E1", "description": "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E2", "description": "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E3", "description": "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E4", "description": "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E5", "description": "Annual risk reassessment records for all Critical-tier agents", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 9 requires a documented risk management system with iterative risk identification and analysis, and Annex III defines high-risk classification criteria including autonomous decision-making systems. The framework's tier thresholds must align with these regulatory classification criteria to satisfy deployer obligations." }, { "control": "apeiris://compliance/controls/CA-06", "id": "CA-06", "domain": "compliance", "name": "Compliance Obligation Gap Analysis", "validation_objective": "Gap analysis must be executed at least quarterly and within 10 business days following every update to the CA-02 obligation map or CA-03 routing table, producing a complete gap register that identifies every obligation in the CA-02 map without a functioning routing table entry, with every gap assigned an owner, severity, and target closure date that precedes the obligation's regulatory effective date.", "blocking_effect": "advisory", "evidence_required": [ "gap_analysis_run_record showing analysis_date, obligation_map_version, routing_table_version, total_obligations_analyzed, gaps_identified_count, analysis_trigger (scheduled or event-driven), and methodology_description", "gap_register entries for each open gap containing obligation_id, applicable_regime, normative_force, gap_severity, assigned_owner, target_closure_date, and escalation_status for high-severity binding-law items", "gap_closure_records showing each closed gap has a corresponding routing_table_entry_id and the entry resolves to a valid attestation confirmed post-closure, with validator_identity and confirmed_at timestamp", "binding_law_gap_escalation_records showing gaps with normative_force='binding-law' were escalated to legal_counsel and executive_leadership within the defined SLA after identification" ], "evidence": [ { "id": "CA-06-E1", "description": "gap_analysis_run_record showing analysis_date, obligation_map_version, routing_table_version, total_obligations_analyzed, gaps_identified_count, analysis_trigger (scheduled or event-driven), and methodology_description", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-06-E2", "description": "gap_register entries for each open gap containing obligation_id, applicable_regime, normative_force, gap_severity, assigned_owner, target_closure_date, and escalation_status for high-severity binding-law items", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-06-E3", "description": "gap_closure_records showing each closed gap has a corresponding routing_table_entry_id and the entry resolves to a valid attestation confirmed post-closure, with validator_identity and confirmed_at timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-06-E4", "description": "binding_law_gap_escalation_records showing gaps with normative_force='binding-law' were escalated to legal_counsel and executive_leadership within the defined SLA after identification", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "adjacent", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 9(2) requires the risk management system for high-risk AI systems to identify and analyze known and reasonably foreseeable risks. For compliance purposes, gaps in evidence coverage for Article 9 obligations represent known compliance risks that must be identified and addressed. CA-06's gap analysis ensures these compliance gaps are treated as risks requiring systematic remediation. The fit is adjacent because Article 9(2) addresses safety and rights risk identification while CA-06 addresses compliance control coverage gaps specifically." }, { "control": "apeiris://authority/controls/PV-02", "id": "PV-02", "domain": "authority", "name": "Operating Intent Boundary Validation", "validation_objective": "Every AI agent action must pass a pre-execution boundary check against the active intent declaration before being submitted to any downstream system. Actions exceeding declared action types, resource categories, or quantitative limits must be blocked and a structured violation event emitted; no out-of-scope action may complete execution before a human escalation is triggered.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "Boundary validation interceptor deployment manifest showing pre-execution positioning in the agent action dispatch layer, including component version, deployment_timestamp, and scope of coverage", "Boundary violation event log entries with structured fields: action_type, resource_target, declared_limit, observed_value, declaration_id, agent_id, and violation_timestamp", "Escalation workflow records confirming boundary violations reached a named human reviewer within the defined SLA, with time-from-violation and reviewer_id recorded", "Adversarial bypass test report confirming interceptor blocked actions submitted via direct API calls and parameter manipulation attempts" ], "evidence": [ { "id": "PV-02-E1", "description": "Boundary validation interceptor deployment manifest showing pre-execution positioning in the agent action dispatch layer, including component version, deployment_timestamp, and scope of coverage", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "PV-02-E2", "description": "Boundary violation event log entries with structured fields: action_type, resource_target, declared_limit, observed_value, declaration_id, agent_id, and violation_timestamp", "evidence_type": "audit-log", "verification": "automated" }, { "id": "PV-02-E3", "description": "Escalation workflow records confirming boundary violations reached a named human reviewer within the defined SLA, with time-from-violation and reviewer_id recorded", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PV-02-E4", "description": "Adversarial bypass test report confirming interceptor blocked actions submitted via direct API calls and parameter manipulation attempts", "evidence_type": "automated-test-result", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "Runtime boundary enforcement is a risk-mitigation action within a risk management system, not the whole Art. 9 system." }, { "control": "apeiris://ethics/controls/HI-01", "id": "HI-01", "domain": "ethics", "name": "Fundamental Rights Impact Assessment Content Governance", "validation_objective": "Every high-risk AI system subject to EU AI Act Art. 27 must have a completed FRIA with explicit impact ratings for all relevant EU Charter rights (Art. 1-54), documented population-level analysis for each protected group in scope, and signed ethics officer and legal counsel approval before production authorization is issued. No Annex III system may enter production without satisfying this gate.", "blocking_effect": "blocks-deployment", "evidence_required": [ "completed_fria document per high-risk AI system with explicit impact ratings (none/low/moderate/high/critical) for each EU Charter article, population-level analysis for all protected groups in scope, and documented mitigation for each impact rated moderate or higher", "fria_signoff_record showing ethics officer and legal counsel reviewer names, dates, and explicit production authorization confirmation for each high-risk system", "fria_registry showing version-controlled FRIA history per system with initial assessment date, reassessment dates triggered by material changes, and current version status", "mitigation_closure_evidence linking each FRIA-identified mitigation commitment to its corresponding risk register entry and documented closure verification with timestamp", "deployment_gate_record confirming FRIA completion check was executed in the AI governance workflow and the gate was satisfied before production authorization was granted" ], "evidence": [ { "id": "HI-01-E1", "description": "completed_fria document per high-risk AI system with explicit impact ratings (none/low/moderate/high/critical) for each EU Charter article, population-level analysis for all protected groups in scope, and documented mitigation for each impact rated moderate or higher", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-01-E2", "description": "fria_signoff_record showing ethics officer and legal counsel reviewer names, dates, and explicit production authorization confirmation for each high-risk system", "evidence_type": "human-review-record", "verification": "human" }, { "id": "HI-01-E3", "description": "fria_registry showing version-controlled FRIA history per system with initial assessment date, reassessment dates triggered by material changes, and current version status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-01-E4", "description": "mitigation_closure_evidence linking each FRIA-identified mitigation commitment to its corresponding risk register entry and documented closure verification with timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-01-E5", "description": "deployment_gate_record confirming FRIA completion check was executed in the AI governance workflow and the gate was satisfied before production authorization was granted", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 27 directly mandates FRIA completion by deployers of high-risk AI systems, specifying the categories of fundamental rights that must be assessed. This control operationalizes that requirement through structured governance gates and assessment methodology. Non-compliance constitutes a regulatory violation subject to supervisory enforcement." } ] }, { "requirement_id": "EU-AIA-ART09-03", "section": "Art. 9(3)", "title": "Risk management \u2014 residual risk estimation and evaluation", "text": "The risk management system shall involve evaluation of known and reasonably foreseeable risks that may emerge when the high-risk AI system is used in accordance with its intended purpose and under conditions of reasonably foreseeable misuse.", "verdict": "supported", "coverage": "direct", "notes": "AG-03 includes residual risk estimation and misuse scenario analysis as mandatory components of the risk assessment output. EV-09 (Risk and Applicability Classification) produces a structured risk classification covering both intended use and foreseeable misuse vectors. AS-01 (Adversarial red-team and evaluate the agent before launch) specifically tests misuse and abuse scenarios beyond the happy-path intended purpose. EV-03 (Dangerous Capability Threshold Assessment) evaluates whether system capabilities create residual risks above defined thresholds even under normal use.", "control_count": 4, "proof_chain": [ { "control": "apeiris://agentic/controls/AG-03", "id": "AG-03", "domain": "agentic", "name": "Agentic AI Risk Assessment Framework", "validation_objective": "Every production AI agent has a completed, current risk assessment evaluated against all five framework dimensions, with the resulting consequence tier documented and linked to the deployment approval and control mitigation plan.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "Annual risk reassessment records for all Critical-tier agents" ], "evidence": [ { "id": "AG-03-E1", "description": "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E2", "description": "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E3", "description": "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E4", "description": "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E5", "description": "Annual risk reassessment records for all Critical-tier agents", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 9 requires a documented risk management system with iterative risk identification and analysis, and Annex III defines high-risk classification criteria including autonomous decision-making systems. The framework's tier thresholds must align with these regulatory classification criteria to satisfy deployer obligations." }, { "control": "apeiris://model/controls/EV-09", "id": "EV-09", "domain": "model", "name": "Risk and Applicability Classification", "validation_objective": "Every model system has a signed classification record produced before any evaluation work begins, containing a documented EU AI Act classification with provision-specific rationale referencing Articles 5, 6, 50, 51, and Annex III as applicable, an SR 26-2 model risk tier for in-scope institutions, a capability tier, and the full applicable Apeiris profiles list; the model registry gate prevents advancement to evaluation stage without this record; and re-classification is triggered on any significant change to use case, capability level, or applicable regulation.", "blocking_effect": "blocks-deployment", "evidence_required": [ "signed_classification_record containing eu_ai_act_classification with specific provision references, sr_262_tier where applicable, capability_tier, applicable_profiles list, mandatory_controls inventory, and obligations_inventory \u2014 produced before any evaluation artifact is created", "classification_questionnaire_responses document answering all required dimensions: intended_use_cases, affected_populations, decision_automation_level, human_oversight_mechanisms, deployment_jurisdiction, compute_budget, parameter_count", "non_high_risk_exclusion_rationale for systems classified below high-risk, explicitly addressing each relevant Annex III category with documented rationale for exclusion", "classification_review_records for all re-classification events documenting trigger_event, prior_classification, new_classification, and rationale with effective_date", "iso_42005_impact_assessment for high-impact-decision and eu-high-risk profile systems per ISO/IEC 42005:2025" ], "evidence": [ { "id": "EV-09-E1", "description": "signed_classification_record containing eu_ai_act_classification with specific provision references, sr_262_tier where applicable, capability_tier, applicable_profiles list, mandatory_controls inventory, and obligations_inventory \u2014 produced before any evaluation artifact is created", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-09-E2", "description": "classification_questionnaire_responses document answering all required dimensions: intended_use_cases, affected_populations, decision_automation_level, human_oversight_mechanisms, deployment_jurisdiction, compute_budget, parameter_count", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E3", "description": "non_high_risk_exclusion_rationale for systems classified below high-risk, explicitly addressing each relevant Annex III category with documented rationale for exclusion", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E4", "description": "classification_review_records for all re-classification events documenting trigger_event, prior_classification, new_classification, and rationale with effective_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E5", "description": "iso_42005_impact_assessment for high-impact-decision and eu-high-risk profile systems per ISO/IEC 42005:2025", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act classification is a mandatory legal determination; this control operationalizes Articles 6, 51, and Annex III classification into a structured, documented process." }, { "control": "apeiris://security/controls/AS-01", "id": "AS-01", "domain": "security", "name": "Adversarially red-team and evaluate the agent before launch", "validation_objective": "Before any deployment to production, the agent must have passed a structured adversarial red-team exercise covering multi-turn goal hijack, tool misuse, and data exfiltration scenarios, with measured attack-success-rates at or below the defined launch threshold. Deployment must be blocked until the red-team pass/fail gate is cleared and documented.", "blocking_effect": "blocks-deployment", "evidence_required": [ "pre_launch_red_team_report listing each scenario (multi-turn hijack, tool-misuse, exfiltration), the attack-success-rate per scenario, the defined launch threshold, and a signed go/no-go decision", "multi_turn_eval_suite_run_log showing the agentic benchmark used (e.g., AgentDojo, FinBot CTF), commit SHA, run date, and overall pass/fail outcome against the threshold", "red_team_scope_document confirming coverage of multi-turn drift scenarios not only single-prompt tests, signed before the red-team exercise begins", "launch_gate_approval_record linking the red-team report to the deployment decision with approver identity and timestamp" ], "evidence": [ { "id": "AS-01-E1", "description": "pre_launch_red_team_report listing each scenario (multi-turn hijack, tool-misuse, exfiltration), the attack-success-rate per scenario, the defined launch threshold, and a signed go/no-go decision", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AS-01-E2", "description": "multi_turn_eval_suite_run_log showing the agentic benchmark used (e.g., AgentDojo, FinBot CTF), commit SHA, run date, and overall pass/fail outcome against the threshold", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "AS-01-E3", "description": "red_team_scope_document confirming coverage of multi-turn drift scenarios not only single-prompt tests, signed before the red-team exercise begins", "evidence_type": "red-team-report", "verification": "third-party" }, { "id": "AS-01-E4", "description": "launch_gate_approval_record linking the red-team report to the deployment decision with approver identity and timestamp", "evidence_type": "red-team-report", "verification": "third-party" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://model/controls/EV-03", "id": "EV-03", "domain": "model", "name": "Dangerous Capability Threshold Assessment", "validation_objective": "Every model at or near frontier capability has been assessed against the organization's applicable responsible scaling or capability policy thresholds for CBRN uplift, cyberweapon generation, autonomous AI R&D, and mass-influence operations before deployment authorization is granted. The safety committee has reviewed elicitation results and issued a signed deployment authorization for models below all thresholds; any model at or above threshold in any domain is not deployed pending safety committee escalation.", "blocking_effect": "blocks-deployment", "evidence_required": [ "scoping_determination_record for each evaluated model referencing the applicable capability policy (responsible scaling policy version or equivalent), with rationale for frontier-class determination including FLOPs estimate, capability benchmark scores, or elicitation pre-screen results", "capability_elicitation_results per domain (CBRN, cyberweapons, autonomous AI R&D, mass-influence operations) with methodology documentation, red-team evaluator identities, uplift elicitation protocol reference, and threshold comparison showing assessed level vs. defined threshold for each domain", "safety_committee_review_record with committee composition, deliberation notes, quorum confirmation, majority determination, any dissenting positions, and signed deployment_authorization or deployment_block decision", "EU_AI_Act_systemic_risk_classification_record for models meeting Art. 51 GPAI thresholds (\u226510\u00b2\u2075 FLOPs training compute or equivalent capability), documenting systemic risk determination and applicable GPAI obligations" ], "evidence": [ { "id": "EV-03-E1", "description": "scoping_determination_record for each evaluated model referencing the applicable capability policy (responsible scaling policy version or equivalent), with rationale for frontier-class determination including FLOPs estimate, capability benchmark scores, or elicitation pre-screen results", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-03-E2", "description": "capability_elicitation_results per domain (CBRN, cyberweapons, autonomous AI R&D, mass-influence operations) with methodology documentation, red-team evaluator identities, uplift elicitation protocol reference, and threshold comparison showing assessed level vs. defined threshold for each domain", "evidence_type": "red-team-report", "verification": "third-party" }, { "id": "EV-03-E3", "description": "safety_committee_review_record with committee composition, deliberation notes, quorum confirmation, majority determination, any dissenting positions, and signed deployment_authorization or deployment_block decision", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EV-03-E4", "description": "EU_AI_Act_systemic_risk_classification_record for models meeting Art. 51 GPAI thresholds (\u226510\u00b2\u2075 FLOPs training compute or equivalent capability), documenting systemic risk determination and applicable GPAI obligations", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "Art. 51 only classifies GPAI models as systemic-risk (including the 10^25 FLOP training-compute presumption); the substantive evaluation obligations attach under Art. 55 \u2014 model evaluation with adversarial testing, systemic-risk assessment and mitigation, and serious-incident reporting. EV-03's dangerous-capability assessment operationalizes the Art. 55 evaluation duty." } ] }, { "requirement_id": "EU-AIA-ART09-04", "section": "Art. 9(4)", "title": "Risk management \u2014 adoption of appropriate measures", "text": "Appropriate risk management measures shall be adopted, in particular as regards the risks referred to in paragraph 2, considering the effects and possible interactions resulting from the combination of requirements laid down in Articles 10 to 15.", "verdict": "supported", "coverage": "direct", "notes": "AG-03 requires risk treatment selection (accept, mitigate, transfer, avoid) with documented rationale for each identified risk. CA-02 (Compliance Framework Selection and Mapping) maps treatment measures to applicable regulatory obligations across Arts. 10-15, ensuring cross-requirement interaction effects are considered. PO-01 (Internal Policy Register for AI Deployments) translates risk treatment decisions into enforceable operational policies. CI-07 (Remediation Tracking and Closure) tracks measure implementation to verified completion.", "control_count": 4, "proof_chain": [ { "control": "apeiris://agentic/controls/AG-03", "id": "AG-03", "domain": "agentic", "name": "Agentic AI Risk Assessment Framework", "validation_objective": "Every production AI agent has a completed, current risk assessment evaluated against all five framework dimensions, with the resulting consequence tier documented and linked to the deployment approval and control mitigation plan.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "Annual risk reassessment records for all Critical-tier agents" ], "evidence": [ { "id": "AG-03-E1", "description": "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E2", "description": "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E3", "description": "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E4", "description": "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E5", "description": "Annual risk reassessment records for all Critical-tier agents", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 9 requires a documented risk management system with iterative risk identification and analysis, and Annex III defines high-risk classification criteria including autonomous decision-making systems. The framework's tier thresholds must align with these regulatory classification criteria to satisfy deployer obligations." }, { "control": "apeiris://compliance/controls/CA-02", "id": "CA-02", "domain": "compliance", "name": "Compliance Framework Selection and Mapping", "validation_objective": "Every AI system must have a current harmonized obligation map derived from the organizational framework catalog, with all applicable frameworks present at their current published versions and every framework requirement either mapped to an organizational control or explicitly flagged as a gap routed to the CA-06 backlog with a gap_id. No requirement may exist in the obligation map in an unmapped and unrouted state.", "blocking_effect": "blocks-deployment", "evidence_required": [ "framework_catalog showing each adopted framework with current_version, last_reviewed_on (within 60 days of current framework publication), and requirement_count", "harmonized_obligation_map for the AI system listing each requirement by framework_id and requirement_id, the mapped organizational control_id or gap_id, and a harmonization_group_id where multiple frameworks share one control", "cross_framework_harmonization_report documenting the count of requirements satisfied by shared controls and estimated evidence collection reduction as a percentage", "gap_routing_records for each unmapped requirement showing obligation_id, gap_id, routed_at timestamp, and assigned CA-06 backlog entry confirmation" ], "evidence": [ { "id": "CA-02-E1", "description": "framework_catalog showing each adopted framework with current_version, last_reviewed_on (within 60 days of current framework publication), and requirement_count", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-02-E2", "description": "harmonized_obligation_map for the AI system listing each requirement by framework_id and requirement_id, the mapped organizational control_id or gap_id, and a harmonization_group_id where multiple frameworks share one control", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-02-E3", "description": "cross_framework_harmonization_report documenting the count of requirements satisfied by shared controls and estimated evidence collection reduction as a percentage", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-02-E4", "description": "gap_routing_records for each unmapped requirement showing obligation_id, gap_id, routed_at timestamp, and assigned CA-06 backlog entry confirmation", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "adjacent", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 9(2) requires high-risk AI system providers to establish a risk management system that considers applicable harmonized standards and common specifications, which requires knowing which standards apply and how their requirements map to the provider's risk controls. CA-02's framework mapping process ensures that applicable harmonized standards are identified and their requirements tracked. The fit is adjacent because Article 9 addresses risk management rather than compliance framework administration directly." }, { "control": "apeiris://authority/controls/PO-01", "id": "PO-01", "domain": "authority", "name": "Internal Policy Register for AI Deployments", "validation_objective": "Every active AI deployment must have at least one current, non-expired policy register entry in the authoritative policy register, and that entry must contain version, effective date, scope, owning team, and deployment linkage fields. No AI deployment may enter or remain in production without a valid policy register reference confirmed by the deployment pipeline.", "blocking_effect": "blocks-deployment", "evidence_required": [ "policy_register_schema_document specifying required fields including policy_id, version, effective_date, expiry_date, owning_team, ai_deployment_scope, and authority_domain_applicability", "deployment_policy_linkage_audit_log confirming every active AI deployment has a corresponding current policy register entry with a non-expired effective date", "policy_register_access_control_matrix demonstrating that register modifications require dual authorization and all changes are attributed and logged", "deployment_pipeline_gate_configuration showing that AI deployment approval workflows validate the presence of a current policy register entry before proceeding" ], "evidence": [ { "id": "PO-01-E1", "description": "policy_register_schema_document specifying required fields including policy_id, version, effective_date, expiry_date, owning_team, ai_deployment_scope, and authority_domain_applicability", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-01-E2", "description": "deployment_policy_linkage_audit_log confirming every active AI deployment has a corresponding current policy register entry with a non-expired effective date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-01-E3", "description": "policy_register_access_control_matrix demonstrating that register modifications require dual authorization and all changes are attributed and logged", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-01-E4", "description": "deployment_pipeline_gate_configuration showing that AI deployment approval workflows validate the presence of a current policy register entry before proceeding", "evidence_type": "human-review-record", "verification": "human" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://compliance/controls/CI-07", "id": "CI-07", "domain": "compliance", "name": "Remediation Tracking and Closure", "validation_objective": "Every compliance gap identified by control testing (CI-01), monitoring (CI-02), or internal audit (CI-06) has a corresponding remediation ticket with an assigned single owner, target date, documented root cause, remediation plan, and independently verified closure evidence. No critical-severity ticket is open beyond 15 business days without a documented executive escalation record.", "blocking_effect": "requires-review", "evidence_required": [ "Remediation register export listing all open and closed tickets with source_control, severity, assigned_owner, root_cause, remediation_plan, target_date, and actual_closure_date for the full audit period", "Closure verification records for each high and critical ticket documenting the independent verifier identity, verification method (re-test, configuration check, or re-assessment), and verification outcome", "Automated escalation log showing escalation trigger events and management acknowledgment timestamps for all overdue items during the period", "Recurrence analysis report identifying any finding appearing in both the current and prior audit cycle, with root cause explanation for recurrence", "Weekly remediation velocity reports showing open ticket counts by severity and age distribution across the audit period" ], "evidence": [ { "id": "CI-07-E1", "description": "Remediation register export listing all open and closed tickets with source_control, severity, assigned_owner, root_cause, remediation_plan, target_date, and actual_closure_date for the full audit period", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "CI-07-E2", "description": "Closure verification records for each high and critical ticket documenting the independent verifier identity, verification method (re-test, configuration check, or re-assessment), and verification outcome", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "CI-07-E3", "description": "Automated escalation log showing escalation trigger events and management acknowledgment timestamps for all overdue items during the period", "evidence_type": "audit-log", "verification": "automated" }, { "id": "CI-07-E4", "description": "Recurrence analysis report identifying any finding appearing in both the current and prior audit cycle, with root cause explanation for recurrence", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-07-E5", "description": "Weekly remediation velocity reports showing open ticket counts by severity and age distribution across the audit period", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 20 requires providers of high-risk AI systems to undertake corrective actions when their systems do not conform to the requirements of the Act. The CI-07 remediation tracking system provides the documented corrective action evidence required to demonstrate compliance with this obligation to market surveillance authorities." } ] }, { "requirement_id": "EU-AIA-ART09-05", "section": "Art. 9(5)", "title": "Risk management \u2014 testing for most appropriate measures", "text": "High-risk AI systems shall be tested for the purpose of identifying the most appropriate and targeted risk management measures. Testing shall ensure that high-risk AI systems perform consistently for their intended purpose and that they are compliant with the requirements set out in this Section.", "verdict": "supported", "coverage": "direct", "notes": "EV-01 (Pre-Deployment Evaluation Gate) is a mandatory test gate that must be passed before deployment, covering consistency with intended purpose. EV-04 (Adversarial Red-Team Testing) tests that risk management measures hold under adversarial conditions. AS-01 (Red-team and evaluate before launch) provides the agentic variant of this requirement. EV-07 (Regression Testing on Updates) ensures that risk management measure effectiveness is re-verified on every system change.", "control_count": 4, "proof_chain": [ { "control": "apeiris://model/controls/EV-01", "id": "EV-01", "domain": "model", "name": "Pre-Deployment Evaluation Gate", "validation_objective": "No model artifact is promoted to production unless a signed evaluation manifest referencing that artifact's exact hash is present in the tamper-evident evaluation log and has received dual approval from named, authorized approvers. The deployment pipeline enforces this as a cryptographic gate \u2014 an absent, unsigned, or hash-mismatched manifest results in an automatic pipeline block with no override path except a logged exception with named risk-accepter.", "blocking_effect": "blocks-deployment", "evidence_required": [ "signed_evaluation_manifest with model_artifact_hash, evaluation_suite_version, evaluator_identities, per-dimension pass/fail outcome, signing_key_id, and manifest_signature (Ed25519) for every production model version", "tamper_evident_evaluation_log entry linking manifest_id to model_artifact_hash, recording append timestamp, appender identity, and log integrity proof", "dual_approval_record with two named approver identities, their organizational roles, approval timestamps, and the manifest_hash each approver authorized", "pipeline_execution_log showing at least one successful gate enforcement event: a deployment attempt with an absent or invalid manifest that was blocked, confirming the gate is operational rather than advisory" ], "evidence": [ { "id": "EV-01-E1", "description": "signed_evaluation_manifest with model_artifact_hash, evaluation_suite_version, evaluator_identities, per-dimension pass/fail outcome, signing_key_id, and manifest_signature (Ed25519) for every production model version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-01-E2", "description": "tamper_evident_evaluation_log entry linking manifest_id to model_artifact_hash, recording append timestamp, appender identity, and log integrity proof", "evidence_type": "audit-log", "verification": "automated" }, { "id": "EV-01-E3", "description": "dual_approval_record with two named approver identities, their organizational roles, approval timestamps, and the manifest_hash each approver authorized", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EV-01-E4", "description": "pipeline_execution_log showing at least one successful gate enforcement event: a deployment attempt with an absent or invalid manifest that was blocked, confirming the gate is operational rather than advisory", "evidence_type": "configuration-snapshot", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "Art. 9 mandates testing and evaluation as part of the risk management system for high-risk AI systems before market placement." }, { "control": "apeiris://model/controls/EV-04", "id": "EV-04", "domain": "model", "name": "Adversarial Red-Team Testing", "validation_objective": "The model system has a signed red-team report produced by a team organizationally independent of model development, documenting structured adversarial probing that covers all required attack categories for the applicable profiles, with all critical and high findings remediated and re-tested before the deployment gate clears.", "blocking_effect": "blocks-deployment", "evidence_required": [ "signed_red_team_scope_document with threat_model version, profile scope, and pre-exercise approval timestamp", "red_team_findings_log with finding_id, severity_classification, reproduction_steps, affected_population, and remediation_status per finding", "signed_red_team_report with residual_risk_statement linked to model artifact hash and listing remediated critical and high findings with re-test results", "remediation_evidence for all critical and high findings demonstrating the vulnerability is closed via re-test, not only via input-level patch", "for frontier-capability profile: escalation_records for any capability elicited at or near threshold levels with escalation_destination and response_action" ], "evidence": [ { "id": "EV-04-E1", "description": "signed_red_team_scope_document with threat_model version, profile scope, and pre-exercise approval timestamp", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EV-04-E2", "description": "red_team_findings_log with finding_id, severity_classification, reproduction_steps, affected_population, and remediation_status per finding", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-04-E3", "description": "signed_red_team_report with residual_risk_statement linked to model artifact hash and listing remediated critical and high findings with re-test results", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "EV-04-E4", "description": "remediation_evidence for all critical and high findings demonstrating the vulnerability is closed via re-test, not only via input-level patch", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "EV-04-E5", "description": "for frontier-capability profile: escalation_records for any capability elicited at or near threshold levels with escalation_destination and response_action", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "Art. 55(1)(a) requires providers of GPAI models with systemic risk to conduct adversarial testing prior to deployment." }, { "control": "apeiris://security/controls/AS-01", "id": "AS-01", "domain": "security", "name": "Adversarially red-team and evaluate the agent before launch", "validation_objective": "Before any deployment to production, the agent must have passed a structured adversarial red-team exercise covering multi-turn goal hijack, tool misuse, and data exfiltration scenarios, with measured attack-success-rates at or below the defined launch threshold. Deployment must be blocked until the red-team pass/fail gate is cleared and documented.", "blocking_effect": "blocks-deployment", "evidence_required": [ "pre_launch_red_team_report listing each scenario (multi-turn hijack, tool-misuse, exfiltration), the attack-success-rate per scenario, the defined launch threshold, and a signed go/no-go decision", "multi_turn_eval_suite_run_log showing the agentic benchmark used (e.g., AgentDojo, FinBot CTF), commit SHA, run date, and overall pass/fail outcome against the threshold", "red_team_scope_document confirming coverage of multi-turn drift scenarios not only single-prompt tests, signed before the red-team exercise begins", "launch_gate_approval_record linking the red-team report to the deployment decision with approver identity and timestamp" ], "evidence": [ { "id": "AS-01-E1", "description": "pre_launch_red_team_report listing each scenario (multi-turn hijack, tool-misuse, exfiltration), the attack-success-rate per scenario, the defined launch threshold, and a signed go/no-go decision", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AS-01-E2", "description": "multi_turn_eval_suite_run_log showing the agentic benchmark used (e.g., AgentDojo, FinBot CTF), commit SHA, run date, and overall pass/fail outcome against the threshold", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "AS-01-E3", "description": "red_team_scope_document confirming coverage of multi-turn drift scenarios not only single-prompt tests, signed before the red-team exercise begins", "evidence_type": "red-team-report", "verification": "third-party" }, { "id": "AS-01-E4", "description": "launch_gate_approval_record linking the red-team report to the deployment decision with approver identity and timestamp", "evidence_type": "red-team-report", "verification": "third-party" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://model/controls/EV-07", "id": "EV-07", "domain": "model", "name": "Regression Testing on Updates", "validation_objective": "Every model update \u2014 including fine-tunes, RLHF updates, guardrail changes, serving-framework changes, and quantization changes \u2014 triggers a full regression evaluation against a signed baseline before promotion; safety_regression_rate is zero-tolerance with any non-zero value producing an automatic blocking finding; and capability_regression_rate exceeding the defined threshold blocks promotion unless a signed risk-acceptance record is present.", "blocking_effect": "blocks-deployment", "evidence_required": [ "versioned_regression_suite_artifact with signed hash covering safety scenarios, alignment/refusal scenarios for generative-ai profile, and failure modes documented in prior red-team exercises", "signed_regression_manifest for each update event linking updated_model_artifact_hash, baseline_artifact_hash, regression_suite_version, run_timestamp, and per-metric regression_results including safety_regression_rate and capability_regression_rate", "signed_baseline_evaluation_results for the production model version serving as the regression reference, version-locked before the update is applied", "blocking_record for any regression finding including root_cause_analysis for safety regressions and proposed remediation with estimated completion date", "risk_acceptance_record for any sub-threshold capability regression finding with explicit rationale, accepting_authority identity, and time_bound_remediation_commitment" ], "evidence": [ { "id": "EV-07-E1", "description": "versioned_regression_suite_artifact with signed hash covering safety scenarios, alignment/refusal scenarios for generative-ai profile, and failure modes documented in prior red-team exercises", "evidence_type": "red-team-report", "verification": "third-party" }, { "id": "EV-07-E2", "description": "signed_regression_manifest for each update event linking updated_model_artifact_hash, baseline_artifact_hash, regression_suite_version, run_timestamp, and per-metric regression_results including safety_regression_rate and capability_regression_rate", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-07-E3", "description": "signed_baseline_evaluation_results for the production model version serving as the regression reference, version-locked before the update is applied", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-07-E4", "description": "blocking_record for any regression finding including root_cause_analysis for safety regressions and proposed remediation with estimated completion date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-07-E5", "description": "risk_acceptance_record for any sub-threshold capability regression finding with explicit rationale, accepting_authority identity, and time_bound_remediation_commitment", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "Art. 9(4) requires the risk management system to be updated when the AI system is modified; regression testing operationalizes this for model updates." } ] }, { "requirement_id": "EU-AIA-ART09-06", "section": "Art. 9(6)", "title": "Risk management \u2014 testing against prior defined metrics and probabilistic thresholds", "text": "Testing of high-risk AI systems shall be performed, as appropriate, at any point in time during the development process, and, in any event, prior to placing on the market or putting into service. Testing shall be performed against prior defined metrics and probabilistic thresholds that are appropriate to the intended purpose.", "verdict": "supported", "coverage": "direct", "notes": "EV-02 (Fitness, Safety, Reliability and Policy-Conformance Evaluation) requires pre-defined performance metrics and pass/fail thresholds declared before evaluation begins. EV-06 (Reproducible Evaluation Design) enforces that metric definitions, test sets, and threshold criteria are fixed prior to evaluation execution \u2014 preventing post-hoc metric selection. EV-05 (Fairness and Bias Evaluation) applies probabilistic fairness thresholds appropriate to the demographic context of the intended purpose. BH-01 (Output Anomaly Detection) provides continuous metric monitoring in production to verify thresholds are maintained over time.", "control_count": 4, "proof_chain": [ { "control": "apeiris://model/controls/EV-02", "id": "EV-02", "domain": "model", "name": "Fitness, Safety, Reliability and Policy-Conformance Evaluation", "validation_objective": "Before deployment, every model has been evaluated against pre-specified, dimension-level pass/fail thresholds \u2014 fitness, safety, reliability, and policy-conformance \u2014 with results documented against the model artifact hash and evaluation suite version. No threshold is modified after evaluation begins, and any threshold trade-off decision is documented as a named risk-acceptance record before the deployment manifest is signed.", "blocking_effect": "blocks-deployment", "evidence_required": [ "pre_specified_evaluation_protocol with model_artifact_hash, evaluation_suite_version, and per-dimension thresholds (fitness accuracy target, safety refusal rate, reliability error budget, policy-conformance violation rate), signed by the evaluation lead before testing begins \u2014 not after results are known", "dimension_level_evaluation_results showing per-dimension metric values, pass/fail verdict against pre-specified threshold, and model_artifact_hash confirming results correspond to the evaluated version", "evaluation_suite_provenance_record confirming that evaluation datasets are disjoint from training data, with contamination-check reference to TG-05 attestation", "risk_acceptance_record for any dimension where the pass threshold was not met but deployment was authorized, documenting named risk-accepter, specific capability gap, deployment risk consequence, and remediation deadline" ], "evidence": [ { "id": "EV-02-E1", "description": "pre_specified_evaluation_protocol with model_artifact_hash, evaluation_suite_version, and per-dimension thresholds (fitness accuracy target, safety refusal rate, reliability error budget, policy-conformance violation rate), signed by the evaluation lead before testing begins \u2014 not after results are known", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-02-E2", "description": "dimension_level_evaluation_results showing per-dimension metric values, pass/fail verdict against pre-specified threshold, and model_artifact_hash confirming results correspond to the evaluated version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-02-E3", "description": "evaluation_suite_provenance_record confirming that evaluation datasets are disjoint from training data, with contamination-check reference to TG-05 attestation", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-02-E4", "description": "risk_acceptance_record for any dimension where the pass threshold was not met but deployment was authorized, documenting named risk-accepter, specific capability gap, deployment risk consequence, and remediation deadline", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "Art. 9(5) requires testing against defined metrics and probabilistic thresholds; Art. 9(6) requires accuracy, robustness, and cybersecurity evaluation for high-risk systems." }, { "control": "apeiris://model/controls/EV-06", "id": "EV-06", "domain": "model", "name": "Reproducible Evaluation Design", "validation_objective": "Every evaluation run against a model artifact can be independently reproduced from the evaluation design document alone within the defined tolerance by a party who was not involved in the original run; all benchmarks have documented contamination screening results; and all evaluation artifacts are signed with SHA-256 content-addressed hashes recorded in the evaluation manifest.", "blocking_effect": "blocks-deployment", "evidence_required": [ "version_controlled_benchmark_selection_document with pre-specified selection_criteria, benchmark_ids, known_limitations, and alternatives_considered \u2014 signed and committed before any evaluation run begins", "contamination_screening_report documenting screening_methodology, training_corpus_reference, per-benchmark contamination_result (clean/flagged/excluded), and screening_date", "evaluation_design_document capturing all reproduction parameters: random_seeds, software_dependency_versions with hashes, hardware_configuration, serving_framework_config, eval_script_version_and_hash, prompt_templates, and post_processing_steps", "independent_reproduction_run_record showing reproduction_results within the defined tolerance alongside original_results, confirming design document sufficiency for independent replication", "signed_evaluation_artifact_manifest listing SHA-256 hashes for all artifacts (design document, scripts, datasets, results) with signer_identity and key_identifier" ], "evidence": [ { "id": "EV-06-E1", "description": "version_controlled_benchmark_selection_document with pre-specified selection_criteria, benchmark_ids, known_limitations, and alternatives_considered \u2014 signed and committed before any evaluation run begins", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-06-E2", "description": "contamination_screening_report documenting screening_methodology, training_corpus_reference, per-benchmark contamination_result (clean/flagged/excluded), and screening_date", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-06-E3", "description": "evaluation_design_document capturing all reproduction parameters: random_seeds, software_dependency_versions with hashes, hardware_configuration, serving_framework_config, eval_script_version_and_hash, prompt_templates, and post_processing_steps", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-06-E4", "description": "independent_reproduction_run_record showing reproduction_results within the defined tolerance alongside original_results, confirming design document sufficiency for independent replication", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-06-E5", "description": "signed_evaluation_artifact_manifest listing SHA-256 hashes for all artifacts (design document, scripts, datasets, results) with signer_identity and key_identifier", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "Art. 9(5) requires testing procedures to be documented; reproducible design operationalizes this requirement." }, { "control": "apeiris://model/controls/EV-05", "id": "EV-05", "domain": "model", "name": "Fairness and Bias Evaluation", "validation_objective": "The model system has a documented, pre-specified fairness evaluation protocol executed on data disjoint from training data, with disaggregated results per population group and harm type measured against pre-specified acceptance thresholds, and legal review obtained for any deployment affecting legally protected characteristics.", "blocking_effect": "blocks-deployment", "evidence_required": [ "fairness_evaluation_protocol document with pre-specified population_groups, harm_types, metric_selections, selection_rationale, legal_basis, and acceptance_thresholds \u2014 version-controlled and signed before any evaluation run begins", "disaggregated_evaluation_results report showing per-group performance metrics independently for each identified population group, with group_id, sample_count, and metric_values per harm type", "metric_tradeoff_decision_record explicitly stating which competing fairness constraints (e.g., demographic parity vs. equalized odds) take precedence for this deployment context and the documented rationale", "evaluation_data_disjointness_attestation confirming evaluation data for each population group does not overlap with the training corpus, with data_source_ids and overlap_check_method documented", "legal_review_record for any deployment affecting legally protected characteristics, with reviewing_authority identity and review_date" ], "evidence": [ { "id": "EV-05-E1", "description": "fairness_evaluation_protocol document with pre-specified population_groups, harm_types, metric_selections, selection_rationale, legal_basis, and acceptance_thresholds \u2014 version-controlled and signed before any evaluation run begins", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-05-E2", "description": "disaggregated_evaluation_results report showing per-group performance metrics independently for each identified population group, with group_id, sample_count, and metric_values per harm type", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-05-E3", "description": "metric_tradeoff_decision_record explicitly stating which competing fairness constraints (e.g., demographic parity vs. equalized odds) take precedence for this deployment context and the documented rationale", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-05-E4", "description": "evaluation_data_disjointness_attestation confirming evaluation data for each population group does not overlap with the training corpus, with data_source_ids and overlap_check_method documented", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-05-E5", "description": "legal_review_record for any deployment affecting legally protected characteristics, with reviewing_authority identity and review_date", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "Art. 9(7) requires high-risk AI systems to be tested for non-discrimination; Annex III identifies categories where fairness failures are particularly high-risk." }, { "control": "apeiris://model/controls/BH-01", "id": "BH-01", "domain": "model", "name": "Output Anomaly Detection", "validation_objective": "The production inference endpoint must be continuously sampled and output distributions must be statistically compared against a versioned, SHA-256-signed baseline artifact using PSI and Shewhart/EWMA control chart methods, such that any distribution shift exceeding PSI 0.2 fires a tiered alert within one monitoring window of the shift occurring and all anomaly events are stored in the evidence registry with BH-01 control linkage.", "blocking_effect": "advisory", "evidence_required": [ "versioned, SHA-256-signed baseline distribution artifact stored in the model registry with per-metric statistics (mean, std_dev, p5/p50/p95/p99) computed from the 30-day post-deployment stable window", "SPC alert log for trailing 90 days with fields: alert_id, trigger_metric, psi_value, alert_severity, triggered_at, acknowledged_at, and resolution_outcome", "PII masking audit record confirming no direct identifier fields (email, SSN, full name) appear in the sampled output storage for the trailing 30 days", "quarterly threshold review sign-off from model owner confirming PSI alert (0.2) and critical (0.25) thresholds remain appropriate for the current deployment context" ], "evidence": [ { "id": "BH-01-E1", "description": "versioned, SHA-256-signed baseline distribution artifact stored in the model registry with per-metric statistics (mean, std_dev, p5/p50/p95/p99) computed from the 30-day post-deployment stable window", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-01-E2", "description": "SPC alert log for trailing 90 days with fields: alert_id, trigger_metric, psi_value, alert_severity, triggered_at, acknowledged_at, and resolution_outcome", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "BH-01-E3", "description": "PII masking audit record confirming no direct identifier fields (email, SSN, full name) appear in the sampled output storage for the trailing 30 days", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-01-E4", "description": "quarterly threshold review sign-off from model owner confirming PSI alert (0.2) and critical (0.25) thresholds remain appropriate for the current deployment context", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 15 requires high-risk AI systems to achieve an appropriate level of accuracy, robustness and cybersecurity; BH-01's statistical process control and PSI-based output anomaly detection directly supports the robustness dimension by detecting production anomalies before they cause downstream harm." } ] }, { "requirement_id": "EU-AIA-ART09-07", "section": "Art. 9(7)", "title": "Risk management \u2014 measures for particularly vulnerable groups", "text": "When identifying the most appropriate risk management measures, due consideration shall be given to whether the intended purpose of the high-risk AI system involves natural persons who are particularly vulnerable, in particular children.", "verdict": "supported", "coverage": "direct", "notes": "HI-03 (Vulnerable Population Protection) requires explicit identification of vulnerable groups in the intended user population and mandates heightened controls for systems affecting those groups. HI-07 (Child and Minors Safety Controls) provides specific control requirements for systems accessible to or intended for minors, including interaction design constraints and parental/guardian notification. FA-07 (Bias Remediation Governance) ensures that disproportionate impact on vulnerable groups identified in testing triggers mandatory remediation before deployment. AG-03 includes vulnerable-group consideration as a mandatory dimension of the risk assessment.", "control_count": 4, "proof_chain": [ { "control": "apeiris://ethics/controls/HI-03", "id": "HI-03", "domain": "ethics", "name": "Vulnerable Population Protection", "validation_objective": "Every AI system in production must have a completed vulnerability impact screening record identifying which vulnerable population categories are in scope, their exposure frequency, and the resulting vulnerability risk score. All systems scoring above the defined threshold must have documented and verified enhanced safeguards implemented, and user testing results from representative vulnerable population participants must be on file prior to deployment and refreshed within 12 months.", "blocking_effect": "blocks-deployment", "evidence_required": [ "vulnerability_impact_screening_record per AI system listing all vulnerable population categories assessed, exposure frequency estimates, vulnerability risk score, and scoring rationale, with completion date before initial deployment", "enhanced_safeguard_implementation_record for each system scoring above the vulnerability risk threshold, documenting each required safeguard (simplified language options, WCAG 2.1 AA compliance, human review gates for high-stakes decisions, crisis detection and escalation pathways) with implementation verification evidence", "user_testing_results from sessions conducted with representative members of each identified vulnerable population category including comprehension scores, consent quality observations, and rights-exercise assessments", "model_performance_disaggregation_report showing evaluation metrics separately for each vulnerable population category with identified performance gaps and applied bias mitigation measures", "wcag_compliance_audit_report for all user-facing interfaces confirming WCAG 2.1 AA conformance or documenting known exceptions with assigned remediation timelines" ], "evidence": [ { "id": "HI-03-E1", "description": "vulnerability_impact_screening_record per AI system listing all vulnerable population categories assessed, exposure frequency estimates, vulnerability risk score, and scoring rationale, with completion date before initial deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-03-E2", "description": "enhanced_safeguard_implementation_record for each system scoring above the vulnerability risk threshold, documenting each required safeguard (simplified language options, WCAG 2.1 AA compliance, human review gates for high-stakes decisions, crisis detection and escalation pathways) with implementation verification evidence", "evidence_type": "human-review-record", "verification": "human" }, { "id": "HI-03-E3", "description": "user_testing_results from sessions conducted with representative members of each identified vulnerable population category including comprehension scores, consent quality observations, and rights-exercise assessments", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-03-E4", "description": "model_performance_disaggregation_report showing evaluation metrics separately for each vulnerable population category with identified performance gaps and applied bias mitigation measures", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "HI-03-E5", "description": "wcag_compliance_audit_report for all user-facing interfaces confirming WCAG 2.1 AA conformance or documenting known exceptions with assigned remediation timelines", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 9(2)(b) explicitly requires that risk management measures account for the reasonably foreseeable misuse and the heightened vulnerability of specific groups, including children and persons with disabilities. This control operationalizes that requirement through structured vulnerability screening and proportionate safeguard implementation." }, { "control": "apeiris://ethics/controls/HI-07", "id": "HI-07", "domain": "ethics", "name": "Child and Minors Safety Controls", "validation_objective": "Every AI system with a child exposure classification above the minimum threshold must have documented age-appropriate design controls implemented, active CSAM detection safeguards validated through testing, and a signed child safety review completed before deployment. A passing state requires 100% of generative AI systems to have active CSAM detection instrumentation and zero above-threshold systems deployed without a dated, signed child safety review record.", "blocking_effect": "blocks-deployment", "evidence_required": [ "child_exposure_assessment_record for each AI system showing estimated minor user percentage based on empirical data, classification tier, assessment methodology, and assessment date within the past 12 months", "age_appropriate_design_control_manifest per above-threshold system listing content filter calibration level (youngest likely user cohort), prohibited engagement mechanics inventory, and parental oversight pathway URL", "CSAM_detection_safeguard_validation_record confirming detection mechanisms are active and have been tested against synthetic prohibited content test cases with zero false negatives and documented true positive rates", "child_safety_review_sign_off record with reviewer identity, developmental psychologist consultation reference or report, approval date predating the system's production deployment date, and any open findings with remediation status" ], "evidence": [ { "id": "HI-07-E1", "description": "child_exposure_assessment_record for each AI system showing estimated minor user percentage based on empirical data, classification tier, assessment methodology, and assessment date within the past 12 months", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-07-E2", "description": "age_appropriate_design_control_manifest per above-threshold system listing content filter calibration level (youngest likely user cohort), prohibited engagement mechanics inventory, and parental oversight pathway URL", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-07-E3", "description": "CSAM_detection_safeguard_validation_record confirming detection mechanisms are active and have been tested against synthetic prohibited content test cases with zero false negatives and documented true positive rates", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "HI-07-E4", "description": "child_safety_review_sign_off record with reviewer identity, developmental psychologist consultation reference or report, approval date predating the system's production deployment date, and any open findings with remediation status", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 5(1)(a) prohibits AI systems that deploy subliminal or manipulative techniques, with heightened application to systems targeting minors. The control's prohibition on manipulative engagement mechanics targeting children directly implements this provision." }, { "control": "apeiris://ethics/controls/FA-07", "id": "FA-07", "domain": "ethics", "name": "Bias Remediation Governance", "validation_objective": "The organization's Bias Remediation Governance Process (BRGP) is documented, operational, and demonstrably functions: every bias finding is classified by severity, escalated within defined SLAs, assigned to a remediation owner, resolved through a verified fix, and closed only after a verification re-test confirms resolution without introducing new disparities.", "blocking_effect": "requires-review", "evidence_required": [ "bias_finding_register with fields: finding_id, severity_class, escalation_timestamp, escalation_target, remediation_owner, remediation_method, verification_retest_result, and closure_timestamp for each finding", "escalation_audit_log showing timestamped escalation events for each critical and high finding with receiving party and resolution pathway", "remediation_verification_report per closed finding, including re-test results on held-out verification dataset and confirmation that no new disparities were introduced on other protected characteristics", "root_cause_analysis_document for each critical and high finding, including structural corrective actions approved by the ethics officer", "ethics_review_board_minutes showing board convened within required cadence with attendance record, findings reviewed, and decisions made" ], "evidence": [ { "id": "FA-07-E1", "description": "bias_finding_register with fields: finding_id, severity_class, escalation_timestamp, escalation_target, remediation_owner, remediation_method, verification_retest_result, and closure_timestamp for each finding", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-07-E2", "description": "escalation_audit_log showing timestamped escalation events for each critical and high finding with receiving party and resolution pathway", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-07-E3", "description": "remediation_verification_report per closed finding, including re-test results on held-out verification dataset and confirmation that no new disparities were introduced on other protected characteristics", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "FA-07-E4", "description": "root_cause_analysis_document for each critical and high finding, including structural corrective actions approved by the ethics officer", "evidence_type": "human-review-record", "verification": "human" }, { "id": "FA-07-E5", "description": "ethics_review_board_minutes showing board convened within required cadence with attendance record, findings reviewed, and decisions made", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 9(1) requires a risk management system that includes ongoing risk control measures throughout the AI system lifecycle. The BRGP is the ongoing corrective measure component of the risk management system for fairness risks." }, { "control": "apeiris://agentic/controls/AG-03", "id": "AG-03", "domain": "agentic", "name": "Agentic AI Risk Assessment Framework", "validation_objective": "Every production AI agent has a completed, current risk assessment evaluated against all five framework dimensions, with the resulting consequence tier documented and linked to the deployment approval and control mitigation plan.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "Annual risk reassessment records for all Critical-tier agents" ], "evidence": [ { "id": "AG-03-E1", "description": "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E2", "description": "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E3", "description": "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E4", "description": "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E5", "description": "Annual risk reassessment records for all Critical-tier agents", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 9 requires a documented risk management system with iterative risk identification and analysis, and Annex III defines high-risk classification criteria including autonomous decision-making systems. The framework's tier thresholds must align with these regulatory classification criteria to satisfy deployer obligations." } ] }, { "requirement_id": "EU-AIA-ART10-01", "section": "Art. 10(1)", "title": "Data and data governance \u2014 governance practices for training, validation, testing data", "text": "High-risk AI systems which make use of techniques involving the training of AI models with data shall be developed on the basis of training, validation and testing data sets that meet the quality criteria referred to in paragraphs 2 to 5.", "verdict": "supported", "coverage": "direct", "notes": "TG-01 (Training Data Quality Gates) establishes quality criteria and enforcement gates specifically for AI training data, operationalizing this article's core requirement. DM-05 (Data Quality Standards and Target Setting) defines organization-wide data quality standards that apply to AI training, validation, and testing sets. DL-02 (Training Data Lineage Documentation) ensures each dataset has traceable provenance to verify quality criteria were applied at source. DV-02 (Data Quality Gate Enforcement) provides the technical gate that rejects datasets below defined quality thresholds before they enter training pipelines.", "control_count": 4, "proof_chain": [ { "control": "apeiris://model/controls/TG-01", "id": "TG-01", "domain": "model", "name": "Training Data Quality Gates", "validation_objective": "No training run may be initiated unless the designated training dataset has passed automated schema validation, completeness checks, and provenance verification in the current pipeline run; all gate results must be logged with pass/fail status and linked to the training job record.", "blocking_effect": "blocks-deployment", "evidence_required": [ "training_data_quality_gate_report for the current training run showing schema validation results (expected vs. actual field types and cardinalities), completeness check results (null rates, minimum coverage thresholds), and provenance verification status (source hash match, chain-of-custody record reference)", "training_pipeline_block_log confirming that any training attempt that failed a quality gate was rejected before the training compute job was allocated", "dataset_provenance_record with source identifier, ingestion timestamp, data owner, and integrity hash for each training shard used in the run", "quality_threshold_configuration_document defining the pass/fail thresholds for schema validation, completeness, and provenance checks, reviewed and approved by the ML engineering lead" ], "evidence": [ { "id": "TG-01-E1", "description": "training_data_quality_gate_report for the current training run showing schema validation results (expected vs. actual field types and cardinalities), completeness check results (null rates, minimum coverage thresholds), and provenance verification status (source hash match, chain-of-custody record reference)", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "TG-01-E2", "description": "training_pipeline_block_log confirming that any training attempt that failed a quality gate was rejected before the training compute job was allocated", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-01-E3", "description": "dataset_provenance_record with source identifier, ingestion timestamp, data owner, and integrity hash for each training shard used in the run", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-01-E4", "description": "quality_threshold_configuration_document defining the pass/fail thresholds for schema validation, completeness, and provenance checks, reviewed and approved by the ML engineering lead", "evidence_type": "data-lineage-record", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "Quality gate operationalizes Art. 10(2) data governance requirements for high-risk AI" }, { "control": "apeiris://data/controls/DM-05", "id": "DM-05", "domain": "data", "name": "Data Quality Standards and Target Setting", "validation_objective": "Minimum data quality thresholds must be defined and published in the quality standards registry for each active AI data category across all required dimensions (completeness, accuracy, consistency, timeliness); automated quality gate checks must execute on every pipeline run and block training progression when scores fall below thresholds; and quality gate results with scores must be logged for every training run in the pipeline audit trail.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Quality standards registry export showing defined numeric thresholds for completeness, accuracy, consistency, and timeliness dimensions for each active AI data category, with governance review dates", "Pipeline execution audit logs for the past 90 days showing quality gate check results including dimension scores and pass/fail status for each training and inference pipeline run", "Quality gate enforcement evidence showing at least one threshold breach triggered a pipeline block and routed the dataset to the remediation workflow in the review period, or a clean run attestation if no breaches occurred", "Data quality profiling framework configuration showing profiling rules mapped to quality standards registry thresholds, with evidence that profiling runs execute on all active AI data pipelines", "Quarterly quality threshold review records showing Data Governance Officer sign-off and any threshold adjustments with business justification tied to observed model performance correlations" ], "evidence": [ { "id": "DM-05-E1", "description": "Quality standards registry export showing defined numeric thresholds for completeness, accuracy, consistency, and timeliness dimensions for each active AI data category, with governance review dates", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "DM-05-E2", "description": "Pipeline execution audit logs for the past 90 days showing quality gate check results including dimension scores and pass/fail status for each training and inference pipeline run", "evidence_type": "audit-log", "verification": "automated" }, { "id": "DM-05-E3", "description": "Quality gate enforcement evidence showing at least one threshold breach triggered a pipeline block and routed the dataset to the remediation workflow in the review period, or a clean run attestation if no breaches occurred", "evidence_type": "human-review-record", "verification": "human" }, { "id": "DM-05-E4", "description": "Data quality profiling framework configuration showing profiling rules mapped to quality standards registry thresholds, with evidence that profiling runs execute on all active AI data pipelines", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "DM-05-E5", "description": "Quarterly quality threshold review records showing Data Governance Officer sign-off and any threshold adjustments with business justification tied to observed model performance correlations", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 10(2)(f) requires data governance to include examination of training data in view of possible biases; the dataset quality criteria themselves \u2014 relevant, sufficiently representative, and to the best extent possible free of errors and complete \u2014 are stated in Article 10(3). Data quality target setting operationalizes both: thresholds implement the Art. 10(3) criteria and profiling for skew implements the Art. 10(2)(f) bias examination." }, { "control": "apeiris://data/controls/DL-02", "id": "DL-02", "domain": "data", "name": "Training Data Lineage Documentation", "validation_objective": "Every model in the model registry must have a training provenance artifact linking to specific training dataset registry entries by version ID, with each registry entry containing source_identity, collection_date_range, collection_method, license_or_consent_basis, and sha256_hash; and no training job may complete without the artifact being generated as an immutable record bound to that model version.", "blocking_effect": "blocks-deployment", "evidence_required": [ "training_dataset_registry_export for all datasets referenced in training runs in the audit period, with source_name, collection_date_range, collection_method, license_or_consent_basis, and sha256_hash fields populated for every entry", "training_provenance_artifact for each deployed model in the model registry, containing dataset_version_ids, lineage_dag_references, and training_job_metadata as immutable records", "training_job_validation_log confirming each training run referenced registered dataset version IDs and was blocked when referencing unregistered or incomplete entries", "legal_review_record for each new dataset added to the registry in the audit period, signed by legal counsel before the registry entry was finalized, confirming the license or consent basis is sufficient for the intended training use" ], "evidence": [ { "id": "DL-02-E1", "description": "training_dataset_registry_export for all datasets referenced in training runs in the audit period, with source_name, collection_date_range, collection_method, license_or_consent_basis, and sha256_hash fields populated for every entry", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "DL-02-E2", "description": "training_provenance_artifact for each deployed model in the model registry, containing dataset_version_ids, lineage_dag_references, and training_job_metadata as immutable records", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "DL-02-E3", "description": "training_job_validation_log confirming each training run referenced registered dataset version IDs and was blocked when referencing unregistered or incomplete entries", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "DL-02-E4", "description": "legal_review_record for each new dataset added to the registry in the audit period, signed by legal counsel before the registry entry was finalized, confirming the license or consent basis is sufficient for the intended training use", "evidence_type": "configuration-snapshot", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 10(2) enumerates specific data governance requirements for training, validation, and testing data used in high-risk AI systems, including documentation of origin, collection methods, and relevant characteristics. Training data lineage documentation is the direct technical implementation of this statutory requirement." }, { "control": "apeiris://data/controls/DV-02", "id": "DV-02", "domain": "data", "name": "Data Quality Gate Enforcement", "validation_objective": "Every data batch ingested into an AI training or inference pipeline must pass automated quality gate checks for completeness, accuracy, and consistency against defined thresholds before processing proceeds \u2014 with any batch failing one or more quality rules blocked from the pipeline and routed to a quarantine process that tracks each failed batch through to documented resolution.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "quality_rule_registry listing each defined quality rule per dataset and AI pipeline with rule_id, quality dimension (completeness/accuracy/consistency), threshold value, blocking_action, and last_reviewed_date", "quality_gate_execution_log showing each batch evaluation result (pass/fail), rules evaluated, threshold values applied, and failure details for a representative 30-day period", "quarantine_batch_register showing all batches blocked in the prior 90 days with quarantine_entry_timestamp, failure_reason, assigned_investigator, resolution_action, and resolution_timestamp", "quality_threshold_calibration_record documenting how thresholds were established, with reference to training data quality requirements in the model card or dataset specification" ], "evidence": [ { "id": "DV-02-E1", "description": "quality_rule_registry listing each defined quality rule per dataset and AI pipeline with rule_id, quality dimension (completeness/accuracy/consistency), threshold value, blocking_action, and last_reviewed_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "DV-02-E2", "description": "quality_gate_execution_log showing each batch evaluation result (pass/fail), rules evaluated, threshold values applied, and failure details for a representative 30-day period", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "DV-02-E3", "description": "quarantine_batch_register showing all batches blocked in the prior 90 days with quarantine_entry_timestamp, failure_reason, assigned_investigator, resolution_action, and resolution_timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "DV-02-E4", "description": "quality_threshold_calibration_record documenting how thresholds were established, with reference to training data quality requirements in the model card or dataset specification", "evidence_type": "model-card", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 10(2)(f) requires bias examination of training data, and Article 10(3) sets the dataset quality criteria (relevant, sufficiently representative, and to the best extent possible free of errors and complete). Quality gate enforcement blocks datasets that fail these criteria from reaching training or inference \u2014 the enforcement mechanism the Art. 10(2) governance practices presuppose." } ] }, { "requirement_id": "EU-AIA-ART10-02", "section": "Art. 10(2)", "title": "Data governance \u2014 training, validation, testing data set requirements", "text": "Training, validation and testing data sets shall be subject to data governance and management practices including statistical properties and bias analysis; relevant to the intended purpose; sufficiently representative; free of errors; complete to the extent possible.", "verdict": "supported", "coverage": "direct", "notes": "TG-05 (Train/Evaluation/Test Separation and Contamination Prevention) enforces proper dataset splits and prevents leakage that would compromise representativeness or introduce errors. TG-01 requires documentation of statistical properties for each dataset. DV-03 (Statistical Distribution Validation) validates that dataset distributions are consistent with the intended use population and flags under-representation of relevant subgroups. DI-01 (Data Integrity Baseline and Checksum Monitoring) detects corruption and errors in stored datasets before they are consumed by training pipelines.", "control_count": 4, "proof_chain": [ { "control": "apeiris://model/controls/TG-05", "id": "TG-05", "domain": "model", "name": "Train/Evaluation/Test Separation and Contamination Prevention", "validation_objective": "Training, evaluation, and test data splits contain no contaminating examples from other splits, verified by automated exact-match and near-duplicate detection before each training run commences. The training pipeline blocks any run where contamination detection has not completed with a clean result and produced a signed attestation.", "blocking_effect": "blocks-deployment", "evidence_required": [ "contamination_check_audit_log with training_run_id, benchmark names checked, exact_match_count, near_duplicate_count, retrieval_leakage_count, and pass/block outcome per split pair for every training run", "split_deduplication_report listing content-hash comparison results for all training-test and training-eval split pairs, with deduplication method (exact-match hash, MinHash LSH, embedding cosine similarity) and similarity threshold used", "test_set_access_control_record showing storage-layer ACL configuration restricting test split access to validation personnel only, with last-verified date", "evaluation_overfitting_policy document specifying maximum benchmark reuse count per model version, rotation schedule, and use of held-out external benchmarks not accessible to the model development team" ], "evidence": [ { "id": "TG-05-E1", "description": "contamination_check_audit_log with training_run_id, benchmark names checked, exact_match_count, near_duplicate_count, retrieval_leakage_count, and pass/block outcome per split pair for every training run", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "TG-05-E2", "description": "split_deduplication_report listing content-hash comparison results for all training-test and training-eval split pairs, with deduplication method (exact-match hash, MinHash LSH, embedding cosine similarity) and similarity threshold used", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "TG-05-E3", "description": "test_set_access_control_record showing storage-layer ACL configuration restricting test split access to validation personnel only, with last-verified date", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "TG-05-E4", "description": "evaluation_overfitting_policy document specifying maximum benchmark reuse count per model version, rotation schedule, and use of held-out external benchmarks not accessible to the model development team", "evidence_type": "evaluation-scorecard", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "Test independence supports EU AI Act testing requirements for high-risk AI" }, { "control": "apeiris://model/controls/TG-01", "id": "TG-01", "domain": "model", "name": "Training Data Quality Gates", "validation_objective": "No training run may be initiated unless the designated training dataset has passed automated schema validation, completeness checks, and provenance verification in the current pipeline run; all gate results must be logged with pass/fail status and linked to the training job record.", "blocking_effect": "blocks-deployment", "evidence_required": [ "training_data_quality_gate_report for the current training run showing schema validation results (expected vs. actual field types and cardinalities), completeness check results (null rates, minimum coverage thresholds), and provenance verification status (source hash match, chain-of-custody record reference)", "training_pipeline_block_log confirming that any training attempt that failed a quality gate was rejected before the training compute job was allocated", "dataset_provenance_record with source identifier, ingestion timestamp, data owner, and integrity hash for each training shard used in the run", "quality_threshold_configuration_document defining the pass/fail thresholds for schema validation, completeness, and provenance checks, reviewed and approved by the ML engineering lead" ], "evidence": [ { "id": "TG-01-E1", "description": "training_data_quality_gate_report for the current training run showing schema validation results (expected vs. actual field types and cardinalities), completeness check results (null rates, minimum coverage thresholds), and provenance verification status (source hash match, chain-of-custody record reference)", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "TG-01-E2", "description": "training_pipeline_block_log confirming that any training attempt that failed a quality gate was rejected before the training compute job was allocated", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-01-E3", "description": "dataset_provenance_record with source identifier, ingestion timestamp, data owner, and integrity hash for each training shard used in the run", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-01-E4", "description": "quality_threshold_configuration_document defining the pass/fail thresholds for schema validation, completeness, and provenance checks, reviewed and approved by the ML engineering lead", "evidence_type": "data-lineage-record", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "Quality gate operationalizes Art. 10(2) data governance requirements for high-risk AI" }, { "control": "apeiris://data/controls/DV-03", "id": "DV-03", "domain": "data", "name": "Statistical Distribution Validation", "validation_objective": "The system must have a registered distribution baseline for every active AI pipeline, with a monitoring service computing drift scores on each incoming data batch and triggering alerts or pipeline holds when scores exceed the documented thresholds. Drift alert acknowledgment and resolution records must exist within the defined SLA for every alert raised during the assessment period.", "blocking_effect": "advisory", "evidence_required": [ "baseline_profile_registry export showing each AI pipeline ID, its reference data window, and computed feature statistics (mean, standard deviation, quantile distributions, null rates) linked to the corresponding model version", "drift_score_time_series log covering the assessment period, with entries for each batch showing pipeline ID, batch ID, drift metric used (PSI/KL/Wasserstein), per-feature drift scores, and whether the threshold was breached", "threshold_configuration record for each pipeline documenting warning and critical drift thresholds per feature and the approved rationale for each threshold value", "drift_alert_log showing each alert raised during the assessment period with timestamp, assigned owner, and acknowledgment and resolution timestamps confirming SLA compliance", "baseline_refresh_record confirming baseline profiles were updated following the most recent model retraining event and within the past 12 months" ], "evidence": [ { "id": "DV-03-E1", "description": "baseline_profile_registry export showing each AI pipeline ID, its reference data window, and computed feature statistics (mean, standard deviation, quantile distributions, null rates) linked to the corresponding model version", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "DV-03-E2", "description": "drift_score_time_series log covering the assessment period, with entries for each batch showing pipeline ID, batch ID, drift metric used (PSI/KL/Wasserstein), per-feature drift scores, and whether the threshold was breached", "evidence_type": "audit-log", "verification": "automated" }, { "id": "DV-03-E3", "description": "threshold_configuration record for each pipeline documenting warning and critical drift thresholds per feature and the approved rationale for each threshold value", "evidence_type": "human-review-record", "verification": "human" }, { "id": "DV-03-E4", "description": "drift_alert_log showing each alert raised during the assessment period with timestamp, assigned owner, and acknowledgment and resolution timestamps confirming SLA compliance", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "DV-03-E5", "description": "baseline_refresh_record confirming baseline profiles were updated following the most recent model retraining event and within the past 12 months", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 9(6)-(8) requires high-risk AI systems to be tested against prior defined metrics and probabilistic thresholds \u2014 including, where appropriate, testing in real-world conditions \u2014 to identify the most appropriate and targeted risk-management measures. Statistical distribution validation implements the continuous, metric-driven testing of operational data these provisions require." }, { "control": "apeiris://data/controls/DI-01", "id": "DI-01", "domain": "data", "name": "Data Integrity Baseline and Checksum Monitoring", "validation_objective": "Every critical AI dataset used for training, fine-tuning, or evaluation must have a SHA-256 cryptographic checksum registered in an append-only integrity ledger at ingest, with scheduled integrity scans confirming no deviation from the baseline fingerprint throughout the dataset lifecycle.", "blocking_effect": "advisory", "evidence_required": [ "integrity_ledger_export showing dataset_id, checksum_algorithm, checksum_value, and registered_at timestamp for each enrolled critical dataset", "integrity_scan_log confirming scheduled scans completed for all enrolled datasets within the defined SLA window, including scan_timestamp, dataset_id, and result (pass/deviation)", "deviation_alert_record for any checksum mismatches detected, including dataset_id, detection_timestamp, scope_of_deviation, and remediation_status", "critical_dataset_inventory showing all datasets requiring enrollment, with enrollment_status field indicating coverage percentage" ], "evidence": [ { "id": "DI-01-E1", "description": "integrity_ledger_export showing dataset_id, checksum_algorithm, checksum_value, and registered_at timestamp for each enrolled critical dataset", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "DI-01-E2", "description": "integrity_scan_log confirming scheduled scans completed for all enrolled datasets within the defined SLA window, including scan_timestamp, dataset_id, and result (pass/deviation)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "DI-01-E3", "description": "deviation_alert_record for any checksum mismatches detected, including dataset_id, detection_timestamp, scope_of_deviation, and remediation_status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "DI-01-E4", "description": "critical_dataset_inventory showing all datasets requiring enrollment, with enrollment_status field indicating coverage percentage", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 10(2)(e) requires an assessment of the availability, quantity and suitability of the data sets needed for the high-risk AI system; bias examination sits in Article 10(2)(f)-(g), not (e). Integrity baselines and checksum monitoring provide verifiable evidence that datasets remain the datasets that were assessed, supporting suitability claims over time." } ] }, { "requirement_id": "EU-AIA-ART10-03", "section": "Art. 10(3)", "title": "Data governance \u2014 relevance, completeness, and appropriateness of data", "text": "Training, validation and testing data sets shall take into account, to the extent required by their intended purpose, the relevant characteristics or elements particular to the specific geographical, contextual, behavioural, or functional setting within which the high-risk AI system is intended to be used.", "verdict": "supported", "coverage": "direct", "notes": "LI-07 (Capability and Limitation Declaration) requires explicit documentation of the intended deployment context \u2014 geographic, demographic, and behavioural \u2014 as a prerequisite for dataset design. TG-06 (Sensitive-Data Necessity, Minimization and Controlled Use) ensures that training data characteristics are scoped to the deployment context. PV-01 (Operating Intent Declaration) anchors the intended purpose that training data must be relevant to. TG-02 (Bias and Representativeness Assessment) verifies that contextual representation is adequate for the stated deployment setting.", "control_count": 4, "proof_chain": [ { "control": "apeiris://model/controls/TG-06", "id": "TG-06", "domain": "model", "name": "Sensitive-Data Necessity, Minimization and Controlled Use", "validation_objective": "Every training dataset containing PII or protected-class attributes has a documented necessity assessment with named approver sign-off confirming that the data cannot be substituted with de-identified or synthetic alternatives. When protected attributes are retained for bias auditing, they are stored exclusively in a separately access-controlled fairness audit vault \u2014 not in the general training corpus \u2014 with time-bounded, logged access for each session.", "blocking_effect": "blocks-deployment", "evidence_required": [ "data_necessity_assessment_record with dataset_id, PII categories identified (name/email/SSN/biometric/protected-class), justification for necessity over de-identified alternatives, and approver_identity with approval_timestamp", "PII_scan_run_log showing scanner tool, dataset version, detection count per PII category, and remediation action per detected item (de-identified / synthetic-replaced / retained-in-fairness-vault)", "fairness_audit_vault_access_log for the retention window, listing accessor_identity, purpose, authorization_record_id, and session_duration for every vault access", "synthetic_data_provenance_record for any PII replaced with synthetic proxies, confirming generation method and confirming synthetic records cannot be re-linked to real individuals via quasi-identifiers" ], "evidence": [ { "id": "TG-06-E1", "description": "data_necessity_assessment_record with dataset_id, PII categories identified (name/email/SSN/biometric/protected-class), justification for necessity over de-identified alternatives, and approver_identity with approval_timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-06-E2", "description": "PII_scan_run_log showing scanner tool, dataset version, detection count per PII category, and remediation action per detected item (de-identified / synthetic-replaced / retained-in-fairness-vault)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-06-E3", "description": "fairness_audit_vault_access_log for the retention window, listing accessor_identity, purpose, authorization_record_id, and session_duration for every vault access", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-06-E4", "description": "synthetic_data_provenance_record for any PII replaced with synthetic proxies, confirming generation method and confirming synthetic records cannot be re-linked to real individuals via quasi-identifiers", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "Minimization controls implement EU AI Act data governance and special-category processing requirements" }, { "control": "apeiris://model/controls/LI-07", "id": "LI-07", "domain": "model", "name": "Capability and Limitation Declaration \u2014 Intended Use, Constraints,...", "validation_objective": "Every registered model must have a structured, schema-validated capability-limitation declaration with all five required dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, and knowledge_cutoff) substantively populated with population- and context-qualified entries, returned as structured metadata in the model registry API response; registration must be blocked when any dimension is absent or empty; and the model's observable behavior for post-knowledge-cutoff queries must be consistent with the declared uncertainty_bounds.", "blocking_effect": "blocks-deployment", "evidence_required": [ "capability_limitation_declaration with all five dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, knowledge_cutoff) substantively populated with population-qualified and context-qualified entries, version-locked to the artifact hash", "registry_api_response_sample demonstrating that the capability_limitation_declaration object is returned as structured metadata in the model registry API response for the model's registered ID without requiring separate documentation lookup", "cutoff_behavior_test_result showing model responses to at least three post-knowledge-cutoff factual queries compared against the declared uncertainty_bounds, confirming the model acknowledges the limitation rather than confabulating confident answers", "registration_rejection_log showing that a model registration attempt with an empty out_of_scope_uses field was blocked with an error identifying the specific missing dimension" ], "evidence": [ { "id": "LI-07-E1", "description": "capability_limitation_declaration with all five dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, knowledge_cutoff) substantively populated with population-qualified and context-qualified entries, version-locked to the artifact hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E2", "description": "registry_api_response_sample demonstrating that the capability_limitation_declaration object is returned as structured metadata in the model registry API response for the model's registered ID without requiring separate documentation lookup", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E3", "description": "cutoff_behavior_test_result showing model responses to at least three post-knowledge-cutoff factual queries compared against the declared uncertainty_bounds, confirming the model acknowledges the limitation rather than confabulating confident answers", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E4", "description": "registration_rejection_log showing that a model registration attempt with an empty out_of_scope_uses field was blocked with an error identifying the specific missing dimension", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art-13 requires that high-risk AI systems be designed and developed such that deployers receive sufficient information to understand the system's capabilities and limitations and to implement appropriate human oversight. LI-07's structured capability-limitation declaration directly satisfies Art-13 by providing machine-readable, structured transparency information at the model consumption point." }, { "control": "apeiris://authority/controls/PV-01", "id": "PV-01", "domain": "authority", "name": "Operating Intent Declaration", "validation_objective": "Every active AI system deployment must have a machine-readable, cryptographically signed intent declaration registered in the authority control registry before production activation. The deployment pipeline must block agent activation when no valid, unexpired declaration with all required schema fields is present.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Signed intent declaration artifact with canonical_id, authorized_action_types, context_scope, principal_id, valid_from, and valid_until fields for every active AI deployment", "Deployment gate rejection logs demonstrating that agent activations without a registered, unexpired declaration were blocked, with fields for system_id, attempted_at, and rejection_reason", "Authority control registry export cross-referencing each active deployment to its current declaration record and cryptographic signature", "Principal authorization verification record confirming the signing identity has organizational authority to bind the enterprise to the declared scope", "Renewal audit trail linking declaration version history to deployment lifecycle events and authorizing principal identity" ], "evidence": [ { "id": "PV-01-E1", "description": "Signed intent declaration artifact with canonical_id, authorized_action_types, context_scope, principal_id, valid_from, and valid_until fields for every active AI deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PV-01-E2", "description": "Deployment gate rejection logs demonstrating that agent activations without a registered, unexpired declaration were blocked, with fields for system_id, attempted_at, and rejection_reason", "evidence_type": "audit-log", "verification": "automated" }, { "id": "PV-01-E3", "description": "Authority control registry export cross-referencing each active deployment to its current declaration record and cryptographic signature", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "PV-01-E4", "description": "Principal authorization verification record confirming the signing identity has organizational authority to bind the enterprise to the declared scope", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PV-01-E5", "description": "Renewal audit trail linking declaration version history to deployment lifecycle events and authorizing principal identity", "evidence_type": "audit-log", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "The signed intent declaration is one input feeding a risk management system, not the full Art. 9 system." }, { "control": "apeiris://model/controls/TG-02", "id": "TG-02", "domain": "model", "name": "Bias and Representativeness Assessment", "validation_objective": "Before each training run and after each data refresh, a documented subgroup and intersectional fairness analysis is completed for the training dataset, producing a bias baseline report that identifies population coverage gaps and subgroup representation rates; this report must be reviewed and accepted before training proceeds.", "blocking_effect": "blocks-deployment", "evidence_required": [ "bias_assessment_report containing subgroup representation rates across all demographic dimensions relevant to the model's use case, intersectional analysis results, identification of underrepresented populations, and comparison to the prior baseline where applicable", "data_refresh_trigger_record showing that a new bias assessment was initiated whenever the training dataset was updated, not only at initial training", "bias_baseline_acceptance_record with reviewer identity, acceptance timestamp, and documented acknowledgment of any known representation gaps and their accepted risk level", "subgroup_definition_document specifying which demographic dimensions and proxy features were analyzed, reviewed against the model's deployment context and affected populations" ], "evidence": [ { "id": "TG-02-E1", "description": "bias_assessment_report containing subgroup representation rates across all demographic dimensions relevant to the model's use case, intersectional analysis results, identification of underrepresented populations, and comparison to the prior baseline where applicable", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-02-E2", "description": "data_refresh_trigger_record showing that a new bias assessment was initiated whenever the training dataset was updated, not only at initial training", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-02-E3", "description": "bias_baseline_acceptance_record with reviewer identity, acceptance timestamp, and documented acknowledgment of any known representation gaps and their accepted risk level", "evidence_type": "human-review-record", "verification": "human" }, { "id": "TG-02-E4", "description": "subgroup_definition_document specifying which demographic dimensions and proxy features were analyzed, reviewed against the model's deployment context and affected populations", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "BAR directly implements Art. 10(3) bias examination mandate for high-risk AI" } ] }, { "requirement_id": "EU-AIA-ART10-04", "section": "Art. 10(4)", "title": "Data governance \u2014 examination for biases", "text": "To the extent that it is strictly necessary for the purposes of ensuring bias detection and correction in the high-risk AI system, providers of such systems may process special categories of personal data, subject to appropriate safeguards for the fundamental rights and freedoms of natural persons.", "verdict": "supported", "coverage": "direct", "notes": "TG-02 (Bias and Representativeness Assessment) is the direct technical control for bias examination in training data, required before training begins. FA-02 (Algorithmic Bias Impact Assessment) covers bias analysis at the model evaluation stage. FA-04 (Independent Bias Testing Methodology) requires structured, repeatable methodology for bias detection that can be disclosed to regulators. PC-06 (AI Privacy Impact Assessment) ensures that where special-category data is used for bias detection, appropriate privacy safeguards and data minimization controls are documented.", "control_count": 4, "proof_chain": [ { "control": "apeiris://model/controls/TG-02", "id": "TG-02", "domain": "model", "name": "Bias and Representativeness Assessment", "validation_objective": "Before each training run and after each data refresh, a documented subgroup and intersectional fairness analysis is completed for the training dataset, producing a bias baseline report that identifies population coverage gaps and subgroup representation rates; this report must be reviewed and accepted before training proceeds.", "blocking_effect": "blocks-deployment", "evidence_required": [ "bias_assessment_report containing subgroup representation rates across all demographic dimensions relevant to the model's use case, intersectional analysis results, identification of underrepresented populations, and comparison to the prior baseline where applicable", "data_refresh_trigger_record showing that a new bias assessment was initiated whenever the training dataset was updated, not only at initial training", "bias_baseline_acceptance_record with reviewer identity, acceptance timestamp, and documented acknowledgment of any known representation gaps and their accepted risk level", "subgroup_definition_document specifying which demographic dimensions and proxy features were analyzed, reviewed against the model's deployment context and affected populations" ], "evidence": [ { "id": "TG-02-E1", "description": "bias_assessment_report containing subgroup representation rates across all demographic dimensions relevant to the model's use case, intersectional analysis results, identification of underrepresented populations, and comparison to the prior baseline where applicable", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-02-E2", "description": "data_refresh_trigger_record showing that a new bias assessment was initiated whenever the training dataset was updated, not only at initial training", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-02-E3", "description": "bias_baseline_acceptance_record with reviewer identity, acceptance timestamp, and documented acknowledgment of any known representation gaps and their accepted risk level", "evidence_type": "human-review-record", "verification": "human" }, { "id": "TG-02-E4", "description": "subgroup_definition_document specifying which demographic dimensions and proxy features were analyzed, reviewed against the model's deployment context and affected populations", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "BAR directly implements Art. 10(3) bias examination mandate for high-risk AI" }, { "control": "apeiris://ethics/controls/FA-02", "id": "FA-02", "domain": "ethics", "name": "Algorithmic Bias Impact Assessment", "validation_objective": "Every AI system subject to fairness evaluation must have a completed Algorithmic Bias Impact Assessment (ABIA) covering all protected characteristics in the FA-01 register, addressing both training data composition bias and model prediction disparities, completed before initial deployment and re-run after any material model or data change.", "blocking_effect": "blocks-deployment", "evidence_required": [ "algorithmic_bias_impact_assessment_report with per-characteristic findings, methodology description, direct discrimination and disparate impact pathways assessed, and risk rating for each finding", "training_data_composition_report showing demographic representation across protected groups relative to the reference deployment population", "model_prediction_disaggregation_report showing predicted outcome rates by protected characteristic with confidence intervals and statistical significance testing", "feedback_loop_risk_analysis documenting whether biased model outputs could influence future training data collection or labeling", "abia_reviewer_sign_off_record with reviewer credentials and date confirming independence from the model development team" ], "evidence": [ { "id": "FA-02-E1", "description": "algorithmic_bias_impact_assessment_report with per-characteristic findings, methodology description, direct discrimination and disparate impact pathways assessed, and risk rating for each finding", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E2", "description": "training_data_composition_report showing demographic representation across protected groups relative to the reference deployment population", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E3", "description": "model_prediction_disaggregation_report showing predicted outcome rates by protected characteristic with confidence intervals and statistical significance testing", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E4", "description": "feedback_loop_risk_analysis documenting whether biased model outputs could influence future training data collection or labeling", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E5", "description": "abia_reviewer_sign_off_record with reviewer credentials and date confirming independence from the model development team", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "Article 9(2)(b) of the EU AI Act requires that risk management for high-risk AI systems include testing procedures to identify and address foreseeable risks, explicitly including bias. A pre-deployment ABIA is the primary mechanism for satisfying this requirement." }, { "control": "apeiris://ethics/controls/FA-04", "id": "FA-04", "domain": "ethics", "name": "Independent Bias Testing Methodology", "validation_objective": "Bias testing for AI systems subject to fairness requirements must be executed under a documented, pre-registered protocol by a tester with no organizational conflict of interest with the model development team, with all findings retained in an immutable log and reported without post-hoc filtering.", "blocking_effect": "blocks-deployment", "evidence_required": [ "independent_bias_test_protocol_document published prior to test execution specifying methodology, test datasets, metrics, and pass/fail thresholds", "tester_independence_certification confirming the testing entity or individual has no direct reporting relationship to or financial interest in the model development team, signed by a party outside the model development chain", "bias_test_execution_log with timestamped test runs, inputs, and outputs in an immutable or append-only store preventing retroactive modification", "bias_test_findings_report including all findings (not only passing results) with statistical support, identified disparity locations, and remediation recommendations" ], "evidence": [ { "id": "FA-04-E1", "description": "independent_bias_test_protocol_document published prior to test execution specifying methodology, test datasets, metrics, and pass/fail thresholds", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "FA-04-E2", "description": "tester_independence_certification confirming the testing entity or individual has no direct reporting relationship to or financial interest in the model development team, signed by a party outside the model development chain", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-04-E3", "description": "bias_test_execution_log with timestamped test runs, inputs, and outputs in an immutable or append-only store preventing retroactive modification", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "FA-04-E4", "description": "bias_test_findings_report including all findings (not only passing results) with statistical support, identified disparity locations, and remediation recommendations", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "Article 9(6) of the EU AI Act requires that high-risk AI systems be tested against preliminary identified risk management measures, including bias. This control operationalizes that testing requirement with documented independent methodology." }, { "control": "apeiris://privacy/controls/PC-06", "id": "PC-06", "domain": "privacy", "name": "AI Privacy Impact Assessment", "validation_objective": "For every AI system that processes personal data, a completed AI-specific Privacy Impact Assessment exists, produced before deployment, explicitly addressing model memorization risk with empirical test results, inference attack exposure, training data leakage scenarios, and automated decision effects. The assessment must carry DPO review sign-off and documented risk acceptance by the business owner for any residual risk above threshold.", "blocking_effect": "blocks-deployment", "evidence_required": [ "AI_PIA_report with system identifier, assessment date, scope of personal data processed, model architecture summary, assessor identity, and completion timestamp predating deployment_date", "memorization_risk_test_results showing membership inference attack test outcomes (e.g., canary token insertion and recovery rates, membership inference AUC) and mitigations applied with effectiveness evidence", "training_data_exposure_analysis documenting data lineage, anonymization or pseudonymisation techniques applied, and residual re-identification risk score with methodology", "automated_decision_effect_analysis listing each decision type the AI makes with documented human review trigger conditions, appeal mechanism reference, and explanation capability status", "DPO_review_record and business_owner_risk_acceptance for any residual risks above the acceptable threshold, with acceptance date and accepted_risk_items listed" ], "evidence": [ { "id": "PC-06-E1", "description": "AI_PIA_report with system identifier, assessment date, scope of personal data processed, model architecture summary, assessor identity, and completion timestamp predating deployment_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PC-06-E2", "description": "memorization_risk_test_results showing membership inference attack test outcomes (e.g., canary token insertion and recovery rates, membership inference AUC) and mitigations applied with effectiveness evidence", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "PC-06-E3", "description": "training_data_exposure_analysis documenting data lineage, anonymization or pseudonymisation techniques applied, and residual re-identification risk score with methodology", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "PC-06-E4", "description": "automated_decision_effect_analysis listing each decision type the AI makes with documented human review trigger conditions, appeal mechanism reference, and explanation capability status", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PC-06-E5", "description": "DPO_review_record and business_owner_risk_acceptance for any residual risks above the acceptable threshold, with acceptance date and accepted_risk_items listed", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "PC-06 partially addresses EU AI Act Art 27 by producing a fundamental rights impact assessment as a distinct document for high-risk AI systems; Art 27(4) allows the FRIA to build on the GDPR Art 35 DPIA that PC-06 extends to AI-specific privacy risks." } ] }, { "requirement_id": "EU-AIA-ART10-05", "section": "Art. 10(5)", "title": "Data governance \u2014 special category data for bias detection", "text": "Special categories of personal data referred to in Article 9 of Regulation (EU) 2016/679 may be processed for bias detection provided that appropriate safeguards are in place for the fundamental rights and freedoms of natural persons.", "verdict": "partial", "coverage": "partial", "notes": "DC-02 (Special Category Data Classification) identifies and applies access controls to special-category data. TG-02 governs its use in bias detection workflows. FA-01 (Protected Characteristic Identification and Scope) maps which protected attributes are being assessed. DG-05 (DPIA Lifecycle Management) is the GDPR-layer safeguard required for special-category processing. Partial: the specific GDPR Article 9(2) legal basis selection, data processor agreements, and Article 30 record-of-processing entries for this specific processing purpose require legal and DPO involvement that extends beyond Apeiris controls.", "control_count": 4, "proof_chain": [ { "control": "apeiris://privacy/controls/DC-02", "id": "DC-02", "domain": "privacy", "name": "Special Category Data Classification", "validation_objective": "Every AI training dataset and inference input stream must be scanned for GDPR Art 9 special category data and CCPA sensitive personal information before processing begins. Any dataset containing detected special category data must have a corresponding classification registry entry with a documented Art 9(2) basis and DPO acknowledgment before the pipeline is permitted to execute.", "blocking_effect": "blocks-deployment", "evidence_required": [ "special_category_classification_registry \u2014 export of all datasets classified as containing special category data with fields: detected_categories[], art9_basis, dpo_acknowledgment_date, access_restriction_profile, and registry_expiry", "classifier_scan_report \u2014 most recent automated classification scan output across active AI training datasets showing coverage percentage, detected categories, and confidence scores", "heightened_access_audit_log \u2014 access log for special category datasets showing every access attributed to an authorized processor role with documented purpose within the review period", "dpia_records \u2014 completed Data Protection Impact Assessments for all AI systems processing Art 9 data, including scope matching classification registry entries" ], "evidence": [ { "id": "DC-02-E1", "description": "special_category_classification_registry \u2014 export of all datasets classified as containing special category data with fields: detected_categories[], art9_basis, dpo_acknowledgment_date, access_restriction_profile, and registry_expiry", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "DC-02-E2", "description": "classifier_scan_report \u2014 most recent automated classification scan output across active AI training datasets showing coverage percentage, detected categories, and confidence scores", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "DC-02-E3", "description": "heightened_access_audit_log \u2014 access log for special category datasets showing every access attributed to an authorized processor role with documented purpose within the review period", "evidence_type": "audit-log", "verification": "automated" }, { "id": "DC-02-E4", "description": "dpia_records \u2014 completed Data Protection Impact Assessments for all AI systems processing Art 9 data, including scope matching classification registry entries", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://model/controls/TG-02", "id": "TG-02", "domain": "model", "name": "Bias and Representativeness Assessment", "validation_objective": "Before each training run and after each data refresh, a documented subgroup and intersectional fairness analysis is completed for the training dataset, producing a bias baseline report that identifies population coverage gaps and subgroup representation rates; this report must be reviewed and accepted before training proceeds.", "blocking_effect": "blocks-deployment", "evidence_required": [ "bias_assessment_report containing subgroup representation rates across all demographic dimensions relevant to the model's use case, intersectional analysis results, identification of underrepresented populations, and comparison to the prior baseline where applicable", "data_refresh_trigger_record showing that a new bias assessment was initiated whenever the training dataset was updated, not only at initial training", "bias_baseline_acceptance_record with reviewer identity, acceptance timestamp, and documented acknowledgment of any known representation gaps and their accepted risk level", "subgroup_definition_document specifying which demographic dimensions and proxy features were analyzed, reviewed against the model's deployment context and affected populations" ], "evidence": [ { "id": "TG-02-E1", "description": "bias_assessment_report containing subgroup representation rates across all demographic dimensions relevant to the model's use case, intersectional analysis results, identification of underrepresented populations, and comparison to the prior baseline where applicable", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-02-E2", "description": "data_refresh_trigger_record showing that a new bias assessment was initiated whenever the training dataset was updated, not only at initial training", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-02-E3", "description": "bias_baseline_acceptance_record with reviewer identity, acceptance timestamp, and documented acknowledgment of any known representation gaps and their accepted risk level", "evidence_type": "human-review-record", "verification": "human" }, { "id": "TG-02-E4", "description": "subgroup_definition_document specifying which demographic dimensions and proxy features were analyzed, reviewed against the model's deployment context and affected populations", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "BAR directly implements Art. 10(3) bias examination mandate for high-risk AI" }, { "control": "apeiris://ethics/controls/FA-01", "id": "FA-01", "domain": "ethics", "name": "Protected Characteristic Identification and Scope", "validation_objective": "Every AI system must have a documented protected characteristic register that enumerates all characteristics protected under each applicable jurisdiction's law, including identified proxy variables that may encode those characteristics, updated whenever jurisdictional scope or system use case changes.", "blocking_effect": "blocks-deployment", "evidence_required": [ "protected_characteristic_register listing each characteristic with jurisdiction_applicability, regulatory_basis (statute or directive citation), and proxy_variable_mapping", "jurisdictional_scope_analysis document identifying all operating jurisdictions and the applicable non-discrimination statutes for each", "proxy_variable_review_record showing assessment of training features for potential encoding of protected characteristics", "legal_or_compliance_sign_off_record confirming register completeness for current jurisdictional scope and use context" ], "evidence": [ { "id": "FA-01-E1", "description": "protected_characteristic_register listing each characteristic with jurisdiction_applicability, regulatory_basis (statute or directive citation), and proxy_variable_mapping", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-01-E2", "description": "jurisdictional_scope_analysis document identifying all operating jurisdictions and the applicable non-discrimination statutes for each", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-01-E3", "description": "proxy_variable_review_record showing assessment of training features for potential encoding of protected characteristics", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-01-E4", "description": "legal_or_compliance_sign_off_record confirming register completeness for current jurisdictional scope and use context", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "Article 10(5) of the EU AI Act requires that providers of high-risk AI systems process special categories of personal data only to the extent strictly necessary for bias monitoring and correction. Identifying which characteristics constitute special categories within each jurisdiction is a prerequisite for compliant data handling." }, { "control": "apeiris://privacy/controls/DG-05", "id": "DG-05", "domain": "privacy", "name": "DPIA Lifecycle Management", "validation_objective": "A Data Protection Impact Assessment must be completed and approved by the DPO before any high-risk AI system is deployed, and the DPIA must be updated whenever the system's processing changes materially. No high-risk AI system may be deployed or have its scope materially changed without an approved, current DPIA on record.", "blocking_effect": "blocks-deployment", "evidence_required": [ "dpia_report for each high-risk AI system including processing description, necessity and proportionality assessment, risk identification and evaluation, and risk mitigation measures with residual risk verdict", "dpo_consultation_record documenting DPO review of the DPIA, DPO advice provided, and controller response to any adverse DPO opinion", "dpia_approval_record with approver identity (controller representative), approval date, and any conditions attached to deployment authorisation", "dpia_change_trigger_log documenting all material processing changes evaluated against the DPIA update threshold, with decision records for changes that did and did not trigger a DPIA update", "supervisory_authority_prior_consultation_record for any DPIA that concluded residual risk remains high, documenting the consultation outcome before deployment proceeded" ], "evidence": [ { "id": "DG-05-E1", "description": "dpia_report for each high-risk AI system including processing description, necessity and proportionality assessment, risk identification and evaluation, and risk mitigation measures with residual risk verdict", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "DG-05-E2", "description": "dpo_consultation_record documenting DPO review of the DPIA, DPO advice provided, and controller response to any adverse DPO opinion", "evidence_type": "human-review-record", "verification": "human" }, { "id": "DG-05-E3", "description": "dpia_approval_record with approver identity (controller representative), approval date, and any conditions attached to deployment authorisation", "evidence_type": "human-review-record", "verification": "human" }, { "id": "DG-05-E4", "description": "dpia_change_trigger_log documenting all material processing changes evaluated against the DPIA update threshold, with decision records for changes that did and did not trigger a DPIA update", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "DG-05-E5", "description": "supervisory_authority_prior_consultation_record for any DPIA that concluded residual risk remains high, documenting the consultation outcome before deployment proceeded", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art 27 requires deployers of certain high-risk AI systems to conduct a fundamental rights impact assessment and allows it to build on an existing DPIA (Art 27(4)); DG-05 covers the GDPR DPIA obligation while the Ethics domain HI layer covers the distinct FRIA." } ] }, { "requirement_id": "EU-AIA-ART11-01", "section": "Art. 11(1)", "title": "Technical documentation \u2014 establish before placing on market", "text": "Before placing on the market or putting into service a high-risk AI system, providers of such systems shall draw up technical documentation in accordance with Annex IV.", "verdict": "supported", "coverage": "direct", "notes": "RF-03 (EU AI Act Technical Documentation Package \u2014 Art. 11) is the Apeiris control created specifically to manage Annex IV technical documentation production and completeness. LI-04 (Structured Model Documentation \u2014 Complete Model Card) covers the system description, intended purpose, version history, and performance characteristics required by Annex IV \u00a71-2. LI-07 (Capability and Limitation Declaration) covers Annex IV \u00a71(c) requirements for capability description and known limitations. LI-02 (Model Provenance Chain) covers Annex IV training data lineage requirements.", "control_count": 4, "proof_chain": [ { "control": "apeiris://model/controls/LI-04", "id": "LI-04", "domain": "model", "name": "Structured Model Documentation \u2014 Complete Model Card with All Required Sections", "validation_objective": "Every model submitted for registration must have a schema-validated model card with all nine Mitchell et al. 2019 sections substantively populated and passing field-level validation rules; the model card must be version-locked to the artifact hash and returned as structured metadata from the registry API; and registration must be blocked when any required section is absent, empty, or contains only placeholder text.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_card_completeness_validation_report showing pass/fail status per section with field-level validation results, registration blocking decision, and validation timestamp for the current artifact version", "versioned_model_card artifact linked to the specific model artifact hash with all nine Mitchell et al. sections containing substantive content (not placeholder text), retrievable from the registry by artifact hash", "model_registry_entry showing the current model card version hash stored alongside the artifact hash as paired immutable fields", "eu_ai_act_annex_iv_supplemental_record for EU AI Act high-risk in-scope systems confirming Annex IV technical documentation fields are populated in addition to the nine Mitchell et al. sections" ], "evidence": [ { "id": "LI-04-E1", "description": "model_card_completeness_validation_report showing pass/fail status per section with field-level validation results, registration blocking decision, and validation timestamp for the current artifact version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-04-E2", "description": "versioned_model_card artifact linked to the specific model artifact hash with all nine Mitchell et al. sections containing substantive content (not placeholder text), retrievable from the registry by artifact hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-04-E3", "description": "model_registry_entry showing the current model card version hash stored alongside the artifact hash as paired immutable fields", "evidence_type": "model-card", "verification": "attested" }, { "id": "LI-04-E4", "description": "eu_ai_act_annex_iv_supplemental_record for EU AI Act high-risk in-scope systems confirming Annex IV technical documentation fields are populated in addition to the nine Mitchell et al. sections", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art-11 requires providers of high-risk AI systems to prepare and maintain technical documentation before market placement. The Mitchell et al. 9-section model card supplemented with Annex IV fields directly satisfies Art-11's technical documentation requirement. This control supports satisfaction of Art-11 for covered deployments; applicability depends on the deployer's role (provider vs. deployer) and the system's high-risk classification." }, { "control": "apeiris://compliance/controls/RF-03", "id": "RF-03", "domain": "compliance", "name": "EU AI Act Technical Documentation Package (Art. 11)", "validation_objective": "Each high-risk AI system must have an Annex IV technical documentation package with all required sections substantively populated \u2014 no missing sections or placeholder content \u2014 version-controlled and linked to the current CE declaration, updated within 30 days of any qualifying model or deployment scope change, and retained in a controlled repository for 10 years from market placement date as required by Art. 18.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Annex IV completeness checklist per high-risk system with completion status for each required section, documentation owner sign-off, and compliance team approval date", "Technical documentation version history linking each documentation version to the corresponding model version, CE declaration version, and the change management ticket that triggered the update", "Model change management tickets with documentation update completion confirmation timestamp within 30 days of each qualifying model or deployment scope change event", "Documentation repository access log and retention policy configuration confirming role-based access controls, full version history, and a 10-year minimum retention period anchored to market placement date", "Pre-submission documentation completeness review record with legal and compliance sign-off completed before notified body submission or CE declaration issuance" ], "evidence": [ { "id": "RF-03-E1", "description": "Annex IV completeness checklist per high-risk system with completion status for each required section, documentation owner sign-off, and compliance team approval date", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RF-03-E2", "description": "Technical documentation version history linking each documentation version to the corresponding model version, CE declaration version, and the change management ticket that triggered the update", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RF-03-E3", "description": "Model change management tickets with documentation update completion confirmation timestamp within 30 days of each qualifying model or deployment scope change event", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RF-03-E4", "description": "Documentation repository access log and retention policy configuration confirming role-based access controls, full version history, and a 10-year minimum retention period anchored to market placement date", "evidence_type": "audit-log", "verification": "automated" }, { "id": "RF-03-E5", "description": "Pre-submission documentation completeness review record with legal and compliance sign-off completed before notified body submission or CE declaration issuance", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "Art. 11 imposes a mandatory obligation on providers of high-risk AI systems to draw up technical documentation before market placement, and Annex IV specifies the required documentation sections. This control implements the documentation assembly and maintenance obligation in its entirety." }, { "control": "apeiris://model/controls/LI-07", "id": "LI-07", "domain": "model", "name": "Capability and Limitation Declaration \u2014 Intended Use, Constraints,...", "validation_objective": "Every registered model must have a structured, schema-validated capability-limitation declaration with all five required dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, and knowledge_cutoff) substantively populated with population- and context-qualified entries, returned as structured metadata in the model registry API response; registration must be blocked when any dimension is absent or empty; and the model's observable behavior for post-knowledge-cutoff queries must be consistent with the declared uncertainty_bounds.", "blocking_effect": "blocks-deployment", "evidence_required": [ "capability_limitation_declaration with all five dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, knowledge_cutoff) substantively populated with population-qualified and context-qualified entries, version-locked to the artifact hash", "registry_api_response_sample demonstrating that the capability_limitation_declaration object is returned as structured metadata in the model registry API response for the model's registered ID without requiring separate documentation lookup", "cutoff_behavior_test_result showing model responses to at least three post-knowledge-cutoff factual queries compared against the declared uncertainty_bounds, confirming the model acknowledges the limitation rather than confabulating confident answers", "registration_rejection_log showing that a model registration attempt with an empty out_of_scope_uses field was blocked with an error identifying the specific missing dimension" ], "evidence": [ { "id": "LI-07-E1", "description": "capability_limitation_declaration with all five dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, knowledge_cutoff) substantively populated with population-qualified and context-qualified entries, version-locked to the artifact hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E2", "description": "registry_api_response_sample demonstrating that the capability_limitation_declaration object is returned as structured metadata in the model registry API response for the model's registered ID without requiring separate documentation lookup", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E3", "description": "cutoff_behavior_test_result showing model responses to at least three post-knowledge-cutoff factual queries compared against the declared uncertainty_bounds, confirming the model acknowledges the limitation rather than confabulating confident answers", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E4", "description": "registration_rejection_log showing that a model registration attempt with an empty out_of_scope_uses field was blocked with an error identifying the specific missing dimension", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art-13 requires that high-risk AI systems be designed and developed such that deployers receive sufficient information to understand the system's capabilities and limitations and to implement appropriate human oversight. LI-07's structured capability-limitation declaration directly satisfies Art-13 by providing machine-readable, structured transparency information at the model consumption point." }, { "control": "apeiris://model/controls/LI-02", "id": "LI-02", "domain": "model", "name": "Model Provenance Chain \u2014 Base Model, Fine-Tune, Merge, and Adapter Lineage", "validation_objective": "Every registered model artifact must have a machine-readable provenance manifest recording the complete ancestry chain including the base model artifact hash and provider version, all fine-tuning steps with dataset references, all merge contributors with their artifact hashes, and all attached adapter components with source and base-model compatibility metadata; and the registry must expose a query interface that returns all derived models for a given base model artifact hash.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_provenance_manifest with typed structured fields for base_model_hash, base_model_provider_version, fine_tuning_steps[] each referencing a TG-layer dataset record, merge_contributors[] with per-contributor artifact hashes and merge parameters, and adapter_components[] with source, version, and base_model_compatibility_hash", "provenance_query_api_result showing all registry entries derived from a specified base model artifact hash, confirming complete downstream impact scope is retrievable by automated query", "registry_provenance_rejection_log showing that a model registration attempt with a missing required provenance field (e.g., absent base_model_hash) was blocked", "adapter_lineage_registry_entry for at least one production model with an attached LoRA or PEFT adapter, confirming adapter source and compatibility metadata are recorded" ], "evidence": [ { "id": "LI-02-E1", "description": "model_provenance_manifest with typed structured fields for base_model_hash, base_model_provider_version, fine_tuning_steps[] each referencing a TG-layer dataset record, merge_contributors[] with per-contributor artifact hashes and merge parameters, and adapter_components[] with source, version, and base_model_compatibility_hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-02-E2", "description": "provenance_query_api_result showing all registry entries derived from a specified base model artifact hash, confirming complete downstream impact scope is retrievable by automated query", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-02-E3", "description": "registry_provenance_rejection_log showing that a model registration attempt with a missing required provenance field (e.g., absent base_model_hash) was blocked", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "LI-02-E4", "description": "adapter_lineage_registry_entry for at least one production model with an attached LoRA or PEFT adapter, confirming adapter source and compatibility metadata are recorded", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "EU-AIA-ART11-02", "section": "Art. 11(2)", "title": "Technical documentation \u2014 must enable conformity assessment", "text": "The technical documentation shall be drawn up in such a way so as to demonstrate that the high-risk AI system complies with the requirements set out in this Section and shall contain, at a minimum, the elements set out in Annex IV.", "verdict": "partial", "coverage": "partial", "notes": "RF-03 produces the technical documentation package mapped to Annex IV elements. AU-02 (Evidence Collection, Curation, and Validation) curates the evidence artifacts that demonstrate compliance with each Annex IV item. AU-07 (Multi-Framework Evidence Reuse) allows evidence from other Apeiris domains to be reused in the technical documentation package. RF-02 (Conformity Assessment Pathway Selection) determines the correct conformity procedure. Partial: formal CE marking, EU declaration of conformity filing, and registration in the EU AI Act database (Art. 71) are regulatory legal acts outside Apeiris control scope.", "control_count": 4, "proof_chain": [ { "control": "apeiris://compliance/controls/RF-03", "id": "RF-03", "domain": "compliance", "name": "EU AI Act Technical Documentation Package (Art. 11)", "validation_objective": "Each high-risk AI system must have an Annex IV technical documentation package with all required sections substantively populated \u2014 no missing sections or placeholder content \u2014 version-controlled and linked to the current CE declaration, updated within 30 days of any qualifying model or deployment scope change, and retained in a controlled repository for 10 years from market placement date as required by Art. 18.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Annex IV completeness checklist per high-risk system with completion status for each required section, documentation owner sign-off, and compliance team approval date", "Technical documentation version history linking each documentation version to the corresponding model version, CE declaration version, and the change management ticket that triggered the update", "Model change management tickets with documentation update completion confirmation timestamp within 30 days of each qualifying model or deployment scope change event", "Documentation repository access log and retention policy configuration confirming role-based access controls, full version history, and a 10-year minimum retention period anchored to market placement date", "Pre-submission documentation completeness review record with legal and compliance sign-off completed before notified body submission or CE declaration issuance" ], "evidence": [ { "id": "RF-03-E1", "description": "Annex IV completeness checklist per high-risk system with completion status for each required section, documentation owner sign-off, and compliance team approval date", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RF-03-E2", "description": "Technical documentation version history linking each documentation version to the corresponding model version, CE declaration version, and the change management ticket that triggered the update", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RF-03-E3", "description": "Model change management tickets with documentation update completion confirmation timestamp within 30 days of each qualifying model or deployment scope change event", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RF-03-E4", "description": "Documentation repository access log and retention policy configuration confirming role-based access controls, full version history, and a 10-year minimum retention period anchored to market placement date", "evidence_type": "audit-log", "verification": "automated" }, { "id": "RF-03-E5", "description": "Pre-submission documentation completeness review record with legal and compliance sign-off completed before notified body submission or CE declaration issuance", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "Art. 11 imposes a mandatory obligation on providers of high-risk AI systems to draw up technical documentation before market placement, and Annex IV specifies the required documentation sections. This control implements the documentation assembly and maintenance obligation in its entirety." }, { "control": "apeiris://compliance/controls/RF-02", "id": "RF-02", "domain": "compliance", "name": "EU AI Act Conformity Assessment Pathway Selection", "validation_objective": "Every high-risk AI system in the classification register must have a conformity assessment pathway record specifying the Art. 43 legal basis for pathway selection, a named assessment owner, legal counsel sign-off, and a projected assessment timeline. For systems on the third-party pathway, notified body engagement evidence must show initiation at least 6 months before the projected market placement date. No high-risk system may reach market placement without a completed and legally signed pathway record.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Conformity pathway register export with system_id, pathway_type (internal/third-party), art_43_basis, assessment_owner, legal_sign_off_date, and projected_placement_date for each high-risk system", "Legal pathway selection opinion for each high-risk system citing the specific Art. 43 sub-clause and confirming the pathway type is legally permissible for the applicable Annex III category", "Notified body engagement records with engagement_initiation_date, notified_body_id, and projected assessment completion date for all third-party pathway systems", "CI/CD pipeline gate enforcement log confirming deployment was blocked for high-risk AI system images without a valid pathway record identifier in the release metadata", "Conformity pathway version history with change log linking each pathway record revision to the CE declaration version it supports" ], "evidence": [ { "id": "RF-02-E1", "description": "Conformity pathway register export with system_id, pathway_type (internal/third-party), art_43_basis, assessment_owner, legal_sign_off_date, and projected_placement_date for each high-risk system", "evidence_type": "third-party-audit-report", "verification": "third-party" }, { "id": "RF-02-E2", "description": "Legal pathway selection opinion for each high-risk system citing the specific Art. 43 sub-clause and confirming the pathway type is legally permissible for the applicable Annex III category", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RF-02-E3", "description": "Notified body engagement records with engagement_initiation_date, notified_body_id, and projected assessment completion date for all third-party pathway systems", "evidence_type": "third-party-audit-report", "verification": "third-party" }, { "id": "RF-02-E4", "description": "CI/CD pipeline gate enforcement log confirming deployment was blocked for high-risk AI system images without a valid pathway record identifier in the release metadata", "evidence_type": "audit-log", "verification": "automated" }, { "id": "RF-02-E5", "description": "Conformity pathway version history with change log linking each pathway record revision to the CE declaration version it supports", "evidence_type": "audit-log", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "Art. 43 is the primary operative provision governing conformity assessment pathway selection, distinguishing between systems that require notified body involvement and those eligible for internal assessment procedures. Compliance with this control is a mandatory prerequisite to lawful market placement of high-risk AI systems." }, { "control": "apeiris://compliance/controls/AU-02", "id": "AU-02", "domain": "compliance", "name": "Evidence Collection, Curation, and Validation", "validation_objective": "Every compliance evidence artifact in the active evidence library has a SHA-256 hash computed at the moment of collection, a documented source_system and collector_identity, a collection_timestamp within the required freshness window for its artifact type, and has passed all validation gate checks prior to promotion. No artifact with missing or failed provenance metadata exists in the active library.", "blocking_effect": "advisory", "evidence_required": [ "Evidence repository ingestion log showing source_system, collector_identity, collection_timestamp, and SHA-256_hash computed at ingest for every artifact collected during the audit period", "Validation gate rejection log documenting all artifacts that failed validation checks, the specific failure reason (missing hash, staleness, format error, incomplete metadata), and their disposition", "Manual curation workflow records for artifacts that bypassed automated validation, including curator identity, review method, artifact authenticity basis, and sign-off timestamp", "Monthly reconciliation reports comparing the artifact inventory against per-framework requirements, identifying collection gaps by artifact type and their age in days", "SHA-256 hash integrity verification report for the audit period confirming no mismatches between ingestion records and current artifact content in the repository" ], "evidence": [ { "id": "AU-02-E1", "description": "Evidence repository ingestion log showing source_system, collector_identity, collection_timestamp, and SHA-256_hash computed at ingest for every artifact collected during the audit period", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AU-02-E2", "description": "Validation gate rejection log documenting all artifacts that failed validation checks, the specific failure reason (missing hash, staleness, format error, incomplete metadata), and their disposition", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AU-02-E3", "description": "Manual curation workflow records for artifacts that bypassed automated validation, including curator identity, review method, artifact authenticity basis, and sign-off timestamp", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "AU-02-E4", "description": "Monthly reconciliation reports comparing the artifact inventory against per-framework requirements, identifying collection gaps by artifact type and their age in days", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AU-02-E5", "description": "SHA-256 hash integrity verification report for the audit period confirming no mismatches between ingestion records and current artifact content in the repository", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 18 requires providers of high-risk AI systems to draw up and keep technical documentation for inspection by competent authorities. Evidence collection and curation controls operationalize the ongoing maintenance of this documentation in a validated, retrievable form throughout the system lifecycle." }, { "control": "apeiris://compliance/controls/AU-07", "id": "AU-07", "domain": "compliance", "name": "Multi-Framework Evidence Reuse", "validation_objective": "The organization must maintain a cross-framework evidence mapping matrix and a master evidence repository in which at least 40% of evidence artifacts are tagged to satisfy more than one compliance framework obligation, with all framework-specific packages assembled exclusively from the master repository using the same artifact versions across all framework packages for any given compliance period, and the mapping matrix reviewed within 12 months or within 30 days of any framework version change.", "blocking_effect": "advisory", "evidence_required": [ "cross_framework_mapping_matrix with last review date within 12 months, listing all applicable frameworks, overlapping requirements, and evidence artifact IDs mapped to multiple framework obligations with substantive fit rationale for each mapping", "master_evidence_repository_export showing multi-framework tag assignments for each artifact, confirming the reuse rate (artifacts tagged to more than one framework as a percentage of total artifacts) is \u226540%", "framework_specific_package_generation_log confirming packages were assembled from the master repository for the last audit cycle, with source artifact IDs, version numbers, and framework destination recorded for each assembly run", "mapping_accuracy_review_report from the last quarterly review, documenting sampled reuse mappings with substantive accuracy verification results and any corrections applied to invalid mappings", "artifact_owner_assignment_record listing the single collection owner for each artifact type in the master repository with current assignment date and coverage plan for owner absence" ], "evidence": [ { "id": "AU-07-E1", "description": "cross_framework_mapping_matrix with last review date within 12 months, listing all applicable frameworks, overlapping requirements, and evidence artifact IDs mapped to multiple framework obligations with substantive fit rationale for each mapping", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AU-07-E2", "description": "master_evidence_repository_export showing multi-framework tag assignments for each artifact, confirming the reuse rate (artifacts tagged to more than one framework as a percentage of total artifacts) is \u226540%", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AU-07-E3", "description": "framework_specific_package_generation_log confirming packages were assembled from the master repository for the last audit cycle, with source artifact IDs, version numbers, and framework destination recorded for each assembly run", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AU-07-E4", "description": "mapping_accuracy_review_report from the last quarterly review, documenting sampled reuse mappings with substantive accuracy verification results and any corrections applied to invalid mappings", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AU-07-E5", "description": "artifact_owner_assignment_record listing the single collection owner for each artifact type in the master repository with current assignment date and coverage plan for owner absence", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "adjacent", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 17(1) requires quality management systems that integrate with other applicable regulatory requirements including ISO 9001 and ISO 27001. Multi-framework evidence reuse enables efficient integration of EU AI Act documentation requirements with existing ISO, SOC 2, and GDPR compliance programs without duplicative collection burden." } ] }, { "requirement_id": "EU-AIA-ART12-01", "section": "Art. 12(1)", "title": "Record-keeping \u2014 logging capabilities", "text": "High-risk AI systems shall technically allow for the automatic recording of events ('logs') over the lifetime of the system.", "verdict": "supported", "coverage": "direct", "notes": "BH-05 (Usage Telemetry and Decision Logging) mandates comprehensive event logging capturing inputs, outputs, confidence scores, model version, and user context for every AI decision. GV-02 (Immutable, tamper-evident audit trail) requires that these logs are protected from alteration \u2014 satisfying the 'automatic' and 'technical' logging requirements of Art. 12(1). AT-07 (Tool Usage Audit Trail) extends logging to cover tool calls made by agentic AI systems, which Art. 12 applies to.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/BH-05", "id": "BH-05", "domain": "model", "name": "Usage Telemetry and Decision Logging", "validation_objective": "Every model inference endpoint must emit a structured DecisionLog record containing input_hash (HMAC-SHA-256), caller_id, model_version, output_sample at the configured sampling rate, latency_ms, and decision_outcome; logs must be stored in an append-only tamper-evident store with daily Merkle root hash publication; and no direct PII must appear in any stored log field.", "blocking_effect": "advisory", "evidence_required": [ "DecisionLog schema documentation with field definitions, HMAC masking policy, key management system references, and output sampling rate configuration per deployment profile", "privacy review sign-off from the data protection team confirming no direct PII identifiers appear in stored log records, based on a regex scan of a trailing 30-day sample", "daily Merkle root hash publication log for trailing 90 days with fields: root_hash, computation_timestamp, and publication_destination for each daily entry", "retention policy configuration and automated deletion audit log confirming tiered retention enforcement (90-day raw, 3-year aggregated, 10-year minimum for EU high-risk deployments)", "DecisionLog query access audit trail for trailing 90 days showing all access events with requester_id, query_timestamp, and authorization_basis" ], "evidence": [ { "id": "BH-05-E1", "description": "DecisionLog schema documentation with field definitions, HMAC masking policy, key management system references, and output sampling rate configuration per deployment profile", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "BH-05-E2", "description": "privacy review sign-off from the data protection team confirming no direct PII identifiers appear in stored log records, based on a regex scan of a trailing 30-day sample", "evidence_type": "audit-log", "verification": "automated" }, { "id": "BH-05-E3", "description": "daily Merkle root hash publication log for trailing 90 days with fields: root_hash, computation_timestamp, and publication_destination for each daily entry", "evidence_type": "audit-log", "verification": "automated" }, { "id": "BH-05-E4", "description": "retention policy configuration and automated deletion audit log confirming tiered retention enforcement (90-day raw, 3-year aggregated, 10-year minimum for EU high-risk deployments)", "evidence_type": "audit-log", "verification": "automated" }, { "id": "BH-05-E5", "description": "DecisionLog query access audit trail for trailing 90 days showing all access events with requester_id, query_timestamp, and authorization_basis", "evidence_type": "audit-log", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 12 requires high-risk AI systems to have the capability to automatically generate logs of operation; BH-05 directly implements this by mandating structured log emission for every inference \u2014 capturing input hash, output hash, decision path, confidence score, and latency \u2014 with 7-year retention using WORM-locked storage and a structured schema. Art. 16(h) additionally requires providers to keep automatically generated logs." }, { "control": "apeiris://security/controls/GV-02", "id": "GV-02", "domain": "security", "name": "Keep an immutable, tamper-evident audit trail of what the agent did", "validation_objective": "Every agent action, state mutation, tool invocation, and decision must be recorded in an append-only, tamper-evident store with cryptographic integrity guarantees (hash-chaining or Merkle anchoring held outside the agent platform's trust boundary); any attempt to modify or delete an audit entry must be rejected by the store and remain detectable via inclusion proof.", "blocking_effect": "advisory", "evidence_required": [ "merkle_anchor_record with root_hash, anchoring_timestamp, and external anchor reference for each audit batch, proving the chain was not retroactively modified", "inclusion_proof_sample showing cryptographic proof that a representative set of action entries exist in the verified tree without gaps", "audit_store_isolation_record confirming the audit store is outside the agent platform's trust boundary and no agent process holds delete or modify privileges on the store", "retention_policy_record confirming audit entries are retained for the required regulatory horizon and are not subject to automated deletion by routine data lifecycle processes", "chain_of_custody_record for each multi-agent or human-agent handoff, capturing actor_identity, action, and timestamp for every hop" ], "evidence": [ { "id": "GV-02-E1", "description": "merkle_anchor_record with root_hash, anchoring_timestamp, and external anchor reference for each audit batch, proving the chain was not retroactively modified", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-02-E2", "description": "inclusion_proof_sample showing cryptographic proof that a representative set of action entries exist in the verified tree without gaps", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-02-E3", "description": "audit_store_isolation_record confirming the audit store is outside the agent platform's trust boundary and no agent process holds delete or modify privileges on the store", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-02-E4", "description": "retention_policy_record confirming audit entries are retained for the required regulatory horizon and are not subject to automated deletion by routine data lifecycle processes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-02-E5", "description": "chain_of_custody_record for each multi-agent or human-agent handoff, capturing actor_identity, action, and timestamp for every hop", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "adjacent", "basis": "anchored", "relation": "satisfies", "rationale": null }, { "control": "apeiris://agentic/controls/AT-07", "id": "AT-07", "domain": "agentic", "name": "Tool Usage Audit Trail", "validation_objective": "Proves that every tool call \u2014 including blocked calls \u2014 generates a complete, tamper-evident log record containing agent identity, tool ID, full input parameters for dangerous tools, response summary, authorization record reference, timestamp, and outcome, and that the log storage detects any post-write modification. No tool invocation may execute or be blocked without a corresponding audit record.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "Log completeness verification report comparing tool call counts in execution metrics against audit trail records for the same period, with zero unexplained gaps", "Hash chain integrity verification report for recent log batches confirming no tampering has been detected", "Sample log records for dangerous tool invocations confirming full (non-truncated) input parameters are captured", "SIEM or centralized logging retention configuration showing the retention period meets the longest applicable regulatory requirement", "Log pipeline health monitoring records confirming no dropped records due to write failures in the audit period" ], "evidence": [ { "id": "AT-07-E1", "description": "Log completeness verification report comparing tool call counts in execution metrics against audit trail records for the same period, with zero unexplained gaps", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AT-07-E2", "description": "Hash chain integrity verification report for recent log batches confirming no tampering has been detected", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AT-07-E3", "description": "Sample log records for dangerous tool invocations confirming full (non-truncated) input parameters are captured", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AT-07-E4", "description": "SIEM or centralized logging retention configuration showing the retention period meets the longest applicable regulatory requirement", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "AT-07-E5", "description": "Log pipeline health monitoring records confirming no dropped records due to write failures in the audit period", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 12 mandates that high-risk AI systems automatically generate logs of their operation to enable post-market monitoring and investigation of incidents. A comprehensive tool usage audit trail directly satisfies this requirement by capturing a complete record of all agent actions through tool invocations. Article 12 specifically requires that log records be sufficient to enable tracing of AI system behavior over the period relevant to regulatory oversight." } ] }, { "requirement_id": "EU-AIA-ART12-02", "section": "Art. 12(2)", "title": "Record-keeping \u2014 automatic logging throughout lifecycle", "text": "The logging capabilities shall ensure a level of traceability of the AI system's functioning throughout its lifecycle that is appropriate to the intended purpose of the system, and shall at a minimum allow for the identification of the time period during which the system was used.", "verdict": "supported", "coverage": "direct", "notes": "BH-05 captures timestamped event records with session metadata enabling reconstruction of usage periods. RT-01 (Capture OS-level telemetry of what the agent actually does) provides the infrastructure-layer telemetry that complements model-layer logging for full lifecycle traceability. AM-01 (Behavioral Telemetry Collection Baseline) establishes the baseline telemetry collection covering all agentic actions. DL-03 (Inference-Time Data Lineage \u2014 Per-Decision Provenance) provides per-decision lineage linking each output to its input data, model version, and execution timestamp.", "control_count": 4, "proof_chain": [ { "control": "apeiris://model/controls/BH-05", "id": "BH-05", "domain": "model", "name": "Usage Telemetry and Decision Logging", "validation_objective": "Every model inference endpoint must emit a structured DecisionLog record containing input_hash (HMAC-SHA-256), caller_id, model_version, output_sample at the configured sampling rate, latency_ms, and decision_outcome; logs must be stored in an append-only tamper-evident store with daily Merkle root hash publication; and no direct PII must appear in any stored log field.", "blocking_effect": "advisory", "evidence_required": [ "DecisionLog schema documentation with field definitions, HMAC masking policy, key management system references, and output sampling rate configuration per deployment profile", "privacy review sign-off from the data protection team confirming no direct PII identifiers appear in stored log records, based on a regex scan of a trailing 30-day sample", "daily Merkle root hash publication log for trailing 90 days with fields: root_hash, computation_timestamp, and publication_destination for each daily entry", "retention policy configuration and automated deletion audit log confirming tiered retention enforcement (90-day raw, 3-year aggregated, 10-year minimum for EU high-risk deployments)", "DecisionLog query access audit trail for trailing 90 days showing all access events with requester_id, query_timestamp, and authorization_basis" ], "evidence": [ { "id": "BH-05-E1", "description": "DecisionLog schema documentation with field definitions, HMAC masking policy, key management system references, and output sampling rate configuration per deployment profile", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "BH-05-E2", "description": "privacy review sign-off from the data protection team confirming no direct PII identifiers appear in stored log records, based on a regex scan of a trailing 30-day sample", "evidence_type": "audit-log", "verification": "automated" }, { "id": "BH-05-E3", "description": "daily Merkle root hash publication log for trailing 90 days with fields: root_hash, computation_timestamp, and publication_destination for each daily entry", "evidence_type": "audit-log", "verification": "automated" }, { "id": "BH-05-E4", "description": "retention policy configuration and automated deletion audit log confirming tiered retention enforcement (90-day raw, 3-year aggregated, 10-year minimum for EU high-risk deployments)", "evidence_type": "audit-log", "verification": "automated" }, { "id": "BH-05-E5", "description": "DecisionLog query access audit trail for trailing 90 days showing all access events with requester_id, query_timestamp, and authorization_basis", "evidence_type": "audit-log", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 12 requires high-risk AI systems to have the capability to automatically generate logs of operation; BH-05 directly implements this by mandating structured log emission for every inference \u2014 capturing input hash, output hash, decision path, confidence score, and latency \u2014 with 7-year retention using WORM-locked storage and a structured schema. Art. 16(h) additionally requires providers to keep automatically generated logs." }, { "control": "apeiris://security/controls/RT-01", "id": "RT-01", "domain": "security", "name": "Capture OS-level telemetry of what the agent actually does", "validation_objective": "The system must capture full OS-level telemetry \u2014 process tree, file I/O, and network calls \u2014 for every agent execution, with each event stamped with the agent's verified identity and correlated to a run_id and tool_call_id. All agent activity on instrumented hosts must be attributable to a specific agent identity with no observability gaps at the OS layer.", "blocking_effect": "advisory", "evidence_required": [ "edr_process_lineage_records for each agent run showing agent_id, run_id, parent_process, child_processes, file_ops, and net_calls", "telemetry_coverage_report confirming EDR instrumentation is active on all hosts where agents execute, with deployment-mode-specific coverage documented for container, VM, and serverless modes", "agent_identity_correlation_log confirming OS-level events are stamped with agent_id and mapped to run_id and goal_id so low-level events resolve to agent intent", "unsanctioned_process_alert_log showing EDR flagged an off-manifest child process or binary during a validation test with the triggering run_id recorded" ], "evidence": [ { "id": "RT-01-E1", "description": "edr_process_lineage_records for each agent run showing agent_id, run_id, parent_process, child_processes, file_ops, and net_calls", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-01-E2", "description": "telemetry_coverage_report confirming EDR instrumentation is active on all hosts where agents execute, with deployment-mode-specific coverage documented for container, VM, and serverless modes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-01-E3", "description": "agent_identity_correlation_log confirming OS-level events are stamped with agent_id and mapped to run_id and goal_id so low-level events resolve to agent intent", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-01-E4", "description": "unsanctioned_process_alert_log showing EDR flagged an off-manifest child process or binary during a validation test with the triggering run_id recorded", "evidence_type": "automated-test-result", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://agentic/controls/AM-01", "id": "AM-01", "domain": "agentic", "name": "Behavioral Telemetry Collection Baseline", "validation_objective": "Proves that every registered production agent emits a schema-validated, minimum signal set \u2014 covering action type, tool invocations, token consumption, session boundaries, and decision rationale traces \u2014 to an append-only telemetry store, with 100% coverage of registered agents demonstrable within the prior 24-hour window.", "blocking_effect": "advisory", "evidence_required": [ "Telemetry schema version registry showing current schema version and change history with change-management approval records", "Agent registry cross-referenced with telemetry coverage report identifying any registered agents with no telemetry events in the prior 24 hours", "Schema validation rejection rate report for the prior 7 days, with alert records for any rejection rate above 0.1%", "Five sample agent session traces each demonstrating a continuous telemetry record from session_start to session_end with all required baseline fields", "Telemetry pipeline SLO report covering ingestion latency, throughput capacity, and event loss rate" ], "evidence": [ { "id": "AM-01-E1", "description": "Telemetry schema version registry showing current schema version and change history with change-management approval records", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AM-01-E2", "description": "Agent registry cross-referenced with telemetry coverage report identifying any registered agents with no telemetry events in the prior 24 hours", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AM-01-E3", "description": "Schema validation rejection rate report for the prior 7 days, with alert records for any rejection rate above 0.1%", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "AM-01-E4", "description": "Five sample agent session traces each demonstrating a continuous telemetry record from session_start to session_end with all required baseline fields", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AM-01-E5", "description": "Telemetry pipeline SLO report covering ingestion latency, throughput capacity, and event loss rate", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 12 mandates automatic logging of events for high-risk AI systems sufficient to enable post-market monitoring and incident investigation. Behavioral telemetry is the technical implementation of this logging obligation. The baseline schema directly maps to the Art. 12(2) requirement to capture system inputs where feasible." }, { "control": "apeiris://data/controls/DL-03", "id": "DL-03", "domain": "data", "name": "Inference-Time Data Lineage (Per-Decision Provenance)", "validation_objective": "For every inference request processed by a high-risk AI system, a provenance record must be created and stored in an append-only log containing inference_id, timestamp, model_version, input_data_identifiers, retrieved_context_record_ids (for RAG systems), and output_record_reference \u2014 and this record must be retrievable via the provenance lookup API for the full duration of the applicable regulatory retention period.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "inference_provenance_log_sample covering a statistically representative set of inference requests, confirming all mandatory fields (inference_id, timestamp, model_version, input_record_ids, output_record_reference) are populated with no null values", "rag_retrieval_provenance_records for RAG-augmented inference systems, showing retrieved_chunk_ids, source_dataset_version, and relevance_scores for each retrieval event linked to its inference_id", "provenance_lookup_api_test_results confirming successful retrieval of complete provenance records for 100% of sampled inference IDs within the retention window, with HTTP 200 responses and all required fields present", "retention_policy_documentation specifying the legal basis for the defined retention period, confirmation that the platform enforces deletion only after the period expires, and evidence the policy has been reviewed by legal counsel" ], "evidence": [ { "id": "DL-03-E1", "description": "inference_provenance_log_sample covering a statistically representative set of inference requests, confirming all mandatory fields (inference_id, timestamp, model_version, input_record_ids, output_record_reference) are populated with no null values", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "DL-03-E2", "description": "rag_retrieval_provenance_records for RAG-augmented inference systems, showing retrieved_chunk_ids, source_dataset_version, and relevance_scores for each retrieval event linked to its inference_id", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "DL-03-E3", "description": "provenance_lookup_api_test_results confirming successful retrieval of complete provenance records for 100% of sampled inference IDs within the retention window, with HTTP 200 responses and all required fields present", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "DL-03-E4", "description": "retention_policy_documentation specifying the legal basis for the defined retention period, confirmation that the platform enforces deletion only after the period expires, and evidence the policy has been reviewed by legal counsel", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 12(1) requires high-risk AI systems to be designed and developed with capabilities enabling automatic logging of events to the degree appropriate for their intended purpose. Per-decision provenance records are the primary mechanism for satisfying this logging obligation at the granularity required by the regulation." } ] }, { "requirement_id": "EU-AIA-ART12-03", "section": "Art. 12(3)", "title": "Record-keeping \u2014 deployer retention of logs", "text": "For high-risk AI systems referred to in Annex III, point 1, the logging capabilities shall, to the extent technically feasible, meet the requirements set out in Annex XII. Deployers shall retain the logs generated by the high-risk AI system.", "verdict": "partial", "coverage": "partial", "notes": "AU-04 (Audit Trail Integrity) governs log retention policies and technical controls ensuring logs remain intact. CR-02 (Model Evidence Archive and Audit Trail) maintains model-layer decision logs as part of the evidence archive. GV-02 enforces tamper-evidence for retained logs. Partial: deployer-specific retention obligations, particularly the specific duration and scope for biometric identification systems (Annex XII), may require jurisdiction-specific configuration beyond standard Apeiris retention controls.", "control_count": 3, "proof_chain": [ { "control": "apeiris://compliance/controls/AU-04", "id": "AU-04", "domain": "compliance", "name": "Audit Trail Integrity", "validation_objective": "The audit log system must maintain a cryptographically chained, append-only record of all compliance program activities \u2014 including policy attestations, control assessments, evidence submissions, and configuration changes \u2014 such that any attempt to modify, delete, or insert log records is detectable within 24 hours of occurrence. Automated daily hash chain verification must confirm log integrity continuously and alert the compliance officer within 1 hour of any detected break.", "blocking_effect": "advisory", "evidence_required": [ "cryptographic_hash_chain_report listing hash values for each log batch and chain linkage between successive batches, covering the full audit period with no unexplained gaps", "WORM_storage_replication_log confirming each log batch was replicated to immutable secondary store within 60 seconds, with source generation timestamp and secondary write timestamp for each batch", "daily_integrity_verification_report showing automated hash chain verification results, detected breaks, and alert dispatch timestamps for each verification run in the last 30 days", "log_custody_register documenting all personnel with access to log infrastructure, last quarterly access review date, and access removal records for personnel no longer requiring access", "log_gap_analysis_report confirming no unexplained gaps in log sequence numbers or timestamps for the audit period" ], "evidence": [ { "id": "AU-04-E1", "description": "cryptographic_hash_chain_report listing hash values for each log batch and chain linkage between successive batches, covering the full audit period with no unexplained gaps", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AU-04-E2", "description": "WORM_storage_replication_log confirming each log batch was replicated to immutable secondary store within 60 seconds, with source generation timestamp and secondary write timestamp for each batch", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AU-04-E3", "description": "daily_integrity_verification_report showing automated hash chain verification results, detected breaks, and alert dispatch timestamps for each verification run in the last 30 days", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "AU-04-E4", "description": "log_custody_register documenting all personnel with access to log infrastructure, last quarterly access review date, and access removal records for personnel no longer requiring access", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AU-04-E5", "description": "log_gap_analysis_report confirming no unexplained gaps in log sequence numbers or timestamps for the audit period", "evidence_type": "audit-log", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 12 requires high-risk AI systems to automatically generate logs to enable traceability and monitoring. Tamper-evident audit trail controls ensure these mandatory logs are protected from modification and retain their evidentiary value for market surveillance authority review throughout the required retention period." }, { "control": "apeiris://model/controls/CR-02", "id": "CR-02", "domain": "model", "name": "Model Evidence Archive and Audit Trail", "validation_objective": "All evaluation results, monitoring snapshots, incident records, and regulatory submissions must be stored in an immutable, content-addressed archive with cryptographic integrity protection; any audit query for a model's historical evidence must resolve to a complete, tamper-evident chain spanning the full production lifetime of that model version.", "blocking_effect": "blocks-deployment", "evidence_required": [ "archive_integrity_configuration_record showing content-addressed storage settings, hash algorithm (minimum SHA-256), write-once immutability enforcement, and retention policy duration per record type", "evidence_chain_completeness_audit confirming that evaluation results, monitoring snapshots, and incident records for each production model version are present in the archive with no missing lifecycle entries", "tamper_detection_scan_report from periodic archive integrity verification showing all stored records produce matching content hashes with zero reported mismatches", "regulatory_submission_evidence_linkage_record linking each regulatory submission to its archived evidence artifact with submission_id, submission_date, submitting_entity, and archive_content_hash", "archive_access_control_audit_log confirming write operations are restricted to authorized pipeline components only and all access attempts are logged with actor_id and timestamp" ], "evidence": [ { "id": "CR-02-E1", "description": "archive_integrity_configuration_record showing content-addressed storage settings, hash algorithm (minimum SHA-256), write-once immutability enforcement, and retention policy duration per record type", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "CR-02-E2", "description": "evidence_chain_completeness_audit confirming that evaluation results, monitoring snapshots, and incident records for each production model version are present in the archive with no missing lifecycle entries", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-02-E3", "description": "tamper_detection_scan_report from periodic archive integrity verification showing all stored records produce matching content hashes with zero reported mismatches", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-02-E4", "description": "regulatory_submission_evidence_linkage_record linking each regulatory submission to its archived evidence artifact with submission_id, submission_date, submitting_entity, and archive_content_hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-02-E5", "description": "archive_access_control_audit_log confirming write operations are restricted to authorized pipeline components only and all access attempts are logged with actor_id and timestamp", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 11 requires providers of high-risk AI systems to draw up technical documentation that includes records of evaluation results and post-market monitoring findings; CR-02's immutable content-addressed evidence archive \u2014 anchored to Sigstore Rekor and locked with S3 Object Lock COMPLIANCE mode \u2014 provides the tamper-evident records infrastructure required to produce and maintain the Art. 11 technical documentation over the required retention period." }, { "control": "apeiris://security/controls/GV-02", "id": "GV-02", "domain": "security", "name": "Keep an immutable, tamper-evident audit trail of what the agent did", "validation_objective": "Every agent action, state mutation, tool invocation, and decision must be recorded in an append-only, tamper-evident store with cryptographic integrity guarantees (hash-chaining or Merkle anchoring held outside the agent platform's trust boundary); any attempt to modify or delete an audit entry must be rejected by the store and remain detectable via inclusion proof.", "blocking_effect": "advisory", "evidence_required": [ "merkle_anchor_record with root_hash, anchoring_timestamp, and external anchor reference for each audit batch, proving the chain was not retroactively modified", "inclusion_proof_sample showing cryptographic proof that a representative set of action entries exist in the verified tree without gaps", "audit_store_isolation_record confirming the audit store is outside the agent platform's trust boundary and no agent process holds delete or modify privileges on the store", "retention_policy_record confirming audit entries are retained for the required regulatory horizon and are not subject to automated deletion by routine data lifecycle processes", "chain_of_custody_record for each multi-agent or human-agent handoff, capturing actor_identity, action, and timestamp for every hop" ], "evidence": [ { "id": "GV-02-E1", "description": "merkle_anchor_record with root_hash, anchoring_timestamp, and external anchor reference for each audit batch, proving the chain was not retroactively modified", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-02-E2", "description": "inclusion_proof_sample showing cryptographic proof that a representative set of action entries exist in the verified tree without gaps", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-02-E3", "description": "audit_store_isolation_record confirming the audit store is outside the agent platform's trust boundary and no agent process holds delete or modify privileges on the store", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-02-E4", "description": "retention_policy_record confirming audit entries are retained for the required regulatory horizon and are not subject to automated deletion by routine data lifecycle processes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-02-E5", "description": "chain_of_custody_record for each multi-agent or human-agent handoff, capturing actor_identity, action, and timestamp for every hop", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "adjacent", "basis": "anchored", "relation": "satisfies", "rationale": null } ] }, { "requirement_id": "EU-AIA-ART13-01", "section": "Art. 13(1)", "title": "Transparency \u2014 sufficiently transparent operation", "text": "High-risk AI systems shall be designed and developed in such a way as to ensure that their operation is sufficiently transparent to enable deployers to interpret the system's output and use it appropriately.", "verdict": "supported", "coverage": "direct", "notes": "XP-01 (Explainability Method Selection and Justification) requires that appropriate explainability methods are selected and integrated into the system design, enabling deployers to understand outputs. XP-05 (Model Card and System Card Transparency Disclosure) provides the system-level transparency disclosure consumed by deployers. LI-07 (Capability and Limitation Declaration) documents the operational envelope, known limitations, and appropriate use cases. XP-06 (Technical vs. Non-Technical Explanation Tiers) ensures that deployer-facing explanations are calibrated to the deployer's technical level.", "control_count": 4, "proof_chain": [ { "control": "apeiris://ethics/controls/XP-01", "id": "XP-01", "domain": "ethics", "name": "Explainability Method Selection and Justification", "validation_objective": "Every high-stakes AI system in production has a documented explainability method selection record in the approved registry, including a written justification that names the method, the model type it covers, known fidelity limitations, regulatory requirements satisfied, and alternative methods considered; and no high-stakes model was promoted to production without ethics officer sign-off on method selection.", "blocking_effect": "blocks-deployment", "evidence_required": [ "explainability_method_registry document listing each model type and decision-stakes combination mapped to approved methods, with version date and reviewing authority signature", "method_selection_justification_record per model deployment with fields: model_id, model_type, decision_stakes_tier, selected_method, fidelity_limitations, regulatory_requirements_satisfied, alternative_methods_considered, and ethics_officer_sign_off_date", "deployment_gate_approval_record showing explainability method approval was a required gate in the model deployment pipeline for each high-stakes model", "model_card entry for each model showing the selected explainability method and its documented limitations" ], "evidence": [ { "id": "XP-01-E1", "description": "explainability_method_registry document listing each model type and decision-stakes combination mapped to approved methods, with version date and reviewing authority signature", "evidence_type": "human-review-record", "verification": "human" }, { "id": "XP-01-E2", "description": "method_selection_justification_record per model deployment with fields: model_id, model_type, decision_stakes_tier, selected_method, fidelity_limitations, regulatory_requirements_satisfied, alternative_methods_considered, and ethics_officer_sign_off_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "XP-01-E3", "description": "deployment_gate_approval_record showing explainability method approval was a required gate in the model deployment pipeline for each high-stakes model", "evidence_type": "human-review-record", "verification": "human" }, { "id": "XP-01-E4", "description": "model_card entry for each model showing the selected explainability method and its documented limitations", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 13 requires that high-risk AI systems be designed to allow deployers to interpret the system's output. Method selection directly determines whether interpretation is possible. Selecting an inapplicable method can render compliance impossible regardless of implementation effort." }, { "control": "apeiris://ethics/controls/XP-05", "id": "XP-05", "domain": "ethics", "name": "Model Card and System Card Transparency Disclosure", "validation_objective": "Every AI system deployed in a high-stakes or public-facing context has a current published model card or system card that accurately represents the system's capabilities, limitations, intended use, known failure modes, and fairness evaluation results; cards are version-controlled and updated when the system undergoes material changes; and no high-stakes AI system is in production without a current card accessible to deployers and affected stakeholders.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_card_or_system_card document per AI system with required fields: system_id, model_version, intended_use, out_of_scope_uses, known_limitations, failure_modes, fairness_evaluation_results (metric name, value, demographic group, evaluation_date), and last_updated_date", "model_card_version_history log showing card updates aligned to model changes with delta description for each version", "card_publication_record confirming the card is accessible at a documented public or deployer-accessible URL before the system was deployed", "material_change_review_log showing that each model retraining, feature change, or scope expansion triggered a card update review with decision to update or document rationale for no-update" ], "evidence": [ { "id": "XP-05-E1", "description": "model_card_or_system_card document per AI system with required fields: system_id, model_version, intended_use, out_of_scope_uses, known_limitations, failure_modes, fairness_evaluation_results (metric name, value, demographic group, evaluation_date), and last_updated_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "XP-05-E2", "description": "model_card_version_history log showing card updates aligned to model changes with delta description for each version", "evidence_type": "audit-log", "verification": "automated" }, { "id": "XP-05-E3", "description": "card_publication_record confirming the card is accessible at a documented public or deployer-accessible URL before the system was deployed", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "XP-05-E4", "description": "material_change_review_log showing that each model retraining, feature change, or scope expansion triggered a card update review with decision to update or document rationale for no-update", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 11 and Annex IV require high-risk AI providers to maintain comprehensive technical documentation including system description, design choices, performance metrics, and known limitations. Model cards directly instantiate this requirement in a standardized, reviewable format." }, { "control": "apeiris://model/controls/LI-07", "id": "LI-07", "domain": "model", "name": "Capability and Limitation Declaration \u2014 Intended Use, Constraints,...", "validation_objective": "Every registered model must have a structured, schema-validated capability-limitation declaration with all five required dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, and knowledge_cutoff) substantively populated with population- and context-qualified entries, returned as structured metadata in the model registry API response; registration must be blocked when any dimension is absent or empty; and the model's observable behavior for post-knowledge-cutoff queries must be consistent with the declared uncertainty_bounds.", "blocking_effect": "blocks-deployment", "evidence_required": [ "capability_limitation_declaration with all five dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, knowledge_cutoff) substantively populated with population-qualified and context-qualified entries, version-locked to the artifact hash", "registry_api_response_sample demonstrating that the capability_limitation_declaration object is returned as structured metadata in the model registry API response for the model's registered ID without requiring separate documentation lookup", "cutoff_behavior_test_result showing model responses to at least three post-knowledge-cutoff factual queries compared against the declared uncertainty_bounds, confirming the model acknowledges the limitation rather than confabulating confident answers", "registration_rejection_log showing that a model registration attempt with an empty out_of_scope_uses field was blocked with an error identifying the specific missing dimension" ], "evidence": [ { "id": "LI-07-E1", "description": "capability_limitation_declaration with all five dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, knowledge_cutoff) substantively populated with population-qualified and context-qualified entries, version-locked to the artifact hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E2", "description": "registry_api_response_sample demonstrating that the capability_limitation_declaration object is returned as structured metadata in the model registry API response for the model's registered ID without requiring separate documentation lookup", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E3", "description": "cutoff_behavior_test_result showing model responses to at least three post-knowledge-cutoff factual queries compared against the declared uncertainty_bounds, confirming the model acknowledges the limitation rather than confabulating confident answers", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E4", "description": "registration_rejection_log showing that a model registration attempt with an empty out_of_scope_uses field was blocked with an error identifying the specific missing dimension", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art-13 requires that high-risk AI systems be designed and developed such that deployers receive sufficient information to understand the system's capabilities and limitations and to implement appropriate human oversight. LI-07's structured capability-limitation declaration directly satisfies Art-13 by providing machine-readable, structured transparency information at the model consumption point." }, { "control": "apeiris://ethics/controls/XP-06", "id": "XP-06", "domain": "ethics", "name": "Technical vs. Non-Technical Explanation Tiers", "validation_objective": "All AI decision systems classified as requiring explanations must implement a minimum three-tier explanation structure (affected-individual plain-language, business-operational summary, technical audit log) that accurately represents the decision at each tier without distortion. Tier-1 individual explanations must pass intelligibility review with representative target audience members prior to production.", "blocking_effect": "blocks-deployment", "evidence_required": [ "explanation_tier_matrix document mapping each audience type (affected individual, business user, technical reviewer, regulator) to required explanation format, depth, and delivery mechanism for each high-stakes AI system", "tier-1 plain-language explanation samples with intelligibility testing records showing comprehension scores from representative target audience participants", "tier-3 technical audit log samples showing feature attribution, model version, and decision factors with cross-reference to corresponding tier-1 explanation for accuracy comparison", "access control configuration records confirming tier-1 explanations are accessible to affected individuals on demand within legally required timeframes", "tier translation methodology documentation showing how technical attribution outputs map to plain-language explanations without material inaccuracy" ], "evidence": [ { "id": "XP-06-E1", "description": "explanation_tier_matrix document mapping each audience type (affected individual, business user, technical reviewer, regulator) to required explanation format, depth, and delivery mechanism for each high-stakes AI system", "evidence_type": "human-review-record", "verification": "human" }, { "id": "XP-06-E2", "description": "tier-1 plain-language explanation samples with intelligibility testing records showing comprehension scores from representative target audience participants", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "XP-06-E3", "description": "tier-3 technical audit log samples showing feature attribution, model version, and decision factors with cross-reference to corresponding tier-1 explanation for accuracy comparison", "evidence_type": "audit-log", "verification": "automated" }, { "id": "XP-06-E4", "description": "access control configuration records confirming tier-1 explanations are accessible to affected individuals on demand within legally required timeframes", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "XP-06-E5", "description": "tier translation methodology documentation showing how technical attribution outputs map to plain-language explanations without material inaccuracy", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 13 requires that high-risk AI systems provide information accessible to deployers, and Art. 86 requires that affected individuals receive explanations in a clear and meaningful form. The tiered explanation framework directly implements both requirements by ensuring each audience receives calibrated information." } ] }, { "requirement_id": "EU-AIA-ART13-02", "section": "Art. 13(2)", "title": "Transparency \u2014 instructions for use", "text": "High-risk AI systems shall be accompanied by instructions for use in an appropriate digital format that include concise, complete, correct, and clear information that is relevant, accessible, and comprehensible to deployers.", "verdict": "supported", "coverage": "direct", "notes": "LI-04 (Structured Model Documentation \u2014 Complete Model Card) requires a complete model card with all required sections including intended use, performance characteristics, and operational guidance, which serves as the primary instructions for use. LI-07 (Capability and Limitation Declaration) provides the capabilities, constraints, and appropriate-use guidance component. XP-06 (Technical vs. Non-Technical Explanation Tiers) ensures documentation is calibrated to deployer comprehension level.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/LI-04", "id": "LI-04", "domain": "model", "name": "Structured Model Documentation \u2014 Complete Model Card with All Required Sections", "validation_objective": "Every model submitted for registration must have a schema-validated model card with all nine Mitchell et al. 2019 sections substantively populated and passing field-level validation rules; the model card must be version-locked to the artifact hash and returned as structured metadata from the registry API; and registration must be blocked when any required section is absent, empty, or contains only placeholder text.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_card_completeness_validation_report showing pass/fail status per section with field-level validation results, registration blocking decision, and validation timestamp for the current artifact version", "versioned_model_card artifact linked to the specific model artifact hash with all nine Mitchell et al. sections containing substantive content (not placeholder text), retrievable from the registry by artifact hash", "model_registry_entry showing the current model card version hash stored alongside the artifact hash as paired immutable fields", "eu_ai_act_annex_iv_supplemental_record for EU AI Act high-risk in-scope systems confirming Annex IV technical documentation fields are populated in addition to the nine Mitchell et al. sections" ], "evidence": [ { "id": "LI-04-E1", "description": "model_card_completeness_validation_report showing pass/fail status per section with field-level validation results, registration blocking decision, and validation timestamp for the current artifact version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-04-E2", "description": "versioned_model_card artifact linked to the specific model artifact hash with all nine Mitchell et al. sections containing substantive content (not placeholder text), retrievable from the registry by artifact hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-04-E3", "description": "model_registry_entry showing the current model card version hash stored alongside the artifact hash as paired immutable fields", "evidence_type": "model-card", "verification": "attested" }, { "id": "LI-04-E4", "description": "eu_ai_act_annex_iv_supplemental_record for EU AI Act high-risk in-scope systems confirming Annex IV technical documentation fields are populated in addition to the nine Mitchell et al. sections", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art-11 requires providers of high-risk AI systems to prepare and maintain technical documentation before market placement. The Mitchell et al. 9-section model card supplemented with Annex IV fields directly satisfies Art-11's technical documentation requirement. This control supports satisfaction of Art-11 for covered deployments; applicability depends on the deployer's role (provider vs. deployer) and the system's high-risk classification." }, { "control": "apeiris://model/controls/LI-07", "id": "LI-07", "domain": "model", "name": "Capability and Limitation Declaration \u2014 Intended Use, Constraints,...", "validation_objective": "Every registered model must have a structured, schema-validated capability-limitation declaration with all five required dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, and knowledge_cutoff) substantively populated with population- and context-qualified entries, returned as structured metadata in the model registry API response; registration must be blocked when any dimension is absent or empty; and the model's observable behavior for post-knowledge-cutoff queries must be consistent with the declared uncertainty_bounds.", "blocking_effect": "blocks-deployment", "evidence_required": [ "capability_limitation_declaration with all five dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, knowledge_cutoff) substantively populated with population-qualified and context-qualified entries, version-locked to the artifact hash", "registry_api_response_sample demonstrating that the capability_limitation_declaration object is returned as structured metadata in the model registry API response for the model's registered ID without requiring separate documentation lookup", "cutoff_behavior_test_result showing model responses to at least three post-knowledge-cutoff factual queries compared against the declared uncertainty_bounds, confirming the model acknowledges the limitation rather than confabulating confident answers", "registration_rejection_log showing that a model registration attempt with an empty out_of_scope_uses field was blocked with an error identifying the specific missing dimension" ], "evidence": [ { "id": "LI-07-E1", "description": "capability_limitation_declaration with all five dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, knowledge_cutoff) substantively populated with population-qualified and context-qualified entries, version-locked to the artifact hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E2", "description": "registry_api_response_sample demonstrating that the capability_limitation_declaration object is returned as structured metadata in the model registry API response for the model's registered ID without requiring separate documentation lookup", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E3", "description": "cutoff_behavior_test_result showing model responses to at least three post-knowledge-cutoff factual queries compared against the declared uncertainty_bounds, confirming the model acknowledges the limitation rather than confabulating confident answers", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E4", "description": "registration_rejection_log showing that a model registration attempt with an empty out_of_scope_uses field was blocked with an error identifying the specific missing dimension", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art-13 requires that high-risk AI systems be designed and developed such that deployers receive sufficient information to understand the system's capabilities and limitations and to implement appropriate human oversight. LI-07's structured capability-limitation declaration directly satisfies Art-13 by providing machine-readable, structured transparency information at the model consumption point." }, { "control": "apeiris://ethics/controls/XP-06", "id": "XP-06", "domain": "ethics", "name": "Technical vs. Non-Technical Explanation Tiers", "validation_objective": "All AI decision systems classified as requiring explanations must implement a minimum three-tier explanation structure (affected-individual plain-language, business-operational summary, technical audit log) that accurately represents the decision at each tier without distortion. Tier-1 individual explanations must pass intelligibility review with representative target audience members prior to production.", "blocking_effect": "blocks-deployment", "evidence_required": [ "explanation_tier_matrix document mapping each audience type (affected individual, business user, technical reviewer, regulator) to required explanation format, depth, and delivery mechanism for each high-stakes AI system", "tier-1 plain-language explanation samples with intelligibility testing records showing comprehension scores from representative target audience participants", "tier-3 technical audit log samples showing feature attribution, model version, and decision factors with cross-reference to corresponding tier-1 explanation for accuracy comparison", "access control configuration records confirming tier-1 explanations are accessible to affected individuals on demand within legally required timeframes", "tier translation methodology documentation showing how technical attribution outputs map to plain-language explanations without material inaccuracy" ], "evidence": [ { "id": "XP-06-E1", "description": "explanation_tier_matrix document mapping each audience type (affected individual, business user, technical reviewer, regulator) to required explanation format, depth, and delivery mechanism for each high-stakes AI system", "evidence_type": "human-review-record", "verification": "human" }, { "id": "XP-06-E2", "description": "tier-1 plain-language explanation samples with intelligibility testing records showing comprehension scores from representative target audience participants", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "XP-06-E3", "description": "tier-3 technical audit log samples showing feature attribution, model version, and decision factors with cross-reference to corresponding tier-1 explanation for accuracy comparison", "evidence_type": "audit-log", "verification": "automated" }, { "id": "XP-06-E4", "description": "access control configuration records confirming tier-1 explanations are accessible to affected individuals on demand within legally required timeframes", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "XP-06-E5", "description": "tier translation methodology documentation showing how technical attribution outputs map to plain-language explanations without material inaccuracy", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 13 requires that high-risk AI systems provide information accessible to deployers, and Art. 86 requires that affected individuals receive explanations in a clear and meaningful form. The tiered explanation framework directly implements both requirements by ensuring each audience receives calibrated information." } ] }, { "requirement_id": "EU-AIA-ART13-03", "section": "Art. 13(3)", "title": "Transparency \u2014 specific information required in instructions", "text": "Instructions for use shall contain information relating to: provider identity, intended purpose, level of accuracy and robustness, any known or foreseeable circumstances that may lead to risks, human oversight measures, expected lifetime and maintenance measures.", "verdict": "partial", "coverage": "partial", "notes": "LI-04 covers identity, intended purpose, and performance characteristics. XP-05 (Model Card and System Card) covers known limitations and risk circumstances. RF-03 (Technical Documentation Package) covers the complete Annex IV information set. EV-02 provides accuracy and robustness metrics. Partial: expected system lifetime and maintenance schedule commitments, and EU-specific provider registration details (EUID), may require legal entity information management beyond Apeiris's technical control scope.", "control_count": 4, "proof_chain": [ { "control": "apeiris://model/controls/LI-04", "id": "LI-04", "domain": "model", "name": "Structured Model Documentation \u2014 Complete Model Card with All Required Sections", "validation_objective": "Every model submitted for registration must have a schema-validated model card with all nine Mitchell et al. 2019 sections substantively populated and passing field-level validation rules; the model card must be version-locked to the artifact hash and returned as structured metadata from the registry API; and registration must be blocked when any required section is absent, empty, or contains only placeholder text.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_card_completeness_validation_report showing pass/fail status per section with field-level validation results, registration blocking decision, and validation timestamp for the current artifact version", "versioned_model_card artifact linked to the specific model artifact hash with all nine Mitchell et al. sections containing substantive content (not placeholder text), retrievable from the registry by artifact hash", "model_registry_entry showing the current model card version hash stored alongside the artifact hash as paired immutable fields", "eu_ai_act_annex_iv_supplemental_record for EU AI Act high-risk in-scope systems confirming Annex IV technical documentation fields are populated in addition to the nine Mitchell et al. sections" ], "evidence": [ { "id": "LI-04-E1", "description": "model_card_completeness_validation_report showing pass/fail status per section with field-level validation results, registration blocking decision, and validation timestamp for the current artifact version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-04-E2", "description": "versioned_model_card artifact linked to the specific model artifact hash with all nine Mitchell et al. sections containing substantive content (not placeholder text), retrievable from the registry by artifact hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-04-E3", "description": "model_registry_entry showing the current model card version hash stored alongside the artifact hash as paired immutable fields", "evidence_type": "model-card", "verification": "attested" }, { "id": "LI-04-E4", "description": "eu_ai_act_annex_iv_supplemental_record for EU AI Act high-risk in-scope systems confirming Annex IV technical documentation fields are populated in addition to the nine Mitchell et al. sections", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art-11 requires providers of high-risk AI systems to prepare and maintain technical documentation before market placement. The Mitchell et al. 9-section model card supplemented with Annex IV fields directly satisfies Art-11's technical documentation requirement. This control supports satisfaction of Art-11 for covered deployments; applicability depends on the deployer's role (provider vs. deployer) and the system's high-risk classification." }, { "control": "apeiris://ethics/controls/XP-05", "id": "XP-05", "domain": "ethics", "name": "Model Card and System Card Transparency Disclosure", "validation_objective": "Every AI system deployed in a high-stakes or public-facing context has a current published model card or system card that accurately represents the system's capabilities, limitations, intended use, known failure modes, and fairness evaluation results; cards are version-controlled and updated when the system undergoes material changes; and no high-stakes AI system is in production without a current card accessible to deployers and affected stakeholders.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_card_or_system_card document per AI system with required fields: system_id, model_version, intended_use, out_of_scope_uses, known_limitations, failure_modes, fairness_evaluation_results (metric name, value, demographic group, evaluation_date), and last_updated_date", "model_card_version_history log showing card updates aligned to model changes with delta description for each version", "card_publication_record confirming the card is accessible at a documented public or deployer-accessible URL before the system was deployed", "material_change_review_log showing that each model retraining, feature change, or scope expansion triggered a card update review with decision to update or document rationale for no-update" ], "evidence": [ { "id": "XP-05-E1", "description": "model_card_or_system_card document per AI system with required fields: system_id, model_version, intended_use, out_of_scope_uses, known_limitations, failure_modes, fairness_evaluation_results (metric name, value, demographic group, evaluation_date), and last_updated_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "XP-05-E2", "description": "model_card_version_history log showing card updates aligned to model changes with delta description for each version", "evidence_type": "audit-log", "verification": "automated" }, { "id": "XP-05-E3", "description": "card_publication_record confirming the card is accessible at a documented public or deployer-accessible URL before the system was deployed", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "XP-05-E4", "description": "material_change_review_log showing that each model retraining, feature change, or scope expansion triggered a card update review with decision to update or document rationale for no-update", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 11 and Annex IV require high-risk AI providers to maintain comprehensive technical documentation including system description, design choices, performance metrics, and known limitations. Model cards directly instantiate this requirement in a standardized, reviewable format." }, { "control": "apeiris://compliance/controls/RF-03", "id": "RF-03", "domain": "compliance", "name": "EU AI Act Technical Documentation Package (Art. 11)", "validation_objective": "Each high-risk AI system must have an Annex IV technical documentation package with all required sections substantively populated \u2014 no missing sections or placeholder content \u2014 version-controlled and linked to the current CE declaration, updated within 30 days of any qualifying model or deployment scope change, and retained in a controlled repository for 10 years from market placement date as required by Art. 18.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Annex IV completeness checklist per high-risk system with completion status for each required section, documentation owner sign-off, and compliance team approval date", "Technical documentation version history linking each documentation version to the corresponding model version, CE declaration version, and the change management ticket that triggered the update", "Model change management tickets with documentation update completion confirmation timestamp within 30 days of each qualifying model or deployment scope change event", "Documentation repository access log and retention policy configuration confirming role-based access controls, full version history, and a 10-year minimum retention period anchored to market placement date", "Pre-submission documentation completeness review record with legal and compliance sign-off completed before notified body submission or CE declaration issuance" ], "evidence": [ { "id": "RF-03-E1", "description": "Annex IV completeness checklist per high-risk system with completion status for each required section, documentation owner sign-off, and compliance team approval date", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RF-03-E2", "description": "Technical documentation version history linking each documentation version to the corresponding model version, CE declaration version, and the change management ticket that triggered the update", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RF-03-E3", "description": "Model change management tickets with documentation update completion confirmation timestamp within 30 days of each qualifying model or deployment scope change event", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RF-03-E4", "description": "Documentation repository access log and retention policy configuration confirming role-based access controls, full version history, and a 10-year minimum retention period anchored to market placement date", "evidence_type": "audit-log", "verification": "automated" }, { "id": "RF-03-E5", "description": "Pre-submission documentation completeness review record with legal and compliance sign-off completed before notified body submission or CE declaration issuance", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "Art. 11 imposes a mandatory obligation on providers of high-risk AI systems to draw up technical documentation before market placement, and Annex IV specifies the required documentation sections. This control implements the documentation assembly and maintenance obligation in its entirety." }, { "control": "apeiris://model/controls/EV-02", "id": "EV-02", "domain": "model", "name": "Fitness, Safety, Reliability and Policy-Conformance Evaluation", "validation_objective": "Before deployment, every model has been evaluated against pre-specified, dimension-level pass/fail thresholds \u2014 fitness, safety, reliability, and policy-conformance \u2014 with results documented against the model artifact hash and evaluation suite version. No threshold is modified after evaluation begins, and any threshold trade-off decision is documented as a named risk-acceptance record before the deployment manifest is signed.", "blocking_effect": "blocks-deployment", "evidence_required": [ "pre_specified_evaluation_protocol with model_artifact_hash, evaluation_suite_version, and per-dimension thresholds (fitness accuracy target, safety refusal rate, reliability error budget, policy-conformance violation rate), signed by the evaluation lead before testing begins \u2014 not after results are known", "dimension_level_evaluation_results showing per-dimension metric values, pass/fail verdict against pre-specified threshold, and model_artifact_hash confirming results correspond to the evaluated version", "evaluation_suite_provenance_record confirming that evaluation datasets are disjoint from training data, with contamination-check reference to TG-05 attestation", "risk_acceptance_record for any dimension where the pass threshold was not met but deployment was authorized, documenting named risk-accepter, specific capability gap, deployment risk consequence, and remediation deadline" ], "evidence": [ { "id": "EV-02-E1", "description": "pre_specified_evaluation_protocol with model_artifact_hash, evaluation_suite_version, and per-dimension thresholds (fitness accuracy target, safety refusal rate, reliability error budget, policy-conformance violation rate), signed by the evaluation lead before testing begins \u2014 not after results are known", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-02-E2", "description": "dimension_level_evaluation_results showing per-dimension metric values, pass/fail verdict against pre-specified threshold, and model_artifact_hash confirming results correspond to the evaluated version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-02-E3", "description": "evaluation_suite_provenance_record confirming that evaluation datasets are disjoint from training data, with contamination-check reference to TG-05 attestation", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-02-E4", "description": "risk_acceptance_record for any dimension where the pass threshold was not met but deployment was authorized, documenting named risk-accepter, specific capability gap, deployment risk consequence, and remediation deadline", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "Art. 9(5) requires testing against defined metrics and probabilistic thresholds; Art. 9(6) requires accuracy, robustness, and cybersecurity evaluation for high-risk systems." } ] }, { "requirement_id": "EU-AIA-ART14-01", "section": "Art. 14(1)", "title": "Human oversight \u2014 design with appropriate measures", "text": "High-risk AI systems shall be designed and developed in such a way, including with appropriate human-machine interface tools, that they can be effectively overseen by natural persons during the period in which the AI system is in use.", "verdict": "supported", "coverage": "direct", "notes": "OA-02 (Meaningful Human Oversight for High-Stakes Decisions) requires design-time integration of oversight mechanisms as a mandatory design requirement rather than an optional feature. AO-04 (Human-in-the-Loop Gates for High-Consequence Orchestrations) enforces pause points at which human review and approval is required before consequential actions proceed. GV-01 (Human hard-stop for irreversible actions) provides the system-level capability for humans to halt the AI system at any point. HI-04 (Human Oversight and Override Mechanisms) requires that override mechanisms are accessible and operationally tested.", "control_count": 4, "proof_chain": [ { "control": "apeiris://model/controls/OA-02", "id": "OA-02", "domain": "model", "name": "Meaningful Human Oversight for High-Stakes Decisions", "validation_objective": "For every high-impact-decision or eu-high-risk model, a human reviewer must have documented access to model inputs, confidence scores, and reasoning; organizational authority to override without penalty; domain competence verified through training records; and a technically effective override mechanism before any AI output takes effect. Override rates must be monitored and a rate near zero for 30 consecutive days must automatically trigger a governance review.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "five_factor_oversight_design_document per high-stakes use case, signed by the AI governance committee, covering: review time allocation, information display design, override authority documentation, competence requirements, and override mechanism technical specification", "override_rate_time_series report for the past 12 months broken down by model, decision type, and reviewer cohort \u2014 with governance-defined floor thresholds annotated", "reviewer_training_completion_record including initial onboarding completion date, annual recertification dates, competence assessment scores, and automation-bias module completion", "override_mechanism_test_log confirming that override actions propagate correctly through downstream systems without requiring secondary approval" ], "evidence": [ { "id": "OA-02-E1", "description": "five_factor_oversight_design_document per high-stakes use case, signed by the AI governance committee, covering: review time allocation, information display design, override authority documentation, competence requirements, and override mechanism technical specification", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-02-E2", "description": "override_rate_time_series report for the past 12 months broken down by model, decision type, and reviewer cohort \u2014 with governance-defined floor thresholds annotated", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-02-E3", "description": "reviewer_training_completion_record including initial onboarding completion date, annual recertification dates, competence assessment scores, and automation-bias module completion", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-02-E4", "description": "override_mechanism_test_log confirming that override actions propagate correctly through downstream systems without requiring secondary approval", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "Art-14 mandates human oversight design for high-risk AI. The five-factor framework operationalizes Art-14(3) requirements." }, { "control": "apeiris://agentic/controls/AO-04", "id": "AO-04", "domain": "agentic", "name": "Human-in-the-Loop Gates for High-Consequence Orchestrations", "validation_objective": "Proves that every orchestration pipeline classified as irreversible-write or regulated-action contains at least one mandatory human approval gate that blocks execution until an authorized reviewer explicitly approves continuation, and that pipelines self-terminate (not auto-approve) when the gate timeout is reached without reviewer action. No irreversible or regulated pipeline action may be executed without a logged, attributed human approval decision.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "Consequence taxonomy documentation mapping all production pipeline action types to classification levels, with legal or compliance sign-off for regulated-action classifications", "Gate activation and approval records for a representative sample of high-consequence pipeline executions, each containing reviewer identity, decision, rationale, and timestamp", "Gate timeout self-termination test records confirming pipelines terminate (not auto-approve) when reviewer action is not received within the defined window", "Gate bypass incident log for the prior 12 months showing zero unauthorized bypass events, or incident records for any that occurred", "Sample reviewer decision packages confirming they present action description, predicted consequence, confidence estimate, and rollback feasibility to the reviewer" ], "evidence": [ { "id": "AO-04-E1", "description": "Consequence taxonomy documentation mapping all production pipeline action types to classification levels, with legal or compliance sign-off for regulated-action classifications", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AO-04-E2", "description": "Gate activation and approval records for a representative sample of high-consequence pipeline executions, each containing reviewer identity, decision, rationale, and timestamp", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AO-04-E3", "description": "Gate timeout self-termination test records confirming pipelines terminate (not auto-approve) when reviewer action is not received within the defined window", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "AO-04-E4", "description": "Gate bypass incident log for the prior 12 months showing zero unauthorized bypass events, or incident records for any that occurred", "evidence_type": "incident-record", "verification": "attested" }, { "id": "AO-04-E5", "description": "Sample reviewer decision packages confirming they present action description, predicted consequence, confidence estimate, and rollback feasibility to the reviewer", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 14 mandates human oversight measures for high-risk AI systems, including the ability for humans to intervene and override system outputs. Human-in-the-loop gates directly implement this requirement at the orchestration layer." }, { "control": "apeiris://security/controls/GV-01", "id": "GV-01", "domain": "security", "name": "Require a human hard-stop for irreversible actions", "validation_objective": "Every irreversible agent action (write, deletion, transfer, deployment, or any action with no safe undo path) must be deterministically halted and routed to an explicit human (or quorum) approval before execution; the agent must not be capable of self-approving such actions, and the hard-stop must be enforced at platform infrastructure level, not by a model-layer instruction.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "irreversible_action_approval_record linking each halted action to the human approver(s), approval_token with timestamp and cryptographic signature, and action outcome (executed/cancelled)", "irreversibility_classification_list identifying which action types are classified as irreversible, with the policy_version and last_review_date", "hard_stop_enforcement_log showing agent execution was suspended at the irreversible action gate and resumed only after receipt of a valid external approval token", "self_approval_rejection_log confirming any attempt by the agent to approve its own irreversible actions was blocked by the platform", "quorum_policy_record for high-stakes action categories specifying minimum required approvers and approval token validity window" ], "evidence": [ { "id": "GV-01-E1", "description": "irreversible_action_approval_record linking each halted action to the human approver(s), approval_token with timestamp and cryptographic signature, and action outcome (executed/cancelled)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-01-E2", "description": "irreversibility_classification_list identifying which action types are classified as irreversible, with the policy_version and last_review_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-01-E3", "description": "hard_stop_enforcement_log showing agent execution was suspended at the irreversible action gate and resumed only after receipt of a valid external approval token", "evidence_type": "human-review-record", "verification": "human" }, { "id": "GV-01-E4", "description": "self_approval_rejection_log confirming any attempt by the agent to approve its own irreversible actions was blocked by the platform", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-01-E5", "description": "quorum_policy_record for high-stakes action categories specifying minimum required approvers and approval token validity window", "evidence_type": "human-review-record", "verification": "human" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://ethics/controls/HI-04", "id": "HI-04", "domain": "ethics", "name": "Human Oversight and Override Mechanisms", "validation_objective": "All AI systems classified as significant or critical consequentiality tier must have override logging implemented and producing verifiable disposition records for every AI recommendation reviewed by a human operator. Override rate monitoring must be active and generating alerts when rates fall below defined thresholds, and every alert must trigger a documented review response within 30 days.", "blocking_effect": "blocks-deployment", "evidence_required": [ "consequentiality_tier_classification_record for every production AI system documenting the assigned tier (advisory/significant/critical), classification rationale, and mandatory oversight requirements that tier triggers", "override_audit_log for significant and critical tier systems showing AI recommendations, human dispositions (accepted/modified/rejected), override rationale where provided, and timestamps covering the prior 90 days", "override_rate_monitoring_report showing per-system trend data, defined threshold levels, alerts triggered in the prior 12 months, and documented investigation responses with completion dates", "interface_design_review_record confirming evaluation of the AI decision interface against automation-bias-avoidance criteria: confidence levels displayed, uncertainty ranges shown, override pathway accessible without additional navigation, AI-generated content distinguished from operator-entered content", "human_overseer_assignment_record naming the qualified overseer role for each significant and critical tier AI system with accountability documentation and training evidence" ], "evidence": [ { "id": "HI-04-E1", "description": "consequentiality_tier_classification_record for every production AI system documenting the assigned tier (advisory/significant/critical), classification rationale, and mandatory oversight requirements that tier triggers", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-04-E2", "description": "override_audit_log for significant and critical tier systems showing AI recommendations, human dispositions (accepted/modified/rejected), override rationale where provided, and timestamps covering the prior 90 days", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-04-E3", "description": "override_rate_monitoring_report showing per-system trend data, defined threshold levels, alerts triggered in the prior 12 months, and documented investigation responses with completion dates", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "HI-04-E4", "description": "interface_design_review_record confirming evaluation of the AI decision interface against automation-bias-avoidance criteria: confidence levels displayed, uncertainty ranges shown, override pathway accessible without additional navigation, AI-generated content distinguished from operator-entered content", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "HI-04-E5", "description": "human_overseer_assignment_record naming the qualified overseer role for each significant and critical tier AI system with accountability documentation and training evidence", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 14 mandates that high-risk AI systems be designed to allow effective human oversight, including the ability to understand capabilities and limitations, detect and address malfunctions, and override or interrupt system outputs. This control operationalizes each of these requirements through tier-based oversight design and automation-bias monitoring." } ] }, { "requirement_id": "EU-AIA-ART14-02", "section": "Art. 14(2)", "title": "Human oversight \u2014 measures proportionate to risks and autonomy level", "text": "Human oversight measures shall be commensurate with the risks, level of autonomy and context of use of the high-risk AI system and shall be identified and built into the high-risk AI system by the provider before placing on the market.", "verdict": "supported", "coverage": "direct", "notes": "OA-04 (Delegated Autonomy Tier Governance) directly maps autonomy levels to oversight requirements \u2014 the higher the autonomy tier, the stricter the required oversight controls. GV-05 (AI management system \u2014 tier agents by autonomy) provides the tiering framework that links autonomy level to risk-proportionate oversight requirements. AG-03 defines the risk level that drives oversight intensity. AG-02 (Agent Deployment Policy and Pre-Deployment Review Gate) ensures oversight measures are verified at the pre-deployment review gate before the system is placed in service.", "control_count": 4, "proof_chain": [ { "control": "apeiris://model/controls/OA-04", "id": "OA-04", "domain": "model", "name": "Delegated Autonomy Tier Governance", "validation_objective": "Every AI model or agent in the production registry must have an explicitly documented autonomy tier assignment sourced from the Security Verifier domain taxonomy, with AIGC approval records present for all Tier 3 and above assignments, and evaluation evidence requirements calibrated to the assigned tier. No model may take actions outside its tier-permitted scope without triggering an escalation event.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_register_extract showing autonomy_tier field populated for every production model, with reference to the Security Verifier tier taxonomy version in use", "aigc_approval_records for all Tier 3 and above tier assignments, including the date, voting outcome, and risk rationale", "tier_assignment_artifact (tier_assignment_{model_id}_{version}.json) consumed from Security Verifier domain for each model, confirming cross-domain provenance", "evaluation_requirement_lookup_table mapping each tier level to specific evidence requirements, with version date and approval signature from model governance committee" ], "evidence": [ { "id": "OA-04-E1", "description": "model_register_extract showing autonomy_tier field populated for every production model, with reference to the Security Verifier tier taxonomy version in use", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-04-E2", "description": "aigc_approval_records for all Tier 3 and above tier assignments, including the date, voting outcome, and risk rationale", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-04-E3", "description": "tier_assignment_artifact (tier_assignment_{model_id}_{version}.json) consumed from Security Verifier domain for each model, confirming cross-domain provenance", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "OA-04-E4", "description": "evaluation_requirement_lookup_table mapping each tier level to specific evidence requirements, with version date and approval signature from model governance committee", "evidence_type": "human-review-record", "verification": "human" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://security/controls/GV-05", "id": "GV-05", "domain": "security", "name": "Run an AI management system and tier agents by their autonomy", "validation_objective": "The organization operates a documented ISO/IEC 42001 AI management system with a current agent inventory, and every production agent is assigned a risk tier based on its level of autonomy and permissions, with higher-autonomy agents carrying impact assessments proportional to their tier.", "blocking_effect": "blocks-deployment", "evidence_required": [ "agent_risk_tier_register listing each production agent's assigned autonomy tier and the criteria used for classification", "ISO/IEC 42001 AI management system documentation with scope statement and AI policy covering agentic systems", "impact_assessment_records for each agent classified at the two highest autonomy tiers with a completed and approved status", "change-trigger log showing tier re-evaluation events (model update, domain shift, performance regression, regulatory change) within the review window", "AWS Agentic AI Security Scoping Matrix or equivalent tier-scoring artifacts used for current-period agent classification", "environment_isolation_attestation confirming each agent tier instance has distinct identity credentials, secrets, and permission scopes per deployment environment (dev/staging/production) with a zero-sharing assertion verified against the credential broker", "environment_promotion_log recording each agent's promotion path through dev \u2192 staging \u2192 production, the approver identity, any autonomy-tier reclassification triggered during promotion, and confirmation that a staging integration validation gate was passed before the production promotion" ], "evidence": [ { "id": "GV-05-E1", "description": "agent_risk_tier_register listing each production agent's assigned autonomy tier and the criteria used for classification", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-05-E2", "description": "ISO/IEC 42001 AI management system documentation with scope statement and AI policy covering agentic systems", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-05-E3", "description": "impact_assessment_records for each agent classified at the two highest autonomy tiers with a completed and approved status", "evidence_type": "human-review-record", "verification": "human" }, { "id": "GV-05-E4", "description": "change-trigger log showing tier re-evaluation events (model update, domain shift, performance regression, regulatory change) within the review window", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "GV-05-E5", "description": "AWS Agentic AI Security Scoping Matrix or equivalent tier-scoring artifacts used for current-period agent classification", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-05-E6", "description": "environment_isolation_attestation confirming each agent tier instance has distinct identity credentials, secrets, and permission scopes per deployment environment (dev/staging/production) with a zero-sharing assertion verified against the credential broker", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "GV-05-E7", "description": "environment_promotion_log recording each agent's promotion path through dev \u2192 staging \u2192 production, the approver identity, any autonomy-tier reclassification triggered during promotion, and confirmation that a staging integration validation gate was passed before the production promotion", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://agentic/controls/AG-03", "id": "AG-03", "domain": "agentic", "name": "Agentic AI Risk Assessment Framework", "validation_objective": "Every production AI agent has a completed, current risk assessment evaluated against all five framework dimensions, with the resulting consequence tier documented and linked to the deployment approval and control mitigation plan.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "Annual risk reassessment records for all Critical-tier agents" ], "evidence": [ { "id": "AG-03-E1", "description": "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E2", "description": "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E3", "description": "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E4", "description": "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E5", "description": "Annual risk reassessment records for all Critical-tier agents", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 9 requires a documented risk management system with iterative risk identification and analysis, and Annex III defines high-risk classification criteria including autonomous decision-making systems. The framework's tier thresholds must align with these regulatory classification criteria to satisfy deployer obligations." }, { "control": "apeiris://agentic/controls/AG-02", "id": "AG-02", "domain": "agentic", "name": "Agent Deployment Policy and Pre-Deployment Review Gate", "validation_objective": "Every production AI agent has a signed, complete deployment approval record meeting the requirements of its assigned consequence tier, and the CI/CD pipeline enforces a hard gate that blocks promotion when that record is absent, expired, or incomplete.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Ratified Agent Deployment Policy document defining consequence tiers, approval authorities, mandatory review artifacts, and maximum approval validity period", "Signed deployment approval record for each production agent, including agent ID, consequence tier, capability manifest hash, authorization scope declaration, and reviewer identity", "CI/CD pipeline audit log showing gate enforcement events (approvals, rejections, blocks) with timestamps and artifact hashes", "Agent consequence tier assignment records linked to the deployment approval for each production agent", "Monitoring configuration validation artifact confirming SOC integration requirements were satisfied at approval time" ], "evidence": [ { "id": "AG-02-E1", "description": "Ratified Agent Deployment Policy document defining consequence tiers, approval authorities, mandatory review artifacts, and maximum approval validity period", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AG-02-E2", "description": "Signed deployment approval record for each production agent, including agent ID, consequence tier, capability manifest hash, authorization scope declaration, and reviewer identity", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "AG-02-E3", "description": "CI/CD pipeline audit log showing gate enforcement events (approvals, rejections, blocks) with timestamps and artifact hashes", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AG-02-E4", "description": "Agent consequence tier assignment records linked to the deployment approval for each production agent", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AG-02-E5", "description": "Monitoring configuration validation artifact confirming SOC integration requirements were satisfied at approval time", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 9 mandates a risk management system for high-risk AI systems including pre-deployment risk identification and evaluation with iterative updates. A tiered deployment policy with a formal review gate and signed approval records satisfies the risk management system requirement for deployers." } ] }, { "requirement_id": "EU-AIA-ART14-03", "section": "Art. 14(3)", "title": "Human oversight \u2014 specific oversight capabilities", "text": "The measures referred to in paragraph 1 shall enable individuals designated to oversee to: fully understand the capabilities and limitations; monitor operation for anomalies; be able to disregard, override or interrupt the system; interpret outputs correctly; and intervene effectively.", "verdict": "supported", "coverage": "direct", "notes": "OA-02 requires that oversight personnel have documented access to capability/limitation documentation, anomaly alerts, and override mechanisms. HI-04 (Human Oversight and Override Mechanisms) operationalizes the override and interrupt capability requirements. GV-01 (Human hard-stop for irreversible actions) provides the technical interrupt capability. XP-02 (Decision-Level Explanation Requirements) ensures outputs are accompanied by decision-level explanations that enable correct interpretation by oversight personnel.", "control_count": 4, "proof_chain": [ { "control": "apeiris://model/controls/OA-02", "id": "OA-02", "domain": "model", "name": "Meaningful Human Oversight for High-Stakes Decisions", "validation_objective": "For every high-impact-decision or eu-high-risk model, a human reviewer must have documented access to model inputs, confidence scores, and reasoning; organizational authority to override without penalty; domain competence verified through training records; and a technically effective override mechanism before any AI output takes effect. Override rates must be monitored and a rate near zero for 30 consecutive days must automatically trigger a governance review.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "five_factor_oversight_design_document per high-stakes use case, signed by the AI governance committee, covering: review time allocation, information display design, override authority documentation, competence requirements, and override mechanism technical specification", "override_rate_time_series report for the past 12 months broken down by model, decision type, and reviewer cohort \u2014 with governance-defined floor thresholds annotated", "reviewer_training_completion_record including initial onboarding completion date, annual recertification dates, competence assessment scores, and automation-bias module completion", "override_mechanism_test_log confirming that override actions propagate correctly through downstream systems without requiring secondary approval" ], "evidence": [ { "id": "OA-02-E1", "description": "five_factor_oversight_design_document per high-stakes use case, signed by the AI governance committee, covering: review time allocation, information display design, override authority documentation, competence requirements, and override mechanism technical specification", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-02-E2", "description": "override_rate_time_series report for the past 12 months broken down by model, decision type, and reviewer cohort \u2014 with governance-defined floor thresholds annotated", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-02-E3", "description": "reviewer_training_completion_record including initial onboarding completion date, annual recertification dates, competence assessment scores, and automation-bias module completion", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-02-E4", "description": "override_mechanism_test_log confirming that override actions propagate correctly through downstream systems without requiring secondary approval", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "Art-14 mandates human oversight design for high-risk AI. The five-factor framework operationalizes Art-14(3) requirements." }, { "control": "apeiris://ethics/controls/HI-04", "id": "HI-04", "domain": "ethics", "name": "Human Oversight and Override Mechanisms", "validation_objective": "All AI systems classified as significant or critical consequentiality tier must have override logging implemented and producing verifiable disposition records for every AI recommendation reviewed by a human operator. Override rate monitoring must be active and generating alerts when rates fall below defined thresholds, and every alert must trigger a documented review response within 30 days.", "blocking_effect": "blocks-deployment", "evidence_required": [ "consequentiality_tier_classification_record for every production AI system documenting the assigned tier (advisory/significant/critical), classification rationale, and mandatory oversight requirements that tier triggers", "override_audit_log for significant and critical tier systems showing AI recommendations, human dispositions (accepted/modified/rejected), override rationale where provided, and timestamps covering the prior 90 days", "override_rate_monitoring_report showing per-system trend data, defined threshold levels, alerts triggered in the prior 12 months, and documented investigation responses with completion dates", "interface_design_review_record confirming evaluation of the AI decision interface against automation-bias-avoidance criteria: confidence levels displayed, uncertainty ranges shown, override pathway accessible without additional navigation, AI-generated content distinguished from operator-entered content", "human_overseer_assignment_record naming the qualified overseer role for each significant and critical tier AI system with accountability documentation and training evidence" ], "evidence": [ { "id": "HI-04-E1", "description": "consequentiality_tier_classification_record for every production AI system documenting the assigned tier (advisory/significant/critical), classification rationale, and mandatory oversight requirements that tier triggers", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-04-E2", "description": "override_audit_log for significant and critical tier systems showing AI recommendations, human dispositions (accepted/modified/rejected), override rationale where provided, and timestamps covering the prior 90 days", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-04-E3", "description": "override_rate_monitoring_report showing per-system trend data, defined threshold levels, alerts triggered in the prior 12 months, and documented investigation responses with completion dates", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "HI-04-E4", "description": "interface_design_review_record confirming evaluation of the AI decision interface against automation-bias-avoidance criteria: confidence levels displayed, uncertainty ranges shown, override pathway accessible without additional navigation, AI-generated content distinguished from operator-entered content", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "HI-04-E5", "description": "human_overseer_assignment_record naming the qualified overseer role for each significant and critical tier AI system with accountability documentation and training evidence", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 14 mandates that high-risk AI systems be designed to allow effective human oversight, including the ability to understand capabilities and limitations, detect and address malfunctions, and override or interrupt system outputs. This control operationalizes each of these requirements through tier-based oversight design and automation-bias monitoring." }, { "control": "apeiris://security/controls/GV-01", "id": "GV-01", "domain": "security", "name": "Require a human hard-stop for irreversible actions", "validation_objective": "Every irreversible agent action (write, deletion, transfer, deployment, or any action with no safe undo path) must be deterministically halted and routed to an explicit human (or quorum) approval before execution; the agent must not be capable of self-approving such actions, and the hard-stop must be enforced at platform infrastructure level, not by a model-layer instruction.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "irreversible_action_approval_record linking each halted action to the human approver(s), approval_token with timestamp and cryptographic signature, and action outcome (executed/cancelled)", "irreversibility_classification_list identifying which action types are classified as irreversible, with the policy_version and last_review_date", "hard_stop_enforcement_log showing agent execution was suspended at the irreversible action gate and resumed only after receipt of a valid external approval token", "self_approval_rejection_log confirming any attempt by the agent to approve its own irreversible actions was blocked by the platform", "quorum_policy_record for high-stakes action categories specifying minimum required approvers and approval token validity window" ], "evidence": [ { "id": "GV-01-E1", "description": "irreversible_action_approval_record linking each halted action to the human approver(s), approval_token with timestamp and cryptographic signature, and action outcome (executed/cancelled)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-01-E2", "description": "irreversibility_classification_list identifying which action types are classified as irreversible, with the policy_version and last_review_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-01-E3", "description": "hard_stop_enforcement_log showing agent execution was suspended at the irreversible action gate and resumed only after receipt of a valid external approval token", "evidence_type": "human-review-record", "verification": "human" }, { "id": "GV-01-E4", "description": "self_approval_rejection_log confirming any attempt by the agent to approve its own irreversible actions was blocked by the platform", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-01-E5", "description": "quorum_policy_record for high-stakes action categories specifying minimum required approvers and approval token validity window", "evidence_type": "human-review-record", "verification": "human" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://ethics/controls/XP-02", "id": "XP-02", "domain": "ethics", "name": "Decision-Level Explanation Requirements", "validation_objective": "Each class of AI-driven decision has a documented explanation specification that defines the required explanation type, depth, and format, explicitly maps to applicable legal obligations (GDPR Art. 22, EU AI Act Art. 13, Colorado AI Act, or other jurisdiction-specific requirements), and is implemented in deployed systems such that explanations generated conform to the specification and are verifiably produced before each decision is communicated.", "blocking_effect": "blocks-deployment", "evidence_required": [ "decision_explanation_specification per decision class with fields: decision_class_id, applicable_legal_obligations, required_explanation_type (feature-attribution, counterfactual, rule-based, natural-language), required_depth (summary, detailed, technical), required_format (structured-json, natural-language, visual), and audience (end-user, regulator, internal-audit)", "explanation_generation_log showing that for each AI decision record a corresponding explanation artifact was generated with timestamp, decision_id, explanation_type, and explanation_content_hash", "explanation_format_compliance_test_report confirming that generated explanations conform to the specification for each decision class", "legal_review_attestation confirming the explanation specification meets applicable legal obligations for each jurisdiction in which the system is deployed" ], "evidence": [ { "id": "XP-02-E1", "description": "decision_explanation_specification per decision class with fields: decision_class_id, applicable_legal_obligations, required_explanation_type (feature-attribution, counterfactual, rule-based, natural-language), required_depth (summary, detailed, technical), required_format (structured-json, natural-language, visual), and audience (end-user, regulator, internal-audit)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "XP-02-E2", "description": "explanation_generation_log showing that for each AI decision record a corresponding explanation artifact was generated with timestamp, decision_id, explanation_type, and explanation_content_hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "XP-02-E3", "description": "explanation_format_compliance_test_report confirming that generated explanations conform to the specification for each decision class", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "XP-02-E4", "description": "legal_review_attestation confirming the explanation specification meets applicable legal obligations for each jurisdiction in which the system is deployed", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 13 mandates transparency requirements for high-risk AI systems, and Art. 86 provides individuals the right to explanation for significant AI-driven decisions. The decision taxonomy directly operationalizes these requirements by mapping each decision class to its applicable obligations." } ] }, { "requirement_id": "EU-AIA-ART14-04", "section": "Art. 14(4)", "title": "Human oversight \u2014 deployer assignment of oversight persons", "text": "Deployers shall take appropriate technical and organisational measures to ensure the effective implementation of the human oversight measures as indicated by the provider in the instructions for use. Deployers shall assign oversight to competent natural persons.", "verdict": "supported", "coverage": "direct", "notes": "OA-01 (Model Ownership Assignment) requires a named accountable owner assigned to every deployed model. PA-04 (Principal Accountability Binding) binds accountability for AI system decisions to a named principal with documented authority and competency requirements. AG-04 (Senior Accountability for Autonomous AI Systems) extends this to agentic systems requiring senior-level accountable owner assignment. GV-09 (Anchor a named business owner to every agent) ensures the oversight assignment is organizationally durable and cannot be left vacant.", "control_count": 4, "proof_chain": [ { "control": "apeiris://model/controls/OA-01", "id": "OA-01", "domain": "model", "name": "Model Ownership Assignment", "validation_objective": "Every AI model in the production model registry must have a non-null named human owner who is a current employee, a responsible team, and an executive sponsor at director level or above for high-impact models, all recorded within five business days of deployment. No production model may exist without a current ownership record, and ownership must be reassigned within ten business days of any owner departure.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_ownership_register_extract with fields: model_id, owner_name, owner_employee_id, team, executive_sponsor, effective_date, review_date \u2014 showing 100% coverage of production models with non-null values", "deployment_pipeline_gate_log showing blocked promotion events for models with null ownership fields, with timestamps and model IDs", "hr_departure_event_log cross-referenced with ownership_reassignment_record demonstrating reassignment within ten business days for each departure", "governance_committee_meeting_minutes containing ownership review agenda items for the preceding 12-month period" ], "evidence": [ { "id": "OA-01-E1", "description": "model_ownership_register_extract with fields: model_id, owner_name, owner_employee_id, team, executive_sponsor, effective_date, review_date \u2014 showing 100% coverage of production models with non-null values", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-01-E2", "description": "deployment_pipeline_gate_log showing blocked promotion events for models with null ownership fields, with timestamps and model IDs", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-01-E3", "description": "hr_departure_event_log cross-referenced with ownership_reassignment_record demonstrating reassignment within ten business days for each departure", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-01-E4", "description": "governance_committee_meeting_minutes containing ownership review agenda items for the preceding 12-month period", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "Art-17 requires providers of high-risk AI systems to operate a quality management system that includes an accountability framework setting out the responsibilities of management and other staff (Art. 17(1)(m)); Art. 16(c) obliges providers to have such a QMS in place. OA-01's named-owner register implements the accountability component." }, { "control": "apeiris://authority/controls/PA-04", "id": "PA-04", "domain": "authority", "name": "Principal Accountability Binding", "validation_objective": "Every consequential AI action must produce an immutable accountability binding artifact atomically with the action, containing the action_id, agent_id, principal_id, delegation_basis_id, action_scope, and an integrity hash sealing the record. The artifact must be written to a tamper-evident, append-only store from which neither the AI agent nor its service account can modify or delete entries.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "accountability_binding_artifact for each consequential AI action, containing action_id, agent_id, principal_id, delegation_basis_id, action_scope, action_timestamp, and integrity_hash (sha256) \u2014 all fields must be non-null", "tamper_evident_store_audit_record confirming the binding store is append-only and that no modification or deletion events occurred for any binding artifact during the audit period", "principal_existence_validation_record confirming the principal_id referenced in each binding artifact resolves to a current, active human identity in the enterprise identity system at the time of binding", "binding_completeness_scan result confirming 100% of consequential AI actions in the audit period have a corresponding accountability binding artifact with no gaps" ], "evidence": [ { "id": "PA-04-E1", "description": "accountability_binding_artifact for each consequential AI action, containing action_id, agent_id, principal_id, delegation_basis_id, action_scope, action_timestamp, and integrity_hash (sha256) \u2014 all fields must be non-null", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PA-04-E2", "description": "tamper_evident_store_audit_record confirming the binding store is append-only and that no modification or deletion events occurred for any binding artifact during the audit period", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PA-04-E3", "description": "principal_existence_validation_record confirming the principal_id referenced in each binding artifact resolves to a current, active human identity in the enterprise identity system at the time of binding", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PA-04-E4", "description": "binding_completeness_scan result confirming 100% of consequential AI actions in the audit period have a corresponding accountability binding artifact with no gaps", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "Binding actions to accountable natural persons implements part of Art. 26 deployer human-oversight obligations." }, { "control": "apeiris://agentic/controls/AG-04", "id": "AG-04", "domain": "agentic", "name": "Senior Accountability for Autonomous AI Systems", "validation_objective": "Every AI agent operating at Medium consequence tier or above has a named accountable owner recorded in both the agent registry and the enterprise risk register, and that owner has formally signed the agent's authorization scope declaration and completed their most recent annual reaffirmation.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Agent registry entries for all Medium-tier-and-above agents showing named accountable owner, seniority level, assignment date, and scope declaration reference", "Signed authorization scope declaration for each in-scope agent, bearing the accountable owner's identity and the date of most recent reaffirmation", "Enterprise risk register entries linking each in-scope agent to its named accountable owner and consequence tier", "Annual reaffirmation records for each accountable owner assignment, confirming reaffirmation within the required cadence" ], "evidence": [ { "id": "AG-04-E1", "description": "Agent registry entries for all Medium-tier-and-above agents showing named accountable owner, seniority level, assignment date, and scope declaration reference", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-04-E2", "description": "Signed authorization scope declaration for each in-scope agent, bearing the accountable owner's identity and the date of most recent reaffirmation", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-04-E3", "description": "Enterprise risk register entries linking each in-scope agent to its named accountable owner and consequence tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-04-E4", "description": "Annual reaffirmation records for each accountable owner assignment, confirming reaffirmation within the required cadence", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 26 imposes explicit accountability obligations on deployers of high-risk AI systems, including designation of persons responsible for human oversight and accountability for consequences. Named senior accountable owners with formal acceptance records directly satisfy this requirement and provide the documentation regulators will seek." }, { "control": "apeiris://security/controls/GV-09", "id": "GV-09", "domain": "security", "name": "Anchor a named business owner to every agent (accountability)", "validation_objective": "Every production agent has a named, uniquely identified business owner bound to its workload identity before first deployment, an explicit incident RACI defining legal and operational liability, and the agent registry resolves both the business owner and engineering owner for any running agent within two minutes of an incident trigger.", "blocking_effect": "blocks-deployment", "evidence_required": [ "agent_registry_record for each production agent containing business_owner_id (unique employee or role identifier), engineering_owner_id, legal_liability_statement, and incident_raci_reference", "binding_audit_log confirming the business_owner_id field was populated and verified before the agent's first production deployment event", "incident_response_drill_record documenting a timed owner-lookup exercise where the on-call team resolved a production agent's full owner chain in under two minutes", "offboarding_check_record showing agents whose registered business owner changed roles or departed were re-assigned to a new named owner before continuity was broken" ], "evidence": [ { "id": "GV-09-E1", "description": "agent_registry_record for each production agent containing business_owner_id (unique employee or role identifier), engineering_owner_id, legal_liability_statement, and incident_raci_reference", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-09-E2", "description": "binding_audit_log confirming the business_owner_id field was populated and verified before the agent's first production deployment event", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-09-E3", "description": "incident_response_drill_record documenting a timed owner-lookup exercise where the on-call team resolved a production agent's full owner chain in under two minutes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-09-E4", "description": "offboarding_check_record showing agents whose registered business owner changed roles or departed were re-assigned to a new named owner before continuity was broken", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "EU-AIA-ART14-05", "section": "Art. 14(5)", "title": "Human oversight \u2014 automation bias prevention", "text": "Deployers shall take appropriate measures to ensure that the natural persons to whom human oversight has been assigned are able to properly interpret the AI system's output, taking into account in particular the risks of automation bias.", "verdict": "supported", "coverage": "direct", "notes": "GV-10 (Enable end-user responsibility and guard against automation bias) directly targets automation bias \u2014 it requires systems to present uncertainty information, limitation disclosures, and confidence calibration alongside outputs to prevent uncritical acceptance. HI-04 requires training and procedural safeguards for oversight personnel. XP-02 (Decision-Level Explanation Requirements) ensures outputs are contextualized to support critical evaluation rather than passive acceptance. XP-06 calibrates explanation depth to oversight personnel's technical level.", "control_count": 4, "proof_chain": [ { "control": "apeiris://ethics/controls/HI-04", "id": "HI-04", "domain": "ethics", "name": "Human Oversight and Override Mechanisms", "validation_objective": "All AI systems classified as significant or critical consequentiality tier must have override logging implemented and producing verifiable disposition records for every AI recommendation reviewed by a human operator. Override rate monitoring must be active and generating alerts when rates fall below defined thresholds, and every alert must trigger a documented review response within 30 days.", "blocking_effect": "blocks-deployment", "evidence_required": [ "consequentiality_tier_classification_record for every production AI system documenting the assigned tier (advisory/significant/critical), classification rationale, and mandatory oversight requirements that tier triggers", "override_audit_log for significant and critical tier systems showing AI recommendations, human dispositions (accepted/modified/rejected), override rationale where provided, and timestamps covering the prior 90 days", "override_rate_monitoring_report showing per-system trend data, defined threshold levels, alerts triggered in the prior 12 months, and documented investigation responses with completion dates", "interface_design_review_record confirming evaluation of the AI decision interface against automation-bias-avoidance criteria: confidence levels displayed, uncertainty ranges shown, override pathway accessible without additional navigation, AI-generated content distinguished from operator-entered content", "human_overseer_assignment_record naming the qualified overseer role for each significant and critical tier AI system with accountability documentation and training evidence" ], "evidence": [ { "id": "HI-04-E1", "description": "consequentiality_tier_classification_record for every production AI system documenting the assigned tier (advisory/significant/critical), classification rationale, and mandatory oversight requirements that tier triggers", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-04-E2", "description": "override_audit_log for significant and critical tier systems showing AI recommendations, human dispositions (accepted/modified/rejected), override rationale where provided, and timestamps covering the prior 90 days", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-04-E3", "description": "override_rate_monitoring_report showing per-system trend data, defined threshold levels, alerts triggered in the prior 12 months, and documented investigation responses with completion dates", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "HI-04-E4", "description": "interface_design_review_record confirming evaluation of the AI decision interface against automation-bias-avoidance criteria: confidence levels displayed, uncertainty ranges shown, override pathway accessible without additional navigation, AI-generated content distinguished from operator-entered content", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "HI-04-E5", "description": "human_overseer_assignment_record naming the qualified overseer role for each significant and critical tier AI system with accountability documentation and training evidence", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 14 mandates that high-risk AI systems be designed to allow effective human oversight, including the ability to understand capabilities and limitations, detect and address malfunctions, and override or interrupt system outputs. This control operationalizes each of these requirements through tier-based oversight design and automation-bias monitoring." }, { "control": "apeiris://security/controls/GV-10", "id": "GV-10", "domain": "security", "name": "Enable end-user responsibility and guard against automation bias", "validation_objective": "Every end user interacting with an agent is explicitly informed at the point of interaction that they are dealing with an AI agent and what actions it can take; all reviewers of agent actions have completed current role-specific training on that agent's failure modes; and oversight telemetry confirms approval override rates and review response times remain within bounds consistent with meaningful human judgment rather than rubber-stamping.", "blocking_effect": "requires-review", "evidence_required": [ "ui_disclosure_audit showing an AI-agent disclosure notice rendering at every end-user interaction surface before the agent takes action, including the agent's permitted action scope", "training_completion_records confirming all designated reviewers for each agent class completed role-specific failure-mode training within the policy refresh window", "oversight_telemetry_report per agent class showing override rate, median review response time, and outlier-reviewer flags over the review period", "bias_remediation_record for any reviewer or agent class where override rate approached zero or review latency fell below the plausible-decision floor, documenting the corrective action taken and its outcome" ], "evidence": [ { "id": "GV-10-E1", "description": "ui_disclosure_audit showing an AI-agent disclosure notice rendering at every end-user interaction surface before the agent takes action, including the agent's permitted action scope", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-10-E2", "description": "training_completion_records confirming all designated reviewers for each agent class completed role-specific failure-mode training within the policy refresh window", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-10-E3", "description": "oversight_telemetry_report per agent class showing override rate, median review response time, and outlier-reviewer flags over the review period", "evidence_type": "human-review-record", "verification": "human" }, { "id": "GV-10-E4", "description": "bias_remediation_record for any reviewer or agent class where override rate approached zero or review latency fell below the plausible-decision floor, documenting the corrective action taken and its outcome", "evidence_type": "human-review-record", "verification": "human" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://ethics/controls/XP-02", "id": "XP-02", "domain": "ethics", "name": "Decision-Level Explanation Requirements", "validation_objective": "Each class of AI-driven decision has a documented explanation specification that defines the required explanation type, depth, and format, explicitly maps to applicable legal obligations (GDPR Art. 22, EU AI Act Art. 13, Colorado AI Act, or other jurisdiction-specific requirements), and is implemented in deployed systems such that explanations generated conform to the specification and are verifiably produced before each decision is communicated.", "blocking_effect": "blocks-deployment", "evidence_required": [ "decision_explanation_specification per decision class with fields: decision_class_id, applicable_legal_obligations, required_explanation_type (feature-attribution, counterfactual, rule-based, natural-language), required_depth (summary, detailed, technical), required_format (structured-json, natural-language, visual), and audience (end-user, regulator, internal-audit)", "explanation_generation_log showing that for each AI decision record a corresponding explanation artifact was generated with timestamp, decision_id, explanation_type, and explanation_content_hash", "explanation_format_compliance_test_report confirming that generated explanations conform to the specification for each decision class", "legal_review_attestation confirming the explanation specification meets applicable legal obligations for each jurisdiction in which the system is deployed" ], "evidence": [ { "id": "XP-02-E1", "description": "decision_explanation_specification per decision class with fields: decision_class_id, applicable_legal_obligations, required_explanation_type (feature-attribution, counterfactual, rule-based, natural-language), required_depth (summary, detailed, technical), required_format (structured-json, natural-language, visual), and audience (end-user, regulator, internal-audit)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "XP-02-E2", "description": "explanation_generation_log showing that for each AI decision record a corresponding explanation artifact was generated with timestamp, decision_id, explanation_type, and explanation_content_hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "XP-02-E3", "description": "explanation_format_compliance_test_report confirming that generated explanations conform to the specification for each decision class", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "XP-02-E4", "description": "legal_review_attestation confirming the explanation specification meets applicable legal obligations for each jurisdiction in which the system is deployed", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 13 mandates transparency requirements for high-risk AI systems, and Art. 86 provides individuals the right to explanation for significant AI-driven decisions. The decision taxonomy directly operationalizes these requirements by mapping each decision class to its applicable obligations." }, { "control": "apeiris://ethics/controls/XP-06", "id": "XP-06", "domain": "ethics", "name": "Technical vs. Non-Technical Explanation Tiers", "validation_objective": "All AI decision systems classified as requiring explanations must implement a minimum three-tier explanation structure (affected-individual plain-language, business-operational summary, technical audit log) that accurately represents the decision at each tier without distortion. Tier-1 individual explanations must pass intelligibility review with representative target audience members prior to production.", "blocking_effect": "blocks-deployment", "evidence_required": [ "explanation_tier_matrix document mapping each audience type (affected individual, business user, technical reviewer, regulator) to required explanation format, depth, and delivery mechanism for each high-stakes AI system", "tier-1 plain-language explanation samples with intelligibility testing records showing comprehension scores from representative target audience participants", "tier-3 technical audit log samples showing feature attribution, model version, and decision factors with cross-reference to corresponding tier-1 explanation for accuracy comparison", "access control configuration records confirming tier-1 explanations are accessible to affected individuals on demand within legally required timeframes", "tier translation methodology documentation showing how technical attribution outputs map to plain-language explanations without material inaccuracy" ], "evidence": [ { "id": "XP-06-E1", "description": "explanation_tier_matrix document mapping each audience type (affected individual, business user, technical reviewer, regulator) to required explanation format, depth, and delivery mechanism for each high-stakes AI system", "evidence_type": "human-review-record", "verification": "human" }, { "id": "XP-06-E2", "description": "tier-1 plain-language explanation samples with intelligibility testing records showing comprehension scores from representative target audience participants", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "XP-06-E3", "description": "tier-3 technical audit log samples showing feature attribution, model version, and decision factors with cross-reference to corresponding tier-1 explanation for accuracy comparison", "evidence_type": "audit-log", "verification": "automated" }, { "id": "XP-06-E4", "description": "access control configuration records confirming tier-1 explanations are accessible to affected individuals on demand within legally required timeframes", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "XP-06-E5", "description": "tier translation methodology documentation showing how technical attribution outputs map to plain-language explanations without material inaccuracy", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 13 requires that high-risk AI systems provide information accessible to deployers, and Art. 86 requires that affected individuals receive explanations in a clear and meaningful form. The tiered explanation framework directly implements both requirements by ensuring each audience receives calibrated information." } ] }, { "requirement_id": "EU-AIA-ART15-01", "section": "Art. 15(1)", "title": "Accuracy, robustness, cybersecurity \u2014 appropriate levels throughout lifecycle", "text": "High-risk AI systems shall be designed and developed in such a way that they achieve, in the light of their intended purpose, an appropriate level of accuracy, robustness and cybersecurity, and perform consistently in those respects throughout their lifecycle.", "verdict": "supported", "coverage": "direct", "notes": "BH-02 (Concept and Data Drift Detection) monitors for accuracy degradation due to distribution shift across the lifecycle. BH-03 (Production Performance Degradation Alerting) triggers alerts when production accuracy metrics fall below defined thresholds, enabling timely remediation. CR-03 (Scheduled Model Re-validation) requires periodic re-evaluation against defined accuracy thresholds to confirm sustained compliance throughout the lifecycle. EV-02 establishes the accuracy and robustness metrics against which lifecycle performance is measured.", "control_count": 4, "proof_chain": [ { "control": "apeiris://model/controls/BH-02", "id": "BH-02", "domain": "model", "name": "Concept and Data Drift Detection", "validation_objective": "The production inference pipeline must compare input feature distributions and prediction distributions against a versioned, SHA-256-signed DriftReference artifact using PSI and KS-test statistics for every monitoring window that meets minimum_sample_size, such that drift exceeding profile-conditional PSI thresholds triggers tiered alert actions, and for continuously-learning profiles, automatically suspends online updates pending a signed model-owner resume authorization.", "blocking_effect": "advisory", "evidence_required": [ "versioned DriftReference artifact for the current production model with SHA-256 hash, training date, and per-feature statistics (mean, std, histogram bins, and KDE parameters) for all tier-1 monitored features", "drift event log for trailing 90 days with fields: feature_name, test_statistic, p_value, window_start, window_end, sample_count, alert_severity, and action_taken for each drift event", "monthly drift summary report signed by the model owner, including trend analysis across tier-1 features and prediction distribution PSI over the reporting period", "profile-conditional drift threshold configuration (YAML or equivalent) showing per-profile PSI alert and critical thresholds, minimum_sample_size, and window duration, stored under version control" ], "evidence": [ { "id": "BH-02-E1", "description": "versioned DriftReference artifact for the current production model with SHA-256 hash, training date, and per-feature statistics (mean, std, histogram bins, and KDE parameters) for all tier-1 monitored features", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-02-E2", "description": "drift event log for trailing 90 days with fields: feature_name, test_statistic, p_value, window_start, window_end, sample_count, alert_severity, and action_taken for each drift event", "evidence_type": "audit-log", "verification": "automated" }, { "id": "BH-02-E3", "description": "monthly drift summary report signed by the model owner, including trend analysis across tier-1 features and prediction distribution PSI over the reporting period", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-02-E4", "description": "profile-conditional drift threshold configuration (YAML or equivalent) showing per-profile PSI alert and critical thresholds, minimum_sample_size, and window duration, stored under version control", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 72 requires providers and deployers of high-risk AI systems to establish and document post-market monitoring plans; BH-02's drift detection operationalizes the monitoring dimension by tracking input feature distribution and prediction shifts using PSI and KS-test statistics against signed baseline artifacts." }, { "control": "apeiris://model/controls/BH-03", "id": "BH-03", "domain": "model", "name": "Production Performance Degradation Alerting", "validation_objective": "Every production model version must have a corresponding signed EvaluationBaseline artifact containing primary task metrics and subgroup slice metrics from the release evaluation gate; the metrics aggregation service must continuously compare production estimates against this baseline and fire tiered alerts when primary metrics regress 5% (warning) or 10% (critical) from the signed baseline values, including independent subgroup regression alerts.", "blocking_effect": "advisory", "evidence_required": [ "signed EvaluationBaseline artifact for the current production model version containing model_id, version, eval_date, primary_metrics with confidence intervals, subgroup slice metrics, eval_dataset_hash, and artifact SHA-256", "performance alert log for trailing 90 days with fields: alert_id, metric_name, regression_pct, severity, triggered_at, acknowledged_at, root_cause, and remediation_action for each alert", "quarterly threshold review sign-off from model owner confirming 5%/10% regression thresholds remain appropriate for the current model type and deployment context", "proxy_metric_registry documenting which proxy metrics substitute for labeled ground truth when unavailable, including calibration methodology and documented limitations" ], "evidence": [ { "id": "BH-03-E1", "description": "signed EvaluationBaseline artifact for the current production model version containing model_id, version, eval_date, primary_metrics with confidence intervals, subgroup slice metrics, eval_dataset_hash, and artifact SHA-256", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-03-E2", "description": "performance alert log for trailing 90 days with fields: alert_id, metric_name, regression_pct, severity, triggered_at, acknowledged_at, root_cause, and remediation_action for each alert", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "BH-03-E3", "description": "quarterly threshold review sign-off from model owner confirming 5%/10% regression thresholds remain appropriate for the current model type and deployment context", "evidence_type": "human-review-record", "verification": "human" }, { "id": "BH-03-E4", "description": "proxy_metric_registry documenting which proxy metrics substitute for labeled ground truth when unavailable, including calibration methodology and documented limitations", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 72 requires high-risk AI system providers to implement post-market monitoring covering performance evaluation; BH-03's performance regression alerting \u2014 tracking accuracy, AUC, and F1 against a signed performance baseline \u2014 directly operationalizes the performance monitoring component of a post-market monitoring plan." }, { "control": "apeiris://model/controls/CR-03", "id": "CR-03", "domain": "model", "name": "Scheduled Model Re-validation", "validation_objective": "A full benchmark, bias, and safety evaluation suite must execute against every production model version on the defined re-validation schedule; results must be compared to the deployment-time baseline metrics, and any performance degradation beyond configured thresholds must trigger a formal response documented and initiated before the next operational window closes.", "blocking_effect": "blocks-deployment", "evidence_required": [ "re_validation_schedule_record per model version showing configured re-validation frequency, last_run_timestamp, next_run_due, and scheduled_suite_identifier with no unmonitored production versions", "scheduled_evaluation_report for each re-validation run showing benchmark results, bias metrics, and safety evaluation scores with explicit comparison to the deployment-time baseline", "threshold_comparison_record showing the delta between current re-validation results and baseline for each metric with a pass/fail determination against the configured degradation threshold", "re_validation_response_record for any threshold breach, documenting the triggered response action (rollback, retraining, or escalation), responsible_party, and closure_timestamp", "re_validation_coverage_audit confirming all active production model versions are enrolled in re-validation schedules and that no version has exceeded its next_run_due without a completed run" ], "evidence": [ { "id": "CR-03-E1", "description": "re_validation_schedule_record per model version showing configured re-validation frequency, last_run_timestamp, next_run_due, and scheduled_suite_identifier with no unmonitored production versions", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-03-E2", "description": "scheduled_evaluation_report for each re-validation run showing benchmark results, bias metrics, and safety evaluation scores with explicit comparison to the deployment-time baseline", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "CR-03-E3", "description": "threshold_comparison_record showing the delta between current re-validation results and baseline for each metric with a pass/fail determination against the configured degradation threshold", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-03-E4", "description": "re_validation_response_record for any threshold breach, documenting the triggered response action (rollback, retraining, or escalation), responsible_party, and closure_timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-03-E5", "description": "re_validation_coverage_audit confirming all active production model versions are enrolled in re-validation schedules and that no version has exceeded its next_run_due without a completed run", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 72 requires high-risk AI system providers to establish post-market monitoring systems that systematically collect and analyse data about model performance; CR-03's scheduled re-evaluation cadence and event-driven re-evaluation triggers directly implement the continuous monitoring and periodic review requirements that underpin Art. 72 compliance." }, { "control": "apeiris://model/controls/EV-02", "id": "EV-02", "domain": "model", "name": "Fitness, Safety, Reliability and Policy-Conformance Evaluation", "validation_objective": "Before deployment, every model has been evaluated against pre-specified, dimension-level pass/fail thresholds \u2014 fitness, safety, reliability, and policy-conformance \u2014 with results documented against the model artifact hash and evaluation suite version. No threshold is modified after evaluation begins, and any threshold trade-off decision is documented as a named risk-acceptance record before the deployment manifest is signed.", "blocking_effect": "blocks-deployment", "evidence_required": [ "pre_specified_evaluation_protocol with model_artifact_hash, evaluation_suite_version, and per-dimension thresholds (fitness accuracy target, safety refusal rate, reliability error budget, policy-conformance violation rate), signed by the evaluation lead before testing begins \u2014 not after results are known", "dimension_level_evaluation_results showing per-dimension metric values, pass/fail verdict against pre-specified threshold, and model_artifact_hash confirming results correspond to the evaluated version", "evaluation_suite_provenance_record confirming that evaluation datasets are disjoint from training data, with contamination-check reference to TG-05 attestation", "risk_acceptance_record for any dimension where the pass threshold was not met but deployment was authorized, documenting named risk-accepter, specific capability gap, deployment risk consequence, and remediation deadline" ], "evidence": [ { "id": "EV-02-E1", "description": "pre_specified_evaluation_protocol with model_artifact_hash, evaluation_suite_version, and per-dimension thresholds (fitness accuracy target, safety refusal rate, reliability error budget, policy-conformance violation rate), signed by the evaluation lead before testing begins \u2014 not after results are known", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-02-E2", "description": "dimension_level_evaluation_results showing per-dimension metric values, pass/fail verdict against pre-specified threshold, and model_artifact_hash confirming results correspond to the evaluated version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-02-E3", "description": "evaluation_suite_provenance_record confirming that evaluation datasets are disjoint from training data, with contamination-check reference to TG-05 attestation", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-02-E4", "description": "risk_acceptance_record for any dimension where the pass threshold was not met but deployment was authorized, documenting named risk-accepter, specific capability gap, deployment risk consequence, and remediation deadline", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "Art. 9(5) requires testing against defined metrics and probabilistic thresholds; Art. 9(6) requires accuracy, robustness, and cybersecurity evaluation for high-risk systems." } ] }, { "requirement_id": "EU-AIA-ART15-02", "section": "Art. 15(2)", "title": "Accuracy \u2014 declared accuracy metrics", "text": "The levels of accuracy and the relevant accuracy metrics of high-risk AI systems shall be declared in the accompanying instructions for use.", "verdict": "supported", "coverage": "direct", "notes": "EV-02 (Fitness, Safety, Reliability and Policy-Conformance Evaluation) produces the accuracy metrics that must be declared. EV-06 (Reproducible Evaluation Design) ensures metrics are defined, reproducible, and suitable for public disclosure. BH-01 (Output Anomaly Detection) monitors that production outputs remain consistent with declared accuracy metrics. LI-04 (Model Card) is the primary vehicle for disclosing accuracy metrics in the instructions for use.", "control_count": 4, "proof_chain": [ { "control": "apeiris://model/controls/EV-02", "id": "EV-02", "domain": "model", "name": "Fitness, Safety, Reliability and Policy-Conformance Evaluation", "validation_objective": "Before deployment, every model has been evaluated against pre-specified, dimension-level pass/fail thresholds \u2014 fitness, safety, reliability, and policy-conformance \u2014 with results documented against the model artifact hash and evaluation suite version. No threshold is modified after evaluation begins, and any threshold trade-off decision is documented as a named risk-acceptance record before the deployment manifest is signed.", "blocking_effect": "blocks-deployment", "evidence_required": [ "pre_specified_evaluation_protocol with model_artifact_hash, evaluation_suite_version, and per-dimension thresholds (fitness accuracy target, safety refusal rate, reliability error budget, policy-conformance violation rate), signed by the evaluation lead before testing begins \u2014 not after results are known", "dimension_level_evaluation_results showing per-dimension metric values, pass/fail verdict against pre-specified threshold, and model_artifact_hash confirming results correspond to the evaluated version", "evaluation_suite_provenance_record confirming that evaluation datasets are disjoint from training data, with contamination-check reference to TG-05 attestation", "risk_acceptance_record for any dimension where the pass threshold was not met but deployment was authorized, documenting named risk-accepter, specific capability gap, deployment risk consequence, and remediation deadline" ], "evidence": [ { "id": "EV-02-E1", "description": "pre_specified_evaluation_protocol with model_artifact_hash, evaluation_suite_version, and per-dimension thresholds (fitness accuracy target, safety refusal rate, reliability error budget, policy-conformance violation rate), signed by the evaluation lead before testing begins \u2014 not after results are known", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-02-E2", "description": "dimension_level_evaluation_results showing per-dimension metric values, pass/fail verdict against pre-specified threshold, and model_artifact_hash confirming results correspond to the evaluated version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-02-E3", "description": "evaluation_suite_provenance_record confirming that evaluation datasets are disjoint from training data, with contamination-check reference to TG-05 attestation", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-02-E4", "description": "risk_acceptance_record for any dimension where the pass threshold was not met but deployment was authorized, documenting named risk-accepter, specific capability gap, deployment risk consequence, and remediation deadline", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "Art. 9(5) requires testing against defined metrics and probabilistic thresholds; Art. 9(6) requires accuracy, robustness, and cybersecurity evaluation for high-risk systems." }, { "control": "apeiris://model/controls/EV-06", "id": "EV-06", "domain": "model", "name": "Reproducible Evaluation Design", "validation_objective": "Every evaluation run against a model artifact can be independently reproduced from the evaluation design document alone within the defined tolerance by a party who was not involved in the original run; all benchmarks have documented contamination screening results; and all evaluation artifacts are signed with SHA-256 content-addressed hashes recorded in the evaluation manifest.", "blocking_effect": "blocks-deployment", "evidence_required": [ "version_controlled_benchmark_selection_document with pre-specified selection_criteria, benchmark_ids, known_limitations, and alternatives_considered \u2014 signed and committed before any evaluation run begins", "contamination_screening_report documenting screening_methodology, training_corpus_reference, per-benchmark contamination_result (clean/flagged/excluded), and screening_date", "evaluation_design_document capturing all reproduction parameters: random_seeds, software_dependency_versions with hashes, hardware_configuration, serving_framework_config, eval_script_version_and_hash, prompt_templates, and post_processing_steps", "independent_reproduction_run_record showing reproduction_results within the defined tolerance alongside original_results, confirming design document sufficiency for independent replication", "signed_evaluation_artifact_manifest listing SHA-256 hashes for all artifacts (design document, scripts, datasets, results) with signer_identity and key_identifier" ], "evidence": [ { "id": "EV-06-E1", "description": "version_controlled_benchmark_selection_document with pre-specified selection_criteria, benchmark_ids, known_limitations, and alternatives_considered \u2014 signed and committed before any evaluation run begins", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-06-E2", "description": "contamination_screening_report documenting screening_methodology, training_corpus_reference, per-benchmark contamination_result (clean/flagged/excluded), and screening_date", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-06-E3", "description": "evaluation_design_document capturing all reproduction parameters: random_seeds, software_dependency_versions with hashes, hardware_configuration, serving_framework_config, eval_script_version_and_hash, prompt_templates, and post_processing_steps", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-06-E4", "description": "independent_reproduction_run_record showing reproduction_results within the defined tolerance alongside original_results, confirming design document sufficiency for independent replication", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-06-E5", "description": "signed_evaluation_artifact_manifest listing SHA-256 hashes for all artifacts (design document, scripts, datasets, results) with signer_identity and key_identifier", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "Art. 9(5) requires testing procedures to be documented; reproducible design operationalizes this requirement." }, { "control": "apeiris://model/controls/BH-01", "id": "BH-01", "domain": "model", "name": "Output Anomaly Detection", "validation_objective": "The production inference endpoint must be continuously sampled and output distributions must be statistically compared against a versioned, SHA-256-signed baseline artifact using PSI and Shewhart/EWMA control chart methods, such that any distribution shift exceeding PSI 0.2 fires a tiered alert within one monitoring window of the shift occurring and all anomaly events are stored in the evidence registry with BH-01 control linkage.", "blocking_effect": "advisory", "evidence_required": [ "versioned, SHA-256-signed baseline distribution artifact stored in the model registry with per-metric statistics (mean, std_dev, p5/p50/p95/p99) computed from the 30-day post-deployment stable window", "SPC alert log for trailing 90 days with fields: alert_id, trigger_metric, psi_value, alert_severity, triggered_at, acknowledged_at, and resolution_outcome", "PII masking audit record confirming no direct identifier fields (email, SSN, full name) appear in the sampled output storage for the trailing 30 days", "quarterly threshold review sign-off from model owner confirming PSI alert (0.2) and critical (0.25) thresholds remain appropriate for the current deployment context" ], "evidence": [ { "id": "BH-01-E1", "description": "versioned, SHA-256-signed baseline distribution artifact stored in the model registry with per-metric statistics (mean, std_dev, p5/p50/p95/p99) computed from the 30-day post-deployment stable window", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-01-E2", "description": "SPC alert log for trailing 90 days with fields: alert_id, trigger_metric, psi_value, alert_severity, triggered_at, acknowledged_at, and resolution_outcome", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "BH-01-E3", "description": "PII masking audit record confirming no direct identifier fields (email, SSN, full name) appear in the sampled output storage for the trailing 30 days", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-01-E4", "description": "quarterly threshold review sign-off from model owner confirming PSI alert (0.2) and critical (0.25) thresholds remain appropriate for the current deployment context", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 15 requires high-risk AI systems to achieve an appropriate level of accuracy, robustness and cybersecurity; BH-01's statistical process control and PSI-based output anomaly detection directly supports the robustness dimension by detecting production anomalies before they cause downstream harm." }, { "control": "apeiris://model/controls/LI-04", "id": "LI-04", "domain": "model", "name": "Structured Model Documentation \u2014 Complete Model Card with All Required Sections", "validation_objective": "Every model submitted for registration must have a schema-validated model card with all nine Mitchell et al. 2019 sections substantively populated and passing field-level validation rules; the model card must be version-locked to the artifact hash and returned as structured metadata from the registry API; and registration must be blocked when any required section is absent, empty, or contains only placeholder text.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_card_completeness_validation_report showing pass/fail status per section with field-level validation results, registration blocking decision, and validation timestamp for the current artifact version", "versioned_model_card artifact linked to the specific model artifact hash with all nine Mitchell et al. sections containing substantive content (not placeholder text), retrievable from the registry by artifact hash", "model_registry_entry showing the current model card version hash stored alongside the artifact hash as paired immutable fields", "eu_ai_act_annex_iv_supplemental_record for EU AI Act high-risk in-scope systems confirming Annex IV technical documentation fields are populated in addition to the nine Mitchell et al. sections" ], "evidence": [ { "id": "LI-04-E1", "description": "model_card_completeness_validation_report showing pass/fail status per section with field-level validation results, registration blocking decision, and validation timestamp for the current artifact version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-04-E2", "description": "versioned_model_card artifact linked to the specific model artifact hash with all nine Mitchell et al. sections containing substantive content (not placeholder text), retrievable from the registry by artifact hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-04-E3", "description": "model_registry_entry showing the current model card version hash stored alongside the artifact hash as paired immutable fields", "evidence_type": "model-card", "verification": "attested" }, { "id": "LI-04-E4", "description": "eu_ai_act_annex_iv_supplemental_record for EU AI Act high-risk in-scope systems confirming Annex IV technical documentation fields are populated in addition to the nine Mitchell et al. sections", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art-11 requires providers of high-risk AI systems to prepare and maintain technical documentation before market placement. The Mitchell et al. 9-section model card supplemented with Annex IV fields directly satisfies Art-11's technical documentation requirement. This control supports satisfaction of Art-11 for covered deployments; applicability depends on the deployer's role (provider vs. deployer) and the system's high-risk classification." } ] }, { "requirement_id": "EU-AIA-ART15-03", "section": "Art. 15(3)", "title": "Robustness \u2014 technical robustness to errors, faults, and inconsistencies", "text": "High-risk AI systems shall be resilient to errors, faults or inconsistencies that may occur within the system or in the environment in which the systems operate. Technically redundant solutions shall be considered.", "verdict": "supported", "coverage": "direct", "notes": "EV-04 (Adversarial Red-Team Testing) systematically tests robustness under error injection, adversarial inputs, and edge cases. BH-04 (Behavioral Boundary Performance Testing) validates system behavior at boundary conditions and under inconsistent inputs. FO-01 (Graceful Degradation Design Patterns) requires fallback behaviors when primary system components fail. FO-04 (Input Validation and Malformed Request Handling) prevents system failures from malformed or inconsistent inputs at the infrastructure level.", "control_count": 4, "proof_chain": [ { "control": "apeiris://model/controls/EV-04", "id": "EV-04", "domain": "model", "name": "Adversarial Red-Team Testing", "validation_objective": "The model system has a signed red-team report produced by a team organizationally independent of model development, documenting structured adversarial probing that covers all required attack categories for the applicable profiles, with all critical and high findings remediated and re-tested before the deployment gate clears.", "blocking_effect": "blocks-deployment", "evidence_required": [ "signed_red_team_scope_document with threat_model version, profile scope, and pre-exercise approval timestamp", "red_team_findings_log with finding_id, severity_classification, reproduction_steps, affected_population, and remediation_status per finding", "signed_red_team_report with residual_risk_statement linked to model artifact hash and listing remediated critical and high findings with re-test results", "remediation_evidence for all critical and high findings demonstrating the vulnerability is closed via re-test, not only via input-level patch", "for frontier-capability profile: escalation_records for any capability elicited at or near threshold levels with escalation_destination and response_action" ], "evidence": [ { "id": "EV-04-E1", "description": "signed_red_team_scope_document with threat_model version, profile scope, and pre-exercise approval timestamp", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EV-04-E2", "description": "red_team_findings_log with finding_id, severity_classification, reproduction_steps, affected_population, and remediation_status per finding", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-04-E3", "description": "signed_red_team_report with residual_risk_statement linked to model artifact hash and listing remediated critical and high findings with re-test results", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "EV-04-E4", "description": "remediation_evidence for all critical and high findings demonstrating the vulnerability is closed via re-test, not only via input-level patch", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "EV-04-E5", "description": "for frontier-capability profile: escalation_records for any capability elicited at or near threshold levels with escalation_destination and response_action", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "Art. 55(1)(a) requires providers of GPAI models with systemic risk to conduct adversarial testing prior to deployment." }, { "control": "apeiris://model/controls/BH-04", "id": "BH-04", "domain": "model", "name": "Behavioral Boundary Performance Testing", "validation_objective": "A versioned BoundaryTestSuite must be executed at minimum daily against the production inference endpoint, BoundaryAdherenceRate must be computed per boundary category and trended over a 30-day rolling window, and critical alerts plus cross-domain notifications to securitycontrols.ai must fire within one probe cycle when any category drops below 90% adherence \u2014 with all probe results logged in the evidence registry under BH-04 control linkage.", "blocking_effect": "advisory", "evidence_required": [ "versioned BoundaryTestSuite artifact with probe categories covered, probe count per category, probe source documentation, and last review date signed by the model owner and security team", "BoundaryAdherenceRate time-series for trailing 90 days per boundary category, including probe_id, timestamp, model_version, response_hash, and pass/fail for each probe execution", "cross-domain alert log showing securitycontrols.ai notifications for adherence drops with triggered_at, affected_category, adherence_rate, and acknowledgment timestamp for each event in the trailing 90 days", "pre-release BoundaryTestSuite run results for the current production model version establishing the BoundaryAdherenceRate baseline at deployment" ], "evidence": [ { "id": "BH-04-E1", "description": "versioned BoundaryTestSuite artifact with probe categories covered, probe count per category, probe source documentation, and last review date signed by the model owner and security team", "evidence_type": "human-review-record", "verification": "human" }, { "id": "BH-04-E2", "description": "BoundaryAdherenceRate time-series for trailing 90 days per boundary category, including probe_id, timestamp, model_version, response_hash, and pass/fail for each probe execution", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-04-E3", "description": "cross-domain alert log showing securitycontrols.ai notifications for adherence drops with triggered_at, affected_category, adherence_rate, and acknowledgment timestamp for each event in the trailing 90 days", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "BH-04-E4", "description": "pre-release BoundaryTestSuite run results for the current production model version establishing the BoundaryAdherenceRate baseline at deployment", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 15 requires high-risk AI systems to be robust against attempts to manipulate outputs through adversarial inputs; BH-04's behavioral boundary enforcement \u2014 including guardrail compliance monitoring and injection-resistance metrics \u2014 supports the cybersecurity and robustness dimensions of Art. 15." }, { "control": "apeiris://resilience/controls/FO-01", "id": "FO-01", "domain": "resilience", "name": "Graceful Degradation Design Patterns", "validation_objective": "Every AI system must activate a documented degraded-mode behavior profile within 30 seconds of detecting a core dependency failure, preserve core capability delivery at the defined reduced SLA, and emit a distinct degradation_activation operational event. No enhanced capability may serve uncommunicated stale or partial outputs as authoritative responses during an active degradation period.", "blocking_effect": "advisory", "evidence_required": [ "capability_tier_inventory classifying each AI system capability as core or enhanced with documented degraded-mode SLA targets and fallback output type for each", "health_check_driven_feature_toggle_test_results confirming automatic degradation activation and correct output behavior under simulated upstream dependency failures in staging", "degradation_event_log with degradation_type, affected_capability, activation_timestamp, and duration fields for all degradation events observed in the audit period", "degraded_mode_security_review confirming authentication, authorization, rate limiting, and output filtering controls remain active on every fallback code path" ], "evidence": [ { "id": "FO-01-E1", "description": "capability_tier_inventory classifying each AI system capability as core or enhanced with documented degraded-mode SLA targets and fallback output type for each", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FO-01-E2", "description": "health_check_driven_feature_toggle_test_results confirming automatic degradation activation and correct output behavior under simulated upstream dependency failures in staging", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FO-01-E3", "description": "degradation_event_log with degradation_type, affected_capability, activation_timestamp, and duration fields for all degradation events observed in the audit period", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FO-01-E4", "description": "degraded_mode_security_review confirming authentication, authorization, rate limiting, and output filtering controls remain active on every fallback code path", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://resilience/controls/FO-04", "id": "FO-04", "domain": "resilience", "name": "Input Validation and Malformed Request Handling", "validation_objective": "The AI system must reject malformed, oversized, and prompt-injection-suspect inputs at the API gateway layer with a structured non-leaking error response before dispatching to the AI inference engine. Every exception handler in the inference and orchestration layer must return a sanitized response containing no stack traces, internal hostnames, model identifiers, or configuration details visible to the calling client.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "input_validation_schema_documentation for all AI API endpoints specifying field types, maximum token and character limits, required fields, and content policy constraints, reviewed within the past year", "validation_failure_metric_report with per-validation-layer failure counts by type (schema, length, injection_detected, budget_exceeded) over the audit period showing rejection occurs at the gateway before inference dispatch", "prompt_injection_test_results confirming coverage of current OWASP LLM Top 10 injection techniques against the deployed model and gateway configuration, conducted within the past 90 days", "exception_response_audit_log or penetration test report confirming all exception responses returned to callers contain no stack traces, internal hostnames, model identifiers, or configuration details" ], "evidence": [ { "id": "FO-04-E1", "description": "input_validation_schema_documentation for all AI API endpoints specifying field types, maximum token and character limits, required fields, and content policy constraints, reviewed within the past year", "evidence_type": "human-review-record", "verification": "human" }, { "id": "FO-04-E2", "description": "validation_failure_metric_report with per-validation-layer failure counts by type (schema, length, injection_detected, budget_exceeded) over the audit period showing rejection occurs at the gateway before inference dispatch", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FO-04-E3", "description": "prompt_injection_test_results confirming coverage of current OWASP LLM Top 10 injection techniques against the deployed model and gateway configuration, conducted within the past 90 days", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "FO-04-E4", "description": "exception_response_audit_log or penetration test report confirming all exception responses returned to callers contain no stack traces, internal hostnames, model identifiers, or configuration details", "evidence_type": "third-party-audit-report", "verification": "third-party" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "EU-AIA-ART15-04", "section": "Art. 15(4)", "title": "Cybersecurity \u2014 protection against adversarial attacks", "text": "The technical solutions to address cybersecurity of high-risk AI systems shall be appropriate to the relevant circumstances and shall include measures to prevent, detect, respond to, and protect against attacks attempting to manipulate the training dataset, pre-trained components or the deployment environment.", "verdict": "supported", "coverage": "direct", "notes": "AS-01 (Adversarial red-team and evaluate before launch) provides comprehensive cybersecurity testing including adversarial attack simulation against the AI system. TG-04 (Data Poisoning Prevention) directly addresses the training dataset manipulation threat cited in Art. 15(4). RT-02 (Detect direct and indirect prompt injection at every input and output) addresses inference-time manipulation attacks on deployed systems. EC-01 (Sandbox \u2014 process isolation to micro-VMs) secures the deployment environment against compromise.", "control_count": 5, "proof_chain": [ { "control": "apeiris://security/controls/AS-01", "id": "AS-01", "domain": "security", "name": "Adversarially red-team and evaluate the agent before launch", "validation_objective": "Before any deployment to production, the agent must have passed a structured adversarial red-team exercise covering multi-turn goal hijack, tool misuse, and data exfiltration scenarios, with measured attack-success-rates at or below the defined launch threshold. Deployment must be blocked until the red-team pass/fail gate is cleared and documented.", "blocking_effect": "blocks-deployment", "evidence_required": [ "pre_launch_red_team_report listing each scenario (multi-turn hijack, tool-misuse, exfiltration), the attack-success-rate per scenario, the defined launch threshold, and a signed go/no-go decision", "multi_turn_eval_suite_run_log showing the agentic benchmark used (e.g., AgentDojo, FinBot CTF), commit SHA, run date, and overall pass/fail outcome against the threshold", "red_team_scope_document confirming coverage of multi-turn drift scenarios not only single-prompt tests, signed before the red-team exercise begins", "launch_gate_approval_record linking the red-team report to the deployment decision with approver identity and timestamp" ], "evidence": [ { "id": "AS-01-E1", "description": "pre_launch_red_team_report listing each scenario (multi-turn hijack, tool-misuse, exfiltration), the attack-success-rate per scenario, the defined launch threshold, and a signed go/no-go decision", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AS-01-E2", "description": "multi_turn_eval_suite_run_log showing the agentic benchmark used (e.g., AgentDojo, FinBot CTF), commit SHA, run date, and overall pass/fail outcome against the threshold", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "AS-01-E3", "description": "red_team_scope_document confirming coverage of multi-turn drift scenarios not only single-prompt tests, signed before the red-team exercise begins", "evidence_type": "red-team-report", "verification": "third-party" }, { "id": "AS-01-E4", "description": "launch_gate_approval_record linking the red-team report to the deployment decision with approver identity and timestamp", "evidence_type": "red-team-report", "verification": "third-party" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://model/controls/TG-04", "id": "TG-04", "domain": "model", "name": "Data Poisoning Prevention", "validation_objective": "Every training shard must pass cryptographic integrity verification against a pre-ingestion hash before it is admitted to a training run; adversarial input screening must be applied at ingestion for all external or third-party data sources; and a chain-of-custody record must exist for every data transformation applied to the training corpus.", "blocking_effect": "blocks-deployment", "evidence_required": [ "training_shard_integrity_manifest listing the cryptographic hash (SHA-256 or stronger) for each shard, the verification timestamp, and the verification result (pass/fail/recomputed) for the current training run", "adversarial_screening_report for each external data source ingested, including the screening method applied, the number of records inspected, any detected anomalies or suspicious patterns, and the disposition (accepted/quarantined/rejected)", "chain_of_custody_record for each data transformation applied to the training corpus, including the transformation type, operator identity, input hash, output hash, and transformation timestamp", "supply_chain_integrity_check_record confirming that third-party training data packages (datasets, pretrained weights, synthetic data) were verified against vendor-provided manifests or signatures before use" ], "evidence": [ { "id": "TG-04-E1", "description": "training_shard_integrity_manifest listing the cryptographic hash (SHA-256 or stronger) for each shard, the verification timestamp, and the verification result (pass/fail/recomputed) for the current training run", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-04-E2", "description": "adversarial_screening_report for each external data source ingested, including the screening method applied, the number of records inspected, any detected anomalies or suspicious patterns, and the disposition (accepted/quarantined/rejected)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-04-E3", "description": "chain_of_custody_record for each data transformation applied to the training corpus, including the transformation type, operator identity, input hash, output hash, and transformation timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-04-E4", "description": "supply_chain_integrity_check_record confirming that third-party training data packages (datasets, pretrained weights, synthetic data) were verified against vendor-provided manifests or signatures before use", "evidence_type": "third-party-audit-report", "verification": "third-party" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "Data integrity controls support EU AI Act data quality requirements for high-risk AI" }, { "control": "apeiris://security/controls/RT-02", "id": "RT-02", "domain": "security", "name": "Detect direct and indirect prompt injection at every input and output", "validation_objective": "Every input channel \u2014 including user prompts, retrieved documents, tool results, and multimodal streams \u2014 must pass through injection inspection before reaching the agent's reasoning layer, and every agent output must pass through inspection before execution or delivery. Suspected injections must be blocked or quarantined before the agent acts on them, with attack-success-rate below the defined threshold on periodic evaluation suites.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "guardrail_decision_log with entries for each inspection event recording content_channel, trust_boundary, injection_score, and action taken (allowed/blocked/quarantined) for both input and output paths", "injection_eval_report from AgentDojo or equivalent suite showing attack-success-rate and false-positive-rate before and after the guardrail, run at least quarterly", "input_coverage_attestation confirming guardrails are applied to retrieved document streams and tool result payloads, not only direct user prompts", "redaction_audit_log confirming sensitive data was stripped at the inspection boundary during the evaluation period" ], "evidence": [ { "id": "RT-02-E1", "description": "guardrail_decision_log with entries for each inspection event recording content_channel, trust_boundary, injection_score, and action taken (allowed/blocked/quarantined) for both input and output paths", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-02-E2", "description": "injection_eval_report from AgentDojo or equivalent suite showing attack-success-rate and false-positive-rate before and after the guardrail, run at least quarterly", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-02-E3", "description": "input_coverage_attestation confirming guardrails are applied to retrieved document streams and tool result payloads, not only direct user prompts", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-02-E4", "description": "redaction_audit_log confirming sensitive data was stripped at the inspection boundary during the evaluation period", "evidence_type": "evaluation-scorecard", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://security/controls/EC-01", "id": "EC-01", "domain": "security", "name": "Run the agent in a sandbox, from process isolation up to micro-VMs", "validation_objective": "Every agent must execute within an isolation tier matched to its threat profile, with untrusted-code agents deployed in a hypervisor-backed micro-VM (Firecracker or gVisor) that prevents direct access to the host kernel. The isolation tier must be declared in the deployment specification and cryptographically attested at runtime.", "blocking_effect": "blocks-deployment", "evidence_required": [ "sandbox_runtime_attestation confirming isolation_tier (process/gVisor/micro-VM), sandbox_type, and kernel_exposure_level for each agent run, captured at deployment time", "deployment_spec_record showing isolation_tier, sandbox_runtime, and seccomp_profile for each agent workload, diffed against the attested runtime configuration", "escape_test_result from known sandbox-escape payload execution inside the sandbox, recording reached_host (must be false), maximum_reached_boundary, and test_run_at", "syscall_profile_baseline showing the expected system call set for the agent workload and any deviations detected during runtime" ], "evidence": [ { "id": "EC-01-E1", "description": "sandbox_runtime_attestation confirming isolation_tier (process/gVisor/micro-VM), sandbox_type, and kernel_exposure_level for each agent run, captured at deployment time", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-01-E2", "description": "deployment_spec_record showing isolation_tier, sandbox_runtime, and seccomp_profile for each agent workload, diffed against the attested runtime configuration", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "EC-01-E3", "description": "escape_test_result from known sandbox-escape payload execution inside the sandbox, recording reached_host (must be false), maximum_reached_boundary, and test_run_at", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-01-E4", "description": "syscall_profile_baseline showing the expected system call set for the agent workload and any deviations detected during runtime", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://security/controls/EC-12", "id": "EC-12", "domain": "security", "name": "AI Serving-Stack Vulnerability Management", "validation_objective": "Prove that every component of the AI serving stack (model-serving runtime, inference servers, agent orchestrator, GPU drivers and firmware, container base images, and exposed dependencies) is inventoried in a per-service SBOM and continuously scanned for known vulnerabilities, and that any vulnerability appearing on the CISA Known Exploited Vulnerabilities catalog affecting a production AI component is remediated within the KEV due date or carries a signed, expiring risk-acceptance. The control passes when 100% of production AI-serving components map to a current SBOM, every KEV match on those components has a remediation or exception record dated on or before its due date, and no internet-reachable AI endpoint runs a component with an open KEV entry past its due date.", "blocking_effect": "blocks-deployment", "evidence_required": [ "ai_serving_stack_sbom: per production AI service, a software bill of materials enumerating the serving runtime, inference server, agent orchestrator, GPU driver and firmware version, base image, and direct dependencies, refreshed on each deployment.", "kev_exposure_report: the current CISA KEV catalog cross-referenced against the AI-serving SBOM, listing each KEV-listed vulnerability present on a production AI component with its KEV due date and remediation or exception status.", "remediation_record: for each KEV-listed vulnerability affecting a production AI component, the patch or mitigation applied and its date, or a signed risk-acceptance with compensating controls and a bounded expiry, produced on or before the KEV due date.", "scan_coverage_manifest: proof that vulnerability scanning covers every production AI-serving component including GPU driver and firmware and container base images, with the last-scan timestamp per component." ], "evidence": [ { "id": "EC-12-E1", "description": "ai_serving_stack_sbom: per production AI service, a software bill of materials enumerating the serving runtime, inference server, agent orchestrator, GPU driver and firmware version, base image, and direct dependencies, refreshed on each deployment.", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-12-E2", "description": "kev_exposure_report: the current CISA KEV catalog cross-referenced against the AI-serving SBOM, listing each KEV-listed vulnerability present on a production AI component with its KEV due date and remediation or exception status.", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-12-E3", "description": "remediation_record: for each KEV-listed vulnerability affecting a production AI component, the patch or mitigation applied and its date, or a signed risk-acceptance with compensating controls and a bounded expiry, produced on or before the KEV due date.", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-12-E4", "description": "scan_coverage_manifest: proof that vulnerability scanning covers every production AI-serving component including GPU driver and firmware and container base images, with the last-scan timestamp per component.", "evidence_type": "automated-test-result", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 15 requires high-risk AI systems to be resilient and cybersecure; remediating exploited vulnerabilities in the serving stack is one component of that cybersecurity obligation, not the whole of it." } ] }, { "requirement_id": "EU-AIA-ART17-01", "section": "Art. 17(1)", "title": "Quality management system \u2014 establishment", "text": "Providers of high-risk AI systems shall put in place a quality management system that ensures compliance with this Regulation. That system shall be documented in a systematic and orderly manner in the form of written policies, procedures and instructions.", "verdict": "supported", "coverage": "direct", "notes": "CG-01 (Compliance Governance Structure) establishes the organizational governance structure that serves as the foundation of the quality management system. CG-02 (Compliance Policy Framework for AI) produces the documented written policies and procedures required by Art. 17(1). PO-01 (Internal Policy Register for AI Deployments) maintains the authoritative register of all AI-related policies and instructions. CI-08 (Compliance Implementation Evidence Package) produces the systematic documentation of the QMS implementation.", "control_count": 4, "proof_chain": [ { "control": "apeiris://compliance/controls/CG-01", "id": "CG-01", "domain": "compliance", "name": "Compliance Governance Structure", "validation_objective": "The organization must have a formally chartered Compliance Committee with documented meeting minutes showing quorum was achieved in at least 80% of scheduled sessions in the last 12 months, a CCO or equivalent with a documented direct reporting channel to the board Audit and Risk Committee that bypasses management for material issues, and a current escalation matrix reviewed within 12 months covering all material compliance issue types including AI regulatory incidents.", "blocking_effect": "requires-review", "evidence_required": [ "compliance_committee_charter signed and approved by the board with defined membership composition, quorum rules, meeting cadence, decision authority scope, and AI regulatory obligation coverage", "cco_role_documentation including the CCO written authority scope, direct reporting line to the Audit and Risk Committee as documented in board resolution or equivalent formal governance instrument, and organizational chart placement", "compliance_committee_meeting_minutes for the last 12 months showing attendees, quorum status at each session, agenda items including AI compliance matters, and action item tracking with completion status", "escalation_matrix covering all material compliance issue types \u2014 regulatory inquiry, enforcement action, material AI risk event, data breach \u2014 with defined escalation paths, response timeframes, and responsible parties for each tier", "board_resolution or formal charter ratification record establishing the compliance governance structure with effective date and scope of authority" ], "evidence": [ { "id": "CG-01-E1", "description": "compliance_committee_charter signed and approved by the board with defined membership composition, quorum rules, meeting cadence, decision authority scope, and AI regulatory obligation coverage", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-01-E2", "description": "cco_role_documentation including the CCO written authority scope, direct reporting line to the Audit and Risk Committee as documented in board resolution or equivalent formal governance instrument, and organizational chart placement", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-01-E3", "description": "compliance_committee_meeting_minutes for the last 12 months showing attendees, quorum status at each session, agenda items including AI compliance matters, and action item tracking with completion status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-01-E4", "description": "escalation_matrix covering all material compliance issue types \u2014 regulatory inquiry, enforcement action, material AI risk event, data breach \u2014 with defined escalation paths, response timeframes, and responsible parties for each tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-01-E5", "description": "board_resolution or formal charter ratification record establishing the compliance governance structure with effective date and scope of authority", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 17 requires providers of high-risk AI systems to implement a quality management system that includes clear responsibilities, documented governance, and senior accountability. A formal compliance governance structure is the organizational prerequisite for meeting this article." }, { "control": "apeiris://compliance/controls/CG-02", "id": "CG-02", "domain": "compliance", "name": "Compliance Policy Framework for AI", "validation_objective": "The organization must maintain a board-approved enterprise AI compliance policy, a regulatory inventory covering all applicable frameworks across all jurisdictions of AI operation updated within 30 days of any material regulatory change, and a documented policy hierarchy extending from the enterprise policy to system-specific procedures for every AI system in production, with all policy documents reviewed within the last 14 months and a demonstrated process for completing policy updates within 90 days of material regulatory change.", "blocking_effect": "requires-review", "evidence_required": [ "board_approved_enterprise_ai_compliance_policy with formal board ratification record, approval date within the last 14 months, and defined scope covering all applicable AI regulatory obligations across all operating jurisdictions", "regulatory_inventory spanning all jurisdictions of AI operation listing all applicable frameworks, assigned obligation owners for each framework, and last update date confirming review within 30 days of any material regulatory change", "policy_coverage_map linking every AI system in the production AI inventory to at least one policy document with a named owner, last review date within 14 months, and applicable regulatory frameworks identified", "regulatory_change_tracking_log for the last 24 months showing detected regulatory changes, policy update decisions triggered, update completion dates, and compliance with the 90-day response target for each change", "framework_specific_standards_documentation for each applicable regulatory framework, mapping framework requirements to internal controls and assigning named owners responsible for each obligation" ], "evidence": [ { "id": "CG-02-E1", "description": "board_approved_enterprise_ai_compliance_policy with formal board ratification record, approval date within the last 14 months, and defined scope covering all applicable AI regulatory obligations across all operating jurisdictions", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-02-E2", "description": "regulatory_inventory spanning all jurisdictions of AI operation listing all applicable frameworks, assigned obligation owners for each framework, and last update date confirming review within 30 days of any material regulatory change", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-02-E3", "description": "policy_coverage_map linking every AI system in the production AI inventory to at least one policy document with a named owner, last review date within 14 months, and applicable regulatory frameworks identified", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-02-E4", "description": "regulatory_change_tracking_log for the last 24 months showing detected regulatory changes, policy update decisions triggered, update completion dates, and compliance with the 90-day response target for each change", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-02-E5", "description": "framework_specific_standards_documentation for each applicable regulatory framework, mapping framework requirements to internal controls and assigning named owners responsible for each obligation", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 9 requires a risk management system that identifies and analyzes known and foreseeable risks and implements risk management measures. A policy framework that maps obligations to controls is the organizational implementation of this systematic requirement." }, { "control": "apeiris://authority/controls/PO-01", "id": "PO-01", "domain": "authority", "name": "Internal Policy Register for AI Deployments", "validation_objective": "Every active AI deployment must have at least one current, non-expired policy register entry in the authoritative policy register, and that entry must contain version, effective date, scope, owning team, and deployment linkage fields. No AI deployment may enter or remain in production without a valid policy register reference confirmed by the deployment pipeline.", "blocking_effect": "blocks-deployment", "evidence_required": [ "policy_register_schema_document specifying required fields including policy_id, version, effective_date, expiry_date, owning_team, ai_deployment_scope, and authority_domain_applicability", "deployment_policy_linkage_audit_log confirming every active AI deployment has a corresponding current policy register entry with a non-expired effective date", "policy_register_access_control_matrix demonstrating that register modifications require dual authorization and all changes are attributed and logged", "deployment_pipeline_gate_configuration showing that AI deployment approval workflows validate the presence of a current policy register entry before proceeding" ], "evidence": [ { "id": "PO-01-E1", "description": "policy_register_schema_document specifying required fields including policy_id, version, effective_date, expiry_date, owning_team, ai_deployment_scope, and authority_domain_applicability", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-01-E2", "description": "deployment_policy_linkage_audit_log confirming every active AI deployment has a corresponding current policy register entry with a non-expired effective date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-01-E3", "description": "policy_register_access_control_matrix demonstrating that register modifications require dual authorization and all changes are attributed and logged", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-01-E4", "description": "deployment_pipeline_gate_configuration showing that AI deployment approval workflows validate the presence of a current policy register entry before proceeding", "evidence_type": "human-review-record", "verification": "human" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://compliance/controls/CI-08", "id": "CI-08", "domain": "compliance", "name": "Compliance Implementation Evidence Package", "validation_objective": "A structured evidence package containing artifacts from all CI-layer controls (CI-01 through CI-07) has been assembled on a defined cadence, with SHA-256 hash verification applied to every artifact, completeness verified at 100% against the CI control inventory, and executive attestation signed within 10 business days of assembly completion. The package must be retrievable for regulatory inspection within 24 hours of any request.", "blocking_effect": "requires-review", "evidence_required": [ "CI evidence package index listing every artifact type, artifact filename, SHA-256 hash, collection timestamp, and source control reference for each included artifact", "Executive attestation signature document confirming the package represents a complete and accurate record of CI-layer control operation for the period covered, signed by the CCO or designated executive", "Package completeness verification log documenting the compliance officer's artifact-by-artifact review against the CI control inventory, with any approved exceptions and exception justification", "SHA-256 hash verification report confirming all artifacts in the package match their recorded hashes, generated at the time of each inspection or audit request", "Retention policy documentation confirming storage period meets the longest applicable statutory requirement across all regulatory frameworks the package covers" ], "evidence": [ { "id": "CI-08-E1", "description": "CI evidence package index listing every artifact type, artifact filename, SHA-256 hash, collection timestamp, and source control reference for each included artifact", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-08-E2", "description": "Executive attestation signature document confirming the package represents a complete and accurate record of CI-layer control operation for the period covered, signed by the CCO or designated executive", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-08-E3", "description": "Package completeness verification log documenting the compliance officer's artifact-by-artifact review against the CI control inventory, with any approved exceptions and exception justification", "evidence_type": "audit-log", "verification": "automated" }, { "id": "CI-08-E4", "description": "SHA-256 hash verification report confirming all artifacts in the package match their recorded hashes, generated at the time of each inspection or audit request", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-08-E5", "description": "Retention policy documentation confirming storage period meets the longest applicable statutory requirement across all regulatory frameworks the package covers", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 18 requires that providers of high-risk AI systems draw up and keep technical documentation that demonstrates compliance with the requirements of the Act. The CI evidence package is the technical documentation artifact that demonstrates the compliance program's operational effectiveness throughout the AI system lifecycle." } ] }, { "requirement_id": "EU-AIA-ART17-01a", "section": "Art. 17(1)(a)", "title": "Quality management system \u2014 compliance strategy", "text": "The quality management system shall address a strategy for regulatory compliance including compliance with conformity assessment procedures and with the management of modifications to the high-risk AI system.", "verdict": "supported", "coverage": "direct", "notes": "CA-02 (Compliance Framework Selection and Mapping) produces a documented compliance strategy covering applicable regulatory frameworks. CG-02 includes the regulatory compliance dimension as a required section of the AI compliance policy framework. LI-09 (Material-Change Determination and Authorization Gate) operationalizes the modification management component, requiring documented determination of whether changes constitute a substantial modification triggering re-assessment.", "control_count": 3, "proof_chain": [ { "control": "apeiris://compliance/controls/CA-02", "id": "CA-02", "domain": "compliance", "name": "Compliance Framework Selection and Mapping", "validation_objective": "Every AI system must have a current harmonized obligation map derived from the organizational framework catalog, with all applicable frameworks present at their current published versions and every framework requirement either mapped to an organizational control or explicitly flagged as a gap routed to the CA-06 backlog with a gap_id. No requirement may exist in the obligation map in an unmapped and unrouted state.", "blocking_effect": "blocks-deployment", "evidence_required": [ "framework_catalog showing each adopted framework with current_version, last_reviewed_on (within 60 days of current framework publication), and requirement_count", "harmonized_obligation_map for the AI system listing each requirement by framework_id and requirement_id, the mapped organizational control_id or gap_id, and a harmonization_group_id where multiple frameworks share one control", "cross_framework_harmonization_report documenting the count of requirements satisfied by shared controls and estimated evidence collection reduction as a percentage", "gap_routing_records for each unmapped requirement showing obligation_id, gap_id, routed_at timestamp, and assigned CA-06 backlog entry confirmation" ], "evidence": [ { "id": "CA-02-E1", "description": "framework_catalog showing each adopted framework with current_version, last_reviewed_on (within 60 days of current framework publication), and requirement_count", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-02-E2", "description": "harmonized_obligation_map for the AI system listing each requirement by framework_id and requirement_id, the mapped organizational control_id or gap_id, and a harmonization_group_id where multiple frameworks share one control", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-02-E3", "description": "cross_framework_harmonization_report documenting the count of requirements satisfied by shared controls and estimated evidence collection reduction as a percentage", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-02-E4", "description": "gap_routing_records for each unmapped requirement showing obligation_id, gap_id, routed_at timestamp, and assigned CA-06 backlog entry confirmation", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "adjacent", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 9(2) requires high-risk AI system providers to establish a risk management system that considers applicable harmonized standards and common specifications, which requires knowing which standards apply and how their requirements map to the provider's risk controls. CA-02's framework mapping process ensures that applicable harmonized standards are identified and their requirements tracked. The fit is adjacent because Article 9 addresses risk management rather than compliance framework administration directly." }, { "control": "apeiris://compliance/controls/CG-02", "id": "CG-02", "domain": "compliance", "name": "Compliance Policy Framework for AI", "validation_objective": "The organization must maintain a board-approved enterprise AI compliance policy, a regulatory inventory covering all applicable frameworks across all jurisdictions of AI operation updated within 30 days of any material regulatory change, and a documented policy hierarchy extending from the enterprise policy to system-specific procedures for every AI system in production, with all policy documents reviewed within the last 14 months and a demonstrated process for completing policy updates within 90 days of material regulatory change.", "blocking_effect": "requires-review", "evidence_required": [ "board_approved_enterprise_ai_compliance_policy with formal board ratification record, approval date within the last 14 months, and defined scope covering all applicable AI regulatory obligations across all operating jurisdictions", "regulatory_inventory spanning all jurisdictions of AI operation listing all applicable frameworks, assigned obligation owners for each framework, and last update date confirming review within 30 days of any material regulatory change", "policy_coverage_map linking every AI system in the production AI inventory to at least one policy document with a named owner, last review date within 14 months, and applicable regulatory frameworks identified", "regulatory_change_tracking_log for the last 24 months showing detected regulatory changes, policy update decisions triggered, update completion dates, and compliance with the 90-day response target for each change", "framework_specific_standards_documentation for each applicable regulatory framework, mapping framework requirements to internal controls and assigning named owners responsible for each obligation" ], "evidence": [ { "id": "CG-02-E1", "description": "board_approved_enterprise_ai_compliance_policy with formal board ratification record, approval date within the last 14 months, and defined scope covering all applicable AI regulatory obligations across all operating jurisdictions", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-02-E2", "description": "regulatory_inventory spanning all jurisdictions of AI operation listing all applicable frameworks, assigned obligation owners for each framework, and last update date confirming review within 30 days of any material regulatory change", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-02-E3", "description": "policy_coverage_map linking every AI system in the production AI inventory to at least one policy document with a named owner, last review date within 14 months, and applicable regulatory frameworks identified", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-02-E4", "description": "regulatory_change_tracking_log for the last 24 months showing detected regulatory changes, policy update decisions triggered, update completion dates, and compliance with the 90-day response target for each change", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-02-E5", "description": "framework_specific_standards_documentation for each applicable regulatory framework, mapping framework requirements to internal controls and assigning named owners responsible for each obligation", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 9 requires a risk management system that identifies and analyzes known and foreseeable risks and implements risk management measures. A policy framework that maps obligations to controls is the organizational implementation of this systematic requirement." }, { "control": "apeiris://model/controls/LI-09", "id": "LI-09", "domain": "model", "name": "Material-Change Determination and Authorization Gate", "validation_objective": "Every planned change to a deployed AI model or its operating environment is assessed against a documented materiality threshold; changes that meet or exceed the threshold must complete a full re-evaluation and authorization cycle before the updated system goes live, and no material change may bypass this gate.", "blocking_effect": "blocks-deployment", "evidence_required": [ "change_assessment_record documenting the change type (model update, prompt change, RAG corpus change, guardrail change, provider-version change), the materiality determination (material/non-material), and the criteria applied", "re_evaluation_authorization_record for each material change showing completed evaluation cycle, approver identity, approval timestamp, and the specific evaluation artifacts reviewed", "deployment_gate_block_log confirming that attempted deployments of material changes without a completed authorization record were rejected by the pipeline", "change_classification_policy_document defining materiality thresholds for each change type, reviewed and signed by model governance and risk owners" ], "evidence": [ { "id": "LI-09-E1", "description": "change_assessment_record documenting the change type (model update, prompt change, RAG corpus change, guardrail change, provider-version change), the materiality determination (material/non-material), and the criteria applied", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-09-E2", "description": "re_evaluation_authorization_record for each material change showing completed evaluation cycle, approver identity, approval timestamp, and the specific evaluation artifacts reviewed", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "LI-09-E3", "description": "deployment_gate_block_log confirming that attempted deployments of material changes without a completed authorization record were rejected by the pipeline", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-09-E4", "description": "change_classification_policy_document defining materiality thresholds for each change type, reviewed and signed by model governance and risk owners", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art-9 requires that the risk management system for high-risk AI systems be ongoing and iterative, covering the full system lifecycle including modifications. LI-09 directly supports Art-9 by providing the operational mechanism for evaluating whether modifications to the AI system require a new risk assessment cycle. Art-9(9) specifically addresses risk management for AI system modifications." } ] }, { "requirement_id": "EU-AIA-ART17-01b", "section": "Art. 17(1)(b)", "title": "Quality management system \u2014 design and development examination", "text": "The quality management system shall address techniques, procedures and systematic actions to be used for the design and development of the high-risk AI system, including design reviews and verification procedures.", "verdict": "supported", "coverage": "direct", "notes": "EV-01 (Pre-Deployment Evaluation Gate) provides the formal design review and verification gate that must be passed before deployment. CI-06 (Internal Audit of AI Compliance Controls) provides systematic review of design-stage compliance control implementation. RF-03 (EU AI Act Technical Documentation Package) documents the design review outcomes for Annex IV technical documentation. EV-08 (Independent Validation) provides external verification against the design requirements.", "control_count": 4, "proof_chain": [ { "control": "apeiris://model/controls/EV-01", "id": "EV-01", "domain": "model", "name": "Pre-Deployment Evaluation Gate", "validation_objective": "No model artifact is promoted to production unless a signed evaluation manifest referencing that artifact's exact hash is present in the tamper-evident evaluation log and has received dual approval from named, authorized approvers. The deployment pipeline enforces this as a cryptographic gate \u2014 an absent, unsigned, or hash-mismatched manifest results in an automatic pipeline block with no override path except a logged exception with named risk-accepter.", "blocking_effect": "blocks-deployment", "evidence_required": [ "signed_evaluation_manifest with model_artifact_hash, evaluation_suite_version, evaluator_identities, per-dimension pass/fail outcome, signing_key_id, and manifest_signature (Ed25519) for every production model version", "tamper_evident_evaluation_log entry linking manifest_id to model_artifact_hash, recording append timestamp, appender identity, and log integrity proof", "dual_approval_record with two named approver identities, their organizational roles, approval timestamps, and the manifest_hash each approver authorized", "pipeline_execution_log showing at least one successful gate enforcement event: a deployment attempt with an absent or invalid manifest that was blocked, confirming the gate is operational rather than advisory" ], "evidence": [ { "id": "EV-01-E1", "description": "signed_evaluation_manifest with model_artifact_hash, evaluation_suite_version, evaluator_identities, per-dimension pass/fail outcome, signing_key_id, and manifest_signature (Ed25519) for every production model version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-01-E2", "description": "tamper_evident_evaluation_log entry linking manifest_id to model_artifact_hash, recording append timestamp, appender identity, and log integrity proof", "evidence_type": "audit-log", "verification": "automated" }, { "id": "EV-01-E3", "description": "dual_approval_record with two named approver identities, their organizational roles, approval timestamps, and the manifest_hash each approver authorized", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EV-01-E4", "description": "pipeline_execution_log showing at least one successful gate enforcement event: a deployment attempt with an absent or invalid manifest that was blocked, confirming the gate is operational rather than advisory", "evidence_type": "configuration-snapshot", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "Art. 9 mandates testing and evaluation as part of the risk management system for high-risk AI systems before market placement." }, { "control": "apeiris://compliance/controls/CI-06", "id": "CI-06", "domain": "compliance", "name": "Internal Audit of AI Compliance Controls", "validation_objective": "An internal audit covering the full CI-layer control matrix has been completed within the current annual cycle by auditors with documented AI domain competence who are independent of compliance operations. All findings include root cause analysis and have been routed to the remediation register with management responses provided within 15 business days of draft report issuance.", "blocking_effect": "requires-review", "evidence_required": [ "Annual internal audit plan signed by the Chief Audit Executive, identifying scope, risk-based prioritization, and AI competence documentation for all audit team members", "Auditor independence declarations for each team member confirming no organizational reporting line to the compliance function under review", "Audit fieldwork workpapers documenting control testing methodology, evidence reviewed, and basis for each finding classification", "Formal audit report with findings classified by severity (critical/high/medium/low), root cause analysis, and specific remediation recommendations per finding", "Management response letters providing corrective action commitments, named owners, and due dates for each finding, submitted within 15 business days of draft issuance" ], "evidence": [ { "id": "CI-06-E1", "description": "Annual internal audit plan signed by the Chief Audit Executive, identifying scope, risk-based prioritization, and AI competence documentation for all audit team members", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-06-E2", "description": "Auditor independence declarations for each team member confirming no organizational reporting line to the compliance function under review", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CI-06-E3", "description": "Audit fieldwork workpapers documenting control testing methodology, evidence reviewed, and basis for each finding classification", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CI-06-E4", "description": "Formal audit report with findings classified by severity (critical/high/medium/low), root cause analysis, and specific remediation recommendations per finding", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-06-E5", "description": "Management response letters providing corrective action commitments, named owners, and due dates for each finding, submitted within 15 business days of draft issuance", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 9(2) requires the risk management system to run as a continuous iterative process requiring regular systematic review and updating throughout the AI system lifecycle. Internal audits of AI compliance controls provide the independent review mechanism that validates whether these risk management measures remain effective and are being properly applied." }, { "control": "apeiris://compliance/controls/RF-03", "id": "RF-03", "domain": "compliance", "name": "EU AI Act Technical Documentation Package (Art. 11)", "validation_objective": "Each high-risk AI system must have an Annex IV technical documentation package with all required sections substantively populated \u2014 no missing sections or placeholder content \u2014 version-controlled and linked to the current CE declaration, updated within 30 days of any qualifying model or deployment scope change, and retained in a controlled repository for 10 years from market placement date as required by Art. 18.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Annex IV completeness checklist per high-risk system with completion status for each required section, documentation owner sign-off, and compliance team approval date", "Technical documentation version history linking each documentation version to the corresponding model version, CE declaration version, and the change management ticket that triggered the update", "Model change management tickets with documentation update completion confirmation timestamp within 30 days of each qualifying model or deployment scope change event", "Documentation repository access log and retention policy configuration confirming role-based access controls, full version history, and a 10-year minimum retention period anchored to market placement date", "Pre-submission documentation completeness review record with legal and compliance sign-off completed before notified body submission or CE declaration issuance" ], "evidence": [ { "id": "RF-03-E1", "description": "Annex IV completeness checklist per high-risk system with completion status for each required section, documentation owner sign-off, and compliance team approval date", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RF-03-E2", "description": "Technical documentation version history linking each documentation version to the corresponding model version, CE declaration version, and the change management ticket that triggered the update", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RF-03-E3", "description": "Model change management tickets with documentation update completion confirmation timestamp within 30 days of each qualifying model or deployment scope change event", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RF-03-E4", "description": "Documentation repository access log and retention policy configuration confirming role-based access controls, full version history, and a 10-year minimum retention period anchored to market placement date", "evidence_type": "audit-log", "verification": "automated" }, { "id": "RF-03-E5", "description": "Pre-submission documentation completeness review record with legal and compliance sign-off completed before notified body submission or CE declaration issuance", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "Art. 11 imposes a mandatory obligation on providers of high-risk AI systems to draw up technical documentation before market placement, and Annex IV specifies the required documentation sections. This control implements the documentation assembly and maintenance obligation in its entirety." }, { "control": "apeiris://model/controls/EV-08", "id": "EV-08", "domain": "model", "name": "Independent Validation", "validation_objective": "Every model deployment authorization is signed by a validator who is organizationally independent of the model development function with no shared management chain at a meaningful level; the validator has documented authority to withhold authorization and escalate findings to a governance committee; and the deployment pipeline rejects any manifest where the validator and development lead share the same organizational identity.", "blocking_effect": "blocks-deployment", "evidence_required": [ "organizational_chart_and_reporting_structure_document confirming validator independence from the development team for each model system, with management_chain_separation explicitly documented to a meaningful organizational level", "validation_function_authority_policy document version-controlled and governance-committee-approved, explicitly granting rights to request additional evaluation runs, require remediation, and withhold deployment authorization without development team approval", "evaluation_manifests containing named, attributed validator approvals with validator_identity distinct from development_team_lead_identity, linked to verifiable PKI certificate or directory record", "escalation_path_verification_record demonstrating that a test dispute routes to the governance committee and not to the development management chain", "annual_independence_structure_review_document for us-regulated-banking profile, available to regulators and auditors on request" ], "evidence": [ { "id": "EV-08-E1", "description": "organizational_chart_and_reporting_structure_document confirming validator independence from the development team for each model system, with management_chain_separation explicitly documented to a meaningful organizational level", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-08-E2", "description": "validation_function_authority_policy document version-controlled and governance-committee-approved, explicitly granting rights to request additional evaluation runs, require remediation, and withhold deployment authorization without development team approval", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-08-E3", "description": "evaluation_manifests containing named, attributed validator approvals with validator_identity distinct from development_team_lead_identity, linked to verifiable PKI certificate or directory record", "evidence_type": "certification", "verification": "third-party" }, { "id": "EV-08-E4", "description": "escalation_path_verification_record demonstrating that a test dispute routes to the governance committee and not to the development management chain", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "EV-08-E5", "description": "annual_independence_structure_review_document for us-regulated-banking profile, available to regulators and auditors on request", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 9 implies independent risk management review for high-risk AI; independent validation supports this requirement." } ] }, { "requirement_id": "EU-AIA-ART17-01c", "section": "Art. 17(1)(c)", "title": "Quality management system \u2014 quality control and assurance", "text": "The quality management system shall address procedures for quality control and quality assurance of high-risk AI systems.", "verdict": "supported", "coverage": "direct", "notes": "CI-01 (Compliance Control Testing Program) defines the quality control testing procedures and schedule. EV-08 (Independent Validation) provides the quality assurance function through independent evaluation of system performance against defined criteria. AU-01 (Audit Readiness Program) maintains the QMS in a continuous state of verifiable compliance readiness. CI-02 (Continuous Compliance Monitoring) automates quality assurance through ongoing monitoring rather than point-in-time testing.", "control_count": 4, "proof_chain": [ { "control": "apeiris://compliance/controls/CI-01", "id": "CI-01", "domain": "compliance", "name": "Compliance Control Testing Program", "validation_objective": "Every AI compliance control designated as active in the compliance program must have at least one documented test executed within its defined testing frequency cycle, with the test result recorded as pass/fail/exception and all exception items linked to an open remediation record. No compliance control may have lapsed testing (last_tested_at exceeding the defined test frequency) without an approved deferral record.", "blocking_effect": "requires-review", "evidence_required": [ "control_test_plan documenting each active compliance control with test_id, test_frequency, test_method, and responsible_tester", "test_execution_record for each completed test including control_id, test_id, execution_date, result (pass/fail/exception), tester_id, and methodology_notes", "exception_register linking each test exception to a remediation_record with owner_id, target_completion_date, and current_status", "testing_calendar showing scheduled test dates for all active controls across the forward 12-month period", "management_attestation signed by the compliance officer confirming the testing program scope and execution status as of the attestation date" ], "evidence": [ { "id": "CI-01-E1", "description": "control_test_plan documenting each active compliance control with test_id, test_frequency, test_method, and responsible_tester", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-01-E2", "description": "test_execution_record for each completed test including control_id, test_id, execution_date, result (pass/fail/exception), tester_id, and methodology_notes", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "CI-01-E3", "description": "exception_register linking each test exception to a remediation_record with owner_id, target_completion_date, and current_status", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "CI-01-E4", "description": "testing_calendar showing scheduled test dates for all active controls across the forward 12-month period", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "CI-01-E5", "description": "management_attestation signed by the compliance officer confirming the testing program scope and execution status as of the attestation date", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 9(2) requires the risk management system to be a continuous, iterative process requiring regular systematic review and updating, including of the risk management measures adopted under Article 9(2)(d). Control testing provides the recurring evidence that risk management measures remain effective after initial implementation." }, { "control": "apeiris://model/controls/EV-08", "id": "EV-08", "domain": "model", "name": "Independent Validation", "validation_objective": "Every model deployment authorization is signed by a validator who is organizationally independent of the model development function with no shared management chain at a meaningful level; the validator has documented authority to withhold authorization and escalate findings to a governance committee; and the deployment pipeline rejects any manifest where the validator and development lead share the same organizational identity.", "blocking_effect": "blocks-deployment", "evidence_required": [ "organizational_chart_and_reporting_structure_document confirming validator independence from the development team for each model system, with management_chain_separation explicitly documented to a meaningful organizational level", "validation_function_authority_policy document version-controlled and governance-committee-approved, explicitly granting rights to request additional evaluation runs, require remediation, and withhold deployment authorization without development team approval", "evaluation_manifests containing named, attributed validator approvals with validator_identity distinct from development_team_lead_identity, linked to verifiable PKI certificate or directory record", "escalation_path_verification_record demonstrating that a test dispute routes to the governance committee and not to the development management chain", "annual_independence_structure_review_document for us-regulated-banking profile, available to regulators and auditors on request" ], "evidence": [ { "id": "EV-08-E1", "description": "organizational_chart_and_reporting_structure_document confirming validator independence from the development team for each model system, with management_chain_separation explicitly documented to a meaningful organizational level", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-08-E2", "description": "validation_function_authority_policy document version-controlled and governance-committee-approved, explicitly granting rights to request additional evaluation runs, require remediation, and withhold deployment authorization without development team approval", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-08-E3", "description": "evaluation_manifests containing named, attributed validator approvals with validator_identity distinct from development_team_lead_identity, linked to verifiable PKI certificate or directory record", "evidence_type": "certification", "verification": "third-party" }, { "id": "EV-08-E4", "description": "escalation_path_verification_record demonstrating that a test dispute routes to the governance committee and not to the development management chain", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "EV-08-E5", "description": "annual_independence_structure_review_document for us-regulated-banking profile, available to regulators and auditors on request", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 9 implies independent risk management review for high-risk AI; independent validation supports this requirement." }, { "control": "apeiris://compliance/controls/AU-01", "id": "AU-01", "domain": "compliance", "name": "Audit Readiness Program", "validation_objective": "The organization maintains a continuously current evidence library for each applicable compliance framework with completeness scores at or above 95%, all artifacts refreshed within defined cadence thresholds, and at least four quarterly mock audit exercises completed in the review year with findings closed within 45 days. No framework evidence package was assembled reactively within 30 days of an audit notification.", "blocking_effect": "advisory", "evidence_required": [ "Evidence library completeness score history for each applicable framework, showing scores recorded at least monthly and distributed across the review period rather than spiking near audit notification dates", "Artifact staleness tracking report showing each artifact type's last_refreshed_date and compliance status against the defined maximum staleness threshold", "Quarterly mock audit reports documenting scope, methodology, findings, and participants for each of the four required exercises in the review year", "Mock audit finding remediation records confirming all gaps identified in each exercise were closed within 45 days of report issuance", "Annual audit readiness program charter or review sign-off from the Chief Compliance Officer confirming applicable framework inventory and program scope" ], "evidence": [ { "id": "AU-01-E1", "description": "Evidence library completeness score history for each applicable framework, showing scores recorded at least monthly and distributed across the review period rather than spiking near audit notification dates", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AU-01-E2", "description": "Artifact staleness tracking report showing each artifact type's last_refreshed_date and compliance status against the defined maximum staleness threshold", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AU-01-E3", "description": "Quarterly mock audit reports documenting scope, methodology, findings, and participants for each of the four required exercises in the review year", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AU-01-E4", "description": "Mock audit finding remediation records confirming all gaps identified in each exercise were closed within 45 days of report issuance", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AU-01-E5", "description": "Annual audit readiness program charter or review sign-off from the Chief Compliance Officer confirming applicable framework inventory and program scope", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 17(1)(k) requires the quality management system of providers of high-risk AI systems to include systems and procedures for record-keeping of all relevant documentation and information. Audit readiness packages serve as the operational mechanism for maintaining these records in a state accessible to market surveillance authorities at any point during the system lifecycle." }, { "control": "apeiris://compliance/controls/CI-02", "id": "CI-02", "domain": "compliance", "name": "Continuous Compliance Monitoring", "validation_objective": "The enterprise must operate automated monitoring pipelines covering 100% of AI obligations designated as continuously monitored in the compliance program, with alert latency not exceeding the defined maximum detection window, and all alert events retained with a machine-readable audit trail. No obligation designated as continuously monitored may remain in an undetected violation state for longer than the defined maximum detection window.", "blocking_effect": "advisory", "evidence_required": [ "monitoring_pipeline_inventory listing each automated compliance monitor with obligation_id, monitor_id, check_frequency, alert_channel, and last_successful_run timestamp", "alert_log showing all compliance alert events with obligation_id, detected_at, severity, alert_channel, and assigned_responder for the review period", "false_positive_rate_report quantifying alert noise by obligation and monitor, with tuning actions taken for monitors exceeding the defined false positive threshold", "obligation_coverage_matrix confirming which obligations are covered by automated monitoring vs. periodic testing, with justification for any obligation placed in periodic-only mode", "monitoring_health_report confirming pipeline availability and last successful execution timestamp for each monitor" ], "evidence": [ { "id": "CI-02-E1", "description": "monitoring_pipeline_inventory listing each automated compliance monitor with obligation_id, monitor_id, check_frequency, alert_channel, and last_successful_run timestamp", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CI-02-E2", "description": "alert_log showing all compliance alert events with obligation_id, detected_at, severity, alert_channel, and assigned_responder for the review period", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CI-02-E3", "description": "false_positive_rate_report quantifying alert noise by obligation and monitor, with tuning actions taken for monitors exceeding the defined false positive threshold", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CI-02-E4", "description": "obligation_coverage_matrix confirming which obligations are covered by automated monitoring vs. periodic testing, with justification for any obligation placed in periodic-only mode", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CI-02-E5", "description": "monitoring_health_report confirming pipeline availability and last successful execution timestamp for each monitor", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 72 requires providers of high-risk AI systems to implement post-market monitoring systems. CI-02's continuous monitoring pipeline is the primary technical implementation of the Article 72 post-market monitoring requirement." } ] }, { "requirement_id": "EU-AIA-ART17-01f", "section": "Art. 17(1)(f)", "title": "Quality management system \u2014 post-market monitoring plan", "text": "The quality management system shall address a post-market monitoring plan pursuant to Article 72.", "verdict": "supported", "coverage": "direct", "notes": "RF-04 (EU AI Act Post-Market Monitoring Plan \u2014 Art. 72) is the Apeiris control specifically designed to satisfy the post-market monitoring plan requirement. CR-06 (Post-Market Surveillance) implements the ongoing monitoring obligations. CR-01 (Continuous Production Monitoring and Risk Aggregation) provides the technical infrastructure for post-market monitoring. BH-02 (Concept and Data Drift Detection) is the primary technical mechanism for detecting post-market performance degradation.", "control_count": 4, "proof_chain": [ { "control": "apeiris://compliance/controls/RF-04", "id": "RF-04", "domain": "compliance", "name": "EU AI Act Post-Market Monitoring Plan (Art. 72)", "validation_objective": "Every high-risk AI system in production must have an approved post-market monitoring plan covering all Art. 72 required elements, with monitoring data current and free of gaps exceeding the defined collection interval, and all qualifying serious incidents must have documented competent authority notification records delivered within Art. 73 prescribed timelines \u2014 no later than 15 days for serious incidents generally, 2 days for widespread infringement or critical-infrastructure incidents, and 10 days in the event of a death \u2014 from the point of detection.", "blocking_effect": "advisory", "evidence_required": [ "Post-market monitoring plan per high-risk system with metrics[], collection_sources[], collection_frequency, serious_incident_thresholds[], escalation_workflow, and notification_timelines defined and approved before market placement", "Tamper-evident monitoring data log with inference-time performance metrics, fairness metrics, error rates, and collection timestamps covering the full production period with no gaps exceeding the defined collection frequency", "Serious incident log with incident_id, detection_timestamp, internal_escalation_timestamp, competent_authority_notification_timestamp, notification_method, and disposition for each qualifying event under Art. 3(49)", "Quarterly post-market monitoring review report comparing current performance metrics against the Annex IV baseline with identified deviations documented and assigned for remediation", "Annual post-market monitoring summary artifact incorporated into the technical documentation package update with version linkage" ], "evidence": [ { "id": "RF-04-E1", "description": "Post-market monitoring plan per high-risk system with metrics[], collection_sources[], collection_frequency, serious_incident_thresholds[], escalation_workflow, and notification_timelines defined and approved before market placement", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "RF-04-E2", "description": "Tamper-evident monitoring data log with inference-time performance metrics, fairness metrics, error rates, and collection timestamps covering the full production period with no gaps exceeding the defined collection frequency", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "RF-04-E3", "description": "Serious incident log with incident_id, detection_timestamp, internal_escalation_timestamp, competent_authority_notification_timestamp, notification_method, and disposition for each qualifying event under Art. 3(49)", "evidence_type": "incident-record", "verification": "attested" }, { "id": "RF-04-E4", "description": "Quarterly post-market monitoring review report comparing current performance metrics against the Annex IV baseline with identified deviations documented and assigned for remediation", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "RF-04-E5", "description": "Annual post-market monitoring summary artifact incorporated into the technical documentation package update with version linkage", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "Art. 72 mandates that providers establish a post-market monitoring system proportionate to the nature and risk of the AI system, and Art. 73 requires serious incident reporting to competent authorities within defined timelines. This control directly implements both obligations." }, { "control": "apeiris://model/controls/CR-06", "id": "CR-06", "domain": "model", "name": "Post-Market Surveillance", "validation_objective": "The organization must operate three distinct proactive surveillance channels \u2014 a structured user-facing harm reporting mechanism, a coordinated vulnerability disclosure (CVD) program with a monitored security inbox, and a quarterly AI literature and media monitoring process \u2014 with outputs aggregated into a monthly post-market surveillance report reviewed and signed by the AI risk function, and an annual surveillance summary included in the model's EU high-risk AI technical documentation (LI-04).", "blocking_effect": "advisory", "evidence_required": [ "User-facing harm reporting mechanism deployment record showing endpoint URL, structured input schema (harm_type, severity_self_assessed, description), and CR-02 archive path", "Published CVD policy document at a canonical URL with designated security email alias and monitored inbox confirmation, including acknowledgement SLA statement", "Last 12 monthly post-market surveillance reports with AI risk function reviewer name, sign-off signature, and review date on each report", "Annual surveillance summary document aggregating user reports, CVD submissions, and literature findings \u2014 present in the model's LI-04 technical documentation with review date", "CVD acknowledgement records showing each submission received an acknowledgement within 5 business days of receipt" ], "evidence": [ { "id": "CR-06-E1", "description": "User-facing harm reporting mechanism deployment record showing endpoint URL, structured input schema (harm_type, severity_self_assessed, description), and CR-02 archive path", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-06-E2", "description": "Published CVD policy document at a canonical URL with designated security email alias and monitored inbox confirmation, including acknowledgement SLA statement", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-06-E3", "description": "Last 12 monthly post-market surveillance reports with AI risk function reviewer name, sign-off signature, and review date on each report", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CR-06-E4", "description": "Annual surveillance summary document aggregating user reports, CVD submissions, and literature findings \u2014 present in the model's LI-04 technical documentation with review date", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CR-06-E5", "description": "CVD acknowledgement records showing each submission received an acknowledgement within 5 business days of receipt", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 73 requires providers of high-risk AI systems and GPAI models with systemic risk to notify national competent authorities of serious incidents without undue delay; CR-06 directly implements this obligation by defining the incident severity thresholds that trigger regulatory notification, the 72-hour notification SLA, and the structured notification content including affected parties, root cause, and corrective actions." }, { "control": "apeiris://model/controls/CR-01", "id": "CR-01", "domain": "model", "name": "Continuous Production Monitoring and Risk Aggregation", "validation_objective": "All runtime monitoring signals \u2014 performance, drift, fairness, safety incidents, and deployment event flags \u2014 must be continuously aggregated into a unified risk dashboard with pre-configured automated alerting thresholds; any degradation in a monitored dimension must be detected and an alert dispatched within one operational window.", "blocking_effect": "advisory", "evidence_required": [ "risk_dashboard_configuration_record showing all registered signal feeds (performance, drift, fairness, safety, incident), their alert thresholds, assigned monitoring window duration, and escalation recipients", "alert_audit_log covering at least 30 days showing triggered alerts with signal_type, threshold_crossed, alert_timestamp, and escalation_recipient for each alert", "monitoring_coverage_audit confirming every deployed model version has an associated monitoring configuration with no version gaps", "risk_aggregation_methodology_document defining how individual dimension alerts are combined into composite risk scores and dashboard status indicators", "post-market_monitoring_report satisfying EU AI Act Art. 72 covering the monitoring period, key findings, and corrective actions taken or planned" ], "evidence": [ { "id": "CR-01-E1", "description": "risk_dashboard_configuration_record showing all registered signal feeds (performance, drift, fairness, safety, incident), their alert thresholds, assigned monitoring window duration, and escalation recipients", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-01-E2", "description": "alert_audit_log covering at least 30 days showing triggered alerts with signal_type, threshold_crossed, alert_timestamp, and escalation_recipient for each alert", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E3", "description": "monitoring_coverage_audit confirming every deployed model version has an associated monitoring configuration with no version gaps", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E4", "description": "risk_aggregation_methodology_document defining how individual dimension alerts are combined into composite risk scores and dashboard status indicators", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E5", "description": "post-market_monitoring_report satisfying EU AI Act Art. 72 covering the monitoring period, key findings, and corrective actions taken or planned", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 72 requires high-risk AI system providers to establish, document, and implement a post-market monitoring plan; CR-01's continuous risk aggregation dashboard \u2014 collecting signals from BH-01 through BH-10 layers and applying tiered alerting calibrated at \u00b12\u03c3 from baseline \u2014 operationalizes the systematic performance collection and anomaly identification components of a post-market monitoring plan." }, { "control": "apeiris://model/controls/BH-02", "id": "BH-02", "domain": "model", "name": "Concept and Data Drift Detection", "validation_objective": "The production inference pipeline must compare input feature distributions and prediction distributions against a versioned, SHA-256-signed DriftReference artifact using PSI and KS-test statistics for every monitoring window that meets minimum_sample_size, such that drift exceeding profile-conditional PSI thresholds triggers tiered alert actions, and for continuously-learning profiles, automatically suspends online updates pending a signed model-owner resume authorization.", "blocking_effect": "advisory", "evidence_required": [ "versioned DriftReference artifact for the current production model with SHA-256 hash, training date, and per-feature statistics (mean, std, histogram bins, and KDE parameters) for all tier-1 monitored features", "drift event log for trailing 90 days with fields: feature_name, test_statistic, p_value, window_start, window_end, sample_count, alert_severity, and action_taken for each drift event", "monthly drift summary report signed by the model owner, including trend analysis across tier-1 features and prediction distribution PSI over the reporting period", "profile-conditional drift threshold configuration (YAML or equivalent) showing per-profile PSI alert and critical thresholds, minimum_sample_size, and window duration, stored under version control" ], "evidence": [ { "id": "BH-02-E1", "description": "versioned DriftReference artifact for the current production model with SHA-256 hash, training date, and per-feature statistics (mean, std, histogram bins, and KDE parameters) for all tier-1 monitored features", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-02-E2", "description": "drift event log for trailing 90 days with fields: feature_name, test_statistic, p_value, window_start, window_end, sample_count, alert_severity, and action_taken for each drift event", "evidence_type": "audit-log", "verification": "automated" }, { "id": "BH-02-E3", "description": "monthly drift summary report signed by the model owner, including trend analysis across tier-1 features and prediction distribution PSI over the reporting period", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-02-E4", "description": "profile-conditional drift threshold configuration (YAML or equivalent) showing per-profile PSI alert and critical thresholds, minimum_sample_size, and window duration, stored under version control", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 72 requires providers and deployers of high-risk AI systems to establish and document post-market monitoring plans; BH-02's drift detection operationalizes the monitoring dimension by tracking input feature distribution and prediction shifts using PSI and KS-test statistics against signed baseline artifacts." } ] }, { "requirement_id": "EU-AIA-ART17-01g", "section": "Art. 17(1)(g)", "title": "Quality management system \u2014 communication to competent authorities", "text": "The quality management system shall address accountability provisions, including the designation of roles and responsibilities, and the communication to competent authorities regarding serious incidents.", "verdict": "supported", "coverage": "direct", "notes": "CR-05 (Regulatory Notification and Statutory Reporting) directly addresses the obligation to communicate with competent authorities, including timelines and content requirements for serious incident notifications. AU-05 (Regulatory Examination Response Program) establishes the ongoing relationship and communication protocols with competent authorities. PE-02 (Regulatory Disclosure Readiness) maintains a disclosure-ready evidence package. OA-07 (Incident Escalation Authority Chain) defines the accountability chain for incident reporting decisions.", "control_count": 4, "proof_chain": [ { "control": "apeiris://compliance/controls/AU-05", "id": "AU-05", "domain": "compliance", "name": "Regulatory Examination Response Program", "validation_objective": "The organization must have a documented, tested examination response program with a current regulatory playbook, a defined response team with assigned roles and named deputies, and regulator-specific response guides for each material regulatory relationship, such that any formal regulatory inquiry is triaged within 4 business hours and a response team with appropriate legal representation is activated within 24 hours of receipt. Zero regulatory response deadlines may be missed.", "blocking_effect": "requires-review", "evidence_required": [ "regulatory_examination_response_playbook with version date within the last 12 months, documented tier classification criteria (routine, examination, investigation, enforcement), and response team activation procedures for each tier", "response_team_roster documenting all designated team members by role (response coordinator, legal counsel lead, SME pool, document production manager, executive sponsor) with named deputies and current contact information", "document_production_log from all regulatory responses in the last 24 months confirming legal privilege review, scoping analysis, and production transmittal documentation were completed for each production", "post_examination_after_action_report for each examination closed in the last 24 months, completed within 30 days of closure and showing lessons-learned implementation status and playbook update record", "regulatory_response_deadline_compliance_record listing all response deadlines and submission dates for the last 24 months, confirming zero missed deadlines" ], "evidence": [ { "id": "AU-05-E1", "description": "regulatory_examination_response_playbook with version date within the last 12 months, documented tier classification criteria (routine, examination, investigation, enforcement), and response team activation procedures for each tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AU-05-E2", "description": "response_team_roster documenting all designated team members by role (response coordinator, legal counsel lead, SME pool, document production manager, executive sponsor) with named deputies and current contact information", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AU-05-E3", "description": "document_production_log from all regulatory responses in the last 24 months confirming legal privilege review, scoping analysis, and production transmittal documentation were completed for each production", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AU-05-E4", "description": "post_examination_after_action_report for each examination closed in the last 24 months, completed within 30 days of closure and showing lessons-learned implementation status and playbook update record", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AU-05-E5", "description": "regulatory_response_deadline_compliance_record listing all response deadlines and submission dates for the last 24 months, confirming zero missed deadlines", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 74(12)\u2013(13) grants market surveillance authorities access to the documentation, data sets, and \u2014 upon reasoned request \u2014 source code of high-risk AI systems. The regulatory examination response program provides the operational framework for managing EU AI Act examinations under these access powers with appropriate scoping and privilege protection." }, { "control": "apeiris://model/controls/CR-05", "id": "CR-05", "domain": "model", "name": "Regulatory Notification and Statutory Reporting", "validation_objective": "The organization must maintain a current, legal-counsel-reviewed regulatory notification matrix mapping P1 severity incident events to all applicable jurisdictions, notification timelines (EU Art. 73: \u226415 calendar days for serious incidents; SR 26-2: immediate for material events), designated liaison and backup contacts, and pre-approved notification templates \u2014 with an automated countdown timer creation integrated into the CR-04 P1 escalation workflow and a complete archive of all notification submissions and delivery confirmations in CR-02.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Regulatory notification matrix document (version-controlled, legal-counsel reviewed within 12 months) listing jurisdiction, authority, trigger_event, timeline_days, liaison_contact, backup_contact, and template_ref for each row", "Pre-approved notification templates for each regulatory authority and jurisdiction, with legal counsel review date and version on record", "Notification task creation records showing automated countdown timers initiated for each P1 incident meeting notification criteria, with regulatory liaison page confirmation and timer expiry date", "All notification submissions and delivery confirmations archived in CR-02 with artifact_hash for the trailing 36 months", "Legal counsel sign-off record confirming annual review of all notification triggers and timelines, dated within 12 months" ], "evidence": [ { "id": "CR-05-E1", "description": "Regulatory notification matrix document (version-controlled, legal-counsel reviewed within 12 months) listing jurisdiction, authority, trigger_event, timeline_days, liaison_contact, backup_contact, and template_ref for each row", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CR-05-E2", "description": "Pre-approved notification templates for each regulatory authority and jurisdiction, with legal counsel review date and version on record", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CR-05-E3", "description": "Notification task creation records showing automated countdown timers initiated for each P1 incident meeting notification criteria, with regulatory liaison page confirmation and timer expiry date", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-05-E4", "description": "All notification submissions and delivery confirmations archived in CR-02 with artifact_hash for the trailing 36 months", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-05-E5", "description": "Legal counsel sign-off record confirming annual review of all notification triggers and timelines, dated within 12 months", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 72 requires post-market monitoring to cover systematic collection and analysis of user feedback and actual model performance outcomes; CR-05's outcomes and disparate impact analysis \u2014 comparing actual decisions against predicted outcomes and testing for differential impact across demographic cohorts \u2014 directly implements the outcome analysis component of post-market monitoring." }, { "control": "apeiris://authority/controls/PE-02", "id": "PE-02", "domain": "authority", "name": "Regulatory Disclosure Readiness", "validation_objective": "For every AI system subject to a regulatory transparency obligation, a complete, current disclosure package must be pre-staged and retrievable within the defined submission window. Each package must include technical documentation, conformity assessment records, and incident notification templates validated against the applicable regulatory schema.", "blocking_effect": "blocks-deployment", "evidence_required": [ "disclosure_package_inventory listing every AI system in scope with system_id, applicable_regulation, package_version, last_updated timestamp, and package_completeness_status", "technical_documentation_record per system containing model card, system architecture summary, intended use case, risk classification rationale, and conformity assessment reference", "conformity_assessment_record per applicable system demonstrating compliance with the relevant regulatory article, with assessor identity, assessment date, and findings summary", "incident_notification_template per applicable regulation validated against the regulatory authority's published schema, with a test submission record confirming schema acceptance", "package_readiness_drill_record showing that a disclosure package was successfully retrieved and formatted for submission within the defined regulatory response window during a tabletop or live drill" ], "evidence": [ { "id": "PE-02-E1", "description": "disclosure_package_inventory listing every AI system in scope with system_id, applicable_regulation, package_version, last_updated timestamp, and package_completeness_status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PE-02-E2", "description": "technical_documentation_record per system containing model card, system architecture summary, intended use case, risk classification rationale, and conformity assessment reference", "evidence_type": "model-card", "verification": "attested" }, { "id": "PE-02-E3", "description": "conformity_assessment_record per applicable system demonstrating compliance with the relevant regulatory article, with assessor identity, assessment date, and findings summary", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PE-02-E4", "description": "incident_notification_template per applicable regulation validated against the regulatory authority's published schema, with a test submission record confirming schema acceptance", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "PE-02-E5", "description": "package_readiness_drill_record showing that a disclosure package was successfully retrieved and formatted for submission within the defined regulatory response window during a tabletop or live drill", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "Pre-staged disclosure packages support Art. 13 transparency obligations, partially, focused on submission readiness." }, { "control": "apeiris://model/controls/OA-07", "id": "OA-07", "domain": "model", "name": "Incident Escalation Authority Chain", "validation_objective": "The organization must have a documented incident escalation authority chain for AI model incidents with named individuals at each of four levels, explicit decision rights at each level, time bounds for escalation steps, a defined board-level notification threshold, and annual tabletop exercise completion records. For EU high-risk AI systems, the escalation chain must map EU AI Act Art-73 serious incident reporting obligations (15-day general deadline; 10 days for death; 2 days for widespread infringement or critical-infrastructure incidents) to a specific escalation level.", "blocking_effect": "blocks-deployment", "evidence_required": [ "escalation_authority_chain_document current version with named individuals (not just roles) at each of the four escalation levels, decision rights matrix, time bounds per level, and board-level notification threshold definition \u2014 with approval date", "annual_tabletop_exercise_record for the preceding 12 months, including scenario description, participant list, escalation chain performance against time bounds, gaps identified, and remediation actions", "incident_post_mortem_records for AI model incidents in the preceding 12 months showing escalation chain adherence, time-bound compliance, and regulatory notification actions taken", "regulatory_notification_obligation_mapping document linking EU AI Act Art-73, sector-specific incident reporting requirements, and other applicable obligations to specific escalation levels and time bounds" ], "evidence": [ { "id": "OA-07-E1", "description": "escalation_authority_chain_document current version with named individuals (not just roles) at each of the four escalation levels, decision rights matrix, time bounds per level, and board-level notification threshold definition \u2014 with approval date", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-07-E2", "description": "annual_tabletop_exercise_record for the preceding 12 months, including scenario description, participant list, escalation chain performance against time bounds, gaps identified, and remediation actions", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-07-E3", "description": "incident_post_mortem_records for AI model incidents in the preceding 12 months showing escalation chain adherence, time-bound compliance, and regulatory notification actions taken", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-07-E4", "description": "regulatory_notification_obligation_mapping document linking EU AI Act Art-73, sector-specific incident reporting requirements, and other applicable obligations to specific escalation levels and time bounds", "evidence_type": "incident-record", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "Art-73 requires providers to notify market surveillance authorities of serious incidents \u2014 the escalation chain must ensure this notification obligation is met within the Art-73 deadlines (15 days generally; 10 days for death; 2 days for widespread infringement or critical-infrastructure incidents)." } ] }, { "requirement_id": "EU-AIA-ART17-01h", "section": "Art. 17(1)(h)", "title": "Quality management system \u2014 corrective action system", "text": "The quality management system shall address a corrective and preventive action system, including market withdrawal measures where necessary.", "verdict": "supported", "coverage": "direct", "notes": "CI-07 (Remediation Tracking and Closure) provides the corrective action tracking system with owner assignment, timeline, and verified closure. CR-04 (AI Incident Response Management) handles the incident-triggered corrective action process. AG-05 (Agent Incident Response Program) extends this to agentic systems. LI-06 (Immutable Version Control with Tested Rollback and Emergency Disable) provides the technical mechanism for market withdrawal \u2014 the emergency disable and rollback to a prior safe version.", "control_count": 4, "proof_chain": [ { "control": "apeiris://compliance/controls/CI-07", "id": "CI-07", "domain": "compliance", "name": "Remediation Tracking and Closure", "validation_objective": "Every compliance gap identified by control testing (CI-01), monitoring (CI-02), or internal audit (CI-06) has a corresponding remediation ticket with an assigned single owner, target date, documented root cause, remediation plan, and independently verified closure evidence. No critical-severity ticket is open beyond 15 business days without a documented executive escalation record.", "blocking_effect": "requires-review", "evidence_required": [ "Remediation register export listing all open and closed tickets with source_control, severity, assigned_owner, root_cause, remediation_plan, target_date, and actual_closure_date for the full audit period", "Closure verification records for each high and critical ticket documenting the independent verifier identity, verification method (re-test, configuration check, or re-assessment), and verification outcome", "Automated escalation log showing escalation trigger events and management acknowledgment timestamps for all overdue items during the period", "Recurrence analysis report identifying any finding appearing in both the current and prior audit cycle, with root cause explanation for recurrence", "Weekly remediation velocity reports showing open ticket counts by severity and age distribution across the audit period" ], "evidence": [ { "id": "CI-07-E1", "description": "Remediation register export listing all open and closed tickets with source_control, severity, assigned_owner, root_cause, remediation_plan, target_date, and actual_closure_date for the full audit period", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "CI-07-E2", "description": "Closure verification records for each high and critical ticket documenting the independent verifier identity, verification method (re-test, configuration check, or re-assessment), and verification outcome", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "CI-07-E3", "description": "Automated escalation log showing escalation trigger events and management acknowledgment timestamps for all overdue items during the period", "evidence_type": "audit-log", "verification": "automated" }, { "id": "CI-07-E4", "description": "Recurrence analysis report identifying any finding appearing in both the current and prior audit cycle, with root cause explanation for recurrence", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-07-E5", "description": "Weekly remediation velocity reports showing open ticket counts by severity and age distribution across the audit period", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 20 requires providers of high-risk AI systems to undertake corrective actions when their systems do not conform to the requirements of the Act. The CI-07 remediation tracking system provides the documented corrective action evidence required to demonstrate compliance with this obligation to market surveillance authorities." }, { "control": "apeiris://model/controls/CR-04", "id": "CR-04", "domain": "model", "name": "AI Incident Response Management", "validation_objective": "The organization must have a documented, version-controlled AI Incident Response Plan (AIRP) with AI-specific containment playbooks covering model rollback, output-filter enforcement, traffic shaping, and full model shutdown \u2014 tested via at least four quarterly tabletop exercises per year using MITRE ATLAS adversarial scenarios \u2014 and P1/P2 post-incident review records produced within 5 days of event resolution for all qualifying events in the trailing 12 months.", "blocking_effect": "blocks-deployment", "evidence_required": [ "AI Incident Response Plan document (version-controlled, CISO or AI-risk-owner signed, with review date within 12 months)", "Containment playbook index listing separate runbooks for model_rollback, output_filter_enforcement, traffic_shaping, and model_shutdown_with_fallback", "Last 4 quarterly tabletop exercise reports with MITRE ATLAS scenario identifier, participant roster, outcomes, and reviewer sign-off", "P1 and P2 post-incident review records for all qualifying events in the trailing 12 months, each showing post_incident_report_date within 5 days of incident_resolved_date", "EU Art. 73 notification trigger mapping document showing which P1 severity criteria trigger the Art. 73 serious-incident notification obligation (15d general / 10d death / 2d widespread or critical infrastructure)" ], "evidence": [ { "id": "CR-04-E1", "description": "AI Incident Response Plan document (version-controlled, CISO or AI-risk-owner signed, with review date within 12 months)", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-04-E2", "description": "Containment playbook index listing separate runbooks for model_rollback, output_filter_enforcement, traffic_shaping, and model_shutdown_with_fallback", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-04-E3", "description": "Last 4 quarterly tabletop exercise reports with MITRE ATLAS scenario identifier, participant roster, outcomes, and reviewer sign-off", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CR-04-E4", "description": "P1 and P2 post-incident review records for all qualifying events in the trailing 12 months, each showing post_incident_report_date within 5 days of incident_resolved_date", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-04-E5", "description": "EU Art. 73 notification trigger mapping document showing which P1 severity criteria trigger the Art. 73 serious-incident notification obligation (15d general / 10d death / 2d widespread or critical infrastructure)", "evidence_type": "incident-record", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 73 requires providers of high-risk AI systems to report serious incidents to national market surveillance authorities without undue delay; CR-04's model-specific incident response management \u2014 including P1/P2/P3 severity classification, mean-time-to-respond SLAs, and structured incident post-mortems \u2014 supports the incident triage and escalation processes required upstream of regulatory notification." }, { "control": "apeiris://agentic/controls/AG-05", "id": "AG-05", "domain": "agentic", "name": "Agent Incident Response Program", "validation_objective": "The enterprise has a documented, tested AI Incident Response Playbook with AI-specific containment capabilities, and every production agent has an authenticated kill-switch that demonstrably suspends its operation within 60 seconds of an authorized responder request.", "blocking_effect": "requires-review", "evidence_required": [ "AI Incident Response Playbook document covering incident classification taxonomy, severity tiers with quantitative criteria, containment actions per incident type, escalation matrix, and regulatory notification timelines", "Kill-switch capability validation records for each production agent, confirming suspension within the 60-second SLA in the most recent test", "Tabletop or functional test records for the AI Incident Response Playbook covering at least P1 and P2 severity scenarios", "Post-incident review records for all P1 and P2 events including root cause, containment timeline, and lessons-learned pipeline submissions" ], "evidence": [ { "id": "AG-05-E1", "description": "AI Incident Response Playbook document covering incident classification taxonomy, severity tiers with quantitative criteria, containment actions per incident type, escalation matrix, and regulatory notification timelines", "evidence_type": "incident-record", "verification": "attested" }, { "id": "AG-05-E2", "description": "Kill-switch capability validation records for each production agent, confirming suspension within the 60-second SLA in the most recent test", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "AG-05-E3", "description": "Tabletop or functional test records for the AI Incident Response Playbook covering at least P1 and P2 severity scenarios", "evidence_type": "incident-record", "verification": "attested" }, { "id": "AG-05-E4", "description": "Post-incident review records for all P1 and P2 events including root cause, containment timeline, and lessons-learned pipeline submissions", "evidence_type": "incident-record", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 73 requires providers and deployers to report serious incidents to national competent authorities within defined timeframes. An AI incident response program with regulatory notification procedures and defined reporting timelines directly addresses this mandatory serious incident reporting obligation." }, { "control": "apeiris://model/controls/LI-06", "id": "LI-06", "domain": "model", "name": "Immutable Version Control with Tested Rollback and Emergency Disable", "validation_objective": "Every production model deployment must use an append-only model registry where no existing version entry can be overwritten or deleted; each version transition must be recorded in an immutable deployment log with source hash, destination hash, timestamp, and authorizing identity; rollback to any prior approved version must be tested and documented at least quarterly with measured rollback time; and the emergency disable mechanism must operate independently of the CI/CD pipeline and be exercisable by on-call personnel within the defined SLA.", "blocking_effect": "blocks-deployment", "evidence_required": [ "immutable_deployment_log with append-only version transition entries recording source artifact hash, destination artifact hash, timestamp, and authorizing identity for each production version change", "quarterly_rollback_test_record including model ID, prior version artifact hash, measured rollback time, and pass/fail outcome, with at least one record per production model dated within the last 90 days", "emergency_disable_test_record documenting the activation path, time from trigger to complete suspension of model serving, and explicit confirmation that the disable did not require access to CI/CD pipeline credentials", "version_drift_monitoring_alert_record demonstrating that a hash mismatch between the serving artifact and the registry entry triggered an alert within the monitoring window defined in the monitoring schema" ], "evidence": [ { "id": "LI-06-E1", "description": "immutable_deployment_log with append-only version transition entries recording source artifact hash, destination artifact hash, timestamp, and authorizing identity for each production version change", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-06-E2", "description": "quarterly_rollback_test_record including model ID, prior version artifact hash, measured rollback time, and pass/fail outcome, with at least one record per production model dated within the last 90 days", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-06-E3", "description": "emergency_disable_test_record documenting the activation path, time from trigger to complete suspension of model serving, and explicit confirmation that the disable did not require access to CI/CD pipeline credentials", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "LI-06-E4", "description": "version_drift_monitoring_alert_record demonstrating that a hash mismatch between the serving artifact and the registry entry triggered an alert within the monitoring window defined in the monitoring schema", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art-12 requires providers of high-risk AI systems to maintain logging capabilities that ensure traceability of system behavior and enable post-market monitoring. LI-06's immutable deployment log and version records directly support Art-12's traceability requirement. Art-12 also requires logs to be retained for a defined period; LI-06 does not independently specify retention \u2014 that is addressed in CR layer controls." } ] }, { "requirement_id": "EU-AIA-ART18-01", "section": "Art. 18(1)", "title": "Documentation retention \u2014 10-year retention obligation", "text": "Providers of high-risk AI systems shall retain the technical documentation referred to in Article 11, the declaration of conformity, the quality management system documentation, and the post-market monitoring documentation for a period ending 10 years after the AI system has been placed on the market.", "verdict": "partial", "coverage": "partial", "notes": "AU-02 (Evidence Collection, Curation, and Validation) governs the evidence retention program including retention schedules. CR-02 (Model Evidence Archive and Audit Trail) provides long-term archive of model-layer evidence. PE-01 (Policy Evidence Archive) maintains policy and governance documentation. Partial: the specific 10-year retention period requires explicit configuration in organizational data retention policies; Apeiris provides the governance framework but does not enforce a specific statutory duration \u2014 this must be configured per-organization. Declaration of conformity retention is a legal act outside Apeiris scope.", "control_count": 3, "proof_chain": [ { "control": "apeiris://compliance/controls/AU-02", "id": "AU-02", "domain": "compliance", "name": "Evidence Collection, Curation, and Validation", "validation_objective": "Every compliance evidence artifact in the active evidence library has a SHA-256 hash computed at the moment of collection, a documented source_system and collector_identity, a collection_timestamp within the required freshness window for its artifact type, and has passed all validation gate checks prior to promotion. No artifact with missing or failed provenance metadata exists in the active library.", "blocking_effect": "advisory", "evidence_required": [ "Evidence repository ingestion log showing source_system, collector_identity, collection_timestamp, and SHA-256_hash computed at ingest for every artifact collected during the audit period", "Validation gate rejection log documenting all artifacts that failed validation checks, the specific failure reason (missing hash, staleness, format error, incomplete metadata), and their disposition", "Manual curation workflow records for artifacts that bypassed automated validation, including curator identity, review method, artifact authenticity basis, and sign-off timestamp", "Monthly reconciliation reports comparing the artifact inventory against per-framework requirements, identifying collection gaps by artifact type and their age in days", "SHA-256 hash integrity verification report for the audit period confirming no mismatches between ingestion records and current artifact content in the repository" ], "evidence": [ { "id": "AU-02-E1", "description": "Evidence repository ingestion log showing source_system, collector_identity, collection_timestamp, and SHA-256_hash computed at ingest for every artifact collected during the audit period", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AU-02-E2", "description": "Validation gate rejection log documenting all artifacts that failed validation checks, the specific failure reason (missing hash, staleness, format error, incomplete metadata), and their disposition", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AU-02-E3", "description": "Manual curation workflow records for artifacts that bypassed automated validation, including curator identity, review method, artifact authenticity basis, and sign-off timestamp", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "AU-02-E4", "description": "Monthly reconciliation reports comparing the artifact inventory against per-framework requirements, identifying collection gaps by artifact type and their age in days", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AU-02-E5", "description": "SHA-256 hash integrity verification report for the audit period confirming no mismatches between ingestion records and current artifact content in the repository", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 18 requires providers of high-risk AI systems to draw up and keep technical documentation for inspection by competent authorities. Evidence collection and curation controls operationalize the ongoing maintenance of this documentation in a validated, retrievable form throughout the system lifecycle." }, { "control": "apeiris://model/controls/CR-02", "id": "CR-02", "domain": "model", "name": "Model Evidence Archive and Audit Trail", "validation_objective": "All evaluation results, monitoring snapshots, incident records, and regulatory submissions must be stored in an immutable, content-addressed archive with cryptographic integrity protection; any audit query for a model's historical evidence must resolve to a complete, tamper-evident chain spanning the full production lifetime of that model version.", "blocking_effect": "blocks-deployment", "evidence_required": [ "archive_integrity_configuration_record showing content-addressed storage settings, hash algorithm (minimum SHA-256), write-once immutability enforcement, and retention policy duration per record type", "evidence_chain_completeness_audit confirming that evaluation results, monitoring snapshots, and incident records for each production model version are present in the archive with no missing lifecycle entries", "tamper_detection_scan_report from periodic archive integrity verification showing all stored records produce matching content hashes with zero reported mismatches", "regulatory_submission_evidence_linkage_record linking each regulatory submission to its archived evidence artifact with submission_id, submission_date, submitting_entity, and archive_content_hash", "archive_access_control_audit_log confirming write operations are restricted to authorized pipeline components only and all access attempts are logged with actor_id and timestamp" ], "evidence": [ { "id": "CR-02-E1", "description": "archive_integrity_configuration_record showing content-addressed storage settings, hash algorithm (minimum SHA-256), write-once immutability enforcement, and retention policy duration per record type", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "CR-02-E2", "description": "evidence_chain_completeness_audit confirming that evaluation results, monitoring snapshots, and incident records for each production model version are present in the archive with no missing lifecycle entries", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-02-E3", "description": "tamper_detection_scan_report from periodic archive integrity verification showing all stored records produce matching content hashes with zero reported mismatches", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-02-E4", "description": "regulatory_submission_evidence_linkage_record linking each regulatory submission to its archived evidence artifact with submission_id, submission_date, submitting_entity, and archive_content_hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-02-E5", "description": "archive_access_control_audit_log confirming write operations are restricted to authorized pipeline components only and all access attempts are logged with actor_id and timestamp", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 11 requires providers of high-risk AI systems to draw up technical documentation that includes records of evaluation results and post-market monitoring findings; CR-02's immutable content-addressed evidence archive \u2014 anchored to Sigstore Rekor and locked with S3 Object Lock COMPLIANCE mode \u2014 provides the tamper-evident records infrastructure required to produce and maintain the Art. 11 technical documentation over the required retention period." }, { "control": "apeiris://authority/controls/PE-01", "id": "PE-01", "domain": "authority", "name": "Policy Evidence Archive", "validation_objective": "All policy evidence artifacts must be stored in a tamper-evident, versioned archive where entries are immutable once committed, indexed by artifact type and control ID, and retrievable within the defined SLA during regulatory examination or litigation hold. The archive must produce a cryptographic proof of immutability on demand.", "blocking_effect": "blocks-deployment", "evidence_required": [ "archive_commit_log showing every artifact entry with artifact_id, control_id, committed_at timestamp, SHA-256 hash, and committer identity \u2014 with no modification events after initial commit", "tamper_evidence_record containing the Merkle root or audit log hash for the archive state at each quarterly checkpoint, signed by the archive operator", "retrieval_test_record showing that a representative sample of archived artifacts was successfully retrieved within the defined SLA, with retrieval timestamps and artifact hashes", "litigation_hold_activation_record documenting hold scope, activation timestamp, and confirmation that affected artifacts are locked against deletion for the hold duration", "archive_access_control_manifest listing authorized readers and writers with role assignments, confirming write access is restricted to the ingestion pipeline and no interactive modification is permitted" ], "evidence": [ { "id": "PE-01-E1", "description": "archive_commit_log showing every artifact entry with artifact_id, control_id, committed_at timestamp, SHA-256 hash, and committer identity \u2014 with no modification events after initial commit", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PE-01-E2", "description": "tamper_evidence_record containing the Merkle root or audit log hash for the archive state at each quarterly checkpoint, signed by the archive operator", "evidence_type": "audit-log", "verification": "automated" }, { "id": "PE-01-E3", "description": "retrieval_test_record showing that a representative sample of archived artifacts was successfully retrieved within the defined SLA, with retrieval timestamps and artifact hashes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PE-01-E4", "description": "litigation_hold_activation_record documenting hold scope, activation timestamp, and confirmation that affected artifacts are locked against deletion for the hold duration", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PE-01-E5", "description": "archive_access_control_manifest listing authorized readers and writers with role assignments, confirming write access is restricted to the ingestion pipeline and no interactive modification is permitted", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "EU-AIA-ART18-02", "section": "Art. 18(2)", "title": "Documentation retention \u2014 availability to authorities on request", "text": "The documentation referred to in paragraph 1 shall be kept available to the relevant national competent authorities and the AI Office upon request.", "verdict": "supported", "coverage": "direct", "notes": "AU-03 (Auditor Access and Cooperation Protocols) establishes the access control and cooperation procedures for providing documentation to competent authorities on request, including response timelines and access provisioning. PE-02 (Regulatory Disclosure Readiness) maintains a continuously updated regulatory evidence package ready for authority inspection. AU-04 (Audit Trail Integrity) ensures that documentation provided to authorities is cryptographically verifiable as unaltered.", "control_count": 3, "proof_chain": [ { "control": "apeiris://compliance/controls/AU-03", "id": "AU-03", "domain": "compliance", "name": "Auditor Access and Cooperation Protocols", "validation_objective": "All regulatory and external auditor interactions during the audit period are logged in the cooperation register within 24 hours of occurrence, every document production was reviewed and approved by the audit coordinator before transmittal, and no regulatory response deadline was missed. The auditor access protocol has been reviewed within the prior 24 months and all personnel in roles likely to receive regulatory inquiries hold current training records.", "blocking_effect": "requires-review", "evidence_required": [ "Cooperation register for the audit period listing every examiner contact with contact_date, regulator_identity, contact_type, request_description, response_deadline, response_submitted_date, and document_production_id for each production made", "Document production approval log showing audit coordinator and legal counsel pre-transmittal sign-off timestamp for each document set produced to examiners during the period", "Annual simulation exercise report documenting scenario design, participants, findings, and after-action remediation items for the exercise conducted in the review year", "Protocol training completion records for all personnel in roles likely to receive direct regulatory inquiry, showing completion within the prior 12 months", "Auditor system access provisioning records for any system access granted to examiners, including access_scope, provisioning_date, provisioning_authority, and access_revocation_date" ], "evidence": [ { "id": "AU-03-E1", "description": "Cooperation register for the audit period listing every examiner contact with contact_date, regulator_identity, contact_type, request_description, response_deadline, response_submitted_date, and document_production_id for each production made", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AU-03-E2", "description": "Document production approval log showing audit coordinator and legal counsel pre-transmittal sign-off timestamp for each document set produced to examiners during the period", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AU-03-E3", "description": "Annual simulation exercise report documenting scenario design, participants, findings, and after-action remediation items for the exercise conducted in the review year", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AU-03-E4", "description": "Protocol training completion records for all personnel in roles likely to receive direct regulatory inquiry, showing completion within the prior 12 months", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AU-03-E5", "description": "Auditor system access provisioning records for any system access granted to examiners, including access_scope, provisioning_date, provisioning_authority, and access_revocation_date", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 74(12) requires operators to grant market surveillance authorities full access to the documentation and to the training, validation and testing data sets used for the development of high-risk AI systems, and Article 74(13) provides for access to source code upon reasoned request. The cooperation protocol implements the structured response to these EU AI Act examination powers, including documentation access procedures, expert designation, and production workflows." }, { "control": "apeiris://authority/controls/PE-02", "id": "PE-02", "domain": "authority", "name": "Regulatory Disclosure Readiness", "validation_objective": "For every AI system subject to a regulatory transparency obligation, a complete, current disclosure package must be pre-staged and retrievable within the defined submission window. Each package must include technical documentation, conformity assessment records, and incident notification templates validated against the applicable regulatory schema.", "blocking_effect": "blocks-deployment", "evidence_required": [ "disclosure_package_inventory listing every AI system in scope with system_id, applicable_regulation, package_version, last_updated timestamp, and package_completeness_status", "technical_documentation_record per system containing model card, system architecture summary, intended use case, risk classification rationale, and conformity assessment reference", "conformity_assessment_record per applicable system demonstrating compliance with the relevant regulatory article, with assessor identity, assessment date, and findings summary", "incident_notification_template per applicable regulation validated against the regulatory authority's published schema, with a test submission record confirming schema acceptance", "package_readiness_drill_record showing that a disclosure package was successfully retrieved and formatted for submission within the defined regulatory response window during a tabletop or live drill" ], "evidence": [ { "id": "PE-02-E1", "description": "disclosure_package_inventory listing every AI system in scope with system_id, applicable_regulation, package_version, last_updated timestamp, and package_completeness_status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PE-02-E2", "description": "technical_documentation_record per system containing model card, system architecture summary, intended use case, risk classification rationale, and conformity assessment reference", "evidence_type": "model-card", "verification": "attested" }, { "id": "PE-02-E3", "description": "conformity_assessment_record per applicable system demonstrating compliance with the relevant regulatory article, with assessor identity, assessment date, and findings summary", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PE-02-E4", "description": "incident_notification_template per applicable regulation validated against the regulatory authority's published schema, with a test submission record confirming schema acceptance", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "PE-02-E5", "description": "package_readiness_drill_record showing that a disclosure package was successfully retrieved and formatted for submission within the defined regulatory response window during a tabletop or live drill", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "Pre-staged disclosure packages support Art. 13 transparency obligations, partially, focused on submission readiness." }, { "control": "apeiris://compliance/controls/AU-04", "id": "AU-04", "domain": "compliance", "name": "Audit Trail Integrity", "validation_objective": "The audit log system must maintain a cryptographically chained, append-only record of all compliance program activities \u2014 including policy attestations, control assessments, evidence submissions, and configuration changes \u2014 such that any attempt to modify, delete, or insert log records is detectable within 24 hours of occurrence. Automated daily hash chain verification must confirm log integrity continuously and alert the compliance officer within 1 hour of any detected break.", "blocking_effect": "advisory", "evidence_required": [ "cryptographic_hash_chain_report listing hash values for each log batch and chain linkage between successive batches, covering the full audit period with no unexplained gaps", "WORM_storage_replication_log confirming each log batch was replicated to immutable secondary store within 60 seconds, with source generation timestamp and secondary write timestamp for each batch", "daily_integrity_verification_report showing automated hash chain verification results, detected breaks, and alert dispatch timestamps for each verification run in the last 30 days", "log_custody_register documenting all personnel with access to log infrastructure, last quarterly access review date, and access removal records for personnel no longer requiring access", "log_gap_analysis_report confirming no unexplained gaps in log sequence numbers or timestamps for the audit period" ], "evidence": [ { "id": "AU-04-E1", "description": "cryptographic_hash_chain_report listing hash values for each log batch and chain linkage between successive batches, covering the full audit period with no unexplained gaps", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AU-04-E2", "description": "WORM_storage_replication_log confirming each log batch was replicated to immutable secondary store within 60 seconds, with source generation timestamp and secondary write timestamp for each batch", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AU-04-E3", "description": "daily_integrity_verification_report showing automated hash chain verification results, detected breaks, and alert dispatch timestamps for each verification run in the last 30 days", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "AU-04-E4", "description": "log_custody_register documenting all personnel with access to log infrastructure, last quarterly access review date, and access removal records for personnel no longer requiring access", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AU-04-E5", "description": "log_gap_analysis_report confirming no unexplained gaps in log sequence numbers or timestamps for the audit period", "evidence_type": "audit-log", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 12 requires high-risk AI systems to automatically generate logs to enable traceability and monitoring. Tamper-evident audit trail controls ensure these mandatory logs are protected from modification and retain their evidentiary value for market surveillance authority review throughout the required retention period." } ] }, { "requirement_id": "EU-AIA-ART19-01", "section": "Art. 19(1)", "title": "Conformity assessment \u2014 procedure selection and completion", "text": "Providers of high-risk AI systems shall ensure that their systems are subject to a conformity assessment procedure prior to placing on the market or putting into service, in accordance with Articles 43 to 49.", "verdict": "partial", "coverage": "partial", "notes": "RF-02 (EU AI Act Conformity Assessment Pathway Selection) provides the Apeiris control for selecting and documenting the applicable conformity assessment pathway. OB-04 (EU AI Act Conformity Assessment Obligation Management) tracks the conformity assessment as a managed obligation. AU-01 (Audit Readiness Program) maintains the organization in a state ready for third-party conformity assessment. RF-03 produces the technical documentation required for the assessment. Partial: the actual notified body assessment for Annex III high-risk systems, the EU Declaration of Conformity, CE marking, and EU database registration are formal regulatory acts that occur outside the Apeiris control framework.", "control_count": 4, "proof_chain": [ { "control": "apeiris://compliance/controls/RF-02", "id": "RF-02", "domain": "compliance", "name": "EU AI Act Conformity Assessment Pathway Selection", "validation_objective": "Every high-risk AI system in the classification register must have a conformity assessment pathway record specifying the Art. 43 legal basis for pathway selection, a named assessment owner, legal counsel sign-off, and a projected assessment timeline. For systems on the third-party pathway, notified body engagement evidence must show initiation at least 6 months before the projected market placement date. No high-risk system may reach market placement without a completed and legally signed pathway record.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Conformity pathway register export with system_id, pathway_type (internal/third-party), art_43_basis, assessment_owner, legal_sign_off_date, and projected_placement_date for each high-risk system", "Legal pathway selection opinion for each high-risk system citing the specific Art. 43 sub-clause and confirming the pathway type is legally permissible for the applicable Annex III category", "Notified body engagement records with engagement_initiation_date, notified_body_id, and projected assessment completion date for all third-party pathway systems", "CI/CD pipeline gate enforcement log confirming deployment was blocked for high-risk AI system images without a valid pathway record identifier in the release metadata", "Conformity pathway version history with change log linking each pathway record revision to the CE declaration version it supports" ], "evidence": [ { "id": "RF-02-E1", "description": "Conformity pathway register export with system_id, pathway_type (internal/third-party), art_43_basis, assessment_owner, legal_sign_off_date, and projected_placement_date for each high-risk system", "evidence_type": "third-party-audit-report", "verification": "third-party" }, { "id": "RF-02-E2", "description": "Legal pathway selection opinion for each high-risk system citing the specific Art. 43 sub-clause and confirming the pathway type is legally permissible for the applicable Annex III category", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RF-02-E3", "description": "Notified body engagement records with engagement_initiation_date, notified_body_id, and projected assessment completion date for all third-party pathway systems", "evidence_type": "third-party-audit-report", "verification": "third-party" }, { "id": "RF-02-E4", "description": "CI/CD pipeline gate enforcement log confirming deployment was blocked for high-risk AI system images without a valid pathway record identifier in the release metadata", "evidence_type": "audit-log", "verification": "automated" }, { "id": "RF-02-E5", "description": "Conformity pathway version history with change log linking each pathway record revision to the CE declaration version it supports", "evidence_type": "audit-log", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "Art. 43 is the primary operative provision governing conformity assessment pathway selection, distinguishing between systems that require notified body involvement and those eligible for internal assessment procedures. Compliance with this control is a mandatory prerequisite to lawful market placement of high-risk AI systems." }, { "control": "apeiris://compliance/controls/OB-04", "id": "OB-04", "domain": "compliance", "name": "EU AI Act Conformity Assessment Obligation Management", "validation_objective": "For each AI system classified as high-risk under the EU AI Act, a structured obligation inventory must exist covering all provider obligations under Article 16 and the Articles 8\u201315 requirements they incorporate, with per-Article owner assignment and conformity assessment milestone tracking; a deployment gate must block EU market placement of any high-risk AI system until conformity assessment documentation is complete and approved.", "blocking_effect": "blocks-deployment", "evidence_required": [ "eu_ai_act_obligation_inventory per AI system with system_id, risk_classification record referencing CA-01 scope_record, and per-Article obligation record (Arts. 8\u201316) each showing article_id, obligation_text, owner_name, fulfillment_status, and milestone_completion_dates", "conformity_assessment_completion_record showing all required technical documentation artifacts (Art. 11), conformity declaration (Art. 47), and applicable notified body certification or self-assessment justification", "deployment_gate_log confirming EU market placement was blocked until conformity_assessment_status='complete' for each high-risk AI system, with approver identity and approval timestamp", "eu_ai_act_obligation_review_log showing quarterly review events for each Article obligation, confirming continued compliance as the regulation's implementation stagger advances" ], "evidence": [ { "id": "OB-04-E1", "description": "eu_ai_act_obligation_inventory per AI system with system_id, risk_classification record referencing CA-01 scope_record, and per-Article obligation record (Arts. 8\u201316) each showing article_id, obligation_text, owner_name, fulfillment_status, and milestone_completion_dates", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OB-04-E2", "description": "conformity_assessment_completion_record showing all required technical documentation artifacts (Art. 11), conformity declaration (Art. 47), and applicable notified body certification or self-assessment justification", "evidence_type": "certification", "verification": "third-party" }, { "id": "OB-04-E3", "description": "deployment_gate_log confirming EU market placement was blocked until conformity_assessment_status='complete' for each high-risk AI system, with approver identity and approval timestamp", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OB-04-E4", "description": "eu_ai_act_obligation_review_log showing quarterly review events for each Article obligation, confirming continued compliance as the regulation's implementation stagger advances", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 16 enumerates the obligations of providers of high-risk AI systems, which incorporate the Section 2 requirements of Articles 8\u201315 (risk management, data governance, technical documentation, record-keeping, transparency, human oversight, accuracy and robustness). Each provision imposes a specific, legally binding requirement on providers, and this control operationalizes per-Article tracking through the conformity assessment lifecycle." }, { "control": "apeiris://compliance/controls/AU-01", "id": "AU-01", "domain": "compliance", "name": "Audit Readiness Program", "validation_objective": "The organization maintains a continuously current evidence library for each applicable compliance framework with completeness scores at or above 95%, all artifacts refreshed within defined cadence thresholds, and at least four quarterly mock audit exercises completed in the review year with findings closed within 45 days. No framework evidence package was assembled reactively within 30 days of an audit notification.", "blocking_effect": "advisory", "evidence_required": [ "Evidence library completeness score history for each applicable framework, showing scores recorded at least monthly and distributed across the review period rather than spiking near audit notification dates", "Artifact staleness tracking report showing each artifact type's last_refreshed_date and compliance status against the defined maximum staleness threshold", "Quarterly mock audit reports documenting scope, methodology, findings, and participants for each of the four required exercises in the review year", "Mock audit finding remediation records confirming all gaps identified in each exercise were closed within 45 days of report issuance", "Annual audit readiness program charter or review sign-off from the Chief Compliance Officer confirming applicable framework inventory and program scope" ], "evidence": [ { "id": "AU-01-E1", "description": "Evidence library completeness score history for each applicable framework, showing scores recorded at least monthly and distributed across the review period rather than spiking near audit notification dates", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AU-01-E2", "description": "Artifact staleness tracking report showing each artifact type's last_refreshed_date and compliance status against the defined maximum staleness threshold", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AU-01-E3", "description": "Quarterly mock audit reports documenting scope, methodology, findings, and participants for each of the four required exercises in the review year", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AU-01-E4", "description": "Mock audit finding remediation records confirming all gaps identified in each exercise were closed within 45 days of report issuance", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AU-01-E5", "description": "Annual audit readiness program charter or review sign-off from the Chief Compliance Officer confirming applicable framework inventory and program scope", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 17(1)(k) requires the quality management system of providers of high-risk AI systems to include systems and procedures for record-keeping of all relevant documentation and information. Audit readiness packages serve as the operational mechanism for maintaining these records in a state accessible to market surveillance authorities at any point during the system lifecycle." }, { "control": "apeiris://compliance/controls/RF-03", "id": "RF-03", "domain": "compliance", "name": "EU AI Act Technical Documentation Package (Art. 11)", "validation_objective": "Each high-risk AI system must have an Annex IV technical documentation package with all required sections substantively populated \u2014 no missing sections or placeholder content \u2014 version-controlled and linked to the current CE declaration, updated within 30 days of any qualifying model or deployment scope change, and retained in a controlled repository for 10 years from market placement date as required by Art. 18.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Annex IV completeness checklist per high-risk system with completion status for each required section, documentation owner sign-off, and compliance team approval date", "Technical documentation version history linking each documentation version to the corresponding model version, CE declaration version, and the change management ticket that triggered the update", "Model change management tickets with documentation update completion confirmation timestamp within 30 days of each qualifying model or deployment scope change event", "Documentation repository access log and retention policy configuration confirming role-based access controls, full version history, and a 10-year minimum retention period anchored to market placement date", "Pre-submission documentation completeness review record with legal and compliance sign-off completed before notified body submission or CE declaration issuance" ], "evidence": [ { "id": "RF-03-E1", "description": "Annex IV completeness checklist per high-risk system with completion status for each required section, documentation owner sign-off, and compliance team approval date", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RF-03-E2", "description": "Technical documentation version history linking each documentation version to the corresponding model version, CE declaration version, and the change management ticket that triggered the update", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RF-03-E3", "description": "Model change management tickets with documentation update completion confirmation timestamp within 30 days of each qualifying model or deployment scope change event", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RF-03-E4", "description": "Documentation repository access log and retention policy configuration confirming role-based access controls, full version history, and a 10-year minimum retention period anchored to market placement date", "evidence_type": "audit-log", "verification": "automated" }, { "id": "RF-03-E5", "description": "Pre-submission documentation completeness review record with legal and compliance sign-off completed before notified body submission or CE declaration issuance", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "Art. 11 imposes a mandatory obligation on providers of high-risk AI systems to draw up technical documentation before market placement, and Annex IV specifies the required documentation sections. This control implements the documentation assembly and maintenance obligation in its entirety." } ] }, { "requirement_id": "EU-AIA-ART19-02", "section": "Art. 19(2)", "title": "Conformity assessment \u2014 re-assessment on substantial modification", "text": "High-risk AI systems which have already been subject to a conformity assessment procedure shall undergo a new conformity assessment procedure whenever they are substantially modified, regardless of whether the modified system is intended to be further distributed or continues to be used by the current deployer.", "verdict": "partial", "coverage": "partial", "notes": "LI-09 (Material-Change Determination and Authorization Gate) is the direct gate for determining whether a system change constitutes a substantial modification requiring re-assessment. RF-02 governs the conformity assessment pathway once a substantial modification is confirmed. OB-04 tracks re-assessment as a regulatory obligation triggered by LI-09 findings. OA-05 (Regulatory and Legal Review Sign-Off) requires regulatory counsel sign-off on material change determinations. Partial: the same formal regulatory procedure limitations as Art. 19(1) apply \u2014 the actual re-assessment with notified body or internal procedure, and updated EU database registration, are outside Apeiris scope.", "control_count": 4, "proof_chain": [ { "control": "apeiris://model/controls/LI-09", "id": "LI-09", "domain": "model", "name": "Material-Change Determination and Authorization Gate", "validation_objective": "Every planned change to a deployed AI model or its operating environment is assessed against a documented materiality threshold; changes that meet or exceed the threshold must complete a full re-evaluation and authorization cycle before the updated system goes live, and no material change may bypass this gate.", "blocking_effect": "blocks-deployment", "evidence_required": [ "change_assessment_record documenting the change type (model update, prompt change, RAG corpus change, guardrail change, provider-version change), the materiality determination (material/non-material), and the criteria applied", "re_evaluation_authorization_record for each material change showing completed evaluation cycle, approver identity, approval timestamp, and the specific evaluation artifacts reviewed", "deployment_gate_block_log confirming that attempted deployments of material changes without a completed authorization record were rejected by the pipeline", "change_classification_policy_document defining materiality thresholds for each change type, reviewed and signed by model governance and risk owners" ], "evidence": [ { "id": "LI-09-E1", "description": "change_assessment_record documenting the change type (model update, prompt change, RAG corpus change, guardrail change, provider-version change), the materiality determination (material/non-material), and the criteria applied", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-09-E2", "description": "re_evaluation_authorization_record for each material change showing completed evaluation cycle, approver identity, approval timestamp, and the specific evaluation artifacts reviewed", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "LI-09-E3", "description": "deployment_gate_block_log confirming that attempted deployments of material changes without a completed authorization record were rejected by the pipeline", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-09-E4", "description": "change_classification_policy_document defining materiality thresholds for each change type, reviewed and signed by model governance and risk owners", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art-9 requires that the risk management system for high-risk AI systems be ongoing and iterative, covering the full system lifecycle including modifications. LI-09 directly supports Art-9 by providing the operational mechanism for evaluating whether modifications to the AI system require a new risk assessment cycle. Art-9(9) specifically addresses risk management for AI system modifications." }, { "control": "apeiris://compliance/controls/RF-02", "id": "RF-02", "domain": "compliance", "name": "EU AI Act Conformity Assessment Pathway Selection", "validation_objective": "Every high-risk AI system in the classification register must have a conformity assessment pathway record specifying the Art. 43 legal basis for pathway selection, a named assessment owner, legal counsel sign-off, and a projected assessment timeline. For systems on the third-party pathway, notified body engagement evidence must show initiation at least 6 months before the projected market placement date. No high-risk system may reach market placement without a completed and legally signed pathway record.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Conformity pathway register export with system_id, pathway_type (internal/third-party), art_43_basis, assessment_owner, legal_sign_off_date, and projected_placement_date for each high-risk system", "Legal pathway selection opinion for each high-risk system citing the specific Art. 43 sub-clause and confirming the pathway type is legally permissible for the applicable Annex III category", "Notified body engagement records with engagement_initiation_date, notified_body_id, and projected assessment completion date for all third-party pathway systems", "CI/CD pipeline gate enforcement log confirming deployment was blocked for high-risk AI system images without a valid pathway record identifier in the release metadata", "Conformity pathway version history with change log linking each pathway record revision to the CE declaration version it supports" ], "evidence": [ { "id": "RF-02-E1", "description": "Conformity pathway register export with system_id, pathway_type (internal/third-party), art_43_basis, assessment_owner, legal_sign_off_date, and projected_placement_date for each high-risk system", "evidence_type": "third-party-audit-report", "verification": "third-party" }, { "id": "RF-02-E2", "description": "Legal pathway selection opinion for each high-risk system citing the specific Art. 43 sub-clause and confirming the pathway type is legally permissible for the applicable Annex III category", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RF-02-E3", "description": "Notified body engagement records with engagement_initiation_date, notified_body_id, and projected assessment completion date for all third-party pathway systems", "evidence_type": "third-party-audit-report", "verification": "third-party" }, { "id": "RF-02-E4", "description": "CI/CD pipeline gate enforcement log confirming deployment was blocked for high-risk AI system images without a valid pathway record identifier in the release metadata", "evidence_type": "audit-log", "verification": "automated" }, { "id": "RF-02-E5", "description": "Conformity pathway version history with change log linking each pathway record revision to the CE declaration version it supports", "evidence_type": "audit-log", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "Art. 43 is the primary operative provision governing conformity assessment pathway selection, distinguishing between systems that require notified body involvement and those eligible for internal assessment procedures. Compliance with this control is a mandatory prerequisite to lawful market placement of high-risk AI systems." }, { "control": "apeiris://compliance/controls/OB-04", "id": "OB-04", "domain": "compliance", "name": "EU AI Act Conformity Assessment Obligation Management", "validation_objective": "For each AI system classified as high-risk under the EU AI Act, a structured obligation inventory must exist covering all provider obligations under Article 16 and the Articles 8\u201315 requirements they incorporate, with per-Article owner assignment and conformity assessment milestone tracking; a deployment gate must block EU market placement of any high-risk AI system until conformity assessment documentation is complete and approved.", "blocking_effect": "blocks-deployment", "evidence_required": [ "eu_ai_act_obligation_inventory per AI system with system_id, risk_classification record referencing CA-01 scope_record, and per-Article obligation record (Arts. 8\u201316) each showing article_id, obligation_text, owner_name, fulfillment_status, and milestone_completion_dates", "conformity_assessment_completion_record showing all required technical documentation artifacts (Art. 11), conformity declaration (Art. 47), and applicable notified body certification or self-assessment justification", "deployment_gate_log confirming EU market placement was blocked until conformity_assessment_status='complete' for each high-risk AI system, with approver identity and approval timestamp", "eu_ai_act_obligation_review_log showing quarterly review events for each Article obligation, confirming continued compliance as the regulation's implementation stagger advances" ], "evidence": [ { "id": "OB-04-E1", "description": "eu_ai_act_obligation_inventory per AI system with system_id, risk_classification record referencing CA-01 scope_record, and per-Article obligation record (Arts. 8\u201316) each showing article_id, obligation_text, owner_name, fulfillment_status, and milestone_completion_dates", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OB-04-E2", "description": "conformity_assessment_completion_record showing all required technical documentation artifacts (Art. 11), conformity declaration (Art. 47), and applicable notified body certification or self-assessment justification", "evidence_type": "certification", "verification": "third-party" }, { "id": "OB-04-E3", "description": "deployment_gate_log confirming EU market placement was blocked until conformity_assessment_status='complete' for each high-risk AI system, with approver identity and approval timestamp", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OB-04-E4", "description": "eu_ai_act_obligation_review_log showing quarterly review events for each Article obligation, confirming continued compliance as the regulation's implementation stagger advances", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 16 enumerates the obligations of providers of high-risk AI systems, which incorporate the Section 2 requirements of Articles 8\u201315 (risk management, data governance, technical documentation, record-keeping, transparency, human oversight, accuracy and robustness). Each provision imposes a specific, legally binding requirement on providers, and this control operationalizes per-Article tracking through the conformity assessment lifecycle." }, { "control": "apeiris://model/controls/OA-05", "id": "OA-05", "domain": "model", "name": "Regulatory and Legal Review Sign-Off", "validation_objective": "Every AI model deployed in a regulated use case must have a documented legal sign-off record from compliance counsel before production promotion, specifying applicable regulations, compliance posture assessment, documentation status, and accepted residual legal risks. EU high-risk AI systems must have a completed conformity assessment and a current EU Declaration of Conformity. Sign-off records must be retained for the model's operational life plus seven years.", "blocking_effect": "blocks-deployment", "evidence_required": [ "legal_signoff_record for each regulated-use model deployment, including: counsel name, date, applicable regulations identified, compliance posture assessment, documentation status, and accepted residual legal risks \u2014 pre-dating the production deployment timestamp", "eu_declaration_of_conformity for each model classified as eu-high-risk, with conformity assessment completion date, notified body reference if applicable, and model version scope", "sr_26_2_validation_report for each US-regulated banking model, reviewed and approved by the independent model risk function prior to deployment", "regulatory_applicability_matrix current version maintained by the compliance function, showing which regulations apply to each model classification" ], "evidence": [ { "id": "OA-05-E1", "description": "legal_signoff_record for each regulated-use model deployment, including: counsel name, date, applicable regulations identified, compliance posture assessment, documentation status, and accepted residual legal risks \u2014 pre-dating the production deployment timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-05-E2", "description": "eu_declaration_of_conformity for each model classified as eu-high-risk, with conformity assessment completion date, notified body reference if applicable, and model version scope", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-05-E3", "description": "sr_26_2_validation_report for each US-regulated banking model, reviewed and approved by the independent model risk function prior to deployment", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-05-E4", "description": "regulatory_applicability_matrix current version maintained by the compliance function, showing which regulations apply to each model classification", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "Art-43 requires conformity assessment; Art-47 requires EU Declaration of Conformity for high-risk AI before market placement." } ] }, { "requirement_id": "EU-AIA-ART20-01", "section": "Art. 20(1)", "title": "Post-market monitoring \u2014 proactive system", "text": "Providers of high-risk AI systems shall establish and document a post-market monitoring system in a manner that is proportionate to the nature of the AI technologies and the risks of the high-risk AI system.", "verdict": "supported", "coverage": "direct", "notes": "CR-06 (Post-Market Surveillance) is the Apeiris control that directly establishes and documents the post-market monitoring system with risk-proportionate scope and frequency. RF-04 (EU AI Act Post-Market Monitoring Plan \u2014 Art. 72) provides the formal documented plan required by this article. CR-01 (Continuous Production Monitoring and Risk Aggregation) provides the technical infrastructure. BH-02 (Concept and Data Drift Detection) ensures the monitoring system detects distributional changes that may affect system behavior in post-market conditions.", "control_count": 4, "proof_chain": [ { "control": "apeiris://model/controls/CR-06", "id": "CR-06", "domain": "model", "name": "Post-Market Surveillance", "validation_objective": "The organization must operate three distinct proactive surveillance channels \u2014 a structured user-facing harm reporting mechanism, a coordinated vulnerability disclosure (CVD) program with a monitored security inbox, and a quarterly AI literature and media monitoring process \u2014 with outputs aggregated into a monthly post-market surveillance report reviewed and signed by the AI risk function, and an annual surveillance summary included in the model's EU high-risk AI technical documentation (LI-04).", "blocking_effect": "advisory", "evidence_required": [ "User-facing harm reporting mechanism deployment record showing endpoint URL, structured input schema (harm_type, severity_self_assessed, description), and CR-02 archive path", "Published CVD policy document at a canonical URL with designated security email alias and monitored inbox confirmation, including acknowledgement SLA statement", "Last 12 monthly post-market surveillance reports with AI risk function reviewer name, sign-off signature, and review date on each report", "Annual surveillance summary document aggregating user reports, CVD submissions, and literature findings \u2014 present in the model's LI-04 technical documentation with review date", "CVD acknowledgement records showing each submission received an acknowledgement within 5 business days of receipt" ], "evidence": [ { "id": "CR-06-E1", "description": "User-facing harm reporting mechanism deployment record showing endpoint URL, structured input schema (harm_type, severity_self_assessed, description), and CR-02 archive path", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-06-E2", "description": "Published CVD policy document at a canonical URL with designated security email alias and monitored inbox confirmation, including acknowledgement SLA statement", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-06-E3", "description": "Last 12 monthly post-market surveillance reports with AI risk function reviewer name, sign-off signature, and review date on each report", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CR-06-E4", "description": "Annual surveillance summary document aggregating user reports, CVD submissions, and literature findings \u2014 present in the model's LI-04 technical documentation with review date", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CR-06-E5", "description": "CVD acknowledgement records showing each submission received an acknowledgement within 5 business days of receipt", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 73 requires providers of high-risk AI systems and GPAI models with systemic risk to notify national competent authorities of serious incidents without undue delay; CR-06 directly implements this obligation by defining the incident severity thresholds that trigger regulatory notification, the 72-hour notification SLA, and the structured notification content including affected parties, root cause, and corrective actions." }, { "control": "apeiris://compliance/controls/RF-04", "id": "RF-04", "domain": "compliance", "name": "EU AI Act Post-Market Monitoring Plan (Art. 72)", "validation_objective": "Every high-risk AI system in production must have an approved post-market monitoring plan covering all Art. 72 required elements, with monitoring data current and free of gaps exceeding the defined collection interval, and all qualifying serious incidents must have documented competent authority notification records delivered within Art. 73 prescribed timelines \u2014 no later than 15 days for serious incidents generally, 2 days for widespread infringement or critical-infrastructure incidents, and 10 days in the event of a death \u2014 from the point of detection.", "blocking_effect": "advisory", "evidence_required": [ "Post-market monitoring plan per high-risk system with metrics[], collection_sources[], collection_frequency, serious_incident_thresholds[], escalation_workflow, and notification_timelines defined and approved before market placement", "Tamper-evident monitoring data log with inference-time performance metrics, fairness metrics, error rates, and collection timestamps covering the full production period with no gaps exceeding the defined collection frequency", "Serious incident log with incident_id, detection_timestamp, internal_escalation_timestamp, competent_authority_notification_timestamp, notification_method, and disposition for each qualifying event under Art. 3(49)", "Quarterly post-market monitoring review report comparing current performance metrics against the Annex IV baseline with identified deviations documented and assigned for remediation", "Annual post-market monitoring summary artifact incorporated into the technical documentation package update with version linkage" ], "evidence": [ { "id": "RF-04-E1", "description": "Post-market monitoring plan per high-risk system with metrics[], collection_sources[], collection_frequency, serious_incident_thresholds[], escalation_workflow, and notification_timelines defined and approved before market placement", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "RF-04-E2", "description": "Tamper-evident monitoring data log with inference-time performance metrics, fairness metrics, error rates, and collection timestamps covering the full production period with no gaps exceeding the defined collection frequency", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "RF-04-E3", "description": "Serious incident log with incident_id, detection_timestamp, internal_escalation_timestamp, competent_authority_notification_timestamp, notification_method, and disposition for each qualifying event under Art. 3(49)", "evidence_type": "incident-record", "verification": "attested" }, { "id": "RF-04-E4", "description": "Quarterly post-market monitoring review report comparing current performance metrics against the Annex IV baseline with identified deviations documented and assigned for remediation", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "RF-04-E5", "description": "Annual post-market monitoring summary artifact incorporated into the technical documentation package update with version linkage", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "Art. 72 mandates that providers establish a post-market monitoring system proportionate to the nature and risk of the AI system, and Art. 73 requires serious incident reporting to competent authorities within defined timelines. This control directly implements both obligations." }, { "control": "apeiris://model/controls/CR-01", "id": "CR-01", "domain": "model", "name": "Continuous Production Monitoring and Risk Aggregation", "validation_objective": "All runtime monitoring signals \u2014 performance, drift, fairness, safety incidents, and deployment event flags \u2014 must be continuously aggregated into a unified risk dashboard with pre-configured automated alerting thresholds; any degradation in a monitored dimension must be detected and an alert dispatched within one operational window.", "blocking_effect": "advisory", "evidence_required": [ "risk_dashboard_configuration_record showing all registered signal feeds (performance, drift, fairness, safety, incident), their alert thresholds, assigned monitoring window duration, and escalation recipients", "alert_audit_log covering at least 30 days showing triggered alerts with signal_type, threshold_crossed, alert_timestamp, and escalation_recipient for each alert", "monitoring_coverage_audit confirming every deployed model version has an associated monitoring configuration with no version gaps", "risk_aggregation_methodology_document defining how individual dimension alerts are combined into composite risk scores and dashboard status indicators", "post-market_monitoring_report satisfying EU AI Act Art. 72 covering the monitoring period, key findings, and corrective actions taken or planned" ], "evidence": [ { "id": "CR-01-E1", "description": "risk_dashboard_configuration_record showing all registered signal feeds (performance, drift, fairness, safety, incident), their alert thresholds, assigned monitoring window duration, and escalation recipients", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-01-E2", "description": "alert_audit_log covering at least 30 days showing triggered alerts with signal_type, threshold_crossed, alert_timestamp, and escalation_recipient for each alert", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E3", "description": "monitoring_coverage_audit confirming every deployed model version has an associated monitoring configuration with no version gaps", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E4", "description": "risk_aggregation_methodology_document defining how individual dimension alerts are combined into composite risk scores and dashboard status indicators", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E5", "description": "post-market_monitoring_report satisfying EU AI Act Art. 72 covering the monitoring period, key findings, and corrective actions taken or planned", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 72 requires high-risk AI system providers to establish, document, and implement a post-market monitoring plan; CR-01's continuous risk aggregation dashboard \u2014 collecting signals from BH-01 through BH-10 layers and applying tiered alerting calibrated at \u00b12\u03c3 from baseline \u2014 operationalizes the systematic performance collection and anomaly identification components of a post-market monitoring plan." }, { "control": "apeiris://model/controls/BH-02", "id": "BH-02", "domain": "model", "name": "Concept and Data Drift Detection", "validation_objective": "The production inference pipeline must compare input feature distributions and prediction distributions against a versioned, SHA-256-signed DriftReference artifact using PSI and KS-test statistics for every monitoring window that meets minimum_sample_size, such that drift exceeding profile-conditional PSI thresholds triggers tiered alert actions, and for continuously-learning profiles, automatically suspends online updates pending a signed model-owner resume authorization.", "blocking_effect": "advisory", "evidence_required": [ "versioned DriftReference artifact for the current production model with SHA-256 hash, training date, and per-feature statistics (mean, std, histogram bins, and KDE parameters) for all tier-1 monitored features", "drift event log for trailing 90 days with fields: feature_name, test_statistic, p_value, window_start, window_end, sample_count, alert_severity, and action_taken for each drift event", "monthly drift summary report signed by the model owner, including trend analysis across tier-1 features and prediction distribution PSI over the reporting period", "profile-conditional drift threshold configuration (YAML or equivalent) showing per-profile PSI alert and critical thresholds, minimum_sample_size, and window duration, stored under version control" ], "evidence": [ { "id": "BH-02-E1", "description": "versioned DriftReference artifact for the current production model with SHA-256 hash, training date, and per-feature statistics (mean, std, histogram bins, and KDE parameters) for all tier-1 monitored features", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-02-E2", "description": "drift event log for trailing 90 days with fields: feature_name, test_statistic, p_value, window_start, window_end, sample_count, alert_severity, and action_taken for each drift event", "evidence_type": "audit-log", "verification": "automated" }, { "id": "BH-02-E3", "description": "monthly drift summary report signed by the model owner, including trend analysis across tier-1 features and prediction distribution PSI over the reporting period", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-02-E4", "description": "profile-conditional drift threshold configuration (YAML or equivalent) showing per-profile PSI alert and critical thresholds, minimum_sample_size, and window duration, stored under version control", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 72 requires providers and deployers of high-risk AI systems to establish and document post-market monitoring plans; BH-02's drift detection operationalizes the monitoring dimension by tracking input feature distribution and prediction shifts using PSI and KS-test statistics against signed baseline artifacts." } ] }, { "requirement_id": "EU-AIA-ART20-02", "section": "Art. 20(2)", "title": "Post-market monitoring \u2014 data collection and analysis plan", "text": "The post-market monitoring system shall actively collect and analyse data on the performance of high-risk AI systems throughout their lifetime in order to identify necessary updates and potential risks.", "verdict": "supported", "coverage": "direct", "notes": "RF-04 includes an active data collection and analysis plan as a required component of the post-market monitoring plan. CR-03 (Scheduled Model Re-validation) implements the periodic analysis of collected performance data. BH-03 (Production Performance Degradation Alerting) provides the automated detection of performance changes that may require corrective action or system update. BH-07 (Resource and Cost Anomaly Monitoring) extends monitoring to operational risk indicators beyond model accuracy.", "control_count": 4, "proof_chain": [ { "control": "apeiris://compliance/controls/RF-04", "id": "RF-04", "domain": "compliance", "name": "EU AI Act Post-Market Monitoring Plan (Art. 72)", "validation_objective": "Every high-risk AI system in production must have an approved post-market monitoring plan covering all Art. 72 required elements, with monitoring data current and free of gaps exceeding the defined collection interval, and all qualifying serious incidents must have documented competent authority notification records delivered within Art. 73 prescribed timelines \u2014 no later than 15 days for serious incidents generally, 2 days for widespread infringement or critical-infrastructure incidents, and 10 days in the event of a death \u2014 from the point of detection.", "blocking_effect": "advisory", "evidence_required": [ "Post-market monitoring plan per high-risk system with metrics[], collection_sources[], collection_frequency, serious_incident_thresholds[], escalation_workflow, and notification_timelines defined and approved before market placement", "Tamper-evident monitoring data log with inference-time performance metrics, fairness metrics, error rates, and collection timestamps covering the full production period with no gaps exceeding the defined collection frequency", "Serious incident log with incident_id, detection_timestamp, internal_escalation_timestamp, competent_authority_notification_timestamp, notification_method, and disposition for each qualifying event under Art. 3(49)", "Quarterly post-market monitoring review report comparing current performance metrics against the Annex IV baseline with identified deviations documented and assigned for remediation", "Annual post-market monitoring summary artifact incorporated into the technical documentation package update with version linkage" ], "evidence": [ { "id": "RF-04-E1", "description": "Post-market monitoring plan per high-risk system with metrics[], collection_sources[], collection_frequency, serious_incident_thresholds[], escalation_workflow, and notification_timelines defined and approved before market placement", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "RF-04-E2", "description": "Tamper-evident monitoring data log with inference-time performance metrics, fairness metrics, error rates, and collection timestamps covering the full production period with no gaps exceeding the defined collection frequency", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "RF-04-E3", "description": "Serious incident log with incident_id, detection_timestamp, internal_escalation_timestamp, competent_authority_notification_timestamp, notification_method, and disposition for each qualifying event under Art. 3(49)", "evidence_type": "incident-record", "verification": "attested" }, { "id": "RF-04-E4", "description": "Quarterly post-market monitoring review report comparing current performance metrics against the Annex IV baseline with identified deviations documented and assigned for remediation", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "RF-04-E5", "description": "Annual post-market monitoring summary artifact incorporated into the technical documentation package update with version linkage", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "Art. 72 mandates that providers establish a post-market monitoring system proportionate to the nature and risk of the AI system, and Art. 73 requires serious incident reporting to competent authorities within defined timelines. This control directly implements both obligations." }, { "control": "apeiris://model/controls/CR-03", "id": "CR-03", "domain": "model", "name": "Scheduled Model Re-validation", "validation_objective": "A full benchmark, bias, and safety evaluation suite must execute against every production model version on the defined re-validation schedule; results must be compared to the deployment-time baseline metrics, and any performance degradation beyond configured thresholds must trigger a formal response documented and initiated before the next operational window closes.", "blocking_effect": "blocks-deployment", "evidence_required": [ "re_validation_schedule_record per model version showing configured re-validation frequency, last_run_timestamp, next_run_due, and scheduled_suite_identifier with no unmonitored production versions", "scheduled_evaluation_report for each re-validation run showing benchmark results, bias metrics, and safety evaluation scores with explicit comparison to the deployment-time baseline", "threshold_comparison_record showing the delta between current re-validation results and baseline for each metric with a pass/fail determination against the configured degradation threshold", "re_validation_response_record for any threshold breach, documenting the triggered response action (rollback, retraining, or escalation), responsible_party, and closure_timestamp", "re_validation_coverage_audit confirming all active production model versions are enrolled in re-validation schedules and that no version has exceeded its next_run_due without a completed run" ], "evidence": [ { "id": "CR-03-E1", "description": "re_validation_schedule_record per model version showing configured re-validation frequency, last_run_timestamp, next_run_due, and scheduled_suite_identifier with no unmonitored production versions", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-03-E2", "description": "scheduled_evaluation_report for each re-validation run showing benchmark results, bias metrics, and safety evaluation scores with explicit comparison to the deployment-time baseline", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "CR-03-E3", "description": "threshold_comparison_record showing the delta between current re-validation results and baseline for each metric with a pass/fail determination against the configured degradation threshold", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-03-E4", "description": "re_validation_response_record for any threshold breach, documenting the triggered response action (rollback, retraining, or escalation), responsible_party, and closure_timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-03-E5", "description": "re_validation_coverage_audit confirming all active production model versions are enrolled in re-validation schedules and that no version has exceeded its next_run_due without a completed run", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 72 requires high-risk AI system providers to establish post-market monitoring systems that systematically collect and analyse data about model performance; CR-03's scheduled re-evaluation cadence and event-driven re-evaluation triggers directly implement the continuous monitoring and periodic review requirements that underpin Art. 72 compliance." }, { "control": "apeiris://model/controls/BH-03", "id": "BH-03", "domain": "model", "name": "Production Performance Degradation Alerting", "validation_objective": "Every production model version must have a corresponding signed EvaluationBaseline artifact containing primary task metrics and subgroup slice metrics from the release evaluation gate; the metrics aggregation service must continuously compare production estimates against this baseline and fire tiered alerts when primary metrics regress 5% (warning) or 10% (critical) from the signed baseline values, including independent subgroup regression alerts.", "blocking_effect": "advisory", "evidence_required": [ "signed EvaluationBaseline artifact for the current production model version containing model_id, version, eval_date, primary_metrics with confidence intervals, subgroup slice metrics, eval_dataset_hash, and artifact SHA-256", "performance alert log for trailing 90 days with fields: alert_id, metric_name, regression_pct, severity, triggered_at, acknowledged_at, root_cause, and remediation_action for each alert", "quarterly threshold review sign-off from model owner confirming 5%/10% regression thresholds remain appropriate for the current model type and deployment context", "proxy_metric_registry documenting which proxy metrics substitute for labeled ground truth when unavailable, including calibration methodology and documented limitations" ], "evidence": [ { "id": "BH-03-E1", "description": "signed EvaluationBaseline artifact for the current production model version containing model_id, version, eval_date, primary_metrics with confidence intervals, subgroup slice metrics, eval_dataset_hash, and artifact SHA-256", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-03-E2", "description": "performance alert log for trailing 90 days with fields: alert_id, metric_name, regression_pct, severity, triggered_at, acknowledged_at, root_cause, and remediation_action for each alert", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "BH-03-E3", "description": "quarterly threshold review sign-off from model owner confirming 5%/10% regression thresholds remain appropriate for the current model type and deployment context", "evidence_type": "human-review-record", "verification": "human" }, { "id": "BH-03-E4", "description": "proxy_metric_registry documenting which proxy metrics substitute for labeled ground truth when unavailable, including calibration methodology and documented limitations", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 72 requires high-risk AI system providers to implement post-market monitoring covering performance evaluation; BH-03's performance regression alerting \u2014 tracking accuracy, AUC, and F1 against a signed performance baseline \u2014 directly operationalizes the performance monitoring component of a post-market monitoring plan." }, { "control": "apeiris://model/controls/BH-07", "id": "BH-07", "domain": "model", "name": "Resource and Cost Anomaly Monitoring", "validation_objective": "The system must continuously monitor compute spend, token consumption, and API call volume per caller and model, with anomaly detection alerting within one operational window when any metric exceeds 2\u00d7 the rolling baseline; per-caller budget guardrails must automatically queue or block requests when the configured monthly spend cap is reached.", "blocking_effect": "advisory", "evidence_required": [ "cost_telemetry_pipeline_record showing CostEvent emission per request with caller_id, model_id, input_tokens, output_tokens, and cost_usd_estimated fields", "anomaly_detection_configuration_record showing baseline computation method (Z-score or EWMA), threshold multipliers, and evaluation window duration per caller and model", "budget_guardrail_configuration_record showing per-caller monthly spend cap, queue-activation threshold percentage, and hard-stop cap percentage for each active caller", "cost_spike_alert_log for any triggered alerts showing caller_id, time_window, observed_cost, baseline_cost, and anomaly_score with routing confirmation to MLOps on-call", "aml_t0024_correlation_record linking cost spike events to bulk inference volume patterns consistent with model extraction detection" ], "evidence": [ { "id": "BH-07-E1", "description": "cost_telemetry_pipeline_record showing CostEvent emission per request with caller_id, model_id, input_tokens, output_tokens, and cost_usd_estimated fields", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-07-E2", "description": "anomaly_detection_configuration_record showing baseline computation method (Z-score or EWMA), threshold multipliers, and evaluation window duration per caller and model", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "BH-07-E3", "description": "budget_guardrail_configuration_record showing per-caller monthly spend cap, queue-activation threshold percentage, and hard-stop cap percentage for each active caller", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-07-E4", "description": "cost_spike_alert_log for any triggered alerts showing caller_id, time_window, observed_cost, baseline_cost, and anomaly_score with routing confirmation to MLOps on-call", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "BH-07-E5", "description": "aml_t0024_correlation_record linking cost spike events to bulk inference volume patterns consistent with model extraction detection", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "adjacent", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 55(1)(d) requires systemic GPAI providers to ensure adequate cybersecurity; BH-07's resource anomaly detection \u2014 monitoring GPU utilization, memory consumption, and inference latency for anomalies \u2014 provides an adjacent signal for detecting infrastructure-level attacks and resource exhaustion patterns that may indicate cybersecurity incidents." } ] }, { "requirement_id": "EU-AIA-ART21-01", "section": "Art. 21(1)", "title": "Serious incident reporting \u2014 obligation to report to authorities", "text": "Providers of high-risk AI systems placed on the market of the Union shall report any serious incident to the market surveillance authorities of the Member States where that incident occurred.", "verdict": "supported", "coverage": "direct", "notes": "CR-04 (AI Incident Response Management) is the primary incident management control \u2014 it defines severity classification (including the 'serious incident' threshold under Art. 3(49)), investigation procedures, and documented escalation paths. CR-05 (Regulatory Notification and Statutory Reporting) governs the regulatory reporting obligation triggered by serious incidents, including authority identification, timeline compliance, and report content requirements. AG-05 (Agent Incident Response Program) extends this to agentic AI systems. CG-06 (Compliance Incident Response) ensures organizational compliance with the reporting obligation at the governance level.", "control_count": 4, "proof_chain": [ { "control": "apeiris://model/controls/CR-04", "id": "CR-04", "domain": "model", "name": "AI Incident Response Management", "validation_objective": "The organization must have a documented, version-controlled AI Incident Response Plan (AIRP) with AI-specific containment playbooks covering model rollback, output-filter enforcement, traffic shaping, and full model shutdown \u2014 tested via at least four quarterly tabletop exercises per year using MITRE ATLAS adversarial scenarios \u2014 and P1/P2 post-incident review records produced within 5 days of event resolution for all qualifying events in the trailing 12 months.", "blocking_effect": "blocks-deployment", "evidence_required": [ "AI Incident Response Plan document (version-controlled, CISO or AI-risk-owner signed, with review date within 12 months)", "Containment playbook index listing separate runbooks for model_rollback, output_filter_enforcement, traffic_shaping, and model_shutdown_with_fallback", "Last 4 quarterly tabletop exercise reports with MITRE ATLAS scenario identifier, participant roster, outcomes, and reviewer sign-off", "P1 and P2 post-incident review records for all qualifying events in the trailing 12 months, each showing post_incident_report_date within 5 days of incident_resolved_date", "EU Art. 73 notification trigger mapping document showing which P1 severity criteria trigger the Art. 73 serious-incident notification obligation (15d general / 10d death / 2d widespread or critical infrastructure)" ], "evidence": [ { "id": "CR-04-E1", "description": "AI Incident Response Plan document (version-controlled, CISO or AI-risk-owner signed, with review date within 12 months)", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-04-E2", "description": "Containment playbook index listing separate runbooks for model_rollback, output_filter_enforcement, traffic_shaping, and model_shutdown_with_fallback", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-04-E3", "description": "Last 4 quarterly tabletop exercise reports with MITRE ATLAS scenario identifier, participant roster, outcomes, and reviewer sign-off", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CR-04-E4", "description": "P1 and P2 post-incident review records for all qualifying events in the trailing 12 months, each showing post_incident_report_date within 5 days of incident_resolved_date", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-04-E5", "description": "EU Art. 73 notification trigger mapping document showing which P1 severity criteria trigger the Art. 73 serious-incident notification obligation (15d general / 10d death / 2d widespread or critical infrastructure)", "evidence_type": "incident-record", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 73 requires providers of high-risk AI systems to report serious incidents to national market surveillance authorities without undue delay; CR-04's model-specific incident response management \u2014 including P1/P2/P3 severity classification, mean-time-to-respond SLAs, and structured incident post-mortems \u2014 supports the incident triage and escalation processes required upstream of regulatory notification." }, { "control": "apeiris://model/controls/CR-05", "id": "CR-05", "domain": "model", "name": "Regulatory Notification and Statutory Reporting", "validation_objective": "The organization must maintain a current, legal-counsel-reviewed regulatory notification matrix mapping P1 severity incident events to all applicable jurisdictions, notification timelines (EU Art. 73: \u226415 calendar days for serious incidents; SR 26-2: immediate for material events), designated liaison and backup contacts, and pre-approved notification templates \u2014 with an automated countdown timer creation integrated into the CR-04 P1 escalation workflow and a complete archive of all notification submissions and delivery confirmations in CR-02.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Regulatory notification matrix document (version-controlled, legal-counsel reviewed within 12 months) listing jurisdiction, authority, trigger_event, timeline_days, liaison_contact, backup_contact, and template_ref for each row", "Pre-approved notification templates for each regulatory authority and jurisdiction, with legal counsel review date and version on record", "Notification task creation records showing automated countdown timers initiated for each P1 incident meeting notification criteria, with regulatory liaison page confirmation and timer expiry date", "All notification submissions and delivery confirmations archived in CR-02 with artifact_hash for the trailing 36 months", "Legal counsel sign-off record confirming annual review of all notification triggers and timelines, dated within 12 months" ], "evidence": [ { "id": "CR-05-E1", "description": "Regulatory notification matrix document (version-controlled, legal-counsel reviewed within 12 months) listing jurisdiction, authority, trigger_event, timeline_days, liaison_contact, backup_contact, and template_ref for each row", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CR-05-E2", "description": "Pre-approved notification templates for each regulatory authority and jurisdiction, with legal counsel review date and version on record", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CR-05-E3", "description": "Notification task creation records showing automated countdown timers initiated for each P1 incident meeting notification criteria, with regulatory liaison page confirmation and timer expiry date", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-05-E4", "description": "All notification submissions and delivery confirmations archived in CR-02 with artifact_hash for the trailing 36 months", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-05-E5", "description": "Legal counsel sign-off record confirming annual review of all notification triggers and timelines, dated within 12 months", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 72 requires post-market monitoring to cover systematic collection and analysis of user feedback and actual model performance outcomes; CR-05's outcomes and disparate impact analysis \u2014 comparing actual decisions against predicted outcomes and testing for differential impact across demographic cohorts \u2014 directly implements the outcome analysis component of post-market monitoring." }, { "control": "apeiris://agentic/controls/AG-05", "id": "AG-05", "domain": "agentic", "name": "Agent Incident Response Program", "validation_objective": "The enterprise has a documented, tested AI Incident Response Playbook with AI-specific containment capabilities, and every production agent has an authenticated kill-switch that demonstrably suspends its operation within 60 seconds of an authorized responder request.", "blocking_effect": "requires-review", "evidence_required": [ "AI Incident Response Playbook document covering incident classification taxonomy, severity tiers with quantitative criteria, containment actions per incident type, escalation matrix, and regulatory notification timelines", "Kill-switch capability validation records for each production agent, confirming suspension within the 60-second SLA in the most recent test", "Tabletop or functional test records for the AI Incident Response Playbook covering at least P1 and P2 severity scenarios", "Post-incident review records for all P1 and P2 events including root cause, containment timeline, and lessons-learned pipeline submissions" ], "evidence": [ { "id": "AG-05-E1", "description": "AI Incident Response Playbook document covering incident classification taxonomy, severity tiers with quantitative criteria, containment actions per incident type, escalation matrix, and regulatory notification timelines", "evidence_type": "incident-record", "verification": "attested" }, { "id": "AG-05-E2", "description": "Kill-switch capability validation records for each production agent, confirming suspension within the 60-second SLA in the most recent test", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "AG-05-E3", "description": "Tabletop or functional test records for the AI Incident Response Playbook covering at least P1 and P2 severity scenarios", "evidence_type": "incident-record", "verification": "attested" }, { "id": "AG-05-E4", "description": "Post-incident review records for all P1 and P2 events including root cause, containment timeline, and lessons-learned pipeline submissions", "evidence_type": "incident-record", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 73 requires providers and deployers to report serious incidents to national competent authorities within defined timeframes. An AI incident response program with regulatory notification procedures and defined reporting timelines directly addresses this mandatory serious incident reporting obligation." }, { "control": "apeiris://compliance/controls/CG-06", "id": "CG-06", "domain": "compliance", "name": "Compliance Incident Response", "validation_objective": "A documented Compliance Incident Response Playbook exists covering at least four AI-specific incident scenario types (discriminatory AI output, unauthorized AI data processing, regulatory inquiry, enforcement action), defines severity levels P1-P4 with named role assignments and notification timelines specific to each applicable regulatory framework (GDPR 72h, EU AI Act Article 73), and has been exercised in a tabletop simulation of an AI compliance scenario within the last 18 months with documented lessons-learned outcomes.", "blocking_effect": "requires-review", "evidence_required": [ "compliance_incident_response_playbook document containing ai_incident_scenario_list (minimum four types), severity_level_definitions (P1-P4) with escalation_paths, regulatory_notification_timeline_matrix per framework with specific SLAs, named_role_assignments for Incident Commander/Legal Lead/Technical Lead, and containment_action_steps", "tabletop_exercise_record dated within the last 18 months documenting scenario_type (must be AI compliance scenario), participants by named role, findings, and lessons_learned items with remediation_action_owner and completion_status", "notification_template_set for each applicable regulatory authority with legal_counsel_review_date within the last 12 months confirming language is current and jurisdiction-appropriate", "incident_response_log for any compliance incidents in the last 24 months showing incident_id, severity_level, trigger_timestamp, notification_sent_timestamp, regulatory_authority_notified, and SLA_compliance status for each framework-governed notification" ], "evidence": [ { "id": "CG-06-E1", "description": "compliance_incident_response_playbook document containing ai_incident_scenario_list (minimum four types), severity_level_definitions (P1-P4) with escalation_paths, regulatory_notification_timeline_matrix per framework with specific SLAs, named_role_assignments for Incident Commander/Legal Lead/Technical Lead, and containment_action_steps", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CG-06-E2", "description": "tabletop_exercise_record dated within the last 18 months documenting scenario_type (must be AI compliance scenario), participants by named role, findings, and lessons_learned items with remediation_action_owner and completion_status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-06-E3", "description": "notification_template_set for each applicable regulatory authority with legal_counsel_review_date within the last 12 months confirming language is current and jurisdiction-appropriate", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-06-E4", "description": "incident_response_log for any compliance incidents in the last 24 months showing incident_id, severity_level, trigger_timestamp, notification_sent_timestamp, regulatory_authority_notified, and SLA_compliance status for each framework-governed notification", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 73 requires providers of high-risk AI systems to report serious incidents to the market surveillance authorities within defined timelines \u2014 no later than 15 days after awareness, 2 days for widespread infringement or a serious incident involving critical infrastructure, and 10 days in the event of the death of a person \u2014 building on the post-market monitoring required by Article 72. Compliance incident response procedures must address these AI-specific notification obligations." } ] }, { "requirement_id": "EU-AIA-ART25-02", "section": "Art. 25(2)", "title": "Value chain obligations \u2014 deployer obligations for high-risk AI", "text": "Deployers of high-risk AI systems shall: use systems in accordance with instructions for use; assign human oversight to natural persons with competence; take appropriate measures to monitor AI systems; notify providers of serious incidents; inform workers' representatives and affected workers.", "verdict": "supported", "coverage": "direct", "notes": "OA-01 (Model Ownership Assignment) and PA-04 (Principal Accountability Binding) establish named accountable persons with competency requirements, satisfying the human oversight assignment obligation. CA-07 (Third-Party and Supply Chain Compliance Obligations) manages the deployer's compliance obligations toward the provider. OA-02 (Meaningful Human Oversight for High-Stakes Decisions) provides the monitoring framework. CR-04 and CR-05 (via the provider domain) cover serious incident notification back to providers and authorities.", "control_count": 4, "proof_chain": [ { "control": "apeiris://model/controls/OA-01", "id": "OA-01", "domain": "model", "name": "Model Ownership Assignment", "validation_objective": "Every AI model in the production model registry must have a non-null named human owner who is a current employee, a responsible team, and an executive sponsor at director level or above for high-impact models, all recorded within five business days of deployment. No production model may exist without a current ownership record, and ownership must be reassigned within ten business days of any owner departure.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_ownership_register_extract with fields: model_id, owner_name, owner_employee_id, team, executive_sponsor, effective_date, review_date \u2014 showing 100% coverage of production models with non-null values", "deployment_pipeline_gate_log showing blocked promotion events for models with null ownership fields, with timestamps and model IDs", "hr_departure_event_log cross-referenced with ownership_reassignment_record demonstrating reassignment within ten business days for each departure", "governance_committee_meeting_minutes containing ownership review agenda items for the preceding 12-month period" ], "evidence": [ { "id": "OA-01-E1", "description": "model_ownership_register_extract with fields: model_id, owner_name, owner_employee_id, team, executive_sponsor, effective_date, review_date \u2014 showing 100% coverage of production models with non-null values", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-01-E2", "description": "deployment_pipeline_gate_log showing blocked promotion events for models with null ownership fields, with timestamps and model IDs", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-01-E3", "description": "hr_departure_event_log cross-referenced with ownership_reassignment_record demonstrating reassignment within ten business days for each departure", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-01-E4", "description": "governance_committee_meeting_minutes containing ownership review agenda items for the preceding 12-month period", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "Art-17 requires providers of high-risk AI systems to operate a quality management system that includes an accountability framework setting out the responsibilities of management and other staff (Art. 17(1)(m)); Art. 16(c) obliges providers to have such a QMS in place. OA-01's named-owner register implements the accountability component." }, { "control": "apeiris://authority/controls/PA-04", "id": "PA-04", "domain": "authority", "name": "Principal Accountability Binding", "validation_objective": "Every consequential AI action must produce an immutable accountability binding artifact atomically with the action, containing the action_id, agent_id, principal_id, delegation_basis_id, action_scope, and an integrity hash sealing the record. The artifact must be written to a tamper-evident, append-only store from which neither the AI agent nor its service account can modify or delete entries.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "accountability_binding_artifact for each consequential AI action, containing action_id, agent_id, principal_id, delegation_basis_id, action_scope, action_timestamp, and integrity_hash (sha256) \u2014 all fields must be non-null", "tamper_evident_store_audit_record confirming the binding store is append-only and that no modification or deletion events occurred for any binding artifact during the audit period", "principal_existence_validation_record confirming the principal_id referenced in each binding artifact resolves to a current, active human identity in the enterprise identity system at the time of binding", "binding_completeness_scan result confirming 100% of consequential AI actions in the audit period have a corresponding accountability binding artifact with no gaps" ], "evidence": [ { "id": "PA-04-E1", "description": "accountability_binding_artifact for each consequential AI action, containing action_id, agent_id, principal_id, delegation_basis_id, action_scope, action_timestamp, and integrity_hash (sha256) \u2014 all fields must be non-null", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PA-04-E2", "description": "tamper_evident_store_audit_record confirming the binding store is append-only and that no modification or deletion events occurred for any binding artifact during the audit period", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PA-04-E3", "description": "principal_existence_validation_record confirming the principal_id referenced in each binding artifact resolves to a current, active human identity in the enterprise identity system at the time of binding", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PA-04-E4", "description": "binding_completeness_scan result confirming 100% of consequential AI actions in the audit period have a corresponding accountability binding artifact with no gaps", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "Binding actions to accountable natural persons implements part of Art. 26 deployer human-oversight obligations." }, { "control": "apeiris://compliance/controls/CA-07", "id": "CA-07", "domain": "compliance", "name": "Third-Party and Supply Chain Compliance Obligations", "validation_objective": "Every supply chain participant for each AI system in scope must have an entry in the third-party compliance obligation register documenting all flowing obligations and a corresponding executed binding contractual instrument containing audit rights, with third-party compliance attestations collected within the defined refresh cycle and incorporated into the CA-03 routing table as evidence inputs.", "blocking_effect": "blocks-deployment", "evidence_required": [ "third_party_compliance_obligation_register entries for each supply chain participant containing vendor_id, vendor_role, applicable_obligations[], contract_instrument_id, contract_execution_date, and next_attestation_due_date", "executed_contract_inventory for each supply chain participant showing contract_type (DPA, EU_AI_Act_compliance_schedule, supplier_agreement), execution_date, audit_rights_clause_present=true, and sub_processor_management_clause_present=true for data processors", "third_party_attestation_collection_log showing each attestation collected with collection_date, valid_until, attesting_entity_name, attestation_scope, and the CA-03 routing_table_entry_id that references it", "service_dependency_map for each AI system listing all integrated third-party APIs, model providers, and data services cross-referenced against the obligation register to confirm no vendor is absent from the register" ], "evidence": [ { "id": "CA-07-E1", "description": "third_party_compliance_obligation_register entries for each supply chain participant containing vendor_id, vendor_role, applicable_obligations[], contract_instrument_id, contract_execution_date, and next_attestation_due_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-07-E2", "description": "executed_contract_inventory for each supply chain participant showing contract_type (DPA, EU_AI_Act_compliance_schedule, supplier_agreement), execution_date, audit_rights_clause_present=true, and sub_processor_management_clause_present=true for data processors", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-07-E3", "description": "third_party_attestation_collection_log showing each attestation collected with collection_date, valid_until, attesting_entity_name, attestation_scope, and the CA-03 routing_table_entry_id that references it", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-07-E4", "description": "service_dependency_map for each AI system listing all integrated third-party APIs, model providers, and data services cross-referenced against the obligation register to confirm no vendor is absent from the register", "evidence_type": "third-party-audit-report", "verification": "third-party" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Articles 23, 24 and 26 establish obligations for importers, distributors and deployers of high-risk AI systems, including verification obligations that flow up the supply chain to providers, and Article 25 allocates responsibilities along the AI value chain \u2014 including written agreements with third-party suppliers of components integrated into high-risk AI systems. CA-07's third-party obligation register and contractual coverage mechanism ensures these value-chain obligations are identified and imposed on the appropriate supply chain participants. Failure to impose these obligations contractually leaves the organization as the residual obligor for non-compliance by downstream parties." }, { "control": "apeiris://model/controls/OA-02", "id": "OA-02", "domain": "model", "name": "Meaningful Human Oversight for High-Stakes Decisions", "validation_objective": "For every high-impact-decision or eu-high-risk model, a human reviewer must have documented access to model inputs, confidence scores, and reasoning; organizational authority to override without penalty; domain competence verified through training records; and a technically effective override mechanism before any AI output takes effect. Override rates must be monitored and a rate near zero for 30 consecutive days must automatically trigger a governance review.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "five_factor_oversight_design_document per high-stakes use case, signed by the AI governance committee, covering: review time allocation, information display design, override authority documentation, competence requirements, and override mechanism technical specification", "override_rate_time_series report for the past 12 months broken down by model, decision type, and reviewer cohort \u2014 with governance-defined floor thresholds annotated", "reviewer_training_completion_record including initial onboarding completion date, annual recertification dates, competence assessment scores, and automation-bias module completion", "override_mechanism_test_log confirming that override actions propagate correctly through downstream systems without requiring secondary approval" ], "evidence": [ { "id": "OA-02-E1", "description": "five_factor_oversight_design_document per high-stakes use case, signed by the AI governance committee, covering: review time allocation, information display design, override authority documentation, competence requirements, and override mechanism technical specification", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-02-E2", "description": "override_rate_time_series report for the past 12 months broken down by model, decision type, and reviewer cohort \u2014 with governance-defined floor thresholds annotated", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-02-E3", "description": "reviewer_training_completion_record including initial onboarding completion date, annual recertification dates, competence assessment scores, and automation-bias module completion", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-02-E4", "description": "override_mechanism_test_log confirming that override actions propagate correctly through downstream systems without requiring secondary approval", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "Art-14 mandates human oversight design for high-risk AI. The five-factor framework operationalizes Art-14(3) requirements." } ] }, { "requirement_id": "EU-AIA-ART25-03", "section": "Art. 25(3)", "title": "Value chain obligations \u2014 substantial modification obligations", "text": "Any provider who places on the market or puts into service a high-risk AI system that has been substantially modified by a third party, or who substantially modifies a high-risk AI system for their own use, shall be considered a provider and shall comply with all provider obligations.", "verdict": "partial", "coverage": "partial", "notes": "LI-09 (Material-Change Determination and Authorization Gate) detects substantial modifications and triggers the appropriate regulatory pathway. RF-02 (EU AI Act Conformity Assessment Pathway Selection) governs the provider obligation triggered by substantial modification. OA-05 (Regulatory and Legal Review Sign-Off) ensures legal determination of provider status is formally made. CA-07 maps the full chain of provider obligations triggered. Partial: the legal determination of who becomes a 'provider' in complex distribution chains, and the transfer of documentation and obligations along the supply chain, involves legal and contractual dimensions beyond technical controls.", "control_count": 4, "proof_chain": [ { "control": "apeiris://model/controls/LI-09", "id": "LI-09", "domain": "model", "name": "Material-Change Determination and Authorization Gate", "validation_objective": "Every planned change to a deployed AI model or its operating environment is assessed against a documented materiality threshold; changes that meet or exceed the threshold must complete a full re-evaluation and authorization cycle before the updated system goes live, and no material change may bypass this gate.", "blocking_effect": "blocks-deployment", "evidence_required": [ "change_assessment_record documenting the change type (model update, prompt change, RAG corpus change, guardrail change, provider-version change), the materiality determination (material/non-material), and the criteria applied", "re_evaluation_authorization_record for each material change showing completed evaluation cycle, approver identity, approval timestamp, and the specific evaluation artifacts reviewed", "deployment_gate_block_log confirming that attempted deployments of material changes without a completed authorization record were rejected by the pipeline", "change_classification_policy_document defining materiality thresholds for each change type, reviewed and signed by model governance and risk owners" ], "evidence": [ { "id": "LI-09-E1", "description": "change_assessment_record documenting the change type (model update, prompt change, RAG corpus change, guardrail change, provider-version change), the materiality determination (material/non-material), and the criteria applied", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-09-E2", "description": "re_evaluation_authorization_record for each material change showing completed evaluation cycle, approver identity, approval timestamp, and the specific evaluation artifacts reviewed", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "LI-09-E3", "description": "deployment_gate_block_log confirming that attempted deployments of material changes without a completed authorization record were rejected by the pipeline", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-09-E4", "description": "change_classification_policy_document defining materiality thresholds for each change type, reviewed and signed by model governance and risk owners", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art-9 requires that the risk management system for high-risk AI systems be ongoing and iterative, covering the full system lifecycle including modifications. LI-09 directly supports Art-9 by providing the operational mechanism for evaluating whether modifications to the AI system require a new risk assessment cycle. Art-9(9) specifically addresses risk management for AI system modifications." }, { "control": "apeiris://compliance/controls/RF-02", "id": "RF-02", "domain": "compliance", "name": "EU AI Act Conformity Assessment Pathway Selection", "validation_objective": "Every high-risk AI system in the classification register must have a conformity assessment pathway record specifying the Art. 43 legal basis for pathway selection, a named assessment owner, legal counsel sign-off, and a projected assessment timeline. For systems on the third-party pathway, notified body engagement evidence must show initiation at least 6 months before the projected market placement date. No high-risk system may reach market placement without a completed and legally signed pathway record.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Conformity pathway register export with system_id, pathway_type (internal/third-party), art_43_basis, assessment_owner, legal_sign_off_date, and projected_placement_date for each high-risk system", "Legal pathway selection opinion for each high-risk system citing the specific Art. 43 sub-clause and confirming the pathway type is legally permissible for the applicable Annex III category", "Notified body engagement records with engagement_initiation_date, notified_body_id, and projected assessment completion date for all third-party pathway systems", "CI/CD pipeline gate enforcement log confirming deployment was blocked for high-risk AI system images without a valid pathway record identifier in the release metadata", "Conformity pathway version history with change log linking each pathway record revision to the CE declaration version it supports" ], "evidence": [ { "id": "RF-02-E1", "description": "Conformity pathway register export with system_id, pathway_type (internal/third-party), art_43_basis, assessment_owner, legal_sign_off_date, and projected_placement_date for each high-risk system", "evidence_type": "third-party-audit-report", "verification": "third-party" }, { "id": "RF-02-E2", "description": "Legal pathway selection opinion for each high-risk system citing the specific Art. 43 sub-clause and confirming the pathway type is legally permissible for the applicable Annex III category", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RF-02-E3", "description": "Notified body engagement records with engagement_initiation_date, notified_body_id, and projected assessment completion date for all third-party pathway systems", "evidence_type": "third-party-audit-report", "verification": "third-party" }, { "id": "RF-02-E4", "description": "CI/CD pipeline gate enforcement log confirming deployment was blocked for high-risk AI system images without a valid pathway record identifier in the release metadata", "evidence_type": "audit-log", "verification": "automated" }, { "id": "RF-02-E5", "description": "Conformity pathway version history with change log linking each pathway record revision to the CE declaration version it supports", "evidence_type": "audit-log", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "Art. 43 is the primary operative provision governing conformity assessment pathway selection, distinguishing between systems that require notified body involvement and those eligible for internal assessment procedures. Compliance with this control is a mandatory prerequisite to lawful market placement of high-risk AI systems." }, { "control": "apeiris://model/controls/OA-05", "id": "OA-05", "domain": "model", "name": "Regulatory and Legal Review Sign-Off", "validation_objective": "Every AI model deployed in a regulated use case must have a documented legal sign-off record from compliance counsel before production promotion, specifying applicable regulations, compliance posture assessment, documentation status, and accepted residual legal risks. EU high-risk AI systems must have a completed conformity assessment and a current EU Declaration of Conformity. Sign-off records must be retained for the model's operational life plus seven years.", "blocking_effect": "blocks-deployment", "evidence_required": [ "legal_signoff_record for each regulated-use model deployment, including: counsel name, date, applicable regulations identified, compliance posture assessment, documentation status, and accepted residual legal risks \u2014 pre-dating the production deployment timestamp", "eu_declaration_of_conformity for each model classified as eu-high-risk, with conformity assessment completion date, notified body reference if applicable, and model version scope", "sr_26_2_validation_report for each US-regulated banking model, reviewed and approved by the independent model risk function prior to deployment", "regulatory_applicability_matrix current version maintained by the compliance function, showing which regulations apply to each model classification" ], "evidence": [ { "id": "OA-05-E1", "description": "legal_signoff_record for each regulated-use model deployment, including: counsel name, date, applicable regulations identified, compliance posture assessment, documentation status, and accepted residual legal risks \u2014 pre-dating the production deployment timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-05-E2", "description": "eu_declaration_of_conformity for each model classified as eu-high-risk, with conformity assessment completion date, notified body reference if applicable, and model version scope", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-05-E3", "description": "sr_26_2_validation_report for each US-regulated banking model, reviewed and approved by the independent model risk function prior to deployment", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-05-E4", "description": "regulatory_applicability_matrix current version maintained by the compliance function, showing which regulations apply to each model classification", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "Art-43 requires conformity assessment; Art-47 requires EU Declaration of Conformity for high-risk AI before market placement." }, { "control": "apeiris://compliance/controls/CA-07", "id": "CA-07", "domain": "compliance", "name": "Third-Party and Supply Chain Compliance Obligations", "validation_objective": "Every supply chain participant for each AI system in scope must have an entry in the third-party compliance obligation register documenting all flowing obligations and a corresponding executed binding contractual instrument containing audit rights, with third-party compliance attestations collected within the defined refresh cycle and incorporated into the CA-03 routing table as evidence inputs.", "blocking_effect": "blocks-deployment", "evidence_required": [ "third_party_compliance_obligation_register entries for each supply chain participant containing vendor_id, vendor_role, applicable_obligations[], contract_instrument_id, contract_execution_date, and next_attestation_due_date", "executed_contract_inventory for each supply chain participant showing contract_type (DPA, EU_AI_Act_compliance_schedule, supplier_agreement), execution_date, audit_rights_clause_present=true, and sub_processor_management_clause_present=true for data processors", "third_party_attestation_collection_log showing each attestation collected with collection_date, valid_until, attesting_entity_name, attestation_scope, and the CA-03 routing_table_entry_id that references it", "service_dependency_map for each AI system listing all integrated third-party APIs, model providers, and data services cross-referenced against the obligation register to confirm no vendor is absent from the register" ], "evidence": [ { "id": "CA-07-E1", "description": "third_party_compliance_obligation_register entries for each supply chain participant containing vendor_id, vendor_role, applicable_obligations[], contract_instrument_id, contract_execution_date, and next_attestation_due_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-07-E2", "description": "executed_contract_inventory for each supply chain participant showing contract_type (DPA, EU_AI_Act_compliance_schedule, supplier_agreement), execution_date, audit_rights_clause_present=true, and sub_processor_management_clause_present=true for data processors", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-07-E3", "description": "third_party_attestation_collection_log showing each attestation collected with collection_date, valid_until, attesting_entity_name, attestation_scope, and the CA-03 routing_table_entry_id that references it", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-07-E4", "description": "service_dependency_map for each AI system listing all integrated third-party APIs, model providers, and data services cross-referenced against the obligation register to confirm no vendor is absent from the register", "evidence_type": "third-party-audit-report", "verification": "third-party" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Articles 23, 24 and 26 establish obligations for importers, distributors and deployers of high-risk AI systems, including verification obligations that flow up the supply chain to providers, and Article 25 allocates responsibilities along the AI value chain \u2014 including written agreements with third-party suppliers of components integrated into high-risk AI systems. CA-07's third-party obligation register and contractual coverage mechanism ensures these value-chain obligations are identified and imposed on the appropriate supply chain participants. Failure to impose these obligations contractually leaves the organization as the residual obligor for non-compliance by downstream parties." } ] }, { "requirement_id": "EU-AIA-ART50-01", "section": "Art. 50(1)", "title": "Transparency \u2014 notification that users interact with AI", "text": "Providers shall ensure that AI systems intended to interact directly with natural persons are designed and developed in such a way that the natural persons concerned are informed that they are interacting with an AI system.", "verdict": "supported", "coverage": "direct", "notes": "XP-05 (Model Card and System Card Transparency Disclosure) requires disclosure of AI nature as a mandatory transparency element. GV-07 (Protect humans from being deceived by an agent) specifically prohibits design patterns that conceal an AI system's nature \u2014 directly implementing Art. 50(1)'s anti-deception requirement. BH-09 (Synthetic-Content Provenance, Disclosure and Traceability) extends this to AI-generated content disclosure. HI-06 (Consent and Agency Preservation for AI Interactions) requires that users have clear, informed understanding of the nature of their interaction before commencing.", "control_count": 4, "proof_chain": [ { "control": "apeiris://ethics/controls/XP-05", "id": "XP-05", "domain": "ethics", "name": "Model Card and System Card Transparency Disclosure", "validation_objective": "Every AI system deployed in a high-stakes or public-facing context has a current published model card or system card that accurately represents the system's capabilities, limitations, intended use, known failure modes, and fairness evaluation results; cards are version-controlled and updated when the system undergoes material changes; and no high-stakes AI system is in production without a current card accessible to deployers and affected stakeholders.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_card_or_system_card document per AI system with required fields: system_id, model_version, intended_use, out_of_scope_uses, known_limitations, failure_modes, fairness_evaluation_results (metric name, value, demographic group, evaluation_date), and last_updated_date", "model_card_version_history log showing card updates aligned to model changes with delta description for each version", "card_publication_record confirming the card is accessible at a documented public or deployer-accessible URL before the system was deployed", "material_change_review_log showing that each model retraining, feature change, or scope expansion triggered a card update review with decision to update or document rationale for no-update" ], "evidence": [ { "id": "XP-05-E1", "description": "model_card_or_system_card document per AI system with required fields: system_id, model_version, intended_use, out_of_scope_uses, known_limitations, failure_modes, fairness_evaluation_results (metric name, value, demographic group, evaluation_date), and last_updated_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "XP-05-E2", "description": "model_card_version_history log showing card updates aligned to model changes with delta description for each version", "evidence_type": "audit-log", "verification": "automated" }, { "id": "XP-05-E3", "description": "card_publication_record confirming the card is accessible at a documented public or deployer-accessible URL before the system was deployed", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "XP-05-E4", "description": "material_change_review_log showing that each model retraining, feature change, or scope expansion triggered a card update review with decision to update or document rationale for no-update", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 11 and Annex IV require high-risk AI providers to maintain comprehensive technical documentation including system description, design choices, performance metrics, and known limitations. Model cards directly instantiate this requirement in a standardized, reviewable format." }, { "control": "apeiris://security/controls/GV-07", "id": "GV-07", "domain": "security", "name": "Protect humans from being deceived by an agent", "validation_objective": "All agent-generated content shown to human approvers or end users is clearly labeled as AI-generated and includes independent, system-sourced facts about the action being approved; the approval channel cryptographically prevents agent impersonation of named individuals; and no agent can manufacture an on-behalf-of claim without an out-of-band verification step.", "blocking_effect": "requires-review", "evidence_required": [ "approval_ui_design_artifact showing the agent-output label and an independent fact panel (resource identifiers, current auth scope, prior action history) displayed alongside any agent-provided summary", "impersonation_block_log recording instances where an agent attempted to assert a named human identity or forge an on-behalf-of header, and the system's rejection response", "channel_integrity_configuration showing the approval workflow is delivered over a path the agent cannot write to, inject into, or intercept", "user_disclosure_audit confirming AI-disclosure notices are rendered at every interaction surface where an end user may encounter agent-generated content", "red_team_exercise_report testing social-engineering and impersonation paths through the agent, with findings and remediation status" ], "evidence": [ { "id": "GV-07-E1", "description": "approval_ui_design_artifact showing the agent-output label and an independent fact panel (resource identifiers, current auth scope, prior action history) displayed alongside any agent-provided summary", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-07-E2", "description": "impersonation_block_log recording instances where an agent attempted to assert a named human identity or forge an on-behalf-of header, and the system's rejection response", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "GV-07-E3", "description": "channel_integrity_configuration showing the approval workflow is delivered over a path the agent cannot write to, inject into, or intercept", "evidence_type": "human-review-record", "verification": "human" }, { "id": "GV-07-E4", "description": "user_disclosure_audit confirming AI-disclosure notices are rendered at every interaction surface where an end user may encounter agent-generated content", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-07-E5", "description": "red_team_exercise_report testing social-engineering and impersonation paths through the agent, with findings and remediation status", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://model/controls/BH-09", "id": "BH-09", "domain": "model", "name": "Synthetic-Content Provenance, Disclosure and Traceability", "validation_objective": "Every AI-generated content artifact must carry verifiable cryptographic provenance metadata linking it to the generating model version, include a mandatory disclosure label visible to recipients, and be resolvable through a complete traceability chain from generation event to content delivery with no gaps in the provenance record.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "content_provenance_record per generated artifact showing model_version_id, generation_timestamp, content_hash, and cryptographic signature (C2PA manifest or equivalent) attached at generation time", "disclosure_label_audit_log confirming that AI-generated disclosure labels were applied and rendered for each content delivery event, with delivery_channel and recipient_context recorded", "traceability_chain_record linking content_id to generation_event_id, model_version_id, and serving_endpoint_id for each production output", "provenance_metadata_schema_validation_report confirming all required provenance fields are present and signature validity checks pass across a sampled period", "regulatory_disclosure_mapping_record showing how disclosure label format and placement satisfies jurisdiction-specific requirements (EU AI Act Art. 50 and equivalent)" ], "evidence": [ { "id": "BH-09-E1", "description": "content_provenance_record per generated artifact showing model_version_id, generation_timestamp, content_hash, and cryptographic signature (C2PA manifest or equivalent) attached at generation time", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "BH-09-E2", "description": "disclosure_label_audit_log confirming that AI-generated disclosure labels were applied and rendered for each content delivery event, with delivery_channel and recipient_context recorded", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-09-E3", "description": "traceability_chain_record linking content_id to generation_event_id, model_version_id, and serving_endpoint_id for each production output", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-09-E4", "description": "provenance_metadata_schema_validation_report confirming all required provenance fields are present and signature validity checks pass across a sampled period", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "BH-09-E5", "description": "regulatory_disclosure_mapping_record showing how disclosure label format and placement satisfies jurisdiction-specific requirements (EU AI Act Art. 50 and equivalent)", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 50 requires providers of AI systems that generate synthetic audio, image, video or text content to ensure outputs are marked in a machine-readable format and detectable as artificially generated; BH-09's synthetic content provenance framework \u2014 using C2PA manifest attachment, cryptographic signing, and automated provenance-token injection \u2014 directly implements this transparency obligation. Art. 50(2) specifically applies to GPAI models generating synthetic images, audio, or video." }, { "control": "apeiris://ethics/controls/HI-06", "id": "HI-06", "domain": "ethics", "name": "Consent and Agency Preservation for AI Interactions", "validation_objective": "All AI-mediated interactions must be preceded by plain-language disclosure of the AI's nature, capability category, data use, and consequential outputs; consent records must be version-tagged to the capability state at the time of consent; and users must be able to exit or modify AI interactions without experiencing service penalties. A passing state requires 100% of active user consent records carrying a capability_version_tag and 100% of material capability changes having a documented consent refresh assessment.", "blocking_effect": "requires-review", "evidence_required": [ "consent_record_export with fields for user_id, consent_timestamp, capability_version_tag, consent_granularity_tier, and revocation_status for every consented user, with no records lacking a version tag", "disclosure_readability_assessment_report showing Flesch-Kincaid reading ease score at or above 60 for all pre-interaction disclosure content, assessed after each material capability update", "capability_change_governance_log listing each AI capability release, its materiality determination (material or non-material), the assessment rationale, and the consent refresh decision and notification record where triggered", "agency_preservation_test_report documenting opt-out flow testing with screen-recorded evidence that users can exit AI-mediated interactions without friction, penalty prompts, or service degradation" ], "evidence": [ { "id": "HI-06-E1", "description": "consent_record_export with fields for user_id, consent_timestamp, capability_version_tag, consent_granularity_tier, and revocation_status for every consented user, with no records lacking a version tag", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-06-E2", "description": "disclosure_readability_assessment_report showing Flesch-Kincaid reading ease score at or above 60 for all pre-interaction disclosure content, assessed after each material capability update", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-06-E3", "description": "capability_change_governance_log listing each AI capability release, its materiality determination (material or non-material), the assessment rationale, and the consent refresh decision and notification record where triggered", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-06-E4", "description": "agency_preservation_test_report documenting opt-out flow testing with screen-recorded evidence that users can exit AI-mediated interactions without friction, penalty prompts, or service degradation", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 50 mandates that AI systems interacting with humans disclose their AI nature and provides transparency obligations for certain AI-generated content. This control implements the disclosure and consent infrastructure required to meet these obligations." } ] }, { "requirement_id": "EU-AIA-ART50-02", "section": "Art. 50(2)", "title": "Transparency \u2014 deepfake and synthetic media notification", "text": "Providers of AI systems generating synthetic audio, image, video or text content shall ensure that the outputs of the AI system are marked in a machine-readable format and detectable as artificially generated or manipulated.", "verdict": "supported", "coverage": "direct", "notes": "BH-09 (Synthetic-Content Provenance, Disclosure and Traceability) is the primary control \u2014 it requires that all AI-generated content is marked with provenance metadata, source model identification, and generation timestamp, in a format compatible with C2PA or equivalent machine-readable marking standards. XP-05 provides the system-level disclosure framework. GV-07 enforces that deceptive presentation of synthetic content as genuine is prohibited.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/BH-09", "id": "BH-09", "domain": "model", "name": "Synthetic-Content Provenance, Disclosure and Traceability", "validation_objective": "Every AI-generated content artifact must carry verifiable cryptographic provenance metadata linking it to the generating model version, include a mandatory disclosure label visible to recipients, and be resolvable through a complete traceability chain from generation event to content delivery with no gaps in the provenance record.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "content_provenance_record per generated artifact showing model_version_id, generation_timestamp, content_hash, and cryptographic signature (C2PA manifest or equivalent) attached at generation time", "disclosure_label_audit_log confirming that AI-generated disclosure labels were applied and rendered for each content delivery event, with delivery_channel and recipient_context recorded", "traceability_chain_record linking content_id to generation_event_id, model_version_id, and serving_endpoint_id for each production output", "provenance_metadata_schema_validation_report confirming all required provenance fields are present and signature validity checks pass across a sampled period", "regulatory_disclosure_mapping_record showing how disclosure label format and placement satisfies jurisdiction-specific requirements (EU AI Act Art. 50 and equivalent)" ], "evidence": [ { "id": "BH-09-E1", "description": "content_provenance_record per generated artifact showing model_version_id, generation_timestamp, content_hash, and cryptographic signature (C2PA manifest or equivalent) attached at generation time", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "BH-09-E2", "description": "disclosure_label_audit_log confirming that AI-generated disclosure labels were applied and rendered for each content delivery event, with delivery_channel and recipient_context recorded", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-09-E3", "description": "traceability_chain_record linking content_id to generation_event_id, model_version_id, and serving_endpoint_id for each production output", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-09-E4", "description": "provenance_metadata_schema_validation_report confirming all required provenance fields are present and signature validity checks pass across a sampled period", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "BH-09-E5", "description": "regulatory_disclosure_mapping_record showing how disclosure label format and placement satisfies jurisdiction-specific requirements (EU AI Act Art. 50 and equivalent)", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 50 requires providers of AI systems that generate synthetic audio, image, video or text content to ensure outputs are marked in a machine-readable format and detectable as artificially generated; BH-09's synthetic content provenance framework \u2014 using C2PA manifest attachment, cryptographic signing, and automated provenance-token injection \u2014 directly implements this transparency obligation. Art. 50(2) specifically applies to GPAI models generating synthetic images, audio, or video." }, { "control": "apeiris://ethics/controls/XP-05", "id": "XP-05", "domain": "ethics", "name": "Model Card and System Card Transparency Disclosure", "validation_objective": "Every AI system deployed in a high-stakes or public-facing context has a current published model card or system card that accurately represents the system's capabilities, limitations, intended use, known failure modes, and fairness evaluation results; cards are version-controlled and updated when the system undergoes material changes; and no high-stakes AI system is in production without a current card accessible to deployers and affected stakeholders.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_card_or_system_card document per AI system with required fields: system_id, model_version, intended_use, out_of_scope_uses, known_limitations, failure_modes, fairness_evaluation_results (metric name, value, demographic group, evaluation_date), and last_updated_date", "model_card_version_history log showing card updates aligned to model changes with delta description for each version", "card_publication_record confirming the card is accessible at a documented public or deployer-accessible URL before the system was deployed", "material_change_review_log showing that each model retraining, feature change, or scope expansion triggered a card update review with decision to update or document rationale for no-update" ], "evidence": [ { "id": "XP-05-E1", "description": "model_card_or_system_card document per AI system with required fields: system_id, model_version, intended_use, out_of_scope_uses, known_limitations, failure_modes, fairness_evaluation_results (metric name, value, demographic group, evaluation_date), and last_updated_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "XP-05-E2", "description": "model_card_version_history log showing card updates aligned to model changes with delta description for each version", "evidence_type": "audit-log", "verification": "automated" }, { "id": "XP-05-E3", "description": "card_publication_record confirming the card is accessible at a documented public or deployer-accessible URL before the system was deployed", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "XP-05-E4", "description": "material_change_review_log showing that each model retraining, feature change, or scope expansion triggered a card update review with decision to update or document rationale for no-update", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 11 and Annex IV require high-risk AI providers to maintain comprehensive technical documentation including system description, design choices, performance metrics, and known limitations. Model cards directly instantiate this requirement in a standardized, reviewable format." }, { "control": "apeiris://security/controls/GV-07", "id": "GV-07", "domain": "security", "name": "Protect humans from being deceived by an agent", "validation_objective": "All agent-generated content shown to human approvers or end users is clearly labeled as AI-generated and includes independent, system-sourced facts about the action being approved; the approval channel cryptographically prevents agent impersonation of named individuals; and no agent can manufacture an on-behalf-of claim without an out-of-band verification step.", "blocking_effect": "requires-review", "evidence_required": [ "approval_ui_design_artifact showing the agent-output label and an independent fact panel (resource identifiers, current auth scope, prior action history) displayed alongside any agent-provided summary", "impersonation_block_log recording instances where an agent attempted to assert a named human identity or forge an on-behalf-of header, and the system's rejection response", "channel_integrity_configuration showing the approval workflow is delivered over a path the agent cannot write to, inject into, or intercept", "user_disclosure_audit confirming AI-disclosure notices are rendered at every interaction surface where an end user may encounter agent-generated content", "red_team_exercise_report testing social-engineering and impersonation paths through the agent, with findings and remediation status" ], "evidence": [ { "id": "GV-07-E1", "description": "approval_ui_design_artifact showing the agent-output label and an independent fact panel (resource identifiers, current auth scope, prior action history) displayed alongside any agent-provided summary", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-07-E2", "description": "impersonation_block_log recording instances where an agent attempted to assert a named human identity or forge an on-behalf-of header, and the system's rejection response", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "GV-07-E3", "description": "channel_integrity_configuration showing the approval workflow is delivered over a path the agent cannot write to, inject into, or intercept", "evidence_type": "human-review-record", "verification": "human" }, { "id": "GV-07-E4", "description": "user_disclosure_audit confirming AI-disclosure notices are rendered at every interaction surface where an end user may encounter agent-generated content", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-07-E5", "description": "red_team_exercise_report testing social-engineering and impersonation paths through the agent, with findings and remediation status", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "EU-AIA-ART50-03", "section": "Art. 50(3)", "title": "Transparency \u2014 AI-generated text disclosure for matters of public interest", "text": "Deployers of AI systems that generate or manipulate text that constitutes an AIGS publication on matters of public interest shall disclose that the text has been artificially generated or manipulated.", "verdict": "partial", "coverage": "partial", "notes": "BH-09 provides the technical content marking and provenance tracking. XP-05 covers system-level disclosure policies. PO-06 (Communication and Commitment Policy) governs AI use in external communications that may constitute matters of public interest. Partial: the 'matters of public interest' determination and the specific disclosure format requirements (which depend on the publication medium and jurisdiction-specific guidance from the AI Office) require legal interpretation and operational workflow design that extends beyond Apeiris controls.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/BH-09", "id": "BH-09", "domain": "model", "name": "Synthetic-Content Provenance, Disclosure and Traceability", "validation_objective": "Every AI-generated content artifact must carry verifiable cryptographic provenance metadata linking it to the generating model version, include a mandatory disclosure label visible to recipients, and be resolvable through a complete traceability chain from generation event to content delivery with no gaps in the provenance record.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "content_provenance_record per generated artifact showing model_version_id, generation_timestamp, content_hash, and cryptographic signature (C2PA manifest or equivalent) attached at generation time", "disclosure_label_audit_log confirming that AI-generated disclosure labels were applied and rendered for each content delivery event, with delivery_channel and recipient_context recorded", "traceability_chain_record linking content_id to generation_event_id, model_version_id, and serving_endpoint_id for each production output", "provenance_metadata_schema_validation_report confirming all required provenance fields are present and signature validity checks pass across a sampled period", "regulatory_disclosure_mapping_record showing how disclosure label format and placement satisfies jurisdiction-specific requirements (EU AI Act Art. 50 and equivalent)" ], "evidence": [ { "id": "BH-09-E1", "description": "content_provenance_record per generated artifact showing model_version_id, generation_timestamp, content_hash, and cryptographic signature (C2PA manifest or equivalent) attached at generation time", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "BH-09-E2", "description": "disclosure_label_audit_log confirming that AI-generated disclosure labels were applied and rendered for each content delivery event, with delivery_channel and recipient_context recorded", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-09-E3", "description": "traceability_chain_record linking content_id to generation_event_id, model_version_id, and serving_endpoint_id for each production output", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-09-E4", "description": "provenance_metadata_schema_validation_report confirming all required provenance fields are present and signature validity checks pass across a sampled period", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "BH-09-E5", "description": "regulatory_disclosure_mapping_record showing how disclosure label format and placement satisfies jurisdiction-specific requirements (EU AI Act Art. 50 and equivalent)", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 50 requires providers of AI systems that generate synthetic audio, image, video or text content to ensure outputs are marked in a machine-readable format and detectable as artificially generated; BH-09's synthetic content provenance framework \u2014 using C2PA manifest attachment, cryptographic signing, and automated provenance-token injection \u2014 directly implements this transparency obligation. Art. 50(2) specifically applies to GPAI models generating synthetic images, audio, or video." }, { "control": "apeiris://ethics/controls/XP-05", "id": "XP-05", "domain": "ethics", "name": "Model Card and System Card Transparency Disclosure", "validation_objective": "Every AI system deployed in a high-stakes or public-facing context has a current published model card or system card that accurately represents the system's capabilities, limitations, intended use, known failure modes, and fairness evaluation results; cards are version-controlled and updated when the system undergoes material changes; and no high-stakes AI system is in production without a current card accessible to deployers and affected stakeholders.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_card_or_system_card document per AI system with required fields: system_id, model_version, intended_use, out_of_scope_uses, known_limitations, failure_modes, fairness_evaluation_results (metric name, value, demographic group, evaluation_date), and last_updated_date", "model_card_version_history log showing card updates aligned to model changes with delta description for each version", "card_publication_record confirming the card is accessible at a documented public or deployer-accessible URL before the system was deployed", "material_change_review_log showing that each model retraining, feature change, or scope expansion triggered a card update review with decision to update or document rationale for no-update" ], "evidence": [ { "id": "XP-05-E1", "description": "model_card_or_system_card document per AI system with required fields: system_id, model_version, intended_use, out_of_scope_uses, known_limitations, failure_modes, fairness_evaluation_results (metric name, value, demographic group, evaluation_date), and last_updated_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "XP-05-E2", "description": "model_card_version_history log showing card updates aligned to model changes with delta description for each version", "evidence_type": "audit-log", "verification": "automated" }, { "id": "XP-05-E3", "description": "card_publication_record confirming the card is accessible at a documented public or deployer-accessible URL before the system was deployed", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "XP-05-E4", "description": "material_change_review_log showing that each model retraining, feature change, or scope expansion triggered a card update review with decision to update or document rationale for no-update", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 11 and Annex IV require high-risk AI providers to maintain comprehensive technical documentation including system description, design choices, performance metrics, and known limitations. Model cards directly instantiate this requirement in a standardized, reviewable format." }, { "control": "apeiris://authority/controls/PO-06", "id": "PO-06", "domain": "authority", "name": "Communication and Commitment Policy", "validation_objective": "A General-Counsel-and-CRO-approved communication authority matrix must exist for every AI system with external communication capability, and every outbound AI communication must be evaluated against that matrix before transmission \u2014 with communications exceeding documented authority limits blocked or escalated, and the evaluation logged with communication_class, authority_matrix_version, and verdict.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "communication_authority_matrix for each AI system with external capability, including permitted_statement_types, max_commitment_value, prohibited_categories, escalation_triggers, general_counsel_approval_signature, and cro_approval_signature with timestamps", "pre_send_policy_evaluation_log with communication_id, ai_system_id, communication_class, authority_matrix_version, verdict (permit/block/escalate), and evaluated_at for every outbound AI communication", "escalation_routing_record for each escalated communication with escalation_trigger_matched, reviewer_id, and resolution_decision", "authority_matrix_review_history showing General Counsel and CRO review timestamps and revision rationale for each version" ], "evidence": [ { "id": "PO-06-E1", "description": "communication_authority_matrix for each AI system with external capability, including permitted_statement_types, max_commitment_value, prohibited_categories, escalation_triggers, general_counsel_approval_signature, and cro_approval_signature with timestamps", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-06-E2", "description": "pre_send_policy_evaluation_log with communication_id, ai_system_id, communication_class, authority_matrix_version, verdict (permit/block/escalate), and evaluated_at for every outbound AI communication", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-06-E3", "description": "escalation_routing_record for each escalated communication with escalation_trigger_matched, reviewer_id, and resolution_decision", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-06-E4", "description": "authority_matrix_review_history showing General Counsel and CRO review timestamps and revision rationale for each version", "evidence_type": "human-review-record", "verification": "human" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "EU-AIA-ART50-04", "section": "Art. 50(4)", "title": "Transparency \u2014 machine-readable content marking", "text": "AI-generated or manipulated content shall be marked in a machine-readable format and shall be detectable as artificially generated or manipulated in a technically feasible and reliable way.", "verdict": "partial", "coverage": "partial", "notes": "BH-09 (Synthetic-Content Provenance, Disclosure and Traceability) covers the machine-readable marking requirement with C2PA-compatible metadata. LI-06 (Immutable Version Control with Tested Rollback and Emergency Disable) provides tamper-evident version tracking that underpins content authenticity claims. Partial: reliable machine-detectable marking for all media types (particularly audio and video) requires integration with C2PA coalition tooling, watermarking infrastructure, and output pipeline configuration that is implementation-specific and depends on third-party marking technology not within Apeiris's direct control.", "control_count": 2, "proof_chain": [ { "control": "apeiris://model/controls/BH-09", "id": "BH-09", "domain": "model", "name": "Synthetic-Content Provenance, Disclosure and Traceability", "validation_objective": "Every AI-generated content artifact must carry verifiable cryptographic provenance metadata linking it to the generating model version, include a mandatory disclosure label visible to recipients, and be resolvable through a complete traceability chain from generation event to content delivery with no gaps in the provenance record.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "content_provenance_record per generated artifact showing model_version_id, generation_timestamp, content_hash, and cryptographic signature (C2PA manifest or equivalent) attached at generation time", "disclosure_label_audit_log confirming that AI-generated disclosure labels were applied and rendered for each content delivery event, with delivery_channel and recipient_context recorded", "traceability_chain_record linking content_id to generation_event_id, model_version_id, and serving_endpoint_id for each production output", "provenance_metadata_schema_validation_report confirming all required provenance fields are present and signature validity checks pass across a sampled period", "regulatory_disclosure_mapping_record showing how disclosure label format and placement satisfies jurisdiction-specific requirements (EU AI Act Art. 50 and equivalent)" ], "evidence": [ { "id": "BH-09-E1", "description": "content_provenance_record per generated artifact showing model_version_id, generation_timestamp, content_hash, and cryptographic signature (C2PA manifest or equivalent) attached at generation time", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "BH-09-E2", "description": "disclosure_label_audit_log confirming that AI-generated disclosure labels were applied and rendered for each content delivery event, with delivery_channel and recipient_context recorded", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-09-E3", "description": "traceability_chain_record linking content_id to generation_event_id, model_version_id, and serving_endpoint_id for each production output", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-09-E4", "description": "provenance_metadata_schema_validation_report confirming all required provenance fields are present and signature validity checks pass across a sampled period", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "BH-09-E5", "description": "regulatory_disclosure_mapping_record showing how disclosure label format and placement satisfies jurisdiction-specific requirements (EU AI Act Art. 50 and equivalent)", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 50 requires providers of AI systems that generate synthetic audio, image, video or text content to ensure outputs are marked in a machine-readable format and detectable as artificially generated; BH-09's synthetic content provenance framework \u2014 using C2PA manifest attachment, cryptographic signing, and automated provenance-token injection \u2014 directly implements this transparency obligation. Art. 50(2) specifically applies to GPAI models generating synthetic images, audio, or video." }, { "control": "apeiris://model/controls/LI-06", "id": "LI-06", "domain": "model", "name": "Immutable Version Control with Tested Rollback and Emergency Disable", "validation_objective": "Every production model deployment must use an append-only model registry where no existing version entry can be overwritten or deleted; each version transition must be recorded in an immutable deployment log with source hash, destination hash, timestamp, and authorizing identity; rollback to any prior approved version must be tested and documented at least quarterly with measured rollback time; and the emergency disable mechanism must operate independently of the CI/CD pipeline and be exercisable by on-call personnel within the defined SLA.", "blocking_effect": "blocks-deployment", "evidence_required": [ "immutable_deployment_log with append-only version transition entries recording source artifact hash, destination artifact hash, timestamp, and authorizing identity for each production version change", "quarterly_rollback_test_record including model ID, prior version artifact hash, measured rollback time, and pass/fail outcome, with at least one record per production model dated within the last 90 days", "emergency_disable_test_record documenting the activation path, time from trigger to complete suspension of model serving, and explicit confirmation that the disable did not require access to CI/CD pipeline credentials", "version_drift_monitoring_alert_record demonstrating that a hash mismatch between the serving artifact and the registry entry triggered an alert within the monitoring window defined in the monitoring schema" ], "evidence": [ { "id": "LI-06-E1", "description": "immutable_deployment_log with append-only version transition entries recording source artifact hash, destination artifact hash, timestamp, and authorizing identity for each production version change", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-06-E2", "description": "quarterly_rollback_test_record including model ID, prior version artifact hash, measured rollback time, and pass/fail outcome, with at least one record per production model dated within the last 90 days", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-06-E3", "description": "emergency_disable_test_record documenting the activation path, time from trigger to complete suspension of model serving, and explicit confirmation that the disable did not require access to CI/CD pipeline credentials", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "LI-06-E4", "description": "version_drift_monitoring_alert_record demonstrating that a hash mismatch between the serving artifact and the registry entry triggered an alert within the monitoring window defined in the monitoring schema", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art-12 requires providers of high-risk AI systems to maintain logging capabilities that ensure traceability of system behavior and enable post-market monitoring. LI-06's immutable deployment log and version records directly support Art-12's traceability requirement. Art-12 also requires logs to be retained for a defined period; LI-06 does not independently specify retention \u2014 that is addressed in CR layer controls." } ] }, { "requirement_id": "EU-AIA-ART53-01a", "section": "Art. 53(1)(a)", "title": "GPAI model obligations \u2014 technical documentation", "text": "Providers of general-purpose AI models shall draw up and keep up-to-date technical documentation of the model, including the training process and the evaluation results.", "verdict": "supported", "coverage": "direct", "notes": "LI-04 (Structured Model Documentation \u2014 Complete Model Card) provides the primary technical documentation artifact for GPAI models including architecture description, training methodology, and capability documentation. LI-02 (Model Provenance Chain) documents the base model, pre-training, fine-tuning, and adapter lineage. EV-10 (Evaluation Result Provenance) documents evaluation methodology and results with full traceability. LI-07 (Capability and Limitation Declaration) captures the intended use, known capabilities, and limitations that Annex XI (GPAI technical documentation) requires.", "control_count": 4, "proof_chain": [ { "control": "apeiris://model/controls/LI-04", "id": "LI-04", "domain": "model", "name": "Structured Model Documentation \u2014 Complete Model Card with All Required Sections", "validation_objective": "Every model submitted for registration must have a schema-validated model card with all nine Mitchell et al. 2019 sections substantively populated and passing field-level validation rules; the model card must be version-locked to the artifact hash and returned as structured metadata from the registry API; and registration must be blocked when any required section is absent, empty, or contains only placeholder text.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_card_completeness_validation_report showing pass/fail status per section with field-level validation results, registration blocking decision, and validation timestamp for the current artifact version", "versioned_model_card artifact linked to the specific model artifact hash with all nine Mitchell et al. sections containing substantive content (not placeholder text), retrievable from the registry by artifact hash", "model_registry_entry showing the current model card version hash stored alongside the artifact hash as paired immutable fields", "eu_ai_act_annex_iv_supplemental_record for EU AI Act high-risk in-scope systems confirming Annex IV technical documentation fields are populated in addition to the nine Mitchell et al. sections" ], "evidence": [ { "id": "LI-04-E1", "description": "model_card_completeness_validation_report showing pass/fail status per section with field-level validation results, registration blocking decision, and validation timestamp for the current artifact version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-04-E2", "description": "versioned_model_card artifact linked to the specific model artifact hash with all nine Mitchell et al. sections containing substantive content (not placeholder text), retrievable from the registry by artifact hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-04-E3", "description": "model_registry_entry showing the current model card version hash stored alongside the artifact hash as paired immutable fields", "evidence_type": "model-card", "verification": "attested" }, { "id": "LI-04-E4", "description": "eu_ai_act_annex_iv_supplemental_record for EU AI Act high-risk in-scope systems confirming Annex IV technical documentation fields are populated in addition to the nine Mitchell et al. sections", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art-11 requires providers of high-risk AI systems to prepare and maintain technical documentation before market placement. The Mitchell et al. 9-section model card supplemented with Annex IV fields directly satisfies Art-11's technical documentation requirement. This control supports satisfaction of Art-11 for covered deployments; applicability depends on the deployer's role (provider vs. deployer) and the system's high-risk classification." }, { "control": "apeiris://model/controls/LI-02", "id": "LI-02", "domain": "model", "name": "Model Provenance Chain \u2014 Base Model, Fine-Tune, Merge, and Adapter Lineage", "validation_objective": "Every registered model artifact must have a machine-readable provenance manifest recording the complete ancestry chain including the base model artifact hash and provider version, all fine-tuning steps with dataset references, all merge contributors with their artifact hashes, and all attached adapter components with source and base-model compatibility metadata; and the registry must expose a query interface that returns all derived models for a given base model artifact hash.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_provenance_manifest with typed structured fields for base_model_hash, base_model_provider_version, fine_tuning_steps[] each referencing a TG-layer dataset record, merge_contributors[] with per-contributor artifact hashes and merge parameters, and adapter_components[] with source, version, and base_model_compatibility_hash", "provenance_query_api_result showing all registry entries derived from a specified base model artifact hash, confirming complete downstream impact scope is retrievable by automated query", "registry_provenance_rejection_log showing that a model registration attempt with a missing required provenance field (e.g., absent base_model_hash) was blocked", "adapter_lineage_registry_entry for at least one production model with an attached LoRA or PEFT adapter, confirming adapter source and compatibility metadata are recorded" ], "evidence": [ { "id": "LI-02-E1", "description": "model_provenance_manifest with typed structured fields for base_model_hash, base_model_provider_version, fine_tuning_steps[] each referencing a TG-layer dataset record, merge_contributors[] with per-contributor artifact hashes and merge parameters, and adapter_components[] with source, version, and base_model_compatibility_hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-02-E2", "description": "provenance_query_api_result showing all registry entries derived from a specified base model artifact hash, confirming complete downstream impact scope is retrievable by automated query", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-02-E3", "description": "registry_provenance_rejection_log showing that a model registration attempt with a missing required provenance field (e.g., absent base_model_hash) was blocked", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "LI-02-E4", "description": "adapter_lineage_registry_entry for at least one production model with an attached LoRA or PEFT adapter, confirming adapter source and compatibility metadata are recorded", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://model/controls/LI-07", "id": "LI-07", "domain": "model", "name": "Capability and Limitation Declaration \u2014 Intended Use, Constraints,...", "validation_objective": "Every registered model must have a structured, schema-validated capability-limitation declaration with all five required dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, and knowledge_cutoff) substantively populated with population- and context-qualified entries, returned as structured metadata in the model registry API response; registration must be blocked when any dimension is absent or empty; and the model's observable behavior for post-knowledge-cutoff queries must be consistent with the declared uncertainty_bounds.", "blocking_effect": "blocks-deployment", "evidence_required": [ "capability_limitation_declaration with all five dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, knowledge_cutoff) substantively populated with population-qualified and context-qualified entries, version-locked to the artifact hash", "registry_api_response_sample demonstrating that the capability_limitation_declaration object is returned as structured metadata in the model registry API response for the model's registered ID without requiring separate documentation lookup", "cutoff_behavior_test_result showing model responses to at least three post-knowledge-cutoff factual queries compared against the declared uncertainty_bounds, confirming the model acknowledges the limitation rather than confabulating confident answers", "registration_rejection_log showing that a model registration attempt with an empty out_of_scope_uses field was blocked with an error identifying the specific missing dimension" ], "evidence": [ { "id": "LI-07-E1", "description": "capability_limitation_declaration with all five dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, knowledge_cutoff) substantively populated with population-qualified and context-qualified entries, version-locked to the artifact hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E2", "description": "registry_api_response_sample demonstrating that the capability_limitation_declaration object is returned as structured metadata in the model registry API response for the model's registered ID without requiring separate documentation lookup", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E3", "description": "cutoff_behavior_test_result showing model responses to at least three post-knowledge-cutoff factual queries compared against the declared uncertainty_bounds, confirming the model acknowledges the limitation rather than confabulating confident answers", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E4", "description": "registration_rejection_log showing that a model registration attempt with an empty out_of_scope_uses field was blocked with an error identifying the specific missing dimension", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art-13 requires that high-risk AI systems be designed and developed such that deployers receive sufficient information to understand the system's capabilities and limitations and to implement appropriate human oversight. LI-07's structured capability-limitation declaration directly satisfies Art-13 by providing machine-readable, structured transparency information at the model consumption point." }, { "control": "apeiris://model/controls/EV-10", "id": "EV-10", "domain": "model", "name": "Evaluation Result Provenance", "validation_objective": "Every evaluation result artifact is SHA-256 content-addressed, cryptographically signed with individually attributed non-repudiable key material, submitted to an append-only tamper-evident log with a recorded inclusion proof, and linked to the model artifact hash and evaluation suite hash such that the complete chain from model artifact to deployment decision is machine-verifiable; the deployment gate rejects any manifest where inclusion proof verification fails.", "blocking_effect": "blocks-deployment", "evidence_required": [ "signed_content_addressed_evaluation_result_artifacts for each run containing model_artifact_hash, eval_suite_id, eval_suite_version, eval_suite_hash, run_timestamp, environment_fingerprint, per_dimension_results, gate_determination, and signer_identity with key_identifier", "tamper_evident_log_inclusion_proofs for each signed evaluation result submission, with log_entry_id and inclusion_proof_bytes sufficient for independent verification", "provenance_chain_traversal_records demonstrating machine-verifiable linkage from model_artifact_hash through evaluation_result to deployment_manifest for each production model version", "signing_key_attribution_records mapping each signer_identity in evaluation artifacts to a named individual via PKI certificate or directory lookup, confirming no shared or service-account signing credentials were used", "retention_compliance_records confirming signed artifacts and inclusion proofs remain available for the required period covering the operational model lifetime plus the applicable regulatory minimum per jurisdiction" ], "evidence": [ { "id": "EV-10-E1", "description": "signed_content_addressed_evaluation_result_artifacts for each run containing model_artifact_hash, eval_suite_id, eval_suite_version, eval_suite_hash, run_timestamp, environment_fingerprint, per_dimension_results, gate_determination, and signer_identity with key_identifier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-10-E2", "description": "tamper_evident_log_inclusion_proofs for each signed evaluation result submission, with log_entry_id and inclusion_proof_bytes sufficient for independent verification", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-10-E3", "description": "provenance_chain_traversal_records demonstrating machine-verifiable linkage from model_artifact_hash through evaluation_result to deployment_manifest for each production model version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-10-E4", "description": "signing_key_attribution_records mapping each signer_identity in evaluation artifacts to a named individual via PKI certificate or directory lookup, confirming no shared or service-account signing credentials were used", "evidence_type": "certification", "verification": "third-party" }, { "id": "EV-10-E5", "description": "retention_compliance_records confirming signed artifacts and inclusion proofs remain available for the required period covering the operational model lifetime plus the applicable regulatory minimum per jurisdiction", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "Art. 12 requires high-risk AI systems to automatically log events; Art. 18 requires technical documentation including testing results. Content-addressed, signed evaluation records directly satisfy these requirements." } ] }, { "requirement_id": "EU-AIA-ART53-01b", "section": "Art. 53(1)(b)", "title": "GPAI model obligations \u2014 information and documentation for downstream providers", "text": "Providers of general-purpose AI models shall make available information and documentation to providers of AI systems who intend to integrate the general-purpose AI model into their AI systems.", "verdict": "supported", "coverage": "direct", "notes": "LI-04 and LI-07 together produce the model card and capability documentation required by Annex XII for downstream provider disclosure. CA-07 (Third-Party and Supply Chain Compliance Obligations) governs the compliance disclosure obligations toward downstream system integrators. LI-08 (License and IP Governance) covers the license and permitted-use information that downstream providers need to assess their own compliance obligations when integrating a GPAI model.", "control_count": 4, "proof_chain": [ { "control": "apeiris://model/controls/LI-04", "id": "LI-04", "domain": "model", "name": "Structured Model Documentation \u2014 Complete Model Card with All Required Sections", "validation_objective": "Every model submitted for registration must have a schema-validated model card with all nine Mitchell et al. 2019 sections substantively populated and passing field-level validation rules; the model card must be version-locked to the artifact hash and returned as structured metadata from the registry API; and registration must be blocked when any required section is absent, empty, or contains only placeholder text.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_card_completeness_validation_report showing pass/fail status per section with field-level validation results, registration blocking decision, and validation timestamp for the current artifact version", "versioned_model_card artifact linked to the specific model artifact hash with all nine Mitchell et al. sections containing substantive content (not placeholder text), retrievable from the registry by artifact hash", "model_registry_entry showing the current model card version hash stored alongside the artifact hash as paired immutable fields", "eu_ai_act_annex_iv_supplemental_record for EU AI Act high-risk in-scope systems confirming Annex IV technical documentation fields are populated in addition to the nine Mitchell et al. sections" ], "evidence": [ { "id": "LI-04-E1", "description": "model_card_completeness_validation_report showing pass/fail status per section with field-level validation results, registration blocking decision, and validation timestamp for the current artifact version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-04-E2", "description": "versioned_model_card artifact linked to the specific model artifact hash with all nine Mitchell et al. sections containing substantive content (not placeholder text), retrievable from the registry by artifact hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-04-E3", "description": "model_registry_entry showing the current model card version hash stored alongside the artifact hash as paired immutable fields", "evidence_type": "model-card", "verification": "attested" }, { "id": "LI-04-E4", "description": "eu_ai_act_annex_iv_supplemental_record for EU AI Act high-risk in-scope systems confirming Annex IV technical documentation fields are populated in addition to the nine Mitchell et al. sections", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art-11 requires providers of high-risk AI systems to prepare and maintain technical documentation before market placement. The Mitchell et al. 9-section model card supplemented with Annex IV fields directly satisfies Art-11's technical documentation requirement. This control supports satisfaction of Art-11 for covered deployments; applicability depends on the deployer's role (provider vs. deployer) and the system's high-risk classification." }, { "control": "apeiris://model/controls/LI-07", "id": "LI-07", "domain": "model", "name": "Capability and Limitation Declaration \u2014 Intended Use, Constraints,...", "validation_objective": "Every registered model must have a structured, schema-validated capability-limitation declaration with all five required dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, and knowledge_cutoff) substantively populated with population- and context-qualified entries, returned as structured metadata in the model registry API response; registration must be blocked when any dimension is absent or empty; and the model's observable behavior for post-knowledge-cutoff queries must be consistent with the declared uncertainty_bounds.", "blocking_effect": "blocks-deployment", "evidence_required": [ "capability_limitation_declaration with all five dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, knowledge_cutoff) substantively populated with population-qualified and context-qualified entries, version-locked to the artifact hash", "registry_api_response_sample demonstrating that the capability_limitation_declaration object is returned as structured metadata in the model registry API response for the model's registered ID without requiring separate documentation lookup", "cutoff_behavior_test_result showing model responses to at least three post-knowledge-cutoff factual queries compared against the declared uncertainty_bounds, confirming the model acknowledges the limitation rather than confabulating confident answers", "registration_rejection_log showing that a model registration attempt with an empty out_of_scope_uses field was blocked with an error identifying the specific missing dimension" ], "evidence": [ { "id": "LI-07-E1", "description": "capability_limitation_declaration with all five dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, knowledge_cutoff) substantively populated with population-qualified and context-qualified entries, version-locked to the artifact hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E2", "description": "registry_api_response_sample demonstrating that the capability_limitation_declaration object is returned as structured metadata in the model registry API response for the model's registered ID without requiring separate documentation lookup", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E3", "description": "cutoff_behavior_test_result showing model responses to at least three post-knowledge-cutoff factual queries compared against the declared uncertainty_bounds, confirming the model acknowledges the limitation rather than confabulating confident answers", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E4", "description": "registration_rejection_log showing that a model registration attempt with an empty out_of_scope_uses field was blocked with an error identifying the specific missing dimension", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art-13 requires that high-risk AI systems be designed and developed such that deployers receive sufficient information to understand the system's capabilities and limitations and to implement appropriate human oversight. LI-07's structured capability-limitation declaration directly satisfies Art-13 by providing machine-readable, structured transparency information at the model consumption point." }, { "control": "apeiris://compliance/controls/CA-07", "id": "CA-07", "domain": "compliance", "name": "Third-Party and Supply Chain Compliance Obligations", "validation_objective": "Every supply chain participant for each AI system in scope must have an entry in the third-party compliance obligation register documenting all flowing obligations and a corresponding executed binding contractual instrument containing audit rights, with third-party compliance attestations collected within the defined refresh cycle and incorporated into the CA-03 routing table as evidence inputs.", "blocking_effect": "blocks-deployment", "evidence_required": [ "third_party_compliance_obligation_register entries for each supply chain participant containing vendor_id, vendor_role, applicable_obligations[], contract_instrument_id, contract_execution_date, and next_attestation_due_date", "executed_contract_inventory for each supply chain participant showing contract_type (DPA, EU_AI_Act_compliance_schedule, supplier_agreement), execution_date, audit_rights_clause_present=true, and sub_processor_management_clause_present=true for data processors", "third_party_attestation_collection_log showing each attestation collected with collection_date, valid_until, attesting_entity_name, attestation_scope, and the CA-03 routing_table_entry_id that references it", "service_dependency_map for each AI system listing all integrated third-party APIs, model providers, and data services cross-referenced against the obligation register to confirm no vendor is absent from the register" ], "evidence": [ { "id": "CA-07-E1", "description": "third_party_compliance_obligation_register entries for each supply chain participant containing vendor_id, vendor_role, applicable_obligations[], contract_instrument_id, contract_execution_date, and next_attestation_due_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-07-E2", "description": "executed_contract_inventory for each supply chain participant showing contract_type (DPA, EU_AI_Act_compliance_schedule, supplier_agreement), execution_date, audit_rights_clause_present=true, and sub_processor_management_clause_present=true for data processors", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-07-E3", "description": "third_party_attestation_collection_log showing each attestation collected with collection_date, valid_until, attesting_entity_name, attestation_scope, and the CA-03 routing_table_entry_id that references it", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-07-E4", "description": "service_dependency_map for each AI system listing all integrated third-party APIs, model providers, and data services cross-referenced against the obligation register to confirm no vendor is absent from the register", "evidence_type": "third-party-audit-report", "verification": "third-party" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Articles 23, 24 and 26 establish obligations for importers, distributors and deployers of high-risk AI systems, including verification obligations that flow up the supply chain to providers, and Article 25 allocates responsibilities along the AI value chain \u2014 including written agreements with third-party suppliers of components integrated into high-risk AI systems. CA-07's third-party obligation register and contractual coverage mechanism ensures these value-chain obligations are identified and imposed on the appropriate supply chain participants. Failure to impose these obligations contractually leaves the organization as the residual obligor for non-compliance by downstream parties." }, { "control": "apeiris://model/controls/LI-08", "id": "LI-08", "domain": "model", "name": "License and IP Governance \u2014 Dataset License Tracking, Derivative Work...", "validation_objective": "A machine-readable license chain record exists for every production model artifact, enumerating SPDX-identified licenses for all training datasets, the base model, and any adapters or fine-tunes; an automated compatibility analysis must confirm the chain is compatible with the declared deployment use type, and deployment must be blocked when a hard incompatibility is detected.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_license_chain_record listing SPDX license identifiers for each training dataset, base model, and adapter component, with a link to TG-layer dataset provenance records", "license_compatibility_analysis_result with pass/fail/ambiguous verdict for the declared deployment use type (commercial, internal, research, distribution), including specific incompatibility details where applicable", "deployment_pipeline_block_log showing that a deployment attempt was rejected when an incompatibility was detected, with the specific conflicting license pair recorded", "legal_review_signoff_record for any deployment where compatibility analysis returned an ambiguous verdict, signed by authorized legal counsel" ], "evidence": [ { "id": "LI-08-E1", "description": "model_license_chain_record listing SPDX license identifiers for each training dataset, base model, and adapter component, with a link to TG-layer dataset provenance records", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "LI-08-E2", "description": "license_compatibility_analysis_result with pass/fail/ambiguous verdict for the declared deployment use type (commercial, internal, research, distribution), including specific incompatibility details where applicable", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-08-E3", "description": "deployment_pipeline_block_log showing that a deployment attempt was rejected when an incompatibility was detected, with the specific conflicting license pair recorded", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-08-E4", "description": "legal_review_signoff_record for any deployment where compatibility analysis returned an ambiguous verdict, signed by authorized legal counsel", "evidence_type": "human-review-record", "verification": "human" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "EU-AIA-ART53-01c", "section": "Art. 53(1)(c)", "title": "GPAI model obligations \u2014 copyright compliance policy", "text": "Providers of general-purpose AI models shall put in place a policy to comply with Union law on copyright and related rights, in particular to identify and comply with a reservation of rights expressed pursuant to Article 4(3) of Directive 2019/790.", "verdict": "supported", "coverage": "direct", "notes": "TG-03 (Data Rights, Lawful Authority and Permitted Use) requires documented legal basis for all training data sources, including identification and compliance with opt-out signals under Article 4(3) TDM exceptions. LI-08 (License and IP Governance \u2014 Dataset License Tracking, Derivative Work Authority) provides the license tracking system that identifies rights reservations in training datasets. TG-07 (Third-Party Dataset Governance) extends this to datasets acquired from third parties, requiring contractual representations of rights clearance.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/TG-03", "id": "TG-03", "domain": "model", "name": "Data Rights, Lawful Authority and Permitted Use", "validation_objective": "For every dataset used in training, a specific and documented legal basis exists \u2014 identifying the consent mechanism, contractual right, statutory authority, or license entitlement that permits collection and use for the declared training purpose \u2014 and no training run may proceed on a dataset whose legal basis record is absent, expired, or jurisdiction-mismatched.", "blocking_effect": "blocks-deployment", "evidence_required": [ "data_rights_record for each training dataset specifying the legal basis type (consent, legitimate interest, contract, statutory authority, or license), the jurisdiction(s) covered, the permitted purpose scope, and any opt-out or withdrawal obligations", "purpose_limitation_compliance_record confirming that the declared training purpose falls within the scope of the legal basis established for the dataset, with documented mapping between use case and authorized purpose", "opt_out_enforcement_log showing that data subjects who exercised withdrawal or opt-out rights had their records removed from training datasets before any training run that included the affected dataset", "legal_basis_expiry_alert showing that datasets with time-limited legal bases (e.g., consents with expiry dates, contracts with end dates) are flagged for renewal review before expiry and blocked from training if the basis lapses" ], "evidence": [ { "id": "TG-03-E1", "description": "data_rights_record for each training dataset specifying the legal basis type (consent, legitimate interest, contract, statutory authority, or license), the jurisdiction(s) covered, the permitted purpose scope, and any opt-out or withdrawal obligations", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-03-E2", "description": "purpose_limitation_compliance_record confirming that the declared training purpose falls within the scope of the legal basis established for the dataset, with documented mapping between use case and authorized purpose", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-03-E3", "description": "opt_out_enforcement_log showing that data subjects who exercised withdrawal or opt-out rights had their records removed from training datasets before any training run that included the affected dataset", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-03-E4", "description": "legal_basis_expiry_alert showing that datasets with time-limited legal bases (e.g., consents with expiry dates, contracts with end dates) are flagged for renewal review before expiry and blocked from training if the basis lapses", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "DRR operationalizes EU AI Act data governance requirements for high-risk AI" }, { "control": "apeiris://model/controls/LI-08", "id": "LI-08", "domain": "model", "name": "License and IP Governance \u2014 Dataset License Tracking, Derivative Work...", "validation_objective": "A machine-readable license chain record exists for every production model artifact, enumerating SPDX-identified licenses for all training datasets, the base model, and any adapters or fine-tunes; an automated compatibility analysis must confirm the chain is compatible with the declared deployment use type, and deployment must be blocked when a hard incompatibility is detected.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_license_chain_record listing SPDX license identifiers for each training dataset, base model, and adapter component, with a link to TG-layer dataset provenance records", "license_compatibility_analysis_result with pass/fail/ambiguous verdict for the declared deployment use type (commercial, internal, research, distribution), including specific incompatibility details where applicable", "deployment_pipeline_block_log showing that a deployment attempt was rejected when an incompatibility was detected, with the specific conflicting license pair recorded", "legal_review_signoff_record for any deployment where compatibility analysis returned an ambiguous verdict, signed by authorized legal counsel" ], "evidence": [ { "id": "LI-08-E1", "description": "model_license_chain_record listing SPDX license identifiers for each training dataset, base model, and adapter component, with a link to TG-layer dataset provenance records", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "LI-08-E2", "description": "license_compatibility_analysis_result with pass/fail/ambiguous verdict for the declared deployment use type (commercial, internal, research, distribution), including specific incompatibility details where applicable", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-08-E3", "description": "deployment_pipeline_block_log showing that a deployment attempt was rejected when an incompatibility was detected, with the specific conflicting license pair recorded", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-08-E4", "description": "legal_review_signoff_record for any deployment where compatibility analysis returned an ambiguous verdict, signed by authorized legal counsel", "evidence_type": "human-review-record", "verification": "human" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://model/controls/TG-07", "id": "TG-07", "domain": "model", "name": "Third-Party Dataset Governance", "validation_objective": "Every externally sourced training dataset in active use has a current Third-Party Dataset Registry entry with a valid security and legal review, version-pinned artifact hash, and license compliance record. No third-party dataset update enters training without a completed re-review gate, and artifact integrity is verified by hash comparison against vendor-published checksums before each training use.", "blocking_effect": "blocks-deployment", "evidence_required": [ "third_party_dataset_registry_entry for each active external dataset containing: dataset_id, vendor_name, license_terms, version_pin with artifact_hash, approval_date, reviewer_identity, legal_review_outcome, and security_review_outcome", "artifact_integrity_verification_log per training run showing hash comparison between locally stored dataset artifact and vendor-published checksum, with pass/fail result", "update_notification_record documenting each vendor-issued dataset update notice received, with quarantine status and re-review outcome (approved / rejected / paused-pending-review)", "license_compliance_attestation confirming permitted training use, output rights, and any attribution or restriction requirements for each active third-party dataset" ], "evidence": [ { "id": "TG-07-E1", "description": "third_party_dataset_registry_entry for each active external dataset containing: dataset_id, vendor_name, license_terms, version_pin with artifact_hash, approval_date, reviewer_identity, legal_review_outcome, and security_review_outcome", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-07-E2", "description": "artifact_integrity_verification_log per training run showing hash comparison between locally stored dataset artifact and vendor-published checksum, with pass/fail result", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-07-E3", "description": "update_notification_record documenting each vendor-issued dataset update notice received, with quarantine status and re-review outcome (approved / rejected / paused-pending-review)", "evidence_type": "human-review-record", "verification": "human" }, { "id": "TG-07-E4", "description": "license_compliance_attestation confirming permitted training use, output rights, and any attribution or restriction requirements for each active third-party dataset", "evidence_type": "third-party-audit-report", "verification": "third-party" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "TPDR provides documentation of data origin required by EU AI Act for high-risk AI" } ] }, { "requirement_id": "EU-AIA-ART53-01d", "section": "Art. 53(1)(d)", "title": "GPAI model obligations \u2014 AI-generated content marking support", "text": "Providers of general-purpose AI models shall publish a summary about the content used for training of the general-purpose AI model and support technical solutions for AI-generated content marking.", "verdict": "partial", "coverage": "partial", "notes": "BH-09 (Synthetic-Content Provenance, Disclosure and Traceability) covers the technical AI-generated content marking support obligation. LI-07 and TG-03 together support the training data summary disclosure. Partial: the public training data summary is a publishing obligation \u2014 requiring a structured summary document published in the EU AI Office's designated format \u2014 that goes beyond technical controls into legal disclosure obligations. The specific format and publication mechanism are defined by implementing acts not yet fully in force.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/BH-09", "id": "BH-09", "domain": "model", "name": "Synthetic-Content Provenance, Disclosure and Traceability", "validation_objective": "Every AI-generated content artifact must carry verifiable cryptographic provenance metadata linking it to the generating model version, include a mandatory disclosure label visible to recipients, and be resolvable through a complete traceability chain from generation event to content delivery with no gaps in the provenance record.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "content_provenance_record per generated artifact showing model_version_id, generation_timestamp, content_hash, and cryptographic signature (C2PA manifest or equivalent) attached at generation time", "disclosure_label_audit_log confirming that AI-generated disclosure labels were applied and rendered for each content delivery event, with delivery_channel and recipient_context recorded", "traceability_chain_record linking content_id to generation_event_id, model_version_id, and serving_endpoint_id for each production output", "provenance_metadata_schema_validation_report confirming all required provenance fields are present and signature validity checks pass across a sampled period", "regulatory_disclosure_mapping_record showing how disclosure label format and placement satisfies jurisdiction-specific requirements (EU AI Act Art. 50 and equivalent)" ], "evidence": [ { "id": "BH-09-E1", "description": "content_provenance_record per generated artifact showing model_version_id, generation_timestamp, content_hash, and cryptographic signature (C2PA manifest or equivalent) attached at generation time", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "BH-09-E2", "description": "disclosure_label_audit_log confirming that AI-generated disclosure labels were applied and rendered for each content delivery event, with delivery_channel and recipient_context recorded", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-09-E3", "description": "traceability_chain_record linking content_id to generation_event_id, model_version_id, and serving_endpoint_id for each production output", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-09-E4", "description": "provenance_metadata_schema_validation_report confirming all required provenance fields are present and signature validity checks pass across a sampled period", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "BH-09-E5", "description": "regulatory_disclosure_mapping_record showing how disclosure label format and placement satisfies jurisdiction-specific requirements (EU AI Act Art. 50 and equivalent)", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 50 requires providers of AI systems that generate synthetic audio, image, video or text content to ensure outputs are marked in a machine-readable format and detectable as artificially generated; BH-09's synthetic content provenance framework \u2014 using C2PA manifest attachment, cryptographic signing, and automated provenance-token injection \u2014 directly implements this transparency obligation. Art. 50(2) specifically applies to GPAI models generating synthetic images, audio, or video." }, { "control": "apeiris://model/controls/LI-07", "id": "LI-07", "domain": "model", "name": "Capability and Limitation Declaration \u2014 Intended Use, Constraints,...", "validation_objective": "Every registered model must have a structured, schema-validated capability-limitation declaration with all five required dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, and knowledge_cutoff) substantively populated with population- and context-qualified entries, returned as structured metadata in the model registry API response; registration must be blocked when any dimension is absent or empty; and the model's observable behavior for post-knowledge-cutoff queries must be consistent with the declared uncertainty_bounds.", "blocking_effect": "blocks-deployment", "evidence_required": [ "capability_limitation_declaration with all five dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, knowledge_cutoff) substantively populated with population-qualified and context-qualified entries, version-locked to the artifact hash", "registry_api_response_sample demonstrating that the capability_limitation_declaration object is returned as structured metadata in the model registry API response for the model's registered ID without requiring separate documentation lookup", "cutoff_behavior_test_result showing model responses to at least three post-knowledge-cutoff factual queries compared against the declared uncertainty_bounds, confirming the model acknowledges the limitation rather than confabulating confident answers", "registration_rejection_log showing that a model registration attempt with an empty out_of_scope_uses field was blocked with an error identifying the specific missing dimension" ], "evidence": [ { "id": "LI-07-E1", "description": "capability_limitation_declaration with all five dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, knowledge_cutoff) substantively populated with population-qualified and context-qualified entries, version-locked to the artifact hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E2", "description": "registry_api_response_sample demonstrating that the capability_limitation_declaration object is returned as structured metadata in the model registry API response for the model's registered ID without requiring separate documentation lookup", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E3", "description": "cutoff_behavior_test_result showing model responses to at least three post-knowledge-cutoff factual queries compared against the declared uncertainty_bounds, confirming the model acknowledges the limitation rather than confabulating confident answers", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E4", "description": "registration_rejection_log showing that a model registration attempt with an empty out_of_scope_uses field was blocked with an error identifying the specific missing dimension", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art-13 requires that high-risk AI systems be designed and developed such that deployers receive sufficient information to understand the system's capabilities and limitations and to implement appropriate human oversight. LI-07's structured capability-limitation declaration directly satisfies Art-13 by providing machine-readable, structured transparency information at the model consumption point." }, { "control": "apeiris://model/controls/TG-03", "id": "TG-03", "domain": "model", "name": "Data Rights, Lawful Authority and Permitted Use", "validation_objective": "For every dataset used in training, a specific and documented legal basis exists \u2014 identifying the consent mechanism, contractual right, statutory authority, or license entitlement that permits collection and use for the declared training purpose \u2014 and no training run may proceed on a dataset whose legal basis record is absent, expired, or jurisdiction-mismatched.", "blocking_effect": "blocks-deployment", "evidence_required": [ "data_rights_record for each training dataset specifying the legal basis type (consent, legitimate interest, contract, statutory authority, or license), the jurisdiction(s) covered, the permitted purpose scope, and any opt-out or withdrawal obligations", "purpose_limitation_compliance_record confirming that the declared training purpose falls within the scope of the legal basis established for the dataset, with documented mapping between use case and authorized purpose", "opt_out_enforcement_log showing that data subjects who exercised withdrawal or opt-out rights had their records removed from training datasets before any training run that included the affected dataset", "legal_basis_expiry_alert showing that datasets with time-limited legal bases (e.g., consents with expiry dates, contracts with end dates) are flagged for renewal review before expiry and blocked from training if the basis lapses" ], "evidence": [ { "id": "TG-03-E1", "description": "data_rights_record for each training dataset specifying the legal basis type (consent, legitimate interest, contract, statutory authority, or license), the jurisdiction(s) covered, the permitted purpose scope, and any opt-out or withdrawal obligations", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-03-E2", "description": "purpose_limitation_compliance_record confirming that the declared training purpose falls within the scope of the legal basis established for the dataset, with documented mapping between use case and authorized purpose", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-03-E3", "description": "opt_out_enforcement_log showing that data subjects who exercised withdrawal or opt-out rights had their records removed from training datasets before any training run that included the affected dataset", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-03-E4", "description": "legal_basis_expiry_alert showing that datasets with time-limited legal bases (e.g., consents with expiry dates, contracts with end dates) are flagged for renewal review before expiry and blocked from training if the basis lapses", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "DRR operationalizes EU AI Act data governance requirements for high-risk AI" } ] }, { "requirement_id": "EU-AIA-ART55-01a", "section": "Art. 55(1)(a)", "title": "GPAI systemic risk \u2014 adversarial testing", "text": "Providers of GPAI models with systemic risk shall perform model evaluations in accordance with standardised protocols and tools reflecting the state of the art, including adversarial testing of the model to identify and mitigate systemic risks.", "verdict": "supported", "coverage": "direct", "notes": "EV-04 (Adversarial Red-Team Testing) provides the structured adversarial testing methodology required by this article, including capability elicitation, jailbreak testing, and dangerous-use scenario evaluation. AS-01 (Adversarially red-team and evaluate before launch) provides the agentic deployment variant of red-team evaluation. EV-03 (Dangerous Capability Threshold Assessment) specifically addresses systemic risks from frontier capabilities \u2014 evaluating whether the model crosses capability thresholds that trigger enhanced risk management. AS-05 (Study frontier offensive capability before public release) aligns with the 'state of the art' evaluation requirement.", "control_count": 4, "proof_chain": [ { "control": "apeiris://model/controls/EV-04", "id": "EV-04", "domain": "model", "name": "Adversarial Red-Team Testing", "validation_objective": "The model system has a signed red-team report produced by a team organizationally independent of model development, documenting structured adversarial probing that covers all required attack categories for the applicable profiles, with all critical and high findings remediated and re-tested before the deployment gate clears.", "blocking_effect": "blocks-deployment", "evidence_required": [ "signed_red_team_scope_document with threat_model version, profile scope, and pre-exercise approval timestamp", "red_team_findings_log with finding_id, severity_classification, reproduction_steps, affected_population, and remediation_status per finding", "signed_red_team_report with residual_risk_statement linked to model artifact hash and listing remediated critical and high findings with re-test results", "remediation_evidence for all critical and high findings demonstrating the vulnerability is closed via re-test, not only via input-level patch", "for frontier-capability profile: escalation_records for any capability elicited at or near threshold levels with escalation_destination and response_action" ], "evidence": [ { "id": "EV-04-E1", "description": "signed_red_team_scope_document with threat_model version, profile scope, and pre-exercise approval timestamp", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EV-04-E2", "description": "red_team_findings_log with finding_id, severity_classification, reproduction_steps, affected_population, and remediation_status per finding", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-04-E3", "description": "signed_red_team_report with residual_risk_statement linked to model artifact hash and listing remediated critical and high findings with re-test results", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "EV-04-E4", "description": "remediation_evidence for all critical and high findings demonstrating the vulnerability is closed via re-test, not only via input-level patch", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "EV-04-E5", "description": "for frontier-capability profile: escalation_records for any capability elicited at or near threshold levels with escalation_destination and response_action", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "Art. 55(1)(a) requires providers of GPAI models with systemic risk to conduct adversarial testing prior to deployment." }, { "control": "apeiris://security/controls/AS-01", "id": "AS-01", "domain": "security", "name": "Adversarially red-team and evaluate the agent before launch", "validation_objective": "Before any deployment to production, the agent must have passed a structured adversarial red-team exercise covering multi-turn goal hijack, tool misuse, and data exfiltration scenarios, with measured attack-success-rates at or below the defined launch threshold. Deployment must be blocked until the red-team pass/fail gate is cleared and documented.", "blocking_effect": "blocks-deployment", "evidence_required": [ "pre_launch_red_team_report listing each scenario (multi-turn hijack, tool-misuse, exfiltration), the attack-success-rate per scenario, the defined launch threshold, and a signed go/no-go decision", "multi_turn_eval_suite_run_log showing the agentic benchmark used (e.g., AgentDojo, FinBot CTF), commit SHA, run date, and overall pass/fail outcome against the threshold", "red_team_scope_document confirming coverage of multi-turn drift scenarios not only single-prompt tests, signed before the red-team exercise begins", "launch_gate_approval_record linking the red-team report to the deployment decision with approver identity and timestamp" ], "evidence": [ { "id": "AS-01-E1", "description": "pre_launch_red_team_report listing each scenario (multi-turn hijack, tool-misuse, exfiltration), the attack-success-rate per scenario, the defined launch threshold, and a signed go/no-go decision", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AS-01-E2", "description": "multi_turn_eval_suite_run_log showing the agentic benchmark used (e.g., AgentDojo, FinBot CTF), commit SHA, run date, and overall pass/fail outcome against the threshold", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "AS-01-E3", "description": "red_team_scope_document confirming coverage of multi-turn drift scenarios not only single-prompt tests, signed before the red-team exercise begins", "evidence_type": "red-team-report", "verification": "third-party" }, { "id": "AS-01-E4", "description": "launch_gate_approval_record linking the red-team report to the deployment decision with approver identity and timestamp", "evidence_type": "red-team-report", "verification": "third-party" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://model/controls/EV-03", "id": "EV-03", "domain": "model", "name": "Dangerous Capability Threshold Assessment", "validation_objective": "Every model at or near frontier capability has been assessed against the organization's applicable responsible scaling or capability policy thresholds for CBRN uplift, cyberweapon generation, autonomous AI R&D, and mass-influence operations before deployment authorization is granted. The safety committee has reviewed elicitation results and issued a signed deployment authorization for models below all thresholds; any model at or above threshold in any domain is not deployed pending safety committee escalation.", "blocking_effect": "blocks-deployment", "evidence_required": [ "scoping_determination_record for each evaluated model referencing the applicable capability policy (responsible scaling policy version or equivalent), with rationale for frontier-class determination including FLOPs estimate, capability benchmark scores, or elicitation pre-screen results", "capability_elicitation_results per domain (CBRN, cyberweapons, autonomous AI R&D, mass-influence operations) with methodology documentation, red-team evaluator identities, uplift elicitation protocol reference, and threshold comparison showing assessed level vs. defined threshold for each domain", "safety_committee_review_record with committee composition, deliberation notes, quorum confirmation, majority determination, any dissenting positions, and signed deployment_authorization or deployment_block decision", "EU_AI_Act_systemic_risk_classification_record for models meeting Art. 51 GPAI thresholds (\u226510\u00b2\u2075 FLOPs training compute or equivalent capability), documenting systemic risk determination and applicable GPAI obligations" ], "evidence": [ { "id": "EV-03-E1", "description": "scoping_determination_record for each evaluated model referencing the applicable capability policy (responsible scaling policy version or equivalent), with rationale for frontier-class determination including FLOPs estimate, capability benchmark scores, or elicitation pre-screen results", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-03-E2", "description": "capability_elicitation_results per domain (CBRN, cyberweapons, autonomous AI R&D, mass-influence operations) with methodology documentation, red-team evaluator identities, uplift elicitation protocol reference, and threshold comparison showing assessed level vs. defined threshold for each domain", "evidence_type": "red-team-report", "verification": "third-party" }, { "id": "EV-03-E3", "description": "safety_committee_review_record with committee composition, deliberation notes, quorum confirmation, majority determination, any dissenting positions, and signed deployment_authorization or deployment_block decision", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EV-03-E4", "description": "EU_AI_Act_systemic_risk_classification_record for models meeting Art. 51 GPAI thresholds (\u226510\u00b2\u2075 FLOPs training compute or equivalent capability), documenting systemic risk determination and applicable GPAI obligations", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "Art. 51 only classifies GPAI models as systemic-risk (including the 10^25 FLOP training-compute presumption); the substantive evaluation obligations attach under Art. 55 \u2014 model evaluation with adversarial testing, systemic-risk assessment and mitigation, and serious-incident reporting. EV-03's dangerous-capability assessment operationalizes the Art. 55 evaluation duty." }, { "control": "apeiris://security/controls/AS-05", "id": "AS-05", "domain": "security", "name": "Study frontier offensive capability before public release", "validation_objective": "Before public release of any model version, a frontier offensive-capability evaluation must be completed that measures the model's ability to autonomously find and exploit vulnerabilities, and the release must be blocked unless measured capability is at or below the defined risk threshold. Each staged access expansion must be tied to specific evidence milestones against that threshold.", "blocking_effect": "blocks-deployment", "evidence_required": [ "frontier_capability_assessment_report documenting model version, evaluation methodology, offensive capability score against the defined threshold, and the release-gating decision with approver identity and date", "control_evaluation_record showing the red-team exercises used to measure vuln-finding and multi-step exploit-chaining capability, including pass/fail outcome per scenario against the tracked-risk threshold", "deployment_gate_decision_record linking the capability score to a signed go/no-go decision with the threshold definition version referenced", "staged_release_access_log showing each incremental access expansion milestone and the specific evidence that cleared each stage", "risk_threshold_definition_document specifying the acceptable offensive capability level at each deployment tier, reviewed and signed by the responsible authority before evaluation begins" ], "evidence": [ { "id": "AS-05-E1", "description": "frontier_capability_assessment_report documenting model version, evaluation methodology, offensive capability score against the defined threshold, and the release-gating decision with approver identity and date", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "AS-05-E2", "description": "control_evaluation_record showing the red-team exercises used to measure vuln-finding and multi-step exploit-chaining capability, including pass/fail outcome per scenario against the tracked-risk threshold", "evidence_type": "red-team-report", "verification": "third-party" }, { "id": "AS-05-E3", "description": "deployment_gate_decision_record linking the capability score to a signed go/no-go decision with the threshold definition version referenced", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AS-05-E4", "description": "staged_release_access_log showing each incremental access expansion milestone and the specific evidence that cleared each stage", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AS-05-E5", "description": "risk_threshold_definition_document specifying the acceptable offensive capability level at each deployment tier, reviewed and signed by the responsible authority before evaluation begins", "evidence_type": "evaluation-scorecard", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "EU-AIA-ART55-01b", "section": "Art. 55(1)(b)", "title": "GPAI systemic risk \u2014 serious incident notification", "text": "Providers of GPAI models with systemic risk shall assess and mitigate possible systemic risks, including their sources, which may stem from the development, the placing on the market, or the use of GPAI models with systemic risk.", "verdict": "supported", "coverage": "direct", "notes": "CR-04 (AI Incident Response Management) provides the structured process for identifying, investigating, and mitigating serious incidents arising from GPAI model deployments. CR-05 (Regulatory Notification and Statutory Reporting) governs the notification obligation to the AI Office when systemic risks or serious incidents are identified. AG-05 extends incident response to agentic deployment contexts. CR-01 (Continuous Production Monitoring and Risk Aggregation) provides ongoing systemic risk signal aggregation across all deployment instances.", "control_count": 4, "proof_chain": [ { "control": "apeiris://model/controls/CR-04", "id": "CR-04", "domain": "model", "name": "AI Incident Response Management", "validation_objective": "The organization must have a documented, version-controlled AI Incident Response Plan (AIRP) with AI-specific containment playbooks covering model rollback, output-filter enforcement, traffic shaping, and full model shutdown \u2014 tested via at least four quarterly tabletop exercises per year using MITRE ATLAS adversarial scenarios \u2014 and P1/P2 post-incident review records produced within 5 days of event resolution for all qualifying events in the trailing 12 months.", "blocking_effect": "blocks-deployment", "evidence_required": [ "AI Incident Response Plan document (version-controlled, CISO or AI-risk-owner signed, with review date within 12 months)", "Containment playbook index listing separate runbooks for model_rollback, output_filter_enforcement, traffic_shaping, and model_shutdown_with_fallback", "Last 4 quarterly tabletop exercise reports with MITRE ATLAS scenario identifier, participant roster, outcomes, and reviewer sign-off", "P1 and P2 post-incident review records for all qualifying events in the trailing 12 months, each showing post_incident_report_date within 5 days of incident_resolved_date", "EU Art. 73 notification trigger mapping document showing which P1 severity criteria trigger the Art. 73 serious-incident notification obligation (15d general / 10d death / 2d widespread or critical infrastructure)" ], "evidence": [ { "id": "CR-04-E1", "description": "AI Incident Response Plan document (version-controlled, CISO or AI-risk-owner signed, with review date within 12 months)", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-04-E2", "description": "Containment playbook index listing separate runbooks for model_rollback, output_filter_enforcement, traffic_shaping, and model_shutdown_with_fallback", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-04-E3", "description": "Last 4 quarterly tabletop exercise reports with MITRE ATLAS scenario identifier, participant roster, outcomes, and reviewer sign-off", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CR-04-E4", "description": "P1 and P2 post-incident review records for all qualifying events in the trailing 12 months, each showing post_incident_report_date within 5 days of incident_resolved_date", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-04-E5", "description": "EU Art. 73 notification trigger mapping document showing which P1 severity criteria trigger the Art. 73 serious-incident notification obligation (15d general / 10d death / 2d widespread or critical infrastructure)", "evidence_type": "incident-record", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 73 requires providers of high-risk AI systems to report serious incidents to national market surveillance authorities without undue delay; CR-04's model-specific incident response management \u2014 including P1/P2/P3 severity classification, mean-time-to-respond SLAs, and structured incident post-mortems \u2014 supports the incident triage and escalation processes required upstream of regulatory notification." }, { "control": "apeiris://model/controls/CR-05", "id": "CR-05", "domain": "model", "name": "Regulatory Notification and Statutory Reporting", "validation_objective": "The organization must maintain a current, legal-counsel-reviewed regulatory notification matrix mapping P1 severity incident events to all applicable jurisdictions, notification timelines (EU Art. 73: \u226415 calendar days for serious incidents; SR 26-2: immediate for material events), designated liaison and backup contacts, and pre-approved notification templates \u2014 with an automated countdown timer creation integrated into the CR-04 P1 escalation workflow and a complete archive of all notification submissions and delivery confirmations in CR-02.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Regulatory notification matrix document (version-controlled, legal-counsel reviewed within 12 months) listing jurisdiction, authority, trigger_event, timeline_days, liaison_contact, backup_contact, and template_ref for each row", "Pre-approved notification templates for each regulatory authority and jurisdiction, with legal counsel review date and version on record", "Notification task creation records showing automated countdown timers initiated for each P1 incident meeting notification criteria, with regulatory liaison page confirmation and timer expiry date", "All notification submissions and delivery confirmations archived in CR-02 with artifact_hash for the trailing 36 months", "Legal counsel sign-off record confirming annual review of all notification triggers and timelines, dated within 12 months" ], "evidence": [ { "id": "CR-05-E1", "description": "Regulatory notification matrix document (version-controlled, legal-counsel reviewed within 12 months) listing jurisdiction, authority, trigger_event, timeline_days, liaison_contact, backup_contact, and template_ref for each row", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CR-05-E2", "description": "Pre-approved notification templates for each regulatory authority and jurisdiction, with legal counsel review date and version on record", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CR-05-E3", "description": "Notification task creation records showing automated countdown timers initiated for each P1 incident meeting notification criteria, with regulatory liaison page confirmation and timer expiry date", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-05-E4", "description": "All notification submissions and delivery confirmations archived in CR-02 with artifact_hash for the trailing 36 months", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-05-E5", "description": "Legal counsel sign-off record confirming annual review of all notification triggers and timelines, dated within 12 months", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 72 requires post-market monitoring to cover systematic collection and analysis of user feedback and actual model performance outcomes; CR-05's outcomes and disparate impact analysis \u2014 comparing actual decisions against predicted outcomes and testing for differential impact across demographic cohorts \u2014 directly implements the outcome analysis component of post-market monitoring." }, { "control": "apeiris://agentic/controls/AG-05", "id": "AG-05", "domain": "agentic", "name": "Agent Incident Response Program", "validation_objective": "The enterprise has a documented, tested AI Incident Response Playbook with AI-specific containment capabilities, and every production agent has an authenticated kill-switch that demonstrably suspends its operation within 60 seconds of an authorized responder request.", "blocking_effect": "requires-review", "evidence_required": [ "AI Incident Response Playbook document covering incident classification taxonomy, severity tiers with quantitative criteria, containment actions per incident type, escalation matrix, and regulatory notification timelines", "Kill-switch capability validation records for each production agent, confirming suspension within the 60-second SLA in the most recent test", "Tabletop or functional test records for the AI Incident Response Playbook covering at least P1 and P2 severity scenarios", "Post-incident review records for all P1 and P2 events including root cause, containment timeline, and lessons-learned pipeline submissions" ], "evidence": [ { "id": "AG-05-E1", "description": "AI Incident Response Playbook document covering incident classification taxonomy, severity tiers with quantitative criteria, containment actions per incident type, escalation matrix, and regulatory notification timelines", "evidence_type": "incident-record", "verification": "attested" }, { "id": "AG-05-E2", "description": "Kill-switch capability validation records for each production agent, confirming suspension within the 60-second SLA in the most recent test", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "AG-05-E3", "description": "Tabletop or functional test records for the AI Incident Response Playbook covering at least P1 and P2 severity scenarios", "evidence_type": "incident-record", "verification": "attested" }, { "id": "AG-05-E4", "description": "Post-incident review records for all P1 and P2 events including root cause, containment timeline, and lessons-learned pipeline submissions", "evidence_type": "incident-record", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 73 requires providers and deployers to report serious incidents to national competent authorities within defined timeframes. An AI incident response program with regulatory notification procedures and defined reporting timelines directly addresses this mandatory serious incident reporting obligation." }, { "control": "apeiris://model/controls/CR-01", "id": "CR-01", "domain": "model", "name": "Continuous Production Monitoring and Risk Aggregation", "validation_objective": "All runtime monitoring signals \u2014 performance, drift, fairness, safety incidents, and deployment event flags \u2014 must be continuously aggregated into a unified risk dashboard with pre-configured automated alerting thresholds; any degradation in a monitored dimension must be detected and an alert dispatched within one operational window.", "blocking_effect": "advisory", "evidence_required": [ "risk_dashboard_configuration_record showing all registered signal feeds (performance, drift, fairness, safety, incident), their alert thresholds, assigned monitoring window duration, and escalation recipients", "alert_audit_log covering at least 30 days showing triggered alerts with signal_type, threshold_crossed, alert_timestamp, and escalation_recipient for each alert", "monitoring_coverage_audit confirming every deployed model version has an associated monitoring configuration with no version gaps", "risk_aggregation_methodology_document defining how individual dimension alerts are combined into composite risk scores and dashboard status indicators", "post-market_monitoring_report satisfying EU AI Act Art. 72 covering the monitoring period, key findings, and corrective actions taken or planned" ], "evidence": [ { "id": "CR-01-E1", "description": "risk_dashboard_configuration_record showing all registered signal feeds (performance, drift, fairness, safety, incident), their alert thresholds, assigned monitoring window duration, and escalation recipients", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-01-E2", "description": "alert_audit_log covering at least 30 days showing triggered alerts with signal_type, threshold_crossed, alert_timestamp, and escalation_recipient for each alert", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E3", "description": "monitoring_coverage_audit confirming every deployed model version has an associated monitoring configuration with no version gaps", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E4", "description": "risk_aggregation_methodology_document defining how individual dimension alerts are combined into composite risk scores and dashboard status indicators", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E5", "description": "post-market_monitoring_report satisfying EU AI Act Art. 72 covering the monitoring period, key findings, and corrective actions taken or planned", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 72 requires high-risk AI system providers to establish, document, and implement a post-market monitoring plan; CR-01's continuous risk aggregation dashboard \u2014 collecting signals from BH-01 through BH-10 layers and applying tiered alerting calibrated at \u00b12\u03c3 from baseline \u2014 operationalizes the systematic performance collection and anomaly identification components of a post-market monitoring plan." } ] }, { "requirement_id": "EU-AIA-ART55-01c", "section": "Art. 55(1)(c)", "title": "GPAI systemic risk \u2014 cybersecurity protection", "text": "Providers of GPAI models with systemic risk shall ensure an adequate level of cybersecurity protection for the GPAI model with systemic risk and the physical infrastructure of the model.", "verdict": "supported", "coverage": "direct", "notes": "AS-01 (Adversarial red-team and evaluate before launch) provides comprehensive cybersecurity testing for the model and its infrastructure. EC-01 (Run the agent in a sandbox, from process isolation up to micro-VMs) secures the physical and virtual infrastructure running GPAI models. GV-04 (Enforce policy as code at run time, in the request path) provides the runtime enforcement layer for cybersecurity controls on model access. TG-04 (Data Poisoning Prevention) protects the training pipeline \u2014 a key attack surface for GPAI models \u2014 from adversarial manipulation.", "control_count": 4, "proof_chain": [ { "control": "apeiris://security/controls/AS-01", "id": "AS-01", "domain": "security", "name": "Adversarially red-team and evaluate the agent before launch", "validation_objective": "Before any deployment to production, the agent must have passed a structured adversarial red-team exercise covering multi-turn goal hijack, tool misuse, and data exfiltration scenarios, with measured attack-success-rates at or below the defined launch threshold. Deployment must be blocked until the red-team pass/fail gate is cleared and documented.", "blocking_effect": "blocks-deployment", "evidence_required": [ "pre_launch_red_team_report listing each scenario (multi-turn hijack, tool-misuse, exfiltration), the attack-success-rate per scenario, the defined launch threshold, and a signed go/no-go decision", "multi_turn_eval_suite_run_log showing the agentic benchmark used (e.g., AgentDojo, FinBot CTF), commit SHA, run date, and overall pass/fail outcome against the threshold", "red_team_scope_document confirming coverage of multi-turn drift scenarios not only single-prompt tests, signed before the red-team exercise begins", "launch_gate_approval_record linking the red-team report to the deployment decision with approver identity and timestamp" ], "evidence": [ { "id": "AS-01-E1", "description": "pre_launch_red_team_report listing each scenario (multi-turn hijack, tool-misuse, exfiltration), the attack-success-rate per scenario, the defined launch threshold, and a signed go/no-go decision", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AS-01-E2", "description": "multi_turn_eval_suite_run_log showing the agentic benchmark used (e.g., AgentDojo, FinBot CTF), commit SHA, run date, and overall pass/fail outcome against the threshold", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "AS-01-E3", "description": "red_team_scope_document confirming coverage of multi-turn drift scenarios not only single-prompt tests, signed before the red-team exercise begins", "evidence_type": "red-team-report", "verification": "third-party" }, { "id": "AS-01-E4", "description": "launch_gate_approval_record linking the red-team report to the deployment decision with approver identity and timestamp", "evidence_type": "red-team-report", "verification": "third-party" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://security/controls/EC-01", "id": "EC-01", "domain": "security", "name": "Run the agent in a sandbox, from process isolation up to micro-VMs", "validation_objective": "Every agent must execute within an isolation tier matched to its threat profile, with untrusted-code agents deployed in a hypervisor-backed micro-VM (Firecracker or gVisor) that prevents direct access to the host kernel. The isolation tier must be declared in the deployment specification and cryptographically attested at runtime.", "blocking_effect": "blocks-deployment", "evidence_required": [ "sandbox_runtime_attestation confirming isolation_tier (process/gVisor/micro-VM), sandbox_type, and kernel_exposure_level for each agent run, captured at deployment time", "deployment_spec_record showing isolation_tier, sandbox_runtime, and seccomp_profile for each agent workload, diffed against the attested runtime configuration", "escape_test_result from known sandbox-escape payload execution inside the sandbox, recording reached_host (must be false), maximum_reached_boundary, and test_run_at", "syscall_profile_baseline showing the expected system call set for the agent workload and any deviations detected during runtime" ], "evidence": [ { "id": "EC-01-E1", "description": "sandbox_runtime_attestation confirming isolation_tier (process/gVisor/micro-VM), sandbox_type, and kernel_exposure_level for each agent run, captured at deployment time", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-01-E2", "description": "deployment_spec_record showing isolation_tier, sandbox_runtime, and seccomp_profile for each agent workload, diffed against the attested runtime configuration", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "EC-01-E3", "description": "escape_test_result from known sandbox-escape payload execution inside the sandbox, recording reached_host (must be false), maximum_reached_boundary, and test_run_at", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-01-E4", "description": "syscall_profile_baseline showing the expected system call set for the agent workload and any deviations detected during runtime", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://security/controls/GV-04", "id": "GV-04", "domain": "security", "name": "Enforce policy as code at run time, in the request path", "validation_objective": "A deterministic policy engine must be positioned in the request path for every agent action, evaluating each proposed action against current policy code and returning an allow/deny decision before execution; the engine must fail closed on evaluation error or uncertainty, and no agent action category may bypass policy evaluation.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "policy_decision_log with action_id, policy_version, decision (allow/deny), evaluation_latency_ms, and matched_policy_rule_id for each evaluated agent action", "fail_closed_test_record showing that disabling or erroring a policy detector caused the engine to deny the action rather than default to allow", "policy_engine_deployment_record confirming the engine is positioned in the request path as a pre-execution gate, not as a post-hoc advisory check", "policy_version_change_log with effective_from timestamp, changed_rules, and approving_authority for each policy update deployed to the request path" ], "evidence": [ { "id": "GV-04-E1", "description": "policy_decision_log with action_id, policy_version, decision (allow/deny), evaluation_latency_ms, and matched_policy_rule_id for each evaluated agent action", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-04-E2", "description": "fail_closed_test_record showing that disabling or erroring a policy detector caused the engine to deny the action rather than default to allow", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-04-E3", "description": "policy_engine_deployment_record confirming the engine is positioned in the request path as a pre-execution gate, not as a post-hoc advisory check", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-04-E4", "description": "policy_version_change_log with effective_from timestamp, changed_rules, and approving_authority for each policy update deployed to the request path", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://model/controls/TG-04", "id": "TG-04", "domain": "model", "name": "Data Poisoning Prevention", "validation_objective": "Every training shard must pass cryptographic integrity verification against a pre-ingestion hash before it is admitted to a training run; adversarial input screening must be applied at ingestion for all external or third-party data sources; and a chain-of-custody record must exist for every data transformation applied to the training corpus.", "blocking_effect": "blocks-deployment", "evidence_required": [ "training_shard_integrity_manifest listing the cryptographic hash (SHA-256 or stronger) for each shard, the verification timestamp, and the verification result (pass/fail/recomputed) for the current training run", "adversarial_screening_report for each external data source ingested, including the screening method applied, the number of records inspected, any detected anomalies or suspicious patterns, and the disposition (accepted/quarantined/rejected)", "chain_of_custody_record for each data transformation applied to the training corpus, including the transformation type, operator identity, input hash, output hash, and transformation timestamp", "supply_chain_integrity_check_record confirming that third-party training data packages (datasets, pretrained weights, synthetic data) were verified against vendor-provided manifests or signatures before use" ], "evidence": [ { "id": "TG-04-E1", "description": "training_shard_integrity_manifest listing the cryptographic hash (SHA-256 or stronger) for each shard, the verification timestamp, and the verification result (pass/fail/recomputed) for the current training run", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-04-E2", "description": "adversarial_screening_report for each external data source ingested, including the screening method applied, the number of records inspected, any detected anomalies or suspicious patterns, and the disposition (accepted/quarantined/rejected)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-04-E3", "description": "chain_of_custody_record for each data transformation applied to the training corpus, including the transformation type, operator identity, input hash, output hash, and transformation timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-04-E4", "description": "supply_chain_integrity_check_record confirming that third-party training data packages (datasets, pretrained weights, synthetic data) were verified against vendor-provided manifests or signatures before use", "evidence_type": "third-party-audit-report", "verification": "third-party" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "Data integrity controls support EU AI Act data quality requirements for high-risk AI" } ] }, { "requirement_id": "EU-AIA-ART55-01d", "section": "Art. 55(1)(d)", "title": "GPAI systemic risk \u2014 energy efficiency reporting", "text": "Providers of GPAI models with systemic risk shall report without undue delay to the AI Office information about serious incidents and possible corrective measures taken to address them, as well as information related to energy consumption.", "verdict": "partial", "coverage": "partial", "notes": "CR-05 (Regulatory Notification and Statutory Reporting) covers the serious incident reporting and corrective measures communication obligation to the AI Office. CI-03 (AI-Specific Compliance KPIs) can be configured to track and report energy-consumption metrics as a regulatory KPI. BH-07 (Resource and Cost Anomaly Monitoring) monitors computational resource consumption, which correlates with energy use. Partial: energy consumption reporting for GPAI models requires dedicated energy metering infrastructure and standardised reporting metrics (defined by AI Office codes of practice) that are technical infrastructure obligations substantially outside the Apeiris AI governance control plane.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/CR-05", "id": "CR-05", "domain": "model", "name": "Regulatory Notification and Statutory Reporting", "validation_objective": "The organization must maintain a current, legal-counsel-reviewed regulatory notification matrix mapping P1 severity incident events to all applicable jurisdictions, notification timelines (EU Art. 73: \u226415 calendar days for serious incidents; SR 26-2: immediate for material events), designated liaison and backup contacts, and pre-approved notification templates \u2014 with an automated countdown timer creation integrated into the CR-04 P1 escalation workflow and a complete archive of all notification submissions and delivery confirmations in CR-02.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Regulatory notification matrix document (version-controlled, legal-counsel reviewed within 12 months) listing jurisdiction, authority, trigger_event, timeline_days, liaison_contact, backup_contact, and template_ref for each row", "Pre-approved notification templates for each regulatory authority and jurisdiction, with legal counsel review date and version on record", "Notification task creation records showing automated countdown timers initiated for each P1 incident meeting notification criteria, with regulatory liaison page confirmation and timer expiry date", "All notification submissions and delivery confirmations archived in CR-02 with artifact_hash for the trailing 36 months", "Legal counsel sign-off record confirming annual review of all notification triggers and timelines, dated within 12 months" ], "evidence": [ { "id": "CR-05-E1", "description": "Regulatory notification matrix document (version-controlled, legal-counsel reviewed within 12 months) listing jurisdiction, authority, trigger_event, timeline_days, liaison_contact, backup_contact, and template_ref for each row", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CR-05-E2", "description": "Pre-approved notification templates for each regulatory authority and jurisdiction, with legal counsel review date and version on record", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CR-05-E3", "description": "Notification task creation records showing automated countdown timers initiated for each P1 incident meeting notification criteria, with regulatory liaison page confirmation and timer expiry date", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-05-E4", "description": "All notification submissions and delivery confirmations archived in CR-02 with artifact_hash for the trailing 36 months", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-05-E5", "description": "Legal counsel sign-off record confirming annual review of all notification triggers and timelines, dated within 12 months", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 72 requires post-market monitoring to cover systematic collection and analysis of user feedback and actual model performance outcomes; CR-05's outcomes and disparate impact analysis \u2014 comparing actual decisions against predicted outcomes and testing for differential impact across demographic cohorts \u2014 directly implements the outcome analysis component of post-market monitoring." }, { "control": "apeiris://compliance/controls/CI-03", "id": "CI-03", "domain": "compliance", "name": "AI-Specific Compliance KPIs", "validation_objective": "The compliance program must produce a defined set of AI-specific KPIs covering all five baseline dimensions (obligation coverage, evidence freshness, audit finding rate, remediation velocity, training completion) on a defined reporting cadence, with each KPI having a documented target threshold, a current measured value, and a trend direction indicator. No KPI may report a null measured_value at the defined reporting cadence without a documented exception.", "blocking_effect": "advisory", "evidence_required": [ "kpi_definition_register listing each KPI with kpi_id, name, definition, measurement_method, data_source, target_threshold, and reporting_frequency", "kpi_measurement_report for the current period containing measured_value, prior_period_value, trend_direction, and within_threshold flag for each defined KPI", "kpi_trend_history covering at least four consecutive reporting periods per KPI to enable trend analysis", "management_reporting_record confirming KPI results were presented to the compliance governance committee with attendance record and date", "remediation_action_record for each KPI where measured_value is outside the target_threshold, with root_cause, corrective_action, and target_return_to_threshold_date" ], "evidence": [ { "id": "CI-03-E1", "description": "kpi_definition_register listing each KPI with kpi_id, name, definition, measurement_method, data_source, target_threshold, and reporting_frequency", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-03-E2", "description": "kpi_measurement_report for the current period containing measured_value, prior_period_value, trend_direction, and within_threshold flag for each defined KPI", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-03-E3", "description": "kpi_trend_history covering at least four consecutive reporting periods per KPI to enable trend analysis", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-03-E4", "description": "management_reporting_record confirming KPI results were presented to the compliance governance committee with attendance record and date", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CI-03-E5", "description": "remediation_action_record for each KPI where measured_value is outside the target_threshold, with root_cause, corrective_action, and target_return_to_threshold_date", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Article 17(1)(i) requires the quality management system to include procedures related to the reporting of serious incidents in accordance with Article 73. CI-03's KPI program includes incident-reporting timeliness among the compliance performance signals measured and reported to governance stakeholders, evidencing that this quality management element is operating." }, { "control": "apeiris://model/controls/BH-07", "id": "BH-07", "domain": "model", "name": "Resource and Cost Anomaly Monitoring", "validation_objective": "The system must continuously monitor compute spend, token consumption, and API call volume per caller and model, with anomaly detection alerting within one operational window when any metric exceeds 2\u00d7 the rolling baseline; per-caller budget guardrails must automatically queue or block requests when the configured monthly spend cap is reached.", "blocking_effect": "advisory", "evidence_required": [ "cost_telemetry_pipeline_record showing CostEvent emission per request with caller_id, model_id, input_tokens, output_tokens, and cost_usd_estimated fields", "anomaly_detection_configuration_record showing baseline computation method (Z-score or EWMA), threshold multipliers, and evaluation window duration per caller and model", "budget_guardrail_configuration_record showing per-caller monthly spend cap, queue-activation threshold percentage, and hard-stop cap percentage for each active caller", "cost_spike_alert_log for any triggered alerts showing caller_id, time_window, observed_cost, baseline_cost, and anomaly_score with routing confirmation to MLOps on-call", "aml_t0024_correlation_record linking cost spike events to bulk inference volume patterns consistent with model extraction detection" ], "evidence": [ { "id": "BH-07-E1", "description": "cost_telemetry_pipeline_record showing CostEvent emission per request with caller_id, model_id, input_tokens, output_tokens, and cost_usd_estimated fields", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-07-E2", "description": "anomaly_detection_configuration_record showing baseline computation method (Z-score or EWMA), threshold multipliers, and evaluation window duration per caller and model", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "BH-07-E3", "description": "budget_guardrail_configuration_record showing per-caller monthly spend cap, queue-activation threshold percentage, and hard-stop cap percentage for each active caller", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-07-E4", "description": "cost_spike_alert_log for any triggered alerts showing caller_id, time_window, observed_cost, baseline_cost, and anomaly_score with routing confirmation to MLOps on-call", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "BH-07-E5", "description": "aml_t0024_correlation_record linking cost spike events to bulk inference volume patterns consistent with model extraction detection", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "adjacent", "basis": "anchored", "relation": "satisfies", "rationale": "EU AI Act Art. 55(1)(d) requires systemic GPAI providers to ensure adequate cybersecurity; BH-07's resource anomaly detection \u2014 monitoring GPU utilization, memory consumption, and inference latency for anomalies \u2014 provides an adjacent signal for detecting infrastructure-level attacks and resource exhaustion patterns that may indicate cybersecurity incidents." } ] } ] }, { "framework": "iso_42001", "label": "ISO/IEC 42001:2023", "source_id": "iso_42001", "anchored": true, "currency": { "version": "2023", "published_on": "2023-12-01", "status": "current", "retrieved_on": null }, "total_requirements": 44, "summary": { "supported": 23, "partial": 21, "unsupported": 0, "out-of-scope": 0, "controls_involved": 105, "evidence_artifacts": 476, "automatable_evidence": 129 }, "obligations": [ { "requirement_id": "ISO42001-4.1", "section": "\u00a74.1", "title": "Understanding the organization and its context", "text": "The organization shall determine external and internal issues relevant to its purpose and that affect its ability to achieve the intended outcome(s) of its AIMS.", "verdict": "partial", "coverage": "partial", "notes": "Apeiris covers AI-specific operating context and regulatory scope determination. General organizational context (business environment, market factors) is out of scope for Apeiris domain controls.", "control_count": 3, "proof_chain": [ { "control": "apeiris://authority/controls/PV-01", "id": "PV-01", "domain": "authority", "name": "Operating Intent Declaration", "validation_objective": "Every active AI system deployment must have a machine-readable, cryptographically signed intent declaration registered in the authority control registry before production activation. The deployment pipeline must block agent activation when no valid, unexpired declaration with all required schema fields is present.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Signed intent declaration artifact with canonical_id, authorized_action_types, context_scope, principal_id, valid_from, and valid_until fields for every active AI deployment", "Deployment gate rejection logs demonstrating that agent activations without a registered, unexpired declaration were blocked, with fields for system_id, attempted_at, and rejection_reason", "Authority control registry export cross-referencing each active deployment to its current declaration record and cryptographic signature", "Principal authorization verification record confirming the signing identity has organizational authority to bind the enterprise to the declared scope", "Renewal audit trail linking declaration version history to deployment lifecycle events and authorizing principal identity" ], "evidence": [ { "id": "PV-01-E1", "description": "Signed intent declaration artifact with canonical_id, authorized_action_types, context_scope, principal_id, valid_from, and valid_until fields for every active AI deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PV-01-E2", "description": "Deployment gate rejection logs demonstrating that agent activations without a registered, unexpired declaration were blocked, with fields for system_id, attempted_at, and rejection_reason", "evidence_type": "audit-log", "verification": "automated" }, { "id": "PV-01-E3", "description": "Authority control registry export cross-referencing each active deployment to its current declaration record and cryptographic signature", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "PV-01-E4", "description": "Principal authorization verification record confirming the signing identity has organizational authority to bind the enterprise to the declared scope", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PV-01-E5", "description": "Renewal audit trail linking declaration version history to deployment lifecycle events and authorizing principal identity", "evidence_type": "audit-log", "verification": "automated" } ], "fit": "adjacent", "basis": "anchored", "relation": "equivalent_to", "rationale": "Declaring authorized scope anchors authority but is not itself a risk-treatment action under \u00a76.1." }, { "control": "apeiris://authority/controls/PV-03", "id": "PV-03", "domain": "authority", "name": "Intended Purpose Alignment Review", "validation_objective": "All active AI deployments must have a documented alignment review completed within the defined risk-tiered cadence. Each review must compare a structured behavioral log against the deployed behavioral profile and produce a signed review record; any material drift finding must trigger a re-authorization workflow before the system continues operating unchanged.", "blocking_effect": "requires-review", "evidence_required": [ "Behavioral profile specification linked to each active intent declaration, defining expected action type distribution ranges, resource access frequency bands, and acceptable escalation trigger rates for the review period", "Structured behavioral log summaries covering the review period, with action type distributions, resource access patterns, and anomaly event counts compared against profile thresholds", "Signed alignment review records with reviewer_id, comparison_methodology, drift_findings, determination_of_alignment, and review_completed_at for all active deployments within the defined cadence", "Re-authorization records for any deployment where material drift was identified, including the triggering drift finding, remediation action, and updated or reaffirmed intent declaration version" ], "evidence": [ { "id": "PV-03-E1", "description": "Behavioral profile specification linked to each active intent declaration, defining expected action type distribution ranges, resource access frequency bands, and acceptable escalation trigger rates for the review period", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PV-03-E2", "description": "Structured behavioral log summaries covering the review period, with action type distributions, resource access patterns, and anomaly event counts compared against profile thresholds", "evidence_type": "audit-log", "verification": "automated" }, { "id": "PV-03-E3", "description": "Signed alignment review records with reviewer_id, comparison_methodology, drift_findings, determination_of_alignment, and review_completed_at for all active deployments within the defined cadence", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PV-03-E4", "description": "Re-authorization records for any deployment where material drift was identified, including the triggering drift finding, remediation action, and updated or reaffirmed intent declaration version", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "The risk-tiered alignment review cadence directly satisfies \u00a79.1 monitoring, measurement, analysis, and evaluation." }, { "control": "apeiris://compliance/controls/CA-01", "id": "CA-01", "domain": "compliance", "name": "Regulatory Scope Determination", "validation_objective": "Every AI system in the compliance registry must have an approved, version-controlled scope record that correctly identifies all applicable regulatory regimes based on its deployment jurisdiction, sector, data categories, and capability tier, and that was reviewed following the most recent material change to deployment context or applicable regulatory publication. Deployment pipeline advancement must be blocked for any system without an approved scope record.", "blocking_effect": "blocks-deployment", "evidence_required": [ "compliance_registry_scope_record containing system_id, applicable_regimes[], triggering_criteria[], approved_by, approved_at, and version_id demonstrating a complete and current classification", "regulatory_trigger_matrix with version_date and last_reviewed_on within 30 days of the most recent applicable regulatory publication affecting AI systems in the organization's jurisdictions", "deployment_gate_log entry for the AI system showing scope_record_approval_status was checked before production promotion with artifact scope_record_id referenced", "escalation_record for any ambiguous classification decisions showing legal_counsel_sign_off, resolution_rationale, and resolution_date within the defined SLA" ], "evidence": [ { "id": "CA-01-E1", "description": "compliance_registry_scope_record containing system_id, applicable_regimes[], triggering_criteria[], approved_by, approved_at, and version_id demonstrating a complete and current classification", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-01-E2", "description": "regulatory_trigger_matrix with version_date and last_reviewed_on within 30 days of the most recent applicable regulatory publication affecting AI systems in the organization's jurisdictions", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-01-E3", "description": "deployment_gate_log entry for the AI system showing scope_record_approval_status was checked before production promotion with artifact scope_record_id referenced", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-01-E4", "description": "escalation_record for any ambiguous classification decisions showing legal_counsel_sign_off, resolution_rationale, and resolution_date within the defined SLA", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001:2023 \u00a74.1 requires organisations to determine external and internal factors affecting AI management; CA-01 regulatory scope determination is the AI-specific implementation of this clause." } ] }, { "requirement_id": "ISO42001-4.2", "section": "\u00a74.2", "title": "Understanding needs and expectations of interested parties", "text": "The organization shall determine the interested parties that are relevant to the AIMS and the relevant requirements of those interested parties.", "verdict": "partial", "coverage": "partial", "notes": "Apeiris obligation register and contractual obligation controls address AI-relevant stakeholder requirements. Broader stakeholder mapping and non-AI interested party management is outside Apeiris scope.", "control_count": 3, "proof_chain": [ { "control": "apeiris://compliance/controls/OB-01", "id": "OB-01", "domain": "compliance", "name": "Obligation Register", "validation_objective": "An authoritative, machine-readable obligation register must exist for every AI system in production, containing each applicable regulatory, contractual, and certification obligation with its source instrument, jurisdiction, fulfillment status, and linkage to the AI system identifier. No AI system may reach production without an approved obligation register entry in the compliance registry.", "blocking_effect": "blocks-deployment", "evidence_required": [ "obligation_register record per AI system with system_id, obligation_id, source_instrument, jurisdiction, obligation_type (regulatory/contractual/certification), and fulfillment_status for each obligation", "compliance_registry deployment_gate log confirming obligation register approval as a prerequisite to production promotion for each AI system", "obligation_register_version_history showing review timestamps and approver identity for each update to the register", "cross-reference report mapping each obligation_id to the CA-01 scope_record and CA-02 obligation_map entries that originally triggered it" ], "evidence": [ { "id": "OB-01-E1", "description": "obligation_register record per AI system with system_id, obligation_id, source_instrument, jurisdiction, obligation_type (regulatory/contractual/certification), and fulfillment_status for each obligation", "evidence_type": "certification", "verification": "third-party" }, { "id": "OB-01-E2", "description": "compliance_registry deployment_gate log confirming obligation register approval as a prerequisite to production promotion for each AI system", "evidence_type": "audit-log", "verification": "automated" }, { "id": "OB-01-E3", "description": "obligation_register_version_history showing review timestamps and approver identity for each update to the register", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OB-01-E4", "description": "cross-reference report mapping each obligation_id to the CA-01 scope_record and CA-02 obligation_map entries that originally triggered it", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://compliance/controls/OB-02", "id": "OB-02", "domain": "compliance", "name": "Obligation Owner Assignment", "validation_objective": "Every obligation in the obligation register must have a named, active individual assigned as owner and a designated deputy, with a documented escalation path, such that for any obligation in the register it is possible to identify the accountable person, their deputy, and the escalation chain without ambiguity or vacancy. No obligation may exist in the register in an owner-unassigned state beyond the defined assignment SLA.", "blocking_effect": "requires-review", "evidence_required": [ "obligation_owner_record per obligation showing owner_name, owner_role, owner_contact, deputy_name, deputy_contact, assigned_at timestamp, and escalation_path identifier", "escalation_path document defining the chain of escalation above the named owner, with named individuals at each escalation tier and response time commitments", "owner_assignment_audit_log showing all ownership changes, vacancy events, and deputy activations with timestamps and triggering events", "obligation_registry staleness report confirming no obligations have been in owner-unassigned status beyond the defined assignment SLA (target: 5 business days)" ], "evidence": [ { "id": "OB-02-E1", "description": "obligation_owner_record per obligation showing owner_name, owner_role, owner_contact, deputy_name, deputy_contact, assigned_at timestamp, and escalation_path identifier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OB-02-E2", "description": "escalation_path document defining the chain of escalation above the named owner, with named individuals at each escalation tier and response time commitments", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OB-02-E3", "description": "owner_assignment_audit_log showing all ownership changes, vacancy events, and deputy activations with timestamps and triggering events", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OB-02-E4", "description": "obligation_registry staleness report confirming no obligations have been in owner-unassigned status beyond the defined assignment SLA (target: 5 business days)", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://authority/controls/PO-03", "id": "PO-03", "domain": "authority", "name": "Contractual Obligation Extraction", "validation_objective": "Every executed contract within AI-relevant scope must be processed by the obligation extraction pipeline within 10 business days of signing, producing a structured obligation manifest with source clause citations. All extracted obligations must be mapped to authority register entries with a General Counsel review sign-off before the mapping takes effect in AI deployment authority evaluation, and no AI deployment may be activated under a contract whose obligations have not been fully extracted, mapped, and reviewed.", "blocking_effect": "blocks-deployment", "evidence_required": [ "obligation_extraction_manifest for each in-scope executed contract, containing source_contract_id, clause_location, obligation_type, authority_impact, and extraction_timestamp", "contract_intake_pipeline_audit_log showing each contract's ingestion date, extraction completion date, and days-to-extraction for SLA compliance tracking", "general_counsel_obligation_review_sign_offs confirming each obligation mapping was reviewed and approved by legal counsel with review_date and reviewer identity", "authority_register_entries_with_contractual_origin showing obligation-to-constraint mappings with back-references to the source contract and clause identifier" ], "evidence": [ { "id": "PO-03-E1", "description": "obligation_extraction_manifest for each in-scope executed contract, containing source_contract_id, clause_location, obligation_type, authority_impact, and extraction_timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-03-E2", "description": "contract_intake_pipeline_audit_log showing each contract's ingestion date, extraction completion date, and days-to-extraction for SLA compliance tracking", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-03-E3", "description": "general_counsel_obligation_review_sign_offs confirming each obligation mapping was reviewed and approved by legal counsel with review_date and reviewer identity", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PO-03-E4", "description": "authority_register_entries_with_contractual_origin showing obligation-to-constraint mappings with back-references to the source contract and clause identifier", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "Mapping contractual obligations to AI authority limits is operational planning under \u00a78.1, partially." } ] }, { "requirement_id": "ISO42001-4.3", "section": "\u00a74.3", "title": "Determining scope of the AI management system", "text": "The organization shall determine the boundaries and applicability of the AIMS to establish its scope, taking into account external and internal issues, requirements of interested parties, and AI systems provided or used.", "verdict": "partial", "coverage": "partial", "notes": "Deployment scope attestation and cross-domain evidence routing support AI scope definition. Formal AIMS boundary documentation as required for certification requires additional organizational process controls.", "control_count": 3, "proof_chain": [ { "control": "apeiris://authority/controls/PV-07", "id": "PV-07", "domain": "authority", "name": "Deployment Scope Attestation", "validation_objective": "Every active AI deployment must have a current, signed deployment scope attestation in the authority registry enumerating authorized geographic regions, legal entities, user population categories, use-case types, and applicable regulatory jurisdictions. The attestation must bear the signature of a named principal with verifiable authority over the declared scope dimensions, and runtime monitoring must detect and alert on AI activity outside attested boundaries.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Signed deployment scope attestation artifacts in the authority registry for all active AI deployments, with fields for geographic_regions, legal_entities, user_population_categories, use_case_types, applicable_jurisdictions, signatory_id, valid_from, and valid_until", "Signatory authority verification records confirming each signing principal has organizational authority over the specific geographic, legal entity, and jurisdictional scope dimensions they attested", "Out-of-scope activity monitoring alerts for any AI system operation detected outside attested boundaries, with system_id, detected_activity, attested_scope, and detection_timestamp", "Renewal records showing timely scope attestation renewal at defined intervals and following material scope dimension changes such as new market entry or entity restructuring" ], "evidence": [ { "id": "PV-07-E1", "description": "Signed deployment scope attestation artifacts in the authority registry for all active AI deployments, with fields for geographic_regions, legal_entities, user_population_categories, use_case_types, applicable_jurisdictions, signatory_id, valid_from, and valid_until", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PV-07-E2", "description": "Signatory authority verification records confirming each signing principal has organizational authority over the specific geographic, legal entity, and jurisdictional scope dimensions they attested", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PV-07-E3", "description": "Out-of-scope activity monitoring alerts for any AI system operation detected outside attested boundaries, with system_id, detected_activity, attested_scope, and detection_timestamp", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "PV-07-E4", "description": "Renewal records showing timely scope attestation renewal at defined intervals and following material scope dimension changes such as new market entry or entity restructuring", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "Scope attestation at deployment is an operational-control artifact, partially satisfying \u00a78.1." }, { "control": "apeiris://authority/controls/PV-01", "id": "PV-01", "domain": "authority", "name": "Operating Intent Declaration", "validation_objective": "Every active AI system deployment must have a machine-readable, cryptographically signed intent declaration registered in the authority control registry before production activation. The deployment pipeline must block agent activation when no valid, unexpired declaration with all required schema fields is present.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Signed intent declaration artifact with canonical_id, authorized_action_types, context_scope, principal_id, valid_from, and valid_until fields for every active AI deployment", "Deployment gate rejection logs demonstrating that agent activations without a registered, unexpired declaration were blocked, with fields for system_id, attempted_at, and rejection_reason", "Authority control registry export cross-referencing each active deployment to its current declaration record and cryptographic signature", "Principal authorization verification record confirming the signing identity has organizational authority to bind the enterprise to the declared scope", "Renewal audit trail linking declaration version history to deployment lifecycle events and authorizing principal identity" ], "evidence": [ { "id": "PV-01-E1", "description": "Signed intent declaration artifact with canonical_id, authorized_action_types, context_scope, principal_id, valid_from, and valid_until fields for every active AI deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PV-01-E2", "description": "Deployment gate rejection logs demonstrating that agent activations without a registered, unexpired declaration were blocked, with fields for system_id, attempted_at, and rejection_reason", "evidence_type": "audit-log", "verification": "automated" }, { "id": "PV-01-E3", "description": "Authority control registry export cross-referencing each active deployment to its current declaration record and cryptographic signature", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "PV-01-E4", "description": "Principal authorization verification record confirming the signing identity has organizational authority to bind the enterprise to the declared scope", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PV-01-E5", "description": "Renewal audit trail linking declaration version history to deployment lifecycle events and authorizing principal identity", "evidence_type": "audit-log", "verification": "automated" } ], "fit": "adjacent", "basis": "anchored", "relation": "equivalent_to", "rationale": "Declaring authorized scope anchors authority but is not itself a risk-treatment action under \u00a76.1." }, { "control": "apeiris://compliance/controls/CA-03", "id": "CA-03", "domain": "compliance", "name": "Cross-Domain Evidence Routing", "validation_objective": "Every compliance obligation in the CA-02 harmonized obligation map must have at least one entry in the cross-domain evidence routing table specifying the producing Apeiris domain, attestation type, and evidence field mappings, and automated evidence assembly must successfully produce a valid evidence package with all referenced attestations within their valid_until window when queried on demand.", "blocking_effect": "requires-review", "evidence_required": [ "cross_domain_routing_table entries keyed by compliance_obligation_id, each containing producing_domain (Apeiris domain slug), attestation_type, control_prefix, evidence_field_mappings[], and last_validated_on timestamp", "automated_evidence_assembly_log showing successful assembly for a representative 20% sample of obligations, with package_id, assembled_at, and valid_until for each attestation included in the package", "routing_coverage_report comparing routing table obligation_id count against CA-02 obligation map requirement count, with gap_percentage metric and CA-06 routing for any gaps", "domain_attestation_registry_query_logs confirming routing table entries resolve to attestations with status='valid' and valid_until > current_date for each sampled obligation" ], "evidence": [ { "id": "CA-03-E1", "description": "cross_domain_routing_table entries keyed by compliance_obligation_id, each containing producing_domain (Apeiris domain slug), attestation_type, control_prefix, evidence_field_mappings[], and last_validated_on timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-03-E2", "description": "automated_evidence_assembly_log showing successful assembly for a representative 20% sample of obligations, with package_id, assembled_at, and valid_until for each attestation included in the package", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-03-E3", "description": "routing_coverage_report comparing routing table obligation_id count against CA-02 obligation map requirement count, with gap_percentage metric and CA-06 routing for any gaps", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-03-E4", "description": "domain_attestation_registry_query_logs confirming routing table entries resolve to attestations with status='valid' and valid_until > current_date for each sampled obligation", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "ISO42001-4.4", "section": "\u00a74.4", "title": "AI management system", "text": "The organization shall establish, implement, maintain, and continually improve an AIMS, including the processes needed and their interactions.", "verdict": "partial", "coverage": "partial", "notes": "Compliance governance structure and ISO 42001 certification pathway control (RF-07) directly support AIMS establishment. Apeiris defines the evidence and control layer; the management system wrapper (documentation, process integration) is an organizational responsibility.", "control_count": 4, "proof_chain": [ { "control": "apeiris://compliance/controls/CG-01", "id": "CG-01", "domain": "compliance", "name": "Compliance Governance Structure", "validation_objective": "The organization must have a formally chartered Compliance Committee with documented meeting minutes showing quorum was achieved in at least 80% of scheduled sessions in the last 12 months, a CCO or equivalent with a documented direct reporting channel to the board Audit and Risk Committee that bypasses management for material issues, and a current escalation matrix reviewed within 12 months covering all material compliance issue types including AI regulatory incidents.", "blocking_effect": "requires-review", "evidence_required": [ "compliance_committee_charter signed and approved by the board with defined membership composition, quorum rules, meeting cadence, decision authority scope, and AI regulatory obligation coverage", "cco_role_documentation including the CCO written authority scope, direct reporting line to the Audit and Risk Committee as documented in board resolution or equivalent formal governance instrument, and organizational chart placement", "compliance_committee_meeting_minutes for the last 12 months showing attendees, quorum status at each session, agenda items including AI compliance matters, and action item tracking with completion status", "escalation_matrix covering all material compliance issue types \u2014 regulatory inquiry, enforcement action, material AI risk event, data breach \u2014 with defined escalation paths, response timeframes, and responsible parties for each tier", "board_resolution or formal charter ratification record establishing the compliance governance structure with effective date and scope of authority" ], "evidence": [ { "id": "CG-01-E1", "description": "compliance_committee_charter signed and approved by the board with defined membership composition, quorum rules, meeting cadence, decision authority scope, and AI regulatory obligation coverage", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-01-E2", "description": "cco_role_documentation including the CCO written authority scope, direct reporting line to the Audit and Risk Committee as documented in board resolution or equivalent formal governance instrument, and organizational chart placement", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-01-E3", "description": "compliance_committee_meeting_minutes for the last 12 months showing attendees, quorum status at each session, agenda items including AI compliance matters, and action item tracking with completion status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-01-E4", "description": "escalation_matrix covering all material compliance issue types \u2014 regulatory inquiry, enforcement action, material AI risk event, data breach \u2014 with defined escalation paths, response timeframes, and responsible parties for each tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-01-E5", "description": "board_resolution or formal charter ratification record establishing the compliance governance structure with effective date and scope of authority", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://compliance/controls/CG-02", "id": "CG-02", "domain": "compliance", "name": "Compliance Policy Framework for AI", "validation_objective": "The organization must maintain a board-approved enterprise AI compliance policy, a regulatory inventory covering all applicable frameworks across all jurisdictions of AI operation updated within 30 days of any material regulatory change, and a documented policy hierarchy extending from the enterprise policy to system-specific procedures for every AI system in production, with all policy documents reviewed within the last 14 months and a demonstrated process for completing policy updates within 90 days of material regulatory change.", "blocking_effect": "requires-review", "evidence_required": [ "board_approved_enterprise_ai_compliance_policy with formal board ratification record, approval date within the last 14 months, and defined scope covering all applicable AI regulatory obligations across all operating jurisdictions", "regulatory_inventory spanning all jurisdictions of AI operation listing all applicable frameworks, assigned obligation owners for each framework, and last update date confirming review within 30 days of any material regulatory change", "policy_coverage_map linking every AI system in the production AI inventory to at least one policy document with a named owner, last review date within 14 months, and applicable regulatory frameworks identified", "regulatory_change_tracking_log for the last 24 months showing detected regulatory changes, policy update decisions triggered, update completion dates, and compliance with the 90-day response target for each change", "framework_specific_standards_documentation for each applicable regulatory framework, mapping framework requirements to internal controls and assigning named owners responsible for each obligation" ], "evidence": [ { "id": "CG-02-E1", "description": "board_approved_enterprise_ai_compliance_policy with formal board ratification record, approval date within the last 14 months, and defined scope covering all applicable AI regulatory obligations across all operating jurisdictions", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-02-E2", "description": "regulatory_inventory spanning all jurisdictions of AI operation listing all applicable frameworks, assigned obligation owners for each framework, and last update date confirming review within 30 days of any material regulatory change", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-02-E3", "description": "policy_coverage_map linking every AI system in the production AI inventory to at least one policy document with a named owner, last review date within 14 months, and applicable regulatory frameworks identified", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-02-E4", "description": "regulatory_change_tracking_log for the last 24 months showing detected regulatory changes, policy update decisions triggered, update completion dates, and compliance with the 90-day response target for each change", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-02-E5", "description": "framework_specific_standards_documentation for each applicable regulatory framework, mapping framework requirements to internal controls and assigning named owners responsible for each obligation", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://authority/controls/PG-01", "id": "PG-01", "domain": "authority", "name": "Policy Adherence Monitoring", "validation_objective": "All in-scope AI systems must have 100% of their active internal policies represented by machine-evaluable monitoring rules in the policy registry, with every AI system action evaluated against applicable rules in real time, and deviation alerts routed to accountable reviewers within the documented SLA.", "blocking_effect": "advisory", "evidence_required": [ "Policy registry export listing all active internal policies with corresponding machine-evaluable rule definitions, effective dates, and policy source references", "Policy evaluation engine event logs showing per-action rule evaluation outcomes, deviation alert generation timestamps, and SLA compliance metrics for the reporting period", "Compliance monitoring SLA definition document signed by the Compliance Officer, specifying alert routing targets and resolution timeframes", "Monitoring coverage report confirming the percentage of in-scope AI systems and action types evaluated against active policy rules, with no coverage gaps documented without risk acceptance" ], "evidence": [ { "id": "PG-01-E1", "description": "Policy registry export listing all active internal policies with corresponding machine-evaluable rule definitions, effective dates, and policy source references", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "PG-01-E2", "description": "Policy evaluation engine event logs showing per-action rule evaluation outcomes, deviation alert generation timestamps, and SLA compliance metrics for the reporting period", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "PG-01-E3", "description": "Compliance monitoring SLA definition document signed by the Compliance Officer, specifying alert routing targets and resolution timeframes", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "PG-01-E4", "description": "Monitoring coverage report confirming the percentage of in-scope AI systems and action types evaluated against active policy rules, with no coverage gaps documented without risk acceptance", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "Continuous policy-adherence monitoring directly implements \u00a79.1 monitoring, measurement, and evaluation." }, { "control": "apeiris://compliance/controls/RF-07", "id": "RF-07", "domain": "compliance", "name": "ISO 42001 Certification Pathway", "validation_objective": "The enterprise must have completed a formal ISO 42001 gap assessment against all clauses, defined a scope statement covering material AI operations, and either achieved initial certification or is executing an active gap closure roadmap with milestone adherence above 80% and a scheduled certification body engagement date. No material AI operation may be excluded from the defined AIMS scope without documented justification.", "blocking_effect": "blocks-deployment", "evidence_required": [ "iso_42001_gap_assessment_report documenting current maturity and gap severity ratings against all clauses of ISO/IEC 42001:2023 with completion date", "aims_scope_statement signed by executive leadership defining the AI systems, organizational units, and processes in scope with explicit exclusions and their justifications", "ai_management_system_policy document signed by executive leadership establishing the AI policy, objectives, and governance framework", "gap_closure_roadmap with milestone schedule, owner assignments, target completion dates, and current milestone adherence rate", "internal_audit_record covering the complete ISO 42001 clause set with findings, ratings, and remediation status" ], "evidence": [ { "id": "RF-07-E1", "description": "iso_42001_gap_assessment_report documenting current maturity and gap severity ratings against all clauses of ISO/IEC 42001:2023 with completion date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RF-07-E2", "description": "aims_scope_statement signed by executive leadership defining the AI systems, organizational units, and processes in scope with explicit exclusions and their justifications", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RF-07-E3", "description": "ai_management_system_policy document signed by executive leadership establishing the AI policy, objectives, and governance framework", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RF-07-E4", "description": "gap_closure_roadmap with milestone schedule, owner assignments, target completion dates, and current milestone adherence rate", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RF-07-E5", "description": "internal_audit_record covering the complete ISO 42001 clause set with findings, ratings, and remediation status", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "ISO42001-5.1", "section": "\u00a75.1", "title": "Leadership and commitment", "text": "Top management shall demonstrate leadership and commitment with respect to the AIMS by ensuring AI policy and objectives are established, integrating AIMS requirements into the organization's processes, and ensuring the AIMS achieves its intended outcomes.", "verdict": "partial", "coverage": "partial", "notes": "Senior and board-level accountability controls across compliance, ethics, and agentic domains address leadership accountability. Demonstrating active leadership commitment (as opposed to evidencing it post-hoc) is an organizational behavior not fully capturable in a control matrix.", "control_count": 4, "proof_chain": [ { "control": "apeiris://compliance/controls/CG-03", "id": "CG-03", "domain": "compliance", "name": "Senior and Board-Level Accountability for AI Compliance", "validation_objective": "The board of directors has a formal, documented mandate for AI compliance oversight via committee resolution, an executive owner is designated in their role charter with AI compliance accountability, and at least one quarterly board compliance report has been presented within the current 90-day window with meeting minutes documenting AI compliance as a substantive agenda item and material risks discussed.", "blocking_effect": "requires-review", "evidence_required": [ "board_resolution_document with committee_name, effective_date, scope (AI compliance oversight mandate), and authorizing_signatories confirming formal assignment of AI compliance oversight", "executive_role_charter or position_description for CCO or designated executive containing explicit AI compliance accountability language and board reporting obligation, with effective_date and incumbent name", "compliance_committee_meeting_minutes from each of the prior four quarters documenting AI compliance agenda item, attendance by designated executive, and material risks discussed or acknowledged", "ai_compliance_dashboard report presented to board, timestamped within the prior 90 days, with KPI section, regulatory obligation status, and material risk disclosures" ], "evidence": [ { "id": "CG-03-E1", "description": "board_resolution_document with committee_name, effective_date, scope (AI compliance oversight mandate), and authorizing_signatories confirming formal assignment of AI compliance oversight", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-03-E2", "description": "executive_role_charter or position_description for CCO or designated executive containing explicit AI compliance accountability language and board reporting obligation, with effective_date and incumbent name", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-03-E3", "description": "compliance_committee_meeting_minutes from each of the prior four quarters documenting AI compliance agenda item, attendance by designated executive, and material risks discussed or acknowledged", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-03-E4", "description": "ai_compliance_dashboard report presented to board, timestamped within the prior 90 days, with KPI section, regulatory obligation status, and material risk disclosures", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://authority/controls/PE-06", "id": "PE-06", "domain": "authority", "name": "Board and Senior Management Policy Reporting", "validation_objective": "Quarterly AI policy governance reports must be produced on schedule, reviewed, and co-signed by both the Chief Risk Officer and General Counsel, with every reported metric traceable to a supporting evidence item in the PE-04 integrated package. All risk items exceeding the board-approved materiality thresholds must appear in the report with prioritized escalation recommendations and documented board response within 30 days.", "blocking_effect": "requires-review", "evidence_required": [ "board_ai_policy_governance_report with executive summary, risk-adjusted metrics, open gap inventory, and escalation recommendations, dated within the quarterly reporting cycle and referencing the PE-04 integrated package version used", "report_sign_off_log showing CRO identity, General Counsel identity, individual sign-off timestamps, and SHA-256 hash of the signed report version to detect post-signature modification", "materiality_threshold_schedule approved by the CRO and version-controlled, defining numeric thresholds for AI policy risk metrics that trigger mandatory board-level reporting and escalation", "report_distribution_log recording recipient role, distribution timestamp, and acknowledgment status for each quarterly report to confirm the board actually received the report" ], "evidence": [ { "id": "PE-06-E1", "description": "board_ai_policy_governance_report with executive summary, risk-adjusted metrics, open gap inventory, and escalation recommendations, dated within the quarterly reporting cycle and referencing the PE-04 integrated package version used", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PE-06-E2", "description": "report_sign_off_log showing CRO identity, General Counsel identity, individual sign-off timestamps, and SHA-256 hash of the signed report version to detect post-signature modification", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PE-06-E3", "description": "materiality_threshold_schedule approved by the CRO and version-controlled, defining numeric thresholds for AI policy risk metrics that trigger mandatory board-level reporting and escalation", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PE-06-E4", "description": "report_distribution_log recording recipient role, distribution timestamp, and acknowledgment status for each quarterly report to confirm the board actually received the report", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://ethics/controls/EG-03", "id": "EG-03", "domain": "ethics", "name": "Senior and Board-Level Ethics Accountability", "validation_objective": "The organization must have a named C-suite executive with documented AI ethics accountability and evidence of at least semi-annual board-level AI ethics briefings within the trailing 12 months. Executive performance objectives must include AI ethics KPIs linked to measurable program outcomes.", "blocking_effect": "requires-review", "evidence_required": [ "executive_accountability_assignment showing named C-suite role, documented accountability scope, and date of assignment in role description or governance framework", "board_briefing_records from past 12 months confirming AI ethics posture, material risks, and incident status were presented, with meeting minutes or attendance logs", "executive_performance_objectives document showing AI ethics KPIs included in C-suite scorecards with defined targets and measurement periods", "material_risk_escalation_procedure document defining thresholds that trigger immediate C-suite notification with named escalation contacts and SLA" ], "evidence": [ { "id": "EG-03-E1", "description": "executive_accountability_assignment showing named C-suite role, documented accountability scope, and date of assignment in role description or governance framework", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-03-E2", "description": "board_briefing_records from past 12 months confirming AI ethics posture, material risks, and incident status were presented, with meeting minutes or attendance logs", "evidence_type": "incident-record", "verification": "attested" }, { "id": "EG-03-E3", "description": "executive_performance_objectives document showing AI ethics KPIs included in C-suite scorecards with defined targets and measurement periods", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-03-E4", "description": "material_risk_escalation_procedure document defining thresholds that trigger immediate C-suite notification with named escalation contacts and SLA", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001:2023 \u00a75.1 requires top management to demonstrate leadership and commitment to the AI management system, including establishing accountability structures. This control directly operationalizes that leadership commitment requirement." }, { "control": "apeiris://agentic/controls/AG-04", "id": "AG-04", "domain": "agentic", "name": "Senior Accountability for Autonomous AI Systems", "validation_objective": "Every AI agent operating at Medium consequence tier or above has a named accountable owner recorded in both the agent registry and the enterprise risk register, and that owner has formally signed the agent's authorization scope declaration and completed their most recent annual reaffirmation.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Agent registry entries for all Medium-tier-and-above agents showing named accountable owner, seniority level, assignment date, and scope declaration reference", "Signed authorization scope declaration for each in-scope agent, bearing the accountable owner's identity and the date of most recent reaffirmation", "Enterprise risk register entries linking each in-scope agent to its named accountable owner and consequence tier", "Annual reaffirmation records for each accountable owner assignment, confirming reaffirmation within the required cadence" ], "evidence": [ { "id": "AG-04-E1", "description": "Agent registry entries for all Medium-tier-and-above agents showing named accountable owner, seniority level, assignment date, and scope declaration reference", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-04-E2", "description": "Signed authorization scope declaration for each in-scope agent, bearing the accountable owner's identity and the date of most recent reaffirmation", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-04-E3", "description": "Enterprise risk register entries linking each in-scope agent to its named accountable owner and consequence tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-04-E4", "description": "Annual reaffirmation records for each accountable owner assignment, confirming reaffirmation within the required cadence", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 Clause 5.3 requires top management to assign and communicate organizational roles and responsibilities for the AI management system. Named accountable owners with defined responsibilities, signed acceptance, and annual reaffirmation cycles directly satisfy this organizational accountability requirement." } ] }, { "requirement_id": "ISO42001-5.2", "section": "\u00a75.2", "title": "Policy", "text": "Top management shall establish an AI policy that is appropriate to the purpose of the organization, includes AI objectives or provides a framework for setting them, includes a commitment to satisfy applicable requirements, and includes a commitment to continual improvement.", "verdict": "supported", "coverage": "direct", "notes": "Internal policy register, policy version control, compliance policy framework for AI, and regulatory disclosure readiness controls together address the full policy clause requirements.", "control_count": 4, "proof_chain": [ { "control": "apeiris://authority/controls/PO-01", "id": "PO-01", "domain": "authority", "name": "Internal Policy Register for AI Deployments", "validation_objective": "Every active AI deployment must have at least one current, non-expired policy register entry in the authoritative policy register, and that entry must contain version, effective date, scope, owning team, and deployment linkage fields. No AI deployment may enter or remain in production without a valid policy register reference confirmed by the deployment pipeline.", "blocking_effect": "blocks-deployment", "evidence_required": [ "policy_register_schema_document specifying required fields including policy_id, version, effective_date, expiry_date, owning_team, ai_deployment_scope, and authority_domain_applicability", "deployment_policy_linkage_audit_log confirming every active AI deployment has a corresponding current policy register entry with a non-expired effective date", "policy_register_access_control_matrix demonstrating that register modifications require dual authorization and all changes are attributed and logged", "deployment_pipeline_gate_configuration showing that AI deployment approval workflows validate the presence of a current policy register entry before proceeding" ], "evidence": [ { "id": "PO-01-E1", "description": "policy_register_schema_document specifying required fields including policy_id, version, effective_date, expiry_date, owning_team, ai_deployment_scope, and authority_domain_applicability", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-01-E2", "description": "deployment_policy_linkage_audit_log confirming every active AI deployment has a corresponding current policy register entry with a non-expired effective date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-01-E3", "description": "policy_register_access_control_matrix demonstrating that register modifications require dual authorization and all changes are attributed and logged", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-01-E4", "description": "deployment_pipeline_gate_configuration showing that AI deployment approval workflows validate the presence of a current policy register entry before proceeding", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "The authoritative policy register maintains documented information per \u00a77.5, partially." }, { "control": "apeiris://authority/controls/PO-02", "id": "PO-02", "domain": "authority", "name": "Policy Version Control and Distribution", "validation_objective": "All AI authority policies must be stored in a version-controlled repository with semantic versioning and approval-gated merges, and every AI system runtime configuration must reference a specific approved policy version. Upon a policy version update, all linked AI system configurations must be updated to the new version within one business day, and all superseded versions must be retained in an immutable archive with their effective date ranges intact.", "blocking_effect": "blocks-deployment", "evidence_required": [ "policy_version_distribution_log showing each policy version publication event, the list of linked AI system configurations notified, and the timestamp of configuration update for each consumer", "ai_runtime_policy_version_references confirming each active AI system references a specific approved policy version rather than an unversioned label", "policy_archive_effective_date_ranges document confirming all superseded policy versions are retained with their start and end effective dates", "policy_repository_approval_log showing committer attribution and approval workflow completion for every version merge during the audit period" ], "evidence": [ { "id": "PO-02-E1", "description": "policy_version_distribution_log showing each policy version publication event, the list of linked AI system configurations notified, and the timestamp of configuration update for each consumer", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "PO-02-E2", "description": "ai_runtime_policy_version_references confirming each active AI system references a specific approved policy version rather than an unversioned label", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PO-02-E3", "description": "policy_archive_effective_date_ranges document confirming all superseded policy versions are retained with their start and end effective dates", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-02-E4", "description": "policy_repository_approval_log showing committer attribution and approval workflow completion for every version merge during the audit period", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "Semantic versioning and retention of superseded policies reflect \u00a77.5 documented information, partially." }, { "control": "apeiris://compliance/controls/CG-02", "id": "CG-02", "domain": "compliance", "name": "Compliance Policy Framework for AI", "validation_objective": "The organization must maintain a board-approved enterprise AI compliance policy, a regulatory inventory covering all applicable frameworks across all jurisdictions of AI operation updated within 30 days of any material regulatory change, and a documented policy hierarchy extending from the enterprise policy to system-specific procedures for every AI system in production, with all policy documents reviewed within the last 14 months and a demonstrated process for completing policy updates within 90 days of material regulatory change.", "blocking_effect": "requires-review", "evidence_required": [ "board_approved_enterprise_ai_compliance_policy with formal board ratification record, approval date within the last 14 months, and defined scope covering all applicable AI regulatory obligations across all operating jurisdictions", "regulatory_inventory spanning all jurisdictions of AI operation listing all applicable frameworks, assigned obligation owners for each framework, and last update date confirming review within 30 days of any material regulatory change", "policy_coverage_map linking every AI system in the production AI inventory to at least one policy document with a named owner, last review date within 14 months, and applicable regulatory frameworks identified", "regulatory_change_tracking_log for the last 24 months showing detected regulatory changes, policy update decisions triggered, update completion dates, and compliance with the 90-day response target for each change", "framework_specific_standards_documentation for each applicable regulatory framework, mapping framework requirements to internal controls and assigning named owners responsible for each obligation" ], "evidence": [ { "id": "CG-02-E1", "description": "board_approved_enterprise_ai_compliance_policy with formal board ratification record, approval date within the last 14 months, and defined scope covering all applicable AI regulatory obligations across all operating jurisdictions", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-02-E2", "description": "regulatory_inventory spanning all jurisdictions of AI operation listing all applicable frameworks, assigned obligation owners for each framework, and last update date confirming review within 30 days of any material regulatory change", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-02-E3", "description": "policy_coverage_map linking every AI system in the production AI inventory to at least one policy document with a named owner, last review date within 14 months, and applicable regulatory frameworks identified", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-02-E4", "description": "regulatory_change_tracking_log for the last 24 months showing detected regulatory changes, policy update decisions triggered, update completion dates, and compliance with the 90-day response target for each change", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-02-E5", "description": "framework_specific_standards_documentation for each applicable regulatory framework, mapping framework requirements to internal controls and assigning named owners responsible for each obligation", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://authority/controls/PE-02", "id": "PE-02", "domain": "authority", "name": "Regulatory Disclosure Readiness", "validation_objective": "For every AI system subject to a regulatory transparency obligation, a complete, current disclosure package must be pre-staged and retrievable within the defined submission window. Each package must include technical documentation, conformity assessment records, and incident notification templates validated against the applicable regulatory schema.", "blocking_effect": "blocks-deployment", "evidence_required": [ "disclosure_package_inventory listing every AI system in scope with system_id, applicable_regulation, package_version, last_updated timestamp, and package_completeness_status", "technical_documentation_record per system containing model card, system architecture summary, intended use case, risk classification rationale, and conformity assessment reference", "conformity_assessment_record per applicable system demonstrating compliance with the relevant regulatory article, with assessor identity, assessment date, and findings summary", "incident_notification_template per applicable regulation validated against the regulatory authority's published schema, with a test submission record confirming schema acceptance", "package_readiness_drill_record showing that a disclosure package was successfully retrieved and formatted for submission within the defined regulatory response window during a tabletop or live drill" ], "evidence": [ { "id": "PE-02-E1", "description": "disclosure_package_inventory listing every AI system in scope with system_id, applicable_regulation, package_version, last_updated timestamp, and package_completeness_status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PE-02-E2", "description": "technical_documentation_record per system containing model card, system architecture summary, intended use case, risk classification rationale, and conformity assessment reference", "evidence_type": "model-card", "verification": "attested" }, { "id": "PE-02-E3", "description": "conformity_assessment_record per applicable system demonstrating compliance with the relevant regulatory article, with assessor identity, assessment date, and findings summary", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PE-02-E4", "description": "incident_notification_template per applicable regulation validated against the regulatory authority's published schema, with a test submission record confirming schema acceptance", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "PE-02-E5", "description": "package_readiness_drill_record showing that a disclosure package was successfully retrieved and formatted for submission within the defined regulatory response window during a tabletop or live drill", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "ISO42001-5.3", "section": "\u00a75.3", "title": "Organizational roles, responsibilities, and authorities", "text": "Top management shall ensure that the responsibilities and authorities for relevant roles are assigned and communicated within the organization.", "verdict": "supported", "coverage": "direct", "notes": "Model ownership assignment, AI model governance committee, compliance governance structure, principal accountability binding, and agentic AI governance structure together define and assign AI management roles.", "control_count": 5, "proof_chain": [ { "control": "apeiris://model/controls/OA-01", "id": "OA-01", "domain": "model", "name": "Model Ownership Assignment", "validation_objective": "Every AI model in the production model registry must have a non-null named human owner who is a current employee, a responsible team, and an executive sponsor at director level or above for high-impact models, all recorded within five business days of deployment. No production model may exist without a current ownership record, and ownership must be reassigned within ten business days of any owner departure.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_ownership_register_extract with fields: model_id, owner_name, owner_employee_id, team, executive_sponsor, effective_date, review_date \u2014 showing 100% coverage of production models with non-null values", "deployment_pipeline_gate_log showing blocked promotion events for models with null ownership fields, with timestamps and model IDs", "hr_departure_event_log cross-referenced with ownership_reassignment_record demonstrating reassignment within ten business days for each departure", "governance_committee_meeting_minutes containing ownership review agenda items for the preceding 12-month period" ], "evidence": [ { "id": "OA-01-E1", "description": "model_ownership_register_extract with fields: model_id, owner_name, owner_employee_id, team, executive_sponsor, effective_date, review_date \u2014 showing 100% coverage of production models with non-null values", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-01-E2", "description": "deployment_pipeline_gate_log showing blocked promotion events for models with null ownership fields, with timestamps and model IDs", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-01-E3", "description": "hr_departure_event_log cross-referenced with ownership_reassignment_record demonstrating reassignment within ten business days for each departure", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-01-E4", "description": "governance_committee_meeting_minutes containing ownership review agenda items for the preceding 12-month period", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO 42001 Clause 5.3 requires assignment of roles, responsibilities, and authorities." }, { "control": "apeiris://model/controls/OA-03", "id": "OA-03", "domain": "model", "name": "AI Model Governance Committee", "validation_objective": "The organization must have a formally chartered AI Model Governance Committee with documented membership covering all required functional areas, exclusive approval authority over high-risk model deployments and risk appetite thresholds, and auditable meeting minutes retained for seven years. The committee must have met at minimum quarterly in each of the preceding four quarters, with quorum achieved for all binding decisions.", "blocking_effect": "blocks-deployment", "evidence_required": [ "committee_charter current version with executive-level approval signature and date, specifying membership composition, decision rights matrix, quorum requirements, and meeting cadence", "meeting_minutes for all scheduled quarterly sessions in the preceding 12-month period, demonstrating quorum was met and binding decisions were recorded with rationale", "decision_log showing AIGC approval records for all high-risk model deployments and risk appetite changes in the preceding 12 months, cross-referenced against the production model registry", "membership_roster with functional affiliations confirming representation from AI/ML engineering, model validation, legal/compliance, risk management, and at least one business line" ], "evidence": [ { "id": "OA-03-E1", "description": "committee_charter current version with executive-level approval signature and date, specifying membership composition, decision rights matrix, quorum requirements, and meeting cadence", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-03-E2", "description": "meeting_minutes for all scheduled quarterly sessions in the preceding 12-month period, demonstrating quorum was met and binding decisions were recorded with rationale", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-03-E3", "description": "decision_log showing AIGC approval records for all high-risk model deployments and risk appetite changes in the preceding 12 months, cross-referenced against the production model registry", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-03-E4", "description": "membership_roster with functional affiliations confirming representation from AI/ML engineering, model validation, legal/compliance, risk management, and at least one business line", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 Clause 5.3 (Organizational roles, responsibilities and authorities) requires top management to assign and communicate relevant roles and authorities. OA-03\u2019s chartered committee documents those authorities for AI model decisions." }, { "control": "apeiris://compliance/controls/CG-01", "id": "CG-01", "domain": "compliance", "name": "Compliance Governance Structure", "validation_objective": "The organization must have a formally chartered Compliance Committee with documented meeting minutes showing quorum was achieved in at least 80% of scheduled sessions in the last 12 months, a CCO or equivalent with a documented direct reporting channel to the board Audit and Risk Committee that bypasses management for material issues, and a current escalation matrix reviewed within 12 months covering all material compliance issue types including AI regulatory incidents.", "blocking_effect": "requires-review", "evidence_required": [ "compliance_committee_charter signed and approved by the board with defined membership composition, quorum rules, meeting cadence, decision authority scope, and AI regulatory obligation coverage", "cco_role_documentation including the CCO written authority scope, direct reporting line to the Audit and Risk Committee as documented in board resolution or equivalent formal governance instrument, and organizational chart placement", "compliance_committee_meeting_minutes for the last 12 months showing attendees, quorum status at each session, agenda items including AI compliance matters, and action item tracking with completion status", "escalation_matrix covering all material compliance issue types \u2014 regulatory inquiry, enforcement action, material AI risk event, data breach \u2014 with defined escalation paths, response timeframes, and responsible parties for each tier", "board_resolution or formal charter ratification record establishing the compliance governance structure with effective date and scope of authority" ], "evidence": [ { "id": "CG-01-E1", "description": "compliance_committee_charter signed and approved by the board with defined membership composition, quorum rules, meeting cadence, decision authority scope, and AI regulatory obligation coverage", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-01-E2", "description": "cco_role_documentation including the CCO written authority scope, direct reporting line to the Audit and Risk Committee as documented in board resolution or equivalent formal governance instrument, and organizational chart placement", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-01-E3", "description": "compliance_committee_meeting_minutes for the last 12 months showing attendees, quorum status at each session, agenda items including AI compliance matters, and action item tracking with completion status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-01-E4", "description": "escalation_matrix covering all material compliance issue types \u2014 regulatory inquiry, enforcement action, material AI risk event, data breach \u2014 with defined escalation paths, response timeframes, and responsible parties for each tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-01-E5", "description": "board_resolution or formal charter ratification record establishing the compliance governance structure with effective date and scope of authority", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://authority/controls/PA-04", "id": "PA-04", "domain": "authority", "name": "Principal Accountability Binding", "validation_objective": "Every consequential AI action must produce an immutable accountability binding artifact atomically with the action, containing the action_id, agent_id, principal_id, delegation_basis_id, action_scope, and an integrity hash sealing the record. The artifact must be written to a tamper-evident, append-only store from which neither the AI agent nor its service account can modify or delete entries.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "accountability_binding_artifact for each consequential AI action, containing action_id, agent_id, principal_id, delegation_basis_id, action_scope, action_timestamp, and integrity_hash (sha256) \u2014 all fields must be non-null", "tamper_evident_store_audit_record confirming the binding store is append-only and that no modification or deletion events occurred for any binding artifact during the audit period", "principal_existence_validation_record confirming the principal_id referenced in each binding artifact resolves to a current, active human identity in the enterprise identity system at the time of binding", "binding_completeness_scan result confirming 100% of consequential AI actions in the audit period have a corresponding accountability binding artifact with no gaps" ], "evidence": [ { "id": "PA-04-E1", "description": "accountability_binding_artifact for each consequential AI action, containing action_id, agent_id, principal_id, delegation_basis_id, action_scope, action_timestamp, and integrity_hash (sha256) \u2014 all fields must be non-null", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PA-04-E2", "description": "tamper_evident_store_audit_record confirming the binding store is append-only and that no modification or deletion events occurred for any binding artifact during the audit period", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PA-04-E3", "description": "principal_existence_validation_record confirming the principal_id referenced in each binding artifact resolves to a current, active human identity in the enterprise identity system at the time of binding", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PA-04-E4", "description": "binding_completeness_scan result confirming 100% of consequential AI actions in the audit period have a corresponding accountability binding artifact with no gaps", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "adjacent", "basis": "anchored", "relation": "equivalent_to", "rationale": "Accountability binding operationalizes responsibility per action, distinct from the leadership commitment \u00a75.1 requires." }, { "control": "apeiris://agentic/controls/AG-01", "id": "AG-01", "domain": "agentic", "name": "Agentic AI Governance Structure", "validation_objective": "Prove that the enterprise has a ratified, operational Agentic AI Governance Committee with a documented charter, RACI matrix, and defined three-tier consequence escalation model, and that a named senior accountable owner is recorded in the enterprise risk register. Validate that the committee meets at minimum quarterly, documents decisions, and that governance approval functions as a hard deployment gate.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Ratified Agentic AI Governance Charter documenting committee scope, cross-functional membership roster, quorum requirements, meeting cadence, decision authorities, and escalation tier triggers \u2014 signed within the past 24 months and reviewed within the past 12", "Published RACI matrix covering agent design review, deployment approval, incident escalation, and program reporting with named role assignments and confirmation that 100% of deployed agents have a named governance owner", "Committee meeting minutes from the past four quarters demonstrating quorum, attendance records, and documented decisions for each session", "Enterprise risk register entry naming the senior accountable owner for the agentic AI program by individual name and role, not by position title alone", "Deployment pipeline configuration demonstrating governance approval is enforced as a blocking gate before any agent is promoted to a production environment" ], "evidence": [ { "id": "AG-01-E1", "description": "Ratified Agentic AI Governance Charter documenting committee scope, cross-functional membership roster, quorum requirements, meeting cadence, decision authorities, and escalation tier triggers \u2014 signed within the past 24 months and reviewed within the past 12", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AG-01-E2", "description": "Published RACI matrix covering agent design review, deployment approval, incident escalation, and program reporting with named role assignments and confirmation that 100% of deployed agents have a named governance owner", "evidence_type": "incident-record", "verification": "attested" }, { "id": "AG-01-E3", "description": "Committee meeting minutes from the past four quarters demonstrating quorum, attendance records, and documented decisions for each session", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AG-01-E4", "description": "Enterprise risk register entry naming the senior accountable owner for the agentic AI program by individual name and role, not by position title alone", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-01-E5", "description": "Deployment pipeline configuration demonstrating governance approval is enforced as a blocking gate before any agent is promoted to a production environment", "evidence_type": "configuration-snapshot", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 Clause 5.1 requires top management to demonstrate leadership and commitment to the AI management system, including establishing organizational roles and responsibilities for AI governance. A governance committee with named senior accountability directly satisfies this leadership requirement." } ] }, { "requirement_id": "ISO42001-6.1", "section": "\u00a76.1", "title": "Actions to address risks and opportunities", "text": "When planning for the AIMS, the organization shall consider the issues and requirements of interested parties and determine the risks and opportunities that need to be addressed to ensure the AIMS can achieve its intended outcomes.", "verdict": "partial", "coverage": "partial", "notes": "Obligation gap analysis, intended purpose alignment review, and compliance risk appetite definition address the risk dimension. Opportunity identification (positive outcomes from AI) is not a specific Apeiris control focus.", "control_count": 3, "proof_chain": [ { "control": "apeiris://compliance/controls/CA-06", "id": "CA-06", "domain": "compliance", "name": "Compliance Obligation Gap Analysis", "validation_objective": "Gap analysis must be executed at least quarterly and within 10 business days following every update to the CA-02 obligation map or CA-03 routing table, producing a complete gap register that identifies every obligation in the CA-02 map without a functioning routing table entry, with every gap assigned an owner, severity, and target closure date that precedes the obligation's regulatory effective date.", "blocking_effect": "advisory", "evidence_required": [ "gap_analysis_run_record showing analysis_date, obligation_map_version, routing_table_version, total_obligations_analyzed, gaps_identified_count, analysis_trigger (scheduled or event-driven), and methodology_description", "gap_register entries for each open gap containing obligation_id, applicable_regime, normative_force, gap_severity, assigned_owner, target_closure_date, and escalation_status for high-severity binding-law items", "gap_closure_records showing each closed gap has a corresponding routing_table_entry_id and the entry resolves to a valid attestation confirmed post-closure, with validator_identity and confirmed_at timestamp", "binding_law_gap_escalation_records showing gaps with normative_force='binding-law' were escalated to legal_counsel and executive_leadership within the defined SLA after identification" ], "evidence": [ { "id": "CA-06-E1", "description": "gap_analysis_run_record showing analysis_date, obligation_map_version, routing_table_version, total_obligations_analyzed, gaps_identified_count, analysis_trigger (scheduled or event-driven), and methodology_description", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-06-E2", "description": "gap_register entries for each open gap containing obligation_id, applicable_regime, normative_force, gap_severity, assigned_owner, target_closure_date, and escalation_status for high-severity binding-law items", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-06-E3", "description": "gap_closure_records showing each closed gap has a corresponding routing_table_entry_id and the entry resolves to a valid attestation confirmed post-closure, with validator_identity and confirmed_at timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-06-E4", "description": "binding_law_gap_escalation_records showing gaps with normative_force='binding-law' were escalated to legal_counsel and executive_leadership within the defined SLA after identification", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://authority/controls/PV-03", "id": "PV-03", "domain": "authority", "name": "Intended Purpose Alignment Review", "validation_objective": "All active AI deployments must have a documented alignment review completed within the defined risk-tiered cadence. Each review must compare a structured behavioral log against the deployed behavioral profile and produce a signed review record; any material drift finding must trigger a re-authorization workflow before the system continues operating unchanged.", "blocking_effect": "requires-review", "evidence_required": [ "Behavioral profile specification linked to each active intent declaration, defining expected action type distribution ranges, resource access frequency bands, and acceptable escalation trigger rates for the review period", "Structured behavioral log summaries covering the review period, with action type distributions, resource access patterns, and anomaly event counts compared against profile thresholds", "Signed alignment review records with reviewer_id, comparison_methodology, drift_findings, determination_of_alignment, and review_completed_at for all active deployments within the defined cadence", "Re-authorization records for any deployment where material drift was identified, including the triggering drift finding, remediation action, and updated or reaffirmed intent declaration version" ], "evidence": [ { "id": "PV-03-E1", "description": "Behavioral profile specification linked to each active intent declaration, defining expected action type distribution ranges, resource access frequency bands, and acceptable escalation trigger rates for the review period", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PV-03-E2", "description": "Structured behavioral log summaries covering the review period, with action type distributions, resource access patterns, and anomaly event counts compared against profile thresholds", "evidence_type": "audit-log", "verification": "automated" }, { "id": "PV-03-E3", "description": "Signed alignment review records with reviewer_id, comparison_methodology, drift_findings, determination_of_alignment, and review_completed_at for all active deployments within the defined cadence", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PV-03-E4", "description": "Re-authorization records for any deployment where material drift was identified, including the triggering drift finding, remediation action, and updated or reaffirmed intent declaration version", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "The risk-tiered alignment review cadence directly satisfies \u00a79.1 monitoring, measurement, analysis, and evaluation." }, { "control": "apeiris://compliance/controls/CG-04", "id": "CG-04", "domain": "compliance", "name": "Compliance Risk Appetite Definition", "validation_objective": "A board-ratified compliance risk appetite statement exists with quantitative thresholds (maximum open critical findings, maximum remediation lag in days) and qualitative criteria for each applicable regulatory framework, and a trigger matrix mapping risk levels to required escalation or deployment-halt actions is documented and embedded in AI deployment approval workflows, with annual board review confirmed within the last 12 months.", "blocking_effect": "blocks-deployment", "evidence_required": [ "board_ratified_risk_appetite_statement containing quantitative_thresholds per regulatory framework, qualitative_criteria, approval_date, and board_signatory \u2014 confirmed reviewed and approved within the last 12 months", "compliance_trigger_matrix document defining green/amber/red risk levels with threshold values, required_actions at each level (monitor/escalate-to-CCO/deployment-pause), responsible_role, and response SLA", "ai_deployment_approval_records for at least three recent production deployments each showing explicit risk_appetite_reference field with threshold_check_outcome (pass/escalate/hold) documented", "annual_review_record confirming risk appetite was presented to and ratified by the board within the last 12 months, including any revision history and legal counsel sign-off date" ], "evidence": [ { "id": "CG-04-E1", "description": "board_ratified_risk_appetite_statement containing quantitative_thresholds per regulatory framework, qualitative_criteria, approval_date, and board_signatory \u2014 confirmed reviewed and approved within the last 12 months", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-04-E2", "description": "compliance_trigger_matrix document defining green/amber/red risk levels with threshold values, required_actions at each level (monitor/escalate-to-CCO/deployment-pause), responsible_role, and response SLA", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CG-04-E3", "description": "ai_deployment_approval_records for at least three recent production deployments each showing explicit risk_appetite_reference field with threshold_check_outcome (pass/escalate/hold) documented", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-04-E4", "description": "annual_review_record confirming risk appetite was presented to and ratified by the board within the last 12 months, including any revision history and legal counsel sign-off date", "evidence_type": "human-review-record", "verification": "human" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "ISO42001-6.1.2", "section": "\u00a76.1.2", "title": "AI risk assessment", "text": "The organization shall define and apply an AI risk assessment process to identify risks associated with the design, development, testing, deployment, maintenance, operation, and decommissioning of AI systems.", "verdict": "supported", "coverage": "direct", "notes": "Risk and applicability classification, agentic AI risk assessment framework, regulatory scope determination, dangerous capability threshold assessment, and ethics impact assessment framework together constitute a comprehensive AI risk assessment process.", "control_count": 5, "proof_chain": [ { "control": "apeiris://model/controls/EV-09", "id": "EV-09", "domain": "model", "name": "Risk and Applicability Classification", "validation_objective": "Every model system has a signed classification record produced before any evaluation work begins, containing a documented EU AI Act classification with provision-specific rationale referencing Articles 5, 6, 50, 51, and Annex III as applicable, an SR 26-2 model risk tier for in-scope institutions, a capability tier, and the full applicable Apeiris profiles list; the model registry gate prevents advancement to evaluation stage without this record; and re-classification is triggered on any significant change to use case, capability level, or applicable regulation.", "blocking_effect": "blocks-deployment", "evidence_required": [ "signed_classification_record containing eu_ai_act_classification with specific provision references, sr_262_tier where applicable, capability_tier, applicable_profiles list, mandatory_controls inventory, and obligations_inventory \u2014 produced before any evaluation artifact is created", "classification_questionnaire_responses document answering all required dimensions: intended_use_cases, affected_populations, decision_automation_level, human_oversight_mechanisms, deployment_jurisdiction, compute_budget, parameter_count", "non_high_risk_exclusion_rationale for systems classified below high-risk, explicitly addressing each relevant Annex III category with documented rationale for exclusion", "classification_review_records for all re-classification events documenting trigger_event, prior_classification, new_classification, and rationale with effective_date", "iso_42005_impact_assessment for high-impact-decision and eu-high-risk profile systems per ISO/IEC 42005:2025" ], "evidence": [ { "id": "EV-09-E1", "description": "signed_classification_record containing eu_ai_act_classification with specific provision references, sr_262_tier where applicable, capability_tier, applicable_profiles list, mandatory_controls inventory, and obligations_inventory \u2014 produced before any evaluation artifact is created", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-09-E2", "description": "classification_questionnaire_responses document answering all required dimensions: intended_use_cases, affected_populations, decision_automation_level, human_oversight_mechanisms, deployment_jurisdiction, compute_budget, parameter_count", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E3", "description": "non_high_risk_exclusion_rationale for systems classified below high-risk, explicitly addressing each relevant Annex III category with documented rationale for exclusion", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E4", "description": "classification_review_records for all re-classification events documenting trigger_event, prior_classification, new_classification, and rationale with effective_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E5", "description": "iso_42005_impact_assessment for high-impact-decision and eu-high-risk profile systems per ISO/IEC 42005:2025", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO 42001 \u00a76.1 requires risk assessment including determination of the significance of identified risks; formal classification operationalizes this." }, { "control": "apeiris://agentic/controls/AG-03", "id": "AG-03", "domain": "agentic", "name": "Agentic AI Risk Assessment Framework", "validation_objective": "Every production AI agent has a completed, current risk assessment evaluated against all five framework dimensions, with the resulting consequence tier documented and linked to the deployment approval and control mitigation plan.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "Annual risk reassessment records for all Critical-tier agents" ], "evidence": [ { "id": "AG-03-E1", "description": "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E2", "description": "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E3", "description": "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E4", "description": "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E5", "description": "Annual risk reassessment records for all Critical-tier agents", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 Clause 6.1 requires organizations to determine risks and opportunities related to the AI management system and plan actions to address them. A systematic risk assessment framework with defined scoring methodology satisfies this planning and risk determination requirement." }, { "control": "apeiris://compliance/controls/CA-01", "id": "CA-01", "domain": "compliance", "name": "Regulatory Scope Determination", "validation_objective": "Every AI system in the compliance registry must have an approved, version-controlled scope record that correctly identifies all applicable regulatory regimes based on its deployment jurisdiction, sector, data categories, and capability tier, and that was reviewed following the most recent material change to deployment context or applicable regulatory publication. Deployment pipeline advancement must be blocked for any system without an approved scope record.", "blocking_effect": "blocks-deployment", "evidence_required": [ "compliance_registry_scope_record containing system_id, applicable_regimes[], triggering_criteria[], approved_by, approved_at, and version_id demonstrating a complete and current classification", "regulatory_trigger_matrix with version_date and last_reviewed_on within 30 days of the most recent applicable regulatory publication affecting AI systems in the organization's jurisdictions", "deployment_gate_log entry for the AI system showing scope_record_approval_status was checked before production promotion with artifact scope_record_id referenced", "escalation_record for any ambiguous classification decisions showing legal_counsel_sign_off, resolution_rationale, and resolution_date within the defined SLA" ], "evidence": [ { "id": "CA-01-E1", "description": "compliance_registry_scope_record containing system_id, applicable_regimes[], triggering_criteria[], approved_by, approved_at, and version_id demonstrating a complete and current classification", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-01-E2", "description": "regulatory_trigger_matrix with version_date and last_reviewed_on within 30 days of the most recent applicable regulatory publication affecting AI systems in the organization's jurisdictions", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-01-E3", "description": "deployment_gate_log entry for the AI system showing scope_record_approval_status was checked before production promotion with artifact scope_record_id referenced", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-01-E4", "description": "escalation_record for any ambiguous classification decisions showing legal_counsel_sign_off, resolution_rationale, and resolution_date within the defined SLA", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001:2023 \u00a74.1 requires organisations to determine external and internal factors affecting AI management; CA-01 regulatory scope determination is the AI-specific implementation of this clause." }, { "control": "apeiris://model/controls/EV-03", "id": "EV-03", "domain": "model", "name": "Dangerous Capability Threshold Assessment", "validation_objective": "Every model at or near frontier capability has been assessed against the organization's applicable responsible scaling or capability policy thresholds for CBRN uplift, cyberweapon generation, autonomous AI R&D, and mass-influence operations before deployment authorization is granted. The safety committee has reviewed elicitation results and issued a signed deployment authorization for models below all thresholds; any model at or above threshold in any domain is not deployed pending safety committee escalation.", "blocking_effect": "blocks-deployment", "evidence_required": [ "scoping_determination_record for each evaluated model referencing the applicable capability policy (responsible scaling policy version or equivalent), with rationale for frontier-class determination including FLOPs estimate, capability benchmark scores, or elicitation pre-screen results", "capability_elicitation_results per domain (CBRN, cyberweapons, autonomous AI R&D, mass-influence operations) with methodology documentation, red-team evaluator identities, uplift elicitation protocol reference, and threshold comparison showing assessed level vs. defined threshold for each domain", "safety_committee_review_record with committee composition, deliberation notes, quorum confirmation, majority determination, any dissenting positions, and signed deployment_authorization or deployment_block decision", "EU_AI_Act_systemic_risk_classification_record for models meeting Art. 51 GPAI thresholds (\u226510\u00b2\u2075 FLOPs training compute or equivalent capability), documenting systemic risk determination and applicable GPAI obligations" ], "evidence": [ { "id": "EV-03-E1", "description": "scoping_determination_record for each evaluated model referencing the applicable capability policy (responsible scaling policy version or equivalent), with rationale for frontier-class determination including FLOPs estimate, capability benchmark scores, or elicitation pre-screen results", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-03-E2", "description": "capability_elicitation_results per domain (CBRN, cyberweapons, autonomous AI R&D, mass-influence operations) with methodology documentation, red-team evaluator identities, uplift elicitation protocol reference, and threshold comparison showing assessed level vs. defined threshold for each domain", "evidence_type": "red-team-report", "verification": "third-party" }, { "id": "EV-03-E3", "description": "safety_committee_review_record with committee composition, deliberation notes, quorum confirmation, majority determination, any dissenting positions, and signed deployment_authorization or deployment_block decision", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EV-03-E4", "description": "EU_AI_Act_systemic_risk_classification_record for models meeting Art. 51 GPAI thresholds (\u226510\u00b2\u2075 FLOPs training compute or equivalent capability), documenting systemic risk determination and applicable GPAI obligations", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO 42001 \u00a76.1 requires identification and assessment of AI risks; dangerous capability assessment extends this to frontier-specific risks." }, { "control": "apeiris://ethics/controls/EF-04", "id": "EF-04", "domain": "ethics", "name": "Ethics Impact Assessment Framework", "validation_objective": "Every AI system in the production inventory must have a completed Ethics Impact Assessment using the organization's documented methodology, producing a structured verdict from the approved verdict taxonomy before initial deployment and within the annual review cycle thereafter. Each EIA must include fairness metric results disaggregated by demographic group, data provenance documentation, and an explicit verdict mapped against the organization's Ethical Risk Appetite Statement tiers.", "blocking_effect": "blocks-deployment", "evidence_required": [ "ethics_impact_assessment document with methodology_version, completed_questionnaire, residual_risk_score, risk_appetite_tier mapping, and structured_verdict (approved / approved-with-conditions / deferred-pending-mitigation / blocked)", "fairness_metric_results_report showing model performance disaggregated by demographic group using at least two metrics (equalized odds, demographic parity, calibration, or individual fairness) as required by the EIA questionnaire", "eia_governance_approval_record showing verdict_issuer, ethics_officer_countersignature for high-risk systems, and approval_date confirmed before production deployment", "eia_registry entry for each production AI system with current_assessment_date and next_review_date within 12 months", "fundamental_rights_impact_assessment artifact for EU-deployed high-risk systems satisfying Art. 27 requirements, integrated into or attached to the EIA documentation package" ], "evidence": [ { "id": "EF-04-E1", "description": "ethics_impact_assessment document with methodology_version, completed_questionnaire, residual_risk_score, risk_appetite_tier mapping, and structured_verdict (approved / approved-with-conditions / deferred-pending-mitigation / blocked)", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EF-04-E2", "description": "fairness_metric_results_report showing model performance disaggregated by demographic group using at least two metrics (equalized odds, demographic parity, calibration, or individual fairness) as required by the EIA questionnaire", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-04-E3", "description": "eia_governance_approval_record showing verdict_issuer, ethics_officer_countersignature for high-risk systems, and approval_date confirmed before production deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-04-E4", "description": "eia_registry entry for each production AI system with current_assessment_date and next_review_date within 12 months", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-04-E5", "description": "fundamental_rights_impact_assessment artifact for EU-deployed high-risk systems satisfying Art. 27 requirements, integrated into or attached to the EIA documentation package", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001:2023 \u00a78.4 requires impact assessments for AI systems and \u00a79.1 requires performance evaluation against responsible AI objectives. The EIA methodology satisfies both by providing a structured pre-deployment and in-operation assessment process with documented verdicts." } ] }, { "requirement_id": "ISO42001-6.1.3", "section": "\u00a76.1.3", "title": "AI risk treatment", "text": "The organization shall define and apply an AI risk treatment process to select appropriate risk treatment options and determine all controls necessary to implement the chosen risk treatment options.", "verdict": "supported", "coverage": "direct", "notes": "Risk assessment framework, pre-deployment evaluation gate, obligation gap analysis, AI management system governance, and remediation tracking collectively implement risk treatment selection and execution.", "control_count": 5, "proof_chain": [ { "control": "apeiris://agentic/controls/AG-03", "id": "AG-03", "domain": "agentic", "name": "Agentic AI Risk Assessment Framework", "validation_objective": "Every production AI agent has a completed, current risk assessment evaluated against all five framework dimensions, with the resulting consequence tier documented and linked to the deployment approval and control mitigation plan.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "Annual risk reassessment records for all Critical-tier agents" ], "evidence": [ { "id": "AG-03-E1", "description": "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E2", "description": "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E3", "description": "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E4", "description": "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E5", "description": "Annual risk reassessment records for all Critical-tier agents", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 Clause 6.1 requires organizations to determine risks and opportunities related to the AI management system and plan actions to address them. A systematic risk assessment framework with defined scoring methodology satisfies this planning and risk determination requirement." }, { "control": "apeiris://model/controls/EV-01", "id": "EV-01", "domain": "model", "name": "Pre-Deployment Evaluation Gate", "validation_objective": "No model artifact is promoted to production unless a signed evaluation manifest referencing that artifact's exact hash is present in the tamper-evident evaluation log and has received dual approval from named, authorized approvers. The deployment pipeline enforces this as a cryptographic gate \u2014 an absent, unsigned, or hash-mismatched manifest results in an automatic pipeline block with no override path except a logged exception with named risk-accepter.", "blocking_effect": "blocks-deployment", "evidence_required": [ "signed_evaluation_manifest with model_artifact_hash, evaluation_suite_version, evaluator_identities, per-dimension pass/fail outcome, signing_key_id, and manifest_signature (Ed25519) for every production model version", "tamper_evident_evaluation_log entry linking manifest_id to model_artifact_hash, recording append timestamp, appender identity, and log integrity proof", "dual_approval_record with two named approver identities, their organizational roles, approval timestamps, and the manifest_hash each approver authorized", "pipeline_execution_log showing at least one successful gate enforcement event: a deployment attempt with an absent or invalid manifest that was blocked, confirming the gate is operational rather than advisory" ], "evidence": [ { "id": "EV-01-E1", "description": "signed_evaluation_manifest with model_artifact_hash, evaluation_suite_version, evaluator_identities, per-dimension pass/fail outcome, signing_key_id, and manifest_signature (Ed25519) for every production model version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-01-E2", "description": "tamper_evident_evaluation_log entry linking manifest_id to model_artifact_hash, recording append timestamp, appender identity, and log integrity proof", "evidence_type": "audit-log", "verification": "automated" }, { "id": "EV-01-E3", "description": "dual_approval_record with two named approver identities, their organizational roles, approval timestamps, and the manifest_hash each approver authorized", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EV-01-E4", "description": "pipeline_execution_log showing at least one successful gate enforcement event: a deployment attempt with an absent or invalid manifest that was blocked, confirming the gate is operational rather than advisory", "evidence_type": "configuration-snapshot", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 A.6.2.4 (AI system verification and validation) requires verification and validation before deployment. EV-01\u2019s evaluation gate is the blocking control where those results are checked." }, { "control": "apeiris://compliance/controls/CA-06", "id": "CA-06", "domain": "compliance", "name": "Compliance Obligation Gap Analysis", "validation_objective": "Gap analysis must be executed at least quarterly and within 10 business days following every update to the CA-02 obligation map or CA-03 routing table, producing a complete gap register that identifies every obligation in the CA-02 map without a functioning routing table entry, with every gap assigned an owner, severity, and target closure date that precedes the obligation's regulatory effective date.", "blocking_effect": "advisory", "evidence_required": [ "gap_analysis_run_record showing analysis_date, obligation_map_version, routing_table_version, total_obligations_analyzed, gaps_identified_count, analysis_trigger (scheduled or event-driven), and methodology_description", "gap_register entries for each open gap containing obligation_id, applicable_regime, normative_force, gap_severity, assigned_owner, target_closure_date, and escalation_status for high-severity binding-law items", "gap_closure_records showing each closed gap has a corresponding routing_table_entry_id and the entry resolves to a valid attestation confirmed post-closure, with validator_identity and confirmed_at timestamp", "binding_law_gap_escalation_records showing gaps with normative_force='binding-law' were escalated to legal_counsel and executive_leadership within the defined SLA after identification" ], "evidence": [ { "id": "CA-06-E1", "description": "gap_analysis_run_record showing analysis_date, obligation_map_version, routing_table_version, total_obligations_analyzed, gaps_identified_count, analysis_trigger (scheduled or event-driven), and methodology_description", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-06-E2", "description": "gap_register entries for each open gap containing obligation_id, applicable_regime, normative_force, gap_severity, assigned_owner, target_closure_date, and escalation_status for high-severity binding-law items", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-06-E3", "description": "gap_closure_records showing each closed gap has a corresponding routing_table_entry_id and the entry resolves to a valid attestation confirmed post-closure, with validator_identity and confirmed_at timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-06-E4", "description": "binding_law_gap_escalation_records showing gaps with normative_force='binding-law' were escalated to legal_counsel and executive_leadership within the defined SLA after identification", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://security/controls/GV-05", "id": "GV-05", "domain": "security", "name": "Run an AI management system and tier agents by their autonomy", "validation_objective": "The organization operates a documented ISO/IEC 42001 AI management system with a current agent inventory, and every production agent is assigned a risk tier based on its level of autonomy and permissions, with higher-autonomy agents carrying impact assessments proportional to their tier.", "blocking_effect": "blocks-deployment", "evidence_required": [ "agent_risk_tier_register listing each production agent's assigned autonomy tier and the criteria used for classification", "ISO/IEC 42001 AI management system documentation with scope statement and AI policy covering agentic systems", "impact_assessment_records for each agent classified at the two highest autonomy tiers with a completed and approved status", "change-trigger log showing tier re-evaluation events (model update, domain shift, performance regression, regulatory change) within the review window", "AWS Agentic AI Security Scoping Matrix or equivalent tier-scoring artifacts used for current-period agent classification", "environment_isolation_attestation confirming each agent tier instance has distinct identity credentials, secrets, and permission scopes per deployment environment (dev/staging/production) with a zero-sharing assertion verified against the credential broker", "environment_promotion_log recording each agent's promotion path through dev \u2192 staging \u2192 production, the approver identity, any autonomy-tier reclassification triggered during promotion, and confirmation that a staging integration validation gate was passed before the production promotion" ], "evidence": [ { "id": "GV-05-E1", "description": "agent_risk_tier_register listing each production agent's assigned autonomy tier and the criteria used for classification", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-05-E2", "description": "ISO/IEC 42001 AI management system documentation with scope statement and AI policy covering agentic systems", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-05-E3", "description": "impact_assessment_records for each agent classified at the two highest autonomy tiers with a completed and approved status", "evidence_type": "human-review-record", "verification": "human" }, { "id": "GV-05-E4", "description": "change-trigger log showing tier re-evaluation events (model update, domain shift, performance regression, regulatory change) within the review window", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "GV-05-E5", "description": "AWS Agentic AI Security Scoping Matrix or equivalent tier-scoring artifacts used for current-period agent classification", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-05-E6", "description": "environment_isolation_attestation confirming each agent tier instance has distinct identity credentials, secrets, and permission scopes per deployment environment (dev/staging/production) with a zero-sharing assertion verified against the credential broker", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "GV-05-E7", "description": "environment_promotion_log recording each agent's promotion path through dev \u2192 staging \u2192 production, the approver identity, any autonomy-tier reclassification triggered during promotion, and confirmation that a staging integration validation gate was passed before the production promotion", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "adjacent", "basis": "anchored", "relation": "equivalent_to", "rationale": null }, { "control": "apeiris://compliance/controls/CI-07", "id": "CI-07", "domain": "compliance", "name": "Remediation Tracking and Closure", "validation_objective": "Every compliance gap identified by control testing (CI-01), monitoring (CI-02), or internal audit (CI-06) has a corresponding remediation ticket with an assigned single owner, target date, documented root cause, remediation plan, and independently verified closure evidence. No critical-severity ticket is open beyond 15 business days without a documented executive escalation record.", "blocking_effect": "requires-review", "evidence_required": [ "Remediation register export listing all open and closed tickets with source_control, severity, assigned_owner, root_cause, remediation_plan, target_date, and actual_closure_date for the full audit period", "Closure verification records for each high and critical ticket documenting the independent verifier identity, verification method (re-test, configuration check, or re-assessment), and verification outcome", "Automated escalation log showing escalation trigger events and management acknowledgment timestamps for all overdue items during the period", "Recurrence analysis report identifying any finding appearing in both the current and prior audit cycle, with root cause explanation for recurrence", "Weekly remediation velocity reports showing open ticket counts by severity and age distribution across the audit period" ], "evidence": [ { "id": "CI-07-E1", "description": "Remediation register export listing all open and closed tickets with source_control, severity, assigned_owner, root_cause, remediation_plan, target_date, and actual_closure_date for the full audit period", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "CI-07-E2", "description": "Closure verification records for each high and critical ticket documenting the independent verifier identity, verification method (re-test, configuration check, or re-assessment), and verification outcome", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "CI-07-E3", "description": "Automated escalation log showing escalation trigger events and management acknowledgment timestamps for all overdue items during the period", "evidence_type": "audit-log", "verification": "automated" }, { "id": "CI-07-E4", "description": "Recurrence analysis report identifying any finding appearing in both the current and prior audit cycle, with root cause explanation for recurrence", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-07-E5", "description": "Weekly remediation velocity reports showing open ticket counts by severity and age distribution across the audit period", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "ISO42001-6.2", "section": "\u00a76.2", "title": "AI objectives and planning to achieve them", "text": "The organization shall establish AI objectives at relevant functions and levels. The AI objectives shall be consistent with the AI policy, be measurable, take into account applicable requirements, and be monitored, communicated, and updated as appropriate.", "verdict": "partial", "coverage": "partial", "notes": "Operating intent declaration and boundary validation establish AI system objectives at the deployment level. AI-specific compliance KPIs support measurability. A formal organization-level AI objectives framework is an AIMS management process not fully covered by Apeiris technical controls.", "control_count": 3, "proof_chain": [ { "control": "apeiris://authority/controls/PV-01", "id": "PV-01", "domain": "authority", "name": "Operating Intent Declaration", "validation_objective": "Every active AI system deployment must have a machine-readable, cryptographically signed intent declaration registered in the authority control registry before production activation. The deployment pipeline must block agent activation when no valid, unexpired declaration with all required schema fields is present.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Signed intent declaration artifact with canonical_id, authorized_action_types, context_scope, principal_id, valid_from, and valid_until fields for every active AI deployment", "Deployment gate rejection logs demonstrating that agent activations without a registered, unexpired declaration were blocked, with fields for system_id, attempted_at, and rejection_reason", "Authority control registry export cross-referencing each active deployment to its current declaration record and cryptographic signature", "Principal authorization verification record confirming the signing identity has organizational authority to bind the enterprise to the declared scope", "Renewal audit trail linking declaration version history to deployment lifecycle events and authorizing principal identity" ], "evidence": [ { "id": "PV-01-E1", "description": "Signed intent declaration artifact with canonical_id, authorized_action_types, context_scope, principal_id, valid_from, and valid_until fields for every active AI deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PV-01-E2", "description": "Deployment gate rejection logs demonstrating that agent activations without a registered, unexpired declaration were blocked, with fields for system_id, attempted_at, and rejection_reason", "evidence_type": "audit-log", "verification": "automated" }, { "id": "PV-01-E3", "description": "Authority control registry export cross-referencing each active deployment to its current declaration record and cryptographic signature", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "PV-01-E4", "description": "Principal authorization verification record confirming the signing identity has organizational authority to bind the enterprise to the declared scope", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PV-01-E5", "description": "Renewal audit trail linking declaration version history to deployment lifecycle events and authorizing principal identity", "evidence_type": "audit-log", "verification": "automated" } ], "fit": "adjacent", "basis": "anchored", "relation": "equivalent_to", "rationale": "Declaring authorized scope anchors authority but is not itself a risk-treatment action under \u00a76.1." }, { "control": "apeiris://authority/controls/PV-02", "id": "PV-02", "domain": "authority", "name": "Operating Intent Boundary Validation", "validation_objective": "Every AI agent action must pass a pre-execution boundary check against the active intent declaration before being submitted to any downstream system. Actions exceeding declared action types, resource categories, or quantitative limits must be blocked and a structured violation event emitted; no out-of-scope action may complete execution before a human escalation is triggered.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "Boundary validation interceptor deployment manifest showing pre-execution positioning in the agent action dispatch layer, including component version, deployment_timestamp, and scope of coverage", "Boundary violation event log entries with structured fields: action_type, resource_target, declared_limit, observed_value, declaration_id, agent_id, and violation_timestamp", "Escalation workflow records confirming boundary violations reached a named human reviewer within the defined SLA, with time-from-violation and reviewer_id recorded", "Adversarial bypass test report confirming interceptor blocked actions submitted via direct API calls and parameter manipulation attempts" ], "evidence": [ { "id": "PV-02-E1", "description": "Boundary validation interceptor deployment manifest showing pre-execution positioning in the agent action dispatch layer, including component version, deployment_timestamp, and scope of coverage", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "PV-02-E2", "description": "Boundary violation event log entries with structured fields: action_type, resource_target, declared_limit, observed_value, declaration_id, agent_id, and violation_timestamp", "evidence_type": "audit-log", "verification": "automated" }, { "id": "PV-02-E3", "description": "Escalation workflow records confirming boundary violations reached a named human reviewer within the defined SLA, with time-from-violation and reviewer_id recorded", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PV-02-E4", "description": "Adversarial bypass test report confirming interceptor blocked actions submitted via direct API calls and parameter manipulation attempts", "evidence_type": "automated-test-result", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "Boundary validation operationalizes limits from impact assessment but is not itself the AI system impact assessment." }, { "control": "apeiris://compliance/controls/CI-03", "id": "CI-03", "domain": "compliance", "name": "AI-Specific Compliance KPIs", "validation_objective": "The compliance program must produce a defined set of AI-specific KPIs covering all five baseline dimensions (obligation coverage, evidence freshness, audit finding rate, remediation velocity, training completion) on a defined reporting cadence, with each KPI having a documented target threshold, a current measured value, and a trend direction indicator. No KPI may report a null measured_value at the defined reporting cadence without a documented exception.", "blocking_effect": "advisory", "evidence_required": [ "kpi_definition_register listing each KPI with kpi_id, name, definition, measurement_method, data_source, target_threshold, and reporting_frequency", "kpi_measurement_report for the current period containing measured_value, prior_period_value, trend_direction, and within_threshold flag for each defined KPI", "kpi_trend_history covering at least four consecutive reporting periods per KPI to enable trend analysis", "management_reporting_record confirming KPI results were presented to the compliance governance committee with attendance record and date", "remediation_action_record for each KPI where measured_value is outside the target_threshold, with root_cause, corrective_action, and target_return_to_threshold_date" ], "evidence": [ { "id": "CI-03-E1", "description": "kpi_definition_register listing each KPI with kpi_id, name, definition, measurement_method, data_source, target_threshold, and reporting_frequency", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-03-E2", "description": "kpi_measurement_report for the current period containing measured_value, prior_period_value, trend_direction, and within_threshold flag for each defined KPI", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-03-E3", "description": "kpi_trend_history covering at least four consecutive reporting periods per KPI to enable trend analysis", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-03-E4", "description": "management_reporting_record confirming KPI results were presented to the compliance governance committee with attendance record and date", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CI-03-E5", "description": "remediation_action_record for each KPI where measured_value is outside the target_threshold, with root_cause, corrective_action, and target_return_to_threshold_date", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "ISO42001-7.1", "section": "\u00a77.1", "title": "Resources", "text": "The organization shall determine and provide the resources needed for the establishment, implementation, maintenance, and continual improvement of the AIMS, including human resources, infrastructure, and specialized expertise.", "verdict": "partial", "coverage": "partial", "notes": "Compliance program resourcing and resilience program resourcing address AI-specific resource planning. The AI model governance committee control covers specialized expertise. Budget allocation and infrastructure provisioning decisions are organizational rather than control-layer concerns.", "control_count": 3, "proof_chain": [ { "control": "apeiris://compliance/controls/CG-05", "id": "CG-05", "domain": "compliance", "name": "Compliance Program Resourcing", "validation_objective": "The compliance program has a documented annual resource assessment \u2014 completed within the current fiscal year \u2014 that maps qualified headcount, allocated budget, and active tooling to each regulatory obligation in scope for AI systems, identifies any coverage gaps, and has been formally presented to executive leadership with documented gap remediation plans or explicit board-approved acceptance rationale for each unresolved gap.", "blocking_effect": "requires-review", "evidence_required": [ "annual_resource_assessment_report dated within the current fiscal year containing headcount_by_regulatory_domain, qualification_evidence for each AI compliance role, budget_allocation by obligation category, and tooling_inventory with coverage_scope listing in-scope AI systems", "executive_presentation_record or board_committee_minutes documenting CCO presentation of resource assessment results with named attendees and executive acknowledgment or formal approval", "staffing_plan document defining minimum qualification requirements for AI-specific compliance roles (EU AI Act specialist, AI risk analyst, compliance engineer) with named_incumbent or open_requisition for each required role", "gap_remediation_plan for each identified resource gap with owner, target_date, budget_approved status, and current_status \u2014 or a formal board-approved acceptance record for gaps accepted as residual risk", "compliance_tooling_inventory listing each platform with license_status, coverage_scope (which AI systems are covered), and last_validated_date confirming active integration with data sources" ], "evidence": [ { "id": "CG-05-E1", "description": "annual_resource_assessment_report dated within the current fiscal year containing headcount_by_regulatory_domain, qualification_evidence for each AI compliance role, budget_allocation by obligation category, and tooling_inventory with coverage_scope listing in-scope AI systems", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-05-E2", "description": "executive_presentation_record or board_committee_minutes documenting CCO presentation of resource assessment results with named attendees and executive acknowledgment or formal approval", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-05-E3", "description": "staffing_plan document defining minimum qualification requirements for AI-specific compliance roles (EU AI Act specialist, AI risk analyst, compliance engineer) with named_incumbent or open_requisition for each required role", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-05-E4", "description": "gap_remediation_plan for each identified resource gap with owner, target_date, budget_approved status, and current_status \u2014 or a formal board-approved acceptance record for gaps accepted as residual risk", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-05-E5", "description": "compliance_tooling_inventory listing each platform with license_status, coverage_scope (which AI systems are covered), and last_validated_date confirming active integration with data sources", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://resilience/controls/RG-05", "id": "RG-05", "domain": "resilience", "name": "Resilience Program Resourcing", "validation_objective": "The resilience program must have an approved and tracked budget line item, all defined resilience roles filled at or above minimum staffing level with no vacancy exceeding 90 days, a tooling inventory with no documented gaps that have caused a required test cadence deferral in the review period, and an annual resource adequacy review delivered to the Resilience Steering Committee.", "blocking_effect": "requires-review", "evidence_required": [ "Approved resilience program resource plan with dedicated budget line item, planning approval date within the current fiscal year, and budget vs. actuals tracking record", "Staffing inventory showing each required resilience role, the minimum headcount threshold, current headcount, and vacancy status with days-open for any open positions", "Tooling inventory covering all resilience tooling categories (monitoring, chaos engineering, DR orchestration, backup verification, model snapshot management) with gap assessment results and last review date", "Annual resource adequacy review report presented to and acknowledged by the Resilience Steering Committee, covering staffing, tooling, and budget against program obligations", "Test calendar showing scheduled obligations vs. actual execution, with any deferrals coded by root cause (resource constraint vs. other)" ], "evidence": [ { "id": "RG-05-E1", "description": "Approved resilience program resource plan with dedicated budget line item, planning approval date within the current fiscal year, and budget vs. actuals tracking record", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RG-05-E2", "description": "Staffing inventory showing each required resilience role, the minimum headcount threshold, current headcount, and vacancy status with days-open for any open positions", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RG-05-E3", "description": "Tooling inventory covering all resilience tooling categories (monitoring, chaos engineering, DR orchestration, backup verification, model snapshot management) with gap assessment results and last review date", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "RG-05-E4", "description": "Annual resource adequacy review report presented to and acknowledged by the Resilience Steering Committee, covering staffing, tooling, and budget against program obligations", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RG-05-E5", "description": "Test calendar showing scheduled obligations vs. actual execution, with any deferrals coded by root cause (resource constraint vs. other)", "evidence_type": "automated-test-result", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://model/controls/OA-03", "id": "OA-03", "domain": "model", "name": "AI Model Governance Committee", "validation_objective": "The organization must have a formally chartered AI Model Governance Committee with documented membership covering all required functional areas, exclusive approval authority over high-risk model deployments and risk appetite thresholds, and auditable meeting minutes retained for seven years. The committee must have met at minimum quarterly in each of the preceding four quarters, with quorum achieved for all binding decisions.", "blocking_effect": "blocks-deployment", "evidence_required": [ "committee_charter current version with executive-level approval signature and date, specifying membership composition, decision rights matrix, quorum requirements, and meeting cadence", "meeting_minutes for all scheduled quarterly sessions in the preceding 12-month period, demonstrating quorum was met and binding decisions were recorded with rationale", "decision_log showing AIGC approval records for all high-risk model deployments and risk appetite changes in the preceding 12 months, cross-referenced against the production model registry", "membership_roster with functional affiliations confirming representation from AI/ML engineering, model validation, legal/compliance, risk management, and at least one business line" ], "evidence": [ { "id": "OA-03-E1", "description": "committee_charter current version with executive-level approval signature and date, specifying membership composition, decision rights matrix, quorum requirements, and meeting cadence", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-03-E2", "description": "meeting_minutes for all scheduled quarterly sessions in the preceding 12-month period, demonstrating quorum was met and binding decisions were recorded with rationale", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-03-E3", "description": "decision_log showing AIGC approval records for all high-risk model deployments and risk appetite changes in the preceding 12 months, cross-referenced against the production model registry", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-03-E4", "description": "membership_roster with functional affiliations confirming representation from AI/ML engineering, model validation, legal/compliance, risk management, and at least one business line", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 Clause 5.3 (Organizational roles, responsibilities and authorities) requires top management to assign and communicate relevant roles and authorities. OA-03\u2019s chartered committee documents those authorities for AI model decisions." } ] }, { "requirement_id": "ISO42001-7.2", "section": "\u00a77.2", "title": "Competence", "text": "The organization shall determine the necessary competence of persons doing work that affects AI performance and conformance, ensure persons are competent on the basis of appropriate education, training, or experience, and retain documented information as evidence of competence.", "verdict": "partial", "coverage": "partial", "notes": "Compliance training and awareness program and ethics training and capability building address AI competence development. Apeiris does not define competency frameworks or track individual staff qualifications.", "control_count": 3, "proof_chain": [ { "control": "apeiris://compliance/controls/CI-05", "id": "CI-05", "domain": "compliance", "name": "Compliance Training and Awareness Program", "validation_objective": "All in-scope personnel have completed role-specific AI compliance training within the required period, with attestation records documenting individual completion stored in a tracked learning management system. Training content must have been reviewed for legal accuracy within the prior 12 months.", "blocking_effect": "requires-review", "evidence_required": [ "LMS completion records listing employee_id, role_category, training_module_id, completion_timestamp, and pass/fail status for all in-scope staff during the audit period", "Training attestation certificates signed by each participant and retained for the audit period, covering EU AI Act, GDPR, and sector-specific AI obligation modules", "Training curriculum legal review sign-off from counsel documenting reviewer identity, review date, and specific regulatory changes prompting the review", "Knowledge assessment results by role category showing aggregate pass rates and individual scores for the current training cycle", "Just-in-time compliance notice log showing distribution date, recipient list, and triggering regulatory event for each notice issued in the period" ], "evidence": [ { "id": "CI-05-E1", "description": "LMS completion records listing employee_id, role_category, training_module_id, completion_timestamp, and pass/fail status for all in-scope staff during the audit period", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-05-E2", "description": "Training attestation certificates signed by each participant and retained for the audit period, covering EU AI Act, GDPR, and sector-specific AI obligation modules", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-05-E3", "description": "Training curriculum legal review sign-off from counsel documenting reviewer identity, review date, and specific regulatory changes prompting the review", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CI-05-E4", "description": "Knowledge assessment results by role category showing aggregate pass rates and individual scores for the current training cycle", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-05-E5", "description": "Just-in-time compliance notice log showing distribution date, recipient list, and triggering regulatory event for each notice issued in the period", "evidence_type": "audit-log", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://ethics/controls/EG-04", "id": "EG-04", "domain": "ethics", "name": "Ethics Training and Capability Building", "validation_objective": "All personnel with AI development, deployment, or governance responsibilities must have completed role-appropriate ethics training within the past 12 months, with training prerequisites enforced as a gate for AI system access and product sign-off authority. Training curricula must be role-differentiated across at least four tracks covering practitioners, product managers, legal/compliance, and executives.", "blocking_effect": "blocks-deployment", "evidence_required": [ "training_completion_records disaggregated by role (AI practitioner, product manager, legal/compliance, executive) showing completion date, curriculum version, and assessment score for each individual within the trailing 12 months", "role_differentiated_curriculum_documentation showing distinct training tracks for each AI-facing role with topic coverage including fairness metrics, bias detection, regulatory obligations, and escalation procedures", "system_access_prerequisite_log confirming ethics training completion status was verified before granting AI development environment access or product approval authority", "training_refresh_trigger_record documenting evaluation of training currency following major regulatory changes with decision rationale and revised curriculum effective date where applicable" ], "evidence": [ { "id": "EG-04-E1", "description": "training_completion_records disaggregated by role (AI practitioner, product manager, legal/compliance, executive) showing completion date, curriculum version, and assessment score for each individual within the trailing 12 months", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-04-E2", "description": "role_differentiated_curriculum_documentation showing distinct training tracks for each AI-facing role with topic coverage including fairness metrics, bias detection, regulatory obligations, and escalation procedures", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-04-E3", "description": "system_access_prerequisite_log confirming ethics training completion status was verified before granting AI development environment access or product approval authority", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EG-04-E4", "description": "training_refresh_trigger_record documenting evaluation of training currency following major regulatory changes with decision rationale and revised curriculum effective date where applicable", "evidence_type": "evaluation-scorecard", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001:2023 \u00a77.2 requires organizations to determine necessary competence for AI management system roles and ensure persons are competent. This control directly implements role-specific competence requirements through structured training programs." }, { "control": "apeiris://compliance/controls/AU-02", "id": "AU-02", "domain": "compliance", "name": "Evidence Collection, Curation, and Validation", "validation_objective": "Every compliance evidence artifact in the active evidence library has a SHA-256 hash computed at the moment of collection, a documented source_system and collector_identity, a collection_timestamp within the required freshness window for its artifact type, and has passed all validation gate checks prior to promotion. No artifact with missing or failed provenance metadata exists in the active library.", "blocking_effect": "advisory", "evidence_required": [ "Evidence repository ingestion log showing source_system, collector_identity, collection_timestamp, and SHA-256_hash computed at ingest for every artifact collected during the audit period", "Validation gate rejection log documenting all artifacts that failed validation checks, the specific failure reason (missing hash, staleness, format error, incomplete metadata), and their disposition", "Manual curation workflow records for artifacts that bypassed automated validation, including curator identity, review method, artifact authenticity basis, and sign-off timestamp", "Monthly reconciliation reports comparing the artifact inventory against per-framework requirements, identifying collection gaps by artifact type and their age in days", "SHA-256 hash integrity verification report for the audit period confirming no mismatches between ingestion records and current artifact content in the repository" ], "evidence": [ { "id": "AU-02-E1", "description": "Evidence repository ingestion log showing source_system, collector_identity, collection_timestamp, and SHA-256_hash computed at ingest for every artifact collected during the audit period", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AU-02-E2", "description": "Validation gate rejection log documenting all artifacts that failed validation checks, the specific failure reason (missing hash, staleness, format error, incomplete metadata), and their disposition", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AU-02-E3", "description": "Manual curation workflow records for artifacts that bypassed automated validation, including curator identity, review method, artifact authenticity basis, and sign-off timestamp", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "AU-02-E4", "description": "Monthly reconciliation reports comparing the artifact inventory against per-framework requirements, identifying collection gaps by artifact type and their age in days", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AU-02-E5", "description": "SHA-256 hash integrity verification report for the audit period confirming no mismatches between ingestion records and current artifact content in the repository", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "ISO42001-7.3", "section": "\u00a77.3", "title": "Awareness", "text": "Persons doing work under the organization's control shall be aware of the AI policy, their contribution to the effectiveness of the AIMS, the implications of not conforming with AIMS requirements, and the AI objectives.", "verdict": "partial", "coverage": "partial", "notes": "Training and awareness program and ethics capability building address awareness requirements. Policy version control and distribution supports policy communication. Individual awareness verification and acknowledgment tracking are organizational HR/compliance processes.", "control_count": 3, "proof_chain": [ { "control": "apeiris://compliance/controls/CI-05", "id": "CI-05", "domain": "compliance", "name": "Compliance Training and Awareness Program", "validation_objective": "All in-scope personnel have completed role-specific AI compliance training within the required period, with attestation records documenting individual completion stored in a tracked learning management system. Training content must have been reviewed for legal accuracy within the prior 12 months.", "blocking_effect": "requires-review", "evidence_required": [ "LMS completion records listing employee_id, role_category, training_module_id, completion_timestamp, and pass/fail status for all in-scope staff during the audit period", "Training attestation certificates signed by each participant and retained for the audit period, covering EU AI Act, GDPR, and sector-specific AI obligation modules", "Training curriculum legal review sign-off from counsel documenting reviewer identity, review date, and specific regulatory changes prompting the review", "Knowledge assessment results by role category showing aggregate pass rates and individual scores for the current training cycle", "Just-in-time compliance notice log showing distribution date, recipient list, and triggering regulatory event for each notice issued in the period" ], "evidence": [ { "id": "CI-05-E1", "description": "LMS completion records listing employee_id, role_category, training_module_id, completion_timestamp, and pass/fail status for all in-scope staff during the audit period", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-05-E2", "description": "Training attestation certificates signed by each participant and retained for the audit period, covering EU AI Act, GDPR, and sector-specific AI obligation modules", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-05-E3", "description": "Training curriculum legal review sign-off from counsel documenting reviewer identity, review date, and specific regulatory changes prompting the review", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CI-05-E4", "description": "Knowledge assessment results by role category showing aggregate pass rates and individual scores for the current training cycle", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-05-E5", "description": "Just-in-time compliance notice log showing distribution date, recipient list, and triggering regulatory event for each notice issued in the period", "evidence_type": "audit-log", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://ethics/controls/EG-04", "id": "EG-04", "domain": "ethics", "name": "Ethics Training and Capability Building", "validation_objective": "All personnel with AI development, deployment, or governance responsibilities must have completed role-appropriate ethics training within the past 12 months, with training prerequisites enforced as a gate for AI system access and product sign-off authority. Training curricula must be role-differentiated across at least four tracks covering practitioners, product managers, legal/compliance, and executives.", "blocking_effect": "blocks-deployment", "evidence_required": [ "training_completion_records disaggregated by role (AI practitioner, product manager, legal/compliance, executive) showing completion date, curriculum version, and assessment score for each individual within the trailing 12 months", "role_differentiated_curriculum_documentation showing distinct training tracks for each AI-facing role with topic coverage including fairness metrics, bias detection, regulatory obligations, and escalation procedures", "system_access_prerequisite_log confirming ethics training completion status was verified before granting AI development environment access or product approval authority", "training_refresh_trigger_record documenting evaluation of training currency following major regulatory changes with decision rationale and revised curriculum effective date where applicable" ], "evidence": [ { "id": "EG-04-E1", "description": "training_completion_records disaggregated by role (AI practitioner, product manager, legal/compliance, executive) showing completion date, curriculum version, and assessment score for each individual within the trailing 12 months", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-04-E2", "description": "role_differentiated_curriculum_documentation showing distinct training tracks for each AI-facing role with topic coverage including fairness metrics, bias detection, regulatory obligations, and escalation procedures", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-04-E3", "description": "system_access_prerequisite_log confirming ethics training completion status was verified before granting AI development environment access or product approval authority", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EG-04-E4", "description": "training_refresh_trigger_record documenting evaluation of training currency following major regulatory changes with decision rationale and revised curriculum effective date where applicable", "evidence_type": "evaluation-scorecard", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001:2023 \u00a77.2 requires organizations to determine necessary competence for AI management system roles and ensure persons are competent. This control directly implements role-specific competence requirements through structured training programs." }, { "control": "apeiris://authority/controls/PO-02", "id": "PO-02", "domain": "authority", "name": "Policy Version Control and Distribution", "validation_objective": "All AI authority policies must be stored in a version-controlled repository with semantic versioning and approval-gated merges, and every AI system runtime configuration must reference a specific approved policy version. Upon a policy version update, all linked AI system configurations must be updated to the new version within one business day, and all superseded versions must be retained in an immutable archive with their effective date ranges intact.", "blocking_effect": "blocks-deployment", "evidence_required": [ "policy_version_distribution_log showing each policy version publication event, the list of linked AI system configurations notified, and the timestamp of configuration update for each consumer", "ai_runtime_policy_version_references confirming each active AI system references a specific approved policy version rather than an unversioned label", "policy_archive_effective_date_ranges document confirming all superseded policy versions are retained with their start and end effective dates", "policy_repository_approval_log showing committer attribution and approval workflow completion for every version merge during the audit period" ], "evidence": [ { "id": "PO-02-E1", "description": "policy_version_distribution_log showing each policy version publication event, the list of linked AI system configurations notified, and the timestamp of configuration update for each consumer", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "PO-02-E2", "description": "ai_runtime_policy_version_references confirming each active AI system references a specific approved policy version rather than an unversioned label", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PO-02-E3", "description": "policy_archive_effective_date_ranges document confirming all superseded policy versions are retained with their start and end effective dates", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-02-E4", "description": "policy_repository_approval_log showing committer attribution and approval workflow completion for every version merge during the audit period", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "Semantic versioning and retention of superseded policies reflect \u00a77.5 documented information, partially." } ] }, { "requirement_id": "ISO42001-7.4", "section": "\u00a77.4", "title": "Communication", "text": "The organization shall determine the need for internal and external communications relevant to the AIMS, including what to communicate, when to communicate, to whom to communicate, and how to communicate.", "verdict": "partial", "coverage": "partial", "notes": "Communication and commitment policy, governance reporting, compliance program metrics and KPIs, and board reporting controls address structured communication channels. Ad hoc internal communication protocols and external AI disclosure decisions are management-layer concerns.", "control_count": 4, "proof_chain": [ { "control": "apeiris://authority/controls/PO-06", "id": "PO-06", "domain": "authority", "name": "Communication and Commitment Policy", "validation_objective": "A General-Counsel-and-CRO-approved communication authority matrix must exist for every AI system with external communication capability, and every outbound AI communication must be evaluated against that matrix before transmission \u2014 with communications exceeding documented authority limits blocked or escalated, and the evaluation logged with communication_class, authority_matrix_version, and verdict.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "communication_authority_matrix for each AI system with external capability, including permitted_statement_types, max_commitment_value, prohibited_categories, escalation_triggers, general_counsel_approval_signature, and cro_approval_signature with timestamps", "pre_send_policy_evaluation_log with communication_id, ai_system_id, communication_class, authority_matrix_version, verdict (permit/block/escalate), and evaluated_at for every outbound AI communication", "escalation_routing_record for each escalated communication with escalation_trigger_matched, reviewer_id, and resolution_decision", "authority_matrix_review_history showing General Counsel and CRO review timestamps and revision rationale for each version" ], "evidence": [ { "id": "PO-06-E1", "description": "communication_authority_matrix for each AI system with external capability, including permitted_statement_types, max_commitment_value, prohibited_categories, escalation_triggers, general_counsel_approval_signature, and cro_approval_signature with timestamps", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-06-E2", "description": "pre_send_policy_evaluation_log with communication_id, ai_system_id, communication_class, authority_matrix_version, verdict (permit/block/escalate), and evaluated_at for every outbound AI communication", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-06-E3", "description": "escalation_routing_record for each escalated communication with escalation_trigger_matched, reviewer_id, and resolution_decision", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-06-E4", "description": "authority_matrix_review_history showing General Counsel and CRO review timestamps and revision rationale for each version", "evidence_type": "human-review-record", "verification": "human" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://authority/controls/PG-07", "id": "PG-07", "domain": "authority", "name": "Policy Governance Reporting", "validation_objective": "Policy governance reports must be generated on the defined schedule for all audience tiers (executive management, audit committee, board), with every defined metric field populated from verified upstream data sources. Distribution logs must confirm delivery within the deadline for each audience.", "blocking_effect": "advisory", "evidence_required": [ "governance_report_package containing report templates per audience tier, populated metric fields, and data-source mappings for each reporting period", "report_distribution_log showing recipient, delivery timestamp, and report version for each scheduled and event-driven governance report", "reporting_pipeline_audit_trail confirming each metric value was sourced from the canonical upstream control system with no manual entry points", "audit_committee_submission_record confirming receipt of quarterly governance reports within the defined deadline", "event_driven_report_log showing supplemental reports triggered by material incidents above the defined severity threshold with generation-to-delivery elapsed time" ], "evidence": [ { "id": "PG-07-E1", "description": "governance_report_package containing report templates per audience tier, populated metric fields, and data-source mappings for each reporting period", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PG-07-E2", "description": "report_distribution_log showing recipient, delivery timestamp, and report version for each scheduled and event-driven governance report", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PG-07-E3", "description": "reporting_pipeline_audit_trail confirming each metric value was sourced from the canonical upstream control system with no manual entry points", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PG-07-E4", "description": "audit_committee_submission_record confirming receipt of quarterly governance reports within the defined deadline", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PG-07-E5", "description": "event_driven_report_log showing supplemental reports triggered by material incidents above the defined severity threshold with generation-to-delivery elapsed time", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://compliance/controls/CG-07", "id": "CG-07", "domain": "compliance", "name": "Compliance Program Metrics and KPIs", "validation_objective": "A two-tier compliance metrics framework exists with at least five board-level KPIs (including at least one outcome indicator per applicable regulatory framework) and at least fifteen operational metrics covering obligation coverage, remediation velocity, and control effectiveness, with automated data collection from source systems and four consecutive periods of historical trend data available at reporting time.", "blocking_effect": "advisory", "evidence_required": [ "kpi_framework_document defining each metric with metric_name, metric_type (leading/lagging/outcome/activity), calculation_method, data_source, collection_frequency, reporting_tier (board/operational), and metric_owner \u2014 with annual_review_date within the last 12 months", "board_kpi_dashboard reports for at least four consecutive quarters showing trend data, with compliance_committee_meeting_minutes confirming each was presented and received by the Compliance Committee", "operational_metrics_report for the current reporting period showing current_value for all defined operational metrics with data_source attribution and freshness_timestamp <= 48 hours at time of report generation", "metric_data_pipeline_health_log confirming automated collection pipeline is active for each metric, with last_successful_collection_timestamp and error_rate for the preceding 30 days" ], "evidence": [ { "id": "CG-07-E1", "description": "kpi_framework_document defining each metric with metric_name, metric_type (leading/lagging/outcome/activity), calculation_method, data_source, collection_frequency, reporting_tier (board/operational), and metric_owner \u2014 with annual_review_date within the last 12 months", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-07-E2", "description": "board_kpi_dashboard reports for at least four consecutive quarters showing trend data, with compliance_committee_meeting_minutes confirming each was presented and received by the Compliance Committee", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-07-E3", "description": "operational_metrics_report for the current reporting period showing current_value for all defined operational metrics with data_source attribution and freshness_timestamp <= 48 hours at time of report generation", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-07-E4", "description": "metric_data_pipeline_health_log confirming automated collection pipeline is active for each metric, with last_successful_collection_timestamp and error_rate for the preceding 30 days", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://authority/controls/PE-06", "id": "PE-06", "domain": "authority", "name": "Board and Senior Management Policy Reporting", "validation_objective": "Quarterly AI policy governance reports must be produced on schedule, reviewed, and co-signed by both the Chief Risk Officer and General Counsel, with every reported metric traceable to a supporting evidence item in the PE-04 integrated package. All risk items exceeding the board-approved materiality thresholds must appear in the report with prioritized escalation recommendations and documented board response within 30 days.", "blocking_effect": "requires-review", "evidence_required": [ "board_ai_policy_governance_report with executive summary, risk-adjusted metrics, open gap inventory, and escalation recommendations, dated within the quarterly reporting cycle and referencing the PE-04 integrated package version used", "report_sign_off_log showing CRO identity, General Counsel identity, individual sign-off timestamps, and SHA-256 hash of the signed report version to detect post-signature modification", "materiality_threshold_schedule approved by the CRO and version-controlled, defining numeric thresholds for AI policy risk metrics that trigger mandatory board-level reporting and escalation", "report_distribution_log recording recipient role, distribution timestamp, and acknowledgment status for each quarterly report to confirm the board actually received the report" ], "evidence": [ { "id": "PE-06-E1", "description": "board_ai_policy_governance_report with executive summary, risk-adjusted metrics, open gap inventory, and escalation recommendations, dated within the quarterly reporting cycle and referencing the PE-04 integrated package version used", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PE-06-E2", "description": "report_sign_off_log showing CRO identity, General Counsel identity, individual sign-off timestamps, and SHA-256 hash of the signed report version to detect post-signature modification", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PE-06-E3", "description": "materiality_threshold_schedule approved by the CRO and version-controlled, defining numeric thresholds for AI policy risk metrics that trigger mandatory board-level reporting and escalation", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PE-06-E4", "description": "report_distribution_log recording recipient role, distribution timestamp, and acknowledgment status for each quarterly report to confirm the board actually received the report", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "ISO42001-7.5", "section": "\u00a77.5", "title": "Documented information", "text": "The AIMS shall include documented information required by this document and documented information determined by the organization as being necessary for the effectiveness of the AIMS. The organization shall ensure documented information is available, adequately protected, and controlled.", "verdict": "partial", "coverage": "partial", "notes": "Policy evidence archive, evidence collection and validation, structured model documentation (model card), and audit trail integrity address documented information for AI systems. Document management system controls (version control for non-AI documents, access permissions) extend beyond Apeiris scope.", "control_count": 4, "proof_chain": [ { "control": "apeiris://authority/controls/PE-01", "id": "PE-01", "domain": "authority", "name": "Policy Evidence Archive", "validation_objective": "All policy evidence artifacts must be stored in a tamper-evident, versioned archive where entries are immutable once committed, indexed by artifact type and control ID, and retrievable within the defined SLA during regulatory examination or litigation hold. The archive must produce a cryptographic proof of immutability on demand.", "blocking_effect": "blocks-deployment", "evidence_required": [ "archive_commit_log showing every artifact entry with artifact_id, control_id, committed_at timestamp, SHA-256 hash, and committer identity \u2014 with no modification events after initial commit", "tamper_evidence_record containing the Merkle root or audit log hash for the archive state at each quarterly checkpoint, signed by the archive operator", "retrieval_test_record showing that a representative sample of archived artifacts was successfully retrieved within the defined SLA, with retrieval timestamps and artifact hashes", "litigation_hold_activation_record documenting hold scope, activation timestamp, and confirmation that affected artifacts are locked against deletion for the hold duration", "archive_access_control_manifest listing authorized readers and writers with role assignments, confirming write access is restricted to the ingestion pipeline and no interactive modification is permitted" ], "evidence": [ { "id": "PE-01-E1", "description": "archive_commit_log showing every artifact entry with artifact_id, control_id, committed_at timestamp, SHA-256 hash, and committer identity \u2014 with no modification events after initial commit", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PE-01-E2", "description": "tamper_evidence_record containing the Merkle root or audit log hash for the archive state at each quarterly checkpoint, signed by the archive operator", "evidence_type": "audit-log", "verification": "automated" }, { "id": "PE-01-E3", "description": "retrieval_test_record showing that a representative sample of archived artifacts was successfully retrieved within the defined SLA, with retrieval timestamps and artifact hashes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PE-01-E4", "description": "litigation_hold_activation_record documenting hold scope, activation timestamp, and confirmation that affected artifacts are locked against deletion for the hold duration", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PE-01-E5", "description": "archive_access_control_manifest listing authorized readers and writers with role assignments, confirming write access is restricted to the ingestion pipeline and no interactive modification is permitted", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "Tamper-evident retention of policy evidence reflects \u00a77.5 documented information control, partially." }, { "control": "apeiris://compliance/controls/AU-02", "id": "AU-02", "domain": "compliance", "name": "Evidence Collection, Curation, and Validation", "validation_objective": "Every compliance evidence artifact in the active evidence library has a SHA-256 hash computed at the moment of collection, a documented source_system and collector_identity, a collection_timestamp within the required freshness window for its artifact type, and has passed all validation gate checks prior to promotion. No artifact with missing or failed provenance metadata exists in the active library.", "blocking_effect": "advisory", "evidence_required": [ "Evidence repository ingestion log showing source_system, collector_identity, collection_timestamp, and SHA-256_hash computed at ingest for every artifact collected during the audit period", "Validation gate rejection log documenting all artifacts that failed validation checks, the specific failure reason (missing hash, staleness, format error, incomplete metadata), and their disposition", "Manual curation workflow records for artifacts that bypassed automated validation, including curator identity, review method, artifact authenticity basis, and sign-off timestamp", "Monthly reconciliation reports comparing the artifact inventory against per-framework requirements, identifying collection gaps by artifact type and their age in days", "SHA-256 hash integrity verification report for the audit period confirming no mismatches between ingestion records and current artifact content in the repository" ], "evidence": [ { "id": "AU-02-E1", "description": "Evidence repository ingestion log showing source_system, collector_identity, collection_timestamp, and SHA-256_hash computed at ingest for every artifact collected during the audit period", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AU-02-E2", "description": "Validation gate rejection log documenting all artifacts that failed validation checks, the specific failure reason (missing hash, staleness, format error, incomplete metadata), and their disposition", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AU-02-E3", "description": "Manual curation workflow records for artifacts that bypassed automated validation, including curator identity, review method, artifact authenticity basis, and sign-off timestamp", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "AU-02-E4", "description": "Monthly reconciliation reports comparing the artifact inventory against per-framework requirements, identifying collection gaps by artifact type and their age in days", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AU-02-E5", "description": "SHA-256 hash integrity verification report for the audit period confirming no mismatches between ingestion records and current artifact content in the repository", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://model/controls/LI-04", "id": "LI-04", "domain": "model", "name": "Structured Model Documentation \u2014 Complete Model Card with All Required Sections", "validation_objective": "Every model submitted for registration must have a schema-validated model card with all nine Mitchell et al. 2019 sections substantively populated and passing field-level validation rules; the model card must be version-locked to the artifact hash and returned as structured metadata from the registry API; and registration must be blocked when any required section is absent, empty, or contains only placeholder text.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_card_completeness_validation_report showing pass/fail status per section with field-level validation results, registration blocking decision, and validation timestamp for the current artifact version", "versioned_model_card artifact linked to the specific model artifact hash with all nine Mitchell et al. sections containing substantive content (not placeholder text), retrievable from the registry by artifact hash", "model_registry_entry showing the current model card version hash stored alongside the artifact hash as paired immutable fields", "eu_ai_act_annex_iv_supplemental_record for EU AI Act high-risk in-scope systems confirming Annex IV technical documentation fields are populated in addition to the nine Mitchell et al. sections" ], "evidence": [ { "id": "LI-04-E1", "description": "model_card_completeness_validation_report showing pass/fail status per section with field-level validation results, registration blocking decision, and validation timestamp for the current artifact version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-04-E2", "description": "versioned_model_card artifact linked to the specific model artifact hash with all nine Mitchell et al. sections containing substantive content (not placeholder text), retrievable from the registry by artifact hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-04-E3", "description": "model_registry_entry showing the current model card version hash stored alongside the artifact hash as paired immutable fields", "evidence_type": "model-card", "verification": "attested" }, { "id": "LI-04-E4", "description": "eu_ai_act_annex_iv_supplemental_record for EU AI Act high-risk in-scope systems confirming Annex IV technical documentation fields are populated in addition to the nine Mitchell et al. sections", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 A.6.2.3 (Documentation of AI system design and development) requires documented design and development information. A complete, versioned model card linked to each release satisfies that documentation requirement for models." }, { "control": "apeiris://compliance/controls/AU-04", "id": "AU-04", "domain": "compliance", "name": "Audit Trail Integrity", "validation_objective": "The audit log system must maintain a cryptographically chained, append-only record of all compliance program activities \u2014 including policy attestations, control assessments, evidence submissions, and configuration changes \u2014 such that any attempt to modify, delete, or insert log records is detectable within 24 hours of occurrence. Automated daily hash chain verification must confirm log integrity continuously and alert the compliance officer within 1 hour of any detected break.", "blocking_effect": "advisory", "evidence_required": [ "cryptographic_hash_chain_report listing hash values for each log batch and chain linkage between successive batches, covering the full audit period with no unexplained gaps", "WORM_storage_replication_log confirming each log batch was replicated to immutable secondary store within 60 seconds, with source generation timestamp and secondary write timestamp for each batch", "daily_integrity_verification_report showing automated hash chain verification results, detected breaks, and alert dispatch timestamps for each verification run in the last 30 days", "log_custody_register documenting all personnel with access to log infrastructure, last quarterly access review date, and access removal records for personnel no longer requiring access", "log_gap_analysis_report confirming no unexplained gaps in log sequence numbers or timestamps for the audit period" ], "evidence": [ { "id": "AU-04-E1", "description": "cryptographic_hash_chain_report listing hash values for each log batch and chain linkage between successive batches, covering the full audit period with no unexplained gaps", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AU-04-E2", "description": "WORM_storage_replication_log confirming each log batch was replicated to immutable secondary store within 60 seconds, with source generation timestamp and secondary write timestamp for each batch", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AU-04-E3", "description": "daily_integrity_verification_report showing automated hash chain verification results, detected breaks, and alert dispatch timestamps for each verification run in the last 30 days", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "AU-04-E4", "description": "log_custody_register documenting all personnel with access to log infrastructure, last quarterly access review date, and access removal records for personnel no longer requiring access", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AU-04-E5", "description": "log_gap_analysis_report confirming no unexplained gaps in log sequence numbers or timestamps for the audit period", "evidence_type": "audit-log", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "ISO42001-8.1", "section": "\u00a78.1", "title": "Operational planning and control", "text": "The organization shall plan, implement, control, monitor, and review the processes needed to meet requirements for the provision of AI systems, and to implement the actions determined in the planning phase.", "verdict": "supported", "coverage": "direct", "notes": "Authorized action scope manifest, agent deployment policy and pre-deployment review gate, pre-deployment evaluation gate, deployment scope attestation, and compliance control testing program together implement operational planning and control for AI systems.", "control_count": 5, "proof_chain": [ { "control": "apeiris://agentic/controls/AB-01", "id": "AB-01", "domain": "agentic", "name": "Authorized Action Scope Manifest", "validation_objective": "Prove that every deployed agent has a machine-readable action scope manifest enumerating its complete authorized action set, and that the platform enforcement layer blocks any attempt to execute an action not listed in the manifest. No action outside the manifest may execute without a manifest update that passes governance review.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "Machine-readable action scope manifest (JSON or YAML) signed and linked to the agent's registry entry with a version-matched reference", "Platform enforcement log showing at least one blocked out-of-manifest action attempt during the test period, or a probed block event from a compliance test", "Change history records for the manifest showing governance review approvals and approver identities for each scope expansion", "Agent registry entry with version identifier that matches the manifest reference exactly" ], "evidence": [ { "id": "AB-01-E1", "description": "Machine-readable action scope manifest (JSON or YAML) signed and linked to the agent's registry entry with a version-matched reference", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "AB-01-E2", "description": "Platform enforcement log showing at least one blocked out-of-manifest action attempt during the test period, or a probed block event from a compliance test", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AB-01-E3", "description": "Change history records for the manifest showing governance review approvals and approver identities for each scope expansion", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "AB-01-E4", "description": "Agent registry entry with version identifier that matches the manifest reference exactly", "evidence_type": "configuration-snapshot", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 \u00a76.1.3 requires the organization to select and implement AI risk treatment options and produce a risk treatment plan. The Action Scope Manifest is an implemented treatment for the excessive-agency risk identified during AI risk assessment: permitted actions are made explicit and machine-enforceable." }, { "control": "apeiris://agentic/controls/AG-02", "id": "AG-02", "domain": "agentic", "name": "Agent Deployment Policy and Pre-Deployment Review Gate", "validation_objective": "Every production AI agent has a signed, complete deployment approval record meeting the requirements of its assigned consequence tier, and the CI/CD pipeline enforces a hard gate that blocks promotion when that record is absent, expired, or incomplete.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Ratified Agent Deployment Policy document defining consequence tiers, approval authorities, mandatory review artifacts, and maximum approval validity period", "Signed deployment approval record for each production agent, including agent ID, consequence tier, capability manifest hash, authorization scope declaration, and reviewer identity", "CI/CD pipeline audit log showing gate enforcement events (approvals, rejections, blocks) with timestamps and artifact hashes", "Agent consequence tier assignment records linked to the deployment approval for each production agent", "Monitoring configuration validation artifact confirming SOC integration requirements were satisfied at approval time" ], "evidence": [ { "id": "AG-02-E1", "description": "Ratified Agent Deployment Policy document defining consequence tiers, approval authorities, mandatory review artifacts, and maximum approval validity period", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AG-02-E2", "description": "Signed deployment approval record for each production agent, including agent ID, consequence tier, capability manifest hash, authorization scope declaration, and reviewer identity", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "AG-02-E3", "description": "CI/CD pipeline audit log showing gate enforcement events (approvals, rejections, blocks) with timestamps and artifact hashes", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AG-02-E4", "description": "Agent consequence tier assignment records linked to the deployment approval for each production agent", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AG-02-E5", "description": "Monitoring configuration validation artifact confirming SOC integration requirements were satisfied at approval time", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 Clause 8.4 requires AI system impact assessment before deployment, including review of potential harms and planned mitigation measures. The deployment review checklist directly instantiates the impact assessment process as a structured, gated artifact." }, { "control": "apeiris://model/controls/EV-01", "id": "EV-01", "domain": "model", "name": "Pre-Deployment Evaluation Gate", "validation_objective": "No model artifact is promoted to production unless a signed evaluation manifest referencing that artifact's exact hash is present in the tamper-evident evaluation log and has received dual approval from named, authorized approvers. The deployment pipeline enforces this as a cryptographic gate \u2014 an absent, unsigned, or hash-mismatched manifest results in an automatic pipeline block with no override path except a logged exception with named risk-accepter.", "blocking_effect": "blocks-deployment", "evidence_required": [ "signed_evaluation_manifest with model_artifact_hash, evaluation_suite_version, evaluator_identities, per-dimension pass/fail outcome, signing_key_id, and manifest_signature (Ed25519) for every production model version", "tamper_evident_evaluation_log entry linking manifest_id to model_artifact_hash, recording append timestamp, appender identity, and log integrity proof", "dual_approval_record with two named approver identities, their organizational roles, approval timestamps, and the manifest_hash each approver authorized", "pipeline_execution_log showing at least one successful gate enforcement event: a deployment attempt with an absent or invalid manifest that was blocked, confirming the gate is operational rather than advisory" ], "evidence": [ { "id": "EV-01-E1", "description": "signed_evaluation_manifest with model_artifact_hash, evaluation_suite_version, evaluator_identities, per-dimension pass/fail outcome, signing_key_id, and manifest_signature (Ed25519) for every production model version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-01-E2", "description": "tamper_evident_evaluation_log entry linking manifest_id to model_artifact_hash, recording append timestamp, appender identity, and log integrity proof", "evidence_type": "audit-log", "verification": "automated" }, { "id": "EV-01-E3", "description": "dual_approval_record with two named approver identities, their organizational roles, approval timestamps, and the manifest_hash each approver authorized", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EV-01-E4", "description": "pipeline_execution_log showing at least one successful gate enforcement event: a deployment attempt with an absent or invalid manifest that was blocked, confirming the gate is operational rather than advisory", "evidence_type": "configuration-snapshot", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 A.6.2.4 (AI system verification and validation) requires verification and validation before deployment. EV-01\u2019s evaluation gate is the blocking control where those results are checked." }, { "control": "apeiris://authority/controls/PV-07", "id": "PV-07", "domain": "authority", "name": "Deployment Scope Attestation", "validation_objective": "Every active AI deployment must have a current, signed deployment scope attestation in the authority registry enumerating authorized geographic regions, legal entities, user population categories, use-case types, and applicable regulatory jurisdictions. The attestation must bear the signature of a named principal with verifiable authority over the declared scope dimensions, and runtime monitoring must detect and alert on AI activity outside attested boundaries.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Signed deployment scope attestation artifacts in the authority registry for all active AI deployments, with fields for geographic_regions, legal_entities, user_population_categories, use_case_types, applicable_jurisdictions, signatory_id, valid_from, and valid_until", "Signatory authority verification records confirming each signing principal has organizational authority over the specific geographic, legal entity, and jurisdictional scope dimensions they attested", "Out-of-scope activity monitoring alerts for any AI system operation detected outside attested boundaries, with system_id, detected_activity, attested_scope, and detection_timestamp", "Renewal records showing timely scope attestation renewal at defined intervals and following material scope dimension changes such as new market entry or entity restructuring" ], "evidence": [ { "id": "PV-07-E1", "description": "Signed deployment scope attestation artifacts in the authority registry for all active AI deployments, with fields for geographic_regions, legal_entities, user_population_categories, use_case_types, applicable_jurisdictions, signatory_id, valid_from, and valid_until", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PV-07-E2", "description": "Signatory authority verification records confirming each signing principal has organizational authority over the specific geographic, legal entity, and jurisdictional scope dimensions they attested", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PV-07-E3", "description": "Out-of-scope activity monitoring alerts for any AI system operation detected outside attested boundaries, with system_id, detected_activity, attested_scope, and detection_timestamp", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "PV-07-E4", "description": "Renewal records showing timely scope attestation renewal at defined intervals and following material scope dimension changes such as new market entry or entity restructuring", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "Scope attestation at deployment is an operational-control artifact, partially satisfying \u00a78.1." }, { "control": "apeiris://compliance/controls/CI-01", "id": "CI-01", "domain": "compliance", "name": "Compliance Control Testing Program", "validation_objective": "Every AI compliance control designated as active in the compliance program must have at least one documented test executed within its defined testing frequency cycle, with the test result recorded as pass/fail/exception and all exception items linked to an open remediation record. No compliance control may have lapsed testing (last_tested_at exceeding the defined test frequency) without an approved deferral record.", "blocking_effect": "requires-review", "evidence_required": [ "control_test_plan documenting each active compliance control with test_id, test_frequency, test_method, and responsible_tester", "test_execution_record for each completed test including control_id, test_id, execution_date, result (pass/fail/exception), tester_id, and methodology_notes", "exception_register linking each test exception to a remediation_record with owner_id, target_completion_date, and current_status", "testing_calendar showing scheduled test dates for all active controls across the forward 12-month period", "management_attestation signed by the compliance officer confirming the testing program scope and execution status as of the attestation date" ], "evidence": [ { "id": "CI-01-E1", "description": "control_test_plan documenting each active compliance control with test_id, test_frequency, test_method, and responsible_tester", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-01-E2", "description": "test_execution_record for each completed test including control_id, test_id, execution_date, result (pass/fail/exception), tester_id, and methodology_notes", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "CI-01-E3", "description": "exception_register linking each test exception to a remediation_record with owner_id, target_completion_date, and current_status", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "CI-01-E4", "description": "testing_calendar showing scheduled test dates for all active controls across the forward 12-month period", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "CI-01-E5", "description": "management_attestation signed by the compliance officer confirming the testing program scope and execution status as of the attestation date", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "ISO42001-8.2", "section": "\u00a78.2", "title": "AI risk assessment process", "text": "The organization shall perform AI risk assessments at planned intervals or when significant changes are proposed or occur.", "verdict": "supported", "coverage": "direct", "notes": "Risk and applicability classification, agentic risk assessment framework, scheduled model re-validation, and material-change determination controls implement periodic AI risk assessment as required.", "control_count": 5, "proof_chain": [ { "control": "apeiris://model/controls/EV-09", "id": "EV-09", "domain": "model", "name": "Risk and Applicability Classification", "validation_objective": "Every model system has a signed classification record produced before any evaluation work begins, containing a documented EU AI Act classification with provision-specific rationale referencing Articles 5, 6, 50, 51, and Annex III as applicable, an SR 26-2 model risk tier for in-scope institutions, a capability tier, and the full applicable Apeiris profiles list; the model registry gate prevents advancement to evaluation stage without this record; and re-classification is triggered on any significant change to use case, capability level, or applicable regulation.", "blocking_effect": "blocks-deployment", "evidence_required": [ "signed_classification_record containing eu_ai_act_classification with specific provision references, sr_262_tier where applicable, capability_tier, applicable_profiles list, mandatory_controls inventory, and obligations_inventory \u2014 produced before any evaluation artifact is created", "classification_questionnaire_responses document answering all required dimensions: intended_use_cases, affected_populations, decision_automation_level, human_oversight_mechanisms, deployment_jurisdiction, compute_budget, parameter_count", "non_high_risk_exclusion_rationale for systems classified below high-risk, explicitly addressing each relevant Annex III category with documented rationale for exclusion", "classification_review_records for all re-classification events documenting trigger_event, prior_classification, new_classification, and rationale with effective_date", "iso_42005_impact_assessment for high-impact-decision and eu-high-risk profile systems per ISO/IEC 42005:2025" ], "evidence": [ { "id": "EV-09-E1", "description": "signed_classification_record containing eu_ai_act_classification with specific provision references, sr_262_tier where applicable, capability_tier, applicable_profiles list, mandatory_controls inventory, and obligations_inventory \u2014 produced before any evaluation artifact is created", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-09-E2", "description": "classification_questionnaire_responses document answering all required dimensions: intended_use_cases, affected_populations, decision_automation_level, human_oversight_mechanisms, deployment_jurisdiction, compute_budget, parameter_count", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E3", "description": "non_high_risk_exclusion_rationale for systems classified below high-risk, explicitly addressing each relevant Annex III category with documented rationale for exclusion", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E4", "description": "classification_review_records for all re-classification events documenting trigger_event, prior_classification, new_classification, and rationale with effective_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E5", "description": "iso_42005_impact_assessment for high-impact-decision and eu-high-risk profile systems per ISO/IEC 42005:2025", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO 42001 \u00a76.1 requires risk assessment including determination of the significance of identified risks; formal classification operationalizes this." }, { "control": "apeiris://agentic/controls/AG-03", "id": "AG-03", "domain": "agentic", "name": "Agentic AI Risk Assessment Framework", "validation_objective": "Every production AI agent has a completed, current risk assessment evaluated against all five framework dimensions, with the resulting consequence tier documented and linked to the deployment approval and control mitigation plan.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "Annual risk reassessment records for all Critical-tier agents" ], "evidence": [ { "id": "AG-03-E1", "description": "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E2", "description": "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E3", "description": "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E4", "description": "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E5", "description": "Annual risk reassessment records for all Critical-tier agents", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 Clause 6.1 requires organizations to determine risks and opportunities related to the AI management system and plan actions to address them. A systematic risk assessment framework with defined scoring methodology satisfies this planning and risk determination requirement." }, { "control": "apeiris://compliance/controls/CA-01", "id": "CA-01", "domain": "compliance", "name": "Regulatory Scope Determination", "validation_objective": "Every AI system in the compliance registry must have an approved, version-controlled scope record that correctly identifies all applicable regulatory regimes based on its deployment jurisdiction, sector, data categories, and capability tier, and that was reviewed following the most recent material change to deployment context or applicable regulatory publication. Deployment pipeline advancement must be blocked for any system without an approved scope record.", "blocking_effect": "blocks-deployment", "evidence_required": [ "compliance_registry_scope_record containing system_id, applicable_regimes[], triggering_criteria[], approved_by, approved_at, and version_id demonstrating a complete and current classification", "regulatory_trigger_matrix with version_date and last_reviewed_on within 30 days of the most recent applicable regulatory publication affecting AI systems in the organization's jurisdictions", "deployment_gate_log entry for the AI system showing scope_record_approval_status was checked before production promotion with artifact scope_record_id referenced", "escalation_record for any ambiguous classification decisions showing legal_counsel_sign_off, resolution_rationale, and resolution_date within the defined SLA" ], "evidence": [ { "id": "CA-01-E1", "description": "compliance_registry_scope_record containing system_id, applicable_regimes[], triggering_criteria[], approved_by, approved_at, and version_id demonstrating a complete and current classification", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-01-E2", "description": "regulatory_trigger_matrix with version_date and last_reviewed_on within 30 days of the most recent applicable regulatory publication affecting AI systems in the organization's jurisdictions", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-01-E3", "description": "deployment_gate_log entry for the AI system showing scope_record_approval_status was checked before production promotion with artifact scope_record_id referenced", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-01-E4", "description": "escalation_record for any ambiguous classification decisions showing legal_counsel_sign_off, resolution_rationale, and resolution_date within the defined SLA", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001:2023 \u00a74.1 requires organisations to determine external and internal factors affecting AI management; CA-01 regulatory scope determination is the AI-specific implementation of this clause." }, { "control": "apeiris://model/controls/CR-03", "id": "CR-03", "domain": "model", "name": "Scheduled Model Re-validation", "validation_objective": "A full benchmark, bias, and safety evaluation suite must execute against every production model version on the defined re-validation schedule; results must be compared to the deployment-time baseline metrics, and any performance degradation beyond configured thresholds must trigger a formal response documented and initiated before the next operational window closes.", "blocking_effect": "blocks-deployment", "evidence_required": [ "re_validation_schedule_record per model version showing configured re-validation frequency, last_run_timestamp, next_run_due, and scheduled_suite_identifier with no unmonitored production versions", "scheduled_evaluation_report for each re-validation run showing benchmark results, bias metrics, and safety evaluation scores with explicit comparison to the deployment-time baseline", "threshold_comparison_record showing the delta between current re-validation results and baseline for each metric with a pass/fail determination against the configured degradation threshold", "re_validation_response_record for any threshold breach, documenting the triggered response action (rollback, retraining, or escalation), responsible_party, and closure_timestamp", "re_validation_coverage_audit confirming all active production model versions are enrolled in re-validation schedules and that no version has exceeded its next_run_due without a completed run" ], "evidence": [ { "id": "CR-03-E1", "description": "re_validation_schedule_record per model version showing configured re-validation frequency, last_run_timestamp, next_run_due, and scheduled_suite_identifier with no unmonitored production versions", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-03-E2", "description": "scheduled_evaluation_report for each re-validation run showing benchmark results, bias metrics, and safety evaluation scores with explicit comparison to the deployment-time baseline", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "CR-03-E3", "description": "threshold_comparison_record showing the delta between current re-validation results and baseline for each metric with a pass/fail determination against the configured degradation threshold", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-03-E4", "description": "re_validation_response_record for any threshold breach, documenting the triggered response action (rollback, retraining, or escalation), responsible_party, and closure_timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-03-E5", "description": "re_validation_coverage_audit confirming all active production model versions are enrolled in re-validation schedules and that no version has exceeded its next_run_due without a completed run", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 A.6.2.4 (AI system verification and validation) requires validation evidence to remain valid; CR-03\u2019s scheduled re-validation re-produces that evidence on a risk-tiered cadence." }, { "control": "apeiris://model/controls/LI-09", "id": "LI-09", "domain": "model", "name": "Material-Change Determination and Authorization Gate", "validation_objective": "Every planned change to a deployed AI model or its operating environment is assessed against a documented materiality threshold; changes that meet or exceed the threshold must complete a full re-evaluation and authorization cycle before the updated system goes live, and no material change may bypass this gate.", "blocking_effect": "blocks-deployment", "evidence_required": [ "change_assessment_record documenting the change type (model update, prompt change, RAG corpus change, guardrail change, provider-version change), the materiality determination (material/non-material), and the criteria applied", "re_evaluation_authorization_record for each material change showing completed evaluation cycle, approver identity, approval timestamp, and the specific evaluation artifacts reviewed", "deployment_gate_block_log confirming that attempted deployments of material changes without a completed authorization record were rejected by the pipeline", "change_classification_policy_document defining materiality thresholds for each change type, reviewed and signed by model governance and risk owners" ], "evidence": [ { "id": "LI-09-E1", "description": "change_assessment_record documenting the change type (model update, prompt change, RAG corpus change, guardrail change, provider-version change), the materiality determination (material/non-material), and the criteria applied", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-09-E2", "description": "re_evaluation_authorization_record for each material change showing completed evaluation cycle, approver identity, approval timestamp, and the specific evaluation artifacts reviewed", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "LI-09-E3", "description": "deployment_gate_block_log confirming that attempted deployments of material changes without a completed authorization record were rejected by the pipeline", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-09-E4", "description": "change_classification_policy_document defining materiality thresholds for each change type, reviewed and signed by model governance and risk owners", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 Clause 6.3 (Planning of changes) requires changes to be planned and controlled. LI-09\u2019s material-change taxonomy and authorization gate implement that discipline for models, prompts, and system configurations." } ] }, { "requirement_id": "ISO42001-8.3", "section": "\u00a78.3", "title": "AI risk treatment process", "text": "The organization shall implement the AI risk treatment plan and retain documented information as evidence of the results of the AI risk treatment process.", "verdict": "supported", "coverage": "direct", "notes": "Risk assessment framework, pre-deployment gate, remediation tracking, evidence collection, and AI incident response management implement risk treatment execution with evidentiary documentation.", "control_count": 5, "proof_chain": [ { "control": "apeiris://agentic/controls/AG-03", "id": "AG-03", "domain": "agentic", "name": "Agentic AI Risk Assessment Framework", "validation_objective": "Every production AI agent has a completed, current risk assessment evaluated against all five framework dimensions, with the resulting consequence tier documented and linked to the deployment approval and control mitigation plan.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "Annual risk reassessment records for all Critical-tier agents" ], "evidence": [ { "id": "AG-03-E1", "description": "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E2", "description": "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E3", "description": "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E4", "description": "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E5", "description": "Annual risk reassessment records for all Critical-tier agents", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 Clause 6.1 requires organizations to determine risks and opportunities related to the AI management system and plan actions to address them. A systematic risk assessment framework with defined scoring methodology satisfies this planning and risk determination requirement." }, { "control": "apeiris://model/controls/EV-01", "id": "EV-01", "domain": "model", "name": "Pre-Deployment Evaluation Gate", "validation_objective": "No model artifact is promoted to production unless a signed evaluation manifest referencing that artifact's exact hash is present in the tamper-evident evaluation log and has received dual approval from named, authorized approvers. The deployment pipeline enforces this as a cryptographic gate \u2014 an absent, unsigned, or hash-mismatched manifest results in an automatic pipeline block with no override path except a logged exception with named risk-accepter.", "blocking_effect": "blocks-deployment", "evidence_required": [ "signed_evaluation_manifest with model_artifact_hash, evaluation_suite_version, evaluator_identities, per-dimension pass/fail outcome, signing_key_id, and manifest_signature (Ed25519) for every production model version", "tamper_evident_evaluation_log entry linking manifest_id to model_artifact_hash, recording append timestamp, appender identity, and log integrity proof", "dual_approval_record with two named approver identities, their organizational roles, approval timestamps, and the manifest_hash each approver authorized", "pipeline_execution_log showing at least one successful gate enforcement event: a deployment attempt with an absent or invalid manifest that was blocked, confirming the gate is operational rather than advisory" ], "evidence": [ { "id": "EV-01-E1", "description": "signed_evaluation_manifest with model_artifact_hash, evaluation_suite_version, evaluator_identities, per-dimension pass/fail outcome, signing_key_id, and manifest_signature (Ed25519) for every production model version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-01-E2", "description": "tamper_evident_evaluation_log entry linking manifest_id to model_artifact_hash, recording append timestamp, appender identity, and log integrity proof", "evidence_type": "audit-log", "verification": "automated" }, { "id": "EV-01-E3", "description": "dual_approval_record with two named approver identities, their organizational roles, approval timestamps, and the manifest_hash each approver authorized", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EV-01-E4", "description": "pipeline_execution_log showing at least one successful gate enforcement event: a deployment attempt with an absent or invalid manifest that was blocked, confirming the gate is operational rather than advisory", "evidence_type": "configuration-snapshot", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 A.6.2.4 (AI system verification and validation) requires verification and validation before deployment. EV-01\u2019s evaluation gate is the blocking control where those results are checked." }, { "control": "apeiris://compliance/controls/CI-07", "id": "CI-07", "domain": "compliance", "name": "Remediation Tracking and Closure", "validation_objective": "Every compliance gap identified by control testing (CI-01), monitoring (CI-02), or internal audit (CI-06) has a corresponding remediation ticket with an assigned single owner, target date, documented root cause, remediation plan, and independently verified closure evidence. No critical-severity ticket is open beyond 15 business days without a documented executive escalation record.", "blocking_effect": "requires-review", "evidence_required": [ "Remediation register export listing all open and closed tickets with source_control, severity, assigned_owner, root_cause, remediation_plan, target_date, and actual_closure_date for the full audit period", "Closure verification records for each high and critical ticket documenting the independent verifier identity, verification method (re-test, configuration check, or re-assessment), and verification outcome", "Automated escalation log showing escalation trigger events and management acknowledgment timestamps for all overdue items during the period", "Recurrence analysis report identifying any finding appearing in both the current and prior audit cycle, with root cause explanation for recurrence", "Weekly remediation velocity reports showing open ticket counts by severity and age distribution across the audit period" ], "evidence": [ { "id": "CI-07-E1", "description": "Remediation register export listing all open and closed tickets with source_control, severity, assigned_owner, root_cause, remediation_plan, target_date, and actual_closure_date for the full audit period", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "CI-07-E2", "description": "Closure verification records for each high and critical ticket documenting the independent verifier identity, verification method (re-test, configuration check, or re-assessment), and verification outcome", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "CI-07-E3", "description": "Automated escalation log showing escalation trigger events and management acknowledgment timestamps for all overdue items during the period", "evidence_type": "audit-log", "verification": "automated" }, { "id": "CI-07-E4", "description": "Recurrence analysis report identifying any finding appearing in both the current and prior audit cycle, with root cause explanation for recurrence", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-07-E5", "description": "Weekly remediation velocity reports showing open ticket counts by severity and age distribution across the audit period", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://compliance/controls/AU-02", "id": "AU-02", "domain": "compliance", "name": "Evidence Collection, Curation, and Validation", "validation_objective": "Every compliance evidence artifact in the active evidence library has a SHA-256 hash computed at the moment of collection, a documented source_system and collector_identity, a collection_timestamp within the required freshness window for its artifact type, and has passed all validation gate checks prior to promotion. No artifact with missing or failed provenance metadata exists in the active library.", "blocking_effect": "advisory", "evidence_required": [ "Evidence repository ingestion log showing source_system, collector_identity, collection_timestamp, and SHA-256_hash computed at ingest for every artifact collected during the audit period", "Validation gate rejection log documenting all artifacts that failed validation checks, the specific failure reason (missing hash, staleness, format error, incomplete metadata), and their disposition", "Manual curation workflow records for artifacts that bypassed automated validation, including curator identity, review method, artifact authenticity basis, and sign-off timestamp", "Monthly reconciliation reports comparing the artifact inventory against per-framework requirements, identifying collection gaps by artifact type and their age in days", "SHA-256 hash integrity verification report for the audit period confirming no mismatches between ingestion records and current artifact content in the repository" ], "evidence": [ { "id": "AU-02-E1", "description": "Evidence repository ingestion log showing source_system, collector_identity, collection_timestamp, and SHA-256_hash computed at ingest for every artifact collected during the audit period", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AU-02-E2", "description": "Validation gate rejection log documenting all artifacts that failed validation checks, the specific failure reason (missing hash, staleness, format error, incomplete metadata), and their disposition", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AU-02-E3", "description": "Manual curation workflow records for artifacts that bypassed automated validation, including curator identity, review method, artifact authenticity basis, and sign-off timestamp", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "AU-02-E4", "description": "Monthly reconciliation reports comparing the artifact inventory against per-framework requirements, identifying collection gaps by artifact type and their age in days", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AU-02-E5", "description": "SHA-256 hash integrity verification report for the audit period confirming no mismatches between ingestion records and current artifact content in the repository", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://model/controls/CR-04", "id": "CR-04", "domain": "model", "name": "AI Incident Response Management", "validation_objective": "The organization must have a documented, version-controlled AI Incident Response Plan (AIRP) with AI-specific containment playbooks covering model rollback, output-filter enforcement, traffic shaping, and full model shutdown \u2014 tested via at least four quarterly tabletop exercises per year using MITRE ATLAS adversarial scenarios \u2014 and P1/P2 post-incident review records produced within 5 days of event resolution for all qualifying events in the trailing 12 months.", "blocking_effect": "blocks-deployment", "evidence_required": [ "AI Incident Response Plan document (version-controlled, CISO or AI-risk-owner signed, with review date within 12 months)", "Containment playbook index listing separate runbooks for model_rollback, output_filter_enforcement, traffic_shaping, and model_shutdown_with_fallback", "Last 4 quarterly tabletop exercise reports with MITRE ATLAS scenario identifier, participant roster, outcomes, and reviewer sign-off", "P1 and P2 post-incident review records for all qualifying events in the trailing 12 months, each showing post_incident_report_date within 5 days of incident_resolved_date", "EU Art. 73 notification trigger mapping document showing which P1 severity criteria trigger the Art. 73 serious-incident notification obligation (15d general / 10d death / 2d widespread or critical infrastructure)" ], "evidence": [ { "id": "CR-04-E1", "description": "AI Incident Response Plan document (version-controlled, CISO or AI-risk-owner signed, with review date within 12 months)", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-04-E2", "description": "Containment playbook index listing separate runbooks for model_rollback, output_filter_enforcement, traffic_shaping, and model_shutdown_with_fallback", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-04-E3", "description": "Last 4 quarterly tabletop exercise reports with MITRE ATLAS scenario identifier, participant roster, outcomes, and reviewer sign-off", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CR-04-E4", "description": "P1 and P2 post-incident review records for all qualifying events in the trailing 12 months, each showing post_incident_report_date within 5 days of incident_resolved_date", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-04-E5", "description": "EU Art. 73 notification trigger mapping document showing which P1 severity criteria trigger the Art. 73 serious-incident notification obligation (15d general / 10d death / 2d widespread or critical infrastructure)", "evidence_type": "incident-record", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 Clause 10.2 (Nonconformity and corrective action) requires responding to nonconformities and correcting root causes. CR-04\u2019s incident response plan, containment playbooks, and post-incident reviews implement that cycle for AI incidents." } ] }, { "requirement_id": "ISO42001-8.4", "section": "\u00a78.4", "title": "Controls for AI systems", "text": "The organization shall implement controls to address the risks identified for AI systems in scope, including controls from Annex A as applicable.", "verdict": "supported", "coverage": "direct", "notes": "The Apeiris 12-domain control framework (252 controls total) constitutes the primary technical and operational control set for AI systems. This mapping covers a representative sample; virtually all Apeiris controls contribute to \u00a78.4 compliance.", "control_count": 5, "proof_chain": [ { "control": "apeiris://model/controls/EV-02", "id": "EV-02", "domain": "model", "name": "Fitness, Safety, Reliability and Policy-Conformance Evaluation", "validation_objective": "Before deployment, every model has been evaluated against pre-specified, dimension-level pass/fail thresholds \u2014 fitness, safety, reliability, and policy-conformance \u2014 with results documented against the model artifact hash and evaluation suite version. No threshold is modified after evaluation begins, and any threshold trade-off decision is documented as a named risk-acceptance record before the deployment manifest is signed.", "blocking_effect": "blocks-deployment", "evidence_required": [ "pre_specified_evaluation_protocol with model_artifact_hash, evaluation_suite_version, and per-dimension thresholds (fitness accuracy target, safety refusal rate, reliability error budget, policy-conformance violation rate), signed by the evaluation lead before testing begins \u2014 not after results are known", "dimension_level_evaluation_results showing per-dimension metric values, pass/fail verdict against pre-specified threshold, and model_artifact_hash confirming results correspond to the evaluated version", "evaluation_suite_provenance_record confirming that evaluation datasets are disjoint from training data, with contamination-check reference to TG-05 attestation", "risk_acceptance_record for any dimension where the pass threshold was not met but deployment was authorized, documenting named risk-accepter, specific capability gap, deployment risk consequence, and remediation deadline" ], "evidence": [ { "id": "EV-02-E1", "description": "pre_specified_evaluation_protocol with model_artifact_hash, evaluation_suite_version, and per-dimension thresholds (fitness accuracy target, safety refusal rate, reliability error budget, policy-conformance violation rate), signed by the evaluation lead before testing begins \u2014 not after results are known", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-02-E2", "description": "dimension_level_evaluation_results showing per-dimension metric values, pass/fail verdict against pre-specified threshold, and model_artifact_hash confirming results correspond to the evaluated version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-02-E3", "description": "evaluation_suite_provenance_record confirming that evaluation datasets are disjoint from training data, with contamination-check reference to TG-05 attestation", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-02-E4", "description": "risk_acceptance_record for any dimension where the pass threshold was not met but deployment was authorized, documenting named risk-accepter, specific capability gap, deployment risk consequence, and remediation deadline", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 A.6.2.4 (AI system verification and validation) requires defined verification and validation measures. EV-02\u2019s structured fitness, safety, reliability, and policy-conformance dimensions define those measures for models." }, { "control": "apeiris://agentic/controls/AB-02", "id": "AB-02", "domain": "agentic", "name": "Tool-Call Authorization Policy", "validation_objective": "Prove that every tool available to an agent has an explicit authorization policy specifying permitted caller roles, parameter value constraints, and human-approval requirements, and that the policy is enforced at the platform invocation layer rather than relying on agent model reasoning or system prompt instructions.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "Tool authorization policy registry listing every tool in the agent's scope with permitted caller roles, parameter constraints, and human-approval flags", "Platform enforcement log showing policy evaluations for tool calls during the test period, including both allow and deny outcomes with tool identifiers", "CI/CD test results demonstrating parameter constraint rejection for out-of-bounds values across all high-impact tools (code execution, file write, external API)", "Human-approval workflow records for any tools flagged as requiring human gate, showing approval or denial events with approver identity" ], "evidence": [ { "id": "AB-02-E1", "description": "Tool authorization policy registry listing every tool in the agent's scope with permitted caller roles, parameter constraints, and human-approval flags", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AB-02-E2", "description": "Platform enforcement log showing policy evaluations for tool calls during the test period, including both allow and deny outcomes with tool identifiers", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AB-02-E3", "description": "CI/CD test results demonstrating parameter constraint rejection for out-of-bounds values across all high-impact tools (code execution, file write, external API)", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "AB-02-E4", "description": "Human-approval workflow records for any tools flagged as requiring human gate, showing approval or denial events with approver identity", "evidence_type": "human-review-record", "verification": "human" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://security/controls/GV-04", "id": "GV-04", "domain": "security", "name": "Enforce policy as code at run time, in the request path", "validation_objective": "A deterministic policy engine must be positioned in the request path for every agent action, evaluating each proposed action against current policy code and returning an allow/deny decision before execution; the engine must fail closed on evaluation error or uncertainty, and no agent action category may bypass policy evaluation.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "policy_decision_log with action_id, policy_version, decision (allow/deny), evaluation_latency_ms, and matched_policy_rule_id for each evaluated agent action", "fail_closed_test_record showing that disabling or erroring a policy detector caused the engine to deny the action rather than default to allow", "policy_engine_deployment_record confirming the engine is positioned in the request path as a pre-execution gate, not as a post-hoc advisory check", "policy_version_change_log with effective_from timestamp, changed_rules, and approving_authority for each policy update deployed to the request path" ], "evidence": [ { "id": "GV-04-E1", "description": "policy_decision_log with action_id, policy_version, decision (allow/deny), evaluation_latency_ms, and matched_policy_rule_id for each evaluated agent action", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-04-E2", "description": "fail_closed_test_record showing that disabling or erroring a policy detector caused the engine to deny the action rather than default to allow", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-04-E3", "description": "policy_engine_deployment_record confirming the engine is positioned in the request path as a pre-execution gate, not as a post-hoc advisory check", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-04-E4", "description": "policy_version_change_log with effective_from timestamp, changed_rules, and approving_authority for each policy update deployed to the request path", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "adjacent", "basis": "anchored", "relation": "equivalent_to", "rationale": null }, { "control": "apeiris://model/controls/BH-01", "id": "BH-01", "domain": "model", "name": "Output Anomaly Detection", "validation_objective": "The production inference endpoint must be continuously sampled and output distributions must be statistically compared against a versioned, SHA-256-signed baseline artifact using PSI and Shewhart/EWMA control chart methods, such that any distribution shift exceeding PSI 0.2 fires a tiered alert within one monitoring window of the shift occurring and all anomaly events are stored in the evidence registry with BH-01 control linkage.", "blocking_effect": "advisory", "evidence_required": [ "versioned, SHA-256-signed baseline distribution artifact stored in the model registry with per-metric statistics (mean, std_dev, p5/p50/p95/p99) computed from the 30-day post-deployment stable window", "SPC alert log for trailing 90 days with fields: alert_id, trigger_metric, psi_value, alert_severity, triggered_at, acknowledged_at, and resolution_outcome", "PII masking audit record confirming no direct identifier fields (email, SSN, full name) appear in the sampled output storage for the trailing 30 days", "quarterly threshold review sign-off from model owner confirming PSI alert (0.2) and critical (0.25) thresholds remain appropriate for the current deployment context" ], "evidence": [ { "id": "BH-01-E1", "description": "versioned, SHA-256-signed baseline distribution artifact stored in the model registry with per-metric statistics (mean, std_dev, p5/p50/p95/p99) computed from the 30-day post-deployment stable window", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-01-E2", "description": "SPC alert log for trailing 90 days with fields: alert_id, trigger_metric, psi_value, alert_severity, triggered_at, acknowledged_at, and resolution_outcome", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "BH-01-E3", "description": "PII masking audit record confirming no direct identifier fields (email, SSN, full name) appear in the sampled output storage for the trailing 30 days", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-01-E4", "description": "quarterly threshold review sign-off from model owner confirming PSI alert (0.2) and critical (0.25) thresholds remain appropriate for the current deployment context", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 A.6.2.6 (AI system operation and monitoring) requires monitoring the AI system in operation. BH-01\u2019s statistical process control over output distributions implements that monitoring with signed baselines and tiered alerts." }, { "control": "apeiris://agentic/controls/AT-01", "id": "AT-01", "domain": "agentic", "name": "Tool and Plugin Registry", "validation_objective": "Proves that every tool invoked by any agent in the deployment has an authoritative registry entry with populated capability description, owner identity, risk classification, version, and approval status, and that the agent runtime blocks invocations of unregistered or unapproved tools before execution reaches any tool executor.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "Full tool registry export with all entries showing tool ID, capability description, owner identity, risk classification (low/medium/high/critical), semantic version, approval status, and approval date", "Execution log extract from the past 90 days cross-referenced against the registry, confirming all invoked tool IDs have a corresponding registry entry with approved status", "Runtime enforcement log showing at least one blocked invocation attempt on an unregistered or unapproved tool ID, or an adversarial test artifact demonstrating enforcement is active", "Dual-approval sign-off records for all tools classified as high or critical risk in the registry", "Most recent quarterly registry reconciliation report identifying any shadow tools, orphaned registrations, or version drift, with documented remediation records" ], "evidence": [ { "id": "AT-01-E1", "description": "Full tool registry export with all entries showing tool ID, capability description, owner identity, risk classification (low/medium/high/critical), semantic version, approval status, and approval date", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "AT-01-E2", "description": "Execution log extract from the past 90 days cross-referenced against the registry, confirming all invoked tool IDs have a corresponding registry entry with approved status", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AT-01-E3", "description": "Runtime enforcement log showing at least one blocked invocation attempt on an unregistered or unapproved tool ID, or an adversarial test artifact demonstrating enforcement is active", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AT-01-E4", "description": "Dual-approval sign-off records for all tools classified as high or critical risk in the registry", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AT-01-E5", "description": "Most recent quarterly registry reconciliation report identifying any shadow tools, orphaned registrations, or version drift, with documented remediation records", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 \u00a77.1 requires the organization to determine and provide the resources needed for the AI management system. A governed tool registry determines and documents exactly which tool resources agent systems depend on, with ownership, risk classification, and approval state." } ] }, { "requirement_id": "ISO42001-9.1", "section": "\u00a79.1", "title": "Monitoring, measurement, analysis and evaluation", "text": "The organization shall determine what needs to be monitored and measured for the AI system and AIMS, the methods for monitoring, measurement, analysis, and evaluation, when monitoring and measuring shall be performed, and when results shall be analyzed and evaluated.", "verdict": "supported", "coverage": "direct", "notes": "Output anomaly detection, continuous production monitoring and risk aggregation, continuous compliance monitoring, behavioral telemetry collection baseline, and AI-specific compliance KPIs together implement the full monitoring, measurement, and evaluation clause.", "control_count": 5, "proof_chain": [ { "control": "apeiris://model/controls/BH-01", "id": "BH-01", "domain": "model", "name": "Output Anomaly Detection", "validation_objective": "The production inference endpoint must be continuously sampled and output distributions must be statistically compared against a versioned, SHA-256-signed baseline artifact using PSI and Shewhart/EWMA control chart methods, such that any distribution shift exceeding PSI 0.2 fires a tiered alert within one monitoring window of the shift occurring and all anomaly events are stored in the evidence registry with BH-01 control linkage.", "blocking_effect": "advisory", "evidence_required": [ "versioned, SHA-256-signed baseline distribution artifact stored in the model registry with per-metric statistics (mean, std_dev, p5/p50/p95/p99) computed from the 30-day post-deployment stable window", "SPC alert log for trailing 90 days with fields: alert_id, trigger_metric, psi_value, alert_severity, triggered_at, acknowledged_at, and resolution_outcome", "PII masking audit record confirming no direct identifier fields (email, SSN, full name) appear in the sampled output storage for the trailing 30 days", "quarterly threshold review sign-off from model owner confirming PSI alert (0.2) and critical (0.25) thresholds remain appropriate for the current deployment context" ], "evidence": [ { "id": "BH-01-E1", "description": "versioned, SHA-256-signed baseline distribution artifact stored in the model registry with per-metric statistics (mean, std_dev, p5/p50/p95/p99) computed from the 30-day post-deployment stable window", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-01-E2", "description": "SPC alert log for trailing 90 days with fields: alert_id, trigger_metric, psi_value, alert_severity, triggered_at, acknowledged_at, and resolution_outcome", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "BH-01-E3", "description": "PII masking audit record confirming no direct identifier fields (email, SSN, full name) appear in the sampled output storage for the trailing 30 days", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-01-E4", "description": "quarterly threshold review sign-off from model owner confirming PSI alert (0.2) and critical (0.25) thresholds remain appropriate for the current deployment context", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 A.6.2.6 (AI system operation and monitoring) requires monitoring the AI system in operation. BH-01\u2019s statistical process control over output distributions implements that monitoring with signed baselines and tiered alerts." }, { "control": "apeiris://model/controls/CR-01", "id": "CR-01", "domain": "model", "name": "Continuous Production Monitoring and Risk Aggregation", "validation_objective": "All runtime monitoring signals \u2014 performance, drift, fairness, safety incidents, and deployment event flags \u2014 must be continuously aggregated into a unified risk dashboard with pre-configured automated alerting thresholds; any degradation in a monitored dimension must be detected and an alert dispatched within one operational window.", "blocking_effect": "advisory", "evidence_required": [ "risk_dashboard_configuration_record showing all registered signal feeds (performance, drift, fairness, safety, incident), their alert thresholds, assigned monitoring window duration, and escalation recipients", "alert_audit_log covering at least 30 days showing triggered alerts with signal_type, threshold_crossed, alert_timestamp, and escalation_recipient for each alert", "monitoring_coverage_audit confirming every deployed model version has an associated monitoring configuration with no version gaps", "risk_aggregation_methodology_document defining how individual dimension alerts are combined into composite risk scores and dashboard status indicators", "post-market_monitoring_report satisfying EU AI Act Art. 72 covering the monitoring period, key findings, and corrective actions taken or planned" ], "evidence": [ { "id": "CR-01-E1", "description": "risk_dashboard_configuration_record showing all registered signal feeds (performance, drift, fairness, safety, incident), their alert thresholds, assigned monitoring window duration, and escalation recipients", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-01-E2", "description": "alert_audit_log covering at least 30 days showing triggered alerts with signal_type, threshold_crossed, alert_timestamp, and escalation_recipient for each alert", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E3", "description": "monitoring_coverage_audit confirming every deployed model version has an associated monitoring configuration with no version gaps", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E4", "description": "risk_aggregation_methodology_document defining how individual dimension alerts are combined into composite risk scores and dashboard status indicators", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E5", "description": "post-market_monitoring_report satisfying EU AI Act Art. 72 covering the monitoring period, key findings, and corrective actions taken or planned", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 A.6.2.6 (AI system operation and monitoring) requires monitoring the AI system in operation. CR-01 aggregates the operational monitoring signals \u2014 performance, drift, fairness, safety, cost \u2014 into one governed risk view." }, { "control": "apeiris://compliance/controls/CI-02", "id": "CI-02", "domain": "compliance", "name": "Continuous Compliance Monitoring", "validation_objective": "The enterprise must operate automated monitoring pipelines covering 100% of AI obligations designated as continuously monitored in the compliance program, with alert latency not exceeding the defined maximum detection window, and all alert events retained with a machine-readable audit trail. No obligation designated as continuously monitored may remain in an undetected violation state for longer than the defined maximum detection window.", "blocking_effect": "advisory", "evidence_required": [ "monitoring_pipeline_inventory listing each automated compliance monitor with obligation_id, monitor_id, check_frequency, alert_channel, and last_successful_run timestamp", "alert_log showing all compliance alert events with obligation_id, detected_at, severity, alert_channel, and assigned_responder for the review period", "false_positive_rate_report quantifying alert noise by obligation and monitor, with tuning actions taken for monitors exceeding the defined false positive threshold", "obligation_coverage_matrix confirming which obligations are covered by automated monitoring vs. periodic testing, with justification for any obligation placed in periodic-only mode", "monitoring_health_report confirming pipeline availability and last successful execution timestamp for each monitor" ], "evidence": [ { "id": "CI-02-E1", "description": "monitoring_pipeline_inventory listing each automated compliance monitor with obligation_id, monitor_id, check_frequency, alert_channel, and last_successful_run timestamp", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CI-02-E2", "description": "alert_log showing all compliance alert events with obligation_id, detected_at, severity, alert_channel, and assigned_responder for the review period", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CI-02-E3", "description": "false_positive_rate_report quantifying alert noise by obligation and monitor, with tuning actions taken for monitors exceeding the defined false positive threshold", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CI-02-E4", "description": "obligation_coverage_matrix confirming which obligations are covered by automated monitoring vs. periodic testing, with justification for any obligation placed in periodic-only mode", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CI-02-E5", "description": "monitoring_health_report confirming pipeline availability and last successful execution timestamp for each monitor", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://agentic/controls/AM-01", "id": "AM-01", "domain": "agentic", "name": "Behavioral Telemetry Collection Baseline", "validation_objective": "Proves that every registered production agent emits a schema-validated, minimum signal set \u2014 covering action type, tool invocations, token consumption, session boundaries, and decision rationale traces \u2014 to an append-only telemetry store, with 100% coverage of registered agents demonstrable within the prior 24-hour window.", "blocking_effect": "advisory", "evidence_required": [ "Telemetry schema version registry showing current schema version and change history with change-management approval records", "Agent registry cross-referenced with telemetry coverage report identifying any registered agents with no telemetry events in the prior 24 hours", "Schema validation rejection rate report for the prior 7 days, with alert records for any rejection rate above 0.1%", "Five sample agent session traces each demonstrating a continuous telemetry record from session_start to session_end with all required baseline fields", "Telemetry pipeline SLO report covering ingestion latency, throughput capacity, and event loss rate" ], "evidence": [ { "id": "AM-01-E1", "description": "Telemetry schema version registry showing current schema version and change history with change-management approval records", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AM-01-E2", "description": "Agent registry cross-referenced with telemetry coverage report identifying any registered agents with no telemetry events in the prior 24 hours", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AM-01-E3", "description": "Schema validation rejection rate report for the prior 7 days, with alert records for any rejection rate above 0.1%", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "AM-01-E4", "description": "Five sample agent session traces each demonstrating a continuous telemetry record from session_start to session_end with all required baseline fields", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AM-01-E5", "description": "Telemetry pipeline SLO report covering ingestion latency, throughput capacity, and event loss rate", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 \u00a79.1 requires organizations to determine what needs to be monitored and measured regarding AI system performance. A telemetry baseline directly instantiates this requirement by specifying the minimum observable signals. Absence of a defined baseline means \u00a79.1 cannot be meaningfully demonstrated." }, { "control": "apeiris://compliance/controls/CI-03", "id": "CI-03", "domain": "compliance", "name": "AI-Specific Compliance KPIs", "validation_objective": "The compliance program must produce a defined set of AI-specific KPIs covering all five baseline dimensions (obligation coverage, evidence freshness, audit finding rate, remediation velocity, training completion) on a defined reporting cadence, with each KPI having a documented target threshold, a current measured value, and a trend direction indicator. No KPI may report a null measured_value at the defined reporting cadence without a documented exception.", "blocking_effect": "advisory", "evidence_required": [ "kpi_definition_register listing each KPI with kpi_id, name, definition, measurement_method, data_source, target_threshold, and reporting_frequency", "kpi_measurement_report for the current period containing measured_value, prior_period_value, trend_direction, and within_threshold flag for each defined KPI", "kpi_trend_history covering at least four consecutive reporting periods per KPI to enable trend analysis", "management_reporting_record confirming KPI results were presented to the compliance governance committee with attendance record and date", "remediation_action_record for each KPI where measured_value is outside the target_threshold, with root_cause, corrective_action, and target_return_to_threshold_date" ], "evidence": [ { "id": "CI-03-E1", "description": "kpi_definition_register listing each KPI with kpi_id, name, definition, measurement_method, data_source, target_threshold, and reporting_frequency", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-03-E2", "description": "kpi_measurement_report for the current period containing measured_value, prior_period_value, trend_direction, and within_threshold flag for each defined KPI", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-03-E3", "description": "kpi_trend_history covering at least four consecutive reporting periods per KPI to enable trend analysis", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-03-E4", "description": "management_reporting_record confirming KPI results were presented to the compliance governance committee with attendance record and date", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CI-03-E5", "description": "remediation_action_record for each KPI where measured_value is outside the target_threshold, with root_cause, corrective_action, and target_return_to_threshold_date", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "ISO42001-9.2", "section": "\u00a79.2", "title": "Internal audit", "text": "The organization shall conduct internal audits at planned intervals to provide information on whether the AIMS conforms to the organization's own requirements and to the requirements of this document, and is effectively implemented and maintained.", "verdict": "supported", "coverage": "direct", "notes": "Internal audit of AI compliance controls, audit readiness program, audit trail integrity, evidence collection and validation, and internal audit support package directly implement the internal audit requirement.", "control_count": 5, "proof_chain": [ { "control": "apeiris://compliance/controls/CI-06", "id": "CI-06", "domain": "compliance", "name": "Internal Audit of AI Compliance Controls", "validation_objective": "An internal audit covering the full CI-layer control matrix has been completed within the current annual cycle by auditors with documented AI domain competence who are independent of compliance operations. All findings include root cause analysis and have been routed to the remediation register with management responses provided within 15 business days of draft report issuance.", "blocking_effect": "requires-review", "evidence_required": [ "Annual internal audit plan signed by the Chief Audit Executive, identifying scope, risk-based prioritization, and AI competence documentation for all audit team members", "Auditor independence declarations for each team member confirming no organizational reporting line to the compliance function under review", "Audit fieldwork workpapers documenting control testing methodology, evidence reviewed, and basis for each finding classification", "Formal audit report with findings classified by severity (critical/high/medium/low), root cause analysis, and specific remediation recommendations per finding", "Management response letters providing corrective action commitments, named owners, and due dates for each finding, submitted within 15 business days of draft issuance" ], "evidence": [ { "id": "CI-06-E1", "description": "Annual internal audit plan signed by the Chief Audit Executive, identifying scope, risk-based prioritization, and AI competence documentation for all audit team members", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-06-E2", "description": "Auditor independence declarations for each team member confirming no organizational reporting line to the compliance function under review", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CI-06-E3", "description": "Audit fieldwork workpapers documenting control testing methodology, evidence reviewed, and basis for each finding classification", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CI-06-E4", "description": "Formal audit report with findings classified by severity (critical/high/medium/low), root cause analysis, and specific remediation recommendations per finding", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-06-E5", "description": "Management response letters providing corrective action commitments, named owners, and due dates for each finding, submitted within 15 business days of draft issuance", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://compliance/controls/AU-01", "id": "AU-01", "domain": "compliance", "name": "Audit Readiness Program", "validation_objective": "The organization maintains a continuously current evidence library for each applicable compliance framework with completeness scores at or above 95%, all artifacts refreshed within defined cadence thresholds, and at least four quarterly mock audit exercises completed in the review year with findings closed within 45 days. No framework evidence package was assembled reactively within 30 days of an audit notification.", "blocking_effect": "advisory", "evidence_required": [ "Evidence library completeness score history for each applicable framework, showing scores recorded at least monthly and distributed across the review period rather than spiking near audit notification dates", "Artifact staleness tracking report showing each artifact type's last_refreshed_date and compliance status against the defined maximum staleness threshold", "Quarterly mock audit reports documenting scope, methodology, findings, and participants for each of the four required exercises in the review year", "Mock audit finding remediation records confirming all gaps identified in each exercise were closed within 45 days of report issuance", "Annual audit readiness program charter or review sign-off from the Chief Compliance Officer confirming applicable framework inventory and program scope" ], "evidence": [ { "id": "AU-01-E1", "description": "Evidence library completeness score history for each applicable framework, showing scores recorded at least monthly and distributed across the review period rather than spiking near audit notification dates", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AU-01-E2", "description": "Artifact staleness tracking report showing each artifact type's last_refreshed_date and compliance status against the defined maximum staleness threshold", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AU-01-E3", "description": "Quarterly mock audit reports documenting scope, methodology, findings, and participants for each of the four required exercises in the review year", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AU-01-E4", "description": "Mock audit finding remediation records confirming all gaps identified in each exercise were closed within 45 days of report issuance", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AU-01-E5", "description": "Annual audit readiness program charter or review sign-off from the Chief Compliance Officer confirming applicable framework inventory and program scope", "evidence_type": "human-review-record", "verification": "human" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://compliance/controls/AU-04", "id": "AU-04", "domain": "compliance", "name": "Audit Trail Integrity", "validation_objective": "The audit log system must maintain a cryptographically chained, append-only record of all compliance program activities \u2014 including policy attestations, control assessments, evidence submissions, and configuration changes \u2014 such that any attempt to modify, delete, or insert log records is detectable within 24 hours of occurrence. Automated daily hash chain verification must confirm log integrity continuously and alert the compliance officer within 1 hour of any detected break.", "blocking_effect": "advisory", "evidence_required": [ "cryptographic_hash_chain_report listing hash values for each log batch and chain linkage between successive batches, covering the full audit period with no unexplained gaps", "WORM_storage_replication_log confirming each log batch was replicated to immutable secondary store within 60 seconds, with source generation timestamp and secondary write timestamp for each batch", "daily_integrity_verification_report showing automated hash chain verification results, detected breaks, and alert dispatch timestamps for each verification run in the last 30 days", "log_custody_register documenting all personnel with access to log infrastructure, last quarterly access review date, and access removal records for personnel no longer requiring access", "log_gap_analysis_report confirming no unexplained gaps in log sequence numbers or timestamps for the audit period" ], "evidence": [ { "id": "AU-04-E1", "description": "cryptographic_hash_chain_report listing hash values for each log batch and chain linkage between successive batches, covering the full audit period with no unexplained gaps", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AU-04-E2", "description": "WORM_storage_replication_log confirming each log batch was replicated to immutable secondary store within 60 seconds, with source generation timestamp and secondary write timestamp for each batch", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AU-04-E3", "description": "daily_integrity_verification_report showing automated hash chain verification results, detected breaks, and alert dispatch timestamps for each verification run in the last 30 days", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "AU-04-E4", "description": "log_custody_register documenting all personnel with access to log infrastructure, last quarterly access review date, and access removal records for personnel no longer requiring access", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AU-04-E5", "description": "log_gap_analysis_report confirming no unexplained gaps in log sequence numbers or timestamps for the audit period", "evidence_type": "audit-log", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://compliance/controls/AU-02", "id": "AU-02", "domain": "compliance", "name": "Evidence Collection, Curation, and Validation", "validation_objective": "Every compliance evidence artifact in the active evidence library has a SHA-256 hash computed at the moment of collection, a documented source_system and collector_identity, a collection_timestamp within the required freshness window for its artifact type, and has passed all validation gate checks prior to promotion. No artifact with missing or failed provenance metadata exists in the active library.", "blocking_effect": "advisory", "evidence_required": [ "Evidence repository ingestion log showing source_system, collector_identity, collection_timestamp, and SHA-256_hash computed at ingest for every artifact collected during the audit period", "Validation gate rejection log documenting all artifacts that failed validation checks, the specific failure reason (missing hash, staleness, format error, incomplete metadata), and their disposition", "Manual curation workflow records for artifacts that bypassed automated validation, including curator identity, review method, artifact authenticity basis, and sign-off timestamp", "Monthly reconciliation reports comparing the artifact inventory against per-framework requirements, identifying collection gaps by artifact type and their age in days", "SHA-256 hash integrity verification report for the audit period confirming no mismatches between ingestion records and current artifact content in the repository" ], "evidence": [ { "id": "AU-02-E1", "description": "Evidence repository ingestion log showing source_system, collector_identity, collection_timestamp, and SHA-256_hash computed at ingest for every artifact collected during the audit period", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AU-02-E2", "description": "Validation gate rejection log documenting all artifacts that failed validation checks, the specific failure reason (missing hash, staleness, format error, incomplete metadata), and their disposition", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AU-02-E3", "description": "Manual curation workflow records for artifacts that bypassed automated validation, including curator identity, review method, artifact authenticity basis, and sign-off timestamp", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "AU-02-E4", "description": "Monthly reconciliation reports comparing the artifact inventory against per-framework requirements, identifying collection gaps by artifact type and their age in days", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AU-02-E5", "description": "SHA-256 hash integrity verification report for the audit period confirming no mismatches between ingestion records and current artifact content in the repository", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://authority/controls/PE-03", "id": "PE-03", "domain": "authority", "name": "Internal Audit Support Package", "validation_objective": "For each internal audit cycle, a pre-indexed, control-mapped evidence package must be available covering all in-scope authority controls, with each evidence artifact tagged to the specific control it satisfies and to the audit test procedure it supports. Auditors must be able to initiate testing without requesting additional evidence collection.", "blocking_effect": "requires-review", "evidence_required": [ "audit_evidence_package_manifest listing each in-scope control with control_id, mapped_audit_test_id, artifact_type, artifact_id, and collection_timestamp for every evidence item", "control_design_documentation per in-scope control including policy reference, control objective, implementation description, and last-review date", "operating_effectiveness_sample_set containing the auditor-defined population, the selected sample, and the corresponding evidence artifacts with provenance metadata", "prior_cycle_finding_remediation_record showing each finding from the previous audit cycle with remediation action, implementation date, and retesting result", "audit_package_completeness_certification signed by the control owner confirming that all evidence is current, accurately represents the control state, and covers the defined audit period" ], "evidence": [ { "id": "PE-03-E1", "description": "audit_evidence_package_manifest listing each in-scope control with control_id, mapped_audit_test_id, artifact_type, artifact_id, and collection_timestamp for every evidence item", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PE-03-E2", "description": "control_design_documentation per in-scope control including policy reference, control objective, implementation description, and last-review date", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PE-03-E3", "description": "operating_effectiveness_sample_set containing the auditor-defined population, the selected sample, and the corresponding evidence artifacts with provenance metadata", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "PE-03-E4", "description": "prior_cycle_finding_remediation_record showing each finding from the previous audit cycle with remediation action, implementation date, and retesting result", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PE-03-E5", "description": "audit_package_completeness_certification signed by the control owner confirming that all evidence is current, accurately represents the control state, and covers the defined audit period", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "Control-mapped audit support packages directly enable the \u00a79.2 internal audit process." } ] }, { "requirement_id": "ISO42001-9.3", "section": "\u00a79.3", "title": "Management review", "text": "Top management shall review the organization's AIMS at planned intervals to ensure its continuing suitability, adequacy, and effectiveness.", "verdict": "partial", "coverage": "partial", "notes": "Senior accountability, board reporting, compliance program metrics, and policy governance program assessment support evidence for management review. Formal management review meeting facilitation, agenda, and decision recording are organizational process requirements beyond Apeiris control scope.", "control_count": 4, "proof_chain": [ { "control": "apeiris://compliance/controls/CG-03", "id": "CG-03", "domain": "compliance", "name": "Senior and Board-Level Accountability for AI Compliance", "validation_objective": "The board of directors has a formal, documented mandate for AI compliance oversight via committee resolution, an executive owner is designated in their role charter with AI compliance accountability, and at least one quarterly board compliance report has been presented within the current 90-day window with meeting minutes documenting AI compliance as a substantive agenda item and material risks discussed.", "blocking_effect": "requires-review", "evidence_required": [ "board_resolution_document with committee_name, effective_date, scope (AI compliance oversight mandate), and authorizing_signatories confirming formal assignment of AI compliance oversight", "executive_role_charter or position_description for CCO or designated executive containing explicit AI compliance accountability language and board reporting obligation, with effective_date and incumbent name", "compliance_committee_meeting_minutes from each of the prior four quarters documenting AI compliance agenda item, attendance by designated executive, and material risks discussed or acknowledged", "ai_compliance_dashboard report presented to board, timestamped within the prior 90 days, with KPI section, regulatory obligation status, and material risk disclosures" ], "evidence": [ { "id": "CG-03-E1", "description": "board_resolution_document with committee_name, effective_date, scope (AI compliance oversight mandate), and authorizing_signatories confirming formal assignment of AI compliance oversight", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-03-E2", "description": "executive_role_charter or position_description for CCO or designated executive containing explicit AI compliance accountability language and board reporting obligation, with effective_date and incumbent name", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-03-E3", "description": "compliance_committee_meeting_minutes from each of the prior four quarters documenting AI compliance agenda item, attendance by designated executive, and material risks discussed or acknowledged", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-03-E4", "description": "ai_compliance_dashboard report presented to board, timestamped within the prior 90 days, with KPI section, regulatory obligation status, and material risk disclosures", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://authority/controls/PE-06", "id": "PE-06", "domain": "authority", "name": "Board and Senior Management Policy Reporting", "validation_objective": "Quarterly AI policy governance reports must be produced on schedule, reviewed, and co-signed by both the Chief Risk Officer and General Counsel, with every reported metric traceable to a supporting evidence item in the PE-04 integrated package. All risk items exceeding the board-approved materiality thresholds must appear in the report with prioritized escalation recommendations and documented board response within 30 days.", "blocking_effect": "requires-review", "evidence_required": [ "board_ai_policy_governance_report with executive summary, risk-adjusted metrics, open gap inventory, and escalation recommendations, dated within the quarterly reporting cycle and referencing the PE-04 integrated package version used", "report_sign_off_log showing CRO identity, General Counsel identity, individual sign-off timestamps, and SHA-256 hash of the signed report version to detect post-signature modification", "materiality_threshold_schedule approved by the CRO and version-controlled, defining numeric thresholds for AI policy risk metrics that trigger mandatory board-level reporting and escalation", "report_distribution_log recording recipient role, distribution timestamp, and acknowledgment status for each quarterly report to confirm the board actually received the report" ], "evidence": [ { "id": "PE-06-E1", "description": "board_ai_policy_governance_report with executive summary, risk-adjusted metrics, open gap inventory, and escalation recommendations, dated within the quarterly reporting cycle and referencing the PE-04 integrated package version used", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PE-06-E2", "description": "report_sign_off_log showing CRO identity, General Counsel identity, individual sign-off timestamps, and SHA-256 hash of the signed report version to detect post-signature modification", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PE-06-E3", "description": "materiality_threshold_schedule approved by the CRO and version-controlled, defining numeric thresholds for AI policy risk metrics that trigger mandatory board-level reporting and escalation", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PE-06-E4", "description": "report_distribution_log recording recipient role, distribution timestamp, and acknowledgment status for each quarterly report to confirm the board actually received the report", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://compliance/controls/CG-07", "id": "CG-07", "domain": "compliance", "name": "Compliance Program Metrics and KPIs", "validation_objective": "A two-tier compliance metrics framework exists with at least five board-level KPIs (including at least one outcome indicator per applicable regulatory framework) and at least fifteen operational metrics covering obligation coverage, remediation velocity, and control effectiveness, with automated data collection from source systems and four consecutive periods of historical trend data available at reporting time.", "blocking_effect": "advisory", "evidence_required": [ "kpi_framework_document defining each metric with metric_name, metric_type (leading/lagging/outcome/activity), calculation_method, data_source, collection_frequency, reporting_tier (board/operational), and metric_owner \u2014 with annual_review_date within the last 12 months", "board_kpi_dashboard reports for at least four consecutive quarters showing trend data, with compliance_committee_meeting_minutes confirming each was presented and received by the Compliance Committee", "operational_metrics_report for the current reporting period showing current_value for all defined operational metrics with data_source attribution and freshness_timestamp <= 48 hours at time of report generation", "metric_data_pipeline_health_log confirming automated collection pipeline is active for each metric, with last_successful_collection_timestamp and error_rate for the preceding 30 days" ], "evidence": [ { "id": "CG-07-E1", "description": "kpi_framework_document defining each metric with metric_name, metric_type (leading/lagging/outcome/activity), calculation_method, data_source, collection_frequency, reporting_tier (board/operational), and metric_owner \u2014 with annual_review_date within the last 12 months", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-07-E2", "description": "board_kpi_dashboard reports for at least four consecutive quarters showing trend data, with compliance_committee_meeting_minutes confirming each was presented and received by the Compliance Committee", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-07-E3", "description": "operational_metrics_report for the current reporting period showing current_value for all defined operational metrics with data_source attribution and freshness_timestamp <= 48 hours at time of report generation", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-07-E4", "description": "metric_data_pipeline_health_log confirming automated collection pipeline is active for each metric, with last_successful_collection_timestamp and error_rate for the preceding 30 days", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://authority/controls/PE-07", "id": "PE-07", "domain": "authority", "name": "Policy Governance Program Assessment", "validation_objective": "An annual structured maturity assessment of the enterprise AI policy governance program must be completed within the policy-defined window, using the CRO-approved scoring rubric, with every scored dimension backed by at least one retrievable evidence citation from the PE-01 archive. The resulting improvement roadmap must assign a named owner and target completion date to each recommendation, with all items tracked in the GRC platform through the subsequent assessment cycle.", "blocking_effect": "advisory", "evidence_required": [ "policy_governance_maturity_assessment_report with dimension scores, evidence citations referencing specific PE-01 archive items by document ID, and improvement recommendations with priority ranking and business justification", "maturity_model_scoring_rubric version-controlled and CRO-approved, with explicit evidence-type requirements per dimension specifying which artifact types constitute acceptable evidence", "grc_platform_roadmap_tracking_export showing all prior-cycle improvement recommendations with current status, assigned owner, and target completion date as of the assessment date", "cro_assessment_sign_off_record with CRO identity, sign-off timestamp, and SHA-256 hash of the signed assessment report version" ], "evidence": [ { "id": "PE-07-E1", "description": "policy_governance_maturity_assessment_report with dimension scores, evidence citations referencing specific PE-01 archive items by document ID, and improvement recommendations with priority ranking and business justification", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PE-07-E2", "description": "maturity_model_scoring_rubric version-controlled and CRO-approved, with explicit evidence-type requirements per dimension specifying which artifact types constitute acceptable evidence", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PE-07-E3", "description": "grc_platform_roadmap_tracking_export showing all prior-cycle improvement recommendations with current status, assigned owner, and target completion date as of the assessment date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PE-07-E4", "description": "cro_assessment_sign_off_record with CRO identity, sign-off timestamp, and SHA-256 hash of the signed assessment report version", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "Structured program maturity assessment partially aligns with \u00a79.2 internal audit of the AIMS." } ] }, { "requirement_id": "ISO42001-10.1", "section": "\u00a710.1", "title": "Nonconformity and corrective action", "text": "When a nonconformity occurs, the organization shall react to the nonconformity, evaluate the need for action to eliminate the causes of the nonconformity, implement any action needed, and review the effectiveness of any corrective action taken.", "verdict": "partial", "coverage": "partial", "notes": "Audit finding remediation program, remediation tracking, compliance incident response, AI incident response management, and agent incident response program address corrective action. Root cause analysis methodology and formal nonconformity recording are organizational quality management processes.", "control_count": 5, "proof_chain": [ { "control": "apeiris://compliance/controls/AU-06", "id": "AU-06", "domain": "compliance", "name": "Audit Finding Remediation Program", "validation_objective": "The organization must maintain a centralized finding register with zero overdue critical findings beyond defined SLAs, at least 95% of closed findings supported by independently verified remediation evidence, and a repeat finding rate in the same control area below 10% over any rolling 24-month window, demonstrating that root-cause analysis is eliminating systemic deficiencies rather than merely closing proximate findings.", "blocking_effect": "requires-review", "evidence_required": [ "finding_register export showing all findings from internal audit, external audit, regulatory examinations, and self-assessments with severity classification, root-cause category, corrective action plan, assigned owner, target close date, verification method, and current status", "independently_verified_closure_records for all findings marked closed in the last 12 months, including the type of verification evidence and the identity of the independent reviewer who confirmed remediation before formal closure", "root_cause_analysis_reports for all critical and high findings and any findings recurring in the same control area within a 24-month window, completed before the corrective action plan was approved", "monthly_aging_reports for the last 6 months showing open finding counts by severity, owner, and source with evidence of GRC committee distribution and documented escalation for overdue items", "corrective_action_change_tickets for all IT-related findings, confirming technical remediation was processed through the change management system with change records attached to the finding" ], "evidence": [ { "id": "AU-06-E1", "description": "finding_register export showing all findings from internal audit, external audit, regulatory examinations, and self-assessments with severity classification, root-cause category, corrective action plan, assigned owner, target close date, verification method, and current status", "evidence_type": "third-party-audit-report", "verification": "third-party" }, { "id": "AU-06-E2", "description": "independently_verified_closure_records for all findings marked closed in the last 12 months, including the type of verification evidence and the identity of the independent reviewer who confirmed remediation before formal closure", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AU-06-E3", "description": "root_cause_analysis_reports for all critical and high findings and any findings recurring in the same control area within a 24-month window, completed before the corrective action plan was approved", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AU-06-E4", "description": "monthly_aging_reports for the last 6 months showing open finding counts by severity, owner, and source with evidence of GRC committee distribution and documented escalation for overdue items", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AU-06-E5", "description": "corrective_action_change_tickets for all IT-related findings, confirming technical remediation was processed through the change management system with change records attached to the finding", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://compliance/controls/CI-07", "id": "CI-07", "domain": "compliance", "name": "Remediation Tracking and Closure", "validation_objective": "Every compliance gap identified by control testing (CI-01), monitoring (CI-02), or internal audit (CI-06) has a corresponding remediation ticket with an assigned single owner, target date, documented root cause, remediation plan, and independently verified closure evidence. No critical-severity ticket is open beyond 15 business days without a documented executive escalation record.", "blocking_effect": "requires-review", "evidence_required": [ "Remediation register export listing all open and closed tickets with source_control, severity, assigned_owner, root_cause, remediation_plan, target_date, and actual_closure_date for the full audit period", "Closure verification records for each high and critical ticket documenting the independent verifier identity, verification method (re-test, configuration check, or re-assessment), and verification outcome", "Automated escalation log showing escalation trigger events and management acknowledgment timestamps for all overdue items during the period", "Recurrence analysis report identifying any finding appearing in both the current and prior audit cycle, with root cause explanation for recurrence", "Weekly remediation velocity reports showing open ticket counts by severity and age distribution across the audit period" ], "evidence": [ { "id": "CI-07-E1", "description": "Remediation register export listing all open and closed tickets with source_control, severity, assigned_owner, root_cause, remediation_plan, target_date, and actual_closure_date for the full audit period", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "CI-07-E2", "description": "Closure verification records for each high and critical ticket documenting the independent verifier identity, verification method (re-test, configuration check, or re-assessment), and verification outcome", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "CI-07-E3", "description": "Automated escalation log showing escalation trigger events and management acknowledgment timestamps for all overdue items during the period", "evidence_type": "audit-log", "verification": "automated" }, { "id": "CI-07-E4", "description": "Recurrence analysis report identifying any finding appearing in both the current and prior audit cycle, with root cause explanation for recurrence", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-07-E5", "description": "Weekly remediation velocity reports showing open ticket counts by severity and age distribution across the audit period", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://compliance/controls/CG-06", "id": "CG-06", "domain": "compliance", "name": "Compliance Incident Response", "validation_objective": "A documented Compliance Incident Response Playbook exists covering at least four AI-specific incident scenario types (discriminatory AI output, unauthorized AI data processing, regulatory inquiry, enforcement action), defines severity levels P1-P4 with named role assignments and notification timelines specific to each applicable regulatory framework (GDPR 72h, EU AI Act Article 73), and has been exercised in a tabletop simulation of an AI compliance scenario within the last 18 months with documented lessons-learned outcomes.", "blocking_effect": "requires-review", "evidence_required": [ "compliance_incident_response_playbook document containing ai_incident_scenario_list (minimum four types), severity_level_definitions (P1-P4) with escalation_paths, regulatory_notification_timeline_matrix per framework with specific SLAs, named_role_assignments for Incident Commander/Legal Lead/Technical Lead, and containment_action_steps", "tabletop_exercise_record dated within the last 18 months documenting scenario_type (must be AI compliance scenario), participants by named role, findings, and lessons_learned items with remediation_action_owner and completion_status", "notification_template_set for each applicable regulatory authority with legal_counsel_review_date within the last 12 months confirming language is current and jurisdiction-appropriate", "incident_response_log for any compliance incidents in the last 24 months showing incident_id, severity_level, trigger_timestamp, notification_sent_timestamp, regulatory_authority_notified, and SLA_compliance status for each framework-governed notification" ], "evidence": [ { "id": "CG-06-E1", "description": "compliance_incident_response_playbook document containing ai_incident_scenario_list (minimum four types), severity_level_definitions (P1-P4) with escalation_paths, regulatory_notification_timeline_matrix per framework with specific SLAs, named_role_assignments for Incident Commander/Legal Lead/Technical Lead, and containment_action_steps", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CG-06-E2", "description": "tabletop_exercise_record dated within the last 18 months documenting scenario_type (must be AI compliance scenario), participants by named role, findings, and lessons_learned items with remediation_action_owner and completion_status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-06-E3", "description": "notification_template_set for each applicable regulatory authority with legal_counsel_review_date within the last 12 months confirming language is current and jurisdiction-appropriate", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-06-E4", "description": "incident_response_log for any compliance incidents in the last 24 months showing incident_id, severity_level, trigger_timestamp, notification_sent_timestamp, regulatory_authority_notified, and SLA_compliance status for each framework-governed notification", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://model/controls/CR-04", "id": "CR-04", "domain": "model", "name": "AI Incident Response Management", "validation_objective": "The organization must have a documented, version-controlled AI Incident Response Plan (AIRP) with AI-specific containment playbooks covering model rollback, output-filter enforcement, traffic shaping, and full model shutdown \u2014 tested via at least four quarterly tabletop exercises per year using MITRE ATLAS adversarial scenarios \u2014 and P1/P2 post-incident review records produced within 5 days of event resolution for all qualifying events in the trailing 12 months.", "blocking_effect": "blocks-deployment", "evidence_required": [ "AI Incident Response Plan document (version-controlled, CISO or AI-risk-owner signed, with review date within 12 months)", "Containment playbook index listing separate runbooks for model_rollback, output_filter_enforcement, traffic_shaping, and model_shutdown_with_fallback", "Last 4 quarterly tabletop exercise reports with MITRE ATLAS scenario identifier, participant roster, outcomes, and reviewer sign-off", "P1 and P2 post-incident review records for all qualifying events in the trailing 12 months, each showing post_incident_report_date within 5 days of incident_resolved_date", "EU Art. 73 notification trigger mapping document showing which P1 severity criteria trigger the Art. 73 serious-incident notification obligation (15d general / 10d death / 2d widespread or critical infrastructure)" ], "evidence": [ { "id": "CR-04-E1", "description": "AI Incident Response Plan document (version-controlled, CISO or AI-risk-owner signed, with review date within 12 months)", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-04-E2", "description": "Containment playbook index listing separate runbooks for model_rollback, output_filter_enforcement, traffic_shaping, and model_shutdown_with_fallback", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-04-E3", "description": "Last 4 quarterly tabletop exercise reports with MITRE ATLAS scenario identifier, participant roster, outcomes, and reviewer sign-off", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CR-04-E4", "description": "P1 and P2 post-incident review records for all qualifying events in the trailing 12 months, each showing post_incident_report_date within 5 days of incident_resolved_date", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-04-E5", "description": "EU Art. 73 notification trigger mapping document showing which P1 severity criteria trigger the Art. 73 serious-incident notification obligation (15d general / 10d death / 2d widespread or critical infrastructure)", "evidence_type": "incident-record", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 Clause 10.2 (Nonconformity and corrective action) requires responding to nonconformities and correcting root causes. CR-04\u2019s incident response plan, containment playbooks, and post-incident reviews implement that cycle for AI incidents." }, { "control": "apeiris://agentic/controls/AG-05", "id": "AG-05", "domain": "agentic", "name": "Agent Incident Response Program", "validation_objective": "The enterprise has a documented, tested AI Incident Response Playbook with AI-specific containment capabilities, and every production agent has an authenticated kill-switch that demonstrably suspends its operation within 60 seconds of an authorized responder request.", "blocking_effect": "requires-review", "evidence_required": [ "AI Incident Response Playbook document covering incident classification taxonomy, severity tiers with quantitative criteria, containment actions per incident type, escalation matrix, and regulatory notification timelines", "Kill-switch capability validation records for each production agent, confirming suspension within the 60-second SLA in the most recent test", "Tabletop or functional test records for the AI Incident Response Playbook covering at least P1 and P2 severity scenarios", "Post-incident review records for all P1 and P2 events including root cause, containment timeline, and lessons-learned pipeline submissions" ], "evidence": [ { "id": "AG-05-E1", "description": "AI Incident Response Playbook document covering incident classification taxonomy, severity tiers with quantitative criteria, containment actions per incident type, escalation matrix, and regulatory notification timelines", "evidence_type": "incident-record", "verification": "attested" }, { "id": "AG-05-E2", "description": "Kill-switch capability validation records for each production agent, confirming suspension within the 60-second SLA in the most recent test", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "AG-05-E3", "description": "Tabletop or functional test records for the AI Incident Response Playbook covering at least P1 and P2 severity scenarios", "evidence_type": "incident-record", "verification": "attested" }, { "id": "AG-05-E4", "description": "Post-incident review records for all P1 and P2 events including root cause, containment timeline, and lessons-learned pipeline submissions", "evidence_type": "incident-record", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 \u00a710.2 requires reacting to nonconformities and taking corrective action to prevent recurrence. An agent incident response program provides the organizational procedures for exactly that reaction when agentic systems misbehave." } ] }, { "requirement_id": "ISO42001-10.2", "section": "\u00a710.2", "title": "Continual improvement", "text": "The organization shall continually improve the suitability, adequacy, and effectiveness of the AIMS.", "verdict": "partial", "coverage": "partial", "notes": "Remediation tracking, scheduled model re-validation, continuous improvement and lessons learned, and policy improvement controls address continual improvement of AI controls. AIMS-level improvement planning (maturity roadmaps, gap closure prioritization) is an organizational management process.", "control_count": 4, "proof_chain": [ { "control": "apeiris://compliance/controls/CI-07", "id": "CI-07", "domain": "compliance", "name": "Remediation Tracking and Closure", "validation_objective": "Every compliance gap identified by control testing (CI-01), monitoring (CI-02), or internal audit (CI-06) has a corresponding remediation ticket with an assigned single owner, target date, documented root cause, remediation plan, and independently verified closure evidence. No critical-severity ticket is open beyond 15 business days without a documented executive escalation record.", "blocking_effect": "requires-review", "evidence_required": [ "Remediation register export listing all open and closed tickets with source_control, severity, assigned_owner, root_cause, remediation_plan, target_date, and actual_closure_date for the full audit period", "Closure verification records for each high and critical ticket documenting the independent verifier identity, verification method (re-test, configuration check, or re-assessment), and verification outcome", "Automated escalation log showing escalation trigger events and management acknowledgment timestamps for all overdue items during the period", "Recurrence analysis report identifying any finding appearing in both the current and prior audit cycle, with root cause explanation for recurrence", "Weekly remediation velocity reports showing open ticket counts by severity and age distribution across the audit period" ], "evidence": [ { "id": "CI-07-E1", "description": "Remediation register export listing all open and closed tickets with source_control, severity, assigned_owner, root_cause, remediation_plan, target_date, and actual_closure_date for the full audit period", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "CI-07-E2", "description": "Closure verification records for each high and critical ticket documenting the independent verifier identity, verification method (re-test, configuration check, or re-assessment), and verification outcome", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "CI-07-E3", "description": "Automated escalation log showing escalation trigger events and management acknowledgment timestamps for all overdue items during the period", "evidence_type": "audit-log", "verification": "automated" }, { "id": "CI-07-E4", "description": "Recurrence analysis report identifying any finding appearing in both the current and prior audit cycle, with root cause explanation for recurrence", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-07-E5", "description": "Weekly remediation velocity reports showing open ticket counts by severity and age distribution across the audit period", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://model/controls/CR-03", "id": "CR-03", "domain": "model", "name": "Scheduled Model Re-validation", "validation_objective": "A full benchmark, bias, and safety evaluation suite must execute against every production model version on the defined re-validation schedule; results must be compared to the deployment-time baseline metrics, and any performance degradation beyond configured thresholds must trigger a formal response documented and initiated before the next operational window closes.", "blocking_effect": "blocks-deployment", "evidence_required": [ "re_validation_schedule_record per model version showing configured re-validation frequency, last_run_timestamp, next_run_due, and scheduled_suite_identifier with no unmonitored production versions", "scheduled_evaluation_report for each re-validation run showing benchmark results, bias metrics, and safety evaluation scores with explicit comparison to the deployment-time baseline", "threshold_comparison_record showing the delta between current re-validation results and baseline for each metric with a pass/fail determination against the configured degradation threshold", "re_validation_response_record for any threshold breach, documenting the triggered response action (rollback, retraining, or escalation), responsible_party, and closure_timestamp", "re_validation_coverage_audit confirming all active production model versions are enrolled in re-validation schedules and that no version has exceeded its next_run_due without a completed run" ], "evidence": [ { "id": "CR-03-E1", "description": "re_validation_schedule_record per model version showing configured re-validation frequency, last_run_timestamp, next_run_due, and scheduled_suite_identifier with no unmonitored production versions", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-03-E2", "description": "scheduled_evaluation_report for each re-validation run showing benchmark results, bias metrics, and safety evaluation scores with explicit comparison to the deployment-time baseline", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "CR-03-E3", "description": "threshold_comparison_record showing the delta between current re-validation results and baseline for each metric with a pass/fail determination against the configured degradation threshold", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-03-E4", "description": "re_validation_response_record for any threshold breach, documenting the triggered response action (rollback, retraining, or escalation), responsible_party, and closure_timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-03-E5", "description": "re_validation_coverage_audit confirming all active production model versions are enrolled in re-validation schedules and that no version has exceeded its next_run_due without a completed run", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 A.6.2.4 (AI system verification and validation) requires validation evidence to remain valid; CR-03\u2019s scheduled re-validation re-produces that evidence on a risk-tiered cadence." }, { "control": "apeiris://agentic/controls/AG-07", "id": "AG-07", "domain": "agentic", "name": "Continuous Improvement and Lessons Learned", "validation_objective": "The enterprise operates a closed-loop lessons-learned program with four defined input channels, a tracked pipeline from capture to verified implementation, and documented control update recommendations with named owners and due dates that are verifiably completed.", "blocking_effect": "advisory", "evidence_required": [ "Lessons-learned register showing all open and closed items from the past 12 months, with input source, root cause, affected control identifiers, recommended update, approval status, implementation date, and verification evidence", "Post-incident review outputs from all P1/P2 events completed within the 5-business-day SLA, linked to lessons-learned register entries", "Records of external intelligence feed subscriptions and quarterly relevance assessments, including items submitted to the lessons-learned pipeline", "Governance committee retrospective records from each quarterly session showing open action item status and newly identified improvement themes" ], "evidence": [ { "id": "AG-07-E1", "description": "Lessons-learned register showing all open and closed items from the past 12 months, with input source, root cause, affected control identifiers, recommended update, approval status, implementation date, and verification evidence", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AG-07-E2", "description": "Post-incident review outputs from all P1/P2 events completed within the 5-business-day SLA, linked to lessons-learned register entries", "evidence_type": "incident-record", "verification": "attested" }, { "id": "AG-07-E3", "description": "Records of external intelligence feed subscriptions and quarterly relevance assessments, including items submitted to the lessons-learned pipeline", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-07-E4", "description": "Governance committee retrospective records from each quarterly session showing open action item status and newly identified improvement themes", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 \u00a710.1 requires continual improvement of the suitability, adequacy, and effectiveness of the AI management system. A structured lessons-learned pipeline with traceability from incident to control change is the direct mechanism of that improvement." }, { "control": "apeiris://authority/controls/PG-08", "id": "PG-08", "domain": "authority", "name": "Lessons Learned and Policy Improvement", "validation_objective": "Every AI policy incident and near-miss must generate a structured lessons-learned record that identifies the root cause, the policy gap exploited, and a documented improvement action with an assigned owner and target closure date. The improvement cycle must be confirmed closed in the policy registry before the control is considered passing.", "blocking_effect": "requires-review", "evidence_required": [ "lessons_learned_record for each qualifying incident containing root_cause, policy_gap_reference, improvement_action, assigned_owner, and target_closure_date fields", "policy_improvement_log confirming that each improvement action triggered a versioned policy update or documented risk-acceptance decision with sign-off", "incident_classification_record distinguishing incidents requiring formal lessons-learned review from those below threshold, with classification rationale", "policy_registry_update_record showing the policy version that incorporated each improvement action, with before-and-after change diff and approver identity", "improvement_cycle_closure_record confirming that each open improvement action was closed within its target date or escalated with documented justification for extension" ], "evidence": [ { "id": "PG-08-E1", "description": "lessons_learned_record for each qualifying incident containing root_cause, policy_gap_reference, improvement_action, assigned_owner, and target_closure_date fields", "evidence_type": "incident-record", "verification": "attested" }, { "id": "PG-08-E2", "description": "policy_improvement_log confirming that each improvement action triggered a versioned policy update or documented risk-acceptance decision with sign-off", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PG-08-E3", "description": "incident_classification_record distinguishing incidents requiring formal lessons-learned review from those below threshold, with classification rationale", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PG-08-E4", "description": "policy_registry_update_record showing the policy version that incorporated each improvement action, with before-and-after change diff and approver identity", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PG-08-E5", "description": "improvement_cycle_closure_record confirming that each open improvement action was closed within its target date or escalated with documented justification for extension", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "The structured lessons-learned-to-policy-update cycle directly implements \u00a710.1 continual improvement." } ] }, { "requirement_id": "ISO42001-A.2.1", "section": "Annex A \u00a7A.2.1", "title": "Policies related to AI \u2014 AI policy document", "text": "The organization shall establish and maintain an AI policy that reflects the organization's approach to the responsible development, deployment, and use of AI systems.", "verdict": "supported", "coverage": "direct", "notes": "Internal policy register for AI deployments, policy version control and distribution, and compliance policy framework for AI directly implement the AI policy document requirement.", "control_count": 3, "proof_chain": [ { "control": "apeiris://authority/controls/PO-01", "id": "PO-01", "domain": "authority", "name": "Internal Policy Register for AI Deployments", "validation_objective": "Every active AI deployment must have at least one current, non-expired policy register entry in the authoritative policy register, and that entry must contain version, effective date, scope, owning team, and deployment linkage fields. No AI deployment may enter or remain in production without a valid policy register reference confirmed by the deployment pipeline.", "blocking_effect": "blocks-deployment", "evidence_required": [ "policy_register_schema_document specifying required fields including policy_id, version, effective_date, expiry_date, owning_team, ai_deployment_scope, and authority_domain_applicability", "deployment_policy_linkage_audit_log confirming every active AI deployment has a corresponding current policy register entry with a non-expired effective date", "policy_register_access_control_matrix demonstrating that register modifications require dual authorization and all changes are attributed and logged", "deployment_pipeline_gate_configuration showing that AI deployment approval workflows validate the presence of a current policy register entry before proceeding" ], "evidence": [ { "id": "PO-01-E1", "description": "policy_register_schema_document specifying required fields including policy_id, version, effective_date, expiry_date, owning_team, ai_deployment_scope, and authority_domain_applicability", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-01-E2", "description": "deployment_policy_linkage_audit_log confirming every active AI deployment has a corresponding current policy register entry with a non-expired effective date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-01-E3", "description": "policy_register_access_control_matrix demonstrating that register modifications require dual authorization and all changes are attributed and logged", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-01-E4", "description": "deployment_pipeline_gate_configuration showing that AI deployment approval workflows validate the presence of a current policy register entry before proceeding", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "The authoritative policy register maintains documented information per \u00a77.5, partially." }, { "control": "apeiris://authority/controls/PO-02", "id": "PO-02", "domain": "authority", "name": "Policy Version Control and Distribution", "validation_objective": "All AI authority policies must be stored in a version-controlled repository with semantic versioning and approval-gated merges, and every AI system runtime configuration must reference a specific approved policy version. Upon a policy version update, all linked AI system configurations must be updated to the new version within one business day, and all superseded versions must be retained in an immutable archive with their effective date ranges intact.", "blocking_effect": "blocks-deployment", "evidence_required": [ "policy_version_distribution_log showing each policy version publication event, the list of linked AI system configurations notified, and the timestamp of configuration update for each consumer", "ai_runtime_policy_version_references confirming each active AI system references a specific approved policy version rather than an unversioned label", "policy_archive_effective_date_ranges document confirming all superseded policy versions are retained with their start and end effective dates", "policy_repository_approval_log showing committer attribution and approval workflow completion for every version merge during the audit period" ], "evidence": [ { "id": "PO-02-E1", "description": "policy_version_distribution_log showing each policy version publication event, the list of linked AI system configurations notified, and the timestamp of configuration update for each consumer", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "PO-02-E2", "description": "ai_runtime_policy_version_references confirming each active AI system references a specific approved policy version rather than an unversioned label", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PO-02-E3", "description": "policy_archive_effective_date_ranges document confirming all superseded policy versions are retained with their start and end effective dates", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-02-E4", "description": "policy_repository_approval_log showing committer attribution and approval workflow completion for every version merge during the audit period", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "Semantic versioning and retention of superseded policies reflect \u00a77.5 documented information, partially." }, { "control": "apeiris://compliance/controls/CG-02", "id": "CG-02", "domain": "compliance", "name": "Compliance Policy Framework for AI", "validation_objective": "The organization must maintain a board-approved enterprise AI compliance policy, a regulatory inventory covering all applicable frameworks across all jurisdictions of AI operation updated within 30 days of any material regulatory change, and a documented policy hierarchy extending from the enterprise policy to system-specific procedures for every AI system in production, with all policy documents reviewed within the last 14 months and a demonstrated process for completing policy updates within 90 days of material regulatory change.", "blocking_effect": "requires-review", "evidence_required": [ "board_approved_enterprise_ai_compliance_policy with formal board ratification record, approval date within the last 14 months, and defined scope covering all applicable AI regulatory obligations across all operating jurisdictions", "regulatory_inventory spanning all jurisdictions of AI operation listing all applicable frameworks, assigned obligation owners for each framework, and last update date confirming review within 30 days of any material regulatory change", "policy_coverage_map linking every AI system in the production AI inventory to at least one policy document with a named owner, last review date within 14 months, and applicable regulatory frameworks identified", "regulatory_change_tracking_log for the last 24 months showing detected regulatory changes, policy update decisions triggered, update completion dates, and compliance with the 90-day response target for each change", "framework_specific_standards_documentation for each applicable regulatory framework, mapping framework requirements to internal controls and assigning named owners responsible for each obligation" ], "evidence": [ { "id": "CG-02-E1", "description": "board_approved_enterprise_ai_compliance_policy with formal board ratification record, approval date within the last 14 months, and defined scope covering all applicable AI regulatory obligations across all operating jurisdictions", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-02-E2", "description": "regulatory_inventory spanning all jurisdictions of AI operation listing all applicable frameworks, assigned obligation owners for each framework, and last update date confirming review within 30 days of any material regulatory change", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-02-E3", "description": "policy_coverage_map linking every AI system in the production AI inventory to at least one policy document with a named owner, last review date within 14 months, and applicable regulatory frameworks identified", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-02-E4", "description": "regulatory_change_tracking_log for the last 24 months showing detected regulatory changes, policy update decisions triggered, update completion dates, and compliance with the 90-day response target for each change", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-02-E5", "description": "framework_specific_standards_documentation for each applicable regulatory framework, mapping framework requirements to internal controls and assigning named owners responsible for each obligation", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "ISO42001-A.2.2", "section": "Annex A \u00a7A.2.2", "title": "Policies related to AI \u2014 Roles and responsibilities", "text": "The organization shall define and communicate roles, responsibilities, and authorities related to AI systems within its policies.", "verdict": "supported", "coverage": "direct", "notes": "Compliance governance structure, model ownership assignment, AI model governance committee, and principal accountability binding define and assign AI roles and responsibilities.", "control_count": 4, "proof_chain": [ { "control": "apeiris://compliance/controls/CG-01", "id": "CG-01", "domain": "compliance", "name": "Compliance Governance Structure", "validation_objective": "The organization must have a formally chartered Compliance Committee with documented meeting minutes showing quorum was achieved in at least 80% of scheduled sessions in the last 12 months, a CCO or equivalent with a documented direct reporting channel to the board Audit and Risk Committee that bypasses management for material issues, and a current escalation matrix reviewed within 12 months covering all material compliance issue types including AI regulatory incidents.", "blocking_effect": "requires-review", "evidence_required": [ "compliance_committee_charter signed and approved by the board with defined membership composition, quorum rules, meeting cadence, decision authority scope, and AI regulatory obligation coverage", "cco_role_documentation including the CCO written authority scope, direct reporting line to the Audit and Risk Committee as documented in board resolution or equivalent formal governance instrument, and organizational chart placement", "compliance_committee_meeting_minutes for the last 12 months showing attendees, quorum status at each session, agenda items including AI compliance matters, and action item tracking with completion status", "escalation_matrix covering all material compliance issue types \u2014 regulatory inquiry, enforcement action, material AI risk event, data breach \u2014 with defined escalation paths, response timeframes, and responsible parties for each tier", "board_resolution or formal charter ratification record establishing the compliance governance structure with effective date and scope of authority" ], "evidence": [ { "id": "CG-01-E1", "description": "compliance_committee_charter signed and approved by the board with defined membership composition, quorum rules, meeting cadence, decision authority scope, and AI regulatory obligation coverage", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-01-E2", "description": "cco_role_documentation including the CCO written authority scope, direct reporting line to the Audit and Risk Committee as documented in board resolution or equivalent formal governance instrument, and organizational chart placement", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-01-E3", "description": "compliance_committee_meeting_minutes for the last 12 months showing attendees, quorum status at each session, agenda items including AI compliance matters, and action item tracking with completion status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-01-E4", "description": "escalation_matrix covering all material compliance issue types \u2014 regulatory inquiry, enforcement action, material AI risk event, data breach \u2014 with defined escalation paths, response timeframes, and responsible parties for each tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-01-E5", "description": "board_resolution or formal charter ratification record establishing the compliance governance structure with effective date and scope of authority", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://model/controls/OA-01", "id": "OA-01", "domain": "model", "name": "Model Ownership Assignment", "validation_objective": "Every AI model in the production model registry must have a non-null named human owner who is a current employee, a responsible team, and an executive sponsor at director level or above for high-impact models, all recorded within five business days of deployment. No production model may exist without a current ownership record, and ownership must be reassigned within ten business days of any owner departure.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_ownership_register_extract with fields: model_id, owner_name, owner_employee_id, team, executive_sponsor, effective_date, review_date \u2014 showing 100% coverage of production models with non-null values", "deployment_pipeline_gate_log showing blocked promotion events for models with null ownership fields, with timestamps and model IDs", "hr_departure_event_log cross-referenced with ownership_reassignment_record demonstrating reassignment within ten business days for each departure", "governance_committee_meeting_minutes containing ownership review agenda items for the preceding 12-month period" ], "evidence": [ { "id": "OA-01-E1", "description": "model_ownership_register_extract with fields: model_id, owner_name, owner_employee_id, team, executive_sponsor, effective_date, review_date \u2014 showing 100% coverage of production models with non-null values", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-01-E2", "description": "deployment_pipeline_gate_log showing blocked promotion events for models with null ownership fields, with timestamps and model IDs", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-01-E3", "description": "hr_departure_event_log cross-referenced with ownership_reassignment_record demonstrating reassignment within ten business days for each departure", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-01-E4", "description": "governance_committee_meeting_minutes containing ownership review agenda items for the preceding 12-month period", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO 42001 Clause 5.3 requires assignment of roles, responsibilities, and authorities." }, { "control": "apeiris://model/controls/OA-03", "id": "OA-03", "domain": "model", "name": "AI Model Governance Committee", "validation_objective": "The organization must have a formally chartered AI Model Governance Committee with documented membership covering all required functional areas, exclusive approval authority over high-risk model deployments and risk appetite thresholds, and auditable meeting minutes retained for seven years. The committee must have met at minimum quarterly in each of the preceding four quarters, with quorum achieved for all binding decisions.", "blocking_effect": "blocks-deployment", "evidence_required": [ "committee_charter current version with executive-level approval signature and date, specifying membership composition, decision rights matrix, quorum requirements, and meeting cadence", "meeting_minutes for all scheduled quarterly sessions in the preceding 12-month period, demonstrating quorum was met and binding decisions were recorded with rationale", "decision_log showing AIGC approval records for all high-risk model deployments and risk appetite changes in the preceding 12 months, cross-referenced against the production model registry", "membership_roster with functional affiliations confirming representation from AI/ML engineering, model validation, legal/compliance, risk management, and at least one business line" ], "evidence": [ { "id": "OA-03-E1", "description": "committee_charter current version with executive-level approval signature and date, specifying membership composition, decision rights matrix, quorum requirements, and meeting cadence", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-03-E2", "description": "meeting_minutes for all scheduled quarterly sessions in the preceding 12-month period, demonstrating quorum was met and binding decisions were recorded with rationale", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-03-E3", "description": "decision_log showing AIGC approval records for all high-risk model deployments and risk appetite changes in the preceding 12 months, cross-referenced against the production model registry", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-03-E4", "description": "membership_roster with functional affiliations confirming representation from AI/ML engineering, model validation, legal/compliance, risk management, and at least one business line", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 Clause 5.3 (Organizational roles, responsibilities and authorities) requires top management to assign and communicate relevant roles and authorities. OA-03\u2019s chartered committee documents those authorities for AI model decisions." }, { "control": "apeiris://authority/controls/PA-04", "id": "PA-04", "domain": "authority", "name": "Principal Accountability Binding", "validation_objective": "Every consequential AI action must produce an immutable accountability binding artifact atomically with the action, containing the action_id, agent_id, principal_id, delegation_basis_id, action_scope, and an integrity hash sealing the record. The artifact must be written to a tamper-evident, append-only store from which neither the AI agent nor its service account can modify or delete entries.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "accountability_binding_artifact for each consequential AI action, containing action_id, agent_id, principal_id, delegation_basis_id, action_scope, action_timestamp, and integrity_hash (sha256) \u2014 all fields must be non-null", "tamper_evident_store_audit_record confirming the binding store is append-only and that no modification or deletion events occurred for any binding artifact during the audit period", "principal_existence_validation_record confirming the principal_id referenced in each binding artifact resolves to a current, active human identity in the enterprise identity system at the time of binding", "binding_completeness_scan result confirming 100% of consequential AI actions in the audit period have a corresponding accountability binding artifact with no gaps" ], "evidence": [ { "id": "PA-04-E1", "description": "accountability_binding_artifact for each consequential AI action, containing action_id, agent_id, principal_id, delegation_basis_id, action_scope, action_timestamp, and integrity_hash (sha256) \u2014 all fields must be non-null", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PA-04-E2", "description": "tamper_evident_store_audit_record confirming the binding store is append-only and that no modification or deletion events occurred for any binding artifact during the audit period", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PA-04-E3", "description": "principal_existence_validation_record confirming the principal_id referenced in each binding artifact resolves to a current, active human identity in the enterprise identity system at the time of binding", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PA-04-E4", "description": "binding_completeness_scan result confirming 100% of consequential AI actions in the audit period have a corresponding accountability binding artifact with no gaps", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "adjacent", "basis": "anchored", "relation": "equivalent_to", "rationale": "Accountability binding operationalizes responsibility per action, distinct from the leadership commitment \u00a75.1 requires." } ] }, { "requirement_id": "ISO42001-A.3.1", "section": "Annex A \u00a7A.3.1", "title": "Internal organization \u2014 AI governance structure", "text": "The organization shall establish an internal structure and governance framework to oversee the responsible development and use of AI systems.", "verdict": "partial", "coverage": "partial", "notes": "Compliance governance structure, agentic AI governance structure, ethics governance structure, and AI model governance committee address AI-specific governance bodies. Cross-domain governance integration and enterprise-wide AI committee charters are organizational design elements.", "control_count": 4, "proof_chain": [ { "control": "apeiris://compliance/controls/CG-01", "id": "CG-01", "domain": "compliance", "name": "Compliance Governance Structure", "validation_objective": "The organization must have a formally chartered Compliance Committee with documented meeting minutes showing quorum was achieved in at least 80% of scheduled sessions in the last 12 months, a CCO or equivalent with a documented direct reporting channel to the board Audit and Risk Committee that bypasses management for material issues, and a current escalation matrix reviewed within 12 months covering all material compliance issue types including AI regulatory incidents.", "blocking_effect": "requires-review", "evidence_required": [ "compliance_committee_charter signed and approved by the board with defined membership composition, quorum rules, meeting cadence, decision authority scope, and AI regulatory obligation coverage", "cco_role_documentation including the CCO written authority scope, direct reporting line to the Audit and Risk Committee as documented in board resolution or equivalent formal governance instrument, and organizational chart placement", "compliance_committee_meeting_minutes for the last 12 months showing attendees, quorum status at each session, agenda items including AI compliance matters, and action item tracking with completion status", "escalation_matrix covering all material compliance issue types \u2014 regulatory inquiry, enforcement action, material AI risk event, data breach \u2014 with defined escalation paths, response timeframes, and responsible parties for each tier", "board_resolution or formal charter ratification record establishing the compliance governance structure with effective date and scope of authority" ], "evidence": [ { "id": "CG-01-E1", "description": "compliance_committee_charter signed and approved by the board with defined membership composition, quorum rules, meeting cadence, decision authority scope, and AI regulatory obligation coverage", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-01-E2", "description": "cco_role_documentation including the CCO written authority scope, direct reporting line to the Audit and Risk Committee as documented in board resolution or equivalent formal governance instrument, and organizational chart placement", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-01-E3", "description": "compliance_committee_meeting_minutes for the last 12 months showing attendees, quorum status at each session, agenda items including AI compliance matters, and action item tracking with completion status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-01-E4", "description": "escalation_matrix covering all material compliance issue types \u2014 regulatory inquiry, enforcement action, material AI risk event, data breach \u2014 with defined escalation paths, response timeframes, and responsible parties for each tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-01-E5", "description": "board_resolution or formal charter ratification record establishing the compliance governance structure with effective date and scope of authority", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://agentic/controls/AG-01", "id": "AG-01", "domain": "agentic", "name": "Agentic AI Governance Structure", "validation_objective": "Prove that the enterprise has a ratified, operational Agentic AI Governance Committee with a documented charter, RACI matrix, and defined three-tier consequence escalation model, and that a named senior accountable owner is recorded in the enterprise risk register. Validate that the committee meets at minimum quarterly, documents decisions, and that governance approval functions as a hard deployment gate.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Ratified Agentic AI Governance Charter documenting committee scope, cross-functional membership roster, quorum requirements, meeting cadence, decision authorities, and escalation tier triggers \u2014 signed within the past 24 months and reviewed within the past 12", "Published RACI matrix covering agent design review, deployment approval, incident escalation, and program reporting with named role assignments and confirmation that 100% of deployed agents have a named governance owner", "Committee meeting minutes from the past four quarters demonstrating quorum, attendance records, and documented decisions for each session", "Enterprise risk register entry naming the senior accountable owner for the agentic AI program by individual name and role, not by position title alone", "Deployment pipeline configuration demonstrating governance approval is enforced as a blocking gate before any agent is promoted to a production environment" ], "evidence": [ { "id": "AG-01-E1", "description": "Ratified Agentic AI Governance Charter documenting committee scope, cross-functional membership roster, quorum requirements, meeting cadence, decision authorities, and escalation tier triggers \u2014 signed within the past 24 months and reviewed within the past 12", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AG-01-E2", "description": "Published RACI matrix covering agent design review, deployment approval, incident escalation, and program reporting with named role assignments and confirmation that 100% of deployed agents have a named governance owner", "evidence_type": "incident-record", "verification": "attested" }, { "id": "AG-01-E3", "description": "Committee meeting minutes from the past four quarters demonstrating quorum, attendance records, and documented decisions for each session", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AG-01-E4", "description": "Enterprise risk register entry naming the senior accountable owner for the agentic AI program by individual name and role, not by position title alone", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-01-E5", "description": "Deployment pipeline configuration demonstrating governance approval is enforced as a blocking gate before any agent is promoted to a production environment", "evidence_type": "configuration-snapshot", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 Clause 5.1 requires top management to demonstrate leadership and commitment to the AI management system, including establishing organizational roles and responsibilities for AI governance. A governance committee with named senior accountability directly satisfies this leadership requirement." }, { "control": "apeiris://ethics/controls/EG-01", "id": "EG-01", "domain": "ethics", "name": "Ethics Governance Structure", "validation_objective": "The enterprise must have an active, formally chartered AI Ethics Board with documented cross-functional membership, defined decision authority over high-risk AI deployments, a functioning escalation path from individual teams to the board, and evidence of executive-level reporting within the past 90 days. The control passes if an Ethics Board charter exists, meeting minutes and decision logs are complete for the trailing 12 months, all high-risk AI systems have Ethics Board approval records, and at least one escalation was exercised and documented.", "blocking_effect": "blocks-deployment", "evidence_required": [ "AI Ethics Board charter document signed at C-suite or board authority level, specifying membership criteria, quorum rules, decision authority scope over high-risk AI deployment approvals, and meeting cadence", "Ethics Board meeting minutes for the trailing 12 months showing dates, attendees, agenda items, decision log entries, and executive or board-level reporting records confirming required governance cadence", "Escalation path documentation distributed to all AI product teams showing the path from individual contributor to Ethics Board with named contacts at each level and documented response SLAs", "Ethics Board decision log entries for AI deployment approvals or rejections in the trailing 12 months, confirming high-risk AI systems passed through the formal governance process", "Evidence of at least one ethics escalation exercised through the documented escalation path, with intake record, investigation record, Ethics Board disposition, and outcome notification to the escalating party" ], "evidence": [ { "id": "EG-01-E1", "description": "AI Ethics Board charter document signed at C-suite or board authority level, specifying membership criteria, quorum rules, decision authority scope over high-risk AI deployment approvals, and meeting cadence", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-01-E2", "description": "Ethics Board meeting minutes for the trailing 12 months showing dates, attendees, agenda items, decision log entries, and executive or board-level reporting records confirming required governance cadence", "evidence_type": "audit-log", "verification": "automated" }, { "id": "EG-01-E3", "description": "Escalation path documentation distributed to all AI product teams showing the path from individual contributor to Ethics Board with named contacts at each level and documented response SLAs", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-01-E4", "description": "Ethics Board decision log entries for AI deployment approvals or rejections in the trailing 12 months, confirming high-risk AI systems passed through the formal governance process", "evidence_type": "audit-log", "verification": "automated" }, { "id": "EG-01-E5", "description": "Evidence of at least one ethics escalation exercised through the documented escalation path, with intake record, investigation record, Ethics Board disposition, and outcome notification to the escalating party", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001:2023 \u00a76.1 requires organizations to establish AI management system governance including roles, responsibilities, and accountability structures. A formal Ethics Board directly satisfies this requirement." }, { "control": "apeiris://model/controls/OA-03", "id": "OA-03", "domain": "model", "name": "AI Model Governance Committee", "validation_objective": "The organization must have a formally chartered AI Model Governance Committee with documented membership covering all required functional areas, exclusive approval authority over high-risk model deployments and risk appetite thresholds, and auditable meeting minutes retained for seven years. The committee must have met at minimum quarterly in each of the preceding four quarters, with quorum achieved for all binding decisions.", "blocking_effect": "blocks-deployment", "evidence_required": [ "committee_charter current version with executive-level approval signature and date, specifying membership composition, decision rights matrix, quorum requirements, and meeting cadence", "meeting_minutes for all scheduled quarterly sessions in the preceding 12-month period, demonstrating quorum was met and binding decisions were recorded with rationale", "decision_log showing AIGC approval records for all high-risk model deployments and risk appetite changes in the preceding 12 months, cross-referenced against the production model registry", "membership_roster with functional affiliations confirming representation from AI/ML engineering, model validation, legal/compliance, risk management, and at least one business line" ], "evidence": [ { "id": "OA-03-E1", "description": "committee_charter current version with executive-level approval signature and date, specifying membership composition, decision rights matrix, quorum requirements, and meeting cadence", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-03-E2", "description": "meeting_minutes for all scheduled quarterly sessions in the preceding 12-month period, demonstrating quorum was met and binding decisions were recorded with rationale", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-03-E3", "description": "decision_log showing AIGC approval records for all high-risk model deployments and risk appetite changes in the preceding 12 months, cross-referenced against the production model registry", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-03-E4", "description": "membership_roster with functional affiliations confirming representation from AI/ML engineering, model validation, legal/compliance, risk management, and at least one business line", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 Clause 5.3 (Organizational roles, responsibilities and authorities) requires top management to assign and communicate relevant roles and authorities. OA-03\u2019s chartered committee documents those authorities for AI model decisions." } ] }, { "requirement_id": "ISO42001-A.4.1", "section": "Annex A \u00a7A.4.1", "title": "Resources for AI systems \u2014 Computational and data resources", "text": "The organization shall identify and provide the necessary resources for AI systems, including computational resources, training data, and personnel.", "verdict": "partial", "coverage": "partial", "notes": "Program resourcing controls and training data quality gates address resource provision for AI. Budget allocation and infrastructure capacity planning are organizational resource management decisions.", "control_count": 4, "proof_chain": [ { "control": "apeiris://compliance/controls/CG-05", "id": "CG-05", "domain": "compliance", "name": "Compliance Program Resourcing", "validation_objective": "The compliance program has a documented annual resource assessment \u2014 completed within the current fiscal year \u2014 that maps qualified headcount, allocated budget, and active tooling to each regulatory obligation in scope for AI systems, identifies any coverage gaps, and has been formally presented to executive leadership with documented gap remediation plans or explicit board-approved acceptance rationale for each unresolved gap.", "blocking_effect": "requires-review", "evidence_required": [ "annual_resource_assessment_report dated within the current fiscal year containing headcount_by_regulatory_domain, qualification_evidence for each AI compliance role, budget_allocation by obligation category, and tooling_inventory with coverage_scope listing in-scope AI systems", "executive_presentation_record or board_committee_minutes documenting CCO presentation of resource assessment results with named attendees and executive acknowledgment or formal approval", "staffing_plan document defining minimum qualification requirements for AI-specific compliance roles (EU AI Act specialist, AI risk analyst, compliance engineer) with named_incumbent or open_requisition for each required role", "gap_remediation_plan for each identified resource gap with owner, target_date, budget_approved status, and current_status \u2014 or a formal board-approved acceptance record for gaps accepted as residual risk", "compliance_tooling_inventory listing each platform with license_status, coverage_scope (which AI systems are covered), and last_validated_date confirming active integration with data sources" ], "evidence": [ { "id": "CG-05-E1", "description": "annual_resource_assessment_report dated within the current fiscal year containing headcount_by_regulatory_domain, qualification_evidence for each AI compliance role, budget_allocation by obligation category, and tooling_inventory with coverage_scope listing in-scope AI systems", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-05-E2", "description": "executive_presentation_record or board_committee_minutes documenting CCO presentation of resource assessment results with named attendees and executive acknowledgment or formal approval", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-05-E3", "description": "staffing_plan document defining minimum qualification requirements for AI-specific compliance roles (EU AI Act specialist, AI risk analyst, compliance engineer) with named_incumbent or open_requisition for each required role", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-05-E4", "description": "gap_remediation_plan for each identified resource gap with owner, target_date, budget_approved status, and current_status \u2014 or a formal board-approved acceptance record for gaps accepted as residual risk", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-05-E5", "description": "compliance_tooling_inventory listing each platform with license_status, coverage_scope (which AI systems are covered), and last_validated_date confirming active integration with data sources", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://resilience/controls/RG-05", "id": "RG-05", "domain": "resilience", "name": "Resilience Program Resourcing", "validation_objective": "The resilience program must have an approved and tracked budget line item, all defined resilience roles filled at or above minimum staffing level with no vacancy exceeding 90 days, a tooling inventory with no documented gaps that have caused a required test cadence deferral in the review period, and an annual resource adequacy review delivered to the Resilience Steering Committee.", "blocking_effect": "requires-review", "evidence_required": [ "Approved resilience program resource plan with dedicated budget line item, planning approval date within the current fiscal year, and budget vs. actuals tracking record", "Staffing inventory showing each required resilience role, the minimum headcount threshold, current headcount, and vacancy status with days-open for any open positions", "Tooling inventory covering all resilience tooling categories (monitoring, chaos engineering, DR orchestration, backup verification, model snapshot management) with gap assessment results and last review date", "Annual resource adequacy review report presented to and acknowledged by the Resilience Steering Committee, covering staffing, tooling, and budget against program obligations", "Test calendar showing scheduled obligations vs. actual execution, with any deferrals coded by root cause (resource constraint vs. other)" ], "evidence": [ { "id": "RG-05-E1", "description": "Approved resilience program resource plan with dedicated budget line item, planning approval date within the current fiscal year, and budget vs. actuals tracking record", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RG-05-E2", "description": "Staffing inventory showing each required resilience role, the minimum headcount threshold, current headcount, and vacancy status with days-open for any open positions", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RG-05-E3", "description": "Tooling inventory covering all resilience tooling categories (monitoring, chaos engineering, DR orchestration, backup verification, model snapshot management) with gap assessment results and last review date", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "RG-05-E4", "description": "Annual resource adequacy review report presented to and acknowledged by the Resilience Steering Committee, covering staffing, tooling, and budget against program obligations", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RG-05-E5", "description": "Test calendar showing scheduled obligations vs. actual execution, with any deferrals coded by root cause (resource constraint vs. other)", "evidence_type": "automated-test-result", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://model/controls/TG-01", "id": "TG-01", "domain": "model", "name": "Training Data Quality Gates", "validation_objective": "No training run may be initiated unless the designated training dataset has passed automated schema validation, completeness checks, and provenance verification in the current pipeline run; all gate results must be logged with pass/fail status and linked to the training job record.", "blocking_effect": "blocks-deployment", "evidence_required": [ "training_data_quality_gate_report for the current training run showing schema validation results (expected vs. actual field types and cardinalities), completeness check results (null rates, minimum coverage thresholds), and provenance verification status (source hash match, chain-of-custody record reference)", "training_pipeline_block_log confirming that any training attempt that failed a quality gate was rejected before the training compute job was allocated", "dataset_provenance_record with source identifier, ingestion timestamp, data owner, and integrity hash for each training shard used in the run", "quality_threshold_configuration_document defining the pass/fail thresholds for schema validation, completeness, and provenance checks, reviewed and approved by the ML engineering lead" ], "evidence": [ { "id": "TG-01-E1", "description": "training_data_quality_gate_report for the current training run showing schema validation results (expected vs. actual field types and cardinalities), completeness check results (null rates, minimum coverage thresholds), and provenance verification status (source hash match, chain-of-custody record reference)", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "TG-01-E2", "description": "training_pipeline_block_log confirming that any training attempt that failed a quality gate was rejected before the training compute job was allocated", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-01-E3", "description": "dataset_provenance_record with source identifier, ingestion timestamp, data owner, and integrity hash for each training shard used in the run", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-01-E4", "description": "quality_threshold_configuration_document defining the pass/fail thresholds for schema validation, completeness, and provenance checks, reviewed and approved by the ML engineering lead", "evidence_type": "data-lineage-record", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 A.7.4 (Quality of data) requires ensuring that data used for AI systems meets defined quality criteria. TG-01\u2019s schema validation, completeness checks, and quality gates enforce those criteria at pipeline time." }, { "control": "apeiris://model/controls/LI-04", "id": "LI-04", "domain": "model", "name": "Structured Model Documentation \u2014 Complete Model Card with All Required Sections", "validation_objective": "Every model submitted for registration must have a schema-validated model card with all nine Mitchell et al. 2019 sections substantively populated and passing field-level validation rules; the model card must be version-locked to the artifact hash and returned as structured metadata from the registry API; and registration must be blocked when any required section is absent, empty, or contains only placeholder text.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_card_completeness_validation_report showing pass/fail status per section with field-level validation results, registration blocking decision, and validation timestamp for the current artifact version", "versioned_model_card artifact linked to the specific model artifact hash with all nine Mitchell et al. sections containing substantive content (not placeholder text), retrievable from the registry by artifact hash", "model_registry_entry showing the current model card version hash stored alongside the artifact hash as paired immutable fields", "eu_ai_act_annex_iv_supplemental_record for EU AI Act high-risk in-scope systems confirming Annex IV technical documentation fields are populated in addition to the nine Mitchell et al. sections" ], "evidence": [ { "id": "LI-04-E1", "description": "model_card_completeness_validation_report showing pass/fail status per section with field-level validation results, registration blocking decision, and validation timestamp for the current artifact version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-04-E2", "description": "versioned_model_card artifact linked to the specific model artifact hash with all nine Mitchell et al. sections containing substantive content (not placeholder text), retrievable from the registry by artifact hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-04-E3", "description": "model_registry_entry showing the current model card version hash stored alongside the artifact hash as paired immutable fields", "evidence_type": "model-card", "verification": "attested" }, { "id": "LI-04-E4", "description": "eu_ai_act_annex_iv_supplemental_record for EU AI Act high-risk in-scope systems confirming Annex IV technical documentation fields are populated in addition to the nine Mitchell et al. sections", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 A.6.2.3 (Documentation of AI system design and development) requires documented design and development information. A complete, versioned model card linked to each release satisfies that documentation requirement for models." } ] }, { "requirement_id": "ISO42001-A.4.2", "section": "Annex A \u00a7A.4.2", "title": "Resources for AI systems \u2014 AI competence and expertise", "text": "The organization shall ensure personnel involved in AI system development and deployment possess the necessary competence and shall provide appropriate training.", "verdict": "partial", "coverage": "partial", "notes": "Ethics training and capability building, compliance training and awareness program, and AI model governance committee (requiring specialized expertise) address AI competence. Competency frameworks, certification requirements, and individual competency assessments are HR processes.", "control_count": 3, "proof_chain": [ { "control": "apeiris://ethics/controls/EG-04", "id": "EG-04", "domain": "ethics", "name": "Ethics Training and Capability Building", "validation_objective": "All personnel with AI development, deployment, or governance responsibilities must have completed role-appropriate ethics training within the past 12 months, with training prerequisites enforced as a gate for AI system access and product sign-off authority. Training curricula must be role-differentiated across at least four tracks covering practitioners, product managers, legal/compliance, and executives.", "blocking_effect": "blocks-deployment", "evidence_required": [ "training_completion_records disaggregated by role (AI practitioner, product manager, legal/compliance, executive) showing completion date, curriculum version, and assessment score for each individual within the trailing 12 months", "role_differentiated_curriculum_documentation showing distinct training tracks for each AI-facing role with topic coverage including fairness metrics, bias detection, regulatory obligations, and escalation procedures", "system_access_prerequisite_log confirming ethics training completion status was verified before granting AI development environment access or product approval authority", "training_refresh_trigger_record documenting evaluation of training currency following major regulatory changes with decision rationale and revised curriculum effective date where applicable" ], "evidence": [ { "id": "EG-04-E1", "description": "training_completion_records disaggregated by role (AI practitioner, product manager, legal/compliance, executive) showing completion date, curriculum version, and assessment score for each individual within the trailing 12 months", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-04-E2", "description": "role_differentiated_curriculum_documentation showing distinct training tracks for each AI-facing role with topic coverage including fairness metrics, bias detection, regulatory obligations, and escalation procedures", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-04-E3", "description": "system_access_prerequisite_log confirming ethics training completion status was verified before granting AI development environment access or product approval authority", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EG-04-E4", "description": "training_refresh_trigger_record documenting evaluation of training currency following major regulatory changes with decision rationale and revised curriculum effective date where applicable", "evidence_type": "evaluation-scorecard", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001:2023 \u00a77.2 requires organizations to determine necessary competence for AI management system roles and ensure persons are competent. This control directly implements role-specific competence requirements through structured training programs." }, { "control": "apeiris://compliance/controls/CI-05", "id": "CI-05", "domain": "compliance", "name": "Compliance Training and Awareness Program", "validation_objective": "All in-scope personnel have completed role-specific AI compliance training within the required period, with attestation records documenting individual completion stored in a tracked learning management system. Training content must have been reviewed for legal accuracy within the prior 12 months.", "blocking_effect": "requires-review", "evidence_required": [ "LMS completion records listing employee_id, role_category, training_module_id, completion_timestamp, and pass/fail status for all in-scope staff during the audit period", "Training attestation certificates signed by each participant and retained for the audit period, covering EU AI Act, GDPR, and sector-specific AI obligation modules", "Training curriculum legal review sign-off from counsel documenting reviewer identity, review date, and specific regulatory changes prompting the review", "Knowledge assessment results by role category showing aggregate pass rates and individual scores for the current training cycle", "Just-in-time compliance notice log showing distribution date, recipient list, and triggering regulatory event for each notice issued in the period" ], "evidence": [ { "id": "CI-05-E1", "description": "LMS completion records listing employee_id, role_category, training_module_id, completion_timestamp, and pass/fail status for all in-scope staff during the audit period", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-05-E2", "description": "Training attestation certificates signed by each participant and retained for the audit period, covering EU AI Act, GDPR, and sector-specific AI obligation modules", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-05-E3", "description": "Training curriculum legal review sign-off from counsel documenting reviewer identity, review date, and specific regulatory changes prompting the review", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CI-05-E4", "description": "Knowledge assessment results by role category showing aggregate pass rates and individual scores for the current training cycle", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-05-E5", "description": "Just-in-time compliance notice log showing distribution date, recipient list, and triggering regulatory event for each notice issued in the period", "evidence_type": "audit-log", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://model/controls/OA-03", "id": "OA-03", "domain": "model", "name": "AI Model Governance Committee", "validation_objective": "The organization must have a formally chartered AI Model Governance Committee with documented membership covering all required functional areas, exclusive approval authority over high-risk model deployments and risk appetite thresholds, and auditable meeting minutes retained for seven years. The committee must have met at minimum quarterly in each of the preceding four quarters, with quorum achieved for all binding decisions.", "blocking_effect": "blocks-deployment", "evidence_required": [ "committee_charter current version with executive-level approval signature and date, specifying membership composition, decision rights matrix, quorum requirements, and meeting cadence", "meeting_minutes for all scheduled quarterly sessions in the preceding 12-month period, demonstrating quorum was met and binding decisions were recorded with rationale", "decision_log showing AIGC approval records for all high-risk model deployments and risk appetite changes in the preceding 12 months, cross-referenced against the production model registry", "membership_roster with functional affiliations confirming representation from AI/ML engineering, model validation, legal/compliance, risk management, and at least one business line" ], "evidence": [ { "id": "OA-03-E1", "description": "committee_charter current version with executive-level approval signature and date, specifying membership composition, decision rights matrix, quorum requirements, and meeting cadence", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-03-E2", "description": "meeting_minutes for all scheduled quarterly sessions in the preceding 12-month period, demonstrating quorum was met and binding decisions were recorded with rationale", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-03-E3", "description": "decision_log showing AIGC approval records for all high-risk model deployments and risk appetite changes in the preceding 12 months, cross-referenced against the production model registry", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-03-E4", "description": "membership_roster with functional affiliations confirming representation from AI/ML engineering, model validation, legal/compliance, risk management, and at least one business line", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 Clause 5.3 (Organizational roles, responsibilities and authorities) requires top management to assign and communicate relevant roles and authorities. OA-03\u2019s chartered committee documents those authorities for AI model decisions." } ] }, { "requirement_id": "ISO42001-A.5.1", "section": "Annex A \u00a7A.5.1", "title": "Assessing impacts of AI systems \u2014 Impact assessment process", "text": "The organization shall establish and implement a process to assess the potential impacts of AI systems on individuals, groups, and society.", "verdict": "supported", "coverage": "direct", "notes": "Ethics impact assessment framework, fundamental rights impact assessment content governance, algorithmic bias impact assessment, and risk and applicability classification together define the AI impact assessment process.", "control_count": 4, "proof_chain": [ { "control": "apeiris://ethics/controls/EF-04", "id": "EF-04", "domain": "ethics", "name": "Ethics Impact Assessment Framework", "validation_objective": "Every AI system in the production inventory must have a completed Ethics Impact Assessment using the organization's documented methodology, producing a structured verdict from the approved verdict taxonomy before initial deployment and within the annual review cycle thereafter. Each EIA must include fairness metric results disaggregated by demographic group, data provenance documentation, and an explicit verdict mapped against the organization's Ethical Risk Appetite Statement tiers.", "blocking_effect": "blocks-deployment", "evidence_required": [ "ethics_impact_assessment document with methodology_version, completed_questionnaire, residual_risk_score, risk_appetite_tier mapping, and structured_verdict (approved / approved-with-conditions / deferred-pending-mitigation / blocked)", "fairness_metric_results_report showing model performance disaggregated by demographic group using at least two metrics (equalized odds, demographic parity, calibration, or individual fairness) as required by the EIA questionnaire", "eia_governance_approval_record showing verdict_issuer, ethics_officer_countersignature for high-risk systems, and approval_date confirmed before production deployment", "eia_registry entry for each production AI system with current_assessment_date and next_review_date within 12 months", "fundamental_rights_impact_assessment artifact for EU-deployed high-risk systems satisfying Art. 27 requirements, integrated into or attached to the EIA documentation package" ], "evidence": [ { "id": "EF-04-E1", "description": "ethics_impact_assessment document with methodology_version, completed_questionnaire, residual_risk_score, risk_appetite_tier mapping, and structured_verdict (approved / approved-with-conditions / deferred-pending-mitigation / blocked)", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EF-04-E2", "description": "fairness_metric_results_report showing model performance disaggregated by demographic group using at least two metrics (equalized odds, demographic parity, calibration, or individual fairness) as required by the EIA questionnaire", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-04-E3", "description": "eia_governance_approval_record showing verdict_issuer, ethics_officer_countersignature for high-risk systems, and approval_date confirmed before production deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-04-E4", "description": "eia_registry entry for each production AI system with current_assessment_date and next_review_date within 12 months", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-04-E5", "description": "fundamental_rights_impact_assessment artifact for EU-deployed high-risk systems satisfying Art. 27 requirements, integrated into or attached to the EIA documentation package", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001:2023 \u00a78.4 requires impact assessments for AI systems and \u00a79.1 requires performance evaluation against responsible AI objectives. The EIA methodology satisfies both by providing a structured pre-deployment and in-operation assessment process with documented verdicts." }, { "control": "apeiris://ethics/controls/HI-01", "id": "HI-01", "domain": "ethics", "name": "Fundamental Rights Impact Assessment Content Governance", "validation_objective": "Every high-risk AI system subject to EU AI Act Art. 27 must have a completed FRIA with explicit impact ratings for all relevant EU Charter rights (Art. 1-54), documented population-level analysis for each protected group in scope, and signed ethics officer and legal counsel approval before production authorization is issued. No Annex III system may enter production without satisfying this gate.", "blocking_effect": "blocks-deployment", "evidence_required": [ "completed_fria document per high-risk AI system with explicit impact ratings (none/low/moderate/high/critical) for each EU Charter article, population-level analysis for all protected groups in scope, and documented mitigation for each impact rated moderate or higher", "fria_signoff_record showing ethics officer and legal counsel reviewer names, dates, and explicit production authorization confirmation for each high-risk system", "fria_registry showing version-controlled FRIA history per system with initial assessment date, reassessment dates triggered by material changes, and current version status", "mitigation_closure_evidence linking each FRIA-identified mitigation commitment to its corresponding risk register entry and documented closure verification with timestamp", "deployment_gate_record confirming FRIA completion check was executed in the AI governance workflow and the gate was satisfied before production authorization was granted" ], "evidence": [ { "id": "HI-01-E1", "description": "completed_fria document per high-risk AI system with explicit impact ratings (none/low/moderate/high/critical) for each EU Charter article, population-level analysis for all protected groups in scope, and documented mitigation for each impact rated moderate or higher", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-01-E2", "description": "fria_signoff_record showing ethics officer and legal counsel reviewer names, dates, and explicit production authorization confirmation for each high-risk system", "evidence_type": "human-review-record", "verification": "human" }, { "id": "HI-01-E3", "description": "fria_registry showing version-controlled FRIA history per system with initial assessment date, reassessment dates triggered by material changes, and current version status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-01-E4", "description": "mitigation_closure_evidence linking each FRIA-identified mitigation commitment to its corresponding risk register entry and documented closure verification with timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-01-E5", "description": "deployment_gate_record confirming FRIA completion check was executed in the AI governance workflow and the gate was satisfied before production authorization was granted", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 \u00a76.1.2 requires organizations to identify and assess AI-related risks including impacts on fundamental rights and human values. FRIA completion and quality are auditable artifacts under ISO 42001 certification scope, linking rights assessment obligations to the management system framework." }, { "control": "apeiris://ethics/controls/FA-02", "id": "FA-02", "domain": "ethics", "name": "Algorithmic Bias Impact Assessment", "validation_objective": "Every AI system subject to fairness evaluation must have a completed Algorithmic Bias Impact Assessment (ABIA) covering all protected characteristics in the FA-01 register, addressing both training data composition bias and model prediction disparities, completed before initial deployment and re-run after any material model or data change.", "blocking_effect": "blocks-deployment", "evidence_required": [ "algorithmic_bias_impact_assessment_report with per-characteristic findings, methodology description, direct discrimination and disparate impact pathways assessed, and risk rating for each finding", "training_data_composition_report showing demographic representation across protected groups relative to the reference deployment population", "model_prediction_disaggregation_report showing predicted outcome rates by protected characteristic with confidence intervals and statistical significance testing", "feedback_loop_risk_analysis documenting whether biased model outputs could influence future training data collection or labeling", "abia_reviewer_sign_off_record with reviewer credentials and date confirming independence from the model development team" ], "evidence": [ { "id": "FA-02-E1", "description": "algorithmic_bias_impact_assessment_report with per-characteristic findings, methodology description, direct discrimination and disparate impact pathways assessed, and risk rating for each finding", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E2", "description": "training_data_composition_report showing demographic representation across protected groups relative to the reference deployment population", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E3", "description": "model_prediction_disaggregation_report showing predicted outcome rates by protected characteristic with confidence intervals and statistical significance testing", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E4", "description": "feedback_loop_risk_analysis documenting whether biased model outputs could influence future training data collection or labeling", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E5", "description": "abia_reviewer_sign_off_record with reviewer credentials and date confirming independence from the model development team", "evidence_type": "human-review-record", "verification": "human" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://model/controls/EV-09", "id": "EV-09", "domain": "model", "name": "Risk and Applicability Classification", "validation_objective": "Every model system has a signed classification record produced before any evaluation work begins, containing a documented EU AI Act classification with provision-specific rationale referencing Articles 5, 6, 50, 51, and Annex III as applicable, an SR 26-2 model risk tier for in-scope institutions, a capability tier, and the full applicable Apeiris profiles list; the model registry gate prevents advancement to evaluation stage without this record; and re-classification is triggered on any significant change to use case, capability level, or applicable regulation.", "blocking_effect": "blocks-deployment", "evidence_required": [ "signed_classification_record containing eu_ai_act_classification with specific provision references, sr_262_tier where applicable, capability_tier, applicable_profiles list, mandatory_controls inventory, and obligations_inventory \u2014 produced before any evaluation artifact is created", "classification_questionnaire_responses document answering all required dimensions: intended_use_cases, affected_populations, decision_automation_level, human_oversight_mechanisms, deployment_jurisdiction, compute_budget, parameter_count", "non_high_risk_exclusion_rationale for systems classified below high-risk, explicitly addressing each relevant Annex III category with documented rationale for exclusion", "classification_review_records for all re-classification events documenting trigger_event, prior_classification, new_classification, and rationale with effective_date", "iso_42005_impact_assessment for high-impact-decision and eu-high-risk profile systems per ISO/IEC 42005:2025" ], "evidence": [ { "id": "EV-09-E1", "description": "signed_classification_record containing eu_ai_act_classification with specific provision references, sr_262_tier where applicable, capability_tier, applicable_profiles list, mandatory_controls inventory, and obligations_inventory \u2014 produced before any evaluation artifact is created", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-09-E2", "description": "classification_questionnaire_responses document answering all required dimensions: intended_use_cases, affected_populations, decision_automation_level, human_oversight_mechanisms, deployment_jurisdiction, compute_budget, parameter_count", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E3", "description": "non_high_risk_exclusion_rationale for systems classified below high-risk, explicitly addressing each relevant Annex III category with documented rationale for exclusion", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E4", "description": "classification_review_records for all re-classification events documenting trigger_event, prior_classification, new_classification, and rationale with effective_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E5", "description": "iso_42005_impact_assessment for high-impact-decision and eu-high-risk profile systems per ISO/IEC 42005:2025", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO 42001 \u00a76.1 requires risk assessment including determination of the significance of identified risks; formal classification operationalizes this." } ] }, { "requirement_id": "ISO42001-A.5.2", "section": "Annex A \u00a7A.5.2", "title": "Assessing impacts of AI systems \u2014 Documentation of assessments", "text": "The organization shall document the results of AI impact assessments and retain this information as evidence.", "verdict": "partial", "coverage": "partial", "notes": "Ethics foundations evidence package, evaluation result provenance, and evidence collection controls support impact assessment documentation. Standardized impact assessment report formats and retention schedules are organizational process decisions.", "control_count": 3, "proof_chain": [ { "control": "apeiris://ethics/controls/EF-08", "id": "EF-08", "domain": "ethics", "name": "Ethics Foundations Evidence Package", "validation_objective": "The ethics governance evidence package must be complete, version-controlled, and retrievable within regulatory inquiry timelines, demonstrating that all EF-01 through EF-07 artifacts are current, co-located in a structured store, and have been reviewed within the past review cycle.", "blocking_effect": "blocks-deployment", "evidence_required": [ "ethics_evidence_package_manifest listing each constituent artifact (EF-01 through EF-07) with version, sha256_hash, artifact_owner, and last_reviewed_date", "version_control_history showing at least one complete revision cycle for the package with review sign-off in the trailing 12 months", "retrieval_test_record demonstrating the full package was assembled within the required retrieval time window (e.g., 24 hours) during a simulated audit exercise", "regulatory_submission_receipt or equivalent record confirming the package was delivered to an external auditor or regulator within the past review cycle" ], "evidence": [ { "id": "EF-08-E1", "description": "ethics_evidence_package_manifest listing each constituent artifact (EF-01 through EF-07) with version, sha256_hash, artifact_owner, and last_reviewed_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-08-E2", "description": "version_control_history showing at least one complete revision cycle for the package with review sign-off in the trailing 12 months", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EF-08-E3", "description": "retrieval_test_record demonstrating the full package was assembled within the required retrieval time window (e.g., 24 hours) during a simulated audit exercise", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-08-E4", "description": "regulatory_submission_receipt or equivalent record confirming the package was delivered to an external auditor or regulator within the past review cycle", "evidence_type": "third-party-audit-report", "verification": "third-party" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001:2023 \u00a77.5 requires that documented information required for the AI management system is controlled, maintained, and retained appropriately. \u00a79.2 requires that internal audits produce documented evidence of conformance. The EFEP is the primary controlled documentation artifact satisfying these requirements." }, { "control": "apeiris://model/controls/EV-10", "id": "EV-10", "domain": "model", "name": "Evaluation Result Provenance", "validation_objective": "Every evaluation result artifact is SHA-256 content-addressed, cryptographically signed with individually attributed non-repudiable key material, submitted to an append-only tamper-evident log with a recorded inclusion proof, and linked to the model artifact hash and evaluation suite hash such that the complete chain from model artifact to deployment decision is machine-verifiable; the deployment gate rejects any manifest where inclusion proof verification fails.", "blocking_effect": "blocks-deployment", "evidence_required": [ "signed_content_addressed_evaluation_result_artifacts for each run containing model_artifact_hash, eval_suite_id, eval_suite_version, eval_suite_hash, run_timestamp, environment_fingerprint, per_dimension_results, gate_determination, and signer_identity with key_identifier", "tamper_evident_log_inclusion_proofs for each signed evaluation result submission, with log_entry_id and inclusion_proof_bytes sufficient for independent verification", "provenance_chain_traversal_records demonstrating machine-verifiable linkage from model_artifact_hash through evaluation_result to deployment_manifest for each production model version", "signing_key_attribution_records mapping each signer_identity in evaluation artifacts to a named individual via PKI certificate or directory lookup, confirming no shared or service-account signing credentials were used", "retention_compliance_records confirming signed artifacts and inclusion proofs remain available for the required period covering the operational model lifetime plus the applicable regulatory minimum per jurisdiction" ], "evidence": [ { "id": "EV-10-E1", "description": "signed_content_addressed_evaluation_result_artifacts for each run containing model_artifact_hash, eval_suite_id, eval_suite_version, eval_suite_hash, run_timestamp, environment_fingerprint, per_dimension_results, gate_determination, and signer_identity with key_identifier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-10-E2", "description": "tamper_evident_log_inclusion_proofs for each signed evaluation result submission, with log_entry_id and inclusion_proof_bytes sufficient for independent verification", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-10-E3", "description": "provenance_chain_traversal_records demonstrating machine-verifiable linkage from model_artifact_hash through evaluation_result to deployment_manifest for each production model version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-10-E4", "description": "signing_key_attribution_records mapping each signer_identity in evaluation artifacts to a named individual via PKI certificate or directory lookup, confirming no shared or service-account signing credentials were used", "evidence_type": "certification", "verification": "third-party" }, { "id": "EV-10-E5", "description": "retention_compliance_records confirming signed artifacts and inclusion proofs remain available for the required period covering the operational model lifetime plus the applicable regulatory minimum per jurisdiction", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO 42001 \u00a77.5 requires documented information to be controlled, retained, and protected; tamper-evident, signed evaluation records operationalize this for evaluation artifacts." }, { "control": "apeiris://compliance/controls/AU-02", "id": "AU-02", "domain": "compliance", "name": "Evidence Collection, Curation, and Validation", "validation_objective": "Every compliance evidence artifact in the active evidence library has a SHA-256 hash computed at the moment of collection, a documented source_system and collector_identity, a collection_timestamp within the required freshness window for its artifact type, and has passed all validation gate checks prior to promotion. No artifact with missing or failed provenance metadata exists in the active library.", "blocking_effect": "advisory", "evidence_required": [ "Evidence repository ingestion log showing source_system, collector_identity, collection_timestamp, and SHA-256_hash computed at ingest for every artifact collected during the audit period", "Validation gate rejection log documenting all artifacts that failed validation checks, the specific failure reason (missing hash, staleness, format error, incomplete metadata), and their disposition", "Manual curation workflow records for artifacts that bypassed automated validation, including curator identity, review method, artifact authenticity basis, and sign-off timestamp", "Monthly reconciliation reports comparing the artifact inventory against per-framework requirements, identifying collection gaps by artifact type and their age in days", "SHA-256 hash integrity verification report for the audit period confirming no mismatches between ingestion records and current artifact content in the repository" ], "evidence": [ { "id": "AU-02-E1", "description": "Evidence repository ingestion log showing source_system, collector_identity, collection_timestamp, and SHA-256_hash computed at ingest for every artifact collected during the audit period", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AU-02-E2", "description": "Validation gate rejection log documenting all artifacts that failed validation checks, the specific failure reason (missing hash, staleness, format error, incomplete metadata), and their disposition", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AU-02-E3", "description": "Manual curation workflow records for artifacts that bypassed automated validation, including curator identity, review method, artifact authenticity basis, and sign-off timestamp", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "AU-02-E4", "description": "Monthly reconciliation reports comparing the artifact inventory against per-framework requirements, identifying collection gaps by artifact type and their age in days", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AU-02-E5", "description": "SHA-256 hash integrity verification report for the audit period confirming no mismatches between ingestion records and current artifact content in the repository", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "ISO42001-A.6.1", "section": "Annex A \u00a7A.6.1", "title": "AI system impact assessment \u2014 Conducting the assessment", "text": "The organization shall conduct AI system impact assessments considering the context of use, affected populations, potential harms, and mitigating controls.", "verdict": "supported", "coverage": "direct", "notes": "Ethics impact assessment framework, fundamental rights impact assessment, algorithmic bias impact assessment, risk classification, and vulnerable population protection controls collectively implement AI system impact assessment.", "control_count": 5, "proof_chain": [ { "control": "apeiris://ethics/controls/EF-04", "id": "EF-04", "domain": "ethics", "name": "Ethics Impact Assessment Framework", "validation_objective": "Every AI system in the production inventory must have a completed Ethics Impact Assessment using the organization's documented methodology, producing a structured verdict from the approved verdict taxonomy before initial deployment and within the annual review cycle thereafter. Each EIA must include fairness metric results disaggregated by demographic group, data provenance documentation, and an explicit verdict mapped against the organization's Ethical Risk Appetite Statement tiers.", "blocking_effect": "blocks-deployment", "evidence_required": [ "ethics_impact_assessment document with methodology_version, completed_questionnaire, residual_risk_score, risk_appetite_tier mapping, and structured_verdict (approved / approved-with-conditions / deferred-pending-mitigation / blocked)", "fairness_metric_results_report showing model performance disaggregated by demographic group using at least two metrics (equalized odds, demographic parity, calibration, or individual fairness) as required by the EIA questionnaire", "eia_governance_approval_record showing verdict_issuer, ethics_officer_countersignature for high-risk systems, and approval_date confirmed before production deployment", "eia_registry entry for each production AI system with current_assessment_date and next_review_date within 12 months", "fundamental_rights_impact_assessment artifact for EU-deployed high-risk systems satisfying Art. 27 requirements, integrated into or attached to the EIA documentation package" ], "evidence": [ { "id": "EF-04-E1", "description": "ethics_impact_assessment document with methodology_version, completed_questionnaire, residual_risk_score, risk_appetite_tier mapping, and structured_verdict (approved / approved-with-conditions / deferred-pending-mitigation / blocked)", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EF-04-E2", "description": "fairness_metric_results_report showing model performance disaggregated by demographic group using at least two metrics (equalized odds, demographic parity, calibration, or individual fairness) as required by the EIA questionnaire", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-04-E3", "description": "eia_governance_approval_record showing verdict_issuer, ethics_officer_countersignature for high-risk systems, and approval_date confirmed before production deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-04-E4", "description": "eia_registry entry for each production AI system with current_assessment_date and next_review_date within 12 months", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-04-E5", "description": "fundamental_rights_impact_assessment artifact for EU-deployed high-risk systems satisfying Art. 27 requirements, integrated into or attached to the EIA documentation package", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001:2023 \u00a78.4 requires impact assessments for AI systems and \u00a79.1 requires performance evaluation against responsible AI objectives. The EIA methodology satisfies both by providing a structured pre-deployment and in-operation assessment process with documented verdicts." }, { "control": "apeiris://ethics/controls/HI-01", "id": "HI-01", "domain": "ethics", "name": "Fundamental Rights Impact Assessment Content Governance", "validation_objective": "Every high-risk AI system subject to EU AI Act Art. 27 must have a completed FRIA with explicit impact ratings for all relevant EU Charter rights (Art. 1-54), documented population-level analysis for each protected group in scope, and signed ethics officer and legal counsel approval before production authorization is issued. No Annex III system may enter production without satisfying this gate.", "blocking_effect": "blocks-deployment", "evidence_required": [ "completed_fria document per high-risk AI system with explicit impact ratings (none/low/moderate/high/critical) for each EU Charter article, population-level analysis for all protected groups in scope, and documented mitigation for each impact rated moderate or higher", "fria_signoff_record showing ethics officer and legal counsel reviewer names, dates, and explicit production authorization confirmation for each high-risk system", "fria_registry showing version-controlled FRIA history per system with initial assessment date, reassessment dates triggered by material changes, and current version status", "mitigation_closure_evidence linking each FRIA-identified mitigation commitment to its corresponding risk register entry and documented closure verification with timestamp", "deployment_gate_record confirming FRIA completion check was executed in the AI governance workflow and the gate was satisfied before production authorization was granted" ], "evidence": [ { "id": "HI-01-E1", "description": "completed_fria document per high-risk AI system with explicit impact ratings (none/low/moderate/high/critical) for each EU Charter article, population-level analysis for all protected groups in scope, and documented mitigation for each impact rated moderate or higher", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-01-E2", "description": "fria_signoff_record showing ethics officer and legal counsel reviewer names, dates, and explicit production authorization confirmation for each high-risk system", "evidence_type": "human-review-record", "verification": "human" }, { "id": "HI-01-E3", "description": "fria_registry showing version-controlled FRIA history per system with initial assessment date, reassessment dates triggered by material changes, and current version status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-01-E4", "description": "mitigation_closure_evidence linking each FRIA-identified mitigation commitment to its corresponding risk register entry and documented closure verification with timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-01-E5", "description": "deployment_gate_record confirming FRIA completion check was executed in the AI governance workflow and the gate was satisfied before production authorization was granted", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 \u00a76.1.2 requires organizations to identify and assess AI-related risks including impacts on fundamental rights and human values. FRIA completion and quality are auditable artifacts under ISO 42001 certification scope, linking rights assessment obligations to the management system framework." }, { "control": "apeiris://ethics/controls/FA-02", "id": "FA-02", "domain": "ethics", "name": "Algorithmic Bias Impact Assessment", "validation_objective": "Every AI system subject to fairness evaluation must have a completed Algorithmic Bias Impact Assessment (ABIA) covering all protected characteristics in the FA-01 register, addressing both training data composition bias and model prediction disparities, completed before initial deployment and re-run after any material model or data change.", "blocking_effect": "blocks-deployment", "evidence_required": [ "algorithmic_bias_impact_assessment_report with per-characteristic findings, methodology description, direct discrimination and disparate impact pathways assessed, and risk rating for each finding", "training_data_composition_report showing demographic representation across protected groups relative to the reference deployment population", "model_prediction_disaggregation_report showing predicted outcome rates by protected characteristic with confidence intervals and statistical significance testing", "feedback_loop_risk_analysis documenting whether biased model outputs could influence future training data collection or labeling", "abia_reviewer_sign_off_record with reviewer credentials and date confirming independence from the model development team" ], "evidence": [ { "id": "FA-02-E1", "description": "algorithmic_bias_impact_assessment_report with per-characteristic findings, methodology description, direct discrimination and disparate impact pathways assessed, and risk rating for each finding", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E2", "description": "training_data_composition_report showing demographic representation across protected groups relative to the reference deployment population", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E3", "description": "model_prediction_disaggregation_report showing predicted outcome rates by protected characteristic with confidence intervals and statistical significance testing", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E4", "description": "feedback_loop_risk_analysis documenting whether biased model outputs could influence future training data collection or labeling", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E5", "description": "abia_reviewer_sign_off_record with reviewer credentials and date confirming independence from the model development team", "evidence_type": "human-review-record", "verification": "human" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://model/controls/EV-09", "id": "EV-09", "domain": "model", "name": "Risk and Applicability Classification", "validation_objective": "Every model system has a signed classification record produced before any evaluation work begins, containing a documented EU AI Act classification with provision-specific rationale referencing Articles 5, 6, 50, 51, and Annex III as applicable, an SR 26-2 model risk tier for in-scope institutions, a capability tier, and the full applicable Apeiris profiles list; the model registry gate prevents advancement to evaluation stage without this record; and re-classification is triggered on any significant change to use case, capability level, or applicable regulation.", "blocking_effect": "blocks-deployment", "evidence_required": [ "signed_classification_record containing eu_ai_act_classification with specific provision references, sr_262_tier where applicable, capability_tier, applicable_profiles list, mandatory_controls inventory, and obligations_inventory \u2014 produced before any evaluation artifact is created", "classification_questionnaire_responses document answering all required dimensions: intended_use_cases, affected_populations, decision_automation_level, human_oversight_mechanisms, deployment_jurisdiction, compute_budget, parameter_count", "non_high_risk_exclusion_rationale for systems classified below high-risk, explicitly addressing each relevant Annex III category with documented rationale for exclusion", "classification_review_records for all re-classification events documenting trigger_event, prior_classification, new_classification, and rationale with effective_date", "iso_42005_impact_assessment for high-impact-decision and eu-high-risk profile systems per ISO/IEC 42005:2025" ], "evidence": [ { "id": "EV-09-E1", "description": "signed_classification_record containing eu_ai_act_classification with specific provision references, sr_262_tier where applicable, capability_tier, applicable_profiles list, mandatory_controls inventory, and obligations_inventory \u2014 produced before any evaluation artifact is created", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-09-E2", "description": "classification_questionnaire_responses document answering all required dimensions: intended_use_cases, affected_populations, decision_automation_level, human_oversight_mechanisms, deployment_jurisdiction, compute_budget, parameter_count", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E3", "description": "non_high_risk_exclusion_rationale for systems classified below high-risk, explicitly addressing each relevant Annex III category with documented rationale for exclusion", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E4", "description": "classification_review_records for all re-classification events documenting trigger_event, prior_classification, new_classification, and rationale with effective_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E5", "description": "iso_42005_impact_assessment for high-impact-decision and eu-high-risk profile systems per ISO/IEC 42005:2025", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO 42001 \u00a76.1 requires risk assessment including determination of the significance of identified risks; formal classification operationalizes this." }, { "control": "apeiris://ethics/controls/HI-03", "id": "HI-03", "domain": "ethics", "name": "Vulnerable Population Protection", "validation_objective": "Every AI system in production must have a completed vulnerability impact screening record identifying which vulnerable population categories are in scope, their exposure frequency, and the resulting vulnerability risk score. All systems scoring above the defined threshold must have documented and verified enhanced safeguards implemented, and user testing results from representative vulnerable population participants must be on file prior to deployment and refreshed within 12 months.", "blocking_effect": "blocks-deployment", "evidence_required": [ "vulnerability_impact_screening_record per AI system listing all vulnerable population categories assessed, exposure frequency estimates, vulnerability risk score, and scoring rationale, with completion date before initial deployment", "enhanced_safeguard_implementation_record for each system scoring above the vulnerability risk threshold, documenting each required safeguard (simplified language options, WCAG 2.1 AA compliance, human review gates for high-stakes decisions, crisis detection and escalation pathways) with implementation verification evidence", "user_testing_results from sessions conducted with representative members of each identified vulnerable population category including comprehension scores, consent quality observations, and rights-exercise assessments", "model_performance_disaggregation_report showing evaluation metrics separately for each vulnerable population category with identified performance gaps and applied bias mitigation measures", "wcag_compliance_audit_report for all user-facing interfaces confirming WCAG 2.1 AA conformance or documenting known exceptions with assigned remediation timelines" ], "evidence": [ { "id": "HI-03-E1", "description": "vulnerability_impact_screening_record per AI system listing all vulnerable population categories assessed, exposure frequency estimates, vulnerability risk score, and scoring rationale, with completion date before initial deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-03-E2", "description": "enhanced_safeguard_implementation_record for each system scoring above the vulnerability risk threshold, documenting each required safeguard (simplified language options, WCAG 2.1 AA compliance, human review gates for high-stakes decisions, crisis detection and escalation pathways) with implementation verification evidence", "evidence_type": "human-review-record", "verification": "human" }, { "id": "HI-03-E3", "description": "user_testing_results from sessions conducted with representative members of each identified vulnerable population category including comprehension scores, consent quality observations, and rights-exercise assessments", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-03-E4", "description": "model_performance_disaggregation_report showing evaluation metrics separately for each vulnerable population category with identified performance gaps and applied bias mitigation measures", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "HI-03-E5", "description": "wcag_compliance_audit_report for all user-facing interfaces confirming WCAG 2.1 AA conformance or documenting known exceptions with assigned remediation timelines", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "ISO42001-A.7.1", "section": "Annex A \u00a7A.7.1", "title": "Human oversight \u2014 Oversight processes", "text": "The organization shall establish processes to ensure appropriate human oversight of AI systems, commensurate with the risk level of the AI system.", "verdict": "supported", "coverage": "direct", "notes": "Meaningful human oversight for high-stakes decisions, human-in-the-loop gates, human oversight and override mechanisms, human hard-stop for irreversible actions, and delegated autonomy tier governance implement risk-commensurate human oversight processes.", "control_count": 5, "proof_chain": [ { "control": "apeiris://model/controls/OA-02", "id": "OA-02", "domain": "model", "name": "Meaningful Human Oversight for High-Stakes Decisions", "validation_objective": "For every high-impact-decision or eu-high-risk model, a human reviewer must have documented access to model inputs, confidence scores, and reasoning; organizational authority to override without penalty; domain competence verified through training records; and a technically effective override mechanism before any AI output takes effect. Override rates must be monitored and a rate near zero for 30 consecutive days must automatically trigger a governance review.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "five_factor_oversight_design_document per high-stakes use case, signed by the AI governance committee, covering: review time allocation, information display design, override authority documentation, competence requirements, and override mechanism technical specification", "override_rate_time_series report for the past 12 months broken down by model, decision type, and reviewer cohort \u2014 with governance-defined floor thresholds annotated", "reviewer_training_completion_record including initial onboarding completion date, annual recertification dates, competence assessment scores, and automation-bias module completion", "override_mechanism_test_log confirming that override actions propagate correctly through downstream systems without requiring secondary approval" ], "evidence": [ { "id": "OA-02-E1", "description": "five_factor_oversight_design_document per high-stakes use case, signed by the AI governance committee, covering: review time allocation, information display design, override authority documentation, competence requirements, and override mechanism technical specification", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-02-E2", "description": "override_rate_time_series report for the past 12 months broken down by model, decision type, and reviewer cohort \u2014 with governance-defined floor thresholds annotated", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-02-E3", "description": "reviewer_training_completion_record including initial onboarding completion date, annual recertification dates, competence assessment scores, and automation-bias module completion", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-02-E4", "description": "override_mechanism_test_log confirming that override actions propagate correctly through downstream systems without requiring secondary approval", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO 42001 requires controls for human oversight of AI systems in high-risk contexts." }, { "control": "apeiris://agentic/controls/AO-04", "id": "AO-04", "domain": "agentic", "name": "Human-in-the-Loop Gates for High-Consequence Orchestrations", "validation_objective": "Proves that every orchestration pipeline classified as irreversible-write or regulated-action contains at least one mandatory human approval gate that blocks execution until an authorized reviewer explicitly approves continuation, and that pipelines self-terminate (not auto-approve) when the gate timeout is reached without reviewer action. No irreversible or regulated pipeline action may be executed without a logged, attributed human approval decision.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "Consequence taxonomy documentation mapping all production pipeline action types to classification levels, with legal or compliance sign-off for regulated-action classifications", "Gate activation and approval records for a representative sample of high-consequence pipeline executions, each containing reviewer identity, decision, rationale, and timestamp", "Gate timeout self-termination test records confirming pipelines terminate (not auto-approve) when reviewer action is not received within the defined window", "Gate bypass incident log for the prior 12 months showing zero unauthorized bypass events, or incident records for any that occurred", "Sample reviewer decision packages confirming they present action description, predicted consequence, confidence estimate, and rollback feasibility to the reviewer" ], "evidence": [ { "id": "AO-04-E1", "description": "Consequence taxonomy documentation mapping all production pipeline action types to classification levels, with legal or compliance sign-off for regulated-action classifications", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AO-04-E2", "description": "Gate activation and approval records for a representative sample of high-consequence pipeline executions, each containing reviewer identity, decision, rationale, and timestamp", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AO-04-E3", "description": "Gate timeout self-termination test records confirming pipelines terminate (not auto-approve) when reviewer action is not received within the defined window", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "AO-04-E4", "description": "Gate bypass incident log for the prior 12 months showing zero unauthorized bypass events, or incident records for any that occurred", "evidence_type": "incident-record", "verification": "attested" }, { "id": "AO-04-E5", "description": "Sample reviewer decision packages confirming they present action description, predicted consequence, confidence estimate, and rollback feasibility to the reviewer", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO 42001 \u00a79.1 requires organizations to monitor and measure AI system impact, including the consequences of AI decisions. Human-in-the-loop gates create structured intervention points that support the monitoring and control objectives of \u00a79.1." }, { "control": "apeiris://ethics/controls/HI-04", "id": "HI-04", "domain": "ethics", "name": "Human Oversight and Override Mechanisms", "validation_objective": "All AI systems classified as significant or critical consequentiality tier must have override logging implemented and producing verifiable disposition records for every AI recommendation reviewed by a human operator. Override rate monitoring must be active and generating alerts when rates fall below defined thresholds, and every alert must trigger a documented review response within 30 days.", "blocking_effect": "blocks-deployment", "evidence_required": [ "consequentiality_tier_classification_record for every production AI system documenting the assigned tier (advisory/significant/critical), classification rationale, and mandatory oversight requirements that tier triggers", "override_audit_log for significant and critical tier systems showing AI recommendations, human dispositions (accepted/modified/rejected), override rationale where provided, and timestamps covering the prior 90 days", "override_rate_monitoring_report showing per-system trend data, defined threshold levels, alerts triggered in the prior 12 months, and documented investigation responses with completion dates", "interface_design_review_record confirming evaluation of the AI decision interface against automation-bias-avoidance criteria: confidence levels displayed, uncertainty ranges shown, override pathway accessible without additional navigation, AI-generated content distinguished from operator-entered content", "human_overseer_assignment_record naming the qualified overseer role for each significant and critical tier AI system with accountability documentation and training evidence" ], "evidence": [ { "id": "HI-04-E1", "description": "consequentiality_tier_classification_record for every production AI system documenting the assigned tier (advisory/significant/critical), classification rationale, and mandatory oversight requirements that tier triggers", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-04-E2", "description": "override_audit_log for significant and critical tier systems showing AI recommendations, human dispositions (accepted/modified/rejected), override rationale where provided, and timestamps covering the prior 90 days", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-04-E3", "description": "override_rate_monitoring_report showing per-system trend data, defined threshold levels, alerts triggered in the prior 12 months, and documented investigation responses with completion dates", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "HI-04-E4", "description": "interface_design_review_record confirming evaluation of the AI decision interface against automation-bias-avoidance criteria: confidence levels displayed, uncertainty ranges shown, override pathway accessible without additional navigation, AI-generated content distinguished from operator-entered content", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "HI-04-E5", "description": "human_overseer_assignment_record naming the qualified overseer role for each significant and critical tier AI system with accountability documentation and training evidence", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 \u00a78.4 requires operational controls for AI systems to include human oversight mechanisms appropriate to the system's risk level. The control's consequentiality tier framework maps directly to this proportionality requirement." }, { "control": "apeiris://security/controls/GV-01", "id": "GV-01", "domain": "security", "name": "Require a human hard-stop for irreversible actions", "validation_objective": "Every irreversible agent action (write, deletion, transfer, deployment, or any action with no safe undo path) must be deterministically halted and routed to an explicit human (or quorum) approval before execution; the agent must not be capable of self-approving such actions, and the hard-stop must be enforced at platform infrastructure level, not by a model-layer instruction.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "irreversible_action_approval_record linking each halted action to the human approver(s), approval_token with timestamp and cryptographic signature, and action outcome (executed/cancelled)", "irreversibility_classification_list identifying which action types are classified as irreversible, with the policy_version and last_review_date", "hard_stop_enforcement_log showing agent execution was suspended at the irreversible action gate and resumed only after receipt of a valid external approval token", "self_approval_rejection_log confirming any attempt by the agent to approve its own irreversible actions was blocked by the platform", "quorum_policy_record for high-stakes action categories specifying minimum required approvers and approval token validity window" ], "evidence": [ { "id": "GV-01-E1", "description": "irreversible_action_approval_record linking each halted action to the human approver(s), approval_token with timestamp and cryptographic signature, and action outcome (executed/cancelled)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-01-E2", "description": "irreversibility_classification_list identifying which action types are classified as irreversible, with the policy_version and last_review_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-01-E3", "description": "hard_stop_enforcement_log showing agent execution was suspended at the irreversible action gate and resumed only after receipt of a valid external approval token", "evidence_type": "human-review-record", "verification": "human" }, { "id": "GV-01-E4", "description": "self_approval_rejection_log confirming any attempt by the agent to approve its own irreversible actions was blocked by the platform", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-01-E5", "description": "quorum_policy_record for high-stakes action categories specifying minimum required approvers and approval token validity window", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "adjacent", "basis": "anchored", "relation": "equivalent_to", "rationale": null }, { "control": "apeiris://model/controls/OA-04", "id": "OA-04", "domain": "model", "name": "Delegated Autonomy Tier Governance", "validation_objective": "Every AI model or agent in the production registry must have an explicitly documented autonomy tier assignment sourced from the Security Verifier domain taxonomy, with AIGC approval records present for all Tier 3 and above assignments, and evaluation evidence requirements calibrated to the assigned tier. No model may take actions outside its tier-permitted scope without triggering an escalation event.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_register_extract showing autonomy_tier field populated for every production model, with reference to the Security Verifier tier taxonomy version in use", "aigc_approval_records for all Tier 3 and above tier assignments, including the date, voting outcome, and risk rationale", "tier_assignment_artifact (tier_assignment_{model_id}_{version}.json) consumed from Security Verifier domain for each model, confirming cross-domain provenance", "evaluation_requirement_lookup_table mapping each tier level to specific evidence requirements, with version date and approval signature from model governance committee" ], "evidence": [ { "id": "OA-04-E1", "description": "model_register_extract showing autonomy_tier field populated for every production model, with reference to the Security Verifier tier taxonomy version in use", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-04-E2", "description": "aigc_approval_records for all Tier 3 and above tier assignments, including the date, voting outcome, and risk rationale", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-04-E3", "description": "tier_assignment_artifact (tier_assignment_{model_id}_{version}.json) consumed from Security Verifier domain for each model, confirming cross-domain provenance", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "OA-04-E4", "description": "evaluation_requirement_lookup_table mapping each tier level to specific evidence requirements, with version date and approval signature from model governance committee", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO 42001 requires risk classification and proportionate controls." } ] }, { "requirement_id": "ISO42001-A.7.2", "section": "Annex A \u00a7A.7.2", "title": "Human oversight \u2014 Human intervention capability", "text": "The organization shall ensure that AI systems provide the capability for human intervention, including the ability to pause, override, or shut down the AI system.", "verdict": "supported", "coverage": "direct", "notes": "Human hard-stop for irreversible actions, human oversight and override mechanisms, real-time alerting and automated agent suspension, immutable version control with tested rollback and emergency disable, and remedy and redress mechanisms together implement human intervention capability.", "control_count": 5, "proof_chain": [ { "control": "apeiris://security/controls/GV-01", "id": "GV-01", "domain": "security", "name": "Require a human hard-stop for irreversible actions", "validation_objective": "Every irreversible agent action (write, deletion, transfer, deployment, or any action with no safe undo path) must be deterministically halted and routed to an explicit human (or quorum) approval before execution; the agent must not be capable of self-approving such actions, and the hard-stop must be enforced at platform infrastructure level, not by a model-layer instruction.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "irreversible_action_approval_record linking each halted action to the human approver(s), approval_token with timestamp and cryptographic signature, and action outcome (executed/cancelled)", "irreversibility_classification_list identifying which action types are classified as irreversible, with the policy_version and last_review_date", "hard_stop_enforcement_log showing agent execution was suspended at the irreversible action gate and resumed only after receipt of a valid external approval token", "self_approval_rejection_log confirming any attempt by the agent to approve its own irreversible actions was blocked by the platform", "quorum_policy_record for high-stakes action categories specifying minimum required approvers and approval token validity window" ], "evidence": [ { "id": "GV-01-E1", "description": "irreversible_action_approval_record linking each halted action to the human approver(s), approval_token with timestamp and cryptographic signature, and action outcome (executed/cancelled)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-01-E2", "description": "irreversibility_classification_list identifying which action types are classified as irreversible, with the policy_version and last_review_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-01-E3", "description": "hard_stop_enforcement_log showing agent execution was suspended at the irreversible action gate and resumed only after receipt of a valid external approval token", "evidence_type": "human-review-record", "verification": "human" }, { "id": "GV-01-E4", "description": "self_approval_rejection_log confirming any attempt by the agent to approve its own irreversible actions was blocked by the platform", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-01-E5", "description": "quorum_policy_record for high-stakes action categories specifying minimum required approvers and approval token validity window", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "adjacent", "basis": "anchored", "relation": "equivalent_to", "rationale": null }, { "control": "apeiris://ethics/controls/HI-04", "id": "HI-04", "domain": "ethics", "name": "Human Oversight and Override Mechanisms", "validation_objective": "All AI systems classified as significant or critical consequentiality tier must have override logging implemented and producing verifiable disposition records for every AI recommendation reviewed by a human operator. Override rate monitoring must be active and generating alerts when rates fall below defined thresholds, and every alert must trigger a documented review response within 30 days.", "blocking_effect": "blocks-deployment", "evidence_required": [ "consequentiality_tier_classification_record for every production AI system documenting the assigned tier (advisory/significant/critical), classification rationale, and mandatory oversight requirements that tier triggers", "override_audit_log for significant and critical tier systems showing AI recommendations, human dispositions (accepted/modified/rejected), override rationale where provided, and timestamps covering the prior 90 days", "override_rate_monitoring_report showing per-system trend data, defined threshold levels, alerts triggered in the prior 12 months, and documented investigation responses with completion dates", "interface_design_review_record confirming evaluation of the AI decision interface against automation-bias-avoidance criteria: confidence levels displayed, uncertainty ranges shown, override pathway accessible without additional navigation, AI-generated content distinguished from operator-entered content", "human_overseer_assignment_record naming the qualified overseer role for each significant and critical tier AI system with accountability documentation and training evidence" ], "evidence": [ { "id": "HI-04-E1", "description": "consequentiality_tier_classification_record for every production AI system documenting the assigned tier (advisory/significant/critical), classification rationale, and mandatory oversight requirements that tier triggers", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-04-E2", "description": "override_audit_log for significant and critical tier systems showing AI recommendations, human dispositions (accepted/modified/rejected), override rationale where provided, and timestamps covering the prior 90 days", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-04-E3", "description": "override_rate_monitoring_report showing per-system trend data, defined threshold levels, alerts triggered in the prior 12 months, and documented investigation responses with completion dates", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "HI-04-E4", "description": "interface_design_review_record confirming evaluation of the AI decision interface against automation-bias-avoidance criteria: confidence levels displayed, uncertainty ranges shown, override pathway accessible without additional navigation, AI-generated content distinguished from operator-entered content", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "HI-04-E5", "description": "human_overseer_assignment_record naming the qualified overseer role for each significant and critical tier AI system with accountability documentation and training evidence", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 \u00a78.4 requires operational controls for AI systems to include human oversight mechanisms appropriate to the system's risk level. The control's consequentiality tier framework maps directly to this proportionality requirement." }, { "control": "apeiris://agentic/controls/AM-07", "id": "AM-07", "domain": "agentic", "name": "Real-Time Alerting and Automated Agent Suspension", "validation_objective": "Prove that the enterprise has implemented a four-tier alert escalation model for agent behavioral violations and that automated suspension is capable of halting an offending agent within 60 seconds of a critical trigger while preserving session state for forensic review. Validate that reinstatement requires documented human authorization.", "blocking_effect": "advisory", "evidence_required": [ "Documented four-tier alert tier definitions with explicit trigger conditions (threshold values or violation patterns), SLAs, and escalation paths for tiers 3 and 4", "On-call pager integration configuration confirming tier-3 and tier-4 alerts route to the security team with SLA clock activation", "Most recent suspension exercise record demonstrating the full suspension-to-reinstatement path was tested in a live or near-production environment, not only in tabletop", "Quarterly alert effectiveness review report documenting false positive rates by tier and threshold tuning decisions made during the review period" ], "evidence": [ { "id": "AM-07-E1", "description": "Documented four-tier alert tier definitions with explicit trigger conditions (threshold values or violation patterns), SLAs, and escalation paths for tiers 3 and 4", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "AM-07-E2", "description": "On-call pager integration configuration confirming tier-3 and tier-4 alerts route to the security team with SLA clock activation", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "AM-07-E3", "description": "Most recent suspension exercise record demonstrating the full suspension-to-reinstatement path was tested in a live or near-production environment, not only in tabletop", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AM-07-E4", "description": "Quarterly alert effectiveness review report documenting false positive rates by tier and threshold tuning decisions made during the review period", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 \u00a710.2 requires organizations to react to nonconformities, control and correct them, and deal with consequences. Automated agent suspension is the operational implementation of 'control and correct' for behavioral violations, executed at machine speed with human-authorized reinstatement." }, { "control": "apeiris://model/controls/LI-06", "id": "LI-06", "domain": "model", "name": "Immutable Version Control with Tested Rollback and Emergency Disable", "validation_objective": "Every production model deployment must use an append-only model registry where no existing version entry can be overwritten or deleted; each version transition must be recorded in an immutable deployment log with source hash, destination hash, timestamp, and authorizing identity; rollback to any prior approved version must be tested and documented at least quarterly with measured rollback time; and the emergency disable mechanism must operate independently of the CI/CD pipeline and be exercisable by on-call personnel within the defined SLA.", "blocking_effect": "blocks-deployment", "evidence_required": [ "immutable_deployment_log with append-only version transition entries recording source artifact hash, destination artifact hash, timestamp, and authorizing identity for each production version change", "quarterly_rollback_test_record including model ID, prior version artifact hash, measured rollback time, and pass/fail outcome, with at least one record per production model dated within the last 90 days", "emergency_disable_test_record documenting the activation path, time from trigger to complete suspension of model serving, and explicit confirmation that the disable did not require access to CI/CD pipeline credentials", "version_drift_monitoring_alert_record demonstrating that a hash mismatch between the serving artifact and the registry entry triggered an alert within the monitoring window defined in the monitoring schema" ], "evidence": [ { "id": "LI-06-E1", "description": "immutable_deployment_log with append-only version transition entries recording source artifact hash, destination artifact hash, timestamp, and authorizing identity for each production version change", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-06-E2", "description": "quarterly_rollback_test_record including model ID, prior version artifact hash, measured rollback time, and pass/fail outcome, with at least one record per production model dated within the last 90 days", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-06-E3", "description": "emergency_disable_test_record documenting the activation path, time from trigger to complete suspension of model serving, and explicit confirmation that the disable did not require access to CI/CD pipeline credentials", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "LI-06-E4", "description": "version_drift_monitoring_alert_record demonstrating that a hash mismatch between the serving artifact and the registry entry triggered an alert within the monitoring window defined in the monitoring schema", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 Clause 6.3 (Planning of changes) requires changes to the AI management system and its systems to be carried out in a planned manner. LI-06\u2019s append-only versioning, authorization gates, and tested rollback give model changes that planned, reversible pathway." }, { "control": "apeiris://ethics/controls/HI-05", "id": "HI-05", "domain": "ethics", "name": "Remedy and Redress Mechanisms", "validation_objective": "The AI system must have an accessible, multi-tier challenge and remedy mechanism for every consequential decision, with documented human reviewers holding authority to reverse AI decisions, SLA-bound response times, and a case management system tracking all challenges to resolution. A passing state requires zero consequential AI systems without a discoverable challenge mechanism and human-review SLA compliance rates at or above 95%.", "blocking_effect": "requires-review", "evidence_required": [ "remedy_mechanism_accessibility_report confirming WCAG 2.1 AA compliance and discoverability for each consequential AI system, including mechanism location within the decision communication and accessibility test results", "case_management_system_export showing all challenges in the past 90 days with fields for intake_timestamp, challenge_basis, reviewer_id, resolution_timestamp, and remedy_outcome \u2014 no null values permitted", "human_reviewer_authorization_record documenting each reviewer's qualifications, organizational independence from the original AI decision process, and formal grant of decision-reversal authority", "SLA_compliance_report showing human review response times against tier-specific commitments, segmented by decision severity tier, covering the most recent 12-month period", "root_cause_analysis_record for each challenge volume spike exceeding the defined threshold, identifying the systemic AI error driving elevated complaints and documenting the remediation action taken" ], "evidence": [ { "id": "HI-05-E1", "description": "remedy_mechanism_accessibility_report confirming WCAG 2.1 AA compliance and discoverability for each consequential AI system, including mechanism location within the decision communication and accessibility test results", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "HI-05-E2", "description": "case_management_system_export showing all challenges in the past 90 days with fields for intake_timestamp, challenge_basis, reviewer_id, resolution_timestamp, and remedy_outcome \u2014 no null values permitted", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-05-E3", "description": "human_reviewer_authorization_record documenting each reviewer's qualifications, organizational independence from the original AI decision process, and formal grant of decision-reversal authority", "evidence_type": "human-review-record", "verification": "human" }, { "id": "HI-05-E4", "description": "SLA_compliance_report showing human review response times against tier-specific commitments, segmented by decision severity tier, covering the most recent 12-month period", "evidence_type": "human-review-record", "verification": "human" }, { "id": "HI-05-E5", "description": "root_cause_analysis_record for each challenge volume spike exceeding the defined threshold, identifying the systemic AI error driving elevated complaints and documenting the remediation action taken", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 \u00a79.1 requires monitoring and measurement of AI system performance, including tracking of complaints and incidents. The case management system and root-cause analysis protocols in this control implement the performance monitoring and improvement requirements of the standard." } ] }, { "requirement_id": "ISO42001-A.8.1", "section": "Annex A \u00a7A.8.1", "title": "AI system life cycle \u2014 Requirements and design", "text": "The organization shall establish requirements for AI systems prior to design and development, taking into account intended use, operating environment, and applicable constraints.", "verdict": "supported", "coverage": "direct", "notes": "Structured model documentation (model card with all required sections), capability and limitation declaration, risk and applicability classification, and operating intent declaration address pre-design requirements specification.", "control_count": 4, "proof_chain": [ { "control": "apeiris://model/controls/LI-04", "id": "LI-04", "domain": "model", "name": "Structured Model Documentation \u2014 Complete Model Card with All Required Sections", "validation_objective": "Every model submitted for registration must have a schema-validated model card with all nine Mitchell et al. 2019 sections substantively populated and passing field-level validation rules; the model card must be version-locked to the artifact hash and returned as structured metadata from the registry API; and registration must be blocked when any required section is absent, empty, or contains only placeholder text.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_card_completeness_validation_report showing pass/fail status per section with field-level validation results, registration blocking decision, and validation timestamp for the current artifact version", "versioned_model_card artifact linked to the specific model artifact hash with all nine Mitchell et al. sections containing substantive content (not placeholder text), retrievable from the registry by artifact hash", "model_registry_entry showing the current model card version hash stored alongside the artifact hash as paired immutable fields", "eu_ai_act_annex_iv_supplemental_record for EU AI Act high-risk in-scope systems confirming Annex IV technical documentation fields are populated in addition to the nine Mitchell et al. sections" ], "evidence": [ { "id": "LI-04-E1", "description": "model_card_completeness_validation_report showing pass/fail status per section with field-level validation results, registration blocking decision, and validation timestamp for the current artifact version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-04-E2", "description": "versioned_model_card artifact linked to the specific model artifact hash with all nine Mitchell et al. sections containing substantive content (not placeholder text), retrievable from the registry by artifact hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-04-E3", "description": "model_registry_entry showing the current model card version hash stored alongside the artifact hash as paired immutable fields", "evidence_type": "model-card", "verification": "attested" }, { "id": "LI-04-E4", "description": "eu_ai_act_annex_iv_supplemental_record for EU AI Act high-risk in-scope systems confirming Annex IV technical documentation fields are populated in addition to the nine Mitchell et al. sections", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 A.6.2.3 (Documentation of AI system design and development) requires documented design and development information. A complete, versioned model card linked to each release satisfies that documentation requirement for models." }, { "control": "apeiris://model/controls/LI-07", "id": "LI-07", "domain": "model", "name": "Capability and Limitation Declaration \u2014 Intended Use, Constraints,...", "validation_objective": "Every registered model must have a structured, schema-validated capability-limitation declaration with all five required dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, and knowledge_cutoff) substantively populated with population- and context-qualified entries, returned as structured metadata in the model registry API response; registration must be blocked when any dimension is absent or empty; and the model's observable behavior for post-knowledge-cutoff queries must be consistent with the declared uncertainty_bounds.", "blocking_effect": "blocks-deployment", "evidence_required": [ "capability_limitation_declaration with all five dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, knowledge_cutoff) substantively populated with population-qualified and context-qualified entries, version-locked to the artifact hash", "registry_api_response_sample demonstrating that the capability_limitation_declaration object is returned as structured metadata in the model registry API response for the model's registered ID without requiring separate documentation lookup", "cutoff_behavior_test_result showing model responses to at least three post-knowledge-cutoff factual queries compared against the declared uncertainty_bounds, confirming the model acknowledges the limitation rather than confabulating confident answers", "registration_rejection_log showing that a model registration attempt with an empty out_of_scope_uses field was blocked with an error identifying the specific missing dimension" ], "evidence": [ { "id": "LI-07-E1", "description": "capability_limitation_declaration with all five dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, knowledge_cutoff) substantively populated with population-qualified and context-qualified entries, version-locked to the artifact hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E2", "description": "registry_api_response_sample demonstrating that the capability_limitation_declaration object is returned as structured metadata in the model registry API response for the model's registered ID without requiring separate documentation lookup", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E3", "description": "cutoff_behavior_test_result showing model responses to at least three post-knowledge-cutoff factual queries compared against the declared uncertainty_bounds, confirming the model acknowledges the limitation rather than confabulating confident answers", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E4", "description": "registration_rejection_log showing that a model registration attempt with an empty out_of_scope_uses field was blocked with an error identifying the specific missing dimension", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 A.9.4 (Intended use of the AI system) requires that systems be used according to their intended, documented use. LI-07\u2019s capability and limitation declaration \u2014 intended_uses, out-of-scope uses, and knowledge cutoff \u2014 is the artifact that makes intended use enforceable." }, { "control": "apeiris://model/controls/EV-09", "id": "EV-09", "domain": "model", "name": "Risk and Applicability Classification", "validation_objective": "Every model system has a signed classification record produced before any evaluation work begins, containing a documented EU AI Act classification with provision-specific rationale referencing Articles 5, 6, 50, 51, and Annex III as applicable, an SR 26-2 model risk tier for in-scope institutions, a capability tier, and the full applicable Apeiris profiles list; the model registry gate prevents advancement to evaluation stage without this record; and re-classification is triggered on any significant change to use case, capability level, or applicable regulation.", "blocking_effect": "blocks-deployment", "evidence_required": [ "signed_classification_record containing eu_ai_act_classification with specific provision references, sr_262_tier where applicable, capability_tier, applicable_profiles list, mandatory_controls inventory, and obligations_inventory \u2014 produced before any evaluation artifact is created", "classification_questionnaire_responses document answering all required dimensions: intended_use_cases, affected_populations, decision_automation_level, human_oversight_mechanisms, deployment_jurisdiction, compute_budget, parameter_count", "non_high_risk_exclusion_rationale for systems classified below high-risk, explicitly addressing each relevant Annex III category with documented rationale for exclusion", "classification_review_records for all re-classification events documenting trigger_event, prior_classification, new_classification, and rationale with effective_date", "iso_42005_impact_assessment for high-impact-decision and eu-high-risk profile systems per ISO/IEC 42005:2025" ], "evidence": [ { "id": "EV-09-E1", "description": "signed_classification_record containing eu_ai_act_classification with specific provision references, sr_262_tier where applicable, capability_tier, applicable_profiles list, mandatory_controls inventory, and obligations_inventory \u2014 produced before any evaluation artifact is created", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-09-E2", "description": "classification_questionnaire_responses document answering all required dimensions: intended_use_cases, affected_populations, decision_automation_level, human_oversight_mechanisms, deployment_jurisdiction, compute_budget, parameter_count", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E3", "description": "non_high_risk_exclusion_rationale for systems classified below high-risk, explicitly addressing each relevant Annex III category with documented rationale for exclusion", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E4", "description": "classification_review_records for all re-classification events documenting trigger_event, prior_classification, new_classification, and rationale with effective_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E5", "description": "iso_42005_impact_assessment for high-impact-decision and eu-high-risk profile systems per ISO/IEC 42005:2025", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO 42001 \u00a76.1 requires risk assessment including determination of the significance of identified risks; formal classification operationalizes this." }, { "control": "apeiris://authority/controls/PV-01", "id": "PV-01", "domain": "authority", "name": "Operating Intent Declaration", "validation_objective": "Every active AI system deployment must have a machine-readable, cryptographically signed intent declaration registered in the authority control registry before production activation. The deployment pipeline must block agent activation when no valid, unexpired declaration with all required schema fields is present.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Signed intent declaration artifact with canonical_id, authorized_action_types, context_scope, principal_id, valid_from, and valid_until fields for every active AI deployment", "Deployment gate rejection logs demonstrating that agent activations without a registered, unexpired declaration were blocked, with fields for system_id, attempted_at, and rejection_reason", "Authority control registry export cross-referencing each active deployment to its current declaration record and cryptographic signature", "Principal authorization verification record confirming the signing identity has organizational authority to bind the enterprise to the declared scope", "Renewal audit trail linking declaration version history to deployment lifecycle events and authorizing principal identity" ], "evidence": [ { "id": "PV-01-E1", "description": "Signed intent declaration artifact with canonical_id, authorized_action_types, context_scope, principal_id, valid_from, and valid_until fields for every active AI deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PV-01-E2", "description": "Deployment gate rejection logs demonstrating that agent activations without a registered, unexpired declaration were blocked, with fields for system_id, attempted_at, and rejection_reason", "evidence_type": "audit-log", "verification": "automated" }, { "id": "PV-01-E3", "description": "Authority control registry export cross-referencing each active deployment to its current declaration record and cryptographic signature", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "PV-01-E4", "description": "Principal authorization verification record confirming the signing identity has organizational authority to bind the enterprise to the declared scope", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PV-01-E5", "description": "Renewal audit trail linking declaration version history to deployment lifecycle events and authorizing principal identity", "evidence_type": "audit-log", "verification": "automated" } ], "fit": "adjacent", "basis": "anchored", "relation": "equivalent_to", "rationale": "Declaring authorized scope anchors authority but is not itself a risk-treatment action under \u00a76.1." } ] }, { "requirement_id": "ISO42001-A.8.2", "section": "Annex A \u00a7A.8.2", "title": "AI system life cycle \u2014 Data management", "text": "The organization shall establish and implement controls for the acquisition, preparation, and management of data used in AI systems, including data quality, provenance, and lifecycle management.", "verdict": "supported", "coverage": "direct", "notes": "Training data quality gates, data rights and lawful authority, train/evaluation/test separation, third-party dataset governance, dataset retention and lifecycle, and training data lineage pointer together constitute comprehensive AI data management controls.", "control_count": 6, "proof_chain": [ { "control": "apeiris://model/controls/TG-01", "id": "TG-01", "domain": "model", "name": "Training Data Quality Gates", "validation_objective": "No training run may be initiated unless the designated training dataset has passed automated schema validation, completeness checks, and provenance verification in the current pipeline run; all gate results must be logged with pass/fail status and linked to the training job record.", "blocking_effect": "blocks-deployment", "evidence_required": [ "training_data_quality_gate_report for the current training run showing schema validation results (expected vs. actual field types and cardinalities), completeness check results (null rates, minimum coverage thresholds), and provenance verification status (source hash match, chain-of-custody record reference)", "training_pipeline_block_log confirming that any training attempt that failed a quality gate was rejected before the training compute job was allocated", "dataset_provenance_record with source identifier, ingestion timestamp, data owner, and integrity hash for each training shard used in the run", "quality_threshold_configuration_document defining the pass/fail thresholds for schema validation, completeness, and provenance checks, reviewed and approved by the ML engineering lead" ], "evidence": [ { "id": "TG-01-E1", "description": "training_data_quality_gate_report for the current training run showing schema validation results (expected vs. actual field types and cardinalities), completeness check results (null rates, minimum coverage thresholds), and provenance verification status (source hash match, chain-of-custody record reference)", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "TG-01-E2", "description": "training_pipeline_block_log confirming that any training attempt that failed a quality gate was rejected before the training compute job was allocated", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-01-E3", "description": "dataset_provenance_record with source identifier, ingestion timestamp, data owner, and integrity hash for each training shard used in the run", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-01-E4", "description": "quality_threshold_configuration_document defining the pass/fail thresholds for schema validation, completeness, and provenance checks, reviewed and approved by the ML engineering lead", "evidence_type": "data-lineage-record", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 A.7.4 (Quality of data) requires ensuring that data used for AI systems meets defined quality criteria. TG-01\u2019s schema validation, completeness checks, and quality gates enforce those criteria at pipeline time." }, { "control": "apeiris://model/controls/TG-03", "id": "TG-03", "domain": "model", "name": "Data Rights, Lawful Authority and Permitted Use", "validation_objective": "For every dataset used in training, a specific and documented legal basis exists \u2014 identifying the consent mechanism, contractual right, statutory authority, or license entitlement that permits collection and use for the declared training purpose \u2014 and no training run may proceed on a dataset whose legal basis record is absent, expired, or jurisdiction-mismatched.", "blocking_effect": "blocks-deployment", "evidence_required": [ "data_rights_record for each training dataset specifying the legal basis type (consent, legitimate interest, contract, statutory authority, or license), the jurisdiction(s) covered, the permitted purpose scope, and any opt-out or withdrawal obligations", "purpose_limitation_compliance_record confirming that the declared training purpose falls within the scope of the legal basis established for the dataset, with documented mapping between use case and authorized purpose", "opt_out_enforcement_log showing that data subjects who exercised withdrawal or opt-out rights had their records removed from training datasets before any training run that included the affected dataset", "legal_basis_expiry_alert showing that datasets with time-limited legal bases (e.g., consents with expiry dates, contracts with end dates) are flagged for renewal review before expiry and blocked from training if the basis lapses" ], "evidence": [ { "id": "TG-03-E1", "description": "data_rights_record for each training dataset specifying the legal basis type (consent, legitimate interest, contract, statutory authority, or license), the jurisdiction(s) covered, the permitted purpose scope, and any opt-out or withdrawal obligations", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-03-E2", "description": "purpose_limitation_compliance_record confirming that the declared training purpose falls within the scope of the legal basis established for the dataset, with documented mapping between use case and authorized purpose", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-03-E3", "description": "opt_out_enforcement_log showing that data subjects who exercised withdrawal or opt-out rights had their records removed from training datasets before any training run that included the affected dataset", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-03-E4", "description": "legal_basis_expiry_alert showing that datasets with time-limited legal bases (e.g., consents with expiry dates, contracts with end dates) are flagged for renewal review before expiry and blocked from training if the basis lapses", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 A.7.5 (Data provenance) requires documenting the provenance of data used in AI systems. TG-03\u2019s Data Rights Registry records origin, legal basis, and permitted use for every training dataset." }, { "control": "apeiris://model/controls/TG-05", "id": "TG-05", "domain": "model", "name": "Train/Evaluation/Test Separation and Contamination Prevention", "validation_objective": "Training, evaluation, and test data splits contain no contaminating examples from other splits, verified by automated exact-match and near-duplicate detection before each training run commences. The training pipeline blocks any run where contamination detection has not completed with a clean result and produced a signed attestation.", "blocking_effect": "blocks-deployment", "evidence_required": [ "contamination_check_audit_log with training_run_id, benchmark names checked, exact_match_count, near_duplicate_count, retrieval_leakage_count, and pass/block outcome per split pair for every training run", "split_deduplication_report listing content-hash comparison results for all training-test and training-eval split pairs, with deduplication method (exact-match hash, MinHash LSH, embedding cosine similarity) and similarity threshold used", "test_set_access_control_record showing storage-layer ACL configuration restricting test split access to validation personnel only, with last-verified date", "evaluation_overfitting_policy document specifying maximum benchmark reuse count per model version, rotation schedule, and use of held-out external benchmarks not accessible to the model development team" ], "evidence": [ { "id": "TG-05-E1", "description": "contamination_check_audit_log with training_run_id, benchmark names checked, exact_match_count, near_duplicate_count, retrieval_leakage_count, and pass/block outcome per split pair for every training run", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "TG-05-E2", "description": "split_deduplication_report listing content-hash comparison results for all training-test and training-eval split pairs, with deduplication method (exact-match hash, MinHash LSH, embedding cosine similarity) and similarity threshold used", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "TG-05-E3", "description": "test_set_access_control_record showing storage-layer ACL configuration restricting test split access to validation personnel only, with last-verified date", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "TG-05-E4", "description": "evaluation_overfitting_policy document specifying maximum benchmark reuse count per model version, rotation schedule, and use of held-out external benchmarks not accessible to the model development team", "evidence_type": "evaluation-scorecard", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 A.7.4 (Quality of data) requires data quality management across the data used for AI systems. TG-05\u2019s split separation and contamination detection protect the integrity of evaluation data as a quality property." }, { "control": "apeiris://model/controls/TG-07", "id": "TG-07", "domain": "model", "name": "Third-Party Dataset Governance", "validation_objective": "Every externally sourced training dataset in active use has a current Third-Party Dataset Registry entry with a valid security and legal review, version-pinned artifact hash, and license compliance record. No third-party dataset update enters training without a completed re-review gate, and artifact integrity is verified by hash comparison against vendor-published checksums before each training use.", "blocking_effect": "blocks-deployment", "evidence_required": [ "third_party_dataset_registry_entry for each active external dataset containing: dataset_id, vendor_name, license_terms, version_pin with artifact_hash, approval_date, reviewer_identity, legal_review_outcome, and security_review_outcome", "artifact_integrity_verification_log per training run showing hash comparison between locally stored dataset artifact and vendor-published checksum, with pass/fail result", "update_notification_record documenting each vendor-issued dataset update notice received, with quarantine status and re-review outcome (approved / rejected / paused-pending-review)", "license_compliance_attestation confirming permitted training use, output rights, and any attribution or restriction requirements for each active third-party dataset" ], "evidence": [ { "id": "TG-07-E1", "description": "third_party_dataset_registry_entry for each active external dataset containing: dataset_id, vendor_name, license_terms, version_pin with artifact_hash, approval_date, reviewer_identity, legal_review_outcome, and security_review_outcome", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-07-E2", "description": "artifact_integrity_verification_log per training run showing hash comparison between locally stored dataset artifact and vendor-published checksum, with pass/fail result", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-07-E3", "description": "update_notification_record documenting each vendor-issued dataset update notice received, with quarantine status and re-review outcome (approved / rejected / paused-pending-review)", "evidence_type": "human-review-record", "verification": "human" }, { "id": "TG-07-E4", "description": "license_compliance_attestation confirming permitted training use, output rights, and any attribution or restriction requirements for each active third-party dataset", "evidence_type": "third-party-audit-report", "verification": "third-party" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 A.7.5 (Data provenance) requires provenance documentation for data used in AI systems. TG-07\u2019s third-party dataset registry and vendor checksum verification extend provenance assurance to externally sourced data." }, { "control": "apeiris://model/controls/TG-08", "id": "TG-08", "domain": "model", "name": "Dataset Retention, Deletion and Lifecycle", "validation_objective": "All training artifacts are classified under the Data Lifecycle Policy with documented retention periods and deletion procedures, and erasure requests trigger automated deletion propagation across all affected artifact categories within the defined SLA. Audit trail records for erasure events are retained separately from the deleted data and remain accessible for the full compliance retention window after deletion.", "blocking_effect": "requires-review", "evidence_required": [ "data_lifecycle_policy_document with retention schedules per artifact category (raw training data, derived features, trained model weights, evaluation results, experiment tracker copies, backups), deletion procedures, and jurisdiction-specific treatment for GDPR Art. 17 and CCPA erasure", "erasure_request_processing_log with request_id, requesting_party, data_subject_reference, artifact_categories_affected, deletion_timestamp per category, and deletion_certificate signed by the processing system", "model_impact_assessment_record for each erasure request affecting data used in a trained model, documenting residual memorization risk, whether retraining or machine unlearning is required, and the decision rationale with named approver", "annual_lifecycle_policy_review_record confirming that retention schedules and deletion procedures were reviewed against current regulatory requirements including machine unlearning developments and GPAI data governance obligations" ], "evidence": [ { "id": "TG-08-E1", "description": "data_lifecycle_policy_document with retention schedules per artifact category (raw training data, derived features, trained model weights, evaluation results, experiment tracker copies, backups), deletion procedures, and jurisdiction-specific treatment for GDPR Art. 17 and CCPA erasure", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "TG-08-E2", "description": "erasure_request_processing_log with request_id, requesting_party, data_subject_reference, artifact_categories_affected, deletion_timestamp per category, and deletion_certificate signed by the processing system", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-08-E3", "description": "model_impact_assessment_record for each erasure request affecting data used in a trained model, documenting residual memorization risk, whether retraining or machine unlearning is required, and the decision rationale with named approver", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-08-E4", "description": "annual_lifecycle_policy_review_record confirming that retention schedules and deletion procedures were reviewed against current regulatory requirements including machine unlearning developments and GPAI data governance obligations", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 A.7.2 (Data for development and enhancement) covers management of development data. TG-08\u2019s retention, deletion, and lifecycle controls govern that data through end-of-life." }, { "control": "apeiris://model/controls/LI-05", "id": "LI-05", "domain": "model", "name": "Training Data Lineage Pointer \u2014 Link from Model Registry to TG-Layer Dataset...", "validation_objective": "Every model registry entry must contain one or more validated machine-resolvable references to TG-layer dataset records covering each applicable training phase (pre-training corpus, fine-tuning dataset, and RLHF preference data where applicable); the registry must enforce referential integrity by blocking registration when any referenced dataset record ID is invalid or carries a disqualified status; and an automated alerting mechanism must notify all affected model registry entries within the defined SLA when a referenced TG-layer dataset record is recalled or flagged.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_registry_entry containing a structured training_data_references[] field with at least one TG-layer dataset record ID per applicable training phase, validated at registration time and stored as immutable foreign-key references", "dataset_reference_validation_log confirming that each referenced dataset record ID resolved to a valid, non-flagged TG-layer record at registration time, with resolution timestamp and referenced record status", "dataset_recall_alert_record demonstrating that an automated notification was dispatched to all model registry entries referencing a recalled or flagged dataset record within the defined SLA", "independent_validation_access_record showing that the validation team successfully retrieved the TG-layer records referenced by a production model registry entry without requiring escalation or special access" ], "evidence": [ { "id": "LI-05-E1", "description": "model_registry_entry containing a structured training_data_references[] field with at least one TG-layer dataset record ID per applicable training phase, validated at registration time and stored as immutable foreign-key references", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-05-E2", "description": "dataset_reference_validation_log confirming that each referenced dataset record ID resolved to a valid, non-flagged TG-layer record at registration time, with resolution timestamp and referenced record status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-05-E3", "description": "dataset_recall_alert_record demonstrating that an automated notification was dispatched to all model registry entries referencing a recalled or flagged dataset record within the defined SLA", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-05-E4", "description": "independent_validation_access_record showing that the validation team successfully retrieved the TG-layer records referenced by a production model registry entry without requiring escalation or special access", "evidence_type": "configuration-snapshot", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 A.6.2.3 (Documentation of AI system design and development) covers development documentation, which includes the data used. LI-05\u2019s registry-to-dataset lineage pointer makes the training-data component of that documentation machine-resolvable." } ] }, { "requirement_id": "ISO42001-A.8.3", "section": "Annex A \u00a7A.8.3", "title": "AI system life cycle \u2014 Development and testing", "text": "The organization shall establish controls for the development and testing of AI systems to ensure they meet their requirements and do not introduce unacceptable risks.", "verdict": "supported", "coverage": "direct", "notes": "Pre-deployment evaluation gate, adversarial red-team testing, reproducible evaluation design, regression testing on updates, and independent validation implement robust AI development and testing controls.", "control_count": 5, "proof_chain": [ { "control": "apeiris://model/controls/EV-01", "id": "EV-01", "domain": "model", "name": "Pre-Deployment Evaluation Gate", "validation_objective": "No model artifact is promoted to production unless a signed evaluation manifest referencing that artifact's exact hash is present in the tamper-evident evaluation log and has received dual approval from named, authorized approvers. The deployment pipeline enforces this as a cryptographic gate \u2014 an absent, unsigned, or hash-mismatched manifest results in an automatic pipeline block with no override path except a logged exception with named risk-accepter.", "blocking_effect": "blocks-deployment", "evidence_required": [ "signed_evaluation_manifest with model_artifact_hash, evaluation_suite_version, evaluator_identities, per-dimension pass/fail outcome, signing_key_id, and manifest_signature (Ed25519) for every production model version", "tamper_evident_evaluation_log entry linking manifest_id to model_artifact_hash, recording append timestamp, appender identity, and log integrity proof", "dual_approval_record with two named approver identities, their organizational roles, approval timestamps, and the manifest_hash each approver authorized", "pipeline_execution_log showing at least one successful gate enforcement event: a deployment attempt with an absent or invalid manifest that was blocked, confirming the gate is operational rather than advisory" ], "evidence": [ { "id": "EV-01-E1", "description": "signed_evaluation_manifest with model_artifact_hash, evaluation_suite_version, evaluator_identities, per-dimension pass/fail outcome, signing_key_id, and manifest_signature (Ed25519) for every production model version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-01-E2", "description": "tamper_evident_evaluation_log entry linking manifest_id to model_artifact_hash, recording append timestamp, appender identity, and log integrity proof", "evidence_type": "audit-log", "verification": "automated" }, { "id": "EV-01-E3", "description": "dual_approval_record with two named approver identities, their organizational roles, approval timestamps, and the manifest_hash each approver authorized", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EV-01-E4", "description": "pipeline_execution_log showing at least one successful gate enforcement event: a deployment attempt with an absent or invalid manifest that was blocked, confirming the gate is operational rather than advisory", "evidence_type": "configuration-snapshot", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 A.6.2.4 (AI system verification and validation) requires verification and validation before deployment. EV-01\u2019s evaluation gate is the blocking control where those results are checked." }, { "control": "apeiris://model/controls/EV-04", "id": "EV-04", "domain": "model", "name": "Adversarial Red-Team Testing", "validation_objective": "The model system has a signed red-team report produced by a team organizationally independent of model development, documenting structured adversarial probing that covers all required attack categories for the applicable profiles, with all critical and high findings remediated and re-tested before the deployment gate clears.", "blocking_effect": "blocks-deployment", "evidence_required": [ "signed_red_team_scope_document with threat_model version, profile scope, and pre-exercise approval timestamp", "red_team_findings_log with finding_id, severity_classification, reproduction_steps, affected_population, and remediation_status per finding", "signed_red_team_report with residual_risk_statement linked to model artifact hash and listing remediated critical and high findings with re-test results", "remediation_evidence for all critical and high findings demonstrating the vulnerability is closed via re-test, not only via input-level patch", "for frontier-capability profile: escalation_records for any capability elicited at or near threshold levels with escalation_destination and response_action" ], "evidence": [ { "id": "EV-04-E1", "description": "signed_red_team_scope_document with threat_model version, profile scope, and pre-exercise approval timestamp", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EV-04-E2", "description": "red_team_findings_log with finding_id, severity_classification, reproduction_steps, affected_population, and remediation_status per finding", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-04-E3", "description": "signed_red_team_report with residual_risk_statement linked to model artifact hash and listing remediated critical and high findings with re-test results", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "EV-04-E4", "description": "remediation_evidence for all critical and high findings demonstrating the vulnerability is closed via re-test, not only via input-level patch", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "EV-04-E5", "description": "for frontier-capability profile: escalation_records for any capability elicited at or near threshold levels with escalation_destination and response_action", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 A.6.2.4 (AI system verification and validation) covers validation of AI systems; EV-04\u2019s adversarial red-team exercises extend validation to hostile-input scenarios." }, { "control": "apeiris://model/controls/EV-06", "id": "EV-06", "domain": "model", "name": "Reproducible Evaluation Design", "validation_objective": "Every evaluation run against a model artifact can be independently reproduced from the evaluation design document alone within the defined tolerance by a party who was not involved in the original run; all benchmarks have documented contamination screening results; and all evaluation artifacts are signed with SHA-256 content-addressed hashes recorded in the evaluation manifest.", "blocking_effect": "blocks-deployment", "evidence_required": [ "version_controlled_benchmark_selection_document with pre-specified selection_criteria, benchmark_ids, known_limitations, and alternatives_considered \u2014 signed and committed before any evaluation run begins", "contamination_screening_report documenting screening_methodology, training_corpus_reference, per-benchmark contamination_result (clean/flagged/excluded), and screening_date", "evaluation_design_document capturing all reproduction parameters: random_seeds, software_dependency_versions with hashes, hardware_configuration, serving_framework_config, eval_script_version_and_hash, prompt_templates, and post_processing_steps", "independent_reproduction_run_record showing reproduction_results within the defined tolerance alongside original_results, confirming design document sufficiency for independent replication", "signed_evaluation_artifact_manifest listing SHA-256 hashes for all artifacts (design document, scripts, datasets, results) with signer_identity and key_identifier" ], "evidence": [ { "id": "EV-06-E1", "description": "version_controlled_benchmark_selection_document with pre-specified selection_criteria, benchmark_ids, known_limitations, and alternatives_considered \u2014 signed and committed before any evaluation run begins", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-06-E2", "description": "contamination_screening_report documenting screening_methodology, training_corpus_reference, per-benchmark contamination_result (clean/flagged/excluded), and screening_date", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-06-E3", "description": "evaluation_design_document capturing all reproduction parameters: random_seeds, software_dependency_versions with hashes, hardware_configuration, serving_framework_config, eval_script_version_and_hash, prompt_templates, and post_processing_steps", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-06-E4", "description": "independent_reproduction_run_record showing reproduction_results within the defined tolerance alongside original_results, confirming design document sufficiency for independent replication", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-06-E5", "description": "signed_evaluation_artifact_manifest listing SHA-256 hashes for all artifacts (design document, scripts, datasets, results) with signer_identity and key_identifier", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 A.6.2.4 (AI system verification and validation) requires validation to be specified and documented; EV-06\u2019s reproducible design makes documented validation independently re-runnable." }, { "control": "apeiris://model/controls/EV-07", "id": "EV-07", "domain": "model", "name": "Regression Testing on Updates", "validation_objective": "Every model update \u2014 including fine-tunes, RLHF updates, guardrail changes, serving-framework changes, and quantization changes \u2014 triggers a full regression evaluation against a signed baseline before promotion; safety_regression_rate is zero-tolerance with any non-zero value producing an automatic blocking finding; and capability_regression_rate exceeding the defined threshold blocks promotion unless a signed risk-acceptance record is present.", "blocking_effect": "blocks-deployment", "evidence_required": [ "versioned_regression_suite_artifact with signed hash covering safety scenarios, alignment/refusal scenarios for generative-ai profile, and failure modes documented in prior red-team exercises", "signed_regression_manifest for each update event linking updated_model_artifact_hash, baseline_artifact_hash, regression_suite_version, run_timestamp, and per-metric regression_results including safety_regression_rate and capability_regression_rate", "signed_baseline_evaluation_results for the production model version serving as the regression reference, version-locked before the update is applied", "blocking_record for any regression finding including root_cause_analysis for safety regressions and proposed remediation with estimated completion date", "risk_acceptance_record for any sub-threshold capability regression finding with explicit rationale, accepting_authority identity, and time_bound_remediation_commitment" ], "evidence": [ { "id": "EV-07-E1", "description": "versioned_regression_suite_artifact with signed hash covering safety scenarios, alignment/refusal scenarios for generative-ai profile, and failure modes documented in prior red-team exercises", "evidence_type": "red-team-report", "verification": "third-party" }, { "id": "EV-07-E2", "description": "signed_regression_manifest for each update event linking updated_model_artifact_hash, baseline_artifact_hash, regression_suite_version, run_timestamp, and per-metric regression_results including safety_regression_rate and capability_regression_rate", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-07-E3", "description": "signed_baseline_evaluation_results for the production model version serving as the regression reference, version-locked before the update is applied", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-07-E4", "description": "blocking_record for any regression finding including root_cause_analysis for safety regressions and proposed remediation with estimated completion date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-07-E5", "description": "risk_acceptance_record for any sub-threshold capability regression finding with explicit rationale, accepting_authority identity, and time_bound_remediation_commitment", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 Clause 10.2 (Nonconformity and corrective action) requires reacting to nonconformities and correcting them. EV-07\u2019s regression findings are structured nonconformity detections raised before an update ships." }, { "control": "apeiris://model/controls/EV-08", "id": "EV-08", "domain": "model", "name": "Independent Validation", "validation_objective": "Every model deployment authorization is signed by a validator who is organizationally independent of the model development function with no shared management chain at a meaningful level; the validator has documented authority to withhold authorization and escalate findings to a governance committee; and the deployment pipeline rejects any manifest where the validator and development lead share the same organizational identity.", "blocking_effect": "blocks-deployment", "evidence_required": [ "organizational_chart_and_reporting_structure_document confirming validator independence from the development team for each model system, with management_chain_separation explicitly documented to a meaningful organizational level", "validation_function_authority_policy document version-controlled and governance-committee-approved, explicitly granting rights to request additional evaluation runs, require remediation, and withhold deployment authorization without development team approval", "evaluation_manifests containing named, attributed validator approvals with validator_identity distinct from development_team_lead_identity, linked to verifiable PKI certificate or directory record", "escalation_path_verification_record demonstrating that a test dispute routes to the governance committee and not to the development management chain", "annual_independence_structure_review_document for us-regulated-banking profile, available to regulators and auditors on request" ], "evidence": [ { "id": "EV-08-E1", "description": "organizational_chart_and_reporting_structure_document confirming validator independence from the development team for each model system, with management_chain_separation explicitly documented to a meaningful organizational level", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-08-E2", "description": "validation_function_authority_policy document version-controlled and governance-committee-approved, explicitly granting rights to request additional evaluation runs, require remediation, and withhold deployment authorization without development team approval", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-08-E3", "description": "evaluation_manifests containing named, attributed validator approvals with validator_identity distinct from development_team_lead_identity, linked to verifiable PKI certificate or directory record", "evidence_type": "certification", "verification": "third-party" }, { "id": "EV-08-E4", "description": "escalation_path_verification_record demonstrating that a test dispute routes to the governance committee and not to the development management chain", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "EV-08-E5", "description": "annual_independence_structure_review_document for us-regulated-banking profile, available to regulators and auditors on request", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO 42001 \u00a79.2 requires independent internal audits of the AI management system; independent validation applies this principle to model evaluation." } ] }, { "requirement_id": "ISO42001-A.8.4", "section": "Annex A \u00a7A.8.4", "title": "AI system life cycle \u2014 Operations and monitoring", "text": "The organization shall establish controls for the operation of AI systems in production, including performance monitoring, behavioral monitoring, and incident response.", "verdict": "supported", "coverage": "direct", "notes": "Output anomaly detection, usage telemetry and decision logging, behavioral telemetry collection baseline, continuous production monitoring and risk aggregation, and AI incident response management together implement production operations and monitoring.", "control_count": 5, "proof_chain": [ { "control": "apeiris://model/controls/BH-01", "id": "BH-01", "domain": "model", "name": "Output Anomaly Detection", "validation_objective": "The production inference endpoint must be continuously sampled and output distributions must be statistically compared against a versioned, SHA-256-signed baseline artifact using PSI and Shewhart/EWMA control chart methods, such that any distribution shift exceeding PSI 0.2 fires a tiered alert within one monitoring window of the shift occurring and all anomaly events are stored in the evidence registry with BH-01 control linkage.", "blocking_effect": "advisory", "evidence_required": [ "versioned, SHA-256-signed baseline distribution artifact stored in the model registry with per-metric statistics (mean, std_dev, p5/p50/p95/p99) computed from the 30-day post-deployment stable window", "SPC alert log for trailing 90 days with fields: alert_id, trigger_metric, psi_value, alert_severity, triggered_at, acknowledged_at, and resolution_outcome", "PII masking audit record confirming no direct identifier fields (email, SSN, full name) appear in the sampled output storage for the trailing 30 days", "quarterly threshold review sign-off from model owner confirming PSI alert (0.2) and critical (0.25) thresholds remain appropriate for the current deployment context" ], "evidence": [ { "id": "BH-01-E1", "description": "versioned, SHA-256-signed baseline distribution artifact stored in the model registry with per-metric statistics (mean, std_dev, p5/p50/p95/p99) computed from the 30-day post-deployment stable window", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-01-E2", "description": "SPC alert log for trailing 90 days with fields: alert_id, trigger_metric, psi_value, alert_severity, triggered_at, acknowledged_at, and resolution_outcome", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "BH-01-E3", "description": "PII masking audit record confirming no direct identifier fields (email, SSN, full name) appear in the sampled output storage for the trailing 30 days", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-01-E4", "description": "quarterly threshold review sign-off from model owner confirming PSI alert (0.2) and critical (0.25) thresholds remain appropriate for the current deployment context", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 A.6.2.6 (AI system operation and monitoring) requires monitoring the AI system in operation. BH-01\u2019s statistical process control over output distributions implements that monitoring with signed baselines and tiered alerts." }, { "control": "apeiris://model/controls/BH-05", "id": "BH-05", "domain": "model", "name": "Usage Telemetry and Decision Logging", "validation_objective": "Every model inference endpoint must emit a structured DecisionLog record containing input_hash (HMAC-SHA-256), caller_id, model_version, output_sample at the configured sampling rate, latency_ms, and decision_outcome; logs must be stored in an append-only tamper-evident store with daily Merkle root hash publication; and no direct PII must appear in any stored log field.", "blocking_effect": "advisory", "evidence_required": [ "DecisionLog schema documentation with field definitions, HMAC masking policy, key management system references, and output sampling rate configuration per deployment profile", "privacy review sign-off from the data protection team confirming no direct PII identifiers appear in stored log records, based on a regex scan of a trailing 30-day sample", "daily Merkle root hash publication log for trailing 90 days with fields: root_hash, computation_timestamp, and publication_destination for each daily entry", "retention policy configuration and automated deletion audit log confirming tiered retention enforcement (90-day raw, 3-year aggregated, 10-year minimum for EU high-risk deployments)", "DecisionLog query access audit trail for trailing 90 days showing all access events with requester_id, query_timestamp, and authorization_basis" ], "evidence": [ { "id": "BH-05-E1", "description": "DecisionLog schema documentation with field definitions, HMAC masking policy, key management system references, and output sampling rate configuration per deployment profile", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "BH-05-E2", "description": "privacy review sign-off from the data protection team confirming no direct PII identifiers appear in stored log records, based on a regex scan of a trailing 30-day sample", "evidence_type": "audit-log", "verification": "automated" }, { "id": "BH-05-E3", "description": "daily Merkle root hash publication log for trailing 90 days with fields: root_hash, computation_timestamp, and publication_destination for each daily entry", "evidence_type": "audit-log", "verification": "automated" }, { "id": "BH-05-E4", "description": "retention policy configuration and automated deletion audit log confirming tiered retention enforcement (90-day raw, 3-year aggregated, 10-year minimum for EU high-risk deployments)", "evidence_type": "audit-log", "verification": "automated" }, { "id": "BH-05-E5", "description": "DecisionLog query access audit trail for trailing 90 days showing all access events with requester_id, query_timestamp, and authorization_basis", "evidence_type": "audit-log", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "BH-05 implements structured documented information controls for AI inference records \u2014 including a defined schema, HMAC-SHA-256 input masking, tiered retention aligned to EU AI Act Art. 12 obligations, and a daily Merkle tree tamper-evidence mechanism \u2014 directly satisfying ISO 42001 Clause 7.5's requirement for documented information necessary for the effectiveness of the AI management system. Clause 9.1 is additionally relevant because DecisionLogs provide the raw telemetry foundation for the operational monitoring and measurement activities implemented by BH-01 through BH-04." }, { "control": "apeiris://agentic/controls/AM-01", "id": "AM-01", "domain": "agentic", "name": "Behavioral Telemetry Collection Baseline", "validation_objective": "Proves that every registered production agent emits a schema-validated, minimum signal set \u2014 covering action type, tool invocations, token consumption, session boundaries, and decision rationale traces \u2014 to an append-only telemetry store, with 100% coverage of registered agents demonstrable within the prior 24-hour window.", "blocking_effect": "advisory", "evidence_required": [ "Telemetry schema version registry showing current schema version and change history with change-management approval records", "Agent registry cross-referenced with telemetry coverage report identifying any registered agents with no telemetry events in the prior 24 hours", "Schema validation rejection rate report for the prior 7 days, with alert records for any rejection rate above 0.1%", "Five sample agent session traces each demonstrating a continuous telemetry record from session_start to session_end with all required baseline fields", "Telemetry pipeline SLO report covering ingestion latency, throughput capacity, and event loss rate" ], "evidence": [ { "id": "AM-01-E1", "description": "Telemetry schema version registry showing current schema version and change history with change-management approval records", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AM-01-E2", "description": "Agent registry cross-referenced with telemetry coverage report identifying any registered agents with no telemetry events in the prior 24 hours", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AM-01-E3", "description": "Schema validation rejection rate report for the prior 7 days, with alert records for any rejection rate above 0.1%", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "AM-01-E4", "description": "Five sample agent session traces each demonstrating a continuous telemetry record from session_start to session_end with all required baseline fields", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AM-01-E5", "description": "Telemetry pipeline SLO report covering ingestion latency, throughput capacity, and event loss rate", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 \u00a79.1 requires organizations to determine what needs to be monitored and measured regarding AI system performance. A telemetry baseline directly instantiates this requirement by specifying the minimum observable signals. Absence of a defined baseline means \u00a79.1 cannot be meaningfully demonstrated." }, { "control": "apeiris://model/controls/CR-01", "id": "CR-01", "domain": "model", "name": "Continuous Production Monitoring and Risk Aggregation", "validation_objective": "All runtime monitoring signals \u2014 performance, drift, fairness, safety incidents, and deployment event flags \u2014 must be continuously aggregated into a unified risk dashboard with pre-configured automated alerting thresholds; any degradation in a monitored dimension must be detected and an alert dispatched within one operational window.", "blocking_effect": "advisory", "evidence_required": [ "risk_dashboard_configuration_record showing all registered signal feeds (performance, drift, fairness, safety, incident), their alert thresholds, assigned monitoring window duration, and escalation recipients", "alert_audit_log covering at least 30 days showing triggered alerts with signal_type, threshold_crossed, alert_timestamp, and escalation_recipient for each alert", "monitoring_coverage_audit confirming every deployed model version has an associated monitoring configuration with no version gaps", "risk_aggregation_methodology_document defining how individual dimension alerts are combined into composite risk scores and dashboard status indicators", "post-market_monitoring_report satisfying EU AI Act Art. 72 covering the monitoring period, key findings, and corrective actions taken or planned" ], "evidence": [ { "id": "CR-01-E1", "description": "risk_dashboard_configuration_record showing all registered signal feeds (performance, drift, fairness, safety, incident), their alert thresholds, assigned monitoring window duration, and escalation recipients", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-01-E2", "description": "alert_audit_log covering at least 30 days showing triggered alerts with signal_type, threshold_crossed, alert_timestamp, and escalation_recipient for each alert", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E3", "description": "monitoring_coverage_audit confirming every deployed model version has an associated monitoring configuration with no version gaps", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E4", "description": "risk_aggregation_methodology_document defining how individual dimension alerts are combined into composite risk scores and dashboard status indicators", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E5", "description": "post-market_monitoring_report satisfying EU AI Act Art. 72 covering the monitoring period, key findings, and corrective actions taken or planned", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 A.6.2.6 (AI system operation and monitoring) requires monitoring the AI system in operation. CR-01 aggregates the operational monitoring signals \u2014 performance, drift, fairness, safety, cost \u2014 into one governed risk view." }, { "control": "apeiris://model/controls/CR-04", "id": "CR-04", "domain": "model", "name": "AI Incident Response Management", "validation_objective": "The organization must have a documented, version-controlled AI Incident Response Plan (AIRP) with AI-specific containment playbooks covering model rollback, output-filter enforcement, traffic shaping, and full model shutdown \u2014 tested via at least four quarterly tabletop exercises per year using MITRE ATLAS adversarial scenarios \u2014 and P1/P2 post-incident review records produced within 5 days of event resolution for all qualifying events in the trailing 12 months.", "blocking_effect": "blocks-deployment", "evidence_required": [ "AI Incident Response Plan document (version-controlled, CISO or AI-risk-owner signed, with review date within 12 months)", "Containment playbook index listing separate runbooks for model_rollback, output_filter_enforcement, traffic_shaping, and model_shutdown_with_fallback", "Last 4 quarterly tabletop exercise reports with MITRE ATLAS scenario identifier, participant roster, outcomes, and reviewer sign-off", "P1 and P2 post-incident review records for all qualifying events in the trailing 12 months, each showing post_incident_report_date within 5 days of incident_resolved_date", "EU Art. 73 notification trigger mapping document showing which P1 severity criteria trigger the Art. 73 serious-incident notification obligation (15d general / 10d death / 2d widespread or critical infrastructure)" ], "evidence": [ { "id": "CR-04-E1", "description": "AI Incident Response Plan document (version-controlled, CISO or AI-risk-owner signed, with review date within 12 months)", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-04-E2", "description": "Containment playbook index listing separate runbooks for model_rollback, output_filter_enforcement, traffic_shaping, and model_shutdown_with_fallback", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-04-E3", "description": "Last 4 quarterly tabletop exercise reports with MITRE ATLAS scenario identifier, participant roster, outcomes, and reviewer sign-off", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CR-04-E4", "description": "P1 and P2 post-incident review records for all qualifying events in the trailing 12 months, each showing post_incident_report_date within 5 days of incident_resolved_date", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-04-E5", "description": "EU Art. 73 notification trigger mapping document showing which P1 severity criteria trigger the Art. 73 serious-incident notification obligation (15d general / 10d death / 2d widespread or critical infrastructure)", "evidence_type": "incident-record", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 Clause 10.2 (Nonconformity and corrective action) requires responding to nonconformities and correcting root causes. CR-04\u2019s incident response plan, containment playbooks, and post-incident reviews implement that cycle for AI incidents." } ] }, { "requirement_id": "ISO42001-A.8.5", "section": "Annex A \u00a7A.8.5", "title": "AI system life cycle \u2014 Decommissioning", "text": "The organization shall establish controls for the decommissioning and disposal of AI systems, including data retention, model archival, and evidence preservation.", "verdict": "partial", "coverage": "partial", "notes": "Model retirement and archive policy, model retirement and evidence archival, and policy evidence archive address AI system decommissioning. Data disposal procedures, downstream consumer notification, and system retirement sign-off processes extend beyond Apeiris controls.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/LI-10", "id": "LI-10", "domain": "model", "name": "Model Retirement and Archive Policy \u2014 End-of-Life Procedure, Evidence...", "validation_objective": "When a model is retired from service, a formal decommissioning record exists showing that all dependent systems were identified and transitioned prior to retirement, evidence records are archived for the required retention period, and the retirement was explicitly authorized by a named governance owner.", "blocking_effect": "requires-review", "evidence_required": [ "decommissioning_authorization_record with model identifier, retirement date, authorizing owner identity, and documented confirmation that dependent system transition is complete", "dependency_transition_log listing each system or integration that relied on the retired model, the transition action taken (migration to successor, decommission, or manual override), and confirmation timestamp", "evidence_archive_record confirming that model evaluation artifacts, training provenance records, and decision audit logs have been transferred to long-term retention storage with the expected retention expiry date", "post_retirement_access_audit_log confirming that the retired model endpoint was disabled and no inference requests were served after the retirement date" ], "evidence": [ { "id": "LI-10-E1", "description": "decommissioning_authorization_record with model identifier, retirement date, authorizing owner identity, and documented confirmation that dependent system transition is complete", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-10-E2", "description": "dependency_transition_log listing each system or integration that relied on the retired model, the transition action taken (migration to successor, decommission, or manual override), and confirmation timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-10-E3", "description": "evidence_archive_record confirming that model evaluation artifacts, training provenance records, and decision audit logs have been transferred to long-term retention storage with the expected retention expiry date", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "LI-10-E4", "description": "post_retirement_access_audit_log confirming that the retired model endpoint was disabled and no inference requests were served after the retirement date", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 A.6.2.6 (AI system operation and monitoring) covers the operation stage of the AI system life cycle, under which controlled end-of-life handling falls. LI-10\u2019s authorized retirement workflow and archive policy give that stage a documented exit." }, { "control": "apeiris://model/controls/CR-07", "id": "CR-07", "domain": "model", "name": "Model Retirement and Evidence Archival", "validation_objective": "Every retired AI model must have a complete retirement record in the CR-02 evidence archive covering: a signed retirement decision record, user notification dispatched \u226530 days before decommission with a migration path, verified traffic drain to zero for 7 consecutive days, revocation of all associated API credentials and IAM permissions, complete infrastructure decommissioning with no orphaned endpoints or container images, a GDPR Art. 17 right-to-erasure evaluation, and the model marked as 'retired' in the LI-01 model registry with a final retirement record artifact_hash.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Signed retirement decision record with model_id, retirement_date, approving_model_owner, approving_ai_risk_function, and decision_rationale", "User retirement notification artifact showing dispatch_date >= 30 days before decommission_date, recipient list or audience scope, and migration_path_documentation link", "Traffic drain verification log showing zero-traffic state on the retired inference endpoint for 7 consecutive days prior to infrastructure decommission execution", "IAM credential revocation audit log listing all revoked API keys, service accounts, OAuth tokens, and service mesh credentials with revoked_at timestamps for the retired model", "Infrastructure decommission confirmation record (IaC destroy plan output or equivalent) documenting endpoint URLs, VM or container image IDs, and DNS records removed", "GDPR Art. 17 evaluation record documenting personal data assessment outcome for the training set and either erasure completion confirmation or documented lawful retention basis with legal sign-off", "Final retirement record in CR-02 with artifact_hash, model_id status=retired confirmed in LI-01, and archive tier set to long-term cold storage with retention_period documented" ], "evidence": [ { "id": "CR-07-E1", "description": "Signed retirement decision record with model_id, retirement_date, approving_model_owner, approving_ai_risk_function, and decision_rationale", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-07-E2", "description": "User retirement notification artifact showing dispatch_date >= 30 days before decommission_date, recipient list or audience scope, and migration_path_documentation link", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-07-E3", "description": "Traffic drain verification log showing zero-traffic state on the retired inference endpoint for 7 consecutive days prior to infrastructure decommission execution", "evidence_type": "audit-log", "verification": "automated" }, { "id": "CR-07-E4", "description": "IAM credential revocation audit log listing all revoked API keys, service accounts, OAuth tokens, and service mesh credentials with revoked_at timestamps for the retired model", "evidence_type": "audit-log", "verification": "automated" }, { "id": "CR-07-E5", "description": "Infrastructure decommission confirmation record (IaC destroy plan output or equivalent) documenting endpoint URLs, VM or container image IDs, and DNS records removed", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-07-E6", "description": "GDPR Art. 17 evaluation record documenting personal data assessment outcome for the training set and either erasure completion confirmation or documented lawful retention basis with legal sign-off", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "CR-07-E7", "description": "Final retirement record in CR-02 with artifact_hash, model_id status=retired confirmed in LI-01, and archive tier set to long-term cold storage with retention_period documented", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 A.6.2.6 (AI system operation and monitoring) covers the operation stage through end-of-life. CR-07\u2019s decommissioning checklist \u2014 traffic drain, credential revocation, evidence archival \u2014 closes that stage in a controlled, documented manner." }, { "control": "apeiris://authority/controls/PE-01", "id": "PE-01", "domain": "authority", "name": "Policy Evidence Archive", "validation_objective": "All policy evidence artifacts must be stored in a tamper-evident, versioned archive where entries are immutable once committed, indexed by artifact type and control ID, and retrievable within the defined SLA during regulatory examination or litigation hold. The archive must produce a cryptographic proof of immutability on demand.", "blocking_effect": "blocks-deployment", "evidence_required": [ "archive_commit_log showing every artifact entry with artifact_id, control_id, committed_at timestamp, SHA-256 hash, and committer identity \u2014 with no modification events after initial commit", "tamper_evidence_record containing the Merkle root or audit log hash for the archive state at each quarterly checkpoint, signed by the archive operator", "retrieval_test_record showing that a representative sample of archived artifacts was successfully retrieved within the defined SLA, with retrieval timestamps and artifact hashes", "litigation_hold_activation_record documenting hold scope, activation timestamp, and confirmation that affected artifacts are locked against deletion for the hold duration", "archive_access_control_manifest listing authorized readers and writers with role assignments, confirming write access is restricted to the ingestion pipeline and no interactive modification is permitted" ], "evidence": [ { "id": "PE-01-E1", "description": "archive_commit_log showing every artifact entry with artifact_id, control_id, committed_at timestamp, SHA-256 hash, and committer identity \u2014 with no modification events after initial commit", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PE-01-E2", "description": "tamper_evidence_record containing the Merkle root or audit log hash for the archive state at each quarterly checkpoint, signed by the archive operator", "evidence_type": "audit-log", "verification": "automated" }, { "id": "PE-01-E3", "description": "retrieval_test_record showing that a representative sample of archived artifacts was successfully retrieved within the defined SLA, with retrieval timestamps and artifact hashes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PE-01-E4", "description": "litigation_hold_activation_record documenting hold scope, activation timestamp, and confirmation that affected artifacts are locked against deletion for the hold duration", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PE-01-E5", "description": "archive_access_control_manifest listing authorized readers and writers with role assignments, confirming write access is restricted to the ingestion pipeline and no interactive modification is permitted", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "Tamper-evident retention of policy evidence reflects \u00a77.5 documented information control, partially." } ] }, { "requirement_id": "ISO42001-A.9.1", "section": "Annex A \u00a7A.9.1", "title": "Ensuring reliability \u2014 Performance monitoring", "text": "The organization shall monitor the performance of AI systems in operation against established metrics to detect degradation, drift, and unexpected behavior.", "verdict": "supported", "coverage": "direct", "notes": "Production performance degradation alerting, continuous production monitoring and risk aggregation, concept and data drift detection, AI-specific compliance KPIs, and anomalous action detection implement comprehensive AI performance monitoring.", "control_count": 5, "proof_chain": [ { "control": "apeiris://model/controls/BH-03", "id": "BH-03", "domain": "model", "name": "Production Performance Degradation Alerting", "validation_objective": "Every production model version must have a corresponding signed EvaluationBaseline artifact containing primary task metrics and subgroup slice metrics from the release evaluation gate; the metrics aggregation service must continuously compare production estimates against this baseline and fire tiered alerts when primary metrics regress 5% (warning) or 10% (critical) from the signed baseline values, including independent subgroup regression alerts.", "blocking_effect": "advisory", "evidence_required": [ "signed EvaluationBaseline artifact for the current production model version containing model_id, version, eval_date, primary_metrics with confidence intervals, subgroup slice metrics, eval_dataset_hash, and artifact SHA-256", "performance alert log for trailing 90 days with fields: alert_id, metric_name, regression_pct, severity, triggered_at, acknowledged_at, root_cause, and remediation_action for each alert", "quarterly threshold review sign-off from model owner confirming 5%/10% regression thresholds remain appropriate for the current model type and deployment context", "proxy_metric_registry documenting which proxy metrics substitute for labeled ground truth when unavailable, including calibration methodology and documented limitations" ], "evidence": [ { "id": "BH-03-E1", "description": "signed EvaluationBaseline artifact for the current production model version containing model_id, version, eval_date, primary_metrics with confidence intervals, subgroup slice metrics, eval_dataset_hash, and artifact SHA-256", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-03-E2", "description": "performance alert log for trailing 90 days with fields: alert_id, metric_name, regression_pct, severity, triggered_at, acknowledged_at, root_cause, and remediation_action for each alert", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "BH-03-E3", "description": "quarterly threshold review sign-off from model owner confirming 5%/10% regression thresholds remain appropriate for the current model type and deployment context", "evidence_type": "human-review-record", "verification": "human" }, { "id": "BH-03-E4", "description": "proxy_metric_registry documenting which proxy metrics substitute for labeled ground truth when unavailable, including calibration methodology and documented limitations", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 A.6.2.6 (AI system operation and monitoring) requires operational monitoring. BH-03\u2019s regression alerting against a signed EvaluationBaseline keeps release-time performance claims continuously verified." }, { "control": "apeiris://model/controls/CR-01", "id": "CR-01", "domain": "model", "name": "Continuous Production Monitoring and Risk Aggregation", "validation_objective": "All runtime monitoring signals \u2014 performance, drift, fairness, safety incidents, and deployment event flags \u2014 must be continuously aggregated into a unified risk dashboard with pre-configured automated alerting thresholds; any degradation in a monitored dimension must be detected and an alert dispatched within one operational window.", "blocking_effect": "advisory", "evidence_required": [ "risk_dashboard_configuration_record showing all registered signal feeds (performance, drift, fairness, safety, incident), their alert thresholds, assigned monitoring window duration, and escalation recipients", "alert_audit_log covering at least 30 days showing triggered alerts with signal_type, threshold_crossed, alert_timestamp, and escalation_recipient for each alert", "monitoring_coverage_audit confirming every deployed model version has an associated monitoring configuration with no version gaps", "risk_aggregation_methodology_document defining how individual dimension alerts are combined into composite risk scores and dashboard status indicators", "post-market_monitoring_report satisfying EU AI Act Art. 72 covering the monitoring period, key findings, and corrective actions taken or planned" ], "evidence": [ { "id": "CR-01-E1", "description": "risk_dashboard_configuration_record showing all registered signal feeds (performance, drift, fairness, safety, incident), their alert thresholds, assigned monitoring window duration, and escalation recipients", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-01-E2", "description": "alert_audit_log covering at least 30 days showing triggered alerts with signal_type, threshold_crossed, alert_timestamp, and escalation_recipient for each alert", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E3", "description": "monitoring_coverage_audit confirming every deployed model version has an associated monitoring configuration with no version gaps", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E4", "description": "risk_aggregation_methodology_document defining how individual dimension alerts are combined into composite risk scores and dashboard status indicators", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E5", "description": "post-market_monitoring_report satisfying EU AI Act Art. 72 covering the monitoring period, key findings, and corrective actions taken or planned", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 A.6.2.6 (AI system operation and monitoring) requires monitoring the AI system in operation. CR-01 aggregates the operational monitoring signals \u2014 performance, drift, fairness, safety, cost \u2014 into one governed risk view." }, { "control": "apeiris://model/controls/BH-02", "id": "BH-02", "domain": "model", "name": "Concept and Data Drift Detection", "validation_objective": "The production inference pipeline must compare input feature distributions and prediction distributions against a versioned, SHA-256-signed DriftReference artifact using PSI and KS-test statistics for every monitoring window that meets minimum_sample_size, such that drift exceeding profile-conditional PSI thresholds triggers tiered alert actions, and for continuously-learning profiles, automatically suspends online updates pending a signed model-owner resume authorization.", "blocking_effect": "advisory", "evidence_required": [ "versioned DriftReference artifact for the current production model with SHA-256 hash, training date, and per-feature statistics (mean, std, histogram bins, and KDE parameters) for all tier-1 monitored features", "drift event log for trailing 90 days with fields: feature_name, test_statistic, p_value, window_start, window_end, sample_count, alert_severity, and action_taken for each drift event", "monthly drift summary report signed by the model owner, including trend analysis across tier-1 features and prediction distribution PSI over the reporting period", "profile-conditional drift threshold configuration (YAML or equivalent) showing per-profile PSI alert and critical thresholds, minimum_sample_size, and window duration, stored under version control" ], "evidence": [ { "id": "BH-02-E1", "description": "versioned DriftReference artifact for the current production model with SHA-256 hash, training date, and per-feature statistics (mean, std, histogram bins, and KDE parameters) for all tier-1 monitored features", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-02-E2", "description": "drift event log for trailing 90 days with fields: feature_name, test_statistic, p_value, window_start, window_end, sample_count, alert_severity, and action_taken for each drift event", "evidence_type": "audit-log", "verification": "automated" }, { "id": "BH-02-E3", "description": "monthly drift summary report signed by the model owner, including trend analysis across tier-1 features and prediction distribution PSI over the reporting period", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-02-E4", "description": "profile-conditional drift threshold configuration (YAML or equivalent) showing per-profile PSI alert and critical thresholds, minimum_sample_size, and window duration, stored under version control", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 A.6.2.6 (AI system operation and monitoring) requires monitoring during operation. BH-02\u2019s PSI/KS drift detection against a versioned DriftReference artifact provides the input-drift component." }, { "control": "apeiris://compliance/controls/CI-03", "id": "CI-03", "domain": "compliance", "name": "AI-Specific Compliance KPIs", "validation_objective": "The compliance program must produce a defined set of AI-specific KPIs covering all five baseline dimensions (obligation coverage, evidence freshness, audit finding rate, remediation velocity, training completion) on a defined reporting cadence, with each KPI having a documented target threshold, a current measured value, and a trend direction indicator. No KPI may report a null measured_value at the defined reporting cadence without a documented exception.", "blocking_effect": "advisory", "evidence_required": [ "kpi_definition_register listing each KPI with kpi_id, name, definition, measurement_method, data_source, target_threshold, and reporting_frequency", "kpi_measurement_report for the current period containing measured_value, prior_period_value, trend_direction, and within_threshold flag for each defined KPI", "kpi_trend_history covering at least four consecutive reporting periods per KPI to enable trend analysis", "management_reporting_record confirming KPI results were presented to the compliance governance committee with attendance record and date", "remediation_action_record for each KPI where measured_value is outside the target_threshold, with root_cause, corrective_action, and target_return_to_threshold_date" ], "evidence": [ { "id": "CI-03-E1", "description": "kpi_definition_register listing each KPI with kpi_id, name, definition, measurement_method, data_source, target_threshold, and reporting_frequency", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-03-E2", "description": "kpi_measurement_report for the current period containing measured_value, prior_period_value, trend_direction, and within_threshold flag for each defined KPI", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-03-E3", "description": "kpi_trend_history covering at least four consecutive reporting periods per KPI to enable trend analysis", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-03-E4", "description": "management_reporting_record confirming KPI results were presented to the compliance governance committee with attendance record and date", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CI-03-E5", "description": "remediation_action_record for each KPI where measured_value is outside the target_threshold, with root_cause, corrective_action, and target_return_to_threshold_date", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://agentic/controls/AM-02", "id": "AM-02", "domain": "agentic", "name": "Anomalous Action Detection", "validation_objective": "Proves that every production agent has a current, signed action manifest defining its permitted tool set and target resource classes, and that the streaming anomaly detector identifies any out-of-manifest tool invocation or resource access within 30 seconds and generates a logged, escalated alert.", "blocking_effect": "advisory", "evidence_required": [ "Action manifest registry listing a current signed manifest for every production agent, including permitted_tools[], permitted_resource_patterns[], expected_token_range, and expected_latency_range", "Anomaly detection alert log for the prior 30 days with triage records confirming each critical alert was reviewed within the 15-minute SLA", "Mean time to detect (MTTD) measurement report for out-of-manifest actions, targeting sub-30-second detection", "Streaming detector configuration documentation confirming it runs in an isolated compute environment independent of monitored agent runtimes", "SOC SIEM integration confirmation showing anomaly alerts are correlated with identity and network signals" ], "evidence": [ { "id": "AM-02-E1", "description": "Action manifest registry listing a current signed manifest for every production agent, including permitted_tools[], permitted_resource_patterns[], expected_token_range, and expected_latency_range", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "AM-02-E2", "description": "Anomaly detection alert log for the prior 30 days with triage records confirming each critical alert was reviewed within the 15-minute SLA", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "AM-02-E3", "description": "Mean time to detect (MTTD) measurement report for out-of-manifest actions, targeting sub-30-second detection", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "AM-02-E4", "description": "Streaming detector configuration documentation confirming it runs in an isolated compute environment independent of monitored agent runtimes", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "AM-02-E5", "description": "SOC SIEM integration confirmation showing anomaly alerts are correlated with identity and network signals", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "ISO42001-A.9.2", "section": "Annex A \u00a7A.9.2", "title": "Ensuring reliability \u2014 Validation and behavioral testing", "text": "The organization shall conduct validation and testing to ensure AI systems behave reliably and as intended across their operating range.", "verdict": "supported", "coverage": "direct", "notes": "Fitness, safety, reliability and policy-conformance evaluation; regression testing on updates; scheduled model re-validation; AI system RTO/RPO definition and validation; and behavioral drift monitoring implement AI reliability validation.", "control_count": 5, "proof_chain": [ { "control": "apeiris://model/controls/EV-02", "id": "EV-02", "domain": "model", "name": "Fitness, Safety, Reliability and Policy-Conformance Evaluation", "validation_objective": "Before deployment, every model has been evaluated against pre-specified, dimension-level pass/fail thresholds \u2014 fitness, safety, reliability, and policy-conformance \u2014 with results documented against the model artifact hash and evaluation suite version. No threshold is modified after evaluation begins, and any threshold trade-off decision is documented as a named risk-acceptance record before the deployment manifest is signed.", "blocking_effect": "blocks-deployment", "evidence_required": [ "pre_specified_evaluation_protocol with model_artifact_hash, evaluation_suite_version, and per-dimension thresholds (fitness accuracy target, safety refusal rate, reliability error budget, policy-conformance violation rate), signed by the evaluation lead before testing begins \u2014 not after results are known", "dimension_level_evaluation_results showing per-dimension metric values, pass/fail verdict against pre-specified threshold, and model_artifact_hash confirming results correspond to the evaluated version", "evaluation_suite_provenance_record confirming that evaluation datasets are disjoint from training data, with contamination-check reference to TG-05 attestation", "risk_acceptance_record for any dimension where the pass threshold was not met but deployment was authorized, documenting named risk-accepter, specific capability gap, deployment risk consequence, and remediation deadline" ], "evidence": [ { "id": "EV-02-E1", "description": "pre_specified_evaluation_protocol with model_artifact_hash, evaluation_suite_version, and per-dimension thresholds (fitness accuracy target, safety refusal rate, reliability error budget, policy-conformance violation rate), signed by the evaluation lead before testing begins \u2014 not after results are known", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-02-E2", "description": "dimension_level_evaluation_results showing per-dimension metric values, pass/fail verdict against pre-specified threshold, and model_artifact_hash confirming results correspond to the evaluated version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-02-E3", "description": "evaluation_suite_provenance_record confirming that evaluation datasets are disjoint from training data, with contamination-check reference to TG-05 attestation", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-02-E4", "description": "risk_acceptance_record for any dimension where the pass threshold was not met but deployment was authorized, documenting named risk-accepter, specific capability gap, deployment risk consequence, and remediation deadline", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 A.6.2.4 (AI system verification and validation) requires defined verification and validation measures. EV-02\u2019s structured fitness, safety, reliability, and policy-conformance dimensions define those measures for models." }, { "control": "apeiris://model/controls/EV-07", "id": "EV-07", "domain": "model", "name": "Regression Testing on Updates", "validation_objective": "Every model update \u2014 including fine-tunes, RLHF updates, guardrail changes, serving-framework changes, and quantization changes \u2014 triggers a full regression evaluation against a signed baseline before promotion; safety_regression_rate is zero-tolerance with any non-zero value producing an automatic blocking finding; and capability_regression_rate exceeding the defined threshold blocks promotion unless a signed risk-acceptance record is present.", "blocking_effect": "blocks-deployment", "evidence_required": [ "versioned_regression_suite_artifact with signed hash covering safety scenarios, alignment/refusal scenarios for generative-ai profile, and failure modes documented in prior red-team exercises", "signed_regression_manifest for each update event linking updated_model_artifact_hash, baseline_artifact_hash, regression_suite_version, run_timestamp, and per-metric regression_results including safety_regression_rate and capability_regression_rate", "signed_baseline_evaluation_results for the production model version serving as the regression reference, version-locked before the update is applied", "blocking_record for any regression finding including root_cause_analysis for safety regressions and proposed remediation with estimated completion date", "risk_acceptance_record for any sub-threshold capability regression finding with explicit rationale, accepting_authority identity, and time_bound_remediation_commitment" ], "evidence": [ { "id": "EV-07-E1", "description": "versioned_regression_suite_artifact with signed hash covering safety scenarios, alignment/refusal scenarios for generative-ai profile, and failure modes documented in prior red-team exercises", "evidence_type": "red-team-report", "verification": "third-party" }, { "id": "EV-07-E2", "description": "signed_regression_manifest for each update event linking updated_model_artifact_hash, baseline_artifact_hash, regression_suite_version, run_timestamp, and per-metric regression_results including safety_regression_rate and capability_regression_rate", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-07-E3", "description": "signed_baseline_evaluation_results for the production model version serving as the regression reference, version-locked before the update is applied", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-07-E4", "description": "blocking_record for any regression finding including root_cause_analysis for safety regressions and proposed remediation with estimated completion date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-07-E5", "description": "risk_acceptance_record for any sub-threshold capability regression finding with explicit rationale, accepting_authority identity, and time_bound_remediation_commitment", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 Clause 10.2 (Nonconformity and corrective action) requires reacting to nonconformities and correcting them. EV-07\u2019s regression findings are structured nonconformity detections raised before an update ships." }, { "control": "apeiris://model/controls/CR-03", "id": "CR-03", "domain": "model", "name": "Scheduled Model Re-validation", "validation_objective": "A full benchmark, bias, and safety evaluation suite must execute against every production model version on the defined re-validation schedule; results must be compared to the deployment-time baseline metrics, and any performance degradation beyond configured thresholds must trigger a formal response documented and initiated before the next operational window closes.", "blocking_effect": "blocks-deployment", "evidence_required": [ "re_validation_schedule_record per model version showing configured re-validation frequency, last_run_timestamp, next_run_due, and scheduled_suite_identifier with no unmonitored production versions", "scheduled_evaluation_report for each re-validation run showing benchmark results, bias metrics, and safety evaluation scores with explicit comparison to the deployment-time baseline", "threshold_comparison_record showing the delta between current re-validation results and baseline for each metric with a pass/fail determination against the configured degradation threshold", "re_validation_response_record for any threshold breach, documenting the triggered response action (rollback, retraining, or escalation), responsible_party, and closure_timestamp", "re_validation_coverage_audit confirming all active production model versions are enrolled in re-validation schedules and that no version has exceeded its next_run_due without a completed run" ], "evidence": [ { "id": "CR-03-E1", "description": "re_validation_schedule_record per model version showing configured re-validation frequency, last_run_timestamp, next_run_due, and scheduled_suite_identifier with no unmonitored production versions", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-03-E2", "description": "scheduled_evaluation_report for each re-validation run showing benchmark results, bias metrics, and safety evaluation scores with explicit comparison to the deployment-time baseline", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "CR-03-E3", "description": "threshold_comparison_record showing the delta between current re-validation results and baseline for each metric with a pass/fail determination against the configured degradation threshold", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-03-E4", "description": "re_validation_response_record for any threshold breach, documenting the triggered response action (rollback, retraining, or escalation), responsible_party, and closure_timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-03-E5", "description": "re_validation_coverage_audit confirming all active production model versions are enrolled in re-validation schedules and that no version has exceeded its next_run_due without a completed run", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 A.6.2.4 (AI system verification and validation) requires validation evidence to remain valid; CR-03\u2019s scheduled re-validation re-produces that evidence on a risk-tiered cadence." }, { "control": "apeiris://resilience/controls/RV-01", "id": "RV-01", "domain": "resilience", "name": "AI System RTO/RPO Definition and Validation", "validation_objective": "Every production AI system must have a formally documented recovery objectives register containing its RTO and RPO values, grounded in a current business impact analysis, with validation evidence from controlled recovery tests demonstrating that actual recovery capability meets or exceeds those declared objectives within the last 12 months.", "blocking_effect": "requires-review", "evidence_required": [ "recovery_objectives_register with ai_system_id, criticality_tier, rto_minutes, rpo_minutes, bia_date, and business_owner_signoff_date for every production AI system", "controlled_recovery_test_report showing scenario_description, execution_date, declared_rto_minutes, declared_rpo_minutes, actual_rto_minutes, actual_rpo_minutes, and pass_fail verdict per system", "business_impact_analysis_document dated within 12 months referencing each AI system and the business process dependencies that drove objective setting", "formal_signoff_record from business_owner and compliance_reviewer confirming objectives are aligned with regulatory obligations" ], "evidence": [ { "id": "RV-01-E1", "description": "recovery_objectives_register with ai_system_id, criticality_tier, rto_minutes, rpo_minutes, bia_date, and business_owner_signoff_date for every production AI system", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RV-01-E2", "description": "controlled_recovery_test_report showing scenario_description, execution_date, declared_rto_minutes, declared_rpo_minutes, actual_rto_minutes, actual_rpo_minutes, and pass_fail verdict per system", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RV-01-E3", "description": "business_impact_analysis_document dated within 12 months referencing each AI system and the business process dependencies that drove objective setting", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RV-01-E4", "description": "formal_signoff_record from business_owner and compliance_reviewer confirming objectives are aligned with regulatory obligations", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://agentic/controls/AB-07", "id": "AB-07", "domain": "agentic", "name": "Behavioral Drift Monitoring", "validation_objective": "Proves that the agent platform continuously compares active behavioral fingerprints against the registered baseline and that all alerts above advisory severity are routed to a documented investigation procedure within the defined SLA. The control is satisfied when the drift detection pipeline produces signal for 100% of deployed agent instances and when all elevated and critical alerts have investigation close records.", "blocking_effect": "requires-review", "evidence_required": [ "Behavioral baseline artifact with version identifier, sha256 hash, and authorization record confirming the baseline was established through an approved change management process", "Sample of behavioral fingerprint events from at least 10 agent sessions in the audit period containing action_distribution, tool_call_frequency_vector, refusal_rate, token_length_distribution, and latency_percentiles fields", "Drift detection service configuration showing defined threshold levels for advisory, elevated, and critical severity tiers", "Alert log with investigation close records confirming SLA compliance for all elevated and critical alerts in the audit period", "Anomaly probe results demonstrating the detection pipeline returns expected signals on at least one known behavioral deviation scenario" ], "evidence": [ { "id": "AB-07-E1", "description": "Behavioral baseline artifact with version identifier, sha256 hash, and authorization record confirming the baseline was established through an approved change management process", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AB-07-E2", "description": "Sample of behavioral fingerprint events from at least 10 agent sessions in the audit period containing action_distribution, tool_call_frequency_vector, refusal_rate, token_length_distribution, and latency_percentiles fields", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AB-07-E3", "description": "Drift detection service configuration showing defined threshold levels for advisory, elevated, and critical severity tiers", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "AB-07-E4", "description": "Alert log with investigation close records confirming SLA compliance for all elevated and critical alerts in the audit period", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "AB-07-E5", "description": "Anomaly probe results demonstrating the detection pipeline returns expected signals on at least one known behavioral deviation scenario", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO 42001 requires organizations to evaluate the performance of their AI management system through monitoring and measurement. Behavioral drift monitoring provides the measurement data required to assess whether AI systems continue to perform within their authorized behavioral envelope." } ] }, { "requirement_id": "ISO42001-A.10.1", "section": "Annex A \u00a7A.10.1", "title": "Accountability for AI decision-making \u2014 Accountability assignment", "text": "The organization shall ensure clear accountability for AI system decisions and outcomes, including assignment of accountable persons and documentation of accountability chains.", "verdict": "supported", "coverage": "direct", "notes": "Principal accountability binding, model ownership assignment, senior and board-level ethics accountability, senior accountability for autonomous AI systems, and named business owner anchoring for every agent together implement comprehensive AI accountability assignment.", "control_count": 5, "proof_chain": [ { "control": "apeiris://authority/controls/PA-04", "id": "PA-04", "domain": "authority", "name": "Principal Accountability Binding", "validation_objective": "Every consequential AI action must produce an immutable accountability binding artifact atomically with the action, containing the action_id, agent_id, principal_id, delegation_basis_id, action_scope, and an integrity hash sealing the record. The artifact must be written to a tamper-evident, append-only store from which neither the AI agent nor its service account can modify or delete entries.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "accountability_binding_artifact for each consequential AI action, containing action_id, agent_id, principal_id, delegation_basis_id, action_scope, action_timestamp, and integrity_hash (sha256) \u2014 all fields must be non-null", "tamper_evident_store_audit_record confirming the binding store is append-only and that no modification or deletion events occurred for any binding artifact during the audit period", "principal_existence_validation_record confirming the principal_id referenced in each binding artifact resolves to a current, active human identity in the enterprise identity system at the time of binding", "binding_completeness_scan result confirming 100% of consequential AI actions in the audit period have a corresponding accountability binding artifact with no gaps" ], "evidence": [ { "id": "PA-04-E1", "description": "accountability_binding_artifact for each consequential AI action, containing action_id, agent_id, principal_id, delegation_basis_id, action_scope, action_timestamp, and integrity_hash (sha256) \u2014 all fields must be non-null", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PA-04-E2", "description": "tamper_evident_store_audit_record confirming the binding store is append-only and that no modification or deletion events occurred for any binding artifact during the audit period", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PA-04-E3", "description": "principal_existence_validation_record confirming the principal_id referenced in each binding artifact resolves to a current, active human identity in the enterprise identity system at the time of binding", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PA-04-E4", "description": "binding_completeness_scan result confirming 100% of consequential AI actions in the audit period have a corresponding accountability binding artifact with no gaps", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "adjacent", "basis": "anchored", "relation": "equivalent_to", "rationale": "Accountability binding operationalizes responsibility per action, distinct from the leadership commitment \u00a75.1 requires." }, { "control": "apeiris://model/controls/OA-01", "id": "OA-01", "domain": "model", "name": "Model Ownership Assignment", "validation_objective": "Every AI model in the production model registry must have a non-null named human owner who is a current employee, a responsible team, and an executive sponsor at director level or above for high-impact models, all recorded within five business days of deployment. No production model may exist without a current ownership record, and ownership must be reassigned within ten business days of any owner departure.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_ownership_register_extract with fields: model_id, owner_name, owner_employee_id, team, executive_sponsor, effective_date, review_date \u2014 showing 100% coverage of production models with non-null values", "deployment_pipeline_gate_log showing blocked promotion events for models with null ownership fields, with timestamps and model IDs", "hr_departure_event_log cross-referenced with ownership_reassignment_record demonstrating reassignment within ten business days for each departure", "governance_committee_meeting_minutes containing ownership review agenda items for the preceding 12-month period" ], "evidence": [ { "id": "OA-01-E1", "description": "model_ownership_register_extract with fields: model_id, owner_name, owner_employee_id, team, executive_sponsor, effective_date, review_date \u2014 showing 100% coverage of production models with non-null values", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-01-E2", "description": "deployment_pipeline_gate_log showing blocked promotion events for models with null ownership fields, with timestamps and model IDs", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-01-E3", "description": "hr_departure_event_log cross-referenced with ownership_reassignment_record demonstrating reassignment within ten business days for each departure", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-01-E4", "description": "governance_committee_meeting_minutes containing ownership review agenda items for the preceding 12-month period", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO 42001 Clause 5.3 requires assignment of roles, responsibilities, and authorities." }, { "control": "apeiris://ethics/controls/EG-03", "id": "EG-03", "domain": "ethics", "name": "Senior and Board-Level Ethics Accountability", "validation_objective": "The organization must have a named C-suite executive with documented AI ethics accountability and evidence of at least semi-annual board-level AI ethics briefings within the trailing 12 months. Executive performance objectives must include AI ethics KPIs linked to measurable program outcomes.", "blocking_effect": "requires-review", "evidence_required": [ "executive_accountability_assignment showing named C-suite role, documented accountability scope, and date of assignment in role description or governance framework", "board_briefing_records from past 12 months confirming AI ethics posture, material risks, and incident status were presented, with meeting minutes or attendance logs", "executive_performance_objectives document showing AI ethics KPIs included in C-suite scorecards with defined targets and measurement periods", "material_risk_escalation_procedure document defining thresholds that trigger immediate C-suite notification with named escalation contacts and SLA" ], "evidence": [ { "id": "EG-03-E1", "description": "executive_accountability_assignment showing named C-suite role, documented accountability scope, and date of assignment in role description or governance framework", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-03-E2", "description": "board_briefing_records from past 12 months confirming AI ethics posture, material risks, and incident status were presented, with meeting minutes or attendance logs", "evidence_type": "incident-record", "verification": "attested" }, { "id": "EG-03-E3", "description": "executive_performance_objectives document showing AI ethics KPIs included in C-suite scorecards with defined targets and measurement periods", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-03-E4", "description": "material_risk_escalation_procedure document defining thresholds that trigger immediate C-suite notification with named escalation contacts and SLA", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001:2023 \u00a75.1 requires top management to demonstrate leadership and commitment to the AI management system, including establishing accountability structures. This control directly operationalizes that leadership commitment requirement." }, { "control": "apeiris://agentic/controls/AG-04", "id": "AG-04", "domain": "agentic", "name": "Senior Accountability for Autonomous AI Systems", "validation_objective": "Every AI agent operating at Medium consequence tier or above has a named accountable owner recorded in both the agent registry and the enterprise risk register, and that owner has formally signed the agent's authorization scope declaration and completed their most recent annual reaffirmation.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Agent registry entries for all Medium-tier-and-above agents showing named accountable owner, seniority level, assignment date, and scope declaration reference", "Signed authorization scope declaration for each in-scope agent, bearing the accountable owner's identity and the date of most recent reaffirmation", "Enterprise risk register entries linking each in-scope agent to its named accountable owner and consequence tier", "Annual reaffirmation records for each accountable owner assignment, confirming reaffirmation within the required cadence" ], "evidence": [ { "id": "AG-04-E1", "description": "Agent registry entries for all Medium-tier-and-above agents showing named accountable owner, seniority level, assignment date, and scope declaration reference", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-04-E2", "description": "Signed authorization scope declaration for each in-scope agent, bearing the accountable owner's identity and the date of most recent reaffirmation", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-04-E3", "description": "Enterprise risk register entries linking each in-scope agent to its named accountable owner and consequence tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-04-E4", "description": "Annual reaffirmation records for each accountable owner assignment, confirming reaffirmation within the required cadence", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 Clause 5.3 requires top management to assign and communicate organizational roles and responsibilities for the AI management system. Named accountable owners with defined responsibilities, signed acceptance, and annual reaffirmation cycles directly satisfy this organizational accountability requirement." }, { "control": "apeiris://security/controls/GV-09", "id": "GV-09", "domain": "security", "name": "Anchor a named business owner to every agent (accountability)", "validation_objective": "Every production agent has a named, uniquely identified business owner bound to its workload identity before first deployment, an explicit incident RACI defining legal and operational liability, and the agent registry resolves both the business owner and engineering owner for any running agent within two minutes of an incident trigger.", "blocking_effect": "blocks-deployment", "evidence_required": [ "agent_registry_record for each production agent containing business_owner_id (unique employee or role identifier), engineering_owner_id, legal_liability_statement, and incident_raci_reference", "binding_audit_log confirming the business_owner_id field was populated and verified before the agent's first production deployment event", "incident_response_drill_record documenting a timed owner-lookup exercise where the on-call team resolved a production agent's full owner chain in under two minutes", "offboarding_check_record showing agents whose registered business owner changed roles or departed were re-assigned to a new named owner before continuity was broken" ], "evidence": [ { "id": "GV-09-E1", "description": "agent_registry_record for each production agent containing business_owner_id (unique employee or role identifier), engineering_owner_id, legal_liability_statement, and incident_raci_reference", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-09-E2", "description": "binding_audit_log confirming the business_owner_id field was populated and verified before the agent's first production deployment event", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-09-E3", "description": "incident_response_drill_record documenting a timed owner-lookup exercise where the on-call team resolved a production agent's full owner chain in under two minutes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-09-E4", "description": "offboarding_check_record showing agents whose registered business owner changed roles or departed were re-assigned to a new named owner before continuity was broken", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "adjacent", "basis": "anchored", "relation": "equivalent_to", "rationale": null } ] }, { "requirement_id": "ISO42001-A.10.2", "section": "Annex A \u00a7A.10.2", "title": "Accountability for AI decision-making \u2014 Auditability and record-keeping", "text": "The organization shall maintain records sufficient to support accountability for AI system decisions, including decision logs, model versions, and evidence of human review where applicable.", "verdict": "partial", "coverage": "partial", "notes": "Model evidence archive and audit trail, audit trail integrity, usage telemetry and decision logging, tool usage audit trail, and notice/explanation/human review and contestability controls address AI auditability. Determining which decision records require human review attestation is an organizational risk-tiering decision.", "control_count": 5, "proof_chain": [ { "control": "apeiris://model/controls/CR-02", "id": "CR-02", "domain": "model", "name": "Model Evidence Archive and Audit Trail", "validation_objective": "All evaluation results, monitoring snapshots, incident records, and regulatory submissions must be stored in an immutable, content-addressed archive with cryptographic integrity protection; any audit query for a model's historical evidence must resolve to a complete, tamper-evident chain spanning the full production lifetime of that model version.", "blocking_effect": "blocks-deployment", "evidence_required": [ "archive_integrity_configuration_record showing content-addressed storage settings, hash algorithm (minimum SHA-256), write-once immutability enforcement, and retention policy duration per record type", "evidence_chain_completeness_audit confirming that evaluation results, monitoring snapshots, and incident records for each production model version are present in the archive with no missing lifecycle entries", "tamper_detection_scan_report from periodic archive integrity verification showing all stored records produce matching content hashes with zero reported mismatches", "regulatory_submission_evidence_linkage_record linking each regulatory submission to its archived evidence artifact with submission_id, submission_date, submitting_entity, and archive_content_hash", "archive_access_control_audit_log confirming write operations are restricted to authorized pipeline components only and all access attempts are logged with actor_id and timestamp" ], "evidence": [ { "id": "CR-02-E1", "description": "archive_integrity_configuration_record showing content-addressed storage settings, hash algorithm (minimum SHA-256), write-once immutability enforcement, and retention policy duration per record type", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "CR-02-E2", "description": "evidence_chain_completeness_audit confirming that evaluation results, monitoring snapshots, and incident records for each production model version are present in the archive with no missing lifecycle entries", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-02-E3", "description": "tamper_detection_scan_report from periodic archive integrity verification showing all stored records produce matching content hashes with zero reported mismatches", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-02-E4", "description": "regulatory_submission_evidence_linkage_record linking each regulatory submission to its archived evidence artifact with submission_id, submission_date, submitting_entity, and archive_content_hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-02-E5", "description": "archive_access_control_audit_log confirming write operations are restricted to authorized pipeline components only and all access attempts are logged with actor_id and timestamp", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "CR-02 creates and maintains documented information for every AI system lifecycle event \u2014 evaluation manifests, monitoring snapshots, incident records, and regulatory submissions \u2014 in an immutable, content-addressed archive with SHA-256 hash verification and defined retention schedules of 3-year default and 10-year banking, directly satisfying ISO 42001 Clause 7.5's requirements for documented information necessary for the effectiveness of the AI management system. The Sigstore Rekor transparency-log anchoring provides the integrity assurance that Clause 7.5 requires for retained documented information." }, { "control": "apeiris://compliance/controls/AU-04", "id": "AU-04", "domain": "compliance", "name": "Audit Trail Integrity", "validation_objective": "The audit log system must maintain a cryptographically chained, append-only record of all compliance program activities \u2014 including policy attestations, control assessments, evidence submissions, and configuration changes \u2014 such that any attempt to modify, delete, or insert log records is detectable within 24 hours of occurrence. Automated daily hash chain verification must confirm log integrity continuously and alert the compliance officer within 1 hour of any detected break.", "blocking_effect": "advisory", "evidence_required": [ "cryptographic_hash_chain_report listing hash values for each log batch and chain linkage between successive batches, covering the full audit period with no unexplained gaps", "WORM_storage_replication_log confirming each log batch was replicated to immutable secondary store within 60 seconds, with source generation timestamp and secondary write timestamp for each batch", "daily_integrity_verification_report showing automated hash chain verification results, detected breaks, and alert dispatch timestamps for each verification run in the last 30 days", "log_custody_register documenting all personnel with access to log infrastructure, last quarterly access review date, and access removal records for personnel no longer requiring access", "log_gap_analysis_report confirming no unexplained gaps in log sequence numbers or timestamps for the audit period" ], "evidence": [ { "id": "AU-04-E1", "description": "cryptographic_hash_chain_report listing hash values for each log batch and chain linkage between successive batches, covering the full audit period with no unexplained gaps", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AU-04-E2", "description": "WORM_storage_replication_log confirming each log batch was replicated to immutable secondary store within 60 seconds, with source generation timestamp and secondary write timestamp for each batch", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AU-04-E3", "description": "daily_integrity_verification_report showing automated hash chain verification results, detected breaks, and alert dispatch timestamps for each verification run in the last 30 days", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "AU-04-E4", "description": "log_custody_register documenting all personnel with access to log infrastructure, last quarterly access review date, and access removal records for personnel no longer requiring access", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AU-04-E5", "description": "log_gap_analysis_report confirming no unexplained gaps in log sequence numbers or timestamps for the audit period", "evidence_type": "audit-log", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://model/controls/BH-05", "id": "BH-05", "domain": "model", "name": "Usage Telemetry and Decision Logging", "validation_objective": "Every model inference endpoint must emit a structured DecisionLog record containing input_hash (HMAC-SHA-256), caller_id, model_version, output_sample at the configured sampling rate, latency_ms, and decision_outcome; logs must be stored in an append-only tamper-evident store with daily Merkle root hash publication; and no direct PII must appear in any stored log field.", "blocking_effect": "advisory", "evidence_required": [ "DecisionLog schema documentation with field definitions, HMAC masking policy, key management system references, and output sampling rate configuration per deployment profile", "privacy review sign-off from the data protection team confirming no direct PII identifiers appear in stored log records, based on a regex scan of a trailing 30-day sample", "daily Merkle root hash publication log for trailing 90 days with fields: root_hash, computation_timestamp, and publication_destination for each daily entry", "retention policy configuration and automated deletion audit log confirming tiered retention enforcement (90-day raw, 3-year aggregated, 10-year minimum for EU high-risk deployments)", "DecisionLog query access audit trail for trailing 90 days showing all access events with requester_id, query_timestamp, and authorization_basis" ], "evidence": [ { "id": "BH-05-E1", "description": "DecisionLog schema documentation with field definitions, HMAC masking policy, key management system references, and output sampling rate configuration per deployment profile", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "BH-05-E2", "description": "privacy review sign-off from the data protection team confirming no direct PII identifiers appear in stored log records, based on a regex scan of a trailing 30-day sample", "evidence_type": "audit-log", "verification": "automated" }, { "id": "BH-05-E3", "description": "daily Merkle root hash publication log for trailing 90 days with fields: root_hash, computation_timestamp, and publication_destination for each daily entry", "evidence_type": "audit-log", "verification": "automated" }, { "id": "BH-05-E4", "description": "retention policy configuration and automated deletion audit log confirming tiered retention enforcement (90-day raw, 3-year aggregated, 10-year minimum for EU high-risk deployments)", "evidence_type": "audit-log", "verification": "automated" }, { "id": "BH-05-E5", "description": "DecisionLog query access audit trail for trailing 90 days showing all access events with requester_id, query_timestamp, and authorization_basis", "evidence_type": "audit-log", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "BH-05 implements structured documented information controls for AI inference records \u2014 including a defined schema, HMAC-SHA-256 input masking, tiered retention aligned to EU AI Act Art. 12 obligations, and a daily Merkle tree tamper-evidence mechanism \u2014 directly satisfying ISO 42001 Clause 7.5's requirement for documented information necessary for the effectiveness of the AI management system. Clause 9.1 is additionally relevant because DecisionLogs provide the raw telemetry foundation for the operational monitoring and measurement activities implemented by BH-01 through BH-04." }, { "control": "apeiris://agentic/controls/AT-07", "id": "AT-07", "domain": "agentic", "name": "Tool Usage Audit Trail", "validation_objective": "Proves that every tool call \u2014 including blocked calls \u2014 generates a complete, tamper-evident log record containing agent identity, tool ID, full input parameters for dangerous tools, response summary, authorization record reference, timestamp, and outcome, and that the log storage detects any post-write modification. No tool invocation may execute or be blocked without a corresponding audit record.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "Log completeness verification report comparing tool call counts in execution metrics against audit trail records for the same period, with zero unexplained gaps", "Hash chain integrity verification report for recent log batches confirming no tampering has been detected", "Sample log records for dangerous tool invocations confirming full (non-truncated) input parameters are captured", "SIEM or centralized logging retention configuration showing the retention period meets the longest applicable regulatory requirement", "Log pipeline health monitoring records confirming no dropped records due to write failures in the audit period" ], "evidence": [ { "id": "AT-07-E1", "description": "Log completeness verification report comparing tool call counts in execution metrics against audit trail records for the same period, with zero unexplained gaps", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AT-07-E2", "description": "Hash chain integrity verification report for recent log batches confirming no tampering has been detected", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AT-07-E3", "description": "Sample log records for dangerous tool invocations confirming full (non-truncated) input parameters are captured", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AT-07-E4", "description": "SIEM or centralized logging retention configuration showing the retention period meets the longest applicable regulatory requirement", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "AT-07-E5", "description": "Log pipeline health monitoring records confirming no dropped records due to write failures in the audit period", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO 42001 \u00a79.1 requires organizations to monitor and measure AI system performance and behavior, with records retained as evidence of conformity. A tool usage audit trail is the primary monitoring artifact for agentic AI systems, capturing all external actions taken by agents. The standard's requirement for documented evidence of AI system operation is directly satisfied by this control's logging and integrity-protection requirements." }, { "control": "apeiris://model/controls/OA-08", "id": "OA-08", "domain": "model", "name": "Notice, Explanation Support, Human Review and Contestability", "validation_objective": "The system must have a documented, legally-reviewed per-use-case applicability determination confirming which of the four obligations (notice, explanation, human review, contestability) apply; for each applicable obligation, the corresponding mechanism must be implemented, technically accurate, and operationally accessible to affected individuals without unreasonable barrier.", "blocking_effect": "requires-review", "evidence_required": [ "per-use-case applicability determination log with legal basis, applicable jurisdiction, conclusions, and reviewing counsel sign-off for each production AI deployment", "explanation mechanism validation test results confirming explanation outputs match model feature attribution (e.g., SHAP/LIME correlation > 0.8) for a representative sample of regulated decisions", "contestability process documentation showing defined SLA timelines, reviewer authority scope, and re-evaluation workflow design reviewed by legal counsel", "human review access log for trailing 12 months showing request volume, response times, reviewer qualifications, and rate of outcome changes", "sample of adverse action notices or equivalent AI disclosure documents (redacted) confirming notice delivery for regulated decision use cases" ], "evidence": [ { "id": "OA-08-E1", "description": "per-use-case applicability determination log with legal basis, applicable jurisdiction, conclusions, and reviewing counsel sign-off for each production AI deployment", "evidence_type": "audit-log", "verification": "automated" }, { "id": "OA-08-E2", "description": "explanation mechanism validation test results confirming explanation outputs match model feature attribution (e.g., SHAP/LIME correlation > 0.8) for a representative sample of regulated decisions", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "OA-08-E3", "description": "contestability process documentation showing defined SLA timelines, reviewer authority scope, and re-evaluation workflow design reviewed by legal counsel", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "OA-08-E4", "description": "human review access log for trailing 12 months showing request volume, response times, reviewer qualifications, and rate of outcome changes", "evidence_type": "audit-log", "verification": "automated" }, { "id": "OA-08-E5", "description": "sample of adverse action notices or equivalent AI disclosure documents (redacted) confirming notice delivery for regulated decision use cases", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "ISO/IEC 42001 A.8.5 (Information for interested parties) requires determining and providing information to interested parties about the AI system. OA-08\u2019s notice, explanation, and contestability mechanisms deliver that information to affected individuals." } ] } ] }, { "framework": "nist_rmf", "label": "NIST AI RMF 1.0", "source_id": "nist_rmf", "anchored": true, "currency": { "version": "1.0", "published_on": "2023-01-26", "status": "current", "retrieved_on": null }, "total_requirements": 77, "summary": { "supported": 58, "partial": 19, "unsupported": 0, "out-of-scope": 0, "controls_involved": 110, "evidence_artifacts": 480, "automatable_evidence": 132 }, "obligations": [ { "requirement_id": "GOVERN-1.1", "section": "GOVERN 1.1", "title": "Policies, processes, procedures for AI risk management", "text": "Policies, processes, procedures, and practices across the organization related to the mapping, measuring, and managing of AI risks are in place, transparent, and implemented effectively.", "verdict": "supported", "coverage": "direct", "notes": "PO-01 establishes the internal AI policy register; PG-01 monitors adherence; AG-01 provides the agentic governance structure that operationalizes policy.", "control_count": 3, "proof_chain": [ { "control": "apeiris://authority/controls/PO-01", "id": "PO-01", "domain": "authority", "name": "Internal Policy Register for AI Deployments", "validation_objective": "Every active AI deployment must have at least one current, non-expired policy register entry in the authoritative policy register, and that entry must contain version, effective date, scope, owning team, and deployment linkage fields. No AI deployment may enter or remain in production without a valid policy register reference confirmed by the deployment pipeline.", "blocking_effect": "blocks-deployment", "evidence_required": [ "policy_register_schema_document specifying required fields including policy_id, version, effective_date, expiry_date, owning_team, ai_deployment_scope, and authority_domain_applicability", "deployment_policy_linkage_audit_log confirming every active AI deployment has a corresponding current policy register entry with a non-expired effective date", "policy_register_access_control_matrix demonstrating that register modifications require dual authorization and all changes are attributed and logged", "deployment_pipeline_gate_configuration showing that AI deployment approval workflows validate the presence of a current policy register entry before proceeding" ], "evidence": [ { "id": "PO-01-E1", "description": "policy_register_schema_document specifying required fields including policy_id, version, effective_date, expiry_date, owning_team, ai_deployment_scope, and authority_domain_applicability", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-01-E2", "description": "deployment_policy_linkage_audit_log confirming every active AI deployment has a corresponding current policy register entry with a non-expired effective date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-01-E3", "description": "policy_register_access_control_matrix demonstrating that register modifications require dual authorization and all changes are attributed and logged", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-01-E4", "description": "deployment_pipeline_gate_configuration showing that AI deployment approval workflows validate the presence of a current policy register entry before proceeding", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "A register of AI governance policies operationalizes GOVERN 1.2 policy integration, partially." }, { "control": "apeiris://authority/controls/PG-01", "id": "PG-01", "domain": "authority", "name": "Policy Adherence Monitoring", "validation_objective": "All in-scope AI systems must have 100% of their active internal policies represented by machine-evaluable monitoring rules in the policy registry, with every AI system action evaluated against applicable rules in real time, and deviation alerts routed to accountable reviewers within the documented SLA.", "blocking_effect": "advisory", "evidence_required": [ "Policy registry export listing all active internal policies with corresponding machine-evaluable rule definitions, effective dates, and policy source references", "Policy evaluation engine event logs showing per-action rule evaluation outcomes, deviation alert generation timestamps, and SLA compliance metrics for the reporting period", "Compliance monitoring SLA definition document signed by the Compliance Officer, specifying alert routing targets and resolution timeframes", "Monitoring coverage report confirming the percentage of in-scope AI systems and action types evaluated against active policy rules, with no coverage gaps documented without risk acceptance" ], "evidence": [ { "id": "PG-01-E1", "description": "Policy registry export listing all active internal policies with corresponding machine-evaluable rule definitions, effective dates, and policy source references", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "PG-01-E2", "description": "Policy evaluation engine event logs showing per-action rule evaluation outcomes, deviation alert generation timestamps, and SLA compliance metrics for the reporting period", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "PG-01-E3", "description": "Compliance monitoring SLA definition document signed by the Compliance Officer, specifying alert routing targets and resolution timeframes", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "PG-01-E4", "description": "Monitoring coverage report confirming the percentage of in-scope AI systems and action types evaluated against active policy rules, with no coverage gaps documented without risk acceptance", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "Continuous adherence monitoring helps identify emergent policy risks, partially addressing MEASURE 3.1." }, { "control": "apeiris://agentic/controls/AG-01", "id": "AG-01", "domain": "agentic", "name": "Agentic AI Governance Structure", "validation_objective": "Prove that the enterprise has a ratified, operational Agentic AI Governance Committee with a documented charter, RACI matrix, and defined three-tier consequence escalation model, and that a named senior accountable owner is recorded in the enterprise risk register. Validate that the committee meets at minimum quarterly, documents decisions, and that governance approval functions as a hard deployment gate.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Ratified Agentic AI Governance Charter documenting committee scope, cross-functional membership roster, quorum requirements, meeting cadence, decision authorities, and escalation tier triggers \u2014 signed within the past 24 months and reviewed within the past 12", "Published RACI matrix covering agent design review, deployment approval, incident escalation, and program reporting with named role assignments and confirmation that 100% of deployed agents have a named governance owner", "Committee meeting minutes from the past four quarters demonstrating quorum, attendance records, and documented decisions for each session", "Enterprise risk register entry naming the senior accountable owner for the agentic AI program by individual name and role, not by position title alone", "Deployment pipeline configuration demonstrating governance approval is enforced as a blocking gate before any agent is promoted to a production environment" ], "evidence": [ { "id": "AG-01-E1", "description": "Ratified Agentic AI Governance Charter documenting committee scope, cross-functional membership roster, quorum requirements, meeting cadence, decision authorities, and escalation tier triggers \u2014 signed within the past 24 months and reviewed within the past 12", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AG-01-E2", "description": "Published RACI matrix covering agent design review, deployment approval, incident escalation, and program reporting with named role assignments and confirmation that 100% of deployed agents have a named governance owner", "evidence_type": "incident-record", "verification": "attested" }, { "id": "AG-01-E3", "description": "Committee meeting minutes from the past four quarters demonstrating quorum, attendance records, and documented decisions for each session", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AG-01-E4", "description": "Enterprise risk register entry naming the senior accountable owner for the agentic AI program by individual name and role, not by position title alone", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-01-E5", "description": "Deployment pipeline configuration demonstrating governance approval is enforced as a blocking gate before any agent is promoted to a production environment", "evidence_type": "configuration-snapshot", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN 2.1 requires roles, responsibilities, and lines of communication for AI risk management to be documented and clearly understood. A chartered agentic governance committee with defined membership, authority, and escalation paths implements this directly." } ] }, { "requirement_id": "GOVERN-1.2", "section": "GOVERN 1.2", "title": "Accountability for AI risk management", "text": "Accountability for risk management throughout an organization is established and clear.", "verdict": "supported", "coverage": "direct", "notes": "PA-04 binds principal accountability; OA-01 assigns model ownership; GV-09 anchors a named business owner to every agent.", "control_count": 3, "proof_chain": [ { "control": "apeiris://authority/controls/PA-04", "id": "PA-04", "domain": "authority", "name": "Principal Accountability Binding", "validation_objective": "Every consequential AI action must produce an immutable accountability binding artifact atomically with the action, containing the action_id, agent_id, principal_id, delegation_basis_id, action_scope, and an integrity hash sealing the record. The artifact must be written to a tamper-evident, append-only store from which neither the AI agent nor its service account can modify or delete entries.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "accountability_binding_artifact for each consequential AI action, containing action_id, agent_id, principal_id, delegation_basis_id, action_scope, action_timestamp, and integrity_hash (sha256) \u2014 all fields must be non-null", "tamper_evident_store_audit_record confirming the binding store is append-only and that no modification or deletion events occurred for any binding artifact during the audit period", "principal_existence_validation_record confirming the principal_id referenced in each binding artifact resolves to a current, active human identity in the enterprise identity system at the time of binding", "binding_completeness_scan result confirming 100% of consequential AI actions in the audit period have a corresponding accountability binding artifact with no gaps" ], "evidence": [ { "id": "PA-04-E1", "description": "accountability_binding_artifact for each consequential AI action, containing action_id, agent_id, principal_id, delegation_basis_id, action_scope, action_timestamp, and integrity_hash (sha256) \u2014 all fields must be non-null", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PA-04-E2", "description": "tamper_evident_store_audit_record confirming the binding store is append-only and that no modification or deletion events occurred for any binding artifact during the audit period", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PA-04-E3", "description": "principal_existence_validation_record confirming the principal_id referenced in each binding artifact resolves to a current, active human identity in the enterprise identity system at the time of binding", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PA-04-E4", "description": "binding_completeness_scan result confirming 100% of consequential AI actions in the audit period have a corresponding accountability binding artifact with no gaps", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://model/controls/OA-01", "id": "OA-01", "domain": "model", "name": "Model Ownership Assignment", "validation_objective": "Every AI model in the production model registry must have a non-null named human owner who is a current employee, a responsible team, and an executive sponsor at director level or above for high-impact models, all recorded within five business days of deployment. No production model may exist without a current ownership record, and ownership must be reassigned within ten business days of any owner departure.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_ownership_register_extract with fields: model_id, owner_name, owner_employee_id, team, executive_sponsor, effective_date, review_date \u2014 showing 100% coverage of production models with non-null values", "deployment_pipeline_gate_log showing blocked promotion events for models with null ownership fields, with timestamps and model IDs", "hr_departure_event_log cross-referenced with ownership_reassignment_record demonstrating reassignment within ten business days for each departure", "governance_committee_meeting_minutes containing ownership review agenda items for the preceding 12-month period" ], "evidence": [ { "id": "OA-01-E1", "description": "model_ownership_register_extract with fields: model_id, owner_name, owner_employee_id, team, executive_sponsor, effective_date, review_date \u2014 showing 100% coverage of production models with non-null values", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-01-E2", "description": "deployment_pipeline_gate_log showing blocked promotion events for models with null ownership fields, with timestamps and model IDs", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-01-E3", "description": "hr_departure_event_log cross-referenced with ownership_reassignment_record demonstrating reassignment within ten business days for each departure", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-01-E4", "description": "governance_committee_meeting_minutes containing ownership review agenda items for the preceding 12-month period", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN-2.1 (GOVERN function) provides that roles, responsibilities, and lines of communication for AI risk management are documented and clear. OA-01\u2019s named-owner register documents the ownership and accountability lines this subcategory requires for every production model." }, { "control": "apeiris://security/controls/GV-09", "id": "GV-09", "domain": "security", "name": "Anchor a named business owner to every agent (accountability)", "validation_objective": "Every production agent has a named, uniquely identified business owner bound to its workload identity before first deployment, an explicit incident RACI defining legal and operational liability, and the agent registry resolves both the business owner and engineering owner for any running agent within two minutes of an incident trigger.", "blocking_effect": "blocks-deployment", "evidence_required": [ "agent_registry_record for each production agent containing business_owner_id (unique employee or role identifier), engineering_owner_id, legal_liability_statement, and incident_raci_reference", "binding_audit_log confirming the business_owner_id field was populated and verified before the agent's first production deployment event", "incident_response_drill_record documenting a timed owner-lookup exercise where the on-call team resolved a production agent's full owner chain in under two minutes", "offboarding_check_record showing agents whose registered business owner changed roles or departed were re-assigned to a new named owner before continuity was broken" ], "evidence": [ { "id": "GV-09-E1", "description": "agent_registry_record for each production agent containing business_owner_id (unique employee or role identifier), engineering_owner_id, legal_liability_statement, and incident_raci_reference", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-09-E2", "description": "binding_audit_log confirming the business_owner_id field was populated and verified before the agent's first production deployment event", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-09-E3", "description": "incident_response_drill_record documenting a timed owner-lookup exercise where the on-call team resolved a production agent's full owner chain in under two minutes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-09-E4", "description": "offboarding_check_record showing agents whose registered business owner changed roles or departed were re-assigned to a new named owner before continuity was broken", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "adjacent", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF Govern function: cultivate and operate a culture of AI risk management, with policies, roles, accountability, and oversight. \"Anchor a named business owner to every agent (accountability)\" is a corresponding governance activity." } ] }, { "requirement_id": "GOVERN-1.3", "section": "GOVERN 1.3", "title": "AI risk culture \u2014 awareness and communication", "text": "Organizational teams are committed to a culture that considers and communicates AI risk.", "verdict": "supported", "coverage": "direct", "notes": "EF-01 operationalizes AI ethics principles; EG-04 builds capability through training; AG-01 structures governance for agentic risk communication.", "control_count": 3, "proof_chain": [ { "control": "apeiris://ethics/controls/EF-01", "id": "EF-01", "domain": "ethics", "name": "Ethics Principles Adoption and Operationalization", "validation_objective": "The Ethics Principles Register must exist as a versioned, governance-approved document in which every adopted ethics principle has a named operational owner and a documented operational definition specifying measurable requirements, prohibited design patterns, and evaluation criteria. Every AI system intake record must reference the current register version before engineering resources are allocated.", "blocking_effect": "blocks-deployment", "evidence_required": [ "ethics_principles_register document with version, approval_date, and each adopted principle mapped to a named operational_owner, measurable_requirements list, prohibited_design_patterns list, and evaluation_criteria", "ai_system_intake_form records for all active AI systems confirming a non-null ethics_principles_register_version field referencing the current register version", "annual_review_record with completion_date, reviewer_identity, and change_log for the current 12-month review cycle", "governance_approval_record showing working group and executive or board sign-off on the current register version" ], "evidence": [ { "id": "EF-01-E1", "description": "ethics_principles_register document with version, approval_date, and each adopted principle mapped to a named operational_owner, measurable_requirements list, prohibited_design_patterns list, and evaluation_criteria", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-01-E2", "description": "ai_system_intake_form records for all active AI systems confirming a non-null ethics_principles_register_version field referencing the current register version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-01-E3", "description": "annual_review_record with completion_date, reviewer_identity, and change_log for the current 12-month review cycle", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EF-01-E4", "description": "governance_approval_record showing working group and executive or board sign-off on the current register version", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN 1.2 requires that the characteristics of trustworthy AI are integrated into organizational policies, processes, and practices, and GOVERN 2.1 requires that roles, responsibilities, and lines of communication for AI risk management are documented. The Ethics Principles Register with named principle owners satisfies both." }, { "control": "apeiris://ethics/controls/EG-04", "id": "EG-04", "domain": "ethics", "name": "Ethics Training and Capability Building", "validation_objective": "All personnel with AI development, deployment, or governance responsibilities must have completed role-appropriate ethics training within the past 12 months, with training prerequisites enforced as a gate for AI system access and product sign-off authority. Training curricula must be role-differentiated across at least four tracks covering practitioners, product managers, legal/compliance, and executives.", "blocking_effect": "blocks-deployment", "evidence_required": [ "training_completion_records disaggregated by role (AI practitioner, product manager, legal/compliance, executive) showing completion date, curriculum version, and assessment score for each individual within the trailing 12 months", "role_differentiated_curriculum_documentation showing distinct training tracks for each AI-facing role with topic coverage including fairness metrics, bias detection, regulatory obligations, and escalation procedures", "system_access_prerequisite_log confirming ethics training completion status was verified before granting AI development environment access or product approval authority", "training_refresh_trigger_record documenting evaluation of training currency following major regulatory changes with decision rationale and revised curriculum effective date where applicable" ], "evidence": [ { "id": "EG-04-E1", "description": "training_completion_records disaggregated by role (AI practitioner, product manager, legal/compliance, executive) showing completion date, curriculum version, and assessment score for each individual within the trailing 12 months", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-04-E2", "description": "role_differentiated_curriculum_documentation showing distinct training tracks for each AI-facing role with topic coverage including fairness metrics, bias detection, regulatory obligations, and escalation procedures", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-04-E3", "description": "system_access_prerequisite_log confirming ethics training completion status was verified before granting AI development environment access or product approval authority", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EG-04-E4", "description": "training_refresh_trigger_record documenting evaluation of training currency following major regulatory changes with decision rationale and revised curriculum effective date where applicable", "evidence_type": "evaluation-scorecard", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN 2.2 requires that the organization's personnel and partners receive AI risk management training to enable them to fulfill their duties and responsibilities. This control implements that training requirement with role-differentiated ethics curricula." }, { "control": "apeiris://agentic/controls/AG-01", "id": "AG-01", "domain": "agentic", "name": "Agentic AI Governance Structure", "validation_objective": "Prove that the enterprise has a ratified, operational Agentic AI Governance Committee with a documented charter, RACI matrix, and defined three-tier consequence escalation model, and that a named senior accountable owner is recorded in the enterprise risk register. Validate that the committee meets at minimum quarterly, documents decisions, and that governance approval functions as a hard deployment gate.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Ratified Agentic AI Governance Charter documenting committee scope, cross-functional membership roster, quorum requirements, meeting cadence, decision authorities, and escalation tier triggers \u2014 signed within the past 24 months and reviewed within the past 12", "Published RACI matrix covering agent design review, deployment approval, incident escalation, and program reporting with named role assignments and confirmation that 100% of deployed agents have a named governance owner", "Committee meeting minutes from the past four quarters demonstrating quorum, attendance records, and documented decisions for each session", "Enterprise risk register entry naming the senior accountable owner for the agentic AI program by individual name and role, not by position title alone", "Deployment pipeline configuration demonstrating governance approval is enforced as a blocking gate before any agent is promoted to a production environment" ], "evidence": [ { "id": "AG-01-E1", "description": "Ratified Agentic AI Governance Charter documenting committee scope, cross-functional membership roster, quorum requirements, meeting cadence, decision authorities, and escalation tier triggers \u2014 signed within the past 24 months and reviewed within the past 12", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AG-01-E2", "description": "Published RACI matrix covering agent design review, deployment approval, incident escalation, and program reporting with named role assignments and confirmation that 100% of deployed agents have a named governance owner", "evidence_type": "incident-record", "verification": "attested" }, { "id": "AG-01-E3", "description": "Committee meeting minutes from the past four quarters demonstrating quorum, attendance records, and documented decisions for each session", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AG-01-E4", "description": "Enterprise risk register entry naming the senior accountable owner for the agentic AI program by individual name and role, not by position title alone", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-01-E5", "description": "Deployment pipeline configuration demonstrating governance approval is enforced as a blocking gate before any agent is promoted to a production environment", "evidence_type": "configuration-snapshot", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN 2.1 requires roles, responsibilities, and lines of communication for AI risk management to be documented and clearly understood. A chartered agentic governance committee with defined membership, authority, and escalation paths implements this directly." } ] }, { "requirement_id": "GOVERN-1.4", "section": "GOVERN 1.4", "title": "AI risk training for organizational roles", "text": "Organizational teams are committed to a culture that considers and communicates AI risk, including staff training on their specific roles.", "verdict": "partial", "coverage": "partial", "notes": "EG-04 covers ethics training and capability building; OA-03 defines the governance committee structure. Role-specific training curricula and formal competency frameworks are not explicitly covered across all deployment scenarios.", "control_count": 2, "proof_chain": [ { "control": "apeiris://ethics/controls/EG-04", "id": "EG-04", "domain": "ethics", "name": "Ethics Training and Capability Building", "validation_objective": "All personnel with AI development, deployment, or governance responsibilities must have completed role-appropriate ethics training within the past 12 months, with training prerequisites enforced as a gate for AI system access and product sign-off authority. Training curricula must be role-differentiated across at least four tracks covering practitioners, product managers, legal/compliance, and executives.", "blocking_effect": "blocks-deployment", "evidence_required": [ "training_completion_records disaggregated by role (AI practitioner, product manager, legal/compliance, executive) showing completion date, curriculum version, and assessment score for each individual within the trailing 12 months", "role_differentiated_curriculum_documentation showing distinct training tracks for each AI-facing role with topic coverage including fairness metrics, bias detection, regulatory obligations, and escalation procedures", "system_access_prerequisite_log confirming ethics training completion status was verified before granting AI development environment access or product approval authority", "training_refresh_trigger_record documenting evaluation of training currency following major regulatory changes with decision rationale and revised curriculum effective date where applicable" ], "evidence": [ { "id": "EG-04-E1", "description": "training_completion_records disaggregated by role (AI practitioner, product manager, legal/compliance, executive) showing completion date, curriculum version, and assessment score for each individual within the trailing 12 months", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-04-E2", "description": "role_differentiated_curriculum_documentation showing distinct training tracks for each AI-facing role with topic coverage including fairness metrics, bias detection, regulatory obligations, and escalation procedures", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-04-E3", "description": "system_access_prerequisite_log confirming ethics training completion status was verified before granting AI development environment access or product approval authority", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EG-04-E4", "description": "training_refresh_trigger_record documenting evaluation of training currency following major regulatory changes with decision rationale and revised curriculum effective date where applicable", "evidence_type": "evaluation-scorecard", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN 2.2 requires that the organization's personnel and partners receive AI risk management training to enable them to fulfill their duties and responsibilities. This control implements that training requirement with role-differentiated ethics curricula." }, { "control": "apeiris://model/controls/OA-03", "id": "OA-03", "domain": "model", "name": "AI Model Governance Committee", "validation_objective": "The organization must have a formally chartered AI Model Governance Committee with documented membership covering all required functional areas, exclusive approval authority over high-risk model deployments and risk appetite thresholds, and auditable meeting minutes retained for seven years. The committee must have met at minimum quarterly in each of the preceding four quarters, with quorum achieved for all binding decisions.", "blocking_effect": "blocks-deployment", "evidence_required": [ "committee_charter current version with executive-level approval signature and date, specifying membership composition, decision rights matrix, quorum requirements, and meeting cadence", "meeting_minutes for all scheduled quarterly sessions in the preceding 12-month period, demonstrating quorum was met and binding decisions were recorded with rationale", "decision_log showing AIGC approval records for all high-risk model deployments and risk appetite changes in the preceding 12 months, cross-referenced against the production model registry", "membership_roster with functional affiliations confirming representation from AI/ML engineering, model validation, legal/compliance, risk management, and at least one business line" ], "evidence": [ { "id": "OA-03-E1", "description": "committee_charter current version with executive-level approval signature and date, specifying membership composition, decision rights matrix, quorum requirements, and meeting cadence", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-03-E2", "description": "meeting_minutes for all scheduled quarterly sessions in the preceding 12-month period, demonstrating quorum was met and binding decisions were recorded with rationale", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-03-E3", "description": "decision_log showing AIGC approval records for all high-risk model deployments and risk appetite changes in the preceding 12 months, cross-referenced against the production model registry", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-03-E4", "description": "membership_roster with functional affiliations confirming representation from AI/ML engineering, model validation, legal/compliance, risk management, and at least one business line", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN-2.3 (GOVERN function) provides that executive leadership takes responsibility for decisions about risks associated with AI development and deployment. OA-03\u2019s chartered governance committee gives executive leadership a standing forum in which those risk decisions are taken and recorded." } ] }, { "requirement_id": "GOVERN-1.5", "section": "GOVERN 1.5", "title": "Organizational risk policies reflect AI risk", "text": "Organizational risk policies and governance procedures reflect AI risk and are updated as AI risk profiles change.", "verdict": "supported", "coverage": "direct", "notes": "PO-01 maintains the internal AI policy register; PO-02 governs version control and distribution; AG-02 enforces a pre-deployment review gate as policies change.", "control_count": 3, "proof_chain": [ { "control": "apeiris://authority/controls/PO-01", "id": "PO-01", "domain": "authority", "name": "Internal Policy Register for AI Deployments", "validation_objective": "Every active AI deployment must have at least one current, non-expired policy register entry in the authoritative policy register, and that entry must contain version, effective date, scope, owning team, and deployment linkage fields. No AI deployment may enter or remain in production without a valid policy register reference confirmed by the deployment pipeline.", "blocking_effect": "blocks-deployment", "evidence_required": [ "policy_register_schema_document specifying required fields including policy_id, version, effective_date, expiry_date, owning_team, ai_deployment_scope, and authority_domain_applicability", "deployment_policy_linkage_audit_log confirming every active AI deployment has a corresponding current policy register entry with a non-expired effective date", "policy_register_access_control_matrix demonstrating that register modifications require dual authorization and all changes are attributed and logged", "deployment_pipeline_gate_configuration showing that AI deployment approval workflows validate the presence of a current policy register entry before proceeding" ], "evidence": [ { "id": "PO-01-E1", "description": "policy_register_schema_document specifying required fields including policy_id, version, effective_date, expiry_date, owning_team, ai_deployment_scope, and authority_domain_applicability", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-01-E2", "description": "deployment_policy_linkage_audit_log confirming every active AI deployment has a corresponding current policy register entry with a non-expired effective date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-01-E3", "description": "policy_register_access_control_matrix demonstrating that register modifications require dual authorization and all changes are attributed and logged", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-01-E4", "description": "deployment_pipeline_gate_configuration showing that AI deployment approval workflows validate the presence of a current policy register entry before proceeding", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "A register of AI governance policies operationalizes GOVERN 1.2 policy integration, partially." }, { "control": "apeiris://authority/controls/PO-02", "id": "PO-02", "domain": "authority", "name": "Policy Version Control and Distribution", "validation_objective": "All AI authority policies must be stored in a version-controlled repository with semantic versioning and approval-gated merges, and every AI system runtime configuration must reference a specific approved policy version. Upon a policy version update, all linked AI system configurations must be updated to the new version within one business day, and all superseded versions must be retained in an immutable archive with their effective date ranges intact.", "blocking_effect": "blocks-deployment", "evidence_required": [ "policy_version_distribution_log showing each policy version publication event, the list of linked AI system configurations notified, and the timestamp of configuration update for each consumer", "ai_runtime_policy_version_references confirming each active AI system references a specific approved policy version rather than an unversioned label", "policy_archive_effective_date_ranges document confirming all superseded policy versions are retained with their start and end effective dates", "policy_repository_approval_log showing committer attribution and approval workflow completion for every version merge during the audit period" ], "evidence": [ { "id": "PO-02-E1", "description": "policy_version_distribution_log showing each policy version publication event, the list of linked AI system configurations notified, and the timestamp of configuration update for each consumer", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "PO-02-E2", "description": "ai_runtime_policy_version_references confirming each active AI system references a specific approved policy version rather than an unversioned label", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PO-02-E3", "description": "policy_archive_effective_date_ranges document confirming all superseded policy versions are retained with their start and end effective dates", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-02-E4", "description": "policy_repository_approval_log showing committer attribution and approval workflow completion for every version merge during the audit period", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "Keeping AI systems on current approved policy versions partially operationalizes GOVERN 1.2 policy integration." }, { "control": "apeiris://agentic/controls/AG-02", "id": "AG-02", "domain": "agentic", "name": "Agent Deployment Policy and Pre-Deployment Review Gate", "validation_objective": "Every production AI agent has a signed, complete deployment approval record meeting the requirements of its assigned consequence tier, and the CI/CD pipeline enforces a hard gate that blocks promotion when that record is absent, expired, or incomplete.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Ratified Agent Deployment Policy document defining consequence tiers, approval authorities, mandatory review artifacts, and maximum approval validity period", "Signed deployment approval record for each production agent, including agent ID, consequence tier, capability manifest hash, authorization scope declaration, and reviewer identity", "CI/CD pipeline audit log showing gate enforcement events (approvals, rejections, blocks) with timestamps and artifact hashes", "Agent consequence tier assignment records linked to the deployment approval for each production agent", "Monitoring configuration validation artifact confirming SOC integration requirements were satisfied at approval time" ], "evidence": [ { "id": "AG-02-E1", "description": "Ratified Agent Deployment Policy document defining consequence tiers, approval authorities, mandatory review artifacts, and maximum approval validity period", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AG-02-E2", "description": "Signed deployment approval record for each production agent, including agent ID, consequence tier, capability manifest hash, authorization scope declaration, and reviewer identity", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "AG-02-E3", "description": "CI/CD pipeline audit log showing gate enforcement events (approvals, rejections, blocks) with timestamps and artifact hashes", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AG-02-E4", "description": "Agent consequence tier assignment records linked to the deployment approval for each production agent", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AG-02-E5", "description": "Monitoring configuration validation artifact confirming SOC integration requirements were satisfied at approval time", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP 5.1 requires the likelihood and magnitude of each identified impact to be assessed based on intended use and deployment context. The pre-deployment review gate's consequence tier assessment is that impact assessment, performed before any agent reaches production." } ] }, { "requirement_id": "GOVERN-1.6", "section": "GOVERN 1.6", "title": "AI risk management policies communicated to staff", "text": "Policies and procedures for AI risk management are communicated to and understood by organizational staff.", "verdict": "partial", "coverage": "partial", "notes": "PO-02 addresses policy distribution; EG-04 covers ethics training. Formal attestation that all staff have received and understood AI risk policies is not fully specified in the current control set.", "control_count": 2, "proof_chain": [ { "control": "apeiris://authority/controls/PO-02", "id": "PO-02", "domain": "authority", "name": "Policy Version Control and Distribution", "validation_objective": "All AI authority policies must be stored in a version-controlled repository with semantic versioning and approval-gated merges, and every AI system runtime configuration must reference a specific approved policy version. Upon a policy version update, all linked AI system configurations must be updated to the new version within one business day, and all superseded versions must be retained in an immutable archive with their effective date ranges intact.", "blocking_effect": "blocks-deployment", "evidence_required": [ "policy_version_distribution_log showing each policy version publication event, the list of linked AI system configurations notified, and the timestamp of configuration update for each consumer", "ai_runtime_policy_version_references confirming each active AI system references a specific approved policy version rather than an unversioned label", "policy_archive_effective_date_ranges document confirming all superseded policy versions are retained with their start and end effective dates", "policy_repository_approval_log showing committer attribution and approval workflow completion for every version merge during the audit period" ], "evidence": [ { "id": "PO-02-E1", "description": "policy_version_distribution_log showing each policy version publication event, the list of linked AI system configurations notified, and the timestamp of configuration update for each consumer", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "PO-02-E2", "description": "ai_runtime_policy_version_references confirming each active AI system references a specific approved policy version rather than an unversioned label", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PO-02-E3", "description": "policy_archive_effective_date_ranges document confirming all superseded policy versions are retained with their start and end effective dates", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-02-E4", "description": "policy_repository_approval_log showing committer attribution and approval workflow completion for every version merge during the audit period", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "Keeping AI systems on current approved policy versions partially operationalizes GOVERN 1.2 policy integration." }, { "control": "apeiris://ethics/controls/EG-04", "id": "EG-04", "domain": "ethics", "name": "Ethics Training and Capability Building", "validation_objective": "All personnel with AI development, deployment, or governance responsibilities must have completed role-appropriate ethics training within the past 12 months, with training prerequisites enforced as a gate for AI system access and product sign-off authority. Training curricula must be role-differentiated across at least four tracks covering practitioners, product managers, legal/compliance, and executives.", "blocking_effect": "blocks-deployment", "evidence_required": [ "training_completion_records disaggregated by role (AI practitioner, product manager, legal/compliance, executive) showing completion date, curriculum version, and assessment score for each individual within the trailing 12 months", "role_differentiated_curriculum_documentation showing distinct training tracks for each AI-facing role with topic coverage including fairness metrics, bias detection, regulatory obligations, and escalation procedures", "system_access_prerequisite_log confirming ethics training completion status was verified before granting AI development environment access or product approval authority", "training_refresh_trigger_record documenting evaluation of training currency following major regulatory changes with decision rationale and revised curriculum effective date where applicable" ], "evidence": [ { "id": "EG-04-E1", "description": "training_completion_records disaggregated by role (AI practitioner, product manager, legal/compliance, executive) showing completion date, curriculum version, and assessment score for each individual within the trailing 12 months", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-04-E2", "description": "role_differentiated_curriculum_documentation showing distinct training tracks for each AI-facing role with topic coverage including fairness metrics, bias detection, regulatory obligations, and escalation procedures", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-04-E3", "description": "system_access_prerequisite_log confirming ethics training completion status was verified before granting AI development environment access or product approval authority", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EG-04-E4", "description": "training_refresh_trigger_record documenting evaluation of training currency following major regulatory changes with decision rationale and revised curriculum effective date where applicable", "evidence_type": "evaluation-scorecard", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN 2.2 requires that the organization's personnel and partners receive AI risk management training to enable them to fulfill their duties and responsibilities. This control implements that training requirement with role-differentiated ethics curricula." } ] }, { "requirement_id": "GOVERN-1.7", "section": "GOVERN 1.7", "title": "Processes for oversight of AI risks", "text": "Processes and procedures for overseeing AI risks, including risk owners and governance bodies, are in place.", "verdict": "supported", "coverage": "direct", "notes": "OA-02 mandates meaningful human oversight for high-stakes decisions; GV-01 enforces a human hard-stop for irreversible actions; AG-03 provides the formal agentic AI risk assessment framework.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/OA-02", "id": "OA-02", "domain": "model", "name": "Meaningful Human Oversight for High-Stakes Decisions", "validation_objective": "For every high-impact-decision or eu-high-risk model, a human reviewer must have documented access to model inputs, confidence scores, and reasoning; organizational authority to override without penalty; domain competence verified through training records; and a technically effective override mechanism before any AI output takes effect. Override rates must be monitored and a rate near zero for 30 consecutive days must automatically trigger a governance review.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "five_factor_oversight_design_document per high-stakes use case, signed by the AI governance committee, covering: review time allocation, information display design, override authority documentation, competence requirements, and override mechanism technical specification", "override_rate_time_series report for the past 12 months broken down by model, decision type, and reviewer cohort \u2014 with governance-defined floor thresholds annotated", "reviewer_training_completion_record including initial onboarding completion date, annual recertification dates, competence assessment scores, and automation-bias module completion", "override_mechanism_test_log confirming that override actions propagate correctly through downstream systems without requiring secondary approval" ], "evidence": [ { "id": "OA-02-E1", "description": "five_factor_oversight_design_document per high-stakes use case, signed by the AI governance committee, covering: review time allocation, information display design, override authority documentation, competence requirements, and override mechanism technical specification", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-02-E2", "description": "override_rate_time_series report for the past 12 months broken down by model, decision type, and reviewer cohort \u2014 with governance-defined floor thresholds annotated", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-02-E3", "description": "reviewer_training_completion_record including initial onboarding completion date, annual recertification dates, competence assessment scores, and automation-bias module completion", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-02-E4", "description": "override_mechanism_test_log confirming that override actions propagate correctly through downstream systems without requiring secondary approval", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN-3.2 (GOVERN function) provides that policies define and differentiate roles and responsibilities for human-AI configurations and oversight. OA-02\u2019s five-factor oversight adequacy framework defines and verifies the human-oversight roles this subcategory calls for." }, { "control": "apeiris://security/controls/GV-01", "id": "GV-01", "domain": "security", "name": "Require a human hard-stop for irreversible actions", "validation_objective": "Every irreversible agent action (write, deletion, transfer, deployment, or any action with no safe undo path) must be deterministically halted and routed to an explicit human (or quorum) approval before execution; the agent must not be capable of self-approving such actions, and the hard-stop must be enforced at platform infrastructure level, not by a model-layer instruction.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "irreversible_action_approval_record linking each halted action to the human approver(s), approval_token with timestamp and cryptographic signature, and action outcome (executed/cancelled)", "irreversibility_classification_list identifying which action types are classified as irreversible, with the policy_version and last_review_date", "hard_stop_enforcement_log showing agent execution was suspended at the irreversible action gate and resumed only after receipt of a valid external approval token", "self_approval_rejection_log confirming any attempt by the agent to approve its own irreversible actions was blocked by the platform", "quorum_policy_record for high-stakes action categories specifying minimum required approvers and approval token validity window" ], "evidence": [ { "id": "GV-01-E1", "description": "irreversible_action_approval_record linking each halted action to the human approver(s), approval_token with timestamp and cryptographic signature, and action outcome (executed/cancelled)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-01-E2", "description": "irreversibility_classification_list identifying which action types are classified as irreversible, with the policy_version and last_review_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-01-E3", "description": "hard_stop_enforcement_log showing agent execution was suspended at the irreversible action gate and resumed only after receipt of a valid external approval token", "evidence_type": "human-review-record", "verification": "human" }, { "id": "GV-01-E4", "description": "self_approval_rejection_log confirming any attempt by the agent to approve its own irreversible actions was blocked by the platform", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-01-E5", "description": "quorum_policy_record for high-stakes action categories specifying minimum required approvers and approval token validity window", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "adjacent", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF Govern function: cultivate and operate a culture of AI risk management, with policies, roles, accountability, and oversight. \"Require a human hard-stop for irreversible actions\" is a corresponding governance activity." }, { "control": "apeiris://agentic/controls/AG-03", "id": "AG-03", "domain": "agentic", "name": "Agentic AI Risk Assessment Framework", "validation_objective": "Every production AI agent has a completed, current risk assessment evaluated against all five framework dimensions, with the resulting consequence tier documented and linked to the deployment approval and control mitigation plan.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "Annual risk reassessment records for all Critical-tier agents" ], "evidence": [ { "id": "AG-03-E1", "description": "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E2", "description": "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E3", "description": "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E4", "description": "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E5", "description": "Annual risk reassessment records for all Critical-tier agents", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP 5.1 requires assessing the likelihood and magnitude of identified AI impacts in deployment context. The five-dimension agentic risk scoring model is a structured method for exactly that assessment across autonomy, reversibility, and blast-radius dimensions." } ] }, { "requirement_id": "GOVERN-2.1", "section": "GOVERN 2.1", "title": "Roles, responsibilities, and organizational structures for AI risk", "text": "Roles and responsibilities and organizational structures to support effective AI risk management are in place.", "verdict": "supported", "coverage": "direct", "notes": "OA-03 establishes the AI Model Governance Committee; EG-01 defines the ethics governance structure; AG-01 defines agentic AI governance; together these create a full organizational coverage.", "control_count": 4, "proof_chain": [ { "control": "apeiris://model/controls/OA-03", "id": "OA-03", "domain": "model", "name": "AI Model Governance Committee", "validation_objective": "The organization must have a formally chartered AI Model Governance Committee with documented membership covering all required functional areas, exclusive approval authority over high-risk model deployments and risk appetite thresholds, and auditable meeting minutes retained for seven years. The committee must have met at minimum quarterly in each of the preceding four quarters, with quorum achieved for all binding decisions.", "blocking_effect": "blocks-deployment", "evidence_required": [ "committee_charter current version with executive-level approval signature and date, specifying membership composition, decision rights matrix, quorum requirements, and meeting cadence", "meeting_minutes for all scheduled quarterly sessions in the preceding 12-month period, demonstrating quorum was met and binding decisions were recorded with rationale", "decision_log showing AIGC approval records for all high-risk model deployments and risk appetite changes in the preceding 12 months, cross-referenced against the production model registry", "membership_roster with functional affiliations confirming representation from AI/ML engineering, model validation, legal/compliance, risk management, and at least one business line" ], "evidence": [ { "id": "OA-03-E1", "description": "committee_charter current version with executive-level approval signature and date, specifying membership composition, decision rights matrix, quorum requirements, and meeting cadence", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-03-E2", "description": "meeting_minutes for all scheduled quarterly sessions in the preceding 12-month period, demonstrating quorum was met and binding decisions were recorded with rationale", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-03-E3", "description": "decision_log showing AIGC approval records for all high-risk model deployments and risk appetite changes in the preceding 12 months, cross-referenced against the production model registry", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-03-E4", "description": "membership_roster with functional affiliations confirming representation from AI/ML engineering, model validation, legal/compliance, risk management, and at least one business line", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN-2.3 (GOVERN function) provides that executive leadership takes responsibility for decisions about risks associated with AI development and deployment. OA-03\u2019s chartered governance committee gives executive leadership a standing forum in which those risk decisions are taken and recorded." }, { "control": "apeiris://ethics/controls/EG-01", "id": "EG-01", "domain": "ethics", "name": "Ethics Governance Structure", "validation_objective": "The enterprise must have an active, formally chartered AI Ethics Board with documented cross-functional membership, defined decision authority over high-risk AI deployments, a functioning escalation path from individual teams to the board, and evidence of executive-level reporting within the past 90 days. The control passes if an Ethics Board charter exists, meeting minutes and decision logs are complete for the trailing 12 months, all high-risk AI systems have Ethics Board approval records, and at least one escalation was exercised and documented.", "blocking_effect": "blocks-deployment", "evidence_required": [ "AI Ethics Board charter document signed at C-suite or board authority level, specifying membership criteria, quorum rules, decision authority scope over high-risk AI deployment approvals, and meeting cadence", "Ethics Board meeting minutes for the trailing 12 months showing dates, attendees, agenda items, decision log entries, and executive or board-level reporting records confirming required governance cadence", "Escalation path documentation distributed to all AI product teams showing the path from individual contributor to Ethics Board with named contacts at each level and documented response SLAs", "Ethics Board decision log entries for AI deployment approvals or rejections in the trailing 12 months, confirming high-risk AI systems passed through the formal governance process", "Evidence of at least one ethics escalation exercised through the documented escalation path, with intake record, investigation record, Ethics Board disposition, and outcome notification to the escalating party" ], "evidence": [ { "id": "EG-01-E1", "description": "AI Ethics Board charter document signed at C-suite or board authority level, specifying membership criteria, quorum rules, decision authority scope over high-risk AI deployment approvals, and meeting cadence", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-01-E2", "description": "Ethics Board meeting minutes for the trailing 12 months showing dates, attendees, agenda items, decision log entries, and executive or board-level reporting records confirming required governance cadence", "evidence_type": "audit-log", "verification": "automated" }, { "id": "EG-01-E3", "description": "Escalation path documentation distributed to all AI product teams showing the path from individual contributor to Ethics Board with named contacts at each level and documented response SLAs", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-01-E4", "description": "Ethics Board decision log entries for AI deployment approvals or rejections in the trailing 12 months, confirming high-risk AI systems passed through the formal governance process", "evidence_type": "audit-log", "verification": "automated" }, { "id": "EG-01-E5", "description": "Evidence of at least one ethics escalation exercised through the documented escalation path, with intake record, investigation record, Ethics Board disposition, and outcome notification to the escalating party", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN 2.1 requires that roles, responsibilities, and lines of communication related to mapping, measuring, and managing AI risks are documented and clear. An Ethics Board with a documented charter, defined membership, and formal escalation paths directly implements this governance subcategory." }, { "control": "apeiris://agentic/controls/AG-01", "id": "AG-01", "domain": "agentic", "name": "Agentic AI Governance Structure", "validation_objective": "Prove that the enterprise has a ratified, operational Agentic AI Governance Committee with a documented charter, RACI matrix, and defined three-tier consequence escalation model, and that a named senior accountable owner is recorded in the enterprise risk register. Validate that the committee meets at minimum quarterly, documents decisions, and that governance approval functions as a hard deployment gate.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Ratified Agentic AI Governance Charter documenting committee scope, cross-functional membership roster, quorum requirements, meeting cadence, decision authorities, and escalation tier triggers \u2014 signed within the past 24 months and reviewed within the past 12", "Published RACI matrix covering agent design review, deployment approval, incident escalation, and program reporting with named role assignments and confirmation that 100% of deployed agents have a named governance owner", "Committee meeting minutes from the past four quarters demonstrating quorum, attendance records, and documented decisions for each session", "Enterprise risk register entry naming the senior accountable owner for the agentic AI program by individual name and role, not by position title alone", "Deployment pipeline configuration demonstrating governance approval is enforced as a blocking gate before any agent is promoted to a production environment" ], "evidence": [ { "id": "AG-01-E1", "description": "Ratified Agentic AI Governance Charter documenting committee scope, cross-functional membership roster, quorum requirements, meeting cadence, decision authorities, and escalation tier triggers \u2014 signed within the past 24 months and reviewed within the past 12", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AG-01-E2", "description": "Published RACI matrix covering agent design review, deployment approval, incident escalation, and program reporting with named role assignments and confirmation that 100% of deployed agents have a named governance owner", "evidence_type": "incident-record", "verification": "attested" }, { "id": "AG-01-E3", "description": "Committee meeting minutes from the past four quarters demonstrating quorum, attendance records, and documented decisions for each session", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AG-01-E4", "description": "Enterprise risk register entry naming the senior accountable owner for the agentic AI program by individual name and role, not by position title alone", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-01-E5", "description": "Deployment pipeline configuration demonstrating governance approval is enforced as a blocking gate before any agent is promoted to a production environment", "evidence_type": "configuration-snapshot", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN 2.1 requires roles, responsibilities, and lines of communication for AI risk management to be documented and clearly understood. A chartered agentic governance committee with defined membership, authority, and escalation paths implements this directly." }, { "control": "apeiris://authority/controls/PO-01", "id": "PO-01", "domain": "authority", "name": "Internal Policy Register for AI Deployments", "validation_objective": "Every active AI deployment must have at least one current, non-expired policy register entry in the authoritative policy register, and that entry must contain version, effective date, scope, owning team, and deployment linkage fields. No AI deployment may enter or remain in production without a valid policy register reference confirmed by the deployment pipeline.", "blocking_effect": "blocks-deployment", "evidence_required": [ "policy_register_schema_document specifying required fields including policy_id, version, effective_date, expiry_date, owning_team, ai_deployment_scope, and authority_domain_applicability", "deployment_policy_linkage_audit_log confirming every active AI deployment has a corresponding current policy register entry with a non-expired effective date", "policy_register_access_control_matrix demonstrating that register modifications require dual authorization and all changes are attributed and logged", "deployment_pipeline_gate_configuration showing that AI deployment approval workflows validate the presence of a current policy register entry before proceeding" ], "evidence": [ { "id": "PO-01-E1", "description": "policy_register_schema_document specifying required fields including policy_id, version, effective_date, expiry_date, owning_team, ai_deployment_scope, and authority_domain_applicability", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-01-E2", "description": "deployment_policy_linkage_audit_log confirming every active AI deployment has a corresponding current policy register entry with a non-expired effective date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-01-E3", "description": "policy_register_access_control_matrix demonstrating that register modifications require dual authorization and all changes are attributed and logged", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-01-E4", "description": "deployment_pipeline_gate_configuration showing that AI deployment approval workflows validate the presence of a current policy register entry before proceeding", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "A register of AI governance policies operationalizes GOVERN 1.2 policy integration, partially." } ] }, { "requirement_id": "GOVERN-2.2", "section": "GOVERN 2.2", "title": "AI risk management training for personnel and partners", "text": "The organization's personnel and partners receive AI risk management training to enable them to perform their duties and responsibilities.", "verdict": "partial", "coverage": "partial", "notes": "EG-04 addresses training and capability building; OA-03 defines the committee structure. Training extension to external partners and third-party entities is not explicitly addressed in the controls mapped here.", "control_count": 2, "proof_chain": [ { "control": "apeiris://ethics/controls/EG-04", "id": "EG-04", "domain": "ethics", "name": "Ethics Training and Capability Building", "validation_objective": "All personnel with AI development, deployment, or governance responsibilities must have completed role-appropriate ethics training within the past 12 months, with training prerequisites enforced as a gate for AI system access and product sign-off authority. Training curricula must be role-differentiated across at least four tracks covering practitioners, product managers, legal/compliance, and executives.", "blocking_effect": "blocks-deployment", "evidence_required": [ "training_completion_records disaggregated by role (AI practitioner, product manager, legal/compliance, executive) showing completion date, curriculum version, and assessment score for each individual within the trailing 12 months", "role_differentiated_curriculum_documentation showing distinct training tracks for each AI-facing role with topic coverage including fairness metrics, bias detection, regulatory obligations, and escalation procedures", "system_access_prerequisite_log confirming ethics training completion status was verified before granting AI development environment access or product approval authority", "training_refresh_trigger_record documenting evaluation of training currency following major regulatory changes with decision rationale and revised curriculum effective date where applicable" ], "evidence": [ { "id": "EG-04-E1", "description": "training_completion_records disaggregated by role (AI practitioner, product manager, legal/compliance, executive) showing completion date, curriculum version, and assessment score for each individual within the trailing 12 months", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-04-E2", "description": "role_differentiated_curriculum_documentation showing distinct training tracks for each AI-facing role with topic coverage including fairness metrics, bias detection, regulatory obligations, and escalation procedures", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-04-E3", "description": "system_access_prerequisite_log confirming ethics training completion status was verified before granting AI development environment access or product approval authority", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EG-04-E4", "description": "training_refresh_trigger_record documenting evaluation of training currency following major regulatory changes with decision rationale and revised curriculum effective date where applicable", "evidence_type": "evaluation-scorecard", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN 2.2 requires that the organization's personnel and partners receive AI risk management training to enable them to fulfill their duties and responsibilities. This control implements that training requirement with role-differentiated ethics curricula." }, { "control": "apeiris://model/controls/OA-03", "id": "OA-03", "domain": "model", "name": "AI Model Governance Committee", "validation_objective": "The organization must have a formally chartered AI Model Governance Committee with documented membership covering all required functional areas, exclusive approval authority over high-risk model deployments and risk appetite thresholds, and auditable meeting minutes retained for seven years. The committee must have met at minimum quarterly in each of the preceding four quarters, with quorum achieved for all binding decisions.", "blocking_effect": "blocks-deployment", "evidence_required": [ "committee_charter current version with executive-level approval signature and date, specifying membership composition, decision rights matrix, quorum requirements, and meeting cadence", "meeting_minutes for all scheduled quarterly sessions in the preceding 12-month period, demonstrating quorum was met and binding decisions were recorded with rationale", "decision_log showing AIGC approval records for all high-risk model deployments and risk appetite changes in the preceding 12 months, cross-referenced against the production model registry", "membership_roster with functional affiliations confirming representation from AI/ML engineering, model validation, legal/compliance, risk management, and at least one business line" ], "evidence": [ { "id": "OA-03-E1", "description": "committee_charter current version with executive-level approval signature and date, specifying membership composition, decision rights matrix, quorum requirements, and meeting cadence", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-03-E2", "description": "meeting_minutes for all scheduled quarterly sessions in the preceding 12-month period, demonstrating quorum was met and binding decisions were recorded with rationale", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-03-E3", "description": "decision_log showing AIGC approval records for all high-risk model deployments and risk appetite changes in the preceding 12 months, cross-referenced against the production model registry", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-03-E4", "description": "membership_roster with functional affiliations confirming representation from AI/ML engineering, model validation, legal/compliance, risk management, and at least one business line", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN-2.3 (GOVERN function) provides that executive leadership takes responsibility for decisions about risks associated with AI development and deployment. OA-03\u2019s chartered governance committee gives executive leadership a standing forum in which those risk decisions are taken and recorded." } ] }, { "requirement_id": "GOVERN-3.1", "section": "GOVERN 3.1", "title": "Organizational AI risk tolerance defined and communicated", "text": "Organizational risk tolerance for AI is determined and communicated through policies, processes, and procedures.", "verdict": "supported", "coverage": "direct", "notes": "EF-03 defines the ethical risk appetite; PO-01 embeds it in the policy register; AG-03 incorporates risk tolerance into the agentic risk assessment framework.", "control_count": 3, "proof_chain": [ { "control": "apeiris://ethics/controls/EF-03", "id": "EF-03", "domain": "ethics", "name": "Ethical Risk Appetite Definition", "validation_objective": "The organization must have a board-approved Ethical Risk Appetite Statement specifying at least one absolute prohibition (zero-tolerance harm type that unconditionally blocks deployment), at least one conditional tolerance band with a measurable residual risk threshold, and a documented exception governance process naming the authority level required to grant exceptions. Every high-risk AI system deployment decision must reference the applicable risk appetite tier in its documentation.", "blocking_effect": "blocks-deployment", "evidence_required": [ "ethical_risk_appetite_statement document with board_approval_record, approval_date, and version, containing an absolute_prohibitions list with named harm types and a conditional_tolerance_bands list with measurable residual_risk_thresholds", "exception_governance_process_document specifying who holds exception authority by harm category, required documentation for each exception request, and conditions that trigger escalation to board level", "ai_system_deployment_records for all high-risk systems linking each deployment decision to the applicable risk_appetite_tier and referencing the current statement version", "exception_register with each entry including system_id, harm_type, approver_role, approval_date, rationale, and next_review_date", "annual_review_completion_record with board re-approval date and change log for the current review cycle" ], "evidence": [ { "id": "EF-03-E1", "description": "ethical_risk_appetite_statement document with board_approval_record, approval_date, and version, containing an absolute_prohibitions list with named harm types and a conditional_tolerance_bands list with measurable residual_risk_thresholds", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-03-E2", "description": "exception_governance_process_document specifying who holds exception authority by harm category, required documentation for each exception request, and conditions that trigger escalation to board level", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-03-E3", "description": "ai_system_deployment_records for all high-risk systems linking each deployment decision to the applicable risk_appetite_tier and referencing the current statement version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-03-E4", "description": "exception_register with each entry including system_id, harm_type, approver_role, approval_date, rationale, and next_review_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-03-E5", "description": "annual_review_completion_record with board re-approval date and change log for the current review cycle", "evidence_type": "audit-log", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN 1.3 requires that organizational risk tolerance for AI is defined and communicated, and GOVERN 4.1 requires that organizational risk posture is reflected in deployment decisions. The Ethical Risk Appetite Statement directly operationalizes both requirements." }, { "control": "apeiris://authority/controls/PO-01", "id": "PO-01", "domain": "authority", "name": "Internal Policy Register for AI Deployments", "validation_objective": "Every active AI deployment must have at least one current, non-expired policy register entry in the authoritative policy register, and that entry must contain version, effective date, scope, owning team, and deployment linkage fields. No AI deployment may enter or remain in production without a valid policy register reference confirmed by the deployment pipeline.", "blocking_effect": "blocks-deployment", "evidence_required": [ "policy_register_schema_document specifying required fields including policy_id, version, effective_date, expiry_date, owning_team, ai_deployment_scope, and authority_domain_applicability", "deployment_policy_linkage_audit_log confirming every active AI deployment has a corresponding current policy register entry with a non-expired effective date", "policy_register_access_control_matrix demonstrating that register modifications require dual authorization and all changes are attributed and logged", "deployment_pipeline_gate_configuration showing that AI deployment approval workflows validate the presence of a current policy register entry before proceeding" ], "evidence": [ { "id": "PO-01-E1", "description": "policy_register_schema_document specifying required fields including policy_id, version, effective_date, expiry_date, owning_team, ai_deployment_scope, and authority_domain_applicability", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-01-E2", "description": "deployment_policy_linkage_audit_log confirming every active AI deployment has a corresponding current policy register entry with a non-expired effective date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-01-E3", "description": "policy_register_access_control_matrix demonstrating that register modifications require dual authorization and all changes are attributed and logged", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-01-E4", "description": "deployment_pipeline_gate_configuration showing that AI deployment approval workflows validate the presence of a current policy register entry before proceeding", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "A register of AI governance policies operationalizes GOVERN 1.2 policy integration, partially." }, { "control": "apeiris://agentic/controls/AG-03", "id": "AG-03", "domain": "agentic", "name": "Agentic AI Risk Assessment Framework", "validation_objective": "Every production AI agent has a completed, current risk assessment evaluated against all five framework dimensions, with the resulting consequence tier documented and linked to the deployment approval and control mitigation plan.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "Annual risk reassessment records for all Critical-tier agents" ], "evidence": [ { "id": "AG-03-E1", "description": "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E2", "description": "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E3", "description": "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E4", "description": "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E5", "description": "Annual risk reassessment records for all Critical-tier agents", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP 5.1 requires assessing the likelihood and magnitude of identified AI impacts in deployment context. The five-dimension agentic risk scoring model is a structured method for exactly that assessment across autonomy, reversibility, and blast-radius dimensions." } ] }, { "requirement_id": "GOVERN-3.2", "section": "GOVERN 3.2", "title": "AI risk tolerance incorporated into risk management decisions", "text": "AI risk tolerance is communicated to teams and incorporated into AI risk management decisions.", "verdict": "partial", "coverage": "partial", "notes": "EF-03 establishes tolerance thresholds; PG-07 reports on compliance; AG-06 tracks agent program metrics. Active feedback loops from tolerance definitions into individual team-level risk decisions are partially covered.", "control_count": 3, "proof_chain": [ { "control": "apeiris://ethics/controls/EF-03", "id": "EF-03", "domain": "ethics", "name": "Ethical Risk Appetite Definition", "validation_objective": "The organization must have a board-approved Ethical Risk Appetite Statement specifying at least one absolute prohibition (zero-tolerance harm type that unconditionally blocks deployment), at least one conditional tolerance band with a measurable residual risk threshold, and a documented exception governance process naming the authority level required to grant exceptions. Every high-risk AI system deployment decision must reference the applicable risk appetite tier in its documentation.", "blocking_effect": "blocks-deployment", "evidence_required": [ "ethical_risk_appetite_statement document with board_approval_record, approval_date, and version, containing an absolute_prohibitions list with named harm types and a conditional_tolerance_bands list with measurable residual_risk_thresholds", "exception_governance_process_document specifying who holds exception authority by harm category, required documentation for each exception request, and conditions that trigger escalation to board level", "ai_system_deployment_records for all high-risk systems linking each deployment decision to the applicable risk_appetite_tier and referencing the current statement version", "exception_register with each entry including system_id, harm_type, approver_role, approval_date, rationale, and next_review_date", "annual_review_completion_record with board re-approval date and change log for the current review cycle" ], "evidence": [ { "id": "EF-03-E1", "description": "ethical_risk_appetite_statement document with board_approval_record, approval_date, and version, containing an absolute_prohibitions list with named harm types and a conditional_tolerance_bands list with measurable residual_risk_thresholds", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-03-E2", "description": "exception_governance_process_document specifying who holds exception authority by harm category, required documentation for each exception request, and conditions that trigger escalation to board level", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-03-E3", "description": "ai_system_deployment_records for all high-risk systems linking each deployment decision to the applicable risk_appetite_tier and referencing the current statement version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-03-E4", "description": "exception_register with each entry including system_id, harm_type, approver_role, approval_date, rationale, and next_review_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-03-E5", "description": "annual_review_completion_record with board re-approval date and change log for the current review cycle", "evidence_type": "audit-log", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN 1.3 requires that organizational risk tolerance for AI is defined and communicated, and GOVERN 4.1 requires that organizational risk posture is reflected in deployment decisions. The Ethical Risk Appetite Statement directly operationalizes both requirements." }, { "control": "apeiris://authority/controls/PG-07", "id": "PG-07", "domain": "authority", "name": "Policy Governance Reporting", "validation_objective": "Policy governance reports must be generated on the defined schedule for all audience tiers (executive management, audit committee, board), with every defined metric field populated from verified upstream data sources. Distribution logs must confirm delivery within the deadline for each audience.", "blocking_effect": "advisory", "evidence_required": [ "governance_report_package containing report templates per audience tier, populated metric fields, and data-source mappings for each reporting period", "report_distribution_log showing recipient, delivery timestamp, and report version for each scheduled and event-driven governance report", "reporting_pipeline_audit_trail confirming each metric value was sourced from the canonical upstream control system with no manual entry points", "audit_committee_submission_record confirming receipt of quarterly governance reports within the defined deadline", "event_driven_report_log showing supplemental reports triggered by material incidents above the defined severity threshold with generation-to-delivery elapsed time" ], "evidence": [ { "id": "PG-07-E1", "description": "governance_report_package containing report templates per audience tier, populated metric fields, and data-source mappings for each reporting period", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PG-07-E2", "description": "report_distribution_log showing recipient, delivery timestamp, and report version for each scheduled and event-driven governance report", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PG-07-E3", "description": "reporting_pipeline_audit_trail confirming each metric value was sourced from the canonical upstream control system with no manual entry points", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PG-07-E4", "description": "audit_committee_submission_record confirming receipt of quarterly governance reports within the defined deadline", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PG-07-E5", "description": "event_driven_report_log showing supplemental reports triggered by material incidents above the defined severity threshold with generation-to-delivery elapsed time", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://agentic/controls/AG-06", "id": "AG-06", "domain": "agentic", "name": "Agent Program Metrics and KPIs", "validation_objective": "The enterprise collects and reports a defined set of agentic AI governance KPIs from automated pipelines on a defined frequency, and the governance committee receives current-period metric values with trend data and threshold breach alerts at each governance review meeting.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Published Agentic AI Program Metrics Catalog defining each KPI: name, formula, data source, reporting frequency, metric owner, and target threshold with current baseline", "Automated governance dashboard outputs from at least the three most recent reporting periods showing coverage, process, outcome, and attestation metrics", "Governance committee meeting records confirming receipt and review of metrics reports and documenting threshold breach discussions and directed actions", "Data pipeline lineage documentation showing the authoritative source for each KPI and the automated collection process" ], "evidence": [ { "id": "AG-06-E1", "description": "Published Agentic AI Program Metrics Catalog defining each KPI: name, formula, data source, reporting frequency, metric owner, and target threshold with current baseline", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-06-E2", "description": "Automated governance dashboard outputs from at least the three most recent reporting periods showing coverage, process, outcome, and attestation metrics", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "AG-06-E3", "description": "Governance committee meeting records confirming receipt and review of metrics reports and documenting threshold breach discussions and directed actions", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AG-06-E4", "description": "Data pipeline lineage documentation showing the authoritative source for each KPI and the automated collection process", "evidence_type": "data-lineage-record", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE 1.1 requires approaches and metrics for AI risk measurement to be selected and implemented. A defined agentic program metrics catalog with coverage, incident, and drift KPIs is that selection, made explicit and reviewable." } ] }, { "requirement_id": "GOVERN-4.1", "section": "GOVERN 4.1", "title": "Trustworthy AI culture with third-party entities", "text": "Organizational policies and practices are in place to foster a trustworthy AI culture with third-party entities, including suppliers, AI developers, and deployers.", "verdict": "supported", "coverage": "direct", "notes": "PO-07 enforces third-party policy requirements; PR-07 monitors contract obligations; EG-05 holds third-party AI providers accountable to ethics standards.", "control_count": 3, "proof_chain": [ { "control": "apeiris://authority/controls/PO-07", "id": "PO-07", "domain": "authority", "name": "Third-Party Policy Requirements", "validation_objective": "Every vendor agreement involving an AI system must include a signed third-party AI authority policy annex before that AI system is granted access to enterprise resources or authorized to act on the organization's behalf, with documented compliance verification evidence on file confirming the vendor's authority constraint configuration meets all required controls.", "blocking_effect": "blocks-deployment", "evidence_required": [ "vendor_agreement_register listing all active vendors with AI systems, each with policy_annex_status (signed/unsigned), annex_version, signed_at timestamp, and audit_rights_confirmed flag", "third_party_compliance_verification_record for each vendor AI system with controls_verified[], evidence_reviewed[], verifier_id, verification_date, and pass/fail verdict per required control area", "vendor_activation_gate_log showing compliance_verification_record_id referenced at AI system activation time for each third-party deployment", "annual_vendor_review_record with completion_date, findings_summary, and remediation_actions for each active vendor relationship" ], "evidence": [ { "id": "PO-07-E1", "description": "vendor_agreement_register listing all active vendors with AI systems, each with policy_annex_status (signed/unsigned), annex_version, signed_at timestamp, and audit_rights_confirmed flag", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-07-E2", "description": "third_party_compliance_verification_record for each vendor AI system with controls_verified[], evidence_reviewed[], verifier_id, verification_date, and pass/fail verdict per required control area", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-07-E3", "description": "vendor_activation_gate_log showing compliance_verification_record_id referenced at AI system activation time for each third-party deployment", "evidence_type": "third-party-audit-report", "verification": "third-party" }, { "id": "PO-07-E4", "description": "annual_vendor_review_record with completion_date, findings_summary, and remediation_actions for each active vendor relationship", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://authority/controls/PR-07", "id": "PR-07", "domain": "authority", "name": "Contract Obligation Monitoring", "validation_objective": "The contract obligation monitoring engine must have active obligation manifests for all active contracts ingested within 24 hours of execution or amendment, and must track AI system actions against each obligation constraint in real time. Breach risk alerts must be generated and routed to named human owners within one hour of detecting that an AI action has brought an obligation to 80% of a usage cap or within 5 business days of a milestone deadline.", "blocking_effect": "advisory", "evidence_required": [ "contract_obligation_monitoring_engine_event_log showing obligation manifest ingestion events, real-time AI action tracking records, breach risk alerts generated with timestamps, and alert routing records with acknowledgment timestamps", "obligation_manifest_registry confirming all active contracts are represented with their obligation constraints (usage caps, exclusivity windows, milestone dates, penalty trigger conditions) and last_ingested_at timestamps", "breach_risk_alert_routing_matrix showing named owner assignments, response SLAs, and escalation paths for each contract category by financial exposure level", "breach_risk_alert_simulation_test_results confirming alerts fire within one hour of simulated 80% usage cap and 5-business-day milestone approach events" ], "evidence": [ { "id": "PR-07-E1", "description": "contract_obligation_monitoring_engine_event_log showing obligation manifest ingestion events, real-time AI action tracking records, breach risk alerts generated with timestamps, and alert routing records with acknowledgment timestamps", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "PR-07-E2", "description": "obligation_manifest_registry confirming all active contracts are represented with their obligation constraints (usage caps, exclusivity windows, milestone dates, penalty trigger conditions) and last_ingested_at timestamps", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PR-07-E3", "description": "breach_risk_alert_routing_matrix showing named owner assignments, response SLAs, and escalation paths for each contract category by financial exposure level", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PR-07-E4", "description": "breach_risk_alert_simulation_test_results confirming alerts fire within one hour of simulated 80% usage cap and 5-business-day milestone approach events", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://ethics/controls/EG-05", "id": "EG-05", "domain": "ethics", "name": "Third-Party AI Provider Ethics Accountability", "validation_objective": "All material third-party AI providers must have documented ethics due diligence on file reviewed within the past 12 months, with contractual ethics obligations including audit rights, bias documentation requirements, and incident notification clauses. A maintained registry must enumerate all material AI systems with due diligence status and last audit date.", "blocking_effect": "blocks-deployment", "evidence_required": [ "third_party_ai_provider_registry listing all material AI systems in production with provider_name, system_id, ethics_due_diligence_date, contractual_ethics_obligations_status, and last_audit_date", "completed_ethics_due_diligence_questionnaires for each material provider covering training data provenance, bias evaluation results, safety testing outcomes, incident history, and ethics governance maturity score", "vendor_contract_ethics_clauses or amendment documentation showing audit rights, bias documentation requirements (model card or equivalent), incident notification SLA, and ethics-related termination trigger", "annual_ethics_audit_report or equivalent review for each material provider with findings, remediation actions, and close-out evidence" ], "evidence": [ { "id": "EG-05-E1", "description": "third_party_ai_provider_registry listing all material AI systems in production with provider_name, system_id, ethics_due_diligence_date, contractual_ethics_obligations_status, and last_audit_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-05-E2", "description": "completed_ethics_due_diligence_questionnaires for each material provider covering training data provenance, bias evaluation results, safety testing outcomes, incident history, and ethics governance maturity score", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "EG-05-E3", "description": "vendor_contract_ethics_clauses or amendment documentation showing audit rights, bias documentation requirements (model card or equivalent), incident notification SLA, and ethics-related termination trigger", "evidence_type": "model-card", "verification": "attested" }, { "id": "EG-05-E4", "description": "annual_ethics_audit_report or equivalent review for each material provider with findings, remediation actions, and close-out evidence", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN 6.1 requires policies and procedures for assessing and managing risks from third-party AI systems and components. This control implements the due diligence and contractual accountability mechanisms GOVERN 6.1 requires." } ] }, { "requirement_id": "GOVERN-4.2", "section": "GOVERN 4.2", "title": "Documenting AI risks for third-party entities", "text": "Organizational teams document AI risk for third-party entities and integrate feedback from them into organizational risk management.", "verdict": "supported", "coverage": "direct", "notes": "OA-06 governs third-party model and vendor risk oversight; PR-09 packages procurement governance evidence; EG-05 extends ethics accountability to third parties.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/OA-06", "id": "OA-06", "domain": "model", "name": "Third-Party Model and Vendor Risk Oversight", "validation_objective": "Every third-party AI model or component used in production must appear in the model inventory with vendor, model version, intake date, and use case documented. All active third-party vendors must have completed due diligence records and current annual risk reviews. Production integrations must implement version pinning verified against the registry, and vendor contracts must include model change notification, audit rights, and incident notification SLA clauses.", "blocking_effect": "blocks-deployment", "evidence_required": [ "third_party_ai_model_inventory current snapshot with fields: vendor, model_name, model_version, api_version, intake_date, use_cases, production_status \u2014 covering all active third-party AI components", "vendor_due_diligence_record for each active vendor, including security practices assessment, data governance review, model documentation review, and governance/safety practice assessment for high-risk use cases", "contract_clause_compliance_checklist for each vendor agreement, confirming presence of: 30-day material change notification, audit rights or third-party audit acceptance, 24-hour security incident SLA, and data residency/confidentiality terms", "annual_vendor_risk_review_report for each active vendor covering the preceding 12 months, with risk rating, material incidents noted, and recommended actions" ], "evidence": [ { "id": "OA-06-E1", "description": "third_party_ai_model_inventory current snapshot with fields: vendor, model_name, model_version, api_version, intake_date, use_cases, production_status \u2014 covering all active third-party AI components", "evidence_type": "third-party-audit-report", "verification": "third-party" }, { "id": "OA-06-E2", "description": "vendor_due_diligence_record for each active vendor, including security practices assessment, data governance review, model documentation review, and governance/safety practice assessment for high-risk use cases", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-06-E3", "description": "contract_clause_compliance_checklist for each vendor agreement, confirming presence of: 30-day material change notification, audit rights or third-party audit acceptance, 24-hour security incident SLA, and data residency/confidentiality terms", "evidence_type": "third-party-audit-report", "verification": "third-party" }, { "id": "OA-06-E4", "description": "annual_vendor_risk_review_report for each active vendor covering the preceding 12 months, with risk rating, material incidents noted, and recommended actions", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN-6.1 (GOVERN function) provides that policies address AI risks associated with third-party entities, including IP-infringement risks. OA-06\u2019s vendor due diligence, contract requirements, and substitution planning implement the third-party risk policies this subcategory requires." }, { "control": "apeiris://authority/controls/PR-09", "id": "PR-09", "domain": "authority", "name": "Procurement Governance Layer Evidence Package", "validation_objective": "The procurement governance layer evidence package for each quarter must contain complete, signed artifacts from all controls PR-01 through PR-08, with a gap register containing no items unresolved beyond two consecutive quarters, and the package must be submitted to the PE-08 PolicyAttestation production cycle within 10 business days of quarter end.", "blocking_effect": "requires-review", "evidence_required": [ "Signed quarterly procurement governance layer evidence package covering required artifacts from all controls PR-01 through PR-08, with package_owner, review_signatories, and submission_timestamp fields populated", "Gap register for each quarterly package listing identified deficiencies with assigned owner, remediation deadline, and resolution status from prior quarters", "Submission record linking each quarterly evidence package to the PE-08 PolicyAttestation production cycle input with accepted_at timestamp", "Artifact collection audit trail showing the date each PR-layer artifact was retrieved and the review session outcome record" ], "evidence": [ { "id": "PR-09-E1", "description": "Signed quarterly procurement governance layer evidence package covering required artifacts from all controls PR-01 through PR-08, with package_owner, review_signatories, and submission_timestamp fields populated", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PR-09-E2", "description": "Gap register for each quarterly package listing identified deficiencies with assigned owner, remediation deadline, and resolution status from prior quarters", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PR-09-E3", "description": "Submission record linking each quarterly evidence package to the PE-08 PolicyAttestation production cycle input with accepted_at timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PR-09-E4", "description": "Artifact collection audit trail showing the date each PR-layer artifact was retrieved and the review session outcome record", "evidence_type": "audit-log", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN 1.5 requires planned ongoing monitoring and periodic review of the risk management process and its outcomes, with clear roles and review cadence. PR-09 instantiates this periodic layer-level review at the Procurement Governance layer." }, { "control": "apeiris://ethics/controls/EG-05", "id": "EG-05", "domain": "ethics", "name": "Third-Party AI Provider Ethics Accountability", "validation_objective": "All material third-party AI providers must have documented ethics due diligence on file reviewed within the past 12 months, with contractual ethics obligations including audit rights, bias documentation requirements, and incident notification clauses. A maintained registry must enumerate all material AI systems with due diligence status and last audit date.", "blocking_effect": "blocks-deployment", "evidence_required": [ "third_party_ai_provider_registry listing all material AI systems in production with provider_name, system_id, ethics_due_diligence_date, contractual_ethics_obligations_status, and last_audit_date", "completed_ethics_due_diligence_questionnaires for each material provider covering training data provenance, bias evaluation results, safety testing outcomes, incident history, and ethics governance maturity score", "vendor_contract_ethics_clauses or amendment documentation showing audit rights, bias documentation requirements (model card or equivalent), incident notification SLA, and ethics-related termination trigger", "annual_ethics_audit_report or equivalent review for each material provider with findings, remediation actions, and close-out evidence" ], "evidence": [ { "id": "EG-05-E1", "description": "third_party_ai_provider_registry listing all material AI systems in production with provider_name, system_id, ethics_due_diligence_date, contractual_ethics_obligations_status, and last_audit_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-05-E2", "description": "completed_ethics_due_diligence_questionnaires for each material provider covering training data provenance, bias evaluation results, safety testing outcomes, incident history, and ethics governance maturity score", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "EG-05-E3", "description": "vendor_contract_ethics_clauses or amendment documentation showing audit rights, bias documentation requirements (model card or equivalent), incident notification SLA, and ethics-related termination trigger", "evidence_type": "model-card", "verification": "attested" }, { "id": "EG-05-E4", "description": "annual_ethics_audit_report or equivalent review for each material provider with findings, remediation actions, and close-out evidence", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN 6.1 requires policies and procedures for assessing and managing risks from third-party AI systems and components. This control implements the due diligence and contractual accountability mechanisms GOVERN 6.1 requires." } ] }, { "requirement_id": "GOVERN-5.1", "section": "GOVERN 5.1", "title": "Senior leadership tone and AI risk implementation support", "text": "Organizational policies and practices are in place to set the organizational tone and support implementation of AI risk management by senior leadership.", "verdict": "supported", "coverage": "direct", "notes": "EG-03 anchors board-level ethics accountability; EG-02 establishes the AI ethics policy framework; PE-06 mandates board and senior management policy reporting.", "control_count": 3, "proof_chain": [ { "control": "apeiris://ethics/controls/EG-03", "id": "EG-03", "domain": "ethics", "name": "Senior and Board-Level Ethics Accountability", "validation_objective": "The organization must have a named C-suite executive with documented AI ethics accountability and evidence of at least semi-annual board-level AI ethics briefings within the trailing 12 months. Executive performance objectives must include AI ethics KPIs linked to measurable program outcomes.", "blocking_effect": "requires-review", "evidence_required": [ "executive_accountability_assignment showing named C-suite role, documented accountability scope, and date of assignment in role description or governance framework", "board_briefing_records from past 12 months confirming AI ethics posture, material risks, and incident status were presented, with meeting minutes or attendance logs", "executive_performance_objectives document showing AI ethics KPIs included in C-suite scorecards with defined targets and measurement periods", "material_risk_escalation_procedure document defining thresholds that trigger immediate C-suite notification with named escalation contacts and SLA" ], "evidence": [ { "id": "EG-03-E1", "description": "executive_accountability_assignment showing named C-suite role, documented accountability scope, and date of assignment in role description or governance framework", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-03-E2", "description": "board_briefing_records from past 12 months confirming AI ethics posture, material risks, and incident status were presented, with meeting minutes or attendance logs", "evidence_type": "incident-record", "verification": "attested" }, { "id": "EG-03-E3", "description": "executive_performance_objectives document showing AI ethics KPIs included in C-suite scorecards with defined targets and measurement periods", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-03-E4", "description": "material_risk_escalation_procedure document defining thresholds that trigger immediate C-suite notification with named escalation contacts and SLA", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN 2.1 requires that organizational leadership establishes and maintains oversight structures for AI risk, including senior leadership accountability. Board-level reporting and C-suite accountability directly implement this function." }, { "control": "apeiris://ethics/controls/EG-02", "id": "EG-02", "domain": "ethics", "name": "AI Ethics Policy Framework", "validation_objective": "The enterprise must maintain a comprehensive, current AI ethics policy framework with a top-level policy approved at C-suite or board level, domain-specific sub-policies covering fairness, transparency, privacy, and safety, a documented prohibited use register, and evidence that all AI systems in production have completed policy compliance sign-off at each lifecycle gate. The control passes if no AI system is in production without documented ethics policy review and sign-off at design, pre-deployment, and post-deployment monitoring gates.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Top-level AI Ethics Policy document with C-suite or board approval signature, current version number, and most recent review date within the past 12 months", "Domain-specific ethics sub-policy documents for fairness and non-discrimination, transparency and explainability, privacy, safety, and environmental impact, each with version history and last-reviewed date", "Prohibited AI use register listing explicitly prohibited use cases with sufficient specificity to enable compliance determination, approved at ethics officer and legal counsel level and reviewed within the past 12 months against current regulatory requirements", "AI system policy compliance sign-off records showing documented ethics policy review at design gate, pre-deployment gate, and post-deployment monitoring gate for all AI systems in production with the reviewing team lead's attestation", "Policy distribution records confirming all AI product teams have access to the ethics policy framework, with read confirmation or training completion records as applicable" ], "evidence": [ { "id": "EG-02-E1", "description": "Top-level AI Ethics Policy document with C-suite or board approval signature, current version number, and most recent review date within the past 12 months", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EG-02-E2", "description": "Domain-specific ethics sub-policy documents for fairness and non-discrimination, transparency and explainability, privacy, safety, and environmental impact, each with version history and last-reviewed date", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EG-02-E3", "description": "Prohibited AI use register listing explicitly prohibited use cases with sufficient specificity to enable compliance determination, approved at ethics officer and legal counsel level and reviewed within the past 12 months against current regulatory requirements", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EG-02-E4", "description": "AI system policy compliance sign-off records showing documented ethics policy review at design gate, pre-deployment gate, and post-deployment monitoring gate for all AI systems in production with the reviewing team lead's attestation", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "EG-02-E5", "description": "Policy distribution records confirming all AI product teams have access to the ethics policy framework, with read confirmation or training completion records as applicable", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN 1.2 requires that the accountability, transparency, and explainability objectives of AI systems are established in organizational policy. A comprehensive ethics policy framework operationalizes these GOVERN requirements." }, { "control": "apeiris://authority/controls/PE-06", "id": "PE-06", "domain": "authority", "name": "Board and Senior Management Policy Reporting", "validation_objective": "Quarterly AI policy governance reports must be produced on schedule, reviewed, and co-signed by both the Chief Risk Officer and General Counsel, with every reported metric traceable to a supporting evidence item in the PE-04 integrated package. All risk items exceeding the board-approved materiality thresholds must appear in the report with prioritized escalation recommendations and documented board response within 30 days.", "blocking_effect": "requires-review", "evidence_required": [ "board_ai_policy_governance_report with executive summary, risk-adjusted metrics, open gap inventory, and escalation recommendations, dated within the quarterly reporting cycle and referencing the PE-04 integrated package version used", "report_sign_off_log showing CRO identity, General Counsel identity, individual sign-off timestamps, and SHA-256 hash of the signed report version to detect post-signature modification", "materiality_threshold_schedule approved by the CRO and version-controlled, defining numeric thresholds for AI policy risk metrics that trigger mandatory board-level reporting and escalation", "report_distribution_log recording recipient role, distribution timestamp, and acknowledgment status for each quarterly report to confirm the board actually received the report" ], "evidence": [ { "id": "PE-06-E1", "description": "board_ai_policy_governance_report with executive summary, risk-adjusted metrics, open gap inventory, and escalation recommendations, dated within the quarterly reporting cycle and referencing the PE-04 integrated package version used", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PE-06-E2", "description": "report_sign_off_log showing CRO identity, General Counsel identity, individual sign-off timestamps, and SHA-256 hash of the signed report version to detect post-signature modification", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PE-06-E3", "description": "materiality_threshold_schedule approved by the CRO and version-controlled, defining numeric thresholds for AI policy risk metrics that trigger mandatory board-level reporting and escalation", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PE-06-E4", "description": "report_distribution_log recording recipient role, distribution timestamp, and acknowledgment status for each quarterly report to confirm the board actually received the report", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "GOVERN-5.2", "section": "GOVERN 5.2", "title": "Teams committed to risk management outcomes", "text": "Organizational teams are committed to achieving risk management outcomes by applying the organization's risk governance and risk management procedures.", "verdict": "supported", "coverage": "direct", "notes": "AG-04 establishes senior accountability for autonomous AI systems; OA-01 assigns model ownership; PG-01 monitors policy adherence in the operational plane.", "control_count": 3, "proof_chain": [ { "control": "apeiris://agentic/controls/AG-04", "id": "AG-04", "domain": "agentic", "name": "Senior Accountability for Autonomous AI Systems", "validation_objective": "Every AI agent operating at Medium consequence tier or above has a named accountable owner recorded in both the agent registry and the enterprise risk register, and that owner has formally signed the agent's authorization scope declaration and completed their most recent annual reaffirmation.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Agent registry entries for all Medium-tier-and-above agents showing named accountable owner, seniority level, assignment date, and scope declaration reference", "Signed authorization scope declaration for each in-scope agent, bearing the accountable owner's identity and the date of most recent reaffirmation", "Enterprise risk register entries linking each in-scope agent to its named accountable owner and consequence tier", "Annual reaffirmation records for each accountable owner assignment, confirming reaffirmation within the required cadence" ], "evidence": [ { "id": "AG-04-E1", "description": "Agent registry entries for all Medium-tier-and-above agents showing named accountable owner, seniority level, assignment date, and scope declaration reference", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-04-E2", "description": "Signed authorization scope declaration for each in-scope agent, bearing the accountable owner's identity and the date of most recent reaffirmation", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-04-E3", "description": "Enterprise risk register entries linking each in-scope agent to its named accountable owner and consequence tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-04-E4", "description": "Annual reaffirmation records for each accountable owner assignment, confirming reaffirmation within the required cadence", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN 2.3 requires executive leadership to take responsibility for decisions about risks associated with AI system development and deployment. Named senior accountable owners for autonomous systems are the direct organizational implementation." }, { "control": "apeiris://model/controls/OA-01", "id": "OA-01", "domain": "model", "name": "Model Ownership Assignment", "validation_objective": "Every AI model in the production model registry must have a non-null named human owner who is a current employee, a responsible team, and an executive sponsor at director level or above for high-impact models, all recorded within five business days of deployment. No production model may exist without a current ownership record, and ownership must be reassigned within ten business days of any owner departure.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_ownership_register_extract with fields: model_id, owner_name, owner_employee_id, team, executive_sponsor, effective_date, review_date \u2014 showing 100% coverage of production models with non-null values", "deployment_pipeline_gate_log showing blocked promotion events for models with null ownership fields, with timestamps and model IDs", "hr_departure_event_log cross-referenced with ownership_reassignment_record demonstrating reassignment within ten business days for each departure", "governance_committee_meeting_minutes containing ownership review agenda items for the preceding 12-month period" ], "evidence": [ { "id": "OA-01-E1", "description": "model_ownership_register_extract with fields: model_id, owner_name, owner_employee_id, team, executive_sponsor, effective_date, review_date \u2014 showing 100% coverage of production models with non-null values", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-01-E2", "description": "deployment_pipeline_gate_log showing blocked promotion events for models with null ownership fields, with timestamps and model IDs", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-01-E3", "description": "hr_departure_event_log cross-referenced with ownership_reassignment_record demonstrating reassignment within ten business days for each departure", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-01-E4", "description": "governance_committee_meeting_minutes containing ownership review agenda items for the preceding 12-month period", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN-2.1 (GOVERN function) provides that roles, responsibilities, and lines of communication for AI risk management are documented and clear. OA-01\u2019s named-owner register documents the ownership and accountability lines this subcategory requires for every production model." }, { "control": "apeiris://authority/controls/PG-01", "id": "PG-01", "domain": "authority", "name": "Policy Adherence Monitoring", "validation_objective": "All in-scope AI systems must have 100% of their active internal policies represented by machine-evaluable monitoring rules in the policy registry, with every AI system action evaluated against applicable rules in real time, and deviation alerts routed to accountable reviewers within the documented SLA.", "blocking_effect": "advisory", "evidence_required": [ "Policy registry export listing all active internal policies with corresponding machine-evaluable rule definitions, effective dates, and policy source references", "Policy evaluation engine event logs showing per-action rule evaluation outcomes, deviation alert generation timestamps, and SLA compliance metrics for the reporting period", "Compliance monitoring SLA definition document signed by the Compliance Officer, specifying alert routing targets and resolution timeframes", "Monitoring coverage report confirming the percentage of in-scope AI systems and action types evaluated against active policy rules, with no coverage gaps documented without risk acceptance" ], "evidence": [ { "id": "PG-01-E1", "description": "Policy registry export listing all active internal policies with corresponding machine-evaluable rule definitions, effective dates, and policy source references", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "PG-01-E2", "description": "Policy evaluation engine event logs showing per-action rule evaluation outcomes, deviation alert generation timestamps, and SLA compliance metrics for the reporting period", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "PG-01-E3", "description": "Compliance monitoring SLA definition document signed by the Compliance Officer, specifying alert routing targets and resolution timeframes", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "PG-01-E4", "description": "Monitoring coverage report confirming the percentage of in-scope AI systems and action types evaluated against active policy rules, with no coverage gaps documented without risk acceptance", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "Continuous adherence monitoring helps identify emergent policy risks, partially addressing MEASURE 3.1." } ] }, { "requirement_id": "GOVERN-6.1", "section": "GOVERN 6.1", "title": "Policies for AI risks from third-party software and data", "text": "Policies and procedures are in place to address AI risks and benefits arising from third-party software and data and other supply chain issues.", "verdict": "supported", "coverage": "direct", "notes": "TG-07 governs third-party dataset use; LI-03 verifies supply chain integrity with cryptographic controls; PR-01 integrates procurement policy; EC-09 treats workspace configuration as untrusted.", "control_count": 4, "proof_chain": [ { "control": "apeiris://model/controls/TG-07", "id": "TG-07", "domain": "model", "name": "Third-Party Dataset Governance", "validation_objective": "Every externally sourced training dataset in active use has a current Third-Party Dataset Registry entry with a valid security and legal review, version-pinned artifact hash, and license compliance record. No third-party dataset update enters training without a completed re-review gate, and artifact integrity is verified by hash comparison against vendor-published checksums before each training use.", "blocking_effect": "blocks-deployment", "evidence_required": [ "third_party_dataset_registry_entry for each active external dataset containing: dataset_id, vendor_name, license_terms, version_pin with artifact_hash, approval_date, reviewer_identity, legal_review_outcome, and security_review_outcome", "artifact_integrity_verification_log per training run showing hash comparison between locally stored dataset artifact and vendor-published checksum, with pass/fail result", "update_notification_record documenting each vendor-issued dataset update notice received, with quarantine status and re-review outcome (approved / rejected / paused-pending-review)", "license_compliance_attestation confirming permitted training use, output rights, and any attribution or restriction requirements for each active third-party dataset" ], "evidence": [ { "id": "TG-07-E1", "description": "third_party_dataset_registry_entry for each active external dataset containing: dataset_id, vendor_name, license_terms, version_pin with artifact_hash, approval_date, reviewer_identity, legal_review_outcome, and security_review_outcome", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-07-E2", "description": "artifact_integrity_verification_log per training run showing hash comparison between locally stored dataset artifact and vendor-published checksum, with pass/fail result", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-07-E3", "description": "update_notification_record documenting each vendor-issued dataset update notice received, with quarantine status and re-review outcome (approved / rejected / paused-pending-review)", "evidence_type": "human-review-record", "verification": "human" }, { "id": "TG-07-E4", "description": "license_compliance_attestation confirming permitted training use, output rights, and any attribution or restriction requirements for each active third-party dataset", "evidence_type": "third-party-audit-report", "verification": "third-party" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN-6.1 (GOVERN function) provides that policies address AI risks associated with third-party entities, including IP-infringement risks. TG-07\u2019s third-party dataset registry, version pinning, and due-diligence records implement those policies for externally sourced training data." }, { "control": "apeiris://model/controls/LI-03", "id": "LI-03", "domain": "model", "name": "Supply Chain Integrity \u2014 Third-Party Model Verification and Cryptographic...", "validation_objective": "Every third-party model artifact must be verified against a publisher-signed SHA-256 digest obtained from an authoritative source that is distinct from the artifact download location before registration, and any artifact failing verification must be quarantined and blocked; a model SBOM (mSBOM) enumerating all artifact components with individual hashes, SPDX license identifiers, and provenance metadata must be generated and stored as an immutable attachment to the registry entry.", "blocking_effect": "blocks-deployment", "evidence_required": [ "supply_chain_verification_record documenting the publisher-signed checksum retrieval URL (distinct from artifact download location), the comparison result, the verifier identity, and the verification timestamp for each acquired third-party artifact", "model_msbom with individual per-component entries for each weights shard, tokenizer file, and configuration file including SHA-256 hash, SPDX license identifier, declared provenance, and the verification method used", "pipeline_quarantine_log showing detection and quarantine of an artifact with a hash mismatch or absent publisher signature (from test injection or a real event)", "model_registry_entry with an immutable mSBOM attachment link, mSBOM creation timestamp, and reference to the corresponding supply_chain_verification_record" ], "evidence": [ { "id": "LI-03-E1", "description": "supply_chain_verification_record documenting the publisher-signed checksum retrieval URL (distinct from artifact download location), the comparison result, the verifier identity, and the verification timestamp for each acquired third-party artifact", "evidence_type": "third-party-audit-report", "verification": "third-party" }, { "id": "LI-03-E2", "description": "model_msbom with individual per-component entries for each weights shard, tokenizer file, and configuration file including SHA-256 hash, SPDX license identifier, declared provenance, and the verification method used", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "LI-03-E3", "description": "pipeline_quarantine_log showing detection and quarantine of an artifact with a hash mismatch or absent publisher signature (from test injection or a real event)", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "LI-03-E4", "description": "model_registry_entry with an immutable mSBOM attachment link, mSBOM creation timestamp, and reference to the corresponding supply_chain_verification_record", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN-6.1 (GOVERN function) provides that policies address AI risks associated with third-party entities, including IP-infringement risks. LI-03 provides the technical verification mechanism \u2014 signed checksums and a model SBOM \u2014 that makes third-party model risk policies enforceable." }, { "control": "apeiris://authority/controls/PR-01", "id": "PR-01", "domain": "authority", "name": "AI Procurement Policy Integration", "validation_objective": "Every AI procurement request must complete a Compliance-Officer-approved AI procurement checklist using the current approved version before any vendor engagement is initiated, with no AI system activated under vendor terms that have not been evaluated against the enterprise AI authority policy checklist.", "blocking_effect": "blocks-deployment", "evidence_required": [ "ai_procurement_checklist_current with version_id, effective_date, compliance_officer_approval_signature, and general_counsel_approval_signature covering all required authority policy areas", "procurement_checklist_completion_record for each AI procurement request with checklist_version_used, completed_by, completed_at, compliance_officer_approval_id, and verdict (approved/rejected/escalated)", "purchase_approval_workflow_gate_log confirming each AI procurement request was blocked from advancing to vendor engagement until a completed checklist record was on file", "quarterly_checklist_review_record documenting that the AI procurement checklist was reviewed against current AI authority policy and either confirmed current or updated with a change rationale" ], "evidence": [ { "id": "PR-01-E1", "description": "ai_procurement_checklist_current with version_id, effective_date, compliance_officer_approval_signature, and general_counsel_approval_signature covering all required authority policy areas", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PR-01-E2", "description": "procurement_checklist_completion_record for each AI procurement request with checklist_version_used, completed_by, completed_at, compliance_officer_approval_id, and verdict (approved/rejected/escalated)", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PR-01-E3", "description": "purchase_approval_workflow_gate_log confirming each AI procurement request was blocked from advancing to vendor engagement until a completed checklist record was on file", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PR-01-E4", "description": "quarterly_checklist_review_record documenting that the AI procurement checklist was reviewed against current AI authority policy and either confirmed current or updated with a change rationale", "evidence_type": "human-review-record", "verification": "human" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://security/controls/EC-09", "id": "EC-09", "domain": "security", "name": "Treat the workspace and its config and hooks as untrusted", "validation_objective": "The agent runtime must refuse to auto-load or execute any config file (mcp.json, .cursor config, cli-config.json) or git hook (.git/hooks, .git/config, .git/info/attributes) originating from the opened workspace without explicit human approval. Dangerous and auto-approve permission modes must be disabled or gated in all non-throwaway contexts.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "workspace_trust_decision_log recording each new workspace opened, the trust verdict, and the approver identity", "config_and_hook_approval_record listing each repo-supplied config or hook reviewed, approval status, and timestamp", "permission_mode_policy document showing auto-approve and skip-permissions modes are disabled or restricted to named sandboxes", "sandbox_escape_regression_test_report confirming known escape vectors were tested and blocked" ], "evidence": [ { "id": "EC-09-E1", "description": "workspace_trust_decision_log recording each new workspace opened, the trust verdict, and the approver identity", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-09-E2", "description": "config_and_hook_approval_record listing each repo-supplied config or hook reviewed, approval status, and timestamp", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "EC-09-E3", "description": "permission_mode_policy document showing auto-approve and skip-permissions modes are disabled or restricted to named sandboxes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-09-E4", "description": "sandbox_escape_regression_test_report confirming known escape vectors were tested and blocked", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "adjacent", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF Manage function: prioritise and act on the identified AI risks, treating, responding, recovering, and allocating resources. \"Treat the workspace and its config and hooks as untrusted\" is a corresponding risk-treatment activity." } ] }, { "requirement_id": "GOVERN-6.2", "section": "GOVERN 6.2", "title": "Organizational team policies for third-party AI risks", "text": "Policies and procedures are in place for organizational teams to address AI risks arising from third-party software and data throughout the AI lifecycle.", "verdict": "supported", "coverage": "direct", "notes": "PR-03 enforces vendor qualification; OA-06 provides third-party model and vendor risk oversight; AT-06 governs third-party plugin vetting and sandboxing.", "control_count": 3, "proof_chain": [ { "control": "apeiris://authority/controls/PR-03", "id": "PR-03", "domain": "authority", "name": "Vendor Qualification Enforcement", "validation_objective": "Every vendor engaged through AI-assisted procurement must have a passing vendor qualification scorecard on file before the procurement workflow advances to contract negotiation, and no vendor with an expired qualification record may receive a renewal order. The procurement workflow must technically prevent advancement past the qualification gate for any vendor that has not met the documented minimum qualification threshold.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "vendor_qualification_scorecard for each AI vendor contracted during the review period, showing scores across all required authority policy compliance areas, a pass/fail determination, reviewer identity, and scorecard effective date", "procurement_workflow_qualification_gate_config demonstrating the gate is technically enforced and that no advancement path to contract negotiation exists for a vendor without a current passed scorecard", "qualified_vendor_list with last_reviewed_date and scorecard_expiry_date for each entry, confirmed updated within the last quarter by Vendor Management", "vendor_exception_records for any vendor granted an exception below the minimum threshold, each with documented General Counsel approval and risk assessment" ], "evidence": [ { "id": "PR-03-E1", "description": "vendor_qualification_scorecard for each AI vendor contracted during the review period, showing scores across all required authority policy compliance areas, a pass/fail determination, reviewer identity, and scorecard effective date", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "PR-03-E2", "description": "procurement_workflow_qualification_gate_config demonstrating the gate is technically enforced and that no advancement path to contract negotiation exists for a vendor without a current passed scorecard", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "PR-03-E3", "description": "qualified_vendor_list with last_reviewed_date and scorecard_expiry_date for each entry, confirmed updated within the last quarter by Vendor Management", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PR-03-E4", "description": "vendor_exception_records for any vendor granted an exception below the minimum threshold, each with documented General Counsel approval and risk assessment", "evidence_type": "human-review-record", "verification": "human" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://model/controls/OA-06", "id": "OA-06", "domain": "model", "name": "Third-Party Model and Vendor Risk Oversight", "validation_objective": "Every third-party AI model or component used in production must appear in the model inventory with vendor, model version, intake date, and use case documented. All active third-party vendors must have completed due diligence records and current annual risk reviews. Production integrations must implement version pinning verified against the registry, and vendor contracts must include model change notification, audit rights, and incident notification SLA clauses.", "blocking_effect": "blocks-deployment", "evidence_required": [ "third_party_ai_model_inventory current snapshot with fields: vendor, model_name, model_version, api_version, intake_date, use_cases, production_status \u2014 covering all active third-party AI components", "vendor_due_diligence_record for each active vendor, including security practices assessment, data governance review, model documentation review, and governance/safety practice assessment for high-risk use cases", "contract_clause_compliance_checklist for each vendor agreement, confirming presence of: 30-day material change notification, audit rights or third-party audit acceptance, 24-hour security incident SLA, and data residency/confidentiality terms", "annual_vendor_risk_review_report for each active vendor covering the preceding 12 months, with risk rating, material incidents noted, and recommended actions" ], "evidence": [ { "id": "OA-06-E1", "description": "third_party_ai_model_inventory current snapshot with fields: vendor, model_name, model_version, api_version, intake_date, use_cases, production_status \u2014 covering all active third-party AI components", "evidence_type": "third-party-audit-report", "verification": "third-party" }, { "id": "OA-06-E2", "description": "vendor_due_diligence_record for each active vendor, including security practices assessment, data governance review, model documentation review, and governance/safety practice assessment for high-risk use cases", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-06-E3", "description": "contract_clause_compliance_checklist for each vendor agreement, confirming presence of: 30-day material change notification, audit rights or third-party audit acceptance, 24-hour security incident SLA, and data residency/confidentiality terms", "evidence_type": "third-party-audit-report", "verification": "third-party" }, { "id": "OA-06-E4", "description": "annual_vendor_risk_review_report for each active vendor covering the preceding 12 months, with risk rating, material incidents noted, and recommended actions", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN-6.1 (GOVERN function) provides that policies address AI risks associated with third-party entities, including IP-infringement risks. OA-06\u2019s vendor due diligence, contract requirements, and substitution planning implement the third-party risk policies this subcategory requires." }, { "control": "apeiris://agentic/controls/AT-06", "id": "AT-06", "domain": "agentic", "name": "Third-Party Plugin Vetting and Sandboxing", "validation_objective": "Proves that every third-party plugin and MCP server in the approved registry has a documented security vetting record and executes within a sandboxed environment that limits access to agent context and host infrastructure. The testable claim is that no unapproved or un-sandboxed external plugin can be invoked by any agent in the deployment.", "blocking_effect": "advisory", "evidence_required": [ "Plugin registry export listing all registered third-party plugins with completed vetting checklist references and approval authorization records", "Sandbox runtime configuration audit confirming process isolation, context scoping, filesystem restrictions, and egress monitoring for sampled plugins", "Network egress monitoring logs from sandbox environments showing destination-level logging coverage for all plugin invocations over a 30-day window", "Plugin revocation procedure test records demonstrating successful removal and invocation blocking within the defined response window", "Continuous monitoring subscription records for vendor vulnerability feeds and post-approval security change alerts" ], "evidence": [ { "id": "AT-06-E1", "description": "Plugin registry export listing all registered third-party plugins with completed vetting checklist references and approval authorization records", "evidence_type": "third-party-audit-report", "verification": "third-party" }, { "id": "AT-06-E2", "description": "Sandbox runtime configuration audit confirming process isolation, context scoping, filesystem restrictions, and egress monitoring for sampled plugins", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "AT-06-E3", "description": "Network egress monitoring logs from sandbox environments showing destination-level logging coverage for all plugin invocations over a 30-day window", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "AT-06-E4", "description": "Plugin revocation procedure test records demonstrating successful removal and invocation blocking within the defined response window", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "AT-06-E5", "description": "Continuous monitoring subscription records for vendor vulnerability feeds and post-approval security change alerts", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN 6.1 requires policies and procedures addressing AI risks associated with third-party software and services. Formal plugin vetting and sandboxing implements those policies for the agent tool supply chain, where third-party code executes with agent-granted capabilities." } ] }, { "requirement_id": "MAP-1.1", "section": "MAP 1.1", "title": "Context established for AI risk assessment", "text": "Context is established for the AI risk assessment, including the organizational mission, purpose, and risk tolerance.", "verdict": "supported", "coverage": "direct", "notes": "EV-09 classifies risk and applicability; AG-03 formalizes the agentic risk assessment context; PV-01 declares operating intent as the foundational context anchor.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/EV-09", "id": "EV-09", "domain": "model", "name": "Risk and Applicability Classification", "validation_objective": "Every model system has a signed classification record produced before any evaluation work begins, containing a documented EU AI Act classification with provision-specific rationale referencing Articles 5, 6, 50, 51, and Annex III as applicable, an SR 26-2 model risk tier for in-scope institutions, a capability tier, and the full applicable Apeiris profiles list; the model registry gate prevents advancement to evaluation stage without this record; and re-classification is triggered on any significant change to use case, capability level, or applicable regulation.", "blocking_effect": "blocks-deployment", "evidence_required": [ "signed_classification_record containing eu_ai_act_classification with specific provision references, sr_262_tier where applicable, capability_tier, applicable_profiles list, mandatory_controls inventory, and obligations_inventory \u2014 produced before any evaluation artifact is created", "classification_questionnaire_responses document answering all required dimensions: intended_use_cases, affected_populations, decision_automation_level, human_oversight_mechanisms, deployment_jurisdiction, compute_budget, parameter_count", "non_high_risk_exclusion_rationale for systems classified below high-risk, explicitly addressing each relevant Annex III category with documented rationale for exclusion", "classification_review_records for all re-classification events documenting trigger_event, prior_classification, new_classification, and rationale with effective_date", "iso_42005_impact_assessment for high-impact-decision and eu-high-risk profile systems per ISO/IEC 42005:2025" ], "evidence": [ { "id": "EV-09-E1", "description": "signed_classification_record containing eu_ai_act_classification with specific provision references, sr_262_tier where applicable, capability_tier, applicable_profiles list, mandatory_controls inventory, and obligations_inventory \u2014 produced before any evaluation artifact is created", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-09-E2", "description": "classification_questionnaire_responses document answering all required dimensions: intended_use_cases, affected_populations, decision_automation_level, human_oversight_mechanisms, deployment_jurisdiction, compute_budget, parameter_count", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E3", "description": "non_high_risk_exclusion_rationale for systems classified below high-risk, explicitly addressing each relevant Annex III category with documented rationale for exclusion", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E4", "description": "classification_review_records for all re-classification events documenting trigger_event, prior_classification, new_classification, and rationale with effective_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E5", "description": "iso_42005_impact_assessment for high-impact-decision and eu-high-risk profile systems per ISO/IEC 42005:2025", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP-1.5 (MAP function) provides that organizational risk tolerances are determined and documented. EV-09\u2019s risk and applicability classification turns documented risk tolerances into a per-system determination of which controls and obligations apply." }, { "control": "apeiris://agentic/controls/AG-03", "id": "AG-03", "domain": "agentic", "name": "Agentic AI Risk Assessment Framework", "validation_objective": "Every production AI agent has a completed, current risk assessment evaluated against all five framework dimensions, with the resulting consequence tier documented and linked to the deployment approval and control mitigation plan.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "Annual risk reassessment records for all Critical-tier agents" ], "evidence": [ { "id": "AG-03-E1", "description": "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E2", "description": "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E3", "description": "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E4", "description": "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E5", "description": "Annual risk reassessment records for all Critical-tier agents", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP 5.1 requires assessing the likelihood and magnitude of identified AI impacts in deployment context. The five-dimension agentic risk scoring model is a structured method for exactly that assessment across autonomy, reversibility, and blast-radius dimensions." }, { "control": "apeiris://authority/controls/PV-01", "id": "PV-01", "domain": "authority", "name": "Operating Intent Declaration", "validation_objective": "Every active AI system deployment must have a machine-readable, cryptographically signed intent declaration registered in the authority control registry before production activation. The deployment pipeline must block agent activation when no valid, unexpired declaration with all required schema fields is present.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Signed intent declaration artifact with canonical_id, authorized_action_types, context_scope, principal_id, valid_from, and valid_until fields for every active AI deployment", "Deployment gate rejection logs demonstrating that agent activations without a registered, unexpired declaration were blocked, with fields for system_id, attempted_at, and rejection_reason", "Authority control registry export cross-referencing each active deployment to its current declaration record and cryptographic signature", "Principal authorization verification record confirming the signing identity has organizational authority to bind the enterprise to the declared scope", "Renewal audit trail linking declaration version history to deployment lifecycle events and authorizing principal identity" ], "evidence": [ { "id": "PV-01-E1", "description": "Signed intent declaration artifact with canonical_id, authorized_action_types, context_scope, principal_id, valid_from, and valid_until fields for every active AI deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PV-01-E2", "description": "Deployment gate rejection logs demonstrating that agent activations without a registered, unexpired declaration were blocked, with fields for system_id, attempted_at, and rejection_reason", "evidence_type": "audit-log", "verification": "automated" }, { "id": "PV-01-E3", "description": "Authority control registry export cross-referencing each active deployment to its current declaration record and cryptographic signature", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "PV-01-E4", "description": "Principal authorization verification record confirming the signing identity has organizational authority to bind the enterprise to the declared scope", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PV-01-E5", "description": "Renewal audit trail linking declaration version history to deployment lifecycle events and authorizing principal identity", "evidence_type": "audit-log", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "A machine-readable intent declaration operationalizes trustworthy-AI scope in policy but not all GOVERN 1.2 characteristics." } ] }, { "requirement_id": "MAP-1.2", "section": "MAP 1.2", "title": "Purpose and beneficial uses of AI system identified", "text": "The purpose, beneficial uses, and intended deployment context of the AI system are clearly identified and documented.", "verdict": "supported", "coverage": "direct", "notes": "PV-01 declares operating intent; LI-07 requires capability and limitation declarations including intended use; PV-03 reviews intended purpose alignment.", "control_count": 3, "proof_chain": [ { "control": "apeiris://authority/controls/PV-01", "id": "PV-01", "domain": "authority", "name": "Operating Intent Declaration", "validation_objective": "Every active AI system deployment must have a machine-readable, cryptographically signed intent declaration registered in the authority control registry before production activation. The deployment pipeline must block agent activation when no valid, unexpired declaration with all required schema fields is present.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Signed intent declaration artifact with canonical_id, authorized_action_types, context_scope, principal_id, valid_from, and valid_until fields for every active AI deployment", "Deployment gate rejection logs demonstrating that agent activations without a registered, unexpired declaration were blocked, with fields for system_id, attempted_at, and rejection_reason", "Authority control registry export cross-referencing each active deployment to its current declaration record and cryptographic signature", "Principal authorization verification record confirming the signing identity has organizational authority to bind the enterprise to the declared scope", "Renewal audit trail linking declaration version history to deployment lifecycle events and authorizing principal identity" ], "evidence": [ { "id": "PV-01-E1", "description": "Signed intent declaration artifact with canonical_id, authorized_action_types, context_scope, principal_id, valid_from, and valid_until fields for every active AI deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PV-01-E2", "description": "Deployment gate rejection logs demonstrating that agent activations without a registered, unexpired declaration were blocked, with fields for system_id, attempted_at, and rejection_reason", "evidence_type": "audit-log", "verification": "automated" }, { "id": "PV-01-E3", "description": "Authority control registry export cross-referencing each active deployment to its current declaration record and cryptographic signature", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "PV-01-E4", "description": "Principal authorization verification record confirming the signing identity has organizational authority to bind the enterprise to the declared scope", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PV-01-E5", "description": "Renewal audit trail linking declaration version history to deployment lifecycle events and authorizing principal identity", "evidence_type": "audit-log", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "A machine-readable intent declaration operationalizes trustworthy-AI scope in policy but not all GOVERN 1.2 characteristics." }, { "control": "apeiris://model/controls/LI-07", "id": "LI-07", "domain": "model", "name": "Capability and Limitation Declaration \u2014 Intended Use, Constraints,...", "validation_objective": "Every registered model must have a structured, schema-validated capability-limitation declaration with all five required dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, and knowledge_cutoff) substantively populated with population- and context-qualified entries, returned as structured metadata in the model registry API response; registration must be blocked when any dimension is absent or empty; and the model's observable behavior for post-knowledge-cutoff queries must be consistent with the declared uncertainty_bounds.", "blocking_effect": "blocks-deployment", "evidence_required": [ "capability_limitation_declaration with all five dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, knowledge_cutoff) substantively populated with population-qualified and context-qualified entries, version-locked to the artifact hash", "registry_api_response_sample demonstrating that the capability_limitation_declaration object is returned as structured metadata in the model registry API response for the model's registered ID without requiring separate documentation lookup", "cutoff_behavior_test_result showing model responses to at least three post-knowledge-cutoff factual queries compared against the declared uncertainty_bounds, confirming the model acknowledges the limitation rather than confabulating confident answers", "registration_rejection_log showing that a model registration attempt with an empty out_of_scope_uses field was blocked with an error identifying the specific missing dimension" ], "evidence": [ { "id": "LI-07-E1", "description": "capability_limitation_declaration with all five dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, knowledge_cutoff) substantively populated with population-qualified and context-qualified entries, version-locked to the artifact hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E2", "description": "registry_api_response_sample demonstrating that the capability_limitation_declaration object is returned as structured metadata in the model registry API response for the model's registered ID without requiring separate documentation lookup", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E3", "description": "cutoff_behavior_test_result showing model responses to at least three post-knowledge-cutoff factual queries compared against the declared uncertainty_bounds, confirming the model acknowledges the limitation rather than confabulating confident answers", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E4", "description": "registration_rejection_log showing that a model registration attempt with an empty out_of_scope_uses field was blocked with an error identifying the specific missing dimension", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP-2.2 (MAP function) provides that information about the AI system\u2019s knowledge limits and how output may be utilized and overseen by humans is documented. LI-07\u2019s capability and limitation declaration \u2014 intended uses, knowledge cutoff, and unsupported domains \u2014 is precisely the knowledge-limits documentation this subcategory requires." }, { "control": "apeiris://authority/controls/PV-03", "id": "PV-03", "domain": "authority", "name": "Intended Purpose Alignment Review", "validation_objective": "All active AI deployments must have a documented alignment review completed within the defined risk-tiered cadence. Each review must compare a structured behavioral log against the deployed behavioral profile and produce a signed review record; any material drift finding must trigger a re-authorization workflow before the system continues operating unchanged.", "blocking_effect": "requires-review", "evidence_required": [ "Behavioral profile specification linked to each active intent declaration, defining expected action type distribution ranges, resource access frequency bands, and acceptable escalation trigger rates for the review period", "Structured behavioral log summaries covering the review period, with action type distributions, resource access patterns, and anomaly event counts compared against profile thresholds", "Signed alignment review records with reviewer_id, comparison_methodology, drift_findings, determination_of_alignment, and review_completed_at for all active deployments within the defined cadence", "Re-authorization records for any deployment where material drift was identified, including the triggering drift finding, remediation action, and updated or reaffirmed intent declaration version" ], "evidence": [ { "id": "PV-03-E1", "description": "Behavioral profile specification linked to each active intent declaration, defining expected action type distribution ranges, resource access frequency bands, and acceptable escalation trigger rates for the review period", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PV-03-E2", "description": "Structured behavioral log summaries covering the review period, with action type distributions, resource access patterns, and anomaly event counts compared against profile thresholds", "evidence_type": "audit-log", "verification": "automated" }, { "id": "PV-03-E3", "description": "Signed alignment review records with reviewer_id, comparison_methodology, drift_findings, determination_of_alignment, and review_completed_at for all active deployments within the defined cadence", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PV-03-E4", "description": "Re-authorization records for any deployment where material drift was identified, including the triggering drift finding, remediation action, and updated or reaffirmed intent declaration version", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "Re-authorization triggered by drift routes decisions to leadership, partially addressing GOVERN 2.3 executive accountability." } ] }, { "requirement_id": "MAP-1.3", "section": "MAP 1.3", "title": "Scientific validity and fitness for purpose established", "text": "The AI system's scientific basis and fitness for purpose are established and verified prior to deployment.", "verdict": "supported", "coverage": "direct", "notes": "EV-02 evaluates fitness, safety, reliability, and policy conformance; LI-04 requires structured model documentation; EV-06 enforces reproducible evaluation design.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/EV-02", "id": "EV-02", "domain": "model", "name": "Fitness, Safety, Reliability and Policy-Conformance Evaluation", "validation_objective": "Before deployment, every model has been evaluated against pre-specified, dimension-level pass/fail thresholds \u2014 fitness, safety, reliability, and policy-conformance \u2014 with results documented against the model artifact hash and evaluation suite version. No threshold is modified after evaluation begins, and any threshold trade-off decision is documented as a named risk-acceptance record before the deployment manifest is signed.", "blocking_effect": "blocks-deployment", "evidence_required": [ "pre_specified_evaluation_protocol with model_artifact_hash, evaluation_suite_version, and per-dimension thresholds (fitness accuracy target, safety refusal rate, reliability error budget, policy-conformance violation rate), signed by the evaluation lead before testing begins \u2014 not after results are known", "dimension_level_evaluation_results showing per-dimension metric values, pass/fail verdict against pre-specified threshold, and model_artifact_hash confirming results correspond to the evaluated version", "evaluation_suite_provenance_record confirming that evaluation datasets are disjoint from training data, with contamination-check reference to TG-05 attestation", "risk_acceptance_record for any dimension where the pass threshold was not met but deployment was authorized, documenting named risk-accepter, specific capability gap, deployment risk consequence, and remediation deadline" ], "evidence": [ { "id": "EV-02-E1", "description": "pre_specified_evaluation_protocol with model_artifact_hash, evaluation_suite_version, and per-dimension thresholds (fitness accuracy target, safety refusal rate, reliability error budget, policy-conformance violation rate), signed by the evaluation lead before testing begins \u2014 not after results are known", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-02-E2", "description": "dimension_level_evaluation_results showing per-dimension metric values, pass/fail verdict against pre-specified threshold, and model_artifact_hash confirming results correspond to the evaluated version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-02-E3", "description": "evaluation_suite_provenance_record confirming that evaluation datasets are disjoint from training data, with contamination-check reference to TG-05 attestation", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-02-E4", "description": "risk_acceptance_record for any dimension where the pass threshold was not met but deployment was authorized, documenting named risk-accepter, specific capability gap, deployment risk consequence, and remediation deadline", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.3 (MEASURE function) provides that AI system performance or assurance criteria are measured and demonstrated for conditions similar to deployment. EV-02\u2019s fitness, safety, reliability, and policy-conformance dimensions measure and demonstrate the system\u2019s assurance criteria before deployment." }, { "control": "apeiris://model/controls/LI-04", "id": "LI-04", "domain": "model", "name": "Structured Model Documentation \u2014 Complete Model Card with All Required Sections", "validation_objective": "Every model submitted for registration must have a schema-validated model card with all nine Mitchell et al. 2019 sections substantively populated and passing field-level validation rules; the model card must be version-locked to the artifact hash and returned as structured metadata from the registry API; and registration must be blocked when any required section is absent, empty, or contains only placeholder text.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_card_completeness_validation_report showing pass/fail status per section with field-level validation results, registration blocking decision, and validation timestamp for the current artifact version", "versioned_model_card artifact linked to the specific model artifact hash with all nine Mitchell et al. sections containing substantive content (not placeholder text), retrievable from the registry by artifact hash", "model_registry_entry showing the current model card version hash stored alongside the artifact hash as paired immutable fields", "eu_ai_act_annex_iv_supplemental_record for EU AI Act high-risk in-scope systems confirming Annex IV technical documentation fields are populated in addition to the nine Mitchell et al. sections" ], "evidence": [ { "id": "LI-04-E1", "description": "model_card_completeness_validation_report showing pass/fail status per section with field-level validation results, registration blocking decision, and validation timestamp for the current artifact version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-04-E2", "description": "versioned_model_card artifact linked to the specific model artifact hash with all nine Mitchell et al. sections containing substantive content (not placeholder text), retrievable from the registry by artifact hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-04-E3", "description": "model_registry_entry showing the current model card version hash stored alongside the artifact hash as paired immutable fields", "evidence_type": "model-card", "verification": "attested" }, { "id": "LI-04-E4", "description": "eu_ai_act_annex_iv_supplemental_record for EU AI Act high-risk in-scope systems confirming Annex IV technical documentation fields are populated in addition to the nine Mitchell et al. sections", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN-4.2 (GOVERN function) provides that organizational teams document the risks and potential impacts of the AI technology they develop and deploy. A mandatory, schema-validated model card is the primary artifact in which a team documents its model\u2019s risks, limitations, and impacts, directly supporting this documentation practice." }, { "control": "apeiris://model/controls/EV-06", "id": "EV-06", "domain": "model", "name": "Reproducible Evaluation Design", "validation_objective": "Every evaluation run against a model artifact can be independently reproduced from the evaluation design document alone within the defined tolerance by a party who was not involved in the original run; all benchmarks have documented contamination screening results; and all evaluation artifacts are signed with SHA-256 content-addressed hashes recorded in the evaluation manifest.", "blocking_effect": "blocks-deployment", "evidence_required": [ "version_controlled_benchmark_selection_document with pre-specified selection_criteria, benchmark_ids, known_limitations, and alternatives_considered \u2014 signed and committed before any evaluation run begins", "contamination_screening_report documenting screening_methodology, training_corpus_reference, per-benchmark contamination_result (clean/flagged/excluded), and screening_date", "evaluation_design_document capturing all reproduction parameters: random_seeds, software_dependency_versions with hashes, hardware_configuration, serving_framework_config, eval_script_version_and_hash, prompt_templates, and post_processing_steps", "independent_reproduction_run_record showing reproduction_results within the defined tolerance alongside original_results, confirming design document sufficiency for independent replication", "signed_evaluation_artifact_manifest listing SHA-256 hashes for all artifacts (design document, scripts, datasets, results) with signer_identity and key_identifier" ], "evidence": [ { "id": "EV-06-E1", "description": "version_controlled_benchmark_selection_document with pre-specified selection_criteria, benchmark_ids, known_limitations, and alternatives_considered \u2014 signed and committed before any evaluation run begins", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-06-E2", "description": "contamination_screening_report documenting screening_methodology, training_corpus_reference, per-benchmark contamination_result (clean/flagged/excluded), and screening_date", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-06-E3", "description": "evaluation_design_document capturing all reproduction parameters: random_seeds, software_dependency_versions with hashes, hardware_configuration, serving_framework_config, eval_script_version_and_hash, prompt_templates, and post_processing_steps", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-06-E4", "description": "independent_reproduction_run_record showing reproduction_results within the defined tolerance alongside original_results, confirming design document sufficiency for independent replication", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-06-E5", "description": "signed_evaluation_artifact_manifest listing SHA-256 hashes for all artifacts (design document, scripts, datasets, results) with signer_identity and key_identifier", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.1 (MEASURE function) provides that test sets, metrics, and details about the tools used during TEVV are documented. EV-06\u2019s reproducible evaluation design pins the test sets, metrics, seeds, and environments so the TEVV documentation this subcategory requires is complete and re-runnable." } ] }, { "requirement_id": "MAP-1.4", "section": "MAP 1.4", "title": "Intended use cases and operational requirements documented", "text": "The AI system's intended use cases, operational requirements, and operational context are documented.", "verdict": "supported", "coverage": "direct", "notes": "LI-07 requires explicit capability and limitation declaration; PV-07 attests deployment scope; LI-04 mandates a complete model card with all required sections.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/LI-07", "id": "LI-07", "domain": "model", "name": "Capability and Limitation Declaration \u2014 Intended Use, Constraints,...", "validation_objective": "Every registered model must have a structured, schema-validated capability-limitation declaration with all five required dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, and knowledge_cutoff) substantively populated with population- and context-qualified entries, returned as structured metadata in the model registry API response; registration must be blocked when any dimension is absent or empty; and the model's observable behavior for post-knowledge-cutoff queries must be consistent with the declared uncertainty_bounds.", "blocking_effect": "blocks-deployment", "evidence_required": [ "capability_limitation_declaration with all five dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, knowledge_cutoff) substantively populated with population-qualified and context-qualified entries, version-locked to the artifact hash", "registry_api_response_sample demonstrating that the capability_limitation_declaration object is returned as structured metadata in the model registry API response for the model's registered ID without requiring separate documentation lookup", "cutoff_behavior_test_result showing model responses to at least three post-knowledge-cutoff factual queries compared against the declared uncertainty_bounds, confirming the model acknowledges the limitation rather than confabulating confident answers", "registration_rejection_log showing that a model registration attempt with an empty out_of_scope_uses field was blocked with an error identifying the specific missing dimension" ], "evidence": [ { "id": "LI-07-E1", "description": "capability_limitation_declaration with all five dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, knowledge_cutoff) substantively populated with population-qualified and context-qualified entries, version-locked to the artifact hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E2", "description": "registry_api_response_sample demonstrating that the capability_limitation_declaration object is returned as structured metadata in the model registry API response for the model's registered ID without requiring separate documentation lookup", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E3", "description": "cutoff_behavior_test_result showing model responses to at least three post-knowledge-cutoff factual queries compared against the declared uncertainty_bounds, confirming the model acknowledges the limitation rather than confabulating confident answers", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E4", "description": "registration_rejection_log showing that a model registration attempt with an empty out_of_scope_uses field was blocked with an error identifying the specific missing dimension", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP-2.2 (MAP function) provides that information about the AI system\u2019s knowledge limits and how output may be utilized and overseen by humans is documented. LI-07\u2019s capability and limitation declaration \u2014 intended uses, knowledge cutoff, and unsupported domains \u2014 is precisely the knowledge-limits documentation this subcategory requires." }, { "control": "apeiris://authority/controls/PV-07", "id": "PV-07", "domain": "authority", "name": "Deployment Scope Attestation", "validation_objective": "Every active AI deployment must have a current, signed deployment scope attestation in the authority registry enumerating authorized geographic regions, legal entities, user population categories, use-case types, and applicable regulatory jurisdictions. The attestation must bear the signature of a named principal with verifiable authority over the declared scope dimensions, and runtime monitoring must detect and alert on AI activity outside attested boundaries.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Signed deployment scope attestation artifacts in the authority registry for all active AI deployments, with fields for geographic_regions, legal_entities, user_population_categories, use_case_types, applicable_jurisdictions, signatory_id, valid_from, and valid_until", "Signatory authority verification records confirming each signing principal has organizational authority over the specific geographic, legal entity, and jurisdictional scope dimensions they attested", "Out-of-scope activity monitoring alerts for any AI system operation detected outside attested boundaries, with system_id, detected_activity, attested_scope, and detection_timestamp", "Renewal records showing timely scope attestation renewal at defined intervals and following material scope dimension changes such as new market entry or entity restructuring" ], "evidence": [ { "id": "PV-07-E1", "description": "Signed deployment scope attestation artifacts in the authority registry for all active AI deployments, with fields for geographic_regions, legal_entities, user_population_categories, use_case_types, applicable_jurisdictions, signatory_id, valid_from, and valid_until", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PV-07-E2", "description": "Signatory authority verification records confirming each signing principal has organizational authority over the specific geographic, legal entity, and jurisdictional scope dimensions they attested", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PV-07-E3", "description": "Out-of-scope activity monitoring alerts for any AI system operation detected outside attested boundaries, with system_id, detected_activity, attested_scope, and detection_timestamp", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "PV-07-E4", "description": "Renewal records showing timely scope attestation renewal at defined intervals and following material scope dimension changes such as new market entry or entity restructuring", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "adjacent", "basis": "anchored", "relation": "equivalent_to", "rationale": "Scope attestation governs authorized operation, not the safe decommissioning GOVERN 1.7 addresses." }, { "control": "apeiris://model/controls/LI-04", "id": "LI-04", "domain": "model", "name": "Structured Model Documentation \u2014 Complete Model Card with All Required Sections", "validation_objective": "Every model submitted for registration must have a schema-validated model card with all nine Mitchell et al. 2019 sections substantively populated and passing field-level validation rules; the model card must be version-locked to the artifact hash and returned as structured metadata from the registry API; and registration must be blocked when any required section is absent, empty, or contains only placeholder text.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_card_completeness_validation_report showing pass/fail status per section with field-level validation results, registration blocking decision, and validation timestamp for the current artifact version", "versioned_model_card artifact linked to the specific model artifact hash with all nine Mitchell et al. sections containing substantive content (not placeholder text), retrievable from the registry by artifact hash", "model_registry_entry showing the current model card version hash stored alongside the artifact hash as paired immutable fields", "eu_ai_act_annex_iv_supplemental_record for EU AI Act high-risk in-scope systems confirming Annex IV technical documentation fields are populated in addition to the nine Mitchell et al. sections" ], "evidence": [ { "id": "LI-04-E1", "description": "model_card_completeness_validation_report showing pass/fail status per section with field-level validation results, registration blocking decision, and validation timestamp for the current artifact version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-04-E2", "description": "versioned_model_card artifact linked to the specific model artifact hash with all nine Mitchell et al. sections containing substantive content (not placeholder text), retrievable from the registry by artifact hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-04-E3", "description": "model_registry_entry showing the current model card version hash stored alongside the artifact hash as paired immutable fields", "evidence_type": "model-card", "verification": "attested" }, { "id": "LI-04-E4", "description": "eu_ai_act_annex_iv_supplemental_record for EU AI Act high-risk in-scope systems confirming Annex IV technical documentation fields are populated in addition to the nine Mitchell et al. sections", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN-4.2 (GOVERN function) provides that organizational teams document the risks and potential impacts of the AI technology they develop and deploy. A mandatory, schema-validated model card is the primary artifact in which a team documents its model\u2019s risks, limitations, and impacts, directly supporting this documentation practice." } ] }, { "requirement_id": "MAP-1.5", "section": "MAP 1.5", "title": "Risk tolerances considered for AI systems", "text": "Organizational risk tolerances are considered and documented in the context of the specific AI system being assessed.", "verdict": "partial", "coverage": "partial", "notes": "EF-03 defines the ethical risk appetite; AG-03 incorporates risk assessment. However, mapping risk tolerance parameters to individual system deployment decisions is not fully specified across all 12 domains.", "control_count": 2, "proof_chain": [ { "control": "apeiris://ethics/controls/EF-03", "id": "EF-03", "domain": "ethics", "name": "Ethical Risk Appetite Definition", "validation_objective": "The organization must have a board-approved Ethical Risk Appetite Statement specifying at least one absolute prohibition (zero-tolerance harm type that unconditionally blocks deployment), at least one conditional tolerance band with a measurable residual risk threshold, and a documented exception governance process naming the authority level required to grant exceptions. Every high-risk AI system deployment decision must reference the applicable risk appetite tier in its documentation.", "blocking_effect": "blocks-deployment", "evidence_required": [ "ethical_risk_appetite_statement document with board_approval_record, approval_date, and version, containing an absolute_prohibitions list with named harm types and a conditional_tolerance_bands list with measurable residual_risk_thresholds", "exception_governance_process_document specifying who holds exception authority by harm category, required documentation for each exception request, and conditions that trigger escalation to board level", "ai_system_deployment_records for all high-risk systems linking each deployment decision to the applicable risk_appetite_tier and referencing the current statement version", "exception_register with each entry including system_id, harm_type, approver_role, approval_date, rationale, and next_review_date", "annual_review_completion_record with board re-approval date and change log for the current review cycle" ], "evidence": [ { "id": "EF-03-E1", "description": "ethical_risk_appetite_statement document with board_approval_record, approval_date, and version, containing an absolute_prohibitions list with named harm types and a conditional_tolerance_bands list with measurable residual_risk_thresholds", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-03-E2", "description": "exception_governance_process_document specifying who holds exception authority by harm category, required documentation for each exception request, and conditions that trigger escalation to board level", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-03-E3", "description": "ai_system_deployment_records for all high-risk systems linking each deployment decision to the applicable risk_appetite_tier and referencing the current statement version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-03-E4", "description": "exception_register with each entry including system_id, harm_type, approver_role, approval_date, rationale, and next_review_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-03-E5", "description": "annual_review_completion_record with board re-approval date and change log for the current review cycle", "evidence_type": "audit-log", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN 1.3 requires that organizational risk tolerance for AI is defined and communicated, and GOVERN 4.1 requires that organizational risk posture is reflected in deployment decisions. The Ethical Risk Appetite Statement directly operationalizes both requirements." }, { "control": "apeiris://agentic/controls/AG-03", "id": "AG-03", "domain": "agentic", "name": "Agentic AI Risk Assessment Framework", "validation_objective": "Every production AI agent has a completed, current risk assessment evaluated against all five framework dimensions, with the resulting consequence tier documented and linked to the deployment approval and control mitigation plan.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "Annual risk reassessment records for all Critical-tier agents" ], "evidence": [ { "id": "AG-03-E1", "description": "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E2", "description": "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E3", "description": "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E4", "description": "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E5", "description": "Annual risk reassessment records for all Critical-tier agents", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP 5.1 requires assessing the likelihood and magnitude of identified AI impacts in deployment context. The five-dimension agentic risk scoring model is a structured method for exactly that assessment across autonomy, reversibility, and blast-radius dimensions." } ] }, { "requirement_id": "MAP-1.6", "section": "MAP 1.6", "title": "System requirements derived from risk tolerances established", "text": "System requirements, including requirements derived from organizational risk tolerances, are established and documented.", "verdict": "partial", "coverage": "partial", "notes": "PV-01 captures operating intent; AB-01 defines the authorized action scope manifest. A structured mechanism for deriving requirements directly from quantified risk tolerance values is partially addressed.", "control_count": 3, "proof_chain": [ { "control": "apeiris://authority/controls/PV-01", "id": "PV-01", "domain": "authority", "name": "Operating Intent Declaration", "validation_objective": "Every active AI system deployment must have a machine-readable, cryptographically signed intent declaration registered in the authority control registry before production activation. The deployment pipeline must block agent activation when no valid, unexpired declaration with all required schema fields is present.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Signed intent declaration artifact with canonical_id, authorized_action_types, context_scope, principal_id, valid_from, and valid_until fields for every active AI deployment", "Deployment gate rejection logs demonstrating that agent activations without a registered, unexpired declaration were blocked, with fields for system_id, attempted_at, and rejection_reason", "Authority control registry export cross-referencing each active deployment to its current declaration record and cryptographic signature", "Principal authorization verification record confirming the signing identity has organizational authority to bind the enterprise to the declared scope", "Renewal audit trail linking declaration version history to deployment lifecycle events and authorizing principal identity" ], "evidence": [ { "id": "PV-01-E1", "description": "Signed intent declaration artifact with canonical_id, authorized_action_types, context_scope, principal_id, valid_from, and valid_until fields for every active AI deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PV-01-E2", "description": "Deployment gate rejection logs demonstrating that agent activations without a registered, unexpired declaration were blocked, with fields for system_id, attempted_at, and rejection_reason", "evidence_type": "audit-log", "verification": "automated" }, { "id": "PV-01-E3", "description": "Authority control registry export cross-referencing each active deployment to its current declaration record and cryptographic signature", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "PV-01-E4", "description": "Principal authorization verification record confirming the signing identity has organizational authority to bind the enterprise to the declared scope", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PV-01-E5", "description": "Renewal audit trail linking declaration version history to deployment lifecycle events and authorizing principal identity", "evidence_type": "audit-log", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "A machine-readable intent declaration operationalizes trustworthy-AI scope in policy but not all GOVERN 1.2 characteristics." }, { "control": "apeiris://agentic/controls/AB-01", "id": "AB-01", "domain": "agentic", "name": "Authorized Action Scope Manifest", "validation_objective": "Prove that every deployed agent has a machine-readable action scope manifest enumerating its complete authorized action set, and that the platform enforcement layer blocks any attempt to execute an action not listed in the manifest. No action outside the manifest may execute without a manifest update that passes governance review.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "Machine-readable action scope manifest (JSON or YAML) signed and linked to the agent's registry entry with a version-matched reference", "Platform enforcement log showing at least one blocked out-of-manifest action attempt during the test period, or a probed block event from a compliance test", "Change history records for the manifest showing governance review approvals and approver identities for each scope expansion", "Agent registry entry with version identifier that matches the manifest reference exactly" ], "evidence": [ { "id": "AB-01-E1", "description": "Machine-readable action scope manifest (JSON or YAML) signed and linked to the agent's registry entry with a version-matched reference", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "AB-01-E2", "description": "Platform enforcement log showing at least one blocked out-of-manifest action attempt during the test period, or a probed block event from a compliance test", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AB-01-E3", "description": "Change history records for the manifest showing governance review approvals and approver identities for each scope expansion", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "AB-01-E4", "description": "Agent registry entry with version identifier that matches the manifest reference exactly", "evidence_type": "configuration-snapshot", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN 1.2 requires trustworthy-AI characteristics to be integrated into organizational policies, processes, and practices. A signed Action Scope Manifest turns the policy statement of what an agent may do into a machine-enforceable artifact, integrating the safe-operation policy into deployment practice itself." }, { "control": "apeiris://authority/controls/PO-01", "id": "PO-01", "domain": "authority", "name": "Internal Policy Register for AI Deployments", "validation_objective": "Every active AI deployment must have at least one current, non-expired policy register entry in the authoritative policy register, and that entry must contain version, effective date, scope, owning team, and deployment linkage fields. No AI deployment may enter or remain in production without a valid policy register reference confirmed by the deployment pipeline.", "blocking_effect": "blocks-deployment", "evidence_required": [ "policy_register_schema_document specifying required fields including policy_id, version, effective_date, expiry_date, owning_team, ai_deployment_scope, and authority_domain_applicability", "deployment_policy_linkage_audit_log confirming every active AI deployment has a corresponding current policy register entry with a non-expired effective date", "policy_register_access_control_matrix demonstrating that register modifications require dual authorization and all changes are attributed and logged", "deployment_pipeline_gate_configuration showing that AI deployment approval workflows validate the presence of a current policy register entry before proceeding" ], "evidence": [ { "id": "PO-01-E1", "description": "policy_register_schema_document specifying required fields including policy_id, version, effective_date, expiry_date, owning_team, ai_deployment_scope, and authority_domain_applicability", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-01-E2", "description": "deployment_policy_linkage_audit_log confirming every active AI deployment has a corresponding current policy register entry with a non-expired effective date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-01-E3", "description": "policy_register_access_control_matrix demonstrating that register modifications require dual authorization and all changes are attributed and logged", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-01-E4", "description": "deployment_pipeline_gate_configuration showing that AI deployment approval workflows validate the presence of a current policy register entry before proceeding", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "A register of AI governance policies operationalizes GOVERN 1.2 policy integration, partially." } ] }, { "requirement_id": "MAP-2.1", "section": "MAP 2.1", "title": "Scientific basis of AI system evaluated", "text": "The AI system's scientific basis has been evaluated and documented by appropriate subject matter experts.", "verdict": "supported", "coverage": "direct", "notes": "EV-02 provides comprehensive pre-deployment fitness and scientific validity assessment; EV-06 requires reproducible evaluation design; LI-07 documents capability and limitations based on evaluation findings.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/EV-02", "id": "EV-02", "domain": "model", "name": "Fitness, Safety, Reliability and Policy-Conformance Evaluation", "validation_objective": "Before deployment, every model has been evaluated against pre-specified, dimension-level pass/fail thresholds \u2014 fitness, safety, reliability, and policy-conformance \u2014 with results documented against the model artifact hash and evaluation suite version. No threshold is modified after evaluation begins, and any threshold trade-off decision is documented as a named risk-acceptance record before the deployment manifest is signed.", "blocking_effect": "blocks-deployment", "evidence_required": [ "pre_specified_evaluation_protocol with model_artifact_hash, evaluation_suite_version, and per-dimension thresholds (fitness accuracy target, safety refusal rate, reliability error budget, policy-conformance violation rate), signed by the evaluation lead before testing begins \u2014 not after results are known", "dimension_level_evaluation_results showing per-dimension metric values, pass/fail verdict against pre-specified threshold, and model_artifact_hash confirming results correspond to the evaluated version", "evaluation_suite_provenance_record confirming that evaluation datasets are disjoint from training data, with contamination-check reference to TG-05 attestation", "risk_acceptance_record for any dimension where the pass threshold was not met but deployment was authorized, documenting named risk-accepter, specific capability gap, deployment risk consequence, and remediation deadline" ], "evidence": [ { "id": "EV-02-E1", "description": "pre_specified_evaluation_protocol with model_artifact_hash, evaluation_suite_version, and per-dimension thresholds (fitness accuracy target, safety refusal rate, reliability error budget, policy-conformance violation rate), signed by the evaluation lead before testing begins \u2014 not after results are known", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-02-E2", "description": "dimension_level_evaluation_results showing per-dimension metric values, pass/fail verdict against pre-specified threshold, and model_artifact_hash confirming results correspond to the evaluated version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-02-E3", "description": "evaluation_suite_provenance_record confirming that evaluation datasets are disjoint from training data, with contamination-check reference to TG-05 attestation", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-02-E4", "description": "risk_acceptance_record for any dimension where the pass threshold was not met but deployment was authorized, documenting named risk-accepter, specific capability gap, deployment risk consequence, and remediation deadline", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.3 (MEASURE function) provides that AI system performance or assurance criteria are measured and demonstrated for conditions similar to deployment. EV-02\u2019s fitness, safety, reliability, and policy-conformance dimensions measure and demonstrate the system\u2019s assurance criteria before deployment." }, { "control": "apeiris://model/controls/EV-06", "id": "EV-06", "domain": "model", "name": "Reproducible Evaluation Design", "validation_objective": "Every evaluation run against a model artifact can be independently reproduced from the evaluation design document alone within the defined tolerance by a party who was not involved in the original run; all benchmarks have documented contamination screening results; and all evaluation artifacts are signed with SHA-256 content-addressed hashes recorded in the evaluation manifest.", "blocking_effect": "blocks-deployment", "evidence_required": [ "version_controlled_benchmark_selection_document with pre-specified selection_criteria, benchmark_ids, known_limitations, and alternatives_considered \u2014 signed and committed before any evaluation run begins", "contamination_screening_report documenting screening_methodology, training_corpus_reference, per-benchmark contamination_result (clean/flagged/excluded), and screening_date", "evaluation_design_document capturing all reproduction parameters: random_seeds, software_dependency_versions with hashes, hardware_configuration, serving_framework_config, eval_script_version_and_hash, prompt_templates, and post_processing_steps", "independent_reproduction_run_record showing reproduction_results within the defined tolerance alongside original_results, confirming design document sufficiency for independent replication", "signed_evaluation_artifact_manifest listing SHA-256 hashes for all artifacts (design document, scripts, datasets, results) with signer_identity and key_identifier" ], "evidence": [ { "id": "EV-06-E1", "description": "version_controlled_benchmark_selection_document with pre-specified selection_criteria, benchmark_ids, known_limitations, and alternatives_considered \u2014 signed and committed before any evaluation run begins", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-06-E2", "description": "contamination_screening_report documenting screening_methodology, training_corpus_reference, per-benchmark contamination_result (clean/flagged/excluded), and screening_date", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-06-E3", "description": "evaluation_design_document capturing all reproduction parameters: random_seeds, software_dependency_versions with hashes, hardware_configuration, serving_framework_config, eval_script_version_and_hash, prompt_templates, and post_processing_steps", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-06-E4", "description": "independent_reproduction_run_record showing reproduction_results within the defined tolerance alongside original_results, confirming design document sufficiency for independent replication", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-06-E5", "description": "signed_evaluation_artifact_manifest listing SHA-256 hashes for all artifacts (design document, scripts, datasets, results) with signer_identity and key_identifier", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.1 (MEASURE function) provides that test sets, metrics, and details about the tools used during TEVV are documented. EV-06\u2019s reproducible evaluation design pins the test sets, metrics, seeds, and environments so the TEVV documentation this subcategory requires is complete and re-runnable." }, { "control": "apeiris://model/controls/LI-07", "id": "LI-07", "domain": "model", "name": "Capability and Limitation Declaration \u2014 Intended Use, Constraints,...", "validation_objective": "Every registered model must have a structured, schema-validated capability-limitation declaration with all five required dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, and knowledge_cutoff) substantively populated with population- and context-qualified entries, returned as structured metadata in the model registry API response; registration must be blocked when any dimension is absent or empty; and the model's observable behavior for post-knowledge-cutoff queries must be consistent with the declared uncertainty_bounds.", "blocking_effect": "blocks-deployment", "evidence_required": [ "capability_limitation_declaration with all five dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, knowledge_cutoff) substantively populated with population-qualified and context-qualified entries, version-locked to the artifact hash", "registry_api_response_sample demonstrating that the capability_limitation_declaration object is returned as structured metadata in the model registry API response for the model's registered ID without requiring separate documentation lookup", "cutoff_behavior_test_result showing model responses to at least three post-knowledge-cutoff factual queries compared against the declared uncertainty_bounds, confirming the model acknowledges the limitation rather than confabulating confident answers", "registration_rejection_log showing that a model registration attempt with an empty out_of_scope_uses field was blocked with an error identifying the specific missing dimension" ], "evidence": [ { "id": "LI-07-E1", "description": "capability_limitation_declaration with all five dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, knowledge_cutoff) substantively populated with population-qualified and context-qualified entries, version-locked to the artifact hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E2", "description": "registry_api_response_sample demonstrating that the capability_limitation_declaration object is returned as structured metadata in the model registry API response for the model's registered ID without requiring separate documentation lookup", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E3", "description": "cutoff_behavior_test_result showing model responses to at least three post-knowledge-cutoff factual queries compared against the declared uncertainty_bounds, confirming the model acknowledges the limitation rather than confabulating confident answers", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E4", "description": "registration_rejection_log showing that a model registration attempt with an empty out_of_scope_uses field was blocked with an error identifying the specific missing dimension", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP-2.2 (MAP function) provides that information about the AI system\u2019s knowledge limits and how output may be utilized and overseen by humans is documented. LI-07\u2019s capability and limitation declaration \u2014 intended uses, knowledge cutoff, and unsupported domains \u2014 is precisely the knowledge-limits documentation this subcategory requires." } ] }, { "requirement_id": "MAP-2.2", "section": "MAP 2.2", "title": "Scientific basis established with appropriate methods", "text": "Scientific basis of the AI system has been established using appropriate methods and quantitative measures where feasible.", "verdict": "partial", "coverage": "partial", "notes": "EV-06 enforces reproducible evaluation; TG-01 requires data quality gates that underpin scientific rigor. The requirement for specific quantitative methods selection criteria is partially addressed \u2014 method justification is covered but not mandated at the granularity described in MAP 2.2.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/EV-06", "id": "EV-06", "domain": "model", "name": "Reproducible Evaluation Design", "validation_objective": "Every evaluation run against a model artifact can be independently reproduced from the evaluation design document alone within the defined tolerance by a party who was not involved in the original run; all benchmarks have documented contamination screening results; and all evaluation artifacts are signed with SHA-256 content-addressed hashes recorded in the evaluation manifest.", "blocking_effect": "blocks-deployment", "evidence_required": [ "version_controlled_benchmark_selection_document with pre-specified selection_criteria, benchmark_ids, known_limitations, and alternatives_considered \u2014 signed and committed before any evaluation run begins", "contamination_screening_report documenting screening_methodology, training_corpus_reference, per-benchmark contamination_result (clean/flagged/excluded), and screening_date", "evaluation_design_document capturing all reproduction parameters: random_seeds, software_dependency_versions with hashes, hardware_configuration, serving_framework_config, eval_script_version_and_hash, prompt_templates, and post_processing_steps", "independent_reproduction_run_record showing reproduction_results within the defined tolerance alongside original_results, confirming design document sufficiency for independent replication", "signed_evaluation_artifact_manifest listing SHA-256 hashes for all artifacts (design document, scripts, datasets, results) with signer_identity and key_identifier" ], "evidence": [ { "id": "EV-06-E1", "description": "version_controlled_benchmark_selection_document with pre-specified selection_criteria, benchmark_ids, known_limitations, and alternatives_considered \u2014 signed and committed before any evaluation run begins", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-06-E2", "description": "contamination_screening_report documenting screening_methodology, training_corpus_reference, per-benchmark contamination_result (clean/flagged/excluded), and screening_date", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-06-E3", "description": "evaluation_design_document capturing all reproduction parameters: random_seeds, software_dependency_versions with hashes, hardware_configuration, serving_framework_config, eval_script_version_and_hash, prompt_templates, and post_processing_steps", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-06-E4", "description": "independent_reproduction_run_record showing reproduction_results within the defined tolerance alongside original_results, confirming design document sufficiency for independent replication", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-06-E5", "description": "signed_evaluation_artifact_manifest listing SHA-256 hashes for all artifacts (design document, scripts, datasets, results) with signer_identity and key_identifier", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.1 (MEASURE function) provides that test sets, metrics, and details about the tools used during TEVV are documented. EV-06\u2019s reproducible evaluation design pins the test sets, metrics, seeds, and environments so the TEVV documentation this subcategory requires is complete and re-runnable." }, { "control": "apeiris://model/controls/TG-01", "id": "TG-01", "domain": "model", "name": "Training Data Quality Gates", "validation_objective": "No training run may be initiated unless the designated training dataset has passed automated schema validation, completeness checks, and provenance verification in the current pipeline run; all gate results must be logged with pass/fail status and linked to the training job record.", "blocking_effect": "blocks-deployment", "evidence_required": [ "training_data_quality_gate_report for the current training run showing schema validation results (expected vs. actual field types and cardinalities), completeness check results (null rates, minimum coverage thresholds), and provenance verification status (source hash match, chain-of-custody record reference)", "training_pipeline_block_log confirming that any training attempt that failed a quality gate was rejected before the training compute job was allocated", "dataset_provenance_record with source identifier, ingestion timestamp, data owner, and integrity hash for each training shard used in the run", "quality_threshold_configuration_document defining the pass/fail thresholds for schema validation, completeness, and provenance checks, reviewed and approved by the ML engineering lead" ], "evidence": [ { "id": "TG-01-E1", "description": "training_data_quality_gate_report for the current training run showing schema validation results (expected vs. actual field types and cardinalities), completeness check results (null rates, minimum coverage thresholds), and provenance verification status (source hash match, chain-of-custody record reference)", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "TG-01-E2", "description": "training_pipeline_block_log confirming that any training attempt that failed a quality gate was rejected before the training compute job was allocated", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-01-E3", "description": "dataset_provenance_record with source identifier, ingestion timestamp, data owner, and integrity hash for each training shard used in the run", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-01-E4", "description": "quality_threshold_configuration_document defining the pass/fail thresholds for schema validation, completeness, and provenance checks, reviewed and approved by the ML engineering lead", "evidence_type": "data-lineage-record", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP-2.3 (MAP function) provides that scientific integrity and TEVV considerations, including data collection and selection, are identified and documented. TG-01\u2019s automated quality gates enforce documented data-selection and quality standards at pipeline time, supporting scientific integrity of the training process." }, { "control": "apeiris://model/controls/EV-02", "id": "EV-02", "domain": "model", "name": "Fitness, Safety, Reliability and Policy-Conformance Evaluation", "validation_objective": "Before deployment, every model has been evaluated against pre-specified, dimension-level pass/fail thresholds \u2014 fitness, safety, reliability, and policy-conformance \u2014 with results documented against the model artifact hash and evaluation suite version. No threshold is modified after evaluation begins, and any threshold trade-off decision is documented as a named risk-acceptance record before the deployment manifest is signed.", "blocking_effect": "blocks-deployment", "evidence_required": [ "pre_specified_evaluation_protocol with model_artifact_hash, evaluation_suite_version, and per-dimension thresholds (fitness accuracy target, safety refusal rate, reliability error budget, policy-conformance violation rate), signed by the evaluation lead before testing begins \u2014 not after results are known", "dimension_level_evaluation_results showing per-dimension metric values, pass/fail verdict against pre-specified threshold, and model_artifact_hash confirming results correspond to the evaluated version", "evaluation_suite_provenance_record confirming that evaluation datasets are disjoint from training data, with contamination-check reference to TG-05 attestation", "risk_acceptance_record for any dimension where the pass threshold was not met but deployment was authorized, documenting named risk-accepter, specific capability gap, deployment risk consequence, and remediation deadline" ], "evidence": [ { "id": "EV-02-E1", "description": "pre_specified_evaluation_protocol with model_artifact_hash, evaluation_suite_version, and per-dimension thresholds (fitness accuracy target, safety refusal rate, reliability error budget, policy-conformance violation rate), signed by the evaluation lead before testing begins \u2014 not after results are known", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-02-E2", "description": "dimension_level_evaluation_results showing per-dimension metric values, pass/fail verdict against pre-specified threshold, and model_artifact_hash confirming results correspond to the evaluated version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-02-E3", "description": "evaluation_suite_provenance_record confirming that evaluation datasets are disjoint from training data, with contamination-check reference to TG-05 attestation", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-02-E4", "description": "risk_acceptance_record for any dimension where the pass threshold was not met but deployment was authorized, documenting named risk-accepter, specific capability gap, deployment risk consequence, and remediation deadline", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.3 (MEASURE function) provides that AI system performance or assurance criteria are measured and demonstrated for conditions similar to deployment. EV-02\u2019s fitness, safety, reliability, and policy-conformance dimensions measure and demonstrate the system\u2019s assurance criteria before deployment." } ] }, { "requirement_id": "MAP-2.3", "section": "MAP 2.3", "title": "AI system risk classifications documented", "text": "AI system risk classifications and categorizations are documented using established frameworks or methods.", "verdict": "supported", "coverage": "direct", "notes": "EV-09 classifies risk and applicability; AG-03 provides a structured risk assessment framework; EF-04 adds ethics impact assessment to capture harmful use scenarios.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/EV-09", "id": "EV-09", "domain": "model", "name": "Risk and Applicability Classification", "validation_objective": "Every model system has a signed classification record produced before any evaluation work begins, containing a documented EU AI Act classification with provision-specific rationale referencing Articles 5, 6, 50, 51, and Annex III as applicable, an SR 26-2 model risk tier for in-scope institutions, a capability tier, and the full applicable Apeiris profiles list; the model registry gate prevents advancement to evaluation stage without this record; and re-classification is triggered on any significant change to use case, capability level, or applicable regulation.", "blocking_effect": "blocks-deployment", "evidence_required": [ "signed_classification_record containing eu_ai_act_classification with specific provision references, sr_262_tier where applicable, capability_tier, applicable_profiles list, mandatory_controls inventory, and obligations_inventory \u2014 produced before any evaluation artifact is created", "classification_questionnaire_responses document answering all required dimensions: intended_use_cases, affected_populations, decision_automation_level, human_oversight_mechanisms, deployment_jurisdiction, compute_budget, parameter_count", "non_high_risk_exclusion_rationale for systems classified below high-risk, explicitly addressing each relevant Annex III category with documented rationale for exclusion", "classification_review_records for all re-classification events documenting trigger_event, prior_classification, new_classification, and rationale with effective_date", "iso_42005_impact_assessment for high-impact-decision and eu-high-risk profile systems per ISO/IEC 42005:2025" ], "evidence": [ { "id": "EV-09-E1", "description": "signed_classification_record containing eu_ai_act_classification with specific provision references, sr_262_tier where applicable, capability_tier, applicable_profiles list, mandatory_controls inventory, and obligations_inventory \u2014 produced before any evaluation artifact is created", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-09-E2", "description": "classification_questionnaire_responses document answering all required dimensions: intended_use_cases, affected_populations, decision_automation_level, human_oversight_mechanisms, deployment_jurisdiction, compute_budget, parameter_count", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E3", "description": "non_high_risk_exclusion_rationale for systems classified below high-risk, explicitly addressing each relevant Annex III category with documented rationale for exclusion", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E4", "description": "classification_review_records for all re-classification events documenting trigger_event, prior_classification, new_classification, and rationale with effective_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E5", "description": "iso_42005_impact_assessment for high-impact-decision and eu-high-risk profile systems per ISO/IEC 42005:2025", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP-1.5 (MAP function) provides that organizational risk tolerances are determined and documented. EV-09\u2019s risk and applicability classification turns documented risk tolerances into a per-system determination of which controls and obligations apply." }, { "control": "apeiris://agentic/controls/AG-03", "id": "AG-03", "domain": "agentic", "name": "Agentic AI Risk Assessment Framework", "validation_objective": "Every production AI agent has a completed, current risk assessment evaluated against all five framework dimensions, with the resulting consequence tier documented and linked to the deployment approval and control mitigation plan.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "Annual risk reassessment records for all Critical-tier agents" ], "evidence": [ { "id": "AG-03-E1", "description": "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E2", "description": "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E3", "description": "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E4", "description": "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E5", "description": "Annual risk reassessment records for all Critical-tier agents", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP 5.1 requires assessing the likelihood and magnitude of identified AI impacts in deployment context. The five-dimension agentic risk scoring model is a structured method for exactly that assessment across autonomy, reversibility, and blast-radius dimensions." }, { "control": "apeiris://ethics/controls/EF-04", "id": "EF-04", "domain": "ethics", "name": "Ethics Impact Assessment Framework", "validation_objective": "Every AI system in the production inventory must have a completed Ethics Impact Assessment using the organization's documented methodology, producing a structured verdict from the approved verdict taxonomy before initial deployment and within the annual review cycle thereafter. Each EIA must include fairness metric results disaggregated by demographic group, data provenance documentation, and an explicit verdict mapped against the organization's Ethical Risk Appetite Statement tiers.", "blocking_effect": "blocks-deployment", "evidence_required": [ "ethics_impact_assessment document with methodology_version, completed_questionnaire, residual_risk_score, risk_appetite_tier mapping, and structured_verdict (approved / approved-with-conditions / deferred-pending-mitigation / blocked)", "fairness_metric_results_report showing model performance disaggregated by demographic group using at least two metrics (equalized odds, demographic parity, calibration, or individual fairness) as required by the EIA questionnaire", "eia_governance_approval_record showing verdict_issuer, ethics_officer_countersignature for high-risk systems, and approval_date confirmed before production deployment", "eia_registry entry for each production AI system with current_assessment_date and next_review_date within 12 months", "fundamental_rights_impact_assessment artifact for EU-deployed high-risk systems satisfying Art. 27 requirements, integrated into or attached to the EIA documentation package" ], "evidence": [ { "id": "EF-04-E1", "description": "ethics_impact_assessment document with methodology_version, completed_questionnaire, residual_risk_score, risk_appetite_tier mapping, and structured_verdict (approved / approved-with-conditions / deferred-pending-mitigation / blocked)", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EF-04-E2", "description": "fairness_metric_results_report showing model performance disaggregated by demographic group using at least two metrics (equalized odds, demographic parity, calibration, or individual fairness) as required by the EIA questionnaire", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-04-E3", "description": "eia_governance_approval_record showing verdict_issuer, ethics_officer_countersignature for high-risk systems, and approval_date confirmed before production deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-04-E4", "description": "eia_registry entry for each production AI system with current_assessment_date and next_review_date within 12 months", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-04-E5", "description": "fundamental_rights_impact_assessment artifact for EU-deployed high-risk systems satisfying Art. 27 requirements, integrated into or attached to the EIA documentation package", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP 5.1 requires that the likelihood and magnitude of AI risks are estimated and MEASURE 2.11 requires that fairness and bias are evaluated and results demonstrated. The EIA questionnaire and scoring rubric directly implement these MAP and MEASURE requirements." } ] }, { "requirement_id": "MAP-3.1", "section": "MAP 3.1", "title": "Potential AI benefits identified and documented", "text": "Potential benefits of the AI system are identified and documented, and trade-offs with risks are considered.", "verdict": "partial", "coverage": "partial", "notes": "LI-07 and LI-04 address capability declarations and model documentation. Formal benefit quantification and explicit trade-off analysis documentation are gaps \u2014 controls focus primarily on risk and limitation disclosure rather than benefit cataloguing.", "control_count": 2, "proof_chain": [ { "control": "apeiris://model/controls/LI-07", "id": "LI-07", "domain": "model", "name": "Capability and Limitation Declaration \u2014 Intended Use, Constraints,...", "validation_objective": "Every registered model must have a structured, schema-validated capability-limitation declaration with all five required dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, and knowledge_cutoff) substantively populated with population- and context-qualified entries, returned as structured metadata in the model registry API response; registration must be blocked when any dimension is absent or empty; and the model's observable behavior for post-knowledge-cutoff queries must be consistent with the declared uncertainty_bounds.", "blocking_effect": "blocks-deployment", "evidence_required": [ "capability_limitation_declaration with all five dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, knowledge_cutoff) substantively populated with population-qualified and context-qualified entries, version-locked to the artifact hash", "registry_api_response_sample demonstrating that the capability_limitation_declaration object is returned as structured metadata in the model registry API response for the model's registered ID without requiring separate documentation lookup", "cutoff_behavior_test_result showing model responses to at least three post-knowledge-cutoff factual queries compared against the declared uncertainty_bounds, confirming the model acknowledges the limitation rather than confabulating confident answers", "registration_rejection_log showing that a model registration attempt with an empty out_of_scope_uses field was blocked with an error identifying the specific missing dimension" ], "evidence": [ { "id": "LI-07-E1", "description": "capability_limitation_declaration with all five dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, knowledge_cutoff) substantively populated with population-qualified and context-qualified entries, version-locked to the artifact hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E2", "description": "registry_api_response_sample demonstrating that the capability_limitation_declaration object is returned as structured metadata in the model registry API response for the model's registered ID without requiring separate documentation lookup", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E3", "description": "cutoff_behavior_test_result showing model responses to at least three post-knowledge-cutoff factual queries compared against the declared uncertainty_bounds, confirming the model acknowledges the limitation rather than confabulating confident answers", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E4", "description": "registration_rejection_log showing that a model registration attempt with an empty out_of_scope_uses field was blocked with an error identifying the specific missing dimension", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP-2.2 (MAP function) provides that information about the AI system\u2019s knowledge limits and how output may be utilized and overseen by humans is documented. LI-07\u2019s capability and limitation declaration \u2014 intended uses, knowledge cutoff, and unsupported domains \u2014 is precisely the knowledge-limits documentation this subcategory requires." }, { "control": "apeiris://model/controls/LI-04", "id": "LI-04", "domain": "model", "name": "Structured Model Documentation \u2014 Complete Model Card with All Required Sections", "validation_objective": "Every model submitted for registration must have a schema-validated model card with all nine Mitchell et al. 2019 sections substantively populated and passing field-level validation rules; the model card must be version-locked to the artifact hash and returned as structured metadata from the registry API; and registration must be blocked when any required section is absent, empty, or contains only placeholder text.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_card_completeness_validation_report showing pass/fail status per section with field-level validation results, registration blocking decision, and validation timestamp for the current artifact version", "versioned_model_card artifact linked to the specific model artifact hash with all nine Mitchell et al. sections containing substantive content (not placeholder text), retrievable from the registry by artifact hash", "model_registry_entry showing the current model card version hash stored alongside the artifact hash as paired immutable fields", "eu_ai_act_annex_iv_supplemental_record for EU AI Act high-risk in-scope systems confirming Annex IV technical documentation fields are populated in addition to the nine Mitchell et al. sections" ], "evidence": [ { "id": "LI-04-E1", "description": "model_card_completeness_validation_report showing pass/fail status per section with field-level validation results, registration blocking decision, and validation timestamp for the current artifact version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-04-E2", "description": "versioned_model_card artifact linked to the specific model artifact hash with all nine Mitchell et al. sections containing substantive content (not placeholder text), retrievable from the registry by artifact hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-04-E3", "description": "model_registry_entry showing the current model card version hash stored alongside the artifact hash as paired immutable fields", "evidence_type": "model-card", "verification": "attested" }, { "id": "LI-04-E4", "description": "eu_ai_act_annex_iv_supplemental_record for EU AI Act high-risk in-scope systems confirming Annex IV technical documentation fields are populated in addition to the nine Mitchell et al. sections", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN-4.2 (GOVERN function) provides that organizational teams document the risks and potential impacts of the AI technology they develop and deploy. A mandatory, schema-validated model card is the primary artifact in which a team documents its model\u2019s risks, limitations, and impacts, directly supporting this documentation practice." } ] }, { "requirement_id": "MAP-3.2", "section": "MAP 3.2", "title": "Metrics for quantifying AI system benefits identified", "text": "Scientific basis or performance metrics used to quantify AI system benefits are identified and documented.", "verdict": "partial", "coverage": "partial", "notes": "EV-02 addresses performance assessment; AG-06 covers agent program metrics. Benefit-specific metric selection \u2014 as distinct from performance or safety metrics \u2014 is not explicitly addressed.", "control_count": 2, "proof_chain": [ { "control": "apeiris://model/controls/EV-02", "id": "EV-02", "domain": "model", "name": "Fitness, Safety, Reliability and Policy-Conformance Evaluation", "validation_objective": "Before deployment, every model has been evaluated against pre-specified, dimension-level pass/fail thresholds \u2014 fitness, safety, reliability, and policy-conformance \u2014 with results documented against the model artifact hash and evaluation suite version. No threshold is modified after evaluation begins, and any threshold trade-off decision is documented as a named risk-acceptance record before the deployment manifest is signed.", "blocking_effect": "blocks-deployment", "evidence_required": [ "pre_specified_evaluation_protocol with model_artifact_hash, evaluation_suite_version, and per-dimension thresholds (fitness accuracy target, safety refusal rate, reliability error budget, policy-conformance violation rate), signed by the evaluation lead before testing begins \u2014 not after results are known", "dimension_level_evaluation_results showing per-dimension metric values, pass/fail verdict against pre-specified threshold, and model_artifact_hash confirming results correspond to the evaluated version", "evaluation_suite_provenance_record confirming that evaluation datasets are disjoint from training data, with contamination-check reference to TG-05 attestation", "risk_acceptance_record for any dimension where the pass threshold was not met but deployment was authorized, documenting named risk-accepter, specific capability gap, deployment risk consequence, and remediation deadline" ], "evidence": [ { "id": "EV-02-E1", "description": "pre_specified_evaluation_protocol with model_artifact_hash, evaluation_suite_version, and per-dimension thresholds (fitness accuracy target, safety refusal rate, reliability error budget, policy-conformance violation rate), signed by the evaluation lead before testing begins \u2014 not after results are known", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-02-E2", "description": "dimension_level_evaluation_results showing per-dimension metric values, pass/fail verdict against pre-specified threshold, and model_artifact_hash confirming results correspond to the evaluated version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-02-E3", "description": "evaluation_suite_provenance_record confirming that evaluation datasets are disjoint from training data, with contamination-check reference to TG-05 attestation", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-02-E4", "description": "risk_acceptance_record for any dimension where the pass threshold was not met but deployment was authorized, documenting named risk-accepter, specific capability gap, deployment risk consequence, and remediation deadline", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.3 (MEASURE function) provides that AI system performance or assurance criteria are measured and demonstrated for conditions similar to deployment. EV-02\u2019s fitness, safety, reliability, and policy-conformance dimensions measure and demonstrate the system\u2019s assurance criteria before deployment." }, { "control": "apeiris://agentic/controls/AG-06", "id": "AG-06", "domain": "agentic", "name": "Agent Program Metrics and KPIs", "validation_objective": "The enterprise collects and reports a defined set of agentic AI governance KPIs from automated pipelines on a defined frequency, and the governance committee receives current-period metric values with trend data and threshold breach alerts at each governance review meeting.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Published Agentic AI Program Metrics Catalog defining each KPI: name, formula, data source, reporting frequency, metric owner, and target threshold with current baseline", "Automated governance dashboard outputs from at least the three most recent reporting periods showing coverage, process, outcome, and attestation metrics", "Governance committee meeting records confirming receipt and review of metrics reports and documenting threshold breach discussions and directed actions", "Data pipeline lineage documentation showing the authoritative source for each KPI and the automated collection process" ], "evidence": [ { "id": "AG-06-E1", "description": "Published Agentic AI Program Metrics Catalog defining each KPI: name, formula, data source, reporting frequency, metric owner, and target threshold with current baseline", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-06-E2", "description": "Automated governance dashboard outputs from at least the three most recent reporting periods showing coverage, process, outcome, and attestation metrics", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "AG-06-E3", "description": "Governance committee meeting records confirming receipt and review of metrics reports and documenting threshold breach discussions and directed actions", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AG-06-E4", "description": "Data pipeline lineage documentation showing the authoritative source for each KPI and the automated collection process", "evidence_type": "data-lineage-record", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE 1.1 requires approaches and metrics for AI risk measurement to be selected and implemented. A defined agentic program metrics catalog with coverage, incident, and drift KPIs is that selection, made explicit and reviewable." } ] }, { "requirement_id": "MAP-3.3", "section": "MAP 3.3", "title": "All identifiable risks of AI system documented", "text": "All identifiable risks and adverse consequences associated with the AI system are identified and documented.", "verdict": "supported", "coverage": "direct", "notes": "EV-09 classifies risk and applicability; EF-04 frames ethics impact assessment; AG-03 provides the structured agentic risk assessment. Together these cover technical, ethical, and behavioral risk identification.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/EV-09", "id": "EV-09", "domain": "model", "name": "Risk and Applicability Classification", "validation_objective": "Every model system has a signed classification record produced before any evaluation work begins, containing a documented EU AI Act classification with provision-specific rationale referencing Articles 5, 6, 50, 51, and Annex III as applicable, an SR 26-2 model risk tier for in-scope institutions, a capability tier, and the full applicable Apeiris profiles list; the model registry gate prevents advancement to evaluation stage without this record; and re-classification is triggered on any significant change to use case, capability level, or applicable regulation.", "blocking_effect": "blocks-deployment", "evidence_required": [ "signed_classification_record containing eu_ai_act_classification with specific provision references, sr_262_tier where applicable, capability_tier, applicable_profiles list, mandatory_controls inventory, and obligations_inventory \u2014 produced before any evaluation artifact is created", "classification_questionnaire_responses document answering all required dimensions: intended_use_cases, affected_populations, decision_automation_level, human_oversight_mechanisms, deployment_jurisdiction, compute_budget, parameter_count", "non_high_risk_exclusion_rationale for systems classified below high-risk, explicitly addressing each relevant Annex III category with documented rationale for exclusion", "classification_review_records for all re-classification events documenting trigger_event, prior_classification, new_classification, and rationale with effective_date", "iso_42005_impact_assessment for high-impact-decision and eu-high-risk profile systems per ISO/IEC 42005:2025" ], "evidence": [ { "id": "EV-09-E1", "description": "signed_classification_record containing eu_ai_act_classification with specific provision references, sr_262_tier where applicable, capability_tier, applicable_profiles list, mandatory_controls inventory, and obligations_inventory \u2014 produced before any evaluation artifact is created", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-09-E2", "description": "classification_questionnaire_responses document answering all required dimensions: intended_use_cases, affected_populations, decision_automation_level, human_oversight_mechanisms, deployment_jurisdiction, compute_budget, parameter_count", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E3", "description": "non_high_risk_exclusion_rationale for systems classified below high-risk, explicitly addressing each relevant Annex III category with documented rationale for exclusion", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E4", "description": "classification_review_records for all re-classification events documenting trigger_event, prior_classification, new_classification, and rationale with effective_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E5", "description": "iso_42005_impact_assessment for high-impact-decision and eu-high-risk profile systems per ISO/IEC 42005:2025", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP-1.5 (MAP function) provides that organizational risk tolerances are determined and documented. EV-09\u2019s risk and applicability classification turns documented risk tolerances into a per-system determination of which controls and obligations apply." }, { "control": "apeiris://ethics/controls/EF-04", "id": "EF-04", "domain": "ethics", "name": "Ethics Impact Assessment Framework", "validation_objective": "Every AI system in the production inventory must have a completed Ethics Impact Assessment using the organization's documented methodology, producing a structured verdict from the approved verdict taxonomy before initial deployment and within the annual review cycle thereafter. Each EIA must include fairness metric results disaggregated by demographic group, data provenance documentation, and an explicit verdict mapped against the organization's Ethical Risk Appetite Statement tiers.", "blocking_effect": "blocks-deployment", "evidence_required": [ "ethics_impact_assessment document with methodology_version, completed_questionnaire, residual_risk_score, risk_appetite_tier mapping, and structured_verdict (approved / approved-with-conditions / deferred-pending-mitigation / blocked)", "fairness_metric_results_report showing model performance disaggregated by demographic group using at least two metrics (equalized odds, demographic parity, calibration, or individual fairness) as required by the EIA questionnaire", "eia_governance_approval_record showing verdict_issuer, ethics_officer_countersignature for high-risk systems, and approval_date confirmed before production deployment", "eia_registry entry for each production AI system with current_assessment_date and next_review_date within 12 months", "fundamental_rights_impact_assessment artifact for EU-deployed high-risk systems satisfying Art. 27 requirements, integrated into or attached to the EIA documentation package" ], "evidence": [ { "id": "EF-04-E1", "description": "ethics_impact_assessment document with methodology_version, completed_questionnaire, residual_risk_score, risk_appetite_tier mapping, and structured_verdict (approved / approved-with-conditions / deferred-pending-mitigation / blocked)", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EF-04-E2", "description": "fairness_metric_results_report showing model performance disaggregated by demographic group using at least two metrics (equalized odds, demographic parity, calibration, or individual fairness) as required by the EIA questionnaire", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-04-E3", "description": "eia_governance_approval_record showing verdict_issuer, ethics_officer_countersignature for high-risk systems, and approval_date confirmed before production deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-04-E4", "description": "eia_registry entry for each production AI system with current_assessment_date and next_review_date within 12 months", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-04-E5", "description": "fundamental_rights_impact_assessment artifact for EU-deployed high-risk systems satisfying Art. 27 requirements, integrated into or attached to the EIA documentation package", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP 5.1 requires that the likelihood and magnitude of AI risks are estimated and MEASURE 2.11 requires that fairness and bias are evaluated and results demonstrated. The EIA questionnaire and scoring rubric directly implement these MAP and MEASURE requirements." }, { "control": "apeiris://agentic/controls/AG-03", "id": "AG-03", "domain": "agentic", "name": "Agentic AI Risk Assessment Framework", "validation_objective": "Every production AI agent has a completed, current risk assessment evaluated against all five framework dimensions, with the resulting consequence tier documented and linked to the deployment approval and control mitigation plan.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "Annual risk reassessment records for all Critical-tier agents" ], "evidence": [ { "id": "AG-03-E1", "description": "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E2", "description": "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E3", "description": "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E4", "description": "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E5", "description": "Annual risk reassessment records for all Critical-tier agents", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP 5.1 requires assessing the likelihood and magnitude of identified AI impacts in deployment context. The five-dimension agentic risk scoring model is a structured method for exactly that assessment across autonomy, reversibility, and blast-radius dimensions." } ] }, { "requirement_id": "MAP-3.4", "section": "MAP 3.4", "title": "AI risks inventoried at system and organizational levels", "text": "AI risks are inventoried at the AI system and organizational levels and tracked through risk registers.", "verdict": "partial", "coverage": "partial", "notes": "CR-01 aggregates production monitoring and risk data; PG-07 produces governance reporting; AG-03 provides the assessment framework. A unified cross-domain AI risk register artifact is not explicitly specified \u2014 evidence packages exist per domain but organizational-level risk inventory consolidation is partial.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/CR-01", "id": "CR-01", "domain": "model", "name": "Continuous Production Monitoring and Risk Aggregation", "validation_objective": "All runtime monitoring signals \u2014 performance, drift, fairness, safety incidents, and deployment event flags \u2014 must be continuously aggregated into a unified risk dashboard with pre-configured automated alerting thresholds; any degradation in a monitored dimension must be detected and an alert dispatched within one operational window.", "blocking_effect": "advisory", "evidence_required": [ "risk_dashboard_configuration_record showing all registered signal feeds (performance, drift, fairness, safety, incident), their alert thresholds, assigned monitoring window duration, and escalation recipients", "alert_audit_log covering at least 30 days showing triggered alerts with signal_type, threshold_crossed, alert_timestamp, and escalation_recipient for each alert", "monitoring_coverage_audit confirming every deployed model version has an associated monitoring configuration with no version gaps", "risk_aggregation_methodology_document defining how individual dimension alerts are combined into composite risk scores and dashboard status indicators", "post-market_monitoring_report satisfying EU AI Act Art. 72 covering the monitoring period, key findings, and corrective actions taken or planned" ], "evidence": [ { "id": "CR-01-E1", "description": "risk_dashboard_configuration_record showing all registered signal feeds (performance, drift, fairness, safety, incident), their alert thresholds, assigned monitoring window duration, and escalation recipients", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-01-E2", "description": "alert_audit_log covering at least 30 days showing triggered alerts with signal_type, threshold_crossed, alert_timestamp, and escalation_recipient for each alert", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E3", "description": "monitoring_coverage_audit confirming every deployed model version has an associated monitoring configuration with no version gaps", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E4", "description": "risk_aggregation_methodology_document defining how individual dimension alerts are combined into composite risk scores and dashboard status indicators", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E5", "description": "post-market_monitoring_report satisfying EU AI Act Art. 72 covering the monitoring period, key findings, and corrective actions taken or planned", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.4 (MEASURE function) provides that the functionality and behavior of the AI system and its components are monitored when in production. CR-01 aggregates production monitoring signals \u2014 performance, drift, fairness, safety, cost \u2014 into a single risk view with calibrated alert thresholds." }, { "control": "apeiris://authority/controls/PG-07", "id": "PG-07", "domain": "authority", "name": "Policy Governance Reporting", "validation_objective": "Policy governance reports must be generated on the defined schedule for all audience tiers (executive management, audit committee, board), with every defined metric field populated from verified upstream data sources. Distribution logs must confirm delivery within the deadline for each audience.", "blocking_effect": "advisory", "evidence_required": [ "governance_report_package containing report templates per audience tier, populated metric fields, and data-source mappings for each reporting period", "report_distribution_log showing recipient, delivery timestamp, and report version for each scheduled and event-driven governance report", "reporting_pipeline_audit_trail confirming each metric value was sourced from the canonical upstream control system with no manual entry points", "audit_committee_submission_record confirming receipt of quarterly governance reports within the defined deadline", "event_driven_report_log showing supplemental reports triggered by material incidents above the defined severity threshold with generation-to-delivery elapsed time" ], "evidence": [ { "id": "PG-07-E1", "description": "governance_report_package containing report templates per audience tier, populated metric fields, and data-source mappings for each reporting period", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PG-07-E2", "description": "report_distribution_log showing recipient, delivery timestamp, and report version for each scheduled and event-driven governance report", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PG-07-E3", "description": "reporting_pipeline_audit_trail confirming each metric value was sourced from the canonical upstream control system with no manual entry points", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PG-07-E4", "description": "audit_committee_submission_record confirming receipt of quarterly governance reports within the defined deadline", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PG-07-E5", "description": "event_driven_report_log showing supplemental reports triggered by material incidents above the defined severity threshold with generation-to-delivery elapsed time", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://agentic/controls/AG-03", "id": "AG-03", "domain": "agentic", "name": "Agentic AI Risk Assessment Framework", "validation_objective": "Every production AI agent has a completed, current risk assessment evaluated against all five framework dimensions, with the resulting consequence tier documented and linked to the deployment approval and control mitigation plan.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "Annual risk reassessment records for all Critical-tier agents" ], "evidence": [ { "id": "AG-03-E1", "description": "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E2", "description": "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E3", "description": "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E4", "description": "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E5", "description": "Annual risk reassessment records for all Critical-tier agents", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP 5.1 requires assessing the likelihood and magnitude of identified AI impacts in deployment context. The five-dimension agentic risk scoring model is a structured method for exactly that assessment across autonomy, reversibility, and blast-radius dimensions." } ] }, { "requirement_id": "MAP-3.5", "section": "MAP 3.5", "title": "Likelihood of risks and impacts quantified", "text": "Likelihood of identified risks and impacts are quantified using appropriate methods.", "verdict": "partial", "coverage": "partial", "notes": "EF-04 covers ethics impact assessment including harm likelihood; AG-03 addresses risk assessment; FA-03 requires fairness metric justification. Quantitative probability estimation for non-fairness risks is not explicitly mandated across all domains.", "control_count": 3, "proof_chain": [ { "control": "apeiris://ethics/controls/EF-04", "id": "EF-04", "domain": "ethics", "name": "Ethics Impact Assessment Framework", "validation_objective": "Every AI system in the production inventory must have a completed Ethics Impact Assessment using the organization's documented methodology, producing a structured verdict from the approved verdict taxonomy before initial deployment and within the annual review cycle thereafter. Each EIA must include fairness metric results disaggregated by demographic group, data provenance documentation, and an explicit verdict mapped against the organization's Ethical Risk Appetite Statement tiers.", "blocking_effect": "blocks-deployment", "evidence_required": [ "ethics_impact_assessment document with methodology_version, completed_questionnaire, residual_risk_score, risk_appetite_tier mapping, and structured_verdict (approved / approved-with-conditions / deferred-pending-mitigation / blocked)", "fairness_metric_results_report showing model performance disaggregated by demographic group using at least two metrics (equalized odds, demographic parity, calibration, or individual fairness) as required by the EIA questionnaire", "eia_governance_approval_record showing verdict_issuer, ethics_officer_countersignature for high-risk systems, and approval_date confirmed before production deployment", "eia_registry entry for each production AI system with current_assessment_date and next_review_date within 12 months", "fundamental_rights_impact_assessment artifact for EU-deployed high-risk systems satisfying Art. 27 requirements, integrated into or attached to the EIA documentation package" ], "evidence": [ { "id": "EF-04-E1", "description": "ethics_impact_assessment document with methodology_version, completed_questionnaire, residual_risk_score, risk_appetite_tier mapping, and structured_verdict (approved / approved-with-conditions / deferred-pending-mitigation / blocked)", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EF-04-E2", "description": "fairness_metric_results_report showing model performance disaggregated by demographic group using at least two metrics (equalized odds, demographic parity, calibration, or individual fairness) as required by the EIA questionnaire", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-04-E3", "description": "eia_governance_approval_record showing verdict_issuer, ethics_officer_countersignature for high-risk systems, and approval_date confirmed before production deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-04-E4", "description": "eia_registry entry for each production AI system with current_assessment_date and next_review_date within 12 months", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-04-E5", "description": "fundamental_rights_impact_assessment artifact for EU-deployed high-risk systems satisfying Art. 27 requirements, integrated into or attached to the EIA documentation package", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP 5.1 requires that the likelihood and magnitude of AI risks are estimated and MEASURE 2.11 requires that fairness and bias are evaluated and results demonstrated. The EIA questionnaire and scoring rubric directly implement these MAP and MEASURE requirements." }, { "control": "apeiris://agentic/controls/AG-03", "id": "AG-03", "domain": "agentic", "name": "Agentic AI Risk Assessment Framework", "validation_objective": "Every production AI agent has a completed, current risk assessment evaluated against all five framework dimensions, with the resulting consequence tier documented and linked to the deployment approval and control mitigation plan.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "Annual risk reassessment records for all Critical-tier agents" ], "evidence": [ { "id": "AG-03-E1", "description": "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E2", "description": "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E3", "description": "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E4", "description": "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E5", "description": "Annual risk reassessment records for all Critical-tier agents", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP 5.1 requires assessing the likelihood and magnitude of identified AI impacts in deployment context. The five-dimension agentic risk scoring model is a structured method for exactly that assessment across autonomy, reversibility, and blast-radius dimensions." }, { "control": "apeiris://ethics/controls/FA-03", "id": "FA-03", "domain": "ethics", "name": "Fairness Metric Selection and Justification", "validation_objective": "For each AI system subject to fairness evaluation, a documented Fairness Metric Justification Document must specify the selected metrics with rationale, demonstrate awareness of mathematical incompatibilities between candidate metrics in the context of this system's base rates, and document why chosen metrics are appropriate for affected populations and applicable legal standards.", "blocking_effect": "blocks-deployment", "evidence_required": [ "fairness_metric_justification_document identifying each selected metric (e.g., demographic_parity, equalized_odds, predictive_rate_parity) with rationale for selection and explicit acknowledgment of trade-offs against rejected alternative metrics", "metric_incompatibility_analysis demonstrating awareness of which metrics cannot simultaneously be satisfied for this system given base-rate differences across protected groups", "legal_alignment_record mapping selected metrics to requirements in applicable law (e.g., four-fifths rule for EEOC and LL144, equal error rates for credit contexts)", "affected_population_consultation_record documenting input from representatives of affected groups on metric priorities and harm weightings" ], "evidence": [ { "id": "FA-03-E1", "description": "fairness_metric_justification_document identifying each selected metric (e.g., demographic_parity, equalized_odds, predictive_rate_parity) with rationale for selection and explicit acknowledgment of trade-offs against rejected alternative metrics", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-03-E2", "description": "metric_incompatibility_analysis demonstrating awareness of which metrics cannot simultaneously be satisfied for this system given base-rate differences across protected groups", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-03-E3", "description": "legal_alignment_record mapping selected metrics to requirements in applicable law (e.g., four-fifths rule for EEOC and LL144, equal error rates for credit contexts)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-03-E4", "description": "affected_population_consultation_record documenting input from representatives of affected groups on metric priorities and harm weightings", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE 2.11 requires that fairness and bias are evaluated, with results demonstrated and measurement approaches documented and justified with reference to context, stakeholders, and applicable standards. The Fairness Metric Justification Document is the primary artifact satisfying this measurement documentation requirement." } ] }, { "requirement_id": "MAP-4.1", "section": "MAP 4.1", "title": "Risks evaluated with domain experts for impact and likelihood", "text": "Risks associated with the AI system are evaluated by domain experts for their potential impact and likelihood.", "verdict": "supported", "coverage": "direct", "notes": "EF-04 requires ethics impact assessment by qualified reviewers; EV-09 classifies risk and applicability; AB-03 classifies and gates action reversibility \u2014 a proxy for impact severity in agentic systems.", "control_count": 3, "proof_chain": [ { "control": "apeiris://ethics/controls/EF-04", "id": "EF-04", "domain": "ethics", "name": "Ethics Impact Assessment Framework", "validation_objective": "Every AI system in the production inventory must have a completed Ethics Impact Assessment using the organization's documented methodology, producing a structured verdict from the approved verdict taxonomy before initial deployment and within the annual review cycle thereafter. Each EIA must include fairness metric results disaggregated by demographic group, data provenance documentation, and an explicit verdict mapped against the organization's Ethical Risk Appetite Statement tiers.", "blocking_effect": "blocks-deployment", "evidence_required": [ "ethics_impact_assessment document with methodology_version, completed_questionnaire, residual_risk_score, risk_appetite_tier mapping, and structured_verdict (approved / approved-with-conditions / deferred-pending-mitigation / blocked)", "fairness_metric_results_report showing model performance disaggregated by demographic group using at least two metrics (equalized odds, demographic parity, calibration, or individual fairness) as required by the EIA questionnaire", "eia_governance_approval_record showing verdict_issuer, ethics_officer_countersignature for high-risk systems, and approval_date confirmed before production deployment", "eia_registry entry for each production AI system with current_assessment_date and next_review_date within 12 months", "fundamental_rights_impact_assessment artifact for EU-deployed high-risk systems satisfying Art. 27 requirements, integrated into or attached to the EIA documentation package" ], "evidence": [ { "id": "EF-04-E1", "description": "ethics_impact_assessment document with methodology_version, completed_questionnaire, residual_risk_score, risk_appetite_tier mapping, and structured_verdict (approved / approved-with-conditions / deferred-pending-mitigation / blocked)", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EF-04-E2", "description": "fairness_metric_results_report showing model performance disaggregated by demographic group using at least two metrics (equalized odds, demographic parity, calibration, or individual fairness) as required by the EIA questionnaire", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-04-E3", "description": "eia_governance_approval_record showing verdict_issuer, ethics_officer_countersignature for high-risk systems, and approval_date confirmed before production deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-04-E4", "description": "eia_registry entry for each production AI system with current_assessment_date and next_review_date within 12 months", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-04-E5", "description": "fundamental_rights_impact_assessment artifact for EU-deployed high-risk systems satisfying Art. 27 requirements, integrated into or attached to the EIA documentation package", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP 5.1 requires that the likelihood and magnitude of AI risks are estimated and MEASURE 2.11 requires that fairness and bias are evaluated and results demonstrated. The EIA questionnaire and scoring rubric directly implement these MAP and MEASURE requirements." }, { "control": "apeiris://model/controls/EV-09", "id": "EV-09", "domain": "model", "name": "Risk and Applicability Classification", "validation_objective": "Every model system has a signed classification record produced before any evaluation work begins, containing a documented EU AI Act classification with provision-specific rationale referencing Articles 5, 6, 50, 51, and Annex III as applicable, an SR 26-2 model risk tier for in-scope institutions, a capability tier, and the full applicable Apeiris profiles list; the model registry gate prevents advancement to evaluation stage without this record; and re-classification is triggered on any significant change to use case, capability level, or applicable regulation.", "blocking_effect": "blocks-deployment", "evidence_required": [ "signed_classification_record containing eu_ai_act_classification with specific provision references, sr_262_tier where applicable, capability_tier, applicable_profiles list, mandatory_controls inventory, and obligations_inventory \u2014 produced before any evaluation artifact is created", "classification_questionnaire_responses document answering all required dimensions: intended_use_cases, affected_populations, decision_automation_level, human_oversight_mechanisms, deployment_jurisdiction, compute_budget, parameter_count", "non_high_risk_exclusion_rationale for systems classified below high-risk, explicitly addressing each relevant Annex III category with documented rationale for exclusion", "classification_review_records for all re-classification events documenting trigger_event, prior_classification, new_classification, and rationale with effective_date", "iso_42005_impact_assessment for high-impact-decision and eu-high-risk profile systems per ISO/IEC 42005:2025" ], "evidence": [ { "id": "EV-09-E1", "description": "signed_classification_record containing eu_ai_act_classification with specific provision references, sr_262_tier where applicable, capability_tier, applicable_profiles list, mandatory_controls inventory, and obligations_inventory \u2014 produced before any evaluation artifact is created", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-09-E2", "description": "classification_questionnaire_responses document answering all required dimensions: intended_use_cases, affected_populations, decision_automation_level, human_oversight_mechanisms, deployment_jurisdiction, compute_budget, parameter_count", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E3", "description": "non_high_risk_exclusion_rationale for systems classified below high-risk, explicitly addressing each relevant Annex III category with documented rationale for exclusion", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E4", "description": "classification_review_records for all re-classification events documenting trigger_event, prior_classification, new_classification, and rationale with effective_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E5", "description": "iso_42005_impact_assessment for high-impact-decision and eu-high-risk profile systems per ISO/IEC 42005:2025", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP-1.5 (MAP function) provides that organizational risk tolerances are determined and documented. EV-09\u2019s risk and applicability classification turns documented risk tolerances into a per-system determination of which controls and obligations apply." }, { "control": "apeiris://agentic/controls/AB-03", "id": "AB-03", "domain": "agentic", "name": "Action Reversibility Classification and Gates", "validation_objective": "Prove that every action type in an agent's authorized scope has been formally classified as reversible or irreversible, and that all irreversible actions are blocked from execution until an explicit authorization gate is satisfied \u2014 pre-authorized scope approval, elevated human approval, or a confirmed dry-run result reviewed before live execution.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Action reversibility classification register covering every action type in the agent's authorized scope with classification rationale and responsible owner", "Platform enforcement records confirming irreversible actions were gated prior to execution during the test period, with gate condition and outcome logged", "Dry-run execution logs for irreversible actions showing dry-run output was produced and reviewed before live execution proceeded", "Governance sign-off records authorizing each irreversible action type for the agent's deployment context, with approver identity and validity period" ], "evidence": [ { "id": "AB-03-E1", "description": "Action reversibility classification register covering every action type in the agent's authorized scope with classification rationale and responsible owner", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AB-03-E2", "description": "Platform enforcement records confirming irreversible actions were gated prior to execution during the test period, with gate condition and outcome logged", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "AB-03-E3", "description": "Dry-run execution logs for irreversible actions showing dry-run output was produced and reviewed before live execution proceeded", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AB-03-E4", "description": "Governance sign-off records authorizing each irreversible action type for the agent's deployment context, with approver identity and validity period", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MANAGE 4.1 requires post-deployment monitoring plans that include mechanisms for override and human intervention. Reversibility classification with human authorization gates on irreversible actions is a concrete intervention mechanism that bounds the permanent impact of agent failures." } ] }, { "requirement_id": "MAP-4.2", "section": "MAP 4.2", "title": "Risks analyzed using appropriate methods", "text": "Risks associated with AI are analyzed using appropriate methods, including structured expert elicitation and adversarial testing.", "verdict": "supported", "coverage": "direct", "notes": "EV-04 mandates adversarial red-team testing; FA-04 requires independent bias testing methodology; EV-09 enforces structured risk classification \u2014 covering both quantitative and adversarial analysis methods.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/EV-04", "id": "EV-04", "domain": "model", "name": "Adversarial Red-Team Testing", "validation_objective": "The model system has a signed red-team report produced by a team organizationally independent of model development, documenting structured adversarial probing that covers all required attack categories for the applicable profiles, with all critical and high findings remediated and re-tested before the deployment gate clears.", "blocking_effect": "blocks-deployment", "evidence_required": [ "signed_red_team_scope_document with threat_model version, profile scope, and pre-exercise approval timestamp", "red_team_findings_log with finding_id, severity_classification, reproduction_steps, affected_population, and remediation_status per finding", "signed_red_team_report with residual_risk_statement linked to model artifact hash and listing remediated critical and high findings with re-test results", "remediation_evidence for all critical and high findings demonstrating the vulnerability is closed via re-test, not only via input-level patch", "for frontier-capability profile: escalation_records for any capability elicited at or near threshold levels with escalation_destination and response_action" ], "evidence": [ { "id": "EV-04-E1", "description": "signed_red_team_scope_document with threat_model version, profile scope, and pre-exercise approval timestamp", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EV-04-E2", "description": "red_team_findings_log with finding_id, severity_classification, reproduction_steps, affected_population, and remediation_status per finding", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-04-E3", "description": "signed_red_team_report with residual_risk_statement linked to model artifact hash and listing remediated critical and high findings with re-test results", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "EV-04-E4", "description": "remediation_evidence for all critical and high findings demonstrating the vulnerability is closed via re-test, not only via input-level patch", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "EV-04-E5", "description": "for frontier-capability profile: escalation_records for any capability elicited at or near threshold levels with escalation_destination and response_action", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.7 (MEASURE function) provides that AI system security and resilience are evaluated and documented. EV-04\u2019s adversarial red-team exercises are the security evaluation this subcategory requires, documented as pre-deployment evidence." }, { "control": "apeiris://ethics/controls/FA-04", "id": "FA-04", "domain": "ethics", "name": "Independent Bias Testing Methodology", "validation_objective": "Bias testing for AI systems subject to fairness requirements must be executed under a documented, pre-registered protocol by a tester with no organizational conflict of interest with the model development team, with all findings retained in an immutable log and reported without post-hoc filtering.", "blocking_effect": "blocks-deployment", "evidence_required": [ "independent_bias_test_protocol_document published prior to test execution specifying methodology, test datasets, metrics, and pass/fail thresholds", "tester_independence_certification confirming the testing entity or individual has no direct reporting relationship to or financial interest in the model development team, signed by a party outside the model development chain", "bias_test_execution_log with timestamped test runs, inputs, and outputs in an immutable or append-only store preventing retroactive modification", "bias_test_findings_report including all findings (not only passing results) with statistical support, identified disparity locations, and remediation recommendations" ], "evidence": [ { "id": "FA-04-E1", "description": "independent_bias_test_protocol_document published prior to test execution specifying methodology, test datasets, metrics, and pass/fail thresholds", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "FA-04-E2", "description": "tester_independence_certification confirming the testing entity or individual has no direct reporting relationship to or financial interest in the model development team, signed by a party outside the model development chain", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-04-E3", "description": "bias_test_execution_log with timestamped test runs, inputs, and outputs in an immutable or append-only store preventing retroactive modification", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "FA-04-E4", "description": "bias_test_findings_report including all findings (not only passing results) with statistical support, identified disparity locations, and remediation recommendations", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE 2.11 recommends that fairness and bias evaluations use diverse evaluation methods including external red-teaming and independent assessment. This control establishes the independence and documentation requirements that make such external assessment credible." }, { "control": "apeiris://model/controls/EV-09", "id": "EV-09", "domain": "model", "name": "Risk and Applicability Classification", "validation_objective": "Every model system has a signed classification record produced before any evaluation work begins, containing a documented EU AI Act classification with provision-specific rationale referencing Articles 5, 6, 50, 51, and Annex III as applicable, an SR 26-2 model risk tier for in-scope institutions, a capability tier, and the full applicable Apeiris profiles list; the model registry gate prevents advancement to evaluation stage without this record; and re-classification is triggered on any significant change to use case, capability level, or applicable regulation.", "blocking_effect": "blocks-deployment", "evidence_required": [ "signed_classification_record containing eu_ai_act_classification with specific provision references, sr_262_tier where applicable, capability_tier, applicable_profiles list, mandatory_controls inventory, and obligations_inventory \u2014 produced before any evaluation artifact is created", "classification_questionnaire_responses document answering all required dimensions: intended_use_cases, affected_populations, decision_automation_level, human_oversight_mechanisms, deployment_jurisdiction, compute_budget, parameter_count", "non_high_risk_exclusion_rationale for systems classified below high-risk, explicitly addressing each relevant Annex III category with documented rationale for exclusion", "classification_review_records for all re-classification events documenting trigger_event, prior_classification, new_classification, and rationale with effective_date", "iso_42005_impact_assessment for high-impact-decision and eu-high-risk profile systems per ISO/IEC 42005:2025" ], "evidence": [ { "id": "EV-09-E1", "description": "signed_classification_record containing eu_ai_act_classification with specific provision references, sr_262_tier where applicable, capability_tier, applicable_profiles list, mandatory_controls inventory, and obligations_inventory \u2014 produced before any evaluation artifact is created", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-09-E2", "description": "classification_questionnaire_responses document answering all required dimensions: intended_use_cases, affected_populations, decision_automation_level, human_oversight_mechanisms, deployment_jurisdiction, compute_budget, parameter_count", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E3", "description": "non_high_risk_exclusion_rationale for systems classified below high-risk, explicitly addressing each relevant Annex III category with documented rationale for exclusion", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E4", "description": "classification_review_records for all re-classification events documenting trigger_event, prior_classification, new_classification, and rationale with effective_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E5", "description": "iso_42005_impact_assessment for high-impact-decision and eu-high-risk profile systems per ISO/IEC 42005:2025", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP-1.5 (MAP function) provides that organizational risk tolerances are determined and documented. EV-09\u2019s risk and applicability classification turns documented risk tolerances into a per-system determination of which controls and obligations apply." } ] }, { "requirement_id": "MAP-5.1", "section": "MAP 5.1", "title": "Policies for likelihood and impact assessment methodologies", "text": "AI system development organizations have policies and processes in place to apply likelihood and impact assessment methodologies.", "verdict": "partial", "coverage": "partial", "notes": "AG-03 provides the agentic risk assessment framework; EF-04 formalizes ethics impact assessment; PO-01 hosts the policy register. Explicit policy text mandating likelihood/impact methodology selection across all AI system types is partially addressed.", "control_count": 3, "proof_chain": [ { "control": "apeiris://agentic/controls/AG-03", "id": "AG-03", "domain": "agentic", "name": "Agentic AI Risk Assessment Framework", "validation_objective": "Every production AI agent has a completed, current risk assessment evaluated against all five framework dimensions, with the resulting consequence tier documented and linked to the deployment approval and control mitigation plan.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "Annual risk reassessment records for all Critical-tier agents" ], "evidence": [ { "id": "AG-03-E1", "description": "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E2", "description": "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E3", "description": "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E4", "description": "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E5", "description": "Annual risk reassessment records for all Critical-tier agents", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP 5.1 requires assessing the likelihood and magnitude of identified AI impacts in deployment context. The five-dimension agentic risk scoring model is a structured method for exactly that assessment across autonomy, reversibility, and blast-radius dimensions." }, { "control": "apeiris://ethics/controls/EF-04", "id": "EF-04", "domain": "ethics", "name": "Ethics Impact Assessment Framework", "validation_objective": "Every AI system in the production inventory must have a completed Ethics Impact Assessment using the organization's documented methodology, producing a structured verdict from the approved verdict taxonomy before initial deployment and within the annual review cycle thereafter. Each EIA must include fairness metric results disaggregated by demographic group, data provenance documentation, and an explicit verdict mapped against the organization's Ethical Risk Appetite Statement tiers.", "blocking_effect": "blocks-deployment", "evidence_required": [ "ethics_impact_assessment document with methodology_version, completed_questionnaire, residual_risk_score, risk_appetite_tier mapping, and structured_verdict (approved / approved-with-conditions / deferred-pending-mitigation / blocked)", "fairness_metric_results_report showing model performance disaggregated by demographic group using at least two metrics (equalized odds, demographic parity, calibration, or individual fairness) as required by the EIA questionnaire", "eia_governance_approval_record showing verdict_issuer, ethics_officer_countersignature for high-risk systems, and approval_date confirmed before production deployment", "eia_registry entry for each production AI system with current_assessment_date and next_review_date within 12 months", "fundamental_rights_impact_assessment artifact for EU-deployed high-risk systems satisfying Art. 27 requirements, integrated into or attached to the EIA documentation package" ], "evidence": [ { "id": "EF-04-E1", "description": "ethics_impact_assessment document with methodology_version, completed_questionnaire, residual_risk_score, risk_appetite_tier mapping, and structured_verdict (approved / approved-with-conditions / deferred-pending-mitigation / blocked)", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EF-04-E2", "description": "fairness_metric_results_report showing model performance disaggregated by demographic group using at least two metrics (equalized odds, demographic parity, calibration, or individual fairness) as required by the EIA questionnaire", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-04-E3", "description": "eia_governance_approval_record showing verdict_issuer, ethics_officer_countersignature for high-risk systems, and approval_date confirmed before production deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-04-E4", "description": "eia_registry entry for each production AI system with current_assessment_date and next_review_date within 12 months", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-04-E5", "description": "fundamental_rights_impact_assessment artifact for EU-deployed high-risk systems satisfying Art. 27 requirements, integrated into or attached to the EIA documentation package", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP 5.1 requires that the likelihood and magnitude of AI risks are estimated and MEASURE 2.11 requires that fairness and bias are evaluated and results demonstrated. The EIA questionnaire and scoring rubric directly implement these MAP and MEASURE requirements." }, { "control": "apeiris://authority/controls/PO-01", "id": "PO-01", "domain": "authority", "name": "Internal Policy Register for AI Deployments", "validation_objective": "Every active AI deployment must have at least one current, non-expired policy register entry in the authoritative policy register, and that entry must contain version, effective date, scope, owning team, and deployment linkage fields. No AI deployment may enter or remain in production without a valid policy register reference confirmed by the deployment pipeline.", "blocking_effect": "blocks-deployment", "evidence_required": [ "policy_register_schema_document specifying required fields including policy_id, version, effective_date, expiry_date, owning_team, ai_deployment_scope, and authority_domain_applicability", "deployment_policy_linkage_audit_log confirming every active AI deployment has a corresponding current policy register entry with a non-expired effective date", "policy_register_access_control_matrix demonstrating that register modifications require dual authorization and all changes are attributed and logged", "deployment_pipeline_gate_configuration showing that AI deployment approval workflows validate the presence of a current policy register entry before proceeding" ], "evidence": [ { "id": "PO-01-E1", "description": "policy_register_schema_document specifying required fields including policy_id, version, effective_date, expiry_date, owning_team, ai_deployment_scope, and authority_domain_applicability", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-01-E2", "description": "deployment_policy_linkage_audit_log confirming every active AI deployment has a corresponding current policy register entry with a non-expired effective date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-01-E3", "description": "policy_register_access_control_matrix demonstrating that register modifications require dual authorization and all changes are attributed and logged", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-01-E4", "description": "deployment_pipeline_gate_configuration showing that AI deployment approval workflows validate the presence of a current policy register entry before proceeding", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "A register of AI governance policies operationalizes GOVERN 1.2 policy integration, partially." } ] }, { "requirement_id": "MAP-5.2", "section": "MAP 5.2", "title": "Risk responses selected and documented", "text": "Risk responses are selected and documented for identified AI risks, with consideration of available options.", "verdict": "supported", "coverage": "direct", "notes": "PG-04 covers policy incident classification and response; AG-05 provides the agent incident response program; EG-06 addresses ethics incident response \u2014 together covering the response selection and documentation lifecycle.", "control_count": 3, "proof_chain": [ { "control": "apeiris://authority/controls/PG-04", "id": "PG-04", "domain": "authority", "name": "Policy Incident Classification and Response", "validation_objective": "Every policy violation detected by AI monitoring controls must be classified to the defined severity taxonomy within the two-hour SLA, routed to the corresponding response playbook with role-assigned owners, and resolved within the tier-specific SLA, with root cause and corrective action records retained for every closed incident.", "blocking_effect": "requires-review", "evidence_required": [ "Incident management system records for the reporting period showing classification outcome, assigned severity tier, playbook routing, escalation events, resolution timestamps, and SLA compliance for all detected violations", "Severity taxonomy definition document and response playbook inventory with documented role owners, resolution SLAs by tier, and signed approval from Chief Risk Officer and General Counsel", "Tabletop exercise records from the most recent annual exercise demonstrating that the Severity 1 escalation chain functions correctly, with participant records and identified gaps with remediation actions", "Root cause and corrective action records for all incidents closed in the reporting period, with repeat incident flags where the same root cause recurs within 90 days" ], "evidence": [ { "id": "PG-04-E1", "description": "Incident management system records for the reporting period showing classification outcome, assigned severity tier, playbook routing, escalation events, resolution timestamps, and SLA compliance for all detected violations", "evidence_type": "incident-record", "verification": "attested" }, { "id": "PG-04-E2", "description": "Severity taxonomy definition document and response playbook inventory with documented role owners, resolution SLAs by tier, and signed approval from Chief Risk Officer and General Counsel", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PG-04-E3", "description": "Tabletop exercise records from the most recent annual exercise demonstrating that the Severity 1 escalation chain functions correctly, with participant records and identified gaps with remediation actions", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PG-04-E4", "description": "Root cause and corrective action records for all incidents closed in the reporting period, with repeat incident flags where the same root cause recurs within 90 days", "evidence_type": "incident-record", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "Classifying and routing incidents to response playbooks partially implements MANAGE 4.1 incident-response mechanisms." }, { "control": "apeiris://agentic/controls/AG-05", "id": "AG-05", "domain": "agentic", "name": "Agent Incident Response Program", "validation_objective": "The enterprise has a documented, tested AI Incident Response Playbook with AI-specific containment capabilities, and every production agent has an authenticated kill-switch that demonstrably suspends its operation within 60 seconds of an authorized responder request.", "blocking_effect": "requires-review", "evidence_required": [ "AI Incident Response Playbook document covering incident classification taxonomy, severity tiers with quantitative criteria, containment actions per incident type, escalation matrix, and regulatory notification timelines", "Kill-switch capability validation records for each production agent, confirming suspension within the 60-second SLA in the most recent test", "Tabletop or functional test records for the AI Incident Response Playbook covering at least P1 and P2 severity scenarios", "Post-incident review records for all P1 and P2 events including root cause, containment timeline, and lessons-learned pipeline submissions" ], "evidence": [ { "id": "AG-05-E1", "description": "AI Incident Response Playbook document covering incident classification taxonomy, severity tiers with quantitative criteria, containment actions per incident type, escalation matrix, and regulatory notification timelines", "evidence_type": "incident-record", "verification": "attested" }, { "id": "AG-05-E2", "description": "Kill-switch capability validation records for each production agent, confirming suspension within the 60-second SLA in the most recent test", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "AG-05-E3", "description": "Tabletop or functional test records for the AI Incident Response Playbook covering at least P1 and P2 severity scenarios", "evidence_type": "incident-record", "verification": "attested" }, { "id": "AG-05-E4", "description": "Post-incident review records for all P1 and P2 events including root cause, containment timeline, and lessons-learned pipeline submissions", "evidence_type": "incident-record", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MANAGE 4.3 requires processes for tracking, responding to, and recovering from AI incidents and errors, with communication to relevant AI actors. An agent-specific incident response program with playbooks and regulatory notification procedures is the direct implementation." }, { "control": "apeiris://ethics/controls/EG-06", "id": "EG-06", "domain": "ethics", "name": "Ethics Incident Response", "validation_objective": "The organization must have a documented AI ethics incident response procedure covering severity classification (minimum three levels), escalation timelines with named roles, investigation protocol, affected party notification procedures, and post-incident review requirements. All Level 2+ incidents must have complete escalation and investigation records within defined SLA, and post-incident reviews must be traceable to policy or system changes.", "blocking_effect": "requires-review", "evidence_required": [ "ai_ethics_incident_response_procedure document with version date, severity classification framework (minimum three levels), named escalation roles with SLA timelines, investigation protocol, affected party notification criteria, and post-incident review requirements", "ethics_incident_log for trailing 12 months showing each incident's classification, intake date, escalation timestamp, assigned investigator, resolution date, and closure status", "post_incident_review_reports for each Level 2+ incident containing root cause analysis, affected population estimate, corrective action plan with owner and deadline, and policy or system change traceable to the finding", "regulatory_notification_assessment_records for Level 3+ incidents showing evaluation of EU AI Act Art. 73 reporting obligations and notification status where applicable" ], "evidence": [ { "id": "EG-06-E1", "description": "ai_ethics_incident_response_procedure document with version date, severity classification framework (minimum three levels), named escalation roles with SLA timelines, investigation protocol, affected party notification criteria, and post-incident review requirements", "evidence_type": "incident-record", "verification": "attested" }, { "id": "EG-06-E2", "description": "ethics_incident_log for trailing 12 months showing each incident's classification, intake date, escalation timestamp, assigned investigator, resolution date, and closure status", "evidence_type": "incident-record", "verification": "attested" }, { "id": "EG-06-E3", "description": "post_incident_review_reports for each Level 2+ incident containing root cause analysis, affected population estimate, corrective action plan with owner and deadline, and policy or system change traceable to the finding", "evidence_type": "incident-record", "verification": "attested" }, { "id": "EG-06-E4", "description": "regulatory_notification_assessment_records for Level 3+ incidents showing evaluation of EU AI Act Art. 73 reporting obligations and notification status where applicable", "evidence_type": "evaluation-scorecard", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MANAGE 4.3 requires that incidents and errors are communicated to relevant AI actors and that processes for tracking, responding to, and recovering from them are followed and documented. This control implements the incident identification, escalation, and remediation elements of that requirement for ethics incidents." } ] }, { "requirement_id": "MEASURE-1.1", "section": "MEASURE 1.1", "title": "Approaches and metrics for AI risk measurement identified", "text": "Approaches and metrics for measurement of AI risk are identified and documented.", "verdict": "supported", "coverage": "direct", "notes": "AG-06 defines agent program metrics and KPIs; EG-07 covers ethics program effectiveness measurement; CR-01 provides continuous production monitoring and risk aggregation.", "control_count": 3, "proof_chain": [ { "control": "apeiris://agentic/controls/AG-06", "id": "AG-06", "domain": "agentic", "name": "Agent Program Metrics and KPIs", "validation_objective": "The enterprise collects and reports a defined set of agentic AI governance KPIs from automated pipelines on a defined frequency, and the governance committee receives current-period metric values with trend data and threshold breach alerts at each governance review meeting.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Published Agentic AI Program Metrics Catalog defining each KPI: name, formula, data source, reporting frequency, metric owner, and target threshold with current baseline", "Automated governance dashboard outputs from at least the three most recent reporting periods showing coverage, process, outcome, and attestation metrics", "Governance committee meeting records confirming receipt and review of metrics reports and documenting threshold breach discussions and directed actions", "Data pipeline lineage documentation showing the authoritative source for each KPI and the automated collection process" ], "evidence": [ { "id": "AG-06-E1", "description": "Published Agentic AI Program Metrics Catalog defining each KPI: name, formula, data source, reporting frequency, metric owner, and target threshold with current baseline", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-06-E2", "description": "Automated governance dashboard outputs from at least the three most recent reporting periods showing coverage, process, outcome, and attestation metrics", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "AG-06-E3", "description": "Governance committee meeting records confirming receipt and review of metrics reports and documenting threshold breach discussions and directed actions", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AG-06-E4", "description": "Data pipeline lineage documentation showing the authoritative source for each KPI and the automated collection process", "evidence_type": "data-lineage-record", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE 1.1 requires approaches and metrics for AI risk measurement to be selected and implemented. A defined agentic program metrics catalog with coverage, incident, and drift KPIs is that selection, made explicit and reviewable." }, { "control": "apeiris://ethics/controls/EG-07", "id": "EG-07", "domain": "ethics", "name": "Ethics Program Metrics and Effectiveness Measurement", "validation_objective": "The organization must maintain an active ethics metrics portfolio containing a minimum of three leading indicators and three lagging indicators across governance, process, and outcome dimensions, with documented collection methodology, quarterly Ethics Board reporting, and traceable action items for any metric below defined threshold. At least one outcome metric must measure system-level ethical performance such as bias finding rate or ethics incident rate.", "blocking_effect": "advisory", "evidence_required": [ "ethics_metrics_portfolio_document defining each metric with name, type (leading/lagging), dimension (governance/process/outcome), collection source, target value, threshold, and reporting cadence", "quarterly_ethics_metrics_dashboard_reports for trailing 12 months showing metric values, trend indicators, threshold alert status, and action items for below-threshold metrics", "action_item_tracking_records linking below-threshold metrics to specific corrective actions with owner, deadline, and closure evidence demonstrating that metrics reviews drive program adjustments", "annual_ethics_effectiveness_report submitted to executive leadership and the Ethics Board with program-level assessment against stated ethics objectives" ], "evidence": [ { "id": "EG-07-E1", "description": "ethics_metrics_portfolio_document defining each metric with name, type (leading/lagging), dimension (governance/process/outcome), collection source, target value, threshold, and reporting cadence", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-07-E2", "description": "quarterly_ethics_metrics_dashboard_reports for trailing 12 months showing metric values, trend indicators, threshold alert status, and action items for below-threshold metrics", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "EG-07-E3", "description": "action_item_tracking_records linking below-threshold metrics to specific corrective actions with owner, deadline, and closure evidence demonstrating that metrics reviews drive program adjustments", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-07-E4", "description": "annual_ethics_effectiveness_report submitted to executive leadership and the Ethics Board with program-level assessment against stated ethics objectives", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE 2.1 requires that AI risk metrics and monitoring approaches are defined and implemented. This control implements the MEASURE function requirement for a structured portfolio of ethics and risk metrics with defined collection and reporting processes." }, { "control": "apeiris://model/controls/CR-01", "id": "CR-01", "domain": "model", "name": "Continuous Production Monitoring and Risk Aggregation", "validation_objective": "All runtime monitoring signals \u2014 performance, drift, fairness, safety incidents, and deployment event flags \u2014 must be continuously aggregated into a unified risk dashboard with pre-configured automated alerting thresholds; any degradation in a monitored dimension must be detected and an alert dispatched within one operational window.", "blocking_effect": "advisory", "evidence_required": [ "risk_dashboard_configuration_record showing all registered signal feeds (performance, drift, fairness, safety, incident), their alert thresholds, assigned monitoring window duration, and escalation recipients", "alert_audit_log covering at least 30 days showing triggered alerts with signal_type, threshold_crossed, alert_timestamp, and escalation_recipient for each alert", "monitoring_coverage_audit confirming every deployed model version has an associated monitoring configuration with no version gaps", "risk_aggregation_methodology_document defining how individual dimension alerts are combined into composite risk scores and dashboard status indicators", "post-market_monitoring_report satisfying EU AI Act Art. 72 covering the monitoring period, key findings, and corrective actions taken or planned" ], "evidence": [ { "id": "CR-01-E1", "description": "risk_dashboard_configuration_record showing all registered signal feeds (performance, drift, fairness, safety, incident), their alert thresholds, assigned monitoring window duration, and escalation recipients", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-01-E2", "description": "alert_audit_log covering at least 30 days showing triggered alerts with signal_type, threshold_crossed, alert_timestamp, and escalation_recipient for each alert", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E3", "description": "monitoring_coverage_audit confirming every deployed model version has an associated monitoring configuration with no version gaps", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E4", "description": "risk_aggregation_methodology_document defining how individual dimension alerts are combined into composite risk scores and dashboard status indicators", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E5", "description": "post-market_monitoring_report satisfying EU AI Act Art. 72 covering the monitoring period, key findings, and corrective actions taken or planned", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.4 (MEASURE function) provides that the functionality and behavior of the AI system and its components are monitored when in production. CR-01 aggregates production monitoring signals \u2014 performance, drift, fairness, safety, cost \u2014 into a single risk view with calibrated alert thresholds." } ] }, { "requirement_id": "MEASURE-1.2", "section": "MEASURE 1.2", "title": "Instruments to measure AI risk identified and tested", "text": "Instruments, measurement tools, and methods to measure AI risk are identified and tested for validity and reliability.", "verdict": "supported", "coverage": "direct", "notes": "EV-06 enforces reproducible evaluation design with documented instrument validity; EV-02 requires pre-deployment evaluation gate; FA-03 mandates fairness metric selection with justification.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/EV-06", "id": "EV-06", "domain": "model", "name": "Reproducible Evaluation Design", "validation_objective": "Every evaluation run against a model artifact can be independently reproduced from the evaluation design document alone within the defined tolerance by a party who was not involved in the original run; all benchmarks have documented contamination screening results; and all evaluation artifacts are signed with SHA-256 content-addressed hashes recorded in the evaluation manifest.", "blocking_effect": "blocks-deployment", "evidence_required": [ "version_controlled_benchmark_selection_document with pre-specified selection_criteria, benchmark_ids, known_limitations, and alternatives_considered \u2014 signed and committed before any evaluation run begins", "contamination_screening_report documenting screening_methodology, training_corpus_reference, per-benchmark contamination_result (clean/flagged/excluded), and screening_date", "evaluation_design_document capturing all reproduction parameters: random_seeds, software_dependency_versions with hashes, hardware_configuration, serving_framework_config, eval_script_version_and_hash, prompt_templates, and post_processing_steps", "independent_reproduction_run_record showing reproduction_results within the defined tolerance alongside original_results, confirming design document sufficiency for independent replication", "signed_evaluation_artifact_manifest listing SHA-256 hashes for all artifacts (design document, scripts, datasets, results) with signer_identity and key_identifier" ], "evidence": [ { "id": "EV-06-E1", "description": "version_controlled_benchmark_selection_document with pre-specified selection_criteria, benchmark_ids, known_limitations, and alternatives_considered \u2014 signed and committed before any evaluation run begins", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-06-E2", "description": "contamination_screening_report documenting screening_methodology, training_corpus_reference, per-benchmark contamination_result (clean/flagged/excluded), and screening_date", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-06-E3", "description": "evaluation_design_document capturing all reproduction parameters: random_seeds, software_dependency_versions with hashes, hardware_configuration, serving_framework_config, eval_script_version_and_hash, prompt_templates, and post_processing_steps", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-06-E4", "description": "independent_reproduction_run_record showing reproduction_results within the defined tolerance alongside original_results, confirming design document sufficiency for independent replication", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-06-E5", "description": "signed_evaluation_artifact_manifest listing SHA-256 hashes for all artifacts (design document, scripts, datasets, results) with signer_identity and key_identifier", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.1 (MEASURE function) provides that test sets, metrics, and details about the tools used during TEVV are documented. EV-06\u2019s reproducible evaluation design pins the test sets, metrics, seeds, and environments so the TEVV documentation this subcategory requires is complete and re-runnable." }, { "control": "apeiris://model/controls/EV-02", "id": "EV-02", "domain": "model", "name": "Fitness, Safety, Reliability and Policy-Conformance Evaluation", "validation_objective": "Before deployment, every model has been evaluated against pre-specified, dimension-level pass/fail thresholds \u2014 fitness, safety, reliability, and policy-conformance \u2014 with results documented against the model artifact hash and evaluation suite version. No threshold is modified after evaluation begins, and any threshold trade-off decision is documented as a named risk-acceptance record before the deployment manifest is signed.", "blocking_effect": "blocks-deployment", "evidence_required": [ "pre_specified_evaluation_protocol with model_artifact_hash, evaluation_suite_version, and per-dimension thresholds (fitness accuracy target, safety refusal rate, reliability error budget, policy-conformance violation rate), signed by the evaluation lead before testing begins \u2014 not after results are known", "dimension_level_evaluation_results showing per-dimension metric values, pass/fail verdict against pre-specified threshold, and model_artifact_hash confirming results correspond to the evaluated version", "evaluation_suite_provenance_record confirming that evaluation datasets are disjoint from training data, with contamination-check reference to TG-05 attestation", "risk_acceptance_record for any dimension where the pass threshold was not met but deployment was authorized, documenting named risk-accepter, specific capability gap, deployment risk consequence, and remediation deadline" ], "evidence": [ { "id": "EV-02-E1", "description": "pre_specified_evaluation_protocol with model_artifact_hash, evaluation_suite_version, and per-dimension thresholds (fitness accuracy target, safety refusal rate, reliability error budget, policy-conformance violation rate), signed by the evaluation lead before testing begins \u2014 not after results are known", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-02-E2", "description": "dimension_level_evaluation_results showing per-dimension metric values, pass/fail verdict against pre-specified threshold, and model_artifact_hash confirming results correspond to the evaluated version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-02-E3", "description": "evaluation_suite_provenance_record confirming that evaluation datasets are disjoint from training data, with contamination-check reference to TG-05 attestation", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-02-E4", "description": "risk_acceptance_record for any dimension where the pass threshold was not met but deployment was authorized, documenting named risk-accepter, specific capability gap, deployment risk consequence, and remediation deadline", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.3 (MEASURE function) provides that AI system performance or assurance criteria are measured and demonstrated for conditions similar to deployment. EV-02\u2019s fitness, safety, reliability, and policy-conformance dimensions measure and demonstrate the system\u2019s assurance criteria before deployment." }, { "control": "apeiris://ethics/controls/FA-03", "id": "FA-03", "domain": "ethics", "name": "Fairness Metric Selection and Justification", "validation_objective": "For each AI system subject to fairness evaluation, a documented Fairness Metric Justification Document must specify the selected metrics with rationale, demonstrate awareness of mathematical incompatibilities between candidate metrics in the context of this system's base rates, and document why chosen metrics are appropriate for affected populations and applicable legal standards.", "blocking_effect": "blocks-deployment", "evidence_required": [ "fairness_metric_justification_document identifying each selected metric (e.g., demographic_parity, equalized_odds, predictive_rate_parity) with rationale for selection and explicit acknowledgment of trade-offs against rejected alternative metrics", "metric_incompatibility_analysis demonstrating awareness of which metrics cannot simultaneously be satisfied for this system given base-rate differences across protected groups", "legal_alignment_record mapping selected metrics to requirements in applicable law (e.g., four-fifths rule for EEOC and LL144, equal error rates for credit contexts)", "affected_population_consultation_record documenting input from representatives of affected groups on metric priorities and harm weightings" ], "evidence": [ { "id": "FA-03-E1", "description": "fairness_metric_justification_document identifying each selected metric (e.g., demographic_parity, equalized_odds, predictive_rate_parity) with rationale for selection and explicit acknowledgment of trade-offs against rejected alternative metrics", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-03-E2", "description": "metric_incompatibility_analysis demonstrating awareness of which metrics cannot simultaneously be satisfied for this system given base-rate differences across protected groups", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-03-E3", "description": "legal_alignment_record mapping selected metrics to requirements in applicable law (e.g., four-fifths rule for EEOC and LL144, equal error rates for credit contexts)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-03-E4", "description": "affected_population_consultation_record documenting input from representatives of affected groups on metric priorities and harm weightings", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE 2.11 requires that fairness and bias are evaluated, with results demonstrated and measurement approaches documented and justified with reference to context, stakeholders, and applicable standards. The Fairness Metric Justification Document is the primary artifact satisfying this measurement documentation requirement." } ] }, { "requirement_id": "MEASURE-1.3", "section": "MEASURE 1.3", "title": "Independent internal experts involved in testing", "text": "Internal experts who did not serve as developers for the AI system are involved in testing, evaluation, validation, and verification.", "verdict": "supported", "coverage": "direct", "notes": "EV-08 requires independent validation; FA-04 mandates independent bias testing methodology; AS-01 requires adversarial red-teaming by a separate team before launch.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/EV-08", "id": "EV-08", "domain": "model", "name": "Independent Validation", "validation_objective": "Every model deployment authorization is signed by a validator who is organizationally independent of the model development function with no shared management chain at a meaningful level; the validator has documented authority to withhold authorization and escalate findings to a governance committee; and the deployment pipeline rejects any manifest where the validator and development lead share the same organizational identity.", "blocking_effect": "blocks-deployment", "evidence_required": [ "organizational_chart_and_reporting_structure_document confirming validator independence from the development team for each model system, with management_chain_separation explicitly documented to a meaningful organizational level", "validation_function_authority_policy document version-controlled and governance-committee-approved, explicitly granting rights to request additional evaluation runs, require remediation, and withhold deployment authorization without development team approval", "evaluation_manifests containing named, attributed validator approvals with validator_identity distinct from development_team_lead_identity, linked to verifiable PKI certificate or directory record", "escalation_path_verification_record demonstrating that a test dispute routes to the governance committee and not to the development management chain", "annual_independence_structure_review_document for us-regulated-banking profile, available to regulators and auditors on request" ], "evidence": [ { "id": "EV-08-E1", "description": "organizational_chart_and_reporting_structure_document confirming validator independence from the development team for each model system, with management_chain_separation explicitly documented to a meaningful organizational level", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-08-E2", "description": "validation_function_authority_policy document version-controlled and governance-committee-approved, explicitly granting rights to request additional evaluation runs, require remediation, and withhold deployment authorization without development team approval", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-08-E3", "description": "evaluation_manifests containing named, attributed validator approvals with validator_identity distinct from development_team_lead_identity, linked to verifiable PKI certificate or directory record", "evidence_type": "certification", "verification": "third-party" }, { "id": "EV-08-E4", "description": "escalation_path_verification_record demonstrating that a test dispute routes to the governance committee and not to the development management chain", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "EV-08-E5", "description": "annual_independence_structure_review_document for us-regulated-banking profile, available to regulators and auditors on request", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN-2.1 (GOVERN function) provides that roles, responsibilities, and lines of communication for AI risk management are documented and clear. EV-08\u2019s organizationally independent validation function is a documented role separation within AI risk management, giving effective challenge a defined organizational home." }, { "control": "apeiris://ethics/controls/FA-04", "id": "FA-04", "domain": "ethics", "name": "Independent Bias Testing Methodology", "validation_objective": "Bias testing for AI systems subject to fairness requirements must be executed under a documented, pre-registered protocol by a tester with no organizational conflict of interest with the model development team, with all findings retained in an immutable log and reported without post-hoc filtering.", "blocking_effect": "blocks-deployment", "evidence_required": [ "independent_bias_test_protocol_document published prior to test execution specifying methodology, test datasets, metrics, and pass/fail thresholds", "tester_independence_certification confirming the testing entity or individual has no direct reporting relationship to or financial interest in the model development team, signed by a party outside the model development chain", "bias_test_execution_log with timestamped test runs, inputs, and outputs in an immutable or append-only store preventing retroactive modification", "bias_test_findings_report including all findings (not only passing results) with statistical support, identified disparity locations, and remediation recommendations" ], "evidence": [ { "id": "FA-04-E1", "description": "independent_bias_test_protocol_document published prior to test execution specifying methodology, test datasets, metrics, and pass/fail thresholds", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "FA-04-E2", "description": "tester_independence_certification confirming the testing entity or individual has no direct reporting relationship to or financial interest in the model development team, signed by a party outside the model development chain", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-04-E3", "description": "bias_test_execution_log with timestamped test runs, inputs, and outputs in an immutable or append-only store preventing retroactive modification", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "FA-04-E4", "description": "bias_test_findings_report including all findings (not only passing results) with statistical support, identified disparity locations, and remediation recommendations", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE 2.11 recommends that fairness and bias evaluations use diverse evaluation methods including external red-teaming and independent assessment. This control establishes the independence and documentation requirements that make such external assessment credible." }, { "control": "apeiris://security/controls/AS-01", "id": "AS-01", "domain": "security", "name": "Adversarially red-team and evaluate the agent before launch", "validation_objective": "Before any deployment to production, the agent must have passed a structured adversarial red-team exercise covering multi-turn goal hijack, tool misuse, and data exfiltration scenarios, with measured attack-success-rates at or below the defined launch threshold. Deployment must be blocked until the red-team pass/fail gate is cleared and documented.", "blocking_effect": "blocks-deployment", "evidence_required": [ "pre_launch_red_team_report listing each scenario (multi-turn hijack, tool-misuse, exfiltration), the attack-success-rate per scenario, the defined launch threshold, and a signed go/no-go decision", "multi_turn_eval_suite_run_log showing the agentic benchmark used (e.g., AgentDojo, FinBot CTF), commit SHA, run date, and overall pass/fail outcome against the threshold", "red_team_scope_document confirming coverage of multi-turn drift scenarios not only single-prompt tests, signed before the red-team exercise begins", "launch_gate_approval_record linking the red-team report to the deployment decision with approver identity and timestamp" ], "evidence": [ { "id": "AS-01-E1", "description": "pre_launch_red_team_report listing each scenario (multi-turn hijack, tool-misuse, exfiltration), the attack-success-rate per scenario, the defined launch threshold, and a signed go/no-go decision", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AS-01-E2", "description": "multi_turn_eval_suite_run_log showing the agentic benchmark used (e.g., AgentDojo, FinBot CTF), commit SHA, run date, and overall pass/fail outcome against the threshold", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "AS-01-E3", "description": "red_team_scope_document confirming coverage of multi-turn drift scenarios not only single-prompt tests, signed before the red-team exercise begins", "evidence_type": "red-team-report", "verification": "third-party" }, { "id": "AS-01-E4", "description": "launch_gate_approval_record linking the red-team report to the deployment decision with approver identity and timestamp", "evidence_type": "red-team-report", "verification": "third-party" } ], "fit": "adjacent", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF Measure function: analyse, assess, benchmark, and monitor the AI risks and impacts. \"Adversarially red-team and evaluate the agent before launch\" is a corresponding measurement and monitoring activity." } ] }, { "requirement_id": "MEASURE-2.1", "section": "MEASURE 2.1", "title": "Test sets representative of operational environment", "text": "Test sets, metrics, and evaluation protocols are representative of the intended operational environment and population.", "verdict": "supported", "coverage": "direct", "notes": "TG-05 enforces train/evaluation/test separation and contamination prevention; EV-01 gates pre-deployment evaluation; TG-02 requires bias and representativeness assessment of training data \u2014 together ensuring test sets reflect the operational context.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/TG-05", "id": "TG-05", "domain": "model", "name": "Train/Evaluation/Test Separation and Contamination Prevention", "validation_objective": "Training, evaluation, and test data splits contain no contaminating examples from other splits, verified by automated exact-match and near-duplicate detection before each training run commences. The training pipeline blocks any run where contamination detection has not completed with a clean result and produced a signed attestation.", "blocking_effect": "blocks-deployment", "evidence_required": [ "contamination_check_audit_log with training_run_id, benchmark names checked, exact_match_count, near_duplicate_count, retrieval_leakage_count, and pass/block outcome per split pair for every training run", "split_deduplication_report listing content-hash comparison results for all training-test and training-eval split pairs, with deduplication method (exact-match hash, MinHash LSH, embedding cosine similarity) and similarity threshold used", "test_set_access_control_record showing storage-layer ACL configuration restricting test split access to validation personnel only, with last-verified date", "evaluation_overfitting_policy document specifying maximum benchmark reuse count per model version, rotation schedule, and use of held-out external benchmarks not accessible to the model development team" ], "evidence": [ { "id": "TG-05-E1", "description": "contamination_check_audit_log with training_run_id, benchmark names checked, exact_match_count, near_duplicate_count, retrieval_leakage_count, and pass/block outcome per split pair for every training run", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "TG-05-E2", "description": "split_deduplication_report listing content-hash comparison results for all training-test and training-eval split pairs, with deduplication method (exact-match hash, MinHash LSH, embedding cosine similarity) and similarity threshold used", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "TG-05-E3", "description": "test_set_access_control_record showing storage-layer ACL configuration restricting test split access to validation personnel only, with last-verified date", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "TG-05-E4", "description": "evaluation_overfitting_policy document specifying maximum benchmark reuse count per model version, rotation schedule, and use of held-out external benchmarks not accessible to the model development team", "evidence_type": "evaluation-scorecard", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP-2.3 (MAP function) provides that scientific integrity and TEVV considerations, including data collection and selection, are identified and documented. TG-05\u2019s enforced train/evaluation/test separation protects the experimental design and construct validity this subcategory requires TEVV to document." }, { "control": "apeiris://model/controls/EV-01", "id": "EV-01", "domain": "model", "name": "Pre-Deployment Evaluation Gate", "validation_objective": "No model artifact is promoted to production unless a signed evaluation manifest referencing that artifact's exact hash is present in the tamper-evident evaluation log and has received dual approval from named, authorized approvers. The deployment pipeline enforces this as a cryptographic gate \u2014 an absent, unsigned, or hash-mismatched manifest results in an automatic pipeline block with no override path except a logged exception with named risk-accepter.", "blocking_effect": "blocks-deployment", "evidence_required": [ "signed_evaluation_manifest with model_artifact_hash, evaluation_suite_version, evaluator_identities, per-dimension pass/fail outcome, signing_key_id, and manifest_signature (Ed25519) for every production model version", "tamper_evident_evaluation_log entry linking manifest_id to model_artifact_hash, recording append timestamp, appender identity, and log integrity proof", "dual_approval_record with two named approver identities, their organizational roles, approval timestamps, and the manifest_hash each approver authorized", "pipeline_execution_log showing at least one successful gate enforcement event: a deployment attempt with an absent or invalid manifest that was blocked, confirming the gate is operational rather than advisory" ], "evidence": [ { "id": "EV-01-E1", "description": "signed_evaluation_manifest with model_artifact_hash, evaluation_suite_version, evaluator_identities, per-dimension pass/fail outcome, signing_key_id, and manifest_signature (Ed25519) for every production model version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-01-E2", "description": "tamper_evident_evaluation_log entry linking manifest_id to model_artifact_hash, recording append timestamp, appender identity, and log integrity proof", "evidence_type": "audit-log", "verification": "automated" }, { "id": "EV-01-E3", "description": "dual_approval_record with two named approver identities, their organizational roles, approval timestamps, and the manifest_hash each approver authorized", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EV-01-E4", "description": "pipeline_execution_log showing at least one successful gate enforcement event: a deployment attempt with an absent or invalid manifest that was blocked, confirming the gate is operational rather than advisory", "evidence_type": "configuration-snapshot", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MANAGE-1.1 (MANAGE function) provides that a determination is made whether the AI system achieves its intended purposes and whether development or deployment should proceed. EV-01\u2019s pre-deployment evaluation gate is the mechanism that produces and enforces that go/no-go determination before release." }, { "control": "apeiris://model/controls/TG-02", "id": "TG-02", "domain": "model", "name": "Bias and Representativeness Assessment", "validation_objective": "Before each training run and after each data refresh, a documented subgroup and intersectional fairness analysis is completed for the training dataset, producing a bias baseline report that identifies population coverage gaps and subgroup representation rates; this report must be reviewed and accepted before training proceeds.", "blocking_effect": "blocks-deployment", "evidence_required": [ "bias_assessment_report containing subgroup representation rates across all demographic dimensions relevant to the model's use case, intersectional analysis results, identification of underrepresented populations, and comparison to the prior baseline where applicable", "data_refresh_trigger_record showing that a new bias assessment was initiated whenever the training dataset was updated, not only at initial training", "bias_baseline_acceptance_record with reviewer identity, acceptance timestamp, and documented acknowledgment of any known representation gaps and their accepted risk level", "subgroup_definition_document specifying which demographic dimensions and proxy features were analyzed, reviewed against the model's deployment context and affected populations" ], "evidence": [ { "id": "TG-02-E1", "description": "bias_assessment_report containing subgroup representation rates across all demographic dimensions relevant to the model's use case, intersectional analysis results, identification of underrepresented populations, and comparison to the prior baseline where applicable", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-02-E2", "description": "data_refresh_trigger_record showing that a new bias assessment was initiated whenever the training dataset was updated, not only at initial training", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-02-E3", "description": "bias_baseline_acceptance_record with reviewer identity, acceptance timestamp, and documented acknowledgment of any known representation gaps and their accepted risk level", "evidence_type": "human-review-record", "verification": "human" }, { "id": "TG-02-E4", "description": "subgroup_definition_document specifying which demographic dimensions and proxy features were analyzed, reviewed against the model's deployment context and affected populations", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.11 (MEASURE function) provides that fairness and bias are evaluated and results are documented. TG-02\u2019s subgroup and intersectional representativeness analysis produces the documented bias evaluation this subcategory requires, applied at the training-data stage." } ] }, { "requirement_id": "MEASURE-2.2", "section": "MEASURE 2.2", "title": "AI system evaluated for human oversight capabilities", "text": "AI system is evaluated to support human oversight and decision-making, including contestability and recourse.", "verdict": "supported", "coverage": "direct", "notes": "OA-02 mandates meaningful human oversight for high-stakes decisions; GV-01 enforces human hard-stop for irreversible actions; HI-04 specifies human oversight and override mechanisms; OA-08 requires notice, explanation, human review, and contestability.", "control_count": 4, "proof_chain": [ { "control": "apeiris://model/controls/OA-02", "id": "OA-02", "domain": "model", "name": "Meaningful Human Oversight for High-Stakes Decisions", "validation_objective": "For every high-impact-decision or eu-high-risk model, a human reviewer must have documented access to model inputs, confidence scores, and reasoning; organizational authority to override without penalty; domain competence verified through training records; and a technically effective override mechanism before any AI output takes effect. Override rates must be monitored and a rate near zero for 30 consecutive days must automatically trigger a governance review.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "five_factor_oversight_design_document per high-stakes use case, signed by the AI governance committee, covering: review time allocation, information display design, override authority documentation, competence requirements, and override mechanism technical specification", "override_rate_time_series report for the past 12 months broken down by model, decision type, and reviewer cohort \u2014 with governance-defined floor thresholds annotated", "reviewer_training_completion_record including initial onboarding completion date, annual recertification dates, competence assessment scores, and automation-bias module completion", "override_mechanism_test_log confirming that override actions propagate correctly through downstream systems without requiring secondary approval" ], "evidence": [ { "id": "OA-02-E1", "description": "five_factor_oversight_design_document per high-stakes use case, signed by the AI governance committee, covering: review time allocation, information display design, override authority documentation, competence requirements, and override mechanism technical specification", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-02-E2", "description": "override_rate_time_series report for the past 12 months broken down by model, decision type, and reviewer cohort \u2014 with governance-defined floor thresholds annotated", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-02-E3", "description": "reviewer_training_completion_record including initial onboarding completion date, annual recertification dates, competence assessment scores, and automation-bias module completion", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-02-E4", "description": "override_mechanism_test_log confirming that override actions propagate correctly through downstream systems without requiring secondary approval", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN-3.2 (GOVERN function) provides that policies define and differentiate roles and responsibilities for human-AI configurations and oversight. OA-02\u2019s five-factor oversight adequacy framework defines and verifies the human-oversight roles this subcategory calls for." }, { "control": "apeiris://security/controls/GV-01", "id": "GV-01", "domain": "security", "name": "Require a human hard-stop for irreversible actions", "validation_objective": "Every irreversible agent action (write, deletion, transfer, deployment, or any action with no safe undo path) must be deterministically halted and routed to an explicit human (or quorum) approval before execution; the agent must not be capable of self-approving such actions, and the hard-stop must be enforced at platform infrastructure level, not by a model-layer instruction.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "irreversible_action_approval_record linking each halted action to the human approver(s), approval_token with timestamp and cryptographic signature, and action outcome (executed/cancelled)", "irreversibility_classification_list identifying which action types are classified as irreversible, with the policy_version and last_review_date", "hard_stop_enforcement_log showing agent execution was suspended at the irreversible action gate and resumed only after receipt of a valid external approval token", "self_approval_rejection_log confirming any attempt by the agent to approve its own irreversible actions was blocked by the platform", "quorum_policy_record for high-stakes action categories specifying minimum required approvers and approval token validity window" ], "evidence": [ { "id": "GV-01-E1", "description": "irreversible_action_approval_record linking each halted action to the human approver(s), approval_token with timestamp and cryptographic signature, and action outcome (executed/cancelled)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-01-E2", "description": "irreversibility_classification_list identifying which action types are classified as irreversible, with the policy_version and last_review_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-01-E3", "description": "hard_stop_enforcement_log showing agent execution was suspended at the irreversible action gate and resumed only after receipt of a valid external approval token", "evidence_type": "human-review-record", "verification": "human" }, { "id": "GV-01-E4", "description": "self_approval_rejection_log confirming any attempt by the agent to approve its own irreversible actions was blocked by the platform", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-01-E5", "description": "quorum_policy_record for high-stakes action categories specifying minimum required approvers and approval token validity window", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "adjacent", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF Govern function: cultivate and operate a culture of AI risk management, with policies, roles, accountability, and oversight. \"Require a human hard-stop for irreversible actions\" is a corresponding governance activity." }, { "control": "apeiris://ethics/controls/HI-04", "id": "HI-04", "domain": "ethics", "name": "Human Oversight and Override Mechanisms", "validation_objective": "All AI systems classified as significant or critical consequentiality tier must have override logging implemented and producing verifiable disposition records for every AI recommendation reviewed by a human operator. Override rate monitoring must be active and generating alerts when rates fall below defined thresholds, and every alert must trigger a documented review response within 30 days.", "blocking_effect": "blocks-deployment", "evidence_required": [ "consequentiality_tier_classification_record for every production AI system documenting the assigned tier (advisory/significant/critical), classification rationale, and mandatory oversight requirements that tier triggers", "override_audit_log for significant and critical tier systems showing AI recommendations, human dispositions (accepted/modified/rejected), override rationale where provided, and timestamps covering the prior 90 days", "override_rate_monitoring_report showing per-system trend data, defined threshold levels, alerts triggered in the prior 12 months, and documented investigation responses with completion dates", "interface_design_review_record confirming evaluation of the AI decision interface against automation-bias-avoidance criteria: confidence levels displayed, uncertainty ranges shown, override pathway accessible without additional navigation, AI-generated content distinguished from operator-entered content", "human_overseer_assignment_record naming the qualified overseer role for each significant and critical tier AI system with accountability documentation and training evidence" ], "evidence": [ { "id": "HI-04-E1", "description": "consequentiality_tier_classification_record for every production AI system documenting the assigned tier (advisory/significant/critical), classification rationale, and mandatory oversight requirements that tier triggers", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-04-E2", "description": "override_audit_log for significant and critical tier systems showing AI recommendations, human dispositions (accepted/modified/rejected), override rationale where provided, and timestamps covering the prior 90 days", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-04-E3", "description": "override_rate_monitoring_report showing per-system trend data, defined threshold levels, alerts triggered in the prior 12 months, and documented investigation responses with completion dates", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "HI-04-E4", "description": "interface_design_review_record confirming evaluation of the AI decision interface against automation-bias-avoidance criteria: confidence levels displayed, uncertainty ranges shown, override pathway accessible without additional navigation, AI-generated content distinguished from operator-entered content", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "HI-04-E5", "description": "human_overseer_assignment_record naming the qualified overseer role for each significant and critical tier AI system with accountability documentation and training evidence", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN 3.2 requires policies and procedures that define and differentiate roles and responsibilities for human-AI configurations and oversight of AI systems. The control's consequentiality tiers, override authority, and disposition logging implement exactly that oversight governance." }, { "control": "apeiris://model/controls/OA-08", "id": "OA-08", "domain": "model", "name": "Notice, Explanation Support, Human Review and Contestability", "validation_objective": "The system must have a documented, legally-reviewed per-use-case applicability determination confirming which of the four obligations (notice, explanation, human review, contestability) apply; for each applicable obligation, the corresponding mechanism must be implemented, technically accurate, and operationally accessible to affected individuals without unreasonable barrier.", "blocking_effect": "requires-review", "evidence_required": [ "per-use-case applicability determination log with legal basis, applicable jurisdiction, conclusions, and reviewing counsel sign-off for each production AI deployment", "explanation mechanism validation test results confirming explanation outputs match model feature attribution (e.g., SHAP/LIME correlation > 0.8) for a representative sample of regulated decisions", "contestability process documentation showing defined SLA timelines, reviewer authority scope, and re-evaluation workflow design reviewed by legal counsel", "human review access log for trailing 12 months showing request volume, response times, reviewer qualifications, and rate of outcome changes", "sample of adverse action notices or equivalent AI disclosure documents (redacted) confirming notice delivery for regulated decision use cases" ], "evidence": [ { "id": "OA-08-E1", "description": "per-use-case applicability determination log with legal basis, applicable jurisdiction, conclusions, and reviewing counsel sign-off for each production AI deployment", "evidence_type": "audit-log", "verification": "automated" }, { "id": "OA-08-E2", "description": "explanation mechanism validation test results confirming explanation outputs match model feature attribution (e.g., SHAP/LIME correlation > 0.8) for a representative sample of regulated decisions", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "OA-08-E3", "description": "contestability process documentation showing defined SLA timelines, reviewer authority scope, and re-evaluation workflow design reviewed by legal counsel", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "OA-08-E4", "description": "human review access log for trailing 12 months showing request volume, response times, reviewer qualifications, and rate of outcome changes", "evidence_type": "audit-log", "verification": "automated" }, { "id": "OA-08-E5", "description": "sample of adverse action notices or equivalent AI disclosure documents (redacted) confirming notice delivery for regulated decision use cases", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MANAGE-4.1 (MANAGE function) provides that post-deployment monitoring plans are implemented, including appeal and override, decommissioning, incident response, and change management. OA-08\u2019s notice, explanation, human-review, and contestability mechanisms implement the appeal-and-override component of post-deployment risk management." } ] }, { "requirement_id": "MEASURE-2.3", "section": "MEASURE 2.3", "title": "AI system evaluated for bias and discrimination", "text": "AI system functionality and behavior are evaluated for bias and potential discriminatory impacts.", "verdict": "supported", "coverage": "direct", "notes": "EV-05 requires fairness and bias evaluation; TG-02 addresses training data bias and representativeness; FA-02 mandates an algorithmic bias impact assessment.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/EV-05", "id": "EV-05", "domain": "model", "name": "Fairness and Bias Evaluation", "validation_objective": "The model system has a documented, pre-specified fairness evaluation protocol executed on data disjoint from training data, with disaggregated results per population group and harm type measured against pre-specified acceptance thresholds, and legal review obtained for any deployment affecting legally protected characteristics.", "blocking_effect": "blocks-deployment", "evidence_required": [ "fairness_evaluation_protocol document with pre-specified population_groups, harm_types, metric_selections, selection_rationale, legal_basis, and acceptance_thresholds \u2014 version-controlled and signed before any evaluation run begins", "disaggregated_evaluation_results report showing per-group performance metrics independently for each identified population group, with group_id, sample_count, and metric_values per harm type", "metric_tradeoff_decision_record explicitly stating which competing fairness constraints (e.g., demographic parity vs. equalized odds) take precedence for this deployment context and the documented rationale", "evaluation_data_disjointness_attestation confirming evaluation data for each population group does not overlap with the training corpus, with data_source_ids and overlap_check_method documented", "legal_review_record for any deployment affecting legally protected characteristics, with reviewing_authority identity and review_date" ], "evidence": [ { "id": "EV-05-E1", "description": "fairness_evaluation_protocol document with pre-specified population_groups, harm_types, metric_selections, selection_rationale, legal_basis, and acceptance_thresholds \u2014 version-controlled and signed before any evaluation run begins", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-05-E2", "description": "disaggregated_evaluation_results report showing per-group performance metrics independently for each identified population group, with group_id, sample_count, and metric_values per harm type", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-05-E3", "description": "metric_tradeoff_decision_record explicitly stating which competing fairness constraints (e.g., demographic parity vs. equalized odds) take precedence for this deployment context and the documented rationale", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-05-E4", "description": "evaluation_data_disjointness_attestation confirming evaluation data for each population group does not overlap with the training corpus, with data_source_ids and overlap_check_method documented", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-05-E5", "description": "legal_review_record for any deployment affecting legally protected characteristics, with reviewing_authority identity and review_date", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.11 (MEASURE function) provides that fairness and bias are evaluated and results are documented. EV-05\u2019s disaggregated error-rate measurement across protected subgroups produces the documented fairness and bias evaluation this subcategory requires." }, { "control": "apeiris://model/controls/TG-02", "id": "TG-02", "domain": "model", "name": "Bias and Representativeness Assessment", "validation_objective": "Before each training run and after each data refresh, a documented subgroup and intersectional fairness analysis is completed for the training dataset, producing a bias baseline report that identifies population coverage gaps and subgroup representation rates; this report must be reviewed and accepted before training proceeds.", "blocking_effect": "blocks-deployment", "evidence_required": [ "bias_assessment_report containing subgroup representation rates across all demographic dimensions relevant to the model's use case, intersectional analysis results, identification of underrepresented populations, and comparison to the prior baseline where applicable", "data_refresh_trigger_record showing that a new bias assessment was initiated whenever the training dataset was updated, not only at initial training", "bias_baseline_acceptance_record with reviewer identity, acceptance timestamp, and documented acknowledgment of any known representation gaps and their accepted risk level", "subgroup_definition_document specifying which demographic dimensions and proxy features were analyzed, reviewed against the model's deployment context and affected populations" ], "evidence": [ { "id": "TG-02-E1", "description": "bias_assessment_report containing subgroup representation rates across all demographic dimensions relevant to the model's use case, intersectional analysis results, identification of underrepresented populations, and comparison to the prior baseline where applicable", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-02-E2", "description": "data_refresh_trigger_record showing that a new bias assessment was initiated whenever the training dataset was updated, not only at initial training", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-02-E3", "description": "bias_baseline_acceptance_record with reviewer identity, acceptance timestamp, and documented acknowledgment of any known representation gaps and their accepted risk level", "evidence_type": "human-review-record", "verification": "human" }, { "id": "TG-02-E4", "description": "subgroup_definition_document specifying which demographic dimensions and proxy features were analyzed, reviewed against the model's deployment context and affected populations", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.11 (MEASURE function) provides that fairness and bias are evaluated and results are documented. TG-02\u2019s subgroup and intersectional representativeness analysis produces the documented bias evaluation this subcategory requires, applied at the training-data stage." }, { "control": "apeiris://ethics/controls/FA-02", "id": "FA-02", "domain": "ethics", "name": "Algorithmic Bias Impact Assessment", "validation_objective": "Every AI system subject to fairness evaluation must have a completed Algorithmic Bias Impact Assessment (ABIA) covering all protected characteristics in the FA-01 register, addressing both training data composition bias and model prediction disparities, completed before initial deployment and re-run after any material model or data change.", "blocking_effect": "blocks-deployment", "evidence_required": [ "algorithmic_bias_impact_assessment_report with per-characteristic findings, methodology description, direct discrimination and disparate impact pathways assessed, and risk rating for each finding", "training_data_composition_report showing demographic representation across protected groups relative to the reference deployment population", "model_prediction_disaggregation_report showing predicted outcome rates by protected characteristic with confidence intervals and statistical significance testing", "feedback_loop_risk_analysis documenting whether biased model outputs could influence future training data collection or labeling", "abia_reviewer_sign_off_record with reviewer credentials and date confirming independence from the model development team" ], "evidence": [ { "id": "FA-02-E1", "description": "algorithmic_bias_impact_assessment_report with per-characteristic findings, methodology description, direct discrimination and disparate impact pathways assessed, and risk rating for each finding", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E2", "description": "training_data_composition_report showing demographic representation across protected groups relative to the reference deployment population", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E3", "description": "model_prediction_disaggregation_report showing predicted outcome rates by protected characteristic with confidence intervals and statistical significance testing", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E4", "description": "feedback_loop_risk_analysis documenting whether biased model outputs could influence future training data collection or labeling", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E5", "description": "abia_reviewer_sign_off_record with reviewer credentials and date confirming independence from the model development team", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP 2.2 requires gathering scientific and empirical information about AI risks including bias and fairness risks across affected populations. The ABIA operationalizes this requirement by providing a structured empirical evaluation methodology." } ] }, { "requirement_id": "MEASURE-2.4", "section": "MEASURE 2.4", "title": "AI system evaluated for robustness against adversarial inputs", "text": "AI system is evaluated for robustness against adversarial, unforeseen, and out-of-distribution inputs.", "verdict": "supported", "coverage": "direct", "notes": "EV-04 mandates adversarial red-team testing; BH-06 evaluates injection-resistance in production; AS-01 requires pre-launch red-teaming against adversarial inputs.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/EV-04", "id": "EV-04", "domain": "model", "name": "Adversarial Red-Team Testing", "validation_objective": "The model system has a signed red-team report produced by a team organizationally independent of model development, documenting structured adversarial probing that covers all required attack categories for the applicable profiles, with all critical and high findings remediated and re-tested before the deployment gate clears.", "blocking_effect": "blocks-deployment", "evidence_required": [ "signed_red_team_scope_document with threat_model version, profile scope, and pre-exercise approval timestamp", "red_team_findings_log with finding_id, severity_classification, reproduction_steps, affected_population, and remediation_status per finding", "signed_red_team_report with residual_risk_statement linked to model artifact hash and listing remediated critical and high findings with re-test results", "remediation_evidence for all critical and high findings demonstrating the vulnerability is closed via re-test, not only via input-level patch", "for frontier-capability profile: escalation_records for any capability elicited at or near threshold levels with escalation_destination and response_action" ], "evidence": [ { "id": "EV-04-E1", "description": "signed_red_team_scope_document with threat_model version, profile scope, and pre-exercise approval timestamp", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EV-04-E2", "description": "red_team_findings_log with finding_id, severity_classification, reproduction_steps, affected_population, and remediation_status per finding", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-04-E3", "description": "signed_red_team_report with residual_risk_statement linked to model artifact hash and listing remediated critical and high findings with re-test results", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "EV-04-E4", "description": "remediation_evidence for all critical and high findings demonstrating the vulnerability is closed via re-test, not only via input-level patch", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "EV-04-E5", "description": "for frontier-capability profile: escalation_records for any capability elicited at or near threshold levels with escalation_destination and response_action", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.7 (MEASURE function) provides that AI system security and resilience are evaluated and documented. EV-04\u2019s adversarial red-team exercises are the security evaluation this subcategory requires, documented as pre-deployment evidence." }, { "control": "apeiris://model/controls/BH-06", "id": "BH-06", "domain": "model", "name": "Injection-Resistance Evaluation in Production", "validation_objective": "A versioned InjectionProbeLibrary covering at least three attack categories (direct prompt injection, indirect context injection, and jailbreak) must execute against the production model endpoint at minimum every 6 hours for generative-ai and frontier-capability profiles; InjectionResistanceScore must be computed per category and published to the model health dashboard; and any category score dropping below 90% must trigger a warning alert and cross-domain notification to securitycontrols.ai within one probe cycle.", "blocking_effect": "blocks-deployment", "evidence_required": [ "versioned InjectionProbeLibrary artifact with attack categories covered, probe count per category, sourcing documentation (red team exercises, MITRE ATLAS AML.T0051, published datasets), and last review date", "InjectionResistanceScore time-series for trailing 90 days per attack category with probe_id, timestamp, model_version, and pass/fail result for each probe execution", "cross-domain alert log showing securitycontrols.ai notifications for resistance score drops with triggered_at, attack_category, score_at_trigger, and acknowledgment timestamp for each event", "monthly InjectionResistanceScore trend report to the governance board showing 30-day rolling score per category, trend direction, and any model versions where scores regressed", "deployment gate certification records for the current production model version confirming InjectionResistanceScore at or above the 90% threshold at time of release across all probe categories" ], "evidence": [ { "id": "BH-06-E1", "description": "versioned InjectionProbeLibrary artifact with attack categories covered, probe count per category, sourcing documentation (red team exercises, MITRE ATLAS AML.T0051, published datasets), and last review date", "evidence_type": "red-team-report", "verification": "third-party" }, { "id": "BH-06-E2", "description": "InjectionResistanceScore time-series for trailing 90 days per attack category with probe_id, timestamp, model_version, and pass/fail result for each probe execution", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-06-E3", "description": "cross-domain alert log showing securitycontrols.ai notifications for resistance score drops with triggered_at, attack_category, score_at_trigger, and acknowledgment timestamp for each event", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "BH-06-E4", "description": "monthly InjectionResistanceScore trend report to the governance board showing 30-day rolling score per category, trend direction, and any model versions where scores regressed", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-06-E5", "description": "deployment gate certification records for the current production model version confirming InjectionResistanceScore at or above the 90% threshold at time of release across all probe categories", "evidence_type": "certification", "verification": "third-party" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.7 (MEASURE function) provides that AI system security and resilience are evaluated and documented. BH-06\u2019s scheduled injection-probe runs measure prompt-injection resilience of the production endpoint, extending security evaluation into operation." }, { "control": "apeiris://security/controls/AS-01", "id": "AS-01", "domain": "security", "name": "Adversarially red-team and evaluate the agent before launch", "validation_objective": "Before any deployment to production, the agent must have passed a structured adversarial red-team exercise covering multi-turn goal hijack, tool misuse, and data exfiltration scenarios, with measured attack-success-rates at or below the defined launch threshold. Deployment must be blocked until the red-team pass/fail gate is cleared and documented.", "blocking_effect": "blocks-deployment", "evidence_required": [ "pre_launch_red_team_report listing each scenario (multi-turn hijack, tool-misuse, exfiltration), the attack-success-rate per scenario, the defined launch threshold, and a signed go/no-go decision", "multi_turn_eval_suite_run_log showing the agentic benchmark used (e.g., AgentDojo, FinBot CTF), commit SHA, run date, and overall pass/fail outcome against the threshold", "red_team_scope_document confirming coverage of multi-turn drift scenarios not only single-prompt tests, signed before the red-team exercise begins", "launch_gate_approval_record linking the red-team report to the deployment decision with approver identity and timestamp" ], "evidence": [ { "id": "AS-01-E1", "description": "pre_launch_red_team_report listing each scenario (multi-turn hijack, tool-misuse, exfiltration), the attack-success-rate per scenario, the defined launch threshold, and a signed go/no-go decision", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AS-01-E2", "description": "multi_turn_eval_suite_run_log showing the agentic benchmark used (e.g., AgentDojo, FinBot CTF), commit SHA, run date, and overall pass/fail outcome against the threshold", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "AS-01-E3", "description": "red_team_scope_document confirming coverage of multi-turn drift scenarios not only single-prompt tests, signed before the red-team exercise begins", "evidence_type": "red-team-report", "verification": "third-party" }, { "id": "AS-01-E4", "description": "launch_gate_approval_record linking the red-team report to the deployment decision with approver identity and timestamp", "evidence_type": "red-team-report", "verification": "third-party" } ], "fit": "adjacent", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF Measure function: analyse, assess, benchmark, and monitor the AI risks and impacts. \"Adversarially red-team and evaluate the agent before launch\" is a corresponding measurement and monitoring activity." } ] }, { "requirement_id": "MEASURE-2.5", "section": "MEASURE 2.5", "title": "Likelihood that AI outputs meet relevant criteria evaluated", "text": "The likelihood that AI system outputs will meet established criteria for accuracy, quality, and intended purpose is evaluated.", "verdict": "supported", "coverage": "direct", "notes": "EV-02 evaluates fitness, safety, reliability, and policy conformance; BH-01 detects output anomalies in production; AB-04 enforces output policy enforcement at the agentic layer.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/EV-02", "id": "EV-02", "domain": "model", "name": "Fitness, Safety, Reliability and Policy-Conformance Evaluation", "validation_objective": "Before deployment, every model has been evaluated against pre-specified, dimension-level pass/fail thresholds \u2014 fitness, safety, reliability, and policy-conformance \u2014 with results documented against the model artifact hash and evaluation suite version. No threshold is modified after evaluation begins, and any threshold trade-off decision is documented as a named risk-acceptance record before the deployment manifest is signed.", "blocking_effect": "blocks-deployment", "evidence_required": [ "pre_specified_evaluation_protocol with model_artifact_hash, evaluation_suite_version, and per-dimension thresholds (fitness accuracy target, safety refusal rate, reliability error budget, policy-conformance violation rate), signed by the evaluation lead before testing begins \u2014 not after results are known", "dimension_level_evaluation_results showing per-dimension metric values, pass/fail verdict against pre-specified threshold, and model_artifact_hash confirming results correspond to the evaluated version", "evaluation_suite_provenance_record confirming that evaluation datasets are disjoint from training data, with contamination-check reference to TG-05 attestation", "risk_acceptance_record for any dimension where the pass threshold was not met but deployment was authorized, documenting named risk-accepter, specific capability gap, deployment risk consequence, and remediation deadline" ], "evidence": [ { "id": "EV-02-E1", "description": "pre_specified_evaluation_protocol with model_artifact_hash, evaluation_suite_version, and per-dimension thresholds (fitness accuracy target, safety refusal rate, reliability error budget, policy-conformance violation rate), signed by the evaluation lead before testing begins \u2014 not after results are known", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-02-E2", "description": "dimension_level_evaluation_results showing per-dimension metric values, pass/fail verdict against pre-specified threshold, and model_artifact_hash confirming results correspond to the evaluated version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-02-E3", "description": "evaluation_suite_provenance_record confirming that evaluation datasets are disjoint from training data, with contamination-check reference to TG-05 attestation", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-02-E4", "description": "risk_acceptance_record for any dimension where the pass threshold was not met but deployment was authorized, documenting named risk-accepter, specific capability gap, deployment risk consequence, and remediation deadline", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.3 (MEASURE function) provides that AI system performance or assurance criteria are measured and demonstrated for conditions similar to deployment. EV-02\u2019s fitness, safety, reliability, and policy-conformance dimensions measure and demonstrate the system\u2019s assurance criteria before deployment." }, { "control": "apeiris://model/controls/BH-01", "id": "BH-01", "domain": "model", "name": "Output Anomaly Detection", "validation_objective": "The production inference endpoint must be continuously sampled and output distributions must be statistically compared against a versioned, SHA-256-signed baseline artifact using PSI and Shewhart/EWMA control chart methods, such that any distribution shift exceeding PSI 0.2 fires a tiered alert within one monitoring window of the shift occurring and all anomaly events are stored in the evidence registry with BH-01 control linkage.", "blocking_effect": "advisory", "evidence_required": [ "versioned, SHA-256-signed baseline distribution artifact stored in the model registry with per-metric statistics (mean, std_dev, p5/p50/p95/p99) computed from the 30-day post-deployment stable window", "SPC alert log for trailing 90 days with fields: alert_id, trigger_metric, psi_value, alert_severity, triggered_at, acknowledged_at, and resolution_outcome", "PII masking audit record confirming no direct identifier fields (email, SSN, full name) appear in the sampled output storage for the trailing 30 days", "quarterly threshold review sign-off from model owner confirming PSI alert (0.2) and critical (0.25) thresholds remain appropriate for the current deployment context" ], "evidence": [ { "id": "BH-01-E1", "description": "versioned, SHA-256-signed baseline distribution artifact stored in the model registry with per-metric statistics (mean, std_dev, p5/p50/p95/p99) computed from the 30-day post-deployment stable window", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-01-E2", "description": "SPC alert log for trailing 90 days with fields: alert_id, trigger_metric, psi_value, alert_severity, triggered_at, acknowledged_at, and resolution_outcome", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "BH-01-E3", "description": "PII masking audit record confirming no direct identifier fields (email, SSN, full name) appear in the sampled output storage for the trailing 30 days", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-01-E4", "description": "quarterly threshold review sign-off from model owner confirming PSI alert (0.2) and critical (0.25) thresholds remain appropriate for the current deployment context", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.4 (MEASURE function) provides that the functionality and behavior of the AI system and its components are monitored when in production. BH-01\u2019s statistical process control over output distributions is production monitoring of system behavior, with signed baselines and tiered alerting." }, { "control": "apeiris://agentic/controls/AB-04", "id": "AB-04", "domain": "agentic", "name": "Output Policy Enforcement", "validation_objective": "Prove that all agent outputs \u2014 text responses, generated content, data extracts, and API payloads \u2014 pass through an enforcement layer that applies content filtering, PII detection and scrubbing, sensitive data classification checks, and output sanitization before delivery to any downstream consumer, and that this enforcement layer operates independently of the agent's model logic.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "Output policy enforcement configuration showing active content filter rules, PII detection patterns (covering at least five entity types), and sensitive data classification thresholds", "Enforcement log from the test period showing output policy evaluations including scrub events, redaction events, and block events with content hashes", "PII detection test results confirming detection of at least five PII entity types (e.g., SSN, email, phone, credit card, health identifier) against labeled test output samples", "Architecture diagram or deployment evidence confirming the enforcement layer runs on a separate runtime path from the agent model process" ], "evidence": [ { "id": "AB-04-E1", "description": "Output policy enforcement configuration showing active content filter rules, PII detection patterns (covering at least five entity types), and sensitive data classification thresholds", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "AB-04-E2", "description": "Enforcement log from the test period showing output policy evaluations including scrub events, redaction events, and block events with content hashes", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AB-04-E3", "description": "PII detection test results confirming detection of at least five PII entity types (e.g., SSN, email, phone, credit card, health identifier) against labeled test output samples", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "AB-04-E4", "description": "Architecture diagram or deployment evidence confirming the enforcement layer runs on a separate runtime path from the agent model process", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "MEASURE-2.6", "section": "MEASURE 2.6", "title": "AI system performance evaluated across demographic groups", "text": "The AI system is evaluated for performance differences across relevant demographic groups.", "verdict": "supported", "coverage": "direct", "notes": "EV-05 requires fairness and bias evaluation across groups; FA-06 mandates disparate impact analysis; FM-06 monitors AI performance divergence by demographic group in production.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/EV-05", "id": "EV-05", "domain": "model", "name": "Fairness and Bias Evaluation", "validation_objective": "The model system has a documented, pre-specified fairness evaluation protocol executed on data disjoint from training data, with disaggregated results per population group and harm type measured against pre-specified acceptance thresholds, and legal review obtained for any deployment affecting legally protected characteristics.", "blocking_effect": "blocks-deployment", "evidence_required": [ "fairness_evaluation_protocol document with pre-specified population_groups, harm_types, metric_selections, selection_rationale, legal_basis, and acceptance_thresholds \u2014 version-controlled and signed before any evaluation run begins", "disaggregated_evaluation_results report showing per-group performance metrics independently for each identified population group, with group_id, sample_count, and metric_values per harm type", "metric_tradeoff_decision_record explicitly stating which competing fairness constraints (e.g., demographic parity vs. equalized odds) take precedence for this deployment context and the documented rationale", "evaluation_data_disjointness_attestation confirming evaluation data for each population group does not overlap with the training corpus, with data_source_ids and overlap_check_method documented", "legal_review_record for any deployment affecting legally protected characteristics, with reviewing_authority identity and review_date" ], "evidence": [ { "id": "EV-05-E1", "description": "fairness_evaluation_protocol document with pre-specified population_groups, harm_types, metric_selections, selection_rationale, legal_basis, and acceptance_thresholds \u2014 version-controlled and signed before any evaluation run begins", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-05-E2", "description": "disaggregated_evaluation_results report showing per-group performance metrics independently for each identified population group, with group_id, sample_count, and metric_values per harm type", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-05-E3", "description": "metric_tradeoff_decision_record explicitly stating which competing fairness constraints (e.g., demographic parity vs. equalized odds) take precedence for this deployment context and the documented rationale", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-05-E4", "description": "evaluation_data_disjointness_attestation confirming evaluation data for each population group does not overlap with the training corpus, with data_source_ids and overlap_check_method documented", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-05-E5", "description": "legal_review_record for any deployment affecting legally protected characteristics, with reviewing_authority identity and review_date", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.11 (MEASURE function) provides that fairness and bias are evaluated and results are documented. EV-05\u2019s disaggregated error-rate measurement across protected subgroups produces the documented fairness and bias evaluation this subcategory requires." }, { "control": "apeiris://ethics/controls/FA-06", "id": "FA-06", "domain": "ethics", "name": "Disparate Impact Analysis", "validation_objective": "Every AI system subject to fairness requirements must have a completed statistical disparate impact analysis that disaggregates decision outcomes by each protected characteristic in the FA-01 register using the metrics selected in FA-03, includes intersectional subgroup analysis, applies multiple comparisons correction, and documents a threshold sensitivity analysis to confirm findings are not threshold-specific.", "blocking_effect": "blocks-deployment", "evidence_required": [ "disparate_impact_analysis_report with adverse_impact_ratio computed per protected characteristic and per intersectional subgroup, using selected fairness metrics with statistical significance testing and multiple comparisons correction applied", "disaggregated_outcome_dataset showing predicted decision rates per demographic group with confidence intervals and group sample sizes", "four_fifths_rule_analysis_record for employment and credit contexts showing selection rate ratios by protected characteristic relative to the most-favored group", "intersectional_subgroup_analysis_report confirming that pairwise combinations of protected characteristics were evaluated for all subgroups with sample size \u2265 30", "threshold_sensitivity_analysis documenting outcome disparity ratios tested across a range of decision thresholds to verify findings are not an artifact of a single threshold value" ], "evidence": [ { "id": "FA-06-E1", "description": "disparate_impact_analysis_report with adverse_impact_ratio computed per protected characteristic and per intersectional subgroup, using selected fairness metrics with statistical significance testing and multiple comparisons correction applied", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-06-E2", "description": "disaggregated_outcome_dataset showing predicted decision rates per demographic group with confidence intervals and group sample sizes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-06-E3", "description": "four_fifths_rule_analysis_record for employment and credit contexts showing selection rate ratios by protected characteristic relative to the most-favored group", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-06-E4", "description": "intersectional_subgroup_analysis_report confirming that pairwise combinations of protected characteristics were evaluated for all subgroups with sample size \u2265 30", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-06-E5", "description": "threshold_sensitivity_analysis documenting outcome disparity ratios tested across a range of decision thresholds to verify findings are not an artifact of a single threshold value", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE 2.11 requires that fairness and bias are evaluated and results demonstrated, which entails quantitative measurement disaggregated by demographic group. The four-fifths rule analysis and significance testing required by this control directly satisfy the quantitative measurement requirement." }, { "control": "apeiris://ethics/controls/FM-06", "id": "FM-06", "domain": "ethics", "name": "AI Performance Divergence by Demographic Group", "validation_objective": "Performance metrics for every in-scope AI system must be computed and stored separately for each relevant demographic subgroup on the defined monitoring schedule, with alerts configured to trigger when the gap between the best-performing and worst-performing subgroup exceeds the defined tolerance for any metric. The control passes if no AI system's monitoring records contain only aggregate performance metrics, and all performance gap alerts have corresponding fairness incident records.", "blocking_effect": "advisory", "evidence_required": [ "Disaggregated performance metric records for each AI system showing per-subgroup values for all relevant metrics with sample counts and 95% confidence intervals per subgroup", "Demographic coverage configuration showing which dimensions are tracked per system, with documented rationale for any dimension excluded despite relevance to the decision context", "Performance gap alert history for the trailing monitoring period showing all events where between-group gaps exceeded defined thresholds, with timestamps, gap magnitude, and linked incident records", "Subgroup sample size monitoring records showing minimum sample size threshold compliance alerts for each demographic dimension, preventing statistically invalid metric computation", "Fairness metric time-series showing per-subgroup performance trends over at least the trailing 6 monitoring cycles to detect gradual divergence" ], "evidence": [ { "id": "FM-06-E1", "description": "Disaggregated performance metric records for each AI system showing per-subgroup values for all relevant metrics with sample counts and 95% confidence intervals per subgroup", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FM-06-E2", "description": "Demographic coverage configuration showing which dimensions are tracked per system, with documented rationale for any dimension excluded despite relevance to the decision context", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "FM-06-E3", "description": "Performance gap alert history for the trailing monitoring period showing all events where between-group gaps exceeded defined thresholds, with timestamps, gap magnitude, and linked incident records", "evidence_type": "incident-record", "verification": "attested" }, { "id": "FM-06-E4", "description": "Subgroup sample size monitoring records showing minimum sample size threshold compliance alerts for each demographic dimension, preventing statistically invalid metric computation", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "FM-06-E5", "description": "Fairness metric time-series showing per-subgroup performance trends over at least the trailing 6 monitoring cycles to detect gradual divergence", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE 2.3 requires that AI system performance be evaluated across relevant demographic subgroups, not only at the aggregate level. This control directly implements that measurement requirement by defining a systematic disaggregated performance monitoring protocol for production systems. NIST explicitly notes that aggregate performance metrics can mask significant subgroup-level failures, making disaggregated evaluation essential for trustworthy AI." } ] }, { "requirement_id": "MEASURE-2.7", "section": "MEASURE 2.7", "title": "AI system performance metrics established and documented", "text": "AI system performance metrics are identified, established, and documented prior to deployment.", "verdict": "supported", "coverage": "direct", "notes": "EV-10 ensures evaluation result provenance; AG-06 defines agent program metrics and KPIs; EG-07 measures ethics program effectiveness \u2014 providing multi-domain metric documentation.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/EV-10", "id": "EV-10", "domain": "model", "name": "Evaluation Result Provenance", "validation_objective": "Every evaluation result artifact is SHA-256 content-addressed, cryptographically signed with individually attributed non-repudiable key material, submitted to an append-only tamper-evident log with a recorded inclusion proof, and linked to the model artifact hash and evaluation suite hash such that the complete chain from model artifact to deployment decision is machine-verifiable; the deployment gate rejects any manifest where inclusion proof verification fails.", "blocking_effect": "blocks-deployment", "evidence_required": [ "signed_content_addressed_evaluation_result_artifacts for each run containing model_artifact_hash, eval_suite_id, eval_suite_version, eval_suite_hash, run_timestamp, environment_fingerprint, per_dimension_results, gate_determination, and signer_identity with key_identifier", "tamper_evident_log_inclusion_proofs for each signed evaluation result submission, with log_entry_id and inclusion_proof_bytes sufficient for independent verification", "provenance_chain_traversal_records demonstrating machine-verifiable linkage from model_artifact_hash through evaluation_result to deployment_manifest for each production model version", "signing_key_attribution_records mapping each signer_identity in evaluation artifacts to a named individual via PKI certificate or directory lookup, confirming no shared or service-account signing credentials were used", "retention_compliance_records confirming signed artifacts and inclusion proofs remain available for the required period covering the operational model lifetime plus the applicable regulatory minimum per jurisdiction" ], "evidence": [ { "id": "EV-10-E1", "description": "signed_content_addressed_evaluation_result_artifacts for each run containing model_artifact_hash, eval_suite_id, eval_suite_version, eval_suite_hash, run_timestamp, environment_fingerprint, per_dimension_results, gate_determination, and signer_identity with key_identifier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-10-E2", "description": "tamper_evident_log_inclusion_proofs for each signed evaluation result submission, with log_entry_id and inclusion_proof_bytes sufficient for independent verification", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-10-E3", "description": "provenance_chain_traversal_records demonstrating machine-verifiable linkage from model_artifact_hash through evaluation_result to deployment_manifest for each production model version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-10-E4", "description": "signing_key_attribution_records mapping each signer_identity in evaluation artifacts to a named individual via PKI certificate or directory lookup, confirming no shared or service-account signing credentials were used", "evidence_type": "certification", "verification": "third-party" }, { "id": "EV-10-E5", "description": "retention_compliance_records confirming signed artifacts and inclusion proofs remain available for the required period covering the operational model lifetime plus the applicable regulatory minimum per jurisdiction", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.1 (MEASURE function) provides that test sets, metrics, and details about the tools used during TEVV are documented. EV-10\u2019s content-addressed, signed evaluation records preserve the test sets, metrics, and tool details this subcategory requires as tamper-evident documentation." }, { "control": "apeiris://agentic/controls/AG-06", "id": "AG-06", "domain": "agentic", "name": "Agent Program Metrics and KPIs", "validation_objective": "The enterprise collects and reports a defined set of agentic AI governance KPIs from automated pipelines on a defined frequency, and the governance committee receives current-period metric values with trend data and threshold breach alerts at each governance review meeting.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Published Agentic AI Program Metrics Catalog defining each KPI: name, formula, data source, reporting frequency, metric owner, and target threshold with current baseline", "Automated governance dashboard outputs from at least the three most recent reporting periods showing coverage, process, outcome, and attestation metrics", "Governance committee meeting records confirming receipt and review of metrics reports and documenting threshold breach discussions and directed actions", "Data pipeline lineage documentation showing the authoritative source for each KPI and the automated collection process" ], "evidence": [ { "id": "AG-06-E1", "description": "Published Agentic AI Program Metrics Catalog defining each KPI: name, formula, data source, reporting frequency, metric owner, and target threshold with current baseline", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-06-E2", "description": "Automated governance dashboard outputs from at least the three most recent reporting periods showing coverage, process, outcome, and attestation metrics", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "AG-06-E3", "description": "Governance committee meeting records confirming receipt and review of metrics reports and documenting threshold breach discussions and directed actions", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AG-06-E4", "description": "Data pipeline lineage documentation showing the authoritative source for each KPI and the automated collection process", "evidence_type": "data-lineage-record", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE 1.1 requires approaches and metrics for AI risk measurement to be selected and implemented. A defined agentic program metrics catalog with coverage, incident, and drift KPIs is that selection, made explicit and reviewable." }, { "control": "apeiris://ethics/controls/EG-07", "id": "EG-07", "domain": "ethics", "name": "Ethics Program Metrics and Effectiveness Measurement", "validation_objective": "The organization must maintain an active ethics metrics portfolio containing a minimum of three leading indicators and three lagging indicators across governance, process, and outcome dimensions, with documented collection methodology, quarterly Ethics Board reporting, and traceable action items for any metric below defined threshold. At least one outcome metric must measure system-level ethical performance such as bias finding rate or ethics incident rate.", "blocking_effect": "advisory", "evidence_required": [ "ethics_metrics_portfolio_document defining each metric with name, type (leading/lagging), dimension (governance/process/outcome), collection source, target value, threshold, and reporting cadence", "quarterly_ethics_metrics_dashboard_reports for trailing 12 months showing metric values, trend indicators, threshold alert status, and action items for below-threshold metrics", "action_item_tracking_records linking below-threshold metrics to specific corrective actions with owner, deadline, and closure evidence demonstrating that metrics reviews drive program adjustments", "annual_ethics_effectiveness_report submitted to executive leadership and the Ethics Board with program-level assessment against stated ethics objectives" ], "evidence": [ { "id": "EG-07-E1", "description": "ethics_metrics_portfolio_document defining each metric with name, type (leading/lagging), dimension (governance/process/outcome), collection source, target value, threshold, and reporting cadence", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-07-E2", "description": "quarterly_ethics_metrics_dashboard_reports for trailing 12 months showing metric values, trend indicators, threshold alert status, and action items for below-threshold metrics", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "EG-07-E3", "description": "action_item_tracking_records linking below-threshold metrics to specific corrective actions with owner, deadline, and closure evidence demonstrating that metrics reviews drive program adjustments", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-07-E4", "description": "annual_ethics_effectiveness_report submitted to executive leadership and the Ethics Board with program-level assessment against stated ethics objectives", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE 2.1 requires that AI risk metrics and monitoring approaches are defined and implemented. This control implements the MEASURE function requirement for a structured portfolio of ethics and risk metrics with defined collection and reporting processes." } ] }, { "requirement_id": "MEASURE-2.8", "section": "MEASURE 2.8", "title": "AI system evaluated for accuracy and reliability", "text": "AI system is evaluated for accuracy, reliability, and consistency of outputs.", "verdict": "supported", "coverage": "direct", "notes": "EV-02 evaluates fitness, safety, and reliability pre-deployment; BH-03 alerts on production performance degradation; CR-03 schedules model re-validation to maintain accuracy over time.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/EV-02", "id": "EV-02", "domain": "model", "name": "Fitness, Safety, Reliability and Policy-Conformance Evaluation", "validation_objective": "Before deployment, every model has been evaluated against pre-specified, dimension-level pass/fail thresholds \u2014 fitness, safety, reliability, and policy-conformance \u2014 with results documented against the model artifact hash and evaluation suite version. No threshold is modified after evaluation begins, and any threshold trade-off decision is documented as a named risk-acceptance record before the deployment manifest is signed.", "blocking_effect": "blocks-deployment", "evidence_required": [ "pre_specified_evaluation_protocol with model_artifact_hash, evaluation_suite_version, and per-dimension thresholds (fitness accuracy target, safety refusal rate, reliability error budget, policy-conformance violation rate), signed by the evaluation lead before testing begins \u2014 not after results are known", "dimension_level_evaluation_results showing per-dimension metric values, pass/fail verdict against pre-specified threshold, and model_artifact_hash confirming results correspond to the evaluated version", "evaluation_suite_provenance_record confirming that evaluation datasets are disjoint from training data, with contamination-check reference to TG-05 attestation", "risk_acceptance_record for any dimension where the pass threshold was not met but deployment was authorized, documenting named risk-accepter, specific capability gap, deployment risk consequence, and remediation deadline" ], "evidence": [ { "id": "EV-02-E1", "description": "pre_specified_evaluation_protocol with model_artifact_hash, evaluation_suite_version, and per-dimension thresholds (fitness accuracy target, safety refusal rate, reliability error budget, policy-conformance violation rate), signed by the evaluation lead before testing begins \u2014 not after results are known", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-02-E2", "description": "dimension_level_evaluation_results showing per-dimension metric values, pass/fail verdict against pre-specified threshold, and model_artifact_hash confirming results correspond to the evaluated version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-02-E3", "description": "evaluation_suite_provenance_record confirming that evaluation datasets are disjoint from training data, with contamination-check reference to TG-05 attestation", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-02-E4", "description": "risk_acceptance_record for any dimension where the pass threshold was not met but deployment was authorized, documenting named risk-accepter, specific capability gap, deployment risk consequence, and remediation deadline", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.3 (MEASURE function) provides that AI system performance or assurance criteria are measured and demonstrated for conditions similar to deployment. EV-02\u2019s fitness, safety, reliability, and policy-conformance dimensions measure and demonstrate the system\u2019s assurance criteria before deployment." }, { "control": "apeiris://model/controls/BH-03", "id": "BH-03", "domain": "model", "name": "Production Performance Degradation Alerting", "validation_objective": "Every production model version must have a corresponding signed EvaluationBaseline artifact containing primary task metrics and subgroup slice metrics from the release evaluation gate; the metrics aggregation service must continuously compare production estimates against this baseline and fire tiered alerts when primary metrics regress 5% (warning) or 10% (critical) from the signed baseline values, including independent subgroup regression alerts.", "blocking_effect": "advisory", "evidence_required": [ "signed EvaluationBaseline artifact for the current production model version containing model_id, version, eval_date, primary_metrics with confidence intervals, subgroup slice metrics, eval_dataset_hash, and artifact SHA-256", "performance alert log for trailing 90 days with fields: alert_id, metric_name, regression_pct, severity, triggered_at, acknowledged_at, root_cause, and remediation_action for each alert", "quarterly threshold review sign-off from model owner confirming 5%/10% regression thresholds remain appropriate for the current model type and deployment context", "proxy_metric_registry documenting which proxy metrics substitute for labeled ground truth when unavailable, including calibration methodology and documented limitations" ], "evidence": [ { "id": "BH-03-E1", "description": "signed EvaluationBaseline artifact for the current production model version containing model_id, version, eval_date, primary_metrics with confidence intervals, subgroup slice metrics, eval_dataset_hash, and artifact SHA-256", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-03-E2", "description": "performance alert log for trailing 90 days with fields: alert_id, metric_name, regression_pct, severity, triggered_at, acknowledged_at, root_cause, and remediation_action for each alert", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "BH-03-E3", "description": "quarterly threshold review sign-off from model owner confirming 5%/10% regression thresholds remain appropriate for the current model type and deployment context", "evidence_type": "human-review-record", "verification": "human" }, { "id": "BH-03-E4", "description": "proxy_metric_registry documenting which proxy metrics substitute for labeled ground truth when unavailable, including calibration methodology and documented limitations", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.4 (MEASURE function) provides that the functionality and behavior of the AI system and its components are monitored when in production. BH-03\u2019s regression alerting monitors production performance against a signed EvaluationBaseline, satisfying the production-monitoring expectation for performance." }, { "control": "apeiris://model/controls/CR-03", "id": "CR-03", "domain": "model", "name": "Scheduled Model Re-validation", "validation_objective": "A full benchmark, bias, and safety evaluation suite must execute against every production model version on the defined re-validation schedule; results must be compared to the deployment-time baseline metrics, and any performance degradation beyond configured thresholds must trigger a formal response documented and initiated before the next operational window closes.", "blocking_effect": "blocks-deployment", "evidence_required": [ "re_validation_schedule_record per model version showing configured re-validation frequency, last_run_timestamp, next_run_due, and scheduled_suite_identifier with no unmonitored production versions", "scheduled_evaluation_report for each re-validation run showing benchmark results, bias metrics, and safety evaluation scores with explicit comparison to the deployment-time baseline", "threshold_comparison_record showing the delta between current re-validation results and baseline for each metric with a pass/fail determination against the configured degradation threshold", "re_validation_response_record for any threshold breach, documenting the triggered response action (rollback, retraining, or escalation), responsible_party, and closure_timestamp", "re_validation_coverage_audit confirming all active production model versions are enrolled in re-validation schedules and that no version has exceeded its next_run_due without a completed run" ], "evidence": [ { "id": "CR-03-E1", "description": "re_validation_schedule_record per model version showing configured re-validation frequency, last_run_timestamp, next_run_due, and scheduled_suite_identifier with no unmonitored production versions", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-03-E2", "description": "scheduled_evaluation_report for each re-validation run showing benchmark results, bias metrics, and safety evaluation scores with explicit comparison to the deployment-time baseline", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "CR-03-E3", "description": "threshold_comparison_record showing the delta between current re-validation results and baseline for each metric with a pass/fail determination against the configured degradation threshold", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-03-E4", "description": "re_validation_response_record for any threshold breach, documenting the triggered response action (rollback, retraining, or escalation), responsible_party, and closure_timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-03-E5", "description": "re_validation_coverage_audit confirming all active production model versions are enrolled in re-validation schedules and that no version has exceeded its next_run_due without a completed run", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.6 (MEASURE function) provides that the AI system is evaluated regularly for safety risks, demonstrated to be safe within risk tolerance, and able to fail safely. CR-03\u2019s scheduled re-validation re-runs the safety and evaluation suites on a defined cadence, keeping the regular safety evaluation this subcategory requires current." } ] }, { "requirement_id": "MEASURE-2.9", "section": "MEASURE 2.9", "title": "Privacy risks of AI system evaluated", "text": "Privacy risks of the AI system are evaluated, including risks of re-identification, data inference, and training data exposure.", "verdict": "partial", "coverage": "partial", "notes": "TG-06 requires sensitive-data minimization and controlled use; EV-09 covers risk classification. Full privacy risk evaluation (re-identification, membership inference attacks) is primarily addressed by the Apeiris Privacy domain (privacyverifier.ai) which is not included in this mapping scope.", "control_count": 2, "proof_chain": [ { "control": "apeiris://model/controls/TG-06", "id": "TG-06", "domain": "model", "name": "Sensitive-Data Necessity, Minimization and Controlled Use", "validation_objective": "Every training dataset containing PII or protected-class attributes has a documented necessity assessment with named approver sign-off confirming that the data cannot be substituted with de-identified or synthetic alternatives. When protected attributes are retained for bias auditing, they are stored exclusively in a separately access-controlled fairness audit vault \u2014 not in the general training corpus \u2014 with time-bounded, logged access for each session.", "blocking_effect": "blocks-deployment", "evidence_required": [ "data_necessity_assessment_record with dataset_id, PII categories identified (name/email/SSN/biometric/protected-class), justification for necessity over de-identified alternatives, and approver_identity with approval_timestamp", "PII_scan_run_log showing scanner tool, dataset version, detection count per PII category, and remediation action per detected item (de-identified / synthetic-replaced / retained-in-fairness-vault)", "fairness_audit_vault_access_log for the retention window, listing accessor_identity, purpose, authorization_record_id, and session_duration for every vault access", "synthetic_data_provenance_record for any PII replaced with synthetic proxies, confirming generation method and confirming synthetic records cannot be re-linked to real individuals via quasi-identifiers" ], "evidence": [ { "id": "TG-06-E1", "description": "data_necessity_assessment_record with dataset_id, PII categories identified (name/email/SSN/biometric/protected-class), justification for necessity over de-identified alternatives, and approver_identity with approval_timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-06-E2", "description": "PII_scan_run_log showing scanner tool, dataset version, detection count per PII category, and remediation action per detected item (de-identified / synthetic-replaced / retained-in-fairness-vault)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-06-E3", "description": "fairness_audit_vault_access_log for the retention window, listing accessor_identity, purpose, authorization_record_id, and session_duration for every vault access", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-06-E4", "description": "synthetic_data_provenance_record for any PII replaced with synthetic proxies, confirming generation method and confirming synthetic records cannot be re-linked to real individuals via quasi-identifiers", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.10 (MEASURE function) provides that privacy risk of the AI system is examined and documented. TG-06\u2019s sensitive-data necessity assessment and minimization controls examine and reduce the privacy risk carried into the model through training data." }, { "control": "apeiris://model/controls/EV-09", "id": "EV-09", "domain": "model", "name": "Risk and Applicability Classification", "validation_objective": "Every model system has a signed classification record produced before any evaluation work begins, containing a documented EU AI Act classification with provision-specific rationale referencing Articles 5, 6, 50, 51, and Annex III as applicable, an SR 26-2 model risk tier for in-scope institutions, a capability tier, and the full applicable Apeiris profiles list; the model registry gate prevents advancement to evaluation stage without this record; and re-classification is triggered on any significant change to use case, capability level, or applicable regulation.", "blocking_effect": "blocks-deployment", "evidence_required": [ "signed_classification_record containing eu_ai_act_classification with specific provision references, sr_262_tier where applicable, capability_tier, applicable_profiles list, mandatory_controls inventory, and obligations_inventory \u2014 produced before any evaluation artifact is created", "classification_questionnaire_responses document answering all required dimensions: intended_use_cases, affected_populations, decision_automation_level, human_oversight_mechanisms, deployment_jurisdiction, compute_budget, parameter_count", "non_high_risk_exclusion_rationale for systems classified below high-risk, explicitly addressing each relevant Annex III category with documented rationale for exclusion", "classification_review_records for all re-classification events documenting trigger_event, prior_classification, new_classification, and rationale with effective_date", "iso_42005_impact_assessment for high-impact-decision and eu-high-risk profile systems per ISO/IEC 42005:2025" ], "evidence": [ { "id": "EV-09-E1", "description": "signed_classification_record containing eu_ai_act_classification with specific provision references, sr_262_tier where applicable, capability_tier, applicable_profiles list, mandatory_controls inventory, and obligations_inventory \u2014 produced before any evaluation artifact is created", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-09-E2", "description": "classification_questionnaire_responses document answering all required dimensions: intended_use_cases, affected_populations, decision_automation_level, human_oversight_mechanisms, deployment_jurisdiction, compute_budget, parameter_count", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E3", "description": "non_high_risk_exclusion_rationale for systems classified below high-risk, explicitly addressing each relevant Annex III category with documented rationale for exclusion", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E4", "description": "classification_review_records for all re-classification events documenting trigger_event, prior_classification, new_classification, and rationale with effective_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E5", "description": "iso_42005_impact_assessment for high-impact-decision and eu-high-risk profile systems per ISO/IEC 42005:2025", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP-1.5 (MAP function) provides that organizational risk tolerances are determined and documented. EV-09\u2019s risk and applicability classification turns documented risk tolerances into a per-system determination of which controls and obligations apply." } ] }, { "requirement_id": "MEASURE-2.10", "section": "MEASURE 2.10", "title": "Privacy risk findings documented", "text": "Privacy risk findings are documented and used to inform updates to the risk register and development practices.", "verdict": "partial", "coverage": "partial", "notes": "TG-06 captures sensitive-data governance findings; CR-02 provides the model evidence archive and audit trail for risk documentation. Full privacy risk register integration is in the Apeiris Privacy domain, outside this mapping scope.", "control_count": 2, "proof_chain": [ { "control": "apeiris://model/controls/TG-06", "id": "TG-06", "domain": "model", "name": "Sensitive-Data Necessity, Minimization and Controlled Use", "validation_objective": "Every training dataset containing PII or protected-class attributes has a documented necessity assessment with named approver sign-off confirming that the data cannot be substituted with de-identified or synthetic alternatives. When protected attributes are retained for bias auditing, they are stored exclusively in a separately access-controlled fairness audit vault \u2014 not in the general training corpus \u2014 with time-bounded, logged access for each session.", "blocking_effect": "blocks-deployment", "evidence_required": [ "data_necessity_assessment_record with dataset_id, PII categories identified (name/email/SSN/biometric/protected-class), justification for necessity over de-identified alternatives, and approver_identity with approval_timestamp", "PII_scan_run_log showing scanner tool, dataset version, detection count per PII category, and remediation action per detected item (de-identified / synthetic-replaced / retained-in-fairness-vault)", "fairness_audit_vault_access_log for the retention window, listing accessor_identity, purpose, authorization_record_id, and session_duration for every vault access", "synthetic_data_provenance_record for any PII replaced with synthetic proxies, confirming generation method and confirming synthetic records cannot be re-linked to real individuals via quasi-identifiers" ], "evidence": [ { "id": "TG-06-E1", "description": "data_necessity_assessment_record with dataset_id, PII categories identified (name/email/SSN/biometric/protected-class), justification for necessity over de-identified alternatives, and approver_identity with approval_timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-06-E2", "description": "PII_scan_run_log showing scanner tool, dataset version, detection count per PII category, and remediation action per detected item (de-identified / synthetic-replaced / retained-in-fairness-vault)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-06-E3", "description": "fairness_audit_vault_access_log for the retention window, listing accessor_identity, purpose, authorization_record_id, and session_duration for every vault access", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-06-E4", "description": "synthetic_data_provenance_record for any PII replaced with synthetic proxies, confirming generation method and confirming synthetic records cannot be re-linked to real individuals via quasi-identifiers", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.10 (MEASURE function) provides that privacy risk of the AI system is examined and documented. TG-06\u2019s sensitive-data necessity assessment and minimization controls examine and reduce the privacy risk carried into the model through training data." }, { "control": "apeiris://model/controls/CR-02", "id": "CR-02", "domain": "model", "name": "Model Evidence Archive and Audit Trail", "validation_objective": "All evaluation results, monitoring snapshots, incident records, and regulatory submissions must be stored in an immutable, content-addressed archive with cryptographic integrity protection; any audit query for a model's historical evidence must resolve to a complete, tamper-evident chain spanning the full production lifetime of that model version.", "blocking_effect": "blocks-deployment", "evidence_required": [ "archive_integrity_configuration_record showing content-addressed storage settings, hash algorithm (minimum SHA-256), write-once immutability enforcement, and retention policy duration per record type", "evidence_chain_completeness_audit confirming that evaluation results, monitoring snapshots, and incident records for each production model version are present in the archive with no missing lifecycle entries", "tamper_detection_scan_report from periodic archive integrity verification showing all stored records produce matching content hashes with zero reported mismatches", "regulatory_submission_evidence_linkage_record linking each regulatory submission to its archived evidence artifact with submission_id, submission_date, submitting_entity, and archive_content_hash", "archive_access_control_audit_log confirming write operations are restricted to authorized pipeline components only and all access attempts are logged with actor_id and timestamp" ], "evidence": [ { "id": "CR-02-E1", "description": "archive_integrity_configuration_record showing content-addressed storage settings, hash algorithm (minimum SHA-256), write-once immutability enforcement, and retention policy duration per record type", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "CR-02-E2", "description": "evidence_chain_completeness_audit confirming that evaluation results, monitoring snapshots, and incident records for each production model version are present in the archive with no missing lifecycle entries", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-02-E3", "description": "tamper_detection_scan_report from periodic archive integrity verification showing all stored records produce matching content hashes with zero reported mismatches", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-02-E4", "description": "regulatory_submission_evidence_linkage_record linking each regulatory submission to its archived evidence artifact with submission_id, submission_date, submitting_entity, and archive_content_hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-02-E5", "description": "archive_access_control_audit_log confirming write operations are restricted to authorized pipeline components only and all access attempts are logged with actor_id and timestamp", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN-1.4 (GOVERN function) provides that the risk management process and its outcomes are established through transparent policies, procedures, and controls. CR-02\u2019s immutable, content-addressed evidence archive preserves the documented outcomes of the risk management process so they remain reviewable and transparent over time." } ] }, { "requirement_id": "MEASURE-2.11", "section": "MEASURE 2.11", "title": "Fairness and bias evaluated across demographic groups", "text": "Fairness and bias, including harmful bias, in AI are evaluated across relevant demographic groups and use cases.", "verdict": "supported", "coverage": "direct", "notes": "FA-02 mandates algorithmic bias impact assessment; EV-05 requires fairness and bias evaluation pre-deployment; FM-01 monitors fairness in production \u2014 providing pre- and post-deployment coverage.", "control_count": 3, "proof_chain": [ { "control": "apeiris://ethics/controls/FA-02", "id": "FA-02", "domain": "ethics", "name": "Algorithmic Bias Impact Assessment", "validation_objective": "Every AI system subject to fairness evaluation must have a completed Algorithmic Bias Impact Assessment (ABIA) covering all protected characteristics in the FA-01 register, addressing both training data composition bias and model prediction disparities, completed before initial deployment and re-run after any material model or data change.", "blocking_effect": "blocks-deployment", "evidence_required": [ "algorithmic_bias_impact_assessment_report with per-characteristic findings, methodology description, direct discrimination and disparate impact pathways assessed, and risk rating for each finding", "training_data_composition_report showing demographic representation across protected groups relative to the reference deployment population", "model_prediction_disaggregation_report showing predicted outcome rates by protected characteristic with confidence intervals and statistical significance testing", "feedback_loop_risk_analysis documenting whether biased model outputs could influence future training data collection or labeling", "abia_reviewer_sign_off_record with reviewer credentials and date confirming independence from the model development team" ], "evidence": [ { "id": "FA-02-E1", "description": "algorithmic_bias_impact_assessment_report with per-characteristic findings, methodology description, direct discrimination and disparate impact pathways assessed, and risk rating for each finding", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E2", "description": "training_data_composition_report showing demographic representation across protected groups relative to the reference deployment population", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E3", "description": "model_prediction_disaggregation_report showing predicted outcome rates by protected characteristic with confidence intervals and statistical significance testing", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E4", "description": "feedback_loop_risk_analysis documenting whether biased model outputs could influence future training data collection or labeling", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E5", "description": "abia_reviewer_sign_off_record with reviewer credentials and date confirming independence from the model development team", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP 2.2 requires gathering scientific and empirical information about AI risks including bias and fairness risks across affected populations. The ABIA operationalizes this requirement by providing a structured empirical evaluation methodology." }, { "control": "apeiris://model/controls/EV-05", "id": "EV-05", "domain": "model", "name": "Fairness and Bias Evaluation", "validation_objective": "The model system has a documented, pre-specified fairness evaluation protocol executed on data disjoint from training data, with disaggregated results per population group and harm type measured against pre-specified acceptance thresholds, and legal review obtained for any deployment affecting legally protected characteristics.", "blocking_effect": "blocks-deployment", "evidence_required": [ "fairness_evaluation_protocol document with pre-specified population_groups, harm_types, metric_selections, selection_rationale, legal_basis, and acceptance_thresholds \u2014 version-controlled and signed before any evaluation run begins", "disaggregated_evaluation_results report showing per-group performance metrics independently for each identified population group, with group_id, sample_count, and metric_values per harm type", "metric_tradeoff_decision_record explicitly stating which competing fairness constraints (e.g., demographic parity vs. equalized odds) take precedence for this deployment context and the documented rationale", "evaluation_data_disjointness_attestation confirming evaluation data for each population group does not overlap with the training corpus, with data_source_ids and overlap_check_method documented", "legal_review_record for any deployment affecting legally protected characteristics, with reviewing_authority identity and review_date" ], "evidence": [ { "id": "EV-05-E1", "description": "fairness_evaluation_protocol document with pre-specified population_groups, harm_types, metric_selections, selection_rationale, legal_basis, and acceptance_thresholds \u2014 version-controlled and signed before any evaluation run begins", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-05-E2", "description": "disaggregated_evaluation_results report showing per-group performance metrics independently for each identified population group, with group_id, sample_count, and metric_values per harm type", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-05-E3", "description": "metric_tradeoff_decision_record explicitly stating which competing fairness constraints (e.g., demographic parity vs. equalized odds) take precedence for this deployment context and the documented rationale", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-05-E4", "description": "evaluation_data_disjointness_attestation confirming evaluation data for each population group does not overlap with the training corpus, with data_source_ids and overlap_check_method documented", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-05-E5", "description": "legal_review_record for any deployment affecting legally protected characteristics, with reviewing_authority identity and review_date", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.11 (MEASURE function) provides that fairness and bias are evaluated and results are documented. EV-05\u2019s disaggregated error-rate measurement across protected subgroups produces the documented fairness and bias evaluation this subcategory requires." }, { "control": "apeiris://ethics/controls/FM-01", "id": "FM-01", "domain": "ethics", "name": "Production Fairness Monitoring Program", "validation_objective": "Every production AI system in scope must have an active fairness monitoring configuration with a defined metric suite, baselines, and threshold values; monitoring must run on at least a daily cadence for high-risk systems; and threshold breach alerts must be acknowledged and assigned to an incident record within 24 hours. A passing state requires 100% enrollment of in-scope systems with no computation gaps exceeding 48 hours and zero unacknowledged breach alerts older than 24 hours.", "blocking_effect": "advisory", "evidence_required": [ "fairness_monitoring_configuration_record per AI system showing enrolled_at date, metric suite, threshold values, computation cadence, and stakeholder alert routing configuration", "fairness_metric_time_series export covering the past 90 days with per-run fields for computation_timestamp, metric_id, demographic_stratum, sample_size, confidence_interval, and computed_value \u2014 with no gaps exceeding 48 hours", "threshold_breach_incident_log for the past 12 months showing each alert event with alert_timestamp, metric_name, observed_value, threshold_value, acknowledged_at, and assigned_remediation_owner", "governance_review_sign_off records from the past three monthly ethics officer review meetings confirming attendance, metrics reviewed, and compliance certification" ], "evidence": [ { "id": "FM-01-E1", "description": "fairness_monitoring_configuration_record per AI system showing enrolled_at date, metric suite, threshold values, computation cadence, and stakeholder alert routing configuration", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "FM-01-E2", "description": "fairness_metric_time_series export covering the past 90 days with per-run fields for computation_timestamp, metric_id, demographic_stratum, sample_size, confidence_interval, and computed_value \u2014 with no gaps exceeding 48 hours", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "FM-01-E3", "description": "threshold_breach_incident_log for the past 12 months showing each alert event with alert_timestamp, metric_name, observed_value, threshold_value, acknowledged_at, and assigned_remediation_owner", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "FM-01-E4", "description": "governance_review_sign_off records from the past three monthly ethics officer review meetings confirming attendance, metrics reviewed, and compliance certification", "evidence_type": "certification", "verification": "third-party" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE 2.11 requires that fairness and bias are evaluated, with results demonstrated \u2014 including in deployment contexts, not only during pre-deployment testing. The production monitoring program operationalizes this requirement by establishing a continuous measurement cadence. NIST guidance recognizes that fairness properties can degrade over time due to distribution shift, making production monitoring essential." } ] }, { "requirement_id": "MEASURE-2.12", "section": "MEASURE 2.12", "title": "Environmental impact and resource consumption evaluated", "text": "Environmental impact and resource consumption of the AI system are evaluated and documented.", "verdict": "partial", "coverage": "partial", "notes": "AB-06 enforces resource budget controls; EC-05 caps spend and resource use; BH-07 monitors resource and cost anomalies. These address operational resource governance but not carbon footprint or broader environmental impact reporting \u2014 a gap in the current Apeiris control set.", "control_count": 3, "proof_chain": [ { "control": "apeiris://agentic/controls/AB-06", "id": "AB-06", "domain": "agentic", "name": "Rate Limiting and Resource Budget Enforcement", "validation_objective": "Prove that every deployed agent operates under platform-enforced per-agent limits on API call rate, token consumption, cost expenditure, and compute time \u2014 and that automated circuit-breaker behavior suspends the agent when any budget is exhausted without relying on agent-side logic as the enforcement mechanism.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Per-agent resource budget configuration showing explicit API call rate limits, token consumption caps, cost ceilings, and compute time limits stored in platform infrastructure", "Platform enforcement logs from the test period showing budget enforcement events including circuit-breaker activations, with agent identifier, limit type, and threshold crossed", "Alert configuration records showing budget threshold alerts are wired to an on-call operations response path with defined SLA", "Load test results confirming circuit-breaker behavior triggers at or within the configured thresholds under simulated overload without agent-side intervention" ], "evidence": [ { "id": "AB-06-E1", "description": "Per-agent resource budget configuration showing explicit API call rate limits, token consumption caps, cost ceilings, and compute time limits stored in platform infrastructure", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "AB-06-E2", "description": "Platform enforcement logs from the test period showing budget enforcement events including circuit-breaker activations, with agent identifier, limit type, and threshold crossed", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AB-06-E3", "description": "Alert configuration records showing budget threshold alerts are wired to an on-call operations response path with defined SLA", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "AB-06-E4", "description": "Load test results confirming circuit-breaker behavior triggers at or within the configured thresholds under simulated overload without agent-side intervention", "evidence_type": "automated-test-result", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MANAGE 2.4 requires mechanisms to supersede, disengage, or deactivate AI systems whose behavior is inconsistent with intended use. Budget exhaustion and rate-limit circuit breakers are exactly such mechanisms: they disengage an agent automatically when consumption departs from its authorized envelope." }, { "control": "apeiris://security/controls/EC-05", "id": "EC-05", "domain": "security", "name": "Cap spend and resource use, stop denial-of-wallet", "validation_objective": "Each agent task invocation must have a pre-assigned budget covering token consumption, API call count, compute time, and monetary spend enforced by a gateway or quota service outside the agent loop. On breach of any budget dimension the enforcement service must issue a hard halt \u2014 not merely a warning \u2014 and record the halt with consumed amounts, breach dimension, and timestamp. Tasks submitted without a budget policy must be rejected at intake.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "budget_policy_record showing per-agent-task limits (token_ceiling, api_call_ceiling, compute_seconds_ceiling, monetary_ceiling_usd) assigned before task start", "budget_enforcement_halt_log showing task_id, budget_dimension_breached, consumed_at_halt, limit_value, halt_type (hard-stop or warn-only), and halt_timestamp", "cost_anomaly_alert_record showing events triggered when agent spend rate exceeds baseline by the defined anomaly threshold", "gateway_quota_service_audit confirming the budget enforcement layer operates outside the agent process and cannot be modified by the agent at runtime" ], "evidence": [ { "id": "EC-05-E1", "description": "budget_policy_record showing per-agent-task limits (token_ceiling, api_call_ceiling, compute_seconds_ceiling, monetary_ceiling_usd) assigned before task start", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-05-E2", "description": "budget_enforcement_halt_log showing task_id, budget_dimension_breached, consumed_at_halt, limit_value, halt_type (hard-stop or warn-only), and halt_timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-05-E3", "description": "cost_anomaly_alert_record showing events triggered when agent spend rate exceeds baseline by the defined anomaly threshold", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-05-E4", "description": "gateway_quota_service_audit confirming the budget enforcement layer operates outside the agent process and cannot be modified by the agent at runtime", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "adjacent", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF Manage function: prioritise and act on the identified AI risks, treating, responding, recovering, and allocating resources. \"Cap spend and resource use, stop denial-of-wallet\" is a corresponding risk-treatment activity." }, { "control": "apeiris://model/controls/BH-07", "id": "BH-07", "domain": "model", "name": "Resource and Cost Anomaly Monitoring", "validation_objective": "The system must continuously monitor compute spend, token consumption, and API call volume per caller and model, with anomaly detection alerting within one operational window when any metric exceeds 2\u00d7 the rolling baseline; per-caller budget guardrails must automatically queue or block requests when the configured monthly spend cap is reached.", "blocking_effect": "advisory", "evidence_required": [ "cost_telemetry_pipeline_record showing CostEvent emission per request with caller_id, model_id, input_tokens, output_tokens, and cost_usd_estimated fields", "anomaly_detection_configuration_record showing baseline computation method (Z-score or EWMA), threshold multipliers, and evaluation window duration per caller and model", "budget_guardrail_configuration_record showing per-caller monthly spend cap, queue-activation threshold percentage, and hard-stop cap percentage for each active caller", "cost_spike_alert_log for any triggered alerts showing caller_id, time_window, observed_cost, baseline_cost, and anomaly_score with routing confirmation to MLOps on-call", "aml_t0024_correlation_record linking cost spike events to bulk inference volume patterns consistent with model extraction detection" ], "evidence": [ { "id": "BH-07-E1", "description": "cost_telemetry_pipeline_record showing CostEvent emission per request with caller_id, model_id, input_tokens, output_tokens, and cost_usd_estimated fields", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-07-E2", "description": "anomaly_detection_configuration_record showing baseline computation method (Z-score or EWMA), threshold multipliers, and evaluation window duration per caller and model", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "BH-07-E3", "description": "budget_guardrail_configuration_record showing per-caller monthly spend cap, queue-activation threshold percentage, and hard-stop cap percentage for each active caller", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-07-E4", "description": "cost_spike_alert_log for any triggered alerts showing caller_id, time_window, observed_cost, baseline_cost, and anomaly_score with routing confirmation to MLOps on-call", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "BH-07-E5", "description": "aml_t0024_correlation_record linking cost spike events to bulk inference volume patterns consistent with model extraction detection", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MANAGE-2.4 (MANAGE function) provides that mechanisms and assigned responsibilities exist to supersede, disengage, or deactivate AI systems that demonstrate performance inconsistent with intended use. BH-07\u2019s resource and cost anomaly alerts provide an early signal feeding the decision to throttle, disengage, or deactivate a model whose runtime behavior deviates from intended use." } ] }, { "requirement_id": "MEASURE-2.13", "section": "MEASURE 2.13", "title": "Effectiveness of risk controls evaluated", "text": "The effectiveness of risk controls and mitigation measures is evaluated and documented.", "verdict": "supported", "coverage": "direct", "notes": "PG-07 produces policy governance reporting including control effectiveness; EG-07 measures ethics program effectiveness; AS-03 gates releases on continuous adversarial validation to verify control efficacy.", "control_count": 3, "proof_chain": [ { "control": "apeiris://authority/controls/PG-07", "id": "PG-07", "domain": "authority", "name": "Policy Governance Reporting", "validation_objective": "Policy governance reports must be generated on the defined schedule for all audience tiers (executive management, audit committee, board), with every defined metric field populated from verified upstream data sources. Distribution logs must confirm delivery within the deadline for each audience.", "blocking_effect": "advisory", "evidence_required": [ "governance_report_package containing report templates per audience tier, populated metric fields, and data-source mappings for each reporting period", "report_distribution_log showing recipient, delivery timestamp, and report version for each scheduled and event-driven governance report", "reporting_pipeline_audit_trail confirming each metric value was sourced from the canonical upstream control system with no manual entry points", "audit_committee_submission_record confirming receipt of quarterly governance reports within the defined deadline", "event_driven_report_log showing supplemental reports triggered by material incidents above the defined severity threshold with generation-to-delivery elapsed time" ], "evidence": [ { "id": "PG-07-E1", "description": "governance_report_package containing report templates per audience tier, populated metric fields, and data-source mappings for each reporting period", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PG-07-E2", "description": "report_distribution_log showing recipient, delivery timestamp, and report version for each scheduled and event-driven governance report", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PG-07-E3", "description": "reporting_pipeline_audit_trail confirming each metric value was sourced from the canonical upstream control system with no manual entry points", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PG-07-E4", "description": "audit_committee_submission_record confirming receipt of quarterly governance reports within the defined deadline", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PG-07-E5", "description": "event_driven_report_log showing supplemental reports triggered by material incidents above the defined severity threshold with generation-to-delivery elapsed time", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://ethics/controls/EG-07", "id": "EG-07", "domain": "ethics", "name": "Ethics Program Metrics and Effectiveness Measurement", "validation_objective": "The organization must maintain an active ethics metrics portfolio containing a minimum of three leading indicators and three lagging indicators across governance, process, and outcome dimensions, with documented collection methodology, quarterly Ethics Board reporting, and traceable action items for any metric below defined threshold. At least one outcome metric must measure system-level ethical performance such as bias finding rate or ethics incident rate.", "blocking_effect": "advisory", "evidence_required": [ "ethics_metrics_portfolio_document defining each metric with name, type (leading/lagging), dimension (governance/process/outcome), collection source, target value, threshold, and reporting cadence", "quarterly_ethics_metrics_dashboard_reports for trailing 12 months showing metric values, trend indicators, threshold alert status, and action items for below-threshold metrics", "action_item_tracking_records linking below-threshold metrics to specific corrective actions with owner, deadline, and closure evidence demonstrating that metrics reviews drive program adjustments", "annual_ethics_effectiveness_report submitted to executive leadership and the Ethics Board with program-level assessment against stated ethics objectives" ], "evidence": [ { "id": "EG-07-E1", "description": "ethics_metrics_portfolio_document defining each metric with name, type (leading/lagging), dimension (governance/process/outcome), collection source, target value, threshold, and reporting cadence", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-07-E2", "description": "quarterly_ethics_metrics_dashboard_reports for trailing 12 months showing metric values, trend indicators, threshold alert status, and action items for below-threshold metrics", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "EG-07-E3", "description": "action_item_tracking_records linking below-threshold metrics to specific corrective actions with owner, deadline, and closure evidence demonstrating that metrics reviews drive program adjustments", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-07-E4", "description": "annual_ethics_effectiveness_report submitted to executive leadership and the Ethics Board with program-level assessment against stated ethics objectives", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE 2.1 requires that AI risk metrics and monitoring approaches are defined and implemented. This control implements the MEASURE function requirement for a structured portfolio of ethics and risk metrics with defined collection and reporting processes." }, { "control": "apeiris://security/controls/AS-03", "id": "AS-03", "domain": "security", "name": "Gate releases on continuous adversarial validation", "validation_objective": "Every production release of the agent must pass an adversarial validation suite compared against the established safety baseline, with any regression in attack-success-rate or safety metric blocking deployment before it reaches production. The gate must execute on code changes AND on model version, routing, or system-prompt changes.", "blocking_effect": "blocks-deployment", "evidence_required": [ "release_gate_eval_report for each deployment showing evaluation suite name, run date, baseline metric values, current metric values, regression flags, and go/no-go decision", "baseline_snapshot_record confirming the safety baseline version and content hash against which the current release was compared", "release_trigger_log confirming the gate was invoked for model version, routing, and system-prompt changes as well as code changes", "regression_block_record for any release where a safety regression was detected, including the blocking metric, severity classification, and remediation steps taken before re-release" ], "evidence": [ { "id": "AS-03-E1", "description": "release_gate_eval_report for each deployment showing evaluation suite name, run date, baseline metric values, current metric values, regression flags, and go/no-go decision", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "AS-03-E2", "description": "baseline_snapshot_record confirming the safety baseline version and content hash against which the current release was compared", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AS-03-E3", "description": "release_trigger_log confirming the gate was invoked for model version, routing, and system-prompt changes as well as code changes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AS-03-E4", "description": "regression_block_record for any release where a safety regression was detected, including the blocking metric, severity classification, and remediation steps taken before re-release", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "adjacent", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF Measure / Manage functions: analyse, assess, benchmark, and monitor the AI risks and impacts; prioritise and act on the identified AI risks, treating, responding, recovering, and allocating resources. \"Gate releases on continuous adversarial validation\" is a corresponding risk-treatment activity." } ] }, { "requirement_id": "MEASURE-3.1", "section": "MEASURE 3.1", "title": "Approaches for testing AI risk defined", "text": "Approaches for testing AI risk are defined and implemented throughout the AI lifecycle.", "verdict": "supported", "coverage": "direct", "notes": "EV-06 enforces reproducible evaluation design; AS-01 mandates adversarial red-teaming before launch; FA-04 specifies independent bias testing methodology \u2014 providing comprehensive pre-deployment testing coverage.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/EV-06", "id": "EV-06", "domain": "model", "name": "Reproducible Evaluation Design", "validation_objective": "Every evaluation run against a model artifact can be independently reproduced from the evaluation design document alone within the defined tolerance by a party who was not involved in the original run; all benchmarks have documented contamination screening results; and all evaluation artifacts are signed with SHA-256 content-addressed hashes recorded in the evaluation manifest.", "blocking_effect": "blocks-deployment", "evidence_required": [ "version_controlled_benchmark_selection_document with pre-specified selection_criteria, benchmark_ids, known_limitations, and alternatives_considered \u2014 signed and committed before any evaluation run begins", "contamination_screening_report documenting screening_methodology, training_corpus_reference, per-benchmark contamination_result (clean/flagged/excluded), and screening_date", "evaluation_design_document capturing all reproduction parameters: random_seeds, software_dependency_versions with hashes, hardware_configuration, serving_framework_config, eval_script_version_and_hash, prompt_templates, and post_processing_steps", "independent_reproduction_run_record showing reproduction_results within the defined tolerance alongside original_results, confirming design document sufficiency for independent replication", "signed_evaluation_artifact_manifest listing SHA-256 hashes for all artifacts (design document, scripts, datasets, results) with signer_identity and key_identifier" ], "evidence": [ { "id": "EV-06-E1", "description": "version_controlled_benchmark_selection_document with pre-specified selection_criteria, benchmark_ids, known_limitations, and alternatives_considered \u2014 signed and committed before any evaluation run begins", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-06-E2", "description": "contamination_screening_report documenting screening_methodology, training_corpus_reference, per-benchmark contamination_result (clean/flagged/excluded), and screening_date", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-06-E3", "description": "evaluation_design_document capturing all reproduction parameters: random_seeds, software_dependency_versions with hashes, hardware_configuration, serving_framework_config, eval_script_version_and_hash, prompt_templates, and post_processing_steps", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-06-E4", "description": "independent_reproduction_run_record showing reproduction_results within the defined tolerance alongside original_results, confirming design document sufficiency for independent replication", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-06-E5", "description": "signed_evaluation_artifact_manifest listing SHA-256 hashes for all artifacts (design document, scripts, datasets, results) with signer_identity and key_identifier", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.1 (MEASURE function) provides that test sets, metrics, and details about the tools used during TEVV are documented. EV-06\u2019s reproducible evaluation design pins the test sets, metrics, seeds, and environments so the TEVV documentation this subcategory requires is complete and re-runnable." }, { "control": "apeiris://security/controls/AS-01", "id": "AS-01", "domain": "security", "name": "Adversarially red-team and evaluate the agent before launch", "validation_objective": "Before any deployment to production, the agent must have passed a structured adversarial red-team exercise covering multi-turn goal hijack, tool misuse, and data exfiltration scenarios, with measured attack-success-rates at or below the defined launch threshold. Deployment must be blocked until the red-team pass/fail gate is cleared and documented.", "blocking_effect": "blocks-deployment", "evidence_required": [ "pre_launch_red_team_report listing each scenario (multi-turn hijack, tool-misuse, exfiltration), the attack-success-rate per scenario, the defined launch threshold, and a signed go/no-go decision", "multi_turn_eval_suite_run_log showing the agentic benchmark used (e.g., AgentDojo, FinBot CTF), commit SHA, run date, and overall pass/fail outcome against the threshold", "red_team_scope_document confirming coverage of multi-turn drift scenarios not only single-prompt tests, signed before the red-team exercise begins", "launch_gate_approval_record linking the red-team report to the deployment decision with approver identity and timestamp" ], "evidence": [ { "id": "AS-01-E1", "description": "pre_launch_red_team_report listing each scenario (multi-turn hijack, tool-misuse, exfiltration), the attack-success-rate per scenario, the defined launch threshold, and a signed go/no-go decision", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AS-01-E2", "description": "multi_turn_eval_suite_run_log showing the agentic benchmark used (e.g., AgentDojo, FinBot CTF), commit SHA, run date, and overall pass/fail outcome against the threshold", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "AS-01-E3", "description": "red_team_scope_document confirming coverage of multi-turn drift scenarios not only single-prompt tests, signed before the red-team exercise begins", "evidence_type": "red-team-report", "verification": "third-party" }, { "id": "AS-01-E4", "description": "launch_gate_approval_record linking the red-team report to the deployment decision with approver identity and timestamp", "evidence_type": "red-team-report", "verification": "third-party" } ], "fit": "adjacent", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF Measure function: analyse, assess, benchmark, and monitor the AI risks and impacts. \"Adversarially red-team and evaluate the agent before launch\" is a corresponding measurement and monitoring activity." }, { "control": "apeiris://ethics/controls/FA-04", "id": "FA-04", "domain": "ethics", "name": "Independent Bias Testing Methodology", "validation_objective": "Bias testing for AI systems subject to fairness requirements must be executed under a documented, pre-registered protocol by a tester with no organizational conflict of interest with the model development team, with all findings retained in an immutable log and reported without post-hoc filtering.", "blocking_effect": "blocks-deployment", "evidence_required": [ "independent_bias_test_protocol_document published prior to test execution specifying methodology, test datasets, metrics, and pass/fail thresholds", "tester_independence_certification confirming the testing entity or individual has no direct reporting relationship to or financial interest in the model development team, signed by a party outside the model development chain", "bias_test_execution_log with timestamped test runs, inputs, and outputs in an immutable or append-only store preventing retroactive modification", "bias_test_findings_report including all findings (not only passing results) with statistical support, identified disparity locations, and remediation recommendations" ], "evidence": [ { "id": "FA-04-E1", "description": "independent_bias_test_protocol_document published prior to test execution specifying methodology, test datasets, metrics, and pass/fail thresholds", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "FA-04-E2", "description": "tester_independence_certification confirming the testing entity or individual has no direct reporting relationship to or financial interest in the model development team, signed by a party outside the model development chain", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-04-E3", "description": "bias_test_execution_log with timestamped test runs, inputs, and outputs in an immutable or append-only store preventing retroactive modification", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "FA-04-E4", "description": "bias_test_findings_report including all findings (not only passing results) with statistical support, identified disparity locations, and remediation recommendations", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE 2.11 recommends that fairness and bias evaluations use diverse evaluation methods including external red-teaming and independent assessment. This control establishes the independence and documentation requirements that make such external assessment credible." } ] }, { "requirement_id": "MEASURE-3.2", "section": "MEASURE 3.2", "title": "Risk tracking in data collection and model development", "text": "Risk tracking approaches are considered and integrated across data collection, model development, and deployment activities.", "verdict": "supported", "coverage": "direct", "notes": "TG-01 applies data quality gates during collection; CR-01 provides continuous production monitoring and risk aggregation; BH-02 detects concept and data drift \u2014 spanning the full model development and deployment lifecycle.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/TG-01", "id": "TG-01", "domain": "model", "name": "Training Data Quality Gates", "validation_objective": "No training run may be initiated unless the designated training dataset has passed automated schema validation, completeness checks, and provenance verification in the current pipeline run; all gate results must be logged with pass/fail status and linked to the training job record.", "blocking_effect": "blocks-deployment", "evidence_required": [ "training_data_quality_gate_report for the current training run showing schema validation results (expected vs. actual field types and cardinalities), completeness check results (null rates, minimum coverage thresholds), and provenance verification status (source hash match, chain-of-custody record reference)", "training_pipeline_block_log confirming that any training attempt that failed a quality gate was rejected before the training compute job was allocated", "dataset_provenance_record with source identifier, ingestion timestamp, data owner, and integrity hash for each training shard used in the run", "quality_threshold_configuration_document defining the pass/fail thresholds for schema validation, completeness, and provenance checks, reviewed and approved by the ML engineering lead" ], "evidence": [ { "id": "TG-01-E1", "description": "training_data_quality_gate_report for the current training run showing schema validation results (expected vs. actual field types and cardinalities), completeness check results (null rates, minimum coverage thresholds), and provenance verification status (source hash match, chain-of-custody record reference)", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "TG-01-E2", "description": "training_pipeline_block_log confirming that any training attempt that failed a quality gate was rejected before the training compute job was allocated", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-01-E3", "description": "dataset_provenance_record with source identifier, ingestion timestamp, data owner, and integrity hash for each training shard used in the run", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-01-E4", "description": "quality_threshold_configuration_document defining the pass/fail thresholds for schema validation, completeness, and provenance checks, reviewed and approved by the ML engineering lead", "evidence_type": "data-lineage-record", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP-2.3 (MAP function) provides that scientific integrity and TEVV considerations, including data collection and selection, are identified and documented. TG-01\u2019s automated quality gates enforce documented data-selection and quality standards at pipeline time, supporting scientific integrity of the training process." }, { "control": "apeiris://model/controls/CR-01", "id": "CR-01", "domain": "model", "name": "Continuous Production Monitoring and Risk Aggregation", "validation_objective": "All runtime monitoring signals \u2014 performance, drift, fairness, safety incidents, and deployment event flags \u2014 must be continuously aggregated into a unified risk dashboard with pre-configured automated alerting thresholds; any degradation in a monitored dimension must be detected and an alert dispatched within one operational window.", "blocking_effect": "advisory", "evidence_required": [ "risk_dashboard_configuration_record showing all registered signal feeds (performance, drift, fairness, safety, incident), their alert thresholds, assigned monitoring window duration, and escalation recipients", "alert_audit_log covering at least 30 days showing triggered alerts with signal_type, threshold_crossed, alert_timestamp, and escalation_recipient for each alert", "monitoring_coverage_audit confirming every deployed model version has an associated monitoring configuration with no version gaps", "risk_aggregation_methodology_document defining how individual dimension alerts are combined into composite risk scores and dashboard status indicators", "post-market_monitoring_report satisfying EU AI Act Art. 72 covering the monitoring period, key findings, and corrective actions taken or planned" ], "evidence": [ { "id": "CR-01-E1", "description": "risk_dashboard_configuration_record showing all registered signal feeds (performance, drift, fairness, safety, incident), their alert thresholds, assigned monitoring window duration, and escalation recipients", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-01-E2", "description": "alert_audit_log covering at least 30 days showing triggered alerts with signal_type, threshold_crossed, alert_timestamp, and escalation_recipient for each alert", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E3", "description": "monitoring_coverage_audit confirming every deployed model version has an associated monitoring configuration with no version gaps", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E4", "description": "risk_aggregation_methodology_document defining how individual dimension alerts are combined into composite risk scores and dashboard status indicators", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E5", "description": "post-market_monitoring_report satisfying EU AI Act Art. 72 covering the monitoring period, key findings, and corrective actions taken or planned", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.4 (MEASURE function) provides that the functionality and behavior of the AI system and its components are monitored when in production. CR-01 aggregates production monitoring signals \u2014 performance, drift, fairness, safety, cost \u2014 into a single risk view with calibrated alert thresholds." }, { "control": "apeiris://model/controls/BH-02", "id": "BH-02", "domain": "model", "name": "Concept and Data Drift Detection", "validation_objective": "The production inference pipeline must compare input feature distributions and prediction distributions against a versioned, SHA-256-signed DriftReference artifact using PSI and KS-test statistics for every monitoring window that meets minimum_sample_size, such that drift exceeding profile-conditional PSI thresholds triggers tiered alert actions, and for continuously-learning profiles, automatically suspends online updates pending a signed model-owner resume authorization.", "blocking_effect": "advisory", "evidence_required": [ "versioned DriftReference artifact for the current production model with SHA-256 hash, training date, and per-feature statistics (mean, std, histogram bins, and KDE parameters) for all tier-1 monitored features", "drift event log for trailing 90 days with fields: feature_name, test_statistic, p_value, window_start, window_end, sample_count, alert_severity, and action_taken for each drift event", "monthly drift summary report signed by the model owner, including trend analysis across tier-1 features and prediction distribution PSI over the reporting period", "profile-conditional drift threshold configuration (YAML or equivalent) showing per-profile PSI alert and critical thresholds, minimum_sample_size, and window duration, stored under version control" ], "evidence": [ { "id": "BH-02-E1", "description": "versioned DriftReference artifact for the current production model with SHA-256 hash, training date, and per-feature statistics (mean, std, histogram bins, and KDE parameters) for all tier-1 monitored features", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-02-E2", "description": "drift event log for trailing 90 days with fields: feature_name, test_statistic, p_value, window_start, window_end, sample_count, alert_severity, and action_taken for each drift event", "evidence_type": "audit-log", "verification": "automated" }, { "id": "BH-02-E3", "description": "monthly drift summary report signed by the model owner, including trend analysis across tier-1 features and prediction distribution PSI over the reporting period", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-02-E4", "description": "profile-conditional drift threshold configuration (YAML or equivalent) showing per-profile PSI alert and critical thresholds, minimum_sample_size, and window duration, stored under version control", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.4 (MEASURE function) provides that the functionality and behavior of the AI system and its components are monitored when in production. BH-02\u2019s PSI/KS drift detection continuously monitors production input behavior against a versioned DriftReference artifact." } ] }, { "requirement_id": "MEASURE-3.3", "section": "MEASURE 3.3", "title": "Feedback processes for AI risk management", "text": "Feedback processes for AI risk management and continuous improvement practices are in place.", "verdict": "supported", "coverage": "direct", "notes": "AG-07 mandates continuous improvement and lessons learned; PG-08 captures policy improvement through lessons learned; CR-06 provides post-market surveillance as the feedback source.", "control_count": 3, "proof_chain": [ { "control": "apeiris://agentic/controls/AG-07", "id": "AG-07", "domain": "agentic", "name": "Continuous Improvement and Lessons Learned", "validation_objective": "The enterprise operates a closed-loop lessons-learned program with four defined input channels, a tracked pipeline from capture to verified implementation, and documented control update recommendations with named owners and due dates that are verifiably completed.", "blocking_effect": "advisory", "evidence_required": [ "Lessons-learned register showing all open and closed items from the past 12 months, with input source, root cause, affected control identifiers, recommended update, approval status, implementation date, and verification evidence", "Post-incident review outputs from all P1/P2 events completed within the 5-business-day SLA, linked to lessons-learned register entries", "Records of external intelligence feed subscriptions and quarterly relevance assessments, including items submitted to the lessons-learned pipeline", "Governance committee retrospective records from each quarterly session showing open action item status and newly identified improvement themes" ], "evidence": [ { "id": "AG-07-E1", "description": "Lessons-learned register showing all open and closed items from the past 12 months, with input source, root cause, affected control identifiers, recommended update, approval status, implementation date, and verification evidence", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AG-07-E2", "description": "Post-incident review outputs from all P1/P2 events completed within the 5-business-day SLA, linked to lessons-learned register entries", "evidence_type": "incident-record", "verification": "attested" }, { "id": "AG-07-E3", "description": "Records of external intelligence feed subscriptions and quarterly relevance assessments, including items submitted to the lessons-learned pipeline", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-07-E4", "description": "Governance committee retrospective records from each quarterly session showing open action item status and newly identified improvement themes", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MANAGE 4.1 requires post-deployment monitoring plans that include mechanisms for capturing and evaluating input from users and affected parties, feeding change management. The lessons-learned pipeline is that capture-and-evaluate mechanism for the agentic program." }, { "control": "apeiris://authority/controls/PG-08", "id": "PG-08", "domain": "authority", "name": "Lessons Learned and Policy Improvement", "validation_objective": "Every AI policy incident and near-miss must generate a structured lessons-learned record that identifies the root cause, the policy gap exploited, and a documented improvement action with an assigned owner and target closure date. The improvement cycle must be confirmed closed in the policy registry before the control is considered passing.", "blocking_effect": "requires-review", "evidence_required": [ "lessons_learned_record for each qualifying incident containing root_cause, policy_gap_reference, improvement_action, assigned_owner, and target_closure_date fields", "policy_improvement_log confirming that each improvement action triggered a versioned policy update or documented risk-acceptance decision with sign-off", "incident_classification_record distinguishing incidents requiring formal lessons-learned review from those below threshold, with classification rationale", "policy_registry_update_record showing the policy version that incorporated each improvement action, with before-and-after change diff and approver identity", "improvement_cycle_closure_record confirming that each open improvement action was closed within its target date or escalated with documented justification for extension" ], "evidence": [ { "id": "PG-08-E1", "description": "lessons_learned_record for each qualifying incident containing root_cause, policy_gap_reference, improvement_action, assigned_owner, and target_closure_date fields", "evidence_type": "incident-record", "verification": "attested" }, { "id": "PG-08-E2", "description": "policy_improvement_log confirming that each improvement action triggered a versioned policy update or documented risk-acceptance decision with sign-off", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PG-08-E3", "description": "incident_classification_record distinguishing incidents requiring formal lessons-learned review from those below threshold, with classification rationale", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PG-08-E4", "description": "policy_registry_update_record showing the policy version that incorporated each improvement action, with before-and-after change diff and approver identity", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PG-08-E5", "description": "improvement_cycle_closure_record confirming that each open improvement action was closed within its target date or escalated with documented justification for extension", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "Lessons-learned closing root-cause gaps partially implements MANAGE 4.1 post-incident change management." }, { "control": "apeiris://model/controls/CR-06", "id": "CR-06", "domain": "model", "name": "Post-Market Surveillance", "validation_objective": "The organization must operate three distinct proactive surveillance channels \u2014 a structured user-facing harm reporting mechanism, a coordinated vulnerability disclosure (CVD) program with a monitored security inbox, and a quarterly AI literature and media monitoring process \u2014 with outputs aggregated into a monthly post-market surveillance report reviewed and signed by the AI risk function, and an annual surveillance summary included in the model's EU high-risk AI technical documentation (LI-04).", "blocking_effect": "advisory", "evidence_required": [ "User-facing harm reporting mechanism deployment record showing endpoint URL, structured input schema (harm_type, severity_self_assessed, description), and CR-02 archive path", "Published CVD policy document at a canonical URL with designated security email alias and monitored inbox confirmation, including acknowledgement SLA statement", "Last 12 monthly post-market surveillance reports with AI risk function reviewer name, sign-off signature, and review date on each report", "Annual surveillance summary document aggregating user reports, CVD submissions, and literature findings \u2014 present in the model's LI-04 technical documentation with review date", "CVD acknowledgement records showing each submission received an acknowledgement within 5 business days of receipt" ], "evidence": [ { "id": "CR-06-E1", "description": "User-facing harm reporting mechanism deployment record showing endpoint URL, structured input schema (harm_type, severity_self_assessed, description), and CR-02 archive path", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-06-E2", "description": "Published CVD policy document at a canonical URL with designated security email alias and monitored inbox confirmation, including acknowledgement SLA statement", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-06-E3", "description": "Last 12 monthly post-market surveillance reports with AI risk function reviewer name, sign-off signature, and review date on each report", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CR-06-E4", "description": "Annual surveillance summary document aggregating user reports, CVD submissions, and literature findings \u2014 present in the model's LI-04 technical documentation with review date", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CR-06-E5", "description": "CVD acknowledgement records showing each submission received an acknowledgement within 5 business days of receipt", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.4 (MEASURE function) provides that the functionality and behavior of the AI system and its components are monitored when in production. CR-06 extends production monitoring beyond runtime metrics to externally reported harms via structured surveillance channels." } ] }, { "requirement_id": "MEASURE-4.1", "section": "MEASURE 4.1", "title": "Measurement approaches connected to deployment context", "text": "Measurement approaches for identifying AI risks are connected to the deployment context and operational conditions.", "verdict": "supported", "coverage": "direct", "notes": "BH-05 captures usage telemetry and decision logging in deployment context; AM-01 establishes behavioral telemetry collection baseline; CR-01 aggregates production monitoring in the operational environment.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/BH-05", "id": "BH-05", "domain": "model", "name": "Usage Telemetry and Decision Logging", "validation_objective": "Every model inference endpoint must emit a structured DecisionLog record containing input_hash (HMAC-SHA-256), caller_id, model_version, output_sample at the configured sampling rate, latency_ms, and decision_outcome; logs must be stored in an append-only tamper-evident store with daily Merkle root hash publication; and no direct PII must appear in any stored log field.", "blocking_effect": "advisory", "evidence_required": [ "DecisionLog schema documentation with field definitions, HMAC masking policy, key management system references, and output sampling rate configuration per deployment profile", "privacy review sign-off from the data protection team confirming no direct PII identifiers appear in stored log records, based on a regex scan of a trailing 30-day sample", "daily Merkle root hash publication log for trailing 90 days with fields: root_hash, computation_timestamp, and publication_destination for each daily entry", "retention policy configuration and automated deletion audit log confirming tiered retention enforcement (90-day raw, 3-year aggregated, 10-year minimum for EU high-risk deployments)", "DecisionLog query access audit trail for trailing 90 days showing all access events with requester_id, query_timestamp, and authorization_basis" ], "evidence": [ { "id": "BH-05-E1", "description": "DecisionLog schema documentation with field definitions, HMAC masking policy, key management system references, and output sampling rate configuration per deployment profile", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "BH-05-E2", "description": "privacy review sign-off from the data protection team confirming no direct PII identifiers appear in stored log records, based on a regex scan of a trailing 30-day sample", "evidence_type": "audit-log", "verification": "automated" }, { "id": "BH-05-E3", "description": "daily Merkle root hash publication log for trailing 90 days with fields: root_hash, computation_timestamp, and publication_destination for each daily entry", "evidence_type": "audit-log", "verification": "automated" }, { "id": "BH-05-E4", "description": "retention policy configuration and automated deletion audit log confirming tiered retention enforcement (90-day raw, 3-year aggregated, 10-year minimum for EU high-risk deployments)", "evidence_type": "audit-log", "verification": "automated" }, { "id": "BH-05-E5", "description": "DecisionLog query access audit trail for trailing 90 days showing all access events with requester_id, query_timestamp, and authorization_basis", "evidence_type": "audit-log", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN-1.2 (GOVERN function) provides that the characteristics of trustworthy AI are integrated into organizational policies, processes, and practices. BH-05\u2019s tamper-evident DecisionLog gives accountability and transparency \u2014 trustworthy-AI characteristics this subcategory integrates into organizational policy \u2014 an enforceable runtime record for every inference." }, { "control": "apeiris://agentic/controls/AM-01", "id": "AM-01", "domain": "agentic", "name": "Behavioral Telemetry Collection Baseline", "validation_objective": "Proves that every registered production agent emits a schema-validated, minimum signal set \u2014 covering action type, tool invocations, token consumption, session boundaries, and decision rationale traces \u2014 to an append-only telemetry store, with 100% coverage of registered agents demonstrable within the prior 24-hour window.", "blocking_effect": "advisory", "evidence_required": [ "Telemetry schema version registry showing current schema version and change history with change-management approval records", "Agent registry cross-referenced with telemetry coverage report identifying any registered agents with no telemetry events in the prior 24 hours", "Schema validation rejection rate report for the prior 7 days, with alert records for any rejection rate above 0.1%", "Five sample agent session traces each demonstrating a continuous telemetry record from session_start to session_end with all required baseline fields", "Telemetry pipeline SLO report covering ingestion latency, throughput capacity, and event loss rate" ], "evidence": [ { "id": "AM-01-E1", "description": "Telemetry schema version registry showing current schema version and change history with change-management approval records", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AM-01-E2", "description": "Agent registry cross-referenced with telemetry coverage report identifying any registered agents with no telemetry events in the prior 24 hours", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AM-01-E3", "description": "Schema validation rejection rate report for the prior 7 days, with alert records for any rejection rate above 0.1%", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "AM-01-E4", "description": "Five sample agent session traces each demonstrating a continuous telemetry record from session_start to session_end with all required baseline fields", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AM-01-E5", "description": "Telemetry pipeline SLO report covering ingestion latency, throughput capacity, and event loss rate", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MANAGE 4.1 requires post-deployment AI system monitoring plans to be implemented. The behavioral telemetry baseline is the foundational implementation: without a defined, complete telemetry contract, no downstream monitoring plan can operate." }, { "control": "apeiris://model/controls/CR-01", "id": "CR-01", "domain": "model", "name": "Continuous Production Monitoring and Risk Aggregation", "validation_objective": "All runtime monitoring signals \u2014 performance, drift, fairness, safety incidents, and deployment event flags \u2014 must be continuously aggregated into a unified risk dashboard with pre-configured automated alerting thresholds; any degradation in a monitored dimension must be detected and an alert dispatched within one operational window.", "blocking_effect": "advisory", "evidence_required": [ "risk_dashboard_configuration_record showing all registered signal feeds (performance, drift, fairness, safety, incident), their alert thresholds, assigned monitoring window duration, and escalation recipients", "alert_audit_log covering at least 30 days showing triggered alerts with signal_type, threshold_crossed, alert_timestamp, and escalation_recipient for each alert", "monitoring_coverage_audit confirming every deployed model version has an associated monitoring configuration with no version gaps", "risk_aggregation_methodology_document defining how individual dimension alerts are combined into composite risk scores and dashboard status indicators", "post-market_monitoring_report satisfying EU AI Act Art. 72 covering the monitoring period, key findings, and corrective actions taken or planned" ], "evidence": [ { "id": "CR-01-E1", "description": "risk_dashboard_configuration_record showing all registered signal feeds (performance, drift, fairness, safety, incident), their alert thresholds, assigned monitoring window duration, and escalation recipients", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-01-E2", "description": "alert_audit_log covering at least 30 days showing triggered alerts with signal_type, threshold_crossed, alert_timestamp, and escalation_recipient for each alert", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E3", "description": "monitoring_coverage_audit confirming every deployed model version has an associated monitoring configuration with no version gaps", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E4", "description": "risk_aggregation_methodology_document defining how individual dimension alerts are combined into composite risk scores and dashboard status indicators", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E5", "description": "post-market_monitoring_report satisfying EU AI Act Art. 72 covering the monitoring period, key findings, and corrective actions taken or planned", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.4 (MEASURE function) provides that the functionality and behavior of the AI system and its components are monitored when in production. CR-01 aggregates production monitoring signals \u2014 performance, drift, fairness, safety, cost \u2014 into a single risk view with calibrated alert thresholds." } ] }, { "requirement_id": "MEASURE-4.2", "section": "MEASURE 4.2", "title": "Measurement results recorded and available", "text": "Measurement results are recorded and made available to relevant teams and stakeholders.", "verdict": "supported", "coverage": "direct", "notes": "CR-02 provides the model evidence archive and audit trail; PE-01 archives policy evidence; EV-10 ensures evaluation result provenance \u2014 together making measurement results durable and accessible.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/CR-02", "id": "CR-02", "domain": "model", "name": "Model Evidence Archive and Audit Trail", "validation_objective": "All evaluation results, monitoring snapshots, incident records, and regulatory submissions must be stored in an immutable, content-addressed archive with cryptographic integrity protection; any audit query for a model's historical evidence must resolve to a complete, tamper-evident chain spanning the full production lifetime of that model version.", "blocking_effect": "blocks-deployment", "evidence_required": [ "archive_integrity_configuration_record showing content-addressed storage settings, hash algorithm (minimum SHA-256), write-once immutability enforcement, and retention policy duration per record type", "evidence_chain_completeness_audit confirming that evaluation results, monitoring snapshots, and incident records for each production model version are present in the archive with no missing lifecycle entries", "tamper_detection_scan_report from periodic archive integrity verification showing all stored records produce matching content hashes with zero reported mismatches", "regulatory_submission_evidence_linkage_record linking each regulatory submission to its archived evidence artifact with submission_id, submission_date, submitting_entity, and archive_content_hash", "archive_access_control_audit_log confirming write operations are restricted to authorized pipeline components only and all access attempts are logged with actor_id and timestamp" ], "evidence": [ { "id": "CR-02-E1", "description": "archive_integrity_configuration_record showing content-addressed storage settings, hash algorithm (minimum SHA-256), write-once immutability enforcement, and retention policy duration per record type", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "CR-02-E2", "description": "evidence_chain_completeness_audit confirming that evaluation results, monitoring snapshots, and incident records for each production model version are present in the archive with no missing lifecycle entries", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-02-E3", "description": "tamper_detection_scan_report from periodic archive integrity verification showing all stored records produce matching content hashes with zero reported mismatches", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-02-E4", "description": "regulatory_submission_evidence_linkage_record linking each regulatory submission to its archived evidence artifact with submission_id, submission_date, submitting_entity, and archive_content_hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-02-E5", "description": "archive_access_control_audit_log confirming write operations are restricted to authorized pipeline components only and all access attempts are logged with actor_id and timestamp", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN-1.4 (GOVERN function) provides that the risk management process and its outcomes are established through transparent policies, procedures, and controls. CR-02\u2019s immutable, content-addressed evidence archive preserves the documented outcomes of the risk management process so they remain reviewable and transparent over time." }, { "control": "apeiris://authority/controls/PE-01", "id": "PE-01", "domain": "authority", "name": "Policy Evidence Archive", "validation_objective": "All policy evidence artifacts must be stored in a tamper-evident, versioned archive where entries are immutable once committed, indexed by artifact type and control ID, and retrievable within the defined SLA during regulatory examination or litigation hold. The archive must produce a cryptographic proof of immutability on demand.", "blocking_effect": "blocks-deployment", "evidence_required": [ "archive_commit_log showing every artifact entry with artifact_id, control_id, committed_at timestamp, SHA-256 hash, and committer identity \u2014 with no modification events after initial commit", "tamper_evidence_record containing the Merkle root or audit log hash for the archive state at each quarterly checkpoint, signed by the archive operator", "retrieval_test_record showing that a representative sample of archived artifacts was successfully retrieved within the defined SLA, with retrieval timestamps and artifact hashes", "litigation_hold_activation_record documenting hold scope, activation timestamp, and confirmation that affected artifacts are locked against deletion for the hold duration", "archive_access_control_manifest listing authorized readers and writers with role assignments, confirming write access is restricted to the ingestion pipeline and no interactive modification is permitted" ], "evidence": [ { "id": "PE-01-E1", "description": "archive_commit_log showing every artifact entry with artifact_id, control_id, committed_at timestamp, SHA-256 hash, and committer identity \u2014 with no modification events after initial commit", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PE-01-E2", "description": "tamper_evidence_record containing the Merkle root or audit log hash for the archive state at each quarterly checkpoint, signed by the archive operator", "evidence_type": "audit-log", "verification": "automated" }, { "id": "PE-01-E3", "description": "retrieval_test_record showing that a representative sample of archived artifacts was successfully retrieved within the defined SLA, with retrieval timestamps and artifact hashes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PE-01-E4", "description": "litigation_hold_activation_record documenting hold scope, activation timestamp, and confirmation that affected artifacts are locked against deletion for the hold duration", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PE-01-E5", "description": "archive_access_control_manifest listing authorized readers and writers with role assignments, confirming write access is restricted to the ingestion pipeline and no interactive modification is permitted", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://model/controls/EV-10", "id": "EV-10", "domain": "model", "name": "Evaluation Result Provenance", "validation_objective": "Every evaluation result artifact is SHA-256 content-addressed, cryptographically signed with individually attributed non-repudiable key material, submitted to an append-only tamper-evident log with a recorded inclusion proof, and linked to the model artifact hash and evaluation suite hash such that the complete chain from model artifact to deployment decision is machine-verifiable; the deployment gate rejects any manifest where inclusion proof verification fails.", "blocking_effect": "blocks-deployment", "evidence_required": [ "signed_content_addressed_evaluation_result_artifacts for each run containing model_artifact_hash, eval_suite_id, eval_suite_version, eval_suite_hash, run_timestamp, environment_fingerprint, per_dimension_results, gate_determination, and signer_identity with key_identifier", "tamper_evident_log_inclusion_proofs for each signed evaluation result submission, with log_entry_id and inclusion_proof_bytes sufficient for independent verification", "provenance_chain_traversal_records demonstrating machine-verifiable linkage from model_artifact_hash through evaluation_result to deployment_manifest for each production model version", "signing_key_attribution_records mapping each signer_identity in evaluation artifacts to a named individual via PKI certificate or directory lookup, confirming no shared or service-account signing credentials were used", "retention_compliance_records confirming signed artifacts and inclusion proofs remain available for the required period covering the operational model lifetime plus the applicable regulatory minimum per jurisdiction" ], "evidence": [ { "id": "EV-10-E1", "description": "signed_content_addressed_evaluation_result_artifacts for each run containing model_artifact_hash, eval_suite_id, eval_suite_version, eval_suite_hash, run_timestamp, environment_fingerprint, per_dimension_results, gate_determination, and signer_identity with key_identifier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-10-E2", "description": "tamper_evident_log_inclusion_proofs for each signed evaluation result submission, with log_entry_id and inclusion_proof_bytes sufficient for independent verification", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-10-E3", "description": "provenance_chain_traversal_records demonstrating machine-verifiable linkage from model_artifact_hash through evaluation_result to deployment_manifest for each production model version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-10-E4", "description": "signing_key_attribution_records mapping each signer_identity in evaluation artifacts to a named individual via PKI certificate or directory lookup, confirming no shared or service-account signing credentials were used", "evidence_type": "certification", "verification": "third-party" }, { "id": "EV-10-E5", "description": "retention_compliance_records confirming signed artifacts and inclusion proofs remain available for the required period covering the operational model lifetime plus the applicable regulatory minimum per jurisdiction", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.1 (MEASURE function) provides that test sets, metrics, and details about the tools used during TEVV are documented. EV-10\u2019s content-addressed, signed evaluation records preserve the test sets, metrics, and tool details this subcategory requires as tamper-evident documentation." } ] }, { "requirement_id": "MANAGE-1.1", "section": "MANAGE 1.1", "title": "Systematic process to manage AI risk", "text": "A systematic process exists and is implemented to manage identified AI risks.", "verdict": "supported", "coverage": "direct", "notes": "AG-03 provides the agentic AI risk assessment framework; PG-01 monitors policy adherence; EG-01 establishes ethics governance structure \u2014 collectively forming the multi-domain systematic risk management process.", "control_count": 3, "proof_chain": [ { "control": "apeiris://agentic/controls/AG-03", "id": "AG-03", "domain": "agentic", "name": "Agentic AI Risk Assessment Framework", "validation_objective": "Every production AI agent has a completed, current risk assessment evaluated against all five framework dimensions, with the resulting consequence tier documented and linked to the deployment approval and control mitigation plan.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "Annual risk reassessment records for all Critical-tier agents" ], "evidence": [ { "id": "AG-03-E1", "description": "Published Agentic AI Risk Assessment Framework document defining the five scoring dimensions, rubrics with anchored examples, tier thresholds, and required control mitigations per tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E2", "description": "Completed risk assessment artifact for each production agent, including per-dimension scores, aggregate tier determination, and identified failure modes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E3", "description": "Control mitigation plan linked to each assessment capturing required mitigations for the assigned tier and their implementation status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E4", "description": "Reassessment records for any agent that underwent significant capability change or context change since initial deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-03-E5", "description": "Annual risk reassessment records for all Critical-tier agents", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP 5.1 requires assessing the likelihood and magnitude of identified AI impacts in deployment context. The five-dimension agentic risk scoring model is a structured method for exactly that assessment across autonomy, reversibility, and blast-radius dimensions." }, { "control": "apeiris://authority/controls/PG-01", "id": "PG-01", "domain": "authority", "name": "Policy Adherence Monitoring", "validation_objective": "All in-scope AI systems must have 100% of their active internal policies represented by machine-evaluable monitoring rules in the policy registry, with every AI system action evaluated against applicable rules in real time, and deviation alerts routed to accountable reviewers within the documented SLA.", "blocking_effect": "advisory", "evidence_required": [ "Policy registry export listing all active internal policies with corresponding machine-evaluable rule definitions, effective dates, and policy source references", "Policy evaluation engine event logs showing per-action rule evaluation outcomes, deviation alert generation timestamps, and SLA compliance metrics for the reporting period", "Compliance monitoring SLA definition document signed by the Compliance Officer, specifying alert routing targets and resolution timeframes", "Monitoring coverage report confirming the percentage of in-scope AI systems and action types evaluated against active policy rules, with no coverage gaps documented without risk acceptance" ], "evidence": [ { "id": "PG-01-E1", "description": "Policy registry export listing all active internal policies with corresponding machine-evaluable rule definitions, effective dates, and policy source references", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "PG-01-E2", "description": "Policy evaluation engine event logs showing per-action rule evaluation outcomes, deviation alert generation timestamps, and SLA compliance metrics for the reporting period", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "PG-01-E3", "description": "Compliance monitoring SLA definition document signed by the Compliance Officer, specifying alert routing targets and resolution timeframes", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "PG-01-E4", "description": "Monitoring coverage report confirming the percentage of in-scope AI systems and action types evaluated against active policy rules, with no coverage gaps documented without risk acceptance", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "Continuous adherence monitoring helps identify emergent policy risks, partially addressing MEASURE 3.1." }, { "control": "apeiris://ethics/controls/EG-01", "id": "EG-01", "domain": "ethics", "name": "Ethics Governance Structure", "validation_objective": "The enterprise must have an active, formally chartered AI Ethics Board with documented cross-functional membership, defined decision authority over high-risk AI deployments, a functioning escalation path from individual teams to the board, and evidence of executive-level reporting within the past 90 days. The control passes if an Ethics Board charter exists, meeting minutes and decision logs are complete for the trailing 12 months, all high-risk AI systems have Ethics Board approval records, and at least one escalation was exercised and documented.", "blocking_effect": "blocks-deployment", "evidence_required": [ "AI Ethics Board charter document signed at C-suite or board authority level, specifying membership criteria, quorum rules, decision authority scope over high-risk AI deployment approvals, and meeting cadence", "Ethics Board meeting minutes for the trailing 12 months showing dates, attendees, agenda items, decision log entries, and executive or board-level reporting records confirming required governance cadence", "Escalation path documentation distributed to all AI product teams showing the path from individual contributor to Ethics Board with named contacts at each level and documented response SLAs", "Ethics Board decision log entries for AI deployment approvals or rejections in the trailing 12 months, confirming high-risk AI systems passed through the formal governance process", "Evidence of at least one ethics escalation exercised through the documented escalation path, with intake record, investigation record, Ethics Board disposition, and outcome notification to the escalating party" ], "evidence": [ { "id": "EG-01-E1", "description": "AI Ethics Board charter document signed at C-suite or board authority level, specifying membership criteria, quorum rules, decision authority scope over high-risk AI deployment approvals, and meeting cadence", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-01-E2", "description": "Ethics Board meeting minutes for the trailing 12 months showing dates, attendees, agenda items, decision log entries, and executive or board-level reporting records confirming required governance cadence", "evidence_type": "audit-log", "verification": "automated" }, { "id": "EG-01-E3", "description": "Escalation path documentation distributed to all AI product teams showing the path from individual contributor to Ethics Board with named contacts at each level and documented response SLAs", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-01-E4", "description": "Ethics Board decision log entries for AI deployment approvals or rejections in the trailing 12 months, confirming high-risk AI systems passed through the formal governance process", "evidence_type": "audit-log", "verification": "automated" }, { "id": "EG-01-E5", "description": "Evidence of at least one ethics escalation exercised through the documented escalation path, with intake record, investigation record, Ethics Board disposition, and outcome notification to the escalating party", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN 2.1 requires that roles, responsibilities, and lines of communication related to mapping, measuring, and managing AI risks are documented and clear. An Ethics Board with a documented charter, defined membership, and formal escalation paths directly implements this governance subcategory." } ] }, { "requirement_id": "MANAGE-1.2", "section": "MANAGE 1.2", "title": "Risk treatment, containment, and sharing options evaluated", "text": "Treatment, containment, and risk-sharing options are evaluated for prioritized identified AI risks.", "verdict": "partial", "coverage": "partial", "notes": "AB-03 classifies action reversibility and gates high-risk actions; EC-01 provides containment via sandboxing; GV-08 makes high-impact actions transactional. Formal risk-sharing mechanisms (insurance, contractual transfer) are outside the current control scope.", "control_count": 3, "proof_chain": [ { "control": "apeiris://agentic/controls/AB-03", "id": "AB-03", "domain": "agentic", "name": "Action Reversibility Classification and Gates", "validation_objective": "Prove that every action type in an agent's authorized scope has been formally classified as reversible or irreversible, and that all irreversible actions are blocked from execution until an explicit authorization gate is satisfied \u2014 pre-authorized scope approval, elevated human approval, or a confirmed dry-run result reviewed before live execution.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Action reversibility classification register covering every action type in the agent's authorized scope with classification rationale and responsible owner", "Platform enforcement records confirming irreversible actions were gated prior to execution during the test period, with gate condition and outcome logged", "Dry-run execution logs for irreversible actions showing dry-run output was produced and reviewed before live execution proceeded", "Governance sign-off records authorizing each irreversible action type for the agent's deployment context, with approver identity and validity period" ], "evidence": [ { "id": "AB-03-E1", "description": "Action reversibility classification register covering every action type in the agent's authorized scope with classification rationale and responsible owner", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AB-03-E2", "description": "Platform enforcement records confirming irreversible actions were gated prior to execution during the test period, with gate condition and outcome logged", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "AB-03-E3", "description": "Dry-run execution logs for irreversible actions showing dry-run output was produced and reviewed before live execution proceeded", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AB-03-E4", "description": "Governance sign-off records authorizing each irreversible action type for the agent's deployment context, with approver identity and validity period", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MANAGE 4.1 requires post-deployment monitoring plans that include mechanisms for override and human intervention. Reversibility classification with human authorization gates on irreversible actions is a concrete intervention mechanism that bounds the permanent impact of agent failures." }, { "control": "apeiris://security/controls/EC-01", "id": "EC-01", "domain": "security", "name": "Run the agent in a sandbox, from process isolation up to micro-VMs", "validation_objective": "Every agent must execute within an isolation tier matched to its threat profile, with untrusted-code agents deployed in a hypervisor-backed micro-VM (Firecracker or gVisor) that prevents direct access to the host kernel. The isolation tier must be declared in the deployment specification and cryptographically attested at runtime.", "blocking_effect": "blocks-deployment", "evidence_required": [ "sandbox_runtime_attestation confirming isolation_tier (process/gVisor/micro-VM), sandbox_type, and kernel_exposure_level for each agent run, captured at deployment time", "deployment_spec_record showing isolation_tier, sandbox_runtime, and seccomp_profile for each agent workload, diffed against the attested runtime configuration", "escape_test_result from known sandbox-escape payload execution inside the sandbox, recording reached_host (must be false), maximum_reached_boundary, and test_run_at", "syscall_profile_baseline showing the expected system call set for the agent workload and any deviations detected during runtime" ], "evidence": [ { "id": "EC-01-E1", "description": "sandbox_runtime_attestation confirming isolation_tier (process/gVisor/micro-VM), sandbox_type, and kernel_exposure_level for each agent run, captured at deployment time", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-01-E2", "description": "deployment_spec_record showing isolation_tier, sandbox_runtime, and seccomp_profile for each agent workload, diffed against the attested runtime configuration", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "EC-01-E3", "description": "escape_test_result from known sandbox-escape payload execution inside the sandbox, recording reached_host (must be false), maximum_reached_boundary, and test_run_at", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-01-E4", "description": "syscall_profile_baseline showing the expected system call set for the agent workload and any deviations detected during runtime", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "adjacent", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF Manage function: prioritise and act on the identified AI risks, treating, responding, recovering, and allocating resources. \"Run the agent in a sandbox, from process isolation up to micro-VMs\" is a corresponding risk-treatment activity." }, { "control": "apeiris://security/controls/GV-08", "id": "GV-08", "domain": "security", "name": "Make high-impact actions transactional, atomic, idempotent, state-checked", "validation_objective": "Every high-impact agent action carries a globally unique idempotency key, re-verifies current authorization and resource state at the moment of commit rather than at plan time, and atomically aborts if a permission revocation, budget breach, or state conflict has occurred in the interval between planning and committing.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "transaction_log for high-impact actions showing: idempotency_key, plan_time_authz_check_result, commit_time_authz_check_result, state_version_at_plan, state_version_at_commit, and commit_outcome (committed or aborted)", "revocation_race_test_record demonstrating an action was aborted when authorization was revoked between the plan step and the commit step", "duplicate_replay_test_record showing a second submission of the same idempotency key was rejected without re-applying the action to the target resource", "conflict_serialization_record showing two concurrent agents targeting the same resource were serialized or one was aborted rather than both committing simultaneously" ], "evidence": [ { "id": "GV-08-E1", "description": "transaction_log for high-impact actions showing: idempotency_key, plan_time_authz_check_result, commit_time_authz_check_result, state_version_at_plan, state_version_at_commit, and commit_outcome (committed or aborted)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-08-E2", "description": "revocation_race_test_record demonstrating an action was aborted when authorization was revoked between the plan step and the commit step", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-08-E3", "description": "duplicate_replay_test_record showing a second submission of the same idempotency key was rejected without re-applying the action to the target resource", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-08-E4", "description": "conflict_serialization_record showing two concurrent agents targeting the same resource were serialized or one was aborted rather than both committing simultaneously", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "adjacent", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF Manage function: prioritise and act on the identified AI risks, treating, responding, recovering, and allocating resources. \"Make high-impact actions transactional, atomic, idempotent, state-checked\" is a corresponding risk-treatment activity." } ] }, { "requirement_id": "MANAGE-1.3", "section": "MANAGE 1.3", "title": "Residual risk documented and incorporated into risk register", "text": "Residual risk is documented, accepted or addressed, and incorporated into the AI system and organizational risk register.", "verdict": "partial", "coverage": "partial", "notes": "EV-09 classifies residual risk after evaluation; PG-07 provides governance reporting; EF-03 defines the risk appetite threshold for residual risk acceptance. Formal residual risk acceptance sign-off and cross-system risk register consolidation are not explicitly specified.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/EV-09", "id": "EV-09", "domain": "model", "name": "Risk and Applicability Classification", "validation_objective": "Every model system has a signed classification record produced before any evaluation work begins, containing a documented EU AI Act classification with provision-specific rationale referencing Articles 5, 6, 50, 51, and Annex III as applicable, an SR 26-2 model risk tier for in-scope institutions, a capability tier, and the full applicable Apeiris profiles list; the model registry gate prevents advancement to evaluation stage without this record; and re-classification is triggered on any significant change to use case, capability level, or applicable regulation.", "blocking_effect": "blocks-deployment", "evidence_required": [ "signed_classification_record containing eu_ai_act_classification with specific provision references, sr_262_tier where applicable, capability_tier, applicable_profiles list, mandatory_controls inventory, and obligations_inventory \u2014 produced before any evaluation artifact is created", "classification_questionnaire_responses document answering all required dimensions: intended_use_cases, affected_populations, decision_automation_level, human_oversight_mechanisms, deployment_jurisdiction, compute_budget, parameter_count", "non_high_risk_exclusion_rationale for systems classified below high-risk, explicitly addressing each relevant Annex III category with documented rationale for exclusion", "classification_review_records for all re-classification events documenting trigger_event, prior_classification, new_classification, and rationale with effective_date", "iso_42005_impact_assessment for high-impact-decision and eu-high-risk profile systems per ISO/IEC 42005:2025" ], "evidence": [ { "id": "EV-09-E1", "description": "signed_classification_record containing eu_ai_act_classification with specific provision references, sr_262_tier where applicable, capability_tier, applicable_profiles list, mandatory_controls inventory, and obligations_inventory \u2014 produced before any evaluation artifact is created", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-09-E2", "description": "classification_questionnaire_responses document answering all required dimensions: intended_use_cases, affected_populations, decision_automation_level, human_oversight_mechanisms, deployment_jurisdiction, compute_budget, parameter_count", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E3", "description": "non_high_risk_exclusion_rationale for systems classified below high-risk, explicitly addressing each relevant Annex III category with documented rationale for exclusion", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E4", "description": "classification_review_records for all re-classification events documenting trigger_event, prior_classification, new_classification, and rationale with effective_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E5", "description": "iso_42005_impact_assessment for high-impact-decision and eu-high-risk profile systems per ISO/IEC 42005:2025", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP-1.5 (MAP function) provides that organizational risk tolerances are determined and documented. EV-09\u2019s risk and applicability classification turns documented risk tolerances into a per-system determination of which controls and obligations apply." }, { "control": "apeiris://authority/controls/PG-07", "id": "PG-07", "domain": "authority", "name": "Policy Governance Reporting", "validation_objective": "Policy governance reports must be generated on the defined schedule for all audience tiers (executive management, audit committee, board), with every defined metric field populated from verified upstream data sources. Distribution logs must confirm delivery within the deadline for each audience.", "blocking_effect": "advisory", "evidence_required": [ "governance_report_package containing report templates per audience tier, populated metric fields, and data-source mappings for each reporting period", "report_distribution_log showing recipient, delivery timestamp, and report version for each scheduled and event-driven governance report", "reporting_pipeline_audit_trail confirming each metric value was sourced from the canonical upstream control system with no manual entry points", "audit_committee_submission_record confirming receipt of quarterly governance reports within the defined deadline", "event_driven_report_log showing supplemental reports triggered by material incidents above the defined severity threshold with generation-to-delivery elapsed time" ], "evidence": [ { "id": "PG-07-E1", "description": "governance_report_package containing report templates per audience tier, populated metric fields, and data-source mappings for each reporting period", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PG-07-E2", "description": "report_distribution_log showing recipient, delivery timestamp, and report version for each scheduled and event-driven governance report", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PG-07-E3", "description": "reporting_pipeline_audit_trail confirming each metric value was sourced from the canonical upstream control system with no manual entry points", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PG-07-E4", "description": "audit_committee_submission_record confirming receipt of quarterly governance reports within the defined deadline", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PG-07-E5", "description": "event_driven_report_log showing supplemental reports triggered by material incidents above the defined severity threshold with generation-to-delivery elapsed time", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://ethics/controls/EF-03", "id": "EF-03", "domain": "ethics", "name": "Ethical Risk Appetite Definition", "validation_objective": "The organization must have a board-approved Ethical Risk Appetite Statement specifying at least one absolute prohibition (zero-tolerance harm type that unconditionally blocks deployment), at least one conditional tolerance band with a measurable residual risk threshold, and a documented exception governance process naming the authority level required to grant exceptions. Every high-risk AI system deployment decision must reference the applicable risk appetite tier in its documentation.", "blocking_effect": "blocks-deployment", "evidence_required": [ "ethical_risk_appetite_statement document with board_approval_record, approval_date, and version, containing an absolute_prohibitions list with named harm types and a conditional_tolerance_bands list with measurable residual_risk_thresholds", "exception_governance_process_document specifying who holds exception authority by harm category, required documentation for each exception request, and conditions that trigger escalation to board level", "ai_system_deployment_records for all high-risk systems linking each deployment decision to the applicable risk_appetite_tier and referencing the current statement version", "exception_register with each entry including system_id, harm_type, approver_role, approval_date, rationale, and next_review_date", "annual_review_completion_record with board re-approval date and change log for the current review cycle" ], "evidence": [ { "id": "EF-03-E1", "description": "ethical_risk_appetite_statement document with board_approval_record, approval_date, and version, containing an absolute_prohibitions list with named harm types and a conditional_tolerance_bands list with measurable residual_risk_thresholds", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-03-E2", "description": "exception_governance_process_document specifying who holds exception authority by harm category, required documentation for each exception request, and conditions that trigger escalation to board level", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-03-E3", "description": "ai_system_deployment_records for all high-risk systems linking each deployment decision to the applicable risk_appetite_tier and referencing the current statement version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-03-E4", "description": "exception_register with each entry including system_id, harm_type, approver_role, approval_date, rationale, and next_review_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EF-03-E5", "description": "annual_review_completion_record with board re-approval date and change log for the current review cycle", "evidence_type": "audit-log", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN 1.3 requires that organizational risk tolerance for AI is defined and communicated, and GOVERN 4.1 requires that organizational risk posture is reflected in deployment decisions. The Ethical Risk Appetite Statement directly operationalizes both requirements." } ] }, { "requirement_id": "MANAGE-1.4", "section": "MANAGE 1.4", "title": "AI risk, response, and residual risk documented", "text": "AI risk and its associated response and residual risk documentation are maintained.", "verdict": "supported", "coverage": "direct", "notes": "CR-02 archives model risk and evaluation evidence; PE-01 maintains the policy evidence archive; AG-05 documents the agent incident response program including risk response decisions.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/CR-02", "id": "CR-02", "domain": "model", "name": "Model Evidence Archive and Audit Trail", "validation_objective": "All evaluation results, monitoring snapshots, incident records, and regulatory submissions must be stored in an immutable, content-addressed archive with cryptographic integrity protection; any audit query for a model's historical evidence must resolve to a complete, tamper-evident chain spanning the full production lifetime of that model version.", "blocking_effect": "blocks-deployment", "evidence_required": [ "archive_integrity_configuration_record showing content-addressed storage settings, hash algorithm (minimum SHA-256), write-once immutability enforcement, and retention policy duration per record type", "evidence_chain_completeness_audit confirming that evaluation results, monitoring snapshots, and incident records for each production model version are present in the archive with no missing lifecycle entries", "tamper_detection_scan_report from periodic archive integrity verification showing all stored records produce matching content hashes with zero reported mismatches", "regulatory_submission_evidence_linkage_record linking each regulatory submission to its archived evidence artifact with submission_id, submission_date, submitting_entity, and archive_content_hash", "archive_access_control_audit_log confirming write operations are restricted to authorized pipeline components only and all access attempts are logged with actor_id and timestamp" ], "evidence": [ { "id": "CR-02-E1", "description": "archive_integrity_configuration_record showing content-addressed storage settings, hash algorithm (minimum SHA-256), write-once immutability enforcement, and retention policy duration per record type", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "CR-02-E2", "description": "evidence_chain_completeness_audit confirming that evaluation results, monitoring snapshots, and incident records for each production model version are present in the archive with no missing lifecycle entries", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-02-E3", "description": "tamper_detection_scan_report from periodic archive integrity verification showing all stored records produce matching content hashes with zero reported mismatches", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-02-E4", "description": "regulatory_submission_evidence_linkage_record linking each regulatory submission to its archived evidence artifact with submission_id, submission_date, submitting_entity, and archive_content_hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-02-E5", "description": "archive_access_control_audit_log confirming write operations are restricted to authorized pipeline components only and all access attempts are logged with actor_id and timestamp", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN-1.4 (GOVERN function) provides that the risk management process and its outcomes are established through transparent policies, procedures, and controls. CR-02\u2019s immutable, content-addressed evidence archive preserves the documented outcomes of the risk management process so they remain reviewable and transparent over time." }, { "control": "apeiris://authority/controls/PE-01", "id": "PE-01", "domain": "authority", "name": "Policy Evidence Archive", "validation_objective": "All policy evidence artifacts must be stored in a tamper-evident, versioned archive where entries are immutable once committed, indexed by artifact type and control ID, and retrievable within the defined SLA during regulatory examination or litigation hold. The archive must produce a cryptographic proof of immutability on demand.", "blocking_effect": "blocks-deployment", "evidence_required": [ "archive_commit_log showing every artifact entry with artifact_id, control_id, committed_at timestamp, SHA-256 hash, and committer identity \u2014 with no modification events after initial commit", "tamper_evidence_record containing the Merkle root or audit log hash for the archive state at each quarterly checkpoint, signed by the archive operator", "retrieval_test_record showing that a representative sample of archived artifacts was successfully retrieved within the defined SLA, with retrieval timestamps and artifact hashes", "litigation_hold_activation_record documenting hold scope, activation timestamp, and confirmation that affected artifacts are locked against deletion for the hold duration", "archive_access_control_manifest listing authorized readers and writers with role assignments, confirming write access is restricted to the ingestion pipeline and no interactive modification is permitted" ], "evidence": [ { "id": "PE-01-E1", "description": "archive_commit_log showing every artifact entry with artifact_id, control_id, committed_at timestamp, SHA-256 hash, and committer identity \u2014 with no modification events after initial commit", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PE-01-E2", "description": "tamper_evidence_record containing the Merkle root or audit log hash for the archive state at each quarterly checkpoint, signed by the archive operator", "evidence_type": "audit-log", "verification": "automated" }, { "id": "PE-01-E3", "description": "retrieval_test_record showing that a representative sample of archived artifacts was successfully retrieved within the defined SLA, with retrieval timestamps and artifact hashes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PE-01-E4", "description": "litigation_hold_activation_record documenting hold scope, activation timestamp, and confirmation that affected artifacts are locked against deletion for the hold duration", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PE-01-E5", "description": "archive_access_control_manifest listing authorized readers and writers with role assignments, confirming write access is restricted to the ingestion pipeline and no interactive modification is permitted", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://agentic/controls/AG-05", "id": "AG-05", "domain": "agentic", "name": "Agent Incident Response Program", "validation_objective": "The enterprise has a documented, tested AI Incident Response Playbook with AI-specific containment capabilities, and every production agent has an authenticated kill-switch that demonstrably suspends its operation within 60 seconds of an authorized responder request.", "blocking_effect": "requires-review", "evidence_required": [ "AI Incident Response Playbook document covering incident classification taxonomy, severity tiers with quantitative criteria, containment actions per incident type, escalation matrix, and regulatory notification timelines", "Kill-switch capability validation records for each production agent, confirming suspension within the 60-second SLA in the most recent test", "Tabletop or functional test records for the AI Incident Response Playbook covering at least P1 and P2 severity scenarios", "Post-incident review records for all P1 and P2 events including root cause, containment timeline, and lessons-learned pipeline submissions" ], "evidence": [ { "id": "AG-05-E1", "description": "AI Incident Response Playbook document covering incident classification taxonomy, severity tiers with quantitative criteria, containment actions per incident type, escalation matrix, and regulatory notification timelines", "evidence_type": "incident-record", "verification": "attested" }, { "id": "AG-05-E2", "description": "Kill-switch capability validation records for each production agent, confirming suspension within the 60-second SLA in the most recent test", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "AG-05-E3", "description": "Tabletop or functional test records for the AI Incident Response Playbook covering at least P1 and P2 severity scenarios", "evidence_type": "incident-record", "verification": "attested" }, { "id": "AG-05-E4", "description": "Post-incident review records for all P1 and P2 events including root cause, containment timeline, and lessons-learned pipeline submissions", "evidence_type": "incident-record", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MANAGE 4.3 requires processes for tracking, responding to, and recovering from AI incidents and errors, with communication to relevant AI actors. An agent-specific incident response program with playbooks and regulatory notification procedures is the direct implementation." } ] }, { "requirement_id": "MANAGE-2.1", "section": "MANAGE 2.1", "title": "Resources for AI risk management allocated", "text": "Resources required to manage AI risks are identified and allocated appropriately.", "verdict": "partial", "coverage": "partial", "notes": "AG-04 establishes senior accountability for autonomous AI systems, implying resource commitment; OA-01 assigns model ownership; EG-03 anchors board-level ethics accountability. Specific resource allocation processes and budget governance for AI risk management are not explicitly addressed.", "control_count": 3, "proof_chain": [ { "control": "apeiris://agentic/controls/AG-04", "id": "AG-04", "domain": "agentic", "name": "Senior Accountability for Autonomous AI Systems", "validation_objective": "Every AI agent operating at Medium consequence tier or above has a named accountable owner recorded in both the agent registry and the enterprise risk register, and that owner has formally signed the agent's authorization scope declaration and completed their most recent annual reaffirmation.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Agent registry entries for all Medium-tier-and-above agents showing named accountable owner, seniority level, assignment date, and scope declaration reference", "Signed authorization scope declaration for each in-scope agent, bearing the accountable owner's identity and the date of most recent reaffirmation", "Enterprise risk register entries linking each in-scope agent to its named accountable owner and consequence tier", "Annual reaffirmation records for each accountable owner assignment, confirming reaffirmation within the required cadence" ], "evidence": [ { "id": "AG-04-E1", "description": "Agent registry entries for all Medium-tier-and-above agents showing named accountable owner, seniority level, assignment date, and scope declaration reference", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-04-E2", "description": "Signed authorization scope declaration for each in-scope agent, bearing the accountable owner's identity and the date of most recent reaffirmation", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-04-E3", "description": "Enterprise risk register entries linking each in-scope agent to its named accountable owner and consequence tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-04-E4", "description": "Annual reaffirmation records for each accountable owner assignment, confirming reaffirmation within the required cadence", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN 2.3 requires executive leadership to take responsibility for decisions about risks associated with AI system development and deployment. Named senior accountable owners for autonomous systems are the direct organizational implementation." }, { "control": "apeiris://model/controls/OA-01", "id": "OA-01", "domain": "model", "name": "Model Ownership Assignment", "validation_objective": "Every AI model in the production model registry must have a non-null named human owner who is a current employee, a responsible team, and an executive sponsor at director level or above for high-impact models, all recorded within five business days of deployment. No production model may exist without a current ownership record, and ownership must be reassigned within ten business days of any owner departure.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_ownership_register_extract with fields: model_id, owner_name, owner_employee_id, team, executive_sponsor, effective_date, review_date \u2014 showing 100% coverage of production models with non-null values", "deployment_pipeline_gate_log showing blocked promotion events for models with null ownership fields, with timestamps and model IDs", "hr_departure_event_log cross-referenced with ownership_reassignment_record demonstrating reassignment within ten business days for each departure", "governance_committee_meeting_minutes containing ownership review agenda items for the preceding 12-month period" ], "evidence": [ { "id": "OA-01-E1", "description": "model_ownership_register_extract with fields: model_id, owner_name, owner_employee_id, team, executive_sponsor, effective_date, review_date \u2014 showing 100% coverage of production models with non-null values", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-01-E2", "description": "deployment_pipeline_gate_log showing blocked promotion events for models with null ownership fields, with timestamps and model IDs", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-01-E3", "description": "hr_departure_event_log cross-referenced with ownership_reassignment_record demonstrating reassignment within ten business days for each departure", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-01-E4", "description": "governance_committee_meeting_minutes containing ownership review agenda items for the preceding 12-month period", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN-2.1 (GOVERN function) provides that roles, responsibilities, and lines of communication for AI risk management are documented and clear. OA-01\u2019s named-owner register documents the ownership and accountability lines this subcategory requires for every production model." }, { "control": "apeiris://ethics/controls/EG-03", "id": "EG-03", "domain": "ethics", "name": "Senior and Board-Level Ethics Accountability", "validation_objective": "The organization must have a named C-suite executive with documented AI ethics accountability and evidence of at least semi-annual board-level AI ethics briefings within the trailing 12 months. Executive performance objectives must include AI ethics KPIs linked to measurable program outcomes.", "blocking_effect": "requires-review", "evidence_required": [ "executive_accountability_assignment showing named C-suite role, documented accountability scope, and date of assignment in role description or governance framework", "board_briefing_records from past 12 months confirming AI ethics posture, material risks, and incident status were presented, with meeting minutes or attendance logs", "executive_performance_objectives document showing AI ethics KPIs included in C-suite scorecards with defined targets and measurement periods", "material_risk_escalation_procedure document defining thresholds that trigger immediate C-suite notification with named escalation contacts and SLA" ], "evidence": [ { "id": "EG-03-E1", "description": "executive_accountability_assignment showing named C-suite role, documented accountability scope, and date of assignment in role description or governance framework", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-03-E2", "description": "board_briefing_records from past 12 months confirming AI ethics posture, material risks, and incident status were presented, with meeting minutes or attendance logs", "evidence_type": "incident-record", "verification": "attested" }, { "id": "EG-03-E3", "description": "executive_performance_objectives document showing AI ethics KPIs included in C-suite scorecards with defined targets and measurement periods", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-03-E4", "description": "material_risk_escalation_procedure document defining thresholds that trigger immediate C-suite notification with named escalation contacts and SLA", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN 2.1 requires that organizational leadership establishes and maintains oversight structures for AI risk, including senior leadership accountability. Board-level reporting and C-suite accountability directly implement this function." } ] }, { "requirement_id": "MANAGE-2.2", "section": "MANAGE 2.2", "title": "Mechanisms to identify and neutralize AI risks", "text": "Mechanisms are established to identify, evaluate, and neutralize AI risks on an ongoing basis.", "verdict": "supported", "coverage": "direct", "notes": "RT-04 detects anomalies and triggers pause, kill switch, or containment; AM-07 enables real-time alerting and automated agent suspension; BH-01 detects output anomalies \u2014 providing multi-layer risk neutralization.", "control_count": 3, "proof_chain": [ { "control": "apeiris://security/controls/RT-04", "id": "RT-04", "domain": "security", "name": "Detect anomalies and trigger pause, kill switch, or containment", "validation_objective": "The system must provide graduated, agent-external response mechanisms \u2014 a graceful pause for human review, a hard kill on provenance failure, and endpoint isolation on lateral movement \u2014 each enforced outside the agent's execution context and capable of revoking delegated tokens and terminating tool-side jobs. All three response tiers must activate within defined time-to-contain bounds validated in timed drills.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "kill_switch_drill_record showing trigger_condition, response_tier_activated (R1/R2/R3), time_to_contain, confirmation that delegated tokens were revoked, and tool-side jobs terminated", "graceful_pause_drill_record confirming pause-for-review is distinct from hard kill and was activated successfully without requiring agent cooperation", "anomaly_trigger_definition_document listing the specific conditions (provenance failure, unverifiable action, lateral movement indicator) that activate each response tier", "containment_event_log from any real events showing trigger, response tier, time-to-contain, and post-incident review outcome" ], "evidence": [ { "id": "RT-04-E1", "description": "kill_switch_drill_record showing trigger_condition, response_tier_activated (R1/R2/R3), time_to_contain, confirmation that delegated tokens were revoked, and tool-side jobs terminated", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-04-E2", "description": "graceful_pause_drill_record confirming pause-for-review is distinct from hard kill and was activated successfully without requiring agent cooperation", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RT-04-E3", "description": "anomaly_trigger_definition_document listing the specific conditions (provenance failure, unverifiable action, lateral movement indicator) that activate each response tier", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "RT-04-E4", "description": "containment_event_log from any real events showing trigger, response tier, time-to-contain, and post-incident review outcome", "evidence_type": "incident-record", "verification": "attested" } ], "fit": "adjacent", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF Manage function: prioritise and act on the identified AI risks, treating, responding, recovering, and allocating resources. \"Detect anomalies and trigger pause, kill switch, or containment\" is a corresponding risk-treatment activity." }, { "control": "apeiris://agentic/controls/AM-07", "id": "AM-07", "domain": "agentic", "name": "Real-Time Alerting and Automated Agent Suspension", "validation_objective": "Prove that the enterprise has implemented a four-tier alert escalation model for agent behavioral violations and that automated suspension is capable of halting an offending agent within 60 seconds of a critical trigger while preserving session state for forensic review. Validate that reinstatement requires documented human authorization.", "blocking_effect": "advisory", "evidence_required": [ "Documented four-tier alert tier definitions with explicit trigger conditions (threshold values or violation patterns), SLAs, and escalation paths for tiers 3 and 4", "On-call pager integration configuration confirming tier-3 and tier-4 alerts route to the security team with SLA clock activation", "Most recent suspension exercise record demonstrating the full suspension-to-reinstatement path was tested in a live or near-production environment, not only in tabletop", "Quarterly alert effectiveness review report documenting false positive rates by tier and threshold tuning decisions made during the review period" ], "evidence": [ { "id": "AM-07-E1", "description": "Documented four-tier alert tier definitions with explicit trigger conditions (threshold values or violation patterns), SLAs, and escalation paths for tiers 3 and 4", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "AM-07-E2", "description": "On-call pager integration configuration confirming tier-3 and tier-4 alerts route to the security team with SLA clock activation", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "AM-07-E3", "description": "Most recent suspension exercise record demonstrating the full suspension-to-reinstatement path was tested in a live or near-production environment, not only in tabletop", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AM-07-E4", "description": "Quarterly alert effectiveness review report documenting false positive rates by tier and threshold tuning decisions made during the review period", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MANAGE 4.3 requires incidents and errors to be communicated to relevant AI actors, with documented processes for tracking, response, and recovery. Real-time alerting with automated suspension implements the response half at machine speed, preserving state for the documented recovery process." }, { "control": "apeiris://model/controls/BH-01", "id": "BH-01", "domain": "model", "name": "Output Anomaly Detection", "validation_objective": "The production inference endpoint must be continuously sampled and output distributions must be statistically compared against a versioned, SHA-256-signed baseline artifact using PSI and Shewhart/EWMA control chart methods, such that any distribution shift exceeding PSI 0.2 fires a tiered alert within one monitoring window of the shift occurring and all anomaly events are stored in the evidence registry with BH-01 control linkage.", "blocking_effect": "advisory", "evidence_required": [ "versioned, SHA-256-signed baseline distribution artifact stored in the model registry with per-metric statistics (mean, std_dev, p5/p50/p95/p99) computed from the 30-day post-deployment stable window", "SPC alert log for trailing 90 days with fields: alert_id, trigger_metric, psi_value, alert_severity, triggered_at, acknowledged_at, and resolution_outcome", "PII masking audit record confirming no direct identifier fields (email, SSN, full name) appear in the sampled output storage for the trailing 30 days", "quarterly threshold review sign-off from model owner confirming PSI alert (0.2) and critical (0.25) thresholds remain appropriate for the current deployment context" ], "evidence": [ { "id": "BH-01-E1", "description": "versioned, SHA-256-signed baseline distribution artifact stored in the model registry with per-metric statistics (mean, std_dev, p5/p50/p95/p99) computed from the 30-day post-deployment stable window", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-01-E2", "description": "SPC alert log for trailing 90 days with fields: alert_id, trigger_metric, psi_value, alert_severity, triggered_at, acknowledged_at, and resolution_outcome", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "BH-01-E3", "description": "PII masking audit record confirming no direct identifier fields (email, SSN, full name) appear in the sampled output storage for the trailing 30 days", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-01-E4", "description": "quarterly threshold review sign-off from model owner confirming PSI alert (0.2) and critical (0.25) thresholds remain appropriate for the current deployment context", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.4 (MEASURE function) provides that the functionality and behavior of the AI system and its components are monitored when in production. BH-01\u2019s statistical process control over output distributions is production monitoring of system behavior, with signed baselines and tiered alerting." } ] }, { "requirement_id": "MANAGE-2.3", "section": "MANAGE 2.3", "title": "AI risk response options considered and documented", "text": "AI risk response options are considered, selected, and documented in accordance with organizational policies.", "verdict": "supported", "coverage": "direct", "notes": "AG-05 defines the agent incident response program; EG-06 governs ethics incident response; CR-04 manages AI incident response \u2014 together covering response option selection and documentation.", "control_count": 3, "proof_chain": [ { "control": "apeiris://agentic/controls/AG-05", "id": "AG-05", "domain": "agentic", "name": "Agent Incident Response Program", "validation_objective": "The enterprise has a documented, tested AI Incident Response Playbook with AI-specific containment capabilities, and every production agent has an authenticated kill-switch that demonstrably suspends its operation within 60 seconds of an authorized responder request.", "blocking_effect": "requires-review", "evidence_required": [ "AI Incident Response Playbook document covering incident classification taxonomy, severity tiers with quantitative criteria, containment actions per incident type, escalation matrix, and regulatory notification timelines", "Kill-switch capability validation records for each production agent, confirming suspension within the 60-second SLA in the most recent test", "Tabletop or functional test records for the AI Incident Response Playbook covering at least P1 and P2 severity scenarios", "Post-incident review records for all P1 and P2 events including root cause, containment timeline, and lessons-learned pipeline submissions" ], "evidence": [ { "id": "AG-05-E1", "description": "AI Incident Response Playbook document covering incident classification taxonomy, severity tiers with quantitative criteria, containment actions per incident type, escalation matrix, and regulatory notification timelines", "evidence_type": "incident-record", "verification": "attested" }, { "id": "AG-05-E2", "description": "Kill-switch capability validation records for each production agent, confirming suspension within the 60-second SLA in the most recent test", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "AG-05-E3", "description": "Tabletop or functional test records for the AI Incident Response Playbook covering at least P1 and P2 severity scenarios", "evidence_type": "incident-record", "verification": "attested" }, { "id": "AG-05-E4", "description": "Post-incident review records for all P1 and P2 events including root cause, containment timeline, and lessons-learned pipeline submissions", "evidence_type": "incident-record", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MANAGE 4.3 requires processes for tracking, responding to, and recovering from AI incidents and errors, with communication to relevant AI actors. An agent-specific incident response program with playbooks and regulatory notification procedures is the direct implementation." }, { "control": "apeiris://ethics/controls/EG-06", "id": "EG-06", "domain": "ethics", "name": "Ethics Incident Response", "validation_objective": "The organization must have a documented AI ethics incident response procedure covering severity classification (minimum three levels), escalation timelines with named roles, investigation protocol, affected party notification procedures, and post-incident review requirements. All Level 2+ incidents must have complete escalation and investigation records within defined SLA, and post-incident reviews must be traceable to policy or system changes.", "blocking_effect": "requires-review", "evidence_required": [ "ai_ethics_incident_response_procedure document with version date, severity classification framework (minimum three levels), named escalation roles with SLA timelines, investigation protocol, affected party notification criteria, and post-incident review requirements", "ethics_incident_log for trailing 12 months showing each incident's classification, intake date, escalation timestamp, assigned investigator, resolution date, and closure status", "post_incident_review_reports for each Level 2+ incident containing root cause analysis, affected population estimate, corrective action plan with owner and deadline, and policy or system change traceable to the finding", "regulatory_notification_assessment_records for Level 3+ incidents showing evaluation of EU AI Act Art. 73 reporting obligations and notification status where applicable" ], "evidence": [ { "id": "EG-06-E1", "description": "ai_ethics_incident_response_procedure document with version date, severity classification framework (minimum three levels), named escalation roles with SLA timelines, investigation protocol, affected party notification criteria, and post-incident review requirements", "evidence_type": "incident-record", "verification": "attested" }, { "id": "EG-06-E2", "description": "ethics_incident_log for trailing 12 months showing each incident's classification, intake date, escalation timestamp, assigned investigator, resolution date, and closure status", "evidence_type": "incident-record", "verification": "attested" }, { "id": "EG-06-E3", "description": "post_incident_review_reports for each Level 2+ incident containing root cause analysis, affected population estimate, corrective action plan with owner and deadline, and policy or system change traceable to the finding", "evidence_type": "incident-record", "verification": "attested" }, { "id": "EG-06-E4", "description": "regulatory_notification_assessment_records for Level 3+ incidents showing evaluation of EU AI Act Art. 73 reporting obligations and notification status where applicable", "evidence_type": "evaluation-scorecard", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MANAGE 4.3 requires that incidents and errors are communicated to relevant AI actors and that processes for tracking, responding to, and recovering from them are followed and documented. This control implements the incident identification, escalation, and remediation elements of that requirement for ethics incidents." }, { "control": "apeiris://model/controls/CR-04", "id": "CR-04", "domain": "model", "name": "AI Incident Response Management", "validation_objective": "The organization must have a documented, version-controlled AI Incident Response Plan (AIRP) with AI-specific containment playbooks covering model rollback, output-filter enforcement, traffic shaping, and full model shutdown \u2014 tested via at least four quarterly tabletop exercises per year using MITRE ATLAS adversarial scenarios \u2014 and P1/P2 post-incident review records produced within 5 days of event resolution for all qualifying events in the trailing 12 months.", "blocking_effect": "blocks-deployment", "evidence_required": [ "AI Incident Response Plan document (version-controlled, CISO or AI-risk-owner signed, with review date within 12 months)", "Containment playbook index listing separate runbooks for model_rollback, output_filter_enforcement, traffic_shaping, and model_shutdown_with_fallback", "Last 4 quarterly tabletop exercise reports with MITRE ATLAS scenario identifier, participant roster, outcomes, and reviewer sign-off", "P1 and P2 post-incident review records for all qualifying events in the trailing 12 months, each showing post_incident_report_date within 5 days of incident_resolved_date", "EU Art. 73 notification trigger mapping document showing which P1 severity criteria trigger the Art. 73 serious-incident notification obligation (15d general / 10d death / 2d widespread or critical infrastructure)" ], "evidence": [ { "id": "CR-04-E1", "description": "AI Incident Response Plan document (version-controlled, CISO or AI-risk-owner signed, with review date within 12 months)", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-04-E2", "description": "Containment playbook index listing separate runbooks for model_rollback, output_filter_enforcement, traffic_shaping, and model_shutdown_with_fallback", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-04-E3", "description": "Last 4 quarterly tabletop exercise reports with MITRE ATLAS scenario identifier, participant roster, outcomes, and reviewer sign-off", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CR-04-E4", "description": "P1 and P2 post-incident review records for all qualifying events in the trailing 12 months, each showing post_incident_report_date within 5 days of incident_resolved_date", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-04-E5", "description": "EU Art. 73 notification trigger mapping document showing which P1 severity criteria trigger the Art. 73 serious-incident notification obligation (15d general / 10d death / 2d widespread or critical infrastructure)", "evidence_type": "incident-record", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MANAGE-4.1 (MANAGE function) provides that post-deployment monitoring plans are implemented, including appeal and override, decommissioning, incident response, and change management. CR-04\u2019s AI-specific incident response plan implements the incident-response and recovery components of post-deployment risk management, tested through recurring tabletop exercises." } ] }, { "requirement_id": "MANAGE-2.4", "section": "MANAGE 2.4", "title": "Negative risks of the AI system diligently addressed", "text": "Negative risks of the AI system are diligently addressed with appropriate safeguards and mitigations.", "verdict": "supported", "coverage": "direct", "notes": "GV-11 plans recovery and compensation for committed actions; AB-05 detects and defends against prompt injection; EC-06 contains runaway loops and over-reach \u2014 collectively addressing technical negative risk mitigation.", "control_count": 3, "proof_chain": [ { "control": "apeiris://security/controls/GV-11", "id": "GV-11", "domain": "security", "name": "Plan recovery and compensation for actions the agent already committed", "validation_objective": "Before any high-impact agent action executes it is classified as reversible, compensable, or irreversible; reversible and compensable actions have a registered, tested compensating workflow the orchestrator fires automatically on a hard-stop or anomaly signal; and irreversible effects that cannot be compensated are escalated to the named business owner with a packaged evidence record within a defined SLA.", "blocking_effect": "blocks-deployment", "evidence_required": [ "reversibility_classification_register listing each high-impact action type with its classification (reversible, compensable, or irreversible) and the registered compensating workflow reference or owner-escalation path", "pre_action_snapshot_log confirming state snapshots were created before each reversible or compensable action executed, with snapshot_id and target resource reference", "compensation_execution_record for each hard-stop event showing which compensating workflows fired, which completed successfully, and which required manual intervention", "irreversible_effect_escalation_record showing escalations to the named business owner with evidence package reference and resolution time against the defined SLA", "compensation_drill_record from the most recent scheduled exercise where a stop was triggered and compensating workflows were executed end-to-end in a staging environment" ], "evidence": [ { "id": "GV-11-E1", "description": "reversibility_classification_register listing each high-impact action type with its classification (reversible, compensable, or irreversible) and the registered compensating workflow reference or owner-escalation path", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-11-E2", "description": "pre_action_snapshot_log confirming state snapshots were created before each reversible or compensable action executed, with snapshot_id and target resource reference", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-11-E3", "description": "compensation_execution_record for each hard-stop event showing which compensating workflows fired, which completed successfully, and which required manual intervention", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-11-E4", "description": "irreversible_effect_escalation_record showing escalations to the named business owner with evidence package reference and resolution time against the defined SLA", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-11-E5", "description": "compensation_drill_record from the most recent scheduled exercise where a stop was triggered and compensating workflows were executed end-to-end in a staging environment", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "adjacent", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF Manage function: prioritise and act on the identified AI risks, treating, responding, recovering, and allocating resources. \"Plan recovery and compensation for actions the agent already committed\" is a corresponding risk-treatment activity." }, { "control": "apeiris://agentic/controls/AB-05", "id": "AB-05", "domain": "agentic", "name": "Prompt Injection Detection and Defense", "validation_objective": "Prove that the agent's input processing pipeline detects and mitigates prompt injection attempts \u2014 both direct user injection and indirect injection via retrieved documents, tool outputs, or external data sources \u2014 and that detected injection attempts are blocked and logged before influencing agent behavior, with alerts routed to the security monitoring function.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "Prompt injection detection configuration with active detection rules or classifiers covering direct instruction-override patterns and indirect injection via retrieved content", "Detection log from the test period showing injection attempt events with outcome (blocked, flagged, or allowed with rationale), content hashes, and timestamps", "Red team or automated adversarial test results covering indirect injection via at least one document retrieval or tool output vector specific to the agent's data sources", "Alert routing records confirming injection detection events are delivered to the security monitoring function within a defined SLA" ], "evidence": [ { "id": "AB-05-E1", "description": "Prompt injection detection configuration with active detection rules or classifiers covering direct instruction-override patterns and indirect injection via retrieved content", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "AB-05-E2", "description": "Detection log from the test period showing injection attempt events with outcome (blocked, flagged, or allowed with rationale), content hashes, and timestamps", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AB-05-E3", "description": "Red team or automated adversarial test results covering indirect injection via at least one document retrieval or tool output vector specific to the agent's data sources", "evidence_type": "red-team-report", "verification": "third-party" }, { "id": "AB-05-E4", "description": "Alert routing records confirming injection detection events are delivered to the security monitoring function within a defined SLA", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://security/controls/EC-06", "id": "EC-06", "domain": "security", "name": "Contain runaway loops and over-reach (least-agency)", "validation_objective": "Every agent execution must be subject to a deterministic iteration cap, a recursion depth limit, and tool-call frequency circuit breakers enforced by the orchestration runtime \u2014 not by the agent itself. When any cap is reached the runtime must issue a hard exit and record the termination with iteration count and triggering condition. The agent's autonomy scope must not exceed the minimum required for the current task as defined by the least-agency principle.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "orchestration_runtime_config showing active loop cap, recursion depth limit, and circuit-breaker thresholds per agent task type", "loop_termination_log showing task_id, iteration_count_at_termination, termination_reason (cap_reached / circuit_breaker / human_interrupt), and timestamp", "autonomy_scope_definition per task type documenting the authorized autonomy level and least-agency justification", "circuit_breaker_event_log showing tool-call frequency threshold breaches with tool_id, call_rate, threshold, and action taken (pause/terminate)" ], "evidence": [ { "id": "EC-06-E1", "description": "orchestration_runtime_config showing active loop cap, recursion depth limit, and circuit-breaker thresholds per agent task type", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-06-E2", "description": "loop_termination_log showing task_id, iteration_count_at_termination, termination_reason (cap_reached / circuit_breaker / human_interrupt), and timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-06-E3", "description": "autonomy_scope_definition per task type documenting the authorized autonomy level and least-agency justification", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-06-E4", "description": "circuit_breaker_event_log showing tool-call frequency threshold breaches with tool_id, call_rate, threshold, and action taken (pause/terminate)", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "adjacent", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF Manage function: prioritise and act on the identified AI risks, treating, responding, recovering, and allocating resources. \"Contain runaway loops and over-reach (least-agency)\" is a corresponding risk-treatment activity." } ] }, { "requirement_id": "MANAGE-3.1", "section": "MANAGE 3.1", "title": "AI risks and treatment status tracked per organizational policies", "text": "AI risks and their treatment status are tracked and stored in accordance with organizational policies.", "verdict": "supported", "coverage": "direct", "notes": "PG-01 monitors policy adherence and tracks risk status; CR-01 provides continuous production monitoring and risk aggregation; AG-06 tracks agent program metrics and KPIs over time.", "control_count": 3, "proof_chain": [ { "control": "apeiris://authority/controls/PG-01", "id": "PG-01", "domain": "authority", "name": "Policy Adherence Monitoring", "validation_objective": "All in-scope AI systems must have 100% of their active internal policies represented by machine-evaluable monitoring rules in the policy registry, with every AI system action evaluated against applicable rules in real time, and deviation alerts routed to accountable reviewers within the documented SLA.", "blocking_effect": "advisory", "evidence_required": [ "Policy registry export listing all active internal policies with corresponding machine-evaluable rule definitions, effective dates, and policy source references", "Policy evaluation engine event logs showing per-action rule evaluation outcomes, deviation alert generation timestamps, and SLA compliance metrics for the reporting period", "Compliance monitoring SLA definition document signed by the Compliance Officer, specifying alert routing targets and resolution timeframes", "Monitoring coverage report confirming the percentage of in-scope AI systems and action types evaluated against active policy rules, with no coverage gaps documented without risk acceptance" ], "evidence": [ { "id": "PG-01-E1", "description": "Policy registry export listing all active internal policies with corresponding machine-evaluable rule definitions, effective dates, and policy source references", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "PG-01-E2", "description": "Policy evaluation engine event logs showing per-action rule evaluation outcomes, deviation alert generation timestamps, and SLA compliance metrics for the reporting period", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "PG-01-E3", "description": "Compliance monitoring SLA definition document signed by the Compliance Officer, specifying alert routing targets and resolution timeframes", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "PG-01-E4", "description": "Monitoring coverage report confirming the percentage of in-scope AI systems and action types evaluated against active policy rules, with no coverage gaps documented without risk acceptance", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "Continuous adherence monitoring helps identify emergent policy risks, partially addressing MEASURE 3.1." }, { "control": "apeiris://model/controls/CR-01", "id": "CR-01", "domain": "model", "name": "Continuous Production Monitoring and Risk Aggregation", "validation_objective": "All runtime monitoring signals \u2014 performance, drift, fairness, safety incidents, and deployment event flags \u2014 must be continuously aggregated into a unified risk dashboard with pre-configured automated alerting thresholds; any degradation in a monitored dimension must be detected and an alert dispatched within one operational window.", "blocking_effect": "advisory", "evidence_required": [ "risk_dashboard_configuration_record showing all registered signal feeds (performance, drift, fairness, safety, incident), their alert thresholds, assigned monitoring window duration, and escalation recipients", "alert_audit_log covering at least 30 days showing triggered alerts with signal_type, threshold_crossed, alert_timestamp, and escalation_recipient for each alert", "monitoring_coverage_audit confirming every deployed model version has an associated monitoring configuration with no version gaps", "risk_aggregation_methodology_document defining how individual dimension alerts are combined into composite risk scores and dashboard status indicators", "post-market_monitoring_report satisfying EU AI Act Art. 72 covering the monitoring period, key findings, and corrective actions taken or planned" ], "evidence": [ { "id": "CR-01-E1", "description": "risk_dashboard_configuration_record showing all registered signal feeds (performance, drift, fairness, safety, incident), their alert thresholds, assigned monitoring window duration, and escalation recipients", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-01-E2", "description": "alert_audit_log covering at least 30 days showing triggered alerts with signal_type, threshold_crossed, alert_timestamp, and escalation_recipient for each alert", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E3", "description": "monitoring_coverage_audit confirming every deployed model version has an associated monitoring configuration with no version gaps", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E4", "description": "risk_aggregation_methodology_document defining how individual dimension alerts are combined into composite risk scores and dashboard status indicators", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E5", "description": "post-market_monitoring_report satisfying EU AI Act Art. 72 covering the monitoring period, key findings, and corrective actions taken or planned", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.4 (MEASURE function) provides that the functionality and behavior of the AI system and its components are monitored when in production. CR-01 aggregates production monitoring signals \u2014 performance, drift, fairness, safety, cost \u2014 into a single risk view with calibrated alert thresholds." }, { "control": "apeiris://agentic/controls/AG-06", "id": "AG-06", "domain": "agentic", "name": "Agent Program Metrics and KPIs", "validation_objective": "The enterprise collects and reports a defined set of agentic AI governance KPIs from automated pipelines on a defined frequency, and the governance committee receives current-period metric values with trend data and threshold breach alerts at each governance review meeting.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Published Agentic AI Program Metrics Catalog defining each KPI: name, formula, data source, reporting frequency, metric owner, and target threshold with current baseline", "Automated governance dashboard outputs from at least the three most recent reporting periods showing coverage, process, outcome, and attestation metrics", "Governance committee meeting records confirming receipt and review of metrics reports and documenting threshold breach discussions and directed actions", "Data pipeline lineage documentation showing the authoritative source for each KPI and the automated collection process" ], "evidence": [ { "id": "AG-06-E1", "description": "Published Agentic AI Program Metrics Catalog defining each KPI: name, formula, data source, reporting frequency, metric owner, and target threshold with current baseline", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-06-E2", "description": "Automated governance dashboard outputs from at least the three most recent reporting periods showing coverage, process, outcome, and attestation metrics", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "AG-06-E3", "description": "Governance committee meeting records confirming receipt and review of metrics reports and documenting threshold breach discussions and directed actions", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AG-06-E4", "description": "Data pipeline lineage documentation showing the authoritative source for each KPI and the automated collection process", "evidence_type": "data-lineage-record", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE 1.1 requires approaches and metrics for AI risk measurement to be selected and implemented. A defined agentic program metrics catalog with coverage, incident, and drift KPIs is that selection, made explicit and reviewable." } ] }, { "requirement_id": "MANAGE-3.2", "section": "MANAGE 3.2", "title": "Organizational incidents investigated and procedures applied", "text": "Organizational incidents are investigated and procedures are applied for minimizing the impact and recurrence of AI incidents.", "verdict": "supported", "coverage": "direct", "notes": "CR-04 manages AI incident response; AG-05 defines the agent incident response program; EG-06 covers ethics incident response \u2014 covering investigation, remediation, and recurrence prevention.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/CR-04", "id": "CR-04", "domain": "model", "name": "AI Incident Response Management", "validation_objective": "The organization must have a documented, version-controlled AI Incident Response Plan (AIRP) with AI-specific containment playbooks covering model rollback, output-filter enforcement, traffic shaping, and full model shutdown \u2014 tested via at least four quarterly tabletop exercises per year using MITRE ATLAS adversarial scenarios \u2014 and P1/P2 post-incident review records produced within 5 days of event resolution for all qualifying events in the trailing 12 months.", "blocking_effect": "blocks-deployment", "evidence_required": [ "AI Incident Response Plan document (version-controlled, CISO or AI-risk-owner signed, with review date within 12 months)", "Containment playbook index listing separate runbooks for model_rollback, output_filter_enforcement, traffic_shaping, and model_shutdown_with_fallback", "Last 4 quarterly tabletop exercise reports with MITRE ATLAS scenario identifier, participant roster, outcomes, and reviewer sign-off", "P1 and P2 post-incident review records for all qualifying events in the trailing 12 months, each showing post_incident_report_date within 5 days of incident_resolved_date", "EU Art. 73 notification trigger mapping document showing which P1 severity criteria trigger the Art. 73 serious-incident notification obligation (15d general / 10d death / 2d widespread or critical infrastructure)" ], "evidence": [ { "id": "CR-04-E1", "description": "AI Incident Response Plan document (version-controlled, CISO or AI-risk-owner signed, with review date within 12 months)", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-04-E2", "description": "Containment playbook index listing separate runbooks for model_rollback, output_filter_enforcement, traffic_shaping, and model_shutdown_with_fallback", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-04-E3", "description": "Last 4 quarterly tabletop exercise reports with MITRE ATLAS scenario identifier, participant roster, outcomes, and reviewer sign-off", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CR-04-E4", "description": "P1 and P2 post-incident review records for all qualifying events in the trailing 12 months, each showing post_incident_report_date within 5 days of incident_resolved_date", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-04-E5", "description": "EU Art. 73 notification trigger mapping document showing which P1 severity criteria trigger the Art. 73 serious-incident notification obligation (15d general / 10d death / 2d widespread or critical infrastructure)", "evidence_type": "incident-record", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MANAGE-4.1 (MANAGE function) provides that post-deployment monitoring plans are implemented, including appeal and override, decommissioning, incident response, and change management. CR-04\u2019s AI-specific incident response plan implements the incident-response and recovery components of post-deployment risk management, tested through recurring tabletop exercises." }, { "control": "apeiris://agentic/controls/AG-05", "id": "AG-05", "domain": "agentic", "name": "Agent Incident Response Program", "validation_objective": "The enterprise has a documented, tested AI Incident Response Playbook with AI-specific containment capabilities, and every production agent has an authenticated kill-switch that demonstrably suspends its operation within 60 seconds of an authorized responder request.", "blocking_effect": "requires-review", "evidence_required": [ "AI Incident Response Playbook document covering incident classification taxonomy, severity tiers with quantitative criteria, containment actions per incident type, escalation matrix, and regulatory notification timelines", "Kill-switch capability validation records for each production agent, confirming suspension within the 60-second SLA in the most recent test", "Tabletop or functional test records for the AI Incident Response Playbook covering at least P1 and P2 severity scenarios", "Post-incident review records for all P1 and P2 events including root cause, containment timeline, and lessons-learned pipeline submissions" ], "evidence": [ { "id": "AG-05-E1", "description": "AI Incident Response Playbook document covering incident classification taxonomy, severity tiers with quantitative criteria, containment actions per incident type, escalation matrix, and regulatory notification timelines", "evidence_type": "incident-record", "verification": "attested" }, { "id": "AG-05-E2", "description": "Kill-switch capability validation records for each production agent, confirming suspension within the 60-second SLA in the most recent test", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "AG-05-E3", "description": "Tabletop or functional test records for the AI Incident Response Playbook covering at least P1 and P2 severity scenarios", "evidence_type": "incident-record", "verification": "attested" }, { "id": "AG-05-E4", "description": "Post-incident review records for all P1 and P2 events including root cause, containment timeline, and lessons-learned pipeline submissions", "evidence_type": "incident-record", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MANAGE 4.3 requires processes for tracking, responding to, and recovering from AI incidents and errors, with communication to relevant AI actors. An agent-specific incident response program with playbooks and regulatory notification procedures is the direct implementation." }, { "control": "apeiris://ethics/controls/EG-06", "id": "EG-06", "domain": "ethics", "name": "Ethics Incident Response", "validation_objective": "The organization must have a documented AI ethics incident response procedure covering severity classification (minimum three levels), escalation timelines with named roles, investigation protocol, affected party notification procedures, and post-incident review requirements. All Level 2+ incidents must have complete escalation and investigation records within defined SLA, and post-incident reviews must be traceable to policy or system changes.", "blocking_effect": "requires-review", "evidence_required": [ "ai_ethics_incident_response_procedure document with version date, severity classification framework (minimum three levels), named escalation roles with SLA timelines, investigation protocol, affected party notification criteria, and post-incident review requirements", "ethics_incident_log for trailing 12 months showing each incident's classification, intake date, escalation timestamp, assigned investigator, resolution date, and closure status", "post_incident_review_reports for each Level 2+ incident containing root cause analysis, affected population estimate, corrective action plan with owner and deadline, and policy or system change traceable to the finding", "regulatory_notification_assessment_records for Level 3+ incidents showing evaluation of EU AI Act Art. 73 reporting obligations and notification status where applicable" ], "evidence": [ { "id": "EG-06-E1", "description": "ai_ethics_incident_response_procedure document with version date, severity classification framework (minimum three levels), named escalation roles with SLA timelines, investigation protocol, affected party notification criteria, and post-incident review requirements", "evidence_type": "incident-record", "verification": "attested" }, { "id": "EG-06-E2", "description": "ethics_incident_log for trailing 12 months showing each incident's classification, intake date, escalation timestamp, assigned investigator, resolution date, and closure status", "evidence_type": "incident-record", "verification": "attested" }, { "id": "EG-06-E3", "description": "post_incident_review_reports for each Level 2+ incident containing root cause analysis, affected population estimate, corrective action plan with owner and deadline, and policy or system change traceable to the finding", "evidence_type": "incident-record", "verification": "attested" }, { "id": "EG-06-E4", "description": "regulatory_notification_assessment_records for Level 3+ incidents showing evaluation of EU AI Act Art. 73 reporting obligations and notification status where applicable", "evidence_type": "evaluation-scorecard", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MANAGE 4.3 requires that incidents and errors are communicated to relevant AI actors and that processes for tracking, responding to, and recovering from them are followed and documented. This control implements the incident identification, escalation, and remediation elements of that requirement for ethics incidents." } ] }, { "requirement_id": "MANAGE-4.1", "section": "MANAGE 4.1", "title": "AI system feedback checked against risk levels", "text": "Particular AI system feedback is checked regularly against established risk levels.", "verdict": "supported", "coverage": "direct", "notes": "BH-10 governs feedback loop integrity and online learning; AM-09 reconciles action effects against expected outcomes; CR-06 conducts post-market surveillance \u2014 providing systematic risk-level-checking from multiple feedback channels.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/BH-10", "id": "BH-10", "domain": "model", "name": "Feedback Loop Integrity and Online Learning Governance", "validation_objective": "All feedback pathways that influence model behavior after deployment \u2014 including RLHF/RLAIF labeler inputs, online learning update triggers, and reward signal channels \u2014 must pass through authorization gates with poisoning detection active at each ingestion point; no unreviewed, anomalous, or flagged feedback must modify model weights or behavior in production without an explicit authorization record.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "feedback_authorization_gate_record per feedback batch showing batch_id, inter-annotator agreement score, outlier labeler flags, approver_id, and authorization_timestamp before pipeline ingestion", "labeler_quality_control_report showing inter-annotator agreement scores, outlier labeler detection results, and remediation action taken for any flagged labeler within the reporting period", "feedback_poisoning_detection_log showing anomaly detection results on incoming feedback signals including label distribution shift analysis, adversarial pattern flags, and disposition per batch", "online_learning_authorization_record per model update triggered by live feedback, showing trigger_condition, validation_check_results, authorized_parameter_bounds, and authorization_decision", "reward_model_evaluation_report confirming the reward model was evaluated for reward hacking vulnerability and known adversarial prompting strategies before deployment to RLHF pipeline" ], "evidence": [ { "id": "BH-10-E1", "description": "feedback_authorization_gate_record per feedback batch showing batch_id, inter-annotator agreement score, outlier labeler flags, approver_id, and authorization_timestamp before pipeline ingestion", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-10-E2", "description": "labeler_quality_control_report showing inter-annotator agreement scores, outlier labeler detection results, and remediation action taken for any flagged labeler within the reporting period", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-10-E3", "description": "feedback_poisoning_detection_log showing anomaly detection results on incoming feedback signals including label distribution shift analysis, adversarial pattern flags, and disposition per batch", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-10-E4", "description": "online_learning_authorization_record per model update triggered by live feedback, showing trigger_condition, validation_check_results, authorized_parameter_bounds, and authorization_decision", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-10-E5", "description": "reward_model_evaluation_report confirming the reward model was evaluated for reward hacking vulnerability and known adversarial prompting strategies before deployment to RLHF pipeline", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MANAGE-4.1 (MANAGE function) provides that post-deployment monitoring plans are implemented, including appeal and override, decommissioning, incident response, and change management. BH-10\u2019s feedback-loop governance is the change-management component of post-deployment monitoring for models whose behavior evolves after release." }, { "control": "apeiris://agentic/controls/AM-09", "id": "AM-09", "domain": "agentic", "name": "Action Effect Reconciliation", "validation_objective": "Prove that every externally-visible or irreversible agent action carries a declared intended_effect and has a corresponding post-execution reconciliation verdict derived from comparison of pre-state and post-state snapshots. Validate that mismatch and duplicate verdicts generate AM-07 escalation records within the defined SLA and that reconciliation coverage reaches 100% of qualifying actions.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Effect declaration format specification documenting the required intended_effect field structure \u2014 including the expected post-state representation schema \u2014 for all externally-visible and irreversible action types", "Sampled action records from the review period showing pre-state snapshot, post-state snapshot, intended_effect declaration, and effect reconciliation verdict for a representative cross-section of action types", "Escalation event records for all mismatch and duplicate verdicts in the review period confirming AM-07 escalation was triggered and completed within the defined SLA for each event", "Coverage rate metric report documenting the percentage of externally-visible and irreversible actions in the review period that have a captured reconciliation verdict" ], "evidence": [ { "id": "AM-09-E1", "description": "Effect declaration format specification documenting the required intended_effect field structure \u2014 including the expected post-state representation schema \u2014 for all externally-visible and irreversible action types", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AM-09-E2", "description": "Sampled action records from the review period showing pre-state snapshot, post-state snapshot, intended_effect declaration, and effect reconciliation verdict for a representative cross-section of action types", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "AM-09-E3", "description": "Escalation event records for all mismatch and duplicate verdicts in the review period confirming AM-07 escalation was triggered and completed within the defined SLA for each event", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AM-09-E4", "description": "Coverage rate metric report documenting the percentage of externally-visible and irreversible actions in the review period that have a captured reconciliation verdict", "evidence_type": "evaluation-scorecard", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE 2.4 requires the functionality and behavior of the AI system and its components to be monitored in production. Effect reconciliation is the strictest form of that monitoring: it verifies, per action, that the observed external state change matches the declared intent." }, { "control": "apeiris://model/controls/CR-06", "id": "CR-06", "domain": "model", "name": "Post-Market Surveillance", "validation_objective": "The organization must operate three distinct proactive surveillance channels \u2014 a structured user-facing harm reporting mechanism, a coordinated vulnerability disclosure (CVD) program with a monitored security inbox, and a quarterly AI literature and media monitoring process \u2014 with outputs aggregated into a monthly post-market surveillance report reviewed and signed by the AI risk function, and an annual surveillance summary included in the model's EU high-risk AI technical documentation (LI-04).", "blocking_effect": "advisory", "evidence_required": [ "User-facing harm reporting mechanism deployment record showing endpoint URL, structured input schema (harm_type, severity_self_assessed, description), and CR-02 archive path", "Published CVD policy document at a canonical URL with designated security email alias and monitored inbox confirmation, including acknowledgement SLA statement", "Last 12 monthly post-market surveillance reports with AI risk function reviewer name, sign-off signature, and review date on each report", "Annual surveillance summary document aggregating user reports, CVD submissions, and literature findings \u2014 present in the model's LI-04 technical documentation with review date", "CVD acknowledgement records showing each submission received an acknowledgement within 5 business days of receipt" ], "evidence": [ { "id": "CR-06-E1", "description": "User-facing harm reporting mechanism deployment record showing endpoint URL, structured input schema (harm_type, severity_self_assessed, description), and CR-02 archive path", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-06-E2", "description": "Published CVD policy document at a canonical URL with designated security email alias and monitored inbox confirmation, including acknowledgement SLA statement", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-06-E3", "description": "Last 12 monthly post-market surveillance reports with AI risk function reviewer name, sign-off signature, and review date on each report", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CR-06-E4", "description": "Annual surveillance summary document aggregating user reports, CVD submissions, and literature findings \u2014 present in the model's LI-04 technical documentation with review date", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CR-06-E5", "description": "CVD acknowledgement records showing each submission received an acknowledgement within 5 business days of receipt", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.4 (MEASURE function) provides that the functionality and behavior of the AI system and its components are monitored when in production. CR-06 extends production monitoring beyond runtime metrics to externally reported harms via structured surveillance channels." } ] }, { "requirement_id": "MANAGE-4.2", "section": "MANAGE 4.2", "title": "Feedback mechanisms inform updates to training and risk management", "text": "Feedback mechanisms inform updates to AI system training and inference data, as well as to organizational risk management practices.", "verdict": "supported", "coverage": "direct", "notes": "AG-07 drives continuous improvement and lessons learned; PG-08 incorporates lessons learned into policy improvement; BH-02 detects concept and data drift that triggers retraining \u2014 connecting operational feedback to model updates.", "control_count": 3, "proof_chain": [ { "control": "apeiris://agentic/controls/AG-07", "id": "AG-07", "domain": "agentic", "name": "Continuous Improvement and Lessons Learned", "validation_objective": "The enterprise operates a closed-loop lessons-learned program with four defined input channels, a tracked pipeline from capture to verified implementation, and documented control update recommendations with named owners and due dates that are verifiably completed.", "blocking_effect": "advisory", "evidence_required": [ "Lessons-learned register showing all open and closed items from the past 12 months, with input source, root cause, affected control identifiers, recommended update, approval status, implementation date, and verification evidence", "Post-incident review outputs from all P1/P2 events completed within the 5-business-day SLA, linked to lessons-learned register entries", "Records of external intelligence feed subscriptions and quarterly relevance assessments, including items submitted to the lessons-learned pipeline", "Governance committee retrospective records from each quarterly session showing open action item status and newly identified improvement themes" ], "evidence": [ { "id": "AG-07-E1", "description": "Lessons-learned register showing all open and closed items from the past 12 months, with input source, root cause, affected control identifiers, recommended update, approval status, implementation date, and verification evidence", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AG-07-E2", "description": "Post-incident review outputs from all P1/P2 events completed within the 5-business-day SLA, linked to lessons-learned register entries", "evidence_type": "incident-record", "verification": "attested" }, { "id": "AG-07-E3", "description": "Records of external intelligence feed subscriptions and quarterly relevance assessments, including items submitted to the lessons-learned pipeline", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-07-E4", "description": "Governance committee retrospective records from each quarterly session showing open action item status and newly identified improvement themes", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MANAGE 4.1 requires post-deployment monitoring plans that include mechanisms for capturing and evaluating input from users and affected parties, feeding change management. The lessons-learned pipeline is that capture-and-evaluate mechanism for the agentic program." }, { "control": "apeiris://authority/controls/PG-08", "id": "PG-08", "domain": "authority", "name": "Lessons Learned and Policy Improvement", "validation_objective": "Every AI policy incident and near-miss must generate a structured lessons-learned record that identifies the root cause, the policy gap exploited, and a documented improvement action with an assigned owner and target closure date. The improvement cycle must be confirmed closed in the policy registry before the control is considered passing.", "blocking_effect": "requires-review", "evidence_required": [ "lessons_learned_record for each qualifying incident containing root_cause, policy_gap_reference, improvement_action, assigned_owner, and target_closure_date fields", "policy_improvement_log confirming that each improvement action triggered a versioned policy update or documented risk-acceptance decision with sign-off", "incident_classification_record distinguishing incidents requiring formal lessons-learned review from those below threshold, with classification rationale", "policy_registry_update_record showing the policy version that incorporated each improvement action, with before-and-after change diff and approver identity", "improvement_cycle_closure_record confirming that each open improvement action was closed within its target date or escalated with documented justification for extension" ], "evidence": [ { "id": "PG-08-E1", "description": "lessons_learned_record for each qualifying incident containing root_cause, policy_gap_reference, improvement_action, assigned_owner, and target_closure_date fields", "evidence_type": "incident-record", "verification": "attested" }, { "id": "PG-08-E2", "description": "policy_improvement_log confirming that each improvement action triggered a versioned policy update or documented risk-acceptance decision with sign-off", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PG-08-E3", "description": "incident_classification_record distinguishing incidents requiring formal lessons-learned review from those below threshold, with classification rationale", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PG-08-E4", "description": "policy_registry_update_record showing the policy version that incorporated each improvement action, with before-and-after change diff and approver identity", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PG-08-E5", "description": "improvement_cycle_closure_record confirming that each open improvement action was closed within its target date or escalated with documented justification for extension", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "Lessons-learned closing root-cause gaps partially implements MANAGE 4.1 post-incident change management." }, { "control": "apeiris://model/controls/BH-02", "id": "BH-02", "domain": "model", "name": "Concept and Data Drift Detection", "validation_objective": "The production inference pipeline must compare input feature distributions and prediction distributions against a versioned, SHA-256-signed DriftReference artifact using PSI and KS-test statistics for every monitoring window that meets minimum_sample_size, such that drift exceeding profile-conditional PSI thresholds triggers tiered alert actions, and for continuously-learning profiles, automatically suspends online updates pending a signed model-owner resume authorization.", "blocking_effect": "advisory", "evidence_required": [ "versioned DriftReference artifact for the current production model with SHA-256 hash, training date, and per-feature statistics (mean, std, histogram bins, and KDE parameters) for all tier-1 monitored features", "drift event log for trailing 90 days with fields: feature_name, test_statistic, p_value, window_start, window_end, sample_count, alert_severity, and action_taken for each drift event", "monthly drift summary report signed by the model owner, including trend analysis across tier-1 features and prediction distribution PSI over the reporting period", "profile-conditional drift threshold configuration (YAML or equivalent) showing per-profile PSI alert and critical thresholds, minimum_sample_size, and window duration, stored under version control" ], "evidence": [ { "id": "BH-02-E1", "description": "versioned DriftReference artifact for the current production model with SHA-256 hash, training date, and per-feature statistics (mean, std, histogram bins, and KDE parameters) for all tier-1 monitored features", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-02-E2", "description": "drift event log for trailing 90 days with fields: feature_name, test_statistic, p_value, window_start, window_end, sample_count, alert_severity, and action_taken for each drift event", "evidence_type": "audit-log", "verification": "automated" }, { "id": "BH-02-E3", "description": "monthly drift summary report signed by the model owner, including trend analysis across tier-1 features and prediction distribution PSI over the reporting period", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-02-E4", "description": "profile-conditional drift threshold configuration (YAML or equivalent) showing per-profile PSI alert and critical thresholds, minimum_sample_size, and window duration, stored under version control", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.4 (MEASURE function) provides that the functionality and behavior of the AI system and its components are monitored when in production. BH-02\u2019s PSI/KS drift detection continuously monitors production input behavior against a versioned DriftReference artifact." } ] }, { "requirement_id": "AI600-GOV-1", "section": "AI 600-1 \u2014 Governance for GenAI", "title": "Governance for GenAI", "text": "Organizations establish and maintain governance structures, policies, and accountability mechanisms specific to generative AI systems, including policies for acceptable use and risk oversight.", "verdict": "supported", "coverage": "direct", "notes": "AG-01 establishes agentic AI governance applicable to GenAI agents; EG-01 defines ethics governance structure; PO-01 hosts the policy register; OA-03 provides the AI model governance committee \u2014 forming a comprehensive GenAI governance scaffold.", "control_count": 4, "proof_chain": [ { "control": "apeiris://agentic/controls/AG-01", "id": "AG-01", "domain": "agentic", "name": "Agentic AI Governance Structure", "validation_objective": "Prove that the enterprise has a ratified, operational Agentic AI Governance Committee with a documented charter, RACI matrix, and defined three-tier consequence escalation model, and that a named senior accountable owner is recorded in the enterprise risk register. Validate that the committee meets at minimum quarterly, documents decisions, and that governance approval functions as a hard deployment gate.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Ratified Agentic AI Governance Charter documenting committee scope, cross-functional membership roster, quorum requirements, meeting cadence, decision authorities, and escalation tier triggers \u2014 signed within the past 24 months and reviewed within the past 12", "Published RACI matrix covering agent design review, deployment approval, incident escalation, and program reporting with named role assignments and confirmation that 100% of deployed agents have a named governance owner", "Committee meeting minutes from the past four quarters demonstrating quorum, attendance records, and documented decisions for each session", "Enterprise risk register entry naming the senior accountable owner for the agentic AI program by individual name and role, not by position title alone", "Deployment pipeline configuration demonstrating governance approval is enforced as a blocking gate before any agent is promoted to a production environment" ], "evidence": [ { "id": "AG-01-E1", "description": "Ratified Agentic AI Governance Charter documenting committee scope, cross-functional membership roster, quorum requirements, meeting cadence, decision authorities, and escalation tier triggers \u2014 signed within the past 24 months and reviewed within the past 12", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AG-01-E2", "description": "Published RACI matrix covering agent design review, deployment approval, incident escalation, and program reporting with named role assignments and confirmation that 100% of deployed agents have a named governance owner", "evidence_type": "incident-record", "verification": "attested" }, { "id": "AG-01-E3", "description": "Committee meeting minutes from the past four quarters demonstrating quorum, attendance records, and documented decisions for each session", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AG-01-E4", "description": "Enterprise risk register entry naming the senior accountable owner for the agentic AI program by individual name and role, not by position title alone", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AG-01-E5", "description": "Deployment pipeline configuration demonstrating governance approval is enforced as a blocking gate before any agent is promoted to a production environment", "evidence_type": "configuration-snapshot", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN 2.1 requires roles, responsibilities, and lines of communication for AI risk management to be documented and clearly understood. A chartered agentic governance committee with defined membership, authority, and escalation paths implements this directly." }, { "control": "apeiris://ethics/controls/EG-01", "id": "EG-01", "domain": "ethics", "name": "Ethics Governance Structure", "validation_objective": "The enterprise must have an active, formally chartered AI Ethics Board with documented cross-functional membership, defined decision authority over high-risk AI deployments, a functioning escalation path from individual teams to the board, and evidence of executive-level reporting within the past 90 days. The control passes if an Ethics Board charter exists, meeting minutes and decision logs are complete for the trailing 12 months, all high-risk AI systems have Ethics Board approval records, and at least one escalation was exercised and documented.", "blocking_effect": "blocks-deployment", "evidence_required": [ "AI Ethics Board charter document signed at C-suite or board authority level, specifying membership criteria, quorum rules, decision authority scope over high-risk AI deployment approvals, and meeting cadence", "Ethics Board meeting minutes for the trailing 12 months showing dates, attendees, agenda items, decision log entries, and executive or board-level reporting records confirming required governance cadence", "Escalation path documentation distributed to all AI product teams showing the path from individual contributor to Ethics Board with named contacts at each level and documented response SLAs", "Ethics Board decision log entries for AI deployment approvals or rejections in the trailing 12 months, confirming high-risk AI systems passed through the formal governance process", "Evidence of at least one ethics escalation exercised through the documented escalation path, with intake record, investigation record, Ethics Board disposition, and outcome notification to the escalating party" ], "evidence": [ { "id": "EG-01-E1", "description": "AI Ethics Board charter document signed at C-suite or board authority level, specifying membership criteria, quorum rules, decision authority scope over high-risk AI deployment approvals, and meeting cadence", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-01-E2", "description": "Ethics Board meeting minutes for the trailing 12 months showing dates, attendees, agenda items, decision log entries, and executive or board-level reporting records confirming required governance cadence", "evidence_type": "audit-log", "verification": "automated" }, { "id": "EG-01-E3", "description": "Escalation path documentation distributed to all AI product teams showing the path from individual contributor to Ethics Board with named contacts at each level and documented response SLAs", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EG-01-E4", "description": "Ethics Board decision log entries for AI deployment approvals or rejections in the trailing 12 months, confirming high-risk AI systems passed through the formal governance process", "evidence_type": "audit-log", "verification": "automated" }, { "id": "EG-01-E5", "description": "Evidence of at least one ethics escalation exercised through the documented escalation path, with intake record, investigation record, Ethics Board disposition, and outcome notification to the escalating party", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN 2.1 requires that roles, responsibilities, and lines of communication related to mapping, measuring, and managing AI risks are documented and clear. An Ethics Board with a documented charter, defined membership, and formal escalation paths directly implements this governance subcategory." }, { "control": "apeiris://authority/controls/PO-01", "id": "PO-01", "domain": "authority", "name": "Internal Policy Register for AI Deployments", "validation_objective": "Every active AI deployment must have at least one current, non-expired policy register entry in the authoritative policy register, and that entry must contain version, effective date, scope, owning team, and deployment linkage fields. No AI deployment may enter or remain in production without a valid policy register reference confirmed by the deployment pipeline.", "blocking_effect": "blocks-deployment", "evidence_required": [ "policy_register_schema_document specifying required fields including policy_id, version, effective_date, expiry_date, owning_team, ai_deployment_scope, and authority_domain_applicability", "deployment_policy_linkage_audit_log confirming every active AI deployment has a corresponding current policy register entry with a non-expired effective date", "policy_register_access_control_matrix demonstrating that register modifications require dual authorization and all changes are attributed and logged", "deployment_pipeline_gate_configuration showing that AI deployment approval workflows validate the presence of a current policy register entry before proceeding" ], "evidence": [ { "id": "PO-01-E1", "description": "policy_register_schema_document specifying required fields including policy_id, version, effective_date, expiry_date, owning_team, ai_deployment_scope, and authority_domain_applicability", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-01-E2", "description": "deployment_policy_linkage_audit_log confirming every active AI deployment has a corresponding current policy register entry with a non-expired effective date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-01-E3", "description": "policy_register_access_control_matrix demonstrating that register modifications require dual authorization and all changes are attributed and logged", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-01-E4", "description": "deployment_pipeline_gate_configuration showing that AI deployment approval workflows validate the presence of a current policy register entry before proceeding", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "A register of AI governance policies operationalizes GOVERN 1.2 policy integration, partially." }, { "control": "apeiris://model/controls/OA-03", "id": "OA-03", "domain": "model", "name": "AI Model Governance Committee", "validation_objective": "The organization must have a formally chartered AI Model Governance Committee with documented membership covering all required functional areas, exclusive approval authority over high-risk model deployments and risk appetite thresholds, and auditable meeting minutes retained for seven years. The committee must have met at minimum quarterly in each of the preceding four quarters, with quorum achieved for all binding decisions.", "blocking_effect": "blocks-deployment", "evidence_required": [ "committee_charter current version with executive-level approval signature and date, specifying membership composition, decision rights matrix, quorum requirements, and meeting cadence", "meeting_minutes for all scheduled quarterly sessions in the preceding 12-month period, demonstrating quorum was met and binding decisions were recorded with rationale", "decision_log showing AIGC approval records for all high-risk model deployments and risk appetite changes in the preceding 12 months, cross-referenced against the production model registry", "membership_roster with functional affiliations confirming representation from AI/ML engineering, model validation, legal/compliance, risk management, and at least one business line" ], "evidence": [ { "id": "OA-03-E1", "description": "committee_charter current version with executive-level approval signature and date, specifying membership composition, decision rights matrix, quorum requirements, and meeting cadence", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-03-E2", "description": "meeting_minutes for all scheduled quarterly sessions in the preceding 12-month period, demonstrating quorum was met and binding decisions were recorded with rationale", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-03-E3", "description": "decision_log showing AIGC approval records for all high-risk model deployments and risk appetite changes in the preceding 12 months, cross-referenced against the production model registry", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-03-E4", "description": "membership_roster with functional affiliations confirming representation from AI/ML engineering, model validation, legal/compliance, risk management, and at least one business line", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN-2.3 (GOVERN function) provides that executive leadership takes responsibility for decisions about risks associated with AI development and deployment. OA-03\u2019s chartered governance committee gives executive leadership a standing forum in which those risk decisions are taken and recorded." } ] }, { "requirement_id": "AI600-DPI-1", "section": "AI 600-1 \u2014 Data Privacy and Integrity", "title": "Data privacy and integrity for GenAI", "text": "Organizations protect the privacy and integrity of data used to train, fine-tune, and operate generative AI systems, including protecting against data poisoning and unauthorized data use.", "verdict": "partial", "coverage": "partial", "notes": "TG-06 addresses sensitive-data minimization and controlled use; TG-04 prevents data poisoning; EC-08 keeps secrets out of prompt and context. Comprehensive GenAI training data privacy (consent management, data subject rights, cross-border transfer) is primarily in the Apeiris Privacy domain (PC-series controls), outside this mapping scope.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/TG-06", "id": "TG-06", "domain": "model", "name": "Sensitive-Data Necessity, Minimization and Controlled Use", "validation_objective": "Every training dataset containing PII or protected-class attributes has a documented necessity assessment with named approver sign-off confirming that the data cannot be substituted with de-identified or synthetic alternatives. When protected attributes are retained for bias auditing, they are stored exclusively in a separately access-controlled fairness audit vault \u2014 not in the general training corpus \u2014 with time-bounded, logged access for each session.", "blocking_effect": "blocks-deployment", "evidence_required": [ "data_necessity_assessment_record with dataset_id, PII categories identified (name/email/SSN/biometric/protected-class), justification for necessity over de-identified alternatives, and approver_identity with approval_timestamp", "PII_scan_run_log showing scanner tool, dataset version, detection count per PII category, and remediation action per detected item (de-identified / synthetic-replaced / retained-in-fairness-vault)", "fairness_audit_vault_access_log for the retention window, listing accessor_identity, purpose, authorization_record_id, and session_duration for every vault access", "synthetic_data_provenance_record for any PII replaced with synthetic proxies, confirming generation method and confirming synthetic records cannot be re-linked to real individuals via quasi-identifiers" ], "evidence": [ { "id": "TG-06-E1", "description": "data_necessity_assessment_record with dataset_id, PII categories identified (name/email/SSN/biometric/protected-class), justification for necessity over de-identified alternatives, and approver_identity with approval_timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-06-E2", "description": "PII_scan_run_log showing scanner tool, dataset version, detection count per PII category, and remediation action per detected item (de-identified / synthetic-replaced / retained-in-fairness-vault)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-06-E3", "description": "fairness_audit_vault_access_log for the retention window, listing accessor_identity, purpose, authorization_record_id, and session_duration for every vault access", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-06-E4", "description": "synthetic_data_provenance_record for any PII replaced with synthetic proxies, confirming generation method and confirming synthetic records cannot be re-linked to real individuals via quasi-identifiers", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.10 (MEASURE function) provides that privacy risk of the AI system is examined and documented. TG-06\u2019s sensitive-data necessity assessment and minimization controls examine and reduce the privacy risk carried into the model through training data." }, { "control": "apeiris://model/controls/TG-04", "id": "TG-04", "domain": "model", "name": "Data Poisoning Prevention", "validation_objective": "Every training shard must pass cryptographic integrity verification against a pre-ingestion hash before it is admitted to a training run; adversarial input screening must be applied at ingestion for all external or third-party data sources; and a chain-of-custody record must exist for every data transformation applied to the training corpus.", "blocking_effect": "blocks-deployment", "evidence_required": [ "training_shard_integrity_manifest listing the cryptographic hash (SHA-256 or stronger) for each shard, the verification timestamp, and the verification result (pass/fail/recomputed) for the current training run", "adversarial_screening_report for each external data source ingested, including the screening method applied, the number of records inspected, any detected anomalies or suspicious patterns, and the disposition (accepted/quarantined/rejected)", "chain_of_custody_record for each data transformation applied to the training corpus, including the transformation type, operator identity, input hash, output hash, and transformation timestamp", "supply_chain_integrity_check_record confirming that third-party training data packages (datasets, pretrained weights, synthetic data) were verified against vendor-provided manifests or signatures before use" ], "evidence": [ { "id": "TG-04-E1", "description": "training_shard_integrity_manifest listing the cryptographic hash (SHA-256 or stronger) for each shard, the verification timestamp, and the verification result (pass/fail/recomputed) for the current training run", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-04-E2", "description": "adversarial_screening_report for each external data source ingested, including the screening method applied, the number of records inspected, any detected anomalies or suspicious patterns, and the disposition (accepted/quarantined/rejected)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-04-E3", "description": "chain_of_custody_record for each data transformation applied to the training corpus, including the transformation type, operator identity, input hash, output hash, and transformation timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-04-E4", "description": "supply_chain_integrity_check_record confirming that third-party training data packages (datasets, pretrained weights, synthetic data) were verified against vendor-provided manifests or signatures before use", "evidence_type": "third-party-audit-report", "verification": "third-party" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.7 (MEASURE function) provides that AI system security and resilience are evaluated and documented. TG-04\u2019s poisoning prevention controls address the training-data attack surface within security-and-resilience evaluation; the RMF has no subcategory prescribing cryptographic data integrity specifically." }, { "control": "apeiris://security/controls/EC-08", "id": "EC-08", "domain": "security", "name": "Keep secrets out of the prompt and context", "validation_objective": "Credentials, API keys, tokens, and other secrets must never appear in the agent's prompt, system prompt, or context window. All secret access must be mediated through a secrets broker that resolves credentials at point-of-use as opaque reference IDs, with the reasoning engine structurally isolated from the execution layer that holds plaintext secret values. The system must resist system-prompt extraction attacks.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "secrets_broker_access_log showing each credential resolution event with agent_id, secret_reference_id, resolved_at timestamp, and confirmation that plaintext was not passed to model context", "context_scan_report showing a scan of all active agent system prompts and context templates for secret patterns (API key formats, PEM headers, password-like strings) with zero findings", "architectural_separation_record confirming the model inference layer and the execution layer holding secret values are structurally isolated with no shared memory or context path", "system_prompt_extraction_test_results showing adversarial attempts to elicit the system prompt or injected credentials returned no secret material" ], "evidence": [ { "id": "EC-08-E1", "description": "secrets_broker_access_log showing each credential resolution event with agent_id, secret_reference_id, resolved_at timestamp, and confirmation that plaintext was not passed to model context", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-08-E2", "description": "context_scan_report showing a scan of all active agent system prompts and context templates for secret patterns (API key formats, PEM headers, password-like strings) with zero findings", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "EC-08-E3", "description": "architectural_separation_record confirming the model inference layer and the execution layer holding secret values are structurally isolated with no shared memory or context path", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-08-E4", "description": "system_prompt_extraction_test_results showing adversarial attempts to elicit the system prompt or injected credentials returned no secret material", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "adjacent", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF Manage function: prioritise and act on the identified AI risks, treating, responding, recovering, and allocating resources. \"Keep secrets out of the prompt and context\" is a corresponding risk-treatment activity." } ] }, { "requirement_id": "AI600-CP-1", "section": "AI 600-1 \u2014 Content Provenance", "title": "Content provenance for GenAI outputs", "text": "Organizations establish mechanisms to track and disclose the provenance of AI-generated content, including watermarking, metadata tagging, and disclosure to end users.", "verdict": "supported", "coverage": "direct", "notes": "BH-09 governs synthetic-content provenance, disclosure, and traceability; LI-02 tracks the full model provenance chain; IA-06 binds a signed, end-to-end provenance chain to every agent action \u2014 covering both model-level and action-level content provenance.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/BH-09", "id": "BH-09", "domain": "model", "name": "Synthetic-Content Provenance, Disclosure and Traceability", "validation_objective": "Every AI-generated content artifact must carry verifiable cryptographic provenance metadata linking it to the generating model version, include a mandatory disclosure label visible to recipients, and be resolvable through a complete traceability chain from generation event to content delivery with no gaps in the provenance record.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "content_provenance_record per generated artifact showing model_version_id, generation_timestamp, content_hash, and cryptographic signature (C2PA manifest or equivalent) attached at generation time", "disclosure_label_audit_log confirming that AI-generated disclosure labels were applied and rendered for each content delivery event, with delivery_channel and recipient_context recorded", "traceability_chain_record linking content_id to generation_event_id, model_version_id, and serving_endpoint_id for each production output", "provenance_metadata_schema_validation_report confirming all required provenance fields are present and signature validity checks pass across a sampled period", "regulatory_disclosure_mapping_record showing how disclosure label format and placement satisfies jurisdiction-specific requirements (EU AI Act Art. 50 and equivalent)" ], "evidence": [ { "id": "BH-09-E1", "description": "content_provenance_record per generated artifact showing model_version_id, generation_timestamp, content_hash, and cryptographic signature (C2PA manifest or equivalent) attached at generation time", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "BH-09-E2", "description": "disclosure_label_audit_log confirming that AI-generated disclosure labels were applied and rendered for each content delivery event, with delivery_channel and recipient_context recorded", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-09-E3", "description": "traceability_chain_record linking content_id to generation_event_id, model_version_id, and serving_endpoint_id for each production output", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-09-E4", "description": "provenance_metadata_schema_validation_report confirming all required provenance fields are present and signature validity checks pass across a sampled period", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "BH-09-E5", "description": "regulatory_disclosure_mapping_record showing how disclosure label format and placement satisfies jurisdiction-specific requirements (EU AI Act Art. 50 and equivalent)", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN-1.2 (GOVERN function) provides that the characteristics of trustworthy AI are integrated into organizational policies, processes, and practices. BH-09\u2019s C2PA provenance assertions and disclosure labels operationalize transparency \u2014 one of the trustworthy-AI characteristics this subcategory integrates into policy \u2014 for generated content." }, { "control": "apeiris://model/controls/LI-02", "id": "LI-02", "domain": "model", "name": "Model Provenance Chain \u2014 Base Model, Fine-Tune, Merge, and Adapter Lineage", "validation_objective": "Every registered model artifact must have a machine-readable provenance manifest recording the complete ancestry chain including the base model artifact hash and provider version, all fine-tuning steps with dataset references, all merge contributors with their artifact hashes, and all attached adapter components with source and base-model compatibility metadata; and the registry must expose a query interface that returns all derived models for a given base model artifact hash.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_provenance_manifest with typed structured fields for base_model_hash, base_model_provider_version, fine_tuning_steps[] each referencing a TG-layer dataset record, merge_contributors[] with per-contributor artifact hashes and merge parameters, and adapter_components[] with source, version, and base_model_compatibility_hash", "provenance_query_api_result showing all registry entries derived from a specified base model artifact hash, confirming complete downstream impact scope is retrievable by automated query", "registry_provenance_rejection_log showing that a model registration attempt with a missing required provenance field (e.g., absent base_model_hash) was blocked", "adapter_lineage_registry_entry for at least one production model with an attached LoRA or PEFT adapter, confirming adapter source and compatibility metadata are recorded" ], "evidence": [ { "id": "LI-02-E1", "description": "model_provenance_manifest with typed structured fields for base_model_hash, base_model_provider_version, fine_tuning_steps[] each referencing a TG-layer dataset record, merge_contributors[] with per-contributor artifact hashes and merge parameters, and adapter_components[] with source, version, and base_model_compatibility_hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-02-E2", "description": "provenance_query_api_result showing all registry entries derived from a specified base model artifact hash, confirming complete downstream impact scope is retrievable by automated query", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-02-E3", "description": "registry_provenance_rejection_log showing that a model registration attempt with a missing required provenance field (e.g., absent base_model_hash) was blocked", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "LI-02-E4", "description": "adapter_lineage_registry_entry for at least one production model with an attached LoRA or PEFT adapter, confirming adapter source and compatibility metadata are recorded", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP-4.2 (MAP function) provides that internal risk controls for AI system components, including third-party AI technologies, are identified and documented. LI-02\u2019s provenance chain documents every component \u2014 base model, fine-tunes, merges, adapters \u2014 so that component-level risk controls can be identified and verified." }, { "control": "apeiris://security/controls/IA-06", "id": "IA-06", "domain": "security", "name": "Bind a signed, end-to-end provenance chain to every agent action", "validation_objective": "Every agent action must carry a cryptographically verifiable provenance chain in which each hop (initiating human, orchestrator, each sub-agent, the tool invoked) is signed by its own distinct workload identity and bound to the upstream hop's signature. The full chain must be verifiable against distinct workload identities and committed to the tamper-evident audit store before the downstream action executes.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "provenance_chain_record for each action containing: hop_sequence (human_id, agent_id per hop, tool_id), per-hop_signature (JWS or DID-VC), upstream_signature_reference, chain_depth, and verified_at timestamp", "signature_verification_log showing for each action: chain_depth, all_signatures_valid (true/false), first_failure_hop if applicable, and workload_identity used at each hop", "tamper_evident_store_write_confirmation showing each provenance chain was committed to the GV-02 store prior to action execution, with integrity_hash and store_sequence_id", "delegation_lineage_record linking the RFC 8693 act-claim across all hops, confirming user-as-subject and agent-as-actor propagation throughout the chain" ], "evidence": [ { "id": "IA-06-E1", "description": "provenance_chain_record for each action containing: hop_sequence (human_id, agent_id per hop, tool_id), per-hop_signature (JWS or DID-VC), upstream_signature_reference, chain_depth, and verified_at timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "IA-06-E2", "description": "signature_verification_log showing for each action: chain_depth, all_signatures_valid (true/false), first_failure_hop if applicable, and workload_identity used at each hop", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "IA-06-E3", "description": "tamper_evident_store_write_confirmation showing each provenance chain was committed to the GV-02 store prior to action execution, with integrity_hash and store_sequence_id", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "IA-06-E4", "description": "delegation_lineage_record linking the RFC 8693 act-claim across all hops, confirming user-as-subject and agent-as-actor propagation throughout the chain", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "adjacent", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF Govern / Manage functions: cultivate and operate a culture of AI risk management, with policies, roles, accountability, and oversight; prioritise and act on the identified AI risks, treating, responding, recovering, and allocating resources. \"Bind a signed, end-to-end provenance chain to every agent action\" is a corresponding risk-treatment activity." } ] }, { "requirement_id": "AI600-HO-1", "section": "AI 600-1 \u2014 Human Oversight of GenAI", "title": "Human oversight of GenAI systems", "text": "Organizations implement meaningful human oversight for generative AI systems, including override mechanisms, escalation paths, and human review for high-stakes outputs.", "verdict": "supported", "coverage": "direct", "notes": "OA-02 mandates meaningful human oversight for high-stakes decisions; GV-01 enforces a human hard-stop for irreversible actions; HI-04 specifies human oversight and override mechanisms; AO-04 gates high-consequence orchestrations with human-in-the-loop review.", "control_count": 4, "proof_chain": [ { "control": "apeiris://model/controls/OA-02", "id": "OA-02", "domain": "model", "name": "Meaningful Human Oversight for High-Stakes Decisions", "validation_objective": "For every high-impact-decision or eu-high-risk model, a human reviewer must have documented access to model inputs, confidence scores, and reasoning; organizational authority to override without penalty; domain competence verified through training records; and a technically effective override mechanism before any AI output takes effect. Override rates must be monitored and a rate near zero for 30 consecutive days must automatically trigger a governance review.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "five_factor_oversight_design_document per high-stakes use case, signed by the AI governance committee, covering: review time allocation, information display design, override authority documentation, competence requirements, and override mechanism technical specification", "override_rate_time_series report for the past 12 months broken down by model, decision type, and reviewer cohort \u2014 with governance-defined floor thresholds annotated", "reviewer_training_completion_record including initial onboarding completion date, annual recertification dates, competence assessment scores, and automation-bias module completion", "override_mechanism_test_log confirming that override actions propagate correctly through downstream systems without requiring secondary approval" ], "evidence": [ { "id": "OA-02-E1", "description": "five_factor_oversight_design_document per high-stakes use case, signed by the AI governance committee, covering: review time allocation, information display design, override authority documentation, competence requirements, and override mechanism technical specification", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-02-E2", "description": "override_rate_time_series report for the past 12 months broken down by model, decision type, and reviewer cohort \u2014 with governance-defined floor thresholds annotated", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-02-E3", "description": "reviewer_training_completion_record including initial onboarding completion date, annual recertification dates, competence assessment scores, and automation-bias module completion", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-02-E4", "description": "override_mechanism_test_log confirming that override actions propagate correctly through downstream systems without requiring secondary approval", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN-3.2 (GOVERN function) provides that policies define and differentiate roles and responsibilities for human-AI configurations and oversight. OA-02\u2019s five-factor oversight adequacy framework defines and verifies the human-oversight roles this subcategory calls for." }, { "control": "apeiris://security/controls/GV-01", "id": "GV-01", "domain": "security", "name": "Require a human hard-stop for irreversible actions", "validation_objective": "Every irreversible agent action (write, deletion, transfer, deployment, or any action with no safe undo path) must be deterministically halted and routed to an explicit human (or quorum) approval before execution; the agent must not be capable of self-approving such actions, and the hard-stop must be enforced at platform infrastructure level, not by a model-layer instruction.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "irreversible_action_approval_record linking each halted action to the human approver(s), approval_token with timestamp and cryptographic signature, and action outcome (executed/cancelled)", "irreversibility_classification_list identifying which action types are classified as irreversible, with the policy_version and last_review_date", "hard_stop_enforcement_log showing agent execution was suspended at the irreversible action gate and resumed only after receipt of a valid external approval token", "self_approval_rejection_log confirming any attempt by the agent to approve its own irreversible actions was blocked by the platform", "quorum_policy_record for high-stakes action categories specifying minimum required approvers and approval token validity window" ], "evidence": [ { "id": "GV-01-E1", "description": "irreversible_action_approval_record linking each halted action to the human approver(s), approval_token with timestamp and cryptographic signature, and action outcome (executed/cancelled)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-01-E2", "description": "irreversibility_classification_list identifying which action types are classified as irreversible, with the policy_version and last_review_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-01-E3", "description": "hard_stop_enforcement_log showing agent execution was suspended at the irreversible action gate and resumed only after receipt of a valid external approval token", "evidence_type": "human-review-record", "verification": "human" }, { "id": "GV-01-E4", "description": "self_approval_rejection_log confirming any attempt by the agent to approve its own irreversible actions was blocked by the platform", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-01-E5", "description": "quorum_policy_record for high-stakes action categories specifying minimum required approvers and approval token validity window", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "adjacent", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF Govern function: cultivate and operate a culture of AI risk management, with policies, roles, accountability, and oversight. \"Require a human hard-stop for irreversible actions\" is a corresponding governance activity." }, { "control": "apeiris://ethics/controls/HI-04", "id": "HI-04", "domain": "ethics", "name": "Human Oversight and Override Mechanisms", "validation_objective": "All AI systems classified as significant or critical consequentiality tier must have override logging implemented and producing verifiable disposition records for every AI recommendation reviewed by a human operator. Override rate monitoring must be active and generating alerts when rates fall below defined thresholds, and every alert must trigger a documented review response within 30 days.", "blocking_effect": "blocks-deployment", "evidence_required": [ "consequentiality_tier_classification_record for every production AI system documenting the assigned tier (advisory/significant/critical), classification rationale, and mandatory oversight requirements that tier triggers", "override_audit_log for significant and critical tier systems showing AI recommendations, human dispositions (accepted/modified/rejected), override rationale where provided, and timestamps covering the prior 90 days", "override_rate_monitoring_report showing per-system trend data, defined threshold levels, alerts triggered in the prior 12 months, and documented investigation responses with completion dates", "interface_design_review_record confirming evaluation of the AI decision interface against automation-bias-avoidance criteria: confidence levels displayed, uncertainty ranges shown, override pathway accessible without additional navigation, AI-generated content distinguished from operator-entered content", "human_overseer_assignment_record naming the qualified overseer role for each significant and critical tier AI system with accountability documentation and training evidence" ], "evidence": [ { "id": "HI-04-E1", "description": "consequentiality_tier_classification_record for every production AI system documenting the assigned tier (advisory/significant/critical), classification rationale, and mandatory oversight requirements that tier triggers", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-04-E2", "description": "override_audit_log for significant and critical tier systems showing AI recommendations, human dispositions (accepted/modified/rejected), override rationale where provided, and timestamps covering the prior 90 days", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "HI-04-E3", "description": "override_rate_monitoring_report showing per-system trend data, defined threshold levels, alerts triggered in the prior 12 months, and documented investigation responses with completion dates", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "HI-04-E4", "description": "interface_design_review_record confirming evaluation of the AI decision interface against automation-bias-avoidance criteria: confidence levels displayed, uncertainty ranges shown, override pathway accessible without additional navigation, AI-generated content distinguished from operator-entered content", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "HI-04-E5", "description": "human_overseer_assignment_record naming the qualified overseer role for each significant and critical tier AI system with accountability documentation and training evidence", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN 3.2 requires policies and procedures that define and differentiate roles and responsibilities for human-AI configurations and oversight of AI systems. The control's consequentiality tiers, override authority, and disposition logging implement exactly that oversight governance." }, { "control": "apeiris://agentic/controls/AO-04", "id": "AO-04", "domain": "agentic", "name": "Human-in-the-Loop Gates for High-Consequence Orchestrations", "validation_objective": "Proves that every orchestration pipeline classified as irreversible-write or regulated-action contains at least one mandatory human approval gate that blocks execution until an authorized reviewer explicitly approves continuation, and that pipelines self-terminate (not auto-approve) when the gate timeout is reached without reviewer action. No irreversible or regulated pipeline action may be executed without a logged, attributed human approval decision.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "Consequence taxonomy documentation mapping all production pipeline action types to classification levels, with legal or compliance sign-off for regulated-action classifications", "Gate activation and approval records for a representative sample of high-consequence pipeline executions, each containing reviewer identity, decision, rationale, and timestamp", "Gate timeout self-termination test records confirming pipelines terminate (not auto-approve) when reviewer action is not received within the defined window", "Gate bypass incident log for the prior 12 months showing zero unauthorized bypass events, or incident records for any that occurred", "Sample reviewer decision packages confirming they present action description, predicted consequence, confidence estimate, and rollback feasibility to the reviewer" ], "evidence": [ { "id": "AO-04-E1", "description": "Consequence taxonomy documentation mapping all production pipeline action types to classification levels, with legal or compliance sign-off for regulated-action classifications", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AO-04-E2", "description": "Gate activation and approval records for a representative sample of high-consequence pipeline executions, each containing reviewer identity, decision, rationale, and timestamp", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AO-04-E3", "description": "Gate timeout self-termination test records confirming pipelines terminate (not auto-approve) when reviewer action is not received within the defined window", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "AO-04-E4", "description": "Gate bypass incident log for the prior 12 months showing zero unauthorized bypass events, or incident records for any that occurred", "evidence_type": "incident-record", "verification": "attested" }, { "id": "AO-04-E5", "description": "Sample reviewer decision packages confirming they present action description, predicted consequence, confidence estimate, and rollback feasibility to the reviewer", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN 3.2 requires policies that define and differentiate human roles for oversight of AI systems. Human-in-the-loop gates instantiate those roles at the orchestration layer, with named approvers for high-consequence multi-agent workflows." } ] }, { "requirement_id": "AI600-SEC-1", "section": "AI 600-1 \u2014 Security of GenAI Systems", "title": "Security of GenAI systems", "text": "Organizations protect generative AI systems from adversarial attacks, prompt injection, model extraction, and other security threats unique to GenAI.", "verdict": "supported", "coverage": "direct", "notes": "AS-08 hardens and assures the security control plane; EC-01 runs agents in sandboxes with process isolation; RT-02 detects direct and indirect prompt injection at every input and output; AS-05 studies frontier offensive capability before public release \u2014 providing a comprehensive GenAI-specific security control set.", "control_count": 4, "proof_chain": [ { "control": "apeiris://security/controls/AS-08", "id": "AS-08", "domain": "security", "name": "Harden and assure the security control plane as tier-zero infrastructure", "validation_objective": "All security control plane components \u2014 agent gateways, policy engines, credential and token brokers, approval services, and audit stores \u2014 must be deployed in an isolated tier-zero zone with network and identity boundaries that no governed agent can reach or traverse; separation of duties must prevent any single agent, operator, or service account from both acting under governance and modifying the controls governing that action; and the control plane configuration and access history must be tamper-evident through hash-chaining or external anchoring, with adversarial testing confirming that compromise of a governed agent cannot propagate to the control plane.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "tier_zero_inventory document listing every control-plane component (gateways, brokers, policy engines, approval services, audit stores) with their network segmentation boundaries, separate identity pools, and administrative access controls", "separation_of_duties_matrix confirming no single agent identity, operator account, or service principal can both perform governed actions and modify the policy, credential issuance rules, or audit records governing those same actions", "tamper_evident_audit_log for the control plane showing hash-chained or externally-anchored records of all configuration changes and administrative access events, with at least one independent verification of chain integrity", "adversarial_test_report documenting attempts by governed-agent identities to reach control-plane admin endpoints, modify policy, mint tokens, or write to audit stores \u2014 with all attempts confirmed as blocked and alerted", "control_plane_monitoring_alert_log showing detection events for any unauthorized policy change, token issuance anomaly, or audit configuration modification within the review period" ], "evidence": [ { "id": "AS-08-E1", "description": "tier_zero_inventory document listing every control-plane component (gateways, brokers, policy engines, approval services, audit stores) with their network segmentation boundaries, separate identity pools, and administrative access controls", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AS-08-E2", "description": "separation_of_duties_matrix confirming no single agent identity, operator account, or service principal can both perform governed actions and modify the policy, credential issuance rules, or audit records governing those same actions", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AS-08-E3", "description": "tamper_evident_audit_log for the control plane showing hash-chained or externally-anchored records of all configuration changes and administrative access events, with at least one independent verification of chain integrity", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "AS-08-E4", "description": "adversarial_test_report documenting attempts by governed-agent identities to reach control-plane admin endpoints, modify policy, mint tokens, or write to audit stores \u2014 with all attempts confirmed as blocked and alerted", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AS-08-E5", "description": "control_plane_monitoring_alert_log showing detection events for any unauthorized policy change, token issuance anomaly, or audit configuration modification within the review period", "evidence_type": "configuration-snapshot", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://security/controls/EC-01", "id": "EC-01", "domain": "security", "name": "Run the agent in a sandbox, from process isolation up to micro-VMs", "validation_objective": "Every agent must execute within an isolation tier matched to its threat profile, with untrusted-code agents deployed in a hypervisor-backed micro-VM (Firecracker or gVisor) that prevents direct access to the host kernel. The isolation tier must be declared in the deployment specification and cryptographically attested at runtime.", "blocking_effect": "blocks-deployment", "evidence_required": [ "sandbox_runtime_attestation confirming isolation_tier (process/gVisor/micro-VM), sandbox_type, and kernel_exposure_level for each agent run, captured at deployment time", "deployment_spec_record showing isolation_tier, sandbox_runtime, and seccomp_profile for each agent workload, diffed against the attested runtime configuration", "escape_test_result from known sandbox-escape payload execution inside the sandbox, recording reached_host (must be false), maximum_reached_boundary, and test_run_at", "syscall_profile_baseline showing the expected system call set for the agent workload and any deviations detected during runtime" ], "evidence": [ { "id": "EC-01-E1", "description": "sandbox_runtime_attestation confirming isolation_tier (process/gVisor/micro-VM), sandbox_type, and kernel_exposure_level for each agent run, captured at deployment time", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-01-E2", "description": "deployment_spec_record showing isolation_tier, sandbox_runtime, and seccomp_profile for each agent workload, diffed against the attested runtime configuration", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "EC-01-E3", "description": "escape_test_result from known sandbox-escape payload execution inside the sandbox, recording reached_host (must be false), maximum_reached_boundary, and test_run_at", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-01-E4", "description": "syscall_profile_baseline showing the expected system call set for the agent workload and any deviations detected during runtime", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "adjacent", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF Manage function: prioritise and act on the identified AI risks, treating, responding, recovering, and allocating resources. \"Run the agent in a sandbox, from process isolation up to micro-VMs\" is a corresponding risk-treatment activity." }, { "control": "apeiris://security/controls/RT-02", "id": "RT-02", "domain": "security", "name": "Detect direct and indirect prompt injection at every input and output", "validation_objective": "Every input channel \u2014 including user prompts, retrieved documents, tool results, and multimodal streams \u2014 must pass through injection inspection before reaching the agent's reasoning layer, and every agent output must pass through inspection before execution or delivery. Suspected injections must be blocked or quarantined before the agent acts on them, with attack-success-rate below the defined threshold on periodic evaluation suites.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "guardrail_decision_log with entries for each inspection event recording content_channel, trust_boundary, injection_score, and action taken (allowed/blocked/quarantined) for both input and output paths", "injection_eval_report from AgentDojo or equivalent suite showing attack-success-rate and false-positive-rate before and after the guardrail, run at least quarterly", "input_coverage_attestation confirming guardrails are applied to retrieved document streams and tool result payloads, not only direct user prompts", "redaction_audit_log confirming sensitive data was stripped at the inspection boundary during the evaluation period" ], "evidence": [ { "id": "RT-02-E1", "description": "guardrail_decision_log with entries for each inspection event recording content_channel, trust_boundary, injection_score, and action taken (allowed/blocked/quarantined) for both input and output paths", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-02-E2", "description": "injection_eval_report from AgentDojo or equivalent suite showing attack-success-rate and false-positive-rate before and after the guardrail, run at least quarterly", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-02-E3", "description": "input_coverage_attestation confirming guardrails are applied to retrieved document streams and tool result payloads, not only direct user prompts", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-02-E4", "description": "redaction_audit_log confirming sensitive data was stripped at the inspection boundary during the evaluation period", "evidence_type": "evaluation-scorecard", "verification": "automated" } ], "fit": "adjacent", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF Measure / Manage functions: analyse, assess, benchmark, and monitor the AI risks and impacts; prioritise and act on the identified AI risks, treating, responding, recovering, and allocating resources. \"Detect direct and indirect prompt injection at every input and output\" is a corresponding risk-treatment activity." }, { "control": "apeiris://security/controls/AS-05", "id": "AS-05", "domain": "security", "name": "Study frontier offensive capability before public release", "validation_objective": "Before public release of any model version, a frontier offensive-capability evaluation must be completed that measures the model's ability to autonomously find and exploit vulnerabilities, and the release must be blocked unless measured capability is at or below the defined risk threshold. Each staged access expansion must be tied to specific evidence milestones against that threshold.", "blocking_effect": "blocks-deployment", "evidence_required": [ "frontier_capability_assessment_report documenting model version, evaluation methodology, offensive capability score against the defined threshold, and the release-gating decision with approver identity and date", "control_evaluation_record showing the red-team exercises used to measure vuln-finding and multi-step exploit-chaining capability, including pass/fail outcome per scenario against the tracked-risk threshold", "deployment_gate_decision_record linking the capability score to a signed go/no-go decision with the threshold definition version referenced", "staged_release_access_log showing each incremental access expansion milestone and the specific evidence that cleared each stage", "risk_threshold_definition_document specifying the acceptable offensive capability level at each deployment tier, reviewed and signed by the responsible authority before evaluation begins" ], "evidence": [ { "id": "AS-05-E1", "description": "frontier_capability_assessment_report documenting model version, evaluation methodology, offensive capability score against the defined threshold, and the release-gating decision with approver identity and date", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "AS-05-E2", "description": "control_evaluation_record showing the red-team exercises used to measure vuln-finding and multi-step exploit-chaining capability, including pass/fail outcome per scenario against the tracked-risk threshold", "evidence_type": "red-team-report", "verification": "third-party" }, { "id": "AS-05-E3", "description": "deployment_gate_decision_record linking the capability score to a signed go/no-go decision with the threshold definition version referenced", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AS-05-E4", "description": "staged_release_access_log showing each incremental access expansion milestone and the specific evidence that cleared each stage", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AS-05-E5", "description": "risk_threshold_definition_document specifying the acceptable offensive capability level at each deployment tier, reviewed and signed by the responsible authority before evaluation begins", "evidence_type": "evaluation-scorecard", "verification": "automated" } ], "fit": "adjacent", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF Map / Measure functions: establish context and identify and categorise the AI risks; analyse, assess, benchmark, and monitor the AI risks and impacts. \"Study frontier offensive capability before public release\" is a corresponding measurement and monitoring activity." } ] }, { "requirement_id": "AI600-BF-1", "section": "AI 600-1 \u2014 Bias and Fairness in GenAI Outputs", "title": "Bias and fairness in GenAI outputs", "text": "Organizations evaluate generative AI outputs for bias, stereotyping, and unfair treatment across protected characteristics, and implement mitigations.", "verdict": "supported", "coverage": "direct", "notes": "FA-01 identifies and scopes protected characteristics; FA-02 mandates algorithmic bias impact assessment; EV-05 requires fairness and bias evaluation pre-deployment; FM-01 monitors production fairness \u2014 providing pre- and post-deployment bias governance for GenAI outputs.", "control_count": 4, "proof_chain": [ { "control": "apeiris://ethics/controls/FA-01", "id": "FA-01", "domain": "ethics", "name": "Protected Characteristic Identification and Scope", "validation_objective": "Every AI system must have a documented protected characteristic register that enumerates all characteristics protected under each applicable jurisdiction's law, including identified proxy variables that may encode those characteristics, updated whenever jurisdictional scope or system use case changes.", "blocking_effect": "blocks-deployment", "evidence_required": [ "protected_characteristic_register listing each characteristic with jurisdiction_applicability, regulatory_basis (statute or directive citation), and proxy_variable_mapping", "jurisdictional_scope_analysis document identifying all operating jurisdictions and the applicable non-discrimination statutes for each", "proxy_variable_review_record showing assessment of training features for potential encoding of protected characteristics", "legal_or_compliance_sign_off_record confirming register completeness for current jurisdictional scope and use context" ], "evidence": [ { "id": "FA-01-E1", "description": "protected_characteristic_register listing each characteristic with jurisdiction_applicability, regulatory_basis (statute or directive citation), and proxy_variable_mapping", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-01-E2", "description": "jurisdictional_scope_analysis document identifying all operating jurisdictions and the applicable non-discrimination statutes for each", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-01-E3", "description": "proxy_variable_review_record showing assessment of training features for potential encoding of protected characteristics", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-01-E4", "description": "legal_or_compliance_sign_off_record confirming register completeness for current jurisdictional scope and use context", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP 1.5 calls for organizational risk tolerance to be defined with reference to affected populations and context. Identifying protected characteristics is the mechanism by which fairness-relevant populations are enumerated and made actionable within the risk mapping process." }, { "control": "apeiris://ethics/controls/FA-02", "id": "FA-02", "domain": "ethics", "name": "Algorithmic Bias Impact Assessment", "validation_objective": "Every AI system subject to fairness evaluation must have a completed Algorithmic Bias Impact Assessment (ABIA) covering all protected characteristics in the FA-01 register, addressing both training data composition bias and model prediction disparities, completed before initial deployment and re-run after any material model or data change.", "blocking_effect": "blocks-deployment", "evidence_required": [ "algorithmic_bias_impact_assessment_report with per-characteristic findings, methodology description, direct discrimination and disparate impact pathways assessed, and risk rating for each finding", "training_data_composition_report showing demographic representation across protected groups relative to the reference deployment population", "model_prediction_disaggregation_report showing predicted outcome rates by protected characteristic with confidence intervals and statistical significance testing", "feedback_loop_risk_analysis documenting whether biased model outputs could influence future training data collection or labeling", "abia_reviewer_sign_off_record with reviewer credentials and date confirming independence from the model development team" ], "evidence": [ { "id": "FA-02-E1", "description": "algorithmic_bias_impact_assessment_report with per-characteristic findings, methodology description, direct discrimination and disparate impact pathways assessed, and risk rating for each finding", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E2", "description": "training_data_composition_report showing demographic representation across protected groups relative to the reference deployment population", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E3", "description": "model_prediction_disaggregation_report showing predicted outcome rates by protected characteristic with confidence intervals and statistical significance testing", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E4", "description": "feedback_loop_risk_analysis documenting whether biased model outputs could influence future training data collection or labeling", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FA-02-E5", "description": "abia_reviewer_sign_off_record with reviewer credentials and date confirming independence from the model development team", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP 2.2 requires gathering scientific and empirical information about AI risks including bias and fairness risks across affected populations. The ABIA operationalizes this requirement by providing a structured empirical evaluation methodology." }, { "control": "apeiris://model/controls/EV-05", "id": "EV-05", "domain": "model", "name": "Fairness and Bias Evaluation", "validation_objective": "The model system has a documented, pre-specified fairness evaluation protocol executed on data disjoint from training data, with disaggregated results per population group and harm type measured against pre-specified acceptance thresholds, and legal review obtained for any deployment affecting legally protected characteristics.", "blocking_effect": "blocks-deployment", "evidence_required": [ "fairness_evaluation_protocol document with pre-specified population_groups, harm_types, metric_selections, selection_rationale, legal_basis, and acceptance_thresholds \u2014 version-controlled and signed before any evaluation run begins", "disaggregated_evaluation_results report showing per-group performance metrics independently for each identified population group, with group_id, sample_count, and metric_values per harm type", "metric_tradeoff_decision_record explicitly stating which competing fairness constraints (e.g., demographic parity vs. equalized odds) take precedence for this deployment context and the documented rationale", "evaluation_data_disjointness_attestation confirming evaluation data for each population group does not overlap with the training corpus, with data_source_ids and overlap_check_method documented", "legal_review_record for any deployment affecting legally protected characteristics, with reviewing_authority identity and review_date" ], "evidence": [ { "id": "EV-05-E1", "description": "fairness_evaluation_protocol document with pre-specified population_groups, harm_types, metric_selections, selection_rationale, legal_basis, and acceptance_thresholds \u2014 version-controlled and signed before any evaluation run begins", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-05-E2", "description": "disaggregated_evaluation_results report showing per-group performance metrics independently for each identified population group, with group_id, sample_count, and metric_values per harm type", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-05-E3", "description": "metric_tradeoff_decision_record explicitly stating which competing fairness constraints (e.g., demographic parity vs. equalized odds) take precedence for this deployment context and the documented rationale", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-05-E4", "description": "evaluation_data_disjointness_attestation confirming evaluation data for each population group does not overlap with the training corpus, with data_source_ids and overlap_check_method documented", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-05-E5", "description": "legal_review_record for any deployment affecting legally protected characteristics, with reviewing_authority identity and review_date", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.11 (MEASURE function) provides that fairness and bias are evaluated and results are documented. EV-05\u2019s disaggregated error-rate measurement across protected subgroups produces the documented fairness and bias evaluation this subcategory requires." }, { "control": "apeiris://ethics/controls/FM-01", "id": "FM-01", "domain": "ethics", "name": "Production Fairness Monitoring Program", "validation_objective": "Every production AI system in scope must have an active fairness monitoring configuration with a defined metric suite, baselines, and threshold values; monitoring must run on at least a daily cadence for high-risk systems; and threshold breach alerts must be acknowledged and assigned to an incident record within 24 hours. A passing state requires 100% enrollment of in-scope systems with no computation gaps exceeding 48 hours and zero unacknowledged breach alerts older than 24 hours.", "blocking_effect": "advisory", "evidence_required": [ "fairness_monitoring_configuration_record per AI system showing enrolled_at date, metric suite, threshold values, computation cadence, and stakeholder alert routing configuration", "fairness_metric_time_series export covering the past 90 days with per-run fields for computation_timestamp, metric_id, demographic_stratum, sample_size, confidence_interval, and computed_value \u2014 with no gaps exceeding 48 hours", "threshold_breach_incident_log for the past 12 months showing each alert event with alert_timestamp, metric_name, observed_value, threshold_value, acknowledged_at, and assigned_remediation_owner", "governance_review_sign_off records from the past three monthly ethics officer review meetings confirming attendance, metrics reviewed, and compliance certification" ], "evidence": [ { "id": "FM-01-E1", "description": "fairness_monitoring_configuration_record per AI system showing enrolled_at date, metric suite, threshold values, computation cadence, and stakeholder alert routing configuration", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "FM-01-E2", "description": "fairness_metric_time_series export covering the past 90 days with per-run fields for computation_timestamp, metric_id, demographic_stratum, sample_size, confidence_interval, and computed_value \u2014 with no gaps exceeding 48 hours", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "FM-01-E3", "description": "threshold_breach_incident_log for the past 12 months showing each alert event with alert_timestamp, metric_name, observed_value, threshold_value, acknowledged_at, and assigned_remediation_owner", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "FM-01-E4", "description": "governance_review_sign_off records from the past three monthly ethics officer review meetings confirming attendance, metrics reviewed, and compliance certification", "evidence_type": "certification", "verification": "third-party" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE 2.11 requires that fairness and bias are evaluated, with results demonstrated \u2014 including in deployment contexts, not only during pre-deployment testing. The production monitoring program operationalizes this requirement by establishing a continuous measurement cadence. NIST guidance recognizes that fairness properties can degrade over time due to distribution shift, making production monitoring essential." } ] }, { "requirement_id": "AI600-RA-1", "section": "AI 600-1 \u2014 Robustness and Accuracy", "title": "Robustness and accuracy of GenAI systems", "text": "Organizations ensure generative AI systems are robust to distribution shift, adversarial perturbations, and hallucination, and maintain acceptable accuracy for intended uses.", "verdict": "supported", "coverage": "direct", "notes": "EV-04 requires adversarial red-team testing covering robustness; BH-04 evaluates behavioral boundary performance; EV-02 assesses fitness, safety, and reliability \u2014 addressing both adversarial robustness and accuracy for intended use.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/EV-04", "id": "EV-04", "domain": "model", "name": "Adversarial Red-Team Testing", "validation_objective": "The model system has a signed red-team report produced by a team organizationally independent of model development, documenting structured adversarial probing that covers all required attack categories for the applicable profiles, with all critical and high findings remediated and re-tested before the deployment gate clears.", "blocking_effect": "blocks-deployment", "evidence_required": [ "signed_red_team_scope_document with threat_model version, profile scope, and pre-exercise approval timestamp", "red_team_findings_log with finding_id, severity_classification, reproduction_steps, affected_population, and remediation_status per finding", "signed_red_team_report with residual_risk_statement linked to model artifact hash and listing remediated critical and high findings with re-test results", "remediation_evidence for all critical and high findings demonstrating the vulnerability is closed via re-test, not only via input-level patch", "for frontier-capability profile: escalation_records for any capability elicited at or near threshold levels with escalation_destination and response_action" ], "evidence": [ { "id": "EV-04-E1", "description": "signed_red_team_scope_document with threat_model version, profile scope, and pre-exercise approval timestamp", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EV-04-E2", "description": "red_team_findings_log with finding_id, severity_classification, reproduction_steps, affected_population, and remediation_status per finding", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-04-E3", "description": "signed_red_team_report with residual_risk_statement linked to model artifact hash and listing remediated critical and high findings with re-test results", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "EV-04-E4", "description": "remediation_evidence for all critical and high findings demonstrating the vulnerability is closed via re-test, not only via input-level patch", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "EV-04-E5", "description": "for frontier-capability profile: escalation_records for any capability elicited at or near threshold levels with escalation_destination and response_action", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.7 (MEASURE function) provides that AI system security and resilience are evaluated and documented. EV-04\u2019s adversarial red-team exercises are the security evaluation this subcategory requires, documented as pre-deployment evidence." }, { "control": "apeiris://model/controls/BH-04", "id": "BH-04", "domain": "model", "name": "Behavioral Boundary Performance Testing", "validation_objective": "A versioned BoundaryTestSuite must be executed at minimum daily against the production inference endpoint, BoundaryAdherenceRate must be computed per boundary category and trended over a 30-day rolling window, and critical alerts plus cross-domain notifications to securitycontrols.ai must fire within one probe cycle when any category drops below 90% adherence \u2014 with all probe results logged in the evidence registry under BH-04 control linkage.", "blocking_effect": "advisory", "evidence_required": [ "versioned BoundaryTestSuite artifact with probe categories covered, probe count per category, probe source documentation, and last review date signed by the model owner and security team", "BoundaryAdherenceRate time-series for trailing 90 days per boundary category, including probe_id, timestamp, model_version, response_hash, and pass/fail for each probe execution", "cross-domain alert log showing securitycontrols.ai notifications for adherence drops with triggered_at, affected_category, adherence_rate, and acknowledgment timestamp for each event in the trailing 90 days", "pre-release BoundaryTestSuite run results for the current production model version establishing the BoundaryAdherenceRate baseline at deployment" ], "evidence": [ { "id": "BH-04-E1", "description": "versioned BoundaryTestSuite artifact with probe categories covered, probe count per category, probe source documentation, and last review date signed by the model owner and security team", "evidence_type": "human-review-record", "verification": "human" }, { "id": "BH-04-E2", "description": "BoundaryAdherenceRate time-series for trailing 90 days per boundary category, including probe_id, timestamp, model_version, response_hash, and pass/fail for each probe execution", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-04-E3", "description": "cross-domain alert log showing securitycontrols.ai notifications for adherence drops with triggered_at, affected_category, adherence_rate, and acknowledgment timestamp for each event in the trailing 90 days", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "BH-04-E4", "description": "pre-release BoundaryTestSuite run results for the current production model version establishing the BoundaryAdherenceRate baseline at deployment", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.7 (MEASURE function) provides that AI system security and resilience are evaluated and documented. BH-04\u2019s continuous BoundaryTestSuite keeps the security-and-resilience evaluation current in production rather than only at release." }, { "control": "apeiris://model/controls/EV-02", "id": "EV-02", "domain": "model", "name": "Fitness, Safety, Reliability and Policy-Conformance Evaluation", "validation_objective": "Before deployment, every model has been evaluated against pre-specified, dimension-level pass/fail thresholds \u2014 fitness, safety, reliability, and policy-conformance \u2014 with results documented against the model artifact hash and evaluation suite version. No threshold is modified after evaluation begins, and any threshold trade-off decision is documented as a named risk-acceptance record before the deployment manifest is signed.", "blocking_effect": "blocks-deployment", "evidence_required": [ "pre_specified_evaluation_protocol with model_artifact_hash, evaluation_suite_version, and per-dimension thresholds (fitness accuracy target, safety refusal rate, reliability error budget, policy-conformance violation rate), signed by the evaluation lead before testing begins \u2014 not after results are known", "dimension_level_evaluation_results showing per-dimension metric values, pass/fail verdict against pre-specified threshold, and model_artifact_hash confirming results correspond to the evaluated version", "evaluation_suite_provenance_record confirming that evaluation datasets are disjoint from training data, with contamination-check reference to TG-05 attestation", "risk_acceptance_record for any dimension where the pass threshold was not met but deployment was authorized, documenting named risk-accepter, specific capability gap, deployment risk consequence, and remediation deadline" ], "evidence": [ { "id": "EV-02-E1", "description": "pre_specified_evaluation_protocol with model_artifact_hash, evaluation_suite_version, and per-dimension thresholds (fitness accuracy target, safety refusal rate, reliability error budget, policy-conformance violation rate), signed by the evaluation lead before testing begins \u2014 not after results are known", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-02-E2", "description": "dimension_level_evaluation_results showing per-dimension metric values, pass/fail verdict against pre-specified threshold, and model_artifact_hash confirming results correspond to the evaluated version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-02-E3", "description": "evaluation_suite_provenance_record confirming that evaluation datasets are disjoint from training data, with contamination-check reference to TG-05 attestation", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-02-E4", "description": "risk_acceptance_record for any dimension where the pass threshold was not met but deployment was authorized, documenting named risk-accepter, specific capability gap, deployment risk consequence, and remediation deadline", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE-2.3 (MEASURE function) provides that AI system performance or assurance criteria are measured and demonstrated for conditions similar to deployment. EV-02\u2019s fitness, safety, reliability, and policy-conformance dimensions measure and demonstrate the system\u2019s assurance criteria before deployment." } ] }, { "requirement_id": "AI600-EX-1", "section": "AI 600-1 \u2014 Explainability", "title": "Explainability of GenAI outputs", "text": "Organizations implement explainability mechanisms for generative AI outputs, appropriate to the use case and user population, including technical and non-technical explanations.", "verdict": "supported", "coverage": "direct", "notes": "XP-01 governs explainability method selection and justification; XP-02 specifies decision-level explanation requirements; XP-05 mandates model card and system card transparency disclosure; XP-06 defines technical vs. non-technical explanation tiers \u2014 directly addressing GenAI explainability requirements.", "control_count": 4, "proof_chain": [ { "control": "apeiris://ethics/controls/XP-01", "id": "XP-01", "domain": "ethics", "name": "Explainability Method Selection and Justification", "validation_objective": "Every high-stakes AI system in production has a documented explainability method selection record in the approved registry, including a written justification that names the method, the model type it covers, known fidelity limitations, regulatory requirements satisfied, and alternative methods considered; and no high-stakes model was promoted to production without ethics officer sign-off on method selection.", "blocking_effect": "blocks-deployment", "evidence_required": [ "explainability_method_registry document listing each model type and decision-stakes combination mapped to approved methods, with version date and reviewing authority signature", "method_selection_justification_record per model deployment with fields: model_id, model_type, decision_stakes_tier, selected_method, fidelity_limitations, regulatory_requirements_satisfied, alternative_methods_considered, and ethics_officer_sign_off_date", "deployment_gate_approval_record showing explainability method approval was a required gate in the model deployment pipeline for each high-stakes model", "model_card entry for each model showing the selected explainability method and its documented limitations" ], "evidence": [ { "id": "XP-01-E1", "description": "explainability_method_registry document listing each model type and decision-stakes combination mapped to approved methods, with version date and reviewing authority signature", "evidence_type": "human-review-record", "verification": "human" }, { "id": "XP-01-E2", "description": "method_selection_justification_record per model deployment with fields: model_id, model_type, decision_stakes_tier, selected_method, fidelity_limitations, regulatory_requirements_satisfied, alternative_methods_considered, and ethics_officer_sign_off_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "XP-01-E3", "description": "deployment_gate_approval_record showing explainability method approval was a required gate in the model deployment pipeline for each high-stakes model", "evidence_type": "human-review-record", "verification": "human" }, { "id": "XP-01-E4", "description": "model_card entry for each model showing the selected explainability method and its documented limitations", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE 2.9 requires that the AI model to be deployed is explained, validated, and documented. Method selection determines what explanations are possible, and the RMF's guidance notes that explanations must be tailored to context and model type \u2014 making documented, fit-for-purpose method selection a prerequisite for satisfying this subcategory." }, { "control": "apeiris://ethics/controls/XP-02", "id": "XP-02", "domain": "ethics", "name": "Decision-Level Explanation Requirements", "validation_objective": "Each class of AI-driven decision has a documented explanation specification that defines the required explanation type, depth, and format, explicitly maps to applicable legal obligations (GDPR Art. 22, EU AI Act Art. 13, Colorado AI Act, or other jurisdiction-specific requirements), and is implemented in deployed systems such that explanations generated conform to the specification and are verifiably produced before each decision is communicated.", "blocking_effect": "blocks-deployment", "evidence_required": [ "decision_explanation_specification per decision class with fields: decision_class_id, applicable_legal_obligations, required_explanation_type (feature-attribution, counterfactual, rule-based, natural-language), required_depth (summary, detailed, technical), required_format (structured-json, natural-language, visual), and audience (end-user, regulator, internal-audit)", "explanation_generation_log showing that for each AI decision record a corresponding explanation artifact was generated with timestamp, decision_id, explanation_type, and explanation_content_hash", "explanation_format_compliance_test_report confirming that generated explanations conform to the specification for each decision class", "legal_review_attestation confirming the explanation specification meets applicable legal obligations for each jurisdiction in which the system is deployed" ], "evidence": [ { "id": "XP-02-E1", "description": "decision_explanation_specification per decision class with fields: decision_class_id, applicable_legal_obligations, required_explanation_type (feature-attribution, counterfactual, rule-based, natural-language), required_depth (summary, detailed, technical), required_format (structured-json, natural-language, visual), and audience (end-user, regulator, internal-audit)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "XP-02-E2", "description": "explanation_generation_log showing that for each AI decision record a corresponding explanation artifact was generated with timestamp, decision_id, explanation_type, and explanation_content_hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "XP-02-E3", "description": "explanation_format_compliance_test_report confirming that generated explanations conform to the specification for each decision class", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "XP-02-E4", "description": "legal_review_attestation confirming the explanation specification meets applicable legal obligations for each jurisdiction in which the system is deployed", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF GOVERN 1.1 requires that legal and regulatory requirements involving AI are understood, managed, and documented. A decision taxonomy that maps each AI decision class to its explanation obligations is the instrument that documents and manages those legal explanation requirements across the portfolio." }, { "control": "apeiris://ethics/controls/XP-05", "id": "XP-05", "domain": "ethics", "name": "Model Card and System Card Transparency Disclosure", "validation_objective": "Every AI system deployed in a high-stakes or public-facing context has a current published model card or system card that accurately represents the system's capabilities, limitations, intended use, known failure modes, and fairness evaluation results; cards are version-controlled and updated when the system undergoes material changes; and no high-stakes AI system is in production without a current card accessible to deployers and affected stakeholders.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_card_or_system_card document per AI system with required fields: system_id, model_version, intended_use, out_of_scope_uses, known_limitations, failure_modes, fairness_evaluation_results (metric name, value, demographic group, evaluation_date), and last_updated_date", "model_card_version_history log showing card updates aligned to model changes with delta description for each version", "card_publication_record confirming the card is accessible at a documented public or deployer-accessible URL before the system was deployed", "material_change_review_log showing that each model retraining, feature change, or scope expansion triggered a card update review with decision to update or document rationale for no-update" ], "evidence": [ { "id": "XP-05-E1", "description": "model_card_or_system_card document per AI system with required fields: system_id, model_version, intended_use, out_of_scope_uses, known_limitations, failure_modes, fairness_evaluation_results (metric name, value, demographic group, evaluation_date), and last_updated_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "XP-05-E2", "description": "model_card_version_history log showing card updates aligned to model changes with delta description for each version", "evidence_type": "audit-log", "verification": "automated" }, { "id": "XP-05-E3", "description": "card_publication_record confirming the card is accessible at a documented public or deployer-accessible URL before the system was deployed", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "XP-05-E4", "description": "material_change_review_log showing that each model retraining, feature change, or scope expansion triggered a card update review with decision to update or document rationale for no-update", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MAP 5.1 requires that the likelihood and impact of undesirable AI outcomes be identified and documented. Model cards are the primary artifact for fulfilling this documentation requirement, capturing known failure modes, performance limitations, and subgroup disparities." }, { "control": "apeiris://ethics/controls/XP-06", "id": "XP-06", "domain": "ethics", "name": "Technical vs. Non-Technical Explanation Tiers", "validation_objective": "All AI decision systems classified as requiring explanations must implement a minimum three-tier explanation structure (affected-individual plain-language, business-operational summary, technical audit log) that accurately represents the decision at each tier without distortion. Tier-1 individual explanations must pass intelligibility review with representative target audience members prior to production.", "blocking_effect": "blocks-deployment", "evidence_required": [ "explanation_tier_matrix document mapping each audience type (affected individual, business user, technical reviewer, regulator) to required explanation format, depth, and delivery mechanism for each high-stakes AI system", "tier-1 plain-language explanation samples with intelligibility testing records showing comprehension scores from representative target audience participants", "tier-3 technical audit log samples showing feature attribution, model version, and decision factors with cross-reference to corresponding tier-1 explanation for accuracy comparison", "access control configuration records confirming tier-1 explanations are accessible to affected individuals on demand within legally required timeframes", "tier translation methodology documentation showing how technical attribution outputs map to plain-language explanations without material inaccuracy" ], "evidence": [ { "id": "XP-06-E1", "description": "explanation_tier_matrix document mapping each audience type (affected individual, business user, technical reviewer, regulator) to required explanation format, depth, and delivery mechanism for each high-stakes AI system", "evidence_type": "human-review-record", "verification": "human" }, { "id": "XP-06-E2", "description": "tier-1 plain-language explanation samples with intelligibility testing records showing comprehension scores from representative target audience participants", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "XP-06-E3", "description": "tier-3 technical audit log samples showing feature attribution, model version, and decision factors with cross-reference to corresponding tier-1 explanation for accuracy comparison", "evidence_type": "audit-log", "verification": "automated" }, { "id": "XP-06-E4", "description": "access control configuration records confirming tier-1 explanations are accessible to affected individuals on demand within legally required timeframes", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "XP-06-E5", "description": "tier translation methodology documentation showing how technical attribution outputs map to plain-language explanations without material inaccuracy", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MEASURE 2.9 requires that the model is explained, validated, and documented, with explanations meaningful to relevant stakeholders. The RMF recognizes that different stakeholders have different information needs, and the tiered explanation framework operationalizes that audience-calibration expectation." } ] }, { "requirement_id": "AI600-IR-1", "section": "AI 600-1 \u2014 Incident Response for GenAI", "title": "Incident response for GenAI systems", "text": "Organizations establish and exercise incident response plans specific to generative AI systems, including procedures for harmful outputs, model failures, and adversarial events.", "verdict": "supported", "coverage": "direct", "notes": "CR-04 manages AI incident response including post-incident analysis; AG-05 defines the agent incident response program; OA-07 establishes the incident escalation authority chain \u2014 collectively addressing GenAI-specific incident response across model and agentic layers.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/CR-04", "id": "CR-04", "domain": "model", "name": "AI Incident Response Management", "validation_objective": "The organization must have a documented, version-controlled AI Incident Response Plan (AIRP) with AI-specific containment playbooks covering model rollback, output-filter enforcement, traffic shaping, and full model shutdown \u2014 tested via at least four quarterly tabletop exercises per year using MITRE ATLAS adversarial scenarios \u2014 and P1/P2 post-incident review records produced within 5 days of event resolution for all qualifying events in the trailing 12 months.", "blocking_effect": "blocks-deployment", "evidence_required": [ "AI Incident Response Plan document (version-controlled, CISO or AI-risk-owner signed, with review date within 12 months)", "Containment playbook index listing separate runbooks for model_rollback, output_filter_enforcement, traffic_shaping, and model_shutdown_with_fallback", "Last 4 quarterly tabletop exercise reports with MITRE ATLAS scenario identifier, participant roster, outcomes, and reviewer sign-off", "P1 and P2 post-incident review records for all qualifying events in the trailing 12 months, each showing post_incident_report_date within 5 days of incident_resolved_date", "EU Art. 73 notification trigger mapping document showing which P1 severity criteria trigger the Art. 73 serious-incident notification obligation (15d general / 10d death / 2d widespread or critical infrastructure)" ], "evidence": [ { "id": "CR-04-E1", "description": "AI Incident Response Plan document (version-controlled, CISO or AI-risk-owner signed, with review date within 12 months)", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-04-E2", "description": "Containment playbook index listing separate runbooks for model_rollback, output_filter_enforcement, traffic_shaping, and model_shutdown_with_fallback", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-04-E3", "description": "Last 4 quarterly tabletop exercise reports with MITRE ATLAS scenario identifier, participant roster, outcomes, and reviewer sign-off", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CR-04-E4", "description": "P1 and P2 post-incident review records for all qualifying events in the trailing 12 months, each showing post_incident_report_date within 5 days of incident_resolved_date", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-04-E5", "description": "EU Art. 73 notification trigger mapping document showing which P1 severity criteria trigger the Art. 73 serious-incident notification obligation (15d general / 10d death / 2d widespread or critical infrastructure)", "evidence_type": "incident-record", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MANAGE-4.1 (MANAGE function) provides that post-deployment monitoring plans are implemented, including appeal and override, decommissioning, incident response, and change management. CR-04\u2019s AI-specific incident response plan implements the incident-response and recovery components of post-deployment risk management, tested through recurring tabletop exercises." }, { "control": "apeiris://agentic/controls/AG-05", "id": "AG-05", "domain": "agentic", "name": "Agent Incident Response Program", "validation_objective": "The enterprise has a documented, tested AI Incident Response Playbook with AI-specific containment capabilities, and every production agent has an authenticated kill-switch that demonstrably suspends its operation within 60 seconds of an authorized responder request.", "blocking_effect": "requires-review", "evidence_required": [ "AI Incident Response Playbook document covering incident classification taxonomy, severity tiers with quantitative criteria, containment actions per incident type, escalation matrix, and regulatory notification timelines", "Kill-switch capability validation records for each production agent, confirming suspension within the 60-second SLA in the most recent test", "Tabletop or functional test records for the AI Incident Response Playbook covering at least P1 and P2 severity scenarios", "Post-incident review records for all P1 and P2 events including root cause, containment timeline, and lessons-learned pipeline submissions" ], "evidence": [ { "id": "AG-05-E1", "description": "AI Incident Response Playbook document covering incident classification taxonomy, severity tiers with quantitative criteria, containment actions per incident type, escalation matrix, and regulatory notification timelines", "evidence_type": "incident-record", "verification": "attested" }, { "id": "AG-05-E2", "description": "Kill-switch capability validation records for each production agent, confirming suspension within the 60-second SLA in the most recent test", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "AG-05-E3", "description": "Tabletop or functional test records for the AI Incident Response Playbook covering at least P1 and P2 severity scenarios", "evidence_type": "incident-record", "verification": "attested" }, { "id": "AG-05-E4", "description": "Post-incident review records for all P1 and P2 events including root cause, containment timeline, and lessons-learned pipeline submissions", "evidence_type": "incident-record", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MANAGE 4.3 requires processes for tracking, responding to, and recovering from AI incidents and errors, with communication to relevant AI actors. An agent-specific incident response program with playbooks and regulatory notification procedures is the direct implementation." }, { "control": "apeiris://model/controls/OA-07", "id": "OA-07", "domain": "model", "name": "Incident Escalation Authority Chain", "validation_objective": "The organization must have a documented incident escalation authority chain for AI model incidents with named individuals at each of four levels, explicit decision rights at each level, time bounds for escalation steps, a defined board-level notification threshold, and annual tabletop exercise completion records. For EU high-risk AI systems, the escalation chain must map EU AI Act Art-73 serious incident reporting obligations (15-day general deadline; 10 days for death; 2 days for widespread infringement or critical-infrastructure incidents) to a specific escalation level.", "blocking_effect": "blocks-deployment", "evidence_required": [ "escalation_authority_chain_document current version with named individuals (not just roles) at each of the four escalation levels, decision rights matrix, time bounds per level, and board-level notification threshold definition \u2014 with approval date", "annual_tabletop_exercise_record for the preceding 12 months, including scenario description, participant list, escalation chain performance against time bounds, gaps identified, and remediation actions", "incident_post_mortem_records for AI model incidents in the preceding 12 months showing escalation chain adherence, time-bound compliance, and regulatory notification actions taken", "regulatory_notification_obligation_mapping document linking EU AI Act Art-73, sector-specific incident reporting requirements, and other applicable obligations to specific escalation levels and time bounds" ], "evidence": [ { "id": "OA-07-E1", "description": "escalation_authority_chain_document current version with named individuals (not just roles) at each of the four escalation levels, decision rights matrix, time bounds per level, and board-level notification threshold definition \u2014 with approval date", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-07-E2", "description": "annual_tabletop_exercise_record for the preceding 12 months, including scenario description, participant list, escalation chain performance against time bounds, gaps identified, and remediation actions", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-07-E3", "description": "incident_post_mortem_records for AI model incidents in the preceding 12 months showing escalation chain adherence, time-bound compliance, and regulatory notification actions taken", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-07-E4", "description": "regulatory_notification_obligation_mapping document linking EU AI Act Art-73, sector-specific incident reporting requirements, and other applicable obligations to specific escalation levels and time bounds", "evidence_type": "incident-record", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "NIST AI RMF MANAGE-2.4 (MANAGE function) provides that mechanisms and assigned responsibilities exist to supersede, disengage, or deactivate AI systems that demonstrate performance inconsistent with intended use. OA-07\u2019s escalation authority chain assigns and documents who may authorize superseding, disengaging, or deactivating a model at each severity level." } ] } ] }, { "framework": "dora", "label": "DORA", "source_id": "dora", "anchored": true, "currency": { "version": "2022/2554", "published_on": "2025-01-17", "status": "current", "retrieved_on": null }, "total_requirements": 35, "summary": { "supported": 25, "partial": 10, "unsupported": 0, "out-of-scope": 0, "controls_involved": 92, "evidence_artifacts": 402, "automatable_evidence": 87 }, "obligations": [ { "requirement_id": "DORA-ART05-01", "section": "Art. 5(2)", "title": "Management Body Accountability for ICT Risk", "text": "The management body of the financial entity shall define, approve, oversee and be accountable for the implementation of all arrangements related to the ICT risk management framework.", "verdict": "supported", "coverage": "direct", "notes": "RG-01 establishes the resilience governance structure; RG-03 mandates named senior accountability for AI operational resilience; CG-01 and CG-03 extend governance and board accountability to the compliance dimension. Together these controls directly address the DORA requirement for management body ownership of the ICT risk framework as applied to AI systems.", "control_count": 4, "proof_chain": [ { "control": "apeiris://resilience/controls/RG-01", "id": "RG-01", "domain": "resilience", "name": "Resilience Governance Structure", "validation_objective": "A Resilience Steering Committee must exist with a ratified governance charter, documented cross-functional membership, and named executive sponsors. Every Tier 1 production AI system must have a named resilience owner in the RACI, and the committee must have met on its defined quarterly cadence with documented action items tracked to closure within 90 days.", "blocking_effect": "requires-review", "evidence_required": [ "Resilience Governance Charter document with ratification date, committee membership list with named executives and their roles, defined quorum rules, quarterly meeting cadence, and escalation path to board-level risk committee", "RACI mapping showing every Tier 1 production AI system with a named executive resilience sponsor and a primary resilience owner, current as of the date of evidence collection", "Quarterly committee meeting minutes for the prior two quarters confirming meetings occurred, quorum was achieved, resilience metrics were reviewed, and action items were recorded with owners and due dates", "Action item tracker export confirming all committee action items are either closed with supporting evidence or have an open status with named owner and next-review date; no item older than 90 days without documented rationale for extension" ], "evidence": [ { "id": "RG-01-E1", "description": "Resilience Governance Charter document with ratification date, committee membership list with named executives and their roles, defined quorum rules, quarterly meeting cadence, and escalation path to board-level risk committee", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RG-01-E2", "description": "RACI mapping showing every Tier 1 production AI system with a named executive resilience sponsor and a primary resilience owner, current as of the date of evidence collection", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RG-01-E3", "description": "Quarterly committee meeting minutes for the prior two quarters confirming meetings occurred, quorum was achieved, resilience metrics were reviewed, and action items were recorded with owners and due dates", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RG-01-E4", "description": "Action item tracker export confirming all committee action items are either closed with supporting evidence or have an open status with named owner and next-review date; no item older than 90 days without documented rationale for extension", "evidence_type": "configuration-snapshot", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "DORA Article 5 requires financial entities to have an internal governance and control framework for ICT risk that ensures the management body takes an active role. For EU-regulated entities operating AI systems, this makes a formal governance structure with named senior accountability a legal obligation, not a recommendation." }, { "control": "apeiris://resilience/controls/RG-03", "id": "RG-03", "domain": "resilience", "name": "Senior Accountability for AI Operational Resilience", "validation_objective": "The organization must have a current, named executive with documented formal accountability for AI operational resilience, with this designation reflected in role definitions and the enterprise risk register, and an annual attestation letter substantively reviewed and delivered to the board or audit committee within the required cycle.", "blocking_effect": "requires-review", "evidence_required": [ "Executive role designation document naming a specific individual (not a role title) with explicit AI operational resilience accountability, including an effective date and last review date", "Enterprise risk register entry confirming the named individual's accountability is registered and current, with the most recent review timestamp", "Annual executive attestation letter addressed to the board or audit committee, with evidence of engagement with underlying program assessment (not a formulaic sign-off)", "Incident escalation contact list confirming the named executive is included in the Tier 1 AI system escalation path with current contact details", "Regulatory submission records (where DORA or equivalent applies) showing the named individual's accountability is disclosed to supervisory authorities" ], "evidence": [ { "id": "RG-03-E1", "description": "Executive role designation document naming a specific individual (not a role title) with explicit AI operational resilience accountability, including an effective date and last review date", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RG-03-E2", "description": "Enterprise risk register entry confirming the named individual's accountability is registered and current, with the most recent review timestamp", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RG-03-E3", "description": "Annual executive attestation letter addressed to the board or audit committee, with evidence of engagement with underlying program assessment (not a formulaic sign-off)", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RG-03-E4", "description": "Incident escalation contact list confirming the named executive is included in the Tier 1 AI system escalation path with current contact details", "evidence_type": "incident-record", "verification": "attested" }, { "id": "RG-03-E5", "description": "Regulatory submission records (where DORA or equivalent applies) showing the named individual's accountability is disclosed to supervisory authorities", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "DORA Article 5(2) explicitly requires that the management body of financial entities define and approve strategies, policies, and procedures for ICT risk management and bear ultimate accountability. This makes named senior accountability a binding legal requirement for EU-regulated entities." }, { "control": "apeiris://compliance/controls/CG-01", "id": "CG-01", "domain": "compliance", "name": "Compliance Governance Structure", "validation_objective": "The organization must have a formally chartered Compliance Committee with documented meeting minutes showing quorum was achieved in at least 80% of scheduled sessions in the last 12 months, a CCO or equivalent with a documented direct reporting channel to the board Audit and Risk Committee that bypasses management for material issues, and a current escalation matrix reviewed within 12 months covering all material compliance issue types including AI regulatory incidents.", "blocking_effect": "requires-review", "evidence_required": [ "compliance_committee_charter signed and approved by the board with defined membership composition, quorum rules, meeting cadence, decision authority scope, and AI regulatory obligation coverage", "cco_role_documentation including the CCO written authority scope, direct reporting line to the Audit and Risk Committee as documented in board resolution or equivalent formal governance instrument, and organizational chart placement", "compliance_committee_meeting_minutes for the last 12 months showing attendees, quorum status at each session, agenda items including AI compliance matters, and action item tracking with completion status", "escalation_matrix covering all material compliance issue types \u2014 regulatory inquiry, enforcement action, material AI risk event, data breach \u2014 with defined escalation paths, response timeframes, and responsible parties for each tier", "board_resolution or formal charter ratification record establishing the compliance governance structure with effective date and scope of authority" ], "evidence": [ { "id": "CG-01-E1", "description": "compliance_committee_charter signed and approved by the board with defined membership composition, quorum rules, meeting cadence, decision authority scope, and AI regulatory obligation coverage", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-01-E2", "description": "cco_role_documentation including the CCO written authority scope, direct reporting line to the Audit and Risk Committee as documented in board resolution or equivalent formal governance instrument, and organizational chart placement", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-01-E3", "description": "compliance_committee_meeting_minutes for the last 12 months showing attendees, quorum status at each session, agenda items including AI compliance matters, and action item tracking with completion status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-01-E4", "description": "escalation_matrix covering all material compliance issue types \u2014 regulatory inquiry, enforcement action, material AI risk event, data breach \u2014 with defined escalation paths, response timeframes, and responsible parties for each tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-01-E5", "description": "board_resolution or formal charter ratification record establishing the compliance governance structure with effective date and scope of authority", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://compliance/controls/CG-03", "id": "CG-03", "domain": "compliance", "name": "Senior and Board-Level Accountability for AI Compliance", "validation_objective": "The board of directors has a formal, documented mandate for AI compliance oversight via committee resolution, an executive owner is designated in their role charter with AI compliance accountability, and at least one quarterly board compliance report has been presented within the current 90-day window with meeting minutes documenting AI compliance as a substantive agenda item and material risks discussed.", "blocking_effect": "requires-review", "evidence_required": [ "board_resolution_document with committee_name, effective_date, scope (AI compliance oversight mandate), and authorizing_signatories confirming formal assignment of AI compliance oversight", "executive_role_charter or position_description for CCO or designated executive containing explicit AI compliance accountability language and board reporting obligation, with effective_date and incumbent name", "compliance_committee_meeting_minutes from each of the prior four quarters documenting AI compliance agenda item, attendance by designated executive, and material risks discussed or acknowledged", "ai_compliance_dashboard report presented to board, timestamped within the prior 90 days, with KPI section, regulatory obligation status, and material risk disclosures" ], "evidence": [ { "id": "CG-03-E1", "description": "board_resolution_document with committee_name, effective_date, scope (AI compliance oversight mandate), and authorizing_signatories confirming formal assignment of AI compliance oversight", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-03-E2", "description": "executive_role_charter or position_description for CCO or designated executive containing explicit AI compliance accountability language and board reporting obligation, with effective_date and incumbent name", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-03-E3", "description": "compliance_committee_meeting_minutes from each of the prior four quarters documenting AI compliance agenda item, attendance by designated executive, and material risks discussed or acknowledged", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-03-E4", "description": "ai_compliance_dashboard report presented to board, timestamped within the prior 90 days, with KPI section, regulatory obligation status, and material risk disclosures", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "DORA-ART05-02", "section": "Art. 5(4)", "title": "ICT Risk Management Strategy and Risk Appetite", "text": "Financial entities shall put in place an ICT risk management strategy that reflects their overall risk appetite and determines the level of ICT risk tolerance and ICT risk exposure that they are willing to accept.", "verdict": "supported", "coverage": "direct", "notes": "RG-02 defines the resilience policy framework and strategy; RG-04 sets resilience risk appetite and thresholds for AI systems; CG-04 establishes the compliance risk appetite definition; FP-03 covers financial AI risk appetite statements relevant to financial entities. These controls directly implement DORA's risk strategy and tolerance mandates.", "control_count": 4, "proof_chain": [ { "control": "apeiris://resilience/controls/RG-02", "id": "RG-02", "domain": "resilience", "name": "Resilience Policy Framework", "validation_objective": "A tiered resilience policy hierarchy must exist covering recovery objective setting, resilience testing cadences, backup verification, and exception management. All policy documents must have been reviewed within the last 12 months with committee approval, and every production AI system must have a documented tier classification with a corresponding policy compliance mapping.", "blocking_effect": "advisory", "evidence_required": [ "Resilience policy document inventory listing each policy and standard in the hierarchy (top-level AI Resilience Policy, Recovery Objective Standard, Resilience Testing Standard, Backup and Restore Standard, Exception Management Standard) with version, effective date, last-review date, committee approval record, and named policy owner", "AI system tier classification register mapping every production AI system to its applicable policy tier with the classification rationale documented and the classification date within the last 12 months", "Policy exception register listing all active exceptions with exception ID, AI system affected, policy requirement being excepted, approved exception scope, expiry date, and risk acceptance record signed by named authority", "Compliance verification sample records confirming at least 5 AI systems were checked against their applicable tier standard within the last audit cycle, with findings and remediation actions documented" ], "evidence": [ { "id": "RG-02-E1", "description": "Resilience policy document inventory listing each policy and standard in the hierarchy (top-level AI Resilience Policy, Recovery Objective Standard, Resilience Testing Standard, Backup and Restore Standard, Exception Management Standard) with version, effective date, last-review date, committee approval record, and named policy owner", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RG-02-E2", "description": "AI system tier classification register mapping every production AI system to its applicable policy tier with the classification rationale documented and the classification date within the last 12 months", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RG-02-E3", "description": "Policy exception register listing all active exceptions with exception ID, AI system affected, policy requirement being excepted, approved exception scope, expiry date, and risk acceptance record signed by named authority", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RG-02-E4", "description": "Compliance verification sample records confirming at least 5 AI systems were checked against their applicable tier standard within the last audit cycle, with findings and remediation actions documented", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "DORA Article 6 requires financial entities to have a comprehensive ICT risk management framework including policies, procedures, and protocols. For AI systems operated by DORA-regulated entities, a formal resilience policy framework is a binding legal requirement." }, { "control": "apeiris://resilience/controls/RG-04", "id": "RG-04", "domain": "resilience", "name": "Resilience Risk Appetite and Threshold Setting", "validation_objective": "The organization must have a formally approved Resilience Risk Appetite Statement with quantitative RTO/RPO thresholds per AI system tier, supported by current BIA documentation completed within 12 months, and all production AI systems must have system-level SLOs demonstrably aligned to their tier-mandated thresholds.", "blocking_effect": "requires-review", "evidence_required": [ "Approved Resilience Risk Appetite Statement with explicit quantitative RTO/RPO thresholds per system tier (Tier 1/2/3), Resilience Steering Committee approval signature, and review date within the last 12 months", "BIA reports for all Tier 1 and Tier 2 AI systems completed within 12 months, documenting AI-specific dependencies including model inference pipelines and training data stores", "AI system inventory showing tier classification (Tier 1/2/3) for every production AI system with BIA basis and last classification review date", "System-level SLO documentation for each production AI system with explicit mapping to the governing tier threshold from the approved appetite statement", "Resilience Steering Committee meeting record confirming the threshold review was conducted and approved with quorum" ], "evidence": [ { "id": "RG-04-E1", "description": "Approved Resilience Risk Appetite Statement with explicit quantitative RTO/RPO thresholds per system tier (Tier 1/2/3), Resilience Steering Committee approval signature, and review date within the last 12 months", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RG-04-E2", "description": "BIA reports for all Tier 1 and Tier 2 AI systems completed within 12 months, documenting AI-specific dependencies including model inference pipelines and training data stores", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RG-04-E3", "description": "AI system inventory showing tier classification (Tier 1/2/3) for every production AI system with BIA basis and last classification review date", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RG-04-E4", "description": "System-level SLO documentation for each production AI system with explicit mapping to the governing tier threshold from the approved appetite statement", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RG-04-E5", "description": "Resilience Steering Committee meeting record confirming the threshold review was conducted and approved with quorum", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "DORA Article 11 requires financial entities to have an ICT business continuity policy that includes recovery time and recovery point objectives. Quantitative threshold-setting backed by governance approval is a direct legal requirement for covered entities." }, { "control": "apeiris://compliance/controls/CG-04", "id": "CG-04", "domain": "compliance", "name": "Compliance Risk Appetite Definition", "validation_objective": "A board-ratified compliance risk appetite statement exists with quantitative thresholds (maximum open critical findings, maximum remediation lag in days) and qualitative criteria for each applicable regulatory framework, and a trigger matrix mapping risk levels to required escalation or deployment-halt actions is documented and embedded in AI deployment approval workflows, with annual board review confirmed within the last 12 months.", "blocking_effect": "blocks-deployment", "evidence_required": [ "board_ratified_risk_appetite_statement containing quantitative_thresholds per regulatory framework, qualitative_criteria, approval_date, and board_signatory \u2014 confirmed reviewed and approved within the last 12 months", "compliance_trigger_matrix document defining green/amber/red risk levels with threshold values, required_actions at each level (monitor/escalate-to-CCO/deployment-pause), responsible_role, and response SLA", "ai_deployment_approval_records for at least three recent production deployments each showing explicit risk_appetite_reference field with threshold_check_outcome (pass/escalate/hold) documented", "annual_review_record confirming risk appetite was presented to and ratified by the board within the last 12 months, including any revision history and legal counsel sign-off date" ], "evidence": [ { "id": "CG-04-E1", "description": "board_ratified_risk_appetite_statement containing quantitative_thresholds per regulatory framework, qualitative_criteria, approval_date, and board_signatory \u2014 confirmed reviewed and approved within the last 12 months", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-04-E2", "description": "compliance_trigger_matrix document defining green/amber/red risk levels with threshold values, required_actions at each level (monitor/escalate-to-CCO/deployment-pause), responsible_role, and response SLA", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CG-04-E3", "description": "ai_deployment_approval_records for at least three recent production deployments each showing explicit risk_appetite_reference field with threshold_check_outcome (pass/escalate/hold) documented", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-04-E4", "description": "annual_review_record confirming risk appetite was presented to and ratified by the board within the last 12 months, including any revision history and legal counsel sign-off date", "evidence_type": "human-review-record", "verification": "human" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://finance/controls/FP-03", "id": "FP-03", "domain": "finance", "name": "Financial AI Risk Appetite Statement", "validation_objective": "The board or its designated risk committee must have approved a current Financial AI Risk Appetite Statement that quantifies the maximum acceptable exposure from AI use in financial decision-making \u2014 including materiality thresholds, error rate tolerances, and category-specific limits \u2014 with AI systems configured to alert when operating parameters approach appetite boundaries and to escalate to the board when limits are breached.", "blocking_effect": "requires-review", "evidence_required": [ "financial_ai_risk_appetite_statement board_approval_record showing approval date, approving body, vote record or unanimous consent confirmation, and version number", "risk_appetite_parameter_table showing each quantified risk metric (maximum AI-driven decision error rate, materiality threshold, maximum model output variance tolerance, category-specific exposure limits) with current measured values and defined breach thresholds", "risk_appetite_monitoring_report showing current AI system risk metrics against appetite limits, breach events in the current period, and escalation actions taken for each breach", "annual_risk_appetite_review_record documenting the review cycle, risk appetite changes approved, and triggering events (material model changes, regulatory updates, loss events) that prompted out-of-cycle reviews" ], "evidence": [ { "id": "FP-03-E1", "description": "financial_ai_risk_appetite_statement board_approval_record showing approval date, approving body, vote record or unanimous consent confirmation, and version number", "evidence_type": "human-review-record", "verification": "human" }, { "id": "FP-03-E2", "description": "risk_appetite_parameter_table showing each quantified risk metric (maximum AI-driven decision error rate, materiality threshold, maximum model output variance tolerance, category-specific exposure limits) with current measured values and defined breach thresholds", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FP-03-E3", "description": "risk_appetite_monitoring_report showing current AI system risk metrics against appetite limits, breach events in the current period, and escalation actions taken for each breach", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FP-03-E4", "description": "annual_risk_appetite_review_record documenting the review cycle, risk appetite changes approved, and triggering events (material model changes, regulatory updates, loss events) that prompted out-of-cycle reviews", "evidence_type": "human-review-record", "verification": "human" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "DORA-ART06-01", "section": "Art. 6(1)", "title": "Sound and Documented ICT Risk Management Framework", "text": "Financial entities shall have in place a sound, comprehensive and well-documented ICT risk management framework as part of their overall risk management system, which enables them to address ICT risk quickly, efficiently and comprehensively.", "verdict": "supported", "coverage": "direct", "notes": "RG-02 mandates the documented resilience policy framework; RE-06 is explicitly the DORA compliance architecture control for AI systems; CI-02 provides continuous compliance monitoring to demonstrate framework operation; CA-02 ensures the broader compliance framework selection and mapping is maintained. RE-06 is the most direct DORA anchor in the Apeiris control set.", "control_count": 4, "proof_chain": [ { "control": "apeiris://resilience/controls/RG-02", "id": "RG-02", "domain": "resilience", "name": "Resilience Policy Framework", "validation_objective": "A tiered resilience policy hierarchy must exist covering recovery objective setting, resilience testing cadences, backup verification, and exception management. All policy documents must have been reviewed within the last 12 months with committee approval, and every production AI system must have a documented tier classification with a corresponding policy compliance mapping.", "blocking_effect": "advisory", "evidence_required": [ "Resilience policy document inventory listing each policy and standard in the hierarchy (top-level AI Resilience Policy, Recovery Objective Standard, Resilience Testing Standard, Backup and Restore Standard, Exception Management Standard) with version, effective date, last-review date, committee approval record, and named policy owner", "AI system tier classification register mapping every production AI system to its applicable policy tier with the classification rationale documented and the classification date within the last 12 months", "Policy exception register listing all active exceptions with exception ID, AI system affected, policy requirement being excepted, approved exception scope, expiry date, and risk acceptance record signed by named authority", "Compliance verification sample records confirming at least 5 AI systems were checked against their applicable tier standard within the last audit cycle, with findings and remediation actions documented" ], "evidence": [ { "id": "RG-02-E1", "description": "Resilience policy document inventory listing each policy and standard in the hierarchy (top-level AI Resilience Policy, Recovery Objective Standard, Resilience Testing Standard, Backup and Restore Standard, Exception Management Standard) with version, effective date, last-review date, committee approval record, and named policy owner", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RG-02-E2", "description": "AI system tier classification register mapping every production AI system to its applicable policy tier with the classification rationale documented and the classification date within the last 12 months", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RG-02-E3", "description": "Policy exception register listing all active exceptions with exception ID, AI system affected, policy requirement being excepted, approved exception scope, expiry date, and risk acceptance record signed by named authority", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RG-02-E4", "description": "Compliance verification sample records confirming at least 5 AI systems were checked against their applicable tier standard within the last audit cycle, with findings and remediation actions documented", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "DORA Article 6 requires financial entities to have a comprehensive ICT risk management framework including policies, procedures, and protocols. For AI systems operated by DORA-regulated entities, a formal resilience policy framework is a binding legal requirement." }, { "control": "apeiris://resilience/controls/RE-06", "id": "RE-06", "domain": "resilience", "name": "DORA Compliance Architecture for AI Systems", "validation_objective": "Every AI system in scope for DORA must have a completed gap assessment against Articles 6-16 with all critical findings remediated or risk-accepted, a documented architecture mapping to all five ICT risk management pillars, third-party AI providers assessed under Articles 28-30, and TLPT scheduled and completed within the required three-year cycle for Tier 1 AI systems.", "blocking_effect": "blocks-deployment", "evidence_required": [ "DORA gap assessment report for each in-scope AI system documenting findings against Articles 6-16 with severity ratings, remediation owners, target completion dates, and current status for each finding", "AI system architecture mapping document cross-referencing design components to each of the five DORA ICT risk management pillars (identify, protect, detect, respond, recover) with named controls for each pillar", "Third-party AI provider risk assessment records under DORA Articles 28-30 including contract review summary, mandatory Article 30 provision confirmation, ICT concentration risk classification, and assessment completion date for each significant provider", "TLPT scheduling record and results for each Tier 1 AI system confirming completion within the three-year cycle, AI-specific attack scenarios included, and remediation plan for findings with owners and timelines", "DORA major incident classification criteria document for AI system failures and a reporting pipeline end-to-end test record confirming the pipeline produces a compliant draft supervisory report within required timelines" ], "evidence": [ { "id": "RE-06-E1", "description": "DORA gap assessment report for each in-scope AI system documenting findings against Articles 6-16 with severity ratings, remediation owners, target completion dates, and current status for each finding", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RE-06-E2", "description": "AI system architecture mapping document cross-referencing design components to each of the five DORA ICT risk management pillars (identify, protect, detect, respond, recover) with named controls for each pillar", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RE-06-E3", "description": "Third-party AI provider risk assessment records under DORA Articles 28-30 including contract review summary, mandatory Article 30 provision confirmation, ICT concentration risk classification, and assessment completion date for each significant provider", "evidence_type": "third-party-audit-report", "verification": "third-party" }, { "id": "RE-06-E4", "description": "TLPT scheduling record and results for each Tier 1 AI system confirming completion within the three-year cycle, AI-specific attack scenarios included, and remediation plan for findings with owners and timelines", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RE-06-E5", "description": "DORA major incident classification criteria document for AI system failures and a reporting pipeline end-to-end test record confirming the pipeline produces a compliant draft supervisory report within required timelines", "evidence_type": "incident-record", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU DORA Articles 6-16 define the complete ICT risk management framework requirements that financial entities must implement. This control maps AI system architecture directly to these binding regulatory requirements across all five ICT risk management pillars. DORA is the primary normative driver for this control, and compliance is mandatory for in-scope financial entities from January 2025." }, { "control": "apeiris://compliance/controls/CI-02", "id": "CI-02", "domain": "compliance", "name": "Continuous Compliance Monitoring", "validation_objective": "The enterprise must operate automated monitoring pipelines covering 100% of AI obligations designated as continuously monitored in the compliance program, with alert latency not exceeding the defined maximum detection window, and all alert events retained with a machine-readable audit trail. No obligation designated as continuously monitored may remain in an undetected violation state for longer than the defined maximum detection window.", "blocking_effect": "advisory", "evidence_required": [ "monitoring_pipeline_inventory listing each automated compliance monitor with obligation_id, monitor_id, check_frequency, alert_channel, and last_successful_run timestamp", "alert_log showing all compliance alert events with obligation_id, detected_at, severity, alert_channel, and assigned_responder for the review period", "false_positive_rate_report quantifying alert noise by obligation and monitor, with tuning actions taken for monitors exceeding the defined false positive threshold", "obligation_coverage_matrix confirming which obligations are covered by automated monitoring vs. periodic testing, with justification for any obligation placed in periodic-only mode", "monitoring_health_report confirming pipeline availability and last successful execution timestamp for each monitor" ], "evidence": [ { "id": "CI-02-E1", "description": "monitoring_pipeline_inventory listing each automated compliance monitor with obligation_id, monitor_id, check_frequency, alert_channel, and last_successful_run timestamp", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CI-02-E2", "description": "alert_log showing all compliance alert events with obligation_id, detected_at, severity, alert_channel, and assigned_responder for the review period", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CI-02-E3", "description": "false_positive_rate_report quantifying alert noise by obligation and monitor, with tuning actions taken for monitors exceeding the defined false positive threshold", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CI-02-E4", "description": "obligation_coverage_matrix confirming which obligations are covered by automated monitoring vs. periodic testing, with justification for any obligation placed in periodic-only mode", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CI-02-E5", "description": "monitoring_health_report confirming pipeline availability and last successful execution timestamp for each monitor", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://compliance/controls/CA-02", "id": "CA-02", "domain": "compliance", "name": "Compliance Framework Selection and Mapping", "validation_objective": "Every AI system must have a current harmonized obligation map derived from the organizational framework catalog, with all applicable frameworks present at their current published versions and every framework requirement either mapped to an organizational control or explicitly flagged as a gap routed to the CA-06 backlog with a gap_id. No requirement may exist in the obligation map in an unmapped and unrouted state.", "blocking_effect": "blocks-deployment", "evidence_required": [ "framework_catalog showing each adopted framework with current_version, last_reviewed_on (within 60 days of current framework publication), and requirement_count", "harmonized_obligation_map for the AI system listing each requirement by framework_id and requirement_id, the mapped organizational control_id or gap_id, and a harmonization_group_id where multiple frameworks share one control", "cross_framework_harmonization_report documenting the count of requirements satisfied by shared controls and estimated evidence collection reduction as a percentage", "gap_routing_records for each unmapped requirement showing obligation_id, gap_id, routed_at timestamp, and assigned CA-06 backlog entry confirmation" ], "evidence": [ { "id": "CA-02-E1", "description": "framework_catalog showing each adopted framework with current_version, last_reviewed_on (within 60 days of current framework publication), and requirement_count", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-02-E2", "description": "harmonized_obligation_map for the AI system listing each requirement by framework_id and requirement_id, the mapped organizational control_id or gap_id, and a harmonization_group_id where multiple frameworks share one control", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-02-E3", "description": "cross_framework_harmonization_report documenting the count of requirements satisfied by shared controls and estimated evidence collection reduction as a percentage", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-02-E4", "description": "gap_routing_records for each unmapped requirement showing obligation_id, gap_id, routed_at timestamp, and assigned CA-06 backlog entry confirmation", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "DORA-ART06-02", "section": "Art. 6(8)", "title": "AI System Lifecycle Integration into ICT Risk Reviews", "text": "Financial entities shall review their ICT risk management framework at least once a year, or following major ICT-related incidents, and whenever required by competent authorities. Reviews shall encompass all ICT assets including AI systems.", "verdict": "partial", "coverage": "partial", "notes": "RE-07 integrates resilience engineering review into the AI development lifecycle but focuses on design-time rather than annual enterprise-level ICT risk reviews. CA-02 and CA-05 address framework mapping and regulatory change management. The explicit annual review cadence and competent authority trigger are procedural obligations that Apeiris controls support but do not fully substitute.", "control_count": 3, "proof_chain": [ { "control": "apeiris://resilience/controls/RE-07", "id": "RE-07", "domain": "resilience", "name": "Resilience Engineering Review in Development Lifecycle", "validation_objective": "Every Tier 1 AI system must have a completed and signed Production Readiness Review with a resilience section before its first production deployment. Post-incident resilience reviews for all Severity 1 and 2 events must be completed within 5 business days, with all findings tracked in the risk register and no critical finding open beyond 30 days without documented risk acceptance.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Production Readiness Review completion record for each Tier 1 AI system including signed resilience section, named SRE or resilience lead reviewer, completion date before first production deployment, and list of any open findings with assigned owners and remediation timelines", "Architecture Review Board meeting record for each new AI system confirming the resilience checklist was completed as a blocking gate item, with checklist results and any findings documented in the ARB decision record", "Post-incident resilience review records for all Sev1 and Sev2 AI system events in the prior 12 months showing review completion date, findings identified, root cause classification, remediation owners, and closure evidence", "Resilience finding tracker export showing all open findings categorized by severity and age, with evidence that every critical finding older than 30 days has a documented risk acceptance record signed by a named authority" ], "evidence": [ { "id": "RE-07-E1", "description": "Production Readiness Review completion record for each Tier 1 AI system including signed resilience section, named SRE or resilience lead reviewer, completion date before first production deployment, and list of any open findings with assigned owners and remediation timelines", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RE-07-E2", "description": "Architecture Review Board meeting record for each new AI system confirming the resilience checklist was completed as a blocking gate item, with checklist results and any findings documented in the ARB decision record", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RE-07-E3", "description": "Post-incident resilience review records for all Sev1 and Sev2 AI system events in the prior 12 months showing review completion date, findings identified, root cause classification, remediation owners, and closure evidence", "evidence_type": "incident-record", "verification": "attested" }, { "id": "RE-07-E4", "description": "Resilience finding tracker export showing all open findings categorized by severity and age, with evidence that every critical finding older than 30 days has a documented risk acceptance record signed by a named authority", "evidence_type": "configuration-snapshot", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU DORA Article 6(5) requires financial entities to continuously update their ICT risk management framework in response to lessons learned and changes in the ICT environment. Lifecycle resilience reviews are the mechanism that satisfies this continuous update obligation. Post-incident resilience reviews feed directly into DORA ICT risk management framework updates ensuring the framework remains current." }, { "control": "apeiris://compliance/controls/CA-02", "id": "CA-02", "domain": "compliance", "name": "Compliance Framework Selection and Mapping", "validation_objective": "Every AI system must have a current harmonized obligation map derived from the organizational framework catalog, with all applicable frameworks present at their current published versions and every framework requirement either mapped to an organizational control or explicitly flagged as a gap routed to the CA-06 backlog with a gap_id. No requirement may exist in the obligation map in an unmapped and unrouted state.", "blocking_effect": "blocks-deployment", "evidence_required": [ "framework_catalog showing each adopted framework with current_version, last_reviewed_on (within 60 days of current framework publication), and requirement_count", "harmonized_obligation_map for the AI system listing each requirement by framework_id and requirement_id, the mapped organizational control_id or gap_id, and a harmonization_group_id where multiple frameworks share one control", "cross_framework_harmonization_report documenting the count of requirements satisfied by shared controls and estimated evidence collection reduction as a percentage", "gap_routing_records for each unmapped requirement showing obligation_id, gap_id, routed_at timestamp, and assigned CA-06 backlog entry confirmation" ], "evidence": [ { "id": "CA-02-E1", "description": "framework_catalog showing each adopted framework with current_version, last_reviewed_on (within 60 days of current framework publication), and requirement_count", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-02-E2", "description": "harmonized_obligation_map for the AI system listing each requirement by framework_id and requirement_id, the mapped organizational control_id or gap_id, and a harmonization_group_id where multiple frameworks share one control", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-02-E3", "description": "cross_framework_harmonization_report documenting the count of requirements satisfied by shared controls and estimated evidence collection reduction as a percentage", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-02-E4", "description": "gap_routing_records for each unmapped requirement showing obligation_id, gap_id, routed_at timestamp, and assigned CA-06 backlog entry confirmation", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://compliance/controls/CA-05", "id": "CA-05", "domain": "compliance", "name": "Regulatory Change Management", "validation_objective": "The organization must maintain a current regulatory watch list covering all applicable jurisdictions and regulatory bodies identified in active CA-01 scope records, and every regulatory publication in the monitoring period must have a completed impact assessment with triage within 5 business days of publication, with all required architecture updates completed before the publication's regulatory effective date.", "blocking_effect": "advisory", "evidence_required": [ "regulatory_watch_list document showing all monitored jurisdictions, regulatory_bodies[], authoritative_source_subscriptions[], and last_reviewed_on within the current quarter", "regulatory_change_log entries for each publication in the watch period, each containing publication_id, source, publication_date, triage_completed_at (within 5 business days), and impact_assessment_id or determination='no_impact'", "impact_assessment records for each assessed regulatory change containing affected_ai_systems[], affected_obligations[], required_architecture_updates[], assigned_owner, target_completion_date, and regulatory_effective_date", "remediation_completion_records for each required architecture update showing completed_at before target_completion_date and before regulatory_effective_date, with updated_artifact_ids referenced" ], "evidence": [ { "id": "CA-05-E1", "description": "regulatory_watch_list document showing all monitored jurisdictions, regulatory_bodies[], authoritative_source_subscriptions[], and last_reviewed_on within the current quarter", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-05-E2", "description": "regulatory_change_log entries for each publication in the watch period, each containing publication_id, source, publication_date, triage_completed_at (within 5 business days), and impact_assessment_id or determination='no_impact'", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-05-E3", "description": "impact_assessment records for each assessed regulatory change containing affected_ai_systems[], affected_obligations[], required_architecture_updates[], assigned_owner, target_completion_date, and regulatory_effective_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-05-E4", "description": "remediation_completion_records for each required architecture update showing completed_at before target_completion_date and before regulatory_effective_date, with updated_artifact_ids referenced", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "DORA-ART07-01", "section": "Art. 7(1)", "title": "ICT Systems Resilience, Reliability, and Continuous Availability", "text": "Financial entities shall use and maintain updated ICT systems, protocols and tools that are appropriate to the magnitude of operations supporting the conduct of their activities, and shall ensure high levels of availability, authenticity, integrity and confidentiality of data.", "verdict": "supported", "coverage": "direct", "notes": "RE-01 mandates high availability architecture for AI systems; FO-01 governs graceful degradation design patterns; FO-02 requires circuit breaker implementation for AI integrations; RV-06 verifies multi-region and multi-AZ resilience. Together these controls directly implement the DORA systems reliability and continuous availability mandate as applied to AI inference infrastructure.", "control_count": 4, "proof_chain": [ { "control": "apeiris://resilience/controls/RE-01", "id": "RE-01", "domain": "resilience", "name": "High Availability Architecture for AI Systems", "validation_objective": "AI inference endpoints and model serving infrastructure must be deployed across at least two independent availability zones with automated health-check-driven failover, and the system must sustain the defined availability SLO under a simulated single-AZ failure without manual intervention. Failover must complete within the documented RTO and result in zero data loss beyond the RPO.", "blocking_effect": "blocks-deployment", "evidence_required": [ "infrastructure_topology_diagram annotating AZ placement for all inference endpoints, load balancers, and supporting data services with redundancy tier labels and single-AZ failure blast radius boundaries", "slo_definition_document specifying availability_target_percentage, RTO_seconds, and RPO_seconds for each AI service component signed by the service owner", "failover_test_report from the most recent AZ-failure simulation showing time_to_failover_seconds, affected_request_count, error_count_during_failover, and data_loss_events", "auto_scaling_policy_record showing scale-in and scale-out triggers, cooldown_seconds, and minimum_healthy_instances constraint per deployment tier", "availability_monitoring_export covering 90 days of uptime data with SLO burn rate annotations and incident markers" ], "evidence": [ { "id": "RE-01-E1", "description": "infrastructure_topology_diagram annotating AZ placement for all inference endpoints, load balancers, and supporting data services with redundancy tier labels and single-AZ failure blast radius boundaries", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RE-01-E2", "description": "slo_definition_document specifying availability_target_percentage, RTO_seconds, and RPO_seconds for each AI service component signed by the service owner", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RE-01-E3", "description": "failover_test_report from the most recent AZ-failure simulation showing time_to_failover_seconds, affected_request_count, error_count_during_failover, and data_loss_events", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RE-01-E4", "description": "auto_scaling_policy_record showing scale-in and scale-out triggers, cooldown_seconds, and minimum_healthy_instances constraint per deployment tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RE-01-E5", "description": "availability_monitoring_export covering 90 days of uptime data with SLO burn rate annotations and incident markers", "evidence_type": "incident-record", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU DORA Article 11 requires financial entities to maintain redundant ICT capabilities to ensure continuity of critical functions. AI systems supporting financial workflows must meet HA requirements as part of DORA ICT business continuity policy. HA architecture documentation and test records are required audit artifacts for DORA supervisory review." }, { "control": "apeiris://resilience/controls/FO-01", "id": "FO-01", "domain": "resilience", "name": "Graceful Degradation Design Patterns", "validation_objective": "Every AI system must activate a documented degraded-mode behavior profile within 30 seconds of detecting a core dependency failure, preserve core capability delivery at the defined reduced SLA, and emit a distinct degradation_activation operational event. No enhanced capability may serve uncommunicated stale or partial outputs as authoritative responses during an active degradation period.", "blocking_effect": "advisory", "evidence_required": [ "capability_tier_inventory classifying each AI system capability as core or enhanced with documented degraded-mode SLA targets and fallback output type for each", "health_check_driven_feature_toggle_test_results confirming automatic degradation activation and correct output behavior under simulated upstream dependency failures in staging", "degradation_event_log with degradation_type, affected_capability, activation_timestamp, and duration fields for all degradation events observed in the audit period", "degraded_mode_security_review confirming authentication, authorization, rate limiting, and output filtering controls remain active on every fallback code path" ], "evidence": [ { "id": "FO-01-E1", "description": "capability_tier_inventory classifying each AI system capability as core or enhanced with documented degraded-mode SLA targets and fallback output type for each", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FO-01-E2", "description": "health_check_driven_feature_toggle_test_results confirming automatic degradation activation and correct output behavior under simulated upstream dependency failures in staging", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FO-01-E3", "description": "degradation_event_log with degradation_type, affected_capability, activation_timestamp, and duration fields for all degradation events observed in the audit period", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FO-01-E4", "description": "degraded_mode_security_review confirming authentication, authorization, rate limiting, and output filtering controls remain active on every fallback code path", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU DORA Article 11 requires financial entities to implement ICT business continuity policies covering response and recovery from ICT disruptions. Graceful degradation directly supports DORA continuity obligations by ensuring AI-dependent financial services can operate at reduced capacity during ICT disruptions rather than going fully offline. The partial fit reflects DORA's financial sector scope, while FO-01 applies universally." }, { "control": "apeiris://resilience/controls/FO-02", "id": "FO-02", "domain": "resilience", "name": "Circuit Breaker Implementation for AI Integrations", "validation_objective": "Every external and downstream AI dependency integration point must be wrapped with an independently configured circuit breaker that transitions to open state within 30 seconds of sustained failure at or above the configured failure rate threshold, emits a circuit_open event to the operational monitoring system with integration_id and failure_reason, and activates the documented fallback behavior without returning a 500 error to the calling service.", "blocking_effect": "advisory", "evidence_required": [ "ai_integration_inventory listing all outbound AI integration points with assigned circuit breaker instance identifier, per-integration failure rate threshold, sleep window, and half-open probe count configuration", "circuit_state_metric_timeseries showing open, closed, and half-open state per integration over the audit period, retained in the operational monitoring system", "circuit_transition_event_log with integration_id, failure_reason, first_failure_timestamp, state_transition, and fallback_activated fields for all open and close events in the audit period", "chaos_experiment_report confirming circuit-open activation, correct fallback behavior, and non-500 caller response under injected dependency failures for each integration within the past 90 days" ], "evidence": [ { "id": "FO-02-E1", "description": "ai_integration_inventory listing all outbound AI integration points with assigned circuit breaker instance identifier, per-integration failure rate threshold, sleep window, and half-open probe count configuration", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "FO-02-E2", "description": "circuit_state_metric_timeseries showing open, closed, and half-open state per integration over the audit period, retained in the operational monitoring system", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "FO-02-E3", "description": "circuit_transition_event_log with integration_id, failure_reason, first_failure_timestamp, state_transition, and fallback_activated fields for all open and close events in the audit period", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FO-02-E4", "description": "chaos_experiment_report confirming circuit-open activation, correct fallback behavior, and non-500 caller response under injected dependency failures for each integration within the past 90 days", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU DORA Article 12 requires backup policies and restoration and recovery procedures and methods that limit downtime and disruption. Circuit breakers contain a failing AI dependency so restoration operates on an isolated fault rather than a propagated outage, supporting the recovery objectives Article 12 protects (business continuity policy itself is Article 11)." }, { "control": "apeiris://resilience/controls/RV-06", "id": "RV-06", "domain": "resilience", "name": "Multi-Region and Multi-AZ Resilience Verification", "validation_objective": "For each multi-region or multi-AZ AI system deployment, AZ-level failover must be verified quarterly and region-level failover annually through controlled tests confirming that traffic routes correctly within the declared RTO, AI model versions are consistent across all regions, and AI system output quality is functionally equivalent in the failover region.", "blocking_effect": "blocks-deployment", "evidence_required": [ "regional_deployment_map per AI system documenting all inference endpoints, model storage locations, feature stores, and dependencies per region and availability zone", "az_failover_test_record with test_date, simulated_az, actual_failover_time_seconds, traffic_routing_verified flag, and rto_met flag for each quarterly AZ-level test", "region_failover_test_record with test_date, simulated_primary_region, failover_region, actual_failover_time_seconds, model_version_consistency_verified flag, output_quality_verified flag, and rto_met flag for each annual region test", "model_version_consistency_report showing model_version per region at time of test and confirming versions are identical across all deployed regions" ], "evidence": [ { "id": "RV-06-E1", "description": "regional_deployment_map per AI system documenting all inference endpoints, model storage locations, feature stores, and dependencies per region and availability zone", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RV-06-E2", "description": "az_failover_test_record with test_date, simulated_az, actual_failover_time_seconds, traffic_routing_verified flag, and rto_met flag for each quarterly AZ-level test", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "RV-06-E3", "description": "region_failover_test_record with test_date, simulated_primary_region, failover_region, actual_failover_time_seconds, model_version_consistency_verified flag, output_quality_verified flag, and rto_met flag for each annual region test", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "RV-06-E4", "description": "model_version_consistency_report showing model_version per region at time of test and confirming versions are identical across all deployed regions", "evidence_type": "automated-test-result", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU DORA Article 12(1)-(2) requires backup policies and documented restoration and recovery procedures and methods, including backup systems that can be activated without jeopardising security or availability. Verified multi-region and multi-AZ failover demonstrates those restoration capabilities under geographic failure (Article 12(5)'s secondary-processing-site requirements bind central securities depositories specifically)." } ] }, { "requirement_id": "DORA-ART07-02", "section": "Art. 7(2)", "title": "Security of ICT Systems, Protocols, and Infrastructure", "text": "Financial entities shall ensure that ICT systems are secure and that appropriate security measures are in place, including network controls and encryption, to minimise the risk of corruption, destruction, or unauthorised access.", "verdict": "supported", "coverage": "direct", "notes": "EC-01 mandates sandbox and process isolation for AI agent environments; EC-02 requires outbound network traffic filtering; EC-04 enforces least-privilege filesystem and tool access; EC-08 keeps secrets out of AI prompts and context. These controls directly address the DORA requirement for security of ICT systems and protocols as applied to AI execution environments.", "control_count": 4, "proof_chain": [ { "control": "apeiris://security/controls/EC-01", "id": "EC-01", "domain": "security", "name": "Run the agent in a sandbox, from process isolation up to micro-VMs", "validation_objective": "Every agent must execute within an isolation tier matched to its threat profile, with untrusted-code agents deployed in a hypervisor-backed micro-VM (Firecracker or gVisor) that prevents direct access to the host kernel. The isolation tier must be declared in the deployment specification and cryptographically attested at runtime.", "blocking_effect": "blocks-deployment", "evidence_required": [ "sandbox_runtime_attestation confirming isolation_tier (process/gVisor/micro-VM), sandbox_type, and kernel_exposure_level for each agent run, captured at deployment time", "deployment_spec_record showing isolation_tier, sandbox_runtime, and seccomp_profile for each agent workload, diffed against the attested runtime configuration", "escape_test_result from known sandbox-escape payload execution inside the sandbox, recording reached_host (must be false), maximum_reached_boundary, and test_run_at", "syscall_profile_baseline showing the expected system call set for the agent workload and any deviations detected during runtime" ], "evidence": [ { "id": "EC-01-E1", "description": "sandbox_runtime_attestation confirming isolation_tier (process/gVisor/micro-VM), sandbox_type, and kernel_exposure_level for each agent run, captured at deployment time", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-01-E2", "description": "deployment_spec_record showing isolation_tier, sandbox_runtime, and seccomp_profile for each agent workload, diffed against the attested runtime configuration", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "EC-01-E3", "description": "escape_test_result from known sandbox-escape payload execution inside the sandbox, recording reached_host (must be false), maximum_reached_boundary, and test_run_at", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-01-E4", "description": "syscall_profile_baseline showing the expected system call set for the agent workload and any deviations detected during runtime", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://security/controls/EC-02", "id": "EC-02", "domain": "security", "name": "Filter the agent's outbound network traffic", "validation_objective": "All outbound network connections from the agent must pass through an externally enforced egress proxy or firewall operating default-deny, with only task-approved destinations permitted via a per-agent TLS-SNI allowlist. Any connection attempt to a non-allowlisted destination must be dropped and logged at the network layer, not by the agent itself.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "egress_allowlist_configuration showing per-agent domain allowlist entries, match type (TLS-SNI), and default-deny posture as active enforced policy", "network_layer_egress_decision_log with agent_id, destination_host, destination_ip, port, protocol, bytes_out, allow/deny verdict, and timestamp for every connection attempt", "dns_firewall_rule_export showing DNS-tunneling prevention rules active for all agent network namespaces", "proxy_configuration_audit confirming the agent process cannot read or modify its own egress allowlist", "canary_exfil_test_report showing a prompt-injected exfiltration attempt to a non-allowlisted domain was blocked and logged" ], "evidence": [ { "id": "EC-02-E1", "description": "egress_allowlist_configuration showing per-agent domain allowlist entries, match type (TLS-SNI), and default-deny posture as active enforced policy", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-02-E2", "description": "network_layer_egress_decision_log with agent_id, destination_host, destination_ip, port, protocol, bytes_out, allow/deny verdict, and timestamp for every connection attempt", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-02-E3", "description": "dns_firewall_rule_export showing DNS-tunneling prevention rules active for all agent network namespaces", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-02-E4", "description": "proxy_configuration_audit confirming the agent process cannot read or modify its own egress allowlist", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-02-E5", "description": "canary_exfil_test_report showing a prompt-injected exfiltration attempt to a non-allowlisted domain was blocked and logged", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://security/controls/EC-04", "id": "EC-04", "domain": "security", "name": "Limit filesystem and tool access to the bare minimum", "validation_objective": "The agent must execute within an OS-level sandbox that enforces a per-task capability allowlist: only explicitly permitted filesystem mount points, tool invocations, and system calls are accessible. The sandbox must be enforced below the agent process by the OS or a dedicated runtime, not by the agent itself, and any capability not explicitly granted must be denied by default.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "sandbox_policy_export showing the active seccomp profile or capability allowlist for the agent process, limited to task-required mount points and syscalls", "tool_broker_configuration showing the permitted tool set for each agent task type with explicit least-privilege scoping per task", "sandbox_enforcement_log showing denied filesystem or tool access attempts with agent_id, resource_path, attempted_operation, deny verdict, and timestamp", "capability_audit_report confirming no filesystem paths or tool invocations are granted beyond documented task requirements" ], "evidence": [ { "id": "EC-04-E1", "description": "sandbox_policy_export showing the active seccomp profile or capability allowlist for the agent process, limited to task-required mount points and syscalls", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-04-E2", "description": "tool_broker_configuration showing the permitted tool set for each agent task type with explicit least-privilege scoping per task", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-04-E3", "description": "sandbox_enforcement_log showing denied filesystem or tool access attempts with agent_id, resource_path, attempted_operation, deny verdict, and timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-04-E4", "description": "capability_audit_report confirming no filesystem paths or tool invocations are granted beyond documented task requirements", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://security/controls/EC-08", "id": "EC-08", "domain": "security", "name": "Keep secrets out of the prompt and context", "validation_objective": "Credentials, API keys, tokens, and other secrets must never appear in the agent's prompt, system prompt, or context window. All secret access must be mediated through a secrets broker that resolves credentials at point-of-use as opaque reference IDs, with the reasoning engine structurally isolated from the execution layer that holds plaintext secret values. The system must resist system-prompt extraction attacks.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "secrets_broker_access_log showing each credential resolution event with agent_id, secret_reference_id, resolved_at timestamp, and confirmation that plaintext was not passed to model context", "context_scan_report showing a scan of all active agent system prompts and context templates for secret patterns (API key formats, PEM headers, password-like strings) with zero findings", "architectural_separation_record confirming the model inference layer and the execution layer holding secret values are structurally isolated with no shared memory or context path", "system_prompt_extraction_test_results showing adversarial attempts to elicit the system prompt or injected credentials returned no secret material" ], "evidence": [ { "id": "EC-08-E1", "description": "secrets_broker_access_log showing each credential resolution event with agent_id, secret_reference_id, resolved_at timestamp, and confirmation that plaintext was not passed to model context", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-08-E2", "description": "context_scan_report showing a scan of all active agent system prompts and context templates for secret patterns (API key formats, PEM headers, password-like strings) with zero findings", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "EC-08-E3", "description": "architectural_separation_record confirming the model inference layer and the execution layer holding secret values are structurally isolated with no shared memory or context path", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-08-E4", "description": "system_prompt_extraction_test_results showing adversarial attempts to elicit the system prompt or injected credentials returned no secret material", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "DORA-ART08-01", "section": "Art. 8(1)", "title": "ICT Asset Identification and Classification Including AI Systems", "text": "Financial entities shall identify and classify all ICT assets, including ICT assets supporting critical or important functions, and document their interdependencies. AI systems, models, and data pipelines shall be included within the scope of this identification.", "verdict": "supported", "coverage": "direct", "notes": "IA-05 requires finding and inventorying every agent including shadow ones; II-01 establishes the AI agent identity registry; II-07 mandates identity metadata and capability manifests for each agent; MR-01 covers SR 26-2-aligned model inventory and risk tiering. Together these controls satisfy DORA's ICT asset identification mandate for AI systems and models.", "control_count": 4, "proof_chain": [ { "control": "apeiris://security/controls/IA-05", "id": "IA-05", "domain": "security", "name": "Find and inventory every agent, surface the shadow ones", "validation_objective": "The identity register must contain an entry for every agent process with system access, continuously reconciled against endpoint and SaaS telemetry. Any agent with system access and no issued identity must be flagged as a shadow agent within the policy-defined detection window and either enrolled under governance or shut down.", "blocking_effect": "advisory", "evidence_required": [ "agent_reconciliation_report showing discovered_agents (from endpoint and SaaS telemetry), registered_agents (from identity register), and gap_list of unregistered agents with first_seen timestamps", "shadow_agent_detection_log recording each unregistered-agent event with process_agent_id, host, saas_app, first_seen, and remediation_action taken", "identity_register_completeness_record confirming each entry includes owner, purpose, permitted_scope, and issued_at", "detection_window_sla_record showing time from first_seen to alert for a sample of shadow-agent events, confirming compliance with the policy SLA" ], "evidence": [ { "id": "IA-05-E1", "description": "agent_reconciliation_report showing discovered_agents (from endpoint and SaaS telemetry), registered_agents (from identity register), and gap_list of unregistered agents with first_seen timestamps", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "IA-05-E2", "description": "shadow_agent_detection_log recording each unregistered-agent event with process_agent_id, host, saas_app, first_seen, and remediation_action taken", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "IA-05-E3", "description": "identity_register_completeness_record confirming each entry includes owner, purpose, permitted_scope, and issued_at", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "IA-05-E4", "description": "detection_window_sla_record showing time from first_seen to alert for a sample of shadow-agent events, confirming compliance with the policy SLA", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://identity/controls/II-01", "id": "II-01", "domain": "identity", "name": "AI Agent Identity Registry", "validation_objective": "The system must maintain an authoritative, machine-readable registry where every deployed AI agent has a corresponding entry capturing its capability_manifest_hash, owner_id, authorization_scope, principal_type=non-human, and lifecycle_status. No AI agent may operate in any environment without a current, human-approved registry entry whose deployment_artifact_hash matches the running artifact.", "blocking_effect": "blocks-deployment", "evidence_required": [ "agent_registration_record showing agent_id, owner_id, capability_manifest_hash, authorization_scope, principal_type, lifecycle_status, and registered_at timestamp for each registered agent", "scim_export of all non-human identities via SCIM GET /Users?filter=principal_type eq \"non-human\" showing all required schema attributes populated and current", "ci_cd_gate_log covering 90 days of deployment pipeline events showing registry pre-check enforcement, with any blocked deployment events and their disposition", "quarterly_reconciliation_report comparing active credentials in the identity provider against registry entries, listing gap counts and resolution timestamps within the SLA window" ], "evidence": [ { "id": "II-01-E1", "description": "agent_registration_record showing agent_id, owner_id, capability_manifest_hash, authorization_scope, principal_type, lifecycle_status, and registered_at timestamp for each registered agent", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "II-01-E2", "description": "scim_export of all non-human identities via SCIM GET /Users?filter=principal_type eq \"non-human\" showing all required schema attributes populated and current", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "II-01-E3", "description": "ci_cd_gate_log covering 90 days of deployment pipeline events showing registry pre-check enforcement, with any blocked deployment events and their disposition", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "II-01-E4", "description": "quarterly_reconciliation_report comparing active credentials in the identity provider against registry entries, listing gap counts and resolution timestamps within the SLA window", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://identity/controls/II-07", "id": "II-07", "domain": "identity", "name": "Identity Metadata, Capability Manifest and Artifact Binding", "validation_objective": "Every deployed AI agent must have a signed capability manifest in the identity registry whose deployment_artifact_hash matches the SHA-256 digest of the currently running container image or deployment artifact. Any change to model_id, model_version, tool_set, or system_prompt_hash must trigger a mandatory re-provisioning workflow requiring owner approval before the modified artifact is permitted to authenticate.", "blocking_effect": "blocks-deployment", "evidence_required": [ "capability_manifest_registry_export showing signed manifests for all active agents with signature_verified status, model_id, model_version, tool_set_hash, system_prompt_hash, and deployment_artifact_hash for each", "deployment_gate_log covering 90 days of artifact hash comparison results at deployment pipeline execution time, including the disposition of any blocked deployments and bypass exceptions", "re_provisioning_event_log for the prior quarter showing all re-provisioning events triggered by capability manifest field changes, with approver identities, capability diffs, and timestamps", "live_artifact_hash_comparison_report comparing the deployment_artifact_hash stored in the registry against the actual running container image digest for all current production agents" ], "evidence": [ { "id": "II-07-E1", "description": "capability_manifest_registry_export showing signed manifests for all active agents with signature_verified status, model_id, model_version, tool_set_hash, system_prompt_hash, and deployment_artifact_hash for each", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "II-07-E2", "description": "deployment_gate_log covering 90 days of artifact hash comparison results at deployment pipeline execution time, including the disposition of any blocked deployments and bypass exceptions", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "II-07-E3", "description": "re_provisioning_event_log for the prior quarter showing all re-provisioning events triggered by capability manifest field changes, with approver identities, capability diffs, and timestamps", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "II-07-E4", "description": "live_artifact_hash_comparison_report comparing the deployment_artifact_hash stored in the registry against the actual running container image digest for all current production agents", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://finance/controls/MR-01", "id": "MR-01", "domain": "finance", "name": "SR 26-2 Model Inventory and Risk Tiering", "validation_objective": "Every financial AI model in production must appear in the centralized model registry with a validated risk tier, owner, validation status, and lifecycle stage assigned; the inventory must achieve 100% completeness as confirmed by cross-reference against deployment pipeline records and IT asset management data, with no unregistered production models identified.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_registry_export showing model_id, owner, risk_tier, validation_status, and lifecycle_stage for every registered entry", "cross_reference_reconciliation_report comparing registry entries against IT asset management and cloud cost records, confirming discrepancy rate \u2264 2%", "risk_tiering_decision_record for each High/Critical tier model documenting the materiality factors and criteria applied to the tier assignment with MRO approval timestamp", "deployment_gate_audit_log confirming no production promotions occurred for models without a registry record in the prior quarter", "quarterly_inventory_reconciliation_sign_off signed by Model Risk Officer attesting to completeness" ], "evidence": [ { "id": "MR-01-E1", "description": "model_registry_export showing model_id, owner, risk_tier, validation_status, and lifecycle_stage for every registered entry", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-01-E2", "description": "cross_reference_reconciliation_report comparing registry entries against IT asset management and cloud cost records, confirming discrepancy rate \u2264 2%", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-01-E3", "description": "risk_tiering_decision_record for each High/Critical tier model documenting the materiality factors and criteria applied to the tier assignment with MRO approval timestamp", "evidence_type": "human-review-record", "verification": "human" }, { "id": "MR-01-E4", "description": "deployment_gate_audit_log confirming no production promotions occurred for models without a registry record in the prior quarter", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "MR-01-E5", "description": "quarterly_inventory_reconciliation_sign_off signed by Model Risk Officer attesting to completeness", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "DORA-ART08-02", "section": "Art. 8(4)", "title": "Business Function Dependency Mapping for AI Assets", "text": "Financial entities shall identify all dependencies between ICT assets and business functions, and assess how any ICT disruption \u2014 including AI system failure or degradation \u2014 would impact critical business processes.", "verdict": "partial", "coverage": "partial", "notes": "CA-04 requires design-time compliance classification that includes business function scoping; MR-01 covers model inventory with risk tiering relative to business impact; RV-05 assesses third-party AI dependency resilience. Business function dependency mapping as a formal ICT discipline is partially addressed \u2014 Apeiris controls cover the AI asset and risk dimensions but not the full enterprise business impact analysis.", "control_count": 3, "proof_chain": [ { "control": "apeiris://compliance/controls/CA-04", "id": "CA-04", "domain": "compliance", "name": "Design-Time Compliance Classification", "validation_objective": "Before any AI system enters production, a signed ComplianceClassificationEvidence artifact must exist in the compliance registry containing the system's classification under each applicable regulatory regime identified in the CA-01 scope record, with legal counsel co-signature required for high-risk and eu-high-risk-ai tier determinations, and the artifact must be current with respect to the system's current capability manifest version.", "blocking_effect": "blocks-deployment", "evidence_required": [ "ComplianceClassificationEvidence artifact containing system_id, capability_manifest_version, classification_outputs[] (each with regime, classification_tier, determination_rationale), compliance_officer_signature, legal_counsel_signature (for high-risk tiers), valid_from, and valid_until", "deployment_gate_log entry showing ComplianceClassificationEvidence.status='valid' was verified before production promotion, with the artifact_id referenced in the gate check record", "capability_manifest document versioned at the time of classification, with the manifest version matching the ComplianceClassificationEvidence.capability_manifest_version field", "reclassification_trigger_log showing that all capability manifest changes since initial classification were evaluated for reclassification need with evaluation_outcome and reviewer_identity recorded" ], "evidence": [ { "id": "CA-04-E1", "description": "ComplianceClassificationEvidence artifact containing system_id, capability_manifest_version, classification_outputs[] (each with regime, classification_tier, determination_rationale), compliance_officer_signature, legal_counsel_signature (for high-risk tiers), valid_from, and valid_until", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-04-E2", "description": "deployment_gate_log entry showing ComplianceClassificationEvidence.status='valid' was verified before production promotion, with the artifact_id referenced in the gate check record", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-04-E3", "description": "capability_manifest document versioned at the time of classification, with the manifest version matching the ComplianceClassificationEvidence.capability_manifest_version field", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "CA-04-E4", "description": "reclassification_trigger_log showing that all capability manifest changes since initial classification were evaluated for reclassification need with evaluation_outcome and reviewer_identity recorded", "evidence_type": "configuration-snapshot", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://finance/controls/MR-01", "id": "MR-01", "domain": "finance", "name": "SR 26-2 Model Inventory and Risk Tiering", "validation_objective": "Every financial AI model in production must appear in the centralized model registry with a validated risk tier, owner, validation status, and lifecycle stage assigned; the inventory must achieve 100% completeness as confirmed by cross-reference against deployment pipeline records and IT asset management data, with no unregistered production models identified.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_registry_export showing model_id, owner, risk_tier, validation_status, and lifecycle_stage for every registered entry", "cross_reference_reconciliation_report comparing registry entries against IT asset management and cloud cost records, confirming discrepancy rate \u2264 2%", "risk_tiering_decision_record for each High/Critical tier model documenting the materiality factors and criteria applied to the tier assignment with MRO approval timestamp", "deployment_gate_audit_log confirming no production promotions occurred for models without a registry record in the prior quarter", "quarterly_inventory_reconciliation_sign_off signed by Model Risk Officer attesting to completeness" ], "evidence": [ { "id": "MR-01-E1", "description": "model_registry_export showing model_id, owner, risk_tier, validation_status, and lifecycle_stage for every registered entry", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-01-E2", "description": "cross_reference_reconciliation_report comparing registry entries against IT asset management and cloud cost records, confirming discrepancy rate \u2264 2%", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-01-E3", "description": "risk_tiering_decision_record for each High/Critical tier model documenting the materiality factors and criteria applied to the tier assignment with MRO approval timestamp", "evidence_type": "human-review-record", "verification": "human" }, { "id": "MR-01-E4", "description": "deployment_gate_audit_log confirming no production promotions occurred for models without a registry record in the prior quarter", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "MR-01-E5", "description": "quarterly_inventory_reconciliation_sign_off signed by Model Risk Officer attesting to completeness", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://resilience/controls/RV-05", "id": "RV-05", "domain": "resilience", "name": "Third-Party AI Dependency Resilience Assessment", "validation_objective": "Every third-party AI dependency (model inference APIs, embedding services, vector database providers, data enrichment services) for each production AI system must be registered and classified, with a current resilience assessment completed within the last 12 months for all critical and high dependencies, and documented fallback architecture or formal risk acceptance for any dependency whose SLA coverage is insufficient for the AI system's recovery objectives.", "blocking_effect": "requires-review", "evidence_required": [ "third_party_ai_dependency_register with dependency_id, ai_system_id, dependency_type, criticality_classification (critical|high|standard), and sla_coverage_adequate flag for all production AI systems", "dependency_resilience_assessment per critical or high dependency within last 12 months, including sla_terms, historical_uptime_12mo_percent, incident_notification_practice, and fallback_option_evaluated", "fallback_architecture_document or risk_acceptance_record with owner_signoff for each dependency where sla_coverage_adequate=false", "synthetic_monitoring_coverage_report confirming active health checks are deployed against all critical third-party AI API endpoints" ], "evidence": [ { "id": "RV-05-E1", "description": "third_party_ai_dependency_register with dependency_id, ai_system_id, dependency_type, criticality_classification (critical|high|standard), and sla_coverage_adequate flag for all production AI systems", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RV-05-E2", "description": "dependency_resilience_assessment per critical or high dependency within last 12 months, including sla_terms, historical_uptime_12mo_percent, incident_notification_practice, and fallback_option_evaluated", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RV-05-E3", "description": "fallback_architecture_document or risk_acceptance_record with owner_signoff for each dependency where sla_coverage_adequate=false", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RV-05-E4", "description": "synthetic_monitoring_coverage_report confirming active health checks are deployed against all critical third-party AI API endpoints", "evidence_type": "third-party-audit-report", "verification": "third-party" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU DORA Articles 28 through 30 establish binding requirements for ICT third-party risk management including pre-contract due diligence, contractual provisions, and ongoing monitoring of critical ICT third-party service providers. AI model API providers and cloud inference services used by financial entities fall within this scope." } ] }, { "requirement_id": "DORA-ART09-01", "section": "Art. 9(2)", "title": "Information Security Policies for ICT and AI Systems", "text": "Financial entities shall put in place information security policies, procedures, and controls for ICT risk, including for AI systems, that ensure confidentiality, integrity, and availability of data and ICT services.", "verdict": "supported", "coverage": "direct", "notes": "GV-01 mandates human hard-stops for irreversible AI actions with documented policies; EC-01 enforces sandbox containment; EC-04 enforces least-privilege access; GV-04 implements policy-as-code enforcement at runtime. These controls collectively operationalize the DORA information security policy mandate for AI system environments.", "control_count": 4, "proof_chain": [ { "control": "apeiris://security/controls/GV-01", "id": "GV-01", "domain": "security", "name": "Require a human hard-stop for irreversible actions", "validation_objective": "Every irreversible agent action (write, deletion, transfer, deployment, or any action with no safe undo path) must be deterministically halted and routed to an explicit human (or quorum) approval before execution; the agent must not be capable of self-approving such actions, and the hard-stop must be enforced at platform infrastructure level, not by a model-layer instruction.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "irreversible_action_approval_record linking each halted action to the human approver(s), approval_token with timestamp and cryptographic signature, and action outcome (executed/cancelled)", "irreversibility_classification_list identifying which action types are classified as irreversible, with the policy_version and last_review_date", "hard_stop_enforcement_log showing agent execution was suspended at the irreversible action gate and resumed only after receipt of a valid external approval token", "self_approval_rejection_log confirming any attempt by the agent to approve its own irreversible actions was blocked by the platform", "quorum_policy_record for high-stakes action categories specifying minimum required approvers and approval token validity window" ], "evidence": [ { "id": "GV-01-E1", "description": "irreversible_action_approval_record linking each halted action to the human approver(s), approval_token with timestamp and cryptographic signature, and action outcome (executed/cancelled)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-01-E2", "description": "irreversibility_classification_list identifying which action types are classified as irreversible, with the policy_version and last_review_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-01-E3", "description": "hard_stop_enforcement_log showing agent execution was suspended at the irreversible action gate and resumed only after receipt of a valid external approval token", "evidence_type": "human-review-record", "verification": "human" }, { "id": "GV-01-E4", "description": "self_approval_rejection_log confirming any attempt by the agent to approve its own irreversible actions was blocked by the platform", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-01-E5", "description": "quorum_policy_record for high-stakes action categories specifying minimum required approvers and approval token validity window", "evidence_type": "human-review-record", "verification": "human" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://security/controls/EC-01", "id": "EC-01", "domain": "security", "name": "Run the agent in a sandbox, from process isolation up to micro-VMs", "validation_objective": "Every agent must execute within an isolation tier matched to its threat profile, with untrusted-code agents deployed in a hypervisor-backed micro-VM (Firecracker or gVisor) that prevents direct access to the host kernel. The isolation tier must be declared in the deployment specification and cryptographically attested at runtime.", "blocking_effect": "blocks-deployment", "evidence_required": [ "sandbox_runtime_attestation confirming isolation_tier (process/gVisor/micro-VM), sandbox_type, and kernel_exposure_level for each agent run, captured at deployment time", "deployment_spec_record showing isolation_tier, sandbox_runtime, and seccomp_profile for each agent workload, diffed against the attested runtime configuration", "escape_test_result from known sandbox-escape payload execution inside the sandbox, recording reached_host (must be false), maximum_reached_boundary, and test_run_at", "syscall_profile_baseline showing the expected system call set for the agent workload and any deviations detected during runtime" ], "evidence": [ { "id": "EC-01-E1", "description": "sandbox_runtime_attestation confirming isolation_tier (process/gVisor/micro-VM), sandbox_type, and kernel_exposure_level for each agent run, captured at deployment time", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-01-E2", "description": "deployment_spec_record showing isolation_tier, sandbox_runtime, and seccomp_profile for each agent workload, diffed against the attested runtime configuration", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "EC-01-E3", "description": "escape_test_result from known sandbox-escape payload execution inside the sandbox, recording reached_host (must be false), maximum_reached_boundary, and test_run_at", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-01-E4", "description": "syscall_profile_baseline showing the expected system call set for the agent workload and any deviations detected during runtime", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://security/controls/EC-04", "id": "EC-04", "domain": "security", "name": "Limit filesystem and tool access to the bare minimum", "validation_objective": "The agent must execute within an OS-level sandbox that enforces a per-task capability allowlist: only explicitly permitted filesystem mount points, tool invocations, and system calls are accessible. The sandbox must be enforced below the agent process by the OS or a dedicated runtime, not by the agent itself, and any capability not explicitly granted must be denied by default.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "sandbox_policy_export showing the active seccomp profile or capability allowlist for the agent process, limited to task-required mount points and syscalls", "tool_broker_configuration showing the permitted tool set for each agent task type with explicit least-privilege scoping per task", "sandbox_enforcement_log showing denied filesystem or tool access attempts with agent_id, resource_path, attempted_operation, deny verdict, and timestamp", "capability_audit_report confirming no filesystem paths or tool invocations are granted beyond documented task requirements" ], "evidence": [ { "id": "EC-04-E1", "description": "sandbox_policy_export showing the active seccomp profile or capability allowlist for the agent process, limited to task-required mount points and syscalls", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-04-E2", "description": "tool_broker_configuration showing the permitted tool set for each agent task type with explicit least-privilege scoping per task", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-04-E3", "description": "sandbox_enforcement_log showing denied filesystem or tool access attempts with agent_id, resource_path, attempted_operation, deny verdict, and timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EC-04-E4", "description": "capability_audit_report confirming no filesystem paths or tool invocations are granted beyond documented task requirements", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://security/controls/GV-04", "id": "GV-04", "domain": "security", "name": "Enforce policy as code at run time, in the request path", "validation_objective": "A deterministic policy engine must be positioned in the request path for every agent action, evaluating each proposed action against current policy code and returning an allow/deny decision before execution; the engine must fail closed on evaluation error or uncertainty, and no agent action category may bypass policy evaluation.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "policy_decision_log with action_id, policy_version, decision (allow/deny), evaluation_latency_ms, and matched_policy_rule_id for each evaluated agent action", "fail_closed_test_record showing that disabling or erroring a policy detector caused the engine to deny the action rather than default to allow", "policy_engine_deployment_record confirming the engine is positioned in the request path as a pre-execution gate, not as a post-hoc advisory check", "policy_version_change_log with effective_from timestamp, changed_rules, and approving_authority for each policy update deployed to the request path" ], "evidence": [ { "id": "GV-04-E1", "description": "policy_decision_log with action_id, policy_version, decision (allow/deny), evaluation_latency_ms, and matched_policy_rule_id for each evaluated agent action", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-04-E2", "description": "fail_closed_test_record showing that disabling or erroring a policy detector caused the engine to deny the action rather than default to allow", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-04-E3", "description": "policy_engine_deployment_record confirming the engine is positioned in the request path as a pre-execution gate, not as a post-hoc advisory check", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-04-E4", "description": "policy_version_change_log with effective_from timestamp, changed_rules, and approving_authority for each policy update deployed to the request path", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "DORA-ART09-02", "section": "Art. 9(4)(a)", "title": "Continuous Access Control and Privileged Identity Management", "text": "Financial entities shall implement access controls, including policies on privileged access management, and ensure access rights to ICT systems and data \u2014 including AI systems \u2014 are regularly reviewed.", "verdict": "supported", "coverage": "direct", "notes": "IA-04 mandates continuous runtime permission checking (not just initial grant); IC-04 provides privileged identity management for AI systems specifically; IC-03 requires periodic identity access reviews; NI-03 enforces credential lifetime and forced rotation. These controls directly satisfy DORA's access control and privileged access management mandate for AI environments.", "control_count": 4, "proof_chain": [ { "control": "apeiris://security/controls/IA-04", "id": "IA-04", "domain": "security", "name": "Check permission continuously at run time, not just once at login", "validation_objective": "Every agent tool call must be evaluated by a policy decision point (PDP) operating on current policy state and live attributes, not on permissions cached from session initialization. A permission revocation must take effect on the agent's very next tool call, denying it before execution proceeds.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "pdp_decision_log showing for each tool call: agent_id, tool_sink, resource, scope, policy_version_evaluated, decision (allow/deny), deny_reason, and decision_latency_ms", "revocation_effectiveness_record showing that for any revoked permission the time-to-deny on the next tool call is within the policy SLA", "policy_epoch_audit confirming no allowed decision was made against a stale policy epoch after a permission change", "sequence_authorization_log recording prior_action_chain for each step, enabling detection of individually-allowed actions composing toward a hijacked objective" ], "evidence": [ { "id": "IA-04-E1", "description": "pdp_decision_log showing for each tool call: agent_id, tool_sink, resource, scope, policy_version_evaluated, decision (allow/deny), deny_reason, and decision_latency_ms", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "IA-04-E2", "description": "revocation_effectiveness_record showing that for any revoked permission the time-to-deny on the next tool call is within the policy SLA", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "IA-04-E3", "description": "policy_epoch_audit confirming no allowed decision was made against a stale policy epoch after a permission change", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "IA-04-E4", "description": "sequence_authorization_log recording prior_action_chain for each step, enabling detection of individually-allowed actions composing toward a hijacked objective", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://identity/controls/IC-04", "id": "IC-04", "domain": "identity", "name": "Privileged Identity Management for AI", "validation_objective": "All AI system identities with privilege above read-only are enrolled in the PAM platform under JIT governance with no standing credentials exceeding the policy-defined maximum TTL for their privilege tier; every privilege elevation event is logged with the requesting system, task context, and elevation reason before access is granted; and no AI service account or agent workload identity holds a static long-lived credential outside PAM enrollment.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "pam_enrollment_log: PAM platform record confirming all AI identities above privilege tier 2 are enrolled under JIT control, with enrollment_date and privilege_tier for each entry; zero gaps against the AI identity inventory", "authorization_server_token_issuance_log: log of OAuth token issuance events for AI service accounts showing token_id, scope, ttl_seconds, dpop_bound flag, and issued_at; all TTL values at or below the policy-defined maximum for the applicable privilege tier", "jit_elevation_event_log: PAM log of AI privilege elevation events showing requesting_system, task_context, elevation_reason, approver where required, and granted_access_window for each event in the trailing 90 days", "ai_identity_privilege_review_report: PAM platform report for the trailing 90 days confirming no standing tokens exceed policy TTL and no AI identities hold broad standing IAM roles outside JIT governance" ], "evidence": [ { "id": "IC-04-E1", "description": "pam_enrollment_log: PAM platform record confirming all AI identities above privilege tier 2 are enrolled under JIT control, with enrollment_date and privilege_tier for each entry; zero gaps against the AI identity inventory", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "IC-04-E2", "description": "authorization_server_token_issuance_log: log of OAuth token issuance events for AI service accounts showing token_id, scope, ttl_seconds, dpop_bound flag, and issued_at; all TTL values at or below the policy-defined maximum for the applicable privilege tier", "evidence_type": "audit-log", "verification": "automated" }, { "id": "IC-04-E3", "description": "jit_elevation_event_log: PAM log of AI privilege elevation events showing requesting_system, task_context, elevation_reason, approver where required, and granted_access_window for each event in the trailing 90 days", "evidence_type": "audit-log", "verification": "automated" }, { "id": "IC-04-E4", "description": "ai_identity_privilege_review_report: PAM platform report for the trailing 90 days confirming no standing tokens exceed policy TTL and no AI identities hold broad standing IAM roles outside JIT governance", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://identity/controls/IC-03", "id": "IC-03", "domain": "identity", "name": "Identity Access Review", "validation_objective": "All identity entitlements are subject to dual-trigger review: a quarterly scheduled campaign covering all identity types (human, service account, AI system) with 100% completion or auto-revocation enforcement; and an org-change-triggered review initiated within 4 hours of any HRIS termination, job-change, or transfer event. No entitlement exists for a departed identity beyond the policy-defined revocation window, and no quarterly campaign closes with uncertified items that remain active.", "blocking_effect": "requires-review", "evidence_required": [ "access_review_campaign_reports: quarterly campaign completion reports for the trailing 12 months showing reviewer_name, decision audit trail per entitlement, completion_rate, and auto_revocation_records for all uncertified items", "iga_org_change_trigger_log: IGA audit log entries for HRIS-triggered review workflows showing triggering_event_id, trigger_timestamp, review_workflow_initiated_timestamp, and sla_met flag for each event in a representative sample", "termination_access_revocation_sample: records for 10 recent identity terminations showing credential_id, termination_date, revocation_timestamp, and time_delta confirming revocation within the policy-defined window", "auto_revocation_policy_configuration: IGA platform configuration record confirming auto-revocation is enabled for uncertified entitlements with the policy-approved campaign window, and the governance approval record for the auto-revocation policy" ], "evidence": [ { "id": "IC-03-E1", "description": "access_review_campaign_reports: quarterly campaign completion reports for the trailing 12 months showing reviewer_name, decision audit trail per entitlement, completion_rate, and auto_revocation_records for all uncertified items", "evidence_type": "audit-log", "verification": "automated" }, { "id": "IC-03-E2", "description": "iga_org_change_trigger_log: IGA audit log entries for HRIS-triggered review workflows showing triggering_event_id, trigger_timestamp, review_workflow_initiated_timestamp, and sla_met flag for each event in a representative sample", "evidence_type": "audit-log", "verification": "automated" }, { "id": "IC-03-E3", "description": "termination_access_revocation_sample: records for 10 recent identity terminations showing credential_id, termination_date, revocation_timestamp, and time_delta confirming revocation within the policy-defined window", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "IC-03-E4", "description": "auto_revocation_policy_configuration: IGA platform configuration record confirming auto-revocation is enabled for uncertified entitlements with the policy-approved campaign window, and the governance approval record for the auto-revocation policy", "evidence_type": "configuration-snapshot", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://identity/controls/NI-03", "id": "NI-03", "domain": "identity", "name": "Credential Lifetime and Forced Rotation", "validation_objective": "Every AI agent credential must have an expiry timestamp that does not exceed the maximum lifetime permitted for its authorized risk tier, and the credential rotation system must demonstrate that rotation is triggered on schedule, on security events, on task completion, and on deployment updates \u2014 whichever occurs first. No credential may remain active beyond its maximum lifetime without renewal through the provisioning gate.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "credential_lifetime_record: For each active credential, a record showing issued_at, expires_at, risk_tier, and maximum_lifetime_for_tier \u2014 confirming expires_at does not exceed the tier-maximum", "rotation_event_log: Log of all credential rotation events in the past 30 days, each with rotation_trigger (scheduled/security-event/task-complete/deployment-update), prior_credential_id, new_credential_id, and rotation_timestamp", "security_event_rotation_record: Evidence that each security event (anomalous access, incident declaration, ownership change) triggered a credential rotation within the defined SLA", "expired_credential_rejection_log: Log showing that requests presenting credentials past their expiry timestamp were rejected with 401 responses \u2014 confirming expiry enforcement at runtime" ], "evidence": [ { "id": "NI-03-E1", "description": "credential_lifetime_record: For each active credential, a record showing issued_at, expires_at, risk_tier, and maximum_lifetime_for_tier \u2014 confirming expires_at does not exceed the tier-maximum", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "NI-03-E2", "description": "rotation_event_log: Log of all credential rotation events in the past 30 days, each with rotation_trigger (scheduled/security-event/task-complete/deployment-update), prior_credential_id, new_credential_id, and rotation_timestamp", "evidence_type": "audit-log", "verification": "automated" }, { "id": "NI-03-E3", "description": "security_event_rotation_record: Evidence that each security event (anomalous access, incident declaration, ownership change) triggered a credential rotation within the defined SLA", "evidence_type": "incident-record", "verification": "attested" }, { "id": "NI-03-E4", "description": "expired_credential_rejection_log: Log showing that requests presenting credentials past their expiry timestamp were rejected with 401 responses \u2014 confirming expiry enforcement at runtime", "evidence_type": "audit-log", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "DORA-ART09-03", "section": "Art. 9(4)(e)", "title": "ICT Supply Chain Security and Third-Party Integrity Verification", "text": "Financial entities shall implement policies and controls to address ICT third-party risk within their supply chain, including verifying the integrity of software, models, and data sources obtained from third parties.", "verdict": "supported", "coverage": "direct", "notes": "AS-06 requires verification of model weights and training-data provenance before loading; PT-03 mandates skill and tool manifest integrity with supply chain signing; AS-07 verifies that a skill does what it declares (behavioral integrity); CA-07 tracks third-party and supply chain compliance obligations. These controls directly implement DORA's ICT supply chain security requirement as applied to AI model and tool providers.", "control_count": 4, "proof_chain": [ { "control": "apeiris://security/controls/AS-06", "id": "AS-06", "domain": "security", "name": "Verify model-weights and training-data provenance before load", "validation_objective": "Model weights must be cryptographically signed using an approved scheme (OpenSSF Model Signing or Sigstore) and the signature must be verified at load time before the model serves any inference. Training and fine-tuning data provenance must be recorded in an ML-BOM with content hashes. Any unsigned, signature-mismatched, or tampered artifact must be refused at the load gate without exception.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_signature_verification_record confirming artifact hash, signing key identifier, verification result (pass/fail), and timestamp for every model load event including re-loads triggered by provider or version changes", "ml_bom_artifact listing all CISA minimum element clusters: SBOM metadata, system-level properties, model components (weights hash, architecture, fine-tuning state), dataset properties (lineage, sensitivity), security properties (guardrails, filters), infrastructure components, and KPIs", "training_data_provenance_attestation linking the loaded model version to its training dataset with a content hash of the dataset snapshot, not a generic dataset name reference", "load_gate_refusal_log confirming the gate refused at least one unsigned or tampered artifact during testing, with the artifact hash and refusal reason recorded", "re_verification_trigger_log showing that signature verification was re-run when provider, model version, routing, quantization, or safety configuration changed underneath an approved deployment" ], "evidence": [ { "id": "AS-06-E1", "description": "model_signature_verification_record confirming artifact hash, signing key identifier, verification result (pass/fail), and timestamp for every model load event including re-loads triggered by provider or version changes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AS-06-E2", "description": "ml_bom_artifact listing all CISA minimum element clusters: SBOM metadata, system-level properties, model components (weights hash, architecture, fine-tuning state), dataset properties (lineage, sensitivity), security properties (guardrails, filters), infrastructure components, and KPIs", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "AS-06-E3", "description": "training_data_provenance_attestation linking the loaded model version to its training dataset with a content hash of the dataset snapshot, not a generic dataset name reference", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "AS-06-E4", "description": "load_gate_refusal_log confirming the gate refused at least one unsigned or tampered artifact during testing, with the artifact hash and refusal reason recorded", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AS-06-E5", "description": "re_verification_trigger_log showing that signature verification was re-run when provider, model version, routing, quantization, or safety configuration changed underneath an approved deployment", "evidence_type": "configuration-snapshot", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://security/controls/PT-03", "id": "PT-03", "domain": "security", "name": "Verify skill/tool manifest integrity and sign the supply chain", "validation_objective": "Every skill and tool manifest must carry a valid Ed25519 signature verified against a trusted key before the agent loads or executes the plugin. An SBOM must exist for all loaded skills and dependencies, and any update that changes the manifest without a matching new valid signature must be refused both in CI and at runtime load time.", "blocking_effect": "blocks-deployment", "evidence_required": [ "signature_verification_log for each skill or tool load event, recording manifest_hash, signature_key_id, verification_result, and timestamp", "sbom_inventory listing all loaded agent skills and dependencies with provenance, version, and supplier metadata per CISA minimum elements", "ci_manifest_check_report showing the outcome of signature verification for each skill in the CI pipeline before deployment", "refused_manifest_log capturing every unsigned, signature-failed, or drifted manifest load attempt with reason and timestamp" ], "evidence": [ { "id": "PT-03-E1", "description": "signature_verification_log for each skill or tool load event, recording manifest_hash, signature_key_id, verification_result, and timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PT-03-E2", "description": "sbom_inventory listing all loaded agent skills and dependencies with provenance, version, and supplier metadata per CISA minimum elements", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "PT-03-E3", "description": "ci_manifest_check_report showing the outcome of signature verification for each skill in the CI pipeline before deployment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PT-03-E4", "description": "refused_manifest_log capturing every unsigned, signature-failed, or drifted manifest load attempt with reason and timestamp", "evidence_type": "configuration-snapshot", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://security/controls/AS-07", "id": "AS-07", "domain": "security", "name": "Verify a skill does what it declares (behavioral integrity)", "validation_objective": "Every skill must be subjected to automated static capability extraction and comparison against its declared capability manifest before being admitted to the skill registry and on every subsequent update; any discrepancy where actual capabilities (filesystem, credential, shell, or network access) exceed or contradict the declaration must result in the skill being blocked from load, with a capability-diff report retained as evidence.", "blocking_effect": "blocks-deployment", "evidence_required": [ "capability_diff_report per skill showing declared capabilities versus AST-extracted actual capabilities (filesystem, credential, shell, network) with an explicit pass or block verdict and the taxonomy version used", "skill_registry_entry containing behavioral_verification_status, verification_timestamp, declared_capabilities list, and detected_capabilities list for each admitted skill version", "static_analysis_scan_log recording AST parsing results and capability extraction for each skill version submitted to the gate", "re_verification_record confirming behavioral check was re-run on each skill update and cross-referencing the prior verification baseline to detect capability drift" ], "evidence": [ { "id": "AS-07-E1", "description": "capability_diff_report per skill showing declared capabilities versus AST-extracted actual capabilities (filesystem, credential, shell, network) with an explicit pass or block verdict and the taxonomy version used", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AS-07-E2", "description": "skill_registry_entry containing behavioral_verification_status, verification_timestamp, declared_capabilities list, and detected_capabilities list for each admitted skill version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AS-07-E3", "description": "static_analysis_scan_log recording AST parsing results and capability extraction for each skill version submitted to the gate", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AS-07-E4", "description": "re_verification_record confirming behavioral check was re-run on each skill update and cross-referencing the prior verification baseline to detect capability drift", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://compliance/controls/CA-07", "id": "CA-07", "domain": "compliance", "name": "Third-Party and Supply Chain Compliance Obligations", "validation_objective": "Every supply chain participant for each AI system in scope must have an entry in the third-party compliance obligation register documenting all flowing obligations and a corresponding executed binding contractual instrument containing audit rights, with third-party compliance attestations collected within the defined refresh cycle and incorporated into the CA-03 routing table as evidence inputs.", "blocking_effect": "blocks-deployment", "evidence_required": [ "third_party_compliance_obligation_register entries for each supply chain participant containing vendor_id, vendor_role, applicable_obligations[], contract_instrument_id, contract_execution_date, and next_attestation_due_date", "executed_contract_inventory for each supply chain participant showing contract_type (DPA, EU_AI_Act_compliance_schedule, supplier_agreement), execution_date, audit_rights_clause_present=true, and sub_processor_management_clause_present=true for data processors", "third_party_attestation_collection_log showing each attestation collected with collection_date, valid_until, attesting_entity_name, attestation_scope, and the CA-03 routing_table_entry_id that references it", "service_dependency_map for each AI system listing all integrated third-party APIs, model providers, and data services cross-referenced against the obligation register to confirm no vendor is absent from the register" ], "evidence": [ { "id": "CA-07-E1", "description": "third_party_compliance_obligation_register entries for each supply chain participant containing vendor_id, vendor_role, applicable_obligations[], contract_instrument_id, contract_execution_date, and next_attestation_due_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-07-E2", "description": "executed_contract_inventory for each supply chain participant showing contract_type (DPA, EU_AI_Act_compliance_schedule, supplier_agreement), execution_date, audit_rights_clause_present=true, and sub_processor_management_clause_present=true for data processors", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-07-E3", "description": "third_party_attestation_collection_log showing each attestation collected with collection_date, valid_until, attesting_entity_name, attestation_scope, and the CA-03 routing_table_entry_id that references it", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-07-E4", "description": "service_dependency_map for each AI system listing all integrated third-party APIs, model providers, and data services cross-referenced against the obligation register to confirm no vendor is absent from the register", "evidence_type": "third-party-audit-report", "verification": "third-party" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "DORA-ART10-01", "section": "Art. 10(1)", "title": "Anomaly Detection and Continuous ICT Monitoring", "text": "Financial entities shall implement mechanisms to promptly detect anomalous activities in ICT systems, including AI systems, to identify potential ICT-related threats and vulnerabilities at an early stage.", "verdict": "supported", "coverage": "direct", "notes": "RT-04 detects anomalies and triggers pause, kill switch, or containment for AI agents; RT-01 captures OS-level telemetry of actual agent behavior; IM-02 monitors for anomalous credential use specific to AI identity; RT-08 monitors latent and representation-level signals beyond visible outputs. These controls directly implement the DORA anomaly detection mandate at the AI system and agent level.", "control_count": 4, "proof_chain": [ { "control": "apeiris://security/controls/RT-04", "id": "RT-04", "domain": "security", "name": "Detect anomalies and trigger pause, kill switch, or containment", "validation_objective": "The system must provide graduated, agent-external response mechanisms \u2014 a graceful pause for human review, a hard kill on provenance failure, and endpoint isolation on lateral movement \u2014 each enforced outside the agent's execution context and capable of revoking delegated tokens and terminating tool-side jobs. All three response tiers must activate within defined time-to-contain bounds validated in timed drills.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "kill_switch_drill_record showing trigger_condition, response_tier_activated (R1/R2/R3), time_to_contain, confirmation that delegated tokens were revoked, and tool-side jobs terminated", "graceful_pause_drill_record confirming pause-for-review is distinct from hard kill and was activated successfully without requiring agent cooperation", "anomaly_trigger_definition_document listing the specific conditions (provenance failure, unverifiable action, lateral movement indicator) that activate each response tier", "containment_event_log from any real events showing trigger, response tier, time-to-contain, and post-incident review outcome" ], "evidence": [ { "id": "RT-04-E1", "description": "kill_switch_drill_record showing trigger_condition, response_tier_activated (R1/R2/R3), time_to_contain, confirmation that delegated tokens were revoked, and tool-side jobs terminated", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-04-E2", "description": "graceful_pause_drill_record confirming pause-for-review is distinct from hard kill and was activated successfully without requiring agent cooperation", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RT-04-E3", "description": "anomaly_trigger_definition_document listing the specific conditions (provenance failure, unverifiable action, lateral movement indicator) that activate each response tier", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "RT-04-E4", "description": "containment_event_log from any real events showing trigger, response tier, time-to-contain, and post-incident review outcome", "evidence_type": "incident-record", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://security/controls/RT-01", "id": "RT-01", "domain": "security", "name": "Capture OS-level telemetry of what the agent actually does", "validation_objective": "The system must capture full OS-level telemetry \u2014 process tree, file I/O, and network calls \u2014 for every agent execution, with each event stamped with the agent's verified identity and correlated to a run_id and tool_call_id. All agent activity on instrumented hosts must be attributable to a specific agent identity with no observability gaps at the OS layer.", "blocking_effect": "advisory", "evidence_required": [ "edr_process_lineage_records for each agent run showing agent_id, run_id, parent_process, child_processes, file_ops, and net_calls", "telemetry_coverage_report confirming EDR instrumentation is active on all hosts where agents execute, with deployment-mode-specific coverage documented for container, VM, and serverless modes", "agent_identity_correlation_log confirming OS-level events are stamped with agent_id and mapped to run_id and goal_id so low-level events resolve to agent intent", "unsanctioned_process_alert_log showing EDR flagged an off-manifest child process or binary during a validation test with the triggering run_id recorded" ], "evidence": [ { "id": "RT-01-E1", "description": "edr_process_lineage_records for each agent run showing agent_id, run_id, parent_process, child_processes, file_ops, and net_calls", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-01-E2", "description": "telemetry_coverage_report confirming EDR instrumentation is active on all hosts where agents execute, with deployment-mode-specific coverage documented for container, VM, and serverless modes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-01-E3", "description": "agent_identity_correlation_log confirming OS-level events are stamped with agent_id and mapped to run_id and goal_id so low-level events resolve to agent intent", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-01-E4", "description": "unsanctioned_process_alert_log showing EDR flagged an off-manifest child process or binary during a validation test with the triggering run_id recorded", "evidence_type": "automated-test-result", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://identity/controls/IM-02", "id": "IM-02", "domain": "identity", "name": "Anomalous Credential Use Detection", "validation_objective": "The anomaly detection pipeline must compute per-credential z-scores in near-real-time (within 60 seconds of event emission) across all baseline dimensions, generate alerts at the correct severity thresholds (>3sigma advisory, >5sigma enforcement), and the scope accumulation sub-check must execute at least daily and on every PA-01 org hierarchy change event, producing findings for any agent whose effective scope exceeds the recomputed PA-01 authorization floor.", "blocking_effect": "advisory", "evidence_required": [ "anomaly_alert_log sample of 10 events each containing credential_id, timestamp, z_score, dimension_flagged, baseline_value, and alert_severity", "scope_accumulation_report from the most recent sub-check execution listing credentials evaluated, accumulation_findings_count, and remediation_status for each finding", "pa01_trigger_log showing PA-01 org change events paired with corresponding IM-02 scope floor recalculation executions and their completion timestamps", "detection_latency_measurement report confirming mean latency from telemetry event emission to alert generation is under 60 seconds over a 7-day sample period" ], "evidence": [ { "id": "IM-02-E1", "description": "anomaly_alert_log sample of 10 events each containing credential_id, timestamp, z_score, dimension_flagged, baseline_value, and alert_severity", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "IM-02-E2", "description": "scope_accumulation_report from the most recent sub-check execution listing credentials evaluated, accumulation_findings_count, and remediation_status for each finding", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "IM-02-E3", "description": "pa01_trigger_log showing PA-01 org change events paired with corresponding IM-02 scope floor recalculation executions and their completion timestamps", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "IM-02-E4", "description": "detection_latency_measurement report confirming mean latency from telemetry event emission to alert generation is under 60 seconds over a 7-day sample period", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://security/controls/RT-08", "id": "RT-08", "domain": "security", "name": "Monitor latent and representation-level signals, not just visible reasoning", "validation_objective": "Oversight of agent behavior must extend below the visible chain-of-thought: representation-level or logit-level monitoring must be active where model internals are accessible, and a divergence between visible reasoning and internal-state indicators must trigger an alert. Probe coverage must remain above the minimum threshold required to trust visible-reasoning monitoring (RT-03).", "blocking_effect": "advisory", "evidence_required": [ "activation_probe_deployment_record listing probe types, coverage percentage, model layers monitored, and the minimum threshold below which visible-reasoning monitoring is no longer trusted", "logit_anomaly_detection_log showing agent_id, timestamp, anomaly_score, and alert disposition for each monitored inference where an anomaly was flagged", "oversight_awareness_test_report documenting red-team scenarios where visible output was manipulated to appease the monitor and recording whether internal-state signals caught the deception", "probe_coverage_report confirming recall and coverage are above the defined minimum threshold at the time of each attestation period" ], "evidence": [ { "id": "RT-08-E1", "description": "activation_probe_deployment_record listing probe types, coverage percentage, model layers monitored, and the minimum threshold below which visible-reasoning monitoring is no longer trusted", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "RT-08-E2", "description": "logit_anomaly_detection_log showing agent_id, timestamp, anomaly_score, and alert disposition for each monitored inference where an anomaly was flagged", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "RT-08-E3", "description": "oversight_awareness_test_report documenting red-team scenarios where visible output was manipulated to appease the monitor and recording whether internal-state signals caught the deception", "evidence_type": "red-team-report", "verification": "third-party" }, { "id": "RT-08-E4", "description": "probe_coverage_report confirming recall and coverage are above the defined minimum threshold at the time of each attestation period", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "DORA-ART10-02", "section": "Art. 10(2)", "title": "Comprehensive ICT Event Logging and Audit Trails", "text": "Financial entities shall put in place mechanisms to enable monitoring and logging of all ICT-related activities and events, including activities performed by AI systems, and shall ensure that logs are complete, reliable, and tamper-resistant.", "verdict": "supported", "coverage": "direct", "notes": "RT-01 captures OS-level telemetry of agent actions; GV-02 requires an immutable, tamper-evident audit trail; IM-06 mandates identity event log integrity; RO-06 maintains the recovery operations audit trail. Together these controls satisfy DORA's comprehensive logging and audit trail requirement as applied to AI system events.", "control_count": 4, "proof_chain": [ { "control": "apeiris://security/controls/RT-01", "id": "RT-01", "domain": "security", "name": "Capture OS-level telemetry of what the agent actually does", "validation_objective": "The system must capture full OS-level telemetry \u2014 process tree, file I/O, and network calls \u2014 for every agent execution, with each event stamped with the agent's verified identity and correlated to a run_id and tool_call_id. All agent activity on instrumented hosts must be attributable to a specific agent identity with no observability gaps at the OS layer.", "blocking_effect": "advisory", "evidence_required": [ "edr_process_lineage_records for each agent run showing agent_id, run_id, parent_process, child_processes, file_ops, and net_calls", "telemetry_coverage_report confirming EDR instrumentation is active on all hosts where agents execute, with deployment-mode-specific coverage documented for container, VM, and serverless modes", "agent_identity_correlation_log confirming OS-level events are stamped with agent_id and mapped to run_id and goal_id so low-level events resolve to agent intent", "unsanctioned_process_alert_log showing EDR flagged an off-manifest child process or binary during a validation test with the triggering run_id recorded" ], "evidence": [ { "id": "RT-01-E1", "description": "edr_process_lineage_records for each agent run showing agent_id, run_id, parent_process, child_processes, file_ops, and net_calls", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-01-E2", "description": "telemetry_coverage_report confirming EDR instrumentation is active on all hosts where agents execute, with deployment-mode-specific coverage documented for container, VM, and serverless modes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-01-E3", "description": "agent_identity_correlation_log confirming OS-level events are stamped with agent_id and mapped to run_id and goal_id so low-level events resolve to agent intent", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-01-E4", "description": "unsanctioned_process_alert_log showing EDR flagged an off-manifest child process or binary during a validation test with the triggering run_id recorded", "evidence_type": "automated-test-result", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://security/controls/GV-02", "id": "GV-02", "domain": "security", "name": "Keep an immutable, tamper-evident audit trail of what the agent did", "validation_objective": "Every agent action, state mutation, tool invocation, and decision must be recorded in an append-only, tamper-evident store with cryptographic integrity guarantees (hash-chaining or Merkle anchoring held outside the agent platform's trust boundary); any attempt to modify or delete an audit entry must be rejected by the store and remain detectable via inclusion proof.", "blocking_effect": "advisory", "evidence_required": [ "merkle_anchor_record with root_hash, anchoring_timestamp, and external anchor reference for each audit batch, proving the chain was not retroactively modified", "inclusion_proof_sample showing cryptographic proof that a representative set of action entries exist in the verified tree without gaps", "audit_store_isolation_record confirming the audit store is outside the agent platform's trust boundary and no agent process holds delete or modify privileges on the store", "retention_policy_record confirming audit entries are retained for the required regulatory horizon and are not subject to automated deletion by routine data lifecycle processes", "chain_of_custody_record for each multi-agent or human-agent handoff, capturing actor_identity, action, and timestamp for every hop" ], "evidence": [ { "id": "GV-02-E1", "description": "merkle_anchor_record with root_hash, anchoring_timestamp, and external anchor reference for each audit batch, proving the chain was not retroactively modified", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-02-E2", "description": "inclusion_proof_sample showing cryptographic proof that a representative set of action entries exist in the verified tree without gaps", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-02-E3", "description": "audit_store_isolation_record confirming the audit store is outside the agent platform's trust boundary and no agent process holds delete or modify privileges on the store", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-02-E4", "description": "retention_policy_record confirming audit entries are retained for the required regulatory horizon and are not subject to automated deletion by routine data lifecycle processes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "GV-02-E5", "description": "chain_of_custody_record for each multi-agent or human-agent handoff, capturing actor_identity, action, and timestamp for every hop", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://identity/controls/IM-06", "id": "IM-06", "domain": "identity", "name": "Identity Event Log Integrity", "validation_objective": "Identity event logs must be written to a SIEM destination where agent credentials have no write, delete, or update permissions; log entries must be hash-chained so that any deletion or modification is detectable within 6 hours; and a log-gap alert must fire within 5 minutes when an active agent stops forwarding events, with delegation chain references present in every event involving a delegated credential.", "blocking_effect": "advisory", "evidence_required": [ "iam_policy_review confirming that no active agent IAM role or service account has s3:PutObject, s3:DeleteObject, cloudwatch:PutLogEvents, or equivalent write/delete permissions on the SIEM log destination", "chain_integrity_check_log from the most recent 24-hour verification run showing all hash chains intact and zero tamper events detected", "log_gap_alert_test_record from the most recent operational test showing a gap alert generated within 5 minutes of log forwarder suspension for an active agent", "log_entry_schema_sample of 10 identity events confirming each contains delegation_chain_id, actor_credential_id, action_type, resource_target, outcome, and event_hash fields" ], "evidence": [ { "id": "IM-06-E1", "description": "iam_policy_review confirming that no active agent IAM role or service account has s3:PutObject, s3:DeleteObject, cloudwatch:PutLogEvents, or equivalent write/delete permissions on the SIEM log destination", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "IM-06-E2", "description": "chain_integrity_check_log from the most recent 24-hour verification run showing all hash chains intact and zero tamper events detected", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "IM-06-E3", "description": "log_gap_alert_test_record from the most recent operational test showing a gap alert generated within 5 minutes of log forwarder suspension for an active agent", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "IM-06-E4", "description": "log_entry_schema_sample of 10 identity events confirming each contains delegation_chain_id, actor_credential_id, action_type, resource_target, outcome, and event_hash fields", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://resilience/controls/RO-06", "id": "RO-06", "domain": "resilience", "name": "Recovery Operations Audit Trail", "validation_objective": "The recovery operations audit log must contain a structured entry for every action taken during recovery, with all required fields populated (actor identity, action type, target system, outcome, ISO 8601 timestamp), stored in a write-once tamper-evident store with an intact cryptographic hash chain. No recovery event may close without a passing log completeness check that cross-references all source system changelogs against the audit log.", "blocking_effect": "advisory", "evidence_required": [ "recovery_audit_log with structured entries for every recovery action containing actor_identity, action_type, target_system, outcome, and ISO 8601 millisecond-precision timestamp", "cryptographic_chain_verification_report confirming hash chain integrity across all log segments sampled from the audit period with zero chain_invalid results", "log_completeness_check_results cross-referencing system changelogs against audit entries and confirming zero unmatched action gaps at incident close", "write_once_storage_configuration_record confirming audit log resides in a separate storage account with no delete or write access for operational accounts", "retention_compliance_certificate confirming log retention meets the longer of seven years or the applicable regulatory period for all jurisdictions in scope" ], "evidence": [ { "id": "RO-06-E1", "description": "recovery_audit_log with structured entries for every recovery action containing actor_identity, action_type, target_system, outcome, and ISO 8601 millisecond-precision timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RO-06-E2", "description": "cryptographic_chain_verification_report confirming hash chain integrity across all log segments sampled from the audit period with zero chain_invalid results", "evidence_type": "audit-log", "verification": "automated" }, { "id": "RO-06-E3", "description": "log_completeness_check_results cross-referencing system changelogs against audit entries and confirming zero unmatched action gaps at incident close", "evidence_type": "incident-record", "verification": "attested" }, { "id": "RO-06-E4", "description": "write_once_storage_configuration_record confirming audit log resides in a separate storage account with no delete or write access for operational accounts", "evidence_type": "audit-log", "verification": "automated" }, { "id": "RO-06-E5", "description": "retention_compliance_certificate confirming log retention meets the longer of seven years or the applicable regulatory period for all jurisdictions in scope", "evidence_type": "audit-log", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "Logging obligations under DORA sit in the ICT risk-management technical standards: Commission Delegated Regulation (EU) 2024/1774 Article 12 requires financial entities to log relevant ICT events and protect those logs against tampering. Tamper-evident recovery audit trails implement that requirement for AI recovery actions (DORA Article 9 itself addresses protection and prevention, not logging)." } ] }, { "requirement_id": "DORA-ART11-01", "section": "Art. 11(1)", "title": "ICT-Related Incident Response Policies and Procedures", "text": "Financial entities shall have in place a comprehensive ICT-related incident management process to detect, manage, and notify ICT-related incidents and shall put in place and implement response and recovery plans.", "verdict": "supported", "coverage": "direct", "notes": "RG-06 integrates resilience incident response into the AI operations program; CG-06 covers compliance incident response protocols; FG-05 addresses finance AI incident response integration for financial entities specifically; OB-05 tracks DORA ICT obligations including incident management requirements. These controls directly operationalize the DORA incident management mandate for AI systems.", "control_count": 4, "proof_chain": [ { "control": "apeiris://resilience/controls/RG-06", "id": "RG-06", "domain": "resilience", "name": "Resilience Incident Response Integration", "validation_objective": "All production AI system incidents must be classified against the published AI resilience severity taxonomy, RTO/RPO breach events must trigger the documented governance escalation path within the required timeframe, and all Severity 1 incidents must have a completed post-incident resilience review within 30 days of resolution that includes governance findings.", "blocking_effect": "requires-review", "evidence_required": [ "Published AI resilience incident severity taxonomy with explicit mapping of RTO/RPO breach scenarios to severity levels, documented escalation timeframes per severity, and recovery decision authority matrix", "Incident management system records for all AI system incidents in the review period showing severity classification field populated using the AI resilience taxonomy", "Governance escalation records for all Severity 1 and Severity 2 AI resilience incidents, including timestamp of executive notification and Resilience Steering Committee notification against the required timeframe", "Post-incident resilience review reports for all Severity 1 incidents, confirming completion within 30 days of resolution and inclusion of governance control failure assessment", "Board-level resilience reporting artifacts showing RTO/RPO breach incidents are reflected in governance reporting with correct severity and timeline" ], "evidence": [ { "id": "RG-06-E1", "description": "Published AI resilience incident severity taxonomy with explicit mapping of RTO/RPO breach scenarios to severity levels, documented escalation timeframes per severity, and recovery decision authority matrix", "evidence_type": "incident-record", "verification": "attested" }, { "id": "RG-06-E2", "description": "Incident management system records for all AI system incidents in the review period showing severity classification field populated using the AI resilience taxonomy", "evidence_type": "incident-record", "verification": "attested" }, { "id": "RG-06-E3", "description": "Governance escalation records for all Severity 1 and Severity 2 AI resilience incidents, including timestamp of executive notification and Resilience Steering Committee notification against the required timeframe", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RG-06-E4", "description": "Post-incident resilience review reports for all Severity 1 incidents, confirming completion within 30 days of resolution and inclusion of governance control failure assessment", "evidence_type": "incident-record", "verification": "attested" }, { "id": "RG-06-E5", "description": "Board-level resilience reporting artifacts showing RTO/RPO breach incidents are reflected in governance reporting with correct severity and timeline", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "DORA Articles 17-23 establish comprehensive requirements for ICT-related incident management, classification, reporting, and post-incident review. For covered entities, integrating AI resilience incidents into the enterprise incident management process that meets DORA standards is a legal obligation." }, { "control": "apeiris://compliance/controls/CG-06", "id": "CG-06", "domain": "compliance", "name": "Compliance Incident Response", "validation_objective": "A documented Compliance Incident Response Playbook exists covering at least four AI-specific incident scenario types (discriminatory AI output, unauthorized AI data processing, regulatory inquiry, enforcement action), defines severity levels P1-P4 with named role assignments and notification timelines specific to each applicable regulatory framework (GDPR 72h, EU AI Act Article 73), and has been exercised in a tabletop simulation of an AI compliance scenario within the last 18 months with documented lessons-learned outcomes.", "blocking_effect": "requires-review", "evidence_required": [ "compliance_incident_response_playbook document containing ai_incident_scenario_list (minimum four types), severity_level_definitions (P1-P4) with escalation_paths, regulatory_notification_timeline_matrix per framework with specific SLAs, named_role_assignments for Incident Commander/Legal Lead/Technical Lead, and containment_action_steps", "tabletop_exercise_record dated within the last 18 months documenting scenario_type (must be AI compliance scenario), participants by named role, findings, and lessons_learned items with remediation_action_owner and completion_status", "notification_template_set for each applicable regulatory authority with legal_counsel_review_date within the last 12 months confirming language is current and jurisdiction-appropriate", "incident_response_log for any compliance incidents in the last 24 months showing incident_id, severity_level, trigger_timestamp, notification_sent_timestamp, regulatory_authority_notified, and SLA_compliance status for each framework-governed notification" ], "evidence": [ { "id": "CG-06-E1", "description": "compliance_incident_response_playbook document containing ai_incident_scenario_list (minimum four types), severity_level_definitions (P1-P4) with escalation_paths, regulatory_notification_timeline_matrix per framework with specific SLAs, named_role_assignments for Incident Commander/Legal Lead/Technical Lead, and containment_action_steps", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CG-06-E2", "description": "tabletop_exercise_record dated within the last 18 months documenting scenario_type (must be AI compliance scenario), participants by named role, findings, and lessons_learned items with remediation_action_owner and completion_status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-06-E3", "description": "notification_template_set for each applicable regulatory authority with legal_counsel_review_date within the last 12 months confirming language is current and jurisdiction-appropriate", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-06-E4", "description": "incident_response_log for any compliance incidents in the last 24 months showing incident_id, severity_level, trigger_timestamp, notification_sent_timestamp, regulatory_authority_notified, and SLA_compliance status for each framework-governed notification", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://finance/controls/FG-05", "id": "FG-05", "domain": "finance", "name": "Finance AI Incident Response Integration", "validation_objective": "All AI-related financial incidents are classified using defined three-tier criteria within four business hours of detection, regulatory notification requirements are assessed and notifications are delivered within applicable deadlines for all high-severity incidents, and post-incident review reports are completed within 30 days. The enterprise ticketing system must demonstrate automatic routing of AI financial incidents to Model Risk and Compliance queues upon high- or medium-severity classification.", "blocking_effect": "requires-review", "evidence_required": [ "ai_incident_log with incident_id, classification_tier, classification_timestamp, model_risk_routing_confirmed flag, and regulatory_notification_assessment_timestamp for each AI-related financial incident", "regulatory_notification_record with incident_id, applicable_regulator, notification_deadline, notification_delivery_timestamp, and notification_content_reference for each high-severity incident requiring regulatory notification", "post_incident_review_report with incident_id, root_cause_classification (model/data/infrastructure), validation_gap_identified flag, remediation_plan with named_owner and deadline, and report_completion_date for each high-severity incident", "incident_response_team_activation_log with incident_id, team_member_identifiers, role_assignments, and escalation_ladder_compliance flag for high-severity incidents" ], "evidence": [ { "id": "FG-05-E1", "description": "ai_incident_log with incident_id, classification_tier, classification_timestamp, model_risk_routing_confirmed flag, and regulatory_notification_assessment_timestamp for each AI-related financial incident", "evidence_type": "incident-record", "verification": "attested" }, { "id": "FG-05-E2", "description": "regulatory_notification_record with incident_id, applicable_regulator, notification_deadline, notification_delivery_timestamp, and notification_content_reference for each high-severity incident requiring regulatory notification", "evidence_type": "incident-record", "verification": "attested" }, { "id": "FG-05-E3", "description": "post_incident_review_report with incident_id, root_cause_classification (model/data/infrastructure), validation_gap_identified flag, remediation_plan with named_owner and deadline, and report_completion_date for each high-severity incident", "evidence_type": "incident-record", "verification": "attested" }, { "id": "FG-05-E4", "description": "incident_response_team_activation_log with incident_id, team_member_identifiers, role_assignments, and escalation_ladder_compliance flag for high-severity incidents", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://compliance/controls/OB-05", "id": "OB-05", "domain": "compliance", "name": "DORA ICT Obligation Tracking", "validation_objective": "Financial entities subject to DORA must have a structured obligation tracking record for all ICT-related obligations across DORA's five pillars, with alert thresholds calibrated to DORA's statutory reporting windows: initial major ICT incident notification within 4 hours of classification and no later than 24 hours from awareness, with intermediate and final reports tracked to their statutory windows. Evidence of on-time alert dispatch for any ICT incident classified as major must be present in the obligation tracking system.", "blocking_effect": "advisory", "evidence_required": [ "dora_obligation_register record per financial entity showing all five pillar obligation inventories (ICT risk management, incident reporting, resilience testing, third-party risk, information sharing) with owner assignments and fulfillment status", "ict_incident_classification_log showing each incident's classification event timestamp, major_incident boolean, and the triggered notification workflow initiation timestamp confirming the 4-hour window was met", "dora_incident_notification_record showing initial notification dispatched to the competent authority within 4 hours of classification and no later than 24 hours from awareness, with dispatch timestamp and submission confirmation", "resilience_testing_schedule showing DORA-compliant testing plan (including TLPT where applicable) with completion dates and test results reports" ], "evidence": [ { "id": "OB-05-E1", "description": "dora_obligation_register record per financial entity showing all five pillar obligation inventories (ICT risk management, incident reporting, resilience testing, third-party risk, information sharing) with owner assignments and fulfillment status", "evidence_type": "third-party-audit-report", "verification": "third-party" }, { "id": "OB-05-E2", "description": "ict_incident_classification_log showing each incident's classification event timestamp, major_incident boolean, and the triggered notification workflow initiation timestamp confirming the 4-hour window was met", "evidence_type": "incident-record", "verification": "attested" }, { "id": "OB-05-E3", "description": "dora_incident_notification_record showing initial notification dispatched to the competent authority within 4 hours of classification and no later than 24 hours from awareness, with dispatch timestamp and submission confirmation", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OB-05-E4", "description": "resilience_testing_schedule showing DORA-compliant testing plan (including TLPT where applicable) with completion dates and test results reports", "evidence_type": "automated-test-result", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "DORA-ART11-02", "section": "Art. 11(5)", "title": "Recovery and Resumption of Activities After ICT Disruption", "text": "Financial entities shall implement recovery plans for ICT-related disruptions and ensure that activities disrupted by an ICT incident, including AI system failures, can be restored within agreed recovery timeframes.", "verdict": "supported", "coverage": "direct", "notes": "RO-01 defines AI system failover execution procedures; RO-05 mandates pre-restoration validation before traffic resumption; RO-07 verifies recovery time compliance against stated objectives; RP-01 provides the AI-specific business continuity plan. These controls directly implement DORA's recovery and resumption mandate as applied to AI system disruptions in financial entities.", "control_count": 4, "proof_chain": [ { "control": "apeiris://resilience/controls/RO-01", "id": "RO-01", "domain": "resilience", "name": "AI System Failover Execution Procedures", "validation_objective": "Every tier-1 AI system component has a version-controlled failover runbook linked to its incident management alert definition, tested within the last six months through a tabletop walkthrough or live drill, and all runbook-specified credentials and access paths are confirmed accessible from the break-glass vault at the start of each on-call rotation.", "blocking_effect": "blocks-deployment", "evidence_required": [ "runbook_registry listing all tier-1 AI system components with their runbook document ID, last-modified date, and the alert definition ID to which each runbook is linked in the incident management platform", "runbook_test_record per component showing test date, test type (tabletop or live drill), participants, documented outcomes, and identified gaps with remediation status", "credential_validation_log from the break-glass vault showing all runbook-specified accounts were verified accessible at the start of each on-call rotation within the last 30 days", "runbook_change_review_record confirming pull-request approval with sign-off from both the owning engineering team and Business Continuity Manager for any runbook changes in the past 12 months" ], "evidence": [ { "id": "RO-01-E1", "description": "runbook_registry listing all tier-1 AI system components with their runbook document ID, last-modified date, and the alert definition ID to which each runbook is linked in the incident management platform", "evidence_type": "incident-record", "verification": "attested" }, { "id": "RO-01-E2", "description": "runbook_test_record per component showing test date, test type (tabletop or live drill), participants, documented outcomes, and identified gaps with remediation status", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "RO-01-E3", "description": "credential_validation_log from the break-glass vault showing all runbook-specified accounts were verified accessible at the start of each on-call rotation within the last 30 days", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RO-01-E4", "description": "runbook_change_review_record confirming pull-request approval with sign-off from both the owning engineering team and Business Continuity Manager for any runbook changes in the past 12 months", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU DORA Article 12(1) requires financial entities to have documented response and recovery plans for ICT incidents. For AI systems operating in financial services, failover execution procedures are a compliance obligation, not merely a best practice. DORA mandates these procedures be regularly tested and updated." }, { "control": "apeiris://resilience/controls/RO-05", "id": "RO-05", "domain": "resilience", "name": "Pre-Restoration Validation Before Traffic Resumption", "validation_objective": "Before production traffic is restored to any AI system following a recovery operation, a gate orchestrator must execute and record pass results for all five gate categories \u2014 infrastructure health, model behavioral correctness, data integrity, security posture, and compliance status \u2014 with each gate's pass timestamp preceding the traffic restoration timestamp; any bypass must carry dual-authorization documentation and be followed by full gate completion within two hours.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "gate_orchestrator_pass_log per recovery event showing gate category, test executed, pass/fail result, and timestamp for each of the five categories, with all gates showing pass before the traffic restoration timestamp", "behavioral_regression_test_report from the model behavioral correctness gate showing results against the golden reference dataset with quantitative deviation metric below the defined threshold and latency measurements within SLA", "security_posture_check_record confirming: configuration integrity comparison against last known-good baseline, credential rotation verification for credentials in scope of the incident, and vulnerability scan completion for high-severity incidents", "bypass_authorization_record (if bypass was used) showing dual-authorization approver identities and timestamps, and post-bypass validation completion confirmation within two hours of traffic restoration" ], "evidence": [ { "id": "RO-05-E1", "description": "gate_orchestrator_pass_log per recovery event showing gate category, test executed, pass/fail result, and timestamp for each of the five categories, with all gates showing pass before the traffic restoration timestamp", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "RO-05-E2", "description": "behavioral_regression_test_report from the model behavioral correctness gate showing results against the golden reference dataset with quantitative deviation metric below the defined threshold and latency measurements within SLA", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RO-05-E3", "description": "security_posture_check_record confirming: configuration integrity comparison against last known-good baseline, credential rotation verification for credentials in scope of the incident, and vulnerability scan completion for high-severity incidents", "evidence_type": "incident-record", "verification": "attested" }, { "id": "RO-05-E4", "description": "bypass_authorization_record (if bypass was used) showing dual-authorization approver identities and timestamps, and post-bypass validation completion confirmation within two hours of traffic restoration", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU DORA Article 12(2) requires backup systems and restoration procedures whose activation does not jeopardise the security of network and information systems or the availability, authenticity, integrity or confidentiality of data. Pre-restoration validation gates are how an AI operator demonstrates a restored system is safe before production traffic resumes." }, { "control": "apeiris://resilience/controls/RO-07", "id": "RO-07", "domain": "resilience", "name": "Recovery Time Compliance Verification", "validation_objective": "For every AI system recovery event, actual RTO and RPO values must be automatically calculated from structured audit trail timestamps and compared against the documented targets in the recovery target register, with a compliance report generated at incident close and any breach routed to the business continuity manager and owning engineering team within five business days for corrective action.", "blocking_effect": "advisory", "evidence_required": [ "recovery_target_register mapping each AI system component to business-owner-approved RTO and RPO values validated against contractual SLA commitments", "rto_rpo_compliance_report with actual_rto, target_rto, actual_rpo, target_rpo, and compliance_status fields per affected component generated automatically from audit trail data for each recovery event", "breach_remediation_records showing corrective action acknowledgment, root cause documentation, and completion status for all documented RTO or RPO breaches within 30 days", "rolling_compliance_dashboard export showing 90-day RTO and RPO compliance rates by system component used in quarterly management reviews" ], "evidence": [ { "id": "RO-07-E1", "description": "recovery_target_register mapping each AI system component to business-owner-approved RTO and RPO values validated against contractual SLA commitments", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RO-07-E2", "description": "rto_rpo_compliance_report with actual_rto, target_rto, actual_rpo, target_rpo, and compliance_status fields per affected component generated automatically from audit trail data for each recovery event", "evidence_type": "audit-log", "verification": "automated" }, { "id": "RO-07-E3", "description": "breach_remediation_records showing corrective action acknowledgment, root cause documentation, and completion status for all documented RTO or RPO breaches within 30 days", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RO-07-E4", "description": "rolling_compliance_dashboard export showing 90-day RTO and RPO compliance rates by system component used in quarterly management reviews", "evidence_type": "configuration-snapshot", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU DORA Article 12(2) requires backup systems and restoration and recovery procedures and methods that are tested periodically. Verifying that actual recovery performance met documented RTO/RPO commitments after each activation supplies the evidence that this testing obligation is met in substance." }, { "control": "apeiris://resilience/controls/RP-01", "id": "RP-01", "domain": "resilience", "name": "AI-Specific Business Continuity Plan", "validation_objective": "Every production AI system must be explicitly named in a formally documented AI BCP annex with at least one named system owner, a defined set of AI-specific failure scenarios (including model service unavailability, training data corruption, and inference pipeline disruption), AI-specific RTO and RPO targets validated against business impact analysis findings, and an annual review record with executive sponsor sign-off.", "blocking_effect": "requires-review", "evidence_required": [ "AI BCP annex document listing all production AI systems with criticality tier, named system owner, and at least three AI-specific failure scenarios with mapped response procedures per system", "Business impact analysis output showing quantified downtime cost and tolerable outage period per AI system, serving as the basis for RTO/RPO target selection", "RTO/RPO target validation record per AI system showing alignment with BIA findings and confirmation that technical recovery capability has been measured against the target", "Annual review record with executive sponsor signature, review date, and a description of changes made since the prior review", "Named BCP stakeholder roster showing AI system owner assignments with role, contact information, and escalation authority" ], "evidence": [ { "id": "RP-01-E1", "description": "AI BCP annex document listing all production AI systems with criticality tier, named system owner, and at least three AI-specific failure scenarios with mapped response procedures per system", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RP-01-E2", "description": "Business impact analysis output showing quantified downtime cost and tolerable outage period per AI system, serving as the basis for RTO/RPO target selection", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RP-01-E3", "description": "RTO/RPO target validation record per AI system showing alignment with BIA findings and confirmation that technical recovery capability has been measured against the target", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RP-01-E4", "description": "Annual review record with executive sponsor signature, review date, and a description of changes made since the prior review", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RP-01-E5", "description": "Named BCP stakeholder roster showing AI system owner assignments with role, contact information, and escalation authority", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU DORA Article 11 requires financial entities to establish, maintain, and test ICT business continuity policies and plans. AI systems used in financial decision-making are explicitly within DORA scope and require dedicated AI-specific continuity planning documentation." } ] }, { "requirement_id": "DORA-ART12-01", "section": "Art. 12(1)", "title": "Backup Policies and AI Data Recovery Systems", "text": "Financial entities shall put in place backup policies and procedures as well as restoration and recovery procedures and methods, covering data, applications, and all functions and their supporting resources, including AI systems, models, and associated datasets.", "verdict": "supported", "coverage": "direct", "notes": "RE-03 governs data redundancy and backup for AI systems; RP-04 provides the RAG index and knowledge base recovery plan; RP-03 covers model rollback and previous version recovery planning; RP-02 is the AI system disaster recovery plan. These controls directly fulfill DORA's backup and recovery policy mandate covering the full AI system stack including models, data, and indices.", "control_count": 4, "proof_chain": [ { "control": "apeiris://resilience/controls/RE-03", "id": "RE-03", "domain": "resilience", "name": "Data Redundancy and Backup Governance", "validation_objective": "All AI system data assets including training datasets, model weights, inference logs, vector indexes, and operational state must be covered by a documented backup policy with defined RPO and RTO, and restore procedures must be verified through scheduled restore tests producing recorded outcomes that confirm data integrity and recovery time within policy.", "blocking_effect": "blocks-deployment", "evidence_required": [ "backup_policy_document enumerating each AI data asset class with assigned backup_frequency, retention_period, storage_tier, rpo_hours, and rto_hours", "backup_configuration_audit_record confirming immutable storage is enabled for AI artifacts, replication_factor meets the policy minimum, and retention rules are enforced on the storage backend", "restore_test_record from the most recent scheduled test for each asset class with fields asset_class, backup_timestamp, restore_start_time, restore_completion_time, integrity_check_method, and integrity_check_result", "backup_monitoring_alert_log confirming backup job failures and RPO breach alerts are routed to on-call within alert_response_sla_minutes", "data_asset_inventory listing all AI data assets in scope for backup governance with coverage_status and last_backup_verified_at for each" ], "evidence": [ { "id": "RE-03-E1", "description": "backup_policy_document enumerating each AI data asset class with assigned backup_frequency, retention_period, storage_tier, rpo_hours, and rto_hours", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RE-03-E2", "description": "backup_configuration_audit_record confirming immutable storage is enabled for AI artifacts, replication_factor meets the policy minimum, and retention rules are enforced on the storage backend", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RE-03-E3", "description": "restore_test_record from the most recent scheduled test for each asset class with fields asset_class, backup_timestamp, restore_start_time, restore_completion_time, integrity_check_method, and integrity_check_result", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "RE-03-E4", "description": "backup_monitoring_alert_log confirming backup job failures and RPO breach alerts are routed to on-call within alert_response_sla_minutes", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "RE-03-E5", "description": "data_asset_inventory listing all AI data assets in scope for backup governance with coverage_status and last_backup_verified_at for each", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU DORA Article 12 requires financial entities to maintain backup policies with defined backup frequency, testing schedules, and demonstrated recovery capability. AI systems supporting financial services must include their data assets in DORA-compliant backup governance programs. Restore test records are required audit artifacts under DORA supervisory examination." }, { "control": "apeiris://resilience/controls/RP-04", "id": "RP-04", "domain": "resilience", "name": "RAG Index and Knowledge Base Recovery Plan", "validation_objective": "Every production RAG system must have a documented knowledge base recovery plan specifying vector database backup schedules aligned to the system's RPO, step-by-step index rebuild procedures with measured time estimates, freshness validation queries that confirm restored content is semantically current and not corrupted, and RTO/RPO targets that explicitly account for index rebuild duration, validated in at least one recovery drill within the past 12 months.", "blocking_effect": "requires-review", "evidence_required": [ "RAG knowledge base recovery plan document per production deployment specifying backup schedule, index rebuild procedure steps, freshness validation query set, RTO/RPO targets inclusive of rebuild time, and responsible roles", "Vector database backup execution logs covering the last 90 days showing each scheduled backup completed with a record of embedding count, backup size, and checksum", "Index rebuild test results from a drill within the last 12 months showing measured rebuild time against RTO target, freshness validation query results, and pass/fail determination per validation check", "Knowledge base content integrity report showing source-to-index mapping is current, no documents are indexed beyond their freshness window, and no corrupted or null embedding vectors exist", "RPO validation record confirming the gap between last successful backup and recovery point is within the documented RPO for the system" ], "evidence": [ { "id": "RP-04-E1", "description": "RAG knowledge base recovery plan document per production deployment specifying backup schedule, index rebuild procedure steps, freshness validation query set, RTO/RPO targets inclusive of rebuild time, and responsible roles", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RP-04-E2", "description": "Vector database backup execution logs covering the last 90 days showing each scheduled backup completed with a record of embedding count, backup size, and checksum", "evidence_type": "audit-log", "verification": "automated" }, { "id": "RP-04-E3", "description": "Index rebuild test results from a drill within the last 12 months showing measured rebuild time against RTO target, freshness validation query results, and pass/fail determination per validation check", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "RP-04-E4", "description": "Knowledge base content integrity report showing source-to-index mapping is current, no documents are indexed beyond their freshness window, and no corrupted or null embedding vectors exist", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RP-04-E5", "description": "RPO validation record confirming the gap between last successful backup and recovery point is within the documented RPO for the system", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://resilience/controls/RP-03", "id": "RP-03", "domain": "resilience", "name": "Model Rollback and Previous Version Recovery Planning", "validation_objective": "For every production AI model, a documented rollback plan must exist specifying at least one previously validated version registered with an integrity hash and available for immediate rollback, quantitative trigger criteria that define when rollback evaluation must begin, step-by-step rollback procedures, the authority required to approve rollback execution, and post-rollback validation criteria that confirm the prior version is performing within acceptable bounds.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Model rollback plan document per production model specifying rollback trigger thresholds (error rate, output quality degradation metric, safety failure count), approved rollback target version with integrity hash, step-by-step rollback procedure, and named rollback authority", "Model version registry showing all production models with at least one prior validated version, integrity hash per version, validation test results that qualified it for rollback use, and storage location", "Rollback drill execution record from within the last 12 months showing rehearsed execution of the rollback procedure in staging, measured rollback time, and post-rollback validation test results", "Monitoring alert configuration showing trigger thresholds that fire rollback evaluation (e.g., error rate > X%, safety refusal rate change > Y%, output quality score below Z)", "Rollback authority approval log or decision matrix showing who may approve rollback under what conditions and at what urgency level" ], "evidence": [ { "id": "RP-03-E1", "description": "Model rollback plan document per production model specifying rollback trigger thresholds (error rate, output quality degradation metric, safety failure count), approved rollback target version with integrity hash, step-by-step rollback procedure, and named rollback authority", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RP-03-E2", "description": "Model version registry showing all production models with at least one prior validated version, integrity hash per version, validation test results that qualified it for rollback use, and storage location", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "RP-03-E3", "description": "Rollback drill execution record from within the last 12 months showing rehearsed execution of the rollback procedure in staging, measured rollback time, and post-rollback validation test results", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "RP-03-E4", "description": "Monitoring alert configuration showing trigger thresholds that fire rollback evaluation (e.g., error rate > X%, safety refusal rate change > Y%, output quality score below Z)", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "RP-03-E5", "description": "Rollback authority approval log or decision matrix showing who may approve rollback under what conditions and at what urgency level", "evidence_type": "audit-log", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU DORA Article 12 requires backup policies and documented restoration and recovery procedures and methods. Versioned model registries and tested rollback plans apply that requirement to AI model artifacts as a class of ICT assets (Article 13 addresses learning and evolving, not backup)." }, { "control": "apeiris://resilience/controls/RP-02", "id": "RP-02", "domain": "resilience", "name": "AI System Disaster Recovery Plan", "validation_objective": "For every tier-1 and tier-2 AI system, a versioned AI disaster recovery plan document must exist with step-by-step recovery procedures for each AI component, explicit integrity validation gates that must pass before production traffic is restored, named recovery roles with decision authority, and RTO/RPO targets validated against measured recovery capability in at least one DR test within the past 12 months.", "blocking_effect": "requires-review", "evidence_required": [ "AI DR plan document per production AI system with version history, step-by-step component recovery procedures, and an integrity validation checklist specifying each gate and its pass criteria", "DR test execution record showing measured actual RTO against target, pass/fail status of each integrity validation gate, and a post-test summary signed by the technical lead", "Recovery role assignment matrix showing named individuals for technical lead, business sponsor, and communications owner per AI system with confirmation that each individual has participated in at least one DR drill", "Asset inventory baseline document listing model artifacts, inference endpoints, vector databases, and pipeline configurations used as the DR restore target with integrity checksums", "Post-DR test report or post-incident review within five business days of the most recent DR activation documenting deviation from plan and corrective actions" ], "evidence": [ { "id": "RP-02-E1", "description": "AI DR plan document per production AI system with version history, step-by-step component recovery procedures, and an integrity validation checklist specifying each gate and its pass criteria", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RP-02-E2", "description": "DR test execution record showing measured actual RTO against target, pass/fail status of each integrity validation gate, and a post-test summary signed by the technical lead", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "RP-02-E3", "description": "Recovery role assignment matrix showing named individuals for technical lead, business sponsor, and communications owner per AI system with confirmation that each individual has participated in at least one DR drill", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RP-02-E4", "description": "Asset inventory baseline document listing model artifacts, inference endpoints, vector databases, and pipeline configurations used as the DR restore target with integrity checksums", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RP-02-E5", "description": "Post-DR test report or post-incident review within five business days of the most recent DR activation documenting deviation from plan and corrective actions", "evidence_type": "incident-record", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU DORA Article 12 requires financial entities to maintain and test ICT disaster recovery plans covering data and system recovery capabilities. AI systems in financial services are in scope and require AI-specific DR documentation covering model artifact restoration." } ] }, { "requirement_id": "DORA-ART12-02", "section": "Art. 12(3)", "title": "Recovery Objectives and Resilience Testing for AI Systems", "text": "Financial entities shall define recovery time objectives and recovery point objectives for all ICT systems, and regularly test backup systems and recovery procedures, including for AI systems and machine learning pipelines.", "verdict": "supported", "coverage": "direct", "notes": "RV-01 defines and validates AI system RTO/RPO; RP-07 mandates recovery plan testing and tabletop exercises; RO-07 verifies recovery time compliance against stated objectives post-incident; RV-02 provides the resilience control verification testing program. These controls directly satisfy DORA's requirement for defined recovery objectives and validated testing of AI recovery capabilities.", "control_count": 4, "proof_chain": [ { "control": "apeiris://resilience/controls/RV-01", "id": "RV-01", "domain": "resilience", "name": "AI System RTO/RPO Definition and Validation", "validation_objective": "Every production AI system must have a formally documented recovery objectives register containing its RTO and RPO values, grounded in a current business impact analysis, with validation evidence from controlled recovery tests demonstrating that actual recovery capability meets or exceeds those declared objectives within the last 12 months.", "blocking_effect": "requires-review", "evidence_required": [ "recovery_objectives_register with ai_system_id, criticality_tier, rto_minutes, rpo_minutes, bia_date, and business_owner_signoff_date for every production AI system", "controlled_recovery_test_report showing scenario_description, execution_date, declared_rto_minutes, declared_rpo_minutes, actual_rto_minutes, actual_rpo_minutes, and pass_fail verdict per system", "business_impact_analysis_document dated within 12 months referencing each AI system and the business process dependencies that drove objective setting", "formal_signoff_record from business_owner and compliance_reviewer confirming objectives are aligned with regulatory obligations" ], "evidence": [ { "id": "RV-01-E1", "description": "recovery_objectives_register with ai_system_id, criticality_tier, rto_minutes, rpo_minutes, bia_date, and business_owner_signoff_date for every production AI system", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RV-01-E2", "description": "controlled_recovery_test_report showing scenario_description, execution_date, declared_rto_minutes, declared_rpo_minutes, actual_rto_minutes, actual_rpo_minutes, and pass_fail verdict per system", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RV-01-E3", "description": "business_impact_analysis_document dated within 12 months referencing each AI system and the business process dependencies that drove objective setting", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RV-01-E4", "description": "formal_signoff_record from business_owner and compliance_reviewer confirming objectives are aligned with regulatory obligations", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU DORA Article 12 imposes binding requirements on financial entities to define recovery time and recovery point objectives for ICT systems supporting critical functions, with documentation subject to supervisory review. Organizations deploying AI in financial services must treat this as a legal obligation, not a best practice." }, { "control": "apeiris://resilience/controls/RP-07", "id": "RP-07", "domain": "resilience", "name": "Recovery Plan Testing and Tabletop Exercises", "validation_objective": "All tier-1 AI systems have documented evidence of at least one tabletop exercise in the preceding 12 months, with exercise records containing AI-specific failure scenarios, multi-stakeholder participation, and a closed after-action report with critical remediation items resolved within 60 days of exercise completion.", "blocking_effect": "requires-review", "evidence_required": [ "exercise_schedule_record showing an annual calendar with at least one tabletop exercise per tier-1 AI system, signed by the Business Continuity Manager", "tabletop_exercise_record per covered system containing scenario inject cards, participant attendance list (AI system owner, recovery team, and business stakeholder), and structured facilitation notes", "after_action_report per exercise documenting identified gaps, assigned remediation owners, and deadlines not exceeding 60 days for critical findings", "plan_update_acknowledgment confirming recovery plan documentation was updated within 30 days of each exercise completion" ], "evidence": [ { "id": "RP-07-E1", "description": "exercise_schedule_record showing an annual calendar with at least one tabletop exercise per tier-1 AI system, signed by the Business Continuity Manager", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RP-07-E2", "description": "tabletop_exercise_record per covered system containing scenario inject cards, participant attendance list (AI system owner, recovery team, and business stakeholder), and structured facilitation notes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RP-07-E3", "description": "after_action_report per exercise documenting identified gaps, assigned remediation owners, and deadlines not exceeding 60 days for critical findings", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RP-07-E4", "description": "plan_update_acknowledgment confirming recovery plan documentation was updated within 30 days of each exercise completion", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU DORA Article 26 requires financial entities to conduct advanced ICT risk testing including threat-led penetration testing and recovery exercises. AI system recovery tabletop exercises satisfy the exercise requirement for systems below the advanced testing threshold and contribute to DORA compliance evidence." }, { "control": "apeiris://resilience/controls/RO-07", "id": "RO-07", "domain": "resilience", "name": "Recovery Time Compliance Verification", "validation_objective": "For every AI system recovery event, actual RTO and RPO values must be automatically calculated from structured audit trail timestamps and compared against the documented targets in the recovery target register, with a compliance report generated at incident close and any breach routed to the business continuity manager and owning engineering team within five business days for corrective action.", "blocking_effect": "advisory", "evidence_required": [ "recovery_target_register mapping each AI system component to business-owner-approved RTO and RPO values validated against contractual SLA commitments", "rto_rpo_compliance_report with actual_rto, target_rto, actual_rpo, target_rpo, and compliance_status fields per affected component generated automatically from audit trail data for each recovery event", "breach_remediation_records showing corrective action acknowledgment, root cause documentation, and completion status for all documented RTO or RPO breaches within 30 days", "rolling_compliance_dashboard export showing 90-day RTO and RPO compliance rates by system component used in quarterly management reviews" ], "evidence": [ { "id": "RO-07-E1", "description": "recovery_target_register mapping each AI system component to business-owner-approved RTO and RPO values validated against contractual SLA commitments", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RO-07-E2", "description": "rto_rpo_compliance_report with actual_rto, target_rto, actual_rpo, target_rpo, and compliance_status fields per affected component generated automatically from audit trail data for each recovery event", "evidence_type": "audit-log", "verification": "automated" }, { "id": "RO-07-E3", "description": "breach_remediation_records showing corrective action acknowledgment, root cause documentation, and completion status for all documented RTO or RPO breaches within 30 days", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RO-07-E4", "description": "rolling_compliance_dashboard export showing 90-day RTO and RPO compliance rates by system component used in quarterly management reviews", "evidence_type": "configuration-snapshot", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU DORA Article 12(2) requires backup systems and restoration and recovery procedures and methods that are tested periodically. Verifying that actual recovery performance met documented RTO/RPO commitments after each activation supplies the evidence that this testing obligation is met in substance." }, { "control": "apeiris://resilience/controls/RV-02", "id": "RV-02", "domain": "resilience", "name": "Resilience Control Verification Testing", "validation_objective": "All resilience controls protecting each production AI system must have been executed against their defined test scenarios within the scheduled testing interval, with pass/fail results recorded per control and all identified failures tracked to a remediation item with an assigned owner and resolution deadline.", "blocking_effect": "requires-review", "evidence_required": [ "resilience_testing_register with control_id, ai_system_id, test_scenario, execution_date, pass_fail_status, and evidence_summary for each control within the current testing interval", "remediation_log with control_id, failure_description, assigned_owner, deadline, and resolution_date for every control that failed its most recent test", "test_schedule_document listing each control's required test frequency and confirming no gaps exceed the prescribed interval", "retest_record confirming each remediated control was retested within 30 days of remediation closure and passed" ], "evidence": [ { "id": "RV-02-E1", "description": "resilience_testing_register with control_id, ai_system_id, test_scenario, execution_date, pass_fail_status, and evidence_summary for each control within the current testing interval", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RV-02-E2", "description": "remediation_log with control_id, failure_description, assigned_owner, deadline, and resolution_date for every control that failed its most recent test", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "RV-02-E3", "description": "test_schedule_document listing each control's required test frequency and confirming no gaps exceed the prescribed interval", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "RV-02-E4", "description": "retest_record confirming each remediated control was retested within 30 days of remediation closure and passed", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU DORA Article 25 mandates that financial entities test their ICT continuity and recovery capabilities at least annually, with advanced testing requirements for significant entities. AI systems that support critical financial functions must meet these legally binding testing obligations." } ] }, { "requirement_id": "DORA-ART12-03", "section": "Art. 12(5)", "title": "System Restore Procedures and Post-Recovery Data Integrity", "text": "Financial entities shall ensure that data and AI system states restored after a disruption are consistent, complete, and accurately reflect the state prior to the ICT incident, and that data integrity is verified before resuming normal operations.", "verdict": "supported", "coverage": "direct", "notes": "RO-03 governs data recovery and integrity verification post-incident; RO-05 mandates pre-restoration validation before traffic resumption (including AI inference); RV-04 verifies recovery capability after an actual incident. These controls directly address DORA's requirement for verified data integrity before AI systems resume operations after disruption.", "control_count": 3, "proof_chain": [ { "control": "apeiris://resilience/controls/RO-03", "id": "RO-03", "domain": "resilience", "name": "Data Recovery and Integrity Verification Post-Incident", "validation_objective": "All tier-1 AI data stores \u2014 including training datasets, feature stores, vector databases, and inference logs \u2014 have backup intervals meeting their defined RPO; post-restore integrity hashes are computed and compared against a separate append-only integrity log before AI workloads are permitted to read from the restored store; and no AI workload accessed unverified recovered data in any recovery event within the review period.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "data_store_inventory listing all AI data stores with assigned backup tier, defined RPO, and last backup timestamp confirming compliance within the RPO window for each store", "integrity_hash_log from the append-only integrity store showing hashes computed at each backup interval for all tier-1 data stores, with the log stored in a system separate from backup storage", "recovery_event_record per data recovery showing: backup ID used, pre-restore hash from the integrity log, post-restore hash comparison result (pass/fail), authorizing engineer, quarantine-lift timestamp, and any AI workload access attempts blocked during quarantine", "quarantine_enforcement_log confirming read-block signals were active and no AI workload accessed the data store before verification completed for each recovery event" ], "evidence": [ { "id": "RO-03-E1", "description": "data_store_inventory listing all AI data stores with assigned backup tier, defined RPO, and last backup timestamp confirming compliance within the RPO window for each store", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RO-03-E2", "description": "integrity_hash_log from the append-only integrity store showing hashes computed at each backup interval for all tier-1 data stores, with the log stored in a system separate from backup storage", "evidence_type": "audit-log", "verification": "automated" }, { "id": "RO-03-E3", "description": "recovery_event_record per data recovery showing: backup ID used, pre-restore hash from the integrity log, post-restore hash comparison result (pass/fail), authorizing engineer, quarantine-lift timestamp, and any AI workload access attempts blocked during quarantine", "evidence_type": "audit-log", "verification": "automated" }, { "id": "RO-03-E4", "description": "quarantine_enforcement_log confirming read-block signals were active and no AI workload accessed the data store before verification completed for each recovery event", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU DORA Article 12(1)-(2) requires backup policies, backup systems and restoration and recovery procedures that safeguard the security and integrity of data when restoring, including restoration from segregated backup systems. Post-incident data recovery with integrity verification implements those requirements for AI training data, feature stores, and vector databases." }, { "control": "apeiris://resilience/controls/RO-05", "id": "RO-05", "domain": "resilience", "name": "Pre-Restoration Validation Before Traffic Resumption", "validation_objective": "Before production traffic is restored to any AI system following a recovery operation, a gate orchestrator must execute and record pass results for all five gate categories \u2014 infrastructure health, model behavioral correctness, data integrity, security posture, and compliance status \u2014 with each gate's pass timestamp preceding the traffic restoration timestamp; any bypass must carry dual-authorization documentation and be followed by full gate completion within two hours.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "gate_orchestrator_pass_log per recovery event showing gate category, test executed, pass/fail result, and timestamp for each of the five categories, with all gates showing pass before the traffic restoration timestamp", "behavioral_regression_test_report from the model behavioral correctness gate showing results against the golden reference dataset with quantitative deviation metric below the defined threshold and latency measurements within SLA", "security_posture_check_record confirming: configuration integrity comparison against last known-good baseline, credential rotation verification for credentials in scope of the incident, and vulnerability scan completion for high-severity incidents", "bypass_authorization_record (if bypass was used) showing dual-authorization approver identities and timestamps, and post-bypass validation completion confirmation within two hours of traffic restoration" ], "evidence": [ { "id": "RO-05-E1", "description": "gate_orchestrator_pass_log per recovery event showing gate category, test executed, pass/fail result, and timestamp for each of the five categories, with all gates showing pass before the traffic restoration timestamp", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "RO-05-E2", "description": "behavioral_regression_test_report from the model behavioral correctness gate showing results against the golden reference dataset with quantitative deviation metric below the defined threshold and latency measurements within SLA", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RO-05-E3", "description": "security_posture_check_record confirming: configuration integrity comparison against last known-good baseline, credential rotation verification for credentials in scope of the incident, and vulnerability scan completion for high-severity incidents", "evidence_type": "incident-record", "verification": "attested" }, { "id": "RO-05-E4", "description": "bypass_authorization_record (if bypass was used) showing dual-authorization approver identities and timestamps, and post-bypass validation completion confirmation within two hours of traffic restoration", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU DORA Article 12(2) requires backup systems and restoration procedures whose activation does not jeopardise the security of network and information systems or the availability, authenticity, integrity or confidentiality of data. Pre-restoration validation gates are how an AI operator demonstrates a restored system is safe before production traffic resumes." }, { "control": "apeiris://resilience/controls/RV-04", "id": "RV-04", "domain": "resilience", "name": "Recovery Capability Verification After Actual Incident", "validation_objective": "Every incident that triggered AI system recovery procedures must have a completed recovery verification record confirming actual RTO and RPO achieved against declared objectives, a post-incident review initiated within five business days for any incident that exceeded declared objectives, and all identified plan gaps tracked to closed remediation items within 30 days.", "blocking_effect": "requires-review", "evidence_required": [ "incident_recovery_verification_record per qualifying incident with incident_id, ai_system_id, declared_rto_minutes, declared_rpo_minutes, actual_rto_minutes, actual_rpo_minutes, all_components_verified_healthy flag, and closure_gate_completed timestamp", "post_incident_review_document with incident_id, root_cause_analysis, recovery_performance_gap_analysis, and action_items for each incident that exceeded RTO or RPO targets", "plan_update_action_item_register with action_id, source_incident_id, gap_description, assigned_owner, deadline, and resolution_date for each gap identified in post-incident reviews", "residual_failure_check_record confirming all AI system components (inference endpoint, model state, data consistency, downstream dependencies) were individually verified healthy before incident closure" ], "evidence": [ { "id": "RV-04-E1", "description": "incident_recovery_verification_record per qualifying incident with incident_id, ai_system_id, declared_rto_minutes, declared_rpo_minutes, actual_rto_minutes, actual_rpo_minutes, all_components_verified_healthy flag, and closure_gate_completed timestamp", "evidence_type": "incident-record", "verification": "attested" }, { "id": "RV-04-E2", "description": "post_incident_review_document with incident_id, root_cause_analysis, recovery_performance_gap_analysis, and action_items for each incident that exceeded RTO or RPO targets", "evidence_type": "incident-record", "verification": "attested" }, { "id": "RV-04-E3", "description": "plan_update_action_item_register with action_id, source_incident_id, gap_description, assigned_owner, deadline, and resolution_date for each gap identified in post-incident reviews", "evidence_type": "incident-record", "verification": "attested" }, { "id": "RV-04-E4", "description": "residual_failure_check_record confirming all AI system components (inference endpoint, model state, data consistency, downstream dependencies) were individually verified healthy before incident closure", "evidence_type": "incident-record", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU DORA Article 17 requires financial entities to conduct post-incident reviews for major ICT-related incidents and to implement corrective measures. AI systems involved in material incidents trigger this obligation, making post-incident recovery verification a component of DORA compliance for in-scope organizations." } ] }, { "requirement_id": "DORA-ART13-01", "section": "Art. 13(1)", "title": "Post-Incident Review and Operational Lessons Learned", "text": "Financial entities shall, after a major ICT-related incident, perform a post-incident review to analyse the causes and identify lessons learned, and shall document findings to improve the ICT risk management framework.", "verdict": "supported", "coverage": "direct", "notes": "RV-04 requires recovery capability verification after actual incidents, including root cause analysis; RG-07 mandates resilience program metrics and board reporting that incorporates incident learnings; AU-06 governs audit finding remediation programs that consume incident lessons; RG-06 integrates incident response and post-incident learning into the resilience governance program. These controls directly support DORA's post-incident review mandate.", "control_count": 4, "proof_chain": [ { "control": "apeiris://resilience/controls/RV-04", "id": "RV-04", "domain": "resilience", "name": "Recovery Capability Verification After Actual Incident", "validation_objective": "Every incident that triggered AI system recovery procedures must have a completed recovery verification record confirming actual RTO and RPO achieved against declared objectives, a post-incident review initiated within five business days for any incident that exceeded declared objectives, and all identified plan gaps tracked to closed remediation items within 30 days.", "blocking_effect": "requires-review", "evidence_required": [ "incident_recovery_verification_record per qualifying incident with incident_id, ai_system_id, declared_rto_minutes, declared_rpo_minutes, actual_rto_minutes, actual_rpo_minutes, all_components_verified_healthy flag, and closure_gate_completed timestamp", "post_incident_review_document with incident_id, root_cause_analysis, recovery_performance_gap_analysis, and action_items for each incident that exceeded RTO or RPO targets", "plan_update_action_item_register with action_id, source_incident_id, gap_description, assigned_owner, deadline, and resolution_date for each gap identified in post-incident reviews", "residual_failure_check_record confirming all AI system components (inference endpoint, model state, data consistency, downstream dependencies) were individually verified healthy before incident closure" ], "evidence": [ { "id": "RV-04-E1", "description": "incident_recovery_verification_record per qualifying incident with incident_id, ai_system_id, declared_rto_minutes, declared_rpo_minutes, actual_rto_minutes, actual_rpo_minutes, all_components_verified_healthy flag, and closure_gate_completed timestamp", "evidence_type": "incident-record", "verification": "attested" }, { "id": "RV-04-E2", "description": "post_incident_review_document with incident_id, root_cause_analysis, recovery_performance_gap_analysis, and action_items for each incident that exceeded RTO or RPO targets", "evidence_type": "incident-record", "verification": "attested" }, { "id": "RV-04-E3", "description": "plan_update_action_item_register with action_id, source_incident_id, gap_description, assigned_owner, deadline, and resolution_date for each gap identified in post-incident reviews", "evidence_type": "incident-record", "verification": "attested" }, { "id": "RV-04-E4", "description": "residual_failure_check_record confirming all AI system components (inference endpoint, model state, data consistency, downstream dependencies) were individually verified healthy before incident closure", "evidence_type": "incident-record", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU DORA Article 17 requires financial entities to conduct post-incident reviews for major ICT-related incidents and to implement corrective measures. AI systems involved in material incidents trigger this obligation, making post-incident recovery verification a component of DORA compliance for in-scope organizations." }, { "control": "apeiris://resilience/controls/RG-07", "id": "RG-07", "domain": "resilience", "name": "Resilience Program Metrics and Board Reporting", "validation_objective": "The resilience program must produce a quarterly metrics dashboard delivered to the Resilience Steering Committee within 30 days of each quarter end covering all five required metric categories with documented targets and trend data, and an annual board resilience report acknowledged by the board or audit committee within the required cycle.", "blocking_effect": "advisory", "evidence_required": [ "Quarterly resilience metrics dashboards for all four quarters in the review period with delivery timestamps confirming receipt by the Resilience Steering Committee within 30 days of quarter end", "Metrics register with documented target values, measurement methodology, and named metric owner for each of the five required metric categories (RTO/RPO compliance rate, recovery test pass rate, AI system resilience coverage, MTTR by tier, Severity 1 incident frequency)", "Annual board resilience report with Resilience Steering Committee approval date preceding board submission, and board or audit committee acknowledgment record", "Source data records (test execution logs, incident records) cross-referenceable against at least two sampled quarters of reported dashboard values to verify metric accuracy", "Evidence that metrics outside target range in any quarter have associated management commentary and governance discussion record in the Resilience Steering Committee minutes" ], "evidence": [ { "id": "RG-07-E1", "description": "Quarterly resilience metrics dashboards for all four quarters in the review period with delivery timestamps confirming receipt by the Resilience Steering Committee within 30 days of quarter end", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RG-07-E2", "description": "Metrics register with documented target values, measurement methodology, and named metric owner for each of the five required metric categories (RTO/RPO compliance rate, recovery test pass rate, AI system resilience coverage, MTTR by tier, Severity 1 incident frequency)", "evidence_type": "incident-record", "verification": "attested" }, { "id": "RG-07-E3", "description": "Annual board resilience report with Resilience Steering Committee approval date preceding board submission, and board or audit committee acknowledgment record", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RG-07-E4", "description": "Source data records (test execution logs, incident records) cross-referenceable against at least two sampled quarters of reported dashboard values to verify metric accuracy", "evidence_type": "incident-record", "verification": "attested" }, { "id": "RG-07-E5", "description": "Evidence that metrics outside target range in any quarter have associated management commentary and governance discussion record in the Resilience Steering Committee minutes", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU DORA Article 6(5) requires the ICT risk management framework to be documented, reviewed at least yearly (and upon major incidents or supervisory instruction) and continuously improved, with a report on the review available to the competent authority on request. Board-level resilience metrics reporting is how the management body exercises that review in practice (Article 6(8) defines the digital operational resilience strategy itself)." }, { "control": "apeiris://compliance/controls/AU-06", "id": "AU-06", "domain": "compliance", "name": "Audit Finding Remediation Program", "validation_objective": "The organization must maintain a centralized finding register with zero overdue critical findings beyond defined SLAs, at least 95% of closed findings supported by independently verified remediation evidence, and a repeat finding rate in the same control area below 10% over any rolling 24-month window, demonstrating that root-cause analysis is eliminating systemic deficiencies rather than merely closing proximate findings.", "blocking_effect": "requires-review", "evidence_required": [ "finding_register export showing all findings from internal audit, external audit, regulatory examinations, and self-assessments with severity classification, root-cause category, corrective action plan, assigned owner, target close date, verification method, and current status", "independently_verified_closure_records for all findings marked closed in the last 12 months, including the type of verification evidence and the identity of the independent reviewer who confirmed remediation before formal closure", "root_cause_analysis_reports for all critical and high findings and any findings recurring in the same control area within a 24-month window, completed before the corrective action plan was approved", "monthly_aging_reports for the last 6 months showing open finding counts by severity, owner, and source with evidence of GRC committee distribution and documented escalation for overdue items", "corrective_action_change_tickets for all IT-related findings, confirming technical remediation was processed through the change management system with change records attached to the finding" ], "evidence": [ { "id": "AU-06-E1", "description": "finding_register export showing all findings from internal audit, external audit, regulatory examinations, and self-assessments with severity classification, root-cause category, corrective action plan, assigned owner, target close date, verification method, and current status", "evidence_type": "third-party-audit-report", "verification": "third-party" }, { "id": "AU-06-E2", "description": "independently_verified_closure_records for all findings marked closed in the last 12 months, including the type of verification evidence and the identity of the independent reviewer who confirmed remediation before formal closure", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AU-06-E3", "description": "root_cause_analysis_reports for all critical and high findings and any findings recurring in the same control area within a 24-month window, completed before the corrective action plan was approved", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AU-06-E4", "description": "monthly_aging_reports for the last 6 months showing open finding counts by severity, owner, and source with evidence of GRC committee distribution and documented escalation for overdue items", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AU-06-E5", "description": "corrective_action_change_tickets for all IT-related findings, confirming technical remediation was processed through the change management system with change records attached to the finding", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://resilience/controls/RG-06", "id": "RG-06", "domain": "resilience", "name": "Resilience Incident Response Integration", "validation_objective": "All production AI system incidents must be classified against the published AI resilience severity taxonomy, RTO/RPO breach events must trigger the documented governance escalation path within the required timeframe, and all Severity 1 incidents must have a completed post-incident resilience review within 30 days of resolution that includes governance findings.", "blocking_effect": "requires-review", "evidence_required": [ "Published AI resilience incident severity taxonomy with explicit mapping of RTO/RPO breach scenarios to severity levels, documented escalation timeframes per severity, and recovery decision authority matrix", "Incident management system records for all AI system incidents in the review period showing severity classification field populated using the AI resilience taxonomy", "Governance escalation records for all Severity 1 and Severity 2 AI resilience incidents, including timestamp of executive notification and Resilience Steering Committee notification against the required timeframe", "Post-incident resilience review reports for all Severity 1 incidents, confirming completion within 30 days of resolution and inclusion of governance control failure assessment", "Board-level resilience reporting artifacts showing RTO/RPO breach incidents are reflected in governance reporting with correct severity and timeline" ], "evidence": [ { "id": "RG-06-E1", "description": "Published AI resilience incident severity taxonomy with explicit mapping of RTO/RPO breach scenarios to severity levels, documented escalation timeframes per severity, and recovery decision authority matrix", "evidence_type": "incident-record", "verification": "attested" }, { "id": "RG-06-E2", "description": "Incident management system records for all AI system incidents in the review period showing severity classification field populated using the AI resilience taxonomy", "evidence_type": "incident-record", "verification": "attested" }, { "id": "RG-06-E3", "description": "Governance escalation records for all Severity 1 and Severity 2 AI resilience incidents, including timestamp of executive notification and Resilience Steering Committee notification against the required timeframe", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RG-06-E4", "description": "Post-incident resilience review reports for all Severity 1 incidents, confirming completion within 30 days of resolution and inclusion of governance control failure assessment", "evidence_type": "incident-record", "verification": "attested" }, { "id": "RG-06-E5", "description": "Board-level resilience reporting artifacts showing RTO/RPO breach incidents are reflected in governance reporting with correct severity and timeline", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "DORA Articles 17-23 establish comprehensive requirements for ICT-related incident management, classification, reporting, and post-incident review. For covered entities, integrating AI resilience incidents into the enterprise incident management process that meets DORA standards is a legal obligation." } ] }, { "requirement_id": "DORA-ART13-02", "section": "Art. 13(2)", "title": "Continuous Improvement and Risk Framework Updates", "text": "Financial entities shall apply lessons learned from ICT-related incidents and from digital operational resilience testing to update their ICT risk management framework and associated controls, ensuring continuous improvement.", "verdict": "partial", "coverage": "partial", "notes": "CA-05 governs regulatory change management including framework updates; CI-07 tracks remediation and closure of compliance findings; PG-08 governs lessons learned and policy improvement cycles. The continuous improvement obligation is partially addressed \u2014 Apeiris controls cover the framework update and remediation tracking dimensions, but the specific process of systematically feeding incident findings back into the ICT risk framework is an operational procedure that goes beyond what attestation controls can fully mandate.", "control_count": 3, "proof_chain": [ { "control": "apeiris://compliance/controls/CA-05", "id": "CA-05", "domain": "compliance", "name": "Regulatory Change Management", "validation_objective": "The organization must maintain a current regulatory watch list covering all applicable jurisdictions and regulatory bodies identified in active CA-01 scope records, and every regulatory publication in the monitoring period must have a completed impact assessment with triage within 5 business days of publication, with all required architecture updates completed before the publication's regulatory effective date.", "blocking_effect": "advisory", "evidence_required": [ "regulatory_watch_list document showing all monitored jurisdictions, regulatory_bodies[], authoritative_source_subscriptions[], and last_reviewed_on within the current quarter", "regulatory_change_log entries for each publication in the watch period, each containing publication_id, source, publication_date, triage_completed_at (within 5 business days), and impact_assessment_id or determination='no_impact'", "impact_assessment records for each assessed regulatory change containing affected_ai_systems[], affected_obligations[], required_architecture_updates[], assigned_owner, target_completion_date, and regulatory_effective_date", "remediation_completion_records for each required architecture update showing completed_at before target_completion_date and before regulatory_effective_date, with updated_artifact_ids referenced" ], "evidence": [ { "id": "CA-05-E1", "description": "regulatory_watch_list document showing all monitored jurisdictions, regulatory_bodies[], authoritative_source_subscriptions[], and last_reviewed_on within the current quarter", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-05-E2", "description": "regulatory_change_log entries for each publication in the watch period, each containing publication_id, source, publication_date, triage_completed_at (within 5 business days), and impact_assessment_id or determination='no_impact'", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-05-E3", "description": "impact_assessment records for each assessed regulatory change containing affected_ai_systems[], affected_obligations[], required_architecture_updates[], assigned_owner, target_completion_date, and regulatory_effective_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-05-E4", "description": "remediation_completion_records for each required architecture update showing completed_at before target_completion_date and before regulatory_effective_date, with updated_artifact_ids referenced", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://compliance/controls/CI-07", "id": "CI-07", "domain": "compliance", "name": "Remediation Tracking and Closure", "validation_objective": "Every compliance gap identified by control testing (CI-01), monitoring (CI-02), or internal audit (CI-06) has a corresponding remediation ticket with an assigned single owner, target date, documented root cause, remediation plan, and independently verified closure evidence. No critical-severity ticket is open beyond 15 business days without a documented executive escalation record.", "blocking_effect": "requires-review", "evidence_required": [ "Remediation register export listing all open and closed tickets with source_control, severity, assigned_owner, root_cause, remediation_plan, target_date, and actual_closure_date for the full audit period", "Closure verification records for each high and critical ticket documenting the independent verifier identity, verification method (re-test, configuration check, or re-assessment), and verification outcome", "Automated escalation log showing escalation trigger events and management acknowledgment timestamps for all overdue items during the period", "Recurrence analysis report identifying any finding appearing in both the current and prior audit cycle, with root cause explanation for recurrence", "Weekly remediation velocity reports showing open ticket counts by severity and age distribution across the audit period" ], "evidence": [ { "id": "CI-07-E1", "description": "Remediation register export listing all open and closed tickets with source_control, severity, assigned_owner, root_cause, remediation_plan, target_date, and actual_closure_date for the full audit period", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "CI-07-E2", "description": "Closure verification records for each high and critical ticket documenting the independent verifier identity, verification method (re-test, configuration check, or re-assessment), and verification outcome", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "CI-07-E3", "description": "Automated escalation log showing escalation trigger events and management acknowledgment timestamps for all overdue items during the period", "evidence_type": "audit-log", "verification": "automated" }, { "id": "CI-07-E4", "description": "Recurrence analysis report identifying any finding appearing in both the current and prior audit cycle, with root cause explanation for recurrence", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-07-E5", "description": "Weekly remediation velocity reports showing open ticket counts by severity and age distribution across the audit period", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://authority/controls/PG-08", "id": "PG-08", "domain": "authority", "name": "Lessons Learned and Policy Improvement", "validation_objective": "Every AI policy incident and near-miss must generate a structured lessons-learned record that identifies the root cause, the policy gap exploited, and a documented improvement action with an assigned owner and target closure date. The improvement cycle must be confirmed closed in the policy registry before the control is considered passing.", "blocking_effect": "requires-review", "evidence_required": [ "lessons_learned_record for each qualifying incident containing root_cause, policy_gap_reference, improvement_action, assigned_owner, and target_closure_date fields", "policy_improvement_log confirming that each improvement action triggered a versioned policy update or documented risk-acceptance decision with sign-off", "incident_classification_record distinguishing incidents requiring formal lessons-learned review from those below threshold, with classification rationale", "policy_registry_update_record showing the policy version that incorporated each improvement action, with before-and-after change diff and approver identity", "improvement_cycle_closure_record confirming that each open improvement action was closed within its target date or escalated with documented justification for extension" ], "evidence": [ { "id": "PG-08-E1", "description": "lessons_learned_record for each qualifying incident containing root_cause, policy_gap_reference, improvement_action, assigned_owner, and target_closure_date fields", "evidence_type": "incident-record", "verification": "attested" }, { "id": "PG-08-E2", "description": "policy_improvement_log confirming that each improvement action triggered a versioned policy update or documented risk-acceptance decision with sign-off", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PG-08-E3", "description": "incident_classification_record distinguishing incidents requiring formal lessons-learned review from those below threshold, with classification rationale", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PG-08-E4", "description": "policy_registry_update_record showing the policy version that incorporated each improvement action, with before-and-after change diff and approver identity", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PG-08-E5", "description": "improvement_cycle_closure_record confirming that each open improvement action was closed within its target date or escalated with documented justification for extension", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "DORA-ART17-01", "section": "Art. 17(1)", "title": "ICT-Related Incident Classification for AI Systems", "text": "Financial entities shall classify ICT-related incidents and shall determine their impact based on criteria such as the number of clients affected, duration of the disruption, geographic spread, data losses, and criticality of affected services, including AI-driven services.", "verdict": "supported", "coverage": "direct", "notes": "CG-06 establishes compliance incident response protocols including classification; RG-06 integrates resilience incident response with classification procedures; CI-03 defines AI-specific compliance KPIs that feed classification thresholds; RP-05 provides recovery priority classification for AI systems that underpins severity determination. These controls directly support DORA's incident classification mandate as applied to AI-driven financial services.", "control_count": 4, "proof_chain": [ { "control": "apeiris://compliance/controls/CG-06", "id": "CG-06", "domain": "compliance", "name": "Compliance Incident Response", "validation_objective": "A documented Compliance Incident Response Playbook exists covering at least four AI-specific incident scenario types (discriminatory AI output, unauthorized AI data processing, regulatory inquiry, enforcement action), defines severity levels P1-P4 with named role assignments and notification timelines specific to each applicable regulatory framework (GDPR 72h, EU AI Act Article 73), and has been exercised in a tabletop simulation of an AI compliance scenario within the last 18 months with documented lessons-learned outcomes.", "blocking_effect": "requires-review", "evidence_required": [ "compliance_incident_response_playbook document containing ai_incident_scenario_list (minimum four types), severity_level_definitions (P1-P4) with escalation_paths, regulatory_notification_timeline_matrix per framework with specific SLAs, named_role_assignments for Incident Commander/Legal Lead/Technical Lead, and containment_action_steps", "tabletop_exercise_record dated within the last 18 months documenting scenario_type (must be AI compliance scenario), participants by named role, findings, and lessons_learned items with remediation_action_owner and completion_status", "notification_template_set for each applicable regulatory authority with legal_counsel_review_date within the last 12 months confirming language is current and jurisdiction-appropriate", "incident_response_log for any compliance incidents in the last 24 months showing incident_id, severity_level, trigger_timestamp, notification_sent_timestamp, regulatory_authority_notified, and SLA_compliance status for each framework-governed notification" ], "evidence": [ { "id": "CG-06-E1", "description": "compliance_incident_response_playbook document containing ai_incident_scenario_list (minimum four types), severity_level_definitions (P1-P4) with escalation_paths, regulatory_notification_timeline_matrix per framework with specific SLAs, named_role_assignments for Incident Commander/Legal Lead/Technical Lead, and containment_action_steps", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CG-06-E2", "description": "tabletop_exercise_record dated within the last 18 months documenting scenario_type (must be AI compliance scenario), participants by named role, findings, and lessons_learned items with remediation_action_owner and completion_status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-06-E3", "description": "notification_template_set for each applicable regulatory authority with legal_counsel_review_date within the last 12 months confirming language is current and jurisdiction-appropriate", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-06-E4", "description": "incident_response_log for any compliance incidents in the last 24 months showing incident_id, severity_level, trigger_timestamp, notification_sent_timestamp, regulatory_authority_notified, and SLA_compliance status for each framework-governed notification", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://resilience/controls/RG-06", "id": "RG-06", "domain": "resilience", "name": "Resilience Incident Response Integration", "validation_objective": "All production AI system incidents must be classified against the published AI resilience severity taxonomy, RTO/RPO breach events must trigger the documented governance escalation path within the required timeframe, and all Severity 1 incidents must have a completed post-incident resilience review within 30 days of resolution that includes governance findings.", "blocking_effect": "requires-review", "evidence_required": [ "Published AI resilience incident severity taxonomy with explicit mapping of RTO/RPO breach scenarios to severity levels, documented escalation timeframes per severity, and recovery decision authority matrix", "Incident management system records for all AI system incidents in the review period showing severity classification field populated using the AI resilience taxonomy", "Governance escalation records for all Severity 1 and Severity 2 AI resilience incidents, including timestamp of executive notification and Resilience Steering Committee notification against the required timeframe", "Post-incident resilience review reports for all Severity 1 incidents, confirming completion within 30 days of resolution and inclusion of governance control failure assessment", "Board-level resilience reporting artifacts showing RTO/RPO breach incidents are reflected in governance reporting with correct severity and timeline" ], "evidence": [ { "id": "RG-06-E1", "description": "Published AI resilience incident severity taxonomy with explicit mapping of RTO/RPO breach scenarios to severity levels, documented escalation timeframes per severity, and recovery decision authority matrix", "evidence_type": "incident-record", "verification": "attested" }, { "id": "RG-06-E2", "description": "Incident management system records for all AI system incidents in the review period showing severity classification field populated using the AI resilience taxonomy", "evidence_type": "incident-record", "verification": "attested" }, { "id": "RG-06-E3", "description": "Governance escalation records for all Severity 1 and Severity 2 AI resilience incidents, including timestamp of executive notification and Resilience Steering Committee notification against the required timeframe", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RG-06-E4", "description": "Post-incident resilience review reports for all Severity 1 incidents, confirming completion within 30 days of resolution and inclusion of governance control failure assessment", "evidence_type": "incident-record", "verification": "attested" }, { "id": "RG-06-E5", "description": "Board-level resilience reporting artifacts showing RTO/RPO breach incidents are reflected in governance reporting with correct severity and timeline", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "DORA Articles 17-23 establish comprehensive requirements for ICT-related incident management, classification, reporting, and post-incident review. For covered entities, integrating AI resilience incidents into the enterprise incident management process that meets DORA standards is a legal obligation." }, { "control": "apeiris://compliance/controls/CI-03", "id": "CI-03", "domain": "compliance", "name": "AI-Specific Compliance KPIs", "validation_objective": "The compliance program must produce a defined set of AI-specific KPIs covering all five baseline dimensions (obligation coverage, evidence freshness, audit finding rate, remediation velocity, training completion) on a defined reporting cadence, with each KPI having a documented target threshold, a current measured value, and a trend direction indicator. No KPI may report a null measured_value at the defined reporting cadence without a documented exception.", "blocking_effect": "advisory", "evidence_required": [ "kpi_definition_register listing each KPI with kpi_id, name, definition, measurement_method, data_source, target_threshold, and reporting_frequency", "kpi_measurement_report for the current period containing measured_value, prior_period_value, trend_direction, and within_threshold flag for each defined KPI", "kpi_trend_history covering at least four consecutive reporting periods per KPI to enable trend analysis", "management_reporting_record confirming KPI results were presented to the compliance governance committee with attendance record and date", "remediation_action_record for each KPI where measured_value is outside the target_threshold, with root_cause, corrective_action, and target_return_to_threshold_date" ], "evidence": [ { "id": "CI-03-E1", "description": "kpi_definition_register listing each KPI with kpi_id, name, definition, measurement_method, data_source, target_threshold, and reporting_frequency", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-03-E2", "description": "kpi_measurement_report for the current period containing measured_value, prior_period_value, trend_direction, and within_threshold flag for each defined KPI", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-03-E3", "description": "kpi_trend_history covering at least four consecutive reporting periods per KPI to enable trend analysis", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-03-E4", "description": "management_reporting_record confirming KPI results were presented to the compliance governance committee with attendance record and date", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CI-03-E5", "description": "remediation_action_record for each KPI where measured_value is outside the target_threshold, with root_cause, corrective_action, and target_return_to_threshold_date", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://resilience/controls/RP-05", "id": "RP-05", "domain": "resilience", "name": "Recovery Priority Classification for AI Systems", "validation_objective": "Every production AI system must be assigned a formally documented recovery priority tier (tier 1 through tier N) based on quantified business impact analysis, regulatory obligation mapping, and downstream dependency assessment, with tier assignments approved by named business stakeholders and explicitly used to sequence recovery resources in the enterprise DR plan when concurrent AI system failures exceed available recovery capacity.", "blocking_effect": "requires-review", "evidence_required": [ "Recovery priority tier register listing every production AI system with tier assignment, business impact justification citing downtime cost, regulatory obligation notes, downstream dependency list, and date of last tier review", "Business impact analysis output per AI system showing quantified downtime cost per hour, maximum tolerable outage period, and dependency chain analysis supporting the tier assignment", "Stakeholder approval records for each tier assignment showing business owner, compliance owner, and date of approval", "Enterprise DR sequencing plan or runbook section showing how tier assignments drive recovery resource allocation during concurrent AI system failures", "Tier review records confirming assignments were reviewed within the last 12 months or within 30 days of any significant AI system change" ], "evidence": [ { "id": "RP-05-E1", "description": "Recovery priority tier register listing every production AI system with tier assignment, business impact justification citing downtime cost, regulatory obligation notes, downstream dependency list, and date of last tier review", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RP-05-E2", "description": "Business impact analysis output per AI system showing quantified downtime cost per hour, maximum tolerable outage period, and dependency chain analysis supporting the tier assignment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RP-05-E3", "description": "Stakeholder approval records for each tier assignment showing business owner, compliance owner, and date of approval", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RP-05-E4", "description": "Enterprise DR sequencing plan or runbook section showing how tier assignments drive recovery resource allocation during concurrent AI system failures", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RP-05-E5", "description": "Tier review records confirming assignments were reviewed within the last 12 months or within 30 days of any significant AI system change", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU DORA Article 11(5) requires financial entities to determine ICT systems and services to prioritize in recovery plans. AI system tier classification directly satisfies this requirement when applied to AI workloads in financial services entities." } ] }, { "requirement_id": "DORA-ART18-01", "section": "Art. 18(1)", "title": "Major ICT Incident Threshold Determination", "text": "Financial entities shall apply the classification criteria established by competent authorities to determine when an ICT-related incident qualifies as major, and shall apply these criteria to incidents involving AI systems consistent with the materiality thresholds published under DORA RTS.", "verdict": "partial", "coverage": "partial", "notes": "OB-05 tracks DORA ICT obligations including the major incident classification thresholds; CA-06 performs compliance obligation gap analysis including against DORA RTS thresholds; RG-04 defines resilience risk appetite and thresholds that inform materiality determination. The determination of what qualifies as a major incident under DORA RTS is a regulatory classification exercise; Apeiris controls provide the tracking and governance framework but the RTS-specific threshold mapping is an obligation management rather than a fully automated control.", "control_count": 3, "proof_chain": [ { "control": "apeiris://compliance/controls/OB-05", "id": "OB-05", "domain": "compliance", "name": "DORA ICT Obligation Tracking", "validation_objective": "Financial entities subject to DORA must have a structured obligation tracking record for all ICT-related obligations across DORA's five pillars, with alert thresholds calibrated to DORA's statutory reporting windows: initial major ICT incident notification within 4 hours of classification and no later than 24 hours from awareness, with intermediate and final reports tracked to their statutory windows. Evidence of on-time alert dispatch for any ICT incident classified as major must be present in the obligation tracking system.", "blocking_effect": "advisory", "evidence_required": [ "dora_obligation_register record per financial entity showing all five pillar obligation inventories (ICT risk management, incident reporting, resilience testing, third-party risk, information sharing) with owner assignments and fulfillment status", "ict_incident_classification_log showing each incident's classification event timestamp, major_incident boolean, and the triggered notification workflow initiation timestamp confirming the 4-hour window was met", "dora_incident_notification_record showing initial notification dispatched to the competent authority within 4 hours of classification and no later than 24 hours from awareness, with dispatch timestamp and submission confirmation", "resilience_testing_schedule showing DORA-compliant testing plan (including TLPT where applicable) with completion dates and test results reports" ], "evidence": [ { "id": "OB-05-E1", "description": "dora_obligation_register record per financial entity showing all five pillar obligation inventories (ICT risk management, incident reporting, resilience testing, third-party risk, information sharing) with owner assignments and fulfillment status", "evidence_type": "third-party-audit-report", "verification": "third-party" }, { "id": "OB-05-E2", "description": "ict_incident_classification_log showing each incident's classification event timestamp, major_incident boolean, and the triggered notification workflow initiation timestamp confirming the 4-hour window was met", "evidence_type": "incident-record", "verification": "attested" }, { "id": "OB-05-E3", "description": "dora_incident_notification_record showing initial notification dispatched to the competent authority within 4 hours of classification and no later than 24 hours from awareness, with dispatch timestamp and submission confirmation", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OB-05-E4", "description": "resilience_testing_schedule showing DORA-compliant testing plan (including TLPT where applicable) with completion dates and test results reports", "evidence_type": "automated-test-result", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://compliance/controls/CA-06", "id": "CA-06", "domain": "compliance", "name": "Compliance Obligation Gap Analysis", "validation_objective": "Gap analysis must be executed at least quarterly and within 10 business days following every update to the CA-02 obligation map or CA-03 routing table, producing a complete gap register that identifies every obligation in the CA-02 map without a functioning routing table entry, with every gap assigned an owner, severity, and target closure date that precedes the obligation's regulatory effective date.", "blocking_effect": "advisory", "evidence_required": [ "gap_analysis_run_record showing analysis_date, obligation_map_version, routing_table_version, total_obligations_analyzed, gaps_identified_count, analysis_trigger (scheduled or event-driven), and methodology_description", "gap_register entries for each open gap containing obligation_id, applicable_regime, normative_force, gap_severity, assigned_owner, target_closure_date, and escalation_status for high-severity binding-law items", "gap_closure_records showing each closed gap has a corresponding routing_table_entry_id and the entry resolves to a valid attestation confirmed post-closure, with validator_identity and confirmed_at timestamp", "binding_law_gap_escalation_records showing gaps with normative_force='binding-law' were escalated to legal_counsel and executive_leadership within the defined SLA after identification" ], "evidence": [ { "id": "CA-06-E1", "description": "gap_analysis_run_record showing analysis_date, obligation_map_version, routing_table_version, total_obligations_analyzed, gaps_identified_count, analysis_trigger (scheduled or event-driven), and methodology_description", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-06-E2", "description": "gap_register entries for each open gap containing obligation_id, applicable_regime, normative_force, gap_severity, assigned_owner, target_closure_date, and escalation_status for high-severity binding-law items", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-06-E3", "description": "gap_closure_records showing each closed gap has a corresponding routing_table_entry_id and the entry resolves to a valid attestation confirmed post-closure, with validator_identity and confirmed_at timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-06-E4", "description": "binding_law_gap_escalation_records showing gaps with normative_force='binding-law' were escalated to legal_counsel and executive_leadership within the defined SLA after identification", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://resilience/controls/RG-04", "id": "RG-04", "domain": "resilience", "name": "Resilience Risk Appetite and Threshold Setting", "validation_objective": "The organization must have a formally approved Resilience Risk Appetite Statement with quantitative RTO/RPO thresholds per AI system tier, supported by current BIA documentation completed within 12 months, and all production AI systems must have system-level SLOs demonstrably aligned to their tier-mandated thresholds.", "blocking_effect": "requires-review", "evidence_required": [ "Approved Resilience Risk Appetite Statement with explicit quantitative RTO/RPO thresholds per system tier (Tier 1/2/3), Resilience Steering Committee approval signature, and review date within the last 12 months", "BIA reports for all Tier 1 and Tier 2 AI systems completed within 12 months, documenting AI-specific dependencies including model inference pipelines and training data stores", "AI system inventory showing tier classification (Tier 1/2/3) for every production AI system with BIA basis and last classification review date", "System-level SLO documentation for each production AI system with explicit mapping to the governing tier threshold from the approved appetite statement", "Resilience Steering Committee meeting record confirming the threshold review was conducted and approved with quorum" ], "evidence": [ { "id": "RG-04-E1", "description": "Approved Resilience Risk Appetite Statement with explicit quantitative RTO/RPO thresholds per system tier (Tier 1/2/3), Resilience Steering Committee approval signature, and review date within the last 12 months", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RG-04-E2", "description": "BIA reports for all Tier 1 and Tier 2 AI systems completed within 12 months, documenting AI-specific dependencies including model inference pipelines and training data stores", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RG-04-E3", "description": "AI system inventory showing tier classification (Tier 1/2/3) for every production AI system with BIA basis and last classification review date", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RG-04-E4", "description": "System-level SLO documentation for each production AI system with explicit mapping to the governing tier threshold from the approved appetite statement", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RG-04-E5", "description": "Resilience Steering Committee meeting record confirming the threshold review was conducted and approved with quorum", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "DORA Article 11 requires financial entities to have an ICT business continuity policy that includes recovery time and recovery point objectives. Quantitative threshold-setting backed by governance approval is a direct legal requirement for covered entities." } ] }, { "requirement_id": "DORA-ART19-01", "section": "Art. 19(1)", "title": "Mandatory Reporting of Major ICT Incidents to Competent Authorities", "text": "Financial entities shall report major ICT-related incidents to the relevant competent authority with initial, intermediate, and final reports within the timeframes prescribed under DORA, including incidents involving AI systems that meet the major incident threshold.", "verdict": "supported", "coverage": "direct", "notes": "AU-05 provides the regulatory examination response program including mandatory notifications; FG-04 governs regulatory relationship management for financial entities specifically; CG-06 covers compliance incident response including regulatory reporting obligations; OB-05 tracks DORA ICT obligations including the mandatory reporting requirements. These controls directly operationalize the DORA mandatory incident reporting obligation for AI-related major incidents.", "control_count": 4, "proof_chain": [ { "control": "apeiris://compliance/controls/AU-05", "id": "AU-05", "domain": "compliance", "name": "Regulatory Examination Response Program", "validation_objective": "The organization must have a documented, tested examination response program with a current regulatory playbook, a defined response team with assigned roles and named deputies, and regulator-specific response guides for each material regulatory relationship, such that any formal regulatory inquiry is triaged within 4 business hours and a response team with appropriate legal representation is activated within 24 hours of receipt. Zero regulatory response deadlines may be missed.", "blocking_effect": "requires-review", "evidence_required": [ "regulatory_examination_response_playbook with version date within the last 12 months, documented tier classification criteria (routine, examination, investigation, enforcement), and response team activation procedures for each tier", "response_team_roster documenting all designated team members by role (response coordinator, legal counsel lead, SME pool, document production manager, executive sponsor) with named deputies and current contact information", "document_production_log from all regulatory responses in the last 24 months confirming legal privilege review, scoping analysis, and production transmittal documentation were completed for each production", "post_examination_after_action_report for each examination closed in the last 24 months, completed within 30 days of closure and showing lessons-learned implementation status and playbook update record", "regulatory_response_deadline_compliance_record listing all response deadlines and submission dates for the last 24 months, confirming zero missed deadlines" ], "evidence": [ { "id": "AU-05-E1", "description": "regulatory_examination_response_playbook with version date within the last 12 months, documented tier classification criteria (routine, examination, investigation, enforcement), and response team activation procedures for each tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AU-05-E2", "description": "response_team_roster documenting all designated team members by role (response coordinator, legal counsel lead, SME pool, document production manager, executive sponsor) with named deputies and current contact information", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AU-05-E3", "description": "document_production_log from all regulatory responses in the last 24 months confirming legal privilege review, scoping analysis, and production transmittal documentation were completed for each production", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AU-05-E4", "description": "post_examination_after_action_report for each examination closed in the last 24 months, completed within 30 days of closure and showing lessons-learned implementation status and playbook update record", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AU-05-E5", "description": "regulatory_response_deadline_compliance_record listing all response deadlines and submission dates for the last 24 months, confirming zero missed deadlines", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://finance/controls/FG-04", "id": "FG-04", "domain": "finance", "name": "Regulatory Relationship Management", "validation_objective": "A named regulatory liaison with documented authority exists and is backed by a designated alternate, a regulatory correspondence log captures all AI-related communications within 24 hours, and notification trigger criteria have been assessed against the current AI system portfolio within the prior 90 days. The examination preparation playbook must have been tested within the prior 12 months and confirmed to produce required documentation within the defined SLA.", "blocking_effect": "advisory", "evidence_required": [ "regulatory_liaison_register with named_liaison, alternate_liaison, appointment_date, and scope_of_authority documentation for AI-related financial supervisory communications", "regulatory_correspondence_log with entry_timestamp, communication_type, regulator_identifier, and response_deadline_tracked flag for each AI-related communication in scope", "notification_trigger_assessment report dated within prior 90 days identifying which AI systems in the current portfolio were evaluated against each defined trigger criterion", "examination_preparation_playbook_drill_record with drill_date within prior 12 months, documentation_types_produced list, SLA_met flag, and gaps_identified notation" ], "evidence": [ { "id": "FG-04-E1", "description": "regulatory_liaison_register with named_liaison, alternate_liaison, appointment_date, and scope_of_authority documentation for AI-related financial supervisory communications", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FG-04-E2", "description": "regulatory_correspondence_log with entry_timestamp, communication_type, regulator_identifier, and response_deadline_tracked flag for each AI-related communication in scope", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FG-04-E3", "description": "notification_trigger_assessment report dated within prior 90 days identifying which AI systems in the current portfolio were evaluated against each defined trigger criterion", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FG-04-E4", "description": "examination_preparation_playbook_drill_record with drill_date within prior 12 months, documentation_types_produced list, SLA_met flag, and gaps_identified notation", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://compliance/controls/CG-06", "id": "CG-06", "domain": "compliance", "name": "Compliance Incident Response", "validation_objective": "A documented Compliance Incident Response Playbook exists covering at least four AI-specific incident scenario types (discriminatory AI output, unauthorized AI data processing, regulatory inquiry, enforcement action), defines severity levels P1-P4 with named role assignments and notification timelines specific to each applicable regulatory framework (GDPR 72h, EU AI Act Article 73), and has been exercised in a tabletop simulation of an AI compliance scenario within the last 18 months with documented lessons-learned outcomes.", "blocking_effect": "requires-review", "evidence_required": [ "compliance_incident_response_playbook document containing ai_incident_scenario_list (minimum four types), severity_level_definitions (P1-P4) with escalation_paths, regulatory_notification_timeline_matrix per framework with specific SLAs, named_role_assignments for Incident Commander/Legal Lead/Technical Lead, and containment_action_steps", "tabletop_exercise_record dated within the last 18 months documenting scenario_type (must be AI compliance scenario), participants by named role, findings, and lessons_learned items with remediation_action_owner and completion_status", "notification_template_set for each applicable regulatory authority with legal_counsel_review_date within the last 12 months confirming language is current and jurisdiction-appropriate", "incident_response_log for any compliance incidents in the last 24 months showing incident_id, severity_level, trigger_timestamp, notification_sent_timestamp, regulatory_authority_notified, and SLA_compliance status for each framework-governed notification" ], "evidence": [ { "id": "CG-06-E1", "description": "compliance_incident_response_playbook document containing ai_incident_scenario_list (minimum four types), severity_level_definitions (P1-P4) with escalation_paths, regulatory_notification_timeline_matrix per framework with specific SLAs, named_role_assignments for Incident Commander/Legal Lead/Technical Lead, and containment_action_steps", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CG-06-E2", "description": "tabletop_exercise_record dated within the last 18 months documenting scenario_type (must be AI compliance scenario), participants by named role, findings, and lessons_learned items with remediation_action_owner and completion_status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-06-E3", "description": "notification_template_set for each applicable regulatory authority with legal_counsel_review_date within the last 12 months confirming language is current and jurisdiction-appropriate", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-06-E4", "description": "incident_response_log for any compliance incidents in the last 24 months showing incident_id, severity_level, trigger_timestamp, notification_sent_timestamp, regulatory_authority_notified, and SLA_compliance status for each framework-governed notification", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://compliance/controls/OB-05", "id": "OB-05", "domain": "compliance", "name": "DORA ICT Obligation Tracking", "validation_objective": "Financial entities subject to DORA must have a structured obligation tracking record for all ICT-related obligations across DORA's five pillars, with alert thresholds calibrated to DORA's statutory reporting windows: initial major ICT incident notification within 4 hours of classification and no later than 24 hours from awareness, with intermediate and final reports tracked to their statutory windows. Evidence of on-time alert dispatch for any ICT incident classified as major must be present in the obligation tracking system.", "blocking_effect": "advisory", "evidence_required": [ "dora_obligation_register record per financial entity showing all five pillar obligation inventories (ICT risk management, incident reporting, resilience testing, third-party risk, information sharing) with owner assignments and fulfillment status", "ict_incident_classification_log showing each incident's classification event timestamp, major_incident boolean, and the triggered notification workflow initiation timestamp confirming the 4-hour window was met", "dora_incident_notification_record showing initial notification dispatched to the competent authority within 4 hours of classification and no later than 24 hours from awareness, with dispatch timestamp and submission confirmation", "resilience_testing_schedule showing DORA-compliant testing plan (including TLPT where applicable) with completion dates and test results reports" ], "evidence": [ { "id": "OB-05-E1", "description": "dora_obligation_register record per financial entity showing all five pillar obligation inventories (ICT risk management, incident reporting, resilience testing, third-party risk, information sharing) with owner assignments and fulfillment status", "evidence_type": "third-party-audit-report", "verification": "third-party" }, { "id": "OB-05-E2", "description": "ict_incident_classification_log showing each incident's classification event timestamp, major_incident boolean, and the triggered notification workflow initiation timestamp confirming the 4-hour window was met", "evidence_type": "incident-record", "verification": "attested" }, { "id": "OB-05-E3", "description": "dora_incident_notification_record showing initial notification dispatched to the competent authority within 4 hours of classification and no later than 24 hours from awareness, with dispatch timestamp and submission confirmation", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OB-05-E4", "description": "resilience_testing_schedule showing DORA-compliant testing plan (including TLPT where applicable) with completion dates and test results reports", "evidence_type": "automated-test-result", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "DORA-ART19-02", "section": "Art. 19(4)", "title": "Timely Incident Report Content and Submission Obligations", "text": "Financial entities shall ensure that initial notifications are submitted within four hours of classification as major, and shall provide intermediate and final reports within the prescribed timeframes, including full details of the AI systems and data affected.", "verdict": "partial", "coverage": "partial", "notes": "OB-03 tracks obligation due dates and milestones including regulatory reporting deadlines; OB-05 maintains the DORA ICT obligation register including report submission requirements; RO-04 governs recovery operations communication protocols that underpin incident communication. The specific four-hour and multi-stage reporting cadence under DORA is a procedural compliance obligation; Apeiris controls provide the tracking and communication framework but cannot substitute for the operational reporting process itself.", "control_count": 3, "proof_chain": [ { "control": "apeiris://compliance/controls/OB-03", "id": "OB-03", "domain": "compliance", "name": "Obligation Due Date and Milestone Tracking", "validation_objective": "Every obligation in the register that carries a regulatory, contractual, or certification deadline must have a structured due date and milestone breakdown recorded in the obligation registry, with automated early warning notifications delivered to the obligation owner and deputy at defined lead-time thresholds before the deadline. Evidence of on-time notifications and owner acknowledgments must be present for all active obligations.", "blocking_effect": "advisory", "evidence_required": [ "obligation_deadline_record per obligation showing due_date, milestone_breakdown (array of milestone names and target dates), and lead_time_thresholds (e.g., 30-day, 14-day, 7-day)", "notification_delivery_log confirming automated alerts were dispatched to owner and deputy at each configured lead-time threshold, with dispatch timestamps and delivery confirmation", "owner_acknowledgment_record confirming each threshold notification was acknowledged by the owner or deputy within the defined response window", "milestone_completion_log showing each milestone's actual completion date versus planned date for all active obligations with deadlines within the current reporting cycle" ], "evidence": [ { "id": "OB-03-E1", "description": "obligation_deadline_record per obligation showing due_date, milestone_breakdown (array of milestone names and target dates), and lead_time_thresholds (e.g., 30-day, 14-day, 7-day)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OB-03-E2", "description": "notification_delivery_log confirming automated alerts were dispatched to owner and deputy at each configured lead-time threshold, with dispatch timestamps and delivery confirmation", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "OB-03-E3", "description": "owner_acknowledgment_record confirming each threshold notification was acknowledged by the owner or deputy within the defined response window", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OB-03-E4", "description": "milestone_completion_log showing each milestone's actual completion date versus planned date for all active obligations with deadlines within the current reporting cycle", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://compliance/controls/OB-05", "id": "OB-05", "domain": "compliance", "name": "DORA ICT Obligation Tracking", "validation_objective": "Financial entities subject to DORA must have a structured obligation tracking record for all ICT-related obligations across DORA's five pillars, with alert thresholds calibrated to DORA's statutory reporting windows: initial major ICT incident notification within 4 hours of classification and no later than 24 hours from awareness, with intermediate and final reports tracked to their statutory windows. Evidence of on-time alert dispatch for any ICT incident classified as major must be present in the obligation tracking system.", "blocking_effect": "advisory", "evidence_required": [ "dora_obligation_register record per financial entity showing all five pillar obligation inventories (ICT risk management, incident reporting, resilience testing, third-party risk, information sharing) with owner assignments and fulfillment status", "ict_incident_classification_log showing each incident's classification event timestamp, major_incident boolean, and the triggered notification workflow initiation timestamp confirming the 4-hour window was met", "dora_incident_notification_record showing initial notification dispatched to the competent authority within 4 hours of classification and no later than 24 hours from awareness, with dispatch timestamp and submission confirmation", "resilience_testing_schedule showing DORA-compliant testing plan (including TLPT where applicable) with completion dates and test results reports" ], "evidence": [ { "id": "OB-05-E1", "description": "dora_obligation_register record per financial entity showing all five pillar obligation inventories (ICT risk management, incident reporting, resilience testing, third-party risk, information sharing) with owner assignments and fulfillment status", "evidence_type": "third-party-audit-report", "verification": "third-party" }, { "id": "OB-05-E2", "description": "ict_incident_classification_log showing each incident's classification event timestamp, major_incident boolean, and the triggered notification workflow initiation timestamp confirming the 4-hour window was met", "evidence_type": "incident-record", "verification": "attested" }, { "id": "OB-05-E3", "description": "dora_incident_notification_record showing initial notification dispatched to the competent authority within 4 hours of classification and no later than 24 hours from awareness, with dispatch timestamp and submission confirmation", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OB-05-E4", "description": "resilience_testing_schedule showing DORA-compliant testing plan (including TLPT where applicable) with completion dates and test results reports", "evidence_type": "automated-test-result", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://resilience/controls/RO-04", "id": "RO-04", "domain": "resilience", "name": "Recovery Operations Communication Protocol", "validation_objective": "A documented recovery communication matrix exists covering all five stakeholder tiers with defined trigger conditions, maximum initial notification windows, update intervals, assigned sender roles, communication channels, and pre-approved message templates; mandatory regulatory notification windows for all applicable jurisdictions are captured with automated pre-deadline alerts configured; and the communication protocol has been validated through a drill at least once in the preceding 12 months.", "blocking_effect": "requires-review", "evidence_required": [ "communication_matrix_document covering all five notification tiers (technical responders, engineering management, executive leadership, customer/partner contacts, regulatory authorities) with: trigger condition, maximum initial notification window, update interval, communication channel, and named sender role for each tier", "regulatory_notification_register listing all applicable jurisdictions, their mandatory incident notification windows, and evidence that automated pre-deadline alerts are configured and have been tested", "incident_communication_audit_log for a sample of past Sev-1 incidents showing notification timestamps per tier, confirming all timestamps fall within defined SLA windows", "communication_drill_record from at least one BCP exercise in the last 12 months showing that all stakeholder tiers received communications within their defined windows during the simulated exercise" ], "evidence": [ { "id": "RO-04-E1", "description": "communication_matrix_document covering all five notification tiers (technical responders, engineering management, executive leadership, customer/partner contacts, regulatory authorities) with: trigger condition, maximum initial notification window, update interval, communication channel, and named sender role for each tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RO-04-E2", "description": "regulatory_notification_register listing all applicable jurisdictions, their mandatory incident notification windows, and evidence that automated pre-deadline alerts are configured and have been tested", "evidence_type": "incident-record", "verification": "attested" }, { "id": "RO-04-E3", "description": "incident_communication_audit_log for a sample of past Sev-1 incidents showing notification timestamps per tier, confirming all timestamps fall within defined SLA windows", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RO-04-E4", "description": "communication_drill_record from at least one BCP exercise in the last 12 months showing that all stakeholder tiers received communications within their defined windows during the simulated exercise", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU DORA Article 19 imposes mandatory reporting of major ICT-related incidents on financial entities; under the incident-reporting technical standards, the initial notification is due within 4 hours of classifying an incident as major, and no later than 24 hours after becoming aware of it. This control's regulatory notification register and automated alerts ensure organizations know their deadlines and are warned before breaching them." } ] }, { "requirement_id": "DORA-ART24-01", "section": "Art. 24(1)", "title": "Digital Operational Resilience Testing Programme", "text": "Financial entities shall establish, maintain, and review a sound and comprehensive digital operational resilience testing programme as an integral part of the ICT risk management framework, with tests performed at least annually across ICT systems including AI systems.", "verdict": "supported", "coverage": "direct", "notes": "RV-02 is the resilience control verification testing program directly aligned to DORA's testing mandate; CI-01 governs the broader compliance control testing program; RP-07 mandates recovery plan testing and tabletop exercises; RG-07 tracks resilience program metrics and board reporting for the testing programme. These controls directly satisfy DORA's annual digital operational resilience testing requirement for AI systems.", "control_count": 4, "proof_chain": [ { "control": "apeiris://resilience/controls/RV-02", "id": "RV-02", "domain": "resilience", "name": "Resilience Control Verification Testing", "validation_objective": "All resilience controls protecting each production AI system must have been executed against their defined test scenarios within the scheduled testing interval, with pass/fail results recorded per control and all identified failures tracked to a remediation item with an assigned owner and resolution deadline.", "blocking_effect": "requires-review", "evidence_required": [ "resilience_testing_register with control_id, ai_system_id, test_scenario, execution_date, pass_fail_status, and evidence_summary for each control within the current testing interval", "remediation_log with control_id, failure_description, assigned_owner, deadline, and resolution_date for every control that failed its most recent test", "test_schedule_document listing each control's required test frequency and confirming no gaps exceed the prescribed interval", "retest_record confirming each remediated control was retested within 30 days of remediation closure and passed" ], "evidence": [ { "id": "RV-02-E1", "description": "resilience_testing_register with control_id, ai_system_id, test_scenario, execution_date, pass_fail_status, and evidence_summary for each control within the current testing interval", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RV-02-E2", "description": "remediation_log with control_id, failure_description, assigned_owner, deadline, and resolution_date for every control that failed its most recent test", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "RV-02-E3", "description": "test_schedule_document listing each control's required test frequency and confirming no gaps exceed the prescribed interval", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "RV-02-E4", "description": "retest_record confirming each remediated control was retested within 30 days of remediation closure and passed", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU DORA Article 25 mandates that financial entities test their ICT continuity and recovery capabilities at least annually, with advanced testing requirements for significant entities. AI systems that support critical financial functions must meet these legally binding testing obligations." }, { "control": "apeiris://compliance/controls/CI-01", "id": "CI-01", "domain": "compliance", "name": "Compliance Control Testing Program", "validation_objective": "Every AI compliance control designated as active in the compliance program must have at least one documented test executed within its defined testing frequency cycle, with the test result recorded as pass/fail/exception and all exception items linked to an open remediation record. No compliance control may have lapsed testing (last_tested_at exceeding the defined test frequency) without an approved deferral record.", "blocking_effect": "requires-review", "evidence_required": [ "control_test_plan documenting each active compliance control with test_id, test_frequency, test_method, and responsible_tester", "test_execution_record for each completed test including control_id, test_id, execution_date, result (pass/fail/exception), tester_id, and methodology_notes", "exception_register linking each test exception to a remediation_record with owner_id, target_completion_date, and current_status", "testing_calendar showing scheduled test dates for all active controls across the forward 12-month period", "management_attestation signed by the compliance officer confirming the testing program scope and execution status as of the attestation date" ], "evidence": [ { "id": "CI-01-E1", "description": "control_test_plan documenting each active compliance control with test_id, test_frequency, test_method, and responsible_tester", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-01-E2", "description": "test_execution_record for each completed test including control_id, test_id, execution_date, result (pass/fail/exception), tester_id, and methodology_notes", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "CI-01-E3", "description": "exception_register linking each test exception to a remediation_record with owner_id, target_completion_date, and current_status", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "CI-01-E4", "description": "testing_calendar showing scheduled test dates for all active controls across the forward 12-month period", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "CI-01-E5", "description": "management_attestation signed by the compliance officer confirming the testing program scope and execution status as of the attestation date", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://resilience/controls/RP-07", "id": "RP-07", "domain": "resilience", "name": "Recovery Plan Testing and Tabletop Exercises", "validation_objective": "All tier-1 AI systems have documented evidence of at least one tabletop exercise in the preceding 12 months, with exercise records containing AI-specific failure scenarios, multi-stakeholder participation, and a closed after-action report with critical remediation items resolved within 60 days of exercise completion.", "blocking_effect": "requires-review", "evidence_required": [ "exercise_schedule_record showing an annual calendar with at least one tabletop exercise per tier-1 AI system, signed by the Business Continuity Manager", "tabletop_exercise_record per covered system containing scenario inject cards, participant attendance list (AI system owner, recovery team, and business stakeholder), and structured facilitation notes", "after_action_report per exercise documenting identified gaps, assigned remediation owners, and deadlines not exceeding 60 days for critical findings", "plan_update_acknowledgment confirming recovery plan documentation was updated within 30 days of each exercise completion" ], "evidence": [ { "id": "RP-07-E1", "description": "exercise_schedule_record showing an annual calendar with at least one tabletop exercise per tier-1 AI system, signed by the Business Continuity Manager", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RP-07-E2", "description": "tabletop_exercise_record per covered system containing scenario inject cards, participant attendance list (AI system owner, recovery team, and business stakeholder), and structured facilitation notes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RP-07-E3", "description": "after_action_report per exercise documenting identified gaps, assigned remediation owners, and deadlines not exceeding 60 days for critical findings", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RP-07-E4", "description": "plan_update_acknowledgment confirming recovery plan documentation was updated within 30 days of each exercise completion", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU DORA Article 26 requires financial entities to conduct advanced ICT risk testing including threat-led penetration testing and recovery exercises. AI system recovery tabletop exercises satisfy the exercise requirement for systems below the advanced testing threshold and contribute to DORA compliance evidence." }, { "control": "apeiris://resilience/controls/RG-07", "id": "RG-07", "domain": "resilience", "name": "Resilience Program Metrics and Board Reporting", "validation_objective": "The resilience program must produce a quarterly metrics dashboard delivered to the Resilience Steering Committee within 30 days of each quarter end covering all five required metric categories with documented targets and trend data, and an annual board resilience report acknowledged by the board or audit committee within the required cycle.", "blocking_effect": "advisory", "evidence_required": [ "Quarterly resilience metrics dashboards for all four quarters in the review period with delivery timestamps confirming receipt by the Resilience Steering Committee within 30 days of quarter end", "Metrics register with documented target values, measurement methodology, and named metric owner for each of the five required metric categories (RTO/RPO compliance rate, recovery test pass rate, AI system resilience coverage, MTTR by tier, Severity 1 incident frequency)", "Annual board resilience report with Resilience Steering Committee approval date preceding board submission, and board or audit committee acknowledgment record", "Source data records (test execution logs, incident records) cross-referenceable against at least two sampled quarters of reported dashboard values to verify metric accuracy", "Evidence that metrics outside target range in any quarter have associated management commentary and governance discussion record in the Resilience Steering Committee minutes" ], "evidence": [ { "id": "RG-07-E1", "description": "Quarterly resilience metrics dashboards for all four quarters in the review period with delivery timestamps confirming receipt by the Resilience Steering Committee within 30 days of quarter end", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RG-07-E2", "description": "Metrics register with documented target values, measurement methodology, and named metric owner for each of the five required metric categories (RTO/RPO compliance rate, recovery test pass rate, AI system resilience coverage, MTTR by tier, Severity 1 incident frequency)", "evidence_type": "incident-record", "verification": "attested" }, { "id": "RG-07-E3", "description": "Annual board resilience report with Resilience Steering Committee approval date preceding board submission, and board or audit committee acknowledgment record", "evidence_type": "human-review-record", "verification": "human" }, { "id": "RG-07-E4", "description": "Source data records (test execution logs, incident records) cross-referenceable against at least two sampled quarters of reported dashboard values to verify metric accuracy", "evidence_type": "incident-record", "verification": "attested" }, { "id": "RG-07-E5", "description": "Evidence that metrics outside target range in any quarter have associated management commentary and governance discussion record in the Resilience Steering Committee minutes", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU DORA Article 6(5) requires the ICT risk management framework to be documented, reviewed at least yearly (and upon major incidents or supervisory instruction) and continuously improved, with a report on the review available to the competent authority on request. Board-level resilience metrics reporting is how the management body exercises that review in practice (Article 6(8) defines the digital operational resilience strategy itself)." } ] }, { "requirement_id": "DORA-ART25-01", "section": "Art. 25(1)", "title": "ICT Tools and Systems Testing Scope Including AI Inference", "text": "Financial entities shall perform a range of assessments and tests including vulnerability assessments and scans, source code reviews, network security assessments, scenario-based tests, and performance tests covering all ICT assets including AI inference systems and decision pipelines.", "verdict": "supported", "coverage": "direct", "notes": "RV-02 provides resilience control verification testing covering AI system components; RV-03 mandates chaos engineering for AI systems to probe failure modes; FO-07 requires fault tolerance test coverage including edge cases and degraded modes; AS-02 performs static analysis of agent skills and manifests in CI. Together these controls map to the DORA multi-method test scope requirement as applied to AI inference and decision systems.", "control_count": 4, "proof_chain": [ { "control": "apeiris://resilience/controls/RV-02", "id": "RV-02", "domain": "resilience", "name": "Resilience Control Verification Testing", "validation_objective": "All resilience controls protecting each production AI system must have been executed against their defined test scenarios within the scheduled testing interval, with pass/fail results recorded per control and all identified failures tracked to a remediation item with an assigned owner and resolution deadline.", "blocking_effect": "requires-review", "evidence_required": [ "resilience_testing_register with control_id, ai_system_id, test_scenario, execution_date, pass_fail_status, and evidence_summary for each control within the current testing interval", "remediation_log with control_id, failure_description, assigned_owner, deadline, and resolution_date for every control that failed its most recent test", "test_schedule_document listing each control's required test frequency and confirming no gaps exceed the prescribed interval", "retest_record confirming each remediated control was retested within 30 days of remediation closure and passed" ], "evidence": [ { "id": "RV-02-E1", "description": "resilience_testing_register with control_id, ai_system_id, test_scenario, execution_date, pass_fail_status, and evidence_summary for each control within the current testing interval", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RV-02-E2", "description": "remediation_log with control_id, failure_description, assigned_owner, deadline, and resolution_date for every control that failed its most recent test", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "RV-02-E3", "description": "test_schedule_document listing each control's required test frequency and confirming no gaps exceed the prescribed interval", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "RV-02-E4", "description": "retest_record confirming each remediated control was retested within 30 days of remediation closure and passed", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU DORA Article 25 mandates that financial entities test their ICT continuity and recovery capabilities at least annually, with advanced testing requirements for significant entities. AI systems that support critical financial functions must meet these legally binding testing obligations." }, { "control": "apeiris://resilience/controls/RV-03", "id": "RV-03", "domain": "resilience", "name": "Chaos Engineering for AI Systems", "validation_objective": "The AI system must have an active chaos engineering program with at least one executed experiment per prioritized failure mode class, documented hypothesis-to-outcome records for each experiment, and tracked action items for every deviation from expected behavior that was discovered.", "blocking_effect": "advisory", "evidence_required": [ "chaos_experiment_log with experiment_id, ai_system_id, fault_class, hypothesis, execution_date, environment (staging|production), steady_state_deviation_observed, and outcome_vs_hypothesis for each experiment", "fault_injection_library listing all fault classes covered (model_api_latency, dependency_shutdown, network_partition, resource_exhaustion, malformed_input) and the date each class was last exercised", "experiment_action_item_register with experiment_id, deviation_description, owner, and resolution_deadline for each finding where behavior deviated from hypothesis", "steady_state_baseline_document defining the metrics and thresholds used to evaluate each experiment's outcome" ], "evidence": [ { "id": "RV-03-E1", "description": "chaos_experiment_log with experiment_id, ai_system_id, fault_class, hypothesis, execution_date, environment (staging|production), steady_state_deviation_observed, and outcome_vs_hypothesis for each experiment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RV-03-E2", "description": "fault_injection_library listing all fault classes covered (model_api_latency, dependency_shutdown, network_partition, resource_exhaustion, malformed_input) and the date each class was last exercised", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RV-03-E3", "description": "experiment_action_item_register with experiment_id, deviation_description, owner, and resolution_deadline for each finding where behavior deviated from hypothesis", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RV-03-E4", "description": "steady_state_baseline_document defining the metrics and thresholds used to evaluate each experiment's outcome", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU DORA Article 26 requires advanced ICT resilience testing including threat-led penetration testing for significant financial entities. Chaos engineering provides the technical depth required to satisfy the spirit of advanced resilience testing obligations, particularly for AI systems in critical financial functions." }, { "control": "apeiris://resilience/controls/FO-07", "id": "FO-07", "domain": "resilience", "name": "Fault Tolerance Test Coverage", "validation_objective": "Every fault tolerance mechanism deployed in the AI system must have at least one executed test case that exercises it under a realistic failure condition, and the aggregate test suite must achieve the documented fault_coverage_target with no failure mode from the threat model remaining untested. Test results must be recorded and traceable by mechanism ID.", "blocking_effect": "blocks-deployment", "evidence_required": [ "fault_coverage_matrix mapping each deployed fault tolerance mechanism to at least one test case with fields test_id, failure_condition_injected, mechanism_under_test, and pass_fail outcome", "chaos_experiment_run_record for each experiment showing target_component, failure_type, blast_radius_actual, steady_state_metric_before, and steady_state_metric_after", "game_day_report with scenario_narrative, expected_behavior, observed_behavior, and delta_actions_required for each conducted exercise", "fault_injection_ci_run_log from the CI/CD pipeline showing automated fault injection test execution and pass/fail result per deployment artifact", "remediation_tracking_record for any test-discovered gaps with status, owner, and target_resolution_date" ], "evidence": [ { "id": "FO-07-E1", "description": "fault_coverage_matrix mapping each deployed fault tolerance mechanism to at least one test case with fields test_id, failure_condition_injected, mechanism_under_test, and pass_fail outcome", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "FO-07-E2", "description": "chaos_experiment_run_record for each experiment showing target_component, failure_type, blast_radius_actual, steady_state_metric_before, and steady_state_metric_after", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FO-07-E3", "description": "game_day_report with scenario_narrative, expected_behavior, observed_behavior, and delta_actions_required for each conducted exercise", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FO-07-E4", "description": "fault_injection_ci_run_log from the CI/CD pipeline showing automated fault injection test execution and pass/fail result per deployment artifact", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "FO-07-E5", "description": "remediation_tracking_record for any test-discovered gaps with status, owner, and target_resolution_date", "evidence_type": "automated-test-result", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "EU DORA Article 26 requires advanced testing by way of threat-led penetration testing on critical live systems for significant financial entities. Comprehensive fault-injection coverage of critical AI systems is the operational-resilience counterpart such advanced testing programs build on (baseline digital operational resilience testing obligations sit in Articles 24-25)." }, { "control": "apeiris://security/controls/AS-02", "id": "AS-02", "domain": "security", "name": "Statically analyze agent skills and manifests in CI", "validation_objective": "Every agent skill artifact and its associated manifest must be scanned in CI with SAST and dependency review before any merge to main or deployment branch, and the build must be blocked \u2014 not warned \u2014 on any high-severity finding. No skill or plug-in may reach production without a passing CI scan gate record linked to its commit SHA.", "blocking_effect": "blocks-deployment", "evidence_required": [ "ci_scan_report in SARIF format for each skill change, including commit SHA, scan tool name and version, finding severity counts, and gate decision (pass/fail)", "manifest_scan_result confirming the skill manifest was validated for schema compliance and absence of unsafe or over-privileged permission declarations", "dependency_review_log showing all third-party dependencies checked against a known-vulnerability database with any high-severity CVEs identified and their disposition", "build_gate_configuration_record confirming the CI pipeline is set to fail (not warn) on high-severity findings, with timestamp of the most recent configuration review", "integration_validation_report listing each registered tool endpoint, the synthetic payload used, response status, schema conformance result, auth flow outcome, and signed gate decision (pass/fail) for the current release candidate" ], "evidence": [ { "id": "AS-02-E1", "description": "ci_scan_report in SARIF format for each skill change, including commit SHA, scan tool name and version, finding severity counts, and gate decision (pass/fail)", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "AS-02-E2", "description": "manifest_scan_result confirming the skill manifest was validated for schema compliance and absence of unsafe or over-privileged permission declarations", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "AS-02-E3", "description": "dependency_review_log showing all third-party dependencies checked against a known-vulnerability database with any high-severity CVEs identified and their disposition", "evidence_type": "third-party-audit-report", "verification": "third-party" }, { "id": "AS-02-E4", "description": "build_gate_configuration_record confirming the CI pipeline is set to fail (not warn) on high-severity findings, with timestamp of the most recent configuration review", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "AS-02-E5", "description": "integration_validation_report listing each registered tool endpoint, the synthetic payload used, response status, schema conformance result, auth flow outcome, and signed gate decision (pass/fail) for the current release candidate", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "DORA-ART26-01", "section": "Art. 26(1)", "title": "Threat-Led Penetration Testing (TLPT) Programme", "text": "Financial entities identified by competent authorities shall carry out threat-led penetration testing at least every three years. TLPT shall cover production systems including AI systems used in critical or important functions.", "verdict": "supported", "coverage": "direct", "notes": "AS-01 mandates adversarial red-teaming and evaluation of AI agents before launch; AS-03 gates releases on continuous adversarial validation; RT-06 maps AI-native threats and extends ATT&CK/ATLAS to agentic orchestration (threat modelling for TLPT scope); AS-04 governs a bug-bounty and vulnerability reward program for agentic systems. These controls directly implement the DORA TLPT requirement framework as applied to AI systems in critical financial functions.", "control_count": 4, "proof_chain": [ { "control": "apeiris://security/controls/AS-01", "id": "AS-01", "domain": "security", "name": "Adversarially red-team and evaluate the agent before launch", "validation_objective": "Before any deployment to production, the agent must have passed a structured adversarial red-team exercise covering multi-turn goal hijack, tool misuse, and data exfiltration scenarios, with measured attack-success-rates at or below the defined launch threshold. Deployment must be blocked until the red-team pass/fail gate is cleared and documented.", "blocking_effect": "blocks-deployment", "evidence_required": [ "pre_launch_red_team_report listing each scenario (multi-turn hijack, tool-misuse, exfiltration), the attack-success-rate per scenario, the defined launch threshold, and a signed go/no-go decision", "multi_turn_eval_suite_run_log showing the agentic benchmark used (e.g., AgentDojo, FinBot CTF), commit SHA, run date, and overall pass/fail outcome against the threshold", "red_team_scope_document confirming coverage of multi-turn drift scenarios not only single-prompt tests, signed before the red-team exercise begins", "launch_gate_approval_record linking the red-team report to the deployment decision with approver identity and timestamp" ], "evidence": [ { "id": "AS-01-E1", "description": "pre_launch_red_team_report listing each scenario (multi-turn hijack, tool-misuse, exfiltration), the attack-success-rate per scenario, the defined launch threshold, and a signed go/no-go decision", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AS-01-E2", "description": "multi_turn_eval_suite_run_log showing the agentic benchmark used (e.g., AgentDojo, FinBot CTF), commit SHA, run date, and overall pass/fail outcome against the threshold", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "AS-01-E3", "description": "red_team_scope_document confirming coverage of multi-turn drift scenarios not only single-prompt tests, signed before the red-team exercise begins", "evidence_type": "red-team-report", "verification": "third-party" }, { "id": "AS-01-E4", "description": "launch_gate_approval_record linking the red-team report to the deployment decision with approver identity and timestamp", "evidence_type": "red-team-report", "verification": "third-party" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://security/controls/AS-03", "id": "AS-03", "domain": "security", "name": "Gate releases on continuous adversarial validation", "validation_objective": "Every production release of the agent must pass an adversarial validation suite compared against the established safety baseline, with any regression in attack-success-rate or safety metric blocking deployment before it reaches production. The gate must execute on code changes AND on model version, routing, or system-prompt changes.", "blocking_effect": "blocks-deployment", "evidence_required": [ "release_gate_eval_report for each deployment showing evaluation suite name, run date, baseline metric values, current metric values, regression flags, and go/no-go decision", "baseline_snapshot_record confirming the safety baseline version and content hash against which the current release was compared", "release_trigger_log confirming the gate was invoked for model version, routing, and system-prompt changes as well as code changes", "regression_block_record for any release where a safety regression was detected, including the blocking metric, severity classification, and remediation steps taken before re-release" ], "evidence": [ { "id": "AS-03-E1", "description": "release_gate_eval_report for each deployment showing evaluation suite name, run date, baseline metric values, current metric values, regression flags, and go/no-go decision", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "AS-03-E2", "description": "baseline_snapshot_record confirming the safety baseline version and content hash against which the current release was compared", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AS-03-E3", "description": "release_trigger_log confirming the gate was invoked for model version, routing, and system-prompt changes as well as code changes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AS-03-E4", "description": "regression_block_record for any release where a safety regression was detected, including the blocking metric, severity classification, and remediation steps taken before re-release", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://security/controls/RT-06", "id": "RT-06", "domain": "security", "name": "Map AI-native threats, extend ATT&CK/ATLAS to agentic orchestration", "validation_objective": "The organization's threat model must reference current MITRE ATLAS agentic technique IDs and explicitly label autonomous-orchestration and real-time-pivot behaviors lacking standard IDs as custom extensions. Risk scoring must use an additive model (Threat + Vulnerability + Impact) that keeps partial attack-enablement signals visible and does not zero them out, and the threat model must be updated whenever ATLAS publishes new agentic technique IDs.", "blocking_effect": "advisory", "evidence_required": [ "threat_model_document referencing current ATLAS agentic technique IDs (including AML.T0053, AML.T0070, AML.T0080, AML.T0104) with verification date against atlas.mitre.org", "agentic_orchestration_extension_record listing custom internal IDs for autonomous killchain orchestration and real-time pivot decisioning behaviors not yet codified in ATLAS, each labeled as an internal extension", "additive_risk_scoring_formula_document showing Threat + Vulnerability + Impact calculation with evidence that no multiplicative step can zero out a partial-enablement score", "threat_model_review_record showing the last update date and trigger (new ATLAS ID publication, observed attack, or scheduled review cycle)" ], "evidence": [ { "id": "RT-06-E1", "description": "threat_model_document referencing current ATLAS agentic technique IDs (including AML.T0053, AML.T0070, AML.T0080, AML.T0104) with verification date against atlas.mitre.org", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-06-E2", "description": "agentic_orchestration_extension_record listing custom internal IDs for autonomous killchain orchestration and real-time pivot decisioning behaviors not yet codified in ATLAS, each labeled as an internal extension", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-06-E3", "description": "additive_risk_scoring_formula_document showing Threat + Vulnerability + Impact calculation with evidence that no multiplicative step can zero out a partial-enablement score", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-06-E4", "description": "threat_model_review_record showing the last update date and trigger (new ATLAS ID publication, observed attack, or scheduled review cycle)", "evidence_type": "human-review-record", "verification": "human" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://security/controls/AS-04", "id": "AS-04", "domain": "security", "name": "Run a bug-bounty / vulnerability reward program for agentic abuse", "validation_objective": "An externally accessible bug-bounty program must exist with a published scope that explicitly includes agentic-abuse vectors \u2014 prompt injection hijack, unauthorized data exfiltration, and harmful autonomous actions \u2014 and validated findings from that program must be traced to control improvements or AS-01 red-team scenario additions within a defined remediation SLA.", "blocking_effect": "advisory", "evidence_required": [ "bug_bounty_scope_document publicly accessible and explicitly listing agentic abuse categories (prompt injection, goal hijack, exfiltration, harmful autonomous action) as in-scope with severity guidance", "agentic_abuse_report_log listing researcher-submitted reports categorized as agentic abuse with triage status, severity score, and remediation outcome per report", "control_update_trace linking at least one validated agentic-abuse bounty finding to a specific control improvement or AS-01 red-team scenario addition in the trailing 12 months", "bounty_payout_record evidencing active researcher engagement with at least one agentic-specific payout in the trailing 12 months" ], "evidence": [ { "id": "AS-04-E1", "description": "bug_bounty_scope_document publicly accessible and explicitly listing agentic abuse categories (prompt injection, goal hijack, exfiltration, harmful autonomous action) as in-scope with severity guidance", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AS-04-E2", "description": "agentic_abuse_report_log listing researcher-submitted reports categorized as agentic abuse with triage status, severity score, and remediation outcome per report", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AS-04-E3", "description": "control_update_trace linking at least one validated agentic-abuse bounty finding to a specific control improvement or AS-01 red-team scenario addition in the trailing 12 months", "evidence_type": "red-team-report", "verification": "third-party" }, { "id": "AS-04-E4", "description": "bounty_payout_record evidencing active researcher engagement with at least one agentic-specific payout in the trailing 12 months", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "DORA-ART26-02", "section": "Art. 26(3)", "title": "TLPT Scope Determination for AI and Critical ICT Systems", "text": "The TLPT scope shall encompass several critical or important functions and shall be conducted on live production systems, including AI systems and model inference endpoints that support critical financial services.", "verdict": "supported", "coverage": "direct", "notes": "AS-01 defines the adversarial red-team scope and methodology for AI production systems; AS-05 requires studying frontier offensive capability before public release (informing TLPT scope); RT-06 maps AI-native attack surfaces including agentic orchestration threat models that define TLPT scope boundaries. These controls directly support DORA's production TLPT scope determination for AI systems.", "control_count": 3, "proof_chain": [ { "control": "apeiris://security/controls/AS-01", "id": "AS-01", "domain": "security", "name": "Adversarially red-team and evaluate the agent before launch", "validation_objective": "Before any deployment to production, the agent must have passed a structured adversarial red-team exercise covering multi-turn goal hijack, tool misuse, and data exfiltration scenarios, with measured attack-success-rates at or below the defined launch threshold. Deployment must be blocked until the red-team pass/fail gate is cleared and documented.", "blocking_effect": "blocks-deployment", "evidence_required": [ "pre_launch_red_team_report listing each scenario (multi-turn hijack, tool-misuse, exfiltration), the attack-success-rate per scenario, the defined launch threshold, and a signed go/no-go decision", "multi_turn_eval_suite_run_log showing the agentic benchmark used (e.g., AgentDojo, FinBot CTF), commit SHA, run date, and overall pass/fail outcome against the threshold", "red_team_scope_document confirming coverage of multi-turn drift scenarios not only single-prompt tests, signed before the red-team exercise begins", "launch_gate_approval_record linking the red-team report to the deployment decision with approver identity and timestamp" ], "evidence": [ { "id": "AS-01-E1", "description": "pre_launch_red_team_report listing each scenario (multi-turn hijack, tool-misuse, exfiltration), the attack-success-rate per scenario, the defined launch threshold, and a signed go/no-go decision", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AS-01-E2", "description": "multi_turn_eval_suite_run_log showing the agentic benchmark used (e.g., AgentDojo, FinBot CTF), commit SHA, run date, and overall pass/fail outcome against the threshold", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "AS-01-E3", "description": "red_team_scope_document confirming coverage of multi-turn drift scenarios not only single-prompt tests, signed before the red-team exercise begins", "evidence_type": "red-team-report", "verification": "third-party" }, { "id": "AS-01-E4", "description": "launch_gate_approval_record linking the red-team report to the deployment decision with approver identity and timestamp", "evidence_type": "red-team-report", "verification": "third-party" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://security/controls/AS-05", "id": "AS-05", "domain": "security", "name": "Study frontier offensive capability before public release", "validation_objective": "Before public release of any model version, a frontier offensive-capability evaluation must be completed that measures the model's ability to autonomously find and exploit vulnerabilities, and the release must be blocked unless measured capability is at or below the defined risk threshold. Each staged access expansion must be tied to specific evidence milestones against that threshold.", "blocking_effect": "blocks-deployment", "evidence_required": [ "frontier_capability_assessment_report documenting model version, evaluation methodology, offensive capability score against the defined threshold, and the release-gating decision with approver identity and date", "control_evaluation_record showing the red-team exercises used to measure vuln-finding and multi-step exploit-chaining capability, including pass/fail outcome per scenario against the tracked-risk threshold", "deployment_gate_decision_record linking the capability score to a signed go/no-go decision with the threshold definition version referenced", "staged_release_access_log showing each incremental access expansion milestone and the specific evidence that cleared each stage", "risk_threshold_definition_document specifying the acceptable offensive capability level at each deployment tier, reviewed and signed by the responsible authority before evaluation begins" ], "evidence": [ { "id": "AS-05-E1", "description": "frontier_capability_assessment_report documenting model version, evaluation methodology, offensive capability score against the defined threshold, and the release-gating decision with approver identity and date", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "AS-05-E2", "description": "control_evaluation_record showing the red-team exercises used to measure vuln-finding and multi-step exploit-chaining capability, including pass/fail outcome per scenario against the tracked-risk threshold", "evidence_type": "red-team-report", "verification": "third-party" }, { "id": "AS-05-E3", "description": "deployment_gate_decision_record linking the capability score to a signed go/no-go decision with the threshold definition version referenced", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AS-05-E4", "description": "staged_release_access_log showing each incremental access expansion milestone and the specific evidence that cleared each stage", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AS-05-E5", "description": "risk_threshold_definition_document specifying the acceptable offensive capability level at each deployment tier, reviewed and signed by the responsible authority before evaluation begins", "evidence_type": "evaluation-scorecard", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://security/controls/RT-06", "id": "RT-06", "domain": "security", "name": "Map AI-native threats, extend ATT&CK/ATLAS to agentic orchestration", "validation_objective": "The organization's threat model must reference current MITRE ATLAS agentic technique IDs and explicitly label autonomous-orchestration and real-time-pivot behaviors lacking standard IDs as custom extensions. Risk scoring must use an additive model (Threat + Vulnerability + Impact) that keeps partial attack-enablement signals visible and does not zero them out, and the threat model must be updated whenever ATLAS publishes new agentic technique IDs.", "blocking_effect": "advisory", "evidence_required": [ "threat_model_document referencing current ATLAS agentic technique IDs (including AML.T0053, AML.T0070, AML.T0080, AML.T0104) with verification date against atlas.mitre.org", "agentic_orchestration_extension_record listing custom internal IDs for autonomous killchain orchestration and real-time pivot decisioning behaviors not yet codified in ATLAS, each labeled as an internal extension", "additive_risk_scoring_formula_document showing Threat + Vulnerability + Impact calculation with evidence that no multiplicative step can zero out a partial-enablement score", "threat_model_review_record showing the last update date and trigger (new ATLAS ID publication, observed attack, or scheduled review cycle)" ], "evidence": [ { "id": "RT-06-E1", "description": "threat_model_document referencing current ATLAS agentic technique IDs (including AML.T0053, AML.T0070, AML.T0080, AML.T0104) with verification date against atlas.mitre.org", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-06-E2", "description": "agentic_orchestration_extension_record listing custom internal IDs for autonomous killchain orchestration and real-time pivot decisioning behaviors not yet codified in ATLAS, each labeled as an internal extension", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-06-E3", "description": "additive_risk_scoring_formula_document showing Threat + Vulnerability + Impact calculation with evidence that no multiplicative step can zero out a partial-enablement score", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-06-E4", "description": "threat_model_review_record showing the last update date and trigger (new ATLAS ID publication, observed attack, or scheduled review cycle)", "evidence_type": "human-review-record", "verification": "human" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "DORA-ART27-01", "section": "Art. 27(1)", "title": "Tester Independence and Qualification Requirements", "text": "Threat-led penetration testing shall be conducted by testers who possess the required expertise, skills, and independence from the financial entity. Testers shall be independent from the ICT systems being tested, including AI systems under evaluation.", "verdict": "partial", "coverage": "partial", "notes": "MV-01 establishes the independent validation function charter relevant to third-party model testing; AU-03 governs auditor access and cooperation protocols for independent assessors; AS-01 covers adversarial red-teaming methodology. Tester independence as a formal qualification and accreditation requirement under DORA's TLPT Framework (TIBER-EU) is a regulatory credentialing matter partially supported by Apeiris governance controls but not fully substitutable by them.", "control_count": 3, "proof_chain": [ { "control": "apeiris://finance/controls/MV-01", "id": "MV-01", "domain": "finance", "name": "Independent Validation Function Charter", "validation_objective": "The model validation function must be established with a board- or risk-committee-approved charter documenting organizational independence from model development and business lines, with all validation staff reporting to the CRO or an independent risk committee rather than to technology or business leadership. The charter must define scope, authority, minimum staffing levels, and escalation rights enabling validators to require model suspension.", "blocking_effect": "blocks-deployment", "evidence_required": [ "board_or_risk_committee_approved_charter document with effective date, scope statement, reporting line definition, and named escalation authority for validation override decisions", "organizational_chart confirming the validation function reporting line is separate from model development and business line management chains with no shared manager below the CRO level", "headcount_and_competency_record listing all validation function staff, their qualifications, and attestation that none hold concurrent model development responsibilities", "annual_charter_review_record documenting review date, reviewer role, findings, and any charter amendments approved by the risk committee", "validation_authority_exercise_log showing instances where the validation function raised adverse findings, suspended models, or escalated to the board" ], "evidence": [ { "id": "MV-01-E1", "description": "board_or_risk_committee_approved_charter document with effective date, scope statement, reporting line definition, and named escalation authority for validation override decisions", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MV-01-E2", "description": "organizational_chart confirming the validation function reporting line is separate from model development and business line management chains with no shared manager below the CRO level", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MV-01-E3", "description": "headcount_and_competency_record listing all validation function staff, their qualifications, and attestation that none hold concurrent model development responsibilities", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MV-01-E4", "description": "annual_charter_review_record documenting review date, reviewer role, findings, and any charter amendments approved by the risk committee", "evidence_type": "human-review-record", "verification": "human" }, { "id": "MV-01-E5", "description": "validation_authority_exercise_log showing instances where the validation function raised adverse findings, suspended models, or escalated to the board", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://compliance/controls/AU-03", "id": "AU-03", "domain": "compliance", "name": "Auditor Access and Cooperation Protocols", "validation_objective": "All regulatory and external auditor interactions during the audit period are logged in the cooperation register within 24 hours of occurrence, every document production was reviewed and approved by the audit coordinator before transmittal, and no regulatory response deadline was missed. The auditor access protocol has been reviewed within the prior 24 months and all personnel in roles likely to receive regulatory inquiries hold current training records.", "blocking_effect": "requires-review", "evidence_required": [ "Cooperation register for the audit period listing every examiner contact with contact_date, regulator_identity, contact_type, request_description, response_deadline, response_submitted_date, and document_production_id for each production made", "Document production approval log showing audit coordinator and legal counsel pre-transmittal sign-off timestamp for each document set produced to examiners during the period", "Annual simulation exercise report documenting scenario design, participants, findings, and after-action remediation items for the exercise conducted in the review year", "Protocol training completion records for all personnel in roles likely to receive direct regulatory inquiry, showing completion within the prior 12 months", "Auditor system access provisioning records for any system access granted to examiners, including access_scope, provisioning_date, provisioning_authority, and access_revocation_date" ], "evidence": [ { "id": "AU-03-E1", "description": "Cooperation register for the audit period listing every examiner contact with contact_date, regulator_identity, contact_type, request_description, response_deadline, response_submitted_date, and document_production_id for each production made", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AU-03-E2", "description": "Document production approval log showing audit coordinator and legal counsel pre-transmittal sign-off timestamp for each document set produced to examiners during the period", "evidence_type": "audit-log", "verification": "automated" }, { "id": "AU-03-E3", "description": "Annual simulation exercise report documenting scenario design, participants, findings, and after-action remediation items for the exercise conducted in the review year", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AU-03-E4", "description": "Protocol training completion records for all personnel in roles likely to receive direct regulatory inquiry, showing completion within the prior 12 months", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AU-03-E5", "description": "Auditor system access provisioning records for any system access granted to examiners, including access_scope, provisioning_date, provisioning_authority, and access_revocation_date", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://security/controls/AS-01", "id": "AS-01", "domain": "security", "name": "Adversarially red-team and evaluate the agent before launch", "validation_objective": "Before any deployment to production, the agent must have passed a structured adversarial red-team exercise covering multi-turn goal hijack, tool misuse, and data exfiltration scenarios, with measured attack-success-rates at or below the defined launch threshold. Deployment must be blocked until the red-team pass/fail gate is cleared and documented.", "blocking_effect": "blocks-deployment", "evidence_required": [ "pre_launch_red_team_report listing each scenario (multi-turn hijack, tool-misuse, exfiltration), the attack-success-rate per scenario, the defined launch threshold, and a signed go/no-go decision", "multi_turn_eval_suite_run_log showing the agentic benchmark used (e.g., AgentDojo, FinBot CTF), commit SHA, run date, and overall pass/fail outcome against the threshold", "red_team_scope_document confirming coverage of multi-turn drift scenarios not only single-prompt tests, signed before the red-team exercise begins", "launch_gate_approval_record linking the red-team report to the deployment decision with approver identity and timestamp" ], "evidence": [ { "id": "AS-01-E1", "description": "pre_launch_red_team_report listing each scenario (multi-turn hijack, tool-misuse, exfiltration), the attack-success-rate per scenario, the defined launch threshold, and a signed go/no-go decision", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AS-01-E2", "description": "multi_turn_eval_suite_run_log showing the agentic benchmark used (e.g., AgentDojo, FinBot CTF), commit SHA, run date, and overall pass/fail outcome against the threshold", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "AS-01-E3", "description": "red_team_scope_document confirming coverage of multi-turn drift scenarios not only single-prompt tests, signed before the red-team exercise begins", "evidence_type": "red-team-report", "verification": "third-party" }, { "id": "AS-01-E4", "description": "launch_gate_approval_record linking the red-team report to the deployment decision with approver identity and timestamp", "evidence_type": "red-team-report", "verification": "third-party" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "DORA-ART28-01", "section": "Art. 28(1)", "title": "ICT Third-Party Risk Management for AI Model and Data Providers", "text": "Financial entities shall manage ICT third-party risk as an integral part of their ICT risk management framework, including risk from AI model providers, data vendors, cloud AI services, and other ICT third-party service providers supporting critical functions.", "verdict": "supported", "coverage": "direct", "notes": "RV-05 performs third-party AI dependency resilience assessment; MR-06 governs third-party and vendor AI model risk management under SR 26-2 methodology; CA-07 tracks third-party and supply chain compliance obligations; RP-06 provides the third-party AI provider outage response plan. These controls directly address DORA's third-party risk management mandate for AI model and data service dependencies in financial entities.", "control_count": 4, "proof_chain": [ { "control": "apeiris://resilience/controls/RV-05", "id": "RV-05", "domain": "resilience", "name": "Third-Party AI Dependency Resilience Assessment", "validation_objective": "Every third-party AI dependency (model inference APIs, embedding services, vector database providers, data enrichment services) for each production AI system must be registered and classified, with a current resilience assessment completed within the last 12 months for all critical and high dependencies, and documented fallback architecture or formal risk acceptance for any dependency whose SLA coverage is insufficient for the AI system's recovery objectives.", "blocking_effect": "requires-review", "evidence_required": [ "third_party_ai_dependency_register with dependency_id, ai_system_id, dependency_type, criticality_classification (critical|high|standard), and sla_coverage_adequate flag for all production AI systems", "dependency_resilience_assessment per critical or high dependency within last 12 months, including sla_terms, historical_uptime_12mo_percent, incident_notification_practice, and fallback_option_evaluated", "fallback_architecture_document or risk_acceptance_record with owner_signoff for each dependency where sla_coverage_adequate=false", "synthetic_monitoring_coverage_report confirming active health checks are deployed against all critical third-party AI API endpoints" ], "evidence": [ { "id": "RV-05-E1", "description": "third_party_ai_dependency_register with dependency_id, ai_system_id, dependency_type, criticality_classification (critical|high|standard), and sla_coverage_adequate flag for all production AI systems", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RV-05-E2", "description": "dependency_resilience_assessment per critical or high dependency within last 12 months, including sla_terms, historical_uptime_12mo_percent, incident_notification_practice, and fallback_option_evaluated", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RV-05-E3", "description": "fallback_architecture_document or risk_acceptance_record with owner_signoff for each dependency where sla_coverage_adequate=false", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RV-05-E4", "description": "synthetic_monitoring_coverage_report confirming active health checks are deployed against all critical third-party AI API endpoints", "evidence_type": "third-party-audit-report", "verification": "third-party" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU DORA Articles 28 through 30 establish binding requirements for ICT third-party risk management including pre-contract due diligence, contractual provisions, and ongoing monitoring of critical ICT third-party service providers. AI model API providers and cloud inference services used by financial entities fall within this scope." }, { "control": "apeiris://finance/controls/MR-06", "id": "MR-06", "domain": "finance", "name": "Third-Party and Vendor AI Model Risk Management", "validation_objective": "All third-party vendor AI models used in material financial decisions must be registered in the model inventory with a completed MRM due diligence record; contractual provisions for change notification and validation support must be confirmed in place for all material vendor models; and compensating controls must be documented and technically operational for opaque vendor models where direct validation access is unavailable.", "blocking_effect": "requires-review", "evidence_required": [ "third_party_model_inventory_record for each vendor AI model showing vendor_name, model_version, api_endpoint, risk_tier, due_diligence_status, and contract_review_date", "vendor_due_diligence_checklist_completed covering model documentation quality, validation evidence provided, bias and fairness testing results, EU AI Act conformity documentation, and change notification process assessment", "vendor_ai_contract_review_record confirming presence of change_notification_clause, audit_rights_clause, and data_residency_requirements for each material vendor model contract", "compensating_control_documentation for opaque vendor models showing output_validation_layer_design, shadow_model_comparison_methodology, and human_review_threshold_definitions", "vendor_change_notification_log recording all received vendor model update notifications with linked mrm_impact_assessment_records showing assessment_date within 5 business days of notification_date" ], "evidence": [ { "id": "MR-06-E1", "description": "third_party_model_inventory_record for each vendor AI model showing vendor_name, model_version, api_endpoint, risk_tier, due_diligence_status, and contract_review_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-06-E2", "description": "vendor_due_diligence_checklist_completed covering model documentation quality, validation evidence provided, bias and fairness testing results, EU AI Act conformity documentation, and change notification process assessment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-06-E3", "description": "vendor_ai_contract_review_record confirming presence of change_notification_clause, audit_rights_clause, and data_residency_requirements for each material vendor model contract", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-06-E4", "description": "compensating_control_documentation for opaque vendor models showing output_validation_layer_design, shadow_model_comparison_methodology, and human_review_threshold_definitions", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-06-E5", "description": "vendor_change_notification_log recording all received vendor model update notifications with linked mrm_impact_assessment_records showing assessment_date within 5 business days of notification_date", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://compliance/controls/CA-07", "id": "CA-07", "domain": "compliance", "name": "Third-Party and Supply Chain Compliance Obligations", "validation_objective": "Every supply chain participant for each AI system in scope must have an entry in the third-party compliance obligation register documenting all flowing obligations and a corresponding executed binding contractual instrument containing audit rights, with third-party compliance attestations collected within the defined refresh cycle and incorporated into the CA-03 routing table as evidence inputs.", "blocking_effect": "blocks-deployment", "evidence_required": [ "third_party_compliance_obligation_register entries for each supply chain participant containing vendor_id, vendor_role, applicable_obligations[], contract_instrument_id, contract_execution_date, and next_attestation_due_date", "executed_contract_inventory for each supply chain participant showing contract_type (DPA, EU_AI_Act_compliance_schedule, supplier_agreement), execution_date, audit_rights_clause_present=true, and sub_processor_management_clause_present=true for data processors", "third_party_attestation_collection_log showing each attestation collected with collection_date, valid_until, attesting_entity_name, attestation_scope, and the CA-03 routing_table_entry_id that references it", "service_dependency_map for each AI system listing all integrated third-party APIs, model providers, and data services cross-referenced against the obligation register to confirm no vendor is absent from the register" ], "evidence": [ { "id": "CA-07-E1", "description": "third_party_compliance_obligation_register entries for each supply chain participant containing vendor_id, vendor_role, applicable_obligations[], contract_instrument_id, contract_execution_date, and next_attestation_due_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-07-E2", "description": "executed_contract_inventory for each supply chain participant showing contract_type (DPA, EU_AI_Act_compliance_schedule, supplier_agreement), execution_date, audit_rights_clause_present=true, and sub_processor_management_clause_present=true for data processors", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-07-E3", "description": "third_party_attestation_collection_log showing each attestation collected with collection_date, valid_until, attesting_entity_name, attestation_scope, and the CA-03 routing_table_entry_id that references it", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-07-E4", "description": "service_dependency_map for each AI system listing all integrated third-party APIs, model providers, and data services cross-referenced against the obligation register to confirm no vendor is absent from the register", "evidence_type": "third-party-audit-report", "verification": "third-party" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://resilience/controls/RP-06", "id": "RP-06", "domain": "resilience", "name": "Third-Party AI Provider Outage Response Plan", "validation_objective": "For every AI system that depends on an external model API provider, a documented provider outage contingency plan must exist specifying quantitative activation criteria, fallback routing or graceful degradation procedures for each tier of provider unavailability, stakeholder communication templates, and evidence that the plan has been validated through at least one tabletop exercise covering a multi-hour primary provider outage scenario within the past 12 months.", "blocking_effect": "requires-review", "evidence_required": [ "Provider outage contingency plan document per AI system showing activation trigger criteria (e.g., provider API error rate > X% for Y minutes), fallback routing configuration or graceful degradation procedures per outage tier, and stakeholder communication templates for internal and customer-facing audiences", "Fallback routing or alternative provider configuration evidence showing the fallback endpoint, credentials, and rate limit are in place, tested, and producing acceptable outputs for the AI system's use case", "Tabletop exercise record from within the last 12 months covering at least one scenario of primary provider unavailability lasting more than four hours with no estimated restoration time, including plan activation decision, fallback routing execution, and stakeholder communication steps", "Provider incident notification subscription record confirming the organization receives real-time status alerts from each critical external AI API provider via status page webhook or email", "Post-exercise action item list with owners and resolution status, confirming findings from the tabletop are tracked to remediation" ], "evidence": [ { "id": "RP-06-E1", "description": "Provider outage contingency plan document per AI system showing activation trigger criteria (e.g., provider API error rate > X% for Y minutes), fallback routing configuration or graceful degradation procedures per outage tier, and stakeholder communication templates for internal and customer-facing audiences", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "RP-06-E2", "description": "Fallback routing or alternative provider configuration evidence showing the fallback endpoint, credentials, and rate limit are in place, tested, and producing acceptable outputs for the AI system's use case", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "RP-06-E3", "description": "Tabletop exercise record from within the last 12 months covering at least one scenario of primary provider unavailability lasting more than four hours with no estimated restoration time, including plan activation decision, fallback routing execution, and stakeholder communication steps", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RP-06-E4", "description": "Provider incident notification subscription record confirming the organization receives real-time status alerts from each critical external AI API provider via status page webhook or email", "evidence_type": "incident-record", "verification": "attested" }, { "id": "RP-06-E5", "description": "Post-exercise action item list with owners and resolution status, confirming findings from the tabletop are tracked to remediation", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU DORA Article 28 imposes binding requirements for managing third-party ICT risk including cloud service providers and AI API vendors. Financial entities using third-party model APIs must maintain contingency plans for provider outages as a regulatory obligation." } ] }, { "requirement_id": "DORA-ART28-02", "section": "Art. 28(5)", "title": "ICT Concentration Risk from Critical Third-Party AI Providers", "text": "Financial entities shall identify and assess concentration risk arising from dependence on a limited number of critical ICT third-party service providers, including AI model vendors or cloud AI platforms, and shall take appropriate steps to mitigate this risk.", "verdict": "partial", "coverage": "partial", "notes": "MR-06 assesses third-party and vendor AI model risk including dependency concentration; RV-05 tests third-party AI dependency resilience; FP-04 governs AI procurement and vendor management including diversification policy. Concentration risk as a systemic exposure assessment \u2014 including portfolio-level dependency mapping across financial entities \u2014 is a macro-prudential concern that Apeiris controls address at the entity level but not at the systemic supervisory level.", "control_count": 3, "proof_chain": [ { "control": "apeiris://finance/controls/MR-06", "id": "MR-06", "domain": "finance", "name": "Third-Party and Vendor AI Model Risk Management", "validation_objective": "All third-party vendor AI models used in material financial decisions must be registered in the model inventory with a completed MRM due diligence record; contractual provisions for change notification and validation support must be confirmed in place for all material vendor models; and compensating controls must be documented and technically operational for opaque vendor models where direct validation access is unavailable.", "blocking_effect": "requires-review", "evidence_required": [ "third_party_model_inventory_record for each vendor AI model showing vendor_name, model_version, api_endpoint, risk_tier, due_diligence_status, and contract_review_date", "vendor_due_diligence_checklist_completed covering model documentation quality, validation evidence provided, bias and fairness testing results, EU AI Act conformity documentation, and change notification process assessment", "vendor_ai_contract_review_record confirming presence of change_notification_clause, audit_rights_clause, and data_residency_requirements for each material vendor model contract", "compensating_control_documentation for opaque vendor models showing output_validation_layer_design, shadow_model_comparison_methodology, and human_review_threshold_definitions", "vendor_change_notification_log recording all received vendor model update notifications with linked mrm_impact_assessment_records showing assessment_date within 5 business days of notification_date" ], "evidence": [ { "id": "MR-06-E1", "description": "third_party_model_inventory_record for each vendor AI model showing vendor_name, model_version, api_endpoint, risk_tier, due_diligence_status, and contract_review_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-06-E2", "description": "vendor_due_diligence_checklist_completed covering model documentation quality, validation evidence provided, bias and fairness testing results, EU AI Act conformity documentation, and change notification process assessment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-06-E3", "description": "vendor_ai_contract_review_record confirming presence of change_notification_clause, audit_rights_clause, and data_residency_requirements for each material vendor model contract", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-06-E4", "description": "compensating_control_documentation for opaque vendor models showing output_validation_layer_design, shadow_model_comparison_methodology, and human_review_threshold_definitions", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-06-E5", "description": "vendor_change_notification_log recording all received vendor model update notifications with linked mrm_impact_assessment_records showing assessment_date within 5 business days of notification_date", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://resilience/controls/RV-05", "id": "RV-05", "domain": "resilience", "name": "Third-Party AI Dependency Resilience Assessment", "validation_objective": "Every third-party AI dependency (model inference APIs, embedding services, vector database providers, data enrichment services) for each production AI system must be registered and classified, with a current resilience assessment completed within the last 12 months for all critical and high dependencies, and documented fallback architecture or formal risk acceptance for any dependency whose SLA coverage is insufficient for the AI system's recovery objectives.", "blocking_effect": "requires-review", "evidence_required": [ "third_party_ai_dependency_register with dependency_id, ai_system_id, dependency_type, criticality_classification (critical|high|standard), and sla_coverage_adequate flag for all production AI systems", "dependency_resilience_assessment per critical or high dependency within last 12 months, including sla_terms, historical_uptime_12mo_percent, incident_notification_practice, and fallback_option_evaluated", "fallback_architecture_document or risk_acceptance_record with owner_signoff for each dependency where sla_coverage_adequate=false", "synthetic_monitoring_coverage_report confirming active health checks are deployed against all critical third-party AI API endpoints" ], "evidence": [ { "id": "RV-05-E1", "description": "third_party_ai_dependency_register with dependency_id, ai_system_id, dependency_type, criticality_classification (critical|high|standard), and sla_coverage_adequate flag for all production AI systems", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RV-05-E2", "description": "dependency_resilience_assessment per critical or high dependency within last 12 months, including sla_terms, historical_uptime_12mo_percent, incident_notification_practice, and fallback_option_evaluated", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RV-05-E3", "description": "fallback_architecture_document or risk_acceptance_record with owner_signoff for each dependency where sla_coverage_adequate=false", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RV-05-E4", "description": "synthetic_monitoring_coverage_report confirming active health checks are deployed against all critical third-party AI API endpoints", "evidence_type": "third-party-audit-report", "verification": "third-party" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "EU DORA Articles 28 through 30 establish binding requirements for ICT third-party risk management including pre-contract due diligence, contractual provisions, and ongoing monitoring of critical ICT third-party service providers. AI model API providers and cloud inference services used by financial entities fall within this scope." }, { "control": "apeiris://finance/controls/FP-04", "id": "FP-04", "domain": "finance", "name": "AI Procurement and Vendor Management Policy for Finance", "validation_objective": "The organization maintains a documented AI vendor procurement policy that governs the full vendor lifecycle from risk-tiered due diligence through offboarding, and every production AI vendor has a completed assessment on file with contractual minimums for data residency, audit rights, and incident notification satisfied before production access is granted.", "blocking_effect": "blocks-deployment", "evidence_required": [ "AI vendor policy document dated within 12 months with risk-tiered due diligence criteria, minimum contractual requirements section, and board or executive approval signature", "Vendor assessment questionnaire completed for each production AI vendor, including security certification status, data residency declaration, and confirmation of SR 26-2-aligned model documentation", "Executed AI vendor contracts containing right-to-audit, data residency, incident notification SLA, and EU AI Act Article 25 value-chain / Article 26 deployer obligation clauses", "Vendor monitoring scorecard for each production AI vendor updated within the last 90 days", "Vendor model inventory cross-referenced against the internal model inventory with no unmatched vendor models in production" ], "evidence": [ { "id": "FP-04-E1", "description": "AI vendor policy document dated within 12 months with risk-tiered due diligence criteria, minimum contractual requirements section, and board or executive approval signature", "evidence_type": "human-review-record", "verification": "human" }, { "id": "FP-04-E2", "description": "Vendor assessment questionnaire completed for each production AI vendor, including security certification status, data residency declaration, and confirmation of SR 26-2-aligned model documentation", "evidence_type": "certification", "verification": "third-party" }, { "id": "FP-04-E3", "description": "Executed AI vendor contracts containing right-to-audit, data residency, incident notification SLA, and EU AI Act Article 25 value-chain / Article 26 deployer obligation clauses", "evidence_type": "incident-record", "verification": "attested" }, { "id": "FP-04-E4", "description": "Vendor monitoring scorecard for each production AI vendor updated within the last 90 days", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "FP-04-E5", "description": "Vendor model inventory cross-referenced against the internal model inventory with no unmatched vendor models in production", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "DORA-ART30-01", "section": "Art. 30(1)", "title": "Key Contractual Provisions for ICT Third-Party Service Agreements", "text": "Financial entities shall ensure that contracts with ICT third-party service providers, including AI model and data service providers, include key provisions covering service levels, data location, security standards, audit rights, termination rights, and exit strategies.", "verdict": "supported", "coverage": "direct", "notes": "PR-03 governs vendor qualification enforcement including contract requirements; PO-03 extracts and tracks contractual obligations from third-party AI agreements; OB-06 manages contractual AI obligation compliance including audit rights and SLAs; PR-04 enforces contract review gate compliance before AI vendor engagement. These controls directly operationalize the DORA key contractual provisions requirement for AI model and data provider agreements.", "control_count": 4, "proof_chain": [ { "control": "apeiris://authority/controls/PR-03", "id": "PR-03", "domain": "authority", "name": "Vendor Qualification Enforcement", "validation_objective": "Every vendor engaged through AI-assisted procurement must have a passing vendor qualification scorecard on file before the procurement workflow advances to contract negotiation, and no vendor with an expired qualification record may receive a renewal order. The procurement workflow must technically prevent advancement past the qualification gate for any vendor that has not met the documented minimum qualification threshold.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "vendor_qualification_scorecard for each AI vendor contracted during the review period, showing scores across all required authority policy compliance areas, a pass/fail determination, reviewer identity, and scorecard effective date", "procurement_workflow_qualification_gate_config demonstrating the gate is technically enforced and that no advancement path to contract negotiation exists for a vendor without a current passed scorecard", "qualified_vendor_list with last_reviewed_date and scorecard_expiry_date for each entry, confirmed updated within the last quarter by Vendor Management", "vendor_exception_records for any vendor granted an exception below the minimum threshold, each with documented General Counsel approval and risk assessment" ], "evidence": [ { "id": "PR-03-E1", "description": "vendor_qualification_scorecard for each AI vendor contracted during the review period, showing scores across all required authority policy compliance areas, a pass/fail determination, reviewer identity, and scorecard effective date", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "PR-03-E2", "description": "procurement_workflow_qualification_gate_config demonstrating the gate is technically enforced and that no advancement path to contract negotiation exists for a vendor without a current passed scorecard", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "PR-03-E3", "description": "qualified_vendor_list with last_reviewed_date and scorecard_expiry_date for each entry, confirmed updated within the last quarter by Vendor Management", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PR-03-E4", "description": "vendor_exception_records for any vendor granted an exception below the minimum threshold, each with documented General Counsel approval and risk assessment", "evidence_type": "human-review-record", "verification": "human" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://authority/controls/PO-03", "id": "PO-03", "domain": "authority", "name": "Contractual Obligation Extraction", "validation_objective": "Every executed contract within AI-relevant scope must be processed by the obligation extraction pipeline within 10 business days of signing, producing a structured obligation manifest with source clause citations. All extracted obligations must be mapped to authority register entries with a General Counsel review sign-off before the mapping takes effect in AI deployment authority evaluation, and no AI deployment may be activated under a contract whose obligations have not been fully extracted, mapped, and reviewed.", "blocking_effect": "blocks-deployment", "evidence_required": [ "obligation_extraction_manifest for each in-scope executed contract, containing source_contract_id, clause_location, obligation_type, authority_impact, and extraction_timestamp", "contract_intake_pipeline_audit_log showing each contract's ingestion date, extraction completion date, and days-to-extraction for SLA compliance tracking", "general_counsel_obligation_review_sign_offs confirming each obligation mapping was reviewed and approved by legal counsel with review_date and reviewer identity", "authority_register_entries_with_contractual_origin showing obligation-to-constraint mappings with back-references to the source contract and clause identifier" ], "evidence": [ { "id": "PO-03-E1", "description": "obligation_extraction_manifest for each in-scope executed contract, containing source_contract_id, clause_location, obligation_type, authority_impact, and extraction_timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-03-E2", "description": "contract_intake_pipeline_audit_log showing each contract's ingestion date, extraction completion date, and days-to-extraction for SLA compliance tracking", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PO-03-E3", "description": "general_counsel_obligation_review_sign_offs confirming each obligation mapping was reviewed and approved by legal counsel with review_date and reviewer identity", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PO-03-E4", "description": "authority_register_entries_with_contractual_origin showing obligation-to-constraint mappings with back-references to the source contract and clause identifier", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://compliance/controls/OB-06", "id": "OB-06", "domain": "compliance", "name": "Contractual AI Obligation Management", "validation_objective": "All AI-specific obligations embedded in customer contracts, data processing agreements, and AI addenda must be extracted at signing and entered into the obligation register within the defined SLA, with named owners assigned and fulfillment tracking active. No contractual AI obligation may remain unregistered beyond the defined extraction SLA, and evidence of systematic extraction must be present for all AI-related contract types.", "blocking_effect": "requires-review", "evidence_required": [ "contractual_obligation_extraction_record per contract showing contract_id, signing_date, extraction_completed_at timestamp (confirming SLA met), and list of extracted obligation_ids with each obligation's type (data_use, model_behavior, audit_rights, ai_governance)", "obligation_register entries for each extracted contractual obligation showing owner_name, due_date or review_cadence, and fulfillment_status", "contract_review_queue log confirming all AI-related contracts entered the extraction workflow within the defined trigger period after signing", "audit_rights_fulfillment_record documenting responses to any customer audit requests under AI contractual audit rights provisions, with response timestamps confirming contractual SLA compliance" ], "evidence": [ { "id": "OB-06-E1", "description": "contractual_obligation_extraction_record per contract showing contract_id, signing_date, extraction_completed_at timestamp (confirming SLA met), and list of extracted obligation_ids with each obligation's type (data_use, model_behavior, audit_rights, ai_governance)", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OB-06-E2", "description": "obligation_register entries for each extracted contractual obligation showing owner_name, due_date or review_cadence, and fulfillment_status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OB-06-E3", "description": "contract_review_queue log confirming all AI-related contracts entered the extraction workflow within the defined trigger period after signing", "evidence_type": "audit-log", "verification": "automated" }, { "id": "OB-06-E4", "description": "audit_rights_fulfillment_record documenting responses to any customer audit requests under AI contractual audit rights provisions, with response timestamps confirming contractual SLA compliance", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://authority/controls/PR-04", "id": "PR-04", "domain": "authority", "name": "Contract Review Gate Compliance", "validation_objective": "All AI-assisted or AI-initiated contract execution attempts must be intercepted by a technical enforcement layer that holds execution pending completion of the full mandatory review gate sequence, with no bypass path available to the AI system. Every contract execution in the production environment must have a corresponding hold-and-approval record documenting completion of legal review, authority policy check, and CFO approval for above-threshold commitments before the contract was finalized.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "contract_execution_hold_and_approval_log (immutable) showing each AI contract execution attempt, hold timestamp, review gate sequence steps completed with approver identity and timestamp for each step, and final execution or rejection outcome", "contract_execution_enforcement_layer_config documenting all AI contract execution paths with interception points and confirming no bypass routes exist", "review_gate_sequence_and_approver_matrix defining mandatory gate steps, approver roles, response SLAs, and escalation paths for delayed approvals", "bypass_attempt_detection_log showing any direct API contract execution attempts detected, with alert delivery records and investigation outcomes" ], "evidence": [ { "id": "PR-04-E1", "description": "contract_execution_hold_and_approval_log (immutable) showing each AI contract execution attempt, hold timestamp, review gate sequence steps completed with approver identity and timestamp for each step, and final execution or rejection outcome", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PR-04-E2", "description": "contract_execution_enforcement_layer_config documenting all AI contract execution paths with interception points and confirming no bypass routes exist", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PR-04-E3", "description": "review_gate_sequence_and_approver_matrix defining mandatory gate steps, approver roles, response SLAs, and escalation paths for delayed approvals", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PR-04-E4", "description": "bypass_attempt_detection_log showing any direct API contract execution attempts detected, with alert delivery records and investigation outcomes", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "DORA-ART31-01", "section": "Art. 31(1)", "title": "Designation and Assessment of Critical ICT Third-Party Providers", "text": "Competent authorities may designate ICT third-party service providers, including AI model and data infrastructure providers, as critical based on systemic importance, scale of service, number of financial entities served, and substitutability of the service.", "verdict": "partial", "coverage": "partial", "notes": "MR-01 provides model inventory and risk tiering that informs criticality assessment of AI providers; PR-03 governs vendor qualification enforcement relevant to critical provider relationships; CA-07 manages third-party and supply chain compliance obligations aligned to criticality designations. The formal designation of critical ICT third-party providers is a supervisory act by competent authorities; Apeiris controls support the risk assessment inputs and compliance management but do not replicate the regulatory designation process.", "control_count": 3, "proof_chain": [ { "control": "apeiris://finance/controls/MR-01", "id": "MR-01", "domain": "finance", "name": "SR 26-2 Model Inventory and Risk Tiering", "validation_objective": "Every financial AI model in production must appear in the centralized model registry with a validated risk tier, owner, validation status, and lifecycle stage assigned; the inventory must achieve 100% completeness as confirmed by cross-reference against deployment pipeline records and IT asset management data, with no unregistered production models identified.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_registry_export showing model_id, owner, risk_tier, validation_status, and lifecycle_stage for every registered entry", "cross_reference_reconciliation_report comparing registry entries against IT asset management and cloud cost records, confirming discrepancy rate \u2264 2%", "risk_tiering_decision_record for each High/Critical tier model documenting the materiality factors and criteria applied to the tier assignment with MRO approval timestamp", "deployment_gate_audit_log confirming no production promotions occurred for models without a registry record in the prior quarter", "quarterly_inventory_reconciliation_sign_off signed by Model Risk Officer attesting to completeness" ], "evidence": [ { "id": "MR-01-E1", "description": "model_registry_export showing model_id, owner, risk_tier, validation_status, and lifecycle_stage for every registered entry", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-01-E2", "description": "cross_reference_reconciliation_report comparing registry entries against IT asset management and cloud cost records, confirming discrepancy rate \u2264 2%", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-01-E3", "description": "risk_tiering_decision_record for each High/Critical tier model documenting the materiality factors and criteria applied to the tier assignment with MRO approval timestamp", "evidence_type": "human-review-record", "verification": "human" }, { "id": "MR-01-E4", "description": "deployment_gate_audit_log confirming no production promotions occurred for models without a registry record in the prior quarter", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "MR-01-E5", "description": "quarterly_inventory_reconciliation_sign_off signed by Model Risk Officer attesting to completeness", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://authority/controls/PR-03", "id": "PR-03", "domain": "authority", "name": "Vendor Qualification Enforcement", "validation_objective": "Every vendor engaged through AI-assisted procurement must have a passing vendor qualification scorecard on file before the procurement workflow advances to contract negotiation, and no vendor with an expired qualification record may receive a renewal order. The procurement workflow must technically prevent advancement past the qualification gate for any vendor that has not met the documented minimum qualification threshold.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "vendor_qualification_scorecard for each AI vendor contracted during the review period, showing scores across all required authority policy compliance areas, a pass/fail determination, reviewer identity, and scorecard effective date", "procurement_workflow_qualification_gate_config demonstrating the gate is technically enforced and that no advancement path to contract negotiation exists for a vendor without a current passed scorecard", "qualified_vendor_list with last_reviewed_date and scorecard_expiry_date for each entry, confirmed updated within the last quarter by Vendor Management", "vendor_exception_records for any vendor granted an exception below the minimum threshold, each with documented General Counsel approval and risk assessment" ], "evidence": [ { "id": "PR-03-E1", "description": "vendor_qualification_scorecard for each AI vendor contracted during the review period, showing scores across all required authority policy compliance areas, a pass/fail determination, reviewer identity, and scorecard effective date", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "PR-03-E2", "description": "procurement_workflow_qualification_gate_config demonstrating the gate is technically enforced and that no advancement path to contract negotiation exists for a vendor without a current passed scorecard", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "PR-03-E3", "description": "qualified_vendor_list with last_reviewed_date and scorecard_expiry_date for each entry, confirmed updated within the last quarter by Vendor Management", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PR-03-E4", "description": "vendor_exception_records for any vendor granted an exception below the minimum threshold, each with documented General Counsel approval and risk assessment", "evidence_type": "human-review-record", "verification": "human" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://compliance/controls/CA-07", "id": "CA-07", "domain": "compliance", "name": "Third-Party and Supply Chain Compliance Obligations", "validation_objective": "Every supply chain participant for each AI system in scope must have an entry in the third-party compliance obligation register documenting all flowing obligations and a corresponding executed binding contractual instrument containing audit rights, with third-party compliance attestations collected within the defined refresh cycle and incorporated into the CA-03 routing table as evidence inputs.", "blocking_effect": "blocks-deployment", "evidence_required": [ "third_party_compliance_obligation_register entries for each supply chain participant containing vendor_id, vendor_role, applicable_obligations[], contract_instrument_id, contract_execution_date, and next_attestation_due_date", "executed_contract_inventory for each supply chain participant showing contract_type (DPA, EU_AI_Act_compliance_schedule, supplier_agreement), execution_date, audit_rights_clause_present=true, and sub_processor_management_clause_present=true for data processors", "third_party_attestation_collection_log showing each attestation collected with collection_date, valid_until, attesting_entity_name, attestation_scope, and the CA-03 routing_table_entry_id that references it", "service_dependency_map for each AI system listing all integrated third-party APIs, model providers, and data services cross-referenced against the obligation register to confirm no vendor is absent from the register" ], "evidence": [ { "id": "CA-07-E1", "description": "third_party_compliance_obligation_register entries for each supply chain participant containing vendor_id, vendor_role, applicable_obligations[], contract_instrument_id, contract_execution_date, and next_attestation_due_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-07-E2", "description": "executed_contract_inventory for each supply chain participant showing contract_type (DPA, EU_AI_Act_compliance_schedule, supplier_agreement), execution_date, audit_rights_clause_present=true, and sub_processor_management_clause_present=true for data processors", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-07-E3", "description": "third_party_attestation_collection_log showing each attestation collected with collection_date, valid_until, attesting_entity_name, attestation_scope, and the CA-03 routing_table_entry_id that references it", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-07-E4", "description": "service_dependency_map for each AI system listing all integrated third-party APIs, model providers, and data services cross-referenced against the obligation register to confirm no vendor is absent from the register", "evidence_type": "third-party-audit-report", "verification": "third-party" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "DORA-ART45-01", "section": "Art. 45(1)", "title": "Voluntary Cyber Threat Intelligence Information Sharing", "text": "Financial entities may exchange cyber threat information and intelligence, including indicators of compromise, cyber threat signatures, and tactics, techniques and procedures, among trusted communities of financial entities to enhance digital operational resilience.", "verdict": "partial", "coverage": "partial", "notes": "RT-06 maps AI-native threats using ATT&CK/ATLAS frameworks that provide a common vocabulary for threat intelligence exchange; CA-05 governs regulatory change management including uptake of shared threat intelligence. The voluntary information sharing arrangement under DORA is a sector-level coordination mechanism; Apeiris controls provide the threat modelling and intelligence uptake framework but the establishment and governance of cross-entity sharing arrangements requires additional program infrastructure.", "control_count": 2, "proof_chain": [ { "control": "apeiris://security/controls/RT-06", "id": "RT-06", "domain": "security", "name": "Map AI-native threats, extend ATT&CK/ATLAS to agentic orchestration", "validation_objective": "The organization's threat model must reference current MITRE ATLAS agentic technique IDs and explicitly label autonomous-orchestration and real-time-pivot behaviors lacking standard IDs as custom extensions. Risk scoring must use an additive model (Threat + Vulnerability + Impact) that keeps partial attack-enablement signals visible and does not zero them out, and the threat model must be updated whenever ATLAS publishes new agentic technique IDs.", "blocking_effect": "advisory", "evidence_required": [ "threat_model_document referencing current ATLAS agentic technique IDs (including AML.T0053, AML.T0070, AML.T0080, AML.T0104) with verification date against atlas.mitre.org", "agentic_orchestration_extension_record listing custom internal IDs for autonomous killchain orchestration and real-time pivot decisioning behaviors not yet codified in ATLAS, each labeled as an internal extension", "additive_risk_scoring_formula_document showing Threat + Vulnerability + Impact calculation with evidence that no multiplicative step can zero out a partial-enablement score", "threat_model_review_record showing the last update date and trigger (new ATLAS ID publication, observed attack, or scheduled review cycle)" ], "evidence": [ { "id": "RT-06-E1", "description": "threat_model_document referencing current ATLAS agentic technique IDs (including AML.T0053, AML.T0070, AML.T0080, AML.T0104) with verification date against atlas.mitre.org", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-06-E2", "description": "agentic_orchestration_extension_record listing custom internal IDs for autonomous killchain orchestration and real-time pivot decisioning behaviors not yet codified in ATLAS, each labeled as an internal extension", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-06-E3", "description": "additive_risk_scoring_formula_document showing Threat + Vulnerability + Impact calculation with evidence that no multiplicative step can zero out a partial-enablement score", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-06-E4", "description": "threat_model_review_record showing the last update date and trigger (new ATLAS ID publication, observed attack, or scheduled review cycle)", "evidence_type": "human-review-record", "verification": "human" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://compliance/controls/CA-05", "id": "CA-05", "domain": "compliance", "name": "Regulatory Change Management", "validation_objective": "The organization must maintain a current regulatory watch list covering all applicable jurisdictions and regulatory bodies identified in active CA-01 scope records, and every regulatory publication in the monitoring period must have a completed impact assessment with triage within 5 business days of publication, with all required architecture updates completed before the publication's regulatory effective date.", "blocking_effect": "advisory", "evidence_required": [ "regulatory_watch_list document showing all monitored jurisdictions, regulatory_bodies[], authoritative_source_subscriptions[], and last_reviewed_on within the current quarter", "regulatory_change_log entries for each publication in the watch period, each containing publication_id, source, publication_date, triage_completed_at (within 5 business days), and impact_assessment_id or determination='no_impact'", "impact_assessment records for each assessed regulatory change containing affected_ai_systems[], affected_obligations[], required_architecture_updates[], assigned_owner, target_completion_date, and regulatory_effective_date", "remediation_completion_records for each required architecture update showing completed_at before target_completion_date and before regulatory_effective_date, with updated_artifact_ids referenced" ], "evidence": [ { "id": "CA-05-E1", "description": "regulatory_watch_list document showing all monitored jurisdictions, regulatory_bodies[], authoritative_source_subscriptions[], and last_reviewed_on within the current quarter", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-05-E2", "description": "regulatory_change_log entries for each publication in the watch period, each containing publication_id, source, publication_date, triage_completed_at (within 5 business days), and impact_assessment_id or determination='no_impact'", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-05-E3", "description": "impact_assessment records for each assessed regulatory change containing affected_ai_systems[], affected_obligations[], required_architecture_updates[], assigned_owner, target_completion_date, and regulatory_effective_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CA-05-E4", "description": "remediation_completion_records for each required architecture update showing completed_at before target_completion_date and before regulatory_effective_date, with updated_artifact_ids referenced", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "DORA-ART45-02", "section": "Art. 45(2)", "title": "AI-Specific Threat Intelligence for Operational Resilience", "text": "Information sharing arrangements for financial entities shall include intelligence specific to emerging ICT threats relevant to AI systems, including adversarial machine learning attacks, model poisoning, and prompt injection threats that may affect digital operational resilience.", "verdict": "partial", "coverage": "partial", "notes": "RT-06 maps AI-native threats and extends ATT&CK/ATLAS to cover adversarial ML and agentic orchestration attack vectors relevant to threat sharing; RT-02 detects direct and indirect prompt injection at every input boundary; RT-07 detects multi-agent collusion and covert channels. The sector-level threat intelligence sharing arrangement is a cross-entity coordination activity; Apeiris controls address the threat detection and modelling dimensions but peer exchange infrastructure requires additional program design.", "control_count": 3, "proof_chain": [ { "control": "apeiris://security/controls/RT-06", "id": "RT-06", "domain": "security", "name": "Map AI-native threats, extend ATT&CK/ATLAS to agentic orchestration", "validation_objective": "The organization's threat model must reference current MITRE ATLAS agentic technique IDs and explicitly label autonomous-orchestration and real-time-pivot behaviors lacking standard IDs as custom extensions. Risk scoring must use an additive model (Threat + Vulnerability + Impact) that keeps partial attack-enablement signals visible and does not zero them out, and the threat model must be updated whenever ATLAS publishes new agentic technique IDs.", "blocking_effect": "advisory", "evidence_required": [ "threat_model_document referencing current ATLAS agentic technique IDs (including AML.T0053, AML.T0070, AML.T0080, AML.T0104) with verification date against atlas.mitre.org", "agentic_orchestration_extension_record listing custom internal IDs for autonomous killchain orchestration and real-time pivot decisioning behaviors not yet codified in ATLAS, each labeled as an internal extension", "additive_risk_scoring_formula_document showing Threat + Vulnerability + Impact calculation with evidence that no multiplicative step can zero out a partial-enablement score", "threat_model_review_record showing the last update date and trigger (new ATLAS ID publication, observed attack, or scheduled review cycle)" ], "evidence": [ { "id": "RT-06-E1", "description": "threat_model_document referencing current ATLAS agentic technique IDs (including AML.T0053, AML.T0070, AML.T0080, AML.T0104) with verification date against atlas.mitre.org", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-06-E2", "description": "agentic_orchestration_extension_record listing custom internal IDs for autonomous killchain orchestration and real-time pivot decisioning behaviors not yet codified in ATLAS, each labeled as an internal extension", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-06-E3", "description": "additive_risk_scoring_formula_document showing Threat + Vulnerability + Impact calculation with evidence that no multiplicative step can zero out a partial-enablement score", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-06-E4", "description": "threat_model_review_record showing the last update date and trigger (new ATLAS ID publication, observed attack, or scheduled review cycle)", "evidence_type": "human-review-record", "verification": "human" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://security/controls/RT-02", "id": "RT-02", "domain": "security", "name": "Detect direct and indirect prompt injection at every input and output", "validation_objective": "Every input channel \u2014 including user prompts, retrieved documents, tool results, and multimodal streams \u2014 must pass through injection inspection before reaching the agent's reasoning layer, and every agent output must pass through inspection before execution or delivery. Suspected injections must be blocked or quarantined before the agent acts on them, with attack-success-rate below the defined threshold on periodic evaluation suites.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "guardrail_decision_log with entries for each inspection event recording content_channel, trust_boundary, injection_score, and action taken (allowed/blocked/quarantined) for both input and output paths", "injection_eval_report from AgentDojo or equivalent suite showing attack-success-rate and false-positive-rate before and after the guardrail, run at least quarterly", "input_coverage_attestation confirming guardrails are applied to retrieved document streams and tool result payloads, not only direct user prompts", "redaction_audit_log confirming sensitive data was stripped at the inspection boundary during the evaluation period" ], "evidence": [ { "id": "RT-02-E1", "description": "guardrail_decision_log with entries for each inspection event recording content_channel, trust_boundary, injection_score, and action taken (allowed/blocked/quarantined) for both input and output paths", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-02-E2", "description": "injection_eval_report from AgentDojo or equivalent suite showing attack-success-rate and false-positive-rate before and after the guardrail, run at least quarterly", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-02-E3", "description": "input_coverage_attestation confirming guardrails are applied to retrieved document streams and tool result payloads, not only direct user prompts", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-02-E4", "description": "redaction_audit_log confirming sensitive data was stripped at the inspection boundary during the evaluation period", "evidence_type": "evaluation-scorecard", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://security/controls/RT-07", "id": "RT-07", "domain": "security", "name": "Detect multi-agent collusion and covert channels", "validation_objective": "A cross-agent correlation layer must continuously analyze behavior across all active agents, flagging coordinated action patterns and shared-artifact hand-offs that individually appear policy-compliant but together constitute a policy bypass. Inter-agent communication channels must be inspected for covert content beyond authentication verification, and mutual information between agents designated as independent must be monitored for anomalous rises above the calibrated baseline threshold.", "blocking_effect": "advisory", "evidence_required": [ "cross_agent_correlation_alert_log showing agent_pair, shared_artifact_id, cross_agent_causal_edge, timing_correlation, mutual_information_score, and alert_action for any flagged coordination pattern", "inter_agent_traffic_inspection_record confirming payload inspection is applied beyond authentication validation for all agent-to-agent channels, including inspection for steganographic encoding", "multi_agent_collusion_test_report documenting a staged split-attack scenario across two agents and the correlation layer's detection outcome including time-to-flag", "agent_independence_baseline_record defining which agent pairs should exhibit low mutual information and the threshold above which a rising score triggers an alert" ], "evidence": [ { "id": "RT-07-E1", "description": "cross_agent_correlation_alert_log showing agent_pair, shared_artifact_id, cross_agent_causal_edge, timing_correlation, mutual_information_score, and alert_action for any flagged coordination pattern", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-07-E2", "description": "inter_agent_traffic_inspection_record confirming payload inspection is applied beyond authentication validation for all agent-to-agent channels, including inspection for steganographic encoding", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-07-E3", "description": "multi_agent_collusion_test_report documenting a staged split-attack scenario across two agents and the correlation layer's detection outcome including time-to-flag", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "RT-07-E4", "description": "agent_independence_baseline_record defining which agent pairs should exhibit low mutual information and the threshold above which a rising score triggers an alert", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] } ] }, { "framework": "sr262", "label": "SR 26-2 (model risk)", "source_id": "sr26_2", "anchored": true, "currency": { "version": "2026", "published_on": "2026-04-17", "status": "current", "retrieved_on": null }, "total_requirements": 22, "summary": { "supported": 20, "partial": 2, "unsupported": 0, "out-of-scope": 0, "controls_involved": 50, "evidence_artifacts": 222, "automatable_evidence": 44 }, "obligations": [ { "requirement_id": "SR26-INV-01", "section": "Sec. VI", "title": "Comprehensive Model Inventory", "text": "The guidance describes the expectation that institutions maintain a comprehensive, current inventory of all models \u2014 including AI/ML models, third-party models, and inherited models \u2014 covering model purpose, owner, data inputs, outputs, users, risk tier, validation status, and lifecycle stage.", "verdict": "supported", "coverage": "direct", "notes": "MR-01 (SR 26-2 Model Inventory and Risk Tiering) maps directly to this requirement by name and substance. LI-01 provides unique identity and version hashing per model entry; LI-02 tracks full provenance chain including base model, fine-tune, merge, and adapter lineage required for complete AI/ML inventory records.", "control_count": 3, "proof_chain": [ { "control": "apeiris://finance/controls/MR-01", "id": "MR-01", "domain": "finance", "name": "SR 26-2 Model Inventory and Risk Tiering", "validation_objective": "Every financial AI model in production must appear in the centralized model registry with a validated risk tier, owner, validation status, and lifecycle stage assigned; the inventory must achieve 100% completeness as confirmed by cross-reference against deployment pipeline records and IT asset management data, with no unregistered production models identified.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_registry_export showing model_id, owner, risk_tier, validation_status, and lifecycle_stage for every registered entry", "cross_reference_reconciliation_report comparing registry entries against IT asset management and cloud cost records, confirming discrepancy rate \u2264 2%", "risk_tiering_decision_record for each High/Critical tier model documenting the materiality factors and criteria applied to the tier assignment with MRO approval timestamp", "deployment_gate_audit_log confirming no production promotions occurred for models without a registry record in the prior quarter", "quarterly_inventory_reconciliation_sign_off signed by Model Risk Officer attesting to completeness" ], "evidence": [ { "id": "MR-01-E1", "description": "model_registry_export showing model_id, owner, risk_tier, validation_status, and lifecycle_stage for every registered entry", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-01-E2", "description": "cross_reference_reconciliation_report comparing registry entries against IT asset management and cloud cost records, confirming discrepancy rate \u2264 2%", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-01-E3", "description": "risk_tiering_decision_record for each High/Critical tier model documenting the materiality factors and criteria applied to the tier assignment with MRO approval timestamp", "evidence_type": "human-review-record", "verification": "human" }, { "id": "MR-01-E4", "description": "deployment_gate_audit_log confirming no production promotions occurred for models without a registry record in the prior quarter", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "MR-01-E5", "description": "quarterly_inventory_reconciliation_sign_off signed by Model Risk Officer attesting to completeness", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "SR 26-2 \u00a7VI (Governance and Controls) describes maintaining a model inventory under its Model Inventory subheading \u2014 the guidance itself calls a comprehensive model inventory 'common industry practice' rather than a requirement, and it is principles-based and non-enforceable. Applicability note: the guidance applies to banking organizations with more than $30 billion in total assets; it may also be relevant to smaller organizations with significant model risk exposure." }, { "control": "apeiris://model/controls/LI-01", "id": "LI-01", "domain": "model", "name": "Unique Model Identity and Content-Addressed Version Hash", "validation_objective": "Every deployed model version must have a globally unique model ID and a SHA-256 content hash computed over the complete artifact bundle (weights, tokenizer, and inference configuration), stored in an append-only registry entry, and verified as a blocking gate before each pipeline promotion stage. Any mismatch between the recomputed artifact hash and the registry entry must produce an auditable rejection event and block the promotion.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_registry_entry with unique model ID encoding model-family/provider/version triple, SHA-256 artifact hash, and registration timestamp, stored in an append-only backend where existing version entries cannot be overwritten", "deployment_pipeline_gate_log showing hash recomputation and comparison result for each promotion stage (build to staging, staging to production) with timestamp and approving identity", "inference_api_audit_log_sample demonstrating model_id and artifact_hash present in response headers or structured log fields for at least 10 consecutive sampled inference requests", "registry_duplicate_rejection_log showing that an attempt to register a second artifact under an existing model-family/version/provider triple was rejected" ], "evidence": [ { "id": "LI-01-E1", "description": "model_registry_entry with unique model ID encoding model-family/provider/version triple, SHA-256 artifact hash, and registration timestamp, stored in an append-only backend where existing version entries cannot be overwritten", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-01-E2", "description": "deployment_pipeline_gate_log showing hash recomputation and comparison result for each promotion stage (build to staging, staging to production) with timestamp and approving identity", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-01-E3", "description": "inference_api_audit_log_sample demonstrating model_id and artifact_hash present in response headers or structured log fields for at least 10 consecutive sampled inference requests", "evidence_type": "audit-log", "verification": "automated" }, { "id": "LI-01-E4", "description": "registry_duplicate_rejection_log showing that an attempt to register a second artifact under an existing model-family/version/provider triple was rejected", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "SR 26-2 Sec. VI (Governance and Controls) describes maintenance of a model inventory as a core governance control. LI-01's unique identifier and content-addressed hash give each inventory entry a verifiable technical anchor, supporting an accurate and current inventory; the guidance itself does not prescribe cryptographic identity mechanisms. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope." }, { "control": "apeiris://model/controls/LI-02", "id": "LI-02", "domain": "model", "name": "Model Provenance Chain \u2014 Base Model, Fine-Tune, Merge, and Adapter Lineage", "validation_objective": "Every registered model artifact must have a machine-readable provenance manifest recording the complete ancestry chain including the base model artifact hash and provider version, all fine-tuning steps with dataset references, all merge contributors with their artifact hashes, and all attached adapter components with source and base-model compatibility metadata; and the registry must expose a query interface that returns all derived models for a given base model artifact hash.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_provenance_manifest with typed structured fields for base_model_hash, base_model_provider_version, fine_tuning_steps[] each referencing a TG-layer dataset record, merge_contributors[] with per-contributor artifact hashes and merge parameters, and adapter_components[] with source, version, and base_model_compatibility_hash", "provenance_query_api_result showing all registry entries derived from a specified base model artifact hash, confirming complete downstream impact scope is retrievable by automated query", "registry_provenance_rejection_log showing that a model registration attempt with a missing required provenance field (e.g., absent base_model_hash) was blocked", "adapter_lineage_registry_entry for at least one production model with an attached LoRA or PEFT adapter, confirming adapter source and compatibility metadata are recorded" ], "evidence": [ { "id": "LI-02-E1", "description": "model_provenance_manifest with typed structured fields for base_model_hash, base_model_provider_version, fine_tuning_steps[] each referencing a TG-layer dataset record, merge_contributors[] with per-contributor artifact hashes and merge parameters, and adapter_components[] with source, version, and base_model_compatibility_hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-02-E2", "description": "provenance_query_api_result showing all registry entries derived from a specified base model artifact hash, confirming complete downstream impact scope is retrievable by automated query", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-02-E3", "description": "registry_provenance_rejection_log showing that a model registration attempt with a missing required provenance field (e.g., absent base_model_hash) was blocked", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "LI-02-E4", "description": "adapter_lineage_registry_entry for at least one production model with an attached LoRA or PEFT adapter, confirming adapter source and compatibility metadata are recorded", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "SR26-INV-02", "section": "Sec. III", "title": "Model Risk Tiering and Materiality Classification", "text": "Each model in the inventory should be assigned a risk tier based on materiality, complexity, and potential financial or operational impact. High-tier models require more rigorous validation, monitoring, and governance controls proportional to their risk.", "verdict": "supported", "coverage": "direct", "notes": "MR-01 includes risk-tier assignment as a core inventory attribute. MR-04 (Model Risk Appetite and Material Model Thresholds) defines the criteria for materiality classification. EV-09 (Risk and Applicability Classification) provides the evaluation-time risk classification gate that feeds tier assignment.", "control_count": 3, "proof_chain": [ { "control": "apeiris://finance/controls/MR-01", "id": "MR-01", "domain": "finance", "name": "SR 26-2 Model Inventory and Risk Tiering", "validation_objective": "Every financial AI model in production must appear in the centralized model registry with a validated risk tier, owner, validation status, and lifecycle stage assigned; the inventory must achieve 100% completeness as confirmed by cross-reference against deployment pipeline records and IT asset management data, with no unregistered production models identified.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_registry_export showing model_id, owner, risk_tier, validation_status, and lifecycle_stage for every registered entry", "cross_reference_reconciliation_report comparing registry entries against IT asset management and cloud cost records, confirming discrepancy rate \u2264 2%", "risk_tiering_decision_record for each High/Critical tier model documenting the materiality factors and criteria applied to the tier assignment with MRO approval timestamp", "deployment_gate_audit_log confirming no production promotions occurred for models without a registry record in the prior quarter", "quarterly_inventory_reconciliation_sign_off signed by Model Risk Officer attesting to completeness" ], "evidence": [ { "id": "MR-01-E1", "description": "model_registry_export showing model_id, owner, risk_tier, validation_status, and lifecycle_stage for every registered entry", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-01-E2", "description": "cross_reference_reconciliation_report comparing registry entries against IT asset management and cloud cost records, confirming discrepancy rate \u2264 2%", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-01-E3", "description": "risk_tiering_decision_record for each High/Critical tier model documenting the materiality factors and criteria applied to the tier assignment with MRO approval timestamp", "evidence_type": "human-review-record", "verification": "human" }, { "id": "MR-01-E4", "description": "deployment_gate_audit_log confirming no production promotions occurred for models without a registry record in the prior quarter", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "MR-01-E5", "description": "quarterly_inventory_reconciliation_sign_off signed by Model Risk Officer attesting to completeness", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "SR 26-2 \u00a7VI (Governance and Controls) describes maintaining a model inventory under its Model Inventory subheading \u2014 the guidance itself calls a comprehensive model inventory 'common industry practice' rather than a requirement, and it is principles-based and non-enforceable. Applicability note: the guidance applies to banking organizations with more than $30 billion in total assets; it may also be relevant to smaller organizations with significant model risk exposure." }, { "control": "apeiris://finance/controls/MR-04", "id": "MR-04", "domain": "finance", "name": "Model Risk Appetite and Material Model Thresholds", "validation_objective": "A board-approved Model Risk Appetite Statement must be in force specifying quantitative materiality thresholds and a maximum acceptable model error impact expressed in dollars or basis points; model risk metrics must be actively monitored against these thresholds with documented escalation events occurring within the SLA defined in the statement whenever thresholds are breached.", "blocking_effect": "requires-review", "evidence_required": [ "board_risk_appetite_statement with explicit materiality criteria, maximum tolerable model error impact thresholds in quantitative terms, and escalation trigger definitions, showing board_approval_date within the last 12 months", "model_risk_monitoring_report showing current model risk metrics measured against defined appetite thresholds with Red/Amber/Green status per model, dated within the last calendar month", "threshold_breach_escalation_record for any breach events in the prior 12 months showing escalation_initiated_timestamp within the SLA and board_notification_record", "material_model_classification_list showing all models meeting materiality criteria with classification rationale and assigning Model Owner accountability", "annual_threshold_review_record documenting MRO assessment of threshold appropriateness and board re-approval of updated risk appetite thresholds" ], "evidence": [ { "id": "MR-04-E1", "description": "board_risk_appetite_statement with explicit materiality criteria, maximum tolerable model error impact thresholds in quantitative terms, and escalation trigger definitions, showing board_approval_date within the last 12 months", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-04-E2", "description": "model_risk_monitoring_report showing current model risk metrics measured against defined appetite thresholds with Red/Amber/Green status per model, dated within the last calendar month", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-04-E3", "description": "threshold_breach_escalation_record for any breach events in the prior 12 months showing escalation_initiated_timestamp within the SLA and board_notification_record", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-04-E4", "description": "material_model_classification_list showing all models meeting materiality criteria with classification rationale and assigning Model Owner accountability", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-04-E5", "description": "annual_threshold_review_record documenting MRO assessment of threshold appropriateness and board re-approval of updated risk appetite thresholds", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "SR 26-2 \u00a7III (Overview of Model Risk and Model Risk Management) frames model risk management as risk-based \u2014 with intensity of governance, validation, and monitoring commensurate with a model's materiality and complexity. Explicit risk appetite and materiality thresholds are the mechanism institutions use to operationalize that risk-based framing." }, { "control": "apeiris://model/controls/EV-09", "id": "EV-09", "domain": "model", "name": "Risk and Applicability Classification", "validation_objective": "Every model system has a signed classification record produced before any evaluation work begins, containing a documented EU AI Act classification with provision-specific rationale referencing Articles 5, 6, 50, 51, and Annex III as applicable, an SR 26-2 model risk tier for in-scope institutions, a capability tier, and the full applicable Apeiris profiles list; the model registry gate prevents advancement to evaluation stage without this record; and re-classification is triggered on any significant change to use case, capability level, or applicable regulation.", "blocking_effect": "blocks-deployment", "evidence_required": [ "signed_classification_record containing eu_ai_act_classification with specific provision references, sr_262_tier where applicable, capability_tier, applicable_profiles list, mandatory_controls inventory, and obligations_inventory \u2014 produced before any evaluation artifact is created", "classification_questionnaire_responses document answering all required dimensions: intended_use_cases, affected_populations, decision_automation_level, human_oversight_mechanisms, deployment_jurisdiction, compute_budget, parameter_count", "non_high_risk_exclusion_rationale for systems classified below high-risk, explicitly addressing each relevant Annex III category with documented rationale for exclusion", "classification_review_records for all re-classification events documenting trigger_event, prior_classification, new_classification, and rationale with effective_date", "iso_42005_impact_assessment for high-impact-decision and eu-high-risk profile systems per ISO/IEC 42005:2025" ], "evidence": [ { "id": "EV-09-E1", "description": "signed_classification_record containing eu_ai_act_classification with specific provision references, sr_262_tier where applicable, capability_tier, applicable_profiles list, mandatory_controls inventory, and obligations_inventory \u2014 produced before any evaluation artifact is created", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-09-E2", "description": "classification_questionnaire_responses document answering all required dimensions: intended_use_cases, affected_populations, decision_automation_level, human_oversight_mechanisms, deployment_jurisdiction, compute_budget, parameter_count", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E3", "description": "non_high_risk_exclusion_rationale for systems classified below high-risk, explicitly addressing each relevant Annex III category with documented rationale for exclusion", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E4", "description": "classification_review_records for all re-classification events documenting trigger_event, prior_classification, new_classification, and rationale with effective_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-09-E5", "description": "iso_42005_impact_assessment for high-impact-decision and eu-high-risk profile systems per ISO/IEC 42005:2025", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "SR 26-2 Sec. VI (Governance and Controls) describes applying model risk management with an intensity commensurate with a model's materiality and risk. EV-09's classification produces and maintains the documented risk basis that risk-commensurate governance depends on; the guidance does not prescribe a specific tiering scheme. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope." } ] }, { "requirement_id": "SR26-INV-03", "section": "Sec. VII", "title": "Third-Party and Vendor Model Inventory", "text": "The guidance describes the expectation that institutions include all third-party and vendor-supplied AI/ML models in the model inventory, subject to the same risk tiering, governance, and validation expectations as internally developed models. Contracts should support access for validation and examination.", "verdict": "supported", "coverage": "direct", "notes": "MR-06 (Third-Party and Vendor AI Model Risk Management) directly addresses vendor model governance including contractual access for validation. LI-03 (Supply Chain Integrity) provides cryptographic verification of third-party model provenance. OA-06 (Third-Party Model and Vendor Risk Oversight) covers ongoing vendor model oversight obligations.", "control_count": 3, "proof_chain": [ { "control": "apeiris://finance/controls/MR-06", "id": "MR-06", "domain": "finance", "name": "Third-Party and Vendor AI Model Risk Management", "validation_objective": "All third-party vendor AI models used in material financial decisions must be registered in the model inventory with a completed MRM due diligence record; contractual provisions for change notification and validation support must be confirmed in place for all material vendor models; and compensating controls must be documented and technically operational for opaque vendor models where direct validation access is unavailable.", "blocking_effect": "requires-review", "evidence_required": [ "third_party_model_inventory_record for each vendor AI model showing vendor_name, model_version, api_endpoint, risk_tier, due_diligence_status, and contract_review_date", "vendor_due_diligence_checklist_completed covering model documentation quality, validation evidence provided, bias and fairness testing results, EU AI Act conformity documentation, and change notification process assessment", "vendor_ai_contract_review_record confirming presence of change_notification_clause, audit_rights_clause, and data_residency_requirements for each material vendor model contract", "compensating_control_documentation for opaque vendor models showing output_validation_layer_design, shadow_model_comparison_methodology, and human_review_threshold_definitions", "vendor_change_notification_log recording all received vendor model update notifications with linked mrm_impact_assessment_records showing assessment_date within 5 business days of notification_date" ], "evidence": [ { "id": "MR-06-E1", "description": "third_party_model_inventory_record for each vendor AI model showing vendor_name, model_version, api_endpoint, risk_tier, due_diligence_status, and contract_review_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-06-E2", "description": "vendor_due_diligence_checklist_completed covering model documentation quality, validation evidence provided, bias and fairness testing results, EU AI Act conformity documentation, and change notification process assessment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-06-E3", "description": "vendor_ai_contract_review_record confirming presence of change_notification_clause, audit_rights_clause, and data_residency_requirements for each material vendor model contract", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-06-E4", "description": "compensating_control_documentation for opaque vendor models showing output_validation_layer_design, shadow_model_comparison_methodology, and human_review_threshold_definitions", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-06-E5", "description": "vendor_change_notification_log recording all received vendor model update notifications with linked mrm_impact_assessment_records showing assessment_date within 5 business days of notification_date", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "SR 26-2 \u00a7VII addresses models obtained from vendors and other third parties, describing expectations that institutions understand vendor models, their limitations, and their appropriate use, and apply commensurate validation and monitoring. Footnote 3 of the guidance excludes generative AI and agentic systems from its stated scope, so vendor LLMs are covered by this control as institutional practice extending the \u00a7VII discipline, not by the guidance itself." }, { "control": "apeiris://model/controls/LI-03", "id": "LI-03", "domain": "model", "name": "Supply Chain Integrity \u2014 Third-Party Model Verification and Cryptographic...", "validation_objective": "Every third-party model artifact must be verified against a publisher-signed SHA-256 digest obtained from an authoritative source that is distinct from the artifact download location before registration, and any artifact failing verification must be quarantined and blocked; a model SBOM (mSBOM) enumerating all artifact components with individual hashes, SPDX license identifiers, and provenance metadata must be generated and stored as an immutable attachment to the registry entry.", "blocking_effect": "blocks-deployment", "evidence_required": [ "supply_chain_verification_record documenting the publisher-signed checksum retrieval URL (distinct from artifact download location), the comparison result, the verifier identity, and the verification timestamp for each acquired third-party artifact", "model_msbom with individual per-component entries for each weights shard, tokenizer file, and configuration file including SHA-256 hash, SPDX license identifier, declared provenance, and the verification method used", "pipeline_quarantine_log showing detection and quarantine of an artifact with a hash mismatch or absent publisher signature (from test injection or a real event)", "model_registry_entry with an immutable mSBOM attachment link, mSBOM creation timestamp, and reference to the corresponding supply_chain_verification_record" ], "evidence": [ { "id": "LI-03-E1", "description": "supply_chain_verification_record documenting the publisher-signed checksum retrieval URL (distinct from artifact download location), the comparison result, the verifier identity, and the verification timestamp for each acquired third-party artifact", "evidence_type": "third-party-audit-report", "verification": "third-party" }, { "id": "LI-03-E2", "description": "model_msbom with individual per-component entries for each weights shard, tokenizer file, and configuration file including SHA-256 hash, SPDX license identifier, declared provenance, and the verification method used", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "LI-03-E3", "description": "pipeline_quarantine_log showing detection and quarantine of an artifact with a hash mismatch or absent publisher signature (from test injection or a real event)", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "LI-03-E4", "description": "model_registry_entry with an immutable mSBOM attachment link, mSBOM creation timestamp, and reference to the corresponding supply_chain_verification_record", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://model/controls/OA-06", "id": "OA-06", "domain": "model", "name": "Third-Party Model and Vendor Risk Oversight", "validation_objective": "Every third-party AI model or component used in production must appear in the model inventory with vendor, model version, intake date, and use case documented. All active third-party vendors must have completed due diligence records and current annual risk reviews. Production integrations must implement version pinning verified against the registry, and vendor contracts must include model change notification, audit rights, and incident notification SLA clauses.", "blocking_effect": "blocks-deployment", "evidence_required": [ "third_party_ai_model_inventory current snapshot with fields: vendor, model_name, model_version, api_version, intake_date, use_cases, production_status \u2014 covering all active third-party AI components", "vendor_due_diligence_record for each active vendor, including security practices assessment, data governance review, model documentation review, and governance/safety practice assessment for high-risk use cases", "contract_clause_compliance_checklist for each vendor agreement, confirming presence of: 30-day material change notification, audit rights or third-party audit acceptance, 24-hour security incident SLA, and data residency/confidentiality terms", "annual_vendor_risk_review_report for each active vendor covering the preceding 12 months, with risk rating, material incidents noted, and recommended actions" ], "evidence": [ { "id": "OA-06-E1", "description": "third_party_ai_model_inventory current snapshot with fields: vendor, model_name, model_version, api_version, intake_date, use_cases, production_status \u2014 covering all active third-party AI components", "evidence_type": "third-party-audit-report", "verification": "third-party" }, { "id": "OA-06-E2", "description": "vendor_due_diligence_record for each active vendor, including security practices assessment, data governance review, model documentation review, and governance/safety practice assessment for high-risk use cases", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-06-E3", "description": "contract_clause_compliance_checklist for each vendor agreement, confirming presence of: 30-day material change notification, audit rights or third-party audit acceptance, 24-hour security incident SLA, and data residency/confidentiality terms", "evidence_type": "third-party-audit-report", "verification": "third-party" }, { "id": "OA-06-E4", "description": "annual_vendor_risk_review_report for each active vendor covering the preceding 12 months, with risk rating, material incidents noted, and recommended actions", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "SR 26-2 Sec. VII (Vendor and Other Third-Party Products) describes due diligence, ongoing monitoring, and documentation expectations for vendor and third-party models. OA-06's vendor inventory, due diligence, and contract requirements operationalize that section. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope." } ] }, { "requirement_id": "SR26-GOV-01", "section": "Sec. VI", "title": "Board-Level Oversight of Model Risk", "text": "The board of directors, or a committee thereof, should maintain active oversight of the institution's model risk management program, including approval of model risk appetite, review of aggregate model risk exposure, and accountability for MRM program adequacy.", "verdict": "supported", "coverage": "direct", "notes": "FG-03 (Board-Level Oversight of Financial AI Risk) maps directly to this requirement. CG-03 (Senior and Board-Level Accountability for AI Compliance) reinforces the accountability chain. PE-06 (Board and Senior Management Policy Reporting) provides the evidence structure for board-level reporting cycles required under SR 26-2.", "control_count": 3, "proof_chain": [ { "control": "apeiris://finance/controls/FG-03", "id": "FG-03", "domain": "finance", "name": "Board-Level Oversight of Financial AI Risk", "validation_objective": "The board risk or audit committee has received a structured AI risk reporting package at least quarterly, containing model inventory status, material model failures, validation backlogs, and key risk indicators with trend, and has formally acknowledged receipt in board meeting minutes. The board risk appetite statement must explicitly address AI or model risk and have been reviewed within the prior 12 months.", "blocking_effect": "requires-review", "evidence_required": [ "board_ai_risk_report with delivery_date, content_checklist_completion_status, and committee_recipient_identification for each quarter in scope", "board_meeting_minutes confirming AI risk discussion with date, attending_committee_members, and formal_acknowledgment_of_reporting_package for each quarter", "board_risk_appetite_statement with ai_risk_section present, last_reviewed_date within 12 months, and approving_body identifier", "incident_escalation_log showing any material AI failures with board_notification_date and board_response_documented flag for each high-severity event" ], "evidence": [ { "id": "FG-03-E1", "description": "board_ai_risk_report with delivery_date, content_checklist_completion_status, and committee_recipient_identification for each quarter in scope", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FG-03-E2", "description": "board_meeting_minutes confirming AI risk discussion with date, attending_committee_members, and formal_acknowledgment_of_reporting_package for each quarter", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FG-03-E3", "description": "board_risk_appetite_statement with ai_risk_section present, last_reviewed_date within 12 months, and approving_body identifier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FG-03-E4", "description": "incident_escalation_log showing any material AI failures with board_notification_date and board_response_documented flag for each high-severity event", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "SR 26-2 \u00a7VI describes the board's oversight role \u2014 understanding significant model risk, approving the framework, and receiving reporting from senior management \u2014 under Roles and Responsibilities. Structured board reporting supports that expectation; the quarterly cadence in this control is an internal practice choice, not a cadence set by the guidance." }, { "control": "apeiris://compliance/controls/CG-03", "id": "CG-03", "domain": "compliance", "name": "Senior and Board-Level Accountability for AI Compliance", "validation_objective": "The board of directors has a formal, documented mandate for AI compliance oversight via committee resolution, an executive owner is designated in their role charter with AI compliance accountability, and at least one quarterly board compliance report has been presented within the current 90-day window with meeting minutes documenting AI compliance as a substantive agenda item and material risks discussed.", "blocking_effect": "requires-review", "evidence_required": [ "board_resolution_document with committee_name, effective_date, scope (AI compliance oversight mandate), and authorizing_signatories confirming formal assignment of AI compliance oversight", "executive_role_charter or position_description for CCO or designated executive containing explicit AI compliance accountability language and board reporting obligation, with effective_date and incumbent name", "compliance_committee_meeting_minutes from each of the prior four quarters documenting AI compliance agenda item, attendance by designated executive, and material risks discussed or acknowledged", "ai_compliance_dashboard report presented to board, timestamped within the prior 90 days, with KPI section, regulatory obligation status, and material risk disclosures" ], "evidence": [ { "id": "CG-03-E1", "description": "board_resolution_document with committee_name, effective_date, scope (AI compliance oversight mandate), and authorizing_signatories confirming formal assignment of AI compliance oversight", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-03-E2", "description": "executive_role_charter or position_description for CCO or designated executive containing explicit AI compliance accountability language and board reporting obligation, with effective_date and incumbent name", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-03-E3", "description": "compliance_committee_meeting_minutes from each of the prior four quarters documenting AI compliance agenda item, attendance by designated executive, and material risks discussed or acknowledged", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-03-E4", "description": "ai_compliance_dashboard report presented to board, timestamped within the prior 90 days, with KPI section, regulatory obligation status, and material risk disclosures", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://authority/controls/PE-06", "id": "PE-06", "domain": "authority", "name": "Board and Senior Management Policy Reporting", "validation_objective": "Quarterly AI policy governance reports must be produced on schedule, reviewed, and co-signed by both the Chief Risk Officer and General Counsel, with every reported metric traceable to a supporting evidence item in the PE-04 integrated package. All risk items exceeding the board-approved materiality thresholds must appear in the report with prioritized escalation recommendations and documented board response within 30 days.", "blocking_effect": "requires-review", "evidence_required": [ "board_ai_policy_governance_report with executive summary, risk-adjusted metrics, open gap inventory, and escalation recommendations, dated within the quarterly reporting cycle and referencing the PE-04 integrated package version used", "report_sign_off_log showing CRO identity, General Counsel identity, individual sign-off timestamps, and SHA-256 hash of the signed report version to detect post-signature modification", "materiality_threshold_schedule approved by the CRO and version-controlled, defining numeric thresholds for AI policy risk metrics that trigger mandatory board-level reporting and escalation", "report_distribution_log recording recipient role, distribution timestamp, and acknowledgment status for each quarterly report to confirm the board actually received the report" ], "evidence": [ { "id": "PE-06-E1", "description": "board_ai_policy_governance_report with executive summary, risk-adjusted metrics, open gap inventory, and escalation recommendations, dated within the quarterly reporting cycle and referencing the PE-04 integrated package version used", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PE-06-E2", "description": "report_sign_off_log showing CRO identity, General Counsel identity, individual sign-off timestamps, and SHA-256 hash of the signed report version to detect post-signature modification", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PE-06-E3", "description": "materiality_threshold_schedule approved by the CRO and version-controlled, defining numeric thresholds for AI policy risk metrics that trigger mandatory board-level reporting and escalation", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PE-06-E4", "description": "report_distribution_log recording recipient role, distribution timestamp, and acknowledgment status for each quarterly report to confirm the board actually received the report", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "SR26-GOV-02", "section": "Sec. VI", "title": "Model Risk Management Function", "text": "The guidance describes the expectation that institutions establish a dedicated model risk management function with clear mandate, sufficient resources, and organizational independence from model development and business lines. The MRM function owns the model risk framework, validation program, and model risk reporting.", "verdict": "supported", "coverage": "direct", "notes": "FG-01 (Finance AI Governance Structure) establishes the governance structure within which the MRM function operates. MV-01 (Independent Validation Function Charter) defines the charter, independence requirements, and mandate for the validation arm of the MRM function. CG-01 (Compliance Governance Structure) reinforces the three-lines-of-defense model required by SR 26-2.", "control_count": 3, "proof_chain": [ { "control": "apeiris://finance/controls/FG-01", "id": "FG-01", "domain": "finance", "name": "Finance AI Governance Structure", "validation_objective": "A chartered Model Risk Committee exists with named senior officers, board-level accountability, documented scope covering all financial AI systems, and the AI system register is complete and examination-ready; the committee has met within the last 90 days with documented minutes and action tracking.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Model Risk Committee charter signed by the CFO and ratified at executive level, containing scope definition, named senior officers, accountability assignments, and governance meeting cadence", "AI system register listing all in-scope financial AI systems with named model owner, named validator, and named senior risk officer for each system, last reconciled within 90 days", "Quarterly governance meeting minutes with attendance record, action item log, and escalation threshold documentation for the last four quarters", "Role-accountability matrix mapping each AI financial system to its named model owner, validator, and senior risk officer", "Annual governance charter review documentation confirming alignment with the enterprise risk framework and board risk charter" ], "evidence": [ { "id": "FG-01-E1", "description": "Model Risk Committee charter signed by the CFO and ratified at executive level, containing scope definition, named senior officers, accountability assignments, and governance meeting cadence", "evidence_type": "human-review-record", "verification": "human" }, { "id": "FG-01-E2", "description": "AI system register listing all in-scope financial AI systems with named model owner, named validator, and named senior risk officer for each system, last reconciled within 90 days", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FG-01-E3", "description": "Quarterly governance meeting minutes with attendance record, action item log, and escalation threshold documentation for the last four quarters", "evidence_type": "audit-log", "verification": "automated" }, { "id": "FG-01-E4", "description": "Role-accountability matrix mapping each AI financial system to its named model owner, validator, and senior risk officer", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FG-01-E5", "description": "Annual governance charter review documentation confirming alignment with the enterprise risk framework and board risk charter", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "SR 26-2 \u00a7VI describes governance and controls \u2014 board and senior management oversight, policies and procedures, and defined roles and responsibilities. A chartered Model Risk Committee with named accountable parties operationalizes those expectations. The guidance is supervisory and principles-based, not an enforceable rule." }, { "control": "apeiris://finance/controls/MV-01", "id": "MV-01", "domain": "finance", "name": "Independent Validation Function Charter", "validation_objective": "The model validation function must be established with a board- or risk-committee-approved charter documenting organizational independence from model development and business lines, with all validation staff reporting to the CRO or an independent risk committee rather than to technology or business leadership. The charter must define scope, authority, minimum staffing levels, and escalation rights enabling validators to require model suspension.", "blocking_effect": "blocks-deployment", "evidence_required": [ "board_or_risk_committee_approved_charter document with effective date, scope statement, reporting line definition, and named escalation authority for validation override decisions", "organizational_chart confirming the validation function reporting line is separate from model development and business line management chains with no shared manager below the CRO level", "headcount_and_competency_record listing all validation function staff, their qualifications, and attestation that none hold concurrent model development responsibilities", "annual_charter_review_record documenting review date, reviewer role, findings, and any charter amendments approved by the risk committee", "validation_authority_exercise_log showing instances where the validation function raised adverse findings, suspended models, or escalated to the board" ], "evidence": [ { "id": "MV-01-E1", "description": "board_or_risk_committee_approved_charter document with effective date, scope statement, reporting line definition, and named escalation authority for validation override decisions", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MV-01-E2", "description": "organizational_chart confirming the validation function reporting line is separate from model development and business line management chains with no shared manager below the CRO level", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MV-01-E3", "description": "headcount_and_competency_record listing all validation function staff, their qualifications, and attestation that none hold concurrent model development responsibilities", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MV-01-E4", "description": "annual_charter_review_record documenting review date, reviewer role, findings, and any charter amendments approved by the risk committee", "evidence_type": "human-review-record", "verification": "human" }, { "id": "MV-01-E5", "description": "validation_authority_exercise_log showing instances where the validation function raised adverse findings, suspended models, or escalated to the board", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "SR 26-2 \u00a7V describes validation carried out with appropriate independence from model development and use, with the validation function having the authority, competence, and resources to evaluate models effectively. A formal charter is the artifact that establishes and evidences that independence." }, { "control": "apeiris://compliance/controls/CG-01", "id": "CG-01", "domain": "compliance", "name": "Compliance Governance Structure", "validation_objective": "The organization must have a formally chartered Compliance Committee with documented meeting minutes showing quorum was achieved in at least 80% of scheduled sessions in the last 12 months, a CCO or equivalent with a documented direct reporting channel to the board Audit and Risk Committee that bypasses management for material issues, and a current escalation matrix reviewed within 12 months covering all material compliance issue types including AI regulatory incidents.", "blocking_effect": "requires-review", "evidence_required": [ "compliance_committee_charter signed and approved by the board with defined membership composition, quorum rules, meeting cadence, decision authority scope, and AI regulatory obligation coverage", "cco_role_documentation including the CCO written authority scope, direct reporting line to the Audit and Risk Committee as documented in board resolution or equivalent formal governance instrument, and organizational chart placement", "compliance_committee_meeting_minutes for the last 12 months showing attendees, quorum status at each session, agenda items including AI compliance matters, and action item tracking with completion status", "escalation_matrix covering all material compliance issue types \u2014 regulatory inquiry, enforcement action, material AI risk event, data breach \u2014 with defined escalation paths, response timeframes, and responsible parties for each tier", "board_resolution or formal charter ratification record establishing the compliance governance structure with effective date and scope of authority" ], "evidence": [ { "id": "CG-01-E1", "description": "compliance_committee_charter signed and approved by the board with defined membership composition, quorum rules, meeting cadence, decision authority scope, and AI regulatory obligation coverage", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-01-E2", "description": "cco_role_documentation including the CCO written authority scope, direct reporting line to the Audit and Risk Committee as documented in board resolution or equivalent formal governance instrument, and organizational chart placement", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-01-E3", "description": "compliance_committee_meeting_minutes for the last 12 months showing attendees, quorum status at each session, agenda items including AI compliance matters, and action item tracking with completion status", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-01-E4", "description": "escalation_matrix covering all material compliance issue types \u2014 regulatory inquiry, enforcement action, material AI risk event, data breach \u2014 with defined escalation paths, response timeframes, and responsible parties for each tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-01-E5", "description": "board_resolution or formal charter ratification record establishing the compliance governance structure with effective date and scope of authority", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "SR26-GOV-03", "section": "Sec. VI", "title": "Model Risk Appetite and Policy Framework", "text": "The guidance describes the expectation that institutions define and document a model risk appetite statement and supporting MRM policy framework that establishes risk tolerance thresholds, escalation criteria, and minimum standards for model development, validation, and use across the enterprise.", "verdict": "supported", "coverage": "direct", "notes": "MR-04 (Model Risk Appetite and Material Model Thresholds) directly codifies the risk appetite statement and materiality thresholds. FP-03 (Financial AI Risk Appetite Statement) provides the formal policy-layer risk appetite definition. FP-01 (AI Use Policy for Financial Decision-Making) establishes the policy framework within which model use is governed.", "control_count": 3, "proof_chain": [ { "control": "apeiris://finance/controls/MR-04", "id": "MR-04", "domain": "finance", "name": "Model Risk Appetite and Material Model Thresholds", "validation_objective": "A board-approved Model Risk Appetite Statement must be in force specifying quantitative materiality thresholds and a maximum acceptable model error impact expressed in dollars or basis points; model risk metrics must be actively monitored against these thresholds with documented escalation events occurring within the SLA defined in the statement whenever thresholds are breached.", "blocking_effect": "requires-review", "evidence_required": [ "board_risk_appetite_statement with explicit materiality criteria, maximum tolerable model error impact thresholds in quantitative terms, and escalation trigger definitions, showing board_approval_date within the last 12 months", "model_risk_monitoring_report showing current model risk metrics measured against defined appetite thresholds with Red/Amber/Green status per model, dated within the last calendar month", "threshold_breach_escalation_record for any breach events in the prior 12 months showing escalation_initiated_timestamp within the SLA and board_notification_record", "material_model_classification_list showing all models meeting materiality criteria with classification rationale and assigning Model Owner accountability", "annual_threshold_review_record documenting MRO assessment of threshold appropriateness and board re-approval of updated risk appetite thresholds" ], "evidence": [ { "id": "MR-04-E1", "description": "board_risk_appetite_statement with explicit materiality criteria, maximum tolerable model error impact thresholds in quantitative terms, and escalation trigger definitions, showing board_approval_date within the last 12 months", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-04-E2", "description": "model_risk_monitoring_report showing current model risk metrics measured against defined appetite thresholds with Red/Amber/Green status per model, dated within the last calendar month", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-04-E3", "description": "threshold_breach_escalation_record for any breach events in the prior 12 months showing escalation_initiated_timestamp within the SLA and board_notification_record", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-04-E4", "description": "material_model_classification_list showing all models meeting materiality criteria with classification rationale and assigning Model Owner accountability", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-04-E5", "description": "annual_threshold_review_record documenting MRO assessment of threshold appropriateness and board re-approval of updated risk appetite thresholds", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "SR 26-2 \u00a7III (Overview of Model Risk and Model Risk Management) frames model risk management as risk-based \u2014 with intensity of governance, validation, and monitoring commensurate with a model's materiality and complexity. Explicit risk appetite and materiality thresholds are the mechanism institutions use to operationalize that risk-based framing." }, { "control": "apeiris://finance/controls/FP-03", "id": "FP-03", "domain": "finance", "name": "Financial AI Risk Appetite Statement", "validation_objective": "The board or its designated risk committee must have approved a current Financial AI Risk Appetite Statement that quantifies the maximum acceptable exposure from AI use in financial decision-making \u2014 including materiality thresholds, error rate tolerances, and category-specific limits \u2014 with AI systems configured to alert when operating parameters approach appetite boundaries and to escalate to the board when limits are breached.", "blocking_effect": "requires-review", "evidence_required": [ "financial_ai_risk_appetite_statement board_approval_record showing approval date, approving body, vote record or unanimous consent confirmation, and version number", "risk_appetite_parameter_table showing each quantified risk metric (maximum AI-driven decision error rate, materiality threshold, maximum model output variance tolerance, category-specific exposure limits) with current measured values and defined breach thresholds", "risk_appetite_monitoring_report showing current AI system risk metrics against appetite limits, breach events in the current period, and escalation actions taken for each breach", "annual_risk_appetite_review_record documenting the review cycle, risk appetite changes approved, and triggering events (material model changes, regulatory updates, loss events) that prompted out-of-cycle reviews" ], "evidence": [ { "id": "FP-03-E1", "description": "financial_ai_risk_appetite_statement board_approval_record showing approval date, approving body, vote record or unanimous consent confirmation, and version number", "evidence_type": "human-review-record", "verification": "human" }, { "id": "FP-03-E2", "description": "risk_appetite_parameter_table showing each quantified risk metric (maximum AI-driven decision error rate, materiality threshold, maximum model output variance tolerance, category-specific exposure limits) with current measured values and defined breach thresholds", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FP-03-E3", "description": "risk_appetite_monitoring_report showing current AI system risk metrics against appetite limits, breach events in the current period, and escalation actions taken for each breach", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FP-03-E4", "description": "annual_risk_appetite_review_record documenting the review cycle, risk appetite changes approved, and triggering events (material model changes, regulatory updates, loss events) that prompted out-of-cycle reviews", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "SR 26-2 \u00a7III frames model risk as a risk to be managed like other risks \u2014 identified, measured, and kept within tolerance. A board-approved risk appetite statement for financial AI operationalizes that framing; the guidance itself does not mandate a specific appetite artifact." }, { "control": "apeiris://finance/controls/FP-01", "id": "FP-01", "domain": "finance", "name": "AI Use Policy for Financial Decision-Making", "validation_objective": "The organization must have a current board-approved policy that explicitly classifies each financial decision type as AI-driven, AI-assisted, or human-only, and the classification must be operationally enforced \u2014 meaning AI-driven and AI-assisted decisions are technically constrained to operate only within the authorized limits defined in the policy \u2014 with the policy reviewed and re-approved by the board at least annually.", "blocking_effect": "blocks-deployment", "evidence_required": [ "board_approval_record for the AI Use Policy for Financial Decision-Making showing board meeting date, resolution text, and signatures of authorizing board members or formally delegated committee representatives", "financial_decision_classification_table listing each financial decision type in scope, its classification (AI-driven/AI-assisted/human-only), the conditions and limits under which AI may operate, and the oversight requirements for each decision class", "policy_enforcement_configuration showing how AI-driven and AI-assisted decision limits are technically enforced in production systems \u2014 including approval thresholds, override requirements, and audit trail configuration", "annual_policy_review_record documenting the review date, reviewer names, changes made, and board re-approval confirmation" ], "evidence": [ { "id": "FP-01-E1", "description": "board_approval_record for the AI Use Policy for Financial Decision-Making showing board meeting date, resolution text, and signatures of authorizing board members or formally delegated committee representatives", "evidence_type": "human-review-record", "verification": "human" }, { "id": "FP-01-E2", "description": "financial_decision_classification_table listing each financial decision type in scope, its classification (AI-driven/AI-assisted/human-only), the conditions and limits under which AI may operate, and the oversight requirements for each decision class", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FP-01-E3", "description": "policy_enforcement_configuration showing how AI-driven and AI-assisted decision limits are technically enforced in production systems \u2014 including approval thresholds, override requirements, and audit trail configuration", "evidence_type": "audit-log", "verification": "automated" }, { "id": "FP-01-E4", "description": "annual_policy_review_record documenting the review date, reviewer names, changes made, and board re-approval confirmation", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "SR 26-2 \u00a7VI describes policies that define how models are used and governed, including appropriate restrictions, as part of governance and controls. Classifying financial decisions by AI authority level is an implementation of that model-use policy discipline." } ] }, { "requirement_id": "SR26-GOV-04", "section": "Sec. VI", "title": "Roles, Responsibilities, and Accountability", "text": "The guidance describes the expectation that institutions define and assign clear roles for model owners, developers, validators, users, and senior management. Named accountable individuals should be identifiable for each model tier, and accountability should extend to third-party models where the institution bears the risk.", "verdict": "supported", "coverage": "direct", "notes": "FG-02 (Senior and Named Accountability for Financial AI Decisions) establishes named accountability for high-tier models. OA-01 (Model Ownership Assignment) assigns model owner roles with clear responsibilities. OA-03 (AI Model Governance Committee) provides the committee structure for cross-functional model governance required under SR 26-2.", "control_count": 3, "proof_chain": [ { "control": "apeiris://finance/controls/FG-02", "id": "FG-02", "domain": "finance", "name": "Senior and Named Accountability for Financial AI Decisions", "validation_objective": "Every AI system that influences material financial decisions has a named C-suite or SVP accountable officer with a current signed accountability acknowledgment stored in the tamper-evident register, the accountability coverage rate is 100% for material systems, and every named officer can describe the scope and performance thresholds of their assigned system.", "blocking_effect": "blocks-deployment", "evidence_required": [ "Signed accountability acknowledgments for each material AI financial system, each containing: system_id, officer_name, officer_title (C-suite or SVP), scope_of_accountability, performance_threshold_summary, and acknowledgment_date within the last 12 months", "Tamper-evident accountability register listing all material AI systems cross-referenced against financial statement line items, with version history and access logs", "Quarterly accountability completeness report showing coverage rate against total material AI system population, signed by the Model Risk Officer", "Period-close certification records for each material AI system confirming that the named accountable officer certified model performance within acceptable bounds before financial statement sign-off", "Succession and interim-coverage plan for each material AI system documenting the named interim officer when the primary accountable officer is unavailable" ], "evidence": [ { "id": "FG-02-E1", "description": "Signed accountability acknowledgments for each material AI financial system, each containing: system_id, officer_name, officer_title (C-suite or SVP), scope_of_accountability, performance_threshold_summary, and acknowledgment_date within the last 12 months", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FG-02-E2", "description": "Tamper-evident accountability register listing all material AI systems cross-referenced against financial statement line items, with version history and access logs", "evidence_type": "audit-log", "verification": "automated" }, { "id": "FG-02-E3", "description": "Quarterly accountability completeness report showing coverage rate against total material AI system population, signed by the Model Risk Officer", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FG-02-E4", "description": "Period-close certification records for each material AI system confirming that the named accountable officer certified model performance within acceptable bounds before financial statement sign-off", "evidence_type": "certification", "verification": "third-party" }, { "id": "FG-02-E5", "description": "Succession and interim-coverage plan for each material AI system documenting the named interim officer when the primary accountable officer is unavailable", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "SR 26-2 \u00a7VI describes senior management responsibility for model risk under its Roles and Responsibilities subheading, including clear assignment of responsibilities across development, validation, and use. Named C-suite accountability with signed acknowledgments operationalizes and evidences that expectation." }, { "control": "apeiris://model/controls/OA-01", "id": "OA-01", "domain": "model", "name": "Model Ownership Assignment", "validation_objective": "Every AI model in the production model registry must have a non-null named human owner who is a current employee, a responsible team, and an executive sponsor at director level or above for high-impact models, all recorded within five business days of deployment. No production model may exist without a current ownership record, and ownership must be reassigned within ten business days of any owner departure.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_ownership_register_extract with fields: model_id, owner_name, owner_employee_id, team, executive_sponsor, effective_date, review_date \u2014 showing 100% coverage of production models with non-null values", "deployment_pipeline_gate_log showing blocked promotion events for models with null ownership fields, with timestamps and model IDs", "hr_departure_event_log cross-referenced with ownership_reassignment_record demonstrating reassignment within ten business days for each departure", "governance_committee_meeting_minutes containing ownership review agenda items for the preceding 12-month period" ], "evidence": [ { "id": "OA-01-E1", "description": "model_ownership_register_extract with fields: model_id, owner_name, owner_employee_id, team, executive_sponsor, effective_date, review_date \u2014 showing 100% coverage of production models with non-null values", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-01-E2", "description": "deployment_pipeline_gate_log showing blocked promotion events for models with null ownership fields, with timestamps and model IDs", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-01-E3", "description": "hr_departure_event_log cross-referenced with ownership_reassignment_record demonstrating reassignment within ten business days for each departure", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-01-E4", "description": "governance_committee_meeting_minutes containing ownership review agenda items for the preceding 12-month period", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "SR 26-2 Sec. VI (Governance and Controls) describes clearly assigned roles and responsibilities across model owners, developers, validators, and users. OA-01's named-owner register operationalizes the ownership component of that expectation. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope." }, { "control": "apeiris://model/controls/OA-03", "id": "OA-03", "domain": "model", "name": "AI Model Governance Committee", "validation_objective": "The organization must have a formally chartered AI Model Governance Committee with documented membership covering all required functional areas, exclusive approval authority over high-risk model deployments and risk appetite thresholds, and auditable meeting minutes retained for seven years. The committee must have met at minimum quarterly in each of the preceding four quarters, with quorum achieved for all binding decisions.", "blocking_effect": "blocks-deployment", "evidence_required": [ "committee_charter current version with executive-level approval signature and date, specifying membership composition, decision rights matrix, quorum requirements, and meeting cadence", "meeting_minutes for all scheduled quarterly sessions in the preceding 12-month period, demonstrating quorum was met and binding decisions were recorded with rationale", "decision_log showing AIGC approval records for all high-risk model deployments and risk appetite changes in the preceding 12 months, cross-referenced against the production model registry", "membership_roster with functional affiliations confirming representation from AI/ML engineering, model validation, legal/compliance, risk management, and at least one business line" ], "evidence": [ { "id": "OA-03-E1", "description": "committee_charter current version with executive-level approval signature and date, specifying membership composition, decision rights matrix, quorum requirements, and meeting cadence", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-03-E2", "description": "meeting_minutes for all scheduled quarterly sessions in the preceding 12-month period, demonstrating quorum was met and binding decisions were recorded with rationale", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-03-E3", "description": "decision_log showing AIGC approval records for all high-risk model deployments and risk appetite changes in the preceding 12 months, cross-referenced against the production model registry", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-03-E4", "description": "membership_roster with functional affiliations confirming representation from AI/ML engineering, model validation, legal/compliance, risk management, and at least one business line", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "SR 26-2 Sec. VI (Governance and Controls) describes board and senior management responsibility for the model risk management framework. OA-03's chartered governance committee provides the standing senior forum that this oversight expectation contemplates. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope." } ] }, { "requirement_id": "SR26-CS-01", "section": "Sec. IV", "title": "Methodology Documentation and Conceptual Soundness", "text": "The guidance describes the expectation that institutions document model methodology, including the theoretical basis, mathematical formulation, key design choices, intended use scope, and known limitations. Documentation should be sufficient for an independent validator to assess conceptual soundness without relying on the developer.", "verdict": "supported", "coverage": "direct", "notes": "MV-02 (Conceptual Soundness Assessment) is the primary control requiring assessment of theoretical basis, design choices, and methodology for AI/ML models. LI-04 (Structured Model Documentation \u2014 Complete Model Card) mandates comprehensive model cards covering all sections needed for independent review. EV-02 (Fitness, Safety, Reliability and Policy-Conformance Evaluation) covers evaluation of intended use scope and known limitations.", "control_count": 3, "proof_chain": [ { "control": "apeiris://finance/controls/MV-02", "id": "MV-02", "domain": "finance", "name": "Conceptual Soundness Assessment", "validation_objective": "Every model must have a documented conceptual soundness assessment completed by the independent validation function before initial production deployment and before each major version change, concluding with an explicit suitability opinion stating whether the model is appropriate for its intended use. All identified conceptual weaknesses must be documented with assigned owners and tracked to verified remediation before or concurrent with deployment approval.", "blocking_effect": "blocks-deployment", "evidence_required": [ "conceptual_soundness_report per model version signed by the validation lead, covering theoretical basis, assumptions inventory, data input assessment, mathematical formulation review, and a formal suitability opinion", "assumptions_inventory record listing all model design assumptions with validity conditions and the date each assumption was validated against current production data conditions", "use_case_boundary_document defining intended use, out-of-scope applications, and conditions under which the model must not be used, approved by the validation function", "deficiency_tracking_record for any conceptual weaknesses identified, showing remediation status, responsible owner, and target resolution date with closure evidence" ], "evidence": [ { "id": "MV-02-E1", "description": "conceptual_soundness_report per model version signed by the validation lead, covering theoretical basis, assumptions inventory, data input assessment, mathematical formulation review, and a formal suitability opinion", "evidence_type": "human-review-record", "verification": "human" }, { "id": "MV-02-E2", "description": "assumptions_inventory record listing all model design assumptions with validity conditions and the date each assumption was validated against current production data conditions", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MV-02-E3", "description": "use_case_boundary_document defining intended use, out-of-scope applications, and conditions under which the model must not be used, approved by the validation function", "evidence_type": "human-review-record", "verification": "human" }, { "id": "MV-02-E4", "description": "deficiency_tracking_record for any conceptual weaknesses identified, showing remediation status, responsible owner, and target resolution date with closure evidence", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "SR 26-2 \u00a7V (Validation and Monitoring) identifies conceptual soundness \u2014 evaluating the quality of a model's design, theory, and construction \u2014 under its Conceptual Soundness subheading as a core element of validation. This control directly implements that element." }, { "control": "apeiris://model/controls/LI-04", "id": "LI-04", "domain": "model", "name": "Structured Model Documentation \u2014 Complete Model Card with All Required Sections", "validation_objective": "Every model submitted for registration must have a schema-validated model card with all nine Mitchell et al. 2019 sections substantively populated and passing field-level validation rules; the model card must be version-locked to the artifact hash and returned as structured metadata from the registry API; and registration must be blocked when any required section is absent, empty, or contains only placeholder text.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_card_completeness_validation_report showing pass/fail status per section with field-level validation results, registration blocking decision, and validation timestamp for the current artifact version", "versioned_model_card artifact linked to the specific model artifact hash with all nine Mitchell et al. sections containing substantive content (not placeholder text), retrievable from the registry by artifact hash", "model_registry_entry showing the current model card version hash stored alongside the artifact hash as paired immutable fields", "eu_ai_act_annex_iv_supplemental_record for EU AI Act high-risk in-scope systems confirming Annex IV technical documentation fields are populated in addition to the nine Mitchell et al. sections" ], "evidence": [ { "id": "LI-04-E1", "description": "model_card_completeness_validation_report showing pass/fail status per section with field-level validation results, registration blocking decision, and validation timestamp for the current artifact version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-04-E2", "description": "versioned_model_card artifact linked to the specific model artifact hash with all nine Mitchell et al. sections containing substantive content (not placeholder text), retrievable from the registry by artifact hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-04-E3", "description": "model_registry_entry showing the current model card version hash stored alongside the artifact hash as paired immutable fields", "evidence_type": "model-card", "verification": "attested" }, { "id": "LI-04-E4", "description": "eu_ai_act_annex_iv_supplemental_record for EU AI Act high-risk in-scope systems confirming Annex IV technical documentation fields are populated in addition to the nine Mitchell et al. sections", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "SR 26-2 Sec. IV (Model Development and Model Use) describes documentation of model purpose, design, assumptions, limitations, and performance as part of sound development practice. The Mitchell et al. model card structure organizes exactly this development documentation into a versioned, schema-validated artifact. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope." }, { "control": "apeiris://model/controls/EV-02", "id": "EV-02", "domain": "model", "name": "Fitness, Safety, Reliability and Policy-Conformance Evaluation", "validation_objective": "Before deployment, every model has been evaluated against pre-specified, dimension-level pass/fail thresholds \u2014 fitness, safety, reliability, and policy-conformance \u2014 with results documented against the model artifact hash and evaluation suite version. No threshold is modified after evaluation begins, and any threshold trade-off decision is documented as a named risk-acceptance record before the deployment manifest is signed.", "blocking_effect": "blocks-deployment", "evidence_required": [ "pre_specified_evaluation_protocol with model_artifact_hash, evaluation_suite_version, and per-dimension thresholds (fitness accuracy target, safety refusal rate, reliability error budget, policy-conformance violation rate), signed by the evaluation lead before testing begins \u2014 not after results are known", "dimension_level_evaluation_results showing per-dimension metric values, pass/fail verdict against pre-specified threshold, and model_artifact_hash confirming results correspond to the evaluated version", "evaluation_suite_provenance_record confirming that evaluation datasets are disjoint from training data, with contamination-check reference to TG-05 attestation", "risk_acceptance_record for any dimension where the pass threshold was not met but deployment was authorized, documenting named risk-accepter, specific capability gap, deployment risk consequence, and remediation deadline" ], "evidence": [ { "id": "EV-02-E1", "description": "pre_specified_evaluation_protocol with model_artifact_hash, evaluation_suite_version, and per-dimension thresholds (fitness accuracy target, safety refusal rate, reliability error budget, policy-conformance violation rate), signed by the evaluation lead before testing begins \u2014 not after results are known", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-02-E2", "description": "dimension_level_evaluation_results showing per-dimension metric values, pass/fail verdict against pre-specified threshold, and model_artifact_hash confirming results correspond to the evaluated version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-02-E3", "description": "evaluation_suite_provenance_record confirming that evaluation datasets are disjoint from training data, with contamination-check reference to TG-05 attestation", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-02-E4", "description": "risk_acceptance_record for any dimension where the pass threshold was not met but deployment was authorized, documenting named risk-accepter, specific capability gap, deployment risk consequence, and remediation deadline", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "SR 26-2 Sec. V (Model Validation and Monitoring) describes evaluation of conceptual soundness and analysis of model outcomes. EV-02's structured fitness, safety, reliability, and policy-conformance dimensions operationalize that validation scope. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope." } ] }, { "requirement_id": "SR26-CS-02", "section": "Sec. IV", "title": "Assumption Documentation and Stress Testing", "text": "The guidance describes the expectation that institutions identify, document, and periodically stress-test all model assumptions, including distributional assumptions for AI/ML models. Stress testing should address out-of-distribution inputs, covariate shift, and performance under adverse or novel conditions beyond the training distribution.", "verdict": "partial", "coverage": "partial", "notes": "MV-02 covers conceptual soundness assessment including assumption review. EV-06 (Reproducible Evaluation Design) addresses evaluation design assumptions and reproducibility. TG-01 (Training Data Quality Gates) covers distributional properties of training data. However, SR 26-2 \u00a75.2 specifically requires formal out-of-distribution stress testing and covariate shift analysis for AI/ML models \u2014 a more prescriptive regime than Apeiris controls currently specify in full. Partial gap in explicit OOD stress-test evidence requirements.", "control_count": 3, "proof_chain": [ { "control": "apeiris://finance/controls/MV-02", "id": "MV-02", "domain": "finance", "name": "Conceptual Soundness Assessment", "validation_objective": "Every model must have a documented conceptual soundness assessment completed by the independent validation function before initial production deployment and before each major version change, concluding with an explicit suitability opinion stating whether the model is appropriate for its intended use. All identified conceptual weaknesses must be documented with assigned owners and tracked to verified remediation before or concurrent with deployment approval.", "blocking_effect": "blocks-deployment", "evidence_required": [ "conceptual_soundness_report per model version signed by the validation lead, covering theoretical basis, assumptions inventory, data input assessment, mathematical formulation review, and a formal suitability opinion", "assumptions_inventory record listing all model design assumptions with validity conditions and the date each assumption was validated against current production data conditions", "use_case_boundary_document defining intended use, out-of-scope applications, and conditions under which the model must not be used, approved by the validation function", "deficiency_tracking_record for any conceptual weaknesses identified, showing remediation status, responsible owner, and target resolution date with closure evidence" ], "evidence": [ { "id": "MV-02-E1", "description": "conceptual_soundness_report per model version signed by the validation lead, covering theoretical basis, assumptions inventory, data input assessment, mathematical formulation review, and a formal suitability opinion", "evidence_type": "human-review-record", "verification": "human" }, { "id": "MV-02-E2", "description": "assumptions_inventory record listing all model design assumptions with validity conditions and the date each assumption was validated against current production data conditions", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MV-02-E3", "description": "use_case_boundary_document defining intended use, out-of-scope applications, and conditions under which the model must not be used, approved by the validation function", "evidence_type": "human-review-record", "verification": "human" }, { "id": "MV-02-E4", "description": "deficiency_tracking_record for any conceptual weaknesses identified, showing remediation status, responsible owner, and target resolution date with closure evidence", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "SR 26-2 \u00a7V (Validation and Monitoring) identifies conceptual soundness \u2014 evaluating the quality of a model's design, theory, and construction \u2014 under its Conceptual Soundness subheading as a core element of validation. This control directly implements that element." }, { "control": "apeiris://model/controls/EV-06", "id": "EV-06", "domain": "model", "name": "Reproducible Evaluation Design", "validation_objective": "Every evaluation run against a model artifact can be independently reproduced from the evaluation design document alone within the defined tolerance by a party who was not involved in the original run; all benchmarks have documented contamination screening results; and all evaluation artifacts are signed with SHA-256 content-addressed hashes recorded in the evaluation manifest.", "blocking_effect": "blocks-deployment", "evidence_required": [ "version_controlled_benchmark_selection_document with pre-specified selection_criteria, benchmark_ids, known_limitations, and alternatives_considered \u2014 signed and committed before any evaluation run begins", "contamination_screening_report documenting screening_methodology, training_corpus_reference, per-benchmark contamination_result (clean/flagged/excluded), and screening_date", "evaluation_design_document capturing all reproduction parameters: random_seeds, software_dependency_versions with hashes, hardware_configuration, serving_framework_config, eval_script_version_and_hash, prompt_templates, and post_processing_steps", "independent_reproduction_run_record showing reproduction_results within the defined tolerance alongside original_results, confirming design document sufficiency for independent replication", "signed_evaluation_artifact_manifest listing SHA-256 hashes for all artifacts (design document, scripts, datasets, results) with signer_identity and key_identifier" ], "evidence": [ { "id": "EV-06-E1", "description": "version_controlled_benchmark_selection_document with pre-specified selection_criteria, benchmark_ids, known_limitations, and alternatives_considered \u2014 signed and committed before any evaluation run begins", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-06-E2", "description": "contamination_screening_report documenting screening_methodology, training_corpus_reference, per-benchmark contamination_result (clean/flagged/excluded), and screening_date", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-06-E3", "description": "evaluation_design_document capturing all reproduction parameters: random_seeds, software_dependency_versions with hashes, hardware_configuration, serving_framework_config, eval_script_version_and_hash, prompt_templates, and post_processing_steps", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-06-E4", "description": "independent_reproduction_run_record showing reproduction_results within the defined tolerance alongside original_results, confirming design document sufficiency for independent replication", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-06-E5", "description": "signed_evaluation_artifact_manifest listing SHA-256 hashes for all artifacts (design document, scripts, datasets, results) with signer_identity and key_identifier", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "SR 26-2 Sec. V (Model Validation and Monitoring) describes documenting validation work in enough detail for others to review and rely on it. EV-06's reproducibility manifest gives validators the artifacts needed to independently re-run and confirm reported results. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope." }, { "control": "apeiris://model/controls/TG-01", "id": "TG-01", "domain": "model", "name": "Training Data Quality Gates", "validation_objective": "No training run may be initiated unless the designated training dataset has passed automated schema validation, completeness checks, and provenance verification in the current pipeline run; all gate results must be logged with pass/fail status and linked to the training job record.", "blocking_effect": "blocks-deployment", "evidence_required": [ "training_data_quality_gate_report for the current training run showing schema validation results (expected vs. actual field types and cardinalities), completeness check results (null rates, minimum coverage thresholds), and provenance verification status (source hash match, chain-of-custody record reference)", "training_pipeline_block_log confirming that any training attempt that failed a quality gate was rejected before the training compute job was allocated", "dataset_provenance_record with source identifier, ingestion timestamp, data owner, and integrity hash for each training shard used in the run", "quality_threshold_configuration_document defining the pass/fail thresholds for schema validation, completeness, and provenance checks, reviewed and approved by the ML engineering lead" ], "evidence": [ { "id": "TG-01-E1", "description": "training_data_quality_gate_report for the current training run showing schema validation results (expected vs. actual field types and cardinalities), completeness check results (null rates, minimum coverage thresholds), and provenance verification status (source hash match, chain-of-custody record reference)", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "TG-01-E2", "description": "training_pipeline_block_log confirming that any training attempt that failed a quality gate was rejected before the training compute job was allocated", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-01-E3", "description": "dataset_provenance_record with source identifier, ingestion timestamp, data owner, and integrity hash for each training shard used in the run", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-01-E4", "description": "quality_threshold_configuration_document defining the pass/fail thresholds for schema validation, completeness, and provenance checks, reviewed and approved by the ML engineering lead", "evidence_type": "data-lineage-record", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "SR 26-2 Sec. IV (Model Development and Model Use) describes assessment and documentation of the suitability and quality of data used in model development. TG-01's automated quality gates operationalize that expectation as blocking pipeline checks. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope." } ] }, { "requirement_id": "SR26-CS-03", "section": "Sec. IV", "title": "Training Data Quality and Representativeness", "text": "The guidance describes the expectation that institutions assess and document the quality, representativeness, completeness, and timeliness of data used to train AI/ML models. Data used should be fit for purpose, and any known gaps or biases in training data should be documented, assessed for risk impact, and monitored over time.", "verdict": "supported", "coverage": "direct", "notes": "TG-01 (Training Data Quality Gates) directly mandates quality gates on training data including completeness, timeliness, and fitness-for-purpose criteria. TG-02 (Bias and Representativeness Assessment) addresses representativeness assessment and known bias documentation requirements. MV-02 requires validators to independently assess training data quality as part of conceptual soundness review.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/TG-01", "id": "TG-01", "domain": "model", "name": "Training Data Quality Gates", "validation_objective": "No training run may be initiated unless the designated training dataset has passed automated schema validation, completeness checks, and provenance verification in the current pipeline run; all gate results must be logged with pass/fail status and linked to the training job record.", "blocking_effect": "blocks-deployment", "evidence_required": [ "training_data_quality_gate_report for the current training run showing schema validation results (expected vs. actual field types and cardinalities), completeness check results (null rates, minimum coverage thresholds), and provenance verification status (source hash match, chain-of-custody record reference)", "training_pipeline_block_log confirming that any training attempt that failed a quality gate was rejected before the training compute job was allocated", "dataset_provenance_record with source identifier, ingestion timestamp, data owner, and integrity hash for each training shard used in the run", "quality_threshold_configuration_document defining the pass/fail thresholds for schema validation, completeness, and provenance checks, reviewed and approved by the ML engineering lead" ], "evidence": [ { "id": "TG-01-E1", "description": "training_data_quality_gate_report for the current training run showing schema validation results (expected vs. actual field types and cardinalities), completeness check results (null rates, minimum coverage thresholds), and provenance verification status (source hash match, chain-of-custody record reference)", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "TG-01-E2", "description": "training_pipeline_block_log confirming that any training attempt that failed a quality gate was rejected before the training compute job was allocated", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-01-E3", "description": "dataset_provenance_record with source identifier, ingestion timestamp, data owner, and integrity hash for each training shard used in the run", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-01-E4", "description": "quality_threshold_configuration_document defining the pass/fail thresholds for schema validation, completeness, and provenance checks, reviewed and approved by the ML engineering lead", "evidence_type": "data-lineage-record", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "equivalent_to", "rationale": "SR 26-2 Sec. IV (Model Development and Model Use) describes assessment and documentation of the suitability and quality of data used in model development. TG-01's automated quality gates operationalize that expectation as blocking pipeline checks. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope." }, { "control": "apeiris://model/controls/TG-02", "id": "TG-02", "domain": "model", "name": "Bias and Representativeness Assessment", "validation_objective": "Before each training run and after each data refresh, a documented subgroup and intersectional fairness analysis is completed for the training dataset, producing a bias baseline report that identifies population coverage gaps and subgroup representation rates; this report must be reviewed and accepted before training proceeds.", "blocking_effect": "blocks-deployment", "evidence_required": [ "bias_assessment_report containing subgroup representation rates across all demographic dimensions relevant to the model's use case, intersectional analysis results, identification of underrepresented populations, and comparison to the prior baseline where applicable", "data_refresh_trigger_record showing that a new bias assessment was initiated whenever the training dataset was updated, not only at initial training", "bias_baseline_acceptance_record with reviewer identity, acceptance timestamp, and documented acknowledgment of any known representation gaps and their accepted risk level", "subgroup_definition_document specifying which demographic dimensions and proxy features were analyzed, reviewed against the model's deployment context and affected populations" ], "evidence": [ { "id": "TG-02-E1", "description": "bias_assessment_report containing subgroup representation rates across all demographic dimensions relevant to the model's use case, intersectional analysis results, identification of underrepresented populations, and comparison to the prior baseline where applicable", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-02-E2", "description": "data_refresh_trigger_record showing that a new bias assessment was initiated whenever the training dataset was updated, not only at initial training", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "TG-02-E3", "description": "bias_baseline_acceptance_record with reviewer identity, acceptance timestamp, and documented acknowledgment of any known representation gaps and their accepted risk level", "evidence_type": "human-review-record", "verification": "human" }, { "id": "TG-02-E4", "description": "subgroup_definition_document specifying which demographic dimensions and proxy features were analyzed, reviewed against the model's deployment context and affected populations", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "SR 26-2 Sec. IV (Model Development and Model Use) describes documenting the characteristics and limitations of development data, including whether it is representative of the intended use. TG-02's subgroup representativeness analysis provides that evidence for supervised institutions. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope." }, { "control": "apeiris://finance/controls/MV-02", "id": "MV-02", "domain": "finance", "name": "Conceptual Soundness Assessment", "validation_objective": "Every model must have a documented conceptual soundness assessment completed by the independent validation function before initial production deployment and before each major version change, concluding with an explicit suitability opinion stating whether the model is appropriate for its intended use. All identified conceptual weaknesses must be documented with assigned owners and tracked to verified remediation before or concurrent with deployment approval.", "blocking_effect": "blocks-deployment", "evidence_required": [ "conceptual_soundness_report per model version signed by the validation lead, covering theoretical basis, assumptions inventory, data input assessment, mathematical formulation review, and a formal suitability opinion", "assumptions_inventory record listing all model design assumptions with validity conditions and the date each assumption was validated against current production data conditions", "use_case_boundary_document defining intended use, out-of-scope applications, and conditions under which the model must not be used, approved by the validation function", "deficiency_tracking_record for any conceptual weaknesses identified, showing remediation status, responsible owner, and target resolution date with closure evidence" ], "evidence": [ { "id": "MV-02-E1", "description": "conceptual_soundness_report per model version signed by the validation lead, covering theoretical basis, assumptions inventory, data input assessment, mathematical formulation review, and a formal suitability opinion", "evidence_type": "human-review-record", "verification": "human" }, { "id": "MV-02-E2", "description": "assumptions_inventory record listing all model design assumptions with validity conditions and the date each assumption was validated against current production data conditions", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MV-02-E3", "description": "use_case_boundary_document defining intended use, out-of-scope applications, and conditions under which the model must not be used, approved by the validation function", "evidence_type": "human-review-record", "verification": "human" }, { "id": "MV-02-E4", "description": "deficiency_tracking_record for any conceptual weaknesses identified, showing remediation status, responsible owner, and target resolution date with closure evidence", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "SR 26-2 \u00a7V (Validation and Monitoring) identifies conceptual soundness \u2014 evaluating the quality of a model's design, theory, and construction \u2014 under its Conceptual Soundness subheading as a core element of validation. This control directly implements that element." } ] }, { "requirement_id": "SR26-CS-04", "section": "Sec. IV", "title": "Output Integrity and Use Limitations", "text": "Model outputs should be assessed for interpretability, appropriate uncertainty quantification, and fitness for their intended decision use. Model use should be constrained to the validated scope; use beyond intended boundaries requires re-assessment. Limitations should be communicated to model users.", "verdict": "supported", "coverage": "direct", "notes": "LI-07 (Capability and Limitation Declaration \u2014 Intended Use, Constraints) mandates formal declaration of intended use scope and known limitations communicated to users. EV-02 (Fitness, Safety, Reliability and Policy-Conformance Evaluation) covers output integrity and fitness-for-use assessment including uncertainty. FD-01 (AI-Driven Decision Transparency and Auditability) ensures transparency of model outputs to decision makers and downstream users.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/LI-07", "id": "LI-07", "domain": "model", "name": "Capability and Limitation Declaration \u2014 Intended Use, Constraints,...", "validation_objective": "Every registered model must have a structured, schema-validated capability-limitation declaration with all five required dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, and knowledge_cutoff) substantively populated with population- and context-qualified entries, returned as structured metadata in the model registry API response; registration must be blocked when any dimension is absent or empty; and the model's observable behavior for post-knowledge-cutoff queries must be consistent with the declared uncertainty_bounds.", "blocking_effect": "blocks-deployment", "evidence_required": [ "capability_limitation_declaration with all five dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, knowledge_cutoff) substantively populated with population-qualified and context-qualified entries, version-locked to the artifact hash", "registry_api_response_sample demonstrating that the capability_limitation_declaration object is returned as structured metadata in the model registry API response for the model's registered ID without requiring separate documentation lookup", "cutoff_behavior_test_result showing model responses to at least three post-knowledge-cutoff factual queries compared against the declared uncertainty_bounds, confirming the model acknowledges the limitation rather than confabulating confident answers", "registration_rejection_log showing that a model registration attempt with an empty out_of_scope_uses field was blocked with an error identifying the specific missing dimension" ], "evidence": [ { "id": "LI-07-E1", "description": "capability_limitation_declaration with all five dimensions (intended_uses, stated_limitations, out_of_scope_uses, uncertainty_bounds, knowledge_cutoff) substantively populated with population-qualified and context-qualified entries, version-locked to the artifact hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E2", "description": "registry_api_response_sample demonstrating that the capability_limitation_declaration object is returned as structured metadata in the model registry API response for the model's registered ID without requiring separate documentation lookup", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E3", "description": "cutoff_behavior_test_result showing model responses to at least three post-knowledge-cutoff factual queries compared against the declared uncertainty_bounds, confirming the model acknowledges the limitation rather than confabulating confident answers", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "LI-07-E4", "description": "registration_rejection_log showing that a model registration attempt with an empty out_of_scope_uses field was blocked with an error identifying the specific missing dimension", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null }, { "control": "apeiris://model/controls/EV-02", "id": "EV-02", "domain": "model", "name": "Fitness, Safety, Reliability and Policy-Conformance Evaluation", "validation_objective": "Before deployment, every model has been evaluated against pre-specified, dimension-level pass/fail thresholds \u2014 fitness, safety, reliability, and policy-conformance \u2014 with results documented against the model artifact hash and evaluation suite version. No threshold is modified after evaluation begins, and any threshold trade-off decision is documented as a named risk-acceptance record before the deployment manifest is signed.", "blocking_effect": "blocks-deployment", "evidence_required": [ "pre_specified_evaluation_protocol with model_artifact_hash, evaluation_suite_version, and per-dimension thresholds (fitness accuracy target, safety refusal rate, reliability error budget, policy-conformance violation rate), signed by the evaluation lead before testing begins \u2014 not after results are known", "dimension_level_evaluation_results showing per-dimension metric values, pass/fail verdict against pre-specified threshold, and model_artifact_hash confirming results correspond to the evaluated version", "evaluation_suite_provenance_record confirming that evaluation datasets are disjoint from training data, with contamination-check reference to TG-05 attestation", "risk_acceptance_record for any dimension where the pass threshold was not met but deployment was authorized, documenting named risk-accepter, specific capability gap, deployment risk consequence, and remediation deadline" ], "evidence": [ { "id": "EV-02-E1", "description": "pre_specified_evaluation_protocol with model_artifact_hash, evaluation_suite_version, and per-dimension thresholds (fitness accuracy target, safety refusal rate, reliability error budget, policy-conformance violation rate), signed by the evaluation lead before testing begins \u2014 not after results are known", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-02-E2", "description": "dimension_level_evaluation_results showing per-dimension metric values, pass/fail verdict against pre-specified threshold, and model_artifact_hash confirming results correspond to the evaluated version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-02-E3", "description": "evaluation_suite_provenance_record confirming that evaluation datasets are disjoint from training data, with contamination-check reference to TG-05 attestation", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-02-E4", "description": "risk_acceptance_record for any dimension where the pass threshold was not met but deployment was authorized, documenting named risk-accepter, specific capability gap, deployment risk consequence, and remediation deadline", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "SR 26-2 Sec. V (Model Validation and Monitoring) describes evaluation of conceptual soundness and analysis of model outcomes. EV-02's structured fitness, safety, reliability, and policy-conformance dimensions operationalize that validation scope. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope." }, { "control": "apeiris://finance/controls/FD-01", "id": "FD-01", "domain": "finance", "name": "AI-Driven Decision Transparency and Auditability", "validation_objective": "Every AI-driven financial decision must generate a decision audit record at execution time capturing the model_id, model_version, complete input feature set hash, output value, confidence score, and a decision rationale reference sufficient to reconstruct the decision logic. These records must be retained for the period required by applicable financial regulation and must be retrievable within the timeframes required for regulatory examination, litigation hold, and consumer dispute resolution.", "blocking_effect": "blocks-runtime-action", "evidence_required": [ "decision_audit_log entries for each AI-driven financial decision containing model_id, model_version, decision_timestamp, input_features_hash, output_value, confidence_score, and decision_rationale_reference", "retention_policy_document specifying retention periods by decision type mapped to applicable regulatory requirements including ECOA, SOX, and applicable state statutes", "decision_retrieval_drill_record demonstrating that individual decision records can be retrieved by decision_id within the required response timeframe under simulated examination conditions", "model_version_registry confirming that every model_version referenced in decision audit records corresponds to a documented and validated model artifact" ], "evidence": [ { "id": "FD-01-E1", "description": "decision_audit_log entries for each AI-driven financial decision containing model_id, model_version, decision_timestamp, input_features_hash, output_value, confidence_score, and decision_rationale_reference", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FD-01-E2", "description": "retention_policy_document specifying retention periods by decision type mapped to applicable regulatory requirements including ECOA, SOX, and applicable state statutes", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FD-01-E3", "description": "decision_retrieval_drill_record demonstrating that individual decision records can be retrieved by decision_id within the required response timeframe under simulated examination conditions", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FD-01-E4", "description": "model_version_registry confirming that every model_version referenced in decision audit records corresponds to a documented and validated model artifact", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "SR26-VAL-01", "section": "Sec. V", "title": "Independent Validation Function", "text": "Model validation should be performed by personnel or units that are independent of model development and business use. Validation should be free from conflicts of interest, with sufficient stature and resources to challenge model developers and escalate findings to senior management.", "verdict": "supported", "coverage": "direct", "notes": "MV-01 (Independent Validation Function Charter) is the primary control establishing independence requirements, mandate, and escalation authority for the validation function. EV-08 (Independent Validation) mandates that evaluation be performed independently of model development. CI-06 (Internal Audit of AI Compliance Controls) provides the third-line audit layer over the validation function itself.", "control_count": 3, "proof_chain": [ { "control": "apeiris://finance/controls/MV-01", "id": "MV-01", "domain": "finance", "name": "Independent Validation Function Charter", "validation_objective": "The model validation function must be established with a board- or risk-committee-approved charter documenting organizational independence from model development and business lines, with all validation staff reporting to the CRO or an independent risk committee rather than to technology or business leadership. The charter must define scope, authority, minimum staffing levels, and escalation rights enabling validators to require model suspension.", "blocking_effect": "blocks-deployment", "evidence_required": [ "board_or_risk_committee_approved_charter document with effective date, scope statement, reporting line definition, and named escalation authority for validation override decisions", "organizational_chart confirming the validation function reporting line is separate from model development and business line management chains with no shared manager below the CRO level", "headcount_and_competency_record listing all validation function staff, their qualifications, and attestation that none hold concurrent model development responsibilities", "annual_charter_review_record documenting review date, reviewer role, findings, and any charter amendments approved by the risk committee", "validation_authority_exercise_log showing instances where the validation function raised adverse findings, suspended models, or escalated to the board" ], "evidence": [ { "id": "MV-01-E1", "description": "board_or_risk_committee_approved_charter document with effective date, scope statement, reporting line definition, and named escalation authority for validation override decisions", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MV-01-E2", "description": "organizational_chart confirming the validation function reporting line is separate from model development and business line management chains with no shared manager below the CRO level", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MV-01-E3", "description": "headcount_and_competency_record listing all validation function staff, their qualifications, and attestation that none hold concurrent model development responsibilities", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MV-01-E4", "description": "annual_charter_review_record documenting review date, reviewer role, findings, and any charter amendments approved by the risk committee", "evidence_type": "human-review-record", "verification": "human" }, { "id": "MV-01-E5", "description": "validation_authority_exercise_log showing instances where the validation function raised adverse findings, suspended models, or escalated to the board", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "SR 26-2 \u00a7V describes validation carried out with appropriate independence from model development and use, with the validation function having the authority, competence, and resources to evaluate models effectively. A formal charter is the artifact that establishes and evidences that independence." }, { "control": "apeiris://model/controls/EV-08", "id": "EV-08", "domain": "model", "name": "Independent Validation", "validation_objective": "Every model deployment authorization is signed by a validator who is organizationally independent of the model development function with no shared management chain at a meaningful level; the validator has documented authority to withhold authorization and escalate findings to a governance committee; and the deployment pipeline rejects any manifest where the validator and development lead share the same organizational identity.", "blocking_effect": "blocks-deployment", "evidence_required": [ "organizational_chart_and_reporting_structure_document confirming validator independence from the development team for each model system, with management_chain_separation explicitly documented to a meaningful organizational level", "validation_function_authority_policy document version-controlled and governance-committee-approved, explicitly granting rights to request additional evaluation runs, require remediation, and withhold deployment authorization without development team approval", "evaluation_manifests containing named, attributed validator approvals with validator_identity distinct from development_team_lead_identity, linked to verifiable PKI certificate or directory record", "escalation_path_verification_record demonstrating that a test dispute routes to the governance committee and not to the development management chain", "annual_independence_structure_review_document for us-regulated-banking profile, available to regulators and auditors on request" ], "evidence": [ { "id": "EV-08-E1", "description": "organizational_chart_and_reporting_structure_document confirming validator independence from the development team for each model system, with management_chain_separation explicitly documented to a meaningful organizational level", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-08-E2", "description": "validation_function_authority_policy document version-controlled and governance-committee-approved, explicitly granting rights to request additional evaluation runs, require remediation, and withhold deployment authorization without development team approval", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "EV-08-E3", "description": "evaluation_manifests containing named, attributed validator approvals with validator_identity distinct from development_team_lead_identity, linked to verifiable PKI certificate or directory record", "evidence_type": "certification", "verification": "third-party" }, { "id": "EV-08-E4", "description": "escalation_path_verification_record demonstrating that a test dispute routes to the governance committee and not to the development management chain", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "EV-08-E5", "description": "annual_independence_structure_review_document for us-regulated-banking profile, available to regulators and auditors on request", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "SR 26-2 Sec. V (Model Validation and Monitoring) is the primary source for this control: it describes validation performed with organizational independence, technical competence, and the standing to provide effective challenge to model developers and users. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope." }, { "control": "apeiris://compliance/controls/CI-06", "id": "CI-06", "domain": "compliance", "name": "Internal Audit of AI Compliance Controls", "validation_objective": "An internal audit covering the full CI-layer control matrix has been completed within the current annual cycle by auditors with documented AI domain competence who are independent of compliance operations. All findings include root cause analysis and have been routed to the remediation register with management responses provided within 15 business days of draft report issuance.", "blocking_effect": "requires-review", "evidence_required": [ "Annual internal audit plan signed by the Chief Audit Executive, identifying scope, risk-based prioritization, and AI competence documentation for all audit team members", "Auditor independence declarations for each team member confirming no organizational reporting line to the compliance function under review", "Audit fieldwork workpapers documenting control testing methodology, evidence reviewed, and basis for each finding classification", "Formal audit report with findings classified by severity (critical/high/medium/low), root cause analysis, and specific remediation recommendations per finding", "Management response letters providing corrective action commitments, named owners, and due dates for each finding, submitted within 15 business days of draft issuance" ], "evidence": [ { "id": "CI-06-E1", "description": "Annual internal audit plan signed by the Chief Audit Executive, identifying scope, risk-based prioritization, and AI competence documentation for all audit team members", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-06-E2", "description": "Auditor independence declarations for each team member confirming no organizational reporting line to the compliance function under review", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CI-06-E3", "description": "Audit fieldwork workpapers documenting control testing methodology, evidence reviewed, and basis for each finding classification", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CI-06-E4", "description": "Formal audit report with findings classified by severity (critical/high/medium/low), root cause analysis, and specific remediation recommendations per finding", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CI-06-E5", "description": "Management response letters providing corrective action commitments, named owners, and due dates for each finding, submitted within 15 business days of draft issuance", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "SR26-VAL-02", "section": "Sec. V", "title": "Validation Scope and Methodology", "text": "Validation scope should encompass conceptual soundness, data quality, output analysis, ongoing monitoring design, and governance. For AI/ML models, validation should additionally cover training pipeline integrity, feature engineering, model selection rationale, and fairness evaluation where applicable.", "verdict": "supported", "coverage": "direct", "notes": "MV-02 (Conceptual Soundness Assessment) defines the validation methodology for AI/ML model theory and design. MV-06 (Validation Scope for AI/ML and LLM Models) specifically extends validation scope to cover training pipeline integrity, feature engineering, and ML-specific elements required by SR 26-2. EV-01 (Pre-Deployment Evaluation Gate) ensures structured evaluation scope is applied before any deployment.", "control_count": 3, "proof_chain": [ { "control": "apeiris://finance/controls/MV-02", "id": "MV-02", "domain": "finance", "name": "Conceptual Soundness Assessment", "validation_objective": "Every model must have a documented conceptual soundness assessment completed by the independent validation function before initial production deployment and before each major version change, concluding with an explicit suitability opinion stating whether the model is appropriate for its intended use. All identified conceptual weaknesses must be documented with assigned owners and tracked to verified remediation before or concurrent with deployment approval.", "blocking_effect": "blocks-deployment", "evidence_required": [ "conceptual_soundness_report per model version signed by the validation lead, covering theoretical basis, assumptions inventory, data input assessment, mathematical formulation review, and a formal suitability opinion", "assumptions_inventory record listing all model design assumptions with validity conditions and the date each assumption was validated against current production data conditions", "use_case_boundary_document defining intended use, out-of-scope applications, and conditions under which the model must not be used, approved by the validation function", "deficiency_tracking_record for any conceptual weaknesses identified, showing remediation status, responsible owner, and target resolution date with closure evidence" ], "evidence": [ { "id": "MV-02-E1", "description": "conceptual_soundness_report per model version signed by the validation lead, covering theoretical basis, assumptions inventory, data input assessment, mathematical formulation review, and a formal suitability opinion", "evidence_type": "human-review-record", "verification": "human" }, { "id": "MV-02-E2", "description": "assumptions_inventory record listing all model design assumptions with validity conditions and the date each assumption was validated against current production data conditions", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MV-02-E3", "description": "use_case_boundary_document defining intended use, out-of-scope applications, and conditions under which the model must not be used, approved by the validation function", "evidence_type": "human-review-record", "verification": "human" }, { "id": "MV-02-E4", "description": "deficiency_tracking_record for any conceptual weaknesses identified, showing remediation status, responsible owner, and target resolution date with closure evidence", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "SR 26-2 \u00a7V (Validation and Monitoring) identifies conceptual soundness \u2014 evaluating the quality of a model's design, theory, and construction \u2014 under its Conceptual Soundness subheading as a core element of validation. This control directly implements that element." }, { "control": "apeiris://finance/controls/MV-06", "id": "MV-06", "domain": "finance", "name": "Validation Scope for AI/ML and LLM Models", "validation_objective": "The validation function must maintain a versioned AI/ML and LLM validation methodology supplement that extends a standard SR 26-2-style validation framework -- which by its footnote 3 does not cover generative AI -- to training data assessment, feature importance and explainability, fairness and bias testing, prompt injection risk, and behavioral consistency. Every AI/ML and LLM model must be validated against this supplemental methodology before production deployment, with the validation report explicitly addressing each supplemental domain with pass/fail findings.", "blocking_effect": "blocks-deployment", "evidence_required": [ "ai_ml_validation_methodology_document versioned and approved by the head of model validation, covering training data assessment, tier-based explainability requirements, fairness testing protocols, LLM behavioral testing, and third-party model due diligence procedures", "training_data_assessment_report per AI/ML model showing data provenance, class distribution analysis, bias assessment results, and documented known training data limitations", "fairness_testing_report per model per validation cycle showing protected attribute disparate impact metrics against defined thresholds and remediation actions for identified disparate effects", "llm_behavioral_testing_report for LLM-based models showing prompt injection resistance test results, behavioral consistency scores under adversarial prompt reformulations, and output quality evaluation against defined rubrics", "explainability_assessment per model documenting the explainability method, its adequacy for the model tier and use-case, and evidence that the method supports meaningful explanations for decision subjects" ], "evidence": [ { "id": "MV-06-E1", "description": "ai_ml_validation_methodology_document versioned and approved by the head of model validation, covering training data assessment, tier-based explainability requirements, fairness testing protocols, LLM behavioral testing, and third-party model due diligence procedures", "evidence_type": "third-party-audit-report", "verification": "third-party" }, { "id": "MV-06-E2", "description": "training_data_assessment_report per AI/ML model showing data provenance, class distribution analysis, bias assessment results, and documented known training data limitations", "evidence_type": "data-lineage-record", "verification": "automated" }, { "id": "MV-06-E3", "description": "fairness_testing_report per model per validation cycle showing protected attribute disparate impact metrics against defined thresholds and remediation actions for identified disparate effects", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MV-06-E4", "description": "llm_behavioral_testing_report for LLM-based models showing prompt injection resistance test results, behavioral consistency scores under adversarial prompt reformulations, and output quality evaluation against defined rubrics", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "MV-06-E5", "description": "explainability_assessment per model documenting the explainability method, its adequacy for the model tier and use-case, and evidence that the method supports meaningful explanations for decision subjects", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "satisfies", "rationale": "Scope note: SR 26-2 footnote 3 excludes generative AI and agentic systems from the guidance's stated scope, so SR 26-2 does not itself cover LLM validation. \u00a7V's validation elements (conceptual soundness, outcomes analysis, ongoing monitoring) remain the closest supervisory reference point; MV-06 exists to fill the gap the guidance leaves by extending validation methodology to AI/ML and LLM models as institutional practice." }, { "control": "apeiris://model/controls/EV-01", "id": "EV-01", "domain": "model", "name": "Pre-Deployment Evaluation Gate", "validation_objective": "No model artifact is promoted to production unless a signed evaluation manifest referencing that artifact's exact hash is present in the tamper-evident evaluation log and has received dual approval from named, authorized approvers. The deployment pipeline enforces this as a cryptographic gate \u2014 an absent, unsigned, or hash-mismatched manifest results in an automatic pipeline block with no override path except a logged exception with named risk-accepter.", "blocking_effect": "blocks-deployment", "evidence_required": [ "signed_evaluation_manifest with model_artifact_hash, evaluation_suite_version, evaluator_identities, per-dimension pass/fail outcome, signing_key_id, and manifest_signature (Ed25519) for every production model version", "tamper_evident_evaluation_log entry linking manifest_id to model_artifact_hash, recording append timestamp, appender identity, and log integrity proof", "dual_approval_record with two named approver identities, their organizational roles, approval timestamps, and the manifest_hash each approver authorized", "pipeline_execution_log showing at least one successful gate enforcement event: a deployment attempt with an absent or invalid manifest that was blocked, confirming the gate is operational rather than advisory" ], "evidence": [ { "id": "EV-01-E1", "description": "signed_evaluation_manifest with model_artifact_hash, evaluation_suite_version, evaluator_identities, per-dimension pass/fail outcome, signing_key_id, and manifest_signature (Ed25519) for every production model version", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-01-E2", "description": "tamper_evident_evaluation_log entry linking manifest_id to model_artifact_hash, recording append timestamp, appender identity, and log integrity proof", "evidence_type": "audit-log", "verification": "automated" }, { "id": "EV-01-E3", "description": "dual_approval_record with two named approver identities, their organizational roles, approval timestamps, and the manifest_hash each approver authorized", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EV-01-E4", "description": "pipeline_execution_log showing at least one successful gate enforcement event: a deployment attempt with an absent or invalid manifest that was blocked, confirming the gate is operational rather than advisory", "evidence_type": "configuration-snapshot", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "SR 26-2 Sec. V (Model Validation and Monitoring) describes validation of models before they are placed into use, with documented results. EV-01's pre-deployment evaluation gate operationalizes that expectation as a blocking release control. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope." } ] }, { "requirement_id": "SR26-VAL-03", "section": "Sec. V", "title": "Challenger Models and Benchmarking", "text": "Where feasible, validators should develop or assess challenger models and benchmark alternatives to evaluate whether the production model performs better than alternatives given its risk profile. The guidance describes the expectation that institutions document why the selected model was preferred over alternatives.", "verdict": "supported", "coverage": "direct", "notes": "MV-04 (Benchmarking and Challenger Models) directly addresses the requirement to assess challenger models and document benchmarking rationale. EV-04 (Adversarial Red-Team Testing) complements challenger model assessment by stress-testing the production model's robustness claims that would be relevant in a challenger comparison.", "control_count": 2, "proof_chain": [ { "control": "apeiris://finance/controls/MV-04", "id": "MV-04", "domain": "finance", "name": "Benchmarking and Challenger Models", "validation_objective": "At each validation cycle the validation function must assess production model performance against at least one defined benchmark and one challenger model using held-out test sets inaccessible to model development teams, and issue a formal comparative performance opinion documenting whether the production model remains the best available option for its intended use. Challenger selection criteria and comparison metrics must be specified and approved before each cycle begins.", "blocking_effect": "requires-review", "evidence_required": [ "challenger_program_record per validation cycle defining challenger candidates, approved comparison metrics, and test set specification approved by the validation lead before the cycle begins", "comparative_performance_report per validation cycle showing production model vs. benchmark vs. challenger results across all defined metrics, with statistical significance indicators", "held_out_test_set_access_log confirming test sets used for benchmarking were not accessible to model development team members prior to validation cycle completion", "validation_comparative_opinion_record per cycle with the validator's signed conclusion on whether the production model remains optimal, including rationale for any recommendation to replace or maintain" ], "evidence": [ { "id": "MV-04-E1", "description": "challenger_program_record per validation cycle defining challenger candidates, approved comparison metrics, and test set specification approved by the validation lead before the cycle begins", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "MV-04-E2", "description": "comparative_performance_report per validation cycle showing production model vs. benchmark vs. challenger results across all defined metrics, with statistical significance indicators", "evidence_type": "evaluation-scorecard", "verification": "automated" }, { "id": "MV-04-E3", "description": "held_out_test_set_access_log confirming test sets used for benchmarking were not accessible to model development team members prior to validation cycle completion", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "MV-04-E4", "description": "validation_comparative_opinion_record per cycle with the validator's signed conclusion on whether the production model remains optimal, including rationale for any recommendation to replace or maintain", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "SR 26-2 \u00a7V discusses benchmarking \u2014 comparison of a model's outputs to alternative estimates \u2014 within the validation elements under Conceptual Soundness. A systematic challenger-model program formalizes that comparison discipline." }, { "control": "apeiris://model/controls/EV-04", "id": "EV-04", "domain": "model", "name": "Adversarial Red-Team Testing", "validation_objective": "The model system has a signed red-team report produced by a team organizationally independent of model development, documenting structured adversarial probing that covers all required attack categories for the applicable profiles, with all critical and high findings remediated and re-tested before the deployment gate clears.", "blocking_effect": "blocks-deployment", "evidence_required": [ "signed_red_team_scope_document with threat_model version, profile scope, and pre-exercise approval timestamp", "red_team_findings_log with finding_id, severity_classification, reproduction_steps, affected_population, and remediation_status per finding", "signed_red_team_report with residual_risk_statement linked to model artifact hash and listing remediated critical and high findings with re-test results", "remediation_evidence for all critical and high findings demonstrating the vulnerability is closed via re-test, not only via input-level patch", "for frontier-capability profile: escalation_records for any capability elicited at or near threshold levels with escalation_destination and response_action" ], "evidence": [ { "id": "EV-04-E1", "description": "signed_red_team_scope_document with threat_model version, profile scope, and pre-exercise approval timestamp", "evidence_type": "human-review-record", "verification": "human" }, { "id": "EV-04-E2", "description": "red_team_findings_log with finding_id, severity_classification, reproduction_steps, affected_population, and remediation_status per finding", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "EV-04-E3", "description": "signed_red_team_report with residual_risk_statement linked to model artifact hash and listing remediated critical and high findings with re-test results", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "EV-04-E4", "description": "remediation_evidence for all critical and high findings demonstrating the vulnerability is closed via re-test, not only via input-level patch", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "EV-04-E5", "description": "for frontier-capability profile: escalation_records for any capability elicited at or near threshold levels with escalation_destination and response_action", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "adjacent", "basis": "anchored", "relation": "equivalent_to", "rationale": "SR 26-2 Sec. V (Model Validation and Monitoring) describes testing models under a range of conditions as part of validation. Adversarial red-team testing extends that principle to hostile inputs; the guidance does not itself prescribe adversarial testing. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope." } ] }, { "requirement_id": "SR26-VAL-04", "section": "Sec. V", "title": "Validation Documentation and Finding Management", "text": "Validation findings should be documented, rated for severity, tracked to remediation, and escalated where unresolved. Validation reports should be produced for each validation engagement and retained as part of the model's evidence record. Deficiencies should have defined remediation timelines.", "verdict": "supported", "coverage": "direct", "notes": "MV-07 (Validation Finding Escalation and Remediation) covers severity rating, escalation paths, and tracked remediation for validation findings. MV-08 (Model Validation Evidence Package) mandates production of the validation report as a structured evidence artifact. CR-02 (Model Evidence Archive and Audit Trail) provides the long-term retention and retrieval of validation records.", "control_count": 3, "proof_chain": [ { "control": "apeiris://finance/controls/MV-07", "id": "MV-07", "domain": "finance", "name": "Validation Finding Escalation and Remediation", "validation_objective": "The finding management system must maintain a centralized finding register where every validation finding is classified by severity within 2 business days of issuance, has an assigned owner and management response SLA, and where all Critical and High findings have documented escalation to the model risk committee within 5 business days of issuance. No model with open Critical findings may remain in production without documented senior management acceptance-of-risk on file.", "blocking_effect": "requires-review", "evidence_required": [ "validation_finding_register with canonical finding_id, severity classification, assigned owner, SLA due date, management response record, and remediation status for each open finding", "model_risk_committee_escalation_records showing Critical and High finding notifications with timestamps confirming escalation within 5 business days of finding issuance", "acceptance_of_risk_documentation for findings not remediated, signed at the required management level and including a residual risk acknowledgment", "monthly_open_findings_aging_report distributed to senior management showing finding age, owner assignment, and remediation progress", "finding_severity_taxonomy_document defining classification criteria and required management response SLA timelines for each severity level" ], "evidence": [ { "id": "MV-07-E1", "description": "validation_finding_register with canonical finding_id, severity classification, assigned owner, SLA due date, management response record, and remediation status for each open finding", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MV-07-E2", "description": "model_risk_committee_escalation_records showing Critical and High finding notifications with timestamps confirming escalation within 5 business days of finding issuance", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MV-07-E3", "description": "acceptance_of_risk_documentation for findings not remediated, signed at the required management level and including a residual risk acknowledgment", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MV-07-E4", "description": "monthly_open_findings_aging_report distributed to senior management showing finding age, owner assignment, and remediation progress", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MV-07-E5", "description": "finding_severity_taxonomy_document defining classification criteria and required management response SLA timelines for each severity level", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "SR 26-2 \u00a7V (Validation and Monitoring) describes communicating validation results, and \u00a7VI (Governance and Controls) describes governance processes for acting on them. A finding-escalation process with documented management response and remediation tracking operationalizes both expectations." }, { "control": "apeiris://finance/controls/MV-08", "id": "MV-08", "domain": "finance", "name": "Model Validation Evidence Package", "validation_objective": "A complete, structured evidence package must exist for each validated model demonstrating that validation was independent, comprehensive, and effective across all MV layer controls. The package must be assembled and retrievable within 24 hours for a regulatory examination request, and a completeness certification signed by the lead validator must confirm that no required MV layer controls were excluded without documented rationale.", "blocking_effect": "blocks-deployment", "evidence_required": [ "model_validation_evidence_package_index listing all constituent artifacts, per-artifact SHA-256 hashes, and a completeness_certification signed by the lead validator", "independence_confirmation_record establishing that validators had no material involvement in model development and no reporting relationship with model owners during the validation period", "validation_scope_checklist confirming all MV layer controls were addressed, with documented rationale for any controls excluded or scoped out", "examination_readiness_drill_record showing the package was assembled and retrieved within a 24-hour SLA during a simulated regulatory request exercise", "senior_management_distribution_log confirming the evidence package summary was delivered to the model risk committee and appropriate senior stakeholders within the required timeframe" ], "evidence": [ { "id": "MV-08-E1", "description": "model_validation_evidence_package_index listing all constituent artifacts, per-artifact SHA-256 hashes, and a completeness_certification signed by the lead validator", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MV-08-E2", "description": "independence_confirmation_record establishing that validators had no material involvement in model development and no reporting relationship with model owners during the validation period", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MV-08-E3", "description": "validation_scope_checklist confirming all MV layer controls were addressed, with documented rationale for any controls excluded or scoped out", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MV-08-E4", "description": "examination_readiness_drill_record showing the package was assembled and retrieved within a 24-hour SLA during a simulated regulatory request exercise", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MV-08-E5", "description": "senior_management_distribution_log confirming the evidence package summary was delivered to the model risk committee and appropriate senior stakeholders within the required timeframe", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "SR 26-2 \u00a7VI addresses documentation under its Documentation subheading \u2014 validation work documented in enough detail for a knowledgeable third party to understand its scope, findings, and conclusions. The validation evidence package implements that documentation standard." }, { "control": "apeiris://model/controls/CR-02", "id": "CR-02", "domain": "model", "name": "Model Evidence Archive and Audit Trail", "validation_objective": "All evaluation results, monitoring snapshots, incident records, and regulatory submissions must be stored in an immutable, content-addressed archive with cryptographic integrity protection; any audit query for a model's historical evidence must resolve to a complete, tamper-evident chain spanning the full production lifetime of that model version.", "blocking_effect": "blocks-deployment", "evidence_required": [ "archive_integrity_configuration_record showing content-addressed storage settings, hash algorithm (minimum SHA-256), write-once immutability enforcement, and retention policy duration per record type", "evidence_chain_completeness_audit confirming that evaluation results, monitoring snapshots, and incident records for each production model version are present in the archive with no missing lifecycle entries", "tamper_detection_scan_report from periodic archive integrity verification showing all stored records produce matching content hashes with zero reported mismatches", "regulatory_submission_evidence_linkage_record linking each regulatory submission to its archived evidence artifact with submission_id, submission_date, submitting_entity, and archive_content_hash", "archive_access_control_audit_log confirming write operations are restricted to authorized pipeline components only and all access attempts are logged with actor_id and timestamp" ], "evidence": [ { "id": "CR-02-E1", "description": "archive_integrity_configuration_record showing content-addressed storage settings, hash algorithm (minimum SHA-256), write-once immutability enforcement, and retention policy duration per record type", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "CR-02-E2", "description": "evidence_chain_completeness_audit confirming that evaluation results, monitoring snapshots, and incident records for each production model version are present in the archive with no missing lifecycle entries", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-02-E3", "description": "tamper_detection_scan_report from periodic archive integrity verification showing all stored records produce matching content hashes with zero reported mismatches", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-02-E4", "description": "regulatory_submission_evidence_linkage_record linking each regulatory submission to its archived evidence artifact with submission_id, submission_date, submitting_entity, and archive_content_hash", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-02-E5", "description": "archive_access_control_audit_log confirming write operations are restricted to authorized pipeline components only and all access attempts are logged with actor_id and timestamp", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "SR 26-2 Sec. VI (Governance and Controls) describes comprehensive model documentation that supports ongoing monitoring, audit, and supervisory examination; CR-02's immutable evidence archive preserves those records with verifiable integrity. The guidance does not itself set retention periods. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope." } ] }, { "requirement_id": "SR26-MON-01", "section": "Sec. V", "title": "Ongoing Performance Monitoring", "text": "The guidance describes the expectation that institutions establish ongoing monitoring programs for all models commensurate with their risk tier. Monitoring should track model performance against defined KPIs, compare actual outputs against expected ranges, and assess whether model performance has degraded since validation.", "verdict": "supported", "coverage": "direct", "notes": "MR-05 (Ongoing Model Risk Monitoring) directly establishes the ongoing monitoring program requirement, including tiered monitoring intensity. BH-03 (Production Performance Degradation Alerting) provides the technical mechanism for detecting and alerting on performance degradation. CR-01 (Continuous Production Monitoring and Risk Aggregation) aggregates model-level monitoring signals into an enterprise model risk view.", "control_count": 3, "proof_chain": [ { "control": "apeiris://finance/controls/MR-05", "id": "MR-05", "domain": "finance", "name": "Ongoing Model Risk Monitoring", "validation_objective": "All production financial AI models classified as material must have active automated monitoring dashboards with data refreshed within the last business day pipeline cycle, all monitoring alerts must be acknowledged by model owners within 24 hours, and no material model may remain in Red monitoring status for more than 30 days without a documented re-validation decision or suspension record signed by the MRO.", "blocking_effect": "advisory", "evidence_required": [ "model_monitoring_dashboard_record for each material model showing last_data_refresh_timestamp within 26 hours of the most recent business day close", "alert_acknowledgment_log showing alert_id, alert_generated_timestamp, acknowledged_by, and acknowledgment_timestamp for all alerts in the prior 90 days, with acknowledgment latency \u2264 24 hours for \u2265 95% of entries", "monthly_model_performance_report with Red/Amber/Green status for all material models, signed by MRM team and submitted to validation committee within 5 business days of month end", "red_status_remediation_record for any model designated Red, showing decision_date, remediation_plan or suspension_decision, and MRO_approval within 30 days of Red designation", "eu_ai_act_post_market_monitoring_plan for each high-risk AI system confirming monitoring scope, metrics tracked, and reporting obligations under Article 72" ], "evidence": [ { "id": "MR-05-E1", "description": "model_monitoring_dashboard_record for each material model showing last_data_refresh_timestamp within 26 hours of the most recent business day close", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-05-E2", "description": "alert_acknowledgment_log showing alert_id, alert_generated_timestamp, acknowledged_by, and acknowledgment_timestamp for all alerts in the prior 90 days, with acknowledgment latency \u2264 24 hours for \u2265 95% of entries", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "MR-05-E3", "description": "monthly_model_performance_report with Red/Amber/Green status for all material models, signed by MRM team and submitted to validation committee within 5 business days of month end", "evidence_type": "human-review-record", "verification": "human" }, { "id": "MR-05-E4", "description": "red_status_remediation_record for any model designated Red, showing decision_date, remediation_plan or suspension_decision, and MRO_approval within 30 days of Red designation", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-05-E5", "description": "eu_ai_act_post_market_monitoring_plan for each high-risk AI system confirming monitoring scope, metrics tracked, and reporting obligations under Article 72", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "SR 26-2 \u00a7V (Validation and Monitoring) addresses ongoing model monitoring under its Ongoing Model Monitoring subheading \u2014 tracking whether a model performs as intended and addressing performance issues promptly. This control implements that expectation with quantitative metrics and alert escalation." }, { "control": "apeiris://model/controls/BH-03", "id": "BH-03", "domain": "model", "name": "Production Performance Degradation Alerting", "validation_objective": "Every production model version must have a corresponding signed EvaluationBaseline artifact containing primary task metrics and subgroup slice metrics from the release evaluation gate; the metrics aggregation service must continuously compare production estimates against this baseline and fire tiered alerts when primary metrics regress 5% (warning) or 10% (critical) from the signed baseline values, including independent subgroup regression alerts.", "blocking_effect": "advisory", "evidence_required": [ "signed EvaluationBaseline artifact for the current production model version containing model_id, version, eval_date, primary_metrics with confidence intervals, subgroup slice metrics, eval_dataset_hash, and artifact SHA-256", "performance alert log for trailing 90 days with fields: alert_id, metric_name, regression_pct, severity, triggered_at, acknowledged_at, root_cause, and remediation_action for each alert", "quarterly threshold review sign-off from model owner confirming 5%/10% regression thresholds remain appropriate for the current model type and deployment context", "proxy_metric_registry documenting which proxy metrics substitute for labeled ground truth when unavailable, including calibration methodology and documented limitations" ], "evidence": [ { "id": "BH-03-E1", "description": "signed EvaluationBaseline artifact for the current production model version containing model_id, version, eval_date, primary_metrics with confidence intervals, subgroup slice metrics, eval_dataset_hash, and artifact SHA-256", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-03-E2", "description": "performance alert log for trailing 90 days with fields: alert_id, metric_name, regression_pct, severity, triggered_at, acknowledged_at, root_cause, and remediation_action for each alert", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "BH-03-E3", "description": "quarterly threshold review sign-off from model owner confirming 5%/10% regression thresholds remain appropriate for the current model type and deployment context", "evidence_type": "human-review-record", "verification": "human" }, { "id": "BH-03-E4", "description": "proxy_metric_registry documenting which proxy metrics substitute for labeled ground truth when unavailable, including calibration methodology and documented limitations", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "SR 26-2 Sec. V (Model Validation and Monitoring) describes ongoing monitoring of model performance and periodic comparison of results against expectations; BH-03's automated performance alerts provide the continuous monitoring layer that supports this expectation. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope." }, { "control": "apeiris://model/controls/CR-01", "id": "CR-01", "domain": "model", "name": "Continuous Production Monitoring and Risk Aggregation", "validation_objective": "All runtime monitoring signals \u2014 performance, drift, fairness, safety incidents, and deployment event flags \u2014 must be continuously aggregated into a unified risk dashboard with pre-configured automated alerting thresholds; any degradation in a monitored dimension must be detected and an alert dispatched within one operational window.", "blocking_effect": "advisory", "evidence_required": [ "risk_dashboard_configuration_record showing all registered signal feeds (performance, drift, fairness, safety, incident), their alert thresholds, assigned monitoring window duration, and escalation recipients", "alert_audit_log covering at least 30 days showing triggered alerts with signal_type, threshold_crossed, alert_timestamp, and escalation_recipient for each alert", "monitoring_coverage_audit confirming every deployed model version has an associated monitoring configuration with no version gaps", "risk_aggregation_methodology_document defining how individual dimension alerts are combined into composite risk scores and dashboard status indicators", "post-market_monitoring_report satisfying EU AI Act Art. 72 covering the monitoring period, key findings, and corrective actions taken or planned" ], "evidence": [ { "id": "CR-01-E1", "description": "risk_dashboard_configuration_record showing all registered signal feeds (performance, drift, fairness, safety, incident), their alert thresholds, assigned monitoring window duration, and escalation recipients", "evidence_type": "incident-record", "verification": "attested" }, { "id": "CR-01-E2", "description": "alert_audit_log covering at least 30 days showing triggered alerts with signal_type, threshold_crossed, alert_timestamp, and escalation_recipient for each alert", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E3", "description": "monitoring_coverage_audit confirming every deployed model version has an associated monitoring configuration with no version gaps", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E4", "description": "risk_aggregation_methodology_document defining how individual dimension alerts are combined into composite risk scores and dashboard status indicators", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "CR-01-E5", "description": "post-market_monitoring_report satisfying EU AI Act Art. 72 covering the monitoring period, key findings, and corrective actions taken or planned", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "SR 26-2 Sec. V (Model Validation and Monitoring) describes ongoing monitoring that surfaces performance problems and escalates material deterioration to appropriate stakeholders; CR-01's P1/P2/P3 tiered alert structure implements that expectation. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope." } ] }, { "requirement_id": "SR26-MON-02", "section": "Sec. V", "title": "Concept Drift and Data Drift Detection", "text": "For AI/ML models, monitoring should include detection of concept drift (changes in the relationship between inputs and target variable) and data drift (changes in input data distributions). Drift detection should be automated where feasible and documented with defined thresholds.", "verdict": "supported", "coverage": "direct", "notes": "BH-02 (Concept and Data Drift Detection) directly addresses both concept drift and data drift detection requirements with automated detection and defined thresholds. BH-01 (Output Anomaly Detection) provides complementary detection of anomalous output patterns that may signal upstream drift. MR-05 requires drift monitoring as a component of the ongoing model risk monitoring program.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/BH-02", "id": "BH-02", "domain": "model", "name": "Concept and Data Drift Detection", "validation_objective": "The production inference pipeline must compare input feature distributions and prediction distributions against a versioned, SHA-256-signed DriftReference artifact using PSI and KS-test statistics for every monitoring window that meets minimum_sample_size, such that drift exceeding profile-conditional PSI thresholds triggers tiered alert actions, and for continuously-learning profiles, automatically suspends online updates pending a signed model-owner resume authorization.", "blocking_effect": "advisory", "evidence_required": [ "versioned DriftReference artifact for the current production model with SHA-256 hash, training date, and per-feature statistics (mean, std, histogram bins, and KDE parameters) for all tier-1 monitored features", "drift event log for trailing 90 days with fields: feature_name, test_statistic, p_value, window_start, window_end, sample_count, alert_severity, and action_taken for each drift event", "monthly drift summary report signed by the model owner, including trend analysis across tier-1 features and prediction distribution PSI over the reporting period", "profile-conditional drift threshold configuration (YAML or equivalent) showing per-profile PSI alert and critical thresholds, minimum_sample_size, and window duration, stored under version control" ], "evidence": [ { "id": "BH-02-E1", "description": "versioned DriftReference artifact for the current production model with SHA-256 hash, training date, and per-feature statistics (mean, std, histogram bins, and KDE parameters) for all tier-1 monitored features", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-02-E2", "description": "drift event log for trailing 90 days with fields: feature_name, test_statistic, p_value, window_start, window_end, sample_count, alert_severity, and action_taken for each drift event", "evidence_type": "audit-log", "verification": "automated" }, { "id": "BH-02-E3", "description": "monthly drift summary report signed by the model owner, including trend analysis across tier-1 features and prediction distribution PSI over the reporting period", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-02-E4", "description": "profile-conditional drift threshold configuration (YAML or equivalent) showing per-profile PSI alert and critical thresholds, minimum_sample_size, and window duration, stored under version control", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "SR 26-2 Sec. V (Model Validation and Monitoring) describes ongoing monitoring for performance deterioration and distributional change in model inputs; BH-02 directly implements this by computing PSI statistics against a versioned DriftReference artifact. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope." }, { "control": "apeiris://model/controls/BH-01", "id": "BH-01", "domain": "model", "name": "Output Anomaly Detection", "validation_objective": "The production inference endpoint must be continuously sampled and output distributions must be statistically compared against a versioned, SHA-256-signed baseline artifact using PSI and Shewhart/EWMA control chart methods, such that any distribution shift exceeding PSI 0.2 fires a tiered alert within one monitoring window of the shift occurring and all anomaly events are stored in the evidence registry with BH-01 control linkage.", "blocking_effect": "advisory", "evidence_required": [ "versioned, SHA-256-signed baseline distribution artifact stored in the model registry with per-metric statistics (mean, std_dev, p5/p50/p95/p99) computed from the 30-day post-deployment stable window", "SPC alert log for trailing 90 days with fields: alert_id, trigger_metric, psi_value, alert_severity, triggered_at, acknowledged_at, and resolution_outcome", "PII masking audit record confirming no direct identifier fields (email, SSN, full name) appear in the sampled output storage for the trailing 30 days", "quarterly threshold review sign-off from model owner confirming PSI alert (0.2) and critical (0.25) thresholds remain appropriate for the current deployment context" ], "evidence": [ { "id": "BH-01-E1", "description": "versioned, SHA-256-signed baseline distribution artifact stored in the model registry with per-metric statistics (mean, std_dev, p5/p50/p95/p99) computed from the 30-day post-deployment stable window", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-01-E2", "description": "SPC alert log for trailing 90 days with fields: alert_id, trigger_metric, psi_value, alert_severity, triggered_at, acknowledged_at, and resolution_outcome", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "BH-01-E3", "description": "PII masking audit record confirming no direct identifier fields (email, SSN, full name) appear in the sampled output storage for the trailing 30 days", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-01-E4", "description": "quarterly threshold review sign-off from model owner confirming PSI alert (0.2) and critical (0.25) thresholds remain appropriate for the current deployment context", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "SR 26-2 Sec. V (Model Validation and Monitoring) describes ongoing monitoring of model performance and behavior; BH-01 operationalizes this by detecting statistical distribution shifts in model outputs that may indicate degraded performance or data-quality problems. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope." }, { "control": "apeiris://finance/controls/MR-05", "id": "MR-05", "domain": "finance", "name": "Ongoing Model Risk Monitoring", "validation_objective": "All production financial AI models classified as material must have active automated monitoring dashboards with data refreshed within the last business day pipeline cycle, all monitoring alerts must be acknowledged by model owners within 24 hours, and no material model may remain in Red monitoring status for more than 30 days without a documented re-validation decision or suspension record signed by the MRO.", "blocking_effect": "advisory", "evidence_required": [ "model_monitoring_dashboard_record for each material model showing last_data_refresh_timestamp within 26 hours of the most recent business day close", "alert_acknowledgment_log showing alert_id, alert_generated_timestamp, acknowledged_by, and acknowledgment_timestamp for all alerts in the prior 90 days, with acknowledgment latency \u2264 24 hours for \u2265 95% of entries", "monthly_model_performance_report with Red/Amber/Green status for all material models, signed by MRM team and submitted to validation committee within 5 business days of month end", "red_status_remediation_record for any model designated Red, showing decision_date, remediation_plan or suspension_decision, and MRO_approval within 30 days of Red designation", "eu_ai_act_post_market_monitoring_plan for each high-risk AI system confirming monitoring scope, metrics tracked, and reporting obligations under Article 72" ], "evidence": [ { "id": "MR-05-E1", "description": "model_monitoring_dashboard_record for each material model showing last_data_refresh_timestamp within 26 hours of the most recent business day close", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-05-E2", "description": "alert_acknowledgment_log showing alert_id, alert_generated_timestamp, acknowledged_by, and acknowledgment_timestamp for all alerts in the prior 90 days, with acknowledgment latency \u2264 24 hours for \u2265 95% of entries", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "MR-05-E3", "description": "monthly_model_performance_report with Red/Amber/Green status for all material models, signed by MRM team and submitted to validation committee within 5 business days of month end", "evidence_type": "human-review-record", "verification": "human" }, { "id": "MR-05-E4", "description": "red_status_remediation_record for any model designated Red, showing decision_date, remediation_plan or suspension_decision, and MRO_approval within 30 days of Red designation", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-05-E5", "description": "eu_ai_act_post_market_monitoring_plan for each high-risk AI system confirming monitoring scope, metrics tracked, and reporting obligations under Article 72", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "SR 26-2 \u00a7V (Validation and Monitoring) addresses ongoing model monitoring under its Ongoing Model Monitoring subheading \u2014 tracking whether a model performs as intended and addressing performance issues promptly. This control implements that expectation with quantitative metrics and alert escalation." } ] }, { "requirement_id": "SR26-MON-03", "section": "Sec. V", "title": "Alert Thresholds, Escalation, and Automated Response", "text": "Monitoring programs should define quantitative alert thresholds for performance degradation, drift, and anomaly signals. Breaching thresholds should trigger escalation to appropriate governance levels. The guidance describes the expectation that institutions document response procedures including temporary model suspension criteria.", "verdict": "supported", "coverage": "direct", "notes": "BH-03 (Production Performance Degradation Alerting) defines the alerting infrastructure with quantitative thresholds and alert routing. OA-07 (Incident Escalation Authority Chain) maps escalation paths for threshold breaches to appropriate governance levels. AM-07 (Real-Time Alerting and Automated Agent Suspension) provides the automated response capability including model/agent suspension on alert trigger.", "control_count": 3, "proof_chain": [ { "control": "apeiris://model/controls/BH-03", "id": "BH-03", "domain": "model", "name": "Production Performance Degradation Alerting", "validation_objective": "Every production model version must have a corresponding signed EvaluationBaseline artifact containing primary task metrics and subgroup slice metrics from the release evaluation gate; the metrics aggregation service must continuously compare production estimates against this baseline and fire tiered alerts when primary metrics regress 5% (warning) or 10% (critical) from the signed baseline values, including independent subgroup regression alerts.", "blocking_effect": "advisory", "evidence_required": [ "signed EvaluationBaseline artifact for the current production model version containing model_id, version, eval_date, primary_metrics with confidence intervals, subgroup slice metrics, eval_dataset_hash, and artifact SHA-256", "performance alert log for trailing 90 days with fields: alert_id, metric_name, regression_pct, severity, triggered_at, acknowledged_at, root_cause, and remediation_action for each alert", "quarterly threshold review sign-off from model owner confirming 5%/10% regression thresholds remain appropriate for the current model type and deployment context", "proxy_metric_registry documenting which proxy metrics substitute for labeled ground truth when unavailable, including calibration methodology and documented limitations" ], "evidence": [ { "id": "BH-03-E1", "description": "signed EvaluationBaseline artifact for the current production model version containing model_id, version, eval_date, primary_metrics with confidence intervals, subgroup slice metrics, eval_dataset_hash, and artifact SHA-256", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "BH-03-E2", "description": "performance alert log for trailing 90 days with fields: alert_id, metric_name, regression_pct, severity, triggered_at, acknowledged_at, root_cause, and remediation_action for each alert", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "BH-03-E3", "description": "quarterly threshold review sign-off from model owner confirming 5%/10% regression thresholds remain appropriate for the current model type and deployment context", "evidence_type": "human-review-record", "verification": "human" }, { "id": "BH-03-E4", "description": "proxy_metric_registry documenting which proxy metrics substitute for labeled ground truth when unavailable, including calibration methodology and documented limitations", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "SR 26-2 Sec. V (Model Validation and Monitoring) describes ongoing monitoring of model performance and periodic comparison of results against expectations; BH-03's automated performance alerts provide the continuous monitoring layer that supports this expectation. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope." }, { "control": "apeiris://model/controls/OA-07", "id": "OA-07", "domain": "model", "name": "Incident Escalation Authority Chain", "validation_objective": "The organization must have a documented incident escalation authority chain for AI model incidents with named individuals at each of four levels, explicit decision rights at each level, time bounds for escalation steps, a defined board-level notification threshold, and annual tabletop exercise completion records. For EU high-risk AI systems, the escalation chain must map EU AI Act Art-73 serious incident reporting obligations (15-day general deadline; 10 days for death; 2 days for widespread infringement or critical-infrastructure incidents) to a specific escalation level.", "blocking_effect": "blocks-deployment", "evidence_required": [ "escalation_authority_chain_document current version with named individuals (not just roles) at each of the four escalation levels, decision rights matrix, time bounds per level, and board-level notification threshold definition \u2014 with approval date", "annual_tabletop_exercise_record for the preceding 12 months, including scenario description, participant list, escalation chain performance against time bounds, gaps identified, and remediation actions", "incident_post_mortem_records for AI model incidents in the preceding 12 months showing escalation chain adherence, time-bound compliance, and regulatory notification actions taken", "regulatory_notification_obligation_mapping document linking EU AI Act Art-73, sector-specific incident reporting requirements, and other applicable obligations to specific escalation levels and time bounds" ], "evidence": [ { "id": "OA-07-E1", "description": "escalation_authority_chain_document current version with named individuals (not just roles) at each of the four escalation levels, decision rights matrix, time bounds per level, and board-level notification threshold definition \u2014 with approval date", "evidence_type": "human-review-record", "verification": "human" }, { "id": "OA-07-E2", "description": "annual_tabletop_exercise_record for the preceding 12 months, including scenario description, participant list, escalation chain performance against time bounds, gaps identified, and remediation actions", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-07-E3", "description": "incident_post_mortem_records for AI model incidents in the preceding 12 months showing escalation chain adherence, time-bound compliance, and regulatory notification actions taken", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "OA-07-E4", "description": "regulatory_notification_obligation_mapping document linking EU AI Act Art-73, sector-specific incident reporting requirements, and other applicable obligations to specific escalation levels and time bounds", "evidence_type": "incident-record", "verification": "attested" } ], "fit": "partial", "basis": "anchored", "relation": "equivalent_to", "rationale": "SR 26-2 Sec. VI (Governance and Controls) describes reporting on model risk to senior management and the board. OA-07's escalation authority chain gives material model incidents a defined path to those governance levels. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope." }, { "control": "apeiris://agentic/controls/AM-07", "id": "AM-07", "domain": "agentic", "name": "Real-Time Alerting and Automated Agent Suspension", "validation_objective": "Prove that the enterprise has implemented a four-tier alert escalation model for agent behavioral violations and that automated suspension is capable of halting an offending agent within 60 seconds of a critical trigger while preserving session state for forensic review. Validate that reinstatement requires documented human authorization.", "blocking_effect": "advisory", "evidence_required": [ "Documented four-tier alert tier definitions with explicit trigger conditions (threshold values or violation patterns), SLAs, and escalation paths for tiers 3 and 4", "On-call pager integration configuration confirming tier-3 and tier-4 alerts route to the security team with SLA clock activation", "Most recent suspension exercise record demonstrating the full suspension-to-reinstatement path was tested in a live or near-production environment, not only in tabletop", "Quarterly alert effectiveness review report documenting false positive rates by tier and threshold tuning decisions made during the review period" ], "evidence": [ { "id": "AM-07-E1", "description": "Documented four-tier alert tier definitions with explicit trigger conditions (threshold values or violation patterns), SLAs, and escalation paths for tiers 3 and 4", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "AM-07-E2", "description": "On-call pager integration configuration confirming tier-3 and tier-4 alerts route to the security team with SLA clock activation", "evidence_type": "monitoring-alert-history", "verification": "automated" }, { "id": "AM-07-E3", "description": "Most recent suspension exercise record demonstrating the full suspension-to-reinstatement path was tested in a live or near-production environment, not only in tabletop", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AM-07-E4", "description": "Quarterly alert effectiveness review report documenting false positive rates by tier and threshold tuning decisions made during the review period", "evidence_type": "monitoring-alert-history", "verification": "automated" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "SR26-MON-04", "section": "Sec. V", "title": "Outcome Analysis and Backtesting", "text": "The guidance describes the expectation that institutions conduct periodic outcome analysis comparing model predictions against realized outcomes, and backtesting where applicable. Outcome analysis results should be documented, compared against validation benchmarks, and used to inform re-validation triggers.", "verdict": "supported", "coverage": "direct", "notes": "MV-03 (Outcome Analysis and Backtesting) directly addresses periodic outcome analysis and backtesting requirements, including comparison to validation benchmarks. CR-06 (Post-Market Surveillance) extends outcome analysis into systematic post-deployment surveillance, providing the broader evidence base that SR 26-2 expects to inform re-validation timing.", "control_count": 2, "proof_chain": [ { "control": "apeiris://finance/controls/MV-03", "id": "MV-03", "domain": "finance", "name": "Outcome Analysis and Backtesting", "validation_objective": "All production models must be enrolled in a continuous outcome analysis program comparing model predictions against realized outcomes using actuals sourced independently of the model development team, with pre-defined pass/fail thresholds that trigger formal escalation workflows when breached. Backtesting results must be documented at all defined intervals, reviewed by the validation function, and any threshold breach must initiate escalation within the defined response window.", "blocking_effect": "requires-review", "evidence_required": [ "backtesting_report per model per test cycle showing test period, prediction-vs-actual comparison metrics, pass/fail verdict against pre-defined thresholds, and escalation actions triggered by any breach", "outcome_data_lineage_record confirming that production actuals used in backtesting are sourced independently from model development, with attestation from an independent data custodian", "backtesting_threshold_specification per model defining pass/fail thresholds, test frequency, breach escalation procedure, and the date thresholds were approved by the validation function", "escalation_log for all backtesting threshold breaches documenting breach date, severity classification, escalation recipient, response action taken, and closure date" ], "evidence": [ { "id": "MV-03-E1", "description": "backtesting_report per model per test cycle showing test period, prediction-vs-actual comparison metrics, pass/fail verdict against pre-defined thresholds, and escalation actions triggered by any breach", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "MV-03-E2", "description": "outcome_data_lineage_record confirming that production actuals used in backtesting are sourced independently from model development, with attestation from an independent data custodian", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MV-03-E3", "description": "backtesting_threshold_specification per model defining pass/fail thresholds, test frequency, breach escalation procedure, and the date thresholds were approved by the validation function", "evidence_type": "automated-test-result", "verification": "automated" }, { "id": "MV-03-E4", "description": "escalation_log for all backtesting threshold breaches documenting breach date, severity classification, escalation recipient, response action taken, and closure date", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "SR 26-2 \u00a7V (Validation and Monitoring) describes outcomes analysis \u2014 comparing model outputs to actual results \u2014 under its Outcomes Analysis subheading as a core element of validation. Formal backtesting protocols with defined thresholds implement that element." }, { "control": "apeiris://model/controls/CR-06", "id": "CR-06", "domain": "model", "name": "Post-Market Surveillance", "validation_objective": "The organization must operate three distinct proactive surveillance channels \u2014 a structured user-facing harm reporting mechanism, a coordinated vulnerability disclosure (CVD) program with a monitored security inbox, and a quarterly AI literature and media monitoring process \u2014 with outputs aggregated into a monthly post-market surveillance report reviewed and signed by the AI risk function, and an annual surveillance summary included in the model's EU high-risk AI technical documentation (LI-04).", "blocking_effect": "advisory", "evidence_required": [ "User-facing harm reporting mechanism deployment record showing endpoint URL, structured input schema (harm_type, severity_self_assessed, description), and CR-02 archive path", "Published CVD policy document at a canonical URL with designated security email alias and monitored inbox confirmation, including acknowledgement SLA statement", "Last 12 monthly post-market surveillance reports with AI risk function reviewer name, sign-off signature, and review date on each report", "Annual surveillance summary document aggregating user reports, CVD submissions, and literature findings \u2014 present in the model's LI-04 technical documentation with review date", "CVD acknowledgement records showing each submission received an acknowledgement within 5 business days of receipt" ], "evidence": [ { "id": "CR-06-E1", "description": "User-facing harm reporting mechanism deployment record showing endpoint URL, structured input schema (harm_type, severity_self_assessed, description), and CR-02 archive path", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-06-E2", "description": "Published CVD policy document at a canonical URL with designated security email alias and monitored inbox confirmation, including acknowledgement SLA statement", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CR-06-E3", "description": "Last 12 monthly post-market surveillance reports with AI risk function reviewer name, sign-off signature, and review date on each report", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CR-06-E4", "description": "Annual surveillance summary document aggregating user reports, CVD submissions, and literature findings \u2014 present in the model's LI-04 technical documentation with review date", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CR-06-E5", "description": "CVD acknowledgement records showing each submission received an acknowledgement within 5 business days of receipt", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "adjacent", "basis": "anchored", "relation": "equivalent_to", "rationale": "SR 26-2 Sec. V (Model Validation and Monitoring) describes ongoing monitoring of models in use; CR-06's post-market surveillance channels extend that monitoring to externally reported harms and findings, providing adjacent coverage. SR 26-2 footnote 3 places generative and agentic AI models outside the guidance's scope, so this mapping applies to the control's traditional and predictive-model scope." } ] }, { "requirement_id": "SR26-RPT-01", "section": "Sec. VI", "title": "Model Risk Committee Reporting", "text": "The guidance describes the expectation that institutions produce regular model risk reports to the Model Risk Committee (or equivalent governance body) covering aggregate model risk exposure, inventory status, validation pipeline, open findings, and emerging risks. Reporting frequency should be commensurate with the institution's model risk profile.", "verdict": "supported", "coverage": "direct", "notes": "MR-08 (Model Risk Evidence Package) produces the structured evidence artifact underpinning MRC reporting, covering inventory status, validation pipeline, and open findings. FG-06 (Financial AI Program Metrics and Board Reporting) defines the metrics and reporting cadence for governance body reporting including MRC-level summaries. CG-07 (Compliance Program Metrics and KPIs) provides the compliance dimension of aggregate risk reporting required at committee level.", "control_count": 3, "proof_chain": [ { "control": "apeiris://finance/controls/MR-08", "id": "MR-08", "domain": "finance", "name": "Model Risk Evidence Package", "validation_objective": "The institution must maintain a Model Risk Evidence Package for each material model that can be assembled and provided to regulatory examiners within 2 business days, achieving a completeness score of 95% or greater across all required artifact categories spanning MR-01 through MR-07. Evidence package completeness must be verifiable on-demand through automated scoring without manual reconstruction of artifacts.", "blocking_effect": "requires-review", "evidence_required": [ "evidence_package_index per material model listing all required artifact categories (MR-01 through MR-07), presence status, artifact_id, and last_updated timestamp for each slot", "automated_completeness_score_report per model showing percentage of required artifact slots populated, scored against the defined MR evidence package schema with currency checks", "artifact_integrity_log showing cryptographic hash verification records for all evidence artifacts, confirming no post-creation modification", "examination_readiness_drill_record documenting the elapsed time to assemble and export the evidence package for at least one material model per quarter", "mro_attestation_signature record on the quarterly completeness report for all material models, with sign-off timestamp and any noted deficiencies" ], "evidence": [ { "id": "MR-08-E1", "description": "evidence_package_index per material model listing all required artifact categories (MR-01 through MR-07), presence status, artifact_id, and last_updated timestamp for each slot", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-08-E2", "description": "automated_completeness_score_report per model showing percentage of required artifact slots populated, scored against the defined MR evidence package schema with currency checks", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-08-E3", "description": "artifact_integrity_log showing cryptographic hash verification records for all evidence artifacts, confirming no post-creation modification", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-08-E4", "description": "examination_readiness_drill_record documenting the elapsed time to assemble and export the evidence package for at least one material model per quarter", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "MR-08-E5", "description": "mro_attestation_signature record on the quarterly completeness report for all material models, with sign-off timestamp and any noted deficiencies", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "SR 26-2 \u00a7VI (Governance and Controls) addresses documentation under its Documentation subheading \u2014 sufficient for a knowledgeable third party to understand a model's development, validation, and use. The MR evidence package operationalizes that documentation expectation across the model portfolio." }, { "control": "apeiris://finance/controls/FG-06", "id": "FG-06", "domain": "finance", "name": "Financial AI Program Metrics and Board Reporting", "validation_objective": "A defined KRI set covering at minimum model risk coverage rate, validation timeliness, outstanding findings severity, control effectiveness score, and regulatory examination readiness is computed from documented source systems, reported to the board quarterly with trend data, and any KRI breaching its red threshold triggers a management action plan within five business days. At least one quarterly board KRI dashboard must exist for the prior period with documented board committee acknowledgment.", "blocking_effect": "advisory", "evidence_required": [ "kri_framework_definition with at least five KRIs, each having data_source, collection_frequency, responsible_owner, and green/amber/red threshold values defined", "quarterly_board_kri_dashboard for each quarter in scope with KRI values, trend_direction, threshold_status, and board_committee_delivery_date", "red_status_action_plan with kri_identifier, breach_detection_date, action_plan_owner, action_plan_creation_date within five business days of breach, and remediation_deadline", "kri_data_quality_certification signed by the MRO confirming data sources are current and disclosing any known accuracy limitations for each reporting period" ], "evidence": [ { "id": "FG-06-E1", "description": "kri_framework_definition with at least five KRIs, each having data_source, collection_frequency, responsible_owner, and green/amber/red threshold values defined", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FG-06-E2", "description": "quarterly_board_kri_dashboard for each quarter in scope with KRI values, trend_direction, threshold_status, and board_committee_delivery_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FG-06-E3", "description": "red_status_action_plan with kri_identifier, breach_detection_date, action_plan_owner, action_plan_creation_date within five business days of breach, and remediation_deadline", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FG-06-E4", "description": "kri_data_quality_certification signed by the MRO confirming data sources are current and disclosing any known accuracy limitations for each reporting period", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "SR 26-2 \u00a7VI describes board and senior management receiving reporting sufficient to oversee the institution's model risk profile. A defined KRI framework with quantitative indicators and trend reporting is one way to make that reporting substantive; the guidance does not prescribe specific metrics or cadences." }, { "control": "apeiris://compliance/controls/CG-07", "id": "CG-07", "domain": "compliance", "name": "Compliance Program Metrics and KPIs", "validation_objective": "A two-tier compliance metrics framework exists with at least five board-level KPIs (including at least one outcome indicator per applicable regulatory framework) and at least fifteen operational metrics covering obligation coverage, remediation velocity, and control effectiveness, with automated data collection from source systems and four consecutive periods of historical trend data available at reporting time.", "blocking_effect": "advisory", "evidence_required": [ "kpi_framework_document defining each metric with metric_name, metric_type (leading/lagging/outcome/activity), calculation_method, data_source, collection_frequency, reporting_tier (board/operational), and metric_owner \u2014 with annual_review_date within the last 12 months", "board_kpi_dashboard reports for at least four consecutive quarters showing trend data, with compliance_committee_meeting_minutes confirming each was presented and received by the Compliance Committee", "operational_metrics_report for the current reporting period showing current_value for all defined operational metrics with data_source attribution and freshness_timestamp <= 48 hours at time of report generation", "metric_data_pipeline_health_log confirming automated collection pipeline is active for each metric, with last_successful_collection_timestamp and error_rate for the preceding 30 days" ], "evidence": [ { "id": "CG-07-E1", "description": "kpi_framework_document defining each metric with metric_name, metric_type (leading/lagging/outcome/activity), calculation_method, data_source, collection_frequency, reporting_tier (board/operational), and metric_owner \u2014 with annual_review_date within the last 12 months", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-07-E2", "description": "board_kpi_dashboard reports for at least four consecutive quarters showing trend data, with compliance_committee_meeting_minutes confirming each was presented and received by the Compliance Committee", "evidence_type": "human-review-record", "verification": "human" }, { "id": "CG-07-E3", "description": "operational_metrics_report for the current reporting period showing current_value for all defined operational metrics with data_source attribution and freshness_timestamp <= 48 hours at time of report generation", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "CG-07-E4", "description": "metric_data_pipeline_health_log confirming automated collection pipeline is active for each metric, with last_successful_collection_timestamp and error_rate for the preceding 30 days", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "SR26-RPT-02", "section": "Sec. VI", "title": "Board-Level Model Risk Reporting", "text": "The board of directors should receive regular, sufficiently detailed model risk reports to enable informed oversight. Reports should include aggregate model risk exposure, significant model risk events, material validation findings, and management's assessment of MRM program adequacy.", "verdict": "supported", "coverage": "direct", "notes": "FG-03 (Board-Level Oversight of Financial AI Risk) directly establishes the board oversight requirement and reporting cadence. FG-06 (Financial AI Program Metrics and Board Reporting) specifies the content and structure of board-level AI risk reporting including aggregate exposure and program adequacy assessment. PE-06 (Board and Senior Management Policy Reporting) ensures policy governance dimensions are included in board reporting packages.", "control_count": 3, "proof_chain": [ { "control": "apeiris://finance/controls/FG-03", "id": "FG-03", "domain": "finance", "name": "Board-Level Oversight of Financial AI Risk", "validation_objective": "The board risk or audit committee has received a structured AI risk reporting package at least quarterly, containing model inventory status, material model failures, validation backlogs, and key risk indicators with trend, and has formally acknowledged receipt in board meeting minutes. The board risk appetite statement must explicitly address AI or model risk and have been reviewed within the prior 12 months.", "blocking_effect": "requires-review", "evidence_required": [ "board_ai_risk_report with delivery_date, content_checklist_completion_status, and committee_recipient_identification for each quarter in scope", "board_meeting_minutes confirming AI risk discussion with date, attending_committee_members, and formal_acknowledgment_of_reporting_package for each quarter", "board_risk_appetite_statement with ai_risk_section present, last_reviewed_date within 12 months, and approving_body identifier", "incident_escalation_log showing any material AI failures with board_notification_date and board_response_documented flag for each high-severity event" ], "evidence": [ { "id": "FG-03-E1", "description": "board_ai_risk_report with delivery_date, content_checklist_completion_status, and committee_recipient_identification for each quarter in scope", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FG-03-E2", "description": "board_meeting_minutes confirming AI risk discussion with date, attending_committee_members, and formal_acknowledgment_of_reporting_package for each quarter", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FG-03-E3", "description": "board_risk_appetite_statement with ai_risk_section present, last_reviewed_date within 12 months, and approving_body identifier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FG-03-E4", "description": "incident_escalation_log showing any material AI failures with board_notification_date and board_response_documented flag for each high-severity event", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "SR 26-2 \u00a7VI describes the board's oversight role \u2014 understanding significant model risk, approving the framework, and receiving reporting from senior management \u2014 under Roles and Responsibilities. Structured board reporting supports that expectation; the quarterly cadence in this control is an internal practice choice, not a cadence set by the guidance." }, { "control": "apeiris://finance/controls/FG-06", "id": "FG-06", "domain": "finance", "name": "Financial AI Program Metrics and Board Reporting", "validation_objective": "A defined KRI set covering at minimum model risk coverage rate, validation timeliness, outstanding findings severity, control effectiveness score, and regulatory examination readiness is computed from documented source systems, reported to the board quarterly with trend data, and any KRI breaching its red threshold triggers a management action plan within five business days. At least one quarterly board KRI dashboard must exist for the prior period with documented board committee acknowledgment.", "blocking_effect": "advisory", "evidence_required": [ "kri_framework_definition with at least five KRIs, each having data_source, collection_frequency, responsible_owner, and green/amber/red threshold values defined", "quarterly_board_kri_dashboard for each quarter in scope with KRI values, trend_direction, threshold_status, and board_committee_delivery_date", "red_status_action_plan with kri_identifier, breach_detection_date, action_plan_owner, action_plan_creation_date within five business days of breach, and remediation_deadline", "kri_data_quality_certification signed by the MRO confirming data sources are current and disclosing any known accuracy limitations for each reporting period" ], "evidence": [ { "id": "FG-06-E1", "description": "kri_framework_definition with at least five KRIs, each having data_source, collection_frequency, responsible_owner, and green/amber/red threshold values defined", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FG-06-E2", "description": "quarterly_board_kri_dashboard for each quarter in scope with KRI values, trend_direction, threshold_status, and board_committee_delivery_date", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FG-06-E3", "description": "red_status_action_plan with kri_identifier, breach_detection_date, action_plan_owner, action_plan_creation_date within five business days of breach, and remediation_deadline", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FG-06-E4", "description": "kri_data_quality_certification signed by the MRO confirming data sources are current and disclosing any known accuracy limitations for each reporting period", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "SR 26-2 \u00a7VI describes board and senior management receiving reporting sufficient to oversee the institution's model risk profile. A defined KRI framework with quantitative indicators and trend reporting is one way to make that reporting substantive; the guidance does not prescribe specific metrics or cadences." }, { "control": "apeiris://authority/controls/PE-06", "id": "PE-06", "domain": "authority", "name": "Board and Senior Management Policy Reporting", "validation_objective": "Quarterly AI policy governance reports must be produced on schedule, reviewed, and co-signed by both the Chief Risk Officer and General Counsel, with every reported metric traceable to a supporting evidence item in the PE-04 integrated package. All risk items exceeding the board-approved materiality thresholds must appear in the report with prioritized escalation recommendations and documented board response within 30 days.", "blocking_effect": "requires-review", "evidence_required": [ "board_ai_policy_governance_report with executive summary, risk-adjusted metrics, open gap inventory, and escalation recommendations, dated within the quarterly reporting cycle and referencing the PE-04 integrated package version used", "report_sign_off_log showing CRO identity, General Counsel identity, individual sign-off timestamps, and SHA-256 hash of the signed report version to detect post-signature modification", "materiality_threshold_schedule approved by the CRO and version-controlled, defining numeric thresholds for AI policy risk metrics that trigger mandatory board-level reporting and escalation", "report_distribution_log recording recipient role, distribution timestamp, and acknowledgment status for each quarterly report to confirm the board actually received the report" ], "evidence": [ { "id": "PE-06-E1", "description": "board_ai_policy_governance_report with executive summary, risk-adjusted metrics, open gap inventory, and escalation recommendations, dated within the quarterly reporting cycle and referencing the PE-04 integrated package version used", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "PE-06-E2", "description": "report_sign_off_log showing CRO identity, General Counsel identity, individual sign-off timestamps, and SHA-256 hash of the signed report version to detect post-signature modification", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PE-06-E3", "description": "materiality_threshold_schedule approved by the CRO and version-controlled, defining numeric thresholds for AI policy risk metrics that trigger mandatory board-level reporting and escalation", "evidence_type": "human-review-record", "verification": "human" }, { "id": "PE-06-E4", "description": "report_distribution_log recording recipient role, distribution timestamp, and acknowledgment status for each quarterly report to confirm the board actually received the report", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] }, { "requirement_id": "SR26-RPT-03", "section": "Sec. VI", "title": "Regulatory Disclosure and Examination Support", "text": "The guidance describes the expectation that institutions maintain model risk information in a form suitable for regulatory examination, including model inventory access, validation reports, governance documentation, and MRM program materials. Regulators should be provided timely access to model risk evidence upon request.", "verdict": "partial", "coverage": "partial", "notes": "FD-04 (Model Output Disclosure to Financial Regulators) addresses mandatory disclosure of model information to financial regulators. MR-08 (Model Risk Evidence Package) produces the structured evidence artifacts that regulators would access during examination. AU-05 (Regulatory Examination Response Program) provides the operational program for coordinating examiner access. Partial gap: SR 26-2 \u00a79.3 contemplates specific regulatory reporting formats and supervisory timelines defined by the Federal Reserve examination process; Apeiris controls establish the evidence infrastructure but cannot substitute for the institution's direct supervisory relationship and examination-specific response procedures.", "control_count": 3, "proof_chain": [ { "control": "apeiris://finance/controls/FD-04", "id": "FD-04", "domain": "finance", "name": "Model Output Disclosure to Financial Regulators", "validation_objective": "The institution must maintain, for each AI model in production, a pre-staged regulatory disclosure package containing the model architecture summary, validation findings, current performance metrics, known limitations, and data lineage sufficient to respond to a regulatory examination request. Disclosure procedures must be tested annually and must enable package delivery within the response timeframe required by the institution's primary regulator.", "blocking_effect": "requires-review", "evidence_required": [ "regulatory_disclosure_package for each production model containing architecture_summary, validation_findings_summary, current_performance_metrics_report, known_limitations_register, and data_lineage_document", "disclosure_procedure_document specifying escalation path, responsible officers, and required response timelines by regulator type including OCC, Federal Reserve, FDIC, and SEC", "annual_disclosure_drill_record showing the package was assembled and reviewed within the required response SLA without creating new documents after the drill commenced", "model_disclosure_inventory_index mapping each production model to its corresponding disclosure package with package version and last_updated_timestamp", "legal_and_compliance_review_record confirming disclosure packages were reviewed for regulatory sufficiency within the past 12 months" ], "evidence": [ { "id": "FD-04-E1", "description": "regulatory_disclosure_package for each production model containing architecture_summary, validation_findings_summary, current_performance_metrics_report, known_limitations_register, and data_lineage_document", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FD-04-E2", "description": "disclosure_procedure_document specifying escalation path, responsible officers, and required response timelines by regulator type including OCC, Federal Reserve, FDIC, and SEC", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FD-04-E3", "description": "annual_disclosure_drill_record showing the package was assembled and reviewed within the required response SLA without creating new documents after the drill commenced", "evidence_type": "human-review-record", "verification": "human" }, { "id": "FD-04-E4", "description": "model_disclosure_inventory_index mapping each production model to its corresponding disclosure package with package version and last_updated_timestamp", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "FD-04-E5", "description": "legal_and_compliance_review_record confirming disclosure packages were reviewed for regulatory sufficiency within the past 12 months", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "SR 26-2 \u00a7VI describes model documentation expectations under its Documentation subheading. Honest scope note: the guidance addresses documentation quality for internal governance and supervisory review; it does not prescribe regulator-disclosure packages. FD-04's pre-staged examiner packages are institutional practice built on the \u00a7VI documentation base." }, { "control": "apeiris://finance/controls/MR-08", "id": "MR-08", "domain": "finance", "name": "Model Risk Evidence Package", "validation_objective": "The institution must maintain a Model Risk Evidence Package for each material model that can be assembled and provided to regulatory examiners within 2 business days, achieving a completeness score of 95% or greater across all required artifact categories spanning MR-01 through MR-07. Evidence package completeness must be verifiable on-demand through automated scoring without manual reconstruction of artifacts.", "blocking_effect": "requires-review", "evidence_required": [ "evidence_package_index per material model listing all required artifact categories (MR-01 through MR-07), presence status, artifact_id, and last_updated timestamp for each slot", "automated_completeness_score_report per model showing percentage of required artifact slots populated, scored against the defined MR evidence package schema with currency checks", "artifact_integrity_log showing cryptographic hash verification records for all evidence artifacts, confirming no post-creation modification", "examination_readiness_drill_record documenting the elapsed time to assemble and export the evidence package for at least one material model per quarter", "mro_attestation_signature record on the quarterly completeness report for all material models, with sign-off timestamp and any noted deficiencies" ], "evidence": [ { "id": "MR-08-E1", "description": "evidence_package_index per material model listing all required artifact categories (MR-01 through MR-07), presence status, artifact_id, and last_updated timestamp for each slot", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-08-E2", "description": "automated_completeness_score_report per model showing percentage of required artifact slots populated, scored against the defined MR evidence package schema with currency checks", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-08-E3", "description": "artifact_integrity_log showing cryptographic hash verification records for all evidence artifacts, confirming no post-creation modification", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "MR-08-E4", "description": "examination_readiness_drill_record documenting the elapsed time to assemble and export the evidence package for at least one material model per quarter", "evidence_type": "configuration-snapshot", "verification": "automated" }, { "id": "MR-08-E5", "description": "mro_attestation_signature record on the quarterly completeness report for all material models, with sign-off timestamp and any noted deficiencies", "evidence_type": "human-review-record", "verification": "human" } ], "fit": "direct", "basis": "anchored", "relation": "satisfies", "rationale": "SR 26-2 \u00a7VI (Governance and Controls) addresses documentation under its Documentation subheading \u2014 sufficient for a knowledgeable third party to understand a model's development, validation, and use. The MR evidence package operationalizes that documentation expectation across the model portfolio." }, { "control": "apeiris://compliance/controls/AU-05", "id": "AU-05", "domain": "compliance", "name": "Regulatory Examination Response Program", "validation_objective": "The organization must have a documented, tested examination response program with a current regulatory playbook, a defined response team with assigned roles and named deputies, and regulator-specific response guides for each material regulatory relationship, such that any formal regulatory inquiry is triaged within 4 business hours and a response team with appropriate legal representation is activated within 24 hours of receipt. Zero regulatory response deadlines may be missed.", "blocking_effect": "requires-review", "evidence_required": [ "regulatory_examination_response_playbook with version date within the last 12 months, documented tier classification criteria (routine, examination, investigation, enforcement), and response team activation procedures for each tier", "response_team_roster documenting all designated team members by role (response coordinator, legal counsel lead, SME pool, document production manager, executive sponsor) with named deputies and current contact information", "document_production_log from all regulatory responses in the last 24 months confirming legal privilege review, scoping analysis, and production transmittal documentation were completed for each production", "post_examination_after_action_report for each examination closed in the last 24 months, completed within 30 days of closure and showing lessons-learned implementation status and playbook update record", "regulatory_response_deadline_compliance_record listing all response deadlines and submission dates for the last 24 months, confirming zero missed deadlines" ], "evidence": [ { "id": "AU-05-E1", "description": "regulatory_examination_response_playbook with version date within the last 12 months, documented tier classification criteria (routine, examination, investigation, enforcement), and response team activation procedures for each tier", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AU-05-E2", "description": "response_team_roster documenting all designated team members by role (response coordinator, legal counsel lead, SME pool, document production manager, executive sponsor) with named deputies and current contact information", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AU-05-E3", "description": "document_production_log from all regulatory responses in the last 24 months confirming legal privilege review, scoping analysis, and production transmittal documentation were completed for each production", "evidence_type": "human-review-record", "verification": "human" }, { "id": "AU-05-E4", "description": "post_examination_after_action_report for each examination closed in the last 24 months, completed within 30 days of closure and showing lessons-learned implementation status and playbook update record", "evidence_type": "policy-attestation", "verification": "attested" }, { "id": "AU-05-E5", "description": "regulatory_response_deadline_compliance_record listing all response deadlines and submission dates for the last 24 months, confirming zero missed deadlines", "evidence_type": "policy-attestation", "verification": "attested" } ], "fit": null, "basis": null, "relation": null, "rationale": null } ] } ] } ] }