The EU AI Act applies to any company placing an AI system on the EU market or whose AI output is used in the EU — including US, Canadian and UK companies with no EU entity. It entered into force on 1 August 2024, with prohibited practices applying from February 2025, general-purpose AI obligations from August 2025, and most high-risk obligations from 2 August 2026. Penalties reach €35 million or 7% of global turnover. GDPR applies in parallel and independently. This is the checklist to work through before you ship.
Key Takeaways
- The AI Act is extraterritorial. No EU office is required for it to apply to you.
- Most business software is not high-risk. The obligations that apply to nearly everyone are transparency, AI literacy, and avoiding prohibited practices.
- AI literacy (Article 4) is a genuine obligation on every provider and deployer, and it is the one teams most often miss entirely.
- The AI Act and GDPR are cumulative, not alternative. Satisfying one does not satisfy the other.
- A DPIA is required for most AI features that process personal data at scale or make automated decisions with significant effects.
- Retrofitting compliance costs roughly three to five times what building it in costs. Classification should happen at the design stage, not before launch.
Step 1: Work Out Whether You Are In Scope
Answer three questions.
Do you place an AI system on the EU market, or is your output used in the EU? If either is true, you are in scope. “AI system” is defined broadly — a machine-based system that infers from input how to generate outputs such as predictions, content, recommendations or decisions. A rules engine is not an AI system. A model that learns is.
Are you a provider or a deployer? A provider develops an AI system or has one developed and places it on the market under its own name. A deployer uses an AI system under its own authority. Obligations differ substantially — providers carry far more. Note that if you significantly modify a third-party system or put your own branding on it, you can become a provider of that system.
Do you also process personal data? If so, GDPR applies in full and separately. The AI Act does not displace it.
Step 2: Classify Your Risk Tier
The AI Act is a risk-tiered regime. Almost all of the compliance burden falls on one tier, so classification is the highest-leverage step.
| Tier | What it covers | Obligation level |
|---|---|---|
| Prohibited | Social scoring, manipulative techniques exploiting vulnerabilities, untargeted facial image scraping, emotion inference in workplaces and schools, most real-time remote biometric identification in public | Banned outright |
| High-risk | AI in recruitment and employment decisions, education access and assessment, creditworthiness, essential private and public services, law enforcement, migration, critical infrastructure, biometric categorisation | Extensive — see Step 3 |
| Limited risk | Chatbots, emotion recognition, deepfakes and synthetic content | Transparency and disclosure |
| Minimal risk | Everything else — recommendation engines, spam filters, most SaaS AI features | Voluntary codes; AI literacy still applies |
The honest reality for most product teams: you are minimal or limited risk. A retrieval-augmented chatbot answering questions about your documentation is not high-risk. An internal tool that summarises support tickets is not high-risk.
But watch for the traps. HR and recruitment features are high-risk — a resume-ranking feature inside an otherwise ordinary SaaS product pulls that product into the high-risk tier. So does credit scoring, and so does AI used to determine access to education or training. If you sell into HR tech, fintech lending or edtech, classify carefully and early.
Step 3: If You Are High-Risk
High-risk obligations began applying on 2 August 2026 for Annex III systems. Providers must have:
- A risk management system operating across the entire lifecycle, not a one-time assessment.
- Data governance covering training, validation and testing datasets — including examination for bias and documented relevance, representativeness and completeness.
- Technical documentation demonstrating conformity, prepared before the system is placed on the market.
- Automatic logging of events over the system’s lifetime, retained for an appropriate period.
- Instructions for use that let deployers understand and operate the system correctly.
- Human oversight designed into the system so a person can intervene, override or halt it.
- Accuracy, robustness and cybersecurity appropriate to the intended purpose, with declared performance metrics.
- A quality management system, conformity assessment, EU declaration of conformity, CE marking, and registration in the EU database.
Deployers of high-risk systems have lighter but real duties: use the system per instructions, assign competent human oversight, monitor operation, retain logs, and — for public bodies and certain private actors — conduct a fundamental rights impact assessment.
This is a serious engineering and documentation programme. Budget for it in the same way you would budget for SOC 2 or ISO 27001.
Step 4: Transparency Duties That Apply to Almost Everyone
Even at minimal risk, three disclosure duties are likely to touch your product:
- Tell people they are talking to an AI. If users interact with an AI system, they must be informed unless it is obvious from context.
- Label synthetic content. AI-generated or manipulated audio, image, video and text must be marked as such in machine-readable form. Deepfakes require clear disclosure.
- Disclose emotion recognition and biometric categorisation to the people subject to it.
These are cheap to implement at design time and awkward to bolt on later.
Step 5: AI Literacy — The Obligation Everyone Misses
Article 4 requires providers and deployers to take measures to ensure a sufficient level of AI literacy among staff and others operating AI systems on their behalf. It applied from 2 February 2025 and it applies regardless of risk tier.
There is no prescribed curriculum, which is precisely why teams ignore it. A defensible programme includes: role-appropriate training on what the systems do and where they fail, documented attendance, guidance on acceptable use, and a refresh cadence. Keep the records — the obligation is on you to demonstrate it.
Step 6: The GDPR Layer
GDPR applies independently and in full. For AI systems, six areas do the most work.
| Requirement | What it means for AI |
|---|---|
| Lawful basis (Art. 6) | You need one for training data and for inference. Legitimate interests requires a documented balancing test. Consent must be specific and withdrawable. |
| Special category data (Art. 9) | Health, biometric, ethnicity, political and similar data need an Article 9 condition on top of Article 6. Explicit consent or a substantial public interest basis. |
| Automated decisions (Art. 22) | Decisions with legal or similarly significant effects made solely by automated means are restricted. You must offer human intervention and an explanation. |
| DPIA (Art. 35) | Required for high-risk processing. Systematic profiling, large-scale special category processing and automated decision-making all trigger it. |
| Data minimisation (Art. 5) | “We might need it later” is not a basis for retaining training data. Define retention and enforce it. |
| Transfers (Ch. V) | Sending personal data to a US-hosted model requires DPF certification or SCCs plus a transfer impact assessment. |
On transfers specifically: most major model providers now offer EU-region processing and zero-retention API options. If you are handling EU personal data, use them. It removes the hardest part of the analysis for the cost of a configuration change.
Beyond the EU: Canada’s PIPEDA and Quebec’s Law 25 impose comparable transparency and automated-decision requirements, and Law 25 carries meaningful penalties. The UK operates its own GDPR regime post-Brexit. A product built to EU standards generally clears all three, which is why we advise clients selling into North America and Europe to design to the strictest applicable standard once rather than three times.
The Practical Checklist
Work through this before launch:
- Determine whether you are a provider or deployer for each AI system
- Classify each system: prohibited, high-risk, limited or minimal
- Confirm no prohibited practices — check emotion inference and biometrics carefully
- Implement AI disclosure in the UI where users interact with AI
- Mark AI-generated content in machine-readable form
- Run and document an AI literacy programme
- Identify the lawful basis for both training and inference
- Complete a DPIA where Article 35 is triggered
- Sign DPAs with every model and infrastructure provider
- Verify a valid transfer mechanism for any non-EU processing
- Document retention periods and enforce them technically
- Implement logging sufficient to explain any individual decision
- Define the human oversight path and who owns it
- Maintain a model inventory with versions, purposes and owners
- Establish an incident and drift monitoring process
How NSDBytes Approaches This
We treat classification as an architecture input, not a legal review at the end. On AI development engagements that touch EU users, our practice is:
- Classify in week one. The risk tier determines the logging, oversight and documentation architecture. Discovering in month six that a feature is high-risk means rebuilding it.
- Build the audit trail into the system, not alongside it. Every inference that affects a person should be reconstructable: inputs, model version, output, and any human override.
- Default to EU-region processing and zero retention for EU personal data, because the configuration cost is trivial compared to the analysis cost of the alternative.
- Document as we build. Technical documentation assembled retrospectively is both more expensive and less accurate.
We are engineers rather than lawyers, and this article is not legal advice — for a formal position you need qualified counsel in the relevant jurisdiction. What we can do is build systems that make the compliance position provable. Our AI consulting engagements usually start with exactly that classification exercise.
Final Thoughts
The AI Act is less alarming than the headlines suggest for most product teams, and more demanding than they expect in a few specific verticals. The cost of getting it wrong is not primarily the fine — it is discovering during an enterprise procurement review that your architecture cannot produce the evidence a buyer requires, and losing the deal while you rebuild.
Classify early, document as you build, and design to the strictest standard you will need. If you are shipping AI into the EU and want the architecture reviewed against these requirements, get in touch.
Related Articles
Frequently Asked Questions
Written by the NSDBytes Team
We are passionate about software development, AI integration, and helping businesses achieve operational excellence through modern technology.
Need something like this built?
We’ve helped 200+ companies ship AI-powered solutions. Let's build your AI product.
