Reinforce Is the Wrong Word: What an AI Roadmap Actually Does to an MDM Roadmap

Weaving Intelligence (House AI Style), with Jeff Shabel’s Experiential Commentary

I am asked to implement roadmaps, and these days the proposal that reaches me has AI in its title whether or not the work needs it. The master data roadmap arrives attached. Picture the slide that carries the pair: two roadmaps side by side, one headed AI and one headed master data management, MDM for short, the discipline of keeping one governed version of the customers, products, suppliers and locations that every other system quietly disagrees about. Arrows run both ways between the two columns. Underneath them sits one sentence, and the sentence says the two initiatives reinforce each other.

It is a good slide. As a statement of intent it is usually sincere, and the best evidence available in 2026 says the money behind the data column is going up rather than down. I will concede all of that before I argue anything, because none of it is where the trouble is.

The trouble is the verb. What I watch pass between the two columns, once the work starts, is not reinforcement. It is subordination. The master data roadmap is funded to exactly the depth the AI roadmap needs, and the rest of it is never built.

That is a narrower claim than people expect from somebody in my trade, so it is worth being plain about what it is not. It is not the complaint that master data is underfunded. That complaint is older than most of the people now making it, and the surveys below do real damage to it. It is a claim about the shape of what gets funded rather than the amount, and shape is precisely what a budget total cannot show you. A starved programme looks starved; everybody can see it, and somebody eventually fixes it. A programme funded to the wrong shape hits its milestones, reports green, and fails the first time somebody asks it for something the AI initiative never needed.

Here is the narrow claim I will defend, stated so it can be checked: where an AI initiative is the only sponsor a piece of master data work has, the funded scope of that work follows the AI use case, and the parts of the discipline the use case does not consume go unbuilt. Everything below either supports that sentence, pushes on it, or tells you what to do about it. The case for the slide gets heard first, and at full strength.

The case that the two roadmaps already reinforce each other

Start with the money. In January 2026 Informatica published its CDO Insights 2026 study, a survey of 600 data leaders across the US, the UK and EU, and Asia-Pacific. Eighty-six percent said they were "proactively increasing their data management investment in 2026" [1]. The same study found 69% had integrated generative AI into their business practices, up from 48% a year earlier; 57% named data reliability as a barrier to moving AI from pilot to production; and more than three-quarters said their company's AI governance does not completely keep pace with how employees are actually using AI [1]. That is not a picture of a discipline being starved. It is a picture of one being fed, and fed because of AI.

Then the standing of the discipline itself. Semarchy's State of Data Management in 2026, a survey of 1,000 C-suite executives across the US, the UK and France, reports that "exactly half of organizations have adopted Master Data Management as a foundation for AI. The other half are scaling on fragmented data," and that "for the first time, data management and governance rank above cost and talent as the primary obstacle to AI success" [2]. For anyone who has spent a career arguing that master data is not back-office plumbing, that second sentence is the one you wait decades to read. Data management has moved from the bottom of the list of obstacles to the top, and it got there at executive level rather than in a backlog grooming session.

Then the analyst telling boards what happens if they skip it. In February 2025 Gartner predicted that "through 2026, organizations will abandon 60% of AI projects unsupported by AI-ready data," on the back of a survey of 248 data management leaders in the third quarter of 2024, 63% of whom either did not have, or were unsure whether they had, the right data management practices for AI [3]. If you want a sentence to put in front of a committee that has been reluctant to fund data work for a decade, that one will do. It says, from the firm the committee already reads, that the shiny thing dies without the dull thing.

Put the three together and the slide looks like a fair summary. Money is rising. Master data is being adopted as a foundation, at the top of the house. The most-read analyst in the room is warning that AI projects fail without the data work underneath them. If AI is the reason master data finally gets funded, the obvious question is why anybody in my position would complain about the reason.

A disclosure before I weigh any of it, because two of those three sources are vendors and my argument ends by favouring master data funded on its own account. The practice behind this publication is a Profisee partner, and it also holds a referral agreement with Profisee. Clients pay us for deployment work; a licence sale we refer earns us a referral fee; and our services revenue depends on this category of software being bought at all. Weigh my criticisms of the case for AI-led funding above anything I say in favour of the discipline.

With that on the table, the honest assessment is that the case is strong and mostly true. Both surveys are vendor-sponsored, Informatica and Semarchy both sell data management software, and both measure what executives report intending rather than what anybody booked. Informatica's "data management" is a wider category than master data, so its 86% does not land on the disputed line. Gartner's figure is a prediction, and the window it predicts for is nearly closed. I am granting all three anyway. The amounts are up, the discipline's standing is up, and the reason is AI. An argument that needs those facts to be false is an argument I would not bother making.

What a survey of amounts cannot see

Every one of those three sources measures an amount, a ranking or a posture. None of them measures scope, which is the only thing my claim is about, and so none of them can refute it. That is a weaker result than a refutation and I will not dress it up as more. But look at what the money in them is for, because the sources are more candid on that point than the slide is.

Informatica names the three top drivers of the increased spending: improving data privacy and security (43%), enhancing data and AI governance (41%), and upskilling employees in data and AI fluency (39%) [1]. Privacy and security has a life that predates AI and would survive it. The other two are services to the AI programme: governance of AI, and fluency so people can use AI. Not one of the three is a master data backlog item with a business case of its own. Nobody in that list is paying for a customer hierarchy.

