AI in the business: build one useful workflow, not another impressive demo

A convincing AI demo answers “Can this system do something interesting?” A useful business implementation answers a harder question: “Can it perform a defined task consistently, within an acceptable level of risk, and improve the economics or quality of our work?”

Those are different tests. A polished answer can still contain a false statement. A faster first draft can still require more checking than writing from scratch. Start with a workflow and an evaluation plan, not with a model name.

1. Choose a bounded task with a clear reviewer

Good initial candidates often involve helping people prepare work: drafting an internal brief from approved material, proposing a support response or extracting fields from a document for review. The scope is narrow, inputs can be checked and a person can correct the result before it affects a customer.

Be more cautious with actions that change money, permissions, contractual terms or consequential decisions. The cost of an error matters as much as the frequency of the task. If a rule-based system can solve the problem reliably, generative AI may add unnecessary variability.

Define the task in one sentence: “Produce a draft response using our approved product documentation, with references, for a support agent to review.” That is much more testable than “Use AI to improve customer service.”

2. Decide which information the system may use

Separate approved reference material from confidential records and untrusted customer input. Check the provider's contractual terms for data use, retention, training and access rather than assuming every service handles data the same way. Minimize what you send and involve the appropriate privacy or security specialist when the data requires it.

Supplying relevant company documents can make a response more grounded, but it does not guarantee correctness. Documents can be stale, retrieval can miss a critical passage and the model can draw an unsupported conclusion. Require the reviewer to verify important claims against the actual source.

Customer messages and uploaded documents should be treated as data, not trusted instructions. A document can contain text designed to redirect the system. Technical permissions and approval boundaries must still apply even if the model produces a persuasive request.

3. Build a small evaluation set before the pilot

Collect representative tasks with permission and remove unnecessary sensitive information. Include ordinary cases, ambiguous requests, missing data and cases where the correct response is “I don't know” or an escalation.

A starter set of 30 cases can help expose obvious failures, but it is not a statistically sufficient safety demonstration for every application. The size and depth of evaluation must reflect the risk and variety of the task.

For each case, define what an acceptable result contains, which errors are unacceptable and whether a reviewer should intervene. Score the result against that rubric rather than asking the same system to declare itself successful. Independent human review is especially important when mistakes could harm someone.

4. Measure end-to-end value, not generation speed

Track time to a reviewed, usable result. Include reading, verification, corrections and escalation. Also track factual errors, unsupported claims, cases that need a complete rewrite and the cost of running the workflow.

Compare with the existing process on similar tasks. A draft produced in seconds is not useful if a team spends ten minutes identifying what is wrong with it. Conversely, a modest time saving can be valuable if it consistently improves completeness without increasing risk.

5. Give the pilot explicit stop conditions

For a low-risk drafting workflow, a four-week pilot might be a practical starting point, not a universal recommendation:

1. Establish the current handling time and quality criteria.
2. Run representative cases without sending outputs to customers automatically.
3. Review errors weekly and adjust instructions, reference material or scope.
4. Decide whether to expand, revise or stop using pre-agreed criteria.

Name a process owner. Keep logs appropriate to the sensitivity of the information, a way to return to the manual process and approval before actions outside the agreed scope. Re-evaluate after changes to the model, documentation or workflow; a successful test is not a permanent assurance.

The purpose is not to put AI everywhere. It is to identify one task where assistance is genuinely useful, the risks are understood and the team can verify the outcome. That is how an experiment becomes an operating capability.

Further reading

NIST: AI Risk Management Framework is a voluntary framework for managing AI risk and trustworthiness. NIST: Generative AI Profile addresses risks specific to generative AI. Our workflow and pilot suggestions are an editorial application of these principles, not a certification of safety or legal compliance.