There's a fundamental difference between an AI agent that works in a demo and an agent that passes a regulatory audit. You win the demo with a good model and a careful prompt. You lose the audit, or win it, in the architecture your team chose six months earlier.
On August 2, 2026 the core obligations of the EU AI Act for high-risk systems come into force. By that date — a little over three months from now — agents deployed in banking, insurance, healthcare, pharma, recruitment, credit scoring or education have to meet formal requirements: risk management, technical documentation, automatic logging, human oversight, robustness, cybersecurity and post-market monitoring. Fines for non-compliance reach up to 15 million euros or 3% of annual global turnover, whichever is greater.
Most of the teams we talk to have functional agents deployed in regulated environments. Almost none have designed them thinking about how a specific decision gets reconstructed in front of an auditor. That gap isn't closed with a logging layer added on top. It's closed by designing the agent as an auditable system from the very first spec.
EU AI Act 2026: the compliance window
Sources: Regulation (EU) 2024/1689 · European Commission · AI Act Service Desk
What compliance-first means (and what it doesn't)
Compliance-first AI design is exactly the opposite of retrofit compliance. In retrofit compliance, the team builds the agent, deploys it, someone on the legal side discovers three months later that technical documentation and traceability are missing, and a sprint opens to "add the logs the auditor asks for". At that point, it's already too late: the training data isn't versioned, past decisions can't be reconstructed and the architecture doesn't allow blocking sensitive actions without rewriting the orchestration.
Compliance-first means that every regulatory requirement is translated into an architecture decision before writing the first line of code. What gets logged, at what granularity and where. Which actions require human validation and how circuit breakers are applied. What technical documentation is generated automatically each time a version of the agent is promoted to production. What acceptance criteria an output has to meet to be considered valid — and how it's evidenced that it meets them.
It's the same discipline we apply in DevSecOps: security isn't added at the end, it's designed from the start. With the EU AI Act, the principle extends to agent governance. Governance-first isn't additional overhead; it's the only pattern that scales when the regulator asks.
The 9 EU AI Act requirements that translate into architecture
Chapter III of the EU AI Act defines the requirements for high-risk systems. Read through a software architecture lens, they translate into nine concrete technical decisions a CTO has to make before deploying the agent. They're not nine legal documents: they're nine system components.
A documented, iterative and updated process to identify, assess and mitigate risks throughout the agent's lifecycle. In architecture: a risk register versioned in the repo, reviewed on each release, with mitigation measures traceable to system components.
Training, validation and testing datasets that are relevant, representative, error-free and complete. For agents with retrieval, it includes the indexed corpora. In architecture: traceable data lineage, dataset hashes per version, bias assessment procedures.
A description of the system, its development, tests, performance metrics and mitigation measures. It has to be ready before putting the system on the market. In architecture: docs generated from the code (specs, model cards, ADRs) with a pipeline that updates them on each release.
Automatic recording of events during operation, with a level of detail sufficient to identify risk situations and enable post-market monitoring. In architecture: a structured, immutable event log, with correlation per session and decisions traceable to the prompt, tool calls, retrieved data and final output.
Clear instructions for use: capabilities, limitations, risks, expected performance by usage context. In architecture: a versioned model card, exposed via API, consultable by the human operator at inference time.
Effective mechanisms for a person to understand the output, decide not to use it, intervene or stop the system. In architecture: risk-graduated human-in-the-loop, a kill switch button, a decision-explanation UI, a record of human overrides.
Declared accuracy metrics, resistance to adversarial inputs and prompt injection attacks, fail-safe measures. In architecture: an automatic evaluation suite, continuous red-teaming, anomaly and model-degradation detection.
Written policies, procedures and instructions for the design, verification, validation and change management. In architecture: the CI/CD and repo governance are part of the QMS. Every change to the agent leaves a trace in an audited version-control system.
Active collection of operational data after deployment and notification of serious incidents to the authority within defined deadlines. In architecture: continuous telemetry, a quality-monitoring dashboard, an incident-response runbook with a channel to the competent authority.
A team that builds the agent thinking first about these nine components isn't going to pass the audit by luck. It's going to pass because the agent is designed to be auditable. The one that doesn't — no matter how premium a model it uses — will reach August 2 with the same problem we describe in the quality gap of AI agents in production: observability without governance.
Reference architecture: the 5 layers of an audit-ready agent
The clean way to organize these responsibilities is a five-layer architecture where each layer has an auditor's question associated with it. When the layer exists and is well designed, the question is answered with evidence; when it's missing, the question is answered with nervousness.
Specification layer — specs and acceptance criteria
For each use case, a spec with expected input, expected output, quality criteria, failure modes and actions on exception. Auditor's question: "How do you know the agent fulfills its declared purpose?"
Execution layer — orchestration and guardrails
The engine that runs the agent (Managed Agents, LangGraph, in-house harness) with scope policies applied before each tool call, output validation and automatic circuit breakers. Auditor's question: "What prevents the agent from doing something it shouldn't?"
Evidence layer — structured, immutable logging
Each interaction generates a traceable event: prompt, retrieved context, tool calls, intermediate outputs, final decision, human intervention. Append-only logs, signed and retained for the regulatory period. Auditor's question: "Reconstruct decision X from July 14."
Oversight layer — human oversight and post-market
A UI that lets an operator understand, approve, reject or stop the agent. A quality-monitoring dashboard, an incident-review process and a channel to the regulator. Auditor's question: "How does the human operator know when and how to intervene?"
This architecture isn't a new architecture you have to invent for the EU AI Act. It's the architecture that teams which have already passed audits in regulated sectors (banking, insurance, health) have used for a long time, adapted to the non-deterministic nature of the agent. What changes is that from August it stops being best practice and becomes a legal obligation.
Why Spec-Driven Development is the natural foundation of compliance-first
As we develop in Spec-Driven Development: AI in controlled code, SDD elevates the specification to a source of truth above the code. When the agent is built against a structured spec — constitution, spec templates, prompt playbook, review flow — the nine EU AI Act requirements stop being separate artifacts and become by-products of the development process.
Mapping SDD → EU AI Act requirements
What matters about this mapping isn't that SDD is the only way to comply with the EU AI Act. It's that if you're already applying SDD seriously, you have most of the work done: the methodology's artifacts are the technical documentation Annex IV requires. Teams without that discipline will discover that their "documentation" is a messy Notion and a backlog of unversioned prompts — insufficient material for a conformity assessment.
This pattern is identical to the one we explain in SDD + Agentic Orchestration: the spec is the policy layer, the execution engine is replaceable. With compliance-first, this separation additionally gains a regulatory property — the spec is the artifact the auditor reviews.
Three cases where compliance-first changes the outcome
To bring the conversation down to earth, three concrete scenarios in which an agent designed compliance-first survives the audit and a retrofit one doesn't.
1. Automated credit scoring
An agent that rejects or approves a credit application falls squarely into Annex III, area 5(b). The auditor can ask for the full reconstruction of any decision: which features were used, what weights they had, which alternatives the model evaluated, what human oversight there was before communicating the result to the customer. Without an Evidence layer from day one, that reconstruction isn't possible: standard app logs don't capture tool calls, tokens consumed or prompt versions. With compliance-first, each decision has an event ID and a complete reproducible chain.
2. Insurance claims classification
An agent that categorizes and prioritizes claims — health, auto, home — touches personal data and has direct consequences for the policyholder. The main risk isn't that an isolated categorization is wrong; it's that it systematically harms certain profiles. Art. 10 requires data governance and bias assessment. A retrofit agent discovers the bias when the complaint arrives. A compliance-first agent detects it in the Evidence layer before it escalates, because the continuous evaluation suite is monitoring the distribution of outputs by protected segment.
3. Clinical support in pharma/healthtech
An agent that helps a doctor interpret images, propose dosages or summarize clinical history is high-risk by definition. Human oversight has to be effective, not merely declared. If the doctor approves with a click with no context, oversight fails as a control. In compliance-first, the Oversight layer forces the display of the evidence — which passages of the history, which clinical guidelines, what confidence level — before allowing approval. It makes oversight real and leaves it recorded.
Minimum stack to reach August 2: 8 weeks of honest work
If you have an agent in production in a regulated sector today and you haven't designed it compliance-first, the realistic path isn't to rewrite it entirely. It's to instrument by layers in an order that maximizes the regulatory value of each sprint.
Classify the system (high-risk / limited / minimal) according to Annex III. Open the risk register and document the identified risks. This step is what justifies (or not) all the rest of the effort.
Write the agent's constitution and the per-use-case specs. Declare capabilities, limitations and failure modes. This is the basis of Art. 13 (transparency) and Annex IV (technical documentation).
Add structured, immutable event-level logging: prompt, context, tool calls, output, overrides. Retention for the regulatory period. If this step doesn't exist today, it's the one with the greatest legal impact.
An effective human-oversight UI, kill switch, escalation procedure, channel to the competent authority. Covers Art. 14 and Art. 73.
Internal review with an Annex IV checklist, gap correction, preparation of the technical dossier. Ideally validated by an external auditor before August 2.
Eight well-organized weeks are a realistic plan if the team has the technical judgment to prioritize. It stops being one if the compliance conversation starts in June. That's why the 90 days before the date of application are the window that matters.
The strategic insight: compliance-first isn't an extra cost on top of the agent. It's the only architecture that allows deploying AI agents in Europe with the same speed you deployed them before the EU AI Act. Without it, every new release is an unquantified legal risk.
Two scenarios for August 2
At 105 days from the date of application, every team with agents in regulated sectors has two realistic scenarios ahead. They're not theoretical scenarios: they're the difference between being able to keep delivering value to the business or having to stop to fix the system.
Scenario A · arriving compliance-first. The agents pass the audit without stoppages, the Annex IV dossier is generated automatically from the specs and every new feature is already developed within the regulatory framework. The conversation with legal and with the regulator is sustained with evidence instead of PowerPoints. Operationally, nothing changes: the roadmap goes on.
Scenario B · retrofit compliance in the summer. Between June and August, the team discovers that structured logs are missing, training data has no traceability, human-oversight processes are only lip service and technical documentation is incomplete. Sprints open to patch it. The roadmap gets blocked. In the worst case, the agent is turned off until the dossier is ready — and the business area, which had already integrated the agent into its flow, loses operational capacity. Added to this is the exposure to fines of up to 3% of global turnover if an incident or an inspection arrives before closing the gap.
The cost of reaching scenario A is eight weeks of well-directed technical work. The cost of reaching scenario B is higher in time, in lost roadmap and in legal exposure. That's why the window matters: in the 90 days before the date of application, every week the technical compliance conversation is delayed is a week that later costs twice as much to recover.
The EU AI Act doesn't prohibit deploying AI agents. It requires being able to explain, demonstrate and reconstruct what each one does. That's an architecture problem, not one of formal compliance. And it's exactly the problem Spec-Driven Development has been solving since before it was mandatory.
Primary sources: Regulation (EU) 2024/1689 of the European Parliament and of the Council ("EU AI Act"), articles 5, 6, 9-17, 72-73 and Annexes III-IV; "Implementation Timeline" (AI Act Service Desk, European Commission); "Guidelines for providers of general-purpose AI models" (European Commission Digital Strategy); "EU AI Act Compliance: a technical audit guide for the 2026 deadline" (Raconteur); "The EU AI Act: 6 Steps to Take Before 2 August 2026" (Orrick, 2025); "High-Risk AI Systems Under the EU AI Act" (DLA Piper, ISACA White Paper 2024).
Further reading: SDD + Agentic Orchestration | Spec-Driven Development: AI in controlled code | AI agents in production: the quality gap | DevSecOps: security integrated from the start
onext methodology: onext AI-Accelerated Development integrates compliance-first AI design into the SDD methodology with which onext's AI Centers of Excellence build agents for regulated sectors: fintech, insurance, pharma and healthtech. Specs, evidence layer and oversight layer as part of the delivery flow — not as a separate compliance project. Without stopping deliveries.
Jordi García is Tech Lead at onext. He works on bringing AI into governed production across development and product teams —with Spec-Driven Development, context engineering and human verification at every step— and authors onext's technical insights on the method, quality and cost of applied AI.
LinkedIn →