This page is for engineering leads, product counsel, and compliance teams that run AI agents which touch people in the European Union, whether as a provider placing a system on the market or as a deployer using one in-house. It maps the controls Praesidia provides to the EU AI Act articles that bear on agent deployments, and it lists the evidence you can export for each.
The Act regulates AI systems by risk tier. Prohibited practices have been banned since February 2025 and general-purpose model duties have applied since August 2025. The Digital Omnibus, in force since 27 July 2026, moved the high-risk obligations: Annex III systems (employment, credit, education, essential services, law enforcement, and similar domains) now fall under them from 2 December 2027, and Annex I systems (AI as a safety component in already-regulated products) from 2 August 2028. Article 50 transparency and Article 49 registration duties were not deferred and have applied since 2 August 2026. The Omnibus explainer covers what moved and what did not.
For agents specifically, the hard articles are 9 (a continuous risk-management system), 12 (automatic event logging), 13 (transparency and instructions to deployers), 14 (effective human oversight), 15 (accuracy, robustness, and cybersecurity), 26 (deployer duties), 72 (post-market monitoring), and 73 (serious-incident reporting). An agent that chains tool calls, delegates to other agents, and acts without a human on each step makes each of those harder than for a single-shot model. The engineering background is in the EU AI Act explained for engineers; the classification method is in how to classify agents by risk tier.
Control mapping
| Requirement / criterion | What Praesidia provides | Evidence you can produce |
|---|---|---|
| Art. 6 and Annexes I/III — Classification of high-risk systems | Per-agent risk-tier classification recorded on the agent, with the ability to reassess as purpose or configuration changes and keep the history. The judgment itself is yours. | Classification record and change history for each agent; the list of agents by tier. |
| Art. 9 — Risk-management system operated across the lifecycle | Customer control; Praesidia contributes a governed inventory of every agent, MCP server, and application, per-connection controls that implement identified mitigations, and gap analysis against recognised frameworks. | Inventory export; mitigation-to-connection mapping (which guardrails and policies address which identified risk); gap-analysis report. |
| Art. 12 — Automatic recording of events over the system's lifetime | An append-only record of every request, response, and policy decision on connections routed through the platform; optional cryptographic tamper-evidence; signed compliance-bundle export. | Audit export for the period; verifier result showing records were not altered after signing. |
| Art. 13 — Transparency and information to deployers | Customer control; Praesidia contributes the declared scope of each agent (connections, permitted tools, guardrails, policies) as a machine-readable statement of intended operation. | Connection and control configuration export per agent, usable as an input to instructions for use. |
| Art. 14 — Human oversight measures, including ability to intervene, interrupt, or stop | Human approval gates before consequential actions; fail-closed block verdicts; single-agent revocation that takes effect on the next request without disturbing other agents; hard budget caps. | Approval decisions with approver identity and timestamp; revocation and cap events; gate configuration per connection. |
| Art. 15 — Accuracy, robustness, and cybersecurity, including resilience to manipulation | Bidirectional guardrails against prompt injection and sensitive-data exfiltration; tool-name restrictions and intent rules that stop the right call against the wrong data; non-human identity with rotation and per-region vaulting. | Guardrail configuration and decision records; blocked-injection samples for the period; credential rotation history. |
| Art. 17 — Quality-management system (providers) | Customer control; Praesidia contributes attributable, logged configuration changes and an API-first surface so governance changes flow through your documented procedures. | Change history for controls; API-key scopes showing which automation may alter what. |
| Art. 26(1)–(2) — Deployers use the system per instructions and assign competent human oversight | Customer control; Praesidia contributes role-based access so only designated people can approve gated actions or change controls, and SSO/SCIM to tie those roles to your identity provider. | Role assignments; approver list per gate; SCIM lifecycle records. |
| Art. 26(5) — Deployers monitor operation and suspend use where risk arises | Alert rules on the audit stream, OpenTelemetry metrics and traces, SIEM forwarding, and revocation as the suspension action. | Alert history; forwarded events; suspension (revocation) events with operator and time. |
| Art. 26(6) — Deployers keep the logs under their control | Signed bundle export by organization owners and compliance officers; configurable per-organization retention; an offline verifier that works without contacting Praesidia. | Exported bundles held in your own systems; verifier output archived alongside them. |
| Art. 49 and 50 — Registration and transparency (in force since 2 August 2026) | Customer control; Praesidia contributes the authoritative agent inventory that registration and disclosure statements draw from. | Inventory export with purpose and tier per agent. |
| Art. 72 — Post-market monitoring by providers | Trend and usage metrics per agent and connection; guardrail hit rates; spend attribution as a proxy for behavioural drift. | Monitoring dashboards and metric exports for the reporting period. |
| Art. 73 — Serious-incident reporting | Customer control; Praesidia contributes forensic search, hop-by-hop attribution across agent-to-agent chains, and a tamper-evident record so the incident timeline can be reconstructed and defended. | Incident-period export with chain views; the verifier result for that export. |
What this mapping is not
This mapping supports your assessment and does not constitute certification or a conformity assessment. Conformity under the Act is established by the provider, through the procedures in Article 43 and, where applicable, a notified body; a platform vendor cannot perform it for you. Nothing here is legal advice on whether a given agent is high-risk, whether you are a provider or a deployer, or what your instructions for use must contain.
The scoping honesty that matters most for Article 12 is coverage. Praesidia records activity on connections routed through it. Agent traffic that bypasses the platform is not visible to it, and your technical documentation should state which paths are covered. If you enable cryptographic signing, the offline verifier confirms that exported records were not altered after signing; it does not prove that every action was captured in the first place. Those limits are written out at /security/verify-your-audit-trail.
Classification, the risk-management system, human-oversight design, instructions for use, and incident-reporting procedures are yours to own. Praesidia gives each of them a place to be recorded, enforced, and evidenced.
Getting started
- Register every agent that touches EU users at /start and record a provisional risk tier for each, using the classification guide. The getting-started guide covers the first entity and connection.
- Put oversight where the Act expects it. Add human approval gates before consequential actions on any agent you have marked high-risk, attach guardrails and policies to its connections, and confirm a denied request shows up in the trail.
- Prove the record. Follow from agent action to audit evidence, export a signed bundle, and verify it offline as described at /security/verify-your-audit-trail. Archive the verifier output with the bundle.
- Re-plan against the Omnibus dates, not the old ones: registration and transparency duties are live now; Annex III conformity work has runway to December 2027. The customer-support agent use case shows the controls above applied to one common deployment.
Common questions
Under the Digital Omnibus, in force since 27 July 2026, the high-risk obligations for Annex III systems apply from 2 December 2027 and for Annex I systems from 2 August 2028. Article 50 transparency and Article 49 registration duties were not deferred and have applied since 2 August 2026. Prohibited practices and general-purpose model obligations were already in force before the Omnibus.
It depends on what they do, not on the technology. Agents that influence employment, credit, education, essential services, law enforcement, or migration decisions are likely Annex III; agents embedded as safety components in regulated products fall under Annex I. Many internal agents are neither. Praesidia lets you record a risk tier per agent and keep the reasoning and history; the classification judgment is yours, ideally with counsel.
It produces the automatic, append-only event record Article 12 describes for the activity routed through it, with cryptographic tamper-evidence you can enable and an offline verifier for independent checking. Coverage of every relevant event, the retention period the Act specifies, and the technical documentation around the logs remain your responsibility to configure and document.
Human approval gates can be placed before consequential agent actions so a person reviews and decides before the action executes; single-agent revocation and fail-closed block verdicts give overseers the ability to interrupt or stop an agent. Which actions require a gate, and who the competent overseer is, are decisions you make and document.
Article 26: using the system per the provider's instructions, assigning human oversight to competent people, monitoring operation, keeping the logs under your control, and informing workers and affected persons where required. The audit trail, oversight gates, and per-agent classification records on this page are the deployer-side evidence most teams need first.