Current AI policy

Turn AI policy into controls without treating different jurisdictions as one rulebook.

The safest implementation model starts by separating binding law, government-specific policy, voluntary risk guidance, contract requirements, and internal policy. The EU AI Act and U.S. federal AI memoranda can both shape an AI program, but they do not impose the same duties on the same organizations.

Substantively reviewed . This revision removes revoked Executive Order 14110 and superseded OMB M-24-10 as current operating authorities, incorporates OMB M-25-21/M-25-22 and scope-specific M-26-04 guidance, and reflects the 2026 amendment to the EU AI Act.

Policy baseline

Build a source hierarchy before building a compliance checklist.

Do not label every AI governance practice a legal requirement. Record the authority, jurisdiction, covered organization, covered system or use case, effective date, current status, evidence owner, and review trigger for each requirement. A regulation, an OMB memorandum for federal agencies, a voluntary NIST framework, a customer contract, and an internal policy can all matter operationally while having different legal force.

For a multinational organization, maintain separate applicability records for provider, deployer, importer, distributor, government-agency, contractor, and ordinary private-sector roles. The same AI capability can create different duties when it is sold into the EU, deployed by a U.S. federal agency, embedded in a regulated product, or used internally for a low-impact workflow.

This guide is an implementation aid, not legal advice. Confirm jurisdiction- and sector-specific duties with qualified counsel and the current primary authority before making a consequential compliance decision.

European Union

Use the amended AI Act timeline, not the original rollout schedule.

Regulation (EU) 2024/1689 remains the core EU AI Act, but Regulation (EU) 2026/1744 changed important implementation dates and other provisions. The general application date remains August 2, 2026. The amended Article 113 moves the Chapter III Sections 1–3 high-risk requirements to December 2, 2027 for systems classified under Article 6(2) and Annex III, and to August 2, 2028 for systems classified under Article 6(1) and Annex I.

AreaCurrent operating dateImplementation focus
Chapters I–IIApplied from February 2, 2025, subject to the 2026 amendment's specified exceptionsDefinitions, scope, prohibited-practice and literacy-related controls should be mapped to current consolidated text.
General applicationAugust 2, 2026Do not assume this date means every high-risk obligation began at once.
Annex III high-risk systemsDecember 2, 2027Prepare classification, risk management, documentation, records, transparency, oversight, accuracy, robustness, and quality-system evidence against the final applicable text.
Annex I high-risk systemsAugust 2, 2028Coordinate AI Act controls with the applicable Union product-safety regime and conformity pathway.

Do not classify a system from a marketing label such as “high risk.” Preserve the facts supporting the Article 6 analysis: intended purpose, deployment context, affected people, product role, Annex category, exceptions, and reviewer. Revisit classification when intended purpose, model, data, integration, or deployment changes materially.

United States federal

Separate federal agency policy from general private-sector law.

Executive Order 14110 is no longer the current presidential AI policy baseline, and OMB M-24-10 is no longer the current federal agency governance memorandum. OMB issued M-25-21 and M-25-22 on April 3, 2025. M-25-21 governs covered federal agencies' development, use, and acquisition of AI and uses a “high-impact AI” category for heightened safeguards. M-25-22 addresses federal AI acquisition, including competition, requirements, documentation, lifecycle change, government data, portability, and vendor lock-in.

For covered federal agency use and procurement of large language models, OMB M-26-04 adds scope-specific implementation guidance around the Unbiased AI Principles, human accountability, vendor information, and contractual disclosures. Treat it as an additional applicable federal agency requirement where its scope is met—not as a general private-sector AI law.

Those memoranda do not create a general AI compliance code for every U.S. private company. A private-sector organization should map the laws, regulations, contractual duties, procurement terms, consumer-protection rules, privacy obligations, sector requirements, and state requirements that actually apply to its use case. Vendors selling to federal agencies may nevertheless need evidence that enables agency compliance with M-25-21, M-25-22, and other applicable federal requirements.

The White House's 2025 America's AI Action Plan sets broader federal policy direction. Treat such policy documents as current government strategy and implementation context—not as a substitute for identifying the legal or contractual authority that binds a particular organization.

NIST AI RMF 1.0 remains a voluntary risk-management framework, and NIST states that it is being revised as part of the AI Action Plan. Use the current final framework and the Generative AI Profile as risk-management resources while tracking the revision; do not present a draft or forthcoming revision as the final standard.

Applicability inventory

Make the inventory capable of answering “which rule applies to this system?”

At minimum, record the system owner, business purpose, provider and model, version, deployment environment, users, affected population, data categories, connected tools, jurisdictions, supplier, acquisition path, role under applicable law, risk classification, human decision point, monitoring owner, incident owner, and last substantive review.

Keep legal applicability separate from internal risk rating. A system can be operationally high risk without being an EU AI Act high-risk system, and an EU-classified high-risk system can still require additional sector controls. Likewise, the M-25-21 “high-impact AI” category is a federal agency policy concept and should not be silently reused as a universal enterprise classification.

Connect the inventory to the AI Governance Implementation Guide for ownership and change control and to the AI Model Evaluation Operations Guide for evidence that supports a deployment decision.

Control design

Translate each applicable requirement into an owner, evidence source, failure condition, and trigger.

For each material obligation, document what must be true, who makes it true, what proves it, when the evidence is created, how long it is preserved, what constitutes failure, who can accept an exception, and what change forces reassessment. This creates an auditable decision trail without pretending one control library can replace the underlying authority.

Before deployment

Applicability, intended purpose, data boundary, evaluation, security, human oversight, supplier evidence, documentation, user notice, and approval conditions.

During operation

Performance and risk monitoring, complaints, overrides, incidents, access, logs, supplier notices, model/version drift, and material-use changes.

At change or exit

Reclassification, renewed evaluation, approval changes, record preservation, migration, portability, decommissioning, and supplier offboarding.

Training cadence, committee frequency, evaluation thresholds, and risk-acceptance limits should be framed as organization-specific controls unless a cited authority actually sets the value.

Procurement and suppliers

Require evidence that survives the sales cycle.

Ask suppliers to distinguish current capability, configurable behavior, customization, roadmap, partner dependency, and unsupported assertion. For material AI acquisitions, preserve the proposed use, model/service identity, data terms, security boundary, evaluation evidence, documentation rights, incident and change notice, audit/logging capability, IP terms, portability, pricing dependencies, termination assistance, and evidence-retention commitments.

M-25-22 is especially useful for federal buyers because it explicitly addresses lifecycle change and vendor lock-in. Outside federal acquisition, those same topics can still be good procurement practice, but label them as buyer requirements rather than federal mandates.

Monitoring and change

Treat policy freshness as a control.

AI policy changes faster than many internal policy-review calendars. Set explicit triggers for authority changes, model/provider changes, new jurisdictions, material feature changes, new affected populations, incidents, enforcement actions, contract renewal, or a change in intended purpose. High-volatility government-policy pages should receive short review windows even when the implementation mechanics remain durable.

Do not use one global incident deadline. Operational teams should contain and preserve evidence immediately, then determine legal and contractual reporting based on jurisdiction, role, incident type, affected system, and applicable authority. The AI Incident Response Guide separates that operational path from jurisdiction-specific reporting duties.

A mature policy program can answer three questions quickly: what authority applied when the decision was made, what evidence supported the decision, and what changed enough to require the decision to be revisited.

Put this guide to work

Turn AI Policy Implementation Guide: EU AI Act & U.S. Federal Governance into a decision-ready next step.

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.