The EU AI Act Is Here. A Practical Readiness Checklist for Engineering Teams
The EU AI Act is the first broad AI regulation with real enforcement behind it, and its obligations are phasing in on a staggered timeline. If your product uses AI and reaches EU users, it applies to you — regardless of where your company is based.
You don't need to become a compliance lawyer. But engineering and product teams do need to understand which risk tier their AI falls into, and have the technical evidence ready to back it up. Here's a practical checklist that translates the regulation into things you can actually check in your system.
Step 1: Figure Out Your Risk Tier
The Act sorts AI systems into tiers, and your obligations follow the tier. Most product teams are in one of three:
- Unacceptable risk (banned): Social scoring, certain biometric surveillance, manipulative systems. If you're here, the answer isn't compliance — it's don't ship it.
- High risk: AI used in areas like hiring, credit, education, essential services, medical devices, and critical infrastructure. This tier carries the heaviest obligations: risk management, data governance, documentation, human oversight, and more.
- Limited / minimal risk: Most general product AI — chatbots, content tools, recommendations. The main obligation here is transparency: telling users they're interacting with AI.
The checklist item: For each AI workflow, which tier does it fall in? Be honest about the high-risk categories — a resume screener or a credit-relevant feature is high-risk even if it feels like a small part of your product.
Step 2: Transparency (Applies to Almost Everyone)
Even minimal-risk systems have to be transparent. Users must know when they're interacting with AI, when content is AI-generated, and — for systems like emotion recognition or biometric categorization — that those are in use.
Checklist:
- Do users know when they're talking to an AI rather than a person?
- Is AI-generated content disclosed as such where required?
- Are these disclosures actually implemented in the product, not just in the terms of service?
Step 3: For High-Risk Systems — The Heavy Obligations
If any workflow is high-risk, the Act expects a specific set of controls. Each maps to something you can assess technically:
Risk management system. An ongoing process to identify and mitigate risks across the AI's lifecycle — not a one-time assessment. *Do we have a repeatable way to assess each high-risk workflow's risks and track mitigation?*
Data governance. Training and input data must be relevant, representative, and checked for bias and errors. *Do we know and control what data feeds these systems?*
Technical documentation. Detailed documentation of how the system works, sufficient for authorities to assess compliance. *Could we produce this today, or would we have to reconstruct it?*
Record-keeping / logging. High-risk systems must automatically log their operation to enable traceability. *Do we log enough to reconstruct what the system did and why?*
Human oversight. The system must be designed so a human can understand, oversee, and if necessary override it. *For consequential decisions, is there a real human check — not a rubber stamp?*
Accuracy, robustness, and cybersecurity. The system must perform consistently and resist manipulation. *Do we have evaluation, resilience, and security controls in place — and evidence of them?*
Step 4: General-Purpose AI Obligations
If you build on top of general-purpose models (which most teams do), some obligations flow to the model providers — but you inherit responsibilities as a deployer. You need to understand the model's capabilities and limitations, and ensure your use stays within them.
Checklist: For each foundation model we use, do we understand its documented limitations, and is our deployment consistent with them?
Step 5: The Evidence Problem
Here's the pattern that runs through the entire Act: almost every obligation requires you to *show* something, not just do it. Risk management, data governance, documentation, logging, human oversight — each is an evidence requirement.
And you can't produce evidence for systems you haven't enumerated. The first practical step toward EU AI Act readiness isn't legal review — it's knowing every AI workflow you run, what each does, what data it touches, and how consequential its decisions are. That inventory tells you your risk tiers, which drives everything else.
The Practical Readiness Checklist
Pulling it together, here's what an engineering team can actually work through:
1. Inventory every AI workflow. You can't tier or document what you haven't listed.
2. Assign a risk tier to each. Flag anything in a high-risk category honestly.
3. Implement transparency across user-facing AI — disclosure that users are interacting with AI.
4. For high-risk workflows, assess against the six control areas: risk management, data governance, documentation, logging, human oversight, and robustness/security.
5. Check foundation-model use against each model's documented limitations.
6. Maintain the evidence continuously — the obligations are ongoing, and your systems change.
None of this requires waiting for a regulator. Most of it is good engineering practice that you now also have a legal reason to document.
Scan your AI workflows to build the inventory that every EU AI Act obligation depends on, and assess each one against the governance, data, and security controls the Act expects. Or learn more about compliance readiness.