A working prototype proves a model can produce the right answer once. Production asks a harder question: can it produce an acceptable answer on the worst input a real user will send, on the busiest day of the quarter, without a human noticing too late?
The teams that cross that gap treat AI as a component inside an ordinary system, not as the system itself.
Start with the evaluation set, not the model
Before choosing a model, collect fifty real examples with known-good answers. That set becomes the contract. It tells you whether a prompt change helped or quietly regressed something else, and it turns model upgrades from a leap of faith into a measurement.
- Draw examples from real user data, including the messy ones.
- Score outputs automatically where possible, by hand where not.
- Re-run the set on every prompt, model or retrieval change.
Put a human where the cost of being wrong is high
Automation is not all-or-nothing. In document workflows we route high-confidence extractions straight through and queue the rest for review. Throughput improves immediately, and the review queue doubles as a stream of new training examples.
Budget for the unglamorous parts
Retries, timeouts, token accounting, PII redaction, audit logs and a kill switch are what make an AI feature operable. They are also what most estimates leave out. Plan for them and the launch is uneventful — which is the goal.