The AI Act does not create a single legal category called an “AI agent”. Obligations depend on the organisation's role — provider, deployer, importer or distributor — on the system's intended purpose, and on the risk level of the system the agent is part of. Agentic architecture does raise the practical bar, though: more autonomy, tools, memory and capacity to act demand better inventories, limits, logs, oversight and security.
The first obligation is to classify the use case
Calling an application an “agent” does not determine its legal regime. What matters is what it actually does: whether it recommends, decides, executes actions, interacts with people or controls a process. Where it is used matters too. An agent that summarises internal documentation is not assessed the same way as one that screens job applications, prioritises patients or intervenes in an essential service.
Classification must answer these questions, in order:
- Does the solution fit the Regulation's definition of an AI system?
- Does a prohibited practice apply to this specific use?
- Is the system high-risk because of its product or one of the areas in Annex III?
- Do the transparency obligations in Article 50 apply?
- Is the organisation a provider or a deployer, or has its role changed by modifying the system?
- Is a general-purpose model involved, and what obligations fall to its provider?
- What other rules still apply: GDPR, consumer law, employment law, professional secrecy, cybersecurity or sector-specific regulation?
The result is recorded per system and version. “We use AI” is not an adequate inventory.
Roles: who has to do what
A company that buys an agent is usually the deployer, but it can become a provider if it markets the solution under its own name, makes a substantial modification, or changes its intended purpose in circumstances covered by the Regulation. Contractual role assignment cannot contradict operational reality.
| Role | Typical control | Main evidence |
|---|---|---|
| Provider | Designs or places the system on the market | Risk management, data, documentation, records, conformity and monitoring |
| Deployer | Uses the system under its authority | Use in line with instructions, oversight, monitoring, logs and impact |
| Importer | Places a third-country system on the market | Required checks and documentation |
| Distributor | Makes it available in the supply chain | Checks and cooperation |
In an architecture with a model, a platform, an integrator, tools and an end customer, several actors can be involved. A map should show who controls purpose, data, prompts, permissions, updates, incidents and withdrawal.
Timeline and regulatory caution
Regulation (EU) 2024/1689 entered into force in 2024 and applies on a staggered basis. The prohibitions and AI literacy obligations began to apply on 2 February 2025; the rules on general-purpose models, among others, from 2 August 2025; and a substantial part of the framework is anchored to 2 August 2026, with further provisions applying later.
The timeline must be checked against the text in force and any officially published amendment. The project should not be built on announcements, legislative proposals or commercial summaries. Even if a date changes, inventory, literacy, security, traceability and governance remain necessary controls.
Technical obligations for high-risk systems
When an agent is part of a high-risk system, the provider must put in place requirements such as continuous risk management, data governance, technical documentation, record-keeping, information for the deployer, human oversight, accuracy, robustness and cybersecurity.
Risk management throughout the lifecycle
The file must identify known and foreseeable risks, including reasonably foreseeable uses. For agents, this includes goal drift, tool misuse, chained actions, excessive credentials, instructions embedded in documents, contaminated memory and third-party dependency.
For each risk, document the scenario, the people or assets affected, severity, probability, measures, testing and residual risk. The assessment is updated whenever the model, tool, permission, data, purpose or environment changes.
Data and knowledge
Where data is used for training, validation or testing, appropriate governance and quality practices must apply. In RAG set-ups, documents, indexes and permissions must also be governed even when the model itself is not retrained.
The inventory should record provenance, lawfulness, representativeness, quality, freshness and limitations. Retrieved passages need traceability back to the source. The agent must not be allowed to promote its own output to “validated memory” without control.
Documentation and logs
Documentation must make it possible to understand purpose, architecture, dependencies, capabilities, limitations and controls. Logs must allow decisions and actions to be reconstructed without indiscriminately storing personal data.
A useful trace includes:
- System identifier and version.
- Model, prompt and policy applied.
- Data or sources retrieved.
- Tools and arguments used.
- Result and action executed.
- Human approval or intervention.
- Errors, retries, cost and latency.
Human oversight
Oversight cannot be reduced to a button. The person involved must understand the system's capabilities and limits, detect anomalies, interpret the output, avoid automatic reliance, and be able to ignore, stop or reverse it.
High-impact actions must show sources, uncertainty, the data affected and the consequences. If the volume of alerts makes review unworkable, the design does not provide effective oversight.
Accuracy, robustness and cybersecurity
Thresholds are defined per use case. Normal inputs, edge cases, attacks, tool failure, version changes and adverse conditions must all be tested. For critical actions, error classes are defined with zero tolerance.
Cybersecurity covers direct and indirect prompt injection, memory poisoning, identity abuse, malicious tools, data extraction and unexpected execution. Deterministic controls must sit outside the model.
Deployer obligations
For high-risk systems, Article 26 requires using the system in line with its instructions, assigning oversight to competent people, controlling input data that is under the deployer's control, and monitoring its operation. If a serious risk or incident is detected, the planned communications and measures must be triggered, including suspension where warranted.
The deployer needs an operational file covering:
- Authorised purpose and prohibited uses.
- Owners and supervising staff.
- Training and competence.
- Internal instructions.
- Permitted data and sources.
- Monitoring, alerts and incidents.
- Record retention.
- Impact assessment where applicable.
- Review of providers and changes.
Provider conformity does not legitimise every use a customer makes of the system. Changing the population, the decision or the level of autonomy can change the risks and the obligations.
Transparency and contact with people
When a person interacts with an AI system, Article 50 sets out information obligations in the cases it covers, unless this is obvious from the circumstances. There are also rules for synthetic or manipulated content in certain cases.
In a customer-facing agent, this information must appear at the start of the interaction and explain how to reach a person. Burying it in the privacy policy is not enough. If the agent takes an action with consequences, its role, limits and the route for review must be communicated.
AI literacy
Article 4 requires taking measures to ensure a sufficient level of AI literacy among staff and other people who operate systems on the organisation's behalf, taking into account their knowledge, experience, context and the people affected.
A useful programme is designed by role:
| Role | Minimum competence |
|---|---|
| Management | Risk, responsibilities and acceptance decisions |
| Product/process | Purpose, limits, impact and oversight |
| Development | Assessment, security, data and logs |
| Users | Intended use, verification and escalation |
| Privacy/compliance | Classification, rights and evidence |
| Support | Incidents, withdrawal and communication |
Evidence includes the curriculum, attendance, assessment and practical application — not just a general video.
Control architecture for agents
- Own identity: never a shared admin account.
- Minimum permission: by tool, data, action, volume and time.
- Deterministic policy: validates every action outside the model.
- Impact-based approval: required in advance for hard-to-reverse decisions.
- Idempotency: a retry does not duplicate operations.
- Isolation: code and attachments run in restricted environments.
- Provenance: sources and memory carry an owner and a date.
- Limits: steps, cost, time and scope.
- Traces: full reconstruction with data minimisation.
- Kill switch: an independent mechanism to suspend actions.
60-day readiness plan
Days 1–15
- Inventory agents, models, tools and owners.
- Classify role, risk and timeline.
- Halt prohibited or ownerless uses.
- Map data, actions and people affected.
Days 16–30
- Build a file for each system.
- Review contracts, instructions and provider documentation.
- Define oversight, prohibited uses and metrics.
- Run a GDPR and fundamental rights analysis where applicable.
Days 31–45
- Roll out identity, permissions, policies, traces and kill switch.
- Build functional and adversarial tests.
- Train each role.
- Rehearse incidents and suspension.
Days 46–60
- Run in shadow mode or a limited pilot.
- Fix failures and calculate residual risk.
- Approve the use and record the conditions.
- Schedule monitoring and re-assessment.
Pre-production checklist
- Role and classification documented.
- Purpose and prohibited uses approved.
- Obligations officially verified against the calendar.
- Data, tools and providers inventoried.
- Risk management and testing up to date.
- Effective human oversight.
- Identity, minimum permissions and kill switch in place.
- Logs reconstruct decisions and actions.
- Transparency and escalation to a person configured.
- Literacy evidenced by role.
- GDPR, FRIA and sector rules coordinated.
Frequently asked questions
Is every agent high-risk?
No. It depends on purpose and scope. Autonomy does not automatically make a system high-risk, but it can raise the technical and organisational risk.
Does buying an agent transfer all responsibility to the provider?
No. Whoever deploys it must control purpose, data, oversight, monitoring and impact. It may also become a provider if it substantially modifies the system or its purpose in the cases covered by the Regulation.
Does a chatbot have to identify itself as AI?
In the cases covered by Article 50, people must be informed that they are interacting with AI, unless this is obvious, and this must be done clearly and in good time.
Does the AI Act replace the GDPR?
No. They are complementary frameworks. A system can meet the AI Act's requirements and still breach data protection law if it lacks a legal basis, minimisation or transparency.
Do logs have to keep everything?
No. They must enable traceability while applying minimisation, security and retention periods. Prompts can contain personal data or secrets.
Summum IA can support the technical classification, architecture and assessment of agents, as well as AI agent design and the associated LLMOps. Legal interpretation and the timeline must be validated before publication and deployment.