Shipping AI Features People Trust: From Demo to Dependable

A demo proves a model can do a task once, on inputs you chose. A shipped feature has to do it on inputs you did not choose, within a speed and cost you can afford, and fail in a way the customer can recover from.

The gap is rarely the model. A prototype that impresses in a meeting usually lacks six things that customers never see but always feel:

• A written definition of a good answer, agreed before anyone tunes a prompt.
• A set of real examples the feature is tested against on every change.
• A plan for wrong answers: what the screen shows, how the user fixes it, and who reviews the risky cases.
• Data boundaries that decide what information may reach which model provider.
• A latency budget and a waiting experience designed to match it.
• Logs, a staged rollout and a kill switch, so you can see what happened and stop it quickly.

This guide takes those in order and ends with a launch-readiness checklist you can use in a review meeting.

Start with one specific job and decide, before building, what a wrong answer costs and whether it can be undone. That single decision sets how much autonomy the feature earns and how much review it needs.

Write the job down in one sentence. A useful template:

For [who], given [input], produce [output]
that meets [quality bar], within [latency], at under [cost per task].
When unsure, [fallback].

If the team cannot fill in the fallback, the feature is not ready to design. Then place the job on a failure profile:

Reading three real products this way

These are analyses of public case studies, not reports of internal metrics.

June: AI Matchmaker generates profiles, offers one match a day and explains the compatibility behind each match. A wrong explanation costs no money, but with one match a day every explanation carries the product. The tolerable failure is an explanation that is less insightful than it could be. The intolerable one is a confident statement about a person that their profile does not support. That points to grounding explanations in profile facts the user can see.

Touchable.ai takes a customer from a photo, through AI generation, deck configuration and a live preview, to a printed deck delivered to their door. Before purchase, a weak generation is cheap: the customer tries again. After printing, it is expensive and physical. The live preview is therefore the point of no return, and it has to be an honest representation of what will print.

Hamhey guides people through housing, documents, appointments and payments across multiple countries. Guidance about local rules can be wrong, and a payment cannot be taken back with an apology. A product like this has to let AI explain and prepare, while the person confirms every action that touches money, an official document or a booking.

Assume a share of answers will be wrong and design so that a wrong answer is cheap: show the basis for it, make it easy to fix, and send the risky cases to a person. Trust comes from how the product behaves when the model misses, not from how often it hits.

Confidence without fake precision

Do not show a model's self-reported confidence as a percentage. Those numbers are poorly calibrated and invite false precision. Express confidence through behaviour instead, driven by signals you can measure: whether retrieval found strong sources, whether the output passed validation, whether two runs agree.

1. Answer when the signals are strong.
2. Answer with a visible caveat when they are mixed.
3. Ask a clarifying question when the input is ambiguous.
4. Decline and hand off to search, a form or a person when they are weak.

A feature that says "I couldn't find this in your documents" earns more trust than one that always answers.

Citations and visible basis

When an answer depends on a source, link the claim to the passage. Check citations in code: a quoted span should actually appear in the cited document, and a cited record should exist and belong to this user. For generated content without a document source, show the inputs it was built from, such as the profile fields behind a compatibility explanation.

Undo, edit and regenerate

Treat AI output as a draft. Keep the previous version, let the user edit in place, and let them regenerate with a steer ("shorter", "more formal"). For actions, prefer a short delay window or a soft delete over an immediate, final write.

Human review where it earns its cost

Route high-stakes or low-confidence cases to a review queue. The reviewer needs the input, the output, the basis and one-click approve, edit or reject. Every review decision is labelled data: feed it back into your evaluation set.

A path that does not need the model

When the model is slow, down or unsure, the feature should fall back to the product you had before: the manual form, plain search, or a human. A feature with no fallback turns a provider outage into your outage.

An evaluation set is a fixed collection of real inputs with agreed expectations, run automatically. Without one, every prompt tweak is a guess and every model upgrade is a gamble. Build it before the feature is finished, because writing the expectations is how the team agrees what "good" means.

