A convincing demo can be built in a few days. That breeds a fallacy I run into on project after project: if it works in the meeting, it must be nearly finished. In reality the hard part starts afterwards, when the system meets real data, real users and real operations.
Where prototypes actually fail
Almost never on the model. A demo runs on hand-picked examples, patient users and no load. Production brings together everything that was left out: patchy data, nonsensical inputs, security requirements, a cost per request. Three patterns show up again and again:
- In the pilot the data is curated. In operation it is incomplete, contradictory, and constantly changing.
- “Good enough” was never defined, so no one can say whether the system is getting better or worse.
- No one feels responsible for operations, monitoring and failure cases.
What “production-ready” actually means
A production system works reliably even when no one is watching, and you can trace why it does what it does. In practice that comes down to four things:
- Reproducibility. Data, prompts and models are versioned; the same approach leads to traceable behaviour.
- Evaluation. Tests measure quality instead of guessing at it.
- Observability. Logging and monitoring show what is happening in operation.
- Guardrails. There are limits, fallback options, and a human deciding at the critical points.
You can’t “try out” quality with LLMs
Language models are not deterministic: the same prompt can give a good answer today and a weak one tomorrow. Keeping quality under control takes a system, not a gut feeling. What works for me is a fixed evaluation dataset of realistic cases that every change has to clear, scored automatically (with rules, reference answers or an LLM acting as judge) and spot-checked by domain experts. Nothing ships until the numbers hold up before release.
Security and data protection aren’t optional extras
AI systems open attack surfaces that classic software doesn’t have. Prompt injection slips foreign intent into the system through manipulated input. Sensitive information ends up in logs, models or responses by accident. And depending on the use case, the Swiss Data Protection Act and the EU AI Act apply. This belongs in the first design, not in a review just before launch.
In operation, everything drifts
Models, data and user behaviour shift, and quality rarely drops with a bang – it erodes quietly. The only thing that helps is continuous monitoring of quality, cost and anomalies; clear fallback paths when the system is uncertain; and human oversight wherever decisions can really hurt.
What it comes down to
A prototype proves something is possible. It only becomes reliable through the invisible work that follows. Plan for data, evaluation, security and operations from the start. You spare yourself expensive surprises later and reach a system you can actually trust sooner.
Have a promising prototype and want to take it into reliable operation? Get in touch.