A Checklist Only Works in the Right Order
A compliance checklist for the EU AI Act only works if it follows the order the Act itself imposes: what you don’t know you have, you can’t classify, and what you haven’t classified, you can’t apply the right obligations to. That order runs through five steps. First, find every AI system the organisation actually uses, including the ones nobody formally approved. Second, classify each one under Article 6, since the tier it lands in, prohibited, high-risk, limited, or minimal, determines almost everything that follows. Third, work out which role, or roles, the organisation holds for that system: provider, deployer, importer, or distributor. Fourth, apply the specific obligations that attach to that tier and role, which range from nothing at all for a minimal-risk system to the full Article 9 to 17 framework for a high-risk one. Fifth, keep the checklist alive, since classification and role can both change if a system is modified or redeployed. This page is the entry point to that sequence, not a replacement for the deeper guides on each step, which it links to throughout.
Step 1: Build the AI System Inventory
List every AI system in use across the organisation before doing anything else. Cast the net wider than the IT department’s procurement records: shadow AI, tools individual teams adopted without central approval, is consistently where compliance exposure actually hides. Include internally built systems, vendor and SaaS tools with AI features, and generative AI accessed directly by staff.
For each system, capture at minimum what it does, who owns it internally, whether it was built in-house or procured from a vendor, what data it processes, and where it’s actually deployed. A list of tool names without this detail is a directory, not an inventory, and it won’t support the classification step that follows.
Name a single owner for the inventory itself, usually the compliance or legal function working jointly with IT, and pair it with an intake step in procurement and engineering onboarding so new tools get logged and classified before they go live, rather than surfacing for the first time during an audit.
For the full step-by-step process, including how to surface shadow AI and what metadata each inventory entry needs, see AI system inventory: How to build one for EU AI Act compliance.
Step 2: Classify Each System Under Article 6
Every system in the inventory falls into one of four AI risk-tiers, checked in this order:
| Question | If yes | If no, continue |
|---|---|---|
| Is the system’s intended use a prohibited practice under Article 5? | Prohibited. Stop. | Continue |
| Is it a safety component of an Annex I regulated product, or listed in Annex III? | High-risk | Continue |
| Does it interact with people in a way they could mistake for human, or generate synthetic content? | Limited risk: Article 50 transparency applies | Continue |
| None of the above? | Minimal risk | – |
For the full tier-by-tier breakdown, see EU AI Act risk classification: The 4-tier system explained. For what minimal risk actually exempts a system from, and the one obligation that reaches it anyway, see Minimal risk AI under the EU AI Act.
Step 3: Determine the Role for Each System
The same organisation can hold different roles for different systems, and sometimes more than one role for the same system.
| Role | What it means |
|---|---|
| Provider | Develops an AI system, or has one developed, and places it on the market or puts it into service |
| Deployer | Uses an AI system under its own authority in a professional context |
| Importer | Places a non-EU provider’s high-risk AI system on the EU market |
| Distributor | Makes an AI system available on the EU market without being its provider or importer |
A company that builds an internal tool and uses it itself is both provider and deployer for that system. A company that substantially modifies a vendor’s system, or rebrands it, can become the provider of the modified version under Article 25, even though it built none of the original model.
The other two roles show up less often but still matter. A European distributor bringing a non-EU vendor’s high-risk hiring tool into the EU market, without itself being that vendor’s EU-based provider, is acting as an importer, and inherits obligations to verify the vendor’s conformity documentation before the system reaches anyone else. A company that makes that same tool available to its own customers further down the supply chain, without having built or imported it, is a distributor, with its own narrower set of verification duties.
For the full breakdown of obligations by role, see EU AI Act roles: Provider, deployer, importer – Who owes what?
Step 4: Apply the Obligations That Follow
What’s actually required depends entirely on the combination of tier and role from Steps 2 and 3.
| Tier | Provider obligations | Deployer obligations |
|---|---|---|
| Prohibited | None permitted. The system cannot be placed on the market or used. | Same as for provider. Using a prohibited system is itself a violation. |
| High-risk | Risk management, data governance, technical documentation, logging, transparency, human oversight, accuracy/robustness (Articles 9-15), a quality management system (Article 17), conformity assessment, CE marking | Follow the provider’s instructions, assign human oversight, monitor operation, retain logs, complete a Fundamental Rights Impact Assessment where required |
| Limited | Article 50 transparency: disclose AI interaction, label synthetic content | Same disclosure duties where the deployer controls the user-facing interaction |
| Minimal | None specific to the AI Act | None specific to the AI Act |
| All tiers | Article 4 AI literacy for staff operating the system | Article 4 AI literacy for staff operating the system |
For the high-risk framework in full detail, see High-risk AI system requirements: EU AI Act compliance checklist.
Step 5: Keep the Checklist Alive
None of the above is a one-time exercise.
- Reassess classification whenever a system is substantially modified or redeployed for a new purpose. A minimal-risk tool repurposed for recruitment does not carry its old classification with it.
- Monitor high-risk systems on an ongoing basis and retain logs.
- Track the deadlines and timelines that apply to each system, since they are not all the same.
- Know which authority would actually review the system if something went wrong, and what the exposure looks like if it does. See Who enforces the EU AI Act and EU AI Act fines explained.
The practical trigger for most of this is an event, a retraining, a new use case, a vendor update, rather than a calendar date. A lightweight process where engineering, procurement, and the teams actually using a system know to flag those events to whoever owns compliance is what keeps Step 5 running, rather than something revisited only when someone happens to remember.
Who Should Own This Checklist
Ownership sits most naturally with the compliance or legal function, since classification and role decisions carry legal consequences, but it cannot be maintained by that function working alone. IT and procurement supply the raw data on what tools exist and what is being bought. Engineering and data science teams know what is actually being built and retrained. Department heads are usually the only reliable source on tools their own teams adopted without going through procurement at all. This works best as a cross-functional responsibility with one named, accountable owner, not a solo compliance project maintained in isolation.
The Checklist in Full
- Every AI system in use is listed, including vendor tools and systems adopted without central approval
- Each inventory entry records what the system does, who owns it, whether it is built in-house or procured, and what data it processes
- A single owner is named for maintaining the inventory, with an intake process for new tools
- Every system has been run through the Article 6 classification questions and its tier documented
- The role, or roles, the organisation holds for each system has been determined and recorded
- The obligations that follow from each system’s tier and role have been identified and assigned to someone
- A process exists for flagging substantial modifications or redeployments that would change a system’s classification or role
- Monitoring and log retention are actually running for high-risk systems, not just documented as a plan
- The relevant deadlines for each system are tracked against the current Digital Omnibus timeline
- It is clear which authority would review each system, and what the fine exposure looks like, if something went wrong
How Deeploy fits
A checklist built once and filed away stops matching reality the moment a system changes. Each of the five steps above has its own way of going stale, and each fails silently rather than with a warning. An inventory goes stale when a team adopts a new tool without telling anyone. A classification goes stale when a system gets retrained or repurposed and nobody revisits which tier it now falls into. The obligations attached to a system go stale when the monitoring or logging behind them quietly stops running, while the paperwork describing them stays exactly as it was written.
Deeploy addresses each of those failure points directly, rather than treating the checklist as a document to be filled in once. It maintains the system inventory from Step 1 as a living record rather than a point-in-time list, surfacing new and changed systems as they appear. It flags when a system’s actual behaviour in production has drifted from the classification assigned to it in Step 2, which is exactly the kind of change that can push a system into a different risk tier without anyone deciding that on purpose. And for the obligations mapped in Step 4, it keeps the underlying evidence, monitoring logs, drift signals, and documentation, generated continuously rather than assembled retroactively, so Step 5’s instruction to keep the checklist alive is something the infrastructure does automatically rather than something a person has to remember to do on a schedule.
The result is a checklist that reflects the current state of the organisation’s AI at any given moment, not a snapshot from whenever it was last reviewed by hand.
Frequently asked questions
Whenever a system is substantially modified, redeployed for a new purpose, or when a new AI tool is added to the inventory, not on a fixed annual schedule alone. Classification and role can both change with use, not just with time, so revisiting compliance overall is an ongoing process.
What's the minimum obligation that applies even to a low-risk AI system? Article 4 AI literacy. It applies to every provider and deployer of any AI system, regardless of risk tier, and is the one item on this checklist with no exceptions.
Spam filters, recommendation engines, AI-enabled games, and most internal process automation are common examples, provided they are not repurposed into one of the Annex III high-risk domains or embedded in an Annex I regulated product.
Not by that name. The Act doesn't contain an article titled "inventory". It does require organisations to classify each AI system's risk tier, register applicable high-risk systems in the EU database, and monitor deployed systems on an ongoing basis. In practice, none of those obligations are achievable without a maintained inventory, which is why regulators and auditors treat it as a baseline expectation.
Any organisation that develops, deploys, imports, or distributes AI systems that are placed on the EU market or affect people in the EU, regardless of where the organisation is headquartered. A US company using AI to screen EU-based job applicants is in scope. So is a European company using a US-built AI tool for credit decisions.
