A natural-language layer over the warehouse answers the questions you thought to ask, in a way you cannot reproduce or defend. Risk does not wait to be queried.
Most companies arrive at the same idea eventually: the data is already in a warehouse, so why not point an AI at it and ask? It is a reasonable instinct, and the demos are genuinely impressive. A question in plain English, an answer in seconds, no analyst in the loop.
The problem is not that it does not work. It is that answering questions and catching what you missed are different jobs, and only one of them is the job.
A query only answers what you thought to ask
The account that damages a quarter is almost never the one somebody was already worried about. It is the one that looked fine — steady usage, no complaints from the executive sponsor, a renewal comfortably out on the horizon — right until it was not.
A query interface cannot help with that, because it requires you to already suspect something. It is a pull model: someone has to log in, form a hypothesis and ask. Risk detection is a push model. It has to run across every account every day, whether or not anyone thought to look, and reach the person who owns the number without being summoned.
You cannot query your way to the thing you did not know to worry about.
The model inherits every disagreement underneath it
An AI layer sits on top of whatever it is pointed at. If the CRM, the support desk and the finance system hold three versions of the same account — different legal name, different renewal date, different status — then a question about the biggest at-risk accounts gets answered from whichever version the query happened to read.
The answer will still arrive fluent and confident, and that is the danger. An unreconciled answer looks exactly like a reconciled one. Reconciliation is upstream of intelligence, not something intelligence can quietly do on the way past.
Ask twice, get two answers
Language models are not deterministic. Ask the same question on Tuesday and on Thursday and the phrasing changes; depending on how the question is parsed, the set of accounts can change with it. That is fine for exploration and disqualifying for a business process, because three things break at once:
- You cannot tune it. A threshold only means something if identical inputs always produce an identical output. Otherwise you are not adjusting sensitivity, you are re-rolling.
- You cannot compare across time. Asking whether an account is getting worse assumes last month's number was produced the same way as this month's.
- You cannot test it. There is no regression suite for a system that is permitted to answer differently.
You will have to defend the answer
When a number moves a forecast, someone senior asks why. The answer has to be a rule and its evidence: this contract renews in twenty-five days, these three escalations opened in the last fortnight, this invoice is forty days overdue, and this is the line that was crossed.
That the model identified it as high risk is not an answer that survives the room, and it should not be. Decisions that move money need provenance.
A query has no memory
Risk is a movement, not a state. The useful signal is rarely that an account scored badly today — it is that it has been getting worse for three weeks, or that it was bad and is now recovering, which is equally worth knowing and far easier to miss.
That requires every score to be stored, every time, so this week can be set against last. A query is stateless by construction. It answers, and forgets.
Where AI genuinely belongs
None of this is an argument against using AI. It is an argument about which layer it belongs in.
Detection should be deterministic: explicit rules over reconciled data, the same inputs producing the same signal every time, and every score kept so that movement is visible. That part is engineering, and it should be boring, testable and dull to explain.
What a model is genuinely good at is the layer above — turning triggered signals into language a specific executive can act on, drafting the recommended next step, and restating a technical finding in the terms a board already uses. That is a writing problem, and a model is better at writing problems than a rules engine will ever be.
Deterministic where it has to be defensible. Generative where it has to be readable.
The order is what matters. Reconcile first, detect deterministically second, and let the model handle the last mile. Point a model at raw, unreconciled data and ask it to do all three at once and you get something that reads like an answer, cannot be reproduced, and was never watching in the first place.
See it against your own book.
Thirty minutes to walk through what your executives would receive, what it takes to run, and whether your book is a fit.