If your team brought its current AI use to you for approval today, would you say yes?

It is a question worth asking before opening the original assessment. Start with what people actually do with the tool now. Who uses it? What information goes into it? Where do the answers go? How much checking happens before somebody relies on them?

Then compare that account with the use you approved.

The difference may be entirely reasonable. People find useful applications, improve a process and share what works with colleagues. But the reasons for approving one use do not automatically explain why another is appropriate.

Look at the work as it happens now

Imagine a team that introduced an assistant to summarise internal research. Staff were expected to read the original material and use the summary to find relevant sections more quickly.

Later, another team starts using the summaries to prepare recommendations sent outside the organisation. The tool is familiar, so the new use feels like an extension of something already accepted.

Would you ask the same questions before approving both uses? Probably not. The audience, reliance and consequences are different. You might want additional review, clearer source references or a limit on the information used.

This is an illustrative example. The point is to examine the work rather than infer that an approved product makes every use of it acceptable.

Speak to someone who regularly uses the tool. Ask them to walk through a recent piece of work, within appropriate access permissions. Where did the material come from? What did they change? Who checked it? What happened to the result?

You may learn something the original project description never anticipated.

Revisit the reasons behind the approval

An approval is more useful when the organisation can explain its conditions. Perhaps the permitted information was limited, a qualified reviewer was required, or the output was intended only for internal use.

Check whether those conditions still hold. If a review depended on a particular team, does that team still have the capacity to do it? If staff were expected to check sources, can they access those sources in practice?

This approach is consistent with NIST’s voluntary AI Risk Management Framework, which treats risk management as continuing throughout the AI lifecycle. Its Govern 1.5 provision addresses ongoing monitoring and periodic review; the Map function calls for attention as context and capabilities evolve.

The exercise proposed here is one practical way to explore that issue. It is not a prescribed NIST procedure or a test of legal compliance.

Make a decision people can use

Finding a difference should lead to a decision about the current use. It should not automatically mean restarting the whole approval process or stopping work that remains appropriate.

Some uses may continue on the existing terms. Others may need a specific change: an additional check, different permissions, a clearer boundary or a pause while an unresolved concern is examined.

Name the person who can make that decision and agree what happens while they consider it. Otherwise, the people doing the work are left to choose between a deadline and an unanswered question.

Keep a short record of what changed, the decision, its reasons and any conditions. Assign responsibility for checking that an agreed improvement actually happened.

A sensible place to begin is one use where AI output influences an important decision. Ask the people involved to explain how it works today, then ask whoever owns the approval whether they would accept it on that basis.

If the answer is “yes, provided that…”, those conditions are the work to do next.

Sources and further reading