Load-Bearing: The Question to Ask Before AI-Enhanced MDM Becomes Your Differentiator (original)

Differentiator or cost centre is a false choice. The question that matters is what happens to a vital process once the money running it stops being yours to control.

There is a sentence master-data leaders are being encouraged to say out loud, and it goes roughly: with AI in the platform, master data management (MDM) stops being a cost centre and becomes a strategic differentiator. It is a good sentence. It gets budget. I put the question behind it to my co-author — is AI-enhanced MDM a differentiator, or a story we tell finance? — expecting him to pick a side.

He picked neither:

Sure—it's a great way to burn a budget extremely quickly.

That is not cynicism and it is not a no. It concedes the word and then detonates it, which is more useful than either answer — and it ends where the differentiator framing never goes, on what you give up in exchange.

First: nobody has done this long enough to be wise about it

I asked him which piece of accepted wisdom about AI in MDM platforms he would argue against. He declined to name one, and his reason is sharper than any target he might have picked: he does not know what the accepted wisdom is, because AI in MDM platforms is new enough that it is hard to believe any has accumulated.

That is checkable, so I checked it — a search for accepted wisdom, best practice and lessons learned on AI in master data management, run on August 21, 2026. Almost everything that came back was vendor pages, vendor blogs and implementation-partner listicles. The most substantial result was a reference article from a major MDM vendor, and it is a fair sample because it is one of the good ones: a five-step strategy ending on the vendor's own AI component, with the quoted authority its senior director of product marketing [1]. None of that is dishonest. It is simply not the same artifact as a report from someone who has run this for three years and can say where it went wrong.

The other category was forecasts. Gartner's most quoted line in this neighbourhood predicts that over 40% of agentic AI projects will be cancelled by the end of 2027, due to escalating costs, unclear business value or inadequate risk controls [2]. I have no quarrel with the analysis, only with what it is: a claim about 2027, published in 2025, resting on a poll of webinar attendees about their investments rather than their results.

Practice reports do exist if you go looking in the literature rather than the marketing. MERAI, published in 2025, describes an entity-resolution pipeline validated across actual deduplication and linkage projects, and reports it processing up to 15.7 million records where one widely used open-source library ran out of memory past two million [10]. That is exactly the artifact I said was missing.

So the defensible claim is smaller, and it is about retrieval rather than the field: the work exists, in ones and twos, in the literature; what reaches a data leader looking for guidance is product copy and dated prediction. It says nothing about whether the vendors are right — only about what a slide deck is made of. The risk is not that you will believe a bad rule. It is that you will mistake marketing for a rule at all, and the two are indistinguishable at that distance.

Which makes his fallback coherent rather than evasive. Absent a body of experience to appeal to, what you have is heuristics with maybe 80% generic utility — and heuristics are, in his words, guidelines, not rules that need to be tested for their applicability to your specific situation before being applied vigorously. That is also, awkwardly, the status of everything below this line, including mine.

Cheaper, not new — and the exception that matters

Here is his claim, stated plainly so you can argue with it: there's no AI capability that allows a company with an unlimited budget to do something new. The reasoning is that a model has no imaginative capacity to invent a genuinely new capability — what it can do is reduce the cost of capabilities that already exist.

Before testing it, be specific about what the reduction buys. Three abilities do real work in master data, and all three are checkable rather than promised:

Notice what is common to all three: each is a thing a competent team could already do, now cheap enough to do at volume. That is a claim about these three, checkable against the sources beneath them.

What the refutation actually establishes

Stated as a universal it is refutable, and there is a published result aimed straight at it. In 2023 a DeepMind system called FunSearch paired a model with an automated evaluator that discarded anything which did not verify, and ran the loop until it found new constructions for the cap set problem — a combinatorial question where any candidate answer can be checked exhaustively by a program in seconds, and where no one had raised the bound this far in twenty years — along with better heuristics for online bin packing. Its authors describe it as the first new discovery on an open problem in science or mathematics made using large language models [9].

That is a real result and I am not going to explain it away. What it establishes is narrower than the headline, and my co-author is the reason this section says so. One clarification, because he pressed on it: the cap set space is not large in the sense of expensive but in the sense that exhaustive enumeration does not finish. Budget and reachability are different axes.

So take the accurate description. FunSearch ran on a well-defined problem in a thoroughly explored domain, on ground decades of prior work had made solid, and what it contributed was convergence — a model proposing candidates and ranking them more or less wrong on the fly, where earlier systems had only brute force. Then notice what the automatic evaluator implies. If a program can decide that a candidate is wrong, the target was already fully specified. The problem was posed before the model arrived.

The move that suggests itself here is to say the exception requires that automatic evaluator. It does not, and the case against it is published. In November 2025 OpenAI researchers and working mathematicians from Cambridge, Oxford, Harvard, Columbia and Berkeley released case studies of GPT-5 in live research, and the abstract does not hedge: the paper carries four new results in mathematics (carefully verified by the human authors), helping human mathematicians settle previously unsolved problems [13]. The verification named in that sentence is human.