Semarchy's headline does the same thing more visibly, and it does it in the report making the strongest available case for my own discipline. Adoption is counted as master data management "as a foundation for AI" [2]. The preposition carries the weight. A foundation for something is scoped by the thing it holds up, and nobody pours a foundation wider than the building they have been paid for.

Gartner is the most useful of the three, because Gartner states the mechanism outright. Its own account of AI-ready data says "there is no way to make data AI-ready in general or in advance" [4], and its February 2025 release says the data "must be representative of the use case, of every pattern, errors, outliers and unexpected emergence that is needed to train or run the AI model for the specific use" [3]. For an AI project that is sound advice, and I would give the same advice myself. Carried across into a funding line, it has a consequence nobody states. If readiness is defined per use case, then a data programme funded to make data AI-ready is funded, by construction, to the use case. The analyst is not recommending that master data be scoped that way; that step is mine. But it is a short step, and it is exactly the step a funding committee takes when the only proposal on the table with a sponsor attached is the AI one.

It helps to see how short the resulting scope is. Microsoft's own documentation for its master data product lays out the work in fifteen tasks: create a model; create entities, including entities used as domain-based attributes; create attributes and attribute groups; import the members of supporting entities; create and apply business rules; import the primary members and validate them against those rules; build derived and explicit hierarchies; create collections; create user-defined metadata; lock a version and assign it a flag, which "help users and subscribing systems identify which version of a model to use"; create subscription views; and configure user and group permissions [5]. The product itself is removed in SQL Server 2025 [5], and I cite the page for its list, not as a recommendation of anything. The list is the point. It is what a master data platform vendor thinks the job consists of.

Now set beside it, as an illustration rather than a count, what an enrichment pilot of the ordinary kind needs from that list: the entity it enriches, the handful of attributes it fills, and a way to read the result back out. Perhaps a business rule, if the pilot has somebody careful on it. The read path can be one of the platform's subscription views, but a pilot needs a view for its own consumer, not the locked, flagged versions that let every subscribing system trust what it reads. The hierarchies, the version flags that downstream systems read, the permission model and the stewardship that sits behind the rules are not rejected. They are never proposed, because the proposal that gets written is the one with a sponsor, and in that illustration the sponsor needs a few items out of fifteen. That gap is what the funded total hides. A committee can double the master data budget and still fund only those few.

A scope built for one pilot inherits that pilot's odds

Here the argument gets a second leg, and it is one the AI enthusiasts supplied. In July 2024 Gartner predicted that "at least 30% of generative AI (GenAI) projects will be abandoned after proof of concept by the end of 2025," naming poor data quality, inadequate risk controls, escalating costs and unclear business value as the reasons [6]. Seven months later came the 60% figure for projects without AI-ready data [3]. Both are predictions rather than counts, and I use neither as a measurement. I use them for what they tell you about the odds the market's own analyst assigns to the initiative that master data is being scoped to serve.

Follow that through. A master data scope that exists to serve one pilot carries that pilot's mortality. When the pilot is cancelled, and by the analyst's own reckoning a sizeable share will be, the funded items are left serving a use case that no longer exists, and everything that was never funded is still not there. Nothing else was holding them up. A master data programme funded on its own business case survives the cancellation of any one consumer, because it was never built for only one. That asymmetry is the practical cost of subordination, and it is the reason the difference between amount and shape is worth an article rather than a footnote.

Why the label wins the room

If subordination is costly, why does it happen at all? Not, I think, because anybody chooses it. William Ocasio's attention-based view of the firm, published in the Strategic Management Journal in 1997, opens from the premise that "firm behavior is the result of how firms channel and distribute the attention of their decision-makers" [7], and that premise is all I take from it. Funding follows attention, and attention follows whatever the organisation's structures put in front of the people who decide: the steering committee agenda, the quarterly review, the status report. A proposal with AI in its title gets a slot on all three. A proposal to build the explicit customer hierarchy does not.

The label is also cheap to attach and expensive to check. Boyuan Li's 2025 working paper separates forward-looking AI claims on earnings calls, which he calls AI talk, from AI expertise visible in employees' résumés, which he calls AI walk. Walk predicts later AI patents in both number and quality; talk does not; and the market "rewards talk in the short run but discounts it in the long run" [8]. It is about capital markets, not budget committees, so it proves nothing about the inside of a firm; what it shows is that even where the label is scrutinised by professionals with money on the line, saying "AI" earns attention before anybody can tell whether the saying was backed by anything.

Outside the firm, somebody does eventually check. In March 2024 the SEC settled charges against two investment advisers over their claims about using AI, with $400,000 in civil penalties between them [9]. That September the FTC announced five enforcement actions under the name Operation AI Comply, with its chair saying "there is no AI exemption from the laws on the books" [10]. Both are about claims made to customers and investors. No regulator audits the label on an internal project proposal. Inside the building the incentive runs one way: attach the word, win the slot, and let the master data work that happens to serve it ride along.

The standards govern the AI system, not the backlog

