Wesley Adeyemi had ninety minutes on the calendar and a new Deputy Administrator who had spent the last twelve years in the private sector and had never read an OMB memorandum in her life. As policy director for a mid-sized federal grant-making agency, Wesley had briefed three Deputy Administrators before this one, and he had learned that the briefing always failed the same way: he would name twenty authorities, the new leader's eyes would glaze, and a month later she would announce an AI initiative that violated three of them. So this time he did not bring twenty slides. He brought one table. Across the top: the authority, what it requires, who it binds, the deadline or trigger, and our agency's specific obligation. Down the side: the things that actually govern what their agency could and could not do with artificial intelligence. His goal for the ninety minutes was simple. The Deputy should leave able to ask the right question before approving anything: which of these does this touch?

This lesson builds that table. The federal AI landscape looks like chaos from the outside: executive orders that get revoked, memos that supersede each other, frameworks that are voluntary until suddenly they are not. New guidance arrives regularly, it sometimes conflicts with what came before, and a change of administration can redirect the whole thing. The job of a policy director is not to memorize all of it, and it is certainly not to wait for the landscape to settle, because it will not. It is to know which instruments bind your agency, what each one demands, and how to keep the map current when the next administration redraws it. We will pitch this at the altitude Wesley needs, the altitude of someone who advises leadership, not someone implementing a single control.

The Shape of the Landscape: Five Kinds of Authority

Before the table, the Deputy needed one mental model: federal AI policy is not one document, it is a stack of instruments with different binding force, issued by different authorities, on different implementation timelines. Some are binding and immediate. Some are advisory and aspirational. Some apply to every federal agency and some only to particular sectors or system types. Wesley sorted them into five kinds, from hardest to softest.

• Statutes. Laws passed by Congress and signed by the President. These bind until Congress changes them. They outlast administrations. The Advancing American AI Act and the AI in Government Act sit here.
• Executive orders. Presidential direction binding on the executive branch until revoked or superseded. Powerful but impermanent. A new President can rescind an executive order on day one. EO 14110 is the headline example.
• OMB memoranda. The Office of Management and Budget translates executive orders and statutes into implementation requirements for agencies. These carry real compliance force and concrete deadlines. M-24-10 and M-24-18 live here.
• Frameworks and standards. NIST products such as the AI Risk Management Framework. Voluntary and non-binding in themselves, but referenced by the binding instruments above, which makes them the practical standard.
• Oversight standards. The Government Accountability Office and Inspectors General do not write rules, but they judge you against criteria, and what they flag becomes tomorrow's requirement.

The reason this ordering matters: when two instruments conflict, the harder one wins, and when a softer one is revoked, the harder one underneath it survives. This is also where briefings most often go wrong. It is common to see the landscape presented with executive orders at the top of the hierarchy because they are the most visible and the most reported. They are not the most durable. Wesley's warning to the Deputy was exactly this. An executive order can vanish overnight. The statute beneath it does not.

EO 14110 and Why an Executive Order Is Not a Foundation

Executive Order 14110, Safe, Secure, and Trustworthy Development and Use of Artificial Intelligence, was issued in 2023. It set the federal tone: agencies were to manage AI risk, protect rights and safety, build governance, and grow AI talent, with attention to safety testing, security, equity and civil liberties. It has since been rescinded by a later administration, which is precisely the point Wesley wanted the Deputy to take from it. Speak about it historically. It is the instrument that shaped the current governance architecture and the reason many agency programs look the way they do, and it is also the clearest demonstration in the whole landscape that the most visible authority is often the least permanent.

The operating rule follows. Never build your agency's AI program so that it collapses if one executive order is rescinded. Anchor the program in the statutes and in the institutionalized memoranda, because those are stickier. The executive order is the weather. The statutes and the durable memoranda are the climate. An agency that built its inventory, its impact assessment process and its governance body as standing capabilities kept all of them through the transition. An agency that built them as an executive order compliance project had to explain to its own staff why the work suddenly had no owner.

