What "responsible AI use" actually means for a civil servant: a practical checklist

"Responsible" is a compliance word, and that's why it gets ignored

Last year the Cabinet Office ran One Big Thing on the theme of "AI for All", with the stated aim that every civil servant becomes a more confident and responsible user of AI. It's a good aim. It also cited a number worth sitting with: only 28% of civil servants felt confident using AI at work. So most people are being asked to be responsible with a tool they don't yet feel able to use.

Here's the problem with the word. "Responsible" arrives in a slide deck, next to a photo of a lock, and your brain files it under things that are somebody else's job. Nobody explains what it changes about the next hour of your work.

So swap the word out. Responsible use means doing work you'd be happy to defend. If a colleague, a minister's private office, or a member of the public asked how that paragraph got written and where that number came from, you'd have an answer you weren't embarrassed by. That's the whole test. Everything below is just how you pass it.

One thing I want to be straight about before we go further. I'm not a lawyer and I don't know your department's rules. Rules vary a lot between departments, and the ones that bind you are written by your organisation, not by me and definitely not by whoever built the tool. What follows is behaviour, not law. Where I say "check", I mean check with your own policy and your own data-protection people.

Habit one: judgement. Know what to hand over and what to keep

AI is very good at the shaping work that eats your week. Turning six pages of notes into a summary. Getting a first draft of something out of your head and onto a page so you can argue with it. Rewriting a paragraph for someone who won't read three. Suggesting what you might have missed. Explaining a policy area you've just been dropped into.

It is not the thing that decides. This is the line I'd hold hardest: never hand an AI the final decision on anything that affects a person's life, their money, or their access to a service. Not a grant. Not a case. Not an eligibility call. Not a sanction. The tool can help you think. It cannot be the one who chose, because it cannot be accountable, and you can.

In practice that means the answer to "can I use AI for this?" is usually about which part of the task you're handing over. Drafting the letter, yes. Deciding whether the person gets the thing the letter is about, no. Summarising twelve consultation responses so you can read them faster, yes. Concluding what the consultation says without reading them, no.

• Fine to hand over: first drafts, summaries, reformatting, plain-English rewrites, "what have I missed here", explaining an unfamiliar area, drawing up options for you to weigh.
• Keep for yourself: the decision, the judgement call, the sign-off, and anything where a person is on the receiving end of the outcome.
• Ask before you assume: anything involving personal data, anything sensitive, anything that would end up outside your organisation.

If you can't tell which side of the line you're on, that uncertainty is itself the signal. Ask someone. Nobody has ever been disciplined for asking.

Habit two: verification. It will be confidently wrong

This is the one people underrate, and it's the one that will actually get you. An AI model states things with total confidence whether or not they're true. It doesn't sound unsure when it's wrong. It sounds exactly the same as when it's right. There's no tell, no hedge, no little wobble in the voice. That's what makes it dangerous in a way that a bad search result isn't.

Public sector work has to be defensible. Someone can ask where a figure came from. Someone can ask which guidance you relied on. If you couldn't explain the provenance of an answer, you can't use the answer. That's not a policy I'm inventing; it's just what your job already requires, applied to a new tool.

So check before you act. Not check everything, forever, at the same intensity. Check in proportion to what happens if it's wrong. A tone tweak on an internal email needs no verification. A statistic in a submission needs you to go and find that statistic at source and read it yourself. A statement of what a piece of guidance says needs you to open the guidance.

The uncomfortable truth is that the biggest risk here isn't a dramatic breach. It isn't a headline. It's much quieter than that: a plausible, confident, wrong sentence that nobody checked, sitting in a document that gets forwarded upward and reused. It doesn't feel like a failure at the time. It feels like a productive afternoon.

• Never paste a fact, figure, quote, legal reference or citation into your work without seeing it at source. Models can produce references that look completely real and do not exist.
• Ask the model to show its reasoning, then read the reasoning rather than the conclusion. If the reasoning is thin, the conclusion is decoration.
• Treat a first answer as a hypothesis. Push back on it. "What's the strongest argument against this?" often gets a better answer than the first reply did.
• If you find yourself thinking "that sounds right", stop. Sounding right is exactly the failure mode.

Habit three: data and disclosure. Know what goes in, and be able to say what you did

Two questions here, and I can only tell you honestly how to handle one of them.

The first is what you're allowed to put into the tool. I can't answer that for you, and neither can the vendor's marketing page. Different departments run different tools under different arrangements, and what's fine in one is not fine in another. So the answer is: find your department's guidance, read it once properly rather than skimming it, and know who your data-protection contact is before you need them. If you're about to type something in and you feel a flicker of doubt about whether it should be there, that flicker is worth more than any general advice I could give you. Stop and check.

The second is disclosure, and this one is a habit you can just adopt. Be able to say how AI was used in a piece of work. Not necessarily a formal declaration on every email. Just this: if someone asked you tomorrow, could you say "I used it to draft this section, then I rewrote it and checked the figures against the source"? If the honest answer would be "I don't really remember what it wrote and what I wrote", you've lost the thread of your own work, and that's a bad place to be defending it from.

The AI Playbook for the UK Government sets out principles for using AI in government, and one of them is about teams having the skills and expertise to implement and use AI properly. That principle is doing a lot of quiet work. Knowing what you can put in a tool, and being able to account for what came out of it, is part of the skill, not an add-on to it.

The checklist

This is the part to pin above your desk. Run it in about fifteen seconds, before you use the output rather than before you open the tool.

• Am I asking it to help me think, or to decide for me? If it's deciding, stop.
• Does anything I'm about to type in belong to a real person, or is it sensitive? If I'm not sure, I check rather than guess.
• Would I be comfortable if my line manager saw this exact prompt? If not, that's my answer.
• Anything factual in this output: have I seen it at source with my own eyes?
• Could I explain, right now, where this answer came from and why I believe it?
• Have I actually read this properly, or have I skimmed something that sounded fluent?
• If someone asked, could I say clearly how AI was used in this piece of work?
• Am I about to send this because it's right, or because it's finished?

That last one catches more mistakes than the rest put together. Fluent output creates a feeling of completion that the work hasn't earned yet.

Responsible use is a skill, not a poster

You cannot become a responsible user of AI by reading a policy, agreeing with it, and returning to your inbox. It's a practical skill, like writing a decent submission or chairing a meeting that doesn't overrun. You get it by doing it, badly at first, on real work, ideally with someone more experienced looking over your shoulder and telling you when you've been too credulous.

That's the case for spending some of your learning time on this properly rather than absorbing it by osmosis. Every civil servant can take up to 5 days of learning a year, and there are free AI learning resources on Civil Service Learning. Most people don't take the days. If you want the argument for booking them, and how to actually get them approved, we wrote that up in the 5 days of learning. And if you want the case for training that puts you in the tool on your own work rather than watching slides about it, that's hands-on Claude and AI training in 2026. The team version is AI and Claude training for public sector teams.

The best users of this stuff I've worked with in government are not the most enthusiastic ones. They're the ones with a well-developed sense of when to stop trusting it. That instinct is learnable. It just takes reps.