Our Software Just Added AI Features: Does That Change Our Risk?

Usually yes, though not always materially. The risk changes when the feature moves your data somewhere new: to a model provider acting as a fresh subprocessor, into another jurisdiction or into training data. It changes little when the feature runs inside infrastructure the supplier already used on data they already processed.

Suppliers are adding AI features to products organisations already run, and none of it went through procurement because the tool was already approved. This page is for IT managers, DPOs and security leads working out whether a supplier’s AI announcement changes their risk position.

What specifically changes when a supplier adds AI to a tool we already use?

Four things typically change, and they change independently of each other. Data flows shift first: your records may now leave the supplier’s platform and travel to a model provider such as OpenAI, Anthropic or Google, or to the supplier’s own hosted model in a different region. The subprocessor list changes second, because a model provider added behind the scenes is a new subprocessor under UK GDPR Article 28 and you are entitled to notice of it. Training use and output risk change third and fourth: some suppliers default to using customer content to improve their models, and a summarisation feature that drops a material clause creates a decision risk that did not exist last week.

Where do we look to find out what actually changed?

Start with four documents, in this order.

• The release notes or changelog, which tell you what shipped and often which model powers it.
• The updated Data Processing Agreement or DPA addendum, which gives the legal position on processing and training.
• The subprocessor list, usually a separate page the supplier maintains, which tells you who else now touches the data.
• The trust or security centre, which covers hosting region, retention and certification scope.

If the supplier published an AI feature without touching any of those four documents, that is itself a finding. Our AI Security Gap Analysis covers this class of undocumented change across a tool estate.

Should we opt out of the AI features?

Opt out when three conditions hold: the feature processes special category data or legally privileged material, the supplier’s default permits training use, and you have no documented business case for the feature. That combination gives you exposure with no offsetting benefit. Do not reflexively opt out of everything, because blanket refusal pushes staff towards consumer AI tools on personal accounts, which is a worse position than a governed supplier feature. Where an organisation says no without offering a sanctioned alternative, Shadow AI is the predictable result.

When is it fine to leave the AI features enabled?

When the processing stays inside the supplier’s existing boundary, training use is contractually excluded, the data class is not sensitive and the output is advisory rather than determinative. A meeting-notes summariser operating on internal project calls, hosted in the UK or EEA, with training use excluded and a human reading the summary before anyone acts on it, is a low-risk feature. Record the decision, note the date and the version you assessed, then move on. Governance effort should be concentrated where the consequences are, because treating every AI feature as equally risky is how AI governance programmes lose credibility with the business.

Does an embedded AI feature bring us into scope of the EU AI Act?

Possibly, and it depends on use rather than on the feature itself. Under the EU AI Act, obligations attach to the role you play and the purpose the system serves. Deploying a general-purpose assistant for internal drafting carries light obligations, while using an AI feature inside an HR or recruitment tool to screen or rank candidates places you closer to the high-risk classification. The practical point is that suppliers ship features horizontally and you deploy them in specific contexts, so your classification comes from your context.

How should we update our AI inventory when this happens?

Treat the supplier update as a new inventory entry rather than an amendment to the existing tool record. You want to know which feature, which underlying model, which date, which data classes and which decision you took. If you find you have no AI inventory, only a software asset register that does not distinguish AI capability, building one from the changelogs of tools you already run is a workable starting point. ISO 42001 expects this inventory as a foundation control, and auditors will ask for the date-stamped assessment behind each entry.

What should we ask the supplier?

Six questions, in writing, to the account manager. Slow or partial answers tell you where to focus your follow-up.

• Which model or models power the feature, and which provider hosts them.
• Whether our content is used for training or fine-tuning, by default and under any configuration.
• Which subprocessors were added, and when the list was updated.
• Where the processing happens geographically.
• What the retention period is for prompts and outputs.
• Whether an admin-level control exists to disable the feature per workspace or per user group.

The longer form of this question set sits in what to ask suppliers about their AI.

Do we need to redo our DPIA?

Review it, and update it if the answers to the supplier questions changed any of your original assumptions about data flows, subprocessors or automated decision-making. A new subprocessor in a new jurisdiction is a material change. A feature that generates text a human then reviews and edits is usually not. Record the review even where nothing changed, because an undocumented decision reads the same as no decision.

Related reading: what to check before deploying an AI tool company-wide, employees using ChatGPT at work and AI Behaviour Verification for features where the output itself carries the risk. Contact us to discuss a review of your estate.