The OMB Memoranda: M-24-10 and M-24-18

If the Deputy remembered only two items from the table, Wesley wanted them to be these. OMB M-24-10, Advancing Governance, Innovation, and Risk Management for Agency Use of Artificial Intelligence, is the governance and risk memorandum. It requires each covered agency to designate a Chief AI Officer, to stand up an AI governance body, to maintain and publish an inventory of AI use cases, and to apply minimum risk management practices to AI that is rights-impacting or safety-impacting. Those practices include impact assessments, testing, meaningful human oversight and ongoing monitoring, with real deadlines attached. It also expects risk management aligned to the NIST framework, documented processes for handling AI incidents, and reporting on progress.

OMB M-24-18, Advancing the Responsible Acquisition of Artificial Intelligence in Government, is the acquisition memorandum, and it is the one people misremember. It is not a second governance memo and it does not carry the governance memo's title. It governs how agencies buy AI: managing vendor lock-in, securing rights to performance data and documentation, requiring transparency from vendors about training data and limitations, and protecting against bias entering the agency through a procured system. Wesley framed the relationship plainly for the Deputy: M-24-10 governs the AI you run, and M-24-18 governs the AI you buy. Almost every AI an agency touches is bought rather than built, which is why the acquisition memorandum is the one program managers underestimate most.

One caution about deadlines. Memoranda set specific clocks, and those clocks are revised, extended and superseded more often than briefing decks are updated. Do not carry a remembered number of days into a leadership briefing. Read the current text, write the actual date into your table, and re-check it at each quarterly review. A wrong deadline in a compliance table is worse than no deadline, because people plan against it.

NIST Frameworks: Voluntary and Unavoidable

The National Institute of Standards and Technology AI Risk Management Framework organizes AI risk work into four functions: govern, map, measure and manage. It covers the lifecycle from design through decommissioning. It is voluntary and non-binding on its own terms, and it is referenced by the binding memoranda, which is why a voluntary framework ends up being the practical standard a GAO auditor measures you against. NIST also publishes companion guidance addressing safety testing and evaluation for advanced models, including red-teaming, meaning the deliberate attempt to make a system fail before adversaries or the public do, and guidance on supply chain security that covers vendor assessment, model provenance and model integrity.

Wesley's point for the Deputy: when a memorandum says manage AI risk, NIST is the how. Mapping your systems to the framework, assessing them with its methods and documenting the result is the most efficient path to readiness, because the binding instruments keep pointing back to it. Say it carefully though. Adopting a framework is not the same as managing risk, and an auditor will ask for the measurements, not the adoption memo. The framework tells you which questions to answer. It does not answer them, and it does not certify anybody.

The Chief AI Officer and the CAIO Council

M-24-10 makes the Chief AI Officer a required role: a senior official with authority over the agency's AI governance and direct access to leadership. Across government, these officials meet as an interagency Chief AI Officer Council, which coordinates practice, shares tooling and surfaces common problems so that 24 agencies do not each invent the same impact assessment template from scratch. Wesley told the Deputy that the agency's Chief AI Officer was her single most important AI relationship, because that is the person who owns compliance with everything else on the table, and the Council is where the agency learns what its peers are doing before an auditor asks why it did not.

Be careful with the names of government-wide bodies in this space. Interagency structures for AI have been created, renamed, merged and stood down repeatedly, and briefing decks are full of confidently named boards that no longer exist or never did under that name. Before you put a body in your authorities table, confirm the name and the status against a current source, and note who is responsible for keeping that row true.

The Statutory Lineage

Beneath the memoranda and orders sit statutes that outlast administrations. The AI in Government Act directed governance and workforce groundwork across agencies. The Advancing American AI Act pushed agencies toward responsible adoption, inventories and use case transparency, codifying in law expectations that an executive order alone could only direct temporarily. Congress continues to work in this space, and sector-specific legislation in health, financial services and other regulated areas increasingly carries AI-specific requirements. Track pending legislation in your own domain, and prepare for the scenario that matters most: a new statutory requirement arriving with a short implementation window and no transition relief.

