What to verify before using AI in a product

A result that works once in a demonstration is not the same as a feature used every day. Real input is unpredictable. A model may respond slowly or not at all. Cost may rise and some outputs will need review. The first design decision is therefore not which model to use but what the feature may do and where it must stop.

Define the role and the stop conditions

Summarise a document does not define a product feature. Specify which documents are in scope and who will use the result. Identify facts such as amounts or dates that must not change.

A feature that proposes a draft carries a different risk from one that changes system state. Keep the actions available to the model narrow. Require a person to confirm consequential actions.

Send only the input the feature needs

Separate necessary fields from information the feature does not need. Do not send personal or confidential information without a defined purpose. Consider replacing identifiers and sending only the relevant passage rather than the full source.

Put those decisions into the implementation. Use a pre-transfer filter and an allowlist of data types. Decide at the same point which values must stay out of operational logs.

Build evaluation from failure cases

A few demonstration prompts do not describe real quality. Include common input as well as empty values and ambiguous requests. Add conflicting instructions and unusually long text.

A summary that changes an amount or date may be more serious than awkward wording. A classifier that holds an item for review may be safer than one that takes the wrong action. Define unacceptable errors before averaging a score.

Make human review part of the workflow

Writing that a person is involved does not create a control. The interface and system state need to show who reviews the result and when it can be changed. The path after rejection must also be explicit.

If corrections are reused to improve the feature then define that purpose separately. Recheck the privacy boundary and retention period for the correction data.

Treat latency and cost as feature conditions

An external model can be slow or unavailable. A timeout is different from a usage limit or a policy refusal. Define when to retry and when to stop.

Use a request identifier so that repeated delivery does not repeat the action. Decide whether the feature can pause and move to a manual path. Give the user a clear choice between waiting and returning later.

Record decisions rather than raw content

Operational signals need to explain quality and cost as well as delay. Volume and response time alone can miss repeated user corrections. Keeping raw content in logs can also collect unnecessary personal information.

Version the model and prompt with the evaluation set. Keep them in the same change record so that a regression can be traced to a specific decision.

Gather release evidence

A recognised model name is not release evidence. Check that evaluation results and stop conditions work as intended. Confirm the recovery path and cost limit. Record who owns the feature and how a change is reviewed.

Those checks are what allow a demonstration result to be treated as a product feature.