Responsible AI and Governance — Turning the EU AI Act into a Platform Checklist

Every AI platform team eventually hits the same question: the regulations are published, the principles are agreed, but which concrete controls does the platform need to enforce, and which obligations sit outside the platform entirely? This article bridges regulation and implementation. It uses the EU AI Act (Regulation (EU) 2024/1689) as the worked example and the NIST AI Risk Management Framework as the operational backbone, then maps both to the platform controls already covered in this series.

The goal is not legal advice — classification of a specific system is a determination for qualified counsel. The goal is an engineering-side translation: for each obligation that attaches to a high-risk AI system, which platform capability satisfies it, and which obligations require organisational governance that no CI pipeline can replace.

The Risk-Tier Decision Tree

The EU AI Act sorts AI systems into four bands — prohibited, high-risk, limited-risk (transparency only), and minimal-risk — and concentrates the bulk of its compliance obligations on the high-risk tier. Article 6 defines two routes into high-risk status, plus a derogation that can keep a system out of scope.

Walk a candidate system top-down through no more than five decision nodes:

1. Is the use case banned outright (social scoring, untargeted facial-recognition scraping, manipulative or exploitative systems)? If yes — prohibited. Block at the model registry; no promotion path exists.
2. Is it a listed high-stakes use case (Annex III: employment, credit, biometrics, critical infrastructure, essential services, law enforcement, migration, justice) or a safety component of a regulated product (Annex I: machinery, medical devices, aviation)? If yes, proceed to step 3. If no, skip to step 4.
3. Does the system perform only a narrow procedural task and does not profile natural persons (Art. 6(3) derogation)? If yes — it drops to limited or minimal. If no, or if it profiles persons — high-risk. Full control stack applies.
4. Does the system interact with people who need to know it is AI (chatbots, content generation, emotion recognition with disclosure)? If yes — limited-risk. Transparency obligations apply.
5. Everything else — minimal-risk. Standard MLOps hygiene; no extra governance load.

Classification is not static. A change of intended purpose, a new downstream consumer, or fine-tuning that materially shifts behaviour can move a system up a tier. The risk tier should live as a field on the model artefact in the registry and be re-evaluated at every promotion, not stamped once at onboarding.

Article-by-Article Obligation to Platform Control Mapping

For systems classified as high-risk, the EU AI Act loads provider obligations through Articles 9-15 and deployer obligations through Article 26. The table below maps each obligation to a concrete platform-control pattern and, where applicable, to the series article that explains the mechanism in depth. The pattern is outcome-based: the Act specifies what must be true, not which tool to use — so every row translates a regulatory requirement into a platform invariant.

Article 9 — Risk-Management System

Requires a continuous, iterative risk-management process across the AI system lifecycle — not a one-off sign-off (Article 9 text). Platform control: A documented model risk register and a pre-release risk-review gate tied to promotion in the model registry. The review re-triggers whenever data, model version, or intended use changes. Series link: see governance-lineage-model-cards (Article 12) for the artefact side.

Article 10 — Data and Data Governance

Training, validation, and test datasets must be relevant, sufficiently representative, and as free of errors as possible (Article 10 text). Platform control: Dataset lineage, versioning, and bias/quality checks captured at curation time. The dataset version is bound to the model version so an auditor can trace from a deployed prediction back to the data it was trained on.

Article 12 — Record-Keeping

Automatic logging of events over the system's lifetime, with records sufficient to trace decisions (Article 12 text). Platform control: Immutable lineage records linking data version, model version, and deployment; serving logs retained per the retention policy. The governance-and-lineage pattern (governance-lineage-model-cards in this series) and the observability stack jointly satisfy this.

Article 13 — Transparency and Provision of Information to Deployers

High-risk systems must be sufficiently transparent to enable deployers to interpret output and use it appropriately (Article 13 text). Platform control: Published model cards with intended-use statements, known limitations, and responsible-AI disclosure. For generative systems, this decomposes into the four operational practices covered below: PII redaction, output provenance, red-teaming, and content filtering together make the output interpretable.

Article 14 — Human Oversight

A named role must be able to interpret the system's output, override it, and stop the system (Article 14 text). Platform control: Approval gates in the promotion path with named accountable roles who hold stop/rollback authority. "On-the-loop" monitoring is acceptable for lower-stakes flows; "in-the-loop" approval before the action takes effect is required where output drives a consequential decision.

Article 15 — Accuracy, Robustness, and Cybersecurity