Wesley returned the Deputy's attention here on purpose. These are the instruments that do not evaporate when the White House changes hands. An AI program anchored to statute has a foundation; one anchored only to an executive order is built on sand.

FedRAMP for Cloud and AI Services

Most modern AI reaches an agency as a cloud service. The Federal Risk and Authorization Management Program authorizes cloud services for federal use after a standardized security assessment. The practical rule Wesley gave the Deputy: if an AI tool runs in someone else's cloud, it generally needs an authorization at the right impact level before agency data can touch it, and the authorization applies to the specific service rather than to the vendor as a whole.

State the limits of that gate honestly, because agencies routinely oversell it. Authorization governs whether a service may hold agency data at a given sensitivity. It is a security assessment. It is not a finding that the tool is accurate, unbiased or appropriate for the decision you want to use it for, and it does not, by itself, stop a staffer signing up for a slick commercial tool with a personal card. It gives you the rule that makes that conduct a violation; enforcement still depends on your network controls, your purchase card policy and whether anybody is looking. Treat unauthorized tool use as a monitoring and culture problem as well as a policy one.

FAR, DFARS, and AI Acquisition

The Federal Acquisition Regulation is the rulebook for how the federal government buys anything; the Defense Federal Acquisition Regulation Supplement adds defense-specific rules. AI acquisition rides on top of these. The acquisition memorandum's requirements get operationalized through contract clauses written under that authority: data rights clauses, documentation deliverables, performance standards and the right to test. Wesley's altitude-appropriate message: policy is only as strong as the contract that carries it. If the agency wants the right to audit a vendor's model for bias, that right has to be a clause in the award, not a hope. The contracting officer, not the policy director, is where the obligation becomes enforceable, which means the policy director's real job is to reach the contracting officer before the solicitation closes.

GAO Oversight and Its AI Accountability Framework

The Government Accountability Office audits agencies on behalf of Congress. It does not issue binding rules, but it published an AI accountability framework organized around four principles: governance, data, performance and monitoring. When GAO audits your agency's AI, those are the headings the findings will fall under, and the evidence it will look for is familiar: clear governance structures and accountability chains, documented risk assessments, performance monitoring data and trend analysis, bias and fairness testing evidence, security assessment documentation, audit trails, incident response records, and disclosure mechanisms.

Wesley described GAO to the Deputy as an open-book exam, and then immediately qualified it, because the metaphor flatters agencies into complacency. The headings are published in advance; the questions are not. GAO tests whether your evidence supports your claims for specific systems on specific dates, which is a different exercise from knowing the four principles. Mapping your evidence to the four areas before the auditors arrive is genuinely worth doing, and it is preparation rather than protection. The other reason to read GAO reports is forward-looking: what GAO flags today routinely becomes an OMB requirement two years from now, so its findings are the closest thing the landscape offers to a weather forecast.

Sector Regulators

The government-wide stack is not the whole picture. Sector regulators layer their own AI expectations on top. An agency in health touches the Food and Drug Administration's posture on AI in medical devices; one in finance touches banking-regulator guidance on model risk; one handling employment touches Equal Employment Opportunity Commission attention to automated hiring tools. Wesley's instruction to the Deputy: the horizontal authorities on the table are the floor, and the agency's own sector adds a column. Always ask the program's general counsel whether a sector regulator has said anything about AI in this specific mission area, because that answer changes by mission and by year.

From Authorities to Obligations: The Gap Analysis

Knowing the landscape is not compliance. The bridge between them is a gap analysis, and it runs in five steps that reward being unglamorous about each one.

