An auditor testing AI use in a state agency can ask for three things: a current inventory of the AI systems in use, a documented policy the agency can show it actually followed, and a log of individual uses that ties a specific request to a specific outcome. Two public frameworks give that test its shape: the GAO’s AI accountability framework, written for federal agencies and other entities, with audit procedures and the types of evidence auditors should collect, and NIST’s AI Risk Management Framework, which Washington’s executive order on AI cites by name. Neither an inventory nor a policy answers the audit question if the agency cannot produce the record for one system, on request, months after the fact.
What belongs in a state agency AI inventory?
NIST’s AI Risk Management Framework treats the inventory itself as a governance outcome, not paperwork. Under the Govern function, “mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities” (NIST AI 100-1, Govern 1.6, p. 23). What states actually collect under that heading varies, but four examples show the shape of it.
California’s AB 302 added Section 11546.45.5 to the Government Code, signed October 13, 2023 and effective January 1, 2024. It requires the Department of Technology to inventory every high-risk automated decision system, defined as one used to assist or replace human discretionary decisions that have a legal or similarly significant effect, including decisions on access to housing, education, employment, credit, health care, and criminal justice, that any state agency has proposed, developed, procured, or used, and to report that inventory to two legislative committees every year starting January 1, 2025. The inaugural report, covering program year 2024 and published in January 2025, canvassed 204 state agencies. 198 responded, and none reported a system that met the statutory definition.
Connecticut’s Public Act No. 23-16, effective July 1, 2023, directs the Department of Administrative Services to conduct an annual inventory of every system that employs AI and is used by a state agency, and the state publishes it. The required fields are narrow and specific: the system’s name and the vendor’s, a description of its general capabilities and use, whether it independently makes, informs, or materially supports a decision, and whether it underwent an impact assessment before implementation. The Bureau of Information Technology Solutions inside the Department of Administrative Services maintains it.
Washington’s Executive Order 24-01, signed January 30, 2024, gets at the same record through risk assessment rather than an inventory. It directs WaTech to produce guidance on risk assessments for high-risk generative AI, and each assessment must cover whether a third party provides the system and that party’s name and address, the intended uses, fitness for that purpose, the communities affected, the potential harms, the mitigations, and how the agency’s approach to generative AI governance is consistent with the NIST framework, which the order names.
Colorado’s Office of Information Technology requires every generative AI use case, including third-party vendor tools, to go through an OIT intake and a NIST-based risk assessment before deployment, and to be recorded in ServiceHub.
None of these four states asks for the same record, and a page that answered for one and implied the rest would be wrong for the other three. What they share is a smaller core: what the system is, what it is used for, and what has been done to assess or reduce its risk.
How do you prove compliance with your own AI use policy?
A policy document proves the agency decided something. It does not prove anything happened afterward, and an auditor is testing the second claim, not the first. GAO’s framework calls this out directly under its Governance principle: entities should “ensure the AI system complies with relevant laws, regulations, standards, and guidance” and should “promote transparency by enabling external stakeholders to access information on the design, operation, and limitations of the AI system” (GAO-21-519SP, Framework Principle 1, practices 1.8 and 1.9, p. 5). NIST’s framework puts the same expectation under its Govern function: policies related to AI risk are “in place, transparent, and implemented effectively,” and specifically that “legal and regulatory requirements involving AI are understood, managed, and documented” (NIST AI 100-1, Govern 1 and Govern 1.1, p. 22). In both, the expectation reaches past what was decided to what can be shown.
In practice that means the agency can answer, for one system, on one date: which version of the policy applied, who approved the use, what the AI tool was given, and what it returned. A training record or a signed acknowledgment form answers none of those questions. It shows staff were told the rule, not that the rule held, which is the whole distinction our post on AI policy enforcement works through in more depth.
What records should an agency keep of AI use?
GAO’s Monitoring principle asks entities to “document results of monitoring activities and any corrective actions taken to promote traceability and transparency” (GAO-21-519SP, Framework Principle 4, practice 4.3, p. 8), and its Performance principle asks them to “catalog model and non-model components, along with operating specifications and parameters” (Framework Principle 3, practice 3.1, p. 7). Read together, the expectation is a running record, not a point-in-time policy, which is the same distinction our explainer on what an AI audit trail actually contains covers for a single interaction.
Colorado is the one state in this group that puts a number on it. SB 26-189, the Automated Decision-Making Technology act, takes effect January 1, 2027 and requires developers and deployers of a covered automated decision-making technology, one used to materially influence a consequential decision, to keep records reasonably necessary to demonstrate compliance for at least three years. The act defines a deployer as a person doing business in Colorado, so whether a state agency is itself a deployer is unsettled, though the consequential decisions it covers include eligibility for essential government services and public benefits. Connecticut’s inventory requirement works differently: because it is public and annual rather than internally retained, the record of what an agency reported, and when, accumulates on the state’s own open data portal.
Whether the prompts and outputs behind one AI-assisted decision are themselves subject to a public records request is a related and unsettled question that this page does not try to answer.
Who in the agency owns the answer?
Ownership of the inventory and ownership of the audit answer are not the same job, and conflating them leaves a gap an auditor can find. Every state cited here puts the central duty, the inventory or the risk-assessment guidance, with a central technology office: California’s Department of Technology, Connecticut’s Bureau of Information Technology Solutions, Washington’s WaTech, and Colorado’s Office of Information Technology. None of those offices is positioned to answer, alone, whether one specific captured interaction from six months ago satisfies one specific legal duty.
Both frameworks push that second question down to defined roles. GAO’s Governance principle calls for entities to “define clear roles, responsibilities, and delegation of authority for the AI system to ensure effective operations, timely corrections, and sustained oversight” (GAO-21-519SP, Framework Principle 1, practice 1.2, p. 5). NIST’s Govern function is more explicit still: “roles and responsibilities and lines of communication related to mapping, measuring, and managing AI risks are documented and are clear to individuals and teams throughout the organization” (NIST AI 100-1, Govern 2.1, p. 23). One workable split runs three ways. The CIO or CISO owns whether the system is inventoried and risk-assessed at all. General counsel owns whether the record satisfies whatever law or attestation is in play. Procurement owns whether the vendor contract creates a record the agency can actually reach, or blocks one. If none of the three can name themselves for a given system, that gap is the finding, not a footnote to it.
Sources
- U.S. Government Accountability Office, Artificial Intelligence: An Accountability Framework for Federal Agencies and Other Entities, GAO-21-519SP, June 2021.
- National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1, January 2023.
- California Assembly Bill 302 (2023), adding Government Code Section 11546.45.5, effective January 1, 2024; California Department of Technology, High-Risk Automated Decision System Inventory, Program Year 2024, published January 2025.
- Connecticut Public Act No. 23-16, effective July 1, 2023.
- State of Washington, Executive Order 24-01, Artificial Intelligence, signed January 30, 2024.
- Colorado SB 26-189, Automated Decision-Making Technology, effective January 1, 2027.
- Colorado Office of Information Technology, Statewide GenAI Agency Responsibilities, read September 25, 2026.
Where Verillian fits
Verillian governs AI use on the devices your organization manages. A checkpoint on each device sits between your people’s AI tools and agents and the AI providers they reach. For the Anthropic API format it enforces your policy before a request leaves the device; for the other providers your policy names, it records the usage. Each record is signed on the device it came from and hash-chained to the one before it, and your own admin server flags any entry that does not link or verify when it arrives, so the record is tamper-evident and stays on your own infrastructure. Redaction is best-effort, not a guarantee that every value is caught. The admin server runs where you choose: on-prem, private cloud, or air-gapped. Mac is supported today, with Windows and Linux in early access. For an agency, that record can help evidence the monitoring GAO’s traceability practice asks it to document, for AI use that starts on managed devices, with each entry bound to the device and person it came from, alongside the inventory and the policy rather than in place of them. The architecture is aligned with the audit and accountability controls in NIST SP 800-53, not certified, because NIST does not certify IT products.
Verillian does not see inside a vendor’s own cloud. When a vendor’s service calls a model on the vendor’s servers, as an ambient scribe or a hosted report-writing tool does, the record of what that model received is created on the vendor’s side, and the contract is your lever for it. What Verillian gives you is the record of AI use that starts on your own devices.
Our compliance mappings lay out the controls the platform is designed to support, the audit trail page covers what a device-side record contains, and the government section of the industries page covers what this looks like for a state or local agency.