As the high-risk deadline of December 2, 2027, approaches, questions about the EU AI Act are popping up in MLOps channels and architecture reviews. Many teams running agents in production are now being told by legal to "get compliant." The good news is that much of what the EU AI Act requires aligns with practices you'd want to implement anyway. Here's how to address the most common questions.
This is engineering guidance, not legal advice. Check your classification with counsel.
Q1: We already trace our agents. Are we basically done on logging?
You're on the right track, but there's more to do. Article 12 requires automatic recording of events over the system's lifetime. Tracing model calls, tool calls, and human steps is a solid foundation.
The challenge is ensuring evidence quality. A log is valid only if you can prove its accuracy and completeness. Focus on these four aspects from the start:
- Integrity: Can you prove the records haven't been altered?
- Completeness: Are all decision paths, including failures and retries, captured?
- Retention: Articles 19 and 26(6) require logs to be kept for at least six months if they're under your control as a deployer.
- Privacy: Determine which personal data enters the trace before collection, and align retention with your GDPR obligations.
Retrofitting these features is difficult. Build them in from the beginning.
Q2: Are we the provider or the deployer? Legal keeps asking and we don't know.
This is about roles, not whether you wrote the code. The provider builds or sells the system under their name. The deployer uses it in their business.
You can be the provider without building from scratch. You're considered the provider if you brand a high-risk system, substantially modify it, or use it for a new high-risk purpose. Fine-tuning a hosted model for high-risk use or re-branding a white-labelled application can qualify.
For example, a team selling a CV-screening SaaS tool is the provider and logs all usage. Their customer is the deployer and logs which CVs were sent to the tool. If a candidate requests an explanation, the deployer needs the call logs, and the provider needs logs showing how the decision was reached. Clarify your role with legal before launching, as it determines who owns what evidence.
Q3: Is our agent even high-risk? It just calls an LLM and some tools.
Calling an LLM or using tools doesn't automatically make an agent high-risk. Classification depends on intended purpose and criteria in Article 6, with use cases listed in Annex III. Relevant examples include assessing creditworthiness, pricing life and health insurance, screening job applicants, and certain education decisions.
Watch for exceptions. Annex III excludes AI systems used to detect financial fraud, so a bank's fraud model and its credit-scoring model can fall into different tiers. Assess each use case separately and document your reasoning. That classification record is part of your audit trail.
Q4: Which parts of the Act already apply to us today?
More than you might think. Prohibited practices and AI literacy duties have been in effect since February 2, 2025. AI literacy covers all AI systems, not just high-risk ones, so ensure your team understands the AI they build, run, and use, possibly through role-appropriate training.
Transparency duties under Article 50 apply from August 2, 2026: inform people they're interacting with AI and label AI-generated content. Machine-readable marking for systems already on the market follows on December 2, 2026. Regulated products will face high-risk obligations on August 2, 2028.
The dates have shifted before due to the complexity of the work. Don't rely on another delay.
Q5: Where does data provenance actually come in? We're not storing anything exotic.
Your agent's data resides in four areas: model calls, prompts, uploaded documents, and traces. For each, ask two questions: Which country is it in, and who controls it? The country determines applicable laws. The controller, meaning whoever can read, change, or delete it, decides whether the logs are "under your control" per Articles 19 and 26(6).
Teams often address the first three and overlook traces. But traces are directly regulated by the Act. The Act doesn't specify a vendor, but keeping all four in one jurisdiction simplifies supply-chain questions.
Article 25(4) requires a written agreement between providers and third parties supplying tools, services, components, or models. If you've tracked package provenance for an SBOM, apply the same discipline to your AI stack. A practical split looks like this:
- Application layer: Your agent logic, disclosures, and routing to human reviewers. This is always yours.
- Observability and evaluation: Tracing, evaluations, annotations, and prompt versions, for example with Phoenix or Arize AX.
- Infrastructure and models: Compute, storage, and model hosting, for example EU-only providers such as evroc.
A reasonable path is self-hosted Phoenix on EU infrastructure first, then a self-hosted enterprise Arize AX deployment as you scale.
Q6: How do we show human oversight and handle a "why was I rejected?" request?
Article 14 requires design for effective human oversight. Record the human step as part of the trace: who reviewed, what they saw, and what they decided. Human review recorded as annotations on the same trace as the model and tool calls gives you one reconstructable record instead of three disconnected systems.
For explanations, Article 86 gives people affected by a decision from an Annex III system (except critical infrastructure), with legal or significant adverse effects, the right to obtain "clear and meaningful explanations of the role of the AI system in the decision-making procedure and the main elements of the decision taken." If your traces capture the inputs, tools called, and review outcome, you can answer that from the record rather than by reverse-engineering.
Two related duties are worth building for now. Article 72 requires post-market monitoring, which online evaluations and trace review support. Article 73 requires serious incident reporting, and you shouldn't alter the system in a way that could affect the investigation before informing the authorities. Your team needs a change-freeze procedure before an incident happens, not during one.
Where to go for more
Start with the Act's text: Articles 6, 12, 14, 19, 25, 26, 50, 72, 73, and 86, plus Annex III. For management-system guidance, ISO/IEC 42001 provides an AI Management System structure that aligns with the evidence-keeping these articles imply. ISO/IEC 23894 covers AI risk management, and ISO/IEC 42005 covers AI system impact assessment.
Do one concrete exercise this quarter: pick a single agent, classify it, name your role, and trace where its four data types live. That one-page map will reveal most of your gaps.
