UK AI data policy needs a worked example, not a slogan

A consultation response is weak evidence when it begins with “regulation is holding us back”. The useful unit is a decision that another person can reconstruct: what the business tried to do, which data had to move, what stopped or changed the plan, and what would have happened under a different control.

On 15 July 2026, the UK Department for Science, Innovation and Technology opened a call for evidence on data regulation and AI. It closes at 11:59pm on 9 September. The document does not merely invite views. It asks for short case studies, governance processes, operational implementation detail and examples of work that organisations pursued, abandoned or remain unsure how to approach.

That is a narrow opportunity for SMEs. A small business may not have a policy team, but it often has the exact evidence the exercise needs: a customer-support pilot that could not use historic tickets, an agent that was denied access to a shared drive, a forecasting project that lacked permission to reuse supplier data, or a model evaluation that exposed an unmanageable correction process.

Start with the decision, not the regulation

The call covers access and use, quality and accuracy, governance across organisations, transparency and rights, and the overall effectiveness of data frameworks. An SME does not need to answer all five themes. DSIT says a focused response on one relevant theme is welcome.

Choose one project with a recorded decision. A decision is more informative than a concern because it has a date, an owner and a consequence. “We worry about data protection” cannot show whether the difficulty came from law, incomplete guidance, a supplier contract, security architecture or an internal refusal to accept uncertainty. “On 4 June, we removed six years of support tickets from the pilot because we could not separate customer messages from employee notes” can.

Build the first page as a reconstruction:

Field	Minimum evidence
Intended outcome	The task, user and measurable operational result
System boundary	Supplier, model or service, integrations and deployment route
Data route	Source, categories, people represented, location, recipients and retention
Decision point	What was approved, narrowed, paused or rejected, by whom and when
Stated reason	The rule, guidance, contract term, technical limit or risk judgement cited
Control attempted	Minimisation, filtering, access restriction, human review, synthetic data or another safeguard
Result	Time, cost, scope, performance or risk effect after the decision
Counterfactual	What the team could have done if the stated constraint changed

Source: Flint Brief evidence template derived from the DSIT call’s request for worked examples, decision-making processes and technical, organisational and contractual detail. Last verified 2026-08-05.

Do not write the legal conclusion first and reverse-engineer the facts around it. Preserve the sequence in which the business actually learned things. A supplier may have changed its terms after the first test. A dataset thought to be anonymous may have contained free-text identifiers. A security review may have exposed a data export that the procurement form did not mention. Those discoveries are part of the evidence, not embarrassing noise to edit out.

Distinguish the source of the constraint

The consultation asks whether uncertainty and legal risk discourage adoption, but not every stopped project proves that regulation caused the stop. A credible response separates at least five possible constraints.

Constraint	Question to answer	Evidence to attach or summarise
Legal requirement	Which provision or principle was considered, and how did it apply to this data use?	Dated assessment, advice or decision note
Regulatory uncertainty	Which interpretation remained unclear after available guidance was checked?	Questions asked, sources reviewed and conflicting readings
Supplier constraint	What did the service retain, reuse, expose or prevent?	Contract version, settings, architecture and support answer
Organisational risk appetite	What risk did the company choose not to accept despite an available route?	Approval threshold, owner and rationale
Project weakness	Would poor quality, cost, integration or performance have stopped the work anyway?	Baseline, test results, budget and dependency log

Source: Flint Brief classification based on the five consultation themes and the operational detail requested by DSIT. Last verified 2026-08-05.

This classification protects the response from overclaiming. If a vendor cannot delete individual records from a training corpus, that technical limitation may make a rights process impractical; it does not by itself prove that the underlying right is the wrong policy. If the team lacks provenance for the dataset, removing a data-minimisation duty would not create the missing permissions. If the business refuses every residual risk, clearer guidance may not change the decision.

Record mixed causes when they are real. A project can face a lawful-basis question, an unsuitable contract and a weak evaluation set at the same time. The response becomes useful when it explains which change would have altered which part of the outcome.

The survey reveals an evidence gap

The UK Business Data Survey gives the consultation a difficult baseline. Of businesses handling digitised data, 41% reported using AI for at least one purpose in 2025–2026. Yet only 17% of AI-using businesses said they had formal or informal AI policies or guidance. Among the businesses that did have a policy, 62% said it covered AI access to business data and files.

The same survey asked how businesses would feel about data they owned — including documents, images and customer interactions — being used to train external AI models. Seventy-three per cent were uncomfortable and 18% comfortable. The result did not materially change depending on whether the question was asked before or after other AI questions.