The strongest reply to everything above is that the sequencing method already exists, written by standards bodies rather than vendors, and the complaint is only that nobody adopts it. NIST's voluntary AI Risk Management Framework, public since January 26, 2023 with a playbook, a roadmap and a crosswalk, and now being revised under the White House AI Action Plan [11], has a core of "four functions: govern, map, measure, and manage" [12]. ISO/IEC 42001:2023, published in December 2023, "specifies requirements for establishing, implementing, maintaining, and continually improving an Artificial Intelligence Management System" [13]. I grant both, and an organisation putting AI into master data without either is taking a needless risk. But they govern an AI system: who answers for it, what it is for, how it is measured, what happens when it fails. On their public pages, neither ranks a master data backlog or says which of the fifteen tasks to build first. They tell you how to run the AI roadmap responsibly, not how to order it against anything else.

For that, the method most delivery organisations already use is the relevant one. Scaled Agile defines Weighted Shortest Job First (WSJF) as "a prioritization model used to sequence work for maximum economic benefit," estimated as the cost of delay divided by the job's duration, with cost of delay built from relative user and business value, time criticality, and risk reduction or opportunity enablement [14]. Its guidance opens with Don Reinertsen's line: "If you only quantify one thing, quantify the Cost of Delay" [14]. Notice what is not an input. There is no term for novelty, none for technology, and none for the name of the initiative a piece of work sits under. A customer hierarchy that removes a week of manual reconciliation every month competes on the same terms as an enrichment pilot, and wins or loses on value and duration.

So the claim I will make here is narrower than "there is no AI method." There are AI methods, and they are good at what they do. The claim is that none of them replaces the ranking function. Value, urgency, risk and duration decide the order; the AI frameworks add controls to the items that involve AI. What it rules out is specific: ranking a backlog by how close each item sits to the AI initiative. If a master data item moves up the list because it is "for AI" rather than because its cost of delay went up, the ranking has been captured, whatever framework is pinned to the wall.

Cheap matching, and what a benchmark cannot price

There is one more objection, and it is the one heard most often from conference platforms: language models will soon take over entity matching, and the matching strategies and data stewards with it. If that is true, a master data roadmap subordinated to the AI roadmap is simply a roadmap that has read the future correctly.

The accuracy half of this has real evidence behind it. Peeters, Steiner and Bizer found that "the best LLMs require no or only a few training examples to perform comparably to PLMs that were fine-tuned using thousands of examples," and that language-model matchers are more robust to entities they have not seen [15]. That removes the labelled-training-data cost, which was a large part of what made machine-learning matchers expensive to own.

The cost half has moved as well, and further. Huang, Pai and Wang benchmarked 46 model configurations across eight entity-resolution datasets under a fixed protocol, counting token cost alongside accuracy. An open-weight model reached 92.10 F1 "while costing ~20x less than GPT-5(high)," and "several ultra-budget configurations under $0.10 reach up to 89 F1, enabling inexpensive deployment" [16]. Fu and colleagues, clustering records inside the prompt rather than comparing them in pairs, report "reducing API calls by up to 5 times, while maintaining comparable monetary cost to the most cost-effective baseline" [17]. Ten cents exhausts nobody's budget, and an objection built on exhaustion alone is an objection with a shelf life. I concede that version of it.

What survives is narrower, and it still rules something out. Those are benchmark costs, per dataset, on curated data whose candidate pairs have already been selected. A production bill is the cost per comparison, times the comparisons your blocking strategy actually emits, times your record volume, times the number of times you run it, and the benchmark does not contain those multipliers and could not. The nearest thing to a production-shaped figure I found comes from an entity-resolution vendor whose product competes with the language-model approach, so weigh it accordingly: running a frontier model over 10,000 person records cost about $10 a run and took six to eight minutes, while the vendor's own engine processed all 92,175 records in the set in about 131 seconds [18]. One vendor, one model, one dataset. It is not a verdict. It is a reminder that the benchmark's ten cents and a real estate's run rate are different numbers. And the same benchmark that makes matching look cheap shows a twentyfold spread in cost by model choice [16], which means the price of the approach depends on a decision you will have to make again, on a schedule you may not set.

The claim I am left defending is this: a business case that quotes benchmark accuracy and benchmark cost has not priced the deployment. It rules out treating a per-dataset benchmark cost as a run rate. It does not rule out using language models for matching, and it says nothing against the accuracy result. Ask for the figure at your own blocking output, at your own volume, and at the next model's price as well as this one's.

From the roadmaps I have been asked to implement

The argument stops here, and what follows is my own operating experience: patterns from the programmes I have been asked to put these roadmaps into, not measurements, offered without a method for falsifying them.

One thing about that record belongs in front of everything else. I have not, to date, operated a governed language-model enrichment process on top of a master data foundation. Building the platform for one is a different job from having run one, and the order matters: nothing a pilot shows means much until the platform under it exists, though pieces of that platform can be tested early on borrowed or temporary architecture. What I have done with these tools is broad, from the publishing apparatus behind this publication to frameworks for generating proposals and technical diagrams, but it is not enrichment on master data in production. So what follows is about roadmaps, budgets, sequencing and the people in the room, which is where my experience lies, and not about how an enrichment model behaves at volume, which is where it does not.

