The EU AI Act is not a future problem. If you are shipping a model to users in the EU before August 2026, several obligations are already active or will be before your next release cycle ends. The short answer to what you need to decide: risk class first, then documentation and human oversight requirements follow directly from that classification.
Why most scale-up engineering teams are behind
Most Series B teams treat compliance as a legal team problem until a customer's procurement team or a large enterprise buyer sends a questionnaire. At that point the engineering decisions have already been made, the training data pipeline is locked, and the HITL hooks were never built. Retrofitting is expensive and slow.
The Act uses a tiered risk model. Where your system sits in that model determines almost everything else: what you must document, how much human oversight you need, what happens to your data governance requirements, and whether conformity assessment is self-declared or third-party audited.
What is your system's risk classification?
This is the first engineering decision and it is not optional. The Act defines four tiers.
| Risk tier | Examples | Key obligations |
|---|---|---|
| Unacceptable | Social scoring, real-time biometric surveillance in public | Prohibited outright |
| High | Hiring tools, credit scoring, medical device software, critical infrastructure management | Conformity assessment, technical documentation, HITL, logging, registration in EU database |
| Limited | Chatbots, emotion recognition in defined contexts | Transparency obligations (user must know they are talking to AI) |
| Minimal | Spam filters, AI-enabled games | No mandatory obligations beyond GPAI rules if applicable |
The classification is not based on your intent. It is based on the use case and the domain. A recommendation engine sitting inside an HR workflow is high-risk. The same algorithm sitting inside a content discovery product is not. If your product touches hiring, lending, health, education access, critical infrastructure, law enforcement, or border control, assume high-risk until your legal counsel says otherwise.
One thing teams get wrong: the classification applies to the intended purpose of the system, not just the technical implementation. If your model is general-purpose but a high-risk use case is reasonably foreseeable, you may still carry obligations.
What technical documentation do you actually need to produce?
For high-risk systems, the Act requires a technical file. This is not a whitepaper. It has specific contents.
- A description of the system, its intended purpose, and the version
- Design specifications, including the general logic and key design choices
- Training, validation, and testing datasets and methodology
- Accuracy, robustness, and cybersecurity metrics
- Risk management documentation (what risks were identified, what mitigations were applied)
- Post-market monitoring plan
- Conformity declaration
Most teams have pieces of this in scattered Notion pages, model cards, and architecture diagrams. None of it is in one place and none of it follows the structure the Act requires. The engineering work here is not writing documents; it is building the internal systems that generate those documents automatically from your existing model metadata, dataset registries, and experiment tracking.
If you are running MLflow, Weights and Biases, or similar tooling, your experiment logs are the raw material. The gap is usually in dataset provenance (where did this training data come from, when was it collected, how was it labeled) and in the risk management log (what failure modes were considered and what was done about each).
Human-in-the-loop: what the Act actually requires
The phrase 'human oversight' appears throughout the Act but it is not defined as a specific technical pattern. What the Act requires for high-risk systems is that humans are able to understand, monitor, and intervene in the system's outputs. That is an engineering spec, not a policy statement.
In practice that means several things your architecture may not currently support.
First, the system must be designed so a human can override or stop it. If your model output feeds directly into an automated action with no review step, that is a compliance gap for a high-risk classification. The override mechanism must be real, not theoretical.
Second, the system must produce outputs that are interpretable enough for oversight to be meaningful. A confidence score with no explanation is not sufficient for a hiring or credit decision. You do not need full XAI in every case, but you need enough that a reviewer can understand why a decision was reached.
Third, logs must exist. Every decision the system makes must be traceable. Log retention requirements are specific: at minimum, the system must store logs for the period specified by its intended purpose, and for high-risk systems in regulated domains that is typically six months to several years depending on the sector.
Building HITL as an afterthought usually means building a review queue that nobody uses because the UX is bad and the throughput kills the product's value proposition. The teams that do this well design the intervention surface into the product from the start, with clear escalation thresholds and routing logic built into the model serving layer.
Data governance questions you need answers to now
The Act does not replace GDPR. It adds to it. For high-risk systems, your training data must meet quality criteria: it must be relevant, representative, and free of errors and complete enough for the intended purpose. That is a legal standard, not an engineering one, which means you need to be able to demonstrate it.
Concrete questions your engineering team needs to answer before your next model ships:
- Do you have a dataset registry that records the source, collection date, labeling methodology, and known limitations of every training dataset?
- Can you produce that registry on request from a regulator or enterprise buyer?
- If training data included personal data of EU residents, do you have a lawful basis under GDPR and is the processing documented in your Records of Processing Activities?
- Do you have a process for detecting and correcting bias in training data before a model goes to production?
- What is your process when a dataset used in production needs to be removed or corrected after deployment?
The last question is the one most teams cannot answer. If a data source is later found to be unlawfully collected or significantly biased, you need a process to retrain or retire the model quickly. That is an operational and architectural question, not just a legal one.
General purpose AI models and the GPAI rules
If you are building on top of a foundation model rather than training your own, the GPAI provisions apply. Providers of GPAI models with systemic risk (broadly, those trained on more than 10^25 FLOPs) carry the heaviest obligations. If you are a deployer using a third-party GPAI model, your obligations are lighter but not zero.
As a deployer you are responsible for the high-risk classification assessment on your application, for any fine-tuning or additional training you apply, and for ensuring that the transparency requirements of the system you deploy are met. You cannot outsource compliance to your model provider. Their compliance with GPAI rules does not cover your application-level obligations.
Get the technical documentation from your model provider. If they cannot provide it, that is a vendor risk question you need to escalate.
What to do in the next 30 days
You do not need a full compliance programme in place immediately. You need to make a small number of decisions that will have large downstream effects on your architecture and your vendor contracts.
Start with classification. Assign an owner to produce a written risk classification for each AI system you are currently shipping or planning to ship in the next two quarters. Have legal review it. The output is a one-page document per system, not a 40-page report.
Then identify your documentation gaps against the high-risk technical file requirements if any of your systems land in that tier. You will almost certainly find that dataset provenance and the risk management log are the largest gaps.
Then make the HITL call. For each high-risk system, design the override and logging surfaces before the next sprint, not as a later iteration.
If you want a structured way to work through this, we put together the AI Readiness Blueprint specifically for engineering leads at EU and Nordic scale-ups who are working through these decisions. It is a working session, not a slide deck. Details at /ai-engineering.
FAQ
If we are based outside the EU but have EU users, does the Act apply to us?
Yes. The Act applies to providers placing AI systems on the EU market and to deployers using AI systems in the EU, regardless of where the provider is established. If your users are in the EU and your system affects them, you are in scope.
Do we need a third-party audit or can we self-certify?
It depends on the risk class. Most high-risk systems in Annex III (which covers hiring, credit, health, etc.) can use internal conformity assessment with self-declaration for now, but systems in specific regulated sectors such as medical devices or safety components may require notified body involvement. Check against the specific annex that covers your domain.
What is the penalty exposure if we ship without completing this?
Fines for violations of prohibited practices go up to 35 million euros or 7% of global annual turnover, whichever is higher. High-risk system violations go up to 15 million euros or 3% of turnover. Non-compliance with GPAI obligations goes up to 15 million euros or 3%. These are maximums, not typical outcomes, but the exposure is real enough to justify the engineering work now.
The roadmap sample at decipheringlogic.com/roadmap-sample shows how we structure the decisions and documentation for technical leads who are working through exactly this kind of pre-deployment checklist.