The Primrose Path: Where AI Is Taking Policy Enforcement, Exceptions and Routing in Master Data
Weaving Intelligence (House AI Style), with Jeff Shabel’s Experiential Commentary
I was asked to look five years ahead at the three jobs that keep a master data programme honest after go-live: enforcing the policies, handling the exceptions the policies cannot settle, and routing the work to the person who should do it. Which would models take over first, and which would they not take over in my working life? I did not pick one:
You’re not going to like the answer: AI will take them all over somewhere and, in many, possibly even most, cases it will do a ‘good enough’ job to keep getting more responsibility.
That is a forecast, and I want it read as one. It is a direction and an order of handover, not a dated prediction: nothing here says in which year any of the three jobs changes hands. It is not what I recommend. The two are easy to blur in an article about AI, because much of what I read on the subject is selling a future and a forecast sounds like an endorsement when it is said with confidence. What I advise anyone running a master data programme to do while the forecast plays out does not change because of it. It is the position I have argued before: no model in the default flow of a pipeline, with its use measured and controlled (the argument of Putty, Not Body Panels), and a model's output landing in a steward's queue as a suggestion the steward approves (the argument of Another Set of Eyes).
A word on the three jobs, since vendors and analysts use them loosely. Policy enforcement is checking records against the rules the organisation has written: required fields, valid codes, reference lists, format and range rules, the conditions under which a record may be published. Routing is deciding who gets a piece of work: which steward, which queue, which escalation path when it sits too long. Exception handling is everything left over: the record the rules flag but cannot fix, the match the matcher cannot decide, the value that is valid by every rule and still wrong.
The pressure is the budget
The reason I gave first was not the technology. It was money:
Even today there is a ton of pressure to incorporate AI and other automation processes into all aspects of Data Governance to bypass human bandwidth and, more importantly, budgetary limitations.
Bandwidth is the reason usually given, and budget is the reason underneath it. Bandwidth is a staffing problem with an obvious fix: more people. AI is attractive because it promises to solve the bandwidth problem without the budget line that the obvious fix requires. That is why my own answer weighted budget more heavily, and why I expect the takeover to arrive through the finance office rather than through the data office.
The analyst firms are forecasting the same direction from the other side of the table, and their forecasts are worth reading as forecasts, not as findings. Gartner predicted in March 2025 that "by 2029, agentic AI will autonomously resolve 80% of common customer service issues without human intervention, leading to a 30% reduction in operational costs" [1]. Three months later it predicted that "by 2027, 50% of business decisions will be augmented or automated by AI agents for decision intelligence" [2], and, separately, that "at least 15% of day-to-day work decisions will be made autonomously through agentic AI by 2028, up from 0% in 2024" [3]. The first of those puts the cost reduction in the same sentence as the autonomy, which is the argument my answer describes.
The clearest public case of the argument being won, and then partly lost, is not from master data at all. In February 2024 Klarna announced that its AI assistant had handled "two-thirds of Klarna's customer service chats" in its first month, was "doing the equivalent work of 700 full-time agents", was "on par with human agents in regard to customer satisfaction score", and was "estimated to drive a $40 million USD in profit improvement" [4]. Those are the company's own claims, in a press release. By May 2025 its chief executive was quoted, from an interview with Bloomberg, saying that "as cost unfortunately seems to have been a too predominant evaluation factor when organizing this, what you end up having is lower quality", and the company was recruiting human agents again [5]. Both halves of that story fit my answer. The assistant did a job good enough to be given most of the work, the work was given to it because it was cheaper, and the quality cost appeared afterwards. The reporting does not say the assistant was switched off.
Gartner's own surveys read the same way. A poll of 163 customer service leaders in March 2025 found that "95% of customer service leaders plan to retain human agents to strategically define AI's role", and the firm predicted that "by 2027, 50% of organizations that expected to significantly reduce their customer service workforce will abandon these plans" [6]. That is the forecast running into the floor, and it is the strongest evidence against my prediction that I found. It is evidence against total replacement. It is not evidence that the model's share of the work is shrinking: the same firm still forecasts that agents will resolve 80% of common issues on their own [1], and on that reading the people kept are the ones left with the rest.
Budget pressure also cuts the other way, and I have argued that side of it myself. A model in every record's path is a variable cost that grows with the volume of data, a recurring charge set by someone else, and a dependency that is expensive to remove; I have said before that the claim that AI will replace both matching strategies and stewards may hold for an organisation with an unlimited budget, which is the argument Reinforce Is the Wrong Word built on. An organisation I have worked with put AI into everything in its pipelines, outran its budget almost at once, and then overcorrected by cutting its AI use back to the bone. Forrester's forecast for 2026 is that same correction at market scale: with "fewer than one-third of decision-makers able to tie the value of AI to their organization's financial growth", chief executives "will lean more on their CFOs to approve AI investments", and "enterprises will defer a quarter of their planned AI spend into 2027" [7]. Gartner expects "over 40% of agentic AI projects" to be cancelled by the end of 2027 "due to escalating costs, unclear business value or inadequate risk controls" [3].
The two budget arguments do not cancel; they decide where the takeover lands. A steward is a salary, a fixed cost the budget office sees every month; a model call costs far less than a steward's time, per decision, and the budget office sees it only in aggregate, and only if someone is measuring. When finance compares the two per decision, the model, sold as a wrapper round the rules, wins wherever the decisions are many, cheap and alike, and it loses wherever the decisions are few, expensive and different from one another, because there the total saving is small, the decisions being few, and the price of one wrong answer is not. That ordering, my reasoning from the two cost structures and not a measured result, is a forecast about which of the three jobs goes first (Figure 1), and it agrees with what I said about each of them.