The lightning rod

The quotations from here on are my written answers from interview, reproduced exactly as I typed them. Asked what actually happens between an AI roadmap and a master data roadmap, I refused the word the question offered:

That's simple: MDM gets ignored while AI sucks up all the oxygen and the budget. AI is the current 'next big thing' in the industry, therefore everything has 'AI' attached to the project proposal. Unfortunately, that tends to draw all the attention and the status reports to the lightning rod that is 'AI-enhancement.' So, instead of reinforcement, the MDM roadmap exists solely to enable the AI roadmap and that's the only portion of the MDM roadmap that gets implemented or funded.

That answer is blunter than the claim I defended earlier, and the difference matters. "MDM gets ignored" is not quite right, and the surveys say so: master data is not being ignored, it is being paid for. The last sentence is the accurate one. The master data roadmap is not starved; it is reduced to the portion that enables the other one, and that portion is funded. Read it as a claim about shape and it survives everything the field threw at it earlier.

What the answer adds to the argument above is the causal chain, and it is worth keeping intact because it is the only part anyone can act on. The proposal gets the label. The label draws the attention. The attention draws the status reports. And the status reports draw the money, because a steering committee funds what it is shown progress on. Ocasio's premise explains the middle links [7]; the status report is the link I would add. A status report for an AI initiative reports the AI initiative's milestones, and master data items appear in it only as dependencies of those milestones. An item that is not a dependency has no line in the report, and an item with no line in the report has nobody asking after it. Nobody decided to leave the customer hierarchy out. It simply never had a line.

There is an old name for the habit underneath this, and I have used it before: the golden hammer, the favoured tool that makes every problem look like the kind it solves. Today the hammer is a model. The syndrome is the same, and so is the way out of it, which starts with remembering that AI is a tool and not a cure-all.

The same four steps, whatever the roadmap

The right order of operations for aligning the two roadmaps is a question whose premise I refused before I answered it:

It's the same order of operations I would take irrespective of which roadmaps I'm asked to implement.Determine what the business really needsDetermine what's critical pathDetermine what's the 'low-hanging fruit'Determine WSJF priorititization

The first sentence is the substance. There is no special order of operations for AI and master data, and asking for one is already half of the capture, because it grants that AI work is a different kind of work to be ranked by different rules. The four steps are the ordinary ones, and they line up with the ranking function described earlier almost term for term: what the business really needs is value, critical path is time criticality, low-hanging fruit is short duration, and WSJF is the arithmetic that combines them [14]. None of the four asks whether an item is AI.

Look hard at the second step, though, because that is where subordination gets in without anybody cheating. Critical path is a legitimate input. But if the AI initiative is on the critical path, every master data item it depends on inherits critical-path status, and every item it does not depend on drops down the list for a reason that looks entirely proper. The ranking has not been gamed. It has been asked the wrong question: whose critical path? The business's, or the initiative's? The answer has to be the business's, and on a roadmap where AI is the only sponsor with a slot, nobody is paid to insist on it.

I went further in the same answer, further than I can defend as written:

Roadmap implementation is exactly the same as project management is exactly the same as product ownership. The hardest part is pushing back against other groups playing buzz-word bingo instead of prioritizing based upon business value and time to deliver.

"Exactly," twice, is too strong. Product ownership decides what is built and why, against a market, and is allowed to move the destination. Project management delivers against a plan, and exists in large part to stop the destination moving. Those are different jobs, and the tension between them is real. What the three genuinely share is narrower, and it is the only part of the sentence I need: the prioritisation discipline, value and time to deliver and nothing else in the ranking. That still rules something out: a ranking in which an item's position depends on which initiative it is filed under.

The second sentence I would keep exactly as it stands. The hardest part is not methodological. The method is on a public web page [14]. The hardest part is that buzz-word bingo is a competing ranking function, run by people with status-report slots, and it wins by default unless somebody pushes back with the dull one.

Accepted wisdom that has not had time to accumulate

Which accepted wisdom about AI in master data would I argue against? I did not name one:

I'd just make the same arguments against that accepted wisdom as I would against any other set: it's a set of heuristics that have, at most, 80% 'generic' utility. They're guidelines, not rules and need to be considered for their applicability to any specific situation before being vigorously applied.

On first reading that looks like a dodge. It was not, and when asked why I had declined to name a target, the reason I gave was sharper than the answer: putting AI inside master data platforms is new enough that I doubt the field has accumulated any wisdom to accept in the first place. The eighty percent answer is what you fall back on when there is no body of experience to appeal to.

That claim can be checked, within limits. The search we ran for accepted wisdom on AI in master data platforms, in August 2026, returned almost entirely vendor pages, comparison listicles and analyst predictions, not reports from people who had run it; that is a statement about one search, not about the field. The sources in the first half of this piece are two vendor surveys and two analyst predictions [1][2][3][6]. A trade-press survey of data management trends for 2026 is honest about what it is doing, and what it is doing is telling data management's story as AI's: "The demand for ROI on AI projects relies on strong data management fundamentals, a must for implementation" [19]. That is a sentence about AI. Even the case for my own discipline, in the places it is most often made, is made as a case for something else.

