The model is not your bottleneck. The sign-off is
Here is how the chat with enterprise data pilot dies. The demo goes well. The CFO asks a question about last quarter's margin, gets a number back in three seconds, and then asks the only question that matters: where did that come from? Nobody can answer in the room. The number is probably right, and it is now worthless, because no executive signs a decision off an answer they cannot trace back to a source. Teams read that moment as a model problem and go shopping for a better one. It isn't. The retrieval was fine. What was missing was the receipt.
Ship the citation with the answer, or don't ship
Every answer should arrive with its provenance attached: the table it came from, the filter that was applied, the time the data was last refreshed, and a link that takes the user to the underlying rows in one click. Not a footnote. Not a "sources" panel three clicks away that nobody opens. The test is brutal and worth running: hand the thing to a finance analyst and watch what they do with a number they didn't expect. If they can't get from the answer to the row in a single step, they'll rebuild it in a spreadsheet. Once that happens your adoption metric is measuring people checking the AI's work, not people using it. This is why lineage has to be in the first release. Retrofitting provenance onto a chat system that was built to return prose means rebuilding the retrieval path, and by then you have already lost the executives who tried it once.
Pick three tables, not the warehouse
The standard blocker is "our data isn't ready". It never is, and waiting for it to be is how three years disappear. You don't need a trustworthy warehouse. You need the three or four tables the use case actually reads to be trustworthy, documented, and owned. Name them. Find out who owns each one, what the refresh cadence is, and where the known bad rows live. That's a week of work, not a data programme. What usually surfaces is that nobody owns the tables at all, and that quiet fact has been blocking every AI project above it for years. The chat use case is useful here for a reason that has nothing to do with AI: it's the forcing function that finally gets data ownership assigned to a human being.
Evaluate on a golden set, not on vibes
Write down 50 to 100 real questions your users will ask, with the correct answers agreed by the people who own those numbers. That's your golden set. Score against it before launch, and again after every model change, prompt change, or schema change. You need this because the ground moves. Providers update models under you, and a system that scored 92% on Friday can score 78% on Monday with nothing in your repo having changed. Without an eval set you find out from an executive, in a meeting, which is the most expensive possible place to find out. Be specific about what counts as correct. "Roughly right" fails: an answer that's off by 2% on a revenue figure is a wrong answer with a confident tone, which is worse than a refusal.
Decide what it is allowed to refuse
The most useful design decision is where the system says "I don't know". A chat interface over enterprise data will be asked about things outside its scope on day one, and the failure mode is that it answers anyway, plausibly, from a table that looks close enough. So scope it explicitly and fail closed outside that scope. Out-of-scope questions get a refusal and a pointer to the human or the report that does answer them. Executives forgive a system that says it can't answer. They stop using one that was confidently wrong once.
The audit trail is the adoption feature, not the compliance chore
Log every question, the answer, the sources used, the user, and the model version, and keep it queryable. Most teams treat that as the box the risk function makes them tick. It's the opposite: it's what lets you answer "why did it say that in March" in June, and it's what lets you show the pattern of questions people actually ask, which is the single best input into what you build next. It matters for the obligations too. The EU AI Act's transparency requirements mean users need to know they're interacting with an AI system, and record keeping is a standing expectation for systems that inform consequential decisions. ISO 42001 asks for the same thing in management-system language. Both are much cheaper to satisfy if the logs exist from day one rather than being reconstructed under audit.
A 30 day shape that works
Week one: name the use case, the owner, and the three tables. Agree the golden set with the people who own the numbers. Week two: build the retrieval path with provenance attached to every answer from the first commit. Get the refusal behaviour right before you tune answer quality. Week three: run the golden set, fix what's broken, and put the logging in place. Give it to five real users, not a demo audience. Week four: measure whether anyone went back to the spreadsheet. That's the only adoption number worth reporting. If they did, the trust gap is still open and no amount of model tuning closes it. Lineage is the trust feature. Ship it with the chat, not after it.