EU AI Act and AI agents: deployer duties

Who the deployer is when AI agents call your systems

Your company connects Claude, ChatGPT or Cursor to Salesforce, Jira or Stripe. Employees ask those apps questions. Your company is operating the system, not building it. Anthropic and OpenAI build the model. You decide which apps it reaches, as whom, and with what ability to change data. Under the EU AI Act, that operating role is the "deployer" (Article 3(4)). A deployer is a natural or legal person using an AI system under its authority. The "provider" is the party that develops it or has it developed (Article 3(3)). That split is why EU AI Act and AI agents questions are hard to answer from a vendor's documentation. The vendor's page describes their product. Your duties as deployer attach to your configuration of it.

Nothing here is legal advice. What follows maps the deployer obligations in Article 26 to the access-layer mechanisms that produce evidence for them. It also notes where the access layer cannot help. A lawyer decides your classification and risk category; this post decides what your logs can show.

Before any of this applies, check whether you are in scope at all. Article 26 duties attach to deployers of high-risk AI systems, and high-risk status is not automatic just because an agent touches production data. Article 6 and Annex III define the high-risk categories. They include biometric identification, critical infrastructure, education and vocational training, and employment and worker management. They also cover access to essential private and public services, including creditworthiness and insurance pricing. Law enforcement, migration and asylum, and administration of justice are on the list too. An agent that drafts Jira tickets or summarizes Salesforce records is not in those categories by itself. An agent that screens job applicants, scores creditworthiness or decides who gets a public benefit is. How it is wired up makes no difference. The access layer cannot make this determination. It has no visibility into why a call was made, only that it was made. Classify the use case first; only then does the rest of this post matter.

Timeline: the Act entered into force on 1 August 2024. Prohibited-practice rules (Article 5) have applied since 2 February 2025. General-purpose AI model obligations applied from 2 August 2025. The high-risk dates then moved. Regulation (EU) 2026/1744, the Digital Omnibus on AI, was published in the Official Journal on 24 July 2026. It entered into force on 27 July 2026 (National Law Review, checked November 2026). Annex III high-risk obligations, the Article 26 deployer duties among them, now apply from 2 December 2027. Annex I products follow on 2 August 2028 (Article 26, artificialintelligenceact.eu, checked November 2026). Most Article 50 transparency obligations were not delayed. If your agent falls into an Annex III category, 2 December 2027 is the date these duties become enforceable, not a vague "eventually."

EU AI Act and AI agents: which deployer duties the access layer serves

Two Article 26 duties attach directly to tool calls: log retention (Article 26(6)) and human oversight (Article 26(2), read together with Article 14). Article 50 transparency is a separate duty and is treated on its own below. Read the obligations at EUR-Lex, Regulation (EU) 2024/1689. Map each one to a mechanism you can demonstrate, rather than to a policy sentence.

Logging (Article 26(6)). The Act requires deployers to keep the logs the high-risk system generates automatically, to the extent those logs are under the deployer's control. The period must suit the system's purpose and run to at least six months. Other EU law, data-protection law in particular, can require otherwise. For an agent with tool access, the loggable event is a tool call: a named person, a named app, a named operation, at a time. If your only record is the chat transcript inside the AI client, you have the model's account of events, not the system's. A model's transcript is not what Article 26(6) means by a generated log. A default retention window is a compliance fact here, not a technical detail. A log kept 90 days by default is short of the six-month floor. A deployer in scope of Article 26 has to extend it, rather than assume the vendor default covers the law.

Human oversight (Article 26(2), Article 14). Article 14 requires providers to design high-risk systems so a human can effectively oversee them. Article 26(2) requires deployers to assign human oversight to natural persons who have the necessary competence, training and authority. For tool-calling agents this is less a pause button mid-sentence than three concrete abilities. Decide in advance what the agent may reach. Require a person before a consequential action. Cut access when something goes wrong. Each is configured before the agent runs, not exercised as a reflex afterward. That matters, because Article 14 oversight is about the capability to intervene, not about having intervened.

