AI agents that modify records: who is responsible under the AI Act?

The scenario: a request, a tool and a modified record

Imagine someone asks to update a customer’s address. An agent interprets the request, queries a business system, checks some details and sends an instruction that changes the record. The legal question cannot be answered simply by calling it an “agent” or noting that it acts without confirmation at every step. First, establish what system has been placed on the market or put into service, for what purpose and by which organisation.

Regulation (EU) 2024/1689, known as the AI Act, does not create a separate regulatory category for agents. The European Commission says an agent will usually include at least one general-purpose AI model and may constitute an AI system. That does not mean every agent, considered as a technical arrangement or commercial product, necessarily has one classification: several systems, components and organisations with different roles may be involved.

To analyse the example, describe the specific workflow: who offers the system, who configures it, which tools it connects to, who authorises instructions and what decision causes the change. It also matters whether the agent merely prepares a proposal or executes the modification, and whether the purpose is an ordinary administrative task or an activity within a field regulated by the Act. An external action is relevant to the operational analysis, but is not by itself enough to conclude that the system is high-risk.

What follows is a general map of the AI Act, not a legal determination for a particular deployment. The allocation of roles depends on verifiable facts and on the relationships between participants, not just on the product’s internal name.

System, model, agent and roles: different concepts

The Regulation defines an “AI system” by reference to features such as operating with varying levels of autonomy, the ability to infer, and the generation of outputs—such as predictions, content, recommendations or decisions—that can influence physical or virtual environments. The European Commission has issued guidelines to help interpret this definition. The analysis should focus on the particular solution and its capabilities, not a market label such as “agent”, “copilot” or “intelligent automation”.

An AI model and an AI system are not interchangeable terms. A model may be a component of a system; the system includes how the model is integrated, made available and used. “Agent”, in turn, usually describes an architecture or way of operating that may combine a model, instructions, tools, memory and execution mechanisms. That technical description does not replace the definitions in the Regulation.

In broad terms, a “provider” is a person or organisation that develops, or has developed, an AI system or general-purpose AI model and places it on the market or puts it into service under its own name or trademark, subject to the conditions in the Regulation. A “deployer” is a person or organisation using the system under its authority, other than in the course of a personal, non-professional activity. The role depends on what the organisation does and how it offers or uses the product; roles may differ across components of the same solution.

“Integrator” is not, by itself, a general operator category under the AI Act equivalent to provider or deployer. A company connecting tools may simply be integrating a system, or its actions may place it in another role depending on the facts. Article 25 addresses cases in which a distributor, importer, deployer or other third party is considered the provider of a high-risk AI system—for example, if it markets the system under its own name, substantially modifies it, or changes its intended purpose so that it becomes high-risk. Not every configuration or integration automatically has that effect.

In the record-update example, the provider might be the company offering the agentic system under its brand; the customer might be the deployer if it uses the system under its authority; and a technology firm might provide integration services. Those labels are working hypotheses, not conclusions: contracts, market presentation, control over the design and changes made can alter the analysis.

Purpose, not autonomy alone, guides classification

The AI Act does not classify every system with autonomy, tool access or an external effect as high-risk. Classification depends on the criteria and fields set out in the Regulation, particularly whether the system is a safety component of a product covered by the listed legislation or falls within one of the use cases in Annex III, taking account of applicable conditions and exceptions.

In the example, changing a customer record is not, by itself, enough to establish that the system is high-risk. The system’s intended purpose and the sector and process in which it operates must be identified. The analysis could change if, for example, the system is used for a function expressly included in an Annex III field, or forms part of a regulated product under the terms of the Regulation. The mere fact that a company uses personal data, that a task is automated, or that an action matters commercially is not enough.

Intended purpose is determined by what the provider intends the system to do, as reflected in instructions, technical documentation and marketing materials, alongside any relevant context of use. That purpose must also be distinguished from actual use that departs from what was intended. If the deployer modifies the system or changes its purpose, it may be necessary to reassess both the classification and who assumes provider obligations.

The European Commission indicates that agents usually contain at least one general-purpose AI model and may constitute an AI system. In practice, this means examining separately the rules applicable to the model and those applicable to the integrated system, without inferring that the presence of a general-purpose AI model determines the classification of the system as a whole.

Autonomy is relevant to describing how the system operates and assessing appropriate controls. For example, it is not the same for a system to suggest a change that a person makes, to apply it after specific approval, or to make it automatically. That distinction may affect the operational assessment, but it does not replace the AI Act’s legal classification criteria.

Responsibilities: separate system obligations from business use

The Regulation allocates obligations according to the role performed and the system category. It is therefore incorrect to assign all obligations to the model developer, or to transfer them automatically to the customer. A workflow may involve obligations for more than one organisation, but only after establishing which system is being assessed, which rules apply to it and who meets each definition.

For high-risk systems, Article 16 sets out provider obligations, including ensuring compliance with applicable requirements, maintaining a quality management system, keeping documentation and meeting the conformity assessment, registration and other requirements specified in that Article. This reference does not make every agent a high-risk system, nor does it mean that the company integrating one is always its provider.

Article 26 sets out obligations for deployers of high-risk AI systems. Among other things, it requires them to use the system in accordance with its instructions for use, assign human oversight to people with appropriate competence and authority, and monitor its operation under the conditions provided for. The precise scope depends on whether the system is in fact high-risk and which provisions apply. These requirements should not be generalised as AI Act obligations for every automated action.

