AI agents make EU AI Act readiness harder because they are not just models. An agent can retrieve information, decide which tool to call, draft a message, update a record, or trigger a workflow. That means the compliance question is not only what model is used. It is what the system can do in context.
A generic AI Act checklist will miss this distinction. For agents, the operating boundary matters: tools, data access, autonomy, users, oversight, logs, deployment context, and change process. Two systems may use the same model and carry very different risk. A read-only internal assistant is not the same as an agent that can screen applicants, adjust insurance claims, or send instructions to customers.
1. Identify the agent and its actual purpose
Start with the system record. Name the agent, owner, business purpose, users, environment, model provider, connected services, retrieval sources, and action surfaces. Do not settle for broad descriptions such as productivity assistant or customer support AI. The purpose should explain what the agent is allowed to do and where its output goes.
Purpose matters because EU AI Act obligations depend heavily on use. An agent used for internal summarization will not be treated the same as a system used in employment, education, credit, insurance, law enforcement, migration, critical infrastructure, or access to essential services. If the purpose changes, classification may change too.
2. Classify the role and risk category
Record whether your organization is acting as provider, deployer, importer, distributor, or another role for the relevant system. Then classify the agent's risk category and keep the rationale. The rationale is important. It is the difference between saying the system is low risk and showing how that conclusion was reached.
For agents, classification should consider the full workflow. Does the agent influence a decision about a person? Does it produce external-facing content? Does it operate in a regulated area? Can it take actions without human review? Does a person reasonably know they are interacting with AI? Does the agent use general-purpose AI components in a way that creates transparency or downstream obligations?
3. Document data and tool access
Agents often create risk through their connections. A model with no tools can still produce harmful output, but a model with tools can act. Document each tool, permission, data source, and downstream system. Separate read access from write access. Record whether the agent can use personal data, confidential information, financial information, health information, employment data, or customer records.
This is also where security and compliance meet. Data access and tool access should not be approved in isolation. A compliance reviewer needs to know whether the agent can affect users. A security reviewer needs to know whether the agent can move data or call privileged actions. A product owner needs to know what happens when the agent is wrong.
4. Define human oversight where it matters
Human oversight is weak if it only means a person exists somewhere in the process. The reviewer needs context, authority, and a clear point of intervention. For higher-risk agents, define which actions require human approval, what the reviewer sees, how decisions are logged, and how overrides are handled.
The review should happen before high-impact or hard-to-reverse actions. External messages, eligibility decisions, account changes, payments, production operations, and actions involving sensitive data deserve closer control than low-risk drafting or summarization.
5. Keep logs that can support an audit
Logs should make it possible to reconstruct what happened without guessing. Capture the agent ID, user or triggering service, input summary, retrieved sources, tool calls, policy checks, approval decisions, incidents, overrides, and timestamps. Avoid collecting unnecessary sensitive content. Use redaction and retention rules where appropriate.
Good logging supports more than audit. It helps teams detect prompt injection, excessive agency, repeated near misses, policy friction, and changes in behavior after model or prompt updates.
6. Review changes as governance events
An agent's risk can change after launch. New tools, new data sources, expanded user groups, new jurisdictions, different prompts, model changes, or a shift from recommendation to action can all change the control requirements. Treat material changes as governance events, not routine maintenance.
The most defensible AI Act readiness program is not a folder of documents. It is a working system that shows what the agent does, why it was classified that way, what controls apply, and what evidence exists.