If you're building or operating a high-risk AI system under the EU AI Act, this is the distinction that trips up almost every compliance program: having a risk framework and being able to prove it operated are two different obligations, in two different articles, and most teams only build one of them.
TL;DR
Article 9 requires a continuous risk management process for high-risk AI systems — identify risks, evaluate them, mitigate them, review them as the system changes. Article 12 requires automatic, tamper-resistant logging of events over the system's lifetime, so that risk claims can actually be checked against what happened in production. Article 9 without Article 12 is a risk framework nobody can verify. Article 12 without Article 9 is a pile of logs with no governance behind them. Regulators, auditors, and — eventually — your own incident response team will ask for both.
One timing note before we get into it: Chapter III high-risk obligations, which is where both Article 9 and Article 12 live, had their compliance deadline moved from August 2, 2026 to December 2, 2027 under the EU's Digital Omnibus (final Council approval June 29, 2026). The requirements themselves didn't change — just the date they start being enforced. That's more runway to build this properly, not a reason to shelve it.
What Is the Difference Between Article 9 and Article 12?
The EU AI Act Article 9 vs 12 comparison comes down to two different responsibilities. Article 9 requires organizations to establish a risk management system for high-risk AI systems. Article 12 requires them to maintain technical logging capabilities that support traceability and accountability throughout the system's lifecycle.
It's a distinction most compliance programs blur without realizing it. A team writes a risk assessment document, checks the "we manage AI risk" box, and assumes that covers the regulation's expectations end to end. It doesn't. Article 9 is the governance layer — what you're supposed to be doing. Article 12 is the evidence layer — proof that you actually did it, in production, at the time it mattered. A regulator (or an internal auditor, or your own incident review after something goes wrong) isn't going to take the risk document's word for it. They're going to ask for the logs that back it up.
The two articles aren't redundant and they aren't optional extras of each other — they're both required, and they solve different halves of the same problem.
What Does Article 9 Actually Require?
Article 9 requires providers of high-risk AI systems to implement a continuous risk management process throughout the system's lifecycle. This is not a one-time assessment signed off before launch — it's an ongoing activity that identifies, evaluates, mitigates, and reviews AI-related risks as the system, its data, and its usage evolve.
In practice, an Article 9 process needs to:
- Identify foreseeable risks — before deployment and continuously afterward, covering both intended use and reasonably foreseeable misuse
- Evaluate and prioritize risks by likelihood and severity, so limited remediation effort goes where exposure is actually highest
- Implement mitigation measures — human oversight, access restrictions, guardrails, monitoring, or approval workflows that bring risk down to an acceptable level
- Continuously review those risks as models are updated, integrations change, or the system's use case quietly expands
The part that trips teams up: this becomes close to impossible if you don't know where your AI systems actually are. You can't run a risk management process against a system you haven't inventoried. Most organizations don't have a complete, current list of every AI tool and integration in active use — which means the Article 9 process has a hole in it before a single risk gets evaluated. Regaining that visibility, including uncovering shadow AI usage that never went through a formal review, is a prerequisite for Article 9 compliance, not a separate initiative.
What Does Article 12 Actually Require?
Where Article 9 is about managing risk, Article 12 is about proving it. It requires high-risk AI systems to technically support automatic recording of events — logs — over the system's entire lifetime, so significant AI activity can be reconstructed whenever it's needed.
This isn't uptime monitoring or generic application logs. Article 12 logging needs to actually support:
- Traceability throughout the lifecycle — reconstructing when a system was used, how it reached a given output, and which governance controls applied at that moment
- Investigations and audits — enough context to review a specific high-risk decision or respond to a regulatory request without falling back on manual documentation
- Demonstrating governance in practice — evidence that approvals, oversight, and controls were actually applied, not just described in a policy PDF
- Continuous monitoring — surfacing unusual behavior or recurring policy violations before they escalate into a larger governance or security incident
This applies just as much to systems you built yourself as to third-party tools. It's a common blind spot: teams assume an internally built AI application is inherently easier to govern because they control the code — but "we wrote it" doesn't produce an audit trail on its own. Homegrown AI applications need the same runtime logging and monitoring discipline as any vendor tool, or they fail Article 12 in exactly the same way.
If your high-risk system involves retrieval (RAG), this gets sharper still: a pipeline that surfaces a document a user wasn't authorized to see, with no record of what was retrieved or what entered the model's context window, has no way to satisfy Article 12 at all — there's simply nothing to reconstruct. This breakdown of RAG-specific data leakage goes into what retrieval-layer logging actually needs to capture to close that gap.
Why Article 9 and Article 12 Depend on Each Other
Neither article works in isolation. Article 9 has limited value if you can't demonstrate how risks were actually monitored or mitigated once the system was live. Article 12 produces records, but records without an underlying governance process just prove something happened — not that risk was being managed.
| Article 9 | Article 12 | |
|---|---|---|
| Focus | Risk management | Logging & traceability |
| Function | Identifies and mitigates risk | Records operational evidence |
| Nature | Defines governance activities | Supports investigations and audits |
| Timeframe | Continuous lifecycle management | Continuous runtime visibility |
Together, they form a governance loop rather than two separate checkboxes:
Risk Identification → Runtime Monitoring → Evidence → Continuous Improvement
↑ │
└──────────────────────────────────────────────────────┘
Article 9 defines what should be managed. Article 12 generates the evidence that it was. That evidence then feeds back into Article 9 — new patterns in the logs surface new risks, which restart the cycle. Treat them as two independent compliance tasks and you end up with a risk document nobody can verify and a pile of logs nobody's watching. Treat them as one operational loop and each one makes the other actually work.
This is also where most existing security tooling quietly falls short: it was built for uptime and performance debugging, not for producing the kind of continuous, audit-ready evidence Article 12 assumes exists by default. This analysis of the gap between traditional security controls and what AI governance actually requires covers why most enterprises can't currently produce that evidence even when they believe their AI usage is fully inventoried.
Compliance Requires More Than Documentation
Article 9 defines how organizations should manage AI risk. Article 12 ensures those activities can be demonstrated through operational records. Compliance requires both — governance and technical implementation, not one standing in for the other.
The question that matters going forward isn't whether your organization has documented AI governance. Almost everyone does at this point; it's an easy box to check. The real question is whether you can demonstrate, with operational evidence, that those governance decisions were continuously enforced — not just written down once and filed away.
Organizations that regain control over enterprise AI adoption — meaning full visibility into what AI is actually in use, sanctioned or not — end up building Article 9 and Article 12 as one integrated program instead of two separate compliance projects. That's the difference between passing an audit on paper and surviving one in practice.
FAQ
Can I satisfy Article 12 with regular application logs?
No. Article 12 requires logging capabilities specifically designed for traceability of the AI system's behavior — recording when it was used, how it reached an outcome, and what governance controls applied. Generic uptime/error logs weren't built to answer any of those questions and won't hold up as compliance evidence.
If I have a documented risk assessment, does that satisfy Article 9?
Only the initial step. Article 9 explicitly requires continuous risk management — identification, evaluation, mitigation, and review as the system evolves. A one-time assessment completed before launch and never revisited doesn't meet that bar once the system, its data, or its use case changes.
Does Article 12 apply to internally built AI tools, or just vendor products?
Both. Article 12's traceability requirements apply to any high-risk AI system regardless of who built it. Homegrown tools need the same runtime logging discipline as a purchased product — building it yourself doesn't exempt you from proving how it behaved.
Has the compliance deadline for Article 9 and Article 12 actually changed?
Yes. Both articles sit within Chapter III's high-risk system requirements, which the EU's Digital Omnibus postponed from August 2, 2026 to December 2, 2027 (final Council approval June 29, 2026). The obligations themselves are unchanged — only the enforcement start date moved.
What's the fastest way to tell if I have an Article 12 gap right now?
Try to answer, for a single high-risk AI interaction from last week: what was the input, what did the system retrieve or reference, what output was produced, and which human reviewed it. If you can't reconstruct that chain end to end, you have a record-keeping gap regardless of how good your risk documentation looks.
Sources
- Regulation (EU) 2024/1689 (EU AI Act), official text — EUR-Lex
- Article 9: Risk Management System — EU Artificial Intelligence Act reference
- Article 12: Record-Keeping — EU Artificial Intelligence Act reference
- Gibson Dunn — EU AI Act Omnibus agreement: postponed high-risk deadlines
- Help Net Security — what the EU AI Act requires for AI agent logging
Where This Fits Into a Bigger Governance Picture
Writing a risk management policy is the part most compliance teams already know how to do. Generating continuous, audit-ready evidence at the prompt and retrieval layer — without slowing down the people actually using these systems — is the harder engineering problem, and it's the one Article 12 quietly assumes you've already solved.
For teams working through this:
- Enterprise AI governance covers regaining visibility into AI usage as the starting point for Article 9's risk identification step.
- Shadow AI detection surfaces the unsanctioned AI usage that a risk management process can't account for if it doesn't know it exists.
- Guardia for Employees generates the prompt-level audit trail Article 12 requires for employee-facing AI usage.
- Armor for AI Applications applies the same runtime logging and guardrail discipline to homegrown, internally built AI systems.
- Preventing data leakage through enterprise AI tools covers the broader set of exposure vectors that a solid Article 9/12 program needs to account for.
If this clarified the distinction for you, a ❤️ or 🦄 helps other compliance and platform engineers find it. Curious where people are seeing the Article 9/Article 12 gap show up first in their own stack — drop it in the comments.
Top comments (0)