An AI policy needs a route to a decision

Someone wants to use an AI tool to summarise customer emails. The organisation has an AI policy, but it says only that confidential information must be protected and outputs must be checked. The employee still needs an answer: can this tool be used for these emails, and who can decide?

That is where an otherwise sensible policy can become difficult to use. Principles provide direction. People also need a route from a proposed use to a decision they can act on.

Describe the use, not just the tool

“We use a language model” tells a reviewer very little. A more useful description is: “The service team will use a hosted tool to draft summaries of support tickets. Staff will check each summary before it is added to the case record.”

Now the questions become clearer. Which ticket fields will be sent? Can the tool access attachments? Will it preserve account numbers or names? What happens if the summary omits a promise made to the customer?

The tool may already be approved for another purpose. That approval may not cover this one. A policy should make it easy to describe the proposed use and recognise when it differs from an existing decision.

Give the request an owner

A review can involve product, security, privacy and procurement, but someone needs to carry the request through. That person should understand the benefit being sought and be able to answer questions about the intended workflow.

The decision owner may be different. They need sufficient authority to accept the residual risk within the organisation’s rules, set conditions or ask for further work.

Keeping these responsibilities visible avoids a familiar problem: several people have commented, but nobody knows whether the use has actually been approved.

Make the evidence proportionate

A low-consequence drafting tool and a system influencing a consequential decision about a person should not receive identical reviews. Begin with the possible effects of error, the information involved and the reach of the system.

For the ticket-summary example, a small review could examine the supplier’s data terms, test summaries against representative tickets and agree how staff will detect omissions. If the tool starts sending replies directly, the review needs to change because its role has changed.

This is a practical way to apply a risk-based process. NIST’s voluntary AI Risk Management Framework separates governance, context, measurement and risk management into connected functions; it does not require every organisation to use one fixed workflow. NIST AI RMF.

Record a decision people can understand

“Approved” is often too short. A useful decision records the permitted use, the version or service assessed, the controls required and the person responsible for keeping them in place.

For example: “Permitted for drafting internal ticket summaries using the approved workspace. Staff must compare the draft with the source ticket before saving it. Attachments are excluded from this trial. The service owner will review the trial after the agreed sample has been checked.”

That is an illustrative decision, not a standard rule. Its value lies in being specific enough for a person to follow and a reviewer to revisit.

Define what brings the decision back

Reviews should be triggered by relevant change, as well as a planned date. A new supplier, a different model, access to more data or permission to take actions can alter the basis of the original approval.

Make it clear who notices those changes. A rule saying “review when the model changes” is hard to follow if the supplier can switch models without notifying anyone. That dependency belongs in the supplier discussion and the operating plan.

Try the process with a real request

Before distributing a long policy, walk one proposed use through it. Can the requester describe the use? Is the reviewer obvious? Can each question be answered, and does the result give the team a usable next step?

The exercise will expose missing responsibilities and unnecessary questions quickly. Update the process around what you learn, then use those same records as examples for the next team.

A policy becomes part of the work when it helps someone make a better decision on an ordinary day.

Next step: Use our AI use-case brief and register to test the route with one proposed use. Beeston Labs can help develop the review process and the controls behind it.