Agentic AI: the legal decisions to make before your next launch

What the ICO's announcement means for your roadmap

On 8 October 2026, the ICO announced that ten leading foundation model developers had made, or committed to make, data protection improvements following its supervision. It also opened a call for evidence on agentic AI, with responses due by 20 November 2026. The evidence will inform future guidance and the forthcoming statutory code of practice on AI and automated decision-making.

The announcement does not introduce a new agentic AI law or establish that every developer has completed its commitments. The ICO's enquiries into reported agent testing and deployment incidents remain ongoing. Existing duties under the UK GDPR and Data Protection Act 2018 continue to apply.

Our view is that product teams should use this regulatory attention to examine the full workflow: the information an agent receives, the tools it calls, the actions it takes and the controls available when something goes wrong. Those are decisions a business can address now.

A pilot that exposes the real issues

Consider a fictional startup building an agent for an online retailer. The pilot begins with answering delivery questions. The team then connects the agent to the retailer's customer relationship management system, shared inbox and refund tool so it can resolve queries without waiting for staff.

A customer explains that a health condition makes it difficult to collect a parcel. The agent copies the full message into an external tool, stores it in long-term memory and emails a delivery partner. The workflow may now involve health information, additional recipients and retention beyond what is needed to arrange delivery.

The questions become specific. Was the agent authorised to send that information? Was sharing the full message necessary? What legal basis and additional condition support processing the health information? Can the businesses identify where copies went and respond to a rights request?

This fictional example shows why a narrow initial use case should be reassessed as permissions, integrations and available actions expand.

Identify responsibility for each use of personal data

A controller determines the purposes and essential means of processing personal data. A processor handles it on the controller's behalf. Depending on the arrangements, organisations may also be joint controllers. These roles determine which obligations apply; the contractual label alone cannot settle the question.

An AI business might act as a processor when operating a customer's support workflow, while acting as a controller for a separate use of the information to improve its own product. Each operation needs its own assessment. The ICO's AI governance guidance explains that roles can differ between phases and purposes.

For the retailer pilot, map collection, model inference, retrieval, memory, tool calls, monitoring and any reuse for training. Record which organisation decides why each operation happens, what information is involved and how the other parties are instructed. That map gives the commercial agreement and privacy information a factual foundation.

Define the data boundary before expanding the agent's reach

UK GDPR Articles 5 and 6 require specified purposes, an appropriate lawful basis and personal data limited to what is necessary. A broad request to improve customer service needs to be translated into defined tasks and justified data uses.

For the pilot, the delivery function could receive an order number, delivery status and approved contact details. Access to an entire shared inbox should be justified against that task. Copying customer messages into an unrelated service or using them for product training requires separate analysis of the purpose, lawful basis and applicable restrictions.

Article 9 adds another layer for special category data, including health information. An Article 6 basis must be accompanied by an applicable Article 9 condition, with further domestic requirements where relevant. The customer's disclosure of a health condition does not establish a general right to reuse it across the agent's workflow.

A practical starting point is to identify unnecessary fields and destinations, restrict access, and decide how unexpected sensitive information will be handled before real customer data enters the pilot.

Use the risk assessment to make a deployment decision

Under Article 35, a controller must complete a data protection impact assessment, or DPIA, before processing likely to result in a high risk to individuals' rights and freedoms. The assessment depends on the actual processing. A small pilot can still require a DPIA where the proposed use creates sufficiently serious risks.

For an agent, examine the combination of data access, autonomy, recipients, affected people and possible consequences. A useful assessment connects each identified risk to a control, an owner and evidence that the control works. It should inform whether a feature is ready to deploy and what conditions apply.

If high residual risk cannot be sufficiently reduced, prior consultation with the ICO is required under Article 36. Revisit the assessment when changes to models, tools, permissions or intended uses alter the risk. For the retailer, moving from drafting replies to issuing refunds is a clear occasion to review the deployment.

Make permissions and security controls enforceable

Article 32 requires technical and organisational security measures appropriate to the risk, including regular evaluation of their effectiveness. The ICO's agentic AI work also highlights the significance of architecture, access and the ability to monitor or stop activity.

