Two comments on my recent LinkedIn post brought the practical questions around agentic AI into focus. Alan L. of V8 Global, whose work includes Axia and Scaffold, highlighted the difficulty of producing compliance evidence after an agent is already live. He proposed keeping a record of outbound actions, the instructions behind them and the person who approved them from day one.

Muhammad Taha Khan, an AI systems architect working with founders and coaches, asked which side tends to be overlooked first when a small team has to prioritise: the legal decisions or the technical ones.

Alan’s observation concerns evidence of control. Muhammad’s question concerns when the business defines that control. As a lawyer and founder of LexIrun, I would address both in the same deployment process: define what the agent is authorised to do, configure the system accordingly, and retain proportionate evidence of what actually happens.

The two contributions behind this article

Alan’s proposal provides a useful starting point for reconstructing an agent’s actions. Its legal value depends on connecting the record to the purpose, permissions and safeguards that applied at the time. Muhammad’s question adds the resource constraint: how can a small team make these decisions while building a working product?

The discussion below develops my legal analysis of those contributions. The scheduling example is fictional and illustrates the decisions a team might face.

First identify who is responsible for the processing

Personal data is information relating to an identified or identifiable individual. Processing includes reading, retrieving, storing, using, sharing and deleting it. An agent querying a customer record or sending a calendar invitation can therefore be processing personal data even if the underlying model was trained elsewhere.

A controller determines the purposes and means of a particular processing operation. A processor handles personal data on the controller’s behalf. A customer may control the purpose of a scheduling service while its supplier processes information on instructions; a separate reuse by the supplier to improve its own product may require a different assessment.

Map those roles by activity. Article 5(2) addresses the controller’s accountability, while processors have their own obligations elsewhere in the UK GDPR. Naming an employee as the approver of a tool call does not settle the organisation’s legal role.

The principles that the evidence needs to support

Article 5(1) sets out six groups of principles. For an agentic workflow, each should be connected to an operational decision:

  • Lawfulness, fairness and transparency: establish a lawful basis, assess the impact on people and provide the required information.
  • Purpose limitation: specify why the data is used and assess compatibility before reusing it for another purpose.
  • Data minimisation: limit collection, access and disclosure to information necessary for the task.
  • Accuracy: take reasonable steps to correct or erase inaccurate personal data and keep it current where necessary.
  • Storage limitation: justify how long identifiable records are needed, taking account of applicable requirements and exceptions.
  • Integrity and confidentiality: protect information against unauthorised access, disclosure, alteration and loss.

Article 5(2): the responsibility to comply and demonstrate compliance

Article 5(2) adds accountability to those principles. It requires the controller to take responsibility for compliance with Article 5(1) and be able to demonstrate it. An action log can contribute to that evidence, alongside functioning controls, documented decisions, contracts and review records.

Article 24 connects this to appropriate technical and organisational measures, taking account of the processing and risks to people. Measures must be reviewed and updated where necessary. The evidence should therefore describe the system actually operating, including changes since its initial approval.

For a small team, a short, maintained record can be useful if it accurately connects purposes, permissions, testing and ownership. A long policy that no longer matches the product will be much harder to rely on when explaining an incident or answering customer due diligence.

Answering Alan: what a useful action record should contain

Start with the questions the business may need to answer after an unexpected email, disclosure or transaction. The following is a suggested record structure to adapt to the workflow and its risks:

  1. Task and instruction: identify the request that initiated the action, using a reference or necessary summary where sufficient.
  2. Permitted scope: record the systems, data categories, recipients and actions authorised for that task.
  3. Applicable rule: identify the operating policy and relevant model or tool configuration in force.
  4. Approval status: record any required approval, rejection or override; for permitted automation, identify the rule authorising execution.
  5. Actual action: identify the tool used, recipient, relevant data disclosed and time of execution.
  6. Outcome: retain reliable evidence of the result, such as a delivery response or failed request, where needed.
  7. Exception handling: record deviations, blocked attempts, escalation, correction and who took responsibility.

Approval of operating limits and approval of individual actions

