Your AI tool works. Can the team use it without its creator?

Someone on the team gets tired of a repetitive task and builds something that helps automate it. Maybe it pulls information from incoming documents or prepares a draft that used to take a lot of copying between files.

Seems like a net positive, especially when that person understands the work better than an outside provider would. They know why the team checks certain details and which exceptions come up regularly, so there's a good chance they've built something genuinely useful.

But then other people start using it, and the questions start coming back to the person who built it. Which file goes in here? Why does this result look different? What happens when it stops halfway through?

The builder may have perfectly sensible answers to all of those questions. The problem is that everyone else needs them too, and a lot of that knowledge can stay in one person's head because they haven't needed to explain it yet.

Let someone else try it while the builder stays out of the way

My advice before adopting it across a team would be to give it to another colleague and let them work through an approved example without the builder stepping in. Choose someone who understands the job but hasn't been involved in making the tool.

Give them the instructions an ordinary user would receive, along with the access they're supposed to have. The builder can watch, but every time they feel the need to explain something, make a note of it rather than rescuing the exercise immediately.

You might find that the colleague can't tell which file to use, assumes a draft has already been checked or doesn't know where the finished work belongs. Those are useful findings. A successful demonstration by the creator wouldn't necessarily show you any of them.

Keep the exercise separate from live delivery. Use synthetic material or other samples your firm has explicitly approved for that environment, and don't give someone broader permissions just to make the test easier.

Use a case that doesn't go perfectly

The clean example tells you whether the person can follow the expected path. Something slightly incomplete tells you much more about whether they can use it sensibly.

For example, imagine a fund administration team using an AI tool to prepare a list of missing items from an investor document package. One test package could be missing a page; another could contain a document from an earlier period. These are illustrative cases, not a description of a Halyard client system.

The tool should make those gaps clear where they're within its agreed checks, and the colleague needs to understand what to do about them. A neat list that treats an old document as current can create more work for the reviewer, especially when the user assumes the tool has already settled the issue.

Include something outside the tool's intended use as well. You're looking for both the system's response and the person's judgment: whether they recognize the limit, stop relying on that output and use the agreed route for review. Existing fund systems and the team's professional approvals remain authoritative.

There won't be one universal pass mark for every tool. A missing detail in an internal draft and a disclosure of another client's information have very different consequences, so agree which failures block wider use before running the exercise.

Can the work still get finished when the tool is unavailable?

This part is easy to leave out because everyone is focused on showing that the new tool works. It's worth testing while the old process is still familiar.

Ask the colleague to finish the same task through the existing process with the AI tool unavailable. For a document check, that might mean opening the approved checklist and reviewing the package manually. For a reporting draft, it might mean retrieving the source records and preparing the material in the usual way.

Watch for work that disappears between the two routes. Has the tool already updated a record? Could someone repeat an action without realizing it? Is it clear which version the reviewer should use? The fallback needs to cover work already in progress, not just a fresh task.

NIST's voluntary AI Risk Management Framework Playbook includes suggested actions for contingency processes and backup systems, as well as mechanisms to stop systems that behave unexpectedly. It supports taking continuity seriously, but it isn't a certification or a substitute for your firm's own requirements.

For this exercise, the practical question is whether the colleague can finish the work within its required checks and deadline, or knows who can decide what happens next.

NIST AI RMF Playbook: Manage, including MANAGE 2.3 and 2.4

Write down the things people actually need to know

The notes from that exercise give you a much better starting point for the handover than a long document written from memory. They show where someone got stuck and what they needed to understand at that moment.

An example of a supported file, an annotated output and an explanation of where to ask for help may be more useful than pages of technical description. Keep the deeper configuration and support records available to the people maintaining the system, but don't expect every user to become its developer.

Someone also needs responsibility for the work after launch. The operating owner can decide whether the output is suitable for the task; technical support can investigate a broken connection. Depending on the firm, those may be different people or an internal owner working with an outside provider. Make the arrangement explicit so a problem doesn't simply return to whoever built the first version.

The firm should retain the access and configuration records it needs, with credentials kept in approved storage rather than passed around in instructions. Before changing a model, prompt, source or connection, work out which checks need running again and who can approve the change. A handover that was accurate six months ago may no longer describe what the team is using.