Conversations with engineers building AI systems in enterprise settings reveal a consistent pattern: the projects that fail almost never fail because the model was wrong, the GPU was too slow, or the accuracy wasn’t high enough.

They fail on the infrastructure and systems layer. Every time.

Here are the five patterns that show up repeatedly.

1. Data quality is assumed, not verified

The model gets blamed when outputs are wrong. The actual cause, in the majority of cases, is that the input data was inconsistent, stale, or structurally different between training and production.

A RAG chatbot trained on a cleaned document corpus gets deployed against live SharePoint exports with inconsistent formatting, broken metadata, and documents that haven’t been updated in three years. The retrieval pipeline surfaces confidently wrong answers. The model is working exactly as designed. The data isn’t.

Data quality in enterprise AI is an ongoing engineering problem, not a pre-deployment checklist item. Pipelines that don’t monitor data drift will degrade silently over time.

2. No latency budget was defined upfront

“How fast does it need to be?” is a question that should be answered before architecture decisions are made. In practice it’s often answered after the first demo, when the business stakeholder says the response time is too slow for production use.

Latency in AI systems has three distinct components — model inference time, retrieval time if using RAG, and orchestration overhead from agents and chains. Each needs to be profiled separately. A system with 200ms inference, 800ms retrieval, and 400ms orchestration overhead is not a slow model problem. It is a systems design problem that was never surfaced.

TTFT (time to first token) and end-to-end latency are different metrics that matter for different use cases. Streaming changes the user experience entirely. These are decisions that need to be made in week one, not week ten.

3. Security and compliance were not included in the design

LLM systems in enterprise settings touch data that is often sensitive — internal documents, customer records, financial information. Security is frequently treated as a deployment gate rather than a design input.

The OWASP LLM Top 10 covers the attack surface specific to LLM applications — prompt injection, insecure output handling, excessive agency, training data poisoning. These are not theoretical. Prompt injection attacks against RAG systems that had access to internal document stores have caused real data exposure in production.

In regulated industries — healthcare, finance, legal — compliance requirements around data residency, audit logging, and model explainability need to be factored into the architecture from day one. Retrofitting compliance into a running system is expensive. Building it in from the start is not.

4. The evaluation strategy was “it looks good to me”

Models need to be evaluated against a held-out benchmark before deployment and continuously monitored in production. In practice, many enterprise AI projects ship with informal evaluation — someone with domain knowledge checked a sample of outputs and said it seemed fine.

This creates two problems. First, there is no baseline to measure regression against when the model is updated or the data changes. Second, there is no systematic way to detect when production behavior diverges from development behavior.

A good evaluation strategy for an enterprise RAG system includes: retrieval precision and recall metrics, answer faithfulness scoring, a labeled evaluation set built from real user queries, and production sampling with human review. None of this is optional if the system is making decisions that affect business outcomes.

5. Organizational ownership was never established

Who owns the model in production? Who gets paged when it starts returning wrong answers at 2am? Who approves changes to the system prompt? Who decides when to retrain or swap the underlying model?

These questions sound like process questions. They are actually reliability questions. AI systems in production require the same operational ownership as any other critical service — on-call rotations, runbooks, incident response procedures. The difference is that AI system failures are often silent and gradual rather than loud and immediate. Accuracy degrades. Hallucination rates increase. User trust erodes before any alert fires.

The teams that run AI systems reliably in production treat them as products with SLAs, not experiments that made it to deployment.

The pattern underneath all five

None of these failures are about the model. They are about the systems, processes, and organizational structures that surround it.

This is the consistent finding: the model is usually the most reliable component in a failed enterprise AI project. The model does what it was trained to do. The failure is that nobody specified what it should do, on what data, at what latency, with what security constraints, monitored by whom.

The engineering problem in enterprise AI is not intelligence. It is systems design, data quality, and organizational clarity. Getting those right is harder than picking a model. It is also more durable — a well-designed system survives model upgrades, data changes, and organizational transitions. A poorly designed one fails as soon as the demo conditions change.

The model is the easy part.

Previous: PagedAttention: the OS trick that made LLM serving practical

Next: Quantization — running INT8 vs FP16 benchmarks on the same model and measuring what actually changes.

Benchmark suite: github.com/anirudhs16/llm-inference-benchmarks