If your AI system reaches EU users, gets embedded in a product sold into the EU, or affects people located there, the AI Act likely applies to you, regardless of where your company is incorporated. The regulation sorts every system into one of four tiers: unacceptable risk (banned outright), high risk (heavy documentation and conformity duties), limited risk (disclosure obligations under Article 50), and minimal risk (no specific duties beyond general product law).
Here's what that means in practice:
- Unacceptable risk: stop building it, full stop. Social scoring and manipulative biometric categorization are banned.
- High risk: budget weeks for risk management, technical documentation, and conformity assessment before launch.
- Limited risk: add a disclosure. A chatbot needs to say it's a chatbot.
- Minimal risk: no new legal duty, but document why you landed here.
Your first move costs nothing: run the official EU AI Act Compliance Checker and save the output. That single PDF becomes your paper trail if a regulator or an investor ever asks how you classified your system.
Key Takeaways
Classifying your AI system under the four risk tiers and documenting that decision is the single most important first step toward EU AI Act compliance.
| Point | Details |
|---|---|
| Classify before you build more | Run the official compliance checker on every distinct AI feature and save the result as your audit trail. |
| High risk means real deliverables | Risk management, Annex IV documentation, conformity assessment, and CE marking are non-negotiable for Annex III systems. |
| Article 50 is cheap to satisfy | A visible UI label or API flag covers most transparency obligations for chatbots and generative content. |
| Re-classify after every meaningful change | Retraining, new datasets, or a new use case can push a system into a different tier. |
| Hanad Kubat builds compliance into the codebase | A fixed-price, two-to-four-week engagement delivers an Annex IV starter, CI tests, and logging as part of the build itself. |
Table of Contents
- How Do You Classify Your System Under the EU AI Act Risk Categories?
- What Do High-Risk Providers Actually Have to Deliver?
- What Does Article 50 Require for Limited-Risk AI Systems?
- When Do EU AI Act Deadlines Take Effect and Who Enforces Them?
- What Should You Do in the First 90 Days?
- Which Official Tools and Resources Should You Bookmark?
- Engineering-First Checklist: Technical Validation Patterns I Use
- How Detailed Should Your Technical Documentation Be?
- What Happens When Your AI System Changes After Launch?
- How Does the AI Act Interact With GDPR and Other Rules?
- Sources
- FAQ
How Do You Classify Your System Under the EU AI Act Risk Categories?
Classification isn't a judgment call you make once and forget. It's a sequence of checks, and you stop at the first one that trips.
- Screen for Article 5 prohibited practices first. If your system does real time biometric categorization in public for law enforcement, social scoring, or manipulative subliminal techniques, you're done. That system can't ship in the EU in its current form.
- Check Annex III for high risk use cases. Recruitment tools, credit scoring, biometric identification, and systems used in education or critical infrastructure sit here. Annex I covers AI embedded as a safety component in regulated products like medical devices or machinery.
- Check Article 50 transparency triggers. Does your system generate synthetic audio, video, image, or text? Does it interact with humans in a way that could be mistaken for a person? If yes, you owe a disclosure even if you're not high risk.
- Write down the decision. Whichever tier you land in, record the reasoning, the date, and who made the call. Auditors and courts care less about the outcome than about whether you can show a documented process behind it.
Most SaaS products doing internal automation, analytics, or content assistance land in limited or minimal risk. Products touching hiring, lending, health triage, or law enforcement almost always land in high risk, and that's where the real work starts.
What Do High-Risk Providers Actually Have to Deliver?
High risk classification isn't a label. It's a stack of concrete deliverables a notified body or market surveillance authority can ask to see, and most of the compliance burden in the Act sits here.
- Risk management system: an ongoing process, not a one-time report, covering identification, evaluation, and mitigation of risks across the system's lifecycle.
- Data governance: documented sourcing, labeling, and bias checks for any training or validation data.
- Technical documentation (Annex IV): intended purpose, design specs, performance metrics, and known limitations, written before the system goes to market and kept current after.
- Logging and record keeping: automatic logs sufficient to reconstruct system behavior after the fact, retained for a defined period.
- Conformity assessment and CE marking: either self-assessment against harmonized standards or, for some categories, third party review by a notified body, followed by the CE mark.
- Post-market monitoring: a live plan for catching drift, failures, and incidents once real users are on the system.
Pro Tip: Write the Annex IV document as a living file in your repo, not a one-off PDF for a lawyer. Update it every time you change the model, the training data, or the intended use, so it never goes stale between audits.
The implementation guidance is explicit that this guidance is interpretive, not legally binding. It clarifies expectations, but the Regulation text and eventual court rulings are what actually settle disputes.
What Does Article 50 Require for Limited-Risk AI Systems?
Article 50 is the quiet workhorse of the Act. It doesn't ban anything or demand a conformity assessment. It just requires you to tell people they're dealing with a machine, and the guidance sets these transparency duties as applying from August 2, 2026.
It hits three categories: chatbots and conversational agents, systems that generate synthetic content (text, image, audio, video), and emotion recognition or biometric categorization systems used outside the prohibited scenarios.
Disclosure has to be practical, not buried in a terms of service page nobody reads:
- In the UI: a visible label at the point of interaction, such as "You're chatting with an AI assistant."
- In the API response: a metadata flag your downstream customers can surface to their own users.
- On generated content: watermarking or embedded metadata identifying it as AI-generated, applied at the time of generation, not retrofitted later.
Skipping this is cheap to fix and expensive to ignore. A single label in your chat widget satisfies most of the obligation.
When Do EU AI Act Deadlines Take Effect and Who Enforces Them?
The Act didn't arrive all at once. It phases in obligations over roughly three years from entry into force, and each wave targets a different category of system.
| Milestone | What kicks in |
|---|---|
| Prohibited practices | Article 5 bans on unacceptable-risk systems |
| Governance structures | AI Office and national authority setup |
| Transparency duties | Article 50 disclosure obligations |
| High-risk obligations | Full Annex III and Annex I compliance |
The AI Office handles general purpose AI models at the EU level, while national market surveillance authorities enforce obligations for most other systems inside their own countries. Fines scale with severity: the most serious violations, like deploying a prohibited practice, carry penalties set out in Article 99 of the Regulation itself, with lower tiers for high-risk noncompliance and for supplying incorrect information to authorities. The dates for specific Annex III and Annex I obligations have shifted before at the political level, so plan against the published schedule but don't treat any single date as immovable.
What Should You Do in the First 90 Days?
Compliance work dies in committee when it has no deadline. Give yourself 90 days and a short list.
- Run the compliance checker in week one. Use the AI Act Compliance Checker on every distinct AI feature, not just your flagship product. Save each result with a timestamp.
- Draft a minimal Annex IV starter by week three. One document per system covering intended purpose, a risk assessment summary, dataset description, test plan, human oversight measures, logging policy, and a post-market monitoring plan. That's enough to show good-faith progress to an auditor without hiring a compliance firm on day one.
- Assign an owner. Someone specific, not "the team," owns updating that document every time the model or its training data changes.
- Build logging and human oversight controls by week six. Structured event logs, a defined retention window, and a documented way for a human to override or halt the system.
- Write and run a small test suite. Cover the performance claims you're actually making publicly. If you say your model is 95% accurate on some task, have a test that checks it.
- Decide on outside help by week eight. If you're in Annex III territory, or your product touches health, credit, or employment decisions, get a notified body assessment and legal counsel involved now, not after a complaint.
Pro Tip: Treat the Annex IV starter the same way you'd treat a README for a new engineer: it should let a stranger understand what the system does and why it's safe within ten minutes of reading.
None of this requires a legal department. It requires someone willing to write things down consistently, which is the part most startups skip.
Which Official Tools and Resources Should You Bookmark?
A handful of sources do most of the work, and everything else is secondary.
- AI Act Compliance Checker: run it per system, save the PDF output as your classification record.
- Regulation (EU) 2024/1689: the actual legal text, including Annex III's high-risk use case list and Annex IV's documentation template.
- Implementation guidance PDF: interpretive detail on Annex IV contents and phased dates, useful but not legally binding on its own.
- AI Crawlability Audit tool: worth running if your Article 50 disclosures or model summaries live on public pages, since a disclosure that bots and auditors can't crawl doesn't do its job.
Bookmark the checker and the Regulation text. Everything else is commentary on those two.
Engineering-First Checklist: Technical Validation Patterns I Use
Compliance documentation is only as good as the evidence behind it. I build reproducible test suites and CI gates that check dataset sanity, distribution shifts, and the specific performance claims a product makes, since those become the evidence Annex IV documentation actually needs.
Practical patterns worth adopting:
- Structured event logs with a defined retention window (six months is a reasonable starting point for most SaaS products).
- CI checks tied to public claims: if a spec sheet says "95% accuracy," a test enforces it before merge.
- Scope frozen at kickoff: decide what the first version documents, build that, then iterate the documentation as the product changes.
I cover the templates for this in more detail in what technical validation means for B2B SaaS and in testing patterns for early-stage teams.
How Detailed Should Your Technical Documentation Be?
Annex IV documentation isn't a marketing brief and it isn't a research paper. It's a working file that has to answer specific questions an auditor or notified body will actually ask.
At minimum, it needs: a clear statement of intended purpose and foreseeable misuse, a description of the system's design choices and architecture, the datasets used for training and validation with their provenance, the performance metrics you're claiming and how they were measured, known limitations and failure modes, the human oversight measures in place, and the logging and post-market monitoring plan.
Format matters less than most founders assume. A single well-organized document, kept in version control alongside your codebase, beats a polished slide deck that nobody updates. Structure it in sections that map directly to the list above, date every revision, and note who approved the change. If your product has multiple distinct AI features, each one gets its own documentation, not a shared paragraph buried in a general product spec.
The most common failure isn't missing detail. It's staleness: a document written once before launch that no longer reflects the model in production six months later. Treat it the way you'd treat an API contract: something that breaks visibly when it's out of sync with reality, and something someone is explicitly responsible for updating. A minimal starter, done honestly and kept current, will outperform an exhaustive document written once and abandoned.
What Happens When Your AI System Changes After Launch?
Models drift. Datasets get retrained. Features get added. None of that pauses your obligations under the Act, and in some cases a significant change can push a system into a different risk tier entirely.
The practical rule: any modification that changes the system's intended purpose, its training data in a way that affects performance, or its use case, triggers a re-evaluation of its classification. A recommendation engine that quietly gets repurposed for credit decisions doesn't stay minimal risk just because nobody updated the paperwork.
Build re-classification into your release process rather than treating it as a one-time event. When a model gets retrained on new data, rerun your classification checklist alongside your usual QA. When a feature that generates content gets extended to a new content type, check whether Article 50 disclosure needs updating too. Version your Annex IV documentation the same way you version your API: each meaningful change gets a note, a date, and a reason.
This is where automated test suites earn their keep. If your CI checks are already validating performance claims and dataset sanity before every deploy, a classification review becomes a checklist item in that same pipeline rather than a separate compliance sprint. Teams that treat compliance as a one-time launch task, rather than an ongoing part of the release cycle, are the ones who get caught flat when a notified body asks for documentation covering a model version from eight months ago that no longer exists.
How Does the AI Act Interact With GDPR and Other Rules?
The AI Act doesn't replace GDPR. It sits alongside it, and the two regimes overlap wherever your system processes personal data, which is most AI products doing anything useful.
GDPR governs how you collect, store, and process personal data, including the legal basis for using it in training. The AI Act governs how the system built on that data behaves, what documentation it needs, and what you disclose to users. A system can be perfectly GDPR compliant on data handling and still fail an AI Act high-risk obligation on technical documentation, and the reverse is just as easy: a well-documented system that mishandles consent for training data is a GDPR problem regardless of its AI Act tier.
The practical friction point is usually data governance. The AI Act's data governance requirement for high-risk systems asks you to document dataset provenance and bias checks, which means you need to know exactly what personal data went into training and under what legal basis. If your GDPR records of processing don't already capture that, you're doing the work twice instead of once.
Human oversight requirements under the AI Act also intersect with GDPR's Article 22, which limits fully automated decisions with legal or significant effects on individuals. If your high-risk system makes automated decisions about people, credit, hiring, insurance, build the human review step so it satisfies both regimes at once, rather than bolting on a second oversight process later. Handle data governance and consent tracking as one workflow, not two parallel compliance efforts.
Why I Integrate Compliance Into Early Builds
The prototype is the spec, and that includes the compliance gaps in it. Rebuilding a system's data handling after launch costs far more than designing it in from the first commit. A fixed scope build makes practical compliance deliverable in weeks, not months. I handle the engineering: logging, documentation, test coverage. For anything touching legal liability directly, like a formal conformity assessment, bring in counsel alongside the build, not instead of it.
— Hanad Kubat
If You Need Help: Fixed-Price Technical Validation and Compliance Builds
Hanad Kubat is the alternative to hiring a compliance consultancy and a separate dev shop for the same problem: one engineer builds the product and the audit trail together, so the documentation actually matches the code that ships. I deliver a fixed-price engagement that includes a minimal Annex IV starter, CI test gates tied to your actual performance claims, and structured logging with a defined retention policy, built directly into your codebase rather than handed over as a disconnected PDF.
The timeline runs two to four weeks, not months, and you own the code from the first commit, no exceptions and no agency overhead sitting between us. Every line is written by me, no juniors, and there are no surprise invoices once scope is frozen at kickoff. If your prototype is stalled around the parts that have to be right, start with the Prototype Audit at a fixed price, credited against the build if you move forward. That audit tells you exactly where compliance work needs to happen before a regulator or an investor asks first.
Sources
- AI Act | Shaping Europe’s digital future
- Implementation guidance for the EU AI Act
- Regulation (EU) 2024/1689 (Artificial Intelligence Act)
- EU AI Act Compliance Checker | AI Act Service Desk
- AI Act High‑Risk AI Systems, Classification and Obligations - RegDossier
FAQ
Does the EU AI Act Apply to US Companies?
Yes, if your system is placed on the EU market or its output affects people located in the EU, regardless of where your company is based. Location of incorporation doesn't exempt you from scope.
Is the EU AI Act Being Enforced Yet?
Enforcement is phasing in on a staggered schedule, with prohibited practices and governance structures active first and high-risk obligations following. The AI Office and national market surveillance authorities share enforcement responsibility depending on the system involved.
Is EU AI Act Compliance Mandatory?
Yes, for any system that falls under the Act's scope. The obligations attached depend entirely on which risk tier your system lands in, from an outright ban to a simple disclosure requirement.
Who Regulates the EU AI Act?
The AI Office regulates general-purpose AI models at the EU level, while individual national market surveillance authorities enforce most other obligations within their own countries.
Does the AI Act Apply to Open-Source AI Models?
Generally no, unless the model is placed on the market as a high-risk system or falls under Article 5 or Article 50 obligations. The open-source exemption is real but narrower than most teams assume.