Implementation Playbooks4 min read

Build an AI Non-Use Register Before Adoption Spreads

An AI non-use register records which business tasks should not use AI yet, why, who owns the decision and what safer route remains available.

Bokili EditorialPublished September 29, 2026· Verified September 29, 2026

A team sorts AI tasks into approved, review and non-use paths with owners and review dates.

Most AI adoption plans catalogue what teams may try: summarise a meeting, draft an email, compare documents or prepare a first analysis. That list is useful, but it is only half of the operating picture. Without an equally visible record of tasks that should not use AI yet, people can stretch an approved tool into work with weak evidence, unclear accountability or consequences that exceed the available controls.

An AI non-use register is a short, revisable record of those boundaries. It does not ban a product across the organisation. It names a business task, explains why AI is unsuitable now, points to a safer route, assigns an owner and states what evidence would justify another review.

Why an approved-tools list is not enough

NIST’s Map Playbook asks organisations to define the business context and purpose of an AI system, including how use, operators and social context shape risk. Its Manage Playbook goes further: AI may not be the right solution for a given business task, and the choice to proceed should be assessed and documented. The UK Government’s People Factor and hidden-risks toolkit add the human side: adoption changes behaviour, incentives and workarounds as well as technology.

The practical implication is simple. Approval belongs to a task and context, not just to a tool. A model that is suitable for rewriting a public product description may still be unsuitable for setting a supplier risk tier when the evidence is incomplete. The register makes that difference available at the moment of choice.

The BOUND non-use record

B — Business task

Name the decision or work product, not the app. Write “assign the final supplier risk tier”, not “use chatbot X”.

O — Out-of-scope reason

State the specific gap: missing evidence, prohibited data, unstable output, unclear accountability or consequences that cannot be safely reversed.

U — Usable alternative

Give people a viable route: a human review, an approved dataset, a deterministic check, or a lower-risk AI task that supports rather than replaces the decision.

N — Named owner

Assign the role that can answer questions, approve an exception and keep the boundary aligned with the workflow.

D — Date or review trigger

Set the evidence that can reopen the decision, such as a completed test, a policy change, better source access or a control becoming available.

Worked example: supplier risk screening

Imagine a fictional procurement team evaluating new suppliers. It approves AI for summarising questionnaire responses and highlighting missing documents. Someone then proposes using the same tool to assign the final supplier risk tier. The source material includes ambiguous answers, exceptions and evidence that sits outside the uploaded pack.

	Field	Non-use record
Business task	Assign the final supplier risk tier
Out-of-scope reason	The available pack may be incomplete; a fluent result could hide missing or conflicting evidence
Usable alternative	AI may organise evidence and flag gaps; the named procurement reviewer applies the approved risk method and signs the tier
Named owner	Head of Procurement Operations
Review trigger	Reassess after the source set, test cases, escalation rule and reviewer evidence view are verified

This boundary preserves a useful role for AI without letting convenience redefine the decision. It also tells the employee what to do next. A red label with no alternative encourages quiet workarounds; a documented route keeps the work moving.

Reading is a start. Practice makes it stick.

Start learning

Keep the register narrow and operational

Quality check for each entry

The entry names one concrete task or decision.
The reason describes an observable control or evidence gap.
The safer alternative is available to the team now.
The owner is a role with authority over the workflow.
The review trigger is evidence-based, not simply a future date.
Related policy, test or incident records can be found.
The boundary is visible where people choose how to do the work.

Avoid filling the register with vague categories such as “high risk” or “sensitive work”. Those phrases do not help a person recognise the boundary. Avoid permanent language too. “Never use AI in procurement” freezes a broad fear into policy; “do not assign the final supplier tier from an incomplete evidence pack” creates a testable rule.

Run a ten-minute non-use review

Add one BOUND entry

Choose one AI-assisted workflow that is already spreading across a team.
Name the final decision or work product in one sentence.
List one nearby task that people may assume is also approved.
Write the specific evidence, control or accountability gap that makes it unsuitable now.
Write the safer route a person can use today.
Assign an owner and one evidence-based trigger for review.
Place the entry beside the approved-use guidance, not in a separate forgotten document.

A useful first session often uncovers disagreement. One person may think AI is drafting a recommendation; another may think it is effectively making the decision. Record that ambiguity as evidence that the task boundary needs work before adoption expands.

Connect non-use to other controls

A non-use register operates before a task starts. Other controls cover later moments. Define how much authority AI has with the three-level authority model. Use a workflow stop rule when a permitted process encounters a live failure signal. Apply pilot exit rules when evidence says a trial should pause, change or end. Build an exception library so training includes recurring boundary cases.

Three levels of AI authority — https://bokili.com/en/learn/ai-literacy-training-business-authority-levels
Give every AI workflow a stop rule — https://bokili.com/en/learn/ai-workflow-stop-rule
Before you scale an AI pilot, write its exit rules — https://bokili.com/en/learn/ai-pilot-exit-rules
Corporate AI training needs an exception library — https://bokili.com/en/learn/corporate-ai-training-exception-library

The aim is not to make AI adoption slower. It is to stop an approved tool from silently inheriting decisions it was never evaluated to support. One clear non-use record gives teams a boundary, an alternative and a path back to evidence.