After two years of advising enterprise AI programs at AWS and building production GenAI systems, I've seen enough deployments to recognize the patterns. The same five mistakes appear in nearly every enterprise GenAI project. They're all preventable. They're also all still very common.
1. Building Before Evaluating
The most expensive mistake in GenAI development is building a system before you have a way to evaluate it. Without evaluation, you cannot know whether the system is working. You cannot know whether a model upgrade made things better or worse. You cannot compare architectural approaches. You're shipping on vibes.
Evaluation infrastructure should come before application code. Define your evaluation dataset: a representative set of inputs with known correct outputs, edge cases that stress the system, and examples of failure modes you want to detect. Define your metrics: exact match, semantic similarity, factual accuracy, format compliance — whatever matters for your specific task. Automate the evaluation so you can run it on every code change.
Teams that skip this step find themselves unable to justify continued investment when the first complaints arrive from users. Teams that have evaluation data can show improvement over time and make evidence-based decisions about when the system is ready for the next stage of rollout.
2. Ignoring Latency Until It's a Product Problem
LLM inference is slow. A GPT-4o call with a 2,000-token context takes one to three seconds. A Claude response with retrieval and a tool call takes three to eight seconds. A multi-step agent workflow that makes six LLM calls takes fifteen to forty seconds. Users notice at every one of those thresholds.
Latency needs to be a design constraint from the beginning, not an optimization problem after launch. For synchronous user-facing applications, set a latency target (usually under three seconds for the first token) and design the architecture to hit it. That might mean choosing a smaller, faster model for the first response and a larger model for follow-up depth. It might mean pre-computing likely responses. It might mean streaming output instead of waiting for the full response.
Async workflows and background processing have more flexibility — but even there, users have expectations about how long "processing" should take, and those expectations are lower than most engineering teams assume.
3. No Fallback When the Model Gets It Wrong
GenAI systems are probabilistic. They will get things wrong. The question is what happens when they do.
Systems without fallback strategies handle model errors one of two ways: they fail silently (the user gets a wrong answer and doesn't know it) or they fail noisily (the user gets an error message or a nonsensical response). Both are bad. Silent failures are worse.
Good fallback design requires knowing what "wrong" looks like for your use case and building detection for it. Confidence scores, consistency checks across multiple calls, human review queues for low-confidence outputs, graceful degradation to a non-AI path for cases the model can't handle — these are product decisions, not engineering afterthoughts.
The systems I trust most are the ones that know when to say "I'm not sure" and route that uncertainty somewhere useful. That's harder to build than a system that always returns an answer. It's also the only version I'd put in front of a regulated enterprise's customers.
4. Undisclosed AI to End Users
This is both an ethical problem and a trust problem. Enterprise users who interact with AI systems and discover later that they were AI — because the response was wrong in a way a human wouldn't be, or because a colleague mentioned it — lose trust in both the system and the organization that deployed it without telling them.
The right approach is explicit disclosure at the appropriate level. Users interacting with an AI assistant know it's AI. Documents generated with AI assistance are flagged as such. Decision support tools that incorporate AI outputs are labeled clearly, with an indication of what the AI contributed and what the human decision-maker is responsible for.
Beyond trust, clear disclosure protects the organization. In financial services and healthcare, regulatory guidance on AI disclosure is still evolving — but the direction of travel is clearly toward more transparency, not less. Building disclosure in now is safer than retrofitting it when a regulation requires it.
5. No Cost Model Before Scaling
GenAI unit economics look fine at pilot scale and terrifying at production scale. A pilot with a hundred daily users calling GPT-4o at $15/MTok costs almost nothing. The same architecture at a hundred thousand users is a seven-figure annual line item that nobody budgeted for.
Before scaling any GenAI application, build the unit economics model. What is the cost per user per day? Per transaction? Per document processed? How does that cost scale with usage? What are the model costs at various usage levels, and what are the switching points where a different model or architecture becomes more cost-effective?
The teams that get surprised by their inference bills are the teams that never asked these questions during design. The teams that avoided that surprise built cost modeling into their architecture review process — not as a box to check, but as a genuine constraint that shaped their design decisions.
GenAI is powerful and real. The organizations that are going to get the most out of it are the ones that treat it as serious engineering — with evaluation, with cost modeling, with failure modes designed in advance and handled gracefully. The pilots that look good in demos but fail in production almost always violated at least three of these five principles. It's not a coincidence.
