This document presents a technical control alignment matrix mapping QODIQA enforcement constructs to major AI and data governance frameworks: GDPR, EU AI Act, NIST AI Risk Management Framework, ISO/IEC 27001, ISO/IEC 42001, and the OECD AI Principles.
The matrix is structured around a deterministic enforcement anchor model. For each regulatory requirement, it identifies which QODIQA controls provide structural support, the evidence artifacts generated, and the residual scope not addressed by runtime enforcement. This document does not constitute legal advice. It does not certify regulatory compliance. It is a technical cross-reference instrument.
The matrix is intended for enterprise risk teams, compliance architects, regulatory affairs specialists, and AI governance practitioners evaluating the control coverage characteristics of QODIQA within their broader compliance posture.
How to Read This Matrix (Non-Normative)
Direct: The control enforces the requirement deterministically at runtime.
Structural: The system produces verifiable evidence supporting the requirement, but does not enforce it directly.
Out of Scope: The requirement lies outside the runtime enforcement boundary and is not addressed.
#Purpose and Scope
1.1 Purpose of This Matrix
This Regulatory Alignment Matrix provides a structured, technical mapping of QODIQA enforcement constructs to the requirements of major AI and data governance frameworks. Its purpose is to enable organizations deploying QODIQA to understand, in precise structural terms, which regulatory control objectives are addressed by deterministic runtime consent enforcement, which are partially supported through evidence generation, and which fall outside the scope of the QODIQA enforcement boundary.
The matrix answers four operational questions: Which QODIQA controls correspond to which regulatory requirements? What evidence artifacts does QODIQA generate that may be relevant to regulatory demonstrability? Where does QODIQA not claim coverage? How does deterministic runtime enforcement reduce the ambiguity surface at execution time?
This document does not constitute legal advice. It does not represent regulatory guidance from any supervisory authority. It does not guarantee, certify, or warrant compliance with any regulation, standard, or law referenced herein. All regulatory interpretation, gap analysis, legal assessment, and compliance determination must be performed by qualified legal counsel and certified compliance professionals in the relevant jurisdiction. QODIQA's role is technical control enforcement, not regulatory adjudication.
1.2 Scope of Interpretation
Mappings in this document are limited to structural and functional alignment between QODIQA enforcement constructs and published regulatory text or guidance. The matrix does not interpret regulatory intent, predict supervisory authority interpretation, or assess the legal sufficiency of any particular implementation. Regulatory frameworks are cited in their published form as of Q1 2026.
1.3 Relationship to QODIQA Corpus
| Document | Document ID | Relationship to This Matrix |
|---|---|---|
| Core Standard v1.0 | QODIQA-CORE-1.0 | Normative source for enforcement constructs cited in mappings |
| 68-Point Enforcement Framework | QODIQA-68P-1.0 | Source of control identifiers used in alignment tables |
| Certification Framework v1.0 | QODIQA-CERT-1.0 | Defines audit artifacts referenced as evidence outputs |
| Implementation Playbook v1.0 | QODIQA-PLAY-1.0 | Operational context for deployment-level control activation |
| Security and Cryptographic Profile v1.0 | QODIQA-SEC-1.0 | Cryptographic evidence generation supporting audit trails |
| Reference Architecture v1.0 | QODIQA-ARCH-1.0 | Structural enforcement model underlying all control mappings |
1.4 Frameworks Covered
| Framework | Jurisdiction / Body | Version / Edition | Mapping Type |
|---|---|---|---|
| General Data Protection Regulation (GDPR) | European Union | Regulation 2016/679 | Article-level control mapping |
| EU Artificial Intelligence Act | European Union | Regulation 2024/1689 | Obligation-level control mapping |
| NIST AI Risk Management Framework | NIST (USA) | AI RMF 1.0 (2023) | Function/category alignment |
| ISO/IEC 27001 | ISO / IEC JTC 1 | ISO/IEC 27001:2022 | Control family alignment |
| ISO/IEC 42001 | ISO / IEC JTC 1/SC 42 | ISO/IEC 42001:2023 | Clause-level structural mapping |
| OECD AI Principles | OECD | OECD/LEGAL/0449 (2024 rev.) | Principle-level structural support |
1.5 Scope Limitation
This document provides a technical crosswalk between the QODIQA enforcement model and selected regulatory frameworks. The mappings presented are analytical in nature and are intended to support architectural alignment discussions and technical interpretation. They do not constitute legal advice, regulatory interpretation, or formal compliance certification.
The Regulatory Alignment Matrix identifies where QODIQA technical controls structurally correspond to regulatory control objectives. It does not assess the sufficiency of those controls for any specific deployment context, nor does it substitute for jurisdiction-specific legal analysis. Organizations must conduct independent compliance assessments with qualified legal and regulatory counsel.
1.6 Regulatory Interpretation Disclaimer
The mappings presented in this matrix represent an analytical interpretation of how deterministic runtime consent enforcement may interact with existing governance frameworks. The alignment claims are structural and technical - they reflect the logical correspondence between QODIQA enforcement constructs and the stated control objectives of each framework.
Final regulatory interpretation remains the responsibility of competent authorities and qualified legal advisors. QODIQA does not claim regulatory authority, does not certify compliance outcomes, and does not warrant that any deployment of QODIQA controls satisfies the requirements of any referenced regulation or standard.
#Mapping Methodology
2.1 Control-Based Mapping Model
All mappings in this document are structured around QODIQA enforcement controls as the primary anchor. Each regulatory requirement is evaluated against the QODIQA control set to determine whether a direct structural correspondence exists, whether QODIQA provides supporting evidence without direct enforcement, or whether the requirement falls outside the enforcement boundary. This approach prevents overclaiming while identifying genuine structural contributions.
2.2 Mapping Logic Chain
Each alignment entry follows a four-stage traceability chain from QODIQA control through to residual gap disclosure:
2.3 Coverage Classification Scheme
| Classification | Definition | Indicator |
|---|---|---|
| Direct | QODIQA control directly enforces the requirement at runtime through deterministic gating, token validation, or cryptographic verification. | Direct |
| Structural | QODIQA generates structured, replayable evidence that supports demonstrability of the requirement but does not constitute enforcement of the requirement itself. | Structural |
| Partial | QODIQA addresses a subset of the requirement within the runtime enforcement boundary. Other dimensions of the requirement require complementary controls outside QODIQA. | Partial |
| Out of Scope | The requirement addresses areas outside the QODIQA enforcement boundary (e.g., model training, fairness, business process governance). No coverage claimed. | Out of Scope |
2.4 Evidence Artifact Classes
| Artifact Class | Description | Source |
|---|---|---|
| Consent Token (CT) | Cryptographically signed consent record with subject identity binding, scope, expiry, and purpose encoding | Core Standard 4; SEC Profile 4 |
| Audit Ledger Entry (ALE) | Append-only, hash-chained record of every enforcement decision at the SUP boundary | Core Standard 7; SEC Profile 8 |
| Enforcement Attestation (EA) | Signed summary of enforcement posture for a defined period or system scope | Certification Framework 6 |
| Revocation Record (RR) | Timestamped, cryptographically bound record of consent withdrawal with propagation confirmation | Core Standard 6; SEC Profile 6 |
| Purpose Binding Record (PBR) | Deterministic record of the declared purpose scope at time of consent grant and enforcement evaluation | Core Standard 3; 68-Point Framework C |
| Lifecycle Event Record (LER) | Structured record of AI system lifecycle state transitions from training through retirement | Core Standard 9; Reference Architecture 5 |
2.5 Interpretation Constraints
Mappings are structural, not legal. The presence of a QODIQA control in an alignment table does not imply that deploying QODIQA satisfies the associated regulatory requirement. Regulatory compliance requires legal analysis, operational controls, organizational governance, and in many cases external audit - none of which QODIQA substitutes for. QODIQA provides a technical control plane that may support compliance demonstration; determination of actual compliance status is outside its scope.
2.6 Deterministic Execution Boundary Definition
#QODIQA Control Index and Traceability Registry
This section provides the formal control registry for all QODIQA enforcement constructs referenced in the regulatory alignment tables of Sections 3 through 10. Each control is assigned a stable identifier, domain classification, enforcement layer, evidence output, control type, and maturity classification. Regulatory reviewers, auditors, and risk analysts should use this registry as the primary reference for control traceability across all framework mappings.
2.X.1 Consent Domain Controls
| Control ID | Control Domain | Core Reference | Enforcement Layer | Evidence Artifact | Control Type | Maturity |
|---|---|---|---|---|---|---|
CT-01 | Consent | Core Standard 4.1 | Token | CT, ALE | Deterministic Enforcement | Foundational |
CT-02 | Consent | Core Standard 4.2 | Token | CT, PBR | Deterministic Enforcement | Foundational |
CT-03 | Consent | Core Standard 4.3 | Token | CT | Deterministic Enforcement | Foundational |
CT-EXPIRY | Consent | Core Standard 4.4 | Token | CT (expiry field), ALE | Deterministic Enforcement | Foundational |
CT-SCOPE | Consent | Core Standard 4.5 | Token | CT, PBR | Deterministic Enforcement | Advanced |
2.X.2 Purpose Limitation Controls
| Control ID | Control Domain | Core Reference | Enforcement Layer | Evidence Artifact | Control Type | Maturity |
|---|---|---|---|---|---|---|
PL-01 | Purpose | Core Standard 3.1; 68-Point C.01 | SUP Boundary | PBR, ALE | Deterministic Enforcement | Foundational |
PL-02 | Purpose | Core Standard 3.2; 68-Point C.02 | SUP Boundary | PBR, ALE | Deterministic Enforcement | Advanced |
PL-03 | Purpose | Core Standard 3.3; 68-Point C.03 | SUP Boundary | PBR, CT | Deterministic Enforcement | Advanced |
PBR-01 | Purpose | Core Standard 3.4 | Token | PBR | Structural Evidence | Foundational |
2.X.3 Enforcement Domain Controls
| Control ID | Control Domain | Core Reference | Enforcement Layer | Evidence Artifact | Control Type | Maturity |
|---|---|---|---|---|---|---|
ENF-01 | Enforcement | 68-Point E.01 | SUP Boundary | ALE | Deterministic Enforcement | Foundational |
ENF-07 | Enforcement | 68-Point E.07 | SUP Boundary | ALE, PBR | Deterministic Enforcement | Advanced |
ENF-DEFAULT-DENY | Enforcement | Core Standard 2.1; 68-Point E.10 | SUP Boundary | ALE (BLOCK events) | Deterministic Enforcement | Foundational |
ENF-HALT | Enforcement | Core Standard 2.3 | SUP Boundary | ALE (HALT events) | Deterministic Enforcement | Advanced |
ENF-RETIRE | Enforcement | Core Standard 9.4 | SUP Boundary | LER | Deterministic Enforcement | Advanced |
ENF-SESSION | Enforcement | Core Standard 5.2 | SUP Boundary | ALE (session records) | Deterministic Enforcement | Advanced |
ENF-TEST | Enforcement | Certification Framework 4 | SUP Boundary | Test records | Governance Support | Advanced |
ENF-THIRD-PARTY | Enforcement | Core Standard 8.1 | SUP Boundary | ALE, CT | Deterministic Enforcement | High-Assurance |
ENF-REVOKE | Enforcement | Core Standard 6.3 | Registry | RR, ALE | Deterministic Enforcement | Foundational |
2.X.4 Revocation Domain Controls
| Control ID | Control Domain | Core Reference | Enforcement Layer | Evidence Artifact | Control Type | Maturity |
|---|---|---|---|---|---|---|
REV-01 | Consent | Core Standard 6.1; SEC Profile 6.1 | Registry | RR, ALE | Deterministic Enforcement | Foundational |
REV-02 | Consent | Core Standard 6.2; SEC Profile 6.2 | Registry | RR | Deterministic Enforcement | Advanced |
REV-03 | Consent | Core Standard 6.3; SEC Profile 6.3 | Registry | RR, ALE | Deterministic Enforcement | High-Assurance |
2.X.5 Audit Domain Controls
| Control ID | Control Domain | Core Reference | Enforcement Layer | Evidence Artifact | Control Type | Maturity |
|---|---|---|---|---|---|---|
AUD-01 | Audit | Core Standard 7.1; SEC Profile 8.1 | Ledger | ALE | Structural Evidence | Foundational |
AUD-02 | Audit | Core Standard 7.2; SEC Profile 8.2 | Ledger | ALE | Structural Evidence | Foundational |
AUD-03 | Audit | Core Standard 7.3 | Ledger | ALE | Structural Evidence | Advanced |
AUD-04 | Audit | Core Standard 7.4 | Ledger | ALE | Structural Evidence | Advanced |
AUD-05 | Audit | Core Standard 7.5; Certification Framework 5 | Ledger | ALE, EA | Structural Evidence | Advanced |
AUD-RETAIN | Audit | Core Standard 7.6 | Ledger | ALE | Governance Support | Foundational |
2.X.6 Certification and Cryptographic Controls
| Control ID | Control Domain | Core Reference | Enforcement Layer | Evidence Artifact | Control Type | Maturity |
|---|---|---|---|---|---|---|
CERT-01 | Audit | Certification Framework 1 | Ledger | EA | Governance Support | Foundational |
CERT-04 | Audit | Certification Framework 4 | Ledger | EA, Test records | Governance Support | Advanced |
SEC-ALG-01 | Crypto | SEC Profile 3.1 (AES-256-GCM) | Key Management | CT (encrypted), ALE | Deterministic Enforcement | Foundational |
SEC-ALG-02 | Crypto | SEC Profile 3.2 (SHA-3/SHA-256) | Key Management | ALE (hash chain) | Deterministic Enforcement | Foundational |
SEC-ALG-03 | Crypto | SEC Profile 3.3 (Ed25519) | Key Management | CT (signature) | Deterministic Enforcement | Foundational |
SEC-ALG-AGILITY-01 | Crypto | SEC Profile 3.4 | Key Management | SEC Profile 3.4 | Governance Support | High-Assurance |
SEC-KEY-01 | Crypto | SEC Profile 5.1 (Key storage) | Key Management | SEC Profile 5 | Deterministic Enforcement | Foundational |
SEC-KEY-02 | Crypto | SEC Profile 5.2 (Prohibited patterns) | Key Management | SEC Profile 5 | Deterministic Enforcement | Advanced |
SEC-KEY-03 | Crypto | SEC Profile 5.3 (FIPS 140-2 L3, dual-control) | Key Management | SEC Profile 5 | Deterministic Enforcement | High-Assurance |
SEC-NET-01 | Crypto | SEC Profile 10.1 (TLS 1.3) | Key Management | SEC Profile 10 | Deterministic Enforcement | Foundational |
SEC-NET-PFS | Crypto | SEC Profile 10.2 (ECDHE) | Key Management | SEC Profile 10 | Deterministic Enforcement | Advanced |
2.X.7 Lifecycle Domain Controls
| Control ID | Control Domain | Core Reference | Enforcement Layer | Evidence Artifact | Control Type | Maturity |
|---|---|---|---|---|---|---|
LER | Lifecycle | Core Standard 9; Reference Architecture 5 | Ledger | LER | Structural Evidence | Foundational |
CERT-REVIEW | Lifecycle | Certification Framework 7 | Ledger | EA | Governance Support | Advanced |
#GDPR Technical Alignment
The General Data Protection Regulation (Regulation 2016/679) establishes the foundational legal framework for personal data processing in the European Union. QODIQA's deterministic consent enforcement constructs correspond structurally to several GDPR obligations, particularly those requiring demonstrable consent, purpose limitation, and records of processing. The following tables map QODIQA controls to GDPR Articles with explicit coverage classification and evidence artifact identification.
GDPR encompasses legal basis determination, data subject rights administration, Data Protection Officer obligations, international transfer mechanisms, and supervisory authority interactions - all of which are outside QODIQA's technical scope. This section addresses only those GDPR obligations where QODIQA's runtime enforcement constructs provide structural technical support.
3.1 Article 5 - Principles Relating to Processing
| Article 5 Principle | Requirement Summary | QODIQA Control(s) | Enforcement Mechanism | Evidence Artifact | Coverage |
|---|---|---|---|---|---|
| Art. 5(1)(a) - Lawfulness, Fairness, Transparency | Processing must be lawful, fair, and transparent to the data subject | CT-01, CT-02, CT-03 | Consent token records declared legal basis; SUP boundary enforces processing only when valid token present | Consent Token (CT), Audit Ledger Entry (ALE) | Partial |
| Art. 5(1)(b) - Purpose Limitation | Data collected for specified, explicit, and legitimate purposes; not processed further in incompatible manner | PL-01, PL-02, PL-03, ENF-07 | Purpose hash encoded in consent token; SUP evaluates purpose binding at every invocation; processing blocked on mismatch | Purpose Binding Record (PBR), ALE | Direct |
| Art. 5(1)(c) - Data Minimisation | Data adequate, relevant, and limited to what is necessary | Outside enforcement boundary | QODIQA does not govern data collection volume or field selection | N/A | Out of Scope |
| Art. 5(1)(d) - Accuracy | Data accurate and kept up to date | Outside enforcement boundary | QODIQA does not govern data quality | N/A | Out of Scope |
| Art. 5(1)(e) - Storage Limitation | Data retained no longer than necessary | CT-EXPIRY, ENF-RETIRE | Consent token expiry enforced at SUP; processing blocked on expired token; LER records retirement transitions | CT (expiry field), LER | Partial |
| Art. 5(1)(f) - Integrity and Confidentiality | Appropriate security of personal data | SEC-ALG-01 through SEC-ALG-03, SEC-KEY-01 through SEC-KEY-03 | Cryptographic integrity enforcement on all consent tokens and audit entries; Ed25519 / AES-256-GCM enforcement | CT (signature), ALE (hash chain) | Structural |
| Art. 5(2) - Accountability | Controller must demonstrate compliance with principles | AUD-01 through AUD-05, CERT-01 | Append-only audit ledger with cryptographic tamper evidence; enforcement attestation generation | ALE, Enforcement Attestation (EA) | Structural |
3.2 Article 6 - Lawfulness of Processing
| Article 6 Basis | Requirement Summary | QODIQA Control(s) | Coverage | Residual Scope |
|---|---|---|---|---|
| Art. 6(1)(a) - Consent | Data subject has given consent for one or more specific purposes | CT-01, CT-02, CT-03, PL-01 | Direct | Consent validity under Art. 7 (freely given, specific, informed, unambiguous) is a legal determination; QODIQA enforces the token, not consent quality |
| Art. 6(1)(b) - Contract | Processing necessary for contract performance | CT legal-basis field (informational) | Structural | QODIQA can encode basis type in token; enforcement of contractual necessity is outside scope |
| Art. 6(1)(c) - Legal Obligation | Processing necessary for legal obligation compliance | CT legal-basis field (informational) | Structural | Legal obligation determination is entirely outside enforcement boundary |
| Art. 6(1)(e–f) - Public / Legitimate Interest | Processing for public task or legitimate interests | Outside enforcement boundary | Out of Scope | Balancing test required; cannot be technically enforced at runtime |
3.3 Article 7 - Conditions for Consent
| Art. 7 Requirement | QODIQA Control(s) | Enforcement Mechanism | Evidence Artifact | Coverage |
|---|---|---|---|---|
| Art. 7(1) - Demonstrability of consent | CT-01, AUD-02, CERT-01 | Cryptographically signed consent token with subject binding; append-only ledger entry at consent capture time; enforcement attestation available for audit | CT, ALE, EA | Direct |
| Art. 7(2) - Intelligibility of consent request | Outside enforcement boundary | UX and presentation layer - not addressed by QODIQA | N/A | Out of Scope |
| Art. 7(3) - Right to withdraw consent | REV-01, REV-02, REV-03, ENF-REVOKE | Revocation propagates to registry within defined SLA; SUP consults registry at each invocation; processing blocked on revoked token; revocation timestamp recorded | RR, ALE | Direct |
| Art. 7(3) - Withdrawal as easy as giving consent | Outside enforcement boundary | UX parity is a product design requirement; QODIQA enforces downstream effect of withdrawal | N/A | Out of Scope |
| Art. 7(4) - Conditioning of consent | Outside enforcement boundary | Legal assessment of conditionality; not deterministic at runtime | N/A | Out of Scope |
3.4 Articles 13–14 - Transparency Information
| Requirement | QODIQA Control(s) | Coverage | Residual Scope |
|---|---|---|---|
| Provision of processing information to data subject | CT (purpose scope field, informational) | Out of Scope | Privacy notice delivery is outside enforcement boundary; purpose field in CT supports record of declared purpose only |
| Documentation of purposes at point of collection | PBR-01, CT-02 | Structural | Purpose Binding Record documents purpose scope at consent time; legal sufficiency of purpose description requires separate determination |
3.5 Article 25 - Data Protection by Design and Default
| Art. 25 Requirement | QODIQA Control(s) | Enforcement Mechanism | Evidence Artifact | Coverage |
|---|---|---|---|---|
| Art. 25(1) - Data protection by design | ENF-01 through ENF-10, CT-01 through CT-03, SEC-ALG-01 | QODIQA enforces consent as a structural prerequisite to AI execution; default posture is deny; cryptographic integrity built into architecture | ALE (deny events), CT (design artifact) | Direct |
| Art. 25(2) - Data protection by default | ENF-DEFAULT-DENY, ENF-01 | SUP boundary operates default-deny; processing requires valid, non-expired, non-revoked consent token; no processing on ambiguous or absent consent | ALE (blocked invocations) | Direct |
| Technical and organisational measures for processing principles | All QODIQA enforcement controls | QODIQA constitutes a technical measure; organisational measures are outside scope | EA | Partial |
3.6 Article 30 - Records of Processing Activities
| Art. 30 Requirement | QODIQA Control(s) | Evidence Artifact | Coverage | Residual Scope |
|---|---|---|---|---|
| Name and contact details of controller | Outside enforcement boundary | N/A | Out of Scope | Organisational record maintenance |
| Purposes of processing | PBR-01, CT-02 | PBR, CT | Structural | QODIQA purpose records support ROPA population; full ROPA maintenance is organisational |
| Categories of data subjects and personal data | Outside enforcement boundary | N/A | Out of Scope | Data inventory and classification outside QODIQA scope |
| Recipients and transfers | Outside enforcement boundary | N/A | Out of Scope | Transfer governance outside scope |
| Time limits for erasure | CT-EXPIRY, LER | CT (expiry), LER | Structural | Expiry records support ROPA; erasure execution is outside enforcement boundary |
| Security measures description | All SEC controls | EA | Structural | QODIQA security controls documented in SEC Profile; compliance assessment separate |
3.7 Article 32 - Security of Processing
| Art. 32 Requirement | QODIQA Control(s) | Enforcement Mechanism | Evidence Artifact | Coverage |
|---|---|---|---|---|
| Pseudonymisation and encryption | SEC-ALG-01 (AES-256-GCM), SEC-ALG-03 (Ed25519) | Cryptographic enforcement on token issuance and verification; all consent artifacts encrypted in transit per SEC-NET-01 | CT (encrypted fields), ALE | Structural |
| Confidentiality, integrity, availability, resilience | SEC-KEY-01 through SEC-KEY-03, SEC-NET-01, AUD-01 | HSM-backed key storage; TLS 1.3 enforcement; append-only audit structure; revocation SLA enforcement | EA, ALE | Structural |
| Process for regular testing and evaluation | CERT-04, AUD-05 | Certification framework mandates periodic enforcement attestation; audit ledger integrity verification | EA | Structural |
#EU AI Act Technical Alignment
The EU Artificial Intelligence Act (Regulation 2024/1689) establishes a risk-based regulatory framework for AI systems deployed in the European Union. QODIQA's runtime enforcement architecture aligns structurally with the Act's obligations relating to logging, record-keeping, human oversight support, and operational transparency for high-risk AI systems. The following tables address those obligations specifically.
The EU AI Act encompasses risk classification, conformity assessment, notified body certification, post-market monitoring, market surveillance, and AI system registration - all substantially outside QODIQA's technical scope. Mappings below address only the operational and logging obligations where QODIQA provides structural technical support. QODIQA does not constitute a conformity assessment instrument and does not substitute for EU AI Act certification processes.
QODIQA does not govern training data quality, dataset representativeness, or data governance obligations under EU AI Act Article 10. These requirements address the upstream model development phase, which precedes the SUP enforcement boundary. No coverage is claimed for Article 10. However, enforcement records generated at inference time - specifically Audit Ledger Entries documenting each invocation context, purpose scope, and consent state - may provide traceability artifacts relevant to post-deployment risk analysis under Articles 72 and 73. The utility of such artifacts in post-deployment contexts is informational; it does not extend QODIQA's coverage classification for Article 10 and does not reduce the obligation for independent compliance with Article 10 requirements.
4.1 Article 9 - Risk Management System
| Art. 9 Obligation | QODIQA Control(s) | Enforcement Mechanism | Evidence Artifact | Coverage |
|---|---|---|---|---|
| Risk management system for high-risk AI - establishment and maintenance | ENF-01 through ENF-10; CERT-01 | QODIQA provides a runtime enforcement control that reduces consent-related risk surface; enforcement attestation documents control operation | EA | Partial |
| Risk identification and analysis | Outside enforcement boundary | Risk assessment is an organisational and analytical function; QODIQA provides enforcement, not risk analysis | N/A | Out of Scope |
| Residual risk evaluation and mitigation measures | SEC Profile - 14 Non-Coverage Disclosure | QODIQA's explicit non-coverage disclosure supports residual risk documentation | SEC Profile 14 | Structural |
4.2 Article 12 - Record-Keeping and Logging
| Art. 12 Requirement | QODIQA Control(s) | Enforcement Mechanism | Evidence Artifact | Coverage |
|---|---|---|---|---|
| Art. 12(1) - Automatic logging capability | AUD-01, AUD-02, AUD-03 | Every invocation at SUP boundary generates an append-only audit ledger entry; logging is non-bypassable at enforcement layer | ALE (all enforcement events) | Direct |
| Art. 12(2) - Traceability across lifetime | AUD-01 through AUD-05, LER | Hash-chained audit ledger provides tamper-evident traceability; lifecycle event records cover training through retirement transitions | ALE, LER | Direct |
| Art. 12(3) - Log period retention | AUD-RETAIN | Audit ledger retention policy configurable per deployment profile; tamper evidence maintained throughout retention period | ALE | Direct |
| Art. 12(4) - High-risk: logging of each use period | AUD-02, ENF-SESSION | Session-level enforcement records generated per invocation sequence; consent token validity verified and recorded at session initiation | ALE (session records) | Direct |
4.3 Article 13 - Transparency and Provision of Information
| Art. 13 Requirement | QODIQA Control(s) | Coverage | Residual Scope |
|---|---|---|---|
| System designed to be sufficiently transparent | CT (purpose encoding), ALE (decision records) | Structural | Transparency to deployers and users via QODIQA audit logs; model transparency is outside scope |
| Instructions for use - capabilities, limitations, human oversight | Outside enforcement boundary | Out of Scope | Documentation obligation; QODIQA does not produce AI system instructions for use |
| Disclosure when interacting with AI system | Outside enforcement boundary | Out of Scope | User notification is a product/UX layer obligation |
4.4 Article 14 - Human Oversight
| Art. 14 Requirement | QODIQA Control(s) | Coverage | Residual Scope |
|---|---|---|---|
| Oversight measures enabling human intervention | ENF-HALT, REV-01 | Partial | QODIQA supports consent revocation as an enforcement-level halt mechanism; broader human oversight interfaces are outside scope |
| Ability to override AI system output | Outside enforcement boundary | Out of Scope | Output override is an AI system interface obligation; QODIQA operates at consent enforcement, not output layer |
| Monitoring of operation for anomalies and malfunctions | AUD-04, AUD-05 | Structural | QODIQA audit ledger enables anomaly detection at enforcement layer; broader system monitoring is outside scope |
4.5 Article 17 - Quality Management System
| Art. 17 Requirement | QODIQA Control(s) | Coverage | Residual Scope |
|---|---|---|---|
| QMS - strategies, techniques for achieving compliance | CERT-01 through CERT-04 | Structural | Certification framework provides structured compliance assessment for QODIQA controls; broader QMS is organisational |
| QMS - procedures for design, development, and monitoring | LER, Implementation Playbook | Structural | QODIQA lifecycle controls provide evidence for QMS documentation; process governance outside scope |
| Record-keeping for QMS | AUD-01 through AUD-05, EA | Structural | QODIQA's enforcement records support QMS documentation requirements |
4.6 Article 26 - Deployers' Obligations
| Art. 26 Obligation | QODIQA Control(s) | Coverage | Residual Scope |
|---|---|---|---|
| Appropriate use within intended purpose | PL-01 through PL-03 | Direct | Purpose-bound enforcement at runtime; contextual hash verification prevents out-of-scope use |
| Human oversight assignment | Outside enforcement boundary | Out of Scope | Personnel and governance assignment is organisational |
| Monitoring for risks to health, safety, or fundamental rights | AUD-04 | Structural | QODIQA enforcement anomaly logs support monitoring; risk content evaluation outside scope |
| Keeping logs as per Art. 12 for the required period | AUD-01 through AUD-05, AUD-RETAIN | Direct | QODIQA audit ledger satisfies technical logging obligation; organisational retention policy configuration required |
#NIST AI Risk Management Framework Alignment
The NIST AI Risk Management Framework (AI RMF 1.0, January 2023) provides a structured approach to managing risks associated with AI systems across four core functions: Govern, Map, Measure, and Manage. QODIQA's deterministic runtime enforcement contributes to risk traceability, control effectiveness evidence, and operational accountability within AI RMF-aligned programs.
The NIST AI RMF is a voluntary framework intended for organisational use. Alignment with the AI RMF does not constitute NIST certification or endorsement. QODIQA's contribution is technical - providing enforcement controls and evidence artifacts that support the Govern, Measure, and Manage functions. Organisational AI governance programs, risk culture, and stakeholder engagement (which constitute the majority of Govern and Map function requirements) are outside QODIQA's technical scope.
5.1 GOVERN Function
| GOVERN Category | GOVERN Subcategory | QODIQA Control(s) | Contribution | Coverage |
|---|---|---|---|---|
| GV-1: Policies, processes, procedures | GV-1.1 - AI risk management policies | CERT-01, Implementation Playbook 1 | QODIQA certification framework provides policy-level enforcement documentation | Structural |
| GV-1: Policies | GV-1.2 - Accountability for AI risk | AUD-01 through AUD-05, EA | Append-only audit ledger with enforcement attestation provides technical accountability evidence | Structural |
| GV-4: Organisational teams | GV-4.1 - Roles and responsibilities | Outside enforcement boundary | Organisational role assignment | Out of Scope |
| GV-6: Policies for third-party risk | GV-6.1 - Third-party AI risk management | ENF-THIRD-PARTY, CT-SCOPE | QODIQA enforces consent boundary at third-party AI invocation; purpose binding prevents scope creep across integrations | Partial |
5.2 MAP Function
| MAP Category | MAP Subcategory | QODIQA Control(s) | Contribution | Coverage |
|---|---|---|---|---|
| MP-2: Scientific and established methods | MP-2.3 - AI system context and scope | CT (purpose scope), PBR | Purpose Binding Record documents processing context at consent grant; supports AI system context mapping | Structural |
| MP-3: AI risks and benefits | MP-3.4 - Risks to data subjects | PL-01, ENF-DEFAULT-DENY, REV-01 | Default-deny posture and revocation enforcement reduce runtime risk to data subjects | Partial |
| MP-4: Risk identification | MP-4.1 - Categorisation of risks | Outside enforcement boundary | Risk categorisation is analytical; QODIQA provides enforcement, not risk analysis | Out of Scope |
| MP-5: Impacts on individuals | MP-5.2 - Privacy risks | CT-01, PL-01, REV-01 | Consent enforcement and withdrawal mechanisms directly address runtime privacy risk to individuals | Direct |
5.3 MEASURE Function
| MEASURE Category | Subcategory | QODIQA Control(s) | Contribution | Coverage |
|---|---|---|---|---|
| MS-1: AI risk measurement methods | MS-1.1 - Identified and documented AI risks | SEC Profile 14 (Non-Coverage Disclosure) | Explicit non-coverage disclosure provides documented residual risk boundary | Structural |
| MS-2: AI risk evaluation | MS-2.5 - Testing conducted in realistic conditions | CERT-04, ENF-TEST | Certification framework mandates enforcement testing under operational conditions; test records generated | Structural |
| MS-3: AI system performance | MS-3.3 - Effectiveness of risk controls | AUD-05, EA | Enforcement attestation provides measurable evidence of control operation; blocked-invocation rates quantifiable from ALE | Direct |
| MS-4: Feedback and incident capture | MS-4.1 - Collection of incident feedback | AUD-03, AUD-04 | Enforcement anomaly records support incident identification; consent failure events captured in ALE | Structural |
5.4 MANAGE Function
| MANAGE Category | Subcategory | QODIQA Control(s) | Contribution | Coverage |
|---|---|---|---|---|
| MG-1: Risk treatment | MG-1.3 - Responses to identified risks | REV-01 through REV-03, ENF-HALT | Revocation and enforcement halt mechanisms provide technical risk response at runtime | Direct |
| MG-2: Risk treatment monitoring | MG-2.2 - Effectiveness of risk treatments | AUD-05, EA | Enforcement attestation and audit ledger analysis support ongoing treatment effectiveness evaluation | Structural |
| MG-3: Risk management improvement | MG-3.1 - Identified risk improvements | SEC-ALG-AGILITY-01, CERT-REVIEW | Algorithm agility framework and certification review cycle support continuous improvement | Structural |
| MG-4: Residual risk | MG-4.1 - Residual risks documented | Section 9 Non-Coverage Disclosure (this document) | Explicit residual risk and non-coverage disclosure provides documented residual risk register input | Direct |
#ISO/IEC 27001 Control Family Alignment
ISO/IEC 27001:2022 (Information Security Management Systems) provides a framework for establishing, implementing, maintaining, and continually improving an information security management system (ISMS). QODIQA's security and enforcement controls operate as a runtime enforcement layer supplementing, but not replacing, an organisation's ISMS. The following tables map QODIQA to relevant Annex A control families.
QODIQA does not implement an ISMS. It provides a runtime enforcement control plane that contributes technical controls relevant to several ISO 27001 control families. ISO 27001 certification requires an organisation-wide management system, risk assessment process, statement of applicability, and independent audit - none of which QODIQA substitutes for. Controls below are informative mappings only.
6.1 A.5 - Organisational Controls (Selected)
| ISO 27001 Control | Control Title | QODIQA Control(s) | Coverage | QODIQA Contribution |
|---|---|---|---|---|
| A.5.18 | Access rights | CT-01, CT-SCOPE, ENF-01 | Partial | Consent token scopes function as access rights in AI processing context; SUP enforces scope boundaries deterministically |
| A.5.20 | Addressing security within supplier agreements | ENF-THIRD-PARTY | Structural | QODIQA's enforcement at third-party AI invocation boundary supports supplier security control documentation |
| A.5.33 | Protection of records | AUD-01, AUD-02, AUD-RETAIN | Direct | Append-only, cryptographically tamper-evident audit ledger provides protected records with configurable retention |
| A.5.36 | Compliance with information security policies | CERT-01, EA | Structural | Enforcement attestation provides structured evidence of consent enforcement policy compliance |
6.2 A.8 - Technological Controls
| ISO 27001 Control | Control Title | QODIQA Control(s) | Coverage | QODIQA Contribution |
|---|---|---|---|---|
| A.8.2 | Privileged access rights | SEC-KEY-03 (dual-control) | Partial | Dual-control key activation for High-Assurance profile enforces separation of duties at cryptographic layer |
| A.8.15 | Logging | AUD-01 through AUD-05 | Direct | Non-bypassable audit logging of all enforcement events with hash-chain integrity; tamper-evident retention |
| A.8.16 | Monitoring activities | AUD-04, AUD-05 | Structural | Audit ledger provides monitoring data for enforcement anomaly detection; alerting on consent failures |
| A.8.24 | Use of cryptography | SEC-ALG-01 through SEC-ALG-03, SEC-ALG-AGILITY-01 | Direct | Normative cryptographic algorithm requirements; agility framework; FIPS-aligned algorithm selection; HSM key storage |
| A.8.25 | Secure development life cycle | LER, Implementation Playbook 4 | Structural | QODIQA lifecycle event records and playbook integration guidance support SDL documentation |
| A.8.28 | Secure coding | Outside enforcement boundary | Out of Scope | Application code security is outside QODIQA scope; QODIQA enforces consent boundary, not code quality |
| A.8.33 | Test information | CERT-04, ENF-TEST | Structural | Certification framework test procedures provide structured test evidence documentation |
QODIQA supplements an ISMS by adding a deterministic runtime enforcement layer at the AI execution boundary. It does not replace ISMS processes for asset management, physical security, supplier management, business continuity, or human resource security - all of which remain organisational responsibilities outside QODIQA's technical scope.
#ISO/IEC 42001 AI Management System Alignment
ISO/IEC 42001:2023 (AI Management Systems) provides requirements for establishing, implementing, maintaining, and continually improving an artificial intelligence management system (AIMS). QODIQA operates as a technical control component within the operational layer of an ISO 42001-aligned AIMS, providing runtime enforcement, consent governance, and audit evidence generation.
ISO/IEC 42001 encompasses organisational context, leadership commitment, planning, support, operation, performance evaluation, and improvement - representing a full management system scope. QODIQA's contribution is specifically at the operational control layer (Clause 8) and performance evaluation layer (Clause 9). All other AIMS requirements remain outside QODIQA's technical scope and must be addressed through organisational governance structures.
7.1 Clause 6 - Planning
| ISO 42001 Clause | Requirement | QODIQA Control(s) | Coverage | QODIQA Contribution |
|---|---|---|---|---|
| 6.1.1 | Actions to address AI risks and opportunities | ENF-01 through ENF-10; SEC Profile 14 | Partial | QODIQA defines technical enforcement actions for consent risk; non-coverage disclosure identifies residual risk requiring organisational treatment |
| 6.1.2 | AI risk assessment | Outside enforcement boundary | Out of Scope | Risk assessment is an analytical and organisational function |
7.2 Clause 8 - Operation
| ISO 42001 Clause | Requirement | QODIQA Control(s) | Coverage | QODIQA Contribution |
|---|---|---|---|---|
| 8.1 | Operational planning and control | ENF-01 through ENF-10; Implementation Playbook 3 | Direct | QODIQA provides the runtime operational control plane for consent enforcement; playbook defines integration procedures |
| 8.3 | AI system lifecycle management | LER, ENF-RETIRE | Partial | Lifecycle event records cover training, deployment, and retirement transitions; training-phase governance outside QODIQA scope |
| 8.4 | Data governance | CT-01, PBR-01, REV-01 | Partial | Consent token and purpose binding records contribute to data governance documentation; data quality and inventory are outside scope |
| 8.5 | Responsible development | Outside enforcement boundary | Out of Scope | Development practices, impact assessments, and responsible AI considerations are organisational |
| 8.6 | Responsible deployment and operation | ENF-01 through ENF-10; PL-01 through PL-03 | Direct | QODIQA's deterministic enforcement constitutes a core technical component of responsible deployment; purpose gating prevents out-of-scope operation |
7.3 Clause 9 - Performance Evaluation
| ISO 42001 Clause | Requirement | QODIQA Control(s) | Coverage | QODIQA Contribution |
|---|---|---|---|---|
| 9.1 | Monitoring, measurement, analysis, and evaluation | AUD-01 through AUD-05, EA | Direct | Audit ledger provides quantitative enforcement performance data; enforcement attestation supports periodic measurement |
| 9.2 | Internal audit | CERT-01 through CERT-04 | Structural | QODIQA certification framework provides structured audit evidence and assessment procedures for internal audit use |
| 9.3 | Management review | EA (periodic reporting) | Structural | Enforcement attestation reports provide structured input to AIMS management review; broader review governance is organisational |
7.4 Annex A (ISO 42001) - AI-Specific Controls
| Annex A Control | Title | QODIQA Control(s) | Coverage |
|---|---|---|---|
| A.2.2 | AI system processes - data for AI | CT-01, PBR-01 | Structural |
| A.2.4 | Documentation | ALE, EA, LER | Structural |
| A.3.3 | Governance of AI - objectives | CERT-01 | Structural |
| A.4.2 | Human oversight of AI systems | REV-01, ENF-HALT | Partial |
| A.6.1 | AI system logging | AUD-01 through AUD-05 | Direct |
| A.7.4 | Security of AI system | SEC Profile - all sections | Direct |
#OECD AI Principles Structural Support
The OECD AI Principles (OECD/LEGAL/0449, updated 2024) provide non-binding guidance on trustworthy AI across five values-based principles. Mappings below identify where QODIQA's technical enforcement constructs provide structural support for the technical dimensions of these principles. Philosophical, policy, and societal dimensions of the principles are outside QODIQA's technical scope and are not addressed here.
8.1 Principle-Level Alignment
| OECD Principle | Technical Dimension | QODIQA Control(s) | Technical Contribution | Coverage |
|---|---|---|---|---|
| 1.1 - Inclusive Growth, Sustainable Development, Well-being | AI benefits distributed with respect to affected persons' interests | Outside enforcement boundary | N/A | Out of Scope |
| 1.2 - Human-centred Values and Fairness | Respect for rule of law; privacy; freedom from manipulation; human dignity | CT-01, PL-01, REV-01, ENF-DEFAULT-DENY | Consent enforcement and revocation support privacy protection at runtime; default-deny posture prevents processing without valid consent; purpose binding prevents manipulation through scope creep | Partial |
| 1.3 - Transparency and Explainability | Actors should be transparent about AI systems; provide meaningful information | ALE, CT, EA | Audit ledger provides verifiable, replayable record of enforcement decisions; consent token encodes declared purpose; enforcement attestation provides structured transparency artifact | Structural |
| 1.4 - Robustness, Security, and Safety | AI systems should be robust, secure, safe throughout lifetime | SEC Profile (all sections); LER; ENF-DEFAULT-DENY | Cryptographic integrity enforcement; HSM-backed key management; hash-chained audit integrity; default-deny posture; lifecycle event tracking through retirement | Direct |
| 1.5 - Accountability | Actors accountable for proper functioning of AI systems; mechanisms for redress | AUD-01 through AUD-05; EA; CERT-01 through CERT-04 | Append-only tamper-evident audit ledger provides accountability evidence; enforcement attestation documents control operation; certification framework supports structured accountability review | Direct |
The OECD AI Principles are policy-level instruments requiring organisational commitment, governance structures, and societal engagement that substantially exceed the scope of any technical control. QODIQA's structural contributions are confined to the technical dimensions identified above. No claim is made that deploying QODIQA constitutes adherence to or implementation of the OECD AI Principles as a whole.
#Residual Risk and Non-Coverage Disclosure
This section provides a definitive, structured disclosure of areas outside QODIQA's enforcement boundary. These disclosures are intended to prevent overclaiming in compliance contexts and to ensure that organizations understand where complementary controls are required. Items listed here are not gaps or deficiencies - they reflect the deliberate and appropriate boundary of a runtime consent enforcement system.
QODIQA provides deterministic runtime consent enforcement. It generates structured, replayable evidence. It does not provide, and does not claim to provide, coverage for any item listed in Section 9.1. Organizations MUST NOT represent QODIQA deployment as satisfying the non-covered areas listed herein without independent complementary controls and qualified legal or compliance assessment.
9.1 Explicit Non-Coverage Table
| Area | Description | Why Outside Scope | Where Addressed |
|---|---|---|---|
| Model Training Governance | Data provenance, training data consent, training-phase data handling, model card generation | QODIQA enforces at inference/use-time SUP boundary; training phase precedes enforcement layer | ML governance frameworks; data management systems; EU AI Act Art. 10 (training data) |
| Algorithmic Fairness and Bias | Evaluation of model outputs for demographic bias, disparate impact, or fairness metrics | QODIQA enforces consent boundary, not output content or fairness characteristics | Fairness evaluation frameworks; AI impact assessments; EU AI Act Art. 10(2)(f) |
| Content Moderation | Evaluation of AI-generated output for harmful, illegal, or policy-violating content | QODIQA operates at enforcement layer upstream of output generation; does not inspect output content | Output moderation systems; trust and safety controls; DSA compliance infrastructure |
| Legal Validity of Consent | Determination of whether a given consent satisfies GDPR Art. 7 requirements (freely given, specific, informed, unambiguous) | Legal validity is a jurisprudential determination; QODIQA enforces the presence and integrity of a consent token, not its legal quality | Legal counsel; DPO assessment; supervisory authority guidance |
| Data Subject Rights Administration | Subject access requests, right to erasure (Art. 17), portability (Art. 20), objection (Art. 21) | QODIQA enforces processing boundaries; data subject rights administration requires organisational processes, not only enforcement controls | DSR management platforms; legal operations; DPO office |
| Privacy Notice and UX Delivery | Provision of privacy information to data subjects (Art. 13–14); intelligibility of consent interface | User interface and notice delivery are product/design layer obligations outside enforcement boundary | Product design; privacy engineering; UX governance |
| International Data Transfers | GDPR Chapter V - SCCs, adequacy decisions, BCRs | Transfer mechanisms are legal instruments; QODIQA does not govern data movement or transfer basis | Legal counsel; EDPB guidance; transfer impact assessments |
| Business Process Governance | Organisational AI governance structures, ethics boards, decision authority, AI policy | Governance is an organisational and managerial function; QODIQA provides a technical control, not governance structures | AI governance frameworks; ISO 42001 (organisational clauses); board-level AI governance |
| ISMS Completeness | Full ISO 27001 ISMS scope including asset management, physical security, HR security, BCP | QODIQA supplements selected control families; it does not implement or certify an ISMS | Certified ISMS programme; ISO 27001 audit |
| Conformity Assessment and Certification | EU AI Act conformity assessment; CE marking; notified body engagement | Conformity assessment is a legal and regulatory process conducted by qualified bodies; QODIQA provides technical controls, not certification | Notified bodies; EU AI Act Chapters V–VI |
| Incident Notification to Authorities | GDPR Art. 33–34 breach notification; EU AI Act Art. 73 serious incident reporting | Notification obligations require organisational incident response processes beyond enforcement layer | Incident response plans; supervisory authority notification procedures |
| AI System Impact Assessment | DPIA (GDPR Art. 35); AI system fundamental rights impact assessment (EU AI Act) | Impact assessments require interdisciplinary analysis of systemic effects; QODIQA provides enforcement records as input, not assessment capability | DPIA process; DPO; fundamental rights teams |
#Cross-Framework Comparative Matrix
This section consolidates the preceding section-by-section alignments into a single cross-framework matrix, presenting QODIQA enforcement controls against all six frameworks simultaneously. The matrix is intended for rapid cross-reference in enterprise risk and compliance review contexts. Coverage indicators follow the classification scheme defined in Section 2.3.
This section provides a consolidated cross-framework view of control alignment. It highlights where deterministic runtime enforcement provides direct coverage, where it supports evidentiary traceability, and where residual gaps remain outside the enforcement boundary.
10.1 Consolidated Control-to-Framework Matrix
| QODIQA Control Domain | Key Controls | GDPR | EU AI Act | NIST AI RMF | ISO 27001 | ISO 42001 | OECD AI | Evidence Type | Primary Risk Domain |
|---|---|---|---|---|---|---|---|---|---|
| Consent Token Enforcement | CT-01, CT-02, CT-03 | Direct | Partial | Partial | Partial | Direct | Partial | CT, ALE | Consent Enforcement |
| Purpose Limitation Enforcement | PL-01, PL-02, PL-03 | Direct | Direct | Partial | Partial | Direct | Partial | PBR, CT, ALE | Privacy |
| Default-Deny Enforcement | ENF-DEFAULT-DENY, ENF-01 | Direct | Structural | Partial | Structural | Direct | Partial | ALE (denied invocations) | Consent Enforcement |
| Revocation Enforcement | REV-01, REV-02, REV-03 | Direct | Partial | Direct | Structural | Partial | Partial | RR, ALE | Consent Enforcement |
| Audit Ledger Integrity | AUD-01 through AUD-05 | Structural | Direct | Direct | Direct | Direct | Direct | ALE, EA | Traceability |
| Enforcement Attestation | CERT-01 through CERT-04 | Structural | Structural | Structural | Structural | Structural | Structural | EA | Accountability |
| Cryptographic Algorithm Enforcement | SEC-ALG-01, SEC-ALG-02, SEC-ALG-03 | Structural | Structural | Structural | Direct | Direct | Structural | CT (signature), ALE | Security |
| Cryptographic Agility | SEC-ALG-AGILITY-01 | Structural | Structural | Structural | Direct | Structural | Structural | SEC Profile 3.4 | Security |
| Key Management | SEC-KEY-01, SEC-KEY-02, SEC-KEY-03 | Structural | Structural | Structural | Direct | Direct | Structural | SEC Profile 5 | Security |
| Lifecycle Event Records | LER, ENF-RETIRE | Structural | Direct | Structural | Structural | Partial | Structural | LER | Lifecycle Integrity |
| Purpose Binding Records | PBR-01, CT-02 | Structural | Structural | Structural | Structural | Structural | Structural | PBR | Traceability |
| Transport Security | SEC-NET-01, SEC-NET-PFS | Structural | Structural | Structural | Direct | Structural | Structural | SEC Profile 10 | Security |
| Third-Party Enforcement | ENF-THIRD-PARTY | Partial | Partial | Partial | Structural | Partial | Structural | ALE, CT | Governance Support |
| Model Training / Fairness / Bias | N/A | Out of Scope | Out of Scope | Out of Scope | Out of Scope | Out of Scope | Out of Scope | See Section 9.1 | N/A |
| Legal Consent Validity | N/A | Out of Scope | Out of Scope | Out of Scope | Out of Scope | Out of Scope | Out of Scope | See Section 9.1 | N/A |
| Data Subject Rights Admin | N/A | Out of Scope | Out of Scope | Out of Scope | Out of Scope | Out of Scope | Out of Scope | See Section 9.1 | N/A |
10.2 Coverage Density Summary
| Framework | Direct Coverage Areas | Structural Coverage Areas | Partial Coverage Areas | Out of Scope Areas |
|---|---|---|---|---|
| GDPR | Art. 5(1)(b) purpose limitation; Art. 7(1) demonstrability; Art. 7(3) revocation; Art. 25(1)(2) privacy by design/default | Art. 5(1)(f) security; Art. 5(2) accountability; Art. 30 records; Art. 32 security measures | Art. 5(1)(a) lawfulness; Art. 5(1)(e) storage; Art. 6(1)(a) consent basis; Art. 25 organisational | Data minimisation; accuracy; rights admin; transfer mechanisms; notice delivery; DPIA |
| EU AI Act | Art. 12 logging (all sub-requirements); Art. 26(a) intended purpose; Art. 26 log retention | Art. 9 risk management (residual); Art. 13 transparency; Art. 17 QMS; Art. 14 monitoring | Art. 9 risk management; Art. 14 oversight | Conformity assessment; CE marking; model transparency; output oversight; bias evaluation |
| NIST AI RMF | MS-3.3 control effectiveness; MG-1.3 risk treatment; MG-4.1 residual risk; MP-5.2 privacy risks | GV-1.1 policies; GV-1.2 accountability; MS-1.1 risk measurement; MS-2.5 testing; MS-4.1 incidents; MG-2.2 monitoring | GV-6.1 third-party; MP-3.4 data subject risk; MP-2.3 system context | Organisational AI governance; risk categorisation; stakeholder engagement; explainability |
| ISO/IEC 27001 | A.5.33 records protection; A.8.15 logging; A.8.24 cryptography | A.5.20 supplier; A.5.36 policy compliance; A.8.16 monitoring; A.8.25 SDL; A.8.33 test info | A.5.18 access rights; A.8.2 privileged access | ISMS scope (asset, physical, HR, BCP); all organisational ISMS clauses |
| ISO/IEC 42001 | 8.1 operational control; 8.6 responsible deployment; 9.1 monitoring; A.6.1 logging; A.7.4 security | 6.1.1 risk actions; 9.2 internal audit; 9.3 management review; A.2.2 data; A.2.4 documentation; A.3.3 governance | 8.3 lifecycle; 8.4 data governance; A.4.2 human oversight | Risk assessment; leadership; responsible development; organisational AIMS clauses |
| OECD AI Principles | 1.4 Robustness/Security/Safety; 1.5 Accountability | 1.3 Transparency/Explainability | 1.2 Human-centred values | 1.1 Inclusive growth; societal and policy dimensions of all principles |
Deterministic runtime enforcement provides the highest level of control assurance at the point of system invocation. Coverage is strongest in areas where enforcement can be applied synchronously and cryptographically verified. Domains such as model training, fairness, and organizational governance remain outside this boundary and require complementary control frameworks.
#Regulatory Ambiguity Surface Reduction Analysis
10.X.1 Definition: Regulatory Ambiguity Surface
For the purposes of this analysis, regulatory ambiguity surface is defined as: the set of execution-time states in which legal obligations depend on non-deterministic enforcement - that is, states where processing may occur without verifiable consent token validation, purpose binding evaluation, or revocation registry consultation. In non-deterministic enforcement environments, the ambiguity surface is unbounded at runtime: any invocation may or may not have occurred with valid consent, and no cryptographically verifiable record distinguishes compliant from non-compliant invocations after the fact.
Deterministic enforcement - as implemented through the QODIQA SUP boundary invariant defined in Section 2.6 - reduces this ambiguity surface by converting probabilistic compliance postures into binary enforcement decisions with cryptographically bound, replayable evidence. The following table quantifies this reduction across identified risk vectors.
10.X.2 Risk Vector Analysis
| Risk Vector | Definition | Non-Deterministic Environment | Deterministic Enforcement Impact | Residual Risk |
|---|---|---|---|---|
| Silent Consent Drift | Processing continues under a consent scope that has materially narrowed since grant, without enforcement-layer detection | No runtime gate; scope evaluation performed at audit or complaint time, if at all; processing and non-compliance may be separated by months or years of invocation history | Purpose hash in CT evaluated against declared scope at every invocation; scope mismatch results in deterministic BLOCK; ALE entry generated for each blocked invocation with timestamp and failure reason; drift detectable in real time from ALE | Consent scope definition quality is upstream of enforcement boundary; QODIQA enforces the declared scope, not its legal adequacy; legal sufficiency determination remains outside scope |
| Scope Creep | AI system invoked for purposes beyond declared consent scope, either deliberately or through feature expansion | Without enforcement gating, purpose scope expansion is governed only by internal policy controls; violations may be undetected until DPA investigation or data subject complaint | PL-01 through PL-03 enforce purpose binding at invocation time; new purpose requires new consent token with updated scope; invocations under undeclared purposes blocked at SUP boundary; every attempt generates ALE entry | Determination of whether a new use case constitutes a compatible purpose under GDPR Art. 5(1)(b) requires legal analysis outside QODIQA scope; QODIQA enforces the technical boundary, not the legal determination of compatibility |
| Revocation Lag | Processing continues after consent withdrawal due to propagation delays, registry synchronisation failures, or system unawareness of revocation event | In poll-based or batch-updated systems, revocation may take hours or days to propagate; processing during lag period constitutes processing without valid legal basis; no cryptographic evidence of when processing actually stopped | REV-01 through REV-03 enforce revocation propagation SLA; SUP consults registry at each invocation; revocation takes effect within defined SLA window; RR provides cryptographic timestamp of revocation and propagation confirmation; post-revocation invocations blocked and ALE-recorded | SLA window creates a bounded residual processing risk during propagation period; SLA duration is configurable by profile (Foundational / Advanced / High-Assurance) and must be assessed against applicable regulatory requirements in each jurisdiction |
| Undocumented Invocation | AI system invoked without any record of the invocation event, rendering post-hoc compliance review impossible | Logging dependent on application-layer implementation; logs may be mutable, deletable, incomplete, or absent; no cryptographic guarantee of completeness or tamper-evidence; logging gaps create irresolvable ambiguity in regulatory proceedings | AUD-01 through AUD-05 enforce non-bypassable, append-only, hash-chained logging of every enforcement decision at the SUP boundary; logging is architecturally pre-application-layer; cryptographic tamper evidence maintained throughout retention period; completeness verifiable through hash chain integrity check | QODIQA logs enforcement decisions, not application-layer invocation content; logs do not capture AI output, user interaction detail, or data processed; content-level audit remains outside QODIQA scope and requires complementary application-layer logging |
| Consent State Ambiguity at Audit Time | Inability to reconstruct the consent state operative at the time of any specific historical AI invocation | Without cryptographic binding, reconstructing historical consent state requires assembling evidence from multiple mutable systems; reconstruction may be contested, incomplete, or impossible; creates significant regulatory exposure in investigations and DPA proceedings | Each ALE entry records consent token state, purpose scope, expiry, revocation status, and cryptographic token identifier at invocation time; historical consent state for any recorded invocation is fully reconstructable from the ALE and the consent token archive; evidence is cryptographically verifiable and non-repudiable | Reconstruction capability depends on retention policy compliance (AUD-RETAIN); organisations must configure retention periods to meet applicable regulatory requirements; QODIQA does not determine applicable retention periods, which are a legal and regulatory analysis function |
10.X.3 Ambiguity Surface Reduction Summary
Deterministic enforcement does not eliminate regulatory risk. It converts non-deterministic ambiguity into bounded, documented, cryptographically verifiable states. The ambiguity surface is reduced to: (a) the SLA window during revocation propagation; (b) the legal sufficiency of consent scope definitions upstream of the enforcement boundary; and (c) content-layer audit gaps outside QODIQA's enforcement scope. All other vectors listed above are addressed within the SUP boundary invariant. No claim of regulatory compliance follows from this reduction analysis.
#Institutional Closing Statement
This matrix has mapped QODIQA's deterministic runtime enforcement controls to the requirements of six major AI and data governance frameworks. The mappings are structural and technical. They establish where QODIQA's enforcement architecture provides genuine, verifiable support for regulatory control objectives - and where it does not.
The matrix demonstrates that QODIQA's contribution is concentrated in three areas: deterministic consent enforcement at the AI execution boundary, structured evidence generation through tamper-evident audit ledgers and cryptographically bound artifacts, and residual risk reduction through default-deny posture and purpose-bound processing gates. These contributions are technically meaningful and can reduce the ambiguity surface at the execution boundary where compliance failures most frequently originate.
At the same time, the matrix confirms that QODIQA does not address - and does not claim to address - the substantial majority of requirements in each framework that require organisational governance, legal interpretation, human judgment, or external certification. The non-coverage disclosures in Section 9 are as important as the coverage claims in Sections 3 through 8.
Institutional Position
QODIQA provides deterministic runtime enforcement at the AI execution boundary. It generates structured, replayable evidence through cryptographically bound audit artifacts. It reduces ambiguity at the execution boundary where consent obligations are most frequently violated. It does not replace legal compliance frameworks, organisational governance structures, or regulatory certification processes. It is a technical control plane that can structurally support them - with precisely defined scope and explicitly bounded non-coverage.
QODIQA-RAM-2026-001 · Regulatory Alignment Matrix · April 2026 · Technical Mapping Specification · Institutional Distribution
#Document Status and Classification
This document presents a technical control alignment matrix mapping QODIQA enforcement constructs to major AI and data governance frameworks. It is issued as a Technical Mapping Specification and is not a product specification, a commercial certification program, or a legal instrument.
QODIQA is not presented as a theoretical framework, but as an implementable infrastructure standard designed to introduce enforceable authorization, deterministic policy execution, runtime verifiability, and auditable proof mechanisms into AI-native systems.
The material contained herein is intended for:
- Enterprise risk teams and compliance architects
- Regulatory affairs specialists
- AI governance practitioners
- Security and governance officers
- Organizations building or operating autonomous AI systems
This matrix serves as a canonical reference for organizations evaluating the control coverage characteristics of QODIQA within their broader compliance posture. All regulatory framework citations are for structural cross-reference only.
This document should be read together with the following related specifications:
- QODIQA — Consent as Infrastructure for Artificial Intelligence Technical Whitepaper
- QODIQA — Core Standard for Deterministic Runtime Consent Enforcement
- QODIQA — 68-Point Enforcement Framework for Deterministic Runtime Consent Enforcement
- QODIQA — Certification Framework for Deterministic Runtime Consent Enforcement
- QODIQA — Implementation Playbook for Deterministic Runtime Consent Enforcement
- QODIQA — Reference Architecture for Deterministic Runtime Consent Enforcement
- QODIQA — Security and Cryptographic Profile for Runtime Consent Enforcement
- QODIQA — Governance Charter for the QODIQA Standard Corpus
Version 1.0 represents the initial formal release of this document as part of the QODIQA standard corpus.
For strategic inquiries, architectural discussions, or partnership exploration:
Bogdan Duțescu
0040.724.218.572