High-Risk AI Systems Checklist: 25 Compliance Points (EU AI Act 2026)

If your AI system falls under Annex III of the EU AI Act, the regulation does not ask you to be careful — it asks you to be auditable. The difference is concrete. Careful is what you tell your CEO. Auditable is what you can produce in front of a market-surveillance officer in under an hour, with timestamps, version hashes, and oversight signatures.

This checklist is the operator's edition. Twenty-five concrete control points, grouped by the eleven AI Act articles that govern high-risk systems end-to-end (Articles 6, 9, 10, 11, 12, 13, 14, 17, 26, 49, 71). Each point is binary — done or not done — with the evidence the auditor expects to see.

Use it as a self-assessment before procurement, as an internal gate before deployment, or as a vendor questionnaire when shortlisting AI Act compliance software. If you cannot answer "yes, here is the evidence" to all 25 by 2 August 2026, you carry residual risk into the enforcement window.

Companion reading: /blog/ai-act-compliance-software-guide, /blog/ai-act-fines-explained, /blog/ai-audit-trail-implementation-guide, /blog/eu-ai-act-business-guide.

Before You Start: Is Your System Actually High-Risk?

Two routes lead into the high-risk regime under Article 6:

1. Article 6(1) — your AI system is a safety component of a product covered by the EU harmonization legislation in Annex I (machinery, medical devices, toys, lifts, radio equipment, in-vitro diagnostics, etc.) and that product requires third-party conformity assessment.
2. Article 6(2) + Annex III — your system falls into one of eight enumerated domains: biometrics, critical infrastructure, education, employment and worker management, essential private and public services (including credit and insurance), law enforcement, migration/asylum/border control, and administration of justice and democratic processes.

Article 6(3) provides a narrow exemption for purely procedural tasks, narrow improvements, pattern-detection without decision-making, or preparatory tasks — but you must document and notify the use of this exemption. Treat the exemption as a high-effort path, not a shortcut.

If neither route applies, the rest of this checklist does not bind you. You may still owe transparency obligations under Article 50 (limited risk), or general-purpose model obligations under Articles 51–55. Confirm before stopping reading.

If either route applies, every item below is in scope. Begin.

Article 6 — Risk Classification (3 controls)

The classification record is the entry document. Without it, every later step is unverifiable.

1. Documented risk classification per AI system

The system is classified under Annex III with the specific sub-category cited (e.g., "Annex III.4(a) — employment, recruitment, and selection"). Free-text "yes/no high-risk" toggles fail this control.

Evidence the auditor expects: a written classification record per system, dated, signed by the AI compliance officer, traceable to the Annex sub-point. In Knowlee, this lives in AI-SYSTEMS-INVENTORY.md with rows like SYS-003 — 4Talents | ALTO — AI Act Annex III, punto 4(a).

2. Article 6(3) exemption claims documented

If you claim the procedural-task exemption, the rationale is written, signed, and stored — and you have notified the competent national authority through the EU AI database under Article 49.

Evidence the auditor expects: the exemption memo, the date of notification, the receipt or registration ID. Undocumented exemption claims are treated as non-classified high-risk systems — the worst posture under enforcement.

3. Annual or change-triggered reclassification

The classification is reviewed at least annually and on any substantial modification (new use case, new training data category, new geographic deployment).

Evidence the auditor expects: a versioned classification log showing review dates and either "no change" or the trigger and the new outcome.

Article 9 — Risk Management System (3 controls)

Article 9 is the spine of the high-risk regime. It demands a continuous, iterative risk-management process for the entire lifecycle.

4. Versioned risk register per system

Each high-risk system has its own register, not a row in a corporate enterprise risk register. Identified hazards, foreseeable misuse, residual risk after controls, and the decision criteria for accepting residual risk are captured.

Evidence the auditor expects: the register, with timestamps for each entry, links to controls, and links to evidence of those controls operating.

5. Post-deployment monitoring plan

A written plan for how the system is monitored after market placement — drift, accuracy degradation, fairness regression, unforeseen interactions. Not a generic "we have monitoring" — a system-specific plan with metrics, thresholds, and review cadence.

Evidence the auditor expects: the plan, the dashboards or reports it produces, and the meeting minutes where last quarter's findings were discussed.

6. Risk-management process integrated with deployer feedback

If the system was placed by a provider and is now operated by a deployer, there is a documented channel for the deployer to report incidents, near-misses, and operational issues back to the provider — closing the Article 72 (post-market monitoring) and Article 73 (serious incident reporting) loops.

