If you installed an AI plugin on a client site, you are in a processor chain

Installing an AI plugin on a client's WordPress site sends their data to a third party you probably have not contracted with. Your client is the controller, you are the processor, and the AI vendor is a sub-processor. That means a DPA, a privacy notice that names the vendor, and telling the client before it goes live.

The bit nobody drew on the architecture diagram

Here is the sequence that happens the moment you activate an AI chat widget, an AI product description generator, or an AI support triage plugin on a client site.

A visitor types something into a form or a chat box. Maybe it is "do you deliver to Aberdeen", maybe it is their order number, maybe — because people are people — it is their full name, their email and a description of a medical complaint. The plugin picks that up. The plugin sends it, over the open internet, to an AI vendor's API. The vendor processes it and sends a response back. The plugin renders the response on your client's site.

That is four parties in a data flow: the visitor, your client, you, and the AI vendor. Possibly five, and we will get to the fifth, because it is the one that catches agencies out.

None of this is exotic. It is the same shape as adding a new email service provider or a new CRM to a client stack — something you would almost certainly have raised with the client, because it obviously involves their customer data. The reason AI plugins slip through is that they arrive as a plugin. You install plugins all day. It does not feel like a supplier decision. It is one.

Who is who, in plain terms

The client is almost always the controller. It is their site, their customers, their commercial purpose. They decide the data gets collected and why.

You are almost always a processor. You run the care plan, you have admin access, you make technical changes on their instructions. Most agencies are also controllers for a slice of things — your own billing records, your own contact database — but for the site data you handle on the client's behalf, you are the processor.

The AI vendor is a sub-processor. You engaged them, by installing the plugin, to process data that belongs to your client's controller relationship. Under UK GDPR Article 28, a processor cannot bring in a sub-processor without the controller's authorisation — either specific authorisation for that vendor, or general written authorisation with notice of changes. And you remain fully liable to the client for what that sub-processor does.

That last clause is worth sitting with. If the AI vendor has an incident involving data that went through the plugin you installed, your client's recourse is to you.

There is a wrinkle worth naming: sometimes the client contracts the AI vendor directly, via the plugin's own terms, using their own API key on their own account. In that case the vendor is arguably the client's processor rather than your sub-processor. The wrinkle does not get you off the hook — you still installed it, you still chose it, and if nobody wrote any of this down, nobody can prove which arrangement applies. Ambiguity is not a defence; it is just an undocumented position.

What you actually need

Four things. None take long once you have done the first.

A DPA with the AI vendor. Most major AI vendors publish one. Some require you to accept it explicitly in account settings rather than it applying by default — check, do not assume. Read the sub-processor list and the international transfer section, because that is where the next question lives.

Know the transfer position for the specific vendor you are using. If the vendor is outside the UK, your client is making a restricted transfer, and the lawfulness of that depends on the mechanism the vendor relies on. Some rely on the Standard Contractual Clauses, which are an Article 46 safeguard — and relying on Article 46 obliges the exporter to complete a transfer risk assessment, under ICO guidance that took effect in February 2026. Others may be covered by adequacy regulations, including the UK Extension to the EU–US Data Privacy Framework, in which case no TRA is needed. This genuinely varies vendor by vendor. Do not take a blanket position either way; go and read what your vendor actually says.

The client's privacy notice needs to name the recipient. Under Articles 13 and 14 the controller has to tell data subjects about the recipients or categories of recipients of their personal data. If your client's privacy notice was written in 2022 and lists their host, their email provider and Google Analytics, it does not cover the AI vendor you added last month. This is a five-minute edit that nobody does.

The client's record of processing needs updating. Article 30. If they have a ROPA — and if they do not, that is a separate conversation — the new processing activity and the new recipient belong in it. You should be keeping your own Article 30(2) processor record too, listing the sub-processors you use across client sites. That record is also, conveniently, the exact document you would want if a client's auditor ever asks.

And underneath all four: tell the client before it goes live, not after. Not because of a specific clause, but because "we added a supplier to your customer data flow and mentioned it eight months later" is a conversation that costs you a retainer.

