For data & governance leaders

AI Enablement for Data Governance

Turning policy prose into enforceable rules, and giving overstretched stewards leverage on the judgment-intensive work - without ever letting AI become the enforcement gate.

R.E.A. Haines - September 2026 - Download the Word version

Related governance dimensions

---

Executive Summary

Most organizations that have invested in data governance end up in the same place: a complete, well-written policy suite that changes almost nothing about how data is actually created, corrected, and controlled. The policies are sound. The problem is that a policy is prose, and enforcement requires machine-readable rules. The gap between the two is where governance programs quietly stall.

A second constraint compounds the first. The people expected to enforce these policies - data stewards and owners - almost never do the work as a full-time role. Stewardship is layered on top of an already-full job, so the judgment-intensive tasks that governance actually depends on (matching messy values to standards, answering "who decides this?", assessing the impact of a change, triaging integration failures) simply do not happen at scale. There is no capacity for them.

These two constraints, taken together, define exactly where artificial intelligence earns its place in a governance program. AI's highest-value role is to close the prose-to-rules gap and to perform the reading, drafting, matching, and triage work that currently exceeds human capacity - while deterministic code, not AI, remains the thing that actually enforces the rules on production data.

This paper lays out a four-layer architecture built on a single governing principle: AI proposes, humans dispose, deterministic code enforces. It describes each layer, maps specific AI capabilities to the standard data-governance policy domains, offers a twelve-week implementation sequence that requires no new system procurement, and states plainly what AI cannot and must not do. The goal is not to automate governance. It is to make governance survivable at current headcount, and to generate the evidence that justifies the deeper investment the organization will eventually need.

1. The Core Problem: Policies Are Prose, Enforcement Needs Rules

Consider a governance program that has done everything right. It has a full policy suite covering the eight domains most enterprises need: data quality, change management, master data management, retention and archival, access control and security, data integration, reference data management, and data remediation. Each policy was reviewed, approved, and published.

None of it is executable. A reference-data policy might specify, in a single section, rules for capitalization, abbreviation, punctuation, pluralization, special characters, null representation, allowed languages, and maximum field length. Every one of those is a testable assertion. Not one of them is being tested, because the assertion lives in a Word document, not in a rule engine.

The second constraint is organizational, and it is just as decisive. A common proposal at this stage is to ask the executive steering committee to fund dedicated data-steward headcount in every region. In practice that proposal rarely survives. Stewardship, leaders conclude, has to be "part of the job," not a new standalone role. That is a reasonable position, but it has a consequence that is usually left unstated: the judgment-intensive governance work now has no one with the time to do it.

Put those two constraints together and the opportunity becomes precise. AI is not here to replace stewards or to make governance decisions. It is here to (a) translate approved policy prose into executable rules, and (b) do the high-volume reading, matching, and drafting that precedes a human decision, so that the scarce human judgment left in the system is spent on approval rather than research.

1.1 The Governing Design Principle

AI proposes. Humans dispose. Deterministic code enforces.

Large language models are non-deterministic. The same input can produce different output, and the model can state a wrong answer with complete confidence. That property alone disqualifies AI from serving as the enforcement gate on production data. Enforcement belongs to the boring, reliable machinery: database constraints, foreign keys, lookup validation, and rule engines that behave identically every time they run.

AI belongs to the layer in front of that machinery - the reading, drafting, triage, matching, and explanation work that supports a human decision. Hold that boundary and AI becomes a powerful accelerant. Blur it, and you have introduced an unauditable, non-repeatable component into the one part of the stack that most needs to be auditable and repeatable.

2. A Four-Layer Architecture

The architecture has four layers. Each has a distinct job, and the boundary between deterministic and AI-driven components is explicit at every step.

Data flows from policy documents through rule extraction into both the deterministic conformance engine and the AI agent layer. Both feed a single steward queue. Steward decisions feed back into the rule repository, closing an improvement loop: every human approval or rejection makes the next proposal better.

