EU AI Act: the 2025-2027 obligations timeline and enterprise checklist

The EU AI Act is too often filed under "a lawyer's problem" — an abstract constraint to deal with "later." That framing is a mistake. The regulation already shapes how you design, document, and operate an AI system, including a simple RAG assistant wired to your internal documentation. Teams that build it in early gain an edge: they avoid refactoring under pressure, and they turn compliance into a sales argument.

Here is what the AI Act actually changes, when the obligations land, and an operational checklist for an enterprise AI system.

A risk-based regulation

The AI Act does not regulate "AI" as a block. It classifies uses by the risk they pose to people's rights, and scales obligations accordingly. Four tiers:

• Unacceptable risk — banned practices (general social scoring, subliminal manipulation, certain real-time biometric identification in public spaces).
• High risk — allowed but heavily regulated (AI in recruitment, education, credit, health, critical infrastructure). Technical documentation, human oversight, risk management, data quality.
• Limited risk — transparency obligations only (users must know they are dealing with AI; generated content must be identifiable).
• Minimal risk — no specific obligation (most uses).

The key reflex is not "am I doing AI?" but "which risk tier does each of my uses fall into?" The answer drives everything else.

Some concrete examples you will meet in the enterprise:

• Minimal risk: auto-categorizing inbound tickets, a spell-checker, an article recommender in a knowledge base. No specific AI Act obligation.
• Limited risk: a support chatbot answering customers, an internal assistant summarizing documents, an email-draft generator. Transparency owed, nothing more.
• High risk: a tool that pre-screens applications, a system scoring a loan applicant's creditworthiness, a medical diagnosis aid. The full regime applies.
• Unacceptable risk: a system inferring employees' emotions at work to penalize them, or general social scoring. Simply banned.

The line that matters in practice sits between limited and high risk. That is where most trade-offs happen for a company deploying generative AI.

The real timeline of obligations

The text entered into force on 1 August 2024, but obligations apply in waves:

1. February 2025 — bans (unacceptable-risk practices) and the AI literacy obligation apply: organizations must ensure operators of AI systems have sufficient understanding.
2. August 2025 — obligations for general-purpose AI models (GPAI): training-data transparency, documentation, and stricter requirements for models with "systemic risk."
3. August 2026 — the bulk of obligations for high-risk systems and transparency rules apply.
4. 2027 — additional deadlines for certain high-risk systems embedded in already-regulated products.

In practice: if you ship in 2026, transparency and risk classification are no longer optional. And if one of your uses is high-risk, the clock on technical documentation is already running.

The AI literacy obligation, in force since February 2025, is the most underestimated. A quickly signed charter does not settle it. The people who design, deploy, and use your AI systems must understand their capabilities, limits, and risks. For a RAG assistant, that means your support agents know the AI can "hallucinate," that it does not replace their judgment, and that they must verify sensitive answers. A role-tailored, logged training session is usually enough — but it has to exist and be documented.

Where does an enterprise RAG assistant fall?

An internal assistant answering employee questions from your documentation, or a customer-support copilot, most often falls under limited risk. Your main obligations are transparency: tell users they are talking to an AI, make generated content identifiable, and document what the system does and which data it relies on.

But beware the shifts into high risk. The same RAG stack can change tier by use:

• an assistant that screens CVs or aids hiring decisions → high risk;
• a system involved in employee evaluation, credit decisions, or access to essential services → high risk;
• any biometric identification → reinforced scrutiny or a ban depending on context.

Technology does not decide the risk tier: use does. The same RAG pipeline is "limited risk" for an internal FAQ and "high risk" for screening applications.

Mini-scenario: the support chatbot that stays limited-risk

A SaaS company ships an assistant that answers customers from its product docs and resolved-ticket base. It makes no decision about a person: it informs, routes, and escalates to a human when it does not know. Limited risk. Its obligations fit in a few lines: a "You are chatting with an AI assistant" banner, marking of generated answers, an internal page describing the sources used, and a channel to reach a human agent. Nothing crushing for a serious engineering team.

Mini-scenario: the HR assistant that shifts to high-risk

The same company extends the assistant to HR. First version: it answers staff about leave and health benefits — still limited risk. Then the team adds a function that ranks and scores applications received for a role, on the same RAG pipeline. At that exact moment, the use shifts to high risk: recruitment is explicitly listed among the AI Act's sensitive domains. The obligation perimeter changes entirely: a formal risk-management system, full technical documentation, data quality and representativeness requirements, effective human oversight on every decision, long-term logging, and clear information to candidates. A single feature added to an existing product can move the whole project from one regime to another. Hence the importance of reclassifying risk at every functional change, not just at launch.