That is the real risk, and it is subtler than hype. It is mistaking marketing for consensus. Gartner's advice that data readiness is specific to a use case [4] is a good heuristic for running an AI project. Applied without checking whether it fits, as a rule for scoping a master data roadmap, it is the subordination argument written down in an analyst's voice. Test heuristics for applicability before applying them vigorously, including the ones with a famous logo on them.

The infrastructure step, and who owns it now

My sequence for standing up a new project of any kind is a long list with one line in it that matters:

The process is the same for standing up any kind of new project: plan, scope, estimate, review, cost, review, infrastructure, prototype, implement, standardize. You only do what you are given time for. The key sequence is infrastructure before PoC before implementation before standardization. You cannot do anything without the infrastructure and, with cloud outsourcing, that is becoming a blocker.

Stated that flat, it inverts the usual advice to de-risk the cheapest thing first, and a careful reader should push on it. What I actually do is less of a slogan. Parts of the platform get proven early on borrowed or temporary architecture, which is de-risking by any definition; then the full build; then the full proof of concept. The partial proofs are not skipped. They are simply not mistaken for the platform.

Two things in that answer bear on the roadmap argument. The last step is standardise, and "you only do what you are given time for." Read the fifteen tasks from the master data documentation again [5]: hierarchies, version flags, business rules, subscription views, permissions. Most of that is standardisation. It sits at the end of the sequence, which is exactly where a roadmap scoped to an AI pilot runs out of time. My own list, read honestly, predicts which half of the master data roadmap gets cut.

The second is the last sentence of the quotation. The infrastructure a master data roadmap now runs on is increasingly somebody else's, rented, metered and scheduled by a provider, and that moves the blocker outside the building. It is also where the next two answers pick up.

The ten-second test

Asked how to tell a realistic AI roadmap from an unrealistic one, I gave a test two clauses long:

Does is have a token costing budget attached and is there a pre-full-implementation phase for validating that token budget?

The second clause is the one that matters. A token budget that no phase of the plan has tested is an estimate for a workload nobody has run at volume, which is a guess with a number attached. And because a phase either appears on the roadmap document or it does not, this takes ten seconds to check rather than an audit.

The instrument usually offered in its place is a spending alert, and the documentation for one of the most common is candid about what it is: when a budget threshold is crossed, "resources aren't affected, and your consumption isn't stopped," and budgets are evaluated against costs every 24 hours [20]. That is a smoke alarm, not a circuit breaker. It is also the difference I have drawn before between a gate and a suggestion: a limit that nothing enforces is advice, however official the dashboard it lives on.

The reason the validation phase matters more on a subordinated roadmap is the one I gave when asked how to make the case for AI inside a data programme without overselling it:

Make the understated case rather than the overstated one. This is generally good advice, but it is especially important for AI because it's brand new and also capable of becoming a runaway expense. We don't really know all of the 'capabilities' AI is bringing to the table and we especially don't know how to ensure we don't outrun our budget with AI. 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.

The last clause is the one I would put on the wall. A hard cap bounds spending; it does not bound work. When a budget runs out in the middle of a run, the records that have not been processed still need processing. The process has stopped being paid for, not stopped being needed. On a roadmap where the master data scope was built only for the AI process, that is the worst available combination: the data work was sized to feed the model, and the model has stopped. I finished that answer by warning that once AI is inside a vital process it becomes load bearing, and its cost leaves the business's control; the argument about control rather than price is made at length in an earlier article in this series, Load-Bearing: Differentiator, Cost Centre, and the Question Neither Label Asks, and I will not make it twice.

The replacement claim, and the three costs inside it

Asked about the claim, familiar from conference platforms, that AI will replace matching and the data stewards with it, I did not deny it:

AI will replace every existing matching strategy and Data Stewards, too. Again, that may be true with an unlimited budget, but running everything through AI not only exhausts your budget before your data, it also introduces an external dependency and an external cost center to your data processing system that will be extremely costly to disconnect or replace.

The shape of the answer is the useful part. It does not say the claim is false. It says the claim is true under a condition nobody states. Unlimited budget is a device I reach for often, and here it is doing honest work. Earlier I conceded more of the budget half than this answer allowed, because the benchmarks make a single model run cheap [16][17]. The other two costs in the answer survive untouched, and they are different costs, usually blurred into one. An external dependency is a third party inside your data processing path. An external cost centre is a recurring charge whose unit price you do not set. And the switching cost sits on top of both.

The dependency has dates on it. One managed model platform publishes its lifecycle in more detail than most, which is to its credit: a generally available model's "retirement date (18 months out) is set programmatically," at retirement "all inference returns 410 Gone," and to the question of whether a retirement can be extended, the answer is "No. Retirement dates aren't extendable" [21]. Put a matching strategy on that platform and the master data roadmap has acquired an eighteen-month revalidation clock that it did not set and cannot move. Nothing on the AI roadmap will fund that revalidation, because to the AI roadmap it is not a milestone.

This stopped being a forecast for me in September 2026. I put it this way at the time:

I'm literally running into the whole 'model changed out from under your production pipeline with a more expensive model--in tokens and in cost' right now. Anthropic just decommissioned Opus 5.1 and replaced it with Opus 5.5, dropped me from High to Medium and increased my capacity usage. I've used Claude less this week than 'normal' and eaten up more of my allocation than my previous trend.