Evidence the auditor expects: the contractual clause, the channel (email distribution list, ticket system, MCP-driven incident endpoint), and at least one example of a deployer-originated finding flowing through it.

Article 10 — Data and Data Governance (2 controls)

7. Training, validation, and testing dataset documentation

For each dataset used to train, validate, or test the system, you have documented provenance, design choices, data collection process, processing operations, and any annotation methods. Datasets are examined for bias and statistical properties relevant to the intended purpose.

Evidence the auditor expects: datasheets per dataset (the Gebru et al. "Datasheets for Datasets" pattern is widely accepted), bias evaluation reports, and rationale for any decisions to proceed despite identified bias.

8. Data quality and representativeness review

Datasets are relevant, sufficiently representative, free of errors, and complete in view of the intended purpose. Geographic, contextual, behavioral, and functional settings are considered. Personal data processing is justified under GDPR Article 6 lawful basis and, where applicable, Article 9 special-category exemption.

Evidence the auditor expects: the data-quality report, the GDPR DPIA where personal data is involved, the legitimate-interest assessment if relied upon.

Article 11 — Technical Documentation (2 controls)

Article 11 plus Annex IV define what is in the technical file. This is the document the notified body or market surveillance authority reads when something goes wrong.

9. Annex IV-compliant technical file

The file covers: a general description of the system; detailed description of the elements and the development process; information on monitoring, functioning, and control; appropriateness of performance metrics; risk-management system per Article 9; a description of any change made through the lifecycle; the harmonized standards applied; the EU Declaration of Conformity; and a description of the post-market monitoring plan.

Evidence the auditor expects: the file itself, with versioning, kept for ten years after market placement (Article 18).

10. Living technical file with change log

The file is not frozen at launch. Substantial modifications trigger a documented update. Trivial changes (UI copy, minor performance tuning) are logged in a change register. Substantial ones (model swap, training data category added, intended purpose extended) trigger a new conformity assessment under Article 43.

Evidence the auditor expects: the change log, the rules used to distinguish substantial from non-substantial, and the conformity assessment trail when triggered.

Article 12 — Records and Logs (3 controls)

Article 12 is where many programs fail in practice. The standard is "automatic" — not manual, not exportable on request. Logs are recorded as the system operates.

11. Automatic, tamper-evident operational logging

Every inference produces a log entry capturing: timestamp; system identifier; model version; input fingerprint (hash, not raw input where personal data is concerned); output (or output reference); the human reviewer where Article 14 oversight intervened.

Evidence the auditor expects: a sample of recent log entries, the cryptographic mechanism guaranteeing tamper-evidence (append-only store, hash chain, or write-once medium), and the documented retention rule.

In Knowlee, every job execution streams JSONL to the audit trail. Each entry carries risk level, data categories, model identifier, and exit code. The audit-trail spoke article (/blog/ai-audit-trail-implementation-guide) walks the implementation in detail.

12. Six-month minimum retention; ten-year for high-risk providers

The logs are retained at least six months by the deployer (Article 26(6)) and at least ten years by the provider after the AI system has been placed on the market or put into service (Article 18(1)).

Evidence the auditor expects: the retention policy, the storage tier and cost line, and a sample restore from the oldest tier.

13. Log access governance

Access to operational logs is RBAC-controlled. Access events are themselves logged. The auditor can request a specific time-window export and receive it within a stated SLA.

Evidence the auditor expects: the access control matrix, the access log, and an example export.

Article 13 — Transparency and Information for Deployers (2 controls)

14. Instructions for use shipped with the system

The deployer receives, before deployment, instructions covering: the provider's identity; the system's intended purpose; performance characteristics; known limitations; foreseeable misuse; the input data the system expects; how to interpret outputs; the human-oversight measures including technical measures put in place; computational and hardware resources required; expected lifetime; and post-market monitoring described in plain terms.

Evidence the auditor expects: the document, dated, version-controlled, and a delivery receipt to each deployer.

15. Deployer-side onboarding record

The deployer has read, acknowledged, and trained relevant staff on the instructions for use. This is a control on the deployer side under Article 26(2), but the provider should request acknowledgment to close the loop.

Evidence the auditor expects: signed acknowledgments, training records, and refresher cadence.

Article 14 — Human Oversight (2 controls)

16. Designed-in oversight, not bolted-on

The system is designed and developed in such a way that natural persons can effectively oversee its operation during the period the AI system is in use, including through appropriate human-machine interface tools. "Effectively" means: the overseer can understand the capacities and limitations, monitor operation, recognize automation bias, interpret output, decide not to use the output, and intervene or interrupt.

