Secure AI adoption means putting AI into a business through a controlled route with 5 key elements – a defined use case, a named owner, a documented data flow, tested controls and a plan for what happens after go-live. The aim is to take the value without inheriting the exposure, while moving fast enough that the business does not route around you.
Most organisations struggle with this because the rollout has no owner, the data questions were never asked, and the security review happened after the tool was already sitting in someone’s workflow. By the time anyone looks properly, there are multiple tools in use and no record of who approved any of them.
Two ways an AI rollout goes wrong
The first is that a defined rollout plan is never delivered. A pilot runs for months, a committee reviews it but nobody wrote down what success would look like and the rollout plan was never issued. Meanwhile, the staff who needed the help six months ago have solved it themselves with a free account and a personal email address.
The second is a rollout with no controls built in. Tools go live because a team liked a demo, permissions are wide because narrowing them was fiddly and nothing is logged. This creates the impression of progress initially.
The Office for National Statistics figures for 2023 to 2026 show why both patterns are common. Adoption among UK businesses with 10 or more employees has close to tripled since September 2023, but the average adopting business still uses only around 1.6 AI technologies.
The same ONS release cites research from the Federal Reserve Bank of St. Louis finding that around 36% of UK workers report using AI in their job.
Individual use has outpaced organised adoption and that is where the risk sits.
Start with the use case, not the tool
“How do we use AI” is the wrong opening question. The better start point is narrower – which of our processes is slow, expensive or inconsistent, and is any part of it a text, classification or pattern problem?
Then score the use cases on four things – the value if it works, its feasibility, the effort to integrate it, and the consequence of a wrong output.
The last one defines the governance need, since a tool that drafts internal meeting notes and a tool that ranks job applicants are not the same in terms of risk.
The consequence of an error is what decides how much control the use case needs and whether it touches obligations under the EU AI Act or UK data protection law. Getting that wrong in either direction is expensive because heavy governance on a low-stakes tool wastes the resource you will need later, and light governance on a high-stakes decision is the risk nobody wants.
Keep a written record of the use cases you rejected and why because somebody will ask in six months, usually a regulator or a board member.
The data question comes before the model question
Before anyone selects a supplier, consider what data the system will see, what the lawful basis is for that use, whether any of it is special category data, where it is processed, how long the supplier retains prompts and outputs, and whether inputs are used to train or improve the model.
The reality is that this is a data governance problem because if nobody can say where a dataset came from or who owns it, the AI project has simply been the first project that asked those questions.
Where the processing is likely to result in a high risk to individuals, UK GDPR requires a data protection impact assessment, and the ICO has been clear that it will test the rigour of those assessments rather than their existence. Prompts, outputs and call transcripts are records too, so they need a retention position and a deletion route like anything else.
Buying AI – due diligence that holds up
Most organisations adopting AI are deployers rather than providers, as they buy software from suppliers who are buying model access from someone else, meaning your true visibility is limited.
Ask every supplier the same set of questions, and keep the answers:
- Which model is behind this, who hosts it, and in which region is the processing carried out?
- Are our inputs used to train or improve models by default, and is the alternative contractual or a setting someone can switch back?
- How long are prompts, outputs and logs retained, and can we set that period?
- How will you notify us of a model change, and what testing sits behind it?
- What accuracy and bias testing evidence can you share for the use case we have described?
- Who are your subprocessors, what are your incident notification timescales, and what audit rights and indemnities are on the table?
The UK government’s AI Cyber Security Code of Practice, published at the start of 2025, is a fair reference point since it is written with purchasers of AI services in mind as well as developers.
Build the security in, because AI breaks in new ways
AI systems carry the vulnerabilities you already manage, plus others that behave differently.
The National Cyber Security Centre published its Guidelines for Secure AI System Development in November 2023, endorsed by 19 international partners, covering secure design, development, deployment, operation and maintenance. DSIT’s Code of Practice followed at the start of 2025 and became the basis for ETSI TS 104 223, with implementation guidance in TR 104 128 and work now progressing towards a European baseline standard.
Give any system with tool access the narrowest permissions that let it do its job, and keep write access out of production until it has been tested.
Treat every document, email and web page a model reads as untrusted input, because prompt injection arrives inside content rather than through a login.
Log prompts and outputs so an incident can be reconstructed.
Put a filter and (where the consequence justifies it) a human between the model and anything that sends, pays or publishes.
Oversight, transparency and the dates that land in 2026
Human oversight only matters if the human can actually change the outcome.
A reviewer processing two hundred cases an hour is ineffective so the review step nust have a realistic workload, a route for the reviewer to disagree, and a record of when they did.
The Data (Use and Access) Act 2025 rewrote the automated decision-making rules, and the ICO has been consulting on guidance for the new UK GDPR Articles 22A to 22D. From 12 May 2026, SI 2026/425 places the Commissioner under a statutory duty to produce a single code of practice on artificial intelligence and automated decision-making.
If you have EU exposure, the transparency obligations in Article 50 of the EU AI Act apply from 2 August 2026 – that means telling people when they are interacting with an AI system, labelling deepfakes, and marking AI-generated content.
The marking requirement extends to systems already on the market from 2 December 2026. The full timetable, including the high-risk dates that moved to December 2027, is set out in our article on why businesses need an AI risk assessment.
Your people determine whether this works
The best approach is to write a policy that says what is allowed rather than one that lists what is banned. Publish an approved tools list and give staff a route to request a new tool and answer it in days, because a request queue measured in months encourages shadow AI.
Tell people plainly what happens to what they type – whether it is retained, whether it leaves the UK, and what must never go in. Most data leakage is from somebody who assumed a tool was secure.
Training needs to cover AI security specifically, not general awareness with an AI slide added. ETSI TS 104 223 expects an organisation’s cyber security training programme to include AI security content and to be reviewed and updated as new threats appear.
From pilot to production – the gates that matter
If you did not measure the process before the pilot, you cannot prove the pilot worked. This is the most common reason good AI projects fail to get funded for a second phase.
After go-live, the system needs an owner, monitoring for drift and error rates, a log of supplier model updates, and a review date in the calendar. A new system, a material model change or a new purpose for an existing tool should all trigger a reassessment rather than a conversation about whether one is needed.
A rollout sequence you can run this quarter
- Take an inventory of what is already in use, including AI features switched on inside software you already pay for.
- Publish an acceptable use policy and an approved tools list, with a named route for requesting additions.
- Choose two use cases – one low-consequence one to learn on, and one with real value attached.
- Work through the data questions, and complete a data protection impact assessment where the processing warrants it.
- Run supplier due diligence and fix the contract terms before, rather than after, procurement.
- Build to the NCSC guidelines, set permissions narrowly, and test for prompt injection before launch.
- Pilot against a recorded baseline, with oversight, logging and written exit criteria.
- Move to production with an owner, a monitoring cadence, a review date and the risk register updated.
Frequently asked questions
How long does a secure AI rollout take?
For a first use case in a mid-sized organisation, inventory and policy work usually runs in weeks, supplier due diligence and the data protection work add several more, and a pilot with a measured baseline needs long enough to gather meaningful data. The timeline depends far more on how quickly internal decisions get made than on the technical build.
Should we build or buy?
Buying is the right default for most organisations, because building makes you a provider with a heavier set of obligations and a permanent maintenance commitment. Building is worth considering where the use case is specific to your business, the data is yours, and the advantage is durable. The governance question shifts accordingly – a buyer manages supplier and contract risk, while a builder also owns model documentation, testing evidence and lifecycle management.
Who should own AI adoption internally?
A named business owner for each system, with a single accountable executive across the programme. Splitting it between IT and legal without an owner in the middle is how projects stall. Whoever holds it needs enough authority to say no to a use case and enough credibility with the business to be told about tools early.
What should an AI acceptable use policy cover?
The approved tools, what data may and may not be entered into them, when output must be checked by a person before it is used, the rule on disclosing AI use to customers, the process for requesting a new tool, and who to tell when something goes wrong. Keep it to a length people will read, and make the requesting route genuinely usable.
Is an AI readiness assessment the same as an AI risk assessment?
They answer different questions. A readiness assessment looks at whether the organisation has the data, skills, processes and governance to adopt AI successfully. A risk assessment looks at the systems in use or planned and scores the harm they could cause against the controls in place. Organisations at the start of a programme often need the first, and everyone with AI in production needs the second.
Where to start this week
Pick the one process people in your business complain about most. Write down how long it takes today, how often it goes wrong, and what a mistake costs when it does. That baseline takes an afternoon and it is what turns an AI proposal into a business case you can defend, and later into evidence that the rollout worked.
Then check who already has AI switched on in that process without telling anyone.
Cybercy Group’s AI Governance and Enablement service covers AI strategy, use case identification, ethical AI framework development and performance monitoring. For a faster read on where you stand across cybersecurity, data protection and AI, the Cybercy+ Check gives you a scored assessment and a prioritised report.