Transparency (Article 50). Article 50 is not an Article 26 duty, and it applies whether or not a system is high risk. Article 50(1) and 50(2) are provider duties. The duty to tell people they are dealing with an AI system sits with the provider. Marking synthetic content does too (Article 50, artificialintelligenceact.eu, checked November 2026). The deployer duties are 50(3), for emotion recognition and biometric categorisation, and 50(4), for deepfakes and for text published to inform the public. A tool-calling agent used internally against CRM or ticketing data usually triggers neither. The access layer can tell you what the agent did; it cannot satisfy a disclosure duty.

The honest limit: Elaichi does not classify your system under Annex III. It does not write your Article 26 risk assessment, and it does not decide whether your use case is high risk. It records and governs what the AI did in your connected apps. That is one input to a compliance file, not the compliance file.

Enforcing per-person grants across commercial clients

The identity boundary is the first thing a reviewer tests, and it is where most setups fail. This is the infrastructure behind Article 26(2), which has deployers assign human oversight to natural persons who have the necessary competence, training and authority. In Elaichi, every AI client signs in at one address, https://api.elaichi.ai/mcp, over OAuth. OAuth is the sign-in standard where a person approves access to an app without handing over a password. The same address serves every organization. Which organization, which person and which tools a client reaches comes from the grant behind its token, not from the URL.

That matters for one reason. Each person connects their own client and approves their own grant. Every call made with that grant's tokens acts as the person who approved it. A reviewer asking "who did this" gets a name, not a shared bot account that obscures the actor. That is the difference between evidence a regulator can use and evidence that invites follow-up questions.

The practical shape:

• Claude, ChatGPT, Cursor and Microsoft Copilot all point at the same endpoint. There is no per-user, per-team or per-client URL to issue, rotate or forget.
• On Elaichi's consent screen the person picks one organization and ticks the scopes the client asked for. They then grant all their tools or name specific toolboxes.
• A grant's scopes never change after consent. A client that needs more has to be connected again.

Tools that should act as the individual have to run on that individual's own connections. That means their All tools toolbox, or a toolbox built on their own connections. It can also be a template each person stamps with their own connection for each app. A toolbox shared with a team runs each entry on the connection pinned into it, under the authority of whoever pinned it. Confusing those two is the common way a per-person setup quietly becomes one person's credential answering for everyone. That trade-off is worked through in AI agents with employee permissions.

Centralizing the audit log via a governed catalog

Every connected-tool call that reaches execution writes an audit entry, whichever client sent it. The entry records the acting person and the toolbox the call went through. It records the tool's advertised and catalog names, the connector, and the connection it reached. It records the tool's classification (read, write or delete) and whether approval was required and how it was given. It also records the surface the call came from, and the MCP client's id when the surface was MCP. For a list or search it records a result count; on failure it records an error code. What a single entry looks like in practice is shown in reading the audit log to see which tools AI agents call.

Two details decide whether that record survives a reviewer's questions.

First, it covers both kinds of connector under the same rules. Elaichi's catalog holds connectors Elaichi authors and runs itself. It also holds native MCP connectors, where the vendor builds and runs its own MCP server. Elaichi handles sign-in, access and audit in front of that server. Datadog and Linear are native MCP connectors. A team can also bring its own remote MCP server in as a connector on Gold. In each case restrictions and scopes are checked before the call leaves Elaichi. Every call that runs lands in the same log, in the same shape. You are not parsing a different format per vendor.

Second, know what the log does not hold. A call refused before execution writes no entry: a tool a restriction withheld, a missing scope, an unknown tool name, a rate limit. Argument values are not recorded, except the one URL path argument that names the object, kept as the target id. If an agent updates a Salesforce account, the log carries the account id and not the new revenue figure. So the log answers "what did the agent do" well, and "what did the agent try and fail to do" only partially. Say that plainly in a control narrative rather than letting a reviewer discover it.