Evidence the auditor expects: the design specification showing the oversight controls, screenshots or recordings of those controls operating in production, and the rationale for why they are sufficient.

In Knowlee, oversight is the dashboard contract: every job declares "human-oversight required" set to true or false, and 4Talents (recruitment, ALTO-risk per Annex III.4(a)) defaults to required oversight with mandatory approval before output is consumed. Documented in TECHNICAL-COMPLIANCE-MAP.md.

17. Trained, named human overseers

Specific persons are designated as human overseers, named in the technical file, trained on the system's outputs and limitations, and refreshed at least annually.

Evidence the auditor expects: names, roles, training records, and rotation schedule. "The product owner" is not a name. "Anna Rossi, AI Compliance Officer, certified ISO/IEC 42001 Lead Implementer 2026-Q1" is a name.

Article 17 — Quality Management System (2 controls)

18. Documented QMS for the AI lifecycle

The provider has a written quality management system covering: regulatory compliance strategy; design control techniques; development, quality control, and quality assurance techniques; examination, test, and validation procedures; technical specifications; data management; the risk management system of Article 9; post-market monitoring; incident reporting under Article 73; communication with authorities; record-keeping; resource management; and an accountability framework.

Evidence the auditor expects: the QMS manual, ISO/IEC 42001:2024 certification or alignment evidence, and audit findings from the most recent internal review.

19. ISO/IEC 42001 alignment as a credible substrate

ISO/IEC 42001:2024 is the recognized substrate for an AI QMS. Even uncertified, demonstrating alignment with its 38 clauses creates a much stronger audit posture than a generic QMS retrofitted to the AI Act. By Q3 2026 the EU Commission's harmonized standards are expected to converge on 42001.

Evidence the auditor expects: a clause-by-clause mapping showing your QMS controls against 42001, along with gaps and remediation timelines.

Article 26 — Deployer Obligations (2 controls)

If you are the deployer (the entity using the AI system in its operations, not the provider that built it), Article 26 binds you separately.

20. Deployer assignment of human oversight

You assign human oversight to natural persons with the necessary competence, training, and authority. They are not assigned this in addition to a full-time job that prevents them from doing it well — Article 26(2) implies adequate resources.

Evidence the auditor expects: the role description, the time allocation, and the training certificate.

21. Operational monitoring and incident reporting

You monitor operation per the provider's instructions, inform the provider of any serious incident, and inform the market surveillance authority under Article 73 (serious incidents) within fifteen days, two days for widespread infringement, and ten days where life is at risk.

Evidence the auditor expects: the monitoring dashboard, the incident register, and the timestamped reports filed.

Article 49 — EU Database Registration (2 controls)

22. Pre-deployment registration in the EU database

Before placing a high-risk AI system on the EU market or putting it into service, the provider registers it in the EU database operated by the Commission under Article 71. This is a public registry and a precondition for market access.

Evidence the auditor expects: the registration confirmation, the assigned identifier, and the maintained metadata.

23. Maintenance of registration data

If the system or its risk classification changes, the database entry is updated. This is not "we registered once".

Evidence the auditor expects: the change history showing each update synchronized to the technical file change log.

Article 71 — Public Database Operations (1 control)

24. Coordination between the database entry and the system in operation

The system identifier in the EU database matches the system identifier in your technical file, your operational logs, your incident reports, and your conformity assessment. A reviewer can trace one system end-to-end without translating between numbering schemes.

Evidence the auditor expects: a trace document mapping all identifiers, and a sample query showing they resolve consistently.

Cross-Cutting — Governance Glue (1 control)

25. Single accountable owner per high-risk system

A named natural person — typically the AI Compliance Officer or, for smaller orgs, the DPO acting as AI Compliance Officer — owns the system end-to-end across articles. They sign the classification, the risk register, the technical file, and the EU Declaration of Conformity. There is no diffuse accountability.

Evidence the auditor expects: the appointment letter, the role description showing AI Act articles in the JD, and the escalation path to the legal representative.

How to Use This Checklist

For self-assessment: Walk the 25 points with the AI compliance officer, product owner, and CISO together. For each point, the answer is binary. Disagreement on whether a point is "done" is a finding. Document it.

For procurement: Send the 25 points as a vendor questionnaire. Vendors that cannot map their feature set to all 25 are not in the modern category — they are documentation tools or GRC retrofits. The buyer's guide (/blog/ai-act-compliance-software-guide) covers vendor selection in detail.

