US AI Executive Orders, in depth: how presidential orders reach your AI system through OMB memos and contract clauses, and how to track them in code

What an executive order can and cannot do

An executive order is the President directing the executive branch. It can tell agencies how to run their own operations, what to buy and on what terms, what to prioritise in enforcement, and which rules to start writing under authority Congress already gave them. It cannot create new duties for private parties on its own, and it cannot override a state statute. A later order can revoke an earlier one on the day it is signed, with no notice period.

Three consequences follow. If you neither sell to nor receive money from the federal government, most orders create no direct duty for you. The date that matters is usually that of a downstream instrument, such as an OMB deadline or a solicitation, not the signing date. And everything is revocable, so build evidence that serves more than one rule.

The orders and instruments, in date order

Two of these do almost all the work for an engineering team: the OMB memoranda, because they turn orders into deadlines and contract terms, and EO 14365, because it is the federal government's attempt to change which state laws you must follow. The rest mostly direct federal spending, permitting and research, which matter to you as opportunities rather than obligations.

Four paths from order to obligation

Agency-use guidance binds agencies, who push its requirements onto vendors. Acquisition guidance becomes clauses that bind you when you sign. The state-law path binds nobody until a court rules or a lawful federal rule preempts. Voluntary programmes bind you only if you join.

Path one: agencies using AI

OMB M-25-21 implements EO 14179 for agency use. Each covered agency must have a Chief AI Officer, publish an AI strategy (due 30 September 2025), keep a public inventory of AI use cases, and issue its own AI policies (due 29 December 2025). For uses it classes as high-impact, the agency must apply minimum practices: pre-deployment testing under realistic conditions, an AI impact assessment, ongoing monitoring for adverse effects, training for the staff who rely on the system, human oversight and fail-safes, and an appeal route for people affected by an AI-influenced decision.

None of those duties names a vendor, yet each needs vendor help: a test environment, logs and metrics for monitoring, and enough traceability to reconstruct why an output was produced when someone appeals. If you sell into a high-impact use, expect your contract to ask for exactly those artefacts, and build them first.

Path two: agencies buying language models

OMB M-25-22 governs AI acquisition, and OMB M-26-04 adds the requirements of EO 14319, Preventing Woke AI in the Federal Government. The order sets two Unbiased AI Principles for LLMs procured by agencies. Truth-seeking: answer factual questions truthfully, prioritising historical accuracy, scientific inquiry and objectivity, and acknowledge uncertainty. Ideological neutrality: act as a nonpartisan tool and do not encode partisan or ideological judgements unless the user prompts for them or they are readily accessible to the user. If a vendor fails to comply after a reasonable cure period, decommissioning costs are charged to the vendor; compliance can be shown through disclosures such as system prompts and specifications rather than model weights.

M-26-04 turns this into a package. The minimum set is an acceptable use policy; a model, system or data card summarising training, risks and mitigations, and evaluation scores; end-user guides; and a feedback channel for problematic outputs. Agencies may also request enhanced transparency: training details including guidelines for responding to queries, safety filters, red-teaming and bias evaluations, benchmark results and third-party modifications. Agencies had to update procurement policies by 11 March 2026, and should, where practicable, amend existing LLM contracts before exercising options. The memo expires on 11 December 2027.

Path three: pressure on state laws

EO 14365, Ensuring a National Policy Framework for Artificial Intelligence, directs the Attorney General to set up an AI Litigation Task Force within 30 days to challenge state AI laws, and the Secretary of Commerce to publish within 90 days an evaluation naming state laws it considers onerous, particularly ones said to compel changes to truthful outputs. It ties remaining Broadband Equity, Access and Deployment (BEAD) funds to that list, asks the FCC to consider a federal reporting and disclosure standard, and asks the FTC for a policy statement on how the ban on deceptive practices applies to AI outputs.

By itself this path changes nothing. Law-firm reporting in March and April 2026 said the Commerce evaluation and BEAD notice had not appeared, and stressed that the order cannot overrule a state statute; check the current position. Keep every state obligation live in your register until a court or a lawful federal rule says otherwise, and record that citation when you retire one.

Path four: security and voluntary programmes

The order of 2 June 2026, Promoting Advanced Artificial Intelligence Innovation and Security, is mostly about cyber defence. According to the White House fact sheet, it creates an AI cybersecurity clearinghouse in voluntary coordination with industry, a classified benchmarking process to identify frontier models with advanced cyber capabilities, and a voluntary framework for secure early access to such models by trusted partners, and it states that it authorises no mandatory licensing or pre-clearance of models. Joining is a business decision; once signed, the terms bind like any contract.

Worked example: an LLM summariser sold to an agency

A vendor sells a summarisation service, built on a third-party model with its own system prompt and retrieval layer, to a benefits agency that will use summaries to prioritise case files. That affects access to benefits, so the agency treats it as high-impact.

Walk the paths. Path two applies directly: the solicitation post-dates M-26-04, so the contract requires the minimum package, and the agency also requests the enhanced items on system prompt policy, safety filters and bias evaluations. Path one applies indirectly: the agency needs a test report, monitoring hooks, a human override and enough traceability to answer appeals. Path three changes nothing: a state automated-decision law stays in the register. Path four does not apply.

The hard case is the model card. The upstream card describes the base model, not the deployed system. The vendor must write a system card for what it ships, cite the upstream card and keep version identifiers aligned, which is the first thing the validator below checks.

