> ## Content Index
> Fetch the complete content index at: https://wi.senterprises.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Heads Up: The Data Steward's Job After the Routine Work Goes
- URL: https://wi.senterprises.com/articles/ai-mdm-heads-up/
- Published: 2026-10-28T08:00:00.000Z
- Updated: 2026-11-06T03:11:36.000Z
- Description: When the master data system first automates a steward's routine work, the tricky residue takes over the week and time opens up for problems nobody could chase before. AI should repeat that pattern. What it means for skills, for headcount, and for the experience it frees.
- Author: Jeffrey Shabel
- Tags: MDM + AI, AI for Data Governance & Stewardship, 2026, October 2026, 2026-W44, AI: Central, #wi-art_01KVZKVTFN6Q44VRGST7ZV9AMR

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

Where AI reached stewards, the introducing was done by other early adopters, not by me, and their habit was to present it as a cure for everything, a framing I rejected (the argument of [*Another Set of Eyes*](https://wi.senterprises.com/articles/ai-mdm-another-set-of-eyes/)). So when I was asked whether I had watched AI take a steward team's routine work and what their week became, I answered from something narrower that I have seen, what happens to stewards when the master data system itself first starts automating their work:

> Not first hand. That said, I can infer from what I’ve seen when Stewards start having MDM systems provide ‘automation’ for the first time because AI is going to establish the same pattern: routine work becomes automated, one-offs and ‘tricky’ choices predominate and lots of time is freed to chase rabbits that wouldn’t have been worth the time before.

That is an inference, and I want it read as one. The first half is what I have seen. The second half, that AI will set up the same pattern, is what I expect. The rest of this piece tests that inference against what the research and the vendors say, and then follows it out to what it means for a steward's skills, for how many stewards an organisation keeps, and for the business that employs them.

A word on terms. A data steward, here, is whoever decides what happens to master data records when the rules cannot: who approves a proposed match, corrects a value, chases an error back to where it came from. In many organisations that is part of someone's job rather than the whole of it, and that distinction will matter later. Routine work is the part of stewarding that repeats: confirming obvious matches, fixing values that break a written rule in a known way, assigning items, chasing the ones that sit too long. Everything else is the residue: the record the rules flag and cannot fix, the match nobody can call without knowing the business, the value that passes every check and is still wrong.

## What the first automation did

The clearest case I can describe of stewards working beside an automated system is a rebuild of one organisation's stewardship, told in full in [*The Queue Nobody Worked*](https://wi.senterprises.com/articles/profisee-the-queue-nobody-worked/). Before it, the work lived in one long-serving employee's spreadsheets and a home-built database application, and when he retired the queue simply went unworked. I tied the processes to job responsibilities instead of to people: a daily emailed digest of what needed doing, dashboards of what was backing up, tracking with times to live, service levels, and escalation that followed positions rather than names. Asked afterwards whether anything had actually moved, I said it had, and described what the stewards' days became:

> Once the system was operating, data issues were rapidly identified by the automated system and the Stewards were focused on resolving those that couldn't be addressed by the automation.

Two things in that sentence matter here. Detection moved to the machine; the stewards did not inherit the machine's work, they inherited what it left over. And because those stewards could reach the source systems as well as the hub, most of what they fixed, they fixed at the source, which cleared the item from the reports without any change in the master data system at all. Once the backlog was gone, upwards of nine in ten items were resolved before their service-level deadline. Matching records across systems and removing duplicates stayed in the hub, as it should.

That is the pattern in its three parts. The routine work goes to the machine. The one-off and tricky items, which were always there, become most of the week. And time opens up, time to chase what I called rabbits: problems that were never worth a steward's afternoon while the queue was full. The first two parts are almost a definition. Lisanne Bainbridge put the second one memorably in 1983, writing about industrial control rooms: automation leaves "the operator to do the tasks which the designer cannot think how to automate" [\[1\]](#ref-1). The residue is not a side effect of automation. It is what automation is designed to leave behind, and it is the hard part by construction. Bainbridge drew the uncomfortable conclusion too: "the more advanced a control system is, so the more crucial may be the contribution of the human operator" [\[1\]](#ref-1). The rest of this piece is about the third.

![A steward’s week in three stages: before automation, after rule-based automation (seen), after AI (expected). Routine work moves to the machine, the tricky residue becomes most of the week, and freed time goes to structural issues or is cut.](https://wi.senterprises.com/assets/diagrams/FIG015_MAI_The_Stewards_Week_v1_0.png)

Figure 1: The pattern in three stages. The first two columns are what the practitioner has seen when a master data system first automates stewardship; the third is what he expects AI to repeat, not something he has observed. 

**The steward’s week: what the first automation did, and what AI is expected to repeat** Beneath the title a key reads: How to read this: (seen) — the practitioner’s own experience; (expected) — his forecast, not something he has observed; (this publication’s reading) — the article’s own analysis. No counts or shares are shown.

Three column headings, left to right: **Before automation (seen)**; **After the first automation, by rules (seen)**; **After AI (expected)**. Three rows, each labelled on the left.

Row **Routine work**, left to right: **Most of the week**: Confirming obvious matches, fixing rule breaks with a known fix, assigning and chasing items. **Taken by the machine**: The system detects the issues and handles what it can (seen). **Taken further, by a model**: A model reaches into cases nobody could write down as a rule (expected).

Row **The tricky residue**, left to right: **Squeezed in**: One-off records and choices nobody can call without knowing the business. **Most of the week**: What the automation could not address; much of it fixed at the source system (seen). **Stranger, and smaller only if review is chosen well**: Plus reviewing what the model proposes, and knowing when not to believe it (this publication’s reading).

Row **Freed time**, left to right: **None**: Problems upstream are not worth a steward’s afternoon while the queue is full. **Rabbits**: Time freed for problems that were never worth it before (seen). **Structural issues and the business**: Or claimed back as a cut in headcount; the budget decides (expected). (The last box in this row is outlined in amber.)

Across the foot, a box headed **Skills (expected)**: From spotting basic match patterns quickly to research and analytics: rote to bespoke.

One caution before going further, because the pattern only holds when the automation is honest. It is easy to make a matching engine look automated by setting its auto-approve threshold foolishly low. That does not free a steward; it moves the work later and makes it worse, because the steward ends up remapping false matches that the business has already made decisions on and reported from. A steward's week after that kind of automation is not the week I am describing. The pattern needs an automation that does the routine work correctly and hands over the rest.

## Why I expect AI to repeat it

The first automation in master data was rules: exact codes, formats and ranges, deterministic match rules, routing tables. That is exactly the kind of work David Autor describes in his account of why automation has not ended work. Computers substitute for people "in performing routine, codifiable tasks", and "Automation does indeed substitute for labor—as it is typically intended to do" [\[2\]](#ref-2). But, he argues, "automation also complements labor" [\[2\]](#ref-2): it raises the value of the problem-solving and judgement around the automated task. The first automation in a stewardship team does both. It takes the codifiable work and raises the value of the steward's judgement on what is left.

AI moves the line between the two. Some of what a steward used to handle as tricky, a model can now handle as routine. In entity matching, Ralph Peeters, Aaron Steiner and Christian Bizer report 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 LLM-based matchers "exhibit higher robustness to unseen entities" [\[3\]](#ref-3). A rule engine's routine is the set of cases somebody could write down. A model's routine reaches some way into the cases nobody wrote down. That is why I expect the same pattern again, shifted: the residue left to the steward gets stranger. Whether it also gets smaller depends on how the review is chosen, and that is the condition on which the freed time depends. This publication has found no independent measurement, in a steward's week, of whether reviewing a model's proposals costs less than the routine work it replaces; until there is one, the freed time after AI is my expectation, not a finding.

It is also where the analogy is weakest, and it is worth being exact about how. A rule fails loudly. A record passes the rule or it does not, and a steward can see the line. A model fails plausibly, and its line is not straight. Fabrizio Dell'Acqua and colleagues called this the "jagged technology frontier": in their field experiment with 758 knowledge workers at Boston Consulting Group, people using AI on tasks inside the frontier finished "12.2% more tasks" and finished them "25.1% more quickly on average", while on a task chosen to sit outside it, "subjects using AI were 19% less likely to produce correct solutions compared with those without AI" [\[4\]](#ref-4). Tasks on either side of that line looked about equally hard. For a steward, that means the model's routine and the model's mistakes arrive in the same queue looking alike. So the residue after AI includes a job the residue after rules did not: reviewing what the model proposes, and knowing when not to believe it.

I have argued before what that review should look like: the model's output and the context it used should be quick for a steward to check and approve, so the steward spends a limited budget of decisions on the records that matter rather than on every element (the argument of [*Another Set of Eyes*](https://wi.senterprises.com/articles/ai-mdm-another-set-of-eyes/)). The research on people and models deciding together supports the shape of that and warns about the size of it. Michelle Vaccaro, Abdullah Almaatouq and Thomas Malone pooled 106 experiments and found that "on average, human–AI combinations performed significantly worse than the best of humans or AI alone", with "performance losses in tasks that involved making decisions"; but "when humans outperformed AI alone, we found performance gains in the combination" [\[5\]](#ref-5). The meta-analysis compares tasks, not records, so this is an analogy: the combination did better where people outperformed the model, and for a steward that is the tricky residue. It does not make the routine safe to leave alone; on the jagged frontier, the model's mistakes look like its routine work.

How the review is chosen is where that condition is met or missed. The approach this publication takes, and which I agree with, is to ask the model for a confidence signal, set a threshold, and send the low-confidence tail to the steward first, with the output and the context it used beside it to approve. Confidence orders the queue; it is not a verdict, because models stating their own confidence "tend to be overconfident", and every method Miao Xiong and colleagues tested struggled "in challenging tasks, such as those requiring professional knowledge" [\[15\]](#ref-15). So the proposals above the threshold are still checked on a sample, because an overconfident model puts some of its mistakes there, and comparing that sample with what the stewards find is what keeps the threshold honest.

The vendor we work with is selling this change, 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 its Aisey assistant describes agents that "monitor your environment, detect conditions, and act automatically", "replacing repetitive stewardship and admin work with autonomous execution", and it closes the pitch with the line most vendors in the category would write: "Let Aisey handle repetitive data quality enforcement so stewards can focus on the decisions that really matter" [\[6\]](#ref-6). The second sentence is the first two parts of my pattern, and I agree with it. The first is where I part company, for the reason above: on the jagged frontier, autonomous execution means the model's plausible mistakes go out with its correct work, and nobody is in the queue to tell them apart before they land. The page says every change is reviewable, and that matters, but a review after the change is a correction, not a decision. I have not tested either of the vendor's modes at a client, so this is a reading of the page and of the evidence, not a report.

## What the steward's skills become

Asked what skills the steward's week would call for afterwards, I gave a short answer:

> Skills change: Skills will move from rapidly identifying basic match patterns to research and analytics skills. Rote to bespoke.

That is a forecast, and the reasoning behind it is the pattern. Spotting basic match patterns quickly is precisely the routine a rule or a model absorbs; it was the core skill of the rote week because the rote week was mostly matches. What is left needs a different kind of work: tracing an irregularity to the process that produces it, querying across systems to see how far it reaches, putting a number on what it costs. That is research and analytics, and it is bespoke because no two of those problems arrive in the same shape.

The research on people working with generative AI points the same way and adds a warning. Hao-Ping Lee and colleagues at Microsoft Research surveyed 319 knowledge workers and found that generative AI shifts critical thinking "toward information verification" and toward "task stewardship", and also that "higher confidence in GenAI is associated with less critical thinking" [\[7\]](#ref-7). For a steward, verification is the review job above, and the warning is the risk in it: the steward who comes to trust the suggestion stops checking it. The European Union's AI Act writes the same risk into law for high-risk systems, requiring that the people overseeing one are enabled "to remain aware of the possible tendency of automatically relying or over-relying on the output produced by a high-risk AI system (automation bias)" [\[8\]](#ref-8). Most master data pipelines are not high-risk systems under that Act; I cite it for how the law describes the problem, not because it applies.

Bainbridge's other irony is the one I cannot answer from my own record. She wrote that "physical skills deteriorate when they are not used" [\[1\]](#ref-1); the same is plausibly true of the judgement a steward builds, and the rote work was how stewards learned the patterns that later make them good at the bespoke work. If the model takes the rote work, where does the next steward learn? Erik Brynjolfsson, Danielle Li and Lindsey Raymond offer part of an answer from a customer-support floor: an AI assistant raised productivity by 14% on average, "including a 34% improvement for novice and low-skilled workers but with minimal impact on experienced and highly skilled workers", and they suggest "the AI model disseminates the best practices of more able workers" [\[9\]](#ref-9). A model can carry some of an experienced steward's patterns to a new one. But the patterns it carries came from experienced people, so the source still has to exist somewhere. My answers do not say how an organisation should grow its next experienced steward once the rote is gone, and I will not invent a method. It is the open question in this piece.

## Chasing rabbits

What the freed time is for rests on a pattern I have seen repeat, not on a law. Asked about it, I answered:

> Adding and incorporating automation, whatever the source, will significantly alter the work of the Steward and will allow them to focus more on the oddities and, more importantly, on the Business. They can lift their head up from the immediate problems of data irregularities and look at structural issues. This gives the business the opportunity to benefit from potentially decades of in-depth experience that had previously only been used by Stewards to solve their own problems.

Stewardship has mostly been reactive, which is why the freed time is worth so much. As I have seen it, it began with power users fixing errors in their own systems that had started upstream, often because auditors flagged them, and the business has kept handing the fix to the group the error hurts (the history in [*Who Owns the Data, Really?*](https://wi.senterprises.com/articles/mdm-who-owns-the-data-really/)). A steward buried in the queue is the reactive end of that chain. A steward with time, if the review is chosen well enough to leave some, is the first person in a position to stop it.

Asked what a rabbit actually looks like, I named the kind: duplicates that keep coming back, columns that keep being overwritten, figures and rollups that are a little wrong, records filed under the wrong category. Each is minor, and with a proper manual process to correct or revert it, it barely touches the business. But each takes specialised knowledge and specifically ordered procedures, and with data sets of millions of records a steward rarely has time to trace one to its root. The example I gave shows the trade:

> It's much easier to make sure to add an 'S' to the end of 'Suite' as part of the export process than it is to figure out which system and, more importantly, why, keeps overwriting 'Suites' with 'Suite' as part of the Survivorship process. Especially if it's part of secondary transactions that take place outside and after the Mastering system.

The workaround is one change to an export. The cause sits somewhere in survivorship, or in a transaction that runs after the master data system has finished, and finding it means knowing which systems write to that column, in what order, and why. A steward with a full queue usually takes the workaround, and the overwrite keeps coming. Chasing that rabbit means following it upstream to the system and the reason, and fixing the process that makes the error rather than this instance of it (Figure 2). The knowledge that lets a steward do this is exactly the knowledge that does not transfer easily: as I see it, stewards carry specialised domain knowledge that is hard to document and hard to hand to a model.

![A chain from top to bottom: a recurring irregularity reaches the queue, the steward traces it upstream, a structural finding results, an owner acts, and fewer irregularities arrive. With no owner, the finding goes nowhere.](https://wi.senterprises.com/assets/diagrams/FIG016_MAI_Where_The_Freed_Experience_Goes_v1_0.png)

Figure 2: The freed time pays only when a structural finding reaches someone who can change the process. With no owner, the chase ends in a report nobody acts on. 

**Where the freed experience goes: a structural finding only pays if someone owns it** Beneath the title a key reads: How to read this: (expected) — the practitioner’s forecast, not something he has observed; (his view) — his stated view, not a reported event; (this publication’s reading) — the article’s own analysis.

Five boxes stacked from top to bottom, each with an arrow pointing down to the next: **The same irregularity reaches the queue again**: A recurring one, not a one-off (this publication’s reading). **The steward traces it upstream**: Research and analytics across systems, with time that used to go to the routine (expected). **A structural finding**: The form, feed or habit that keeps producing the error (this publication’s reading). (This box is outlined in amber.) **An owner with authority acts**: The process is changed where the error starts (this publication’s reading). **Fewer irregularities reach the queue**: The cause is removed, not only this instance (this publication’s reading).

From the third box, a dashed arrow points right to a box headed **No owner**: The finding goes nowhere: a business ignores what it must to keep operating (his view).

That chain has a weak joint, and my own view says where. A finding about a structural problem goes nowhere unless someone with authority acts on it, and if the business has to ignore something to keep operating, it will ignore it, however intelligent the system that raised it. A steward who chases a rabbit to its burrow and reports it to nobody has spent the freed time on a hobby. The organisations that get value from the pattern are the ones that give those findings an owner.

## The number of people

The question I was asked also covered headcount. My answer was a forecast, and a hedged one:

> Headcount: Could conceivably drop significantly. This is why it's so important to demonstrate value and think beyond the immediate problems--no matter your role in the Enterprise. 'Steward' might reasonably become just one aspect of another position instead of a position unto itself.

The word "conceivably" is my hedge; I will not attach a number to it. Two things in the answer need separating. One is the drop: if routine work is automated, whatever the source, fewer hours of stewarding are needed. The other is the title: stewardship may stop being a job and become part of one. That second part is already true in many organisations, where stewarding is part of someone's job rather than the whole of it, and where adoption suffers for exactly that reason. My forecast is that the pattern pushes more organisations that way.

This is not the claim that a model will replace the stewards. I have argued that the claim that AI will replace both matching strategies and stewards holds only for an organisation with an unlimited budget, because a model in every record's path is a variable cost and a dependency that is expensive to remove ([*Reinforce Is the Wrong Word*](https://wi.senterprises.com/articles/mdm-ai-roadmaps-reinforce-is-the-wrong-word/)). Nothing here concedes that. The drop I expect comes from the routine shrinking and the role folding into other roles, not from a token-priced model doing a steward's whole job.

The public evidence cuts in both directions, and it is worth reading carefully. The best-known older case is the bank teller. James Bessen found that "the number of bank teller jobs did not decrease as the ATMs were rolled out", although "the number of tellers required to operate a branch office in the average urban market fell from 20 to 13". The job changed: "cash handling became less important and human interaction more important" [\[10\]](#ref-10). Fewer people per unit of work, a different job, and not a smaller workforce: that is one way my forecast could come out. The best-known recent case goes the other way first. Klarna announced in 2024 that its AI assistant was "doing the equivalent work of 700 full-time agents" [\[11\]](#ref-11); by May 2025 its chief executive was reported saying that "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 [\[12\]](#ref-12). Gartner, polling 163 customer-service leaders, found "95% of customer service leaders plan to retain human agents to strategically define AI's role", and predicted that half of the organisations that expected to cut their service workforce significantly would abandon those plans by 2027 [\[13\]](#ref-13).

Those are not master data cases, and none of them refutes a significant drop; they refute a total one, which I did not forecast. What they do show is the pressure that decides which way it goes. I have said the pressure to automate data governance is driven by bandwidth and, more, by budget (the argument of [*The Primrose Path*](https://wi.senterprises.com/articles/ai-mdm-the-primrose-path/)). Freed steward hours are an obvious line for a finance office to take. My advice to a steward does not change with the forecast, and it is advice I have given before ([*The Primrose Path*](https://wi.senterprises.com/articles/ai-mdm-the-primrose-path/)): show the value you add, and think past the problem in front of you, whatever your title. A steward whose week is the tricky residue plus the rabbits is easy to justify. A steward whose week is the routine work that a machine now does is not.

## What the pitch leaves out

The last part of the question was what the sales pitch does not predict. I answered:

> Sales Pitch Misses: AI isn't a panacea. At least, not yet. There's still room for 'human in the lead,' especially at the strategic or 30,000 foot level.

"Not yet" is doing real work there. It is not a claim that AI cannot do strategic work; I have predicted that AI will take over policy enforcement, routing and exception handling somewhere, often doing a good-enough job that earns it more (the argument of [*The Primrose Path*](https://wi.senterprises.com/articles/ai-mdm-the-primrose-path/)). It is a claim about now, and about where the human role is most secure. Even Gartner, which forecasts that "50% of business decisions will be augmented or automated by AI agents for decision intelligence" by 2027, says through its analyst Carlie Idoine that such agents "aren't a panacea, nor are they infallible", and that "Human decisions still require proper knowledge, as well as data and AI literacy" [\[14\]](#ref-14). At the recent 2026 Profisee Data Hero Summit, I heard Jordan Morrow argue for putting the human in the lead ahead of keeping the human in the loop; that is my account of what I heard, not a quotation. The pitch tends to describe the steward's future as the same job with less tedium. The pattern I have seen says the job moves: away from the queue and toward the level where someone decides how the business should run.

## The most valuable thing

I finished my answer with what I think the whole change is for:

> Freeing that experience to contribute to strategic direction and structural analysis of the way the Business runs is, to my mind, the most valuable thing automated Mastering Strategies or AI can provide to the Enterprise.

That is the claim I would defend against everything above. Not that stewards will have easier weeks, and not that organisations will save on stewarding, though both may happen. The valuable thing is that people who have spent years seeing exactly how the business breaks its own data stop spending that knowledge only on cleaning up after it. They start spending it on why it keeps happening.

Kept apart from that expectation, here is what I would advise anyone running a stewardship team while the change arrives:

1. **Automate honestly.** Thresholds that look automated and push false matches downstream make the steward's week worse, not better.
2. **Keep the steward deciding on the residue.** Let the model propose and show its context; let the steward approve. That is where the combination of person and model is most likely to beat either alone.
3. **Measure where the freed hours go.** If nobody records it, the hours will be taken back as a cost saving, and the experience with them.
4. **Give structural findings an owner.** A rabbit chased to its burrow and reported to nobody is wasted time.
5. **Decide how the next steward learns.** If the rote work goes to a model, so does the apprenticeship; plan for that before the experienced people leave.

The routine will go, whatever does the automating. What it leaves behind is the part of the work that only the people who know the business can do, and the time for them to do it. Whether that time is spent on structural problems or simply cut is a choice someone in the organisation will make, deliberately or by default.

## References

\[1\] 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%5F1983%5FAutomatica.pdf>

\[2\] David H. Autor, "Why Are There Still So Many Jobs? The History and Future of Workplace Automation," Journal of Economic Perspectives 29(3), 2015, pp. 3–30\. The abstract read 2026-10-27; the full paper was not read. <https://www.aeaweb.org/articles?id=10.1257/jep.29.3.3>

\[3\] 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>

\[4\] Fabrizio Dell'Acqua, Edward McFowland III, Ethan Mollick, Hila Lifshitz-Assaf, Katherine C. Kellogg, Saran Rajendran, Lisa Krayer, François Candelon and Karim R. Lakhani, "Navigating the Jagged Technological Frontier: Field Experimental Evidence of the Effects of AI on Knowledge Worker Productivity and Quality," Harvard Business School Working Paper 24-013, September 2023\. The abstract read 2026-10-27; the full paper was not read. <https://www.hbs.edu/faculty/Pages/item.aspx?num=64700>

\[5\] 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 article page and abstract read 2026-10-27 (open access). <https://www.nature.com/articles/s41562-024-02024-1>

\[6\] Profisee, "Aisey: The AI Assistant Redefining Enterprise MDM," profisee.com. Read 2026-10-27 (the passages on agents and stewards; earlier reads 2026-10-12 and 2026-10-18). Vendor page (the vendor we partner with). <https://profisee.com/platform/ai-assistant-aisey/>

\[7\] Hao-Ping (Hank) Lee, Advait Sarkar, Lev Tankelevitch, Ian Drosos, Sean Rintel, Richard Banks and Nicholas Wilson, "The Impact of Generative AI on Critical Thinking: Self-Reported Reductions in Cognitive Effort and Confidence Effects From a Survey of Knowledge Workers," Proceedings of the 2025 CHI Conference on Human Factors in Computing Systems, Article 1121\. The abstract read 2026-10-27 on the Microsoft Research page; the full paper was not read. <https://www.microsoft.com/en-us/research/publication/the-impact-of-generative-ai-on-critical-thinking-self-reported-reductions-in-cognitive-effort-and-confidence-effects-from-a-survey-of-knowledge-workers/>

\[8\] Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 14, "Human Oversight," as reproduced in the AI Act Explorer. Article 14 read in full 2026-10-18; the rest of the Regulation was not read. <https://artificialintelligenceact.eu/article/14/>

\[9\] 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\. The NBER abstract read 2026-10-18; the full paper was not read. <https://www.nber.org/papers/w31161>

\[10\] James Bessen, "Toil and Technology," Finance & Development 52(1), International Monetary Fund, March 2015\. Read 2026-10-27\. <https://www.imf.org/external/pubs/ft/fandd/2015/03/bessen.htm>

\[11\] Klarna, "Klarna AI assistant handles two-thirds of customer service chats in its first month," press release, 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/>

\[12\] 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>

\[13\] 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>

\[14\] 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>

\[15\] Miao Xiong, Zhiyuan Hu, Xinyang Lu, Yifei Li, Jie Fu, Junxian He and Bryan Hooi, "Can LLMs Express Their Uncertainty? An Empirical Evaluation of Confidence Elicitation in LLMs," International Conference on Learning Representations (ICLR 2024); arXiv:2306.13063 (v2, 17 March 2024). The abstract read 2026-10-27; the full paper was not read. <https://arxiv.org/abs/2306.13063>