Most unsuccessful AI initiatives start with a technology demonstration and only later search for a business problem. A production initiative should work in the opposite direction: identify a recurring decision or task, understand its inputs and consequences, establish a baseline, and then determine whether AI is the appropriate component.
Artificial intelligence is useful when it improves a process that already matters. It may reduce the time required to review documents, help employees retrieve internal knowledge, classify incoming requests, draft responses, detect anomalies or support a decision. The value is created by the complete operating system around the model—not by the model in isolation.
1. Start with a process, not a model
Select one process that is frequent enough to matter and bounded enough to evaluate. Describe how it works today: who starts it, what information is required, which systems participate, where manual judgment appears and what happens when something goes wrong.
A good first case usually has a clear owner, representative historical examples and a measurable bottleneck. “Use generative AI” is not a use case. “Reduce the time spent finding the current procedure and preparing a cited answer for an internal support request” is.
A useful problem statement contains four elements: the user, the task, the current constraint and the measurable outcome.
2. Establish the baseline before building
Without a baseline, a prototype can look impressive while failing to improve the operation. Measure the current process using indicators such as handling time, backlog, correction rate, escalation rate, cost per case or time to decision.
The target does not need to be dramatic. A smaller improvement that can be operated safely is more valuable than a spectacular demo that cannot be monitored, corrected or integrated.
3. Classify the type of intervention
| Pattern | What the system does | Typical human role |
|---|---|---|
| Assist | Finds information, summarizes, drafts or recommends. | Reviews and decides. |
| Automate | Executes a bounded task under explicit rules. | Handles exceptions and audits outcomes. |
| Predict | Produces a score, classification or forecast. | Interprets the result and acts within policy. |
This distinction matters because the required controls are different. A drafting assistant can tolerate uncertainty if every output is reviewed. An automated decision affecting payments, access or customers requires stronger validation, traceability and fallback procedures.
4. Map data, permissions and risk
Identify the information the system will receive, where it is stored, who is allowed to access it and whether it can be sent to an external provider. The deployment architecture—cloud API, private environment or local model—should follow these constraints rather than precede them.
NIST structures AI risk management around four continuous functions: govern, map, measure and manage. Applied pragmatically, this means assigning ownership, understanding the context and affected users, measuring quality and failure modes, and operating controls throughout the lifecycle.
5. Validate with representative cases
A useful prototype is tested against real variation: good inputs, poor scans, incomplete records, unusual wording, conflicting sources and edge cases. A curated demonstration set is not enough. The evaluation set should reflect the distribution the system will encounter in operation.
6. Design the human review path
Human review is not a temporary weakness. It is an operating mechanism. Define which cases can proceed automatically, which require confirmation and which must be rejected or escalated. Confidence scores can help, but thresholds must be validated against business consequences rather than chosen arbitrarily.
For assistants and agents, also define tool permissions, source restrictions, action limits and audit logs. The OWASP guidance for LLM applications highlights risks such as prompt injection, sensitive information disclosure and excessive agency; these are architecture concerns, not prompt-writing problems.
7. Move to production as a system
Production requires authentication, permissions, integration, monitoring, versioning, feedback, incident handling and an owner responsible for the outcome. It also requires a fallback when the model is unavailable or uncertain.
The model may change over time. The process definition, evaluation set and operational controls are the durable assets. Build those first, and model replacement becomes an engineering decision rather than a new project.
A practical first engagement
A focused AI adoption assessment can be completed before committing to a full implementation. The output should include a process map, prioritized use cases, data and integration requirements, risk assumptions, evaluation criteria, preliminary architecture and a phased delivery plan.
The objective is not to produce a generic strategy deck. It is to determine what should be built first, how success will be measured and what must be true for the system to operate safely.