Extract the specific requirements. Be precise and refuse to generalize. A requirement for impact assessments of high-risk AI systems is not yet actionable. What counts as an impact assessment? Which systems are high risk? What scope and depth are required? Refine it until it reads like an instruction: systems that make or materially inform decisions affecting individual rights, such as benefit eligibility, criminal risk assessment, employment or housing, require a formal assessment; assessments must evaluate accuracy and fairness, security, data quality, transparency, civil liberties and equitable impact; assessments use a standard template; assessments are reviewed by the governance body before deployment; assessments are reviewed annually and whenever the system or its context changes.

Assess where you actually are. For each requirement, record one of four states: compliant with documented evidence, partially compliant where some systems meet it and others do not, non-compliant, or not applicable. Resist the urge to record intent as status.

Document each gap. What is missing, why it is missing, whether the cause is resources, expertise, system limitations or unclear requirements, what the consequence of leaving it is in audit risk, public trust or operational vulnerability, and what fixing it would cost in staff, tools, time and disruption.

Plan the remediation. Specific and measurable action, a named accountable person rather than a role, a realistic timeline that accounts for dependencies, the resources required, how completion will be verified, and the risk if the date slips.

Prioritize, because you cannot fix everything at once. Rank by regulatory risk, operational risk, how many people are affected if something goes wrong, feasibility with the resources you actually have, and dependencies between items. A prioritized list of ten real gaps beats a complete list of sixty that nobody works.

Keeping the Map Current

The Deputy's last question was the right one: how do we keep this table true when all of it keeps moving? Wesley's answer was a standing process, not a one-time briefing. Name a person responsible for monitoring regulatory change, and give them the sources: the Federal Register, White House publications, OMB, NIST, GAO reports, congressional activity in your domain, and the faster but unofficial channels of professional associations and legal updates. Court decisions matter too, and they arrive without a press release. Your own general counsel is the source that converts all of it into an interpretation your agency can act on.

Then run a written rule for each new instrument, so the response does not depend on who happens to read it first. Determine whether it binds the agency and with what force. Extract the specific requirements. Identify which systems are affected and the scope of work. Set the deadline from the current text. Brief the governance body. Assign remediation with an owner and a verification step. Review the whole table quarterly. When EO 14110 was rescinded, agencies running this process updated one row and carried on, because their obligations were traced to instruments rather than to a mood.

Interpreting Ambiguity Without Guessing

Much of this landscape is genuinely underspecified, and pretending otherwise helps nobody. Four practices make ambiguity manageable. The first, and the one worth carrying exactly as it is usually stated: when in doubt, interpret requirements broadly and implement toward the protective end. If guidance requires impact assessments for high-risk systems, err toward assessing more systems rather than fewer. If a framework recommends red-teaming, do not wait for it to be mandated. You are unlikely to be criticized for exceeding a requirement.

The second is to document your reasoning whenever you interpret an ambiguous requirement, because the audit question is not only what you did but why you believed it was sufficient. The third is not to guess: OMB and NIST staff do provide guidance to agencies, peers face the same question, and your general counsel can seek a formal interpretation. The fourth is structural, which is to build governance as modular processes that can absorb a changed interpretation without a reorganization.

Hold the first practice alongside a real tension rather than pretending it away. Interpreting everything at maximum strictness has a cost, and that cost is not only speed. A process so heavy that a low-risk classification model takes months to deploy teaches business units to route around governance entirely, which leaves you with less oversight than a proportionate process would have delivered. The resolution is not to be less protective. It is to be proportionate by risk tier: strict interpretation where rights are affected, lightweight and fast where they are not, and a documented basis for placing each system in its tier.

Turning the Landscape Into an Agency Framework

Federal requirements set the floor; your agency's own framework is what people actually follow. A workable one covers five things. Governance structure: the Chief AI Officer's authority, reporting line, staffing and budget, the governance body's composition, decision rights, meeting rhythm and escalation path, and how individual bureaus participate rather than merely comply. Principles: the values that guide AI use, how each translates into a requirement, and, most usefully, how conflicts between them are resolved when they collide in a real decision.