Article 5(2) does not prescribe human approval for every AI action. A business can define a category of permitted actions and require individual approval for exceptions, where that approach satisfies the applicable obligations and risks.

For example, a scheduling agent might send invitations to named participants within agreed times. Adding a new recipient, including an attachment or using another calendar could trigger a review. Record the authorisation for the operating rule and any later individual approval separately.

A human approval cannot supply a missing lawful basis under Article 6 or make unnecessary data sharing justified. Reviewers need relevant information and authority to refuse or change the action. For significant decisions made solely through automated processing, assess Articles 22A to 22D separately, including the applicable restrictions and safeguards.

Answering Muhammad: put legal scope into the build

For a small team, I would make legal scope explicit in the same discussion that authorises the integration. A working connection can be demonstrated immediately; questions about permitted use are easier to leave unresolved unless someone owns them.

Agree the purpose of the workflow, the lawful basis, the people affected and the information needed. Then decide which systems the agent can access, what it can disclose, which actions can run automatically and when a person must intervene. These decisions should inform the permissions engineers implement.

Article 25 requires appropriate measures to embed data protection principles in the design and operation of processing. By default, personal data must be limited to what is necessary for each specific purpose, including its amount, use, retention and accessibility.

A practical release discussion can connect each promised restriction to a setting, a test and an owner. If the customer is told that an agent can only read availability, the team should be able to show that broader calendar content is outside its effective access.

The DPIA comes before the processing that requires it

Article 35 requires a controller to conduct a data protection impact assessment, or DPIA, before processing likely to result in a high risk to individuals’ rights and freedoms. The assessment concerns the actual use, context and possible harm. A limited pilot can still involve high-risk processing.

The assessment must describe the processing and purposes, assess necessity and proportionality, identify risks to people and set out measures to address them. For an agent, useful questions include whether it can reach unrelated records, add recipients, combine information or continue acting after a mistaken instruction.

Logs can later help evaluate whether those safeguards are working. They do not change the requirement to assess qualifying processing before it begins. If a deployment is already live and an assessment was required, address the gap promptly and consider restricting or pausing the relevant processing while risks and safeguards are assessed.

Where high residual risk cannot be sufficiently reduced, prior consultation with the ICO is required under Article 36. Revisit the assessment when changes to the processing alter the risk.

Worked example: a scheduling agent with defined authority

Imagine a small consultancy using an agent to arrange introductory calls. Its agreed task is to offer available slots and send a calendar invitation to the named customer and adviser. The task needs contact details, availability and the chosen time.

A convenient connector offers full mailbox and calendar access. That wider access could expose unrelated messages, confidential meeting titles and information about other customers. The team should assess whether a narrower interface can meet the task, rather than accepting the connector’s maximum permissions as the product requirement.

The team chooses free/busy access, a dedicated sending identity, approved recipients and a booking rule. The agent may issue the invitation within those limits. A request to add someone else, forward an email chain or include an attachment is paused for review.

A proportionate record of one run could look like this:

  • Request: arrange an introductory call with the named customer.
  • Authority: send one invitation using approved participants and available slots.
  • Data disclosed: participant names, email addresses and the selected time.
  • Decision: execution permitted under the current booking rule; no exception approval required.
  • Result: invitation sent to the recorded recipients; delivery result retained where needed.
  • Exception: an attempted addition of another recipient was blocked and referred for review.

Use the record to explain the event and test the controls

If the customer asks why an invitation arrived, the consultancy can trace it to the request and the rule that allowed the action. If another recipient received it, the team can compare the actual tool output with the permitted scope and investigate the discrepancy.

Testing should cover attempted boundary crossings as well as ordinary bookings. For this fictional workflow, that could mean asking the agent to invite an unapproved address, attach a private message or access a calendar outside the task. Check whether the system blocks the action and produces an appropriate record.

The person reviewing exceptions should know which facts to examine, what changes they can approve and when the matter needs legal or security input. A recurring exception can indicate that the approved scope or the implementation needs revision.

The audit trail needs its own data protection controls

