Integrating AI beyond the demo

A convincing demo answers a few good questions. A useful application must also handle incomplete requests, slow dependencies and answers that sound plausible but are wrong. Integrating AI means designing that surrounding behaviour as carefully as the model call.

Give the feature a narrow job

Start with a task whose success you can describe. “Add an assistant” is too broad. “Suggest a category for a support request and show it to an operator for review” creates a clearer boundary. The operator remains responsible for the final decision, and the suggested category can be compared with an expected result.

Write down what the feature should decline to do. In this example, suggesting a category does not imply permission to close a ticket, change an account or send a message. Keep those operations outside the feature until there is a specific reason and an appropriate authorisation flow.

Keep application rules outside the prompt

A prompt can describe the desired behaviour, but the application still needs to enforce its rules. Validate the response shape, reject unknown category values and check permissions before performing an action. Valid JSON only proves that the output can be parsed; it does not prove that the recommendation is correct.

For a hypothetical ticket classifier, a small response could contain a category and a short explanation. The server would check the category against an allowed list, while the interface would label the result as a suggestion. Avoid presenting a model’s self-reported confidence as a calibrated probability.

Treat retrieved content as input, not authority

Documents and user messages can contain instructions that conflict with the task. Treat that content as untrusted data. Limit what the model can access and keep tool permissions narrow; a retrieved paragraph should not grant the ability to perform an unrelated action. Prompt injection and excessive agency are among the risks discussed by the OWASP project on LLM application security.

Send only the information needed for the task. Decide how prompts, responses and logs are handled before enabling broad logging. Debugging is useful, but copying every support request into another system is not a neutral implementation detail.

Design the failure path before launch

Define a timeout and a useful fallback. If classification is unavailable, the operator should still be able to select a category manually. If the output cannot be validated, show that no suggestion is available rather than silently picking a default.

Build a small evaluation set with ordinary requests, ambiguous examples, missing context and attempts to redirect the model. Keep expected behaviour alongside each example. Compare results when changing the prompt, model or source material, and inspect failures by category rather than relying on a single average score.

Measure the whole interaction: latency, cost, validation failures and how often users replace the suggestion. These signals answer different questions. A fast response can still be unhelpful; a frequently edited suggestion may expose an unclear taxonomy rather than only a model problem.