Then the operational three. Processes: how new initiatives are evaluated and approved, how high-risk systems are assessed, what happens when an issue is escalated, how often systems are reviewed, and how incidents are reported and handled. Risk management: an assessment method aligned to the NIST framework, a stated risk appetite that says what the agency will and will not accept, defined responses of mitigate, accept, transfer or avoid, and risk reporting that reaches the governance body in a form it can act on. Transparency and accountability: how citizens know they are interacting with an AI system, what is disclosed, how an affected person appeals or challenges a decision, and what documentation is published.

The Artifact: Federal AI Authorities Map and Obligations Checklist

Here is the table Wesley put in front of the Deputy. It is the deliverable a policy director can hand to leadership, to a Chief AI Officer, or to a contracting officer, and it answers in one view what binds the agency and what the agency owes. Treat every row as perishable: each one carries a date, an owner and a source you can re-check.

The Deputy kept the table. Three weeks later, when a program office proposed a commercial AI screening tool, her first email back was a single question Wesley had taught her to ask: which rows does this touch? The answer, the cloud authorization row, the acquisition memorandum and the governance memorandum, told her exactly which three people needed to be in the room before she could say yes. That is what the artifact buys: not memorized law, but the right question at the right moment.

Anti-Patterns to Avoid

Waiting for clarity before building governance. The reasoning sounds prudent: requirements are still evolving, so why build to a moving target? By the time requirements are clear you are years behind, you have deployed systems with no governance, and retrofitting compliance into live operations is expensive and disruptive. Auditors will also ask why you did not start. Build now, build for flexibility, and let the processes evolve as requirements sharpen.

Checkbox compliance. Treating requirements as boxes rather than principles produces impact assessments completed by junior staff from a template, asserting fairness that was never tested. Reviewers can tell the difference, and checkbox compliance fails audits. More importantly it fails the actual objective, which is trustworthy systems. Ask what problem each requirement exists to solve and build for that.

Uniform maximum strictness. Reading one memorandum as requiring full assessment of every system, including pilots and prototypes that touch no individual rights, makes deployment take months and teaches business units to go around the process. That leaves you with less oversight, not more. Be strict where rights are affected and proportionate everywhere else, with the tiering documented.

Compliance as somebody else's department. When the legal or compliance office owns AI compliance alone and the development, operations and data teams are not involved, compliance becomes a drag rather than a property of the system. Developers improvise answers to questions they do not understand, documentation becomes inaccurate, and the agency ends up with two tracks: business as usual, which ignores governance, and formal AI, which everyone avoids. Embed the expertise, train the builders, and make compliance a shared responsibility with real oversight.

Mistaking the authorities table for the compliance record. A mapped row says you know an instrument applies. It is not evidence that you met it for a given system on a given date. The table routes the question to the right people; the evidence still has to exist underneath it.

Treating an authorization as a fitness assessment. A cloud authorization means a service may hold agency data at a stated sensitivity. It is silent on whether the model is accurate, fair or appropriate for the decision. Programs that read an authorization as a green light skip the assessment that would have caught the real problem.

Practice Prompts

1. Map three systems to the table. Take a predictive maintenance model for field equipment, a conversational system answering public inquiries about benefits eligibility, and a fraud detection system that flags applications for human review. For each, identify which rows of the authorities table apply, the specific requirements that follow, your current compliance status, and the top three gaps with a remediation plan for each.

2. Absorb a new statutory deadline. Assume Congress requires equity impact assessments for all AI systems affecting individual rights, with a twelve month implementation deadline, and your agency operates 47 AI systems. Decide how you prioritize which systems are assessed first, design the assessment process, allocate the resources to meet the date, and define the process for systems deployed after the deadline.

