Secure AI adoption checklist

Use this checklist to get from "people are using AI tools somewhere" to "we know what is in use, what data goes into it, who can do what, and what we do when something goes wrong". It is ordered the way most organisations need to tackle it. You do not need to finish a section before starting the next, but do not skip the first two.

Tick items as you go. Print it, or download the Markdown version and put it in your own tracker.

Not legal advice. This is general good-practice guidance, not a compliance certificate and not advice for your specific circumstances. Check legal obligations with a qualified adviser.

1. Ownership and scope

Someone has to own this, or it will not happen.

• A named person is accountable for AI use across the organisation (this can be shared with IT, security, data protection and legal, but one name should lead).
• You have written down what "AI" covers for you: chatbots, AI features inside existing software, coding assistants, browser extensions, and AI agents that can take actions.
• Senior leaders have agreed how much risk the organisation will accept from AI and who can approve exceptions.
• You have a short acceptable-use policy and staff know where to find it.

2. Shadow AI discovery

You cannot protect what you do not know about. Start by finding out what is already in use.

• Ask staff, without blame, which AI tools they use and for what. A short survey often surfaces more than technical scanning.
• Check what your existing records can show: single sign-on and identity provider logs, expense claims, browser extension lists, DNS or web-proxy logs, and the OAuth apps connected to your email and file storage.
• List AI features that suppliers have switched on in software you already use.
• Record each tool: purpose, owner, who uses it, what data goes in, whether it can take actions, and whether it is approved.
• Give people a quick, safe route to get a useful tool approved. Banning without an alternative pushes use out of sight.

3. Data classification and rules

• You have a simple classification (three levels is plenty) with examples people recognise.
• For each approved tool, you have written down which level of data it may receive.
• Secrets are always off limits for chat tools: passwords, API keys, tokens, private keys, connection strings.
• Personal data rules are clear, and a data protection impact assessment is done before AI is used on high-risk personal data processes.
• Staff understand that, as the NCSC puts it, queries to a public AI tool are visible to the provider and may be stored and used to develop the service. Do not submit anything that would be a problem if it became public.

4. Prompt and data-leak controls

• Use business-grade accounts with settings that match your data rules (for example, whether your data is used for training, how long it is kept, and who can see it).
• Consider controls that warn or block when sensitive data is about to be pasted or uploaded. Test them with real examples before relying on them.
• Review what connectors and plug-ins each tool can reach (mailboxes, drives, code repositories, CRM) and remove what is not needed.
• Treat content that an AI tool reads (web pages, emails, documents, code repositories) as untrusted, because it can contain instructions aimed at the AI. See the staff guide to prompt injection and data leaks.
• Do not rely on keyword filters alone. The NCSC warns that prompt injection is different from SQL injection and may never be fully mitigated, so design so that a fooled model cannot do serious damage.

5. Vendor due diligence

• Every AI supplier is put through the same checks as other suppliers that handle your data, plus AI-specific questions. Use the AI vendor security questionnaire.
• You know where data is processed and stored, who the sub-processors are, and whether your data trains models.
• Contracts cover confidentiality, breach notification, data return and deletion, and what happens if the supplier changes ownership.
• You ask for evidence (for example independent assurance reports and test summaries), not just badges on a web page.
• You know how the supplier will tell you about security incidents, and how quickly.

6. Access control

• Single sign-on and multi-factor authentication are required for AI tools wherever the supplier supports them.
• Access follows the principle of least privilege: people and agents get only what the task needs, for as long as it needs it.
• Each AI agent has its own identity, not a shared admin account or someone's personal login.
• Credentials used by agents are short-lived where possible and are stored in a secrets manager, not in prompts, notebooks or code.
• Leavers lose access to AI tools and any agents or tokens they created.
• AI provider API keys are treated like cloud credentials: inventoried, scoped, rotated, and monitored for unusual spend.

7. Logging and monitoring

• You log who used which AI tool, and for agents, what they were asked to do, what they did and which tools they called. The NCSC advises logging inputs, outputs and tool calls.
• Logs are kept somewhere an agent or user cannot quietly alter, and are retained for long enough to investigate.
• Agent activity can be attributed to a named owner.
• Someone is responsible for reviewing alerts and unusual patterns, such as sudden spikes in usage or spend.
• You can stop an agent quickly. The NCSC's agentic AI blog describes this as being able to "pull the plug".

8. Human oversight

• You have decided, for each AI use, whether a person approves each action (human in the loop), supervises and can intervene (on the loop), or neither (out of the loop). Higher-impact uses need more oversight.
• Reviewers have the authority and the time to change or reject an outcome, and know the limits of the system.
• AI is not the sole basis for decisions with significant effects on people.
• High-impact agent actions (payments, deletions, permission changes, publishing, installing software) require explicit approval.
• Staff are trained to check AI output rather than trust it.

9. Secure build and supply chain (if you build or integrate AI)

• You follow a recognised secure development approach, such as the NCSC guidelines for secure AI system development and the UK AI Cyber Security Code of Practice.
• You threat-model AI features, including prompt injection, data leakage, excessive agency and model or dependency compromise (the OWASP Top 10 for LLM Applications and MITRE ATLAS are useful references).
• You pin and verify dependencies and container images (use hash-pinned lockfiles and image digests rather than floating tags) and restrict outbound network access from build and runtime environments. Microsoft recommends these steps in its analysis of the October 2026 LiteLLM compromise.
• You test AI features for abuse before release and after significant changes.
• Sensitive actions are controlled by deterministic safeguards outside the model, not by instructions in a prompt.

10. Incident response

• Your incident plan covers AI-specific scenarios (data pasted into an unapproved tool, agent misuse, compromised AI keys, deepfake payment fraud). Use the AI incident response mini-playbook.
• Staff know how to report an AI-related incident and are not afraid to.
• You know who decides whether to notify the ICO, customers, insurers or a regulator, and the deadlines involved.
• You can rotate credentials quickly, including AI provider keys.
• You rehearse the plan at least once a year.

11. Review and improve

• The tool inventory is reviewed at least quarterly.
• Policies are reviewed when AI capabilities change, especially when tools gain the ability to act.
• You track the regulatory and guidance landscape. Our UK and EU AI regulation tracker is one place to start.
• You consider a recognised management system standard such as ISO/IEC 42001 if you need a structured, auditable approach.

A realistic first 30 days

1. Week 1: name an owner, agree the scope, run the staff survey, and publish a short interim rule: "Do not put secrets, personal data or confidential information into AI tools that are not approved."
2. Week 2: build the first tool inventory from the survey, identity logs and connected apps. Approve a small set of tools that fit the most common needs.
3. Week 3: publish the acceptable-use policy, set data rules per tool, switch on single sign-on and multi-factor authentication, and remove unneeded connectors.
4. Week 4: brief staff using real examples, add AI scenarios to your incident plan, and set up logging for anything that can take actions.

Optional, from Pyralink. Item 4 mentions controls that warn before sensitive data is pasted into AI tools. Pyralink's AI Paste Guard is a Chrome extension that does this: it checks what is pasted into AI chat prompt boxes and warns first, and the checks run on the device. This checklist works whether or not you use it.