Technical documentation, in detail

For a high-risk system, technical documentation is not a formality: it is the auditable proof that you control your system. It must cover, among other things:

• General description: purpose, version, intended scope of use, and explicitly excluded uses.
• Architecture and logic: components (model, vector store, reranker, guardrails), data flows, design choices and their rationale.
• Data: corpus provenance, collection and cleaning methods, quality criteria, freshness measures, handling of known biases.
• Performance and limits: evaluation metrics, conditions under which the system is reliable, where it is not, failure behaviors.
• Risk management: identified risks to people's rights and mitigation measures.
• Human oversight: checkpoints, intervention and contestation paths.
• Cybersecurity and robustness: protection against manipulation (prompt injection, data poisoning), traceability.

Good news for RAG practitioners: much of this content already exists as engineering decisions. Your chunking parameters, your hybrid retrieval strategy, your relevance thresholds, your evaluation golden set — all of that is technical documentation, provided you write it as you go rather than reconstructing it in a panic. Version those decisions in the repo, next to the code, and the documentation almost builds itself.

Concrete transparency notices

Transparency is not a sentence buried in your terms of service. A few formulations that work:

• At the top of a conversation: "You are chatting with an AI assistant. It can be wrong — verify important information. To reach a human, type 'agent'."
• Under a generated answer: "AI-generated answer based on: Product Guide v4, KB-1182." — citing sources serves both legal transparency and user trust.
• On auto-produced content (email, summary, document draft): a visible "Generated by AI" mark, ideally plus a machine-readable mark usable by downstream tools.

The best transparency notice is the one that helps the user while keeping you compliant. Citing your sources ticks the regulatory box and reduces perceived hallucinations.

AI Act and GDPR: two regimes that stack

A common mistake is believing GDPR compliance is enough. The two texts pursue different goals and stack. GDPR protects personal data (legal basis, minimization, data-subject rights, DPIA). The AI Act governs the AI system itself (risk classification, technical documentation, human oversight, data governance, transparency). A RAG assistant may need a GDPR legal basis, a DPIA if warranted, and AI Act transparency — at the same time.

DPIA (GDPR) vs technical documentation (AI Act): who covers what

These two deliverables overlap but are not the same:

• The DPIA focuses on the processing of personal data: which data, for which purpose, on which legal basis, with which risks to data subjects and which safeguards. It answers "does this processing respect people's rights?"
• The AI Act technical documentation focuses on the system: how it is built, how it was evaluated, what its limits are, how humans stay in control. It answers "is this system safe, robust, and controlled?"

On a high-risk RAG project, you run both in parallel and have them cross-reference each other. The DPIA describes the ingested corpus containing personal data and its legal basis; the technical documentation describes how the pipeline processes that corpus, with which guardrails. Running only one leaves you exposed on the other regime.

Operational compliance checklist

1. Inventory — list every AI system, including those hidden inside SaaS tools.
2. Risk classification — for each use, determine the tier and document the reasoning; reclassify at every functional change.
3. Transparency — explicit "you are talking to an AI," generated-content marking.
4. Technical documentation — architecture, data sources, known limits, security measures.
5. Human oversight — checkpoints wherever a decision affects a person.
6. Logging and traceability — keep query logs, retrieved sources, model versions.
7. Data governance — quality, freshness, absence of obvious bias in the corpus.
8. GDPR articulation — check the legal basis for ingested data and run a DPIA where warranted; have it dialogue with the technical documentation.
9. Vendor management — collect compliance documentation from any third-party GPAI model.
10. AI literacy — train and log the training of those who operate the system; tailor the level to their role.

Good news: a well-built RAG assistant (controlled sources, sourced answers, sovereign hosting, logging) already covers most of this checklist through sound engineering.

Compliance as an advantage, not a brake

Read as a list of bans, the AI Act is scary. Read differently, it formalizes what a serious company should already do: know where its data lives, trace its processing, keep a human in the loop for sensitive decisions, and tell users the truth. Classify your uses now, document as you go, and make transparency a product feature. Compliance then becomes a commercial asset, not technical debt. In a procurement process, being able to produce your risk classification, your technical documentation, and your human-oversight policy on request immediately sets you apart from a competitor just discovering the topic. Handled early, compliance is not a cost: it is a barrier to entry you raise against those who neglected it.

Further reading

• GDPR and generative AI: the compliance guide for your RAG projects
• AI sovereignty for the European enterprise: the 2026 strategic guide