The point I was making was this is an example of my 'concern' occurring.

The vendor's page supports the mechanism: a request that sets no effort level now runs at medium where the previous generation ran at high, the new model "tends to think more per turn" at the same setting, and the list price fell to $4 and $20 per million input and output tokens from $5 and $25 [22]. It states no retirement; that part is my account of my own tools. The rate card fell. The tokens per result are the vendor's to change, and they changed with the model.

That shape is the part that breaks a business case, and I have put the reason bluntly. The trouble for the finance people in the room is that

you can't tie the variable cost to a produced result as the per result cost is, itself, variable.

An ordinary variable cost has a unit under it: per record, per call, per shipment. The unit is what lets you multiply by volume, charge the cost to what it produced, and defend the line. A matching strategy run through a model has a price per token, but not a stable price per record matched, because the number of tokens per record is set partly by the data and partly by a vendor. A master data roadmap that has handed its matching to the AI roadmap cannot state its own unit cost, and a line with no stable unit is hard to defend in the next budget round, which is when the AI roadmap will be asked what it is still for.

As for the stewards, matching is one line in the fifteen [5]. The steward's job is deciding the policy a comparison implements: what counts as the same customer here, which value survives when two records disagree, and which of those decisions may run unattended. When a model classifies confidently and wrongly, my position has been that the failure belongs to whoever set it up, because they gave it too little context to recognise what it did not know. The steward is where that context lives. An imitation of a steward for the matching portion can be a rational purchase. Somebody accountable for the rule is not something a model can be.

What reinforcement would actually look like

None of this means the slide's verb can never be true. It means the arrows on it point the wrong way. The work I would point to is designed the other way round, and on what the master data had to get right before a model was worth pointing at it, my answer was this:

One of the core elements of this project is that we are using AI to fill in the gaps in our master data, so the only data-related prerequisite is the output format — which in this case is mostly legacy — and data source access, which keeps expanding as the number of sources increases. Having the expected and required data structure in place is the main piece necessary, because that is the standard to which we are trying to get AI to help the data conform.

That inverts the slide. The expected and required data structure is the master data roadmap's product, and it is the standard. The model is a tool for getting data to conform to it: filling gaps, pulling structure out of sources that arrive without any. In that design the master data work defines the target and exists whether or not the model does, and the model is the thing that has to earn its place. AI serves master data, and the arrow runs from the standard to the model. That is reinforcement in a sense I will put my name to. I should be careful with it: this is a design, not yet a result, and the honest record above says so.

It also answers the funding question the surveys raised. If AI is why the money is up, fine; take the money. But spend it on the standard, because the standard outlives any one model, any one pilot, and any one vendor's calendar.

Two tests follow, and both take less time than reading this.

First, the survival test. Which items on the master data roadmap would still be funded if the AI programme were cancelled on Monday? Write the answer down where somebody else can see it. If the honest answer is none of them, there are not two roadmaps. There is one roadmap and a dependency that files its own status report. The fix is not a bigger number. It is one or two master data items funded on their own business case and ranked on the same value-and-duration arithmetic as everything else, so that the programme has a reason to exist that no single initiative can cancel.

Second, rank blind. Put every proposal on one list with the initiative names covered, rank it on value, urgency, risk and duration, and then uncover the names. Fund what comes out on top with a clear conscience. If an item moves four places when the word "AI" goes back on, that is not an opinion about hype; it is a measurement, and a measurement is much harder to argue past. Then ask of every AI item that survives the ranking whether it has a phase for validating its token budget before it goes live.

Spend the argument there, on the shape of what gets funded and the order it gets funded in, and not on whether AI is overhyped. That is the bigger fight and the unwinnable one, and it is not the one that decides whether the customer hierarchy ever gets built.

An earlier version of this piece — written before this publication rebuilt how its voices are generated — is published unedited at Reinforce Is the Wrong Word: What an AI Roadmap Actually Does to an MDM Roadmap (original), so the two can be read side by side. The account of why is at The Voice Problem.

References

[1] Informatica, New Global CDO Report Reveals Data Governance and AI Literacy as Key Accelerators in AI Adoption (news release, January 27, 2026), reporting the CDO Insights 2026 study: a survey of 600 data leaders across the U.S., UK/EU and APAC; 86% "proactively increasing their data management investment in 2026," with top drivers data privacy and security (43%), data and AI governance (41%) and employee upskilling in data and AI fluency (39%); 69% GenAI integration (48% the year before); 57% naming data reliability a barrier from pilot to production; more than three-quarters saying AI governance does not completely keep pace with employee AI use. A vendor-sponsored survey of self-reported intent. The release was read at source on September 26, 2026; the full report was not. https://www.informatica.com/about-us/news/news-releases/2026/01/20260127-new-global-cdo-report-reveals-data-governance-and-ai-literacy-as-key-accelerators-in-ai-adoption.html

[2] Semarchy, The State of Data Management in 2026 (report landing page) — "a global survey of 1,000 C-suite executives across the US, UK, and France"; "Exactly half of organizations have adopted Master Data Management as a foundation for AI. The other half are scaling on fragmented data"; "For the first time, data management and governance rank above cost and talent as the primary obstacle to AI success." A vendor-sponsored survey. Only the landing page was read (September 26, 2026); the report itself is behind a form and was not read, so only the figures the vendor publishes openly are used. https://semarchy.com/resources/ai-data-management-report-2026/

