A short checklist of decisions an AI policy should never delegate, such as ending employment, safeguarding judgements and legal signatures, and why keeping the list short protects the rest of the policy.
The last piece in this series set out the permitted-use table: one row per role and task, four columns, safeguard named in the same line. That table handles the common, repeatable cases well. It is the wrong tool for a small number of decisions that should never appear in it at all, however good the safeguard column looks, because for these the safeguard cannot be "reviewed by a named person before it goes out." The decision itself has to be made by a specific accountable person, and no amount of AI assistance upstream should be able to shift where that judgement actually happened.
An earlier piece in this series used the phrase "red lines" for HR specifically, because HR carries more of them than most departments. This piece generalises the idea into a checklist any organisation can apply, whatever department the decision sits in.
Sensitivity alone is not the test. A lot of work feels sensitive, donor correspondence, board papers, safeguarding-adjacent research, and this series has already shown most of it is safely delegable with the right safeguard. The test for the red-line list is narrower and harder to satisfy: is the output itself the decision, not a draft of one, and is there no realistic way for someone downstream to catch and correct an error before it takes effect. A grant report can be checked before it is sent. A termination decision, once acted on, usually cannot be quietly reversed without real damage already done.
A safeguard that says "reviewed before it goes out" works for most of this series. It does not work here, because the review cannot un-happen the decision once it has already been made.
A red-line list padded out with anything that feels uncomfortable quietly re-imports the exact problem this series argued against at the start: a policy dominated by prohibitions gets routed around rather than followed. The honest answer is that the list has to stay short and hard to argue with, four or five categories, not forty, precisely so that everything not on it can genuinely live in the permitted-use table with a real safeguard instead of migrating into a grey zone nobody enforces. A red-line list that tries to cover every uncomfortable case stops functioning as a red-line list and starts functioning as the ban-first policy this whole series was written to replace.
Keep the red-line list to decisions where the output is itself the decision and a mistake cannot be meaningfully corrected downstream, employment endings, safeguarding disclosures, legal signatures, and named-accountability calls, and resist the pull to lengthen it, because every category added there is a category quietly removed from the permitted-use table that was doing the real work.
No external statistic cited; this article presents an internal checklist rather than third-party evidence.
A template for the permitted-use table in an AI policy: one row per role and task, with four columns for role, task, safeguard and data boundary, so staff can find answers in seconds.
AI Use Policy · 3 minGuide · 18 September 2026Which HR tasks can be delegated to AI, such as scheduling, job posting drafts and aggregated survey themes, and why hiring, discipline, grievances and individual personal data stay with named humans.
Team AI Training · 4 minIf this is the question on your desk, a thirty-minute call tells you whether the service fits, or that you do not need us yet.