The structural mismatch
State government data architecture evolved program by program. An unemployment insurance agency built its own database to support UI claims. Medicaid built a separate Medicaid Management Information System (MMIS). Child welfare built SACWIS, then moved toward CCWIS. Each system was procured, often at the direction of a federal program partner with its own data requirements, interoperability standards, and certification timelines.
The result is a landscape of isolated, independently-operated systems that do not share data in any normalized, documented way. A state that wants to deploy AI for benefits fraud detection — a use case that requires correlating UI, Medicaid and SNAP records, including the wage and income matches exchanged through the federally required Income and Eligibility Verification System (IEVS) — is not facing a machine learning problem. It is facing a data integration problem that no algorithm can resolve from the outside. The same pattern applies to AI eligibility determination, workforce analytics, service delivery optimization, and most high-value state AI use cases: the prerequisite is not a better model, it is a governed data layer.
What AI actually requires from data governance
Data governance for AI differs from data governance for reporting. Reporting systems tolerate stale data, undocumented fields, and inconsistent formats because human analysts compensate. An AI system that ingests training data inherits every defect in that data silently. A model trained on incomplete or biased historical records will reproduce those patterns at scale, at speed, without the warning signals that slow human review.
The minimum conditions for an AI program that operates reliably:
- Documented data ownership. Every data element used as a model input must have an identified steward — a specific person or role accountable for its definition, quality, and authorized use. Ownership undocumented at the field level is not ownership.
- Published data lineage. The upstream source for each field, transformation steps applied, and known quality limitations must be available to the model developer. "We get it from the legacy mainframe" is not a lineage record.
- Formal data sharing agreements. Cross-agency AI use cases require data sharing agreements that specify permitted uses, retention limits, and breach notification obligations. Verbal coordination is not an agreement, and the absence of a signed agreement blocks production deployment regardless of technical readiness.
- Measured data quality. Quality for AI is not the same as completeness. A field that is 100% populated but populated inconsistently — free-text entry, conflicting code systems, definitions that changed over time — is a reliability problem. Automated quality metrics, tracked over time, are required to detect drift.
- Documented training data provenance. The dates, sources, and known gaps of training data must be recorded. A model trained on data from a period before a significant policy change may embed now-incorrect assumptions that are invisible until they produce a systematic error.
Most state agencies can describe their major systems and confirm they are operational. Fewer can produce documented field-level ownership tables, formal lineage records, or tracked quality metrics. Fewer still have cross-agency data sharing agreements in place that cover AI inference workloads, since MOUs that predate the current AI investment cycle were typically written for reporting and batch-file exchanges, not for machine learning pipelines.
The federal interoperability mandate as a precedent
The federal government's experience with healthcare interoperability offers a direct precedent. The 21st Century Cures Act (Pub. L. 114-255, enacted December 2016) and ONC's implementing Final Rule (85 FR 25642, published May 1, 2020) established information blocking rules and required certified health IT to support a standardized API built on HL7 FHIR Release 4. A companion CMS rule then made FHIR-based Patient Access and Provider Directory APIs a program requirement for state Medicaid and CHIP programs, beginning January 1, 2021.
The state Medicaid obligation specifically came from the companion CMS Interoperability and Patient Access Final Rule (CMS-9115-F, 85 FR 25510, also published May 1, 2020), which applied directly to state Medicaid agencies and Medicaid managed care plans — a distinct rule from the ONC Final Rule that governed health IT developers and EHR vendors.
In our reading, what that mandate exposed was not primarily a technology gap. Most states had Medicaid IT vendors who could implement a FHIR endpoint. What it revealed was a data governance gap: the underlying member demographics, provider rosters, and claims data were frequently inconsistent, fragmented across adjudication systems, or governed by access control frameworks that predated API concepts. The mandate forced resolution of governance questions that had accumulated for decades, because compliance required answering them.
The lesson for state AI programs is structural: the forcing function mattered. A state that resolved its Medicaid data governance questions to meet the FHIR mandate should be better positioned for downstream uses, including AI, than one that built a compliant endpoint over unresolved data. CMS's follow-on rule (CMS-0057-F, 89 FR 8758, Feb. 8, 2024), which adds Provider Access, Payer-to-Payer and Prior Authorization APIs with API compliance dates generally beginning January 1, 2027, shows the forcing function is continuing. A state that waits for a comparable federal mandate before addressing data governance for AI programs will face the same acceleration under less favorable conditions — less time, more vendor pressure, and active program commitments that cannot absorb a data remediation project.
Where the CDO role fits
Many states have established a Chief Data Officer role, though the authority, reporting structure, and mandate assigned to that role varies significantly across the states that have created it. The 2025 NASCIO and Beeck Center state CDO survey documents the range — from CDOs with enterprise authority and meaningful budget ownership to nominally titled roles embedded in IT operations without cross-agency mandate or enforcement capability.
The distinction matters for AI programs. A CDO with enterprise authority can establish and enforce data standards, broker cross-agency sharing agreements, and set data governance preconditions for AI deployments as policy. A CDO without that authority can publish frameworks that agencies may or may not adopt.
State CIOs evaluating their data governance posture should assess the CDO's authority on three operational questions: Can the CDO block an AI deployment that lacks documented data governance? Can the CDO compel another agency to execute a data sharing agreement? Can the CDO set data quality requirements that are reflected in vendor contracts? In states where all three answers are yes, AI programs operate on materially stronger foundation, because the governance prerequisites exist before procurement begins rather than becoming remediation work inside a delivery project.
A readiness assessment before procurement
Before issuing an RFP for an AI system that will operate on state data, a CIO or CDO should be able to answer the following. If the answers require research, the data governance is not ready for the AI program being procured.
- What data does this system require as input, and where does each field originate? The answer should be available from a data catalog, not from a vendor conversation.
- Who is the documented owner of each input data element, and what are their quality commitments? Ownership without a quality SLA is not ownership for AI purposes.
- Do existing cross-agency data sharing agreements cover AI inference workloads, model training, and AI-generated output? Agreements written for reporting or batch-file exchange often do not, and retrofitting them after a deployment is technically and legally complex.
- How will the state detect and respond to training data drift? Models degrade as the distribution of input data shifts. Without a monitoring mechanism, reliability deteriorates without detection.
- What is the audit trail for model outputs that affect individual decisions? Adverse determinations — benefits termination, fraud determination, license denial — carry due process obligations. For public benefits, that means notice stating the specific reasons for the action and a hearing at which the decision maker states the reasons and the evidence relied on (Goldberg v. Kelly, 397 U.S. 254 (1970); for Medicaid, 42 CFR 431.210). Licensing and other programs have their own notice and hearing rules. In each case the agency must be able to explain and document how an AI output contributed to the decision, so confirm that the system supports that and retains the records; do not assume it does by default.
This is not a checklist intended to block AI adoption. It is the set of conditions that distinguishes a program likely to succeed from one that will require a parallel data remediation project before it delivers value.
Building the data architecture layer
A structured approach to enterprise data architecture typically includes:
- A master data management program for high-reuse reference data — individual identity, benefit eligibility, provider rosters — that enforces consistent identifiers across agency systems
- A data catalog accessible to AI developers that documents field definitions, owners, quality scores, update cadences, and authorized uses
- A standard data sharing agreement template that explicitly addresses machine learning inference, training data use, and model output access
- Data quality monitoring integrated into pipelines, with alert thresholds calibrated to AI system sensitivity rather than reporting tolerances
None of this requires a single large-scale platform procurement. It does require a governance decision — that data architecture is a precondition for AI investment — backed by policy authority to enforce it across agencies.
Spartan X's approach to state AI programs
Spartan X advises state leadership on AI strategy, enterprise architecture and AI governance, including frameworks that address data provenance, explainability and compliance. That work is where the readiness questions above belong: establishing who owns each input, how it is lineaged and shared, and how outputs are documented, before model selection, vendor evaluation and procurement strategy lock in assumptions that a later data remediation project would have to unwind.
Sources and further reading
- 21st Century Cures Act, Pub. L. 114-255 (Dec. 13, 2016): congress.gov
- ONC 21st Century Cures Act Final Rule, 85 FR 25642 (May 1, 2020): federalregister.gov
- CMS Interoperability and Patient Access Final Rule, CMS-9115-F, 85 FR 25510 (May 1, 2020): federalregister.gov
- CMS Interoperability and Prior Authorization Final Rule, CMS-0057-F, 89 FR 8758 (Feb. 8, 2024): federalregister.gov
- OMB Memorandum M-25-21, "Accelerating Federal Use of AI through Innovation, Governance, and Public Trust" (Apr. 3, 2025), which rescinded and replaced M-24-10; applies to federal agencies and is a useful governance reference for states: whitehouse.gov
- NASCIO and Georgetown Beeck Center, "The 2025 State Chief Data Officer Survey: Insights from the Field" (Oct. 2025): beeckcenter.georgetown.edu
- CMS, SHO #25-003, "Streamlining Medicaid Enterprise Systems (MES) Templates to Improve Monitoring and Oversight to Ensure Fiscal Integrity" (Aug. 6, 2025): medicaid.gov
