This sixth part continues Part V on AI Act transparency for content and interactions. The question now concerns how an EU business should control an agent's access to personal data, use of tools and decisions affecting people. The analysis concerns ordinary business software within the AI Act and GDPR, with the particular controls assessed against the agent's intended use. (Regulation (EU) 2024/1689, Article 3(1), (12)–(13); Regulation (EU) 2016/679, Article 4(2).)
Summary
- Assess the deployed agent's intended use, including connected tools, permissions and resulting actions. The underlying model is one component of that operation. (AI Act, Article 3(1), (12)–(13), recital 97.)
- Personal-data access must serve a lawful purpose and respect necessity, default limits and security requirements. An employee's software permissions do not themselves establish the legal basis for every operation an agent can perform. (GDPR, Articles 5(1), 6(1), 25, 32.)
- Human oversight under the AI Act must be proportionate to the high-risk system's risks, autonomy and use. The relevant requirements apply from 2 December 2027 or 2 August 2028, according to the statutory category and transitions. They do not prescribe approval before every action of every agent. (AI Act, Articles 14, 111(2), 113, as amended.)
- A decision based solely on automated processing, with legal or similarly significant effects, engages GDPR Article 22. A nominal approver or another reviewing agent does not necessarily provide human decision-making. Permitted solely automated decisions require an applicable exception and safeguards. (GDPR, Article 22; Article 29 Working Party, WP251rev.01, pp. 20–21, 27.)
- Persistent memory and connected services extend the processing that the business must control. Purpose, retention and recipient restrictions must reach those operations; processor relationships require the safeguards in Article 28. (GDPR, Articles 5(1)(b)–(f), 25(2), 28.)
- Where Article 15(1)(h) applies, the explanation must describe the procedure and principles actually used to reach the person's result. A newly generated account of possible reasons cannot substitute for the required explanation. (CJEU, Dun & Bradstreet Austria, C-203/22, ECLI:EU:C:2025:117, paragraphs 57–66.)
- Testing should examine the complete action, including rejected requests, uncertain tool responses and recovery. Separate permissions, action-specific approvals and tested suspension procedures are proposed ways to address those risks. Their suitability depends on the operation and applicable duties. (GDPR, Article 32(1)–(2); AI Act, Articles 9(6), (8), 14(3)–(4), 15.)
The agent's system boundary
The business should assess the agent as configured for use, including the software through which it acts. The AI Act defines systems by their characteristics, including autonomy and inference producing outputs that influence physical or virtual environments. Its intended-purpose definition includes the provider's specified context and conditions of use. Reasonably foreseeable misuse includes interactions with other systems, including other AI systems. These provisions require attention to the connected operation when the tools affect those characteristics or conditions. (AI Act, Article 3(1), (12)–(13), recital 97.)
Consider a hypothetical customer-support agent. It retrieves a customer's record, prepares an address correction and drafts a confirmation. The business then adds permission to change the record and send the message. An assessment of generated text alone would not test whether the agent changes the correct record or sends the authorised message. The relevant examination includes the permitted fields, customer identity and destination of the confirmation.
The amended Act expressly mentions Agentic AI in Annex XIV, code AIH 0401. That code concerns the designation of conformity assessment bodies. It creates no separate substantive risk class for every agent. Classification still depends on the applicable statutory criteria, which the earlier parts of this series address. (AI Act, Article 6, Annex XIV, introductory text and section 3(d); Regulation (EU) 2026/1744, Article 1(43).)
Timing also limits the high-risk duties discussed here. Chapter III, Sections 1–3, except Article 6(5), apply from 2 December 2027 for Article 6(2) systems. The date for Article 6(1) systems is 2 August 2028, subject to the applicable scope and Article 111 transitions. Those sections contain the risk-management, oversight, security and deployer requirements relevant to agent controls. GDPR duties already apply to processing within that Regulation. (AI Act, Articles 111(2), 113, third paragraph, point (c); Regulation (EU) 2026/1744, Article 1(39)(a), (40)(b); GDPR, Article 99(2).)
For high-risk systems placed on the market or put into service before the relevant Chapter III date, Article 111(2) conditions application on significant changes in their designs from that date. This rule excludes the systems in Article 111(1) and preserves Article 5. Providers and deployers of high-risk systems intended for public authorities must take the necessary steps to comply by 2 August 2030. (AI Act, Article 111(2), as replaced by Regulation (EU) 2026/1744, Article 1(39)(a).)
Authority for tool use
The business must establish a lawful basis for the personal-data processing that an agent performs. Retrieval, alteration, storage and disclosure are processing operations under the GDPR. Technical permission to open a mailbox or update a database does not supply that lawful basis. A controller must also respect purpose limitation and data minimisation. (GDPR, Articles 4(2), 5(1)(a)–(c), 6(1).)
A request to correct a delivery address can justify access to the information necessary for that service where the applicable legal basis covers it. It does not, by itself, justify sending the customer's complete correspondence to every connected service. The controller should identify the permitted purpose and necessary information before granting the agent access. Article 6 permits several legal bases; using an agent does not require fresh consent for each technical step within otherwise lawful processing.
A practical design separates permission to read information, prepare a proposed change and execute it. The data service should enforce the permitted records and fields before returning information to the model. The action service should check the operation and target before accepting a change. Those controls implement the controller's duties to limit processing by default and protect personal data against unauthorised access or alteration. Their exact design depends on the processing and risks. (GDPR, Articles 25(1)–(2), 32(1)–(2).)
For the support agent, a credential limited to one customer's permitted fields reduces the operations available through that interface. The application can reject a request to alter another account even if the model proposes it. Review must also cover any broader route available through a browser, another tool or delegated agent.
Instructions in retrieved material
Material that an agent reads should not acquire authority to change its permissions. A customer message or retrieved webpage can contain instructions directed at the model. The European Data Protection Supervisor (EDPS) identifies prompt injection as a security risk and recommends tailored controls and continuing assessment. Its guidance concerns EU institutions under Regulation (EU) 2018/1725; it supplies technical recommendations, not a binding GDPR checklist for private businesses. (EDPS, Generative AI and the EUDPR, Version 2, 28 October 2025, section 15, p. 36.)
Suppose an attachment tells the support agent to send account records to an external address before correcting the customer's details. The application should treat the attachment as task input and enforce its own permitted recipients and approval rules. A service that rejects an unauthorised destination prevents execution through that service, even if the model follows the injected instruction.
The European Union Agency for Cybersecurity (ENISA) recommends least privilege, runtime controls and protection of agent endpoints. Those nonbinding technical recommendations support placing restrictions in the services that handle data and execute actions. A prompt telling the model to ignore hostile instructions needs testing alongside those restrictions. The company should test whether malicious content can produce an actual unauthorised disclosure through any available tool. (ENISA, ENISA's view on Cybersecurity in the Frontier AI Era, 7 July 2026, pp. 11–12, 15; GDPR, Article 32(1)–(2).)
Approval before execution
Human approval should be placed where the reviewer can affect the consequential action. When the AI Act's high-risk requirements apply, Article 14 requires effective oversight calibrated to risk, autonomy and use. As appropriate and proportionate, the overseer must be able to understand limitations, monitor performance and interpret outputs. The required capabilities also include disregarding or overriding outputs and intervening safely. The Act does not impose identical approval points on all agents. (AI Act, Article 14(1)–(4).)
For a proposed address change, the reviewer should see the correct customer, existing value and proposed replacement. If the workflow also sends a message, the approval should identify its recipient and content. A general instruction to resolve the case leaves those details undecided. The business can design the application to associate approval with the specified action and require reconsideration after a material change.
The control must remain effective between approval and execution. A changed recipient, substituted account or amended message can invalidate the factual basis on which the person approved the action. Checking the final request against the approved details addresses that failure. The system should also recognise whether the authorised action has already occurred before accepting a repeated request.
These are proposed implementations of oversight and security duties, selected according to the task. Routine operations can use automatic execution where the underlying processing is lawful and the controls are adequate. For high-risk deployment, the assigned person must have the necessary competence, training, authority and support. A reviewer who cannot understand or stop the operation cannot perform those functions merely by pressing an approval button. (AI Act, Articles 14(3)–(4), 26(2); GDPR, Article 32(1)–(2).)
Automated decisions about people
An agent making a consequential decision about a person requires a separate Article 22 assessment. The GDPR's prohibition in principle concerns three cumulative elements: a decision, based solely on automated processing, which produces legal or similarly significant effects. A person need not first object for that prohibition to apply. Routine scheduling or message preparation does not acquire those effects merely because an agent performs it. (GDPR, Article 22(1); CJEU, SCHUFA Holding (Scoring), C-634/21, ECLI:EU:C:2023:957, paragraphs 43–52.)
Assume a recruitment agent evaluates applicants and sends rejection decisions that significantly affect them. If the process operates solely through automated processing, Article 22 requires an applicable exception. A recruiter who performs an actual assessment before deciding may change that analysis. The Working Party guidance, endorsed by the European Data Protection Board (EDPB), requires review by someone with authority and competence to change the decision, taking the relevant information into account. Routine acceptance of the output is insufficient. That guidance is nonbinding and explains the distinction between actual human involvement and a nominal step. (WP251rev.01, pp. 20–21.)
A second agent that checks the first agent's recommendation remains part of automated processing. Human participation in designing the workflow also does not establish human assessment of each later decision. The business should examine who determines the outcome, what information that person considers and whether the person can depart from the recommendation before it takes effect.
The examination must include downstream reliance. In SCHUFA, the Court held that an automatically produced credit probability could itself constitute the relevant decision. The recipient bank drew strongly on the score, which played a determining role in granting credit. The holding concerns that dependence; it does not make every intermediate recommendation an Article 22 decision. Applied to agents, the business should establish whether a component's output effectively determines the subsequent result. Calling that output advisory does not resolve the statutory conditions. (SCHUFA, paragraphs 48–50, 61–64.)
Article 22(2) permits specified solely automated decisions where necessary for entering into or performing a contract between the data subject and the controller. Its other exceptions concern decisions authorised by qualifying Union or Member State law or based on explicit consent. The contractual exception requires necessity, not the company's preference for automation. The authorising law must provide suitable safeguards. Decisions based on special-category data also require Article 9(2)(a) or (g) and suitable safeguards. Other GDPR requirements continue to apply. (GDPR, Article 22(2)–(4); SCHUFA, paragraphs 53–55, 65–68; WP251rev.01, pp. 23–24.)
For the contractual and explicit-consent exceptions, Article 22(3) requires rights to obtain human intervention, express a view and contest the decision. SCHUFA also confirms those minimum safeguards when national law authorises the decision under Article 22(2)(b). The controller therefore needs a functioning review route for the permitted automated outcome. A later review remedy does not retrospectively make the original decision nonautomated. (GDPR, Article 22(3); SCHUFA, paragraphs 65–66; WP251rev.01, p. 27.)
Personal data in retrieval and memory
The controller must control the information that an agent can retrieve and retain for later tasks. Article 25(2) requires default limits tied to each specific purpose. It expressly covers the amount of data, extent of processing, storage period and accessibility. These duties apply when the business adds a retrieval store or persistent memory to its application. (GDPR, Articles 4(2), 25(2).)
For the support agent, retrieval should be limited to the customer's relevant records before passages enter the model's working context. A shared knowledge store needs controls preventing one customer's task from drawing on another customer's restricted information. The EDPS recommends testing retrieval-augmented generation for leakage of personal data from its knowledge base. That technical recommendation addresses a concrete failure that a private deployment can test under its own GDPR security assessment. (GDPR, Article 32(1)–(2); EDPS, Generative AI and the EUDPR, Version 2, section 15, p. 36.)
The controller must specify the purpose of retaining information in memory for later tasks. A summary or inferred preference remains subject to the GDPR where it relates to an identifiable person. If a stored summary contains an outdated address, correcting the customer database while retaining the old value in operational memory can reintroduce the error. The company should design correction procedures to reach the relevant controlled copies and prevent that recurrence. (GDPR, Articles 4(1), 5(1)(b)–(e), 16.)
Erasure depends on the grounds in Article 17(1) and the exceptions in Article 17(3). Where erasure is required, deleting only the visible conversation leaves other relevant retained copies to be addressed. A record lawfully retained for a distinct purpose may require restricted access and separation from routine agent retrieval. The technical procedure should distinguish those purposes so that a retained audit record is not automatically reused as operational memory. (GDPR, Articles 5(1)(b), (c), (e)–(f), 17, 25(2).)
Personal data sent to connected services
The controller must establish the processing relationship for each connected service receiving personal data. An external model service, search tool or storage service may act as a processor for specified operations. Its actual purposes and essential means determine the role. Technical discretion over implementation does not alone make a processor a controller. A service that determines its own purposes and means requires a different assessment for that processing. (GDPR, Article 4(7)–(8), 28(10); EDPB, Guidelines 07/2020, Version 2.1, paragraphs 39–43, 75–82.)
Where a processor acts for the business, Article 28 requires sufficient guarantees and a binding contract or other qualifying legal act. The processor must follow documented instructions unless Union or Member State law to which it is subject requires the processing. It must inform the controller of that requirement beforehand, unless that law prohibits notice on important public-interest grounds. The agent's ability to select a tool cannot replace the controller's decision about permitted processing and recipients. A practical implementation restricts tool selection to services and operations covered by those arrangements. (GDPR, Article 28(1), (3)(a), (9).)
Subprocessors require prior specific or general written authorisation. Under general authorisation, the processor must give notice of intended additions or replacements and an opportunity to object. These conditions do not require a new signature for each API call. They do require the business to distinguish ordinary use of an authorised service from adding another processor. The same data-protection obligations must be imposed on that subprocessor through the required agreement. (GDPR, Article 28(2), (3)(d), (4).)
If the arrangement involves a third-country transfer, the controller must also satisfy the applicable Chapter V conditions. An Article 28 processing agreement or tool permission does not, without more, satisfy Chapter V. The proposed list of permitted services should identify relevant destinations and onward processing before the agent receives access. (GDPR, Articles 28(3)(a), 44.)
Records and explanations of actions
The business should preserve evidence sufficient to establish the authorised action and what actually happened. A proposed record identifies the task, relevant permission state, tool request and execution outcome. Where approval is required, it should connect the reviewer's decision to the action that was executed. The useful record is proportionate to the operation; personal-data minimisation, storage limitation and security still apply. (GDPR, Articles 5(1)(c), (e)–(f), 5(2), 32.)
That record also supports a more specific duty where Article 15(1)(h) applies. In Dun & Bradstreet Austria, the Court required an intelligible explanation of the procedure and principles actually used to process the person's data and obtain the result. Providing a complex formula or an exhaustive technical account alone cannot satisfy the requirement for a concise and intelligible explanation. (GDPR, Articles 12(1), 15(1)(h); Dun & Bradstreet Austria, paragraphs 57–66.)
For an agent workflow, the explanation should be grounded in the actual decision process and relevant data. A fluent explanation produced after the event does not establish which information or criteria determined the outcome. The company should verify that account against reliable decision evidence. This application of the judgment does not require publication of hidden model reasoning or prescribe a particular action-log format.
Trade secrets and other people's data require a case-specific balance. They do not permit a blanket refusal to provide all information. Where the controller considers the required information protected, it must provide it to the competent supervisory authority or court for that assessment. Supplier confidentiality terms therefore cannot be treated as a complete answer to the controller's explanation duty. (Dun & Bradstreet Austria, paragraphs 69–76.)
Tests of the complete workflow
The company should test whether the connected application respects its limits throughout the task. GDPR Article 32 requires security appropriate to risk and includes regular effectiveness testing among the measures applicable as appropriate. When the AI Act's high-risk requirements apply, Article 9 requires testing against previously defined metrics and probabilistic thresholds appropriate to the intended purpose. Article 15 requires relevant lifecycle accuracy, robustness and cybersecurity. An isolated model test does not establish that the surrounding tool controls work. (GDPR, Article 32(1)–(2); AI Act, Articles 9(6), (8), 15(1), (4)–(5).)
For the hypothetical support agent, useful tests include access to the wrong customer's record and an attempted change to a prohibited field. Another test substitutes the destination after approval. A malicious attachment can test whether retrieved instructions trigger an unauthorised disclosure. Each test should examine the service's response and resulting record, so that a reassuring message from the agent cannot conceal an incorrect external action.
A further test assumes that a service completes a change but its response is lost. Retrying the same request without checking the external result can duplicate a consequential action. The application should recognise uncertain completion and use the service's available verification or duplicate-prevention mechanisms before repeating it. The precise method depends on what the service supports; a model's assertion that the first attempt failed is insufficient evidence of nonexecution.
The business should also test limits across a sequence of actions. A cap on each individual message or operation does not control total activity if the agent can repeat it indefinitely. Aggregate limits and escalation rules are proposed controls where that cumulative activity creates risk. Their thresholds should follow the actual business task and potential harm, with testing sufficient to assess whether the selected restrictions work. (GDPR, Article 32(1)–(2); ENISA, ENISA's view on Cybersecurity in the Frontier AI Era, pp. 11–12, 15.)
Suspension and changed capabilities
The business should be able to contain an agent's operation and determine what has already occurred. Where Article 14 applies, the required oversight capabilities include, as appropriate and proportionate, intervention or interruption through a stop button or similar procedure producing a safe halt. The company should determine which pending requests can be cancelled and which completed actions require separate correction. (AI Act, Article 14(4)(e).)
In a practical exercise, staff suspend the agent, revoke its credentials and check queued requests. Staff then reconcile calls already sent with the external service's records. They should establish which changes completed and what corrective action remains possible before restoring access. These proposed steps address containment and recovery; ENISA recommends incident containment with human review, while GDPR security measures include timely restoration of personal-data availability and access where appropriate. (ENISA, ENISA's view on Cybersecurity in the Frontier AI Era, p. 15; GDPR, Article 32(1)(b)–(d).)
An unauthorised disclosure can also trigger the GDPR's breach duties. The controller must notify the supervisory authority without undue delay and, where feasible, within 72 hours of awareness, unless the breach is unlikely to create a risk to people's rights and freedoms. A processor must notify the controller without undue delay after becoming aware of a personal data breach. Where the breach is likely to result in a high risk to people's rights and freedoms, the controller must communicate it to affected people without undue delay, subject to Article 34(3). Stopping the agent does not discharge those duties. (GDPR, Articles 33(1)–(2), 34(1), (3).)
The assessment should be revisited when the business changes the agent's permitted operation. Adding write access, a new recipient or persistent cross-task memory can alter the processing and its risks. Where necessary, Article 35(11) requires review of a data protection impact assessment (DPIA) at least when the processing risk changes. Human approval does not itself remove Article 35(3)(a)'s requirement for systematic and extensive evaluations based on automated processing, where decisions producing legal or similarly significant effects are based on those evaluations. (GDPR, Articles 25(1), 35(3)(a), (11).)
For the support agent, the change from drafting an address correction to executing it calls for tests of the new permissions and external result. Replacing the model while keeping the same interface also warrants checking whether the established restrictions remain effective. Where the high-risk duties apply, the provider's lifecycle risk process and the deployer's use and monitoring duties require attention to relevant changes. The organisation should resolve failures in the changed workflow before permitting it to take the affected actions. (GDPR, Article 32(1)(d); AI Act, Articles 9(2), 26(1), (5).)