The register and the validator, in code

Keep orders and memos as data. Each instrument records what it binds, what it implements and whether it is revoked or expired; each obligation names its source and a predicate over your product profile. An obligation is live only if its whole chain is live, so revoking a parent switches off every memo built on it.

from dataclasses import dataclass, field
from datetime import date

@dataclass
class Instrument:
    id: str                       # "EO 14179", "OMB M-26-04"
    issued: date
    binds: str                    # "agencies", "contractors-via-clause", "voluntary"
    implements: list = field(default_factory=list)
    revoked_by: str | None = None
    expires: date | None = None

@dataclass
class Obligation:
    id: str
    source: str                   # Instrument.id
    applies_if: callable          # profile -> bool
    evidence: list                # artifacts a reviewer will ask for
    due: date | None = None

REGISTER = {
    "EO 14110": Instrument("EO 14110", date(2023, 10, 30), "agencies", revoked_by="EO 14148"),
    "EO 14179": Instrument("EO 14179", date(2025, 1, 23), "agencies"),
    "OMB M-25-21": Instrument("OMB M-25-21", date(2025, 4, 3), "agencies", ["EO 14179"]),
    "OMB M-25-22": Instrument("OMB M-25-22", date(2025, 4, 3), "contractors-via-clause", ["EO 14179"]),
    "EO 14319": Instrument("EO 14319", date(2025, 7, 23), "agencies"),
    "OMB M-26-04": Instrument("OMB M-26-04", date(2025, 12, 11), "contractors-via-clause",
                              ["EO 14319"], expires=date(2027, 12, 11)),
}

OBLIGATIONS = [
    Obligation("unbiased-ai-minimum-transparency", "OMB M-26-04",
               lambda pr: pr["sells_to_federal"] and pr["product_is_llm"],
               ["acceptable_use_policy", "model_card", "end_user_resources", "feedback_channel"]),
    Obligation("high-impact-practices-support", "OMB M-25-21",
               lambda pr: pr["sells_to_federal"] and pr["agency_use_high_impact"],
               ["pre_deployment_test_report", "impact_assessment_inputs", "monitoring_hooks",
                "human_override_path", "appeal_support"]),
]

def live(instr_id, today):
    i = REGISTER[instr_id]
    if i.revoked_by or (i.expires and today > i.expires):
        return False
    return all(live(parent, today) for parent in i.implements)

def obligations_for(profile, today):
    return [o for o in OBLIGATIONS if live(o.source, today) and o.applies_if(profile)]

Then check the evidence before a contracting officer does. The validator below enforces the M-26-04 minimum set and, when requested, the enhanced items, and it fails any artefact that describes a model version other than the one deployed. Run it in CI on every model, prompt or retrieval change, because those are exactly the changes that make a submitted card stale.

REQUIRED = {
    "acceptable_use_policy": ["permitted_uses", "prohibited_uses"],
    "model_card": ["training_summary", "risks_and_mitigations", "evaluation_scores"],
    "end_user_resources": ["guides"],
    "feedback_channel": ["contact"],
}
ENHANCED = ["system_prompt_policy", "safety_filters", "red_team_results",
            "bias_evaluations", "third_party_modifications"]

def check_package(pkg: dict, enhanced_requested: bool = False) -> list[str]:
    problems = []
    for artifact, fields in REQUIRED.items():
        doc = pkg.get(artifact)
        if not doc:
            problems.append(f"missing {artifact}")
            continue
        problems += [f"{artifact}.{f} empty" for f in fields if not doc.get(f)]
        if doc.get("model_version") != pkg["model_version"]:
            problems.append(f"{artifact} describes {doc.get('model_version')}, "
                            f"deployed is {pkg['model_version']}")
    if enhanced_requested:
        problems += [f"enhanced: missing {a}" for a in ENHANCED if a not in pkg]
    return problems

Building evidence that survives the next order

Generate the system card from your evaluation pipeline, so its scores belong to the build you ship. Version system prompts like code, since enhanced transparency can ask for them. Route the feedback channel into the incident queue and measure time to triage.

For truth-seeking and neutrality, build evaluations you can defend to any reviewer: factual question sets with known answers; paired prompts that differ only in which side of a contested issue they name, scored for symmetric treatment; and checks that the model flags incomplete evidence. Keep the raw outputs. The red-teaming guide covers how to run adversarial probes and record them, and the same records serve the bias evaluations M-26-04 lets agencies request.

Failure modes

The common thread is dating: every claim in your evidence should carry the version and date it describes. The audit preparation guide shows how to keep it ready.

Trade-offs

Orders get undone, and those of 2023 and 2025 point in different directions. The defensible path is evidence every regime asks for: tests, monitoring, system cards, prompt versioning, traceable decisions and a working feedback loop, which also cover much of the EU AI Act. Spend instrument-specific effort only where a contract or court makes it binding.

What to do next

1. List every federal contract, grant and solicitation you hold or are bidding for, with issue dates, since those decide which memo terms apply.
2. Load the instruments above into a register with issued, revoked_by, implements and expires fields, alongside your state obligations.
3. Generate a system card for each deployed LLM product from your evaluation pipeline, pinned to model, prompt and retrieval versions.
4. Assemble the M-26-04 minimum package now, and decide which enhanced items you could release.
5. Add the package validator to CI so stale evidence fails the build.
6. Re-check EO 14365 implementation and the M-26-04 expiry date periodically, and update the register.