This checklist mirrors the obligations binding from 2 August 2026 on providers and deployers of high-risk AI systems under Regulation (EU) 2024/1689. Walk it column-by-column with your QA / compliance lead. Anything red is a control to build before enforcement.
How to use: tick `Yes` only where you have written, version-controlled evidence (SOP, model card, audit row, signed approval). `Partial` means the activity happens but is not yet documented to inspector standard. `No` means absent. Targets sub-30 minutes per AI system in scope.
Article 9 -- Risk management system
1
Risk register identifies foreseeable risks per system, scored likelihood x impact
YesPartialNoN/A
2
Mitigations are documented per risk + assigned to a named owner
YesPartialNoN/A
3
Residual risk recorded after mitigation + signed off
YesPartialNoN/A
4
Risk review cadence defined; trigger-based + at-least-quarterly
YesPartialNoN/A
Article 11 + Annex IV -- Technical documentation
5
Model card per (model, version) pair is up-to-date
YesPartialNoN/A
6
Card includes intended use, out-of-scope use, data sources, evaluation, bias assessment, limitations
YesPartialNoN/A
7
Card describes the human-oversight mechanism in concrete reviewer terms
YesPartialNoN/A
8
High-risk cards approved by a different person than the author (segregation of duties)
YesPartialNoN/A
Article 13 -- Transparency to deployers
9
End users are informed they are interacting with an AI system
YesPartialNoN/A
10
AI-generated outputs visibly labelled `Draft -- requires qualified review` until human-signed
YesPartialNoN/A
11
Reviewers see source-page citations alongside extracted fields
YesPartialNoN/A
12
An instructions-for-use document accompanies each high-risk system in production
YesPartialNoN/A
Article 14 -- Human oversight
13
No AI output advances to a regulatory submission without an e-signed human approval
YesPartialNoN/A
14
Reviewers can edit, reject, or reclassify every AI output before approval
YesPartialNoN/A
15
Reject reasons recorded under a controlled vocabulary (not free-text)
YesPartialNoN/A
16
Drift detection flags accuracy regressions; affected systems can be paused tenant-wide
YesPartialNoN/A
Article 16 -- Provider obligations
17
Quality management system in place (or aligned to ISO 9001 / equivalent)
YesPartialNoN/A
18
Post-market monitoring plan documented for each high-risk system
YesPartialNoN/A
19
Conformity assessment path identified (Annex VI internal vs Annex VII NB)
YesPartialNoN/A
20
EU representative appointed if provider is established outside the EU/UK
YesPartialNoN/A
Article 17 -- Quality management system
21
Change management procedures cover model updates, prompt updates, vendor swaps
YesPartialNoN/A
22
Frozen prompt versioning -- production prompts are not edited in place
YesPartialNoN/A
23
Incident-response procedure includes regulator-notification triggers
YesPartialNoN/A
Article 26 -- Deployer obligations (when you operate AI built by others)
24
Vendor model cards reviewed and stored locally before go-live
YesPartialNoN/A
25
Deployer-side oversight policy in place (who reviews, what they sign for)
YesPartialNoN/A
26
Workers using the AI are informed that an AI system is involved
YesPartialNoN/A
Article 50 -- Transparency for limited-risk AI
27
Limited-risk systems disclosed to end users; emotion-recognition / biometrics flagged
YesPartialNoN/A
Article 72 -- Post-market monitoring
28
Serious incidents reportable to national authority within 15 days; SOP in place
YesPartialNoN/A
Where Praxara helps
Items 1-16 are produced by the platform: risk register, model cards (with the four-eyes guard for #8), draft-only labels (#10), source-page citations (#11), e-signature on every approval (#13), reject-with-reason (#15), drift detection (#16). Items 17-28 are organisational controls Praxara documents in your Compliance Pack but does not enforce on your behalf -- they sit with your QMS.