Read the other phrase again, because it is the half that survives: previously unsolved problems. Somebody had posed each of them, and what counted as an answer was fixed before the model arrived. So here is what I will defend, and you can disagree with it: the exception needs a target specified first — a question already asked, and a standard capable of saying wrong. Who applies that standard is negotiable; that it existed beforehand is not. What would refute this: one documented case of a model's output accepted as knowledge where nobody had posed the question or fixed what a right answer looked like. And note the price of the human evaluator: mathematicians reading proofs line by line, and there are not twelve million of them.

It matters because it converts straight into practice: in master data your evaluator is the governed standard. The target schema, the value sets, the survivorship rules, the labelled ground truth — that is the artifact that can say wrong without being asked twice, and it is the difference between generation that compounds and generation that produces confident nonsense in volume. It is also why the cap-set result does not transfer for free. A combinatorial construction is checkable in full, by a program, against a definition nobody disputes; a customer record is checkable only against a standard somebody sat down and wrote. If nobody wrote it, you do not have the exception. You have the generator on its own.

The seeming is not a mistake

None of which stops the substitution feeling like new capability from where the buyer sits, and my co-author does not say the buyer is wrong to feel it. His example is a role: a model can fill in for a domain expert when properly trained, but not as well as one, because the human's training happened before you hired them and carries an enormous quantity of non-domain material as a byproduct of having had a life. What keeps a forager from eating the toxic lookalike is rarely the field guide; it is the fifty other things they know about that hillside in October.

Then he puts a hypothetical on it. Suppose the budget for the position is five thousand a year and the human costs two hundred and fifty thousand, all expenses included. Those are his numbers, round on purpose, and neither is a rate, a contract or a measured salary — what is doing the work is the ratio, roughly fifty to one. Be careful which half you lean on: a fully loaded salary is a number the organization has been paying for years, while the five thousand is a forecast nobody has learned to bound. The ratio describes the moment of the decision, not the run rate of the year that follows. It still does its work, because at anything like fifty to one the distinction between "cheaper" and "new" stops being visible from the buying committee. An imitation expert with known limitations, at that price, is a capability you did not have — not because the technology invented anything, but because the price crossed the line where you were allowed to want it.

That is where the differentiator question actually lives. Not is this new, but how much cheaper, for how long, and whose price is it?

The flexibility is the price

Which brings me to the mechanism that explains most of the disappointments:

The more complicated and vague the problem at which its pointed, the more expensive it is to provide a solution—and the solution isn't even guaranteed to be right.