3. Layer 1 - Policy-to-Rule Extraction

The policies contain hundreds of testable assertions buried in prose. This is the single highest-leverage component in the whole architecture, because every other capability depends on it.

Method. A language model parses each policy document section by section and emits structured rule definitions. Each rule carries its provenance: the policy it came from, the section number, and the exact assertion text that generated it. The rules are reviewed by a human once, then committed to version control, after which they are fixed, executable, and auditable. Any existing set of already-documented test cases makes an ideal validation set: if the extraction reproduces the known cases correctly, the remainder can be trusted with spot-checking.

Illustrative rule output (one assertion, made executable):

rule_id:   REF-DISPLAY-TITLECASE
policy:    Reference Data Management, Display Value Standards
assertion: "Title Case for multi-word values"
scope:     [Brand, Display Type, Delivery Method, Item Type]
test_type: regex
severity:  warning
auto_correct: true
owner_role: Data Steward

Scale and value. A full eight-policy suite typically yields on the order of two to three hundred executable rules. This is a one-time extraction, maintained thereafter through normal policy amendment. Without this layer, every downstream capability has to be hand-coded against policy text that only exists in documents. With it, the policy suite becomes something a machine can actually run.

4. Layer 2 - Continuous Conformance Monitoring

Once rules exist, checking data against them should be automated, scheduled, and completely deterministic. This layer deliberately contains no AI: for auditability and repeatability, conformance measurement must produce the same result every time it runs, on any modern data platform (a lakehouse notebook-and-pipeline environment is sufficient; no specialized tooling is required).

The output of this layer - conformance rates, trended over time, per domain - turns out to be one of the most valuable things the whole program produces. More on that in Section 8.

5. Layer 3 - Applied AI Capabilities

This is the layer that does the work which genuinely requires judgment and which, today, does not get done at scale. Each capability produces a proposal for a human to approve; none of them writes to production data on its own.

5.1 Semantic Matching and Variant Resolution

This is the highest-volume application. Legacy systems accumulate variants: a brand value stored as ACME-X against the golden standard Acme X, or a delivery-method field with dozens of legacy codes (SPRY1, CLSC, PMP2) that need to collapse onto a much smaller set of standard values.

Plain fuzzy string matching resolves perhaps 60 percent of these cases. A language model supplied with the policy context and the golden-standard list resolves well over 90 percent and, critically, explains its reasoning:

SPRY1 maps to Spray Applicator, Gen 1 (confidence: high). The SPRY prefix matches the Spray Applicator family; the numeric suffix 1 indicates first generation, distinguishing it from SPRY2. This mirrors the CLSC to Classic pattern in the same field.

The reasoning is the point. It lets a steward approve or reject with confidence, reviewing a ranked list instead of researching each value from scratch. Work that would take a steward the better part of a week becomes an afternoon of approvals.

5.2 Solving the Decision-Rights Problem

A recurring, and expensive, blocker in governance programs is not capability but unclear authority. A regional steward is fully able to standardize a value but does not know whether that decision is hers to make. Organizations that historically encouraged regional autonomy hit this wall hard the moment they move to a single global system.

A governance assistant grounded in the policy corpus and glossary, using retrieval-augmented generation, answers decision-rights questions directly:

Q: Who approves adding a new delivery-method value?

The data steward validates the proposal against the reference-data standards. The data owner for that domain approves. If a standards exception is required, the data governance lead co-approves. Target turnaround is one to three business days. Submit via a reference-data change request with: domain, proposed value, proposed code, definition, and business justification.

This makes governance tangible in a way a policy PDF never is. It requires no new systems and minimal build effort, and it is an ideal candidate for a live demonstration to a steering committee, because it answers the question every "if you see something, say something" model leaves open: say it to whom?

5.3 Description Standardization