[3] Gartner, Lack of AI-Ready Data Puts AI Projects at Risk (press release, February 26, 2025) — "Through 2026, organizations will abandon 60% of AI projects unsupported by AI-ready data"; a Q3 2024 survey of 248 data management leaders in which 63% "either do not have or are unsure if they have the right data management practices for AI"; Roxane Edjlali quoted that the data "must be representative of the use case ... needed to train or run the AI model for the specific use." A prediction, cited as one. Release read at source September 26, 2026. https://www.gartner.com/en/newsroom/press-releases/2025-02-26-lack-of-ai-ready-data-puts-ai-projects-at-risk

[4] Gartner, AI-Ready Data (article page, undated as read) — Rita Sallam quoted: "There is no way to make data AI-ready in general or in advance." Read at source September 26, 2026. https://www.gartner.com/en/articles/ai-ready-data

[5] Microsoft, Master Data Services Overview (MDS) (SQL Server documentation) — enumerates fifteen tasks, from creating a model, entities, attributes and attribute groups through business rules, derived and explicit hierarchies, collections, user-defined metadata, version locking and flags ("Flags help users and subscribing systems identify which version of a model to use"), subscription views and user and group permissions; records that MDS "is removed in SQL Server 2025 (17.x)." Cited for what master data work consists of, not as a recommendation of a product. Read at source September 26, 2026. https://learn.microsoft.com/en-us/sql/master-data-services/master-data-services-overview-mds

[6] Gartner, Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept By End of 2025 (press release, July 29, 2024) — "At least 30% of generative AI (GenAI) projects will be abandoned after proof of concept by the end of 2025," citing poor data quality, inadequate risk controls, escalating costs and unclear business value. A prediction, cited as one. Read at source September 26, 2026. https://www.gartner.com/en/newsroom/press-releases/2024-07-29-gartner-predicts-30-percent-of-generative-ai-projects-will-be-abandoned-after-proof-of-concept-by-end-of-2025

[7] William Ocasio, "Towards an Attention-Based View of the Firm," Strategic Management Journal 18 (Summer Special Issue, 1997): 187–206 — abstract: "Firm behavior is the result of how firms channel and distribute the attention of their decision-makers." ABSTRACT ONLY: read on the Northwestern Scholars record on September 26, 2026; a hosted copy of the paper returned no readable text, and the paper itself was not read, so only its opening premise is relied on. https://www.scholars.northwestern.edu/en/publications/towards-an-attention-based-view-of-the-firm

[8] Boyuan Li, AI Washing (University of Florida, working paper, August 2025) — "AI talk" from forward-looking in-house AI investment claims on quarterly earnings calls, "AI walk" from AI-related human capital in employee résumés; "AI walk, but not AI talk, predicts subsequent AI patent quantity and quality"; "Market rewards talk in the short run but discounts it in the long run." A working paper, not peer-reviewed, and about capital markets rather than internal budgeting; both limits are stated in the text. Abstract read at source September 26, 2026. https://bpb-us-e2.wpmucdn.com/sites.utdallas.edu/dist/8/1090/files/2025/09/AI_Washing_Boyuan_Li.pdf

[9] U.S. Securities and Exchange Commission, press release 2024-36, SEC Charges Two Investment Advisers with Making False and Misleading Statements About Their Use of Artificial Intelligence (March 18, 2024) — settled charges against Delphia (USA) Inc. ($225,000) and Global Predictions Inc. ($175,000), $400,000 in total civil penalties. Read at source September 26, 2026. https://www.sec.gov/newsroom/press-releases/2024-36

[10] U.S. Federal Trade Commission, FTC Announces Crackdown on Deceptive AI Claims and Schemes (press release, September 25, 2024) — five law enforcement actions under Operation AI Comply; the chair quoted, "There is no AI exemption from the laws on the books." Read at source September 26, 2026. https://www.ftc.gov/news-events/news/press-releases/2024/09/ftc-announces-crackdown-deceptive-ai-claims-schemes

[11] National Institute of Standards and Technology, AI Risk Management Framework (programme page) — AI RMF 1.0 released January 26, 2023, "intended for voluntary use and to improve the ability to incorporate trustworthiness considerations into the design, development, use, and evaluation of AI products, services, and systems," with a Playbook, Roadmap and Crosswalk; "The AI RMF 1.0 is being revised as part of the White House AI Action Plan." The programme page was read at source September 26, 2026; the framework document (NIST AI 100-1) was not opened. https://www.nist.gov/itl/ai-risk-management-framework

[12] National Institute of Standards and Technology, AI Resource Center, AI RMF Core (section 5 of the online framework) — "The Core is composed of four functions: govern, map, measure, and manage." That section was read at source September 26, 2026; the remainder of the framework was not. https://airc.nist.gov/airmf-resources/airmf/5-sec-core/

