Use a current operating model for AI inventory, ownership, evaluation, supplier evidence, change control, transparency, incident handling, and executive risk decisions.
This revision replaces the obsolete M-24-10-era framework, reflects OMB M-25-21 and the amended EU AI Act, and treats NIST AI RMF as a practical risk framework rather than a certification.
OMB M-25-21, issued April 3, 2025, expressly rescinded and replaced M-24-10 for federal agency use of AI. It directs agencies to retain or designate Chief AI Officers, requires AI Governance Boards for CFO Act agencies, calls for agency AI strategies and compliance plans, and establishes minimum risk-management practices for high-impact AI uses. Those details matter to federal teams and vendors supporting them, but they should not be generalized into claims about every organization.
The July 2025 White House AI Action Plan adds a broader federal policy agenda focused on adoption, infrastructure, procurement, international leadership, and interagency coordination. For enterprise and state/local teams, the useful lesson is organizational: AI governance needs executive ownership and technology-operating processes, not only a standalone ethics policy.
NIST AI RMF remains a practical cross-sector framework organized around Govern, Map, Measure, and Manage. NIST's AI Resource Center currently notes that AI RMF 1.0 is being revised, so governance teams should use the existing framework while tracking future changes rather than hard-coding internal policy to wording that may evolve.
In the European Union, the AI Act is broadly applicable but follows a staggered amended calendar. The current Zeph Tech EU AI Act timeline separates obligations that are already active, the December 2026 synthetic-content transition, and the later 2027/2028 high-risk dates. Governance records should identify the exact legal role and obligation family instead of using one generic “EU AI Act status.”
An AI inventory should support a decision, not merely prove that a spreadsheet exists.
Do not restrict the inventory to models built internally. Include AI capabilities embedded in SaaS products, copilots, workflow tools, search features, contact-center systems, security products, analytics platforms, and vendor-operated services when they create a meaningful organizational dependency or risk.
Make material changes visible. A system can change risk without changing its product name: a new model, new retrieval source, new tool permission, new user group, new sensitive dataset, or new downstream decision can justify a fresh review.
Executive governance should set policy, resolve material exceptions, approve risk appetite, and receive meaningful reporting. Day-to-day system accountability should stay with named operational roles. A business owner should be accountable for why the AI is used; a technical owner for implementation and change; security/privacy/legal/accessibility specialists for their respective reviews; and an identified risk authority for accepting material residual risk.
For federal organizations, M-25-21 provides explicit CAIO and governance-board structures. Other organizations can adapt the principle without copying the federal org chart. The design objective is clear decision rights and escalation, not a particular title.
Create an exception process that is harder to ignore than the control it bypasses. An exception should identify the requirement, reason, evidence, compensating controls, owner, expiration, and review event. Permanent undocumented exceptions are a common way governance becomes ceremonial.
Keep meeting artifacts lightweight but traceable. Decisions should link back to the system inventory, evidence, evaluation, and open findings. A later reviewer should be able to understand why the organization approved a system without reconstructing months of chat messages and slide decks.
Document the intended purpose, users, information boundary, external actions, consequences of failure, and applicable obligations.
Run representative acceptance, security, quality, accessibility, and operational tests with predefined criteria.
Approve, restrict, conditionally approve, reject, or request more evidence. Record the risk owner and conditions.
Track the small set of signals connected to known failure modes, incidents, supplier changes, and cost/quality drift.
Trigger proportionate review when the model, workflow, data, permissions, provider, legal context, or consequence changes.
The AI Model Evaluation Operations Guide provides the detailed measurement layer. Governance should consume those results rather than creating separate subjective risk ratings disconnected from real system behavior.
Hosted AI inherits risk from model providers, cloud infrastructure, subprocessors, data flows, tools, and provider-controlled change.
Request model/system documentation, security evidence, data-use and retention terms, subprocessors, evaluation evidence, incident practices, version/change behavior, and export/exit capability.
Define change notice, data rights, incident notification, evidence refresh, material failure remedies, support, portability, deletion, and transition responsibilities.
Track material model and policy changes, supplier incidents, new dependencies, evidence expiration, deprecation, service performance, and conditions from the original decision.
Use the AI Procurement Governance Guide for the full buying lifecycle and NIST SP 1326 supplier due diligence briefing when ownership, provenance, resilience, cyber practices, or upstream dependencies matter to the decision.
Transparency should answer practical questions: does the person know they are interacting with or receiving material generated by AI when disclosure is required or appropriate? Do staff understand when output needs verification? Can a consequential recommendation be escalated or corrected? Does the system record enough information to investigate a complaint or incident?
For EU-facing systems, Article 50 and the 2026 amendments create specific transparency and synthetic-content considerations. For other environments, disclosure may come from internal policy, consumer law, procurement commitments, sector rules, or risk-management practice. Record the basis rather than applying the same banner to every system.
AI literacy should also be role-specific. A developer needs different competencies from a procurement reviewer, frontline operator, executive, or risk reviewer. Training evidence is stronger when it maps to actual responsibilities and known failure modes rather than a single annual awareness course.
Useful monitoring depends on the use case. Possible indicators include task-success drift, unsupported claims, override frequency, retrieval failures, tool failures, harmful or prohibited output, latency, cost per successful workflow, accessibility defects, incident frequency, and supplier changes. Avoid dashboards filled with metrics that no owner uses to trigger an action.
Define incident intake before the first problem. Staff should know how to report harmful output, data exposure, unexpected external actions, bias or access concerns, security events, and material service failures. Incident handling should preserve the model/version, prompts or relevant input, connected tools, logs, user impact, containment, and the governance decision that follows.
Not every issue is a security incident, and not every model error requires executive escalation. Use a taxonomy that routes technical defects, safety concerns, privacy events, security incidents, accessibility barriers, supplier failures, and legal questions to the appropriate owners while preserving one traceable record.
Periodic reviews should ask whether the original purpose, risk classification, supplier, controls, evaluation baseline, and legal context still match reality. Change-triggered review is often more valuable than an annual questionnaire performed simply because the calendar says so.
Leadership should be able to see which material AI systems are active, which lack owners or current evaluation, which have open high-severity findings, which depend on expiring supplier evidence, which are approaching legal or contractual milestones, and which incidents or changes have triggered re-review.
Useful measures can include inventory ownership coverage, percentage of material systems with current evaluation, overdue conditions, time to remediate high-severity findings, supplier evidence completeness, change-review timeliness, and the number of systems with a tested disablement or fallback path.
Counts such as “number of AI projects,” “number of models approved,” or “training completion” can provide context but should not be treated as proof the control environment works. Governance maturity is demonstrated when decisions are traceable to evidence and material changes cause appropriate action.
Last substantive review: September 2, 2026. This guide is an operational framework, not legal advice. Revalidate legal and agency-specific requirements for the system and jurisdiction in scope.
Use the source-backed research to pressure-test assumptions, then build a reusable evaluation brief before you compare products, scope implementation, or request a fit review.