
The High-Risk AI Obligations Checklist You Can Actually Execute
The EU AI Act's obligations for high-risk AI systems read like a compliance essay. This checklist does the opposite: it maps each obligation to a runtime control you can operate and demonstrate — not a document you write once and hope no one tests.
- Katya SavenkovaDirector of Operations
In this article
The EU AI Act's obligations for high-risk AI systems read like a compliance essay. This checklist does the opposite: it maps each obligation to a runtime control you can operate and demonstrate — not a document you write once and hope no one tests.
Why a checklist you can execute, not an essay you file
Most EU AI Act guidance restates the law and stops there, which leaves teams with a list of obligations and no idea how to satisfy them beyond writing a policy document. The problem is that a regulator doesn't want your policy; they want to see the control working. So the useful question isn't "what does Article 9 say" — it's "what do I operate, day to day, that satisfies Article 9, and can I show it?"
Each obligation below is paired with the runtime control that discharges it inside a governed AI platform. Where a control writes to the signed audit ledger, "prove it works" becomes a query rather than a binder.
This is a practical mapping to help you operationalize obligations — not legal advice, and not a claim of certification. Classification and conformity for a specific system are decisions for your compliance and legal teams.
1. Risk management system
The obligation: identify, evaluate, and mitigate the risks a high-risk system poses across its lifecycle — continuously, not once.
The control you operate: risks are tied to live controls — content policy, security checks, human-approval gates — whose behavior is recorded as they run, so the risk process is a system that operates rather than a document that ages.
2. Data and data governance
The obligation: ensure the data used is relevant, appropriately governed, and access-controlled.
The control you operate: permission-aware retrieval and source-level access controls mean the system can only draw on what a given user is allowed to see, and every retrieval is recorded with its scope.
3. Record-keeping (logging)
The obligation: automatically log events over the lifecycle so the system's functioning can be traced and audited.
The control you operate: every prompt, retrieval, completion, redaction, and security decision is written to a signed, hash-chained ledger. Tracing the system's functioning is what the ledger is for.
4. Transparency and information to users
The obligation: provide clear information about the system's capabilities and limitations to those deploying it and, separately, meet the Article 50 duty — where it applies — to tell people when they are interacting with AI or seeing AI-generated content.
The control you operate: disclosure is generated by the system rather than remembered by a person; where AI was used, a machine-generated notice can be attached by construction, and its presence is itself on the record.
5. Human oversight
The obligation: design the system so a person can understand, oversee, and override its output — especially for consequential or irreversible actions.
The control you operate: consequential and outbound actions sit behind human-approval gates; nothing irreversible happens without a person, and the approval — who, when — is recorded alongside the decision.
6. Accuracy, robustness, and cybersecurity
The obligation: achieve appropriate accuracy and resist errors, manipulation, and adversarial attack.
The control you operate: accuracy is enforced by eval-gating before publish and continuous evaluation after; robustness and security by the deterministic firewall that inspects every prompt and completion for injection, jailbreak, and exfiltration.
7. Technical documentation
The obligation: maintain the technical file (Annex IV) that demonstrates the system meets its requirements.
The control you operate: much of the technical file assembles from what the platform already records — controls that ran, evaluations that passed, decisions that were logged — so documentation is composed from evidence rather than authored from memory after the fact.
Two further obligations — conformity assessment and registration — sit at the edge of what a platform can do for you, because they're procedural steps you take with the evidence in hand. The point of operating the controls above is that when you reach those steps, the evidence already exists.
Frequently asked questions
Turn obligations into controls you can show. See how Comply AI maps each high-risk requirement to a live control and assembles the technical file from evidence the platform already records. Book a walkthrough.
Part of