There is a reliable pattern in AI projects. The prototype is astonishing. The pilot is encouraging. The production deployment is a grind, and nobody warned anyone.

The gap is not about model quality. It is about the difference between the inputs you imagined and the inputs you get.

1. Input diversity explodes

Your test cases were written by people who understood the system. Real inputs include typos, three questions in one sentence, pasted email threads with signatures and disclaimers, screenshots described in words, and requests in the wrong language entirely.

The fix: collect real inputs before launch. Run a shadow period where the system processes real traffic without acting on it, and grade the outputs. This surfaces input diversity while it is still cheap.

2. Edge cases are the majority

In most business processes, the "standard case" is perhaps 60% of volume. The remaining 40% is a long tail of exceptions, each individually rare. A system that handles the standard case beautifully and the tail badly is a system that fails four times out of ten.

The fix: design the exception path first. What happens when the system is unsure? A confident wrong answer is far worse than an explicit "this one needs a person," and users forgive the second while abandoning the product over the first.

3. Latency becomes visible

In a demo, eight seconds feels acceptable because everyone is watching something impressive. In daily use, eight seconds forty times a day is an interruption people route around.

The fix: move generation off the interactive path wherever possible. Pre-generate, cache, or make it a background draft the user reviews rather than a live wait.

4. Cost scales in a way nobody modeled

Pilot volume is a rounding error. Production volume is not, and per-request cost that looked negligible becomes a line item somebody has to defend.

The fix: model the cost at 10× projected volume before launch, and instrument per-request cost from day one. Escalation architecture — cheap model first, expensive model only on low confidence — is the standard answer and should be built in from the start.

5. Trust breaks asymmetrically

This is the one that kills deployments. A user who gets nine good outputs and one confidently wrong one does not conclude the system is 90% accurate. They conclude it cannot be trusted, and they revert to doing it by hand.

The fix: calibrate confidence and show it. A system that says "I'm not sure about this one" preserves trust through errors. A system that presents every output with identical confidence spends its credibility on its worst answer.

6. The workflow around it was never designed

The model works. But nobody decided who reviews the output, what happens to rejections, where the record is stored, or how corrections feed back. The AI becomes an orphan step that people work around.

The fix: design the human workflow before the model work. Who sees this, when, in which tool, and what do they do next? If that has no clear answer, the technical work is premature.

The order that works

Shadow the real traffic. Design the exception path. Instrument cost and latency per request. Calibrate and expose confidence. Place the approval gate. Then tune the prompts.

Teams that do it in the opposite order — prompt tuning first, workflow last — ship demos. Teams that do it in this order ship systems people still use in a year.