EU AI Act on August 2: The MLOps Stack for Production Compliance
On August 2, 2026, the core obligations of the EU AI Act become enforceable for AI systems running in production on the European market. The penalty side is concrete: up to €15M or 3% of global annual revenue per breach. For most teams that shipped agents during 2024-2025, the deadline is closing faster than their tooling stack can catch up.
LangChain published a detailed mapping on April 27 between seven articles of the regulation and the MLOps capabilities that cover them. It's a useful framework regardless of vendor choice — because it surfaces what must exist, not who supplies it. Below is the practical reading for a team that has to deliver a compliance proof before summer.
The context and the seven articles that force a tooling change
The AI Act entered force in August 2024 but its obligations roll out in waves. August 2, 2026 triggers articles 9 through 15 and 72, which cover systems classified "high-risk." That category includes a lot of agentic AI use cases currently in production: credit scoring, medical devices, recruitment, biometric identification, critical infrastructure, law enforcement, financial services, healthcare, HR, manufacturing.
If your agent participates in any of those flows — even indirectly — you fall under the high-risk regime. And the calendar isn't forgiving: past August 2, this is a real risk, not a theoretical one. Penalties for serious non-compliance cap at €15M or 3% of global revenue, whichever is higher. For comparison, GDPR caps at €20M or 4% — same order of magnitude, different philosophy.
Here's the short cartography, in the order of the regulation:
- Article 9 — Risk management system: risk managed across the system lifecycle, not a once-a-year audit
- Article 10 — Data governance: bias examination on protected dimensions (race, gender, age, religion, nationality, disability, sexual orientation)
- Article 12 — Automatic logging: timestamped event traces retained over the system lifetime
- Article 13 — Transparency and interpretability: outputs understandable to the user, accuracy levels declared
- Article 14 — Human oversight: capability to intervene, override, interrupt at any time
- Article 15 — Robustness and accuracy: accuracy metrics, adversarial resilience, consistency
- Article 72 — Post-market monitoring: active monitoring after deployment
Seven articles, seven distinct requirements. None of them are settled "at deployment" — they all describe ongoing operational capabilities.
Observability: the foundation for articles 12 and 72
Article 12 explicitly demands an automatic event log across the system lifetime. In practice, that means tracing every LLM call with:
- Textual inputs and outputs
- Millisecond-precision timestamps
- Structured metadata: user, model, version, session context
- Tool-call chain with results
- Intermediate reasoning steps
That's exactly what a tracing tool like LangSmith produces, but also what a custom OpenTelemetry setup can produce. The practical MLOps question: how long do you retain those traces? The answer isn't in the regulation directly, but recital 73 calls for "reasonable" retention aligned with the system's lifetime. LangSmith ships with 14-day base retention and 400-day extended; for a high-risk system, targeting at least 12 months of auditable retention is the prudent reading.
Article 72 (post-market monitoring) layers on top: don't just log, react to drift. Online evaluators on a sample of production traffic, PagerDuty alerting, drift dashboards. It's the same logic as an SRE on a web service, ported to model metrics (perplexity, hallucination rate, PII usage rate).
Continuous evaluation: bias, robustness, hallucinations
Articles 10 and 15 demand active measurement of the system's quality, not just logging. Three families of evaluators become mandatory in practice:
Bias and fairness (Article 10)
Evaluation of behavior on the protected axes named in the regulation. Concretely: a test dataset stratified by race, gender, age, religion, nationality, disability, sexual orientation, and a parity score to publish. If your agent makes credit-scoring or recruitment decisions, this is non-negotiable.
Adversarial robustness (Article 15)
Prompt injection and jailbreak detection. End-to-end tests on malicious payloads. The regulation doesn't give a quantified threshold, but the complete absence of documented defense is indefensible at audit time.
Content safety (Articles 13 and 15)
Hallucination, PII leakage, toxic content, explicit content, code injection. Out-of-the-box evaluators from MLOps platforms cover those axes; writing them by hand is possible but adds weeks to the calendar.
Human oversight: the new operational standard (Article 14)
Article 14 is probably the one that changes existing architectures the most. It requires a capability to intervene, override, and interrupt by a human, with clear understanding of what's happening. For an agent running in a closed loop, that implies:
- A programmable break point at any node of the execution graph
- A human review queue routing sessions for annotation
- An escalation webhook when an evaluator score crosses a threshold
LangGraph's interrupt primitive covers this, as do HumanLayer or the checkpoint pattern of equivalent frameworks. On the implementation side, the subtle angle is exactly-once execution: you must be able to resume exactly where the agent stopped, without replaying side effects (ticket creation, email sending, DB writes). That's the layer that separates a prototype from a compliant system.
What this actually changes for AI teams
Three concrete actions to run before end of June to be ready on August 2:
1. Audit the existing. List your production systems and classify them against the AI Act high-risk grid. Most teams discover that at least one of their agents falls in scope without realising it. Once the list is set, map each system against the seven articles above and identify the gaps. That's a 2-3 day exercise done well.
2. Choose between integrated stack and assembled stack. A platform like LangSmith covers all seven articles in one go; a homegrown stack (OpenTelemetry + Pydantic evals + Argilla for annotation + PagerDuty) takes 3-6 months to reach the same coverage. For teams that haven't started, the May 2026 trade-off leans hard toward the integrated path; for teams that already invested, the question is filling the gaps without rewriting everything.
3. Prepare audit documentation now. The regulation requires a written trace of technical choices: why this evaluator, why this threshold, why this retention policy. That documentation is the evidence in case of inspection. Keeping a technical-decision log on Notion or a versioned git ADR covers the need without extra complexity — provided you start now and not in July.
The AI Act isn't a storm that will pass. It's the operating standard for the next five years in Europe, and probably the baseline that other jurisdictions will calibrate against. The window to bring the stack in order is three months. Past that, the risk turns financial and reputational, no longer just operational.
TL;DR
- August 2, 2026: articles 9-15 and 72 of the AI Act become enforceable; max penalty €15M or 3% of global revenue
- Seven MLOps capabilities to cover: continuous risk mgmt, data governance, automatic logging, transparency, human oversight, robustness, post-prod monitoring
- Observability = foundation: full tracing (inputs/outputs/timestamps/metadata) + min 12 months retention for high-risk systems
- Mandatory evaluators: bias on protected axes, prompt injection, hallucination, PII leakage, toxic content
- Human oversight = interrupt primitive + annotation queue + escalation webhook, with exactly-once execution on resume
- Realistic timeline: audit (D), stack arbitration (D+15), implementation (D+60), audit doc in parallel. All of it before end of June.
Industrialising AI agents? SeedVision offers 3-5 day AI audits and 15-30 day production rollouts. See the packages or book a 30-min call.
Cover photo: Photo by 1981 Digital on Unsplash.