High-risk systems must achieve appropriate levels of accuracy, robustness, and cybersecurity (Article 15 text). Platform control: Evaluation suites run as tests in CI (see eval-as-test-suite in this series) provide the accuracy and robustness evidence as a CI artefact. Supply-chain integrity for ML artefacts — provenance signing, SBOM, attestation — closes the cybersecurity limb so a model cannot be silently swapped between evaluation and serving (see sbom-and-signing-for-ml).

Article 26 — Deployer Obligations

Deployers carry their own duties: use the system per instructions, assign competent human oversight, retain automatically generated logs for at least six months, monitor operation, report serious incidents without undue delay, and inform affected workers before workplace deployment (Article 26 text). Platform control: Operational monitoring, drift and eval observability, and a log-retention policy that meets the six-month floor. Note that worker notification and incident-reporting routes are organisational processes that sit outside the platform — they need a named owner, not a CI job.

Calibrating Controls with the NIST AI RMF

The EU AI Act gives you the categorical tier — a system is in a band or it is not. The NIST AI Risk Management Framework (AI 100-1, January 2023) gives you the continuous posture inside a tier. Its four core functions — Govern, Map, Measure, Manage — provide the operational loop that determines how much of the optional control surface to apply within a given risk band.

Govern is the cross-cutting function: it establishes accountability, defines policies, and ensures oversight across the AI lifecycle. It is where the organisational governance that the platform cannot replace lives — incident-reporting routes, worker-notice processes, and the legal classification of record.

Map establishes context: categorising the system, clarifying capabilities and goals, identifying risks from first- and third-party sources, and characterising impacts. This is where the risk-tier decision tree plugs in — the tree is the mapping step, and its output (the tier) feeds everything downstream.

Measure selects metrics and methods, evaluates trustworthiness characteristics, and tracks risk over time. The evaluation suites in CI (accuracy, robustness, red-team regression corpus) and the observability signals (drift detection, output-quality metrics) are the platform's expression of Measure.

Manage prioritises identified risks, defines treatments, and plans response and recovery. The promotion gates, rollback capability, and content-filtering thresholds that block or escalate based on measured risk are the platform's Manage function.

Use the Act to pick the tier and the RMF to calibrate the controls inside it. The two frameworks pull in different directions — categorical versus continuous — and the tension is productive: it prevents both over-governing minimal-risk systems and under-governing high-risk ones with only a checkbox.

ISO/IEC 42001 and the Management-System Layer

Where the EU AI Act sets outcome-based obligations and the NIST AI RMF provides an operational loop, ISO/IEC 42001:2023 adds the certifiable management-system wrapper. Published in December 2023, it is the first international standard for an AI Management System (AIMS), built on the same Annex SL backbone as ISO/IEC 27001 and ISO 9001. It uses the Plan-Do-Check-Act cycle and requires systematic AI risk assessment (Clause 6.1), performance measurement against defined indicators (Clause 9), and third-party supplier oversight.

For teams operating in a regulated industry, ISO/IEC 42001 certification can serve as evidence of a quality-management system — which is what Articles 16-17 of the EU AI Act require from providers. The standard does not replace the Act's specific technical obligations (Articles 9-15), but it provides the organisational governance framework within which those obligations are managed.

The Four Operational Practices for Generative AI

Generative AI systems add a distinct surface to the governance problem: they emit free text, images, and code that can leak training data, fabricate claims, be steered by adversarial input, or be passed off as human-authored. The following four operational practices close that surface. Each maps to the OWASP Top 10 for LLM Applications (2025 edition) for the concrete attack class and to the NIST AI RMF for the governance function it plugs into.

1. PII Redaction

Strip or tokenise personal data before it reaches a model — on both the prompt path and the logging path. This is the precondition for everything downstream: you cannot safely red-team, store evaluation transcripts, or ship traces to observability without it. Closes OWASP LLM02:2025 — Sensitive Information Disclosure. A common trap: redacting the prompt but forgetting the completion — a model can echo or infer an identifier the input did not contain, so the response path needs the same pass.

2. Output Watermarking and Provenance

Attach verifiable provenance to model-generated media so downstream consumers can distinguish synthesised from human-authored content. For images, audio, and video the durable mechanism is content credentials (C2PA) — cryptographically signed manifests bound to the asset. For text, the practical signal today is metadata-level labelling and retrieval-time attribution rather than robust pixel-style watermarks. This directly supports Article 50 transparency obligations, enforceable from 2 August 2026, which require providers to ensure AI-generated content is marked in a machine-readable format. An honest limitation: text watermarking is not yet robust to paraphrase or re-generation — do not over-claim it.

