Trending:
AI & Machine Learning

Why enterprise RAG projects take months, not weekends: the data problem

Custom GPTs and NotebookLM make RAG look simple. They're not. Most enterprise RAG projects stall because organizations underestimate data cleanup, access controls, and ongoing validation work. The engineering isn't the bottleneck - organizational readiness is.

Why enterprise RAG projects take months, not weekends: the data problem

The Pattern

A prospect describes their project: "It's basically a copy of what we already built. Same timeline."

The existing project? A marketing chatbot. No proprietary data, just search integration and personality.

The new project? Structured data retrieval from S3 buckets, Lambda triggers, ETL pipelines, and query reasoning over enterprise databases. That's not the same project. Not even close.

This happens constantly. Not because clients mislead - because the gap between "AI chatbot" concept and production RAG system is massive.

The Custom GPT Illusion

Client builds a Custom GPT over a weekend. Uploads PDFs, asks questions, shows the CEO. Everyone gets excited.

"We want this for the whole company."

That's where it stops being simple. "For the whole company" means multi-tenancy, role-based retrieval, audit logs, access controls. Custom GPT handles none of that. The prototype took a weekend. The production system takes months.

NotebookLM and Custom GPTs create dangerous expectations. They make RAG feel simple because they hide enterprise complexity.

Three Versions of "We Have Data"

Version 1: Documents. PDFs that are text, scans, or text with scanned tables. PowerPoints where critical information lives in speaker notes. This becomes a classification problem, an OCR problem, a parsing problem, then a chunking problem. Each adds weeks.

Version 2: Structured data. Multiple databases with different schemas. Legacy systems from 2012. CSV exports that break because someone used commas in text fields. Now you're building SQL agents and data transformation pipelines. Different architecture entirely.

Version 3: Both. Documents, databases, spreadsheets, emails, disorganized SharePoint. Most common. Most underestimated.

Industry data suggests 40-60% accuracy drops stem from chunking errors or retrieval irrelevance. Context overload causes latency spikes. These aren't edge cases - they're the norm with messy enterprise data.

The Real Bottlenecks

Access delays. Projects wait weeks for database credentials, months for security approvals. One stalled because a stakeholder with API access went on vacation. Every week of waiting is zero progress.

Validation work. Clients must provide domain expertise, evaluation data, and accuracy trade-off decisions. 85% accuracy in 6 weeks versus 95% in 12 weeks - that's their call. Most expect to hand off requirements and receive a product. RAG doesn't work that way.

Ongoing maintenance. When source documents change or accuracy drifts, someone investigates. This isn't one-time delivery. It's continuous operation.

What Actually Ships

Projects succeed when clients arrive with: clear process documentation, measurable outcomes, domain experts for validation, and evaluation data. Best case with clean data and engaged stakeholders: 6-8 weeks, mostly prompt engineering.

"Clean data" is rare. When it's missing, multiply timelines. When scope is unclear and stakeholders are overbooked, reconsider starting.

The technology isn't the constraint. Organizational readiness is. The sooner clients understand that, the faster projects ship.