EU AI Act and AI Agents

The EU AI Act and AI agents intersect the moment an autonomous system touches a person in the EU. The Act does not carve out a separate category called "agent." It regulates AI systems by risk and impact, and an agent that plans, calls tools, and takes multi-step actions is an AI system under that framework, with extra obligations layered on for the general-purpose models that often power it.

Scope follows outputs, not headquarters. The Act reaches providers who build or place an agent on the EU market, deployers who put it to work in their operations, and importers or distributors in between. A US enterprise running a Salesforce Agentforce agent against EU customer records is a deployer. A vendor selling an autonomous procurement agent into the EU is a provider. If the output is used in the EU, the geography of your infrastructure does not get you out.

The mechanism matters more than the label. When an agent takes autonomous action, chains tool calls, or affects a person's rights, opportunities, or safety in the EU, obligations attach. Specific article references, transition windows, and thresholds continue to be clarified through delegated acts and guidance, so verify the current text with legal counsel rather than treating any summary as settled.

Who is in scope, and the narrow exemptions

Very few deployers escape entirely. The Act reserves narrow carve-outs for purely personal non-professional use, for military, defense, and national security, for scientific research before market placement, and a limited allowance for open-source components with important exceptions where those components feed high-risk or general-purpose use. Small and mid-sized companies are not exempt. They get proportionate relief such as simplified documentation and access to regulatory sandboxes, but a startup that deploys a high-risk agent still carries the substantive duties.

Classification is a use-case question, not an architecture question. The same underlying model can sit in a minimal-risk internal tool or a high-risk hiring system depending on what the agent is allowed to decide and touch. The Act sorts systems into four tiers.

A working rule for architects: if an agent takes actions that affect a person's employment, finances, health, education, safety, or legal status, treat it as high-risk until legal review says otherwise. The cost of guessing low is asymmetric.

High-risk use cases such as hiring

Recruitment shows how fast an agent climbs the tiers. An agent that screens resumes, ranks candidates, schedules interviews from that ranking, or generates performance summaries a manager relies on is operating in a high-risk domain. That pulls in conformity assessment before deployment, ongoing monitoring, human oversight of decisions, and detailed logging. Any agent with reach into HR systems whose outputs feed employment decisions needs that fuller treatment.

Agents versus chatbots under the Act

The legal line is behavior, not branding. A system that only produces text for a person to act on usually sits at limited risk with a transparency duty. A system that takes actions itself using connected credentials, tools, and integrations carries real-world consequences and is far more likely to trigger high-risk obligations. "It only makes recommendations" does not lower the tier if a human rubber-stamps the output without meaningful review, because the agent is then the effective decision-maker.

Human oversight is the requirement most teams underestimate. The Act expects a person to understand an agent's capabilities and limits, monitor its operation, and step in or stop it. That is not possible when security can see the identity that invoked an agent but not the authority the agent actually carried.

Consider the maker-mode pattern. A business user builds a Copilot agent using their own admin-level Salesforce credentials. Anyone who later invokes that agent runs with the creator's privileges. From an identity and access management view, the invoker has no Salesforce rights at all. From the agent's view, every action inherits admin. The overseer reading IAM policy sees nothing wrong while the agent quietly routes around access controls by design. This is the machine insider: a non-human identity acting with more reach than any person on the org chart was granted.

Meaningful oversight depends on correlating an agent's activity to its effective access, not its vendor config page. Which service account did it assume? Which tables, objects, and actions did it touch inside each system of record? Roughly nine in ten agents are over-permissioned, and agents move on the order of sixteen times more data than a human user, so the gap between theoretical configuration and effective access is where blast radius accumulates. Reviewing static policy with no runtime evidence is ghost chasing. Oversight becomes real only when the evidence shows what happened.

High-risk systems have to produce automatic event logs sufficient to trace their operation. For agents this is harder than it reads. A single request can fan out into dozens of tool calls across several applications and any MCP servers the agent connects to. Native platform logs are siloed and rarely capture the identity correlation an auditor wants.

What a defensible record looks like

A record that stands up to review answers, for every action: which agent ran, on whose behalf, using which credentials and service account, touching what data, with what result. Miss any field and you cannot demonstrate traceability. The common failure is stitching together native audit logs from each platform after the fact, because they seldom tie the invoker's identity to the agent's effective authority. That correlation is precisely the evidence a regulator asks for, and rebuilding it by hand turns every audit into manual archaeology.

Deployers generally must tell people when they are interacting with an AI system unless it is already obvious. For high-risk systems, providers supply instructions covering intended purpose, accuracy expectations, foreseeable misuse, and the oversight measures built in. Content-producing agents raise an added duty to disclose AI-generated material, and in some cases to mark it.

Traceability has to follow the agent outward. When an agent reaches third-party tools or external MCP servers, your records need to reflect those hops. Shadow MCP servers, or tools inside a server that were never disclosed at design time, break the chain of custody and leave gaps that oversight cannot close.

Penalties and enforcement, described generically

The Act attaches real financial exposure, with the heaviest penalties reserved for prohibited practices and high-risk violations, generally scaled against global turnover. Authorities can also order withdrawal or suspension of a non-compliant system and pursue corrective action, and harmed parties may seek civil liability. The exact ceilings and tiers change as guidance matures, so confirm current figures in the Act's text before quoting any number internally. The operational point holds regardless of the amount: exposure grows with the size of the evidence gap.

The Act's obligations translate cleanly into three workstreams a security team can own.

Discover. You cannot govern what you cannot see. Build an inventory of every agent, including shadow agents deployed without review, orphaned agents whose owners have left, and the MCP servers those agents connect to. In practice, a first assessment routinely surfaces hundreds or thousands of agents that no one had catalogued, which is why discovery, not documentation, is usually the real starting cost of compliance.

Govern. Assign an owner to every agent. Classify each against the risk tiers, erring toward high-risk when in doubt. Map effective access for the high-risk ones. Flag toxic combinations, such as a maker-mode agent that holds sensitive data access and is available org-wide. Record the risk assessments and instructions for use as you go, so the technical file writes itself instead of being reconstructed later.

Enforce. Here honesty in the technical documentation matters. Autonomous runtime enforcement, the ability to block an agent mid-action, exists today on a limited set of platforms, currently Claude and Microsoft Copilot. For the broader estate (Agentforce, Snowflake Cortex, ServiceNow and Now Assist, Moveworks, Bedrock, Vertex, n8n and others), treat capability as discover and govern now, with runtime enforcement on the roadmap rather than in production. Obsidian is not an inline gateway sitting in the request path. It runs as a decision engine, an "Intel Inside" model, that surfaces where a deterministic guardrail should fire and lets platforms with native enforcement hooks act on that signal. Describe your own enforcement architecture the same way in your documentation: what blocks today, what only alerts, and what is planned.

How to audit your AI agents against the Act

An audit passes only when each answer rests on evidence, not assumption. Inventory every agent, its owner, purpose, and risk tier. Establish effective access for each: what it can actually reach inside every connected system, not what policy implies. Pull runtime evidence of what each agent has done, on whose behalf, with what data. Show how a human intervenes and whether they can stop the agent in time. Hold the technical file and instructions for use. Check for toxic combinations of exposure and sensitive access. If any of these is theoretical, the audit fails. The runtime truth layer, the connector-free record of what every agent did and what data it touched, is what turns these obligations from paperwork into evidence that generates itself.