Logging can create an additional store of personal and confidential information. Full prompts and tool responses may contain material unnecessary to investigate the action. Decide what the record needs to establish and use references, selected fields or restricted supporting records where appropriate.

Identify the purpose and lawful basis for retaining personal data in the trail. Set a justified retention period and decide how records will be located when a relevant rights request, incident or dispute arises. A technical ability to retain everything indefinitely is not a retention policy.

Article 32 requires security appropriate to the risk and evaluation of the effectiveness of the measures used. For the trail, consider access permissions, protection against unauthorised alteration, secure storage and the ability to distinguish an original event from a later correction.

The practical aim is reliable, accessible evidence for authorised users, with unnecessary exposure reduced. Test whether the people responsible can retrieve the relevant run and understand what happened.

Reflect the operating model in supplier contracts

Where a supplier acts as a processor, Article 28 requires a binding agreement addressing the processing and the parties’ obligations. Relevant provisions include documented instructions, confidentiality, security, subprocessors, assistance with rights and specified compliance duties, audit information, and deletion or return.

For an agentic service, agree who configures permissions, approves new integrations, keeps action records and assists when a customer challenges an action. Ask whether a supplier can provide the evidence the customer will need, including relevant records held by downstream providers.

Commercial terms should also address incident cooperation, changes to the service, transition arrangements and contractual liability. Check whether the product’s actual settings match the restrictions promised in the agreement. A contractual allocation of responsibility sits alongside each party’s statutory duties.

Article 5(3): compatible reuse still needs a lawful basis

The current UK GDPR includes Article 5(3), added by the Data (Use and Access) Act 2025. It clarifies that processing is not lawful merely because it is compatible with the purpose for which the information was collected.

Suppose the consultancy later proposes to use scheduling records to train a separate product. It should assess purpose compatibility under the applicable reuse rules, whether its lawful basis covers the proposed processing, transparency and any additional conditions. The existence of a well-kept booking log does not itself authorise that reuse.

This matters when monitoring data gradually becomes a product-development dataset. Review the proposed use before the information moves into another workflow, and update the relevant records and information for affected people where required.

A proportionate release pack for a small team

For the scheduling example, I would bring the key decisions together in a compact pack, with each item kept current as the service changes:

  1. Purpose and data map: the task, people affected, data categories, recipients and relevant lawful bases.
  2. Roles and contracts: who determines the processing, who acts on instructions and the applicable supplier terms.
  3. Risk decision: DPIA screening, the completed assessment where required, safeguards and unresolved risks.
  4. Permission rules: allowed systems and actions, approval conditions, exception owners and stop arrangements.
  5. Evidence: the action-record design, tests of the restrictions, monitoring and access to supporting records.
  6. Review triggers: changes in models, tools, data, recipients or uses that require another decision.

How LexIrun can help

LexIrun helps AI and technology businesses connect their product decisions with data protection, contracts and governance. The starting point is the workflow the team is building and the commercial milestone it needs to reach.

Depending on the agreed scope, support can include a review of purposes and data flows, controller and processor roles, risk assessments, permissions and oversight arrangements, supplier terms, privacy information and the evidence needed for customer due diligence.

  • AI Legal Readiness Review: identify the main legal issues and prioritise the next steps before a pilot, fundraise or launch.
  • AI Governance Pack: define decision owners, approval gates, review records and processes for changes and incidents.
  • AI Commercial & Data Launch Pack: scope the relevant assessment, commercial agreements and data documentation for a paid pilot or release.
  • Fractional Legal & AI Compliance Counsel: maintain legal input as the product, suppliers and customer commitments evolve.

If your next integration expands what an agent can read, disclose or do, share a short description of the workflow and the decision ahead with LexIrun. We can discuss the appropriate review and agree the scope of support.

Legal position reviewed on 22 October 2026. The logging and release-pack examples are practical suggestions to adapt to the deployment; the applicable legal duties depend on the processing, parties and risks involved.

This article provides general information and does not constitute legal advice on a specific matter. Legal obligations depend on the facts and the applicable law.