OMB issues federal agency AI governance and risk-management guidance

By Hypler editorial team · Source: US Office of Management and Budget.

Original source date: 2024-03-28.

Hypler publication: 2026-10-06. Hypler updated: 2026-10-10.

Topics: US, inventory, oversight

United States Capitol west front, 1997. Government context photograph, not the White House or an AI policy event. Credit: Architect of the Capitol / Wikimedia Commons, 1997. Public domain in the United States License details.

Generated illustration of evidence records passing through a permission gate; not a compliance certification. Credit: Hypler / AI-generated editorial illustration. Hypler editorial asset; not vendor or event photography

Engineering relevance

What M-24-10 said

OMB Memorandum M-24-10 directed U.S. federal agencies to establish AI governance, manage risks, publish inventories, and apply safeguards for safety-impacting and rights-impacting uses. It is binding guidance for covered federal agencies, with controls, timelines, accountability, and reporting mechanisms that differ from private-sector practice for covered uses. The March 28, 2024 memorandum is not a private-sector rulebook. Its value to software teams is the operational shape of its questions: who owns a use case, what is known about it, what risk boundary applies, and how is that evidence kept current.

Borrow the operating pattern

The memo gives useful patterns for inventories, impact assessment, human oversight, and monitoring. Hypler can borrow operational ideas while keeping private-sector work scoped to applicable commitments and contracts. An inventory is valuable because it limits the invisible spread of model use: it can capture a workflow's name, owner, vendor, input category, output audience, tool permissions, and change history. That is more precise than an organization-wide statement about using AI or Super Intelligence, and it lets a team distinguish research assistance from a workflow that can influence a consequential decision.

Inventory as a system interface

For engineering, the inventory should be fed by delivery artifacts rather than a separate spreadsheet that becomes stale. A deployment manifest can emit model and endpoint identifiers. A tool gateway can emit declared capabilities. A service registry can emit the route owner and data classification. The resulting record still needs a human accountable for meaning, but automated fields reduce transcription error. Hypler's direction toward inspectable systems fits this approach: do not treat a model call as an untraceable helper function; treat it as a versioned dependency with defined inputs, permissions, observable outcomes, and an explicit person or service responsible for exceptions.

Where oversight breaks

Oversight fails when the documented decision point differs from the actual one. For example, a human approval screen may exist but default to automatic acceptance, or a reviewer may see only the model's conclusion without source evidence. Monitoring also fails when it counts completions but not harm-relevant failures such as unsupported claims, unauthorized tool attempts, or outcome reversals. A public inventory alone cannot fix those problems. Product logic must preserve the option to pause a workflow, rerun it with a known revision, and investigate a result without exposing private inputs in a broad diagnostic log.

Hypothetical agency-inspired workflow

In a hypothetical Hypler partner portal, a drafting assistant prepares a case handoff. The inventory entry says the assistant may read an approved case summary, may not query external systems, and may not send messages. A reviewer must select a final handoff template and can compare the draft against its cited fields. When the source record is incomplete, the assistant returns a missing-information state rather than an invented account. The event record stores the workflow revision, the reviewer action, and a redacted error category. This borrows accountability mechanics without claiming that the portal is a federal agency system or follows M-24-10 requirements.

Testable controls

Acceptance tests can require an inventory record before a model-backed route is enabled, reject a request that asks for a capability absent from its declared allowlist, and verify that a reviewer decision cannot be silently replaced by model output. Regression cases should include changed model IDs, unavailable source records, malformed tool results, and a user who tries to prompt the assistant to bypass its role. A release review should compare the route manifest with the inventory and flag new data categories or action authority. These checks turn the memo's useful governance ideas into local software evidence without presenting a policy memo as proof of legal compliance.

Implementation detail

The durable engineering lesson is an inventory that is useful on an ordinary Tuesday, not a spreadsheet assembled after a request arrives. Each entry should name a workflow owner, the business decision it supports, approved input classes, the model and tool boundaries, evaluation status, and a contact who can disable it. Link the entry to a deployment manifest or configuration revision so an inventory row can be traced to actual code and settings. For systems that influence a person or a material decision, add a decision ledger: what the system supplied, what the authorized person decided, when the handoff occurred, and which appeal or correction channel was offered. That is more informative than a log saying an assistant was used. Monitoring should report drift in the facts that matter to the stated use: fallback frequency, missing evidence, refusal rate, tool errors, reviewer overrides, and changes in input distribution. A rising success rate can conceal a growing share of incomplete outputs, so pair aggregate measures with sampled traces. Exercises should include a model outage, a stale data source, an unavailable human reviewer, and a request outside the declared purpose. Private teams can borrow this structure without presenting themselves as federal agencies or importing government-specific obligations into customer contracts.