The EU AI Act: a practical checklist for agent builders

1. Classify your system : are you even building a "high-risk system"?

• Identify your role under Article 3: provider (you develop/place on market) vs deployer (you use AI) vs both. Obligations differ substantially.
• Run the Article 6(1) test: is the agent a safety component covered by EU harmonisation legislation (Annex I — machinery, medical devices, etc.) requiring third-party conformity assessment?
• Run the Article 6(2) test: does the agent's intended purpose fall within one of the eight Annex III areas: biometrics, critical infrastructure, education, employment, essential/public services (including creditworthiness and insurance pricing), law enforcement, migration/border control, or justice/democratic processes?
• Apply the anti-circumvention test for agentic stacks. Under the Commission's draft guidance, an orchestrator plus its sub-agents and tools is assessed as one system if the combined configuration serves a high-risk purpose. Splitting a workflow across agents does not split the classification.
• Don't rely on human-in-the-loop to declassify. A human reviewer does not, by itself, take a system out of scope — oversight is a separate Article 14 obligation, not an escape route.
• Re-run classification on every material change to tool/MCP configuration. Adding a new connector or tool at runtime can change what the agent is capable of doing and therefore its classification. Build this into your design and change-management process.
• Lock down and version a single, consistent intended purpose statement: instructions for use, marketing copy, and technical documentation must tell the same story and how it's actually used.
• If you conclude "not high-risk," document the reasoning and keep it — misclassification carries penalty exposure, and self-assessments relying on the Article 6(3) filter must be registered.

2. Build Requirements

• Risk management system (Art. 9) continuous and iterative across the whole lifecycle, not a one-off pre-launch exercise. Must cover reasonably foreseeable misuse of the agent (e.g., prompt injection leading to unauthorised tool calls, goal misgeneralisation across multi-step tasks).
• Data governance (Art. 10) provenance, quality, and bias examination for training/fine-tuning data and for retrieval corpora / knowledge bases the agent draws on at inference time.
• Technical documentation (Art. 11 / Annex IV) must describe the full agent stack: orchestrator logic, sub-agents, tool/MCP integrations, memory and state stores, not just the base model.
• Record-keeping / automatic logging (Art. 12) every tool call, decision point, and hand-off across the agent's operating life needs to be traceable. Design logging as a first-class architectural requirement, not an afterthought bolted onto an existing agent.
• Transparency & instructions for use (Art. 13) All deployers must be able to understand capabilities, limitations, tool permissions granted, and required oversight measures.
• Human oversight (Art. 14) design for effective oversight of an autonomous, potentially high-throughput system. Per-action approval is unworkable for agents executing many actions per minute; a tiered model is the practical answer: Pre-deployment scope approval (what the agent is authorised to do), Runtime guardrails / permission boundaries (what it's technically capable of doing), Live monitoring with dashboards to assess how systems are behaving, Asynchronous log review, Emergency stop / kill switch, tested and reachable in practice, not just on paper
• Accuracy, robustness & cybersecurity (Art. 15) explicitly test resilience against prompt injection, tool-response poisoning, and adversarial manipulation across the entire tool-calling surface, not just the model endpoint.

3. Conformity Assessment

• Quality management system (Art. 17) covers the full development and post-market lifecycle.
• Determine your conformity assessment route internal control (Annex VI) vs notified body involvement (Annex VII) — this depends on which Article 6 pathway classified the system.
• CE marking and EU Declaration of Conformity (Art. 47–48) where applicable.
• EU database registration (Art. 49) before placing on market. Note: the Omnibus moves when high-risk obligations bite, but it does not remove the registration requirement itself.
• Fundamental Rights Impact Assessment (Art. 27) a deployer obligation in specific contexts, notably creditworthiness assessment and life/health insurance risk-pricing. No "fraud detection" carve-out applies to insurance risk-pricing systems under the draft guidance.

4. Developer Obligations

• Use the system strictly per the provider's instructions for use.
• Assign competent, trained human oversight not nominal sign-off.
• Monitor operation on an ongoing basis; report serious incidents (Art. 73).
• Coordinate FRIA/DPIA work with existing GDPR processes rather than running parallel, duplicative assessments.