[13] ISO/IEC 42001:2023, Information technology — Artificial intelligence — Management system (ISO/IEC JTC 1/SC 42; edition 1, December 2023; 51 pages) — "specifies requirements for establishing, implementing, maintaining, and continually improving an Artificial Intelligence Management System (AIMS) within organizations." The catalogue entry was read at source September 26, 2026; the standard itself is sold (CHF 225) and was not opened, so nothing here characterises its clauses. https://www.iso.org/standard/42001

[14] Scaled Agile, Inc., Weighted Shortest Job First (SAFe guidance) — "a prioritization model used to sequence work for maximum economic benefit," estimated as cost of delay divided by job duration, with cost of delay built from relative user and business value, time criticality, and risk reduction and/or opportunity enablement; opens with Don Reinertsen's line from The Principles of Product Development Flow, "If you only quantify one thing, quantify the Cost of Delay." The public opening section was read at source September 26, 2026; the rest of the page sits behind a login and was not read, and Reinertsen's book was not opened. https://framework.scaledagile.com/wsjf

[15] Ralph Peeters, Aaron Steiner and Christian Bizer, Entity Matching using Large Language Models, arXiv:2310.11244 (v4, October 2024; Proceedings of the 28th International Conference on Extending Database Technology, EDBT 2025) — "The best LLMs require no or only a few training examples to perform comparably to PLMs that were fine-tuned using thousands of examples"; LLM-based matchers "exhibit higher robustness to unseen entities." Abstract read at source September 26, 2026; the full paper was not read. https://arxiv.org/abs/2310.11244

[16] Donghao Huang, Prasan Pai and Zhaoxia Wang, "Entity Matching with LLMs at Scale: Accuracy, Cost, and Reasoning Effects," in Trends and Applications in Knowledge Discovery and Data Mining (PAKDD 2026), Lecture Notes in Computer Science vol. 16603, pp. 112–124, Springer (DOI 10.1007/978-981-92-2014-4_10) — 46 model configurations across 8 datasets under a fixed protocol, with API-equivalent token cost measured alongside accuracy; "GPT-OSS:120b attains 92.10 F1 while costing ~20× less than GPT-5(high)"; "several ultra-budget configurations under $0.10 reach up to 89 F1, enabling inexpensive deployment." Abstract read at source September 26, 2026; the chapter body is paywalled and was not read. https://link.springer.com/chapter/10.1007/978-981-92-2014-4_10

[17] Jiajie Fu, Haitong Tang, Arijit Khan, Sharad Mehrotra, Xiangyu Ke and Yunjun Gao, In-context Clustering-based Entity Resolution with Large Language Models: A Design Space Exploration, arXiv:2506.02509 (June 2025; accepted to SIGMOD 2026) — proposes LLM-CER, clustering records in context rather than matching pairs; reports "reducing API calls by up to 5 times, while maintaining comparable monetary cost to the most cost-effective baseline." Abstract read at source September 26, 2026; the full paper was not read. https://arxiv.org/abs/2506.02509

[18] Clair Sullivan, I Pitted an LLM Against Senzing for Agentic Entity Resolution. And Whew. (Senzing blog, July 9, 2026; modified July 13, 2026) — Claude Opus 4.8 against Senzing's engine on 92,175 person records; at 10,000 records the LLM runs cost about $10.04 and $10.17 and took 371 and 501 seconds, against 131.47 seconds for the engine on the full set. Published by a vendor whose product competes with the approach it measures; one model, one dataset. Read at source September 26, 2026. https://senzing.com/llm-vs-senzing-agentic-entity-resolution-tokenomics/

[19] Michelle Knight, Data Management Trends in 2026: Moving Beyond Awareness to Action (DATAVERSITY) — frames data management throughout as foundational to AI; "The demand for ROI on AI projects relies on strong data management fundamentals, a must for implementation." Read at source September 26, 2026. https://www.dataversity.net/articles/data-management-trends/

[20] Microsoft, Tutorial: Create and manage budgets (Microsoft Cost Management documentation) — "Notifications are triggered when the budget thresholds are exceeded. Resources aren't affected, and your consumption isn't stopped"; budgets "are evaluated against these costs every 24 hours." Cited for the documented behaviour of the control. Read at source September 26, 2026. https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/tutorial-acm-create-budgets

[21] Microsoft, Foundry Models lifecycle and support policy (Microsoft Foundry documentation) — a generally available model's "Retirement date (18 months out) is set programmatically"; at retirement "all inference returns 410 Gone"; to whether a retirement can be extended, "No. Retirement dates aren't extendable." Cited for the documented terms, not as a criticism of a platform whose policy is published in more detail than most. Read at source September 26, 2026. https://learn.microsoft.com/en-us/azure/ai-foundry/openai/concepts/model-retirements

[22] Anthropic, What's new in Claude Opus 5.5 (Claude Platform documentation) — the default effort is medium, and "a request that omits effort runs at medium; on Claude Opus 5 it ran at high" (code formatting on the parameter names dropped); "At the same effort setting the model tends to think more per turn than Claude Opus 5"; "$4 USD per million input tokens and $20 USD per million output tokens, below Claude Opus 5's $5 and $25." The page compares with Opus 5 and states no retirement of a prior model. Read at source September 26, 2026. https://platform.claude.com/docs/en/models/opus-5-5/whats-new-opus-5-5