When AI Belongs in a Product

The useful question is not whether a product can include AI. It is whether a probabilistic system improves a real workflow enough to justify its cost, latency and failure modes compared with conventional software.

Start with the user decision or task

Describe the task without mentioning a model. A support agent needs to find the right policy quickly. A user needs to classify a document. An analyst needs to extract structured fields from inconsistent text. This keeps the problem measurable.

Once the task is clear, establish a non-AI baseline. Search, rules, templates and better interface design are often cheaper, faster and more predictable. AI earns its place when it materially improves the outcome.

Define evaluation before choosing a model

A demo can look impressive while failing the cases that matter. Build a representative evaluation set and define what counts as success. Depending on the task, measure accuracy, precision and recall, groundedness, completion rate, latency, cost or human review time.

Keep difficult and adversarial cases in the evaluation set. They prevent a team from optimising only for the easy examples used during development.

Engineer around uncertainty

Model outputs are probabilistic. Product architecture should therefore make confidence, validation and fallback behaviour explicit. High-impact actions may require deterministic checks or human approval even when the model is usually correct.

For retrieval systems, log source selection and measure whether answers are grounded in the supplied material. For extraction systems, validate fields against expected types and business rules before allowing them to change system state.

Cost and latency are product constraints

A model call that is affordable during a prototype can become expensive at production volume. Track cost per successful task rather than cost per token alone. The relevant denominator is useful work completed.

Latency has the same property. Some workflows tolerate asynchronous processing; others need immediate feedback. Architecture should reflect the user experience rather than forcing every request through the same model path.

Security extends beyond the model

AI features often touch sensitive documents, internal tools and external services. Access control, data minimisation, prompt injection resistance, tool permissions and audit logs belong in the system design.

A model should receive only the data and capabilities required for the current task. Treat tool invocation as privileged application behaviour, not as harmless text generation.

Ship behind measurement

Release to a constrained workflow, record outcomes and compare them with the baseline. Monitor model errors, user corrections, latency, cost and downstream impact. If the feature cannot be evaluated after launch, it will be difficult to improve safely.

The strongest AI products are not the ones with the most model calls. They are the ones where model capability is bounded by good software engineering, clear evaluation and a workflow that genuinely benefits from it.