Praesidia gives teams that run AI agents in the EU controls and exportable evidence for the EU AI Act obligations that bear hardest on agents: risk management (Article 9), automatic event logging (Article 12), human oversight (Article 14), deployer duties (Article 26), post-market monitoring (Article 72) and serious-incident reporting (Article 73). It supports your assessment and is not a certification or a conformity assessment: whether an agent is high-risk, and whether you meet the Act, stay your decisions.
This page is for engineering leads, product counsel, and compliance teams whose agents touch people in the European Union, whether as a provider placing a system on the market or as a deployer using one in-house. For each article it summarises the obligation, names the Praesidia capability that bears on it and the plan that includes it, and lists the evidence you can export.
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, with the Commission able to fine GPAI providers since 2 August 2026 (what the AI Office can now do). 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 duties were not deferred and have applied since 2 August 2026. Article 49 registration is not among the provisions the Omnibus deferred, but it attaches to systems classified as high-risk, and the Article 6 classification rules apply to Annex III systems from 2 December 2027; confirm with counsel when your registration duty starts. 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
Each obligation below is a plain-words summary of Regulation (EU) 2024/1689 on EUR-Lex; read the article text, as amended by the Digital Omnibus, before you rely on a summary. Where a capability is not on every plan, its row names the plan; pricing has the full split.
| Requirement / criterion | What Praesidia provides | Evidence you can produce |
|---|---|---|
| Art. 6 and Annexes I/III — Classification of high-risk systems: AI that is, or is a safety component of, a product under the Union laws in Annex I that needs third-party conformity assessment, and systems used in the areas Annex III lists unless they pose no significant risk | Risk classification for each agent, MCP server, or application, on the Advanced tier and Enterprise: Praesidia can suggest a tier, and a person confirms it with the intended purpose, the provision relied on, and a rationale; a confirmed classification is marked for periodic review. The judgment itself is yours; the classification guide walks through it. | Classification record for each entity, with its rationale and the person who confirmed it; the list of agents by tier. |
| Art. 9 — Risk-management system: providers run a documented process across the system's lifecycle that identifies and evaluates foreseeable risks, adopts measures against them, and tests the system | Customer control; Praesidia contributes an inventory of the agents, MCP servers, and applications you register, a risk register, and per-connection guardrails and policies that implement the mitigations you choose. Gap analysis against recognised frameworks is on the Enterprise plan. | Inventory export; mitigation-to-connection mapping (which guardrails and policies address which identified risk); gap-analysis report on Enterprise. |
| Art. 11 and Annex IV — Technical documentation: providers draw it up before the system is placed on the market or put into service and keep it up to date; Annex IV sets its contents | Technical documentation per AI system on the Enterprise plan, organised by the Annex IV sections, with versions, approval, a completeness check, and export. | The approved, versioned document for each AI system; its completeness result; the export. |
| Art. 12 — Record-keeping: high-risk systems technically allow the automatic recording of events (logs) over their lifetime, to help identify risks and substantial modifications, support post-market monitoring, and let deployers monitor operation | Praesidia records the decisions it makes in an append-only, hash-chained audit trail, signed under the default configuration; an operator can turn signing off. Each decision record names the actor, the action and resource, the policy version and rule that applied, and the verdict with its reason code; for MCP tool calls it can include a redacted summary of the arguments. It is a record of decisions, not a transcript of requests and responses: tool-call arguments and results are kept in a separate log that is not signed. External anchoring is optional; without it, removal of the most recent records cannot be detected. Calls that do not pass through Praesidia are not recorded. Signed compliance-bundle export by organization owners and compliance officers, on every plan. | Audit export for the period; verifier result showing records were not altered after signing. |
| Art. 13 — Transparency and information to deployers: providers design high-risk systems so deployers can interpret and use their output, and supply instructions for use | 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: high-risk systems are designed so that people can oversee them while in use, including deciding not to use or to override an output and intervening in or stopping the system | A connection between two agents can hold every task sent over it until a person approves it, and a tool policy can require a person's approval for an MCP tool call: under the enforce governance mode the call is refused and an approval request opened, and the same call made again after approval passes. Single-step approvals are on every plan. Multi-step approval workflows are on the Enterprise plan. A tool policy refuses or holds an MCP tool call only when the organization's agent governance mode is enforce; in observe mode the call still runs, and the refusal or approval it would have required is recorded as a decision. Revocation acts on one agent and leaves the others running: once an agent is revoked, Praesidia refuses its next A2A call and issues it no new tokens, and its MCP tool calls through Praesidia are refused from the next call under the enforce governance mode. An identity token issued to the agent before its revocation stays valid until it expires, by default minutes after issuance, for a service that checks it offline, and model calls made through the gateway with an application key continue to be accepted for up to a minute, until the gateway's next policy refresh refuses the key; requests already running then finish, and a streamed response can last up to 10 minutes. | Approval decisions with approver identity and timestamp; revocation events; approval settings per connection and per tool policy. |
| Art. 15 — Accuracy, robustness, and cybersecurity: high-risk systems perform consistently and resist attempts to manipulate them | 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 vaulted credentials. | Guardrail configuration and decision records; blocked-injection samples for the period; credential rotation history. |
| Art. 17 — Quality-management system: providers put a documented quality-management system in place | Customer control; Praesidia contributes audit records of control-plane changes (not every change is recorded) and an API-first surface so governance changes flow through your documented procedures. | Audit records of control-plane changes (not every change is recorded); API-key scopes showing which automation may alter what. |
| Art. 26(1)–(2) — Deployers use the system according to the provider's instructions for use and assign human oversight to people with the competence, training, and authority it needs | Customer control; Praesidia contributes role-based access so only designated people can approve gated actions or change controls, and an AI-literacy register that shows which members have a current AI-literacy record, both on the Advanced tier and Enterprise. SSO and SCIM tie those roles to your identity provider on the Enterprise plan. | Role assignments; approver list per gate; SCIM lifecycle records; AI-literacy coverage across members. |
| Art. 26(5) — Deployers monitor operation, inform the provider, and suspend use where they have reason to think the system presents a risk | Alert rules on the audit stream and SIEM forwarding, on the Advanced tier and Enterprise; a per-organization metrics export; a view of the OpenTelemetry traces your instrumented agents send to your Praesidia workspace, on the Enterprise plan; and revocation as the suspension action. | Alert history; forwarded events; suspension (revocation) events with operator and time. |
| Art. 26(6) — Deployers keep the logs the system generates, to the extent they control them, for a period suited to its purpose and of at least six months unless other law provides otherwise | Signed bundle export by organization owners and compliance officers, on every plan; 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. 27 — Fundamental-rights impact assessment: before deploying certain high-risk systems, public bodies, private entities providing public services, and deployers of credit-scoring or life and health insurance pricing systems assess the impact on fundamental rights | A fundamental-rights impact assessment per AI system, on the Advanced tier and Enterprise, that moves from draft through review to approval or rejection, with an export. | The decided assessment with its reviewer; the export. |
| Art. 49 and 50 — Registration and transparency (Art. 50 applies from 2 August 2026; confirm the Art. 49 start date with counsel) | Customer control; Praesidia contributes the agent inventory that registration and disclosure statements draw from, and a transparency assessment per AI system on the Advanced tier and Enterprise. | Inventory export with purpose and tier per agent; the transparency assessment for each AI system. |
| Art. 72 — Post-market monitoring: providers run a documented post-market monitoring system, based on a plan, that collects and analyses data on the system's performance over its lifetime | Post-market monitoring per AI system on the Enterprise plan: a monitoring plan with recorded reviews, complaints and corrective actions, and one overview of the system's incidents, drift, performance, and risk changes. A per-organization metrics export adds usage data. | The post-market overview for the reporting period; the monitoring plan and its review record; complaint and corrective-action records. |
| Art. 73 — Serious-incident reporting: providers report a serious incident to the market surveillance authority no later than 15 days after becoming aware of it, sooner for the gravest cases; a deployer that identifies one informs the provider first | Customer control; Praesidia contributes an incident register in which a person other than the reporter reviews the impact assessment before a regulator report can be generated, and an incident timeline; forensic search over MCP tool calls, on the Advanced tier and Enterprise; a chain view that attributes each hop of an agent-to-agent chain, on the Enterprise plan; and a tamper-evident record so the incident timeline can be reconstructed and defended. | The incident record with its reviewed impact assessment and regulator report; 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. Under the default configuration, where records are signed, 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, and the AI agent audit trail guide covers what Articles 12 and 26 ask of a trail. The post on EU AI Act Article 12 logging reads the article's automatic-recording duty against an agent that calls tools, purpose by purpose.
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; risk classification is on the Advanced tier and Enterprise. 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. Tool policies refuse or hold MCP tool calls only under the enforce governance mode, so check which mode your organization runs in.
- 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: Article 50 transparency duties have applied since 2 August 2026; Annex III conformity work has runway to 2 December 2027 and Annex I to 2 August 2028; confirm the Article 49 registration start date with counsel. 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 duties were not deferred and have applied since 2 August 2026; generative systems already on the market before that date have until 2 December 2026 to meet the Article 50(2) marking duty. Article 49 registration is not among the provisions the Omnibus deferred, but it attaches to systems classified as high-risk, and the Article 6 classification rules apply to Annex III systems from 2 December 2027, so confirm with counsel when your registration duty starts. 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 for each agent, MCP server, or application, with the intended purpose and the rationale behind it, on the Advanced tier of the Team plan and on Enterprise; the classification judgment is yours, ideally with counsel.
No. Praesidia records the decisions it makes about activity routed through it in an append-only, hash-chained audit trail, the kind of automatic event log Article 12 asks high-risk systems to support. The trail is signed under the default configuration, and an operator can turn signing off; an offline verifier checks it independently. A signed record shows it was not changed afterwards, not that every relevant event was captured, and calls that do not pass through Praesidia are not recorded. 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.
A connection between two agents can hold every task sent over it until a person approves it, and a tool policy can require a person's approval for an MCP tool call. A tool policy refuses or holds a tool call only when the organization's agent governance mode is enforce; in observe mode the call runs and what it would have met is recorded. Single-step approvals are on every plan, multi-step approval workflows on Enterprise. Revoking one agent refuses its next A2A call and leaves the others running. Which actions need a gate, and who the competent overseer is, are decisions you make and document.
Risk classification, the fundamental-rights impact assessment and the AI-literacy register are on the Advanced tier of the Team plan and on Enterprise. Technical documentation, post-market monitoring, multi-step approval workflows and compliance export are on the Enterprise plan. The audit trail, signed bundle export, decisions, tool policies and single-step approvals are on every plan.
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. Before deploying most high-risk systems, a deployer that is a public body or a private entity providing public services also owes a fundamental-rights impact assessment under Article 27, as does any deployer of a credit-scoring or life and health insurance pricing system. The audit trail, oversight gates, and per-agent classification records on this page are the deployer-side evidence most teams need first.