Plenty of your estate is metered by consumption already — a careless warehouse query, a per-record enrichment call, an elastic cluster nobody turned off — so imprecision costing money is not the novelty. Three narrower things are. The coupling is tighter: the vagueness of the instruction is itself the price driver, because a model handed an underspecified problem spends more tokens deciding what you meant. It is invisible in advance: no plan to read before you run, only a bill afterwards. And it is unattributable after the fact — you cannot point at the clause that spent the money the way you can point at a missing index. Vendors have stopped hiding this and started selling controls for it. One publishes an effort parameter with five levels, calls its top setting unconstrained token spending, and says outright that on most workloads the maximum adds significant cost for relatively small quality gains while lower levels buy savings at some capability reduction [3]. (Those control surfaces are one vendor's, read on one day; read your own, and date them.)

The imputation benchmark shows the same shape: the models won on quality and incurred significantly higher computational time and monetary cost than the classical methods they beat [5]. Nobody found a free lunch. They found a better lunch and an itemized bill.

The operational consequence is a rule I would write into the design standard: the specificity of your prompt is a line item. "Clean up the supplier names" is expensive and unverifiable. "Normalize this value to the following value set, return one of these seventeen codes or the string UNRESOLVED, and give me a confidence" is cheap, checkable and answerable at a low effort setting. Same model, same records, materially different bill — and the difference is the standard you wrote before you called it, the governed layer that was decisive before AI and is more so now.

The budget stops. The work doesn't.

Then the failure mode that gets people. A tool this flexible invites you to reach for it everywhere and often, which drains a token allocation far faster than the plan assumed — and the instinctive answer, the one every finance function reaches for, is a hard limit. My co-author's objection to that is the most useful sentence in this article:

It's all well and good to have token budgets and hard limits on spending, but just because the budget is exhausted doesn't mean the data is.

Sit with the asymmetry. A spending cap bounds what you pay for, and has no opinion about the records still sitting unenriched in the queue on the first of the month. What stopped was the payment.

And the caps themselves are softer than the word suggests. One vendor's per-task budget feature is documented as a soft hint, not a hard cap — the model may exceed it if it is mid-action — with the enforced ceiling living somewhere else entirely, in a per-request output limit that truncates mid-answer; and a budget set too small produces refusal-like behaviour, the model declining the task, scoping it down aggressively, or stopping early with a partial result [7]. Set the cap loose and it does not cap. Set it tight and you have not bought restraint, you have bought a queue of half-processed records with no error to alert on, which is the worst state a master-data pipeline can be in: it looks like it ran.

The part that is about control, not price

All of which is manageable while the process is optional, and changes character entirely once it is not. This is the argument the differentiator framing is structurally unable to make:

Tread very lightly when incorporating AI into vital business processes because now it becomes load bearing for the business and the cost is no longer under the business' control.

Load-bearing is the exact word. A cost you can decline is a cost. A cost you cannot decline is a dependency, and its price is set by someone else. You do not need a forecast for this — the terms are published. One vendor's deprecation page shows models moving through active, deprecated and retired, and states plainly that requests to a retired model will fail; its own history shows the flagship you built on in 2025 retired in August 2026, with a replacement named for you, and three sampling parameters deprecated on newer models that now return a 400 error if you set them [8]. Read from the other side of the invoice: the thing your survivorship logic depends on has an expiry date you did not choose and a successor you did not select.

The obvious objection is that this is nothing unusual: every load-bearing system you own already runs on a price somebody else sets — the platform, the database, the cloud, the maintenance uplift that arrives whether you wanted it or not. Fair, and the answer is in the published terms rather than the sentiment. An enterprise platform's end of life arrives on a horizon measured in years, usually with a supported upgrade path, and asks for a migration you can plan: recompile, re-certify, regression-test the logic you have. A model retirement is sixty days' notice at the floor — the vendor publishes tentative dates further out, and then its three most recent retirements landed sixty to sixty-two days from announcement [8] — and it asks for a re-tuning instead: thresholds, prompts and confidence bands calibrated against one model's behaviour have to be re-derived against another's, and the only way to learn whether they still hold is to run them and look. So the distinction is not "a price you do not set", because you never set any of them. It is a price you do not set, on a calendar you do not keep, governing behaviour you calibrated against and cannot pin down. The first is procurement. All three at once is what I mean by load-bearing.

There is one real escape. Open-weight models exist and can be served on infrastructure you own: one current family ships instruction-tuned weights at several sizes with a 128K context window, explicitly positioned for deployment on your own hardware or your own cloud, with documented serving through vLLM, SGLang, Docker and quantized runtimes [11]. Nobody can retire a model you hold, and nobody can reprice it.

I cannot hand you the invoice, but the shape of the price is knowable, in three parts. The bill changes species: you stop paying per call and start paying for capacity sized to your peak, so the money goes out whether the queue is full or empty, and a well-specified prompt buys headroom rather than cash. You acquire a standing operations job that used to be someone else's — serving, capacity planning, quantization choices, and an upgrade decision that now arrives on nobody's calendar, which cuts both ways: nobody improves it either, so reaching the next one is a project you fund rather than one you inherit. And the quality question becomes yours, which lands back on the imputation result: the win came from what the model absorbed in pre-training, so a smaller model is not merely cheaper, it knows less about your domain [5] — and the harness that says whether it still knows enough is yours to build and run.

There is a middle path that prices the same trade in the open. One major cloud sells model invocation capacity at a fixed cost, billed hourly, with a commitment of none, one month or six — the longer the commitment, the deeper the discount — and states plainly that under a term you cannot delete the provisioned throughput before it ends, and billing continues until you do [12]. That is real price certainty, sold without pretence, and notice what buys it: you fix the price by converting a variable cost into an obligation you cannot leave. Control is purchasable, never free, and the currency is always some other commitment.

Which is where the accountants in the room stop nodding. An ordinary variable cost has a unit under it — per record, per call, per shipment — and the unit is what lets you multiply by volume, charge the cost to the thing it produced, and defend the line in a business case. This one has no stable unit. The cost of a single result moves with the model you are routed to, with the length of the prompt and the context it dragged in, and with the supplier's next price change, so two identical records processed a month apart are two different numbers. My co-author's version is the one that lands in a finance meeting: you can't tie the variable cost to a produced result as the per result cost is, itself, variable. He calls it a real conundrum, and it is. So notice what a commitment term is actually selling, because it is not a lower price. It is a denominator.

So when the deck says differentiator, the translation is: we are moving a vital process onto a supplier's release schedule for a large, real and probably temporary reduction in what the work costs to do — unless we run it ourselves, or buy the price down with a term we cannot leave. The four things below are how I would tell whether that sentence is being said on purpose.

So: differentiator, or cost centre?

Still a false choice, and now for a reason we can state precisely. The three abilities this article put under the microscope are each something a competent team could already do, at a price that decides who is allowed to ask for it — and when that price falls far enough it is a capability you did not have, whatever the mechanism underneath. The exceptions are real, and they are earlier in this piece rather than explained away; what each of them needed was a target somebody specified first. What none of it is, is self-checking, and it is not yours.

So the question I would put in front of a board, in place of the sentence they were handed, is this: which processes are we prepared to make load-bearing on a price we do not set? Some are worth it. Enrichment that is genuinely optional this quarter is a fine place to start, because the failure mode is a slower queue rather than a stopped business. Identity resolution in the middle of customer onboarding deserves the harder version of the question.

The catch is that the default way of buying this swaps a cost you controlled for one you do not, and you can buy the control back only at the price named above. What you cannot do is have both for the number on the slide, and that choice is invisible in every business case I have seen, because a business case has a column for price and none for control.

Put both in the room. Then promise less than you think you can deliver, and let the thing work.