AI workflow assessment or pilot? What to commission first

Start with the decision, then name the engagement

If the process, owner or access is unclear, start with a workflow assessment. If one technical assumption is blocking a defined plan, test that assumption in a proof of concept. If the workflow and permitted environment are agreed, a pilot can show whether the whole handoff is usable.

Providers use these terms differently. A proposal labelled “pilot” may contain only a model demonstration; a proof of concept may include more operational work than its name suggests. Write down the decision, deliverables and acceptance evidence before comparing proposals.

You do not need all three stages for every project. The useful sequence depends on what you already know, what you can safely test and who will use the result.

What each stage should help you decide

This is a practical distinction for commissioning work, rather than a universal definition. Ask the provider to explain how their scope maps to it. A small technical experiment can be part of a scoped pilot; it does not have to become a separate purchase.

Choose an assessment when the uncertainty is in the process

An assessment is useful when the team cannot yet agree where the work gets stuck, which records are authoritative or who may approve a change. It is also useful when a desired connection has not been confirmed in the actual tools and account plan.

Bring a few representative, redacted inputs and outputs, the main systems and the person who owns the process. The assessment should trace the current work, distinguish observed constraints from assumptions and identify what still needs verification. It should not require production credentials just to describe the problem.

A useful recommendation can be a smaller scope, an improved manual step or no AI build. For example, if the missing handoff is caused by an unclear review owner, adding a model does not resolve that decision. The report should remain useful if you later choose a different implementation provider.

Use a proof of concept to test one technical assumption

Suppose the process is understood, but nobody has verified whether the destination API can create the required record with the available permissions. A focused experiment should test that operation with approved sample data, in an agreed environment, and record what actually happened.

Ask for the input, version or configuration, test steps, result and failure evidence. “The integration is possible” is too broad if the experiment only read a public endpoint. Reading, drafting and writing are separate capabilities, and a successful read does not establish a permitted write.

A proof of concept can establish that an approach works for the tested case. It does not establish reliable operation across every input, a customer-ready interface, an unattended deployment or financial savings. Keep those questions visible so the next scope does not treat them as settled.

Commission a pilot when someone can accept the handoff

A pilot needs a named owner, a defined input and destination, agreed operations, a permitted test environment and observable acceptance checks. The owner should be able to say what a successful result looks like at the destination, including when the correct result is to hold the item for review.

The difference becomes clear in a fictional service-request workflow. An assessment might discover that staff use two conflicting categories. A technical experiment might verify that a task can be created in the test board. A pilot would also check that an approved request becomes the intended task, missing information reaches the right person and an unresolved write does not cause a blind retry.

Include review and recovery effort in the evaluation. If a person must correct the draft, repair a missing reference or reconcile a duplicate record, that work belongs in the result. Use the actual observations from the agreed examples; do not extrapolate them into company-wide savings.

The pilot handover should let the designated owner run a normal case and handle one agreed exception. An attractive demonstration that only its creator can operate leaves a different question unanswered.

Compare proposals by their evidence and boundaries

Before choosing a proposal, check that its main promise can be accepted by inspecting an artifact or an observed result. The following points make proposals easier to compare without assuming that their labels mean the same thing.

• Decision: the next business or technical decision this work is intended to support.
• Evidence: the report, repeatable experiment, destination record or handover exercise you can inspect.
• Boundary: the workflow, users, systems, environment and allowed operations included in the fee.
• Unknowns: what is assumed, what will be verified and what happens when a required permission or API is unavailable.
• Costs and ownership: consulting work, third-party costs, deliverable ownership and any ongoing support stated separately.

Make the commercial scope explicit

A low headline fee is difficult to compare if evaluation, handover or required software costs are unspecified. Ask for a written scope that explains these items and how changes will be agreed. Fees, dates and availability should be confirmed before paid work begins.

Keep risk review proportional to the work

NIST’s voluntary AI Risk Management Framework describes four functions: govern, map, measure and manage. Its release announcement says they can be applied in context-specific use cases and at different stages of the AI life cycle. That supports reviewing the process, measuring observed behaviour and agreeing how risks are handled; it does not prescribe the commercial stages in this guide.

For a small workflow, start with the people and records affected by a mistake, the allowed data and operations, a few useful failure cases and the owner who can intervene. More consequential uses need a deeper review. Completing an assessment or checklist does not certify compliance with NIST or any regulation.

Choose a useful next step

If the workflow is still uncertain, use the assessment scope to make the next decision explicit. If it is already defined, use the pilot checklist to identify any remaining access or acceptance gaps before an implementation proposal.

I work as an independent FDE engineer and AI implementation consultant. The service scope is agreed around one process and its owner. An assessment stands on its own; a subsequent pilot is optional. Technical experiments, deliverables, fees and delivery dates are included only when agreed in writing.