DSIT AI Management Essentials: a practical walkthrough

AI Management Essentials (AIME) is a self-assessment tool published by the Department for Science, Innovation and Technology. It is aimed primarily at SMEs, but it applies to any organisation that develops, provides or uses AI systems.

Completion is voluntary. The reason to pay attention anyway is commercial: government has been exploring integrating AIME into public sector procurement. If that lands, it becomes a practical requirement for anyone selling to government long before it becomes a legal requirement for anyone at all.

That is a familiar pattern. Cyber Essentials was voluntary too, right up until it appeared in the tender documents.

What it is, and what it is not

AIME is a structured questionnaire covering baseline good practice for managing AI systems. It is deliberately not a technical standard, not a certification, and not an assessment of whether a specific model is safe. It asks whether your organisation has sensible arrangements in place.

It sits alongside two other DSIT-published resources: the Algorithmic Transparency Recording Standard (ATRS), which covers publishing information about public sector algorithmic tools, and the Model for Responsible Innovation. AIME is the management-system layer; ATRS is the transparency layer.

If you know ISO/IEC 42001, AIME will feel like a lightweight relative. That is roughly what it is, and the mapping between them is close enough that AIME work is not wasted if you later certify.

The three themes

AIME is structured around three areas.

1. Internal processes

Does the organisation have defined ways of working around AI, or does each team improvise?

In practice this means: a policy that says which tools may be used with which data; a named owner for each AI system; a route to get something reviewed and approved; and a decision record showing that someone considered the question before deployment rather than after.

The common gap here is not the absence of a policy. It is a policy nobody can follow, so the real process is unwritten and invisible.

2. Managing risks

Have you identified what could go wrong, and is someone accountable for each of those things?

This is where generic technology risk registers fall short, because the AI-specific failure modes are not in them:

• Incorrect output stated confidently. The model does not signal uncertainty in the way a human expert would.
• Drift. The world changes; the model does not. Performance degrades quietly.
• Prompt injection. Untrusted content in a document or web page instructs the model. If your system reads external material and can take actions, this is a live vulnerability, not a theoretical one.
• Over-reliance. Users stop checking, precisely because the system is usually right.
• Data leakage. Sensitive material reaching a tier of tool it was never classified for.

Each needs an owner, a control and a review date. “We are aware of hallucination” is not a risk entry.

3. Communication

Do the people affected know what is happening, and can they do something about it?

Internally: do staff know which tools are approved, and what they are accountable for when they use one? Externally: are customers or citizens told when AI is materially involved in a decision affecting them, and is there a route to challenge it?

This theme is the one organisations score worst on, and it is also the one that most closely tracks actual harm. Most AI failures that reach a complaint, a regulator or a newspaper involve someone who did not know the system was there and had no way to contest it.

How to work through it without turning it into a project

The self-assessment itself is not long. What makes it feel large is discovering how much you do not currently know. A workable sequence:

Week one: count what you have. Build the AI inventory first; nothing else in AIME is answerable without it. Include embedded AI in tools procured as something else: the CRM’s lead scoring, the HR platform’s CV screening, the service desk’s auto-triage. This is where the surprises are, and where the highest-risk uses usually turn out to be.

Week two: answer honestly and record the gaps. The temptation is to answer aspirationally. Resist it: an accurate low score with a dated remediation plan is far more defensible in front of a procurement panel than a high score you cannot evidence. Someone will eventually ask you to show the thing you claimed.

Week three: fix the cheap, high-value gaps. Usually: name owners for each system, write a policy that permits a compliant path rather than only prohibiting things, add AI-specific entries to the risk register, and make sure there is a way for someone to say “this decision was wrong”.

Then leave it alone until something changes. AIME is not an annual ritual with intrinsic value. Revisit it when you deploy something new, when a supplier changes materially, or when a tender asks.

Should you bother?

Yes, and soon, if: you sell to the public sector, you are in a supply chain that does, or AI governance questions have started appearing in your tenders and security questionnaires.

Yes, eventually, if: you use AI on personal data at any scale. The artefacts AIME asks for are largely the ones UK GDPR already requires you to have, so the marginal cost is low and you were going to need them anyway.

Not yet, if: your AI use is genuinely limited to individuals using a public chatbot for drafting, with no systems built on it. In that case, write the acceptable-use policy and come back when that changes, which it will, faster than you expect.

The honest framing

AIME is a floor, not a ceiling. Working through it will not make your AI safe, and it will not satisfy a sector regulator that has its own expectations.

What it will do is force you to write down what you are actually running, who is accountable for it, and what you would do when it goes wrong. Most organisations discover, doing this, that they cannot currently answer the first question, and that is worth finding out from a voluntary questionnaire rather than from an incident.

---

Related reading: UK AI regulation in 2026 covers what actually binds you. If you would rather have the artefacts built than described, that is our AI governance and compliance service.