A discussion on the challenges consultants face when clients want to deploy LLMs despite having poor data governance, weighing the risks of fixing data first versus deploying quickly on messy data.
Here's a Reddit-style body for that question: **When a client wants to deploy an LLM internally but their data governance is a mess, do you take the engagement and fix the data first, or walk away?** Looking for some honest takes from people who've been in this position, because I keep seeing the same pattern and I'm not sure my firm is handling it well. Client comes to us, usually mid-market or larger, and says some version of: "We want to deploy an internal LLM. Our competitors are doing it. The board is asking. Can you help us build a chatbot over our internal knowledge base / a copilot for our analysts / an AI assistant for our support team?" Sounds great on paper. Then you start the discovery and find out: * Their "knowledge base" is 14 SharePoint sites, 3 Confluence instances from acquisitions, a shared drive nobody has cleaned since 2017, and a guy named Dave who knows everything but is retiring in 8 months. * Sensitive customer data is sitting in spreadsheets that anyone with a corporate login can read. * They have no data classification policy, or they have one on paper that everyone ignores. * Half their "documents" are screenshots of emails saved as PDFs. * Access controls are basically vibes. So now you're standing at a fork. You can: **A) Take the engagement and quietly fix the data layer first.** Bill it as "AI readiness" or "knowledge foundation work." Spend 6-9 months doing the unglamorous data hygiene, governance, and access control work nobody wants to pay for. Then deploy the LLM on top of a clean foundation. The client gets a real outcome but they're impatient and the CFO is asking why we haven't shipped anything yet. **B) Build the LLM anyway on the mess.** Slap some RAG on top, ship something demo-able in 8 weeks, collect the fees. Watch it hallucinate, leak data it shouldn't have access to, or surface that one HR doc with everyone's salaries. Hope you're out the door before the lawsuit. **C) Walk away.** Tell them they're not ready, recommend a smaller scoped engagement, lose the deal to the consultancy down the street who will happily do option B. In practice my firm does some flavor of A but the commercial pressure to start showing "AI value" within the first quarter is brutal. The clients hear "data governance work" and their eyes glaze over. They hear "we'll have a chatbot in 6 weeks" and they sign the SOW. A few things I'd love to hear from this sub: * How are you scoping these engagements at signing time so the data foundation work is non-negotiable, not an upsell? * For folks at the bigger firms, are you walking away from deals where the client isn't ready, or are you taking the work and managing the risk? * Has anyone actually had success doing option B and not getting burned, or is that survivor bias talking? * How are you handling the partner/principal pressure to "just ship something" when you know the foundation isn't there? I genuinely think a lot of the "AI projects fail at 80% rate" headlines trace back to this exact decision point, and we're collectively not being honest about it with clients.
A discussion on whether LLM capability or enterprise data access and permissions is the bigger bottleneck for AI adoption, arguing that content management is becoming as critical as the models themselves.
A founder seeks validation for a service that configures production-grade LLM gateways to address common enterprise issues like cost visibility, provider lock-in, and PII leakage using open-source tools.
Based on conversations with over 20 teams, the author identifies three recurring pain points when using LLMs in production: enterprise-only basics, lack of agent observability, and slow support for new models.
A developer with 45 years of experience is building a local-first harness for LLMs with multi-agent logic, soon to be open-sourced on GitHub, and asks the community what features would improve their local LLM experience.
This paper investigates how narrative patterns from training data influence LLM behavior, leading to narrative drift, sycophancy, and deceptiveness over extended interactions, posing governance risks in deployed systems.