> ## Documentation Index > Fetch the complete documentation index at: https://docs.aigoframework.com/llms.txt > Use this file to discover all available pages before exploring further. # 02 AIGO Cross Framework Requirements Mapping v0.1 # AIGO — Cross-Framework Requirements Mapping ## 1. Document Purpose This document defines the cross-framework requirements mapping between: * the European Union Artificial Intelligence Act; * ISO/IEC 42001:2023; and * NIST AI RMF 1.0; and the AIGO operational governance architecture. The purpose is to identify where requirements or outcomes from different frameworks address related governance objectives and can therefore use common AIGO controls, evidence, monitoring, and assurance. This document does **not** declare that requirements from different frameworks are legally or normatively equivalent. The individual framework mappings remain authoritative for the exact interpretation of each source requirement. *** # 2. Mapping Information | Field | Value | | ------------------- | ---------------------------------------------------- | | Mapping | AIGO Cross-Framework Requirements Mapping | | Version | 0.1 | | Status | Draft | | Document Identifier | `AIGO-MAP-XFW-002` | | Document Type | Cross-Framework Requirements Mapping | | Mapping Package | `AIGO-MAP-XFW` | | Architecture | `AIGO-MAP-XFW-ARCH-001` | | Registry | `00-AIGO-Cross-Framework-Mapping-Registry-v0.1.json` | | Primary Function | Cross-framework requirement harmonization | *** # 3. Source Framework Baselines The cross-framework requirements model currently uses: ```text theme={null} EU AI Act ↓ Regulation (EU) 2024/1689 + applicable amendments ISO/IEC 42001 ↓ ISO/IEC 42001:2023 NIST AI RMF ↓ NIST AI 100-1 AI RMF 1.0 ``` The current EU legal baseline includes Regulation (EU) 2024/1689 and Regulation (EU) 2026/1744, which amended the AI Act as part of the Digital Omnibus on AI. ISO identifies ISO/IEC 42001:2023 as a published International Standard specifying requirements for an Artificial Intelligence Management System. NIST identifies AI RMF 1.0 as NIST AI 100-1 and currently states that AI RMF 1.0 is being updated. *** # 4. Normative Status The cross-framework requirements model must preserve the different status of each source. | Framework | Status | | ------------- | ---------------------------------------- | | EU AI Act | Binding EU legislation | | ISO/IEC 42001 | International management-system standard | | NIST AI RMF | Voluntary risk-management framework | A relationship between requirements does not change these statuses. *** # 5. Requirements Mapping Principle The fundamental relationship is: ```text theme={null} External Requirement ↓ Requirement Interpretation ↓ Cross-Framework Relationship ↓ AIGO Governance Objective ↓ AIGO Control ``` The source requirement remains independently identifiable. *** # 6. Requirement Relationship Types This document uses: ```text theme={null} DIRECT PARTIAL OVERLAPPING COMPLEMENTARY INTEGRATED CONDITIONAL SUPPORTING CONFLICTING NO_DIRECT_EQUIVALENT ``` ## DIRECT The source requirements address substantially the same operational governance objective. ## PARTIAL One source addresses only part of the operational objective. ## OVERLAPPING The source requirements cover related governance subject matter but have different scope or criteria. ## COMPLEMENTARY The requirements address different aspects of the same governance objective. ## INTEGRATED Multiple source requirements can be operationalized through a common AIGO process. ## CONDITIONAL The relationship applies only under specified applicability conditions. ## SUPPORTING One requirement provides useful support for another but does not satisfy it. ## CONFLICTING The requirements cannot safely be treated as a single requirement or control relationship without additional analysis. ## NO\_DIRECT\_EQUIVALENT There is no defensible common requirement relationship. *** # 7. Requirement Identity Rule Every requirement retains its original source identity. For example: ```text theme={null} EUAI-ART-005 ISO42001-CLAUSE-... NIST-AIRMF-GOVERN-... ``` A common AIGO control must never replace the source identifier. *** # 8. Applicability Rule Cross-framework mapping occurs only after framework-specific applicability is determined. The sequence is: ```text theme={null} Source Framework ↓ Applicability ↓ Requirement ↓ AIGO Relationship ↓ Control ``` An organization must not mark a requirement as applicable solely because another framework maps to the same AIGO control. *** # 9. Cross-Framework Requirement Matrix The following matrix identifies major governance areas where the frameworks can be operationally connected. | Governance Area | EU AI Act | ISO/IEC 42001 | NIST AI RMF | Primary AIGO Layer | | --------------- | ----------------------------------------------- | ---------------------------------- | ---------------------------------- | ------------------ | | Governance | Applicable statutory governance duties | Clauses 4–10 governance | GOVERN | Governance | | Context | Applicability and system context | Clause 4 | MAP | Context | | Applicability | Legal applicability / classification | AIMS scope | Organizational tailoring | Assessment | | AI risk | Applicable risk-management duties | Risk and opportunity management | MAP / MANAGE | Risk | | Impact | Fundamental-rights and other applicable impacts | AI-related impact/risk governance | MAP | Assessment | | Data | Applicable data governance | AIMS controls | MAP / MEASURE | Control | | Lifecycle | Applicable lifecycle duties | AI operational management | All functions | AI System | | Human oversight | Applicable statutory requirements | AI governance controls | Human factors / trustworthy AI | Control | | Transparency | Statutory transparency requirements | Transparency-related controls | Accountable and transparent | Control | | Performance | Applicable technical requirements | Performance evaluation | MEASURE | Monitoring | | Security | Applicable cybersecurity duties | Security-related controls | Secure and resilient | Control | | Privacy | Applicable privacy interfaces | AI management controls | Privacy-enhanced | Risk | | Fairness | Applicable discrimination/bias requirements | Risk/impact controls | Fairness with harmful bias managed | Risk | | Monitoring | Applicable post-deployment duties | Clause 9 | MEASURE / MANAGE | Monitoring | | Incidents | Applicable reporting duties | Nonconformity / improvement | MANAGE | Incident | | Change | Applicable significant-change consequences | Change planning | Reassessment / MANAGE | Change | | Competence | AI literacy requirements where applicable | Competence / awareness | Governance capabilities | Governance | | Documentation | Statutory documentation requirements | Documented information | Evidence and documentation | Evidence | | Assurance | Regulatory / conformity mechanisms | Internal audit / management review | Risk assurance | Assurance | | Improvement | Corrective and regulatory action | Clause 10 | MANAGE / iterative improvement | Improvement | | Retirement | Applicable lifecycle / record obligations | AI lifecycle | Lifecycle risk management | Retirement | This table is an architectural harmonization view, not a substitute for the individual framework mappings. *** # 10. Governance Requirements ## 10.1 Common Objective The common objective is: > Establish accountable organizational governance for AI systems and AI-related risks. ### EU AI Act The EU AI Act establishes obligations that vary according to the role, system type, risk classification, and applicable provisions. ### ISO/IEC 42001 ISO/IEC 42001 establishes organizational management-system requirements covering context, leadership, planning, support, operation, performance evaluation, and improvement. ISO describes the standard as a management-system standard for organizations providing or using AI-based products or services. ### NIST AI RMF GOVERN establishes organizational governance, policies, roles, and processes for AI risk management. NIST describes GOVERN as a cross-cutting function of the AI RMF Core. ### Cross-Framework Relationship `INTEGRATED` ### AIGO Control `AIGO-XFW-GOV-001` *** # 11. Context Requirements ## 11.1 Common Objective Establish sufficient organizational and AI-system context to understand applicable requirements, risks, stakeholders, and impacts. ### EU AI Act Context supports legal applicability, classification, role determination, and system-specific obligations. ### ISO/IEC 42001 Clause 4 establishes the organizational context and AIMS scope. ### NIST AI RMF MAP establishes contextual understanding of AI systems, actors, impacts, and risks. NIST describes MAP as one of the four Core functions and states that AI risk management is performed throughout the AI lifecycle. ### Cross-Framework Relationship `DIRECT / INTEGRATED` ### AIGO Control `AIGO-XFW-CTX-001` *** # 12. AIMS and AI Governance Scope ## 12.1 Common Objective Define the boundary within which AI governance requirements are applied. ### EU AI Act The relevant legal scope depends on the Act's applicability provisions and the organization's role and AI activities. ### ISO/IEC 42001 The organization establishes the scope of its AIMS based on organizational context and relevant requirements. ### NIST AI RMF NIST permits organizations to tailor AI RMF implementation to their context, use cases, and needs. ### Relationship `COMPLEMENTARY` ### AIGO Control `AIGO-XFW-APP-001` *** # 13. AI System Identification ## 13.1 Common Objective Maintain a reliable inventory and identity for AI systems subject to governance. ### EU AI Act System identity and classification support identification of applicable statutory obligations. ### ISO/IEC 42001 An AIMS requires organizational governance over relevant AI activities and systems. ### NIST AI RMF MAP requires understanding the AI system and its context. ### Relationship `INTEGRATED` ### AIGO Control `AIGO-XFW-CTX-001` ### AIGO Schema `AI System` *** # 14. AI Classification ## 14.1 Common Objective Determine relevant categories or classifications before applying downstream controls. ### EU AI Act The Act contains legal classifications including prohibited practices, high-risk AI, transparency-related obligations, and GPAI-related obligations. ### ISO/IEC 42001 Classification is context- and risk-dependent rather than a statutory EU AI Act-style risk taxonomy. ### NIST AI RMF NIST uses contextual risk framing rather than a legally binding risk class taxonomy. ### Relationship `COMPLEMENTARY` ### Critical Rule An organization's internal AI risk rating must not be represented as the EU AI Act's legal classification. ### AIGO Control `AIGO-XFW-CLS-001` *** # 15. AI Risk Management ## 15.1 Common Objective Identify, analyze, evaluate, prioritize, treat, monitor, and reassess AI risks. ### EU AI Act The AI Act establishes risk-management requirements for applicable AI systems, including high-risk systems. ### ISO/IEC 42001 The standard provides a management-system structure for managing AI-related risks and opportunities. ISO describes ISO/IEC 42001 as a management-system standard covering AI-related risks and opportunities. ### NIST AI RMF MAP and MANAGE provide risk-context and risk-treatment functions. NIST describes AI RMF as a voluntary resource for managing AI risks and promoting trustworthy and responsible development and use. ### Relationship `DIRECT / INTEGRATED` ### AIGO Control `AIGO-XFW-RSK-001` *** # 16. Risk Treatment ## 16.1 Common Objective Turn risk assessments into documented decisions and controls. ### EU AI Act Applicable systems may have legally defined risk-management and risk-control obligations. ### ISO/IEC 42001 Risk and opportunity treatment forms part of AIMS planning and operation. ### NIST AI RMF MANAGE uses risk analysis and measurement results to prioritize and respond to risk. ### Relationship `DIRECT / INTEGRATED` ### AIGO Control `AIGO-XFW-RSK-001` *** # 17. Residual Risk ## 17.1 Common Objective Maintain an explicit decision regarding risk remaining after treatment. ### EU AI Act Residual-risk concepts may arise within applicable system risk-management requirements. ### ISO/IEC 42001 Residual risk is relevant to risk-treatment and management-system decisions. ### NIST AI RMF MANAGE addresses risk response and prioritization. ### Relationship `COMPLEMENTARY` ### AIGO Control `AIGO-XFW-RSK-002` *** # 18. Impact Assessment ## 18.1 Common Objective Identify and assess potential impacts on individuals, groups, organizations, and society. ### EU AI Act Applicable provisions address fundamental rights and other impacts depending on the AI system and actor. ### ISO/IEC 42001 AI impact and risk considerations can be incorporated into AIMS processes. ### NIST AI RMF MAP includes understanding risks, impacts, harms, and context. NIST explicitly frames AI risk management around potential negative impacts as well as positive impacts and opportunities. ### Relationship `COMPLEMENTARY / INTEGRATED` ### AIGO Control `AIGO-XFW-IMP-001` *** # 19. Data Governance ## 19.1 Common Objective Govern AI-related data according to its intended use, quality requirements, risk, privacy, fairness, security, and lifecycle. ### EU AI Act Applicable high-risk AI requirements include data-governance requirements. ### ISO/IEC 42001 AIMS controls address AI data-related governance where applicable. ### NIST AI RMF Data quality and measurement affect validity, reliability, fairness, privacy, and other trustworthiness considerations. ### Relationship `INTEGRATED` ### AIGO Control `AIGO-XFW-DATA-001` *** # 20. AI Lifecycle Governance ## 20.1 Common Objective Apply governance across the AI lifecycle. ### EU AI Act Applicable obligations may arise before deployment, during operation, after deployment, and following relevant changes. ### ISO/IEC 42001 Operational planning and AI-system management operate within the AIMS. ### NIST AI RMF The AI RMF Core is intended to operate across AI lifecycle dimensions. NIST states that AI risk management should be continuous and performed throughout the AI system lifecycle. ### Relationship `DIRECT / INTEGRATED` ### AIGO Control `AIGO-XFW-LIFE-001` *** # 21. Human Oversight ## 21.1 Common Objective Ensure that human oversight is appropriately designed and operational where required. ### EU AI Act Applicable high-risk AI requirements include human oversight. ### ISO/IEC 42001 Human-related governance and control mechanisms can be incorporated into the AIMS. ### NIST AI RMF Human and organizational factors are integral to trustworthy AI risk management. ### Relationship `COMPLEMENTARY` ### AIGO Control `AIGO-XFW-HUM-001` ### Boundary An organization must not treat a generic NIST or ISO human-oversight control as automatically satisfying an EU AI Act statutory requirement. *** # 22. Transparency ## 22.1 Common Objective Provide appropriate information about AI systems, their operation, limitations, and relevant consequences. ### EU AI Act The Act establishes specific transparency obligations for defined circumstances. ### ISO/IEC 42001 Transparency is incorporated into AI management-system governance. ### NIST AI RMF Accountability and transparency are trustworthiness characteristics. ### Relationship `COMPLEMENTARY / INTEGRATED` ### AIGO Control `AIGO-XFW-TRANS-001` *** # 23. Performance Evaluation ## 23.1 Common Objective Evaluate whether an AI system performs appropriately for its intended purpose and risk context. ### EU AI Act Applicable high-risk requirements include accuracy, robustness, and cybersecurity-related requirements. ### ISO/IEC 42001 Performance evaluation forms part of the AIMS. ### NIST AI RMF MEASURE evaluates AI risks and trustworthiness characteristics. ### Relationship `DIRECT / INTEGRATED` ### AIGO Control `AIGO-XFW-PERF-001` *** # 24. Safety ## 24.1 Common Objective Identify, evaluate, control, and monitor safety risks. ### EU AI Act Applicable AI systems may have statutory safety and risk-management requirements. ### ISO/IEC 42001 Safety can be addressed as an AI risk within the AIMS. ### NIST AI RMF Safety is a trustworthiness characteristic. ### Relationship `COMPLEMENTARY` ### AIGO Control `AIGO-XFW-SAFE-001` *** # 25. Security and Resilience ## 25.1 Common Objective Protect AI systems from security threats and support resilience. ### EU AI Act Applicable requirements address cybersecurity and robustness. ### ISO/IEC 42001 Security-related AI controls can be integrated into the AIMS. ### NIST AI RMF Secure and resilient is a trustworthiness characteristic. ### Relationship `INTEGRATED` ### AIGO Control `AIGO-XFW-SEC-001` *** # 26. Privacy ## 26.1 Common Objective Identify and manage privacy risks associated with AI systems. ### EU AI Act Privacy and data-protection obligations interact with the AI Act but remain subject to applicable privacy law. ### ISO/IEC 42001 Privacy-related AI governance can be incorporated into the AIMS. ### NIST AI RMF Privacy-enhanced is a trustworthiness characteristic. ### Relationship `COMPLEMENTARY` ### AIGO Control `AIGO-XFW-PRIV-001` ### Boundary The EU AI Act mapping does not replace GDPR or other applicable privacy mappings. *** # 27. Fairness and Harmful Bias ## 27.1 Common Objective Identify and mitigate unfairness, discrimination, and harmful bias. ### EU AI Act Applicable provisions address discrimination, fundamental rights, and data/governance requirements. ### ISO/IEC 42001 Fairness-related risks may be governed through AI risk and impact processes. ### NIST AI RMF Fairness with harmful bias managed is a core trustworthiness characteristic. ### Relationship `COMPLEMENTARY / INTEGRATED` ### AIGO Control `AIGO-XFW-FAIR-001` *** # 28. Explainability and Interpretability ## 28.1 Common Objective Provide appropriate understanding of AI-system behavior. ### EU AI Act Applicable transparency and information obligations depend on system type and role. ### ISO/IEC 42001 Explainability-related controls can be incorporated into the AIMS. ### NIST AI RMF Explainability and interpretability are trustworthiness characteristics. ### Relationship `COMPLEMENTARY` ### AIGO Control `AIGO-XFW-EXP-001` *** # 29. Monitoring and Measurement ## 29.1 Common Objective Measure and monitor AI-system and governance performance. ### EU AI Act Applicable systems may have monitoring and post-market obligations. ### ISO/IEC 42001 Clause 9 provides the performance-evaluation layer. ### NIST AI RMF MEASURE and MANAGE support ongoing risk monitoring. ### Relationship `DIRECT / INTEGRATED` ### AIGO Control `AIGO-XFW-MON-001` *** # 30. Incident Management ## 30.1 Common Objective Identify, investigate, respond to, document, and learn from AI-related incidents. ### EU AI Act Certain serious incidents create specific regulatory obligations. ### ISO/IEC 42001 Nonconformities, corrective actions, and improvement mechanisms support incident-related governance. ### NIST AI RMF MANAGE includes incident response and learning. ### Relationship `INTEGRATED` ### AIGO Control `AIGO-XFW-INC-001` ### Critical Boundary The same incident record may support multiple frameworks, but statutory reporting criteria and deadlines remain framework-specific. *** # 31. Change Management ## 31.1 Common Objective Assess and control material changes to AI systems and governance. ### EU AI Act Certain changes can affect regulatory classification or obligations. ### ISO/IEC 42001 Management-system changes require controlled planning. ### NIST AI RMF AI risks must be reassessed as context and systems evolve. ### Relationship `INTEGRATED / CONDITIONAL` ### AIGO Control `AIGO-XFW-CHG-001` *** # 32. Third-Party Governance ## 32.1 Common Objective Control risks created by external providers, models, datasets, software, infrastructure, and services. ### EU AI Act Role-specific provider/deployer/downstream obligations may apply. ### ISO/IEC 42001 Externally provided processes and services are part of management-system control. ### NIST AI RMF AI supply-chain and third-party risk are relevant to AI risk management. ### Relationship `INTEGRATED` ### AIGO Control `AIGO-XFW-TPG-001` *** # 33. Competence and AI Literacy ## 33.1 Common Objective Ensure people performing AI governance activities have appropriate knowledge, skills, and awareness. ### EU AI Act Article 4 establishes AI-literacy requirements for providers and deployers within the Act's scope. ### ISO/IEC 42001 Competence and awareness are management-system requirements. ### NIST AI RMF Governance requires appropriate organizational capability and multidisciplinary expertise. ### Relationship `INTEGRATED / CONDITIONAL` ### AIGO Control `AIGO-XFW-COMP-001` ### Boundary EU AI Act AI-literacy compliance remains a separate statutory relationship from ISO competence and NIST governance capability. *** # 34. Documentation ## 34.1 Common Objective Maintain controlled documentation supporting AI governance. ### EU AI Act Applicable systems may require technical documentation and other regulated documentation. ### ISO/IEC 42001 Documented information is a core management-system requirement. ### NIST AI RMF Documentation supports transparency, risk management, measurement, and accountability. ### Relationship `INTEGRATED` ### AIGO Control `AIGO-XFW-DOC-001` *** # 35. Records and Logging ## 35.1 Common Objective Maintain reliable records of governance actions and AI-system activity where required. ### EU AI Act Applicable record-keeping and logging requirements may apply. ### ISO/IEC 42001 The AIMS requires controlled documented information and records. ### NIST AI RMF Records support evidence and reproducibility of risk-management activities. ### Relationship `INTEGRATED` ### AIGO Control `AIGO-XFW-REC-001` *** # 36. Assurance ## 36.1 Common Objective Evaluate whether governance requirements and controls are appropriately implemented and effective. ### EU AI Act Regulatory conformity mechanisms and statutory oversight are distinct from internal AIGO assurance. ### ISO/IEC 42001 Internal audit and management review provide management-system performance evaluation. ### NIST AI RMF Organizations can evaluate implementation of selected AI RMF outcomes through their assurance processes. ### Relationship `COMPLEMENTARY / INTEGRATED` ### AIGO Control `AIGO-XFW-ASSR-001` *** # 37. Internal Audit and External Assessment The cross-framework architecture must preserve: ```text theme={null} Internal AIGO Assurance ≠ ISO Internal Audit ≠ ISO Certification Audit ≠ EU Statutory Conformity Assessment ≠ NIST Framework Assessment ``` A shared evidence base may support multiple activities, but authority and criteria remain distinct. *** # 38. Management Review ## 38.1 Common Objective Provide management with evidence-based information for governance decisions. ### EU AI Act Management review may support organizational oversight but does not replace statutory obligations. ### ISO/IEC 42001 Management review is a direct management-system mechanism. ### NIST AI RMF Governance decisions and risk-management outcomes can be incorporated into management review. ### Relationship `INTEGRATED` ### AIGO Control `AIGO-XFW-MREV-001` *** # 39. Corrective Action ## 39.1 Common Objective Address failures, findings, incidents, and identified control weaknesses. ### EU AI Act Corrective measures may be required by competent authorities or under applicable legal obligations. ### ISO/IEC 42001 Corrective action is part of continual improvement. ### NIST AI RMF Risk treatment and iterative improvement support corrective action. ### Relationship `COMPLEMENTARY / INTEGRATED` ### AIGO Control `AIGO-XFW-IMPR-001` *** # 40. Continual Improvement ## 40.1 Common Objective Use monitoring, incidents, assurance, and management decisions to improve AI governance. ### EU AI Act Improvement activities can support ongoing compliance but do not replace mandatory legal action. ### ISO/IEC 42001 Continual improvement is a management-system requirement. ### NIST AI RMF AI risk management is intended to operate iteratively and continuously. NIST states that risk management should be continuous, timely, and performed throughout AI-system lifecycle dimensions. ### Relationship `DIRECT / INTEGRATED` ### AIGO Control `AIGO-XFW-IMPR-001` *** # 41. Retirement ## 41.1 Common Objective Terminate AI systems in a controlled manner while preserving required records and resolving residual obligations. ### EU AI Act Applicable lifecycle, record, and post-deployment obligations may affect retirement. ### ISO/IEC 42001 AI-system lifecycle governance includes controlled lifecycle management. ### NIST AI RMF Risk management continues through the AI lifecycle and should consider changing contexts and risks. ### Relationship `COMPLEMENTARY` ### AIGO Control `AIGO-XFW-RET-001` *** # 42. Framework-Specific Requirements Not every requirement has a shared equivalent. The following categories should generally remain framework-specific. ## EU AI Act-specific Examples include: * prohibited AI practices; * statutory high-risk classification; * GPAI-specific obligations; * regulatory registration; * CE/conformity mechanisms; * statutory transparency obligations; * regulatory reporting; * enforcement; * legally defined rights and remedies. These should remain anchored in the EU AI Act mapping. *** # 43. ISO/IEC 42001-Specific Requirements Examples include: * AIMS scope; * management-system planning; * internal-audit programme; * management review; * management-system continual improvement; * ISO-specific Annex A applicability and controls. These remain anchored in the ISO/IEC 42001 mapping. *** # 44. NIST AI RMF-Specific Elements Examples include: * GOVERN; * MAP; * MEASURE; * MANAGE; * trustworthiness characteristics; * NIST-specific profiles; * voluntary tailoring; * NIST implementation guidance. These remain anchored in the NIST mapping. NIST explicitly states that AI RMF Core actions are not a checklist or necessarily an ordered sequence. *** # 45. Requirement Equivalence Rule A cross-framework relationship must not be described as: ```text theme={null} "Requirement A = Requirement B" ``` unless equivalence can be formally established. Preferred wording: ```text theme={null} "Both requirements are operationalized through AIGO Control X." ``` This preserves the distinction between source requirements. *** # 46. Requirement-to-Control Relationship The canonical relationship is: ```text theme={null} Framework A Requirement ↓ AIGO Control X Framework B Requirement ↓ AIGO Control X ``` not: ```text theme={null} Framework A Requirement = Framework B Requirement ``` *** # 47. Requirement-to-Evidence Relationship Evidence should be evaluated separately: ```text theme={null} EU Requirement ↓ Evidence E ISO Requirement ↓ Evidence E NIST Outcome ↓ Evidence E ``` The same evidence can support each relationship if sufficient. *** # 48. Evidence Sufficiency Potential outcomes: ```text theme={null} SUFFICIENT SUFFICIENT_WITH_EXTENSION PARTIAL INSUFFICIENT NOT_APPLICABLE ``` Sufficiency is always relative to the source criterion. *** # 49. Requirement-to-Assurance Relationship Assurance should remain criterion-specific: ```text theme={null} Requirement ↓ AIGO Control ↓ Evidence ↓ Framework Criteria ↓ Assurance ``` A single audit or assurance activity may contain multiple criteria. *** # 50. Common-Control Gap A common control gap occurs when: ```text theme={null} Framework Requirement ↓ No adequate AIGO Control ``` This should generate: `XFW_CONTROL_GAP` rather than forcing an incorrect relationship. *** # 51. Framework-Specific Gap A framework-specific gap occurs when: ```text theme={null} AIGO Control exists ↓ Framework-specific requirement remains uncovered ``` Example: ```text theme={null} Common Governance Control + EU statutory extension missing ``` This should produce: `XFW_FRAMEWORK_SPECIFIC_GAP` *** # 52. Cross-Framework Overlap An overlap exists when several frameworks address materially related governance subject matter. Examples: * risk management; * monitoring; * governance; * lifecycle; * transparency; * evidence. Overlap should lead to harmonization analysis, not automatic equivalence. *** # 53. Complementary Requirements Complementary requirements should be retained where one framework adds something absent from another. Example: ```text theme={null} Common Risk Management + EU statutory classification ``` The statutory element remains a framework-specific extension. *** # 54. Conflicting Requirements Where requirements differ materially: ```text theme={null} Requirement A Requirement B ↓ CONFLICTING ↓ Review ↓ Decision ``` The repository must preserve the original requirements and the documented resolution. *** # 55. Version-Specific Requirement Mapping Every mapping must identify: * framework; * version; * requirement; * AIGO mapping version; * control version. This allows historical reconstruction after framework changes. *** # 56. Current NIST Version Rule The NIST mapping currently uses AI RMF 1.0. NIST currently states that AI RMF 1.0 is being updated. Therefore, future NIST revisions must not silently alter this v0.1 mapping. *** # 57. Current ISO Version Rule The ISO mapping currently uses: `ISO/IEC 42001:2023` ISO lists this as Edition 1, published in December 2023. Future revisions or related standards must be separately versioned. *** # 58. Current EU AI Act Version Rule The EU mapping must preserve the legal source and applicable amendments. Regulation (EU) 2026/1744 was adopted on 8 July 2026 and published on 24 July 2026 as an amendment to Regulation (EU) 2024/1689 and other EU legislation. The AIGO repository should therefore avoid using a generic, unversioned label such as: `EU AI Act` as the sole machine-readable source identifier. *** # 59. Cross-Framework Requirement Registry The cross-framework registry should eventually maintain: ```text theme={null} relationshipId frameworkId sourceRequirementId frameworkVersion aigoControlId relationshipType applicability priority mappingStatus reviewDate ``` *** # 60. Coverage Calculation Cross-framework requirement coverage should be calculated as: ```text theme={null} Applicable Requirements ↓ Mapped Requirements ↓ Controlled Requirements ↓ Implemented Requirements ↓ Evidenced Requirements ↓ Assured Requirements ``` Coverage percentages must be reported separately by framework. *** # 61. No Universal Compliance Score The repository must not produce a single value such as: `97% compliant` by simply aggregating: * EU AI Act coverage; * ISO coverage; * NIST coverage. Such a number would mix fundamentally different frameworks and criteria. *** # 62. Framework-Specific Coverage Instead: ```text theme={null} EU AI Act: Coverage by applicable legal requirement ISO/IEC 42001: Coverage by applicable AIMS requirement NIST AI RMF: Coverage by selected AI RMF outcomes ``` These results can then be presented in a consolidated management view. *** # 63. Cross-Framework Coverage View A management dashboard may show: | Framework | Requirements / Outcomes | Controls | Evidence | Assurance | | ------------- | ----------------------: | ------------------: | ----------------: | --------------------------------: | | EU AI Act | Framework-specific | Shared + extensions | Shared + specific | Shared + specific | | ISO/IEC 42001 | Management-system | Shared + extensions | Shared + specific | Internal / certification-specific | | NIST AI RMF | Selected outcomes | Shared + extensions | Shared + specific | Internal assurance | Actual values should be generated from validated repository data. *** # 64. Management Use The cross-framework requirements mapping should enable management to identify: * common governance obligations; * framework-specific obligations; * resource concentration; * duplicated activities; * evidence reuse; * assurance reuse; * unresolved conflicts; * regulatory exposure. *** # 65. Implementation Boundary This document identifies relationships. Detailed implementation instructions remain in: ```text theme={null} framework/ guidance/ mappings// ``` The common procedures and templates remain in the AIGO guidance layer. *** # 66. Control Boundary Detailed control definitions remain in the AIGO Control Schema and control architecture. This document identifies which source requirements may be operationalized through those controls. *** # 67. Evidence Boundary Detailed evidence definitions remain in: ```text theme={null} schemas/10-evidence/ ``` and: ```text theme={null} guidance/03-templates/ ``` The cross-framework requirements mapping identifies evidence relationships only at the framework-integration level. *** # 68. Assurance Boundary Detailed assurance methodology remains in the framework-specific assurance mappings and the AIGO Assurance Schema. This document identifies requirements that may share assurance infrastructure. *** # 69. Validation Requirements The cross-framework requirements mapping must pass: ```text theme={null} Framework Source Validation Requirement Reference Validation Version Validation Applicability Validation Control Reference Validation Traceability Validation Conflict Detection Coverage Validation Framework Consistency Document Integrity Repository Health ``` *** # 70. Potential Findings Potential findings include: ```text theme={null} XFW_REQUIREMENT_UNMAPPED XFW_CONTROL_GAP XFW_FRAMEWORK_SPECIFIC_GAP XFW_APPLICABILITY_GAP XFW_VERSION_GAP XFW_SOURCE_CONFLICT XFW_TRACEABILITY_GAP XFW_EVIDENCE_GAP XFW_ASSURANCE_GAP XFW_FALSE_EQUIVALENCE ``` *** # 71. Critical Finding — False Equivalence A particularly important v1 validation rule is: > A source requirement must never be marked satisfied solely because another framework has a similar requirement mapped to the same AIGO control. Example: ```text theme={null} EU requirement ↓ AIGO Control A NIST outcome ↓ AIGO Control A ``` does not prove: ```text theme={null} EU requirement = NIST outcome ``` The control is shared; the requirements remain distinct. *** # 72. Critical Finding — Missing Extension Where a common control lacks a legally required framework-specific extension: ```text theme={null} Common Control + Required EU Extension ✗ ``` the relationship must be considered incomplete for that source requirement. *** # 73. Critical Finding — Evidence Reuse Error If the same evidence is reused across frameworks but does not satisfy the criteria of one framework: `XFW_EVIDENCE_GAP` must be generated for that relationship. *** # 74. Critical Finding — Assurance Reuse Error If an assurance conclusion is copied between frameworks without evaluating the separate criteria: `XFW_ASSURANCE_GAP` or: `XFW_FALSE_EQUIVALENCE` should be raised. *** # 75. Critical Finding — Version Conflict If: ```text theme={null} Source Requirement → version A Registry → version B Mapping → version C ``` the repository has a: `XFW_VERSION_GAP` until the relationship is reconciled. *** # 76. Final Cross-Framework Requirement Chain The intended chain is: ```text theme={null} Framework ↓ Requirement ↓ Applicability ↓ AIGO Governance Objective ↓ AIGO Common Control ↓ Framework-Specific Extension ↓ Process ↓ Evidence ↓ Monitoring ↓ Assurance ↓ Finding ↓ Improvement ``` *** # 77. Final Requirement-Harmonization Principle The AIGO cross-framework requirements layer follows one governing principle: > **Harmonize operational implementation, not the underlying requirements.** AIGO should provide one coherent operating architecture where possible, while preserving the separate: * legal requirements; * standards requirements; * voluntary framework outcomes; * applicability rules; * evidence criteria; * assurance criteria; * version histories. *** # 78. Document Control | Field | Value | | -------------------------- | ----------------------------------------- | | Document | AIGO Cross-Framework Requirements Mapping | | Version | 0.1 | | Status | Draft | | Document Identifier | `AIGO-MAP-XFW-002` | | Document Type | Cross-Framework Requirements Mapping | | Mapping Package | `AIGO-MAP-XFW` | | Source Frameworks | EU AI Act, ISO/IEC 42001, NIST AI RMF | | Owner | | | Framework Reviewers | | | Legal / Standards Reviewer | | | Governance Reviewer | | | Control Reviewer | | | Evidence Reviewer | | | Assurance Reviewer | | | Framework Architect | | | Approved By | | | Effective Date | | | Next Review Date | | *** # 79. Document Status **Document:** AIGO — Cross-Framework Requirements Mapping **Version:** 0.1 **Status:** Draft **Working Name:** AIGO **Full Name:** AI Governance Operating Framework **Document Identifier:** `AIGO-MAP-XFW-002` **Document Type:** Cross-Framework Requirements Mapping This document establishes the requirement-level harmonization architecture for the EU AI Act, ISO/IEC 42001, and NIST AI RMF mappings, connecting related source requirements to common AIGO governance objectives and controls while explicitly preserving framework-specific applicability, legal or normative status, evidence requirements, assurance criteria, and version history. End of Document