That discomfort is politically important but operationally incomplete. It does not say which data categories caused concern, whether the model provider could retain inputs, whether personal data was involved, whether anonymisation was credible, what commercial value the data carried or which contractual control would have changed the answer.

An SME response can add that missing layer. Replace a general attitude with a decision matrix:

Data category	Proposed AI use	Reuse outside the task	Retention	Decision and reason
Public product manuals	Retrieval for staff answers	Contractually excluded	30 days	Approved with source links
Customer support tickets	Fine-tuning a classifier	Supplier requested improvement rights	Unclear	Paused pending narrower terms
Employee case notes	Summarisation	No model training	Seven days	Rejected because access groups could not be preserved
Synthetic test cases	Accuracy evaluation	Allowed	Project life	Approved after disclosure-risk test

Source: illustrative Flint Brief matrix informed by the UK Business Data Survey’s external-model-training question. Entries are examples, not survey findings. Last verified 2026-08-05.

The point is not that every business should reach these outcomes. It is that each answer names the data, the service behaviour and the control. Policymakers can compare that with the relevant rule; another SME can recognise whether it faces the same problem.

Show the control that almost worked

DSIT is asking about privacy-enhancing technologies, synthetic data, access models, provenance, metadata and governance across supply chains. A response is therefore stronger when it describes the attempted repair, not only the barrier.

For data minimisation, record what was removed and what performance changed. For purpose limitation, show the original collection purpose and the proposed AI use rather than saying the purposes were “compatible” or “incompatible”. For access control, state whether permissions survived export, indexing, prompt construction, logging and human support. For rights handling, test whether one person’s record could be found, corrected and deleted across the full route.

The ICO’s AI guidance is organised around lawfulness, fairness, transparency, purpose limitation, minimisation, accuracy, storage limitation, security and accountability. Its risk toolkit is designed to help organisations reduce risks to rights and freedoms in their own AI systems. The ICO also flags that the guidance is under review following the Data (Use and Access) Act. That makes a time-stamped account important: note which version of the guidance the team used and which question remained unresolved on that date.

A useful “almost worked” control might read like this:

• the team excluded direct identifiers before transfer;
• it then found that free text still contained names, health details and complaint histories;
• automated redaction removed too much context for acceptable classification accuracy;
• manual review would have cost 180 hours before the pilot;
• a synthetic dataset preserved the workflow test but could not establish production accuracy;
• the project was therefore limited to routing low-risk public queries while a separate lawful production route was assessed.

This description lets DSIT see the trade-off between protection, engineering effort and project value. “Anonymisation was too hard” does not.

Quantify the counterfactual carefully

Every barrier claim needs a counterfactual: what would the business have done if the disputed condition were different? Keep it plausible.

Measure direct effects where records exist: legal-review cost, engineering days, vendor fees, delayed launch, reduced dataset size, accuracy movement, number of users excluded or manual cases retained. Separate incurred cost from an estimate. State the range and method behind forecasts.

Then test alternative explanations. If the company received perfect regulatory guidance tomorrow, would the supplier still refuse the required contract term? Would the integration still fail? Would the model still miss the quality threshold? Would the business have the staff to monitor it? If the answer is yes, regulation is not the whole counterfactual.

The Data (Use and Access) Act 2025 already made targeted changes to the UK data framework. The current call may inform guidance, targeted changes or broader reform, but it does not suspend existing duties. A response should therefore avoid pretending that a future policy choice has already been made. Describe the present route, the specific uncertainty and the result a defined change could produce.

Assemble a submission pack in one afternoon

The final response can be short if the evidence behind it is controlled.

1. Select one AI project with a real decision and a named owner.
2. Freeze the factual record: date, system version, supplier terms, data sources, flow and intended outcome.
3. Identify the consultation theme that best matches the decision.
4. Separate personal from non-personal data and identify mixed or uncertain categories.
5. List the exact legal, technical, contractual and organisational constraints considered.
6. Describe one control attempted and the evidence of what it changed.
7. Quantify the decision’s effect and test a credible counterfactual.
8. Remove personal data, privileged advice and trade secrets that are not necessary to explain the example.
9. Ask a technical owner and a business owner to verify the same account.
10. Submit only the relevant theme before 11:59pm on 9 September 2026, retaining the source record and final copy.

The most valuable SME contribution may be a project that never launched. A documented “no” can show exactly where data law protected people, where supplier design made compliance impractical, where guidance failed to resolve a decision, or where regulation was blamed for an ordinary delivery problem. That is evidence a policy team can use — and a better internal record even if the law never changes.