Create a short AI approved-use list that names allowed tasks, inputs, accounts, reviewers and stop conditions, with a practical check on review capacity.
Direct answer: Approve specific tasks, not entire applications: record the allowed input, account, output, reviewer and condition that stops the task. Keep the initial list short enough that the team can apply it without interpretation, and leave unassessed uses unapproved. If a task needs expertise or review time you cannot supply, restrict it to a fictional-data trial or keep the work manual until that gap is resolved.
“You may use this AI tool” is incomplete permission. It does not tell someone whether they can upload a client brief, connect an inbox or send the resulting advice. Those are materially different uses of the same interface.
Your list should answer the question at the moment of work: is this task, with this information and this destination, within the agreed boundary? It turns the small operating zone in the guide to adopting AI without losing trust into something colleagues can actually consult.
Applies to: a small team's operational instructions. This is an editorial approach, not a substitute for legal, security, contractual or sector-specific requirements.
Build the task permission register
The task permission register is an editorial method for representing each allowed use as a bounded task. One row describes one permission. Related tasks can share the same application but require separate rows when their data, output or consequences differ.
Start with the person authorised to make the decision. In a small business this may be an owner, but ownership does not supply specialist expertise automatically. Bring in the responsible privacy, security or professional adviser where the task requires it.
Ask colleagues for the work they want help with, not a list of fashionable tools. “Reformat a public event schedule” is assessable. “Use AI for operations” is not. Name what remains outside the task, such as changing dates or contacting attendees.
My recommendation is to approve fewer uses with precise boundaries rather than issue broad permission followed by many vague warnings. That can feel restrictive when a team is experimenting quickly. A wider sandbox may be reasonable if it contains only fictional or approved public material and cannot affect live systems, but label that as experimentation, not operational approval.
Make every row answer the same practical questions
Use a shared document the team already has. It needs to be readable, versioned and accessible to the people doing the work; it does not need a new governance subscription.
| Field | Example for a fictional approved task |
|---|---|
| Task | Reformat a published event schedule into a draft table |
| Input boundary | Public schedule text only; no attendee information |
| Service and account | Exact organisation-approved application and account type |
| Output boundary | Internal draft; no automatic publication or messages |
| Required review | Compare every date, time and venue with the source |
| Stop condition | Missing source, conflicting times or request for account connection |
| Owner and review trigger | Named role; reassess if the service, inputs or task change |
Include the relevant settings or configuration where they affect the permission, but verify them against current documentation for your account. A consumer subscription and an organisation's contracted service should not be treated as interchangeable merely because the product name looks similar.
The Home Office's engineering standard provides a concrete institutional example: it separates approved tools, restricted-data handling and human review. Its requirements apply to Home Office engineering; they are not automatically rules for your business. The useful distinction is that choosing a tool does not settle every use of it. Home Office guidance on using AI.
Separate allowed work from restricted experiments
Use plain statuses with distinct meanings. “Approved” means the row's conditions are met for actual work. “Trial only” means the task can be explored within the stated test boundary. “Not approved” means the team must not use AI for it under the present arrangement.
Do not label a task approved while leaving the reviewer or data terms as “to be confirmed”. Those are unfinished decisions. Put the task into the appropriate restricted status until the evidence exists.
For example, drafting generic questions for an internal workshop might be allowed with ordinary human editing. Summarising a confidential client meeting is not covered by that permission. An assistant that can send the summary introduces another boundary again: permission to create text is not permission to communicate it externally.
State how someone asks for an additional use. Require a short description of the task, information involved, proposed output and reason the existing process is insufficient. Give the request an owner and response date so uncertainty does not become an indefinite obstacle.
Keep the original source material and final review record where the team normally manages the work. Avoid making one person's private AI conversation the only explanation of what was approved or changed.
Check that human review is a real resource
A named reviewer must have time, competence and authority to reject the result. Someone who is expected to approve everything immediately is not a meaningful safeguard.
The UK Government's AI Playbook emphasises meaningful human control and the ability to intervene where needed. It is public-sector guidance, not a universal business rule. For your register, translate the principle into an observable responsibility: who checks which details, against what evidence, before the output is used? UK Government AI Playbook.
Consider an illustrative five-person team proposing 13 uses. After assessment, six are approved, four are trial-only and three are not approved. The status count is 6 + 4 + 3 = 13. That says nothing yet about the workload those six approvals create.
Suppose the approved uses produce 30 outputs a week. At four minutes of checking per output, review requires 30 × 4 = 120 minutes. Six exceptions need another eight minutes each, and maintaining the register takes 15 minutes:
120 + (6 × 8) + 15 = 183 minutes a week.
If the actual reviewer has only 120 minutes available, the plan is short by 63 minutes. These figures are illustrative assumptions, not measured performance. The practical response is to reduce the volume, narrow the allowed tasks or allocate more review time, not to assume AI will make the missing hour disappear.
To judge the economics, compare that total with the manual baseline, plus any setup and subscription costs. Review capacity is an operating requirement; it is not automatically evidence of either savings or waste.
Test the wording with real decisions
Before circulating the list, ask two colleagues to apply it independently to a few fictional situations. Include a permitted task, a similar task involving confidential information, a changed account and an output intended for publication.
Ask them to point to the row that supports their decision. If one person approves the scenario and another refuses it, inspect the wording. The disagreement may expose a missing boundary rather than a training problem.
Check that someone can find the stop condition without reading a lengthy policy. Give them a safe alternative, such as completing the task manually or asking the named owner. “Use your judgement” is not enough when the whole purpose of the list is to define an organisational decision.
Also test how approval ends. A changed supplier term, new connector or unavailable reviewer should trigger reassessment where it affects the task. Retiring a row must not delete the source work or remove access before the team has a supported replacement process.
Put a usable first list in place this week
- Today, collect proposed tasks and choose the person responsible for approval. Keep actual customer or employee records out of the discussion document.
- In a focused working session, complete the permission fields for the few tasks you can assess properly. Leave the remainder explicitly unapproved or restricted to a defined trial.
- Before operational use, check the account evidence, review capacity and scenario interpretations. Resolve conflicting readings rather than asking people to guess.
- After the first working week, review the exceptions and unclear requests. Amend the list where evidence supports it and set the next review point.
Stop a use when its required evidence, permission or reviewer is missing. The list should make that decision straightforward, even when the tool is available and the deadline is close.
Related guides
Frequently asked questions
Is this the same as a full AI policy?
No. The register is an operational list of bounded permissions, while a full policy may cover responsibilities, procurement, incidents, employment matters and legal obligations more broadly. A short list can make those wider requirements easier to apply, but it cannot replace requirements your organisation already has. Link to the relevant policy rather than duplicating long passages inside every row. If you do not have the authority or evidence to approve a use, write down the open decision and seek it. Calling the document a policy does not resolve missing expertise.
Should we name specific products in the list?
Name the exact approved service and account arrangement when those details affect the permission. A generic phrase such as “an AI chatbot” leaves colleagues to choose between services with different controls and terms. However, keep the task definition separate so the permission does not become an endorsement of everything that product can do. If the supplier changes a feature or a colleague moves to another account tier, reassess the affected row. You do not need to rewrite unrelated tasks solely because a product's marketing name changes.
What if someone needs an answer before approval is complete?
Use the existing manual process or another already approved method. Urgency does not establish that a new service may receive the information or take the proposed action. Provide a clear escalation route for genuine time-sensitive decisions, including who can assess the risk and what evidence they need. Keep a record of any authorised exception and its limits, rather than silently expanding the standing permission. If urgent exceptions become routine, investigate the underlying process. The repeated need may justify a properly assessed new task or a change that does not involve AI.
Can one person both use the tool and review the result?
Sometimes, for low-consequence work that the person can verify independently against an authoritative source. The register should say when self-review is sufficient and when a separate reviewer or specialist is needed. Do not assume a second pair of eyes is meaningful if neither person understands the content. For external advice, consequential decisions or difficult source interpretation, separation may be a useful additional safeguard. The deciding factors are the possible harm, the quality of the evidence and the reviewer's competence, not simply how many names appear beside the task.
How often should we update the list?
Set a practical routine and also define event-driven triggers. A regular review can catch abandoned uses and ownership changes, while a new data source, account arrangement, connector or output destination may require reassessment immediately. There is no universal calendar interval that makes permissions reliable. Match the routine to how quickly your tools and workflows change. Give each row an owner so changes do not depend on one central person noticing everything. If nothing material changed, record that the row was reviewed rather than rewriting it merely to demonstrate activity.
What should happen when a task is removed from the list?
Tell the people using it what stops, when it stops and which process replaces it. Preserve source material and required business records before withdrawing access or removing a connection. Check whether scheduled actions, shared instructions or dependent workflows still rely on the retired use. Record the reason so someone does not immediately request the same permission without understanding the problem. If removal follows a possible data incident, use the incident process as well; editing the register is not the response by itself. Keep the transition proportionate to the task's actual consequences.
Sources and verification
- Home Office: Use AI engineering standard, checked 11 September 2026 for its separate expectations on tools, data and review. Its institutional scope is stated in the article.
- UK Government AI Playbook, checked 11 September 2026 for meaningful human control, not used as a source of universal private-sector obligations.
- The parent was read in the supplied website source; its public route could not be retrieved. The register and workload are editorial examples, not a certification or documented team trial.
This article is practical guidance. Apply it in proportion to your tools, evidence, risks, and responsibilities.