3. Red-Teaming Cadence

Adversarially probe the system on a fixed schedule and on every material change (new model version, new tool or function, new system prompt). Red-teaming is not a launch gate you pass once; it is a recurring obligation whose cadence is itself the control. Closes OWASP LLM01:2025 — Prompt Injection and the broader Measure function of the NIST loop. Run automated prompt-injection and jailbreak corpora in CI on every PR; schedule a quarterly human-led exercise against the live configuration; ensure every confirmed exploit becomes a permanent regression test.

4. Content Filtering and Transparency Disclosure

Classify and block disallowed input and output on both the request and response side — at minimum self-harm, illegal content, and the categories your jurisdiction and product policy prohibit. A moderation classifier on the response path with documented actions per category (block, redact, escalate to human), version-controlled thresholds tested as part of the evaluation suite, and a clear, logged refusal path so blocked interactions are auditable. Treat the filter as the last line of defence, not the first — redaction, system-prompt hardening, and red-teaming all sit upstream of it.

What the Platform Cannot Do Alone

A well-governed platform satisfies a large fraction of the EU AI Act's technical obligations, but several duties are organisational by nature and require governance structures, legal determinations, and human processes that no CI pipeline can replace:

• Legal classification of record. The platform can triage via the decision tree, but the binding determination of whether a system is high-risk — and especially claims under the Art. 6(3) derogation — is a legal judgement for qualified counsel.
• Incident reporting routes. Article 26 requires serious-incident reporting without undue delay. The platform emits the detection signal; the reporting path to regulators needs a named owner, defined timelines, and a communication chain.
• Worker notification. Article 26 requires deployers to inform affected workers and their representatives before workplace deployment of a high-risk system. This is an HR and legal process, not a platform feature.
• Data-protection impact assessment inputs. Providers must supply information that feeds the deployer's DPIA under GDPR Article 35. The platform captures metadata; the assessment itself is a legal-privacy exercise.
• Conformity assessment. For Annex I systems (regulated products), Articles 16-17 require third-party conformity assessment. The platform provides the evidence; the assessment is performed by a notified body, not by a pipeline.

The pattern to internalise: the platform provides the technical controls and the evidence trail; the organisation provides the governance, legal determinations, human processes, and regulatory interface. A mature posture has both — platform controls without governance is a green pipeline with no legal standing; governance without platform controls is policy with no enforcement mechanism.

Enforcement Timeline and Sequencing

The EU AI Act entered into force on 1 August 2024 and applies in phases (implementation timeline). The dates most platform teams anchor on:

• 2 February 2025: Prohibited-practice bans and AI-literacy duties live.
• 2 August 2025: Governance bodies and GPAI model obligations live.
• 2 August 2026: Article 50 transparency obligations (disclosure and watermarking of AI-generated content) enforceable.
• 2 December 2027: Stand-alone high-risk systems (Annex III) obligations enforceable.
• 2 August 2028: Regulated-product high-risk systems (Annex I) obligations enforceable.

Sequence your control work against these dates: transparency and provenance controls first (August 2026 is imminent), then the full high-risk obligation stack. Build to the earlier of the dates that apply to your system, and verify against the final adopted text — the 2026 Digital Omnibus simplification package adjusted several of these deadlines.

References

1. European Parliament and Council. "Regulation (EU) 2024/1689 — Article 6: Classification Rules for High-Risk AI SystemsArticle 6: Classification Rules for High-Risk AI Systems." Official Journal of the European Union, 2024.
2. EU AI Act — Articles 9-15: Requirements for High-Risk AI Systems. artificialintelligenceact.eu, 2024.
3. EU AI Act — Article 26: Obligations of Deployers of High-Risk AI Systems. artificialintelligenceact.eu, 2024.
4. EU AI Act — Article 50: Transparency Obligations for Providers and Deployers of Certain AI Systems. artificialintelligenceact.eu, 2024.
5. NIST. "Artificial Intelligence Risk Management Framework (AI RMF 1.0)." NIST AI 100-1, January 2023.
6. OWASP. "Top 10 for LLM Applications 2025." OWASP GenAI Security Project, November 2024.
7. ISO/IEC. "ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system." International Organization for Standardization, December 2023.
8. Coalition for Content Provenance and Authenticity. "C2PA Technical Specification." Linux Foundation, v2.2, May 2025.
9. "EU AI Act — Implementation Timeline." artificialintelligenceact.eu, 2026.