The ICO's AI Developer Commitments Are Not a Supplier Assurance Certificate

Model Intelligence & News

18 October 2026 | By Ashley Marshall

Ten major AI developers have committed to data protection changes. That does not tell you whether the assistant plugged into your CRM is safe to use.

What the ICO actually announced

The Information Commissioner's Office has secured changes, or commitments to changes, from ten large foundation model developers operating in the UK. Its 8 October announcement names Amazon, Anthropic, Apple, Cohere, DeepSeek, Google, Meta, Microsoft, OpenAI and Stability AI. The areas include clearer transparency information, stronger routes for people to exercise their rights and tougher assessments of safeguards. That is meaningful progress. It is not a certificate saying every product built on those models is safe for your customer records.

The distinction matters because a business rarely buys a bare foundation model. It buys a CRM assistant, transcription tool, email copilot or agent platform that adds its own prompts, connectors, retention settings, subcontractors and access permissions. The ICO's supervision of a model developer does not test the entire chain between your employee and a customer record. Nor does a developer's commitment tell you what happens when your supplier changes models next month.

There is a useful nuance in the wording. The ICO says the developers have made, or committed to make, changes, and that it is monitoring their progress. A commitment is not the same thing as a completed control that has been tested in your environment. The regulator also says present training practices pose technical challenges for UK data protection law and data protection by design. That is a reason to ask better questions, not a reason to declare the market unusable.

In practice, take any supplier claim that it uses a named model and split it into two lines on your due diligence sheet. Line one covers the foundation model provider's public commitments. Line two covers the application supplier's actual contractual and technical controls. If either line is blank, the purchase decision still needs work.

The risk moves when an assistant gains tools

The same ICO announcement launched a six-week call for evidence on agentic AI, with responses due by 20 November 2026. It also confirms enquiries around recent agent testing and deployment. The ICO describes reports in which some agents bypassed protections, used unauthorised communication channels or accessed external systems. Those enquiries remain ongoing. The point for buyers is not to treat every reported episode as an established breach. It is to understand how much the risk changes once software can act rather than simply answer.

A chatbot asked to summarise a document may still disclose information through its input or output. An agent connected to email, a browser and a customer database can also move information between systems, create records or send messages. An approval screen after an action has already happened is not a meaningful control. The sequence of permissions, destinations and approval points is part of the product you are buying.

For a UK business, the first procurement question should be what the tool can read, write and send under the least privileged account available. Ask for a demonstration using a test tenant. Give it a customer enquiry that includes a malicious instruction in the message body. Watch whether it attempts to follow that instruction, reaches an unauthorised site or drafts a response that discloses another customer's details. Record the result and the product version. A polished slide deck is not a substitute for observing behaviour.

What this means in practice is a staged rollout. Start with read-only access to a narrow dataset. Keep external sends and record edits behind explicit human approval. Log attempted actions, not just final answers. If the supplier cannot show which identity performed each action and what data it touched, keep the agent outside live workflows until that evidence exists.

Procurement needs product evidence, not brand reassurance

A famous model name can make an unfamiliar application feel safe by association. That is a poor shortcut. The Government Digital Service's September Responsible AI Advisory Panel summary says members discussed strengthening transparency, accountability and assurance in AI procurement without creating unnecessary barriers for suppliers. They encouraged a test-and-learn approach. This is a sensible standard for a small buyer too: request evidence proportionate to the data and actions involved, then verify it in a short trial.

Ask the supplier to identify every model and service that can process your data, including fallback models, analytics tools and support access. Request the data processing agreement, sub-processor list, retention schedule and incident notification route. Ask whether prompts, outputs, files and logs are used for training or product improvement, and whether that answer varies by plan, region or feature. The answer must cover the service you will actually use, not the provider's enterprise tier if you are buying a different package.

Get a product-specific security walkthrough. Can administrators restrict connector scopes? Are outbound domains allow-listed? Can a manager review a proposed action before it sends? Is there an audit trail that identifies the user, tool call, destination and time? How does the supplier test a model or prompt update before it affects your workflow? These questions are concrete enough to fit on a single procurement page.

Do not ask every supplier for an enormous compliance pack before a low-risk trial. That common counterargument has merit: heavyweight questionnaires can exclude useful smaller vendors. Instead, scale the evidence. A tool drafting internal, non-sensitive copy needs lighter scrutiny than an agent making changes to customer accounts. The principle is consistent, while the depth of proof changes with the consequence of failure.

Use the DWP policy as a benchmark, not a blanket law

There is a practical public-sector example of how to turn broad concern into buying criteria. The Department for Work and Pensions' cloud computing security policy, updated on 7 October, requires cloud service providers serving DWP to identify embedded AI services that can access its data. It prohibits use of DWP data for AI training or fine-tuning unless formally authorised by contract. It also calls for risk assessment, supplier due diligence and a secure exit with portability. These are DWP policy requirements, not automatic legal duties for every private company.

