The EU AI Act High-Risk Checklist: What Providers and Deployers Must Do
The EU AI Act sorts AI systems by risk, and the heaviest obligations fall on high-risk systems. If one of yours qualifies, "we take AI seriously" is not a compliance position. The Act sets out specific, testable requirements — and they differ depending on whether you are the provider or the deployer. This is a practical checklist to work through.
First, is your system actually high-risk?
High-risk is a defined category, not a vibe. Two routes put a system there:
Annex III use cases — systems used in areas such as biometric identification, critical infrastructure, education, employment, access to essential services, law enforcement, migration, and the administration of justice.
AI embedded in regulated products — systems that are safety components of products already covered by EU product-safety legislation.
If your system is neither, it is likely limited risk (transparency duties, such as telling people they are dealing with a chatbot or that content is AI-generated) or minimal risk (no specific obligations). Prohibited practices — social scoring, certain manipulative or exploitative uses — are banned outright. Getting the tier right is the whole game; everything below assumes you have confirmed high-risk.
Know your role: provider vs deployer
The Act assigns duties by role, and most obligations sit with the provider.
A provider develops an AI system (or has it developed) and places it on the market or puts it into service under its own name. Provider duties sit primarily in Article 16.
A deployer uses an AI system under its authority in the course of its activity. Deployer duties sit primarily in Article 26.
One nuance worth flagging: a deployer can become a provider — for example, by substantially modifying a high-risk system or putting its own name on it. If you fine-tune, rebrand, or materially change a system, check whether you have inherited provider obligations.
Provider checklist (high-risk)
If you are the provider, you are responsible for building compliance into the system:
Risk management system — a continuous, documented process across the lifecycle, not a one-off assessment.
Data governance — training, validation, and test data managed for quality, relevance, and bias.
Technical documentation — the evidence pack demonstrating conformity, kept current.
Record-keeping / logging — automatic logs so events are traceable.
Transparency and instructions for use — enough information for deployers to use the system correctly.
Human oversight — designed-in measures so a person can understand, intervene, and override.
Accuracy, robustness, and cybersecurity — appropriate and consistent performance, and resilience.
Quality management system — the organisational system that holds all of the above together.
Conformity assessment — before going to market (see below).
Registration — high-risk systems registered in the EU database where required.
Post-market monitoring and incident reporting — watch the system in the wild and report serious incidents.
Deployer checklist (high-risk)
If you are the deployer, you are responsible for using the system properly:
Use in line with the instructions provided by the provider.
Assign human oversight to competent people with the authority to act.
Ensure input data is relevant and sufficiently representative for the intended purpose, to the extent you control it.
Monitor operation and suspend use / inform the provider if the system presents a risk or malfunctions.
Keep logs that are under your control.
Inform affected people where required, and preserve their right to explanation for decisions that affect them.
Run a fundamental rights impact assessment where your deployment triggers it (notably certain public-sector and essential-services contexts).
Conformity assessment: two routes
For high-risk systems, conformity assessment is the trigger before market entry, and there are two routes:
Annex VI — internal control, where the provider self-assesses against the requirements. Most Annex III high-risk systems use this route.
Annex VII — involving a notified body, an independent third party, for certain cases.
Article 43 governs which route applies. If you remember one thing: Annex VII means someone independent assessed conformity; Annex VI means the provider self-assessed.
A note on timelines
The Act's obligations phase in over time, and the dates have moved. Prohibited-practice rules applied first, general-purpose AI model obligations followed, and the heavy high-risk obligations have their own — later — dates, some of which have been adjusted. Do not quote a deadline from memory in front of a regulator or a customer; confirm the current applicable date for your specific obligation before you rely on it.
Turning the checklist into evidence
The obligations above are only half the job. The other half is being able to prove you meet them — technical documentation that is current, logs that are actually retained, human-oversight measures that are demonstrable, and a risk management process with a paper trail. That evidence is what a conformity assessment, an auditor, or a regulator will ask to see. The organisations that struggle are those that can describe their controls but cannot show them.
CorpStage helps providers and deployers turn EU AI Act obligations into testable controls and audit-ready evidence. Explore EU AI Act Readiness and AI Assurance Readiness.