Where the budget sends each job: a forecast A note across the top reads: A forecast, not advice. No prices, dates or shares are shown, and the positions are an order, not a scale.
Top row, two boxes. A steward, reading A salary: a fixed cost the budget office sees every month; and A model call, reading Far less than a steward's time, per decision; seen only in aggregate, and only if someone is measuring. An arrow runs from each into a box reading Finance compares the two per decision.
Below it, a shaded panel. Arrows run from the comparison to two boxes: on the left, Many, cheap, alike decisions, reading The model wins the comparison; on the right, Few, expensive, different decisions, reading The steward keeps them. Under the left box, inside a group box labelled Taken by the model, in this order, sit Policy enforcement, reading Goes first, and Routing, reading Follows enforcement. Under the right box, highlighted, sits Exception handling, reading Handed over last, a class at a time: the dashed arrow is one class moving over to the model side once it passes a budget review; a dashed arrow runs from it to the group box around Policy enforcement and Routing.
A band across the bottom, headed The counter-pressure, reads: A model in every record's path is a variable cost that grows with the data. Push too far and the budget pulls back, putting people beside the model rather than in its place.
Enforcement and routing are the easier jobs
On policy enforcement and routing, my answer conceded the ground and then took most of it back:
Right now, AI is great at enforcing policy—though, in fairness, you don’t need AI to do that, just well written algorithms and processes that apply them and listen to their output. AI is also good at routing work to people. Again, this can be—and is—done with algorithms alone. Where AI is making strides is in exception handling, but it’s still not as good or knowledgeable as a human.
The concession is real. A language model can read a written policy, check a record against it and say what failed, and it can read a work item and decide which queue it belongs in. The taking back is the more important half. Neither job needs a model, and neither has needed one for a long time.
Policy enforcement as code is a mature discipline outside master data. The Open Policy Agent, a graduated open-source project of the Cloud Native Computing Foundation, describes itself as "a general-purpose policy engine that unifies policy enforcement across the stack", in which policies are written in "a high-level declarative language" and decisions are produced "by evaluating the query input against policies and data" [8]. Its design principle is the one that matters here: it "decouples policy decision-making from policy enforcement" [8], so the rule can be read, tested and versioned apart from the system that applies it. What a rule engine gives you that a model does not is that the same record gets the same answer every time, and the reason for the answer is the rule, which a person can read.
Routing is older still as a solved problem. In 2004 Nick Russell, Arthur ter Hofstede, David Edmond and Wil van der Aalst catalogued the ways workflow systems assign work to people, and every pattern I read in the catalogue is a rule, not a model: role-based allocation, "the ability to specify at design time that a task can only be executed by resources which correspond to a given role"; capability-based allocation, by "specific capabilities that they possess"; history-based allocation, by "previous execution history"; round robin; shortest queue, to "the resource that has the least number of work items allocated to it"; and escalation, when work stalls [9]. None of that needs a model. A model can make routing smarter at the margin, choosing by the content of the item rather than its type, but the gain is small, and so is the risk, because a misrouted item is only a delay as long as the person it reaches knows what to do with it.
Which is why I expect AI to take over both, and why the takeover will mostly be a relabelling. Gartner has a name for it: "agent washing", "the rebranding of existing products, such as AI assistants, robotic process automation (RPA) and chatbots, without substantial agentic capabilities", and it estimates "only about 130 of the thousands of agentic AI vendors are real" [3]. The same release says "many use cases positioned as agentic today don't require agentic implementations", and advises "using AI agents when decisions are needed, automation for routine workflows" [3]. That is my point about enforcement and routing, in an analyst's words. The rule engine and the routing table will survive; the model will be wrapped around them, sold as the thing doing the work, and mostly be good enough, because the work underneath is simple.
The vendor we work with is already selling that wrapper, so a disclosure before I say more. The practice behind this publication is a Profisee partner. Clients pay us for deployment work, a licence sale we refer earns us a referral fee from the vendor, and our services revenue depends on master data management being bought. That interest runs toward praise of Profisee and of the category, so weigh anything favourable I say about either below what I say against them.
Profisee's page for Aisey, its AI assistant, now opens on "the agentic future of MDM" and says its agents "monitor your environment, detect conditions, and act automatically — replacing repetitive stewardship and admin work with autonomous execution", with templates that include "Review Records for Data Quality Violations" and "Edit or Update Attributes Automatically" [10]. Stewards, it says, can review match proposals and survivorship and "interrogate records for violations or let those tasks run autonomously", and it invites them to "let Aisey handle repetitive data quality enforcement so stewards can focus on the decisions that really matter" [10]. That is my prediction about enforcement on a product page. The page does not say what the agents do when a rule and the model disagree, or, beyond saying every change is reviewable, what a steward sees after an autonomous edit, and I have not used the agents at a client: the environments I work in do not always run the newest release, and I have said so before. What the page does show is that enforcement is among the jobs being offered to a model to run alone, which is what the cost argument predicts.
Exceptions are where the knowledge lives
The third job is the one I held back. Exception handling is where I said AI is making strides and is still not as good or as knowledgeable as a person, and both halves of that need defending.
The strides are real and measurable on benchmarks. Avanika Narayan and colleagues cast five data cleaning and integration tasks as prompts in 2022 and found that "large FMs generalize and achieve SoTA performance on data cleaning and integration tasks, even though they are not trained for these data tasks" [11]. Ralph Peeters, Aaron Steiner and Christian Bizer tested large language models on entity matching, the core of master data work, and reported 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", with "higher robustness to unseen entities" [12]. They also found that a model "can generate structured explanations for matching decisions" and identify potential causes of matching errors from its explanations of wrong decisions [12].
What the benchmarks measure is not quite what a steward does. A benchmark pair has a right answer that someone wrote down. A steward's exception is the record whose right answer depends on something nobody wrote down: that two suppliers with different tax identifiers are one company after an acquisition, that a customer's legal name changed last quarter and the old one is still on the contracts, that a product code is valid and was retired for a reason that lives in an email. Peeters and his co-authors also found "there is no single best prompt but that the prompt needs to be tuned for each model/dataset combination" [12], so the result depends on how the prompt is set up for each model and dataset. Moe Kayali and colleagues measured one form of that gap, on labelling the type of each column in enterprise tables. They found that "the performance of methods based on LLMs seriously degrades when tested on real-world enterprise datasets" and that "current benchmarks, based on public data, overestimate the performance of LLMs" [13]. They also report that, on the task they tested (labelling the type of each column), the system can close the gap itself: with three techniques the pipeline runs on its own, seeded with a small number of starting classes, "the performance on enterprise data becomes on par with that of public data" [13]. That is the strides half of my answer, and it is stronger than I would like: the context the model lacked was in the data, and the system worked it out. What no technique of that kind reaches is the context that is in no table at all: the acquisition, the renamed customer, the code retired for a reason that lives in an email. That is the knowledge half, and the person who holds it is the steward.
The more troubling finding is about what a model does when it does not know. Adam Kalai and colleagues argued in 2025 that "large language models sometimes guess when uncertain, producing plausible yet incorrect statements instead of admitting uncertainty", because "the training and evaluation procedures reward guessing over acknowledging uncertainty" [14]. An exception is, by definition, the case where the rules were uncertain. A system rewarded for guessing is being pointed at exactly the records where a guess does the most damage.
The field evidence on who gains from AI help points the same way. Erik Brynjolfsson, Danielle Li and Lindsey Raymond studied 5,179 customer support agents (the figure in the working-paper abstract I cite; the published journal abstract gives 5,172, and neither abstract says what the seven-agent difference is) given a generative AI assistant and found productivity rose "by 14% on average, including a 34% improvement for novice and low-skilled workers but with minimal impact on experienced and highly skilled workers", with suggestive evidence that the model "disseminates the best practices of more able workers" [15]. The model carried what the experienced people already knew to the people who did not. It added little to the experienced people themselves. That is my claim about exceptions, made on a different kind of work: the model lifts the routine case towards the standard of the expert, and leaves the expert's own cases where they were.
I have said before that no AI system I have seen checks and fixes records as well as a steward who knows the domain, at a cost that makes sense. The prediction leaves that intact for now. It says the gap will narrow, the model will be given more exceptions as it narrows, and much of the time it will be good enough. The question the prediction raises is what happens to the steward in the meantime.
Lisanne Bainbridge answered it in 1983, about industrial process control rather than data. In "Ironies of Automation" she observed that automation leaves "the operator to do the tasks which the designer cannot think how to automate", while the operator "may be expected to monitor that the automatic system is operating correctly" [16]. The irony she named is the one that matters here: "physical skills deteriorate when they are not used", and "the more advanced a control system is, so the more crucial may be the contribution of the human operator" [16]. Translate it into a master data programme and it reads as a forecast of its own. The model takes the exceptions it can handle; the steward is left with the ones it cannot, which are the hardest; and the steward handles fewer of them, so gets less practice at exactly the judgement the remaining cases need. The better the model gets, the more the residual steward matters, and the less prepared that steward is (Figure 2).

