What the ranking actually says
Artificial intelligence leads the National Association of State Chief Information Officers' 2026 priorities. Cybersecurity held the top position for twelve consecutive years and now ranks second. The ranking records CIO priorities; it does not establish why individual states made past investment decisions or show that their cybersecurity needs have been resolved.
For CIOs, the ranking raises a practical budget question: which capabilities will the state build, who will evaluate them and what will it cost to keep them working?
Make the dependencies explicit
NASCIO's full 2026 list frames the AI priority around governance and policies, security and privacy, workforce skills, data quality, ethical use, and overall adoption. Those responsibilities depend on one another. Governance should identify the intended use and the data used for training where applicable, retrieval, testing and operation; not every state AI deployment trains its own model.
Evaluating data quality requires suitable access, methods and accountable people. A bounded manual review may be enough to expose a problem before a state invests in automated auditing infrastructure. Parallel work streams can be effective if their dependencies are explicit and someone owns the evidence required before deployment. Otherwise a framework can reach approval before the evaluators or monitoring capability exist.
Treat data readiness as use-case specific
Data quality is a constraint worth making explicit. Many legacy program systems were designed for transactions and reporting, not the specific AI use now proposed. A Medicaid eligibility platform may predate newer interoperability mandates. Employment and wage data collected for different statutory purposes can carry inconsistent definitions of the same concepts. Benefits enrollment may use identifier schemes that were not designed to reconcile across programs. Asking whether development, evaluation and operational data represent the cases and people affected can expose previously overlooked integration debt or make an already known defect consequential for a new use.
AI is, in this sense, functioning as a quality audit on state data architecture. States that address the underlying integration debt directly will build something that outlasts the specific model. States that paper over it with governance language will accumulate technical debt in a new form.
Provide evaluation capacity agencies can use
Workforce is the compounding constraint. The skills required to govern AI seriously — reading model documentation with informed skepticism, identifying statistical bias in outcomes data, monitoring model drift in deployed systems — can be difficult to recruit under public-sector compensation and classification constraints. A state CIO who is serious about AI governance needs either staff who can do this work or a shared service arrangement that delivers the capability to agency programs that cannot afford to develop it independently.
The shared-service pattern also appears in functions such as GIS, human resources and security operations. It is one option for AI evaluation, particularly where agencies cannot sustain specialized staff. An agency with established technical capacity may do more internally; a hybrid or contracted arrangement may fill a specific gap. In each model, program officials retain responsibility for the decision, and reviewers need enough independence to challenge the product being evaluated.
Put recurring governance into the budget
The budget makes these choices concrete, and NASCIO's number three priority is budget and fiscal management. Building AI governance capacity costs money: staff time, suitable evaluation and monitoring tools, and technical skills that must be maintained. Each state should assess the recurring commitment against its own fiscal position. A dedicated budget line can make the obligation visible; documented allocations within existing programs can also support it. If funding comes from another service, identify the resulting capacity loss and have the responsible official accept that tradeoff. Publishing a strategy alone does not establish that the operating work is funded.
For the next applicable budget cycle, the useful test is whether the request reflects what governing the proposed deployments actually costs. States have different fiscal calendars and planning horizons.
Judge the operating model, not the policy document
A credible program should be judged on sequencing as well as policy language. Resolve data defects that would invalidate the intended use before scaling it; not every pilot requires repairing an entire enterprise first. Choose an agency, shared or hybrid evaluation function that can actually handle the workload. Support honest workforce conversations: what classifications attract people who can do this work, what the agency can offer that large technology employers cannot, and how contracted vendors are held accountable for what their models actually deliver in production.
The NASCIO list identifies stated priorities. Turning those priorities into dependable services requires operating capacity, suitable use cases and evidence that the chosen approach improves the work.
Price the review workload before approving the queue
Suppose, as an illustrative planning case, three agencies propose AI tools at once: an internal policy search assistant, a public information service and a tool that recommends which benefit cases receive additional review. Calling all three projects pilots does not make their consequences equivalent. The third can change who faces an investigation; the second can give residents incorrect instructions; the first still needs controls over sensitive records and unreliable answers.
The CIO's office should ask each program for a small evaluation brief: its intended decision, data access, expected users, error consequences and release date. Evaluators can then estimate work against actual availability. A shared reviewer assigned to three launches in the same week is not three separate units of capacity. Vendor updates, incident follow-up and already deployed systems also consume that person's time.
This changes the budget discussion. The request may be for a qualified evaluator, secure test access and program staff time rather than another platform license. Where those resources are unavailable, narrow the use or move the release date. An internal search pilot using approved public material could proceed while a consequential case-routing tool waits for a defensible reference set and review process. That is a reasoned sequencing decision, not evidence that either project is inherently safe or unsafe.
Make the next funding decision depend on evidence
A successful demonstration answers whether the product can perform selected tasks. Continued funding should answer whether it improves the agency's work under the conditions in which it will operate.
- The program owner compares results with the existing process, including staff time spent correcting outputs and handling exceptions.
- The technical reviewer checks failures on representative cases and records where test coverage remains weak. A polished answer is not proof of a correct answer.
- The service owner estimates the recurring workload after model, source-data or policy changes and identifies who covers absences.
- The approving official decides whether to expand, continue within limits, repair or stop, with reasons recorded.
These are recommended operating roles, not titles mandated by the NASCIO list. A smaller agency may combine roles where appropriate while preserving an independent challenge to the vendor's evidence. The important distinction is between having access to expertise and having that expertise available when a release decision is due.
A backlog of unreviewed changes is therefore a useful capacity warning. Count it alongside evaluation coverage and track its age and consequence. More completed assessments are not progress if the highest-risk changes remain waiting or the resulting conditions are never enforced.
Turn the priority into a release decision
- Define one outcome and its limits. Identify the decision or task being improved, the people affected and the errors the program cannot tolerate. Establish a non-AI baseline for comparison.
- Test the actual data path. Review training where relevant, retrieval sources, test sets and production inputs. Check representativeness, quality, permissions and retention separately.
- Name the evaluators. Identify technical, security, privacy, program and accessibility reviewers. State which evidence they need and who resolves disagreements before deployment.
- Budget the recurring work. Include monitoring, revalidation after vendor changes, incident response, resident correction channels and staff development. A funded pilot is not a funded service.
- Use a release decision record. Document baseline results, remaining risks, approval, rollback conditions and the next review date. Stop or narrow a use case when the required evidence is missing.
What to measure
- Evaluation coverage: deployments with a representative test set, documented baseline and named reviewer.
- Change control: vendor or model changes detected and reassessed before they affect consequential use.
- Operating capacity: recurring review work funded and staffed, with a backup for each critical role.
Sources and further reading
- NASCIO 2026 priority list — AI first and cybersecurity's preceding twelve-year run
- NASCIO agentic AI report — government AI governance and evolving autonomy context
Spartan X's AI consulting, engineering and cybersecurity disciplines support the less visible work behind an AI priority: defining a suitable use, evaluating it and putting the controls and ownership in place to sustain it.