1. Collect real examples. A useful starting size is 50 to 150 anonymised inputs. Spread them across common cases, edge cases, adversarial inputs, sensitive topics and requests the feature should refuse.
2. Write expectations per case. Some are hard checks: the output matches the schema, cites a source, stays under a length, never contains a phone number. Others are judgements scored against a short rubric.
3. Grade in layers. Run deterministic checks first. Have people grade rubric cases at the start. Use a model as a grader only after checking, on a sample, that it agrees with your human grades.
4. Set launch thresholds by category. Safety and privacy failures get zero tolerance. Quality gets a pass rate the product owner signs off.
5. Run it as a regression suite. Every change to a prompt, model, retrieval setting or tool runs the set in CI. A drop in a critical category blocks the merge, just like a failing unit test.

An evaluation case can be as simple as this illustrative one:

id: relocation-docs-017
input: "Which documents do I need to register my address?"
context: user_country=DE, stage=arrived
must:
  - cite at least one official source from the retrieved set
  - list documents as a checklist
must_not:
  - state a fee or deadline that is not in a cited source
rubric: specific to the user's stage; no generic advice

Two practical notes. Models are not fully deterministic, so run important cases several times and look at the spread, not one result. And pin model versions: providers update and retire models, and a silent upgrade can move your scores. In production, every correction, undo or escalation is a candidate for a new case, so the set grows from real failures rather than imagined ones.

Guardrails are checks outside the model that decide what goes in, what comes out and which actions are allowed. Data boundaries decide which information may reach which provider. Neither should depend on the model following instructions.

• Input checks. Limit size and file types, rate-limit per user, and strip personal data the task does not need before it leaves your servers.
• Output checks. Ask for structured output and validate it against a schema. Reject or repair invalid responses, cap length and filter content against your policy before anything is shown.
• Action checks. Tools enforce permissions on the server using the signed-in user's identity, never the model's claim about who it is acting for. Keep an allow-list of actions, require confirmation for writes and record every action in an audit log.
• Prompt injection. Retrieved documents, emails and web pages are untrusted data, not instructions. The dangerous combination for an agent is access to private data, exposure to untrusted content and a way to send data out. Remove at least one of the three for any given task.

Agree the data boundary in a table before integration, not after a security review:

A relocation product that handles identity and residence documents, like Hamhey's document journeys, sits squarely in the third row. Where data cannot leave a device or a network, a local model may be the right answer: see local vs cloud AI. Keep provider-specific code behind one interface either way, so changing providers is a configuration decision rather than a rewrite.

Set a latency budget for each step before building, and design the wait to match it. Stream when the output is text someone reads; show staged progress when the output is a job, such as generating images or assembling a document.

An illustrative budget for a chat-style answer grounded in the user's documents:

Measure the 95th percentile, not the average: the slow tail is what customers remember.

• Stream prose, not structure. Streaming a paragraph feels fast. Streaming half-formed JSON into a form looks broken, so for structured output stream progress messages, then render the validated result.
• Treat long generation as a job. Queue it, show named stages and let the user keep working. In a photo-to-deck flow like Touchable.ai's, letting the customer explore deck options while generation runs makes the wait feel like progress rather than a spinner.
• Time out with a plan. Every model call gets a timeout and a fallback: a retry on a faster model, a cached answer, or the manual path.
• Spend latency where it buys quality. A larger model or an extra verification step may be worth two seconds on a high-stakes answer and not on autocomplete.

Latency and cost move together, because the same levers (shorter context, smaller models, caching) improve both. The cost of an AI feature covers those levers in detail.

Log every AI call as a structured trace with versions, timings, token counts and outcome, and log raw content only where you have a reason and a retention limit. Without traces you cannot answer the first question after a complaint: what did the model see, and why did it say that?

A useful trace for each request records:

