AI Needs Data. But Have We Earned the Right to Use It?
A system’s access to information does not by itself establish that every use is expected, necessary or trusted. The reported NHS objections concern data processing and governance; they should not be misdescribed as an objection to AI model training.
What the NHS story is—and is not—about
On 30 September 2026, The Guardian reported that 44,000 people had registered formal objections to the handling of their information through the NHS Federated Data Platform. The platform is intended to connect operational health information to support care and improve the running of NHS services. The reported concern is about processing, sharing, storage and public confidence in how the platform is governed.
That is not evidence that the dispute is about training an AI model. Collecting or making information available to a service, using it to coordinate care, and using it to train or fine-tune a model are different processing activities. Each has its own purpose and should be described accurately. Do not infer model training unless a source establishes it.
The case matters to businesses because people’s willingness to share information depends on more than a privacy notice. They need to understand who is using it, for what reason, under whose responsibility and with what safeguards. A technically secure system can still lose trust if the purpose or access arrangements are unclear.
Access, use and training are not interchangeable
A business might collect customer details to fulfil an order, store them in a CRM and later connect a search assistant to selected records. Those steps are not automatically the same as sending the data to a model provider for training. A supplier may process input to return an answer while contractually excluding it from training; another product or account setting may have different terms. Check the specific service, configuration and contract.
Information is personal data when it relates to an identifiable person. Replacing a name with a customer number may be pseudonymisation rather than anonymisation if the organisation can reconnect that number to a person. Properly anonymised information falls outside data protection law only when people are no longer identifiable by means reasonably likely to be used. Sensitive information needs particular care.
Data minimisation is practical: give a system only the information needed for the task. A summariser preparing a delivery update may not need a customer’s full payment history. Excluding unnecessary records reduces the consequences of misuse and can improve the relevance of the answer.
Choose a lawful basis and explain the real purpose
Consent is not the only lawful basis under UK GDPR and is not automatically required for every use of personal data. The appropriate basis depends on the organisation, the purpose, the context and applicable law. A public authority, a private company and a health provider may have different obligations. If special-category information is involved, an additional condition may also be required.
The ICO’s right-to-object guidance explains that an objection is not an automatic veto in every case; the controller must assess the request and may continue only where the relevant legal conditions are met. Direct marketing has a distinct and stronger objection right. Organisations should not promise that every objection stops processing, nor dismiss an objection without following the applicable process. The ICO currently says its guidance is under review following changes made by the Data (Use and Access) Act, so check the current guidance before relying on it for a live decision.
For a business AI workflow, record the purpose, lawful basis, data categories, access roles and retention period. Check whether a data protection impact assessment is needed before processing that is likely to create high risk. Privacy explanations should describe the actual use, not rely on vague statements that data is used to “improve services”.
The supplier is part of the data system
Before connecting customer or staff information to an AI product, identify which supplier receives it, which subprocessors may handle it, where processing and storage occur, how long logs remain available and how deletion works. Ask whether inputs or outputs are used for model training, service improvement, abuse monitoring or human review. These are separate questions; a “no training” answer does not resolve the rest.
Check the account tier, product terms and technical settings actually used by staff. Confirm who can access the system, how permissions are revoked, and what happens to records when a contract ends. If the service cannot give a clear answer, do not place sensitive information into it until the uncertainty is resolved.
For a deeper supplier review, see what your business data does when staff use AI and how to assess UK AI data residency. The point is not to demand that every tool use the same architecture; it is to verify that the selected tool matches the organisation’s obligations and purpose.
Trust is a governance outcome
A proportionate review can be concise: map the data flow, remove unnecessary fields, identify the legal basis, confirm supplier terms, limit access, set retention and deletion, and tell affected people what is happening. Assign a named owner who can respond to questions and review whether the original purpose has changed.
Do not treat a public objection as proof that a system is unlawful; equally, do not treat a lawful basis as proof that a use will be accepted. The organisation must meet its legal duties and earn confidence through clear purpose, consistent controls and accountable decisions.
Good AI starts with responsible data use, not simply access to more information. The more sensitive the information and the less expected the use, the more important it is to explain the process and ensure that people can challenge or correct what is wrong.