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, SNAP, and IEVS data — 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 most MOUs predating the current AI investment cycle were 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) mandated FHIR R4 APIs for patient data access and established information blocking rules. States implementing Medicaid programs were required to build FHIR-compliant Patient Access APIs and Provider Directory APIs to maintain federal certification.
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.
What that mandate revealed in practice was not 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. States that resolved their Medicaid data governance in response to the FHIR mandate ended up with better data infrastructure for every downstream use case, including AI. 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. NASCIO has published research documenting 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? Most existing MOUs 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? Due process for adverse determinations — benefits termination, fraud determination, license denial — requires explainability and record retention. Most commercial AI systems do not provide either 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
States that have moved past the readiness questions have typically adopted a structured approach to enterprise data architecture:
- 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's AI advisory work for state government has returned consistently to data architecture as the first layer of work, before model selection, before vendor evaluation, and before procurement strategy. The patterns evident in state AI engagements reflect the challenges described here: data fields without clear ownership, integration gaps that block cross-program use cases, and sharing agreements that were not written for AI workloads. Addressing the data governance layer first compresses delivery timelines and reduces the technical remediation that otherwise delays production deployment.
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
- OMB Memorandum M-24-10, "Advancing Governance, Innovation, and Risk Management for Agency Use of Artificial Intelligence" (Mar. 28, 2024): whitehouse.gov
- NASCIO, State CIO and CDO publications (nascio.org)
- CMS Medicaid Enterprise Systems (MES) Blueprint (medicaid.gov)