• A trace ID, the feature name and a pseudonymous user or tenant ID
• The model identifier and version, and the prompt template version
• IDs of the retrieved documents, not their contents
• Input and output token counts, and the computed cost
• Latency for each stage, and any timeout or retry
• Tool calls with their status, and the validator result
• Whether a fallback was used
• What the user did next: accepted, edited, undid, regenerated or escalated

The last item matters most: acceptance, edit and undo rates are the closest thing you have to a live quality score.

Privacy rules for AI logs

• Content logging is off by default. Turn it on for a sample, an opted-in group or a time-boxed investigation, with a short retention period.
• Redact before writing. Remove personal data and secrets in the logging layer, not in a later clean-up job.
• Treat log tools like model providers. A third-party tracing service that receives prompts needs the same data review as the model provider.
• Make deletion reach the logs. When a user deletes their account, traces containing their content go too.

Put five numbers on a dashboard and alert on change rather than on absolute values: acceptance rate, undo or escalation rate, fallback rate, p95 latency and cost per successful task.

Release an AI feature the way you would release risky infrastructure: shadow first, then a small audience, then wider, with a switch that turns it off in seconds without an app release. Each stage catches a different kind of failure.

1. Shadow mode. Run the feature on real traffic without showing its output. Compare what it would have done with what users or staff actually did. This catches the inputs your evaluation set missed.
2. Internal and friendly users. Real people, real screens, a short feedback loop. This catches confusing interfaces and missing fallbacks.
3. Staged percentages with gates. Move from 1% to 10% to 50% to everyone only while the dashboard numbers hold. Write the gate criteria down before the rollout starts.
4. A kill switch per feature. A server-side flag that switches the feature, or one tenant, back to the fallback path. For products shipped through the app stores, like June and Hamhey, the switch has to live on the server, because a fix cannot wait for a store review.

Model and prompt changes are releases too. Version them, run the evaluation suite, stage them and keep the previous version one flag away. Plan for the day a provider retires the model you depend on: the evaluation set is what makes a forced migration a routine change rather than an emergency.

Use this table in the review before you widen access. If a row has no owner or no evidence, the feature is not ready for more users.

Where to start on Monday

Write the job statement, collect 50 real examples and grade the current prototype against them. That afternoon of work usually tells you more about launch risk than another week of prompt tuning.

This is also how we run AI product development with clients: a first call on fit and risk, then a bounded first milestone in week one built around one useful job tested on real examples, with visible weekly work after that. If an agent will take actions on your systems, read why AI agents need receipts. If you have a prototype that needs to become something customers rely on, talk to the team.

How do I know if my AI feature is ready to launch?

It is ready when it passes an evaluation set of real examples at thresholds you agreed in advance, has a designed path for wrong answers, meets its latency budget at the 95th percentile, and can be switched off from the server. If any of those is missing, widen access only in shadow mode or to internal users.

What is an AI evaluation set?

An evaluation set is a fixed collection of real, anonymised inputs with expected properties for each output, run automatically. It combines hard checks, such as schema validity and citations, with rubric judgements. Running it on every prompt or model change turns quality from an opinion into a regression test.

Should AI features show a confidence score?

Usually not as a percentage, because model self-reported confidence is poorly calibrated and invites false precision. Express confidence through behaviour instead: answer, answer with a caveat, ask a clarifying question, or decline and hand off. Drive that choice from measurable signals such as retrieval strength and validation results.

How do you stop an AI agent from taking harmful actions?

Enforce permissions on the server using the signed-in user's identity, keep an allow-list of actions, and require human confirmation for anything costly or irreversible. Treat retrieved content as untrusted data so it cannot grant permissions, and record every action in an audit log.

What should we log for an AI feature without breaking privacy?

Log structured metadata for every call: model and prompt versions, token counts, latency, tool calls, validation results, cost and what the user did next. Keep raw prompt and response logging off by default, redact personal data before writing, and apply short retention and deletion rules to any content you do keep.

What is shadow mode for AI features?

Shadow mode runs the AI feature on real production traffic without showing its output to users. You compare what it would have done with what people actually did, which exposes failures your test examples missed before any customer is affected.