Article 25 can change the allocation of roles when an organisation’s role in relation to a high-risk system changes—for example, if it places the system on the market under its own name or trademark, makes a substantial modification, or changes its intended purpose so that it becomes high-risk. The assessment requires examining what changed and how it affects the system; connecting an API or changing a template does not necessarily amount to one of these cases.

Article 4 requires providers and deployers to take measures to ensure, to the best extent possible, a sufficient level of AI literacy among their staff and other people operating or using AI systems on their behalf, taking account of knowledge, experience, training, the context of use and the people affected. This obligation does not replace the role analysis or turn the design recommendations in this article into legal requirements.

Other European or national rules may also be relevant, depending on the data processed, automated decision, sector and consequences. This analysis is limited to locating issues under the AI Act and does not determine obligations under other frameworks.

Permissions, approval and logs: prudent controls

Even though the AI Act does not automatically make every conceivable technical control a general obligation, an agent able to write to business systems warrants proportionate operational limits. Restricting the available tools, the data it can access and the permitted operations reduces the potential impact of errors, misinterpreted instructions or integration failures. These are design and security recommendations, not claims that the AI Act requires each of them in every deployment.

One useful practice is to grant minimum permissions: allow the agent to read only the necessary fields and keep read and write access separate. If an update could cause significant harm or is difficult to reverse, human approval before execution may be appropriate. For routine changes, the design could allow automatic execution within narrow limits, with prior validation and a rollback mechanism. The decision depends on impact and context, not on a single universal formula.

Operational logs can help reconstruct which request led to an action, which data or tools were used, what instruction was sent, what result the system returned and whether a person intervened. Set access, retention and protection rules for those logs in line with applicable law. The fact that an action is logged does not by itself demonstrate a compliant deployment, nor does it replace documentation or legally required records where applicable.

Human escalation is a suitable design measure when the system detects incomplete data, an ambiguous instruction, an operation outside the authorised pattern or a tool failure. Define who receives the case, what information they receive and whether they can stop or correct the operation. For high-risk systems, Article 26 includes specific human oversight requirements for deployers; in other cases, a prudent recommendation should not be presented as an equivalent AI Act obligation.

These measures help govern external actions, but do not settle the legal classification. A technically controlled implementation may still require an analysis of purpose and roles; and a high-risk classification is not satisfied merely by restricting permissions.

Application dates and transitional rules

Read the timeline from the official Regulation and distinguish entry into force from the date each obligation becomes applicable. Regulation (EU) 2024/1689 entered into force on 1 August 2024. Its general rule is that it applies from 2 August 2026, but Article 113 sets earlier dates for specific parts and a later date for certain high-risk systems integrated into regulated products.

Chapters I and II apply from 2 February 2025 under Article 113. These include, among other provisions, the definitions in Chapter I, AI literacy under Article 4 and prohibited practices under Article 5. This does not mean that the full regime for high-risk systems applies from that date.

From 2 August 2025, provisions including Chapter V on general-purpose AI models, as well as the institutional provisions and penalty rules identified in Article 113, apply. For providers of general-purpose AI models placed on the market before 2 August 2025, Article 111 provides a transitional rule: they must comply with the applicable obligations no later than 2 August 2027.

The general date of application is 2 August 2026. For high-risk systems referred to in Article 6(1) that are safety components of products, or are themselves products, subject to the harmonisation legislation listed in Annex I, Article 113 sets the date at 2 August 2027. Article 111 also contains transitional rules for high-risk systems already placed on the market or put into service before 2 August 2026; their scope depends on whether significant changes are made to the design and on other conditions in the text.

It is therefore not enough to cite a general date in a business plan. Each obligation must be linked to its Article, category and transitional provision, and it must be checked whether the system or model was already on the market or in service on the relevant date. This summary reflects the text of Regulation (EU) 2024/1689 identified in the supplied sources; if the legislation has since been amended, check the current official text again before making decisions.

Pre-deployment verification checklist

Start by defining what is being assessed: is it a model, a system incorporating one, or a workflow involving several systems? Map the chain from the request to the record change and identify which component produces each output. Establish whether there is an external action and which organisation controls its execution.

Then determine roles using concrete evidence: the brand under which the system is offered, contracts, documentation, who commissions or makes changes, who decides its purpose and who uses it under their authority. Pay particular attention to whether a modification could be substantial or whether the intended purpose has been changed in a way that affects the system’s category.

Assess classification without shortcuts: identify the intended purpose, check the Article 6 criteria and relevant fields in the annexes, and review any exceptions or conditions. If the available information is not enough to decide, record the question as open and seek legal or regulatory review before claiming that the system is, or is not, high-risk.

Finally, separate legal requirements from prudent measures: determine which provisions apply to each organisation’s role and to the specific system; note dates and transitions; and define permissions, approvals, logs and escalation as operational controls with accountable owners and verifiable criteria. The assessment should be revisited if the model, tools, purpose, sector or manner of use changes.

This checklist structures an initial review but does not replace legal advice for a particular product or deployment. Nor is it a complete guide to risk management, provider conformity, impact assessments or the documentation of decisions. Its aim is to prevent the agent’s autonomy from becoming a substitute for analysis grounded in the legal text and verifiable facts.

Keep exploring

Corrections and transparency

If you spot incorrect or outdated information, send us a correction with the page and source we should review.