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.
The last piece in this series argued that a permissions section has to name the task and the safeguard in the same sentence: "AI-assisted drafting of donor correspondence is permitted, provided a named staff member reviews the output before it is sent." That works cleanly for one permission. It stops working the moment an organisation has a dozen roles and several dozen permitted tasks between them, because a policy that states each one as a full sentence in prose becomes a document nobody can actually search when they need an answer on a Tuesday afternoon.
This piece is a template for the artefact that actually does the work at that scale: a single table, one row per role and task, with four columns that carry everything the earlier prose sentence carried, in a form someone can scan in seconds.
A programme officer who wants to know whether she can use AI to draft a donor update should not have to read six paragraphs of policy to find the answer. A table lets her find her role, scan down to the relevant task, and read the safeguard in one line. The same property that makes a table faster for staff to use makes it faster for a DPO to audit and faster for a new starter to learn from: everything is in one place, in the same shape, row after row.
Each row exists to answer one question: can this role do this task, and if so, under what condition. Four columns answer that completely; fewer than four and something load-bearing gets left implicit.
A table only works if every row fits on one line. The moment a row needs a paragraph of caveats, it has stopped being a table and become an annex waiting to be written.
A table forces brevity, and brevity is exactly what makes it usable, but the same discipline means a genuinely complex permission, one with multiple conditions, exceptions, or a decision that depends on judgement rather than a fixed rule, does not belong in a single row. Forcing it in produces a row that is technically present but practically useless, because nobody can act on four columns' worth of caveats crammed into a cell. The honest answer is that the table is the right tool for the common, repeatable cases, and a case that will not fit in one line is a signal to escalate it to its own annex rather than to compress it until it loses its meaning.
Build the permitted-use table with exactly four columns, role, task, safeguard, and data boundary, keep every row short enough to read in one glance, and move anything that will not fit into a dedicated annex instead of compressing it into an unusable cell.
No external statistic cited; this article presents an internal template rather than third-party evidence.
If 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.