For the retailer scenario, practical controls to consider include:

• Give the agent a separate service identity with access limited to the records and actions required.
• Restrict external tools and destinations, and require approval before adding an integration.
• Set refund limits and require staff approval for exceptional or consequential transactions.
• Test whether malicious instructions in a customer message can redirect data or trigger unauthorised actions.
• Provide monitoring, credential revocation and a tested route for stopping a run.

Check whether automated decision-making safeguards apply

The UK's automated decision-making framework changed through the Data (Use and Access) Act 2025. Under UK GDPR Article 22A, a decision is solely automated where there is no meaningful human involvement. It is significant if it produces a legal or similarly significant effect on the individual.

Where Article 22C applies, safeguards must include information about the decision and routes to make representations, obtain human intervention and contest it. Article 22B adds restrictions for significant solely automated decisions involving special category data. It also prohibits significant solely automated decisions where the relevant processing relies wholly or partly on the recognised legitimate interests basis.

Apply those tests to the consequence of the action. A routine delivery-status message and an automated refusal affecting a contractual entitlement can raise different issues. A person's presence somewhere in the workflow does not establish meaningful involvement in a particular decision.

For significant decisions, define what reviewers can examine, when they intervene and how they can change an outcome. Customers also need a working route to request intervention after a qualifying automated decision.

Make transparency and rights work across the workflow

Article 13 requires specified information where personal data is collected from the individual, including purposes, legal basis, recipients, retention and applicable rights. Information obtained from elsewhere requires separate consideration under Article 14. The ICO identifies transparency and exercising rights as particular challenges for agentic systems.

For the retailer pilot, people should be able to understand the relevant data uses and find a clear contact route. The businesses need an operational process for locating information across messages, agent memory, logs and suppliers when a request arrives.

Rights have conditions and exceptions, so avoid promising universal deletion or unrestricted access. Agree who receives requests, which party searches each system and how assistance from suppliers will be obtained. Test that process with the people who will actually run it.

Contract for the product you are actually deploying

Where a supplier acts as a processor, Article 28 requires a binding agreement addressing matters including instructions, security, assistance with rights, subprocessors, audit information and deletion or return. Adding an external tool may change the processing chain and the authorisations required.

Commercial negotiations should also address the agent's permitted actions, customer configuration responsibilities, incident cooperation, service changes and contractual liability. Check provider terms for retention, model training and data reuse. Establish where processing takes place and assess any applicable international transfer requirements.

For the fictional startup, a workable agreement would align the promised refund limits and approved integrations with the settings delivered to the retailer. Contractual allocation of costs and responsibilities must sit alongside each organisation's own statutory obligations.

A release checklist for founders and product leads

1. Describe the specific customer task, the affected people and the actions the agent can take.
2. Map personal data through prompts, retrieval, memory, tools, logs and external recipients.
3. Confirm controller and processor roles, lawful bases and any special category conditions.
4. Complete the DPIA where required and resolve the controls needed before deployment.
5. Check significant automated decisions, meaningful human involvement and challenge routes.
6. Test access boundaries, misuse scenarios, stop procedures and supplier cooperation.
7. Align contracts, privacy information and customer promises with the deployed product.
8. Name the person responsible for monitoring changes and deciding when another review is needed.

How LexIrun can support an agentic AI business

LexIrun works with AI and technology businesses on the legal and governance questions surrounding product development and commercial deployment. For an agentic product, the starting point is understanding what the system does, how it uses data and which decision the team needs to make next.

The appropriate engagement depends on the product's stage and the gaps identified:

• AI Legal Readiness Review: an initial product, model and data walkthrough, regulatory issue mapping and a prioritised action list before a pilot, launch or fundraise.
• AI Governance Pack: responsibilities, approval gates, oversight records and processes for reviewing models, vendors, changes and incidents.
• AI Commercial & Data Launch Pack: a DPIA or focused EU AI Act gap scan, with agreed commercial contracts, privacy information and supporting launch materials.
• Fractional Legal & AI Compliance Counsel: ongoing support as the business negotiates contracts, develops its product and manages evolving compliance priorities.