3. Interpret an ambiguous transparency requirement. Guidance requires that AI systems be transparent to affected parties. Your agency runs a predictive model used internally by eligibility processors; the public never interacts with it, but its outputs influence eligibility decisions. Decide whether affected parties includes those indirect beneficiaries, define what disclosure would be adequate, design a mechanism that is transparent without exposing exploitable model detail, and write down your reasoning as you would for an auditor.

4. Design the monitoring process. Build an end-to-end compliance monitoring process that tracks new guidance from multiple sources, assesses its impact on current operations, updates your remediation plans, communicates changes to stakeholders, and verifies that compliance activities were actually completed. Specify roles, responsibilities, timeline, communication mechanisms and documentation requirements.

5. Draft the agency framework. Outline an AI governance framework for your agency that aligns with the currently binding memoranda and the NIST framework, reflects your mission and risk profile, establishes clear roles and responsibilities, defines processes for evaluation, deployment and monitoring, and creates mechanisms for transparency and accountability.

Reflection

What is your agency's current AI governance structure, and if there is not one, what is actually blocking it? Which of your AI systems are rights-impacting or safety-impacting, and would a stranger reading your inventory reach the same classification you did? Where is the widest gap between federal requirements and your current position, and who owns closing it? How are you monitoring regulatory change today, and would you find out about a new memorandum from your own process or from a reporter's question? If a significant new requirement arrived tomorrow, walk through what would happen in the first week, and notice how much of it depends on one person remembering.

Glossary

• Executive order. A directive issued by the President to federal agencies, binding within the executive branch until revoked or superseded, and capable of being overridden by legislation.
• Office of Management and Budget. The executive office component that manages the federal budget, oversees agency operations and issues memoranda establishing requirements federal agencies must follow.
• Chief AI Officer. The senior official responsible for AI governance within an agency, with authority over AI policy, risk management and innovation, and direct access to agency leadership.
• NIST AI Risk Management Framework. A voluntary framework from the National Institute of Standards and Technology for managing AI risk across the lifecycle, organized around govern, map, measure and manage.
• Impact assessment. A formal evaluation of how an AI system affects the people subject to it, covering accuracy, fairness, security, transparency and civil liberties. Required for rights-impacting and safety-impacting systems by the binding OMB governance memorandum.
• Red-teaming. Structured adversarial testing in which an independent team deliberately attempts to make a system fail, produce harmful output or reveal vulnerabilities, before adversaries or the public do.
• Rights-impacting AI. A system whose outputs materially affect civil rights, civil liberties or individual entitlements, including decisions about benefits eligibility, criminal risk, employment, housing and immigration status.
• Government Accountability Office. The independent legislative branch agency that audits and evaluates federal agencies, and whose findings shape what later becomes formal requirement.

Related Lessons

This lesson is the map; several others are the territory. Government AI Policy Landscape is the introductory treatment for readers who need the concepts before the instruments. OMB M-24-10 Deep Dive: Full Implementation and OMB M-24-18 and AI Procurement Governance unpack the two memoranda at implementation depth, and AI Use Case Inventory and Documentation (OMB M-24-10) covers the inventory obligation in detail. Federal Acquisition of AI: FAR/DFARS and FedRAMP and AI Cloud Authorization cover the acquisition and authorization gates. GAO AI Accountability: Four Principles in Practice takes the oversight framework further, Risk Classification: Safety-Impacting vs. Rights-Impacting is the classification decision the memoranda turn on, and Drafting Agency AI Policies and State and Local Government AI Policy extend the work into your own framework and into other levels of government.

Closing

The federal AI landscape is not a fixed set of rules and it will not become one. It is a dynamic set of overlapping instruments issued by different authorities with different binding force, and the correct response is not to memorize it but to build governance that absorbs change without collapsing. Sort by binding force so you know what survives a transition. Trace each obligation to an instrument you can re-read. Assign a person to watch the sources and a quarterly rhythm to update the table. Document your interpretations so a future auditor can follow your reasoning. Wesley's ninety minutes were never about teaching a Deputy Administrator the law. They were about leaving her with one durable question she would ask before approving anything, and a table good enough to answer it.