The steward's loop: Bainbridge's irony in master data A note across the top reads: A concept, not data: no rates, counts or dates. Read clockwise from the first box; the last arrow closes the loop.
Four boxes in a loop, read clockwise from the top left. The model takes the exceptions it can handle, reading The first turn of the loop. An arrow runs to The steward is left with the ones it cannot, reading Which are the hardest. An arrow runs down to the highlighted box The steward handles fewer exceptions, reading So gets less practice at the judgement the remaining cases need. An arrow runs left to The better the model gets, reading The more the residual steward matters, and the less prepared that steward is. An arrow labelled As the gap narrows, the model is given more exceptions runs up from that box to the first box, closing the loop.
Human in the lead
What follows comes from my own record. I offer it as a pattern, not a law, and I use the sources above to test it, not to prove it.
My answer pointed to Jordan Morrow, who at the 2026 Profisee Data Hero Summit on 8 October, in his session "Being Human in the Age of Data and AI" [17], proposed the change of phrase himself: "In practice we call it human in the loop. I actually want to change that phrase to be human in the lead: not a human on the sidelines who observes, but a human who is making informed decisions with the data and AI." He did not throw the loop away. His slide on the point says "Human-in-the-loop only works if the human stays curious enough to question the output." The answer gave it straight after the point about exceptions, as the reason the person stays in charge. The difference between the two phrases is the whole argument. A human in the loop is a checkpoint the automated process passes through, and a checkpoint is a recurring cost, which is the kind of cost a budget review looks at first. A human in the lead decides what the automated process is for, and the model works beside that person to make the decision better, not to take it away, whatever savings full automation promises.
Profisee's own summary of the summit, by Malcolm Hawker, describes a related but not identical shift, "from human-first (where people define the rules) to human-led (where people review and approve the rules suggested by AI)", which he writes that both he and Morrow highlighted in their keynotes [18]. Morrow's own slide on the point reads "AI should inform decisions, not replace the person responsible for them" [17]. I would put the line in a different place. In Hawker's definition the model drafts the rules and people approve them. That is a good design for many rules, and it is the suggestion-in-the-queue model applied to configuration rather than to records. But approval is a checkpoint, and an approver who approves most of what arrives is a loop, not a lead. The test I would apply is whether the person can still write the rule without the suggestion, and whether anyone would notice if they stopped reading.
The law has started to write the same distinction for the systems it regulates. Article 14 of the European Union's AI Act requires high-risk systems to be built so they "can be effectively overseen by natural persons", and requires those persons to be able "to remain aware of the possible tendency of automatically relying or over-relying on the output", to "disregard, override or reverse the output", and to "interrupt the system through a 'stop' button or a similar procedure" [19]. Many master data pipelines will not be high-risk systems under the Act, as far as I can tell, and on the current timetable the article applies to the high-risk uses the Act lists from December 2027 [19]. I cite it for its shape, not its reach: it describes a human in the lead, someone who understands the system, can say no to it and can stop it, not a reviewer at the end of a conveyor.
There is a serious objection to all of this, and I want to meet it rather than step round it. Michelle Vaccaro, Abdullah Almaatouq and Thomas Malone reviewed 106 experiments and 370 effect sizes and found that "human–AI combinations performed significantly worse than the best of humans or AI alone", with "performance losses in tasks that involved making decisions" [20]. If the model alone is better at the decision, combining it with a person makes the result worse. That cuts against keeping a human on routine enforcement, and I accept it there: where a written rule or a tested model is measurably right more often than the steward, let it run, and spend the steward elsewhere. But the same review found that "when humans outperformed AI alone, we found performance gains in the combination" [20]. That is the exception queue, on my own account of where the gap still is. It does not argue against a person working with the model where the person is better; it finds losses where the model is better at the decision.
The primrose path
My answer ended on one sentence, and I would keep it if I kept nothing else:
Full automation is the primrose path to automated error propagation.
Full automation does not, on my argument, make more errors per decision than a person. What it does is remove, or leave unused, the point at which an error stops. A person who makes a mistake makes it once, on one record, at human speed, and if the process makes someone look, there is a point where it can be noticed and stopped. Once published through a hub, a person's error fans out to the subscribers just the same; the difference is scale and detection. An automated process with a wrong rule makes the same mistake on every record the rule touches, at machine speed, and in a master data hub it then publishes the mistake to every system that subscribes to the golden record. Propagation is what master data is for (Figure 3). It is also what makes an unchecked error in it expensive.

