The EU AI Act in production: a build checklist for engineering teams

How do we make the AI we ship in the EU AI Act compliant?

Start by classifying every AI system you ship by its risk tier, then attach the obligations that tier requires before the feature reaches users. Most teams fail compliance not because the rules are exotic, but because they never wrote down which tier a feature falls into, who is accountable for it, and where the audit trail lives. The EU AI Act (Regulation (EU) 2024/1689) is built around those tiers, and almost every engineering obligation follows from getting the classification right first.

This is a build checklist, not legal advice — and it reflects how we approach shipping AI products in the EU at TechRevati, grounded in production work on retrieval and agent systems.

What are the EU AI Act risk tiers, and what does each one oblige?

The Act sorts AI systems into four broad categories. The higher the tier, the heavier the duty.

| Tier | Examples | Core obligation | | --- | --- | --- | | Prohibited | Social scoring, manipulative or exploitative systems, certain biometric categorisation | Do not build or deploy. Full stop. | | High-risk | AI used in hiring, credit, education, critical infrastructure, medical devices, and similar consequential domains | Risk management, data governance, technical documentation, logging, human oversight, accuracy/robustness, conformity assessment | | Limited-risk (transparency) | Chatbots, AI-generated or AI-manipulated content (synthetic text, image, audio, video) | Disclose that the user is interacting with AI; label synthetic content | | Minimal-risk | Spam filters, recommendation widgets, most internal tooling | No specific obligations beyond existing law; voluntary good practice encouraged |

Two practical notes. First, "high-risk" is defined mostly by use case and context, not by how clever the model is — a simple classifier deciding who gets a loan is high-risk; a powerful model summarising your own notes usually is not. Second, when in doubt, classify up and document why.

What does "high-risk" actually require from an engineering team?

A high-risk system owes a defined package of controls. The ones that land on engineering's plate:

• Risk management system — a documented, ongoing process to identify and mitigate foreseeable risks across the lifecycle, not a one-time sign-off.
• Data governance — training, validation, and test data must be relevant and, as far as feasible, accurate and representative; document provenance and known gaps.
• Technical documentation — a maintained record of the system's design, intended purpose, and the controls above, kept current as you ship.
• Logging and traceability — automatic recording of events over the system's lifetime so behaviour can be reconstructed after the fact.
• Human oversight — a real person can understand, monitor, and intervene — including a stop/override path.
• Accuracy, robustness, and cybersecurity — appropriate to the use case, with the limitations stated honestly.

Conformity assessment and registration are typically the provider's responsibility before market entry — but engineering produces most of the evidence those steps depend on.

What about GPAI and foundation models?

GPAI means general-purpose AI — a foundation model that can be adapted to many tasks (the large language and multimodal models most teams now build on). The Act sets duties for the providers of these models, distinct from the duties on you as a deployer building a product on top.

GPAI providers are expected to maintain technical documentation, publish a summary of the content used for training, and put a policy in place to respect EU copyright law. Models judged to carry systemic risk — the largest, most capable ones — carry heavier duties, including model evaluation, adversarial testing, and incident reporting.

For most product teams the takeaway is narrower: you are usually a deployer, not a GPAI provider. Pick a model whose provider meets these duties, record which model and version you depend on, and layer your own use-case controls on top. The moment you substantially fine-tune or rebrand a base model as your own, re-check whether provider duties now attach to you.

How does this overlap with GDPR?

Heavily — and you can reuse most of the work. The AI Act governs the system; GDPR governs the personal data flowing through it. If your AI processes personal data, both apply at once.

• A DPIA (Data Protection Impact Assessment) under GDPR and the Act's risk-management documentation cover much of the same ground — write them to reference each other rather than duplicate effort.
• Data minimisation is a GDPR principle that also satisfies the Act's data-governance expectations: don't ingest fields you don't need, and don't retain logs longer than you can justify.
• Lawful basis, purpose limitation, and data-subject rights still apply to training data, prompts, and outputs. Retrieval is a common trap: indexing a document does not grant a new lawful basis to surface it.

The build checklist

Run this against any AI feature before it ships:

1. Classify the system by risk tier and record the rationale beside the code. Re-run it when the use case changes.
2. Name an accountable owner for the compliance posture — a person, not a committee.
3. Map your data flows — what personal data enters, where it lives, how long it's retained, and the lawful basis for each.
4. Implement structured, tamper-evident logging of inputs, model/version, key decisions, and outputs, with defensible retention.
5. Build a human-in-the-loop path for any consequential decision: review, override, stop.
6. Pin and record model provenance — model, version, provider — and confirm the provider meets its GPAI duties.
7. Ship the transparency notices — tell users when they're talking to AI; label AI-generated or AI-manipulated content.
8. Write the technical documentation as you build, under version control beside the code.
9. State limitations honestly — accuracy bounds, known failure modes, out-of-scope uses.
10. Schedule a re-review cadence so classification and controls keep pace with the product.

When does the EU AI Act apply?

The Act is being phased in over several years (roughly 2024 through 2027), not switched on all at once. Prohibitions on unacceptable-risk systems took effect earliest, GPAI and governance obligations follow, and the full high-risk regime arrives last. Exact dates and transition periods depend on the category — confirm the current deadline for your tier against the official text or counsel rather than a blog post, because the timeline is the part most likely to have moved since this was written.

FAQ

Is my chatbot high-risk under the EU AI Act? Usually not by default. A customer-support or assistant chatbot typically falls under limited-risk transparency rules — you must tell users they're interacting with AI. It only becomes high-risk if it's used in a consequential domain the Act lists (for example, making or materially influencing hiring, credit, or safety decisions).

Do I have to label AI-generated content? Yes, where it applies. Providers and deployers of systems that generate or manipulate synthetic text, image, audio, or video are expected to mark that content as AI-generated and disclose manipulation, so people aren't deceived about what they're seeing.

We only use a third-party model via API — are we off the hook? No. You're a deployer, which carries its own duties: transparency, human oversight, and your use-case controls. The GPAI provider's duties don't cover how your product behaves in your hands.

Does AI Act compliance replace GDPR? No — they run in parallel. If your system touches personal data, GDPR still applies in full. Treat the Act's documentation and your DPIA as complementary, and reuse the evidence across both.

How an EU-sovereign, audit-ready deployment makes this easier

Several obligations get noticeably lighter when the deployment is designed for them from day one. Keeping data and inference inside the EU — for instance, running on Mistral AI models with a Qdrant vector store under EU data residency — simplifies the GDPR overlap and the data-governance story, because you aren't reasoning about cross-border transfers on top of everything else. Structured logging, pinned model provenance, and a built-in human-oversight path turn the checklist above from paperwork into properties of the system. US-hosted models stay a valid option for many workloads; the point is to choose deliberately and keep the audit trail either way.

That audit-ready posture is how we build AI at TechRevati: classify first, log what matters, keep a human in the loop, and make the compliance evidence a by-product of good engineering rather than a scramble before launch.