> ## 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. # Same Work, New Tools: What the Rules Engines Already Taught Stewardship About AI - URL: https://wi.senterprises.com/articles/ai-mdm-same-work-new-tools/ - Published: 2026-11-04T09:00:00.000Z - Updated: 2026-11-06T03:11:40.000Z - Description: Rules engines, rule-proposing profilers, auto-approve thresholds, automatic classification and routing were the smart governance of the pre-AI era. They mostly kept their promise. What struggled was adoption, the steward's loop never changed, and today's AI pitch repeats the list. - Author: Jeffrey Shabel - Tags: MDM + AI, AI for Data Governance & Stewardship, 2026, November 2026, 2026-W45, AI: Central, #wi-art_01KVZKVTFNSB6ASG9K26MNJACK *Weaving Intelligence (House AI Style), with Jeff Shabel’s Experiential Commentary* I was asked to look back at the "smart" automation sold for governance and stewardship work before language models arrived, and to pick the one I had actually seen used: a rules engine for data quality, profiling that proposes the rules, auto-approve thresholds, automatic classification or tagging, automatic routing of stewardship tasks. The question assumed I would have to choose. I did not: > All of the above were sold, approved, built and implemented. Most of them by me. Rules engines and metadata-driven dynamic processing were my niche for over a decade. They all promised increased efficiency, effectiveness and lower time to market—almost all of them succeeded in those areas. That answer changes what this piece can be. The usual retrospective on "early AI" in a business function is a story of disappointment: the technology was oversold, the results were thin, and today's tools finally deliver what the old ones promised. I cannot write that story honestly about these five, because on their own terms most of them worked. They made the governed work faster, they made it more consistent, and they got new data products into use sooner. Where they ran into trouble was somewhere else, and the steward at the centre of them kept doing the same job before, during and after. Both of those facts bear directly on how AI is being pitched for stewardship now. ## The rules engine was the AI of its day It is worth remembering where the rules engine came from, because the lineage is the first thing today's pitch repeats. The best-known matching algorithm for rules engines is Charles Forgy's Rete, published in *Artificial Intelligence* in 1982 and developed, in his words, "for use in production system interpreters", the machinery of the expert systems that were that decade's artificial intelligence [\[1\]](#ref-1). When a vendor later put a rules engine under a data-quality product and called it smart, the word was earned honestly. It was the same idea, and sometimes the same algorithm, pointed at records instead of diagnoses. By the turn of the century the governance version of the idea had a manifesto. The Business Rules Group's 2003 statement of principles reads, in places, like a current product page. "Rules should arise from knowledgeable business people," it says, and those people "should have tools available to help them formulate, validate, and manage rules"; a rule system "must always be able to explain the reasoning by which it arrives at conclusions or takes action" [\[2\]](#ref-2). Business ownership of the logic, separation from code, explainable decisions: none of that is new in 2026\. One of its other principles turned out to matter more than its authors could have meant it to. "Rules are not process and not procedure," the Manifesto says, and "should not be contained in either of these" [\[2\]](#ref-2). That is good design. It is also a description of exactly where the friction would land, as the rest of this piece shows: a rule kept apart from the process still has to reach the person whose day the process runs. Profiling that proposes the rules was not a vendor's fantasy either. Erhard Rahm and Hong Hai Do's survey of data cleaning in 2000 already treated profiling, the analysis of what the values in a column actually look like, as a step in its own right, and described cleaning tools whose transformation steps "may request user feedback on data instances for which they have no built-in cleaning logic" [\[3\]](#ref-3). Their conclusion on the tools of the day was blunt: they "cover only part of the problem and still require substantial manual effort or self-programming" [\[3\]](#ref-3). By 2008 the research community had a formal language for data-quality rules that profiling could look for, conditional functional dependencies, with methods for "detecting CFD violations in SQL" and checking them incrementally as data changed [\[4\]](#ref-4); by 2015 a survey in *The VLDB Journal* could review the automatic discovery of dependencies, including conditional ones, alongside profiling "tools and systems from research and industry" [\[5\]](#ref-5). "Self-programming" is the phrase in that list I recognise. Rules engines and metadata-driven processing, where the behaviour of a pipeline is read from a table of rules rather than written into its code, were my niche for more than a decade, and the self-programming was the job. The engine evaluated whatever rules it was handed. Everything that made it usable inside a business had to be built around it. Routing had its own standard even earlier. The Workflow Management Coalition's reference model of 1995 describes a "worklist handler", "a software component which manages the interaction between workflow participants and the workflow enactment service", and treats electronic mail as one way of distributing "work items to individual participants" [\[6\]](#ref-6). Automatic routing of stewardship tasks, in other words, was designed into the industry's vocabulary before most of today's master data platforms existed. Auto-approve thresholds I have written about before, and the earlier piece on [*sixty-seven years of machines on master data*](https://wi.senterprises.com/articles/ai-master-data-every-generation-moved-the-work/) tells their history from the census bureau on; I will not repeat it. My position on them is the one thing worth carrying into this piece: set the cutoff low to make an automation figure look good and you have bought the stewards more work, not less, because they spend it remapping false matches the business has already acted and reported on. A disclosure, before I assess any vendor's product, including which way each interest points. The practice behind this publication is a Profisee partner and 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, so weigh anything favourable I say about the category below my criticism of it. Informatica sells master data management that competes with Profisee's, which gives me a reason to be hard on it; discount my criticism of it accordingly. Microsoft is a vendor Profisee is aligned with, since Profisee markets itself as a native workload in Microsoft's Fabric platform, which gives me a reason to go easy on it; weigh anything favourable I say about Microsoft with that in mind. Collibra sells data governance and cataloguing rather than master data management; the category interest still applies to it. Classification is the instructive one, because it is where the gap between then and now is easiest to see in a single vendor's documentation. Microsoft's current classification service for its office and collaboration suite describes its sensitive information types plainly as "pattern-based classifiers": regular expressions or checksums, supporting keywords near the match, and confidence levels a policy can be set against [\[7\]](#ref-7). When a label is applied automatically inside the applications, "the user decides whether to accept or reject the label" [\[7\]](#ref-7). The older classification feature in its database tooling is humbler still: it "scans your database for columns (based on column names only) containing potentially sensitive data and provides a list of recommended column classifications", which a person then reviews and applies [\[8\]](#ref-8). Neither is a language model; the suite's service offers machine-learning classifiers alongside its pattern-based types [\[7\]](#ref-7), and the database recommender is not even reading the data. Both are the pattern-and-threshold approach that, in the earlier wave, had to be built by hand, now shipped as a setting. ## What they promised, and what they kept The promise of all five was the same three words: efficiency, effectiveness, and a shorter time to market. On my record, almost all of them kept it. I want to be careful about how much weight that sentence can carry. I can give no figure for the gain, and the fair reading of "almost all" is that some did not. Nor can I point to a measurement against a control group, and a system judged only against the manual process it replaced is judged on the comparison most likely to flatter it. The closest thing to an industry figure I found is a survey of master data programmes reported in 2012: large companies called their implementations broadly successful about 54 percent of the time in 2008 and 81 percent by 2012, and the barriers they cited most were internal politics and poor data quality [\[9\]](#ref-9). Those are whole programmes, not the automation inside them, and the 2008 number is a fair warning against reading my "almost all" as true of everyone. But the shape matches my record: where it went wrong, it went wrong in the organisation more often than in the engine. There is a better-documented warning from the same family of technology. When Judith Bachant and John McDermott looked back on four years of R1, the expert system Digital Equipment Corporation used to configure its computer orders and one of the most celebrated rules-based systems of its era, the system was a success by its own standards and still needed constant care. Fewer than one order in a thousand was misconfigured because of a rule problem; the rule base had nonetheless grown from 750 rules in 1979 to about 3,300 by late 1983, under a standing technical group of about eight, and its authors expected that "its development will never be finished" [\[10\]](#ref-10). Three years later a second paper put it at 6,200 rules, "of which approximately 50% change every year" [\[11\]](#ref-11). A rules engine that keeps its promise has not finished costing money. It is the first lesson of the earlier wave I would put in front of anyone buying the current one: the system's logic is the part you buy, and its upkeep is the part you keep. ## Where it got hard If the engines mostly worked, the obvious question is why anyone remembers the era as a struggle. I was asked what went wrong, and my answer did not mention the logic at all: > Where they were challenged was adoption and integration with daily work. Workflow processes were a lot more cumbersome in the past and email/SMS integration was… not as robust toward the early part of this century than it is today. Further, security, compartmentalization and data abstraction was also being developed alongside the processes. The two halves of that answer are different problems, and it helps to take them apart. The first is the distance between the engine and the person. A rule that flags a record has done nothing until a steward sees the flag, and early in this century getting it in front of them was its own project. The 1995 reference model had already drawn e-mail into the design [\[6\]](#ref-6); what the products of the time delivered was another matter. In my experience a notification that arrived reliably, on the device the steward actually carried, when the item needed them, was one more supplemental system to build. The Manifesto's principle that rules sit outside process [\[2\]](#ref-2) is correct, and it is also why each rules engine needed a process built next to it before anyone used its output. The human-factors literature has names for what happens when that link is weak. Raja Parasuraman and Victor Riley called the neglect of a working automation "disuse", "commonly caused by alarms that activate falsely" [\[12\]](#ref-12); John Lee and Katrina See record some operators who "rejected automated controllers in paper mills, undermining the potential benefits of the automation" [\[13\]](#ref-13). A 2018 survey of governance practitioners found that "Just 29.4% considered software to be a major influence on their programs" [\[14\]](#ref-14). An engine can be right and unused. A profiler whose proposals are often noise teaches its stewards to stop reading the proposals, and an alert that arrives somewhere nobody looks is an alert nobody gets. The efficiency measured at go-live can leak away through exactly that gap; the literature describes the mechanism, and my own answer put the challenge in adoption and integration, not in the logic. The second half of my answer is the one that took the most building: > Data masking, data abstraction and data compartmentalization were constant challenges—not the least of which because the tools to provide correct identification of audience and access needed to be built instead of merely configured. It would be easy to overstate this, so here is the strongest case against it. Oracle shipped fine-grained access control in its 8i release, around 1999: "security policy functions attached to the table or view", generating a "dynamic predicate" that filters the rows each user can see [\[15\]](#ref-15). Row-level enforcement inside the database engine existed. But read the same documentation and the work is all there: the developer writes the policy function, and writes the code that establishes who the user is [\[15\]](#ref-15). The engine enforced a decision about audience; somebody still had to build the decision. SQL Server did not get declarative masking or row-level security until its 2016 release, and even then row-level security asks for a hand-written predicate function [\[16\]](#ref-16). So the claim survives in its narrower form, and the narrower form is the one that matters: the platform could enforce access, but identifying the correct audience for a given steward, a given record and a given column, across several systems at once, was code someone wrote. A master data hub sees every domain's records by design. Deciding which steward could see which slice of them was never a checkbox. I have described elsewhere what that era looked like from inside: approval gates and multi-system master data integration built into the warehouse layers before the practice had a name, because it was the best way to meet what the business needed (the history in [*Before It Had a Name*](https://wi.senterprises.com/articles/edg-governance-frameworks-before-the-name/)). The smart governance features were built the same way, and so were the walls around them. ## What the stewards did with it So far the documents have carried the history; from here the evidence is my own record of the stewards inside those systems, which is a pattern I have watched repeat, not a law. The question asked what the stewards ended up doing with the smart systems' output: accepting the proposed rules, working the routed queue, overriding the auto-approvals. They did all of those things, and none of it was new work. Asked what the stewards' work actually was, then and now, I answered: > Data Stewards did pretty much the same jobs then as they do now: review the data, change it in the MDM system and feed the change back to the source system—either directly through that system or indirectly by flagging it for reprocessing in the upstream system. The level of complexity of the process that was implemented was inversely correlated with the amount of work expected by the Steward. The first sentence is the loop: review, change in the master data system, feed the change back. As I read it, every one of the five automations attached to some step of it. The rules engine and the profiler decided what reached review. The threshold decided which changes skipped review entirely. Classification informed who was allowed to review what. Routing decided whose review it was. None of them replaced a step. That fits the history of the role as I have told it before: stewardship began with power users correcting errors that started in somebody else's system, and the fix has been pushed back up the pipe ever since, for lack of knowledge or bandwidth downstream. The third step of the loop, feeding the change back, is that history in one clause. When I rebuilt one organisation's stewardship around an automated detection system, the systems most often changed were the sources, not the hub, because the stewards could reach both (the case in [*The Queue Nobody Worked*](https://wi.senterprises.com/articles/profisee-the-queue-nobody-worked/)). The second sentence of that answer is the one I would ask a buyer to read twice. The more process you implement around the steward, the less work you should expect of them. That is a heuristic from building these systems, not a measured correlation, and I would not put a number on it. But it has a direction, and it is a direction a vendor's demonstration cannot show you. A rules engine with nothing around it hands the steward a list. The same engine with routing, notification, the right audience and a path back to the source hands them a decision. The engine is the same in both cases. The work expected of the person is not. ![The steward’s loop: review, change in the master data system, feed back to the source. Rules and profiling decide what reaches review; classification informs who may review; routing, whose review; the threshold lets changes skip review.](https://wi.senterprises.com/assets/diagrams/FIG017_MAI_Same_Loop_New_Tools_v1_0.png) Figure 1: The steward’s loop, then and now, with each pre-language-model automation drawn where it attaches. None replaced a step; the threshold lets some changes skip review. **Five automations attached to the steward’s loop; none replaced a step of it** Beneath the title a key reads: How to read this: the loop (gold) is the practitioner’s own experience, then and now; each arrow from an automation is this publication’s reading of where it attaches; (seen) — his experience building these systems; (his view) — his stated judgement. No counts or shares are shown. Three boxes outlined in gold form a loop, joined by arrows: **Review the data** (What was flagged, or could not be settled.) leads to **Change it in the master data system** (Correct, match or approve the record.), which leads to **Feed the change back to the source** (Directly in that system, or flagged for reprocessing upstream.), which leads back to review. Two boxes above point into **Review the data**: **Data-quality rules engine and profiling that proposes rules**: Decide what reaches review. And **Automatic classification and automatic routing**: Inform who may review, and decide whose review it is. A box in the middle, **Auto-approve thresholds**: Above the cutoff, a change skips review and goes straight to the record. A dashed arrow runs from it to **Change it in the master data system**. At the foot, two boxes side by side: **Then: built (seen)**: Each automation, and the workflow, notifications, masking and who‑may‑see‑what around it, designed, coded and integrated by hand. **Now: configured (his view)**: The same five jobs, standardized into packaged software as integrated features and set up by configuration. Below them a wide box, **What moves**: How much work reaches the loop: the more process implemented, the less work expected of the steward (his view). Which items reach it, and how hard they are (this publication’s reading). There is a respectable objection to reading that as "more automation, less work", and Lisanne Bainbridge made it in 1983: automation tends to leave the human operator the tasks the designer could not automate, which are the hard ones [\[17\]](#ref-17). The answer, and it is my reading rather than something I watched, is to separate the kind of work from its mix. The kind is the loop, and it has been the same loop for as long as I have known the job; the new layers the earlier retrospective described, such as choosing which pairs a person should look at, sit around the loop rather than replacing a step of it. The mix is how many items reach the loop and how hard each one is, and that is what each automation moves: fewer items, stranger items, and, if the process around the steward is good, a decision instead of a list. My heuristic is a statement about the volume. Bainbridge's is a statement about the difficulty. Both can be true of the same queue. The same distinction covers two things I have argued before: that each generation of matching machine handed a person a new layer of work, and that once the routine goes, the tricky residue becomes most of the week. The first adds work around the loop, the second changes its mix, and neither changes its kind. The research adds one condition I accept: Richard Cook and David Woods found that "clumsy automation" can increase "the workload at peak workload times" [\[18\]](#ref-18). Automation piled on a steward without the process around it can add work, which is why the heuristic is about the process implemented, not the number of engines installed. ## What actually changed If the work did not change, something must have, or there would be nothing to explain about today. What changed, in my own words: > The big things that have changed is the Industry has identified the common problems and developed standardized solutions that are incorporated into today’s software packages. We’ve moved from needing to develop supplemental systems and processes to configuring integrated features instead. The work hasn’t changed, but the tools have. The industry did what it always does with a problem every customer solves the same way: it stopped letting each customer solve it. Workflow, notification, masking, row filtering, classification and routing went from being supplemental systems a team wrote around the engine to being features of the platform, switched on and set. The documents above trace the shape of it. Pattern-based classification is now a setting with confidence levels [\[7\]](#ref-7); masking and row-level security arrived in SQL Server as declared features in 2016 [\[16\]](#ref-16); a classification service recommends and a person accepts [\[8\]](#ref-8). What took a project now takes a configuration screen. The line was not crossed on one date. A profiling product in 2006 already let users "run business rules against any source system" [\[19\]](#ref-19), and the Oracle feature above shipped years earlier; what stayed built, in my experience, was the part that joined them to each other and to the people who had to act. That is a large change, and it is almost entirely a change in what the implementer does. My niche was building what the platform did not have. Most of it the platform now has. For the steward at the far end, the loop is still review, change, feed back. The tools brought the decision to them faster and more reliably, and with a better idea of who was allowed to make it; they did not make a different decision for them. One practitioner's reading of current job descriptions argues the role has changed a great deal: "Modern Data Stewards rarely focus on governance oversight alone," Irina Steenbeek writes, and the role now reaches into metadata, quality practice and AI environments [\[20\]](#ref-20). I do not dispute that the job around the loop has widened; it is what I expect to keep happening as the routine goes. It is a change in what else a steward is asked to do, not in what stewarding is. ## What today's pitch repeats I did not answer the last part of the question I was asked, which pitch claims come back, with a list, and I will not invent one for myself. What I can do is read the current pitch against the record above and say where it lands. The comparison that follows is my reading of vendors' own pages, not something I have tested in a deployment. Read side by side, the pages name the same five automations as the 2000s did. Informatica offers a tool that "automatically discovers and contextually classifies sensitive data", "automated policy management and enforcement", "no-code workflow management", and agents that "proactively fix data quality issues" [\[21\]](#ref-21). Collibra's documentation describes a feature that will "automate SQL rule writing" and a semantic mapper that suggests relations and creates them "when suggestions are accepted" [\[22\]](#ref-22). Microsoft's data quality service offers "AI-generated rules" and "AI-powered data profiling capabilities, recommending columns for profiling while allowing human intervention to refine these recommendations" [\[23\]](#ref-23). Classification, rule enforcement, workflow, profiling that proposes rules, and an automatic fix where the threshold used to be: the list has not changed, and neither has the promise. Informatica's page puts it in the oldest currency there is, "51,870 user hours saved annually", with no basis stated on the page [\[21\]](#ref-21). Two things are new, and they are worth separating. The first is real. A language model can propose a rule nobody wrote down, describe an asset nobody documented and classify a column whose name gives nothing away, which the name-based recommender above cannot do at all [\[8\]](#ref-8) and pattern-based types do only where someone has written the pattern [\[7\]](#ref-7). That moves which items reach the steward and how strange they are, which is the mix I described, and the earlier pieces on [*Heads Up*](https://wi.senterprises.com/articles/ai-mdm-heads-up/) and [*The Primrose Path*](https://wi.senterprises.com/articles/ai-mdm-the-primrose-path/) follow where it goes. I have also argued that policy enforcement and routing never needed AI in the first place, only well-written algorithms and the processes that act on what they report; I wrote a good many of them. The second is a claim about the person, and it is where the record disagrees. "Turn every employee into a data expert," says one page [\[21\]](#ref-21). "Eliminate manual data hunting," says another [\[22\]](#ref-22). Those are promises to change the work, not the tools, and the last wave of smart governance, which mostly kept its promises, did not keep that one. It did not try to. The best evidence that the work survives is in the same pages: Microsoft's lifecycle begins with assigning "data quality steward permissions", configures alerts "to notify data owners and data stewards" when a threshold is missed, and ends in an actions centre that gives the steward diagnostic queries "to zero in on the specific data to fix" [\[23\]](#ref-23). Review, change, feed back. It is the loop, delivered by a better tool. Gartner's own forecast makes the same point from the other side. In the press release that predicts "80% of data and analytics (D&A) governance initiatives will fail" by 2027, the failure is put down to "a lack of a real or manufactured crisis" and to governance that "does not enable prioritized business outcomes"; the same release then promises that generative AI "will accelerate time to value" for governance, naming cataloguing and classification [\[24\]](#ref-24). One of those sentences is about tools and one is about adoption. The failure is in the second; the pitch is aimed at the first. That is the part of the earlier wave the current one is quietest about. Configuration has made the old building work cheap, and that is a genuine gain. It has not made a steward read the queue, put the alert where they will see it, or decided who may see which records. A model that reads every domain to propose its rules raises that last question again, and no vendor page I read for this piece discusses it. ## What I would take from it When AI was first put in front of stewards, the people doing the introducing tended to sell it as a cure for everything, and I reject that (the argument of [*Another Set of Eyes*](https://wi.senterprises.com/articles/ai-mdm-another-set-of-eyes/)): presented to stewards, it should be another set of eyes and a suggestion, taken or left on their judgement. The history in this piece is why. The previous generation of smart governance kept its promise on efficiency, and the steward's loop came through it unchanged. A buyer who expects the new generation to change the loop is buying the one thing the last generation never delivered. So the question I would put to a vendor is not what the model can do. It is where in the loop the model sits, what reaches the steward afterwards, and what had to be built around the old engine that this demonstration quietly assumes is already there: the notification that lands where the steward looks, the path back to the source system, and the rule for who may see what. My heuristic says the answer decides how much work you should expect of your stewards, more than the model does. Last time, those were the parts that had to be built by hand. This time they are configurable, which makes them cheaper. It does not make them optional. The rules engines did not fail. They worked, and they left behind a loop that a person still runs, and a lesson about where the hard part was. The tools have changed again. Before deciding what the new ones will do to the work, it is worth checking what the old ones did, and the answer, on my record, is that they changed everything around the steward and left the job itself where it was. ## References \[1\] Charles L. Forgy, "Rete: A fast algorithm for the many pattern/many object pattern match problem," Artificial Intelligence 19(1), 1982, pp. 17–37\. The abstract read 2026-11-01; the full paper was not read. \[2\] Business Rules Group (Ronald G. Ross, ed.), "The Business Rules Manifesto: The Principles of Rule Independence," version 2.0, November 2003\. Read 2026-11-01\. \[3\] Erhard Rahm and Hong Hai Do, "Data Cleaning: Problems and Current Approaches," IEEE Data Engineering Bulletin 23(4), December 2000, pp. 3–13\. Read 2026-11-01 in a partial extract covering the paper. \[4\] Wenfei Fan, Floris Geerts, Xibei Jia and Anastasios Kementsietsidis, "Conditional functional dependencies for capturing data inconsistencies," ACM Transactions on Database Systems 33(2), 2008, Article 6\. The abstract read 2026-11-01; the full paper was not read. \[5\] Ziawasch Abedjan, Lukasz Golab and Felix Naumann, "Profiling relational data: a survey," The VLDB Journal 24(4), 2015, pp. 557–581\. The abstract, notes and references read 2026-11-01; the body was not read. \[6\] David Hollingsworth, "The Workflow Reference Model," Workflow Management Coalition, document TC00-1003, issue 1.1, January 1995\. Read 2026-11-01 in a partial extract from a university-hosted copy. \[7\] Microsoft Learn, "Learn about sensitive information types" and "Apply a sensitivity label to content automatically," Microsoft Purview. Read 2026-11-01\. Vendor documentation. ; \[8\] Microsoft Learn, "SQL Data Discovery and Classification." Read 2026-11-01\. Vendor documentation. \[9\] Loraine Lawson, "The Winds of Change: More Master Data Management Projects Succeeding," IT Business Edge, 24 September 2012, reporting a survey by The Information Difference. Read 2026-11-01; the figures are as reported in the article, not checked against the survey. \[10\] Judith Bachant and John McDermott, "R1 Revisited: Four Years in the Trenches," AI Magazine 5(3), 1984, pp. 21–32\. Read 2026-11-01\. \[11\] Elliot Soloway, Judy Bachant and Keith Jensen, "Assessing the Maintainability of XCON-in-RIME: Coping with the Problems of a VERY Large Rule-Base," Proceedings of AAAI-87, 1987, pp. 824–829\. Read 2026-11-01\. \[12\] Raja Parasuraman and Victor Riley, "Humans and Automation: Use, Misuse, Disuse, Abuse," Human Factors 39(2), 1997, pp. 230–253\. The abstract read 2026-11-01; the full paper was not read. \[13\] John D. Lee and Katrina A. See, "Trust in Automation: Designing for Appropriate Reliance," Human Factors 46(1), 2004, pp. 50–80\. Read 2026-11-01 in the authors' copy (first two-thirds). \[14\] Anthony Algmin and Jennifer Zaino, "Trends in Data Governance and Data Stewardship," DATAVERSITY, 2018\. Read 2026-11-01\. \[15\] Oracle, Oracle8i Application Developer's Guide – Fundamentals, Release 8.1.5 (A68003-01), chapter 12, "Establishing Security Policies" (fine-grained access control). Read 2026-11-01; the release date is not printed in the chapter and is dated here by the release. \[16\] Microsoft Learn, "Dynamic data masking" and "Row-level security" (SQL Server 2016 (13.x) and later). Read 2026-11-01\. ; \[17\] Lisanne Bainbridge, "Ironies of Automation," Automatica 19(6), 1983, pp. 775–779\. Read 2026-11-01 in a hosted scan. \[18\] Richard I. Cook, David D. Woods, Elizabeth McColligan and Michael B. Howie, "Cognitive consequences of clumsy automation on high workload, high consequence human performance," SOAR 90, NASA, 1991\. The abstract read 2026-11-01\. \[19\] Stephen Swoyer, "Data Profiling Pros Welcome TS Discovery 5.0," TDWI, 11 January 2006\. Read 2026-11-01\. \[20\] Irina Steenbeek, "Data Steward: From Business Expert to Data Professional," Data Crossroads, 25 March 2026\. Read 2026-11-01\. Practitioner blog. \[21\] Informatica, "Data & AI Governance, Access and Privacy" and "CLAIRE AI Engine" product pages. Read 2026-11-01\. Vendor pages (a Profisee competitor). ; \[22\] Collibra, "About Collibra AI" (product documentation, latest) and "AI governance" product page. Read 2026-11-01\. Vendor pages. ; \[23\] Microsoft Learn, "Overview of data quality in Microsoft Purview Unified Catalog," updated 8 September 2026\. Read 2026-11-01\. Vendor documentation (a vendor Profisee is aligned with). \[24\] Gartner, "Gartner Predicts 80% of D&A Governance Initiatives Will Fail by 2027, Due to a Lack of a Real or Manufactured Crisis," press release, 28 February 2024\. Read 2026-11-01\.