Where an error stops A note across the top reads: The mechanism, not a forecast and not advice. Not to scale: three boxes stand for every subscribing system.
Upper panel, headed A person makes a mistake. A box reading One record and Made once, at human speed has an arrow to a highlighted box reading A person can notice it and stop it, if the process makes them look and The point full automation removes or leaves unused.
Lower panel, shaded differently and headed Full automation: a wrong rule, and no point where it stops. A box reading Every record the rule touches and The same mistake, at machine speed has an arrow to a box reading The hub publishes the golden record and Propagation is what master data is for, which fans out in three arrows to three boxes, each reading Subscribing system.
The two clearest public cases are not AI, which is the point: the hazard is full automation, and AI only makes it harder to read. In August 2012 a defective function in Knight Capital's automated order router, triggered by a faulty code deployment, "rapidly sent more than 4 million orders into the market when attempting to fill just 212 customer orders" in the first 45 minutes of trading, and the firm lost "more than $460 million" [21]. The SEC's account adds the detail that matters for this piece: an internal system "generated 97 automated emails" that "identified an error before the markets opened", and Knight did not act on them [21]. The warning existed, though not as an alert anyone had to act on.
The second is closer to master data, because it was data matching. Australia's Robodebt scheme matched welfare recipients' declared income against tax office records. Before it, mismatches had been "a trigger for a manual review" of the files most likely to be overpayments, "about 20,000 such files a year", in which "a DHS compliance officer" checked the file and contacted the recipient [22]. Under the scheme, averaged annual income "was now applied automatically where alternative information was not provided and accepted", and recipients faced a debt and, prospectively, a penalty "automatically raised against them" unless they could disprove it [22]. The Royal Commission called it "a crude and cruel mechanism, neither fair nor legal", and described "the lengths to which public servants were prepared to go to oblige ministers on a quest for savings" [22]. Its recommendations on automated decision-making ask for "a clear path for those affected by decisions to seek review" and for "business rules and algorithms" to be "made available, to enable independent expert scrutiny" [22]. That is enforcement and exception handling, automated together, to save money, with the exception path removed. It is the shape of my prediction with the brakes taken off.
Neither case is a forecast that AI in master data will end that way. They show the mechanism. A rule engine's error is at least legible: someone can read the rule and find the averaging. A model's error is probabilistic, varies by record, and may come with a plausible explanation attached; the Kalai paper argues that training and evaluation procedures reward guessing over acknowledging uncertainty [14]. If the budget logic moves exception handling to a model before the gap with a domain steward has closed, the errors will be fewer than the steward's on routine cases and worse on the hard ones, and the hard ones are the ones that propagate furthest, because nobody downstream knows to question them.
What I expect, and what I advise
The two lists below are deliberately separate, and they carry only what Figure 4 does not. The first is where I think the field is going whether anyone takes my advice or not. The second is what I advise, and it is the same advice I gave before I was asked to forecast.

