Where an AI demo ends and a product begins

A demo can be impressive with one carefully chosen question. But people use a service to achieve something: understand a document, find information or prepare a request. That action should be at the centre of development, rather than the response itself.

Describe who uses the feature, what they do today and the outcome they need. “An assistant analyses documents” is broad. “An employee finds the return conditions in the current contract and sees the source” defines a scenario that can be checked. It also makes clear which information the system needs.

Compare AI with search, filters, templates or a straightforward rule. Sometimes those solve the problem more simply. If a model is necessary, define its role: does it suggest an option, extract information or make a decision? The greater the consequences of an error, the more important human review becomes.

Demonstrations use tidy documents and unambiguous questions. Real work includes scans, outdated versions, incomplete requests and conflicting information. Testing only convenient examples does not reveal how the feature behaves in those conditions.

An initial evaluation set should include ordinary cases, difficult cases and questions the system should decline to answer. Record the expected outcome for each example: information to find, a source to show or a clarification to request. Repeat these checks when changing the model, instructions or data processing.

OpenAI’s evaluation guidance recommends task-specific evaluation and a test set that evolves with the product. In practice, assessment should reflect real scenarios rather than a general impression from a handful of responses.

A good response can still arrive too late or fail to fit the task. The interface needs waiting, retry and no-result states. When information is missing, saying so is more useful than a confident guess. Document-based answers should expose their sources so the reader can inspect the original passage.

Decide which information may be sent to an external provider and which actions the feature may perform. A document or user message must not automatically grant new permissions. When AI proposes sending a message or changing a record, keep the proposal separate from execution.

• The source of the answer is clear.
• The user can correct the result or ask a person.
• A model error does not trigger an irreversible action.

Limit the first version to one useful workflow and a small audience. Observe where people get stuck, which questions repeat and when results need manual correction. Reasons for abandoning the feature are as useful as praise.

Before expanding, assess result quality, waiting time and the cost of a completed task. A cheap request means little if several attempts are needed. A fast answer is not useful if the person still has to redo the work.

Expansion makes sense when the original scenario already provides clear value. New features can then build on tested behaviour rather than the hope that a more sophisticated model will fix every product problem.