Every member can read the audit log. With the audit permission they see every event in the organization. Without it they see their own events, plus events on connections they own or can edit. Default retention is 90 days, below the Article 26(6) six-month floor for deployers of high-risk systems. If you are in scope of Article 26, you need the log to outlive the default. Logging destinations come with the Black plan, and Datadog is the destination that delivers. Audit Log Retention: AI Actions at 90 Days vs Seven Years works through that gap in detail.

Meeting human oversight through access-layer controls

Oversight at the access layer is three mechanisms. Each produces a different kind of evidence for the Article 26(2) record of who can intervene and how.

Decide in advance. A restriction rule names whole connectors or single tools. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. To keep a team off a tool, write the rule on their role. Blocks beat allows within a layer. An allow rule turns on an allowlist for its target just by existing. An allow rule that names nothing therefore blocks everything for that target. Restrictions are enforced at every point a member can reach a tool, including when tools are advertised to a client. A restricted tool is not offered for the model to try. An IT team may need to read device records in Jamf but never remove one. It gets exactly that: delete_a_jamf_computer_inventory_by_id is absent from what the client is shown. Precedence is worked through in the MCP restriction resolver decision tree.

Require a person. Over MCP there is no per-call approval from Elaichi. The person's OAuth grant is the approval, chosen on Elaichi's own consent screen for that named client. Any per-call prompt a user sees over MCP is their client's behavior, not Elaichi's. Where a genuine approval card is needed before a write runs, that lives in the Elaichi Agent, which comes with the Black plan. Workflows on Black can also hold a step for a named approver, in the console or in Slack. A payment above a threshold can require one or two approvals from people who did not start the run. Human approval for AI agent actions covers the shapes.

Cut access. Revoking a grant, removing a member or suspending them takes effect on the client's next call, because every MCP request re-reads the grant. Suspending someone in your identity provider over SCIM has the same effect. Their grants are revoked, and their AI client fails on its next call with an invalid token. In Elaichi, revoking a share or disconnecting an account takes effect on the caller's next call. Role, team and restriction changes are different: they take effect in about two minutes. Write that figure into your runbook rather than claiming instant revocation, because a reviewer who tests it will find the difference.

Residency, and what follows the region

An organization's region is chosen when it is created and cannot be changed afterward. For an EU organization, the per-organization data store is pinned to the EU jurisdiction. Its org-scoped requests, including tool calls, execute there, inside that region's gateway. Note that the AI Act itself does not mandate data residency. This section addresses what GDPR cross-border transfer analysis and your own Article 30 record of processing need, not an Article 26 requirement.

Not everything follows the region, and the gap matters in a records-of-processing entry. Every organization's audit trail, whatever its region, is stored in one log instance in the EU, as the privacy policy states. Stored tool files go to an EU bucket for every organization. User accounts, the organization row and API tokens live outside the per-organization store. Requests that do not act inside an organization, such as sign-in and the OAuth token endpoint, run wherever the request lands. The leg-by-leg version is in EU data residency for AI agents. The Article 30 mapping is in GDPR Article 30 AI agent entry.

Where the access layer is not the answer

If your company trains or fine-tunes its own model and ships it, you are closer to the provider side of the Act. The fuller duty set sits in Article 3(3) and Articles 16 to 27. An MCP control plane governs none of that.

Your use case may not fall into an Annex III category. Most back-office agent deployments against CRM, ticketing or payment-ops tools do not. Article 26 may then not apply to you at all. The right move is then confirming that classification in writing, not building an evidence pipeline for duties you do not have.

If nobody has connected an AI client to a production system yet, the right first step is a policy and an inventory, not a purchase. When you don't need an MCP gateway yet makes that case.

And if your agents run entirely inside one vendor's ecosystem with that vendor's own admin controls, start by reading what those controls already record. An access-layer control plane earns its place when several clients reach several apps. You then need one record and one set of rules across all of them, not a per-vendor audit format to reconcile. Start with the catalog at /connectors/ and the governance rollouts at /use-cases/governance/.