Three jobs: where I expect them to go, and what I advise A note across the top reads: A forecast and a recommendation, kept apart. No dates, shares or rates are shown.
Left column, one box per job. Policy enforcement, reading Today: Rule engines already do it; Routing, reading Today: Allocation patterns already do it; Exception handling, reading Today: Steward with domain knowledge. An arrow runs from each job box into the middle panel.
Middle panel, headed Forecast: where I expect it to go and Driven by budget more than bandwidth. Against policy enforcement: Goes to models first, mostly as a wrapper around the rules; good enough, because the rules are simple. Against routing: Follows enforcement; small gains from reading the content of the work item. Against exception handling: Handed over last and in pieces, each when good enough to pass a budget review.
Right panel, shaded differently and headed Advice: what I recommend, unchanged by the forecast and The model proposes; the person leads. Against policy enforcement: Keep rules as rules: same answer twice, readable; the model may not silently overrule them. Against routing: Route by named rules; enforced gates, never advisory ones. Against exception handling, highlighted: Model proposes with its evidence; the steward decides; keep the steward in practice. No arrow enters the right panel.
What I expect over the five years I was asked about, besides the order of handover in the figure.
- Organisations that push too far will pull back, as Klarna did, and as Gartner expects half of the service organisations that planned deep cuts to abandon those plans [5] [6]. The pull-back will not return the work to people. It will put people back beside the model.
- The steward's job narrows to the residue, and the residue is harder each year, which is Bainbridge's irony arriving in master data [16].
What I advise, now and then.
- Keep a model out of the default flow of the pipeline, measure what it costs per record, and decide on purpose where it is worth that, as Putty, Not Body Panels argued. Prediction is not permission.
- Where a class of decisions has been measured, on your own records, as better left to the rule or the model, let it run and spend the steward elsewhere [20].
- Make the gates enforced, not advisory. A check the system can skip is a suggestion; I have argued that one before, and the 97 automated emails Knight did not act on, which the SEC says were not designed as alerts, show how little a signal nobody has to act on is worth [21].
- Keep a path for the exception to reach a person, and keep that person in practice. Rotate stewards through the cases the model handles, sample the model's autonomous decisions, and treat a quiet queue as a reason to look, not to cut.
None of that stops the forecast. It decides whether the forecast arrives as a set of cheaper decisions with someone still in the lead, or as the primrose path.
What a practitioner should do now
The question I was asked had a last part, which I did not answer the first time: what should a practitioner learn now that will still matter once AI has taken over enforcement, routing and most exceptions? When I came back to it, my answer was not a skill:
Provide Value to the Business. Solve, or at least Identify, Problems. If you can't look at what the Business is doing and what your Role is within the Business can do better, you're eminently replaceable. That's fine if you're fine with it, but it's not a recipe for job security or the ability to switch jobs when you need to.
That is less comforting than a reading list. If the forecast holds, the parts of master data work that can be written as a rule or a routing table are the parts a budget review will hand to a model, and a practitioner whose value is executing them is in the position Klarna's support agents were in during 2024. The customer-support study points the same way: the model lifts the novice and low-skilled worker, not the experienced one [15].
So the skill is the one the model is worst at and the residual exception queue needs most: knowing what the business is trying to do, seeing where the data stops serving it, and saying so before anyone asks. Hawker made a related point at the same summit, closing on "the need for data professionals to become business consultants" [18]; I would put it more bluntly. A practitioner who can identify a problem, explain what it costs and propose what to do about it is the person the lead stays with, because that is the work the forecast does not reach. A practitioner who cannot is doing work that will be good enough by machine in time, and I do not think it is honest to tell them otherwise.
That is also the answer to whether the forecast should frighten anyone. It is not a recipe for job security, and I did not offer it as one. Stewardship has been handed from one group to another for as long as I have done this work, usually to whoever felt the pain of the errors, and the current attempt is to hand it to a model. The attempt will partly succeed. What decides whether it propagates errors or catches them is whether someone who understands the business is still leading it, and that person has to be worth keeping on the budget line the model was bought to cut.
Correction, 28 October 2026: An earlier version of this article misattributed to Jordan Morrow the framing that the human should be in the lead "as AI enters its next phase". Those words were mine, not his, and the earlier version summarised my account of his keynote rather than quoting it. This version quotes the recording [17]. It also read Kayali and colleagues' study [13] as showing people supplying the enterprise context the model lacked; in the study the system works that context out itself, and the passage now says so.
References
[1] Gartner, "Gartner Predicts Agentic AI Will Autonomously Resolve 80% of Common Customer Service Issues Without Human Intervention by 2029," press release, Stamford, 5 March 2025. Read in full 2026-10-18. Analyst forecast, cited as the firm's prediction. https://www.gartner.com/en/newsroom/press-releases/2025-03-05-gartner-predicts-agentic-ai-will-autonomously-resolve-80-percent-of-common-customer-service-issues-without-human-intervention-by-20290
[2] Gartner, "Gartner Announces the Top Data & Analytics Predictions," press release, Sydney, 17 June 2025. Read in full 2026-10-18. Analyst forecast, cited as the firm's prediction. https://www.gartner.com/en/newsroom/press-releases/2025-06-17-gartner-announces-top-data-and-analytics-predictions
[3] Gartner, "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027," press release, 25 June 2025. Read in full 2026-10-18. Analyst forecast and webinar poll, cited as the firm's. https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027
[4] Klarna, "Klarna AI assistant handles two-thirds of customer service chats in its first month," press release, New York, 27 February 2024. Read in full 2026-10-18. The figures are the company's own claims. https://www.klarna.com/international/press/klarna-ai-assistant-handles-two-thirds-of-customer-service-chats-in-its-first-month/
[5] Rhys Fisher, "Klarna Grapples with AI-Led Customer Service, Pivots to an “Uber Type of Setup”," CX Today, 12 May 2025. Read in full 2026-10-18. Trade reporting of an interview the chief executive gave Bloomberg; the Bloomberg original is paywalled and was not read. https://cxtoday.com/klarna-grapples-with-ai-led-customer-service-pivots-to-an-uber-type-of-setup
[6] Gartner, "Gartner Predicts 50% of Organizations Will Abandon Plans to Reduce Customer Service Workforce Due to AI," press release, 10 June 2025. Read in full 2026-10-18. Analyst forecast and a poll of 163 leaders, cited as the firm's. https://www.gartner.com/en/newsroom/press-releases/2025-06-10-gartner-predicts-50-percent-of-organizations-will-abandon-plans-to-reduce-customer-service-workforce-due-to-ai
[7] Forrester, "Forrester’s 2026 Technology & Security Predictions: As AI’s Hype Fades, Enterprises Will Defer 25% Of Planned AI Spend To 2027," press release, Cambridge, Mass., 28 October 2025. The press release read 2026-10-18; the underlying reports are subscription-only and were not read. https://www.forrester.com/press-newsroom/forrester-tech-security-2026-predictions/
[8] Open Policy Agent, "Open Policy Agent (OPA)," documentation introduction, openpolicyagent.org (documentation version 1.21.2). Read 2026-10-18 (the introduction page). https://www.openpolicyagent.org/docs
[9] Nick Russell, Arthur H. M. ter Hofstede, David Edmond and Wil M. P. van der Aalst, "Workflow Resource Patterns," BETA Working Paper 127, Technische Universiteit Eindhoven, 2004. Read 2026-10-18 in a copy hosted on van der Aalst's site, for the pattern definitions quoted in the body; not every pattern was read. https://www.vdaalst.com/publications/p250.pdf
[10] Profisee, "Aisey: The AI Assistant Redefining Enterprise MDM," profisee.com. Read in full 2026-10-18 (the page has changed since earlier in October). Vendor page (the vendor we partner with). Cited for the phrases quoted in the body; the page does not describe what an agent does when a rule and the model disagree. https://profisee.com/platform/ai-assistant-aisey/
[11] Avanika Narayan, Ines Chami, Laurel Orr, Simran Arora and Christopher Ré, "Can Foundation Models Wrangle Your Data?," arXiv:2205.09911 (v2, 24 December 2022); published in Proceedings of the VLDB Endowment 16(4), 2022. The abstract read 2026-10-18; the full paper was not read. https://arxiv.org/abs/2205.09911
[12] Ralph Peeters, Aaron Steiner and Christian Bizer, "Entity Matching using Large Language Models," Proceedings of the 28th International Conference on Extending Database Technology (EDBT 2025); arXiv:2310.11244 (v4, 18 October 2024). The abstract read 2026-10-18; the full paper was not read. https://arxiv.org/abs/2310.11244
[13] Moe Kayali, Fabian Wenz, Nesime Tatbul and Çağatay Demiralp, "Mind the Data Gap: Bridging LLMs to Enterprise Data Integration," Conference on Innovative Data Systems Research (CIDR 2025); arXiv:2412.20331, 29 December 2024. The abstract read 2026-10-18; the method sections 4.2–4.4 read 2026-10-28 in the arXiv HTML version (v1); the parity claim is the abstract's, and the method sections report the techniques one at a time. https://arxiv.org/abs/2412.20331
[14] Adam Tauman Kalai, Ofir Nachum, Santosh S. Vempala and Edwin Zhang, "Why Language Models Hallucinate," arXiv:2509.04664, 4 September 2025. The abstract read 2026-10-18; the full paper was not read. https://arxiv.org/abs/2509.04664
[15] Erik Brynjolfsson, Danielle Li and Lindsey R. Raymond, "Generative AI at Work," NBER Working Paper 31161, April 2023, revised November 2023; published in The Quarterly Journal of Economics 140(2), 2025, pp. 889–942 (whose abstract gives 5,172 agents). The NBER abstract read 2026-10-18; the full paper was not read. https://www.nber.org/papers/w31161
[16] Lisanne Bainbridge, "Ironies of Automation," Automatica 19(6), 1983, pp. 775–779. Read in full 2026-10-18 in a hosted copy. https://ckrybus.com/static/papers/Bainbridge_1983_Automatica.pdf
[17] Jordan Morrow, "Being Human in the Age of Data and AI," keynote at Profisee's 2026 Data Hero Summit, 8 October 2026, 12:05–12:35 PM CDT. Recording on the event's Goldcast stage (registration required); the quoted words are at about 11:52–12:04 of the recording, and the slide "Human-in-the-Lead, Not Human-on-the-Sidelines" is on screen by about 12:09, when he reads its box aloud. Spoken words taken from the recording's machine caption track, read in full, with punctuation and capitals added; slide text read off the recording. Viewed 2026-10-28. https://events.goldcast.io/e/c3cee985-10b6-4340-b8d7-1589201398d3/stage/agenda
[18] Malcolm Hawker, "The Data Hero Summit 2026 – That's a Wrap!," Profisee blog, 9 October 2026. Read in full 2026-10-18. Vendor blog (the vendor we partner with). https://profisee.com/blog/the-data-hero-summit-2026-thats-a-wrap/
[19] Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 14, "Human Oversight," as reproduced in the AI Act Explorer with its note on dates of application. Article 14 read in full 2026-10-18; the rest of the Regulation was not read. https://artificialintelligenceact.eu/article/14/
[20] Michelle Vaccaro, Abdullah Almaatouq and Thomas Malone, "When combinations of humans and AI are useful: A systematic review and meta-analysis," Nature Human Behaviour 8, 2024, pp. 2293–2303. The abstract read 2026-10-18 on the publisher's page; the full paper was not read. https://www.nature.com/articles/s41562-024-02024-1
[21] U.S. Securities and Exchange Commission, "SEC Charges Knight Capital With Violations of Market Access Rule," press release 2013-222, 16 October 2013. Read in full 2026-10-18; the order it summarises was not read. Knight Capital settled without admitting or denying the findings. https://www.sec.gov/newsroom/press-releases/2013-222
[22] Royal Commission into the Robodebt Scheme (Commissioner Catherine Holmes AC SC), Report, 7 July 2023 (updated 11 July 2023), Volume 1, and the list of 57 recommendations on the report page. The preface, the report summary (Volume 1, PDF pages 1–60 of 364) and the recommendations read 2026-10-18; the rest of the three volumes was not read. https://robodebt.royalcommission.gov.au/publications/report