Before you buy an AI solution, define the exception.

Name the task and the owner.

“Add AI” is not a useful acceptance criterion. Choose a task with an identifiable user, an input, an output and a person responsible for the result. Finding a policy answer, drafting a support response and updating a customer record are distinct tasks with different permissions.

Capture the current process before designing a new one. How much effort does it take? Where do mistakes happen? What counts as a completed task? Without a baseline, it is difficult to tell whether a new workflow is an improvement.

Make an evaluation set before the pitch becomes a product.

Collect permitted examples that represent ordinary cases, ambiguous requests, missing information and material exceptions. Include questions the system should refuse or escalate. Keep some examples separate from development so the final test is not merely a rehearsal.

Agree who judges correctness and what errors are tolerable. A stylistic weakness in a draft and an unauthorised action in a business system are not equivalent failures. Measure them separately.

Design the boundary around the action.

A model may propose an action without being allowed to execute it. Separate read access from write access, and require approval for consequential changes. Make the proposed action visible before the user confirms it.

Prefer reliable, permissioned integrations. Log the important steps, make retries safe and define what happens when a source or external system is unavailable. The recovery path is part of the product, not a future enhancement.

Account for the whole operating cost.

Estimate usage from expected tasks, model calls, retrieval, storage and any messaging or voice services. Include monitoring, support and human review. A low token price does not automatically make a workflow economical.

For private deployment or model adaptation, compare the added infrastructure and maintenance against a simpler option. Agree a budget, spending controls and an owner. A near-zero-cost marketing website does not imply that the AI application it advertises will run for free.

Let the pilot earn the rollout.

Set a time and scope boundary, then test with the people who will actually use the system. Review quality, accepted output, latency, exceptions and total cost. Document the situations where a person still needs to take over.

The outcome can be a production build, a revised pilot, an off-the-shelf tool or a decision not to proceed. A feasibility engagement is useful when it makes that decision clearer—not only when it creates more implementation work.

Keep the useful part

The short checklist.

One workflow, an accountable owner and a baseline
Permitted representative data and held-out tests
Explicit action permissions and escalation rules
Quality, latency and cost acceptance thresholds
A go / revise / stop decision before rollout

Have a brief in mind?

Bring the context. We’ll help work out a useful next step.

Start the conversation