Start AI enablement with a task someone repeats

“Help the finance team use AI” leaves almost every implementation question unanswered. “Prepare the weekly supplier-spend summary from the approved export, with explanations for unusual changes” gives you something to inspect.

You can find the inputs, watch the work, examine a finished report and ask who checks it. You can also discover that preparing the report is easy, while reconciling conflicting supplier names takes most of the time.

That is where enablement should start: the task as it actually happens.

Observe the work before choosing the tool

Ask someone to walk through a recent example. Use the files and systems they used, rather than a description of their ideal process.

Where did the information come from? What did they copy between systems? Which judgement required a colleague? What delayed completion? What did the recipient send back for correction?

Keep those observations separate from estimates. “This usually takes all morning” is a useful interview answer. It is not yet a baseline. Record enough actual examples to understand routine cases and the exceptions that make the work slow.

Existing AI usage is another source of evidence. It can show where people are already trying to solve a problem. Treat it within its authorised scope, alongside the walkthrough; a count of messages does not tell you whether the resulting work was useful.

Turn the task into a short specification

Before building, write a task card that another person can understand:

This exposes disagreements early. If one person expects a draft and another expects the report to be sent automatically, the same prototype will be judged against incompatible requirements.

It also prevents the project from expanding unnoticed. Reading an export, drafting a summary and sending it to external recipients are different actions with different consequences. Decide which actions are in scope.

Choose work that can be evaluated

A useful early candidate has recurring demand, usable inputs and a checkable output. It should have someone willing to own it after the initial build.

Compare candidates using those conditions rather than the attractiveness of the demonstration. An impressive prototype that depends on unavailable data will not remove work. A modest extraction task may be valuable if it fits into a process people already repeat.

Make the uncertainty visible in the backlog. Mark missing access, unclear ownership and quality questions directly beside the proposed task. Resolve the largest unknown before estimating a return from it.

NIST’s AI Risk Management Framework provides a voluntary structure for considering AI risks through governance, context, measurement and management. It is a useful reference for making evaluation and ownership part of adoption from the beginning. NIST AI Risk Management Framework.

The task card and selection approach here are practical suggestions, rather than a prescribed NIST implementation.

Measure the work after the first draft

An AI-generated report can arrive quickly and still take longer to finish. Someone may need to verify every number, rebuild missing references and rewrite unsupported explanations.

Measure preparation, generation, checking, correction and handover. Compare the finished output with the current process using the same quality criteria. Keep observed results separate from projected savings.

For the supplier-report example, ask whether totals reconcile, whether explanations are supported, and whether the report identifies missing data instead of guessing. Test routine inputs and awkward ones: renamed suppliers, empty fields, duplicate rows and a period with no comparable history.

A failed test is information about the work that remains. It can mean changing the instructions, improving source data, limiting the scope or keeping a step manual. Record which change was made so the next run tests the revised process.

Hand over a process someone can operate

The handover should include the task instructions, authorised data sources, evaluation examples and the steps to follow when something goes wrong. Name an owner who can update the process and decide when a change needs testing again.

Document how access is removed and how the work continues if the AI service is unavailable. Make clear which outputs require review before they are used. These details determine whether the workflow survives beyond the person who built it.

Then inspect what happens in normal use. Are people repeating corrections? Has a source changed? Is the output reaching the intended recipient? Feed that evidence into the next improvement rather than counting deployment as the end of the job.

Connor’s AI enablement services follow discovery, building and ongoing operation: understand the recurring work, deliver a scoped workflow, and use what happens in practice to choose what comes next.

A useful first project ends with a task that someone can complete, check and own.