For audit preparation: For each point, generate the evidence today, not the morning of the audit. The evidence-generation drill is itself a control on whether your processes work.

FAQ

What is a high-risk AI system under the EU AI Act?

A high-risk AI system is one that either (a) acts as a safety component in a product subject to EU harmonization legislation (Article 6(1)), or (b) falls within one of eight Annex III domains: biometrics, critical infrastructure, education, employment, essential services (including credit and insurance), law enforcement, migration, and justice. The classification is binary, but the impact is graduated — the higher the consequence on persons, the more stringent the controls.

What are the eight Annex III categories?

(1) Biometric identification and categorization; (2) management and operation of critical infrastructure; (3) education and vocational training; (4) employment, worker management, access to self-employment; (5) access to essential private and public services and benefits, including credit scoring and insurance; (6) law enforcement; (7) migration, asylum, and border control; (8) administration of justice and democratic processes (including elections).

How long do I have to comply?

The Act entered into force on 1 August 2024. The high-risk obligations under Article 6(2) and Annex III become applicable on 2 August 2026. Article 6(1) high-risk systems (safety components in regulated products) follow on 2 August 2027. Article 5 prohibitions applied from 2 February 2025. General-purpose AI obligations applied from 2 August 2025.

What happens if I miss the 2 August 2026 deadline?

Article 99 fines apply: up to €35 million or 7% of global annual turnover for prohibited-practices breaches; up to €15 million or 3% for general non-conformity by providers and deployers; up to €7.5 million or 1.5% for supplying incorrect information to authorities. The fines structure is covered in detail in /blog/ai-act-fines-explained.

Do I need a notified body?

Most Annex III high-risk systems can use internal conformity assessment (self-assessment) per Article 43(2) — you produce the technical file, sign the EU Declaration of Conformity, and proceed. Notified-body assessment is required for biometric identification systems (Article 43(1)) and for AI systems used as safety components in regulated products (Article 43(3)). The conformity-assessment framework article (/blog/ai-conformity-assessment-framework) walks through the procedural steps.

Is ISO/IEC 42001 certification required for high-risk AI?

No, not strictly. The Act does not name 42001. However, harmonized standards adopted under Article 40 are expected to map to 42001, and certification creates a presumption of conformity. Practically, every serious provider is aligning with 42001 because the alternative — building a parallel AI QMS — is more expensive than certification.

Can a deployer be fined even if the provider is non-compliant?

Yes. Article 26 places independent obligations on deployers — assigning human oversight, monitoring, retaining logs at least six months, reporting incidents, performing fundamental rights impact assessments where required (Article 27). A deployer cannot hide behind the provider's failures. Procurement contracts must allocate compliance responsibilities explicitly.

Does the checklist apply to GPAI providers?

GPAI (general-purpose AI) providers have a separate regime under Articles 51–55 — model documentation, copyright policy, downstream cooperation, systemic-risk model controls. If your high-risk system embeds a GPAI model from a third party, you remain the high-risk system provider; the GPAI obligations sit with the model provider. Use the checklist for the high-risk wrapper; rely on the GPAI provider's documentation for the model layer.

What evidence does an auditor actually want?

Three things, every time: (1) the document or record exists; (2) it is current — within the review cadence the policy specifies; (3) it is integrated with adjacent records. A risk register that does not reference the technical file by ID, that does not link to operational logs, that is not signed by an accountable owner, fails the integration test even if the document exists. The 25-point checklist is built to surface the integration gaps, not just the document gaps.

Where does this overlap with GDPR?

Heavily. Article 10 (data governance) requires a GDPR-compliant lawful basis for personal data processing. Article 12 logs are GDPR records of processing. Human oversight under Article 14 satisfies the GDPR Article 22 right not to be subject to solely automated decision-making. Run the AI Act program with the DPO at the table, not in parallel.

Next Steps

1. Print or export this checklist. Walk it with the AI Compliance Officer and the product owner of each high-risk system.
2. For every "no" answer, open a gap in your remediation register with an owner and a target date before 2 August 2026.
3. Map your current tooling against the AI Act Compliance Software Guide. If your platform cannot generate the evidence each control requires, the gap is procurement-shaped.
4. For the operational layer — audit trails specifically — the Audit Trail Implementation Guide gives you the JSONL pattern Knowlee runs in production today.
5. For the regulatory framework view, the EU AI Act Business Guide and the Fines Explained article are the executive briefings to circulate before procurement decisions.

The clock is the regulator's. Twenty-five controls is fewer than you have weeks to 2 August 2026.