This page covers steps 1 to 3 of our AI governance framework, which also sets out who should own AI governance, a plan for the first 90 days and a minimum version for SMEs. Steps 4 to 6 are in AI data protection, human oversight and security controls.
Step 1: Map what you are already using
Before writing a policy, find out what AI tools are in use. Most organisations find more than expected when they look properly.
Four categories to check
Survey department heads and run a discovery pass across your SaaS estate. The shadow AI risks guide covers the discovery process in more detail. The inventory becomes your control baseline: every tool on it either has a governance record or gets one before it stays approved.
AI tool register: minimum fields
Record each AI tool in a central register. This becomes the living record that your AI governance owner maintains and your auditors or regulators can inspect.
| Field | Example |
|---|---|
| AI tool | Microsoft 365 Copilot |
| Business owner | Head of Marketing |
| Purpose | Content drafting, email summarisation |
| Data processed | Internal business data, employee emails |
| Personal data involved | Yes |
| Vendor | Microsoft |
| Data processing / hosting location | UK / EU |
| DPA in place | Yes, via Microsoft Data Processing Agreement |
| Risk level | Medium |
| DPIA required | Yes, completed 24 Aug 2026 |
| Article 22 assessment | Not applicable (advisory use only, human review required) |
| Approved users | Marketing, Sales (licensed users only) |
| Approval date | 24 Aug 2026 |
| Next review date | 24 Feb 2027 |
Keep the register in a location your AI governance owner and DPO can both access and update. A shared document or a row in your existing risk register works. The format matters less than the discipline of keeping it current.
Map the data flow, not just the tool
A tool name and a risk rating tell you what the AI is, not what it touches. For each entry in the register, particularly anything medium risk or above, trace the path the data actually takes. This is also the version of the register that is useful in board or management reporting, where "what does this tool actually do with our data" is the first question asked.
| Stage | What to record |
|---|---|
| User | Who provides the input, and whether they are a defined role or anyone with a licence |
| AI application | The tool or interface the user interacts with directly |
| Model | The underlying model or vendor providing it, including where it is hosted |
| Data | What data the model can see or is trained on: only the prompt, or connected systems too |
| External systems | Any API, plugin, or third-party system the AI can read from or write to on its own |
| Output | Where the output goes: back to the user, into another system, or directly to a customer |
| Human decision or action | Who reviews the output before it has a consequence, and what they are able to change |
A tool where every stage terminates with a human reviewing the output before anything happens is a materially different risk to one where the AI application can write directly to an external system with no stage in between. The classification framework in Step 2 formalises that difference; this map is what makes the difference visible in the first place.
Step 2: Classify tools by risk
Not every AI tool needs the same level of control. A grammar checker and a CV screening system are both AI, but the governance requirement for each is completely different. The classification framework below uses two axes: what data the tool processes, and what decisions it influences.
Additional classification dimensions
Beyond the three tiers above, four additional dimensions refine the classification and identify where enhanced controls are needed:
- Autonomy level: is the AI purely assistive (draft text for a human to review), advisory (recommends an action), semi-automated (requires human approval to proceed), or fully automated (acts without human intervention)? Treat any system capable of taking an action on its own, sending an email, updating a record, calling another system or API, as a default high-risk classification regardless of how sensitive the underlying data is: the risk in an agentic system comes from what it can do, not only from what it can see.
- External exposure: does the AI process or produce output that goes to customers, partners, or the public, or does it stay entirely internal?
- Regulatory exposure: does the use case fall under a sector-specific regime such as FCA, NHS DSP Toolkit, DORA, or the EU AI Act for organisations with EU operations?
- Data sensitivity: public and non-personal data, internal business data, personal data, confidential or legally privileged material, or special category data such as health or biometric information?
A tool that scores medium on the primary risk tier but also involves full automation, customer-facing outputs, and special category data should be treated as high risk in practice. Use the dimensions to sense-check the primary classification rather than override it mechanically.
Step 3: Write an AI acceptable use policy
An AI acceptable use policy sets the rules staff follow when using AI tools at work. It does not need to be long. A policy that staff can read in five minutes and apply without asking for clarification is more valuable than a comprehensive document that no one reads.
What to include
Assign a named owner for the policy and set a review date. Given how fast AI capabilities and vendor terms change, a six-month review cycle is more useful than an annual one.
Employees may only use AI tools approved by the organisation. Confidential, personal, customer, financial, legal, or otherwise restricted information must not be entered into any AI system unless the tool and use case have been explicitly approved. AI-generated content must be reviewed by an appropriately authorised employee before being used in consequential decisions or external communications.