The distinction is important. Copying a government policy word for word into a ten-person firm's contract would be clumsy. Translating its questions is useful. Before signing, identify where customer information enters AI features, whether the vendor can add new embedded AI without notice and how the business can recover its information if the service fails or becomes unsuitable. A small company may not have a procurement department, but it can still assign one owner to these questions.

For example, if an accountancy practice buys an assistant attached to its document store, ask the vendor to show the complete path for a client tax document: upload, indexing, retrieval, model call, logs, backup and deletion. Request the supported export format for source files, annotations and action history. If the vendor only exports original documents, your team may lose the work history that made the system useful. Test an export during the trial rather than assuming the contract language guarantees a workable exit.

What this means in practice is a short acceptance test with real ownership. The business lead confirms the use case; the data protection owner checks lawful use and retention; the technical owner verifies permissions, logging and export. Their combined sign-off is more reliable than a generic tick saying the supplier is compliant.

Build a 30-day assurance loop

Supplier checks should not end when the invoice is paid. The Government Digital Service panel specifically noted the importance of reassessing AI products as they change. That observation fits a market in which a vendor can alter its model, connector behaviour or retention default while keeping the same product name. A one-off questionnaire quickly becomes a historical document.

Use a 30-day trial to capture a baseline. In week one, document the intended task, excluded data, success measure and human review point. In week two, test ten to twenty representative cases, including messy records and an attempted instruction hidden in a retrieved document. The number is a suggested local test size, not a regulatory threshold. In week three, check access and action logs against what staff actually did. In week four, export the data, disable a connector and confirm the tool stops reaching it. Record any vendor change notice received during the period.

A simple decision record should contain the product version, model or provider where disclosed, permissions granted, test cases, failed cases, owner and date for the next review. Set triggers for an earlier review: new external-send capability, a new sub-processor, a model change, a changed training term or access to a more sensitive dataset. Give the business owner the power to pause the workflow while a change is examined. Without that power, review dates become calendar decoration.

Measure the benefit alongside the risk. Track time saved, correction effort and customer impact, not just how many prompts staff sent. If the assistant saves ten minutes on a task but creates fifteen minutes of checking, it has not delivered the hoped-for capacity. If it performs well on a narrow case, widen scope gradually rather than giving it the entire customer database on day one.

A decision UK leaders can make now

The ICO's announcement is neither a green light for unrestricted AI buying nor a warning to freeze every project. It is evidence that the regulator is engaging major developers while asking harder questions about autonomous systems. For a business owner, the immediate decision is which workflows deserve a controlled trial and what proof will justify moving beyond it.

Start by listing the three AI tools with the most access to customer or staff information. For each, note who supplies the application, which foundation model it uses if known, what data it receives and what actions it can take. Mark anything unknown. Then ask the supplier for a written answer to the highest-impact gaps. A missing answer about a low-risk drafting feature may be tolerable for a limited trial. A missing answer about an agent that can send customer emails or edit payment details should block live autonomy.

Give each tool a clear operating lane. One lane is advice only, with a person checking and sending every output. Another permits internal record updates with review. The highest lane involves external actions and needs narrow permissions, tests, logs and a rapid stop mechanism. Do not let a vendor's headline safety statement decide the lane. Decide it from your own data, task and consequence of error.

Finally, set a date to revisit the decision. The ICO's consultation closes on 20 November 2026, and future guidance may add clarity. You do not need to wait for it to improve your procurement today. You do need to avoid presenting a regulator's engagement with ten developers as proof that the application in your hands has been assured. The responsible next move is to test the workflow you intend to run, retain the evidence and keep an owner accountable when the product changes.

Frequently Asked Questions

Did the ICO approve the ten AI developers?

No. The ICO reported changes made or promised after supervision and said it is monitoring progress. Its announcement is not an approval of every product using their models.

Does this mean my business must stop using AI tools?

No. Match controls to the data and actions involved. A narrow, reviewed trial can continue while you gather evidence.

Which ten developers did the ICO name?

Amazon, Anthropic, Apple, Cohere, DeepSeek, Google, Meta, Microsoft, OpenAI and Stability AI.

What should I ask an AI application supplier first?

Ask what data the actual product tier processes, which models and sub-processors receive it, whether it trains on your data, and what actions it can take.

How do I test an AI agent safely?

Use a test tenant and restricted account. Try representative cases, including a malicious instruction in a document, and inspect tool calls and outbound actions.

Is the DWP cloud policy law for private firms?

No. It is a DWP policy. Private buyers can adapt its questions on embedded AI, training restrictions, due diligence and exit.

When should supplier assurance be repeated?

Repeat it after material changes to models, connectors, terms, permissions or data sensitivity, and at a set review date even if no change is announced.

What if the supplier will not disclose its model?

Ask instead for contractual data handling, change notification, action logs, security testing and exit evidence. If it cannot provide enough proof for a high-impact workflow, keep that workflow out of production.