Key Takeaways

• Sort authorities by binding force, hardest first. Statutes outlast executive orders; OMB memoranda translate both into deadlines; frameworks are voluntary but referenced; oversight standards become tomorrow's rules. When instruments conflict, the harder one wins.
• An executive order is weather; statutes are climate. EO 14110 shaped the current architecture and has since been rescinded, which is exactly why a program must never depend on one. Anchor the durable core in the AI in Government Act and the Advancing American AI Act.
• M-24-10 governs the AI you run; M-24-18 governs the AI you buy. They are different memoranda with different titles and different triggers, and because almost all agency AI is procured, the acquisition memorandum is the one program managers most underestimate.
• NIST tells you how, and adopting it is not the same as doing it. The framework is voluntary and non-binding, the binding memoranda point to it, and an auditor will ask for your measurements rather than your adoption memo.
• Policy is only as strong as the contract that carries it. Rights to audit, test and access data must appear as clauses in the award, not as expectations. The contracting officer is where the obligation becomes enforceable.
• Cloud authorization is a data-placement gate, not a fitness assessment. Verify authorization for the specific service at the right impact level, and never read it as evidence that a model is accurate, fair or appropriate for the decision.
• GAO publishes the headings, not the questions. Pre-map evidence to the four accountability principles, keep it current per system, and read GAO reports as an early indicator of the requirements coming next.
• Keep a living authorities table, not a memorized landscape. A named monitor, a written intake rule for each new instrument, dated rows with owners, and a quarterly review mean that when an administration rewrites the landscape you update rows instead of rebuilding the program.

Frequently Asked Questions

EO 14110 was rescinded. Does that mean the requirements built under it went away? Not generally, and this is the most useful thing to understand about the stack. The executive order directed, but much of the operational obligation lives in OMB memoranda and in statute, which do not disappear when an order does. What changes is the framing, the emphasis and sometimes the deadlines. The practical response is the same either way: re-derive your obligations from the currently binding instruments, update the affected rows of your table, and keep the capabilities you built, because the next instrument will almost certainly want them too.

How do I keep from teaching leadership a memo number or deadline that has since changed? Put a source and a date on every row of the table and re-check them on a schedule. Never quote a number of days from memory or from an old briefing deck, and be especially careful with the names of interagency bodies, which get created, renamed and stood down more often than the instruments themselves. If you cannot confirm a name or a date against a current source before the briefing, say what you know and flag what you are checking. A policy director who says "I will confirm that by Friday" keeps credibility; one who states a wrong deadline loses it permanently.

Should we interpret ambiguous requirements strictly or proportionately? Both, in different places. Where a system affects individual rights, interpret broadly and implement toward the protective end; you will not be criticized for exceeding a requirement, and the risk of under-protecting is borne by the public. Where a system affects no individual rights, a heavy process buys nothing and drives teams around governance entirely. What makes this defensible rather than arbitrary is the tiering: a written basis for placing each system in a tier, and documented reasoning for the interpretation you applied.

Who actually owns compliance with all of this? The Chief AI Officer owns it in the formal sense, but ownership that sits with one office produces paper rather than practice. The workable pattern is shared: the officer and the governance body set the requirements and hold the record, the program and technical teams own compliance for the systems they build and run, the contracting officer carries the requirements into the award, and general counsel resolves interpretation. The policy director's role is to make sure those four groups are looking at the same table.

How much of this applies to a state or local agency? The specific federal instruments generally bind federal agencies, but they travel: state programs administering federal funds often inherit obligations through their grant terms, and state legislatures and procurement offices have been adopting similar structures, frequently borrowing the NIST framework directly because it is voluntary, public and free to use. Build the same table with your own rows, and check your grant agreements carefully, because that is where a federal requirement most often becomes a state obligation without anybody announcing it.