Free-text item or product descriptions are usually the highest-value and most difficult target - the place where the most business meaning is locked up in the least structured field. Given a defined format (for example: Brand, Size, Case Count, Delivery System), a language model parses free-text descriptions into structured components, flags ambiguities rather than silently resolving them, and cross-validates its proposals against the structured fields on the same record.

Where a description reads ACME 12 OZ and the brand field reads Acme Pro, the system proposes Acme Pro 12 oz and flags the source disagreement for a human. This work is effectively infeasible by hand at scale, and well matched to language-model capability.

5.4 Impact-Assessment Drafting

Change-management and remediation policies both require an impact assessment before a change. These are routinely skipped, because they are tedious to write. An agent supplied with data lineage and the metadata model can draft them:

Proposed change: retitle a set of code values from all-capitals to Title Case, affecting a few hundred rows. Downstream impact: three BI reports filter on the literal old value; two integration pipelines contain hardcoded clauses; the synchronization mapping to the downstream hub needs updating. Rollback: reverse the update from a pre-change snapshot. Recommendation: update reports and pipelines in the same change window.

The steward edits and approves rather than authoring from nothing. An omitted control becomes a performed one.

5.5 Dead-Letter Triage

Integration policies typically require steward review of failed ("dead-letter") records within a fixed window. AI clusters the failures by root cause, separates systemic problems from isolated ones, and drafts the disposition:

Roughly 40 records quarantined; the large majority share one root cause - the source system is sending a singular value where the target expects the plural form. Recommend a single translation-table entry rather than dozens of individual record corrections.

6. Layer 4 - Prevention at the Point of Entry

The highest-value intervention is the one that stops the defect from being created at all. Good governance already mandates constrained lookup fields. AI makes those lookups intelligent rather than merely restrictive - which is what drives adoption instead of workarounds.

The boundary holds here too: the deterministic constraint remains the gate. AI supplies ranking, suggestion, and explanation within that gate, never around it.

7. Mapping AI to the Policy Suite

Each standard policy domain has a distinct highest-value AI application.

8. A Twelve-Week Implementation Sequence

The sequence below is designed to deliver a demonstrable result at every checkpoint, and to fit inside a ninety-day window using only existing tooling - no new system procurement.

The final pilot is deliberately scoped to one family. Proving value in one place is what makes stakeholders ask for it elsewhere - the mechanism by which organizational belief is actually built.

9. The Strategic Payoff: Measurement as the Investment Case

The most important output of this program may not be correction at all. It may be measurement.

The fastest route to funding a proper master-data investment is rarely an internal memo; it is evidence. Executives act when they can see pain quantified, not when functional leaders assert it. AI-generated conformance metrics are the mechanism that converts pain from anecdote into evidence.

A business case backed by trended conformance data and quantified effort is a fundamentally different object from one backed by assertion. It is the difference between "we think data quality is a problem" and "here is the measured cost, the trend line, and the point at which it breaks."

10. Limitations and Guardrails

These constraints should be stated explicitly, to prevent overstatement of AI capability and to protect the integrity of the governance framework.

11. Conclusion: Start With the Rules

Of everything in this architecture, one component is the foundation for all the rest: policy-to-rule extraction. Build that first.

It requires no new infrastructure and no procurement. It touches no production data, so its risk is minimal. And it produces an immediately reviewable artifact - a version-controlled repository of executable rules, derived directly from the approved policy suite, with full provenance back to the source assertion. From two to three hundred rules across eight policies, validated against a set of known test cases, everything else in this paper becomes buildable: the conformance engine, the AI mapping proposals, the prevention layer at the point of entry.

Governance fails when policy stays prose. It becomes real the moment the prose becomes rules a machine can run and a steward can trust. AI is what makes that translation affordable - and what finally lets a small, part-time stewardship function govern data at enterprise scale.

Companion papers

Read alongside these companion papers:

• The AI-Readiness Gap - why AI projects fail on data, not models
• Fix, Prevent, Govern: Data Remediation That Sticks - making remediation durable
• The Hidden Cost of Bad Data - the CFO’s view of data-quality cost