The awkward one: plugins that ship with the developer's own API key

A meaningful number of WordPress AI plugins do not ask you for an API key at all. You install, you activate, it works. Free tier, maybe a credits system, maybe a subscription paid to the plugin developer rather than to the AI vendor.

That is only possible because the calls go through the developer's infrastructure. Which means the data path is: visitor → client site → plugin developer's server → AI vendor → back. The plugin developer is in the chain. They are a sub-processor. And you very likely have no DPA with them, no visibility of where their server sits, and no idea whether they log prompts, retain them, or use them for anything.

Ask three questions of any plugin in this category:

• Does the request go through your servers, or straight from the site to the AI vendor?
• Which AI vendor, which region, and do you publish a DPA?
• Do you retain prompt or response content, and for how long?

If the plugin's documentation cannot answer those, that is your answer. You do not have to rip it out today, but you cannot in good conscience tell a client that data flow is understood.

Run this against every client site this week

1. List every site on a care plan. Spreadsheet. One row per site.
2. For each site, list the active plugins that call an external AI API. Chat widgets, content generators, support triage, image alt text tools, spam filters with "AI" in the name, SEO plugins with content suggestions. Look at outbound requests if you are unsure.
3. Record which AI vendor is behind each, and whether the key is yours, the client's, or the developer's. The third case gets a flag.
4. Record what personal data can reach it. Form submissions? Chat transcripts? Order data? Comment content? Be specific — "customer name and enquiry text" beats "some data".
5. Confirm you have a DPA with each vendor and each intermediary. Link to it in the sheet. If there is not one, the row is red.
6. Check each vendor's stated transfer mechanism and note whether that puts a TRA obligation on your client.
7. Open each client's privacy notice and search it for the vendor's name. If it is not there, draft the paragraph.
8. Check the client's ROPA lists the processing activity. If they do not have one, note it and raise it separately.
9. Update your own processor record with the full sub-processor list, per client.
10. Send each client a short note. What is installed, what it does, what data it touches, who else is now in the chain, and the two documents you have drafted for them. Three paragraphs is plenty.
11. Add step 2 to your plugin approval process so the next AI plugin does not go live unassessed.

Half a day for a ten-site portfolio, probably less once you have done the first three.

This is not an argument against AI plugins

It is an argument for documenting them.

AI features on client sites are genuinely good. They deflect support tickets, they speed up content, clients like them. Nothing above says do not ship. It says: know what is in the chain, have the paperwork, and tell the client.

And here is the commercial bit, since you are running a business rather than a compliance function. Almost nobody in the WordPress agency market is doing this. A client who has been told, clearly and in writing, which suppliers touch their customer data and what documentation exists for each is a client who has just received something their previous agency never gave them. That is a line item. Charge for the audit, charge for the annual review, charge for the drafted notice updates. The agencies that treat data flow documentation as a deliverable rather than an overhead are the ones with defensible retainers.

Where we fit

We build AdminAI, a WordPress plugin that runs Claude through our own gateway on AWS Bedrock in London rather than calling a US API. Agencies on it get a per-client processing location attestation naming the specific sites — a document you can forward to a client without rewriting it.

Two honest caveats. You can build this yourself: Bedrock in London is self-serve, and if you have someone comfortable with AWS IAM it is an afternoon's work. And EU hosting is a perfectly lawful answer for UK GDPR, since UK-to-EEA transfers are covered by adequacy — so if nothing in your client contracts or procurement questionnaires specifically asks for the UK, a Dublin or Frankfurt endpoint is a reasonable choice and we will say so. Where the UK answer earns its keep is public sector work, financial services security reviews, and clients whose own contracts name the UK.

Either way, the checklist above is worth running this week. It is free, and it is the part that actually protects you.

dijitul Ltd is not a law firm and this is not legal advice. Documents we provide are drafts for your own adviser to review and adopt.

This is general information about how the rules work, not legal advice about your circumstances. If a decision turns on it, take advice.