This playbook doesn't just claim alignment with 19 regulations and standards — this page shows exactly what each one requires, how many artifacts actually cite it, and (for the EU AI Act specifically) which exact section addresses which exact Article. Extracted directly from the real build data, not estimated.
For each source: what it actually says, how many artifacts cite it, and which ones. A narrow count isn't automatically a gap — ISO/IEC 22989 is a terminology standard, so it's correctly cited only where AI vocabulary alignment matters, not everywhere.
The EU AI Act is the most complex source cited across this playbook. This table goes one level deeper than the matrix above: for each of the 18 Articles already addressed somewhere in the playbook, what it requires and the exact section that addresses it.
| Article | What It Actually Requires | Artifact | Exact Section / Question |
|---|---|---|---|
| Art. 5 | Prohibits 8 specific AI practices outright (social scoring, exploiting vulnerabilities, subliminal manipulation, real-time public biometric ID for law enforcement, workplace/education emotion recognition, sensitive-attribute biometric categorization, untargeted facial scraping, predictive policing) — no risk tier or mitigation applies; these cannot be built. | Compliance Analysis | Section 8, “Step One — Prohibited Practices Screen” (hard-stop callout before classification) |
| Art. 6 / Annex III | Defines which AI systems count as High-Risk by naming 9 specific use-case categories (medical devices, vehicles, recruitment/HR, education, essential services, critical infrastructure, law enforcement, migration/justice, biometrics). | Compliance Analysis | Section 8, Axis 2 (EU AI Act Risk Tier) — Annex III category checklist note under the High-Risk checkbox |
| Art. 9 | Requires a continuous, iterative risk management system across the AI system's lifecycle — not a one-time assessment. | AI Risk Register / AI Solutions FMEA | Both artifacts (ongoing use); confirmed as a genuine system, not just artifacts existing, in QMS Section 4 (“Risk Management System”) |
| Art. 10 | Requires data governance covering acquisition, quality, representativeness, bias examination, and data-gap documentation for training/validation/test data. | Data Assessment Report | Sections 2–3 (Data Quality Assessment; Data Representativeness & Early Bias Screening) |
| Art. 11 / Annex IV | Requires comprehensive technical documentation covering system description, development process, risk management, monitoring, and standards applied — compiled before market placement. | Conformity Assessment | Section 2, “Technical Documentation Compilation (Annex IV)” — element-by-element checklist |
| Art. 12 | Requires the system to automatically log events across its lifetime, enabling traceability and post-market monitoring. | Instructions for Use | Section 7, “System Lifetime, Maintenance & Logging” |
| Art. 13 | Requires the system to be accompanied by instructions for use covering intended purpose, performance characteristics, known limitations, and interpretation guidance for the deployer. | Instructions for Use | Whole document (Sections 1–4 specifically); Solution Design Section 5 addresses this at design time |
| Art. 14 | Requires human oversight measures be designed in — the ability for a human to understand, monitor, and intervene in or override the system's operation. | Instructions for Use | Section 5, “Human Oversight Measures” + “Deactivation & Restriction Controls”; Solution Design Section 5 |
| Art. 15 | Requires an appropriate level of accuracy, robustness, and cybersecurity, consistently maintained throughout the lifecycle. | System Test Protocol / Model Validation Report | System Test Protocol Section 5, “Test Types & Coverage” (AI/Model Verification row); Model Validation Report (whole document) |
| Art. 17 | Requires a Provider-level Quality Management System covering compliance strategy, design control, data management, risk management, post-market monitoring, incident reporting, record-keeping, and accountability. | Quality Management System | Whole document — an index confirming the above artifacts function as one system, not 11 disconnected ones |
| Art. 27 | Requires certain Deployers (public bodies, public-service providers, or credit/insurance risk-assessment use cases) to assess a specific deployment's impact on fundamental rights before use. | Fundamental Rights Impact Assessment | Whole document — explicitly Deployer-side, with an applicability gate before Section 1 |
| Art. 43 | Defines the conformity assessment procedure a High-Risk system must undergo before market placement (internal control, or third-party/notified body, depending on category). | Conformity Assessment | Section 1, “Scope & Applicability”; Section 3, “Conformity Assessment Outcome” |
| Art. 47 | Requires a formal Declaration of Conformity be issued and retained once conformity assessment is complete. | Conformity Assessment | Section 4, “Declaration of Conformity” |
| Art. 49 | Requires High-Risk systems be registered in the EU public database before being placed on the market. | Conformity Assessment; AI Application & Model Inventory | Section 3 (registration referenced as part of the conformity outcome); AI App & Model Inventory References & Sources block (registration duty cited as basis for the internal register) |
| Art. 71 | Establishes and requires the Commission to set up and maintain the EU database that Art. 49 registrations are entered into — the database itself, not the registration duty. | AI Application & Model Inventory | References & Sources block — cited as the database Art. 49 registration feeds; this artifact is the internal register that precedes external submission |
| Art. 50 | Requires end-user-facing disclosure when a person interacts with generative AI, and labeling/watermarking of AI-generated synthetic content (with a stricter rule for deepfake-like content). | Solution Design Document | Section 5, “EU AI Act Art. 50 — Generative AI Disclosure” block |
| Art. 72 | Requires Providers to actively collect and analyze post-market performance data as an operating system, not just a design intention. | AI/Model Monitoring Plan | Section 5, “Hypercare-to-Steady-State Cadence Step-Down”; confirmed as a real system (not just a plan) in QMS Section 5 |
| Art. 73 | Requires serious incidents be reported to the relevant market surveillance authority within a defined timeframe. | AI Incident Report | Reportability test (whole document); QMS Section 6, “Serious Incident Reporting Procedures” confirms the org-level process around it |
Same treatment, extended to GDPR, HIPAA, NIST AI RMF, and ISO/IEC 42001.
NIST AI RMF's Manage function isn't explicitly cited anywhere in this playbook yet. The AI Risk Register and Quality Management System (Section 4) cover the underlying substance — prioritizing and acting on identified risks — but neither names the Manage function directly. This surfaced while compiling this page, and is left visible rather than quietly patched over. See the highlighted row below.
| Regulation | Clause | What It Actually Requires | Artifact | Exact Section / Question |
|---|---|---|---|---|
| GDPR | Art. 6 | Requires a valid lawful basis (consent, contract, legitimate interest, etc.) before personal data can be processed. | Compliance Analysis | Section 5, “Data Privacy Deep-Dive” |
| GDPR | Art. 9 | Imposes a stricter basis requirement for special-category data — health, biometric, and other sensitive personal data. | Compliance Analysis | Section 5, “Data Privacy Deep-Dive” |
| GDPR | Art. 32 | Requires appropriate technical and organizational security measures proportionate to the risk of processing. | System Test Protocol / AI System Audit Checklist | System Test Protocol Section 5 (Security test type) |
| GDPR | Art. 35 | Requires a Data Protection Impact Assessment before processing likely to result in high risk to individuals. | Compliance Analysis / Business Case & Charter | Compliance Analysis Section 5; Business Case & Charter Section 5 (DPIA trigger question) |
| HIPAA | §164.312 | Security Rule technical safeguards — access control, unique user identification, audit controls, encryption. | Solution Design Document | Section 6, “Security & Privacy by Design” |
| HIPAA | Minimum Necessary Standard | Limits use/disclosure of protected health information to the minimum needed for the intended purpose. | Data Assessment Report | Section 4, “Privacy & Sensitive Data Mapping” |
| NIST AI RMF | Govern | Establishes organizational culture, risk tolerance, and accountability structures for AI risk management. | Business Case & Charter / AI System Audit Checklist | Business Case & Charter, EU AI Act/NIST framework tag (risk tolerance ownership question) |
| NIST AI RMF | Map | Identifies system context, boundaries, and potential impacts before risk can be meaningfully measured. | Solution Design Document / System Test Protocol | Solution Design Section 7 (system boundaries question); Threat Modeling (System Test Protocol) |
| NIST AI RMF | Measure | Analyzes, assesses, and tracks identified risks using appropriate methods. | System Test Protocol | Red Teaming and Computer Vision robustness rows, Section 5 |
| NIST AI RMF | Manage | Prioritizes and acts on risks based on the Measure function's findings; the follow-through step. | — | Not currently an explicit citation anywhere — the AI Risk Register and QMS Section 4 cover this in substance but don't cite the Manage function by name. A real, honest gap. |
| ISO/IEC 42001 | Annex A.2 / A.3 | Requires defined organizational roles, responsibilities, and leadership commitment to the AI Management System. | AI System Audit Checklist / Business Case & Charter | AI System Audit Checklist; Business Case & Charter (AIMS scope question) |
| ISO/IEC 42001 | Annex A.6 | Requires life-cycle controls across an AI system's design, development, and deployment stages. | Solution Design Document | Section 8, framework tag (Annex A.6 life-cycle design controls question) |
| ISO/IEC 42001 | Annex A.7 | Requires documented data governance — provenance, quality, and category classification for AI system data. | Data Assessment Report / AI System Audit Checklist | Data Assessment Report, framework tag; AI System Audit Checklist |
| ISO/IEC 42001 | Clause 9.1 | Requires ongoing performance evaluation of the AI Management System — monitoring, measurement, and analysis. | AI System Audit Checklist | Performance evaluation section (Clause 9.1 citation) |