AI DPIA template and the record of processing activities for AI tools

When an AI tool needs a DPIA

Article 35 requires a DPIA where processing is likely to result in a high risk to people, and names new technologies as a typical trigger. The ICO's guidance lists the use of innovative technology, large-scale processing, profiling and automated decisions among the cases where a DPIA is needed, and treats AI as likely to fall into at least one of them. If an AI app reads customer records, drafts replies to people, or acts on their data, assume you need one.

The DPIA must be done before the processing starts. For an AI app that is already in use, do it now and record why it was late.

What the DPIA must contain

Article 35(7) sets the minimum. In practice an AI DPIA has these parts:

1. A description of the processing and its purposes: which AI apps, which data, which people, what the AI does with it, and which third parties it reaches.
2. Why the processing is necessary and proportionate: what the AI achieves that a less intrusive route would not.
3. The risks to people: inaccurate outputs acted on, personal data sent to a model or tool that should not see it, decisions made without a human, data kept longer than needed.
4. The measures that address each risk, and who owns them: redaction before data reaches a model, tools switched off, human review, retention limits, access controls.
5. The outcome: residual risk, the data protection officer's advice, and sign-off. If a high risk remains that you cannot reduce, Article 36 requires prior consultation with the ICO.

The record of processing activities (RoPA) for AI

Article 30 requires most organisations to keep a record of their processing activities: the purposes, the categories of people and personal data, the recipients, any transfers outside the UK, the retention periods and a general description of the security measures. Organisations with fewer than 250 staff are exempt only where the processing is occasional, carries no particular risk and involves no special category data, which is rarely the case for AI.

For AI apps, the entries that change most often are the recipients and the security measures. Every app and MCP server an AI tool can reach is a recipient of the data it reads. A record of the calls actually made gives you the real list rather than the one in the project plan.

An AI DPIA template

The ICO publishes a general DPIA template. For AI, add these sections to it:

• AI systems in scope: the apps, the models behind them, and the tools and data sources each can call.
• Data flows: for each tool, what personal data goes in as arguments and comes back in results, and whether it reaches the model.
• Automated decision-making: whether any output is acted on without a person, and what Article 22 requires if so.
• Controls on the tool boundary: redaction, blocked actions, switched-off tools, and the record of every call.
• Monitoring: how you will know if the AI starts doing something the DPIA did not cover.

Where ContextGate's record helps

ContextGate is one MCP connection your AI apps share. Every tool call through it is recorded with the AI app, the user, the tool, the arguments, the result after redaction and the policy outcome. For the DPIA and the RoPA that gives you three things you otherwise reconstruct by hand: which types of personal data were redacted in tool results (for the categories of data), which apps and MCP servers the calls went to (for the recipients), and the redaction, blocking and access controls in force (for the security measures).

The lawful basis, the necessity argument, the risk judgement and the sign-off stay with you. ContextGate sees only the tool calls that go through it, not an AI app's built-in tools or the chat itself.