On January 20, 2025, hours after taking office, President Trump revoked Executive Order 14110 — the Biden administration's "Safe, Secure, and Trustworthy Development and Use of Artificial Intelligence" order, signed October 30, 2023, which had required dual-use foundation model developers to report training runs and safety test results to the federal government under the Defense Production Act. Three days later, a replacement order, "Removing Barriers to American Leadership in Artificial Intelligence," directed agencies to review and rescind any actions taken under the revoked order and produce a new AI Action Plan within 180 days. For compliance teams who spent 2024 building processes around EO 14110's reporting thresholds, the mandate evaporated overnight. But not every AI-adjacent obligation moved with it: EO 14028, the 2021 order that created the modern SBOM requirement, was untouched by any of this, and the EU AI Act's general-purpose AI (GPAI) obligations became applicable on schedule on August 2, 2025. The result is a compliance landscape that looks deregulated at the federal executive level but is actually converging, across every jurisdiction that still has teeth, on the same demand: prove where your models and code came from. This piece walks through what changed, what didn't, and what enterprise security teams should actually be building toward.
What did revoking EO 14110 actually remove?
Revoking EO 14110 removed a federal reporting requirement, not a security obligation your engineering team was directly executing. The order's most consequential provision used the Defense Production Act to compel companies training frontier models above a compute threshold to report training runs and red-team results to the Commerce Department, and it directed NIST to publish red-teaming guidance for dual-use foundation models. Almost none of that applied to a typical enterprise building software with third-party AI APIs — it targeted foundation-model labs like OpenAI, Anthropic, and Google DeepMind. The January 23, 2025 replacement order reframed the federal posture around removing "barriers to American AI leadership," and instructed agencies to identify and rescind EO 14110-derived policies within 60 days. For most enterprises, the practical effect is that there is currently no binding federal executive-level mandate requiring AI safety testing disclosure — that gap is now filled unevenly by state law (notably Colorado's AI Act and California's SB 53) and sector regulators like the FDA and financial supervisors, not by a single federal order.
Which AI-related obligations survived the political shift?
The obligations tied to EO 14028 — the May 2021 order on "Improving the Nation's Cybersecurity" — survived entirely, because it was never an AI-specific order and nothing revoked it. EO 14028 requires federal software vendors to produce a Software Bill of Materials meeting NTIA's minimum elements, attest to practices under NIST's Secure Software Development Framework (SP 800-218), and disclose vulnerabilities. Those requirements apply just as much to a vendor shipping an LLM-wrapped feature as to one shipping a traditional web app, since SSDF attestation covers the development process, not the presence of a model. NIST's AI Risk Management Framework (AI RMF 1.0, published January 2023) and ISO/IEC 42001 (the AI management system standard, published December 2023) also remain fully in force as voluntary frameworks — and procurement teams and cyber insurers increasingly cite both as baseline expectations in contracts, independent of whatever the current administration's executive orders say about AI safety reporting.
What is actually changing under the EU AI Act right now?
The EU AI Act's obligations are landing on a real, moving timeline that enterprise teams selling into Europe need to track closely. GPAI model provider obligations — documentation, copyright-compliance summaries, and systemic-risk assessment for the largest models — became legally applicable on August 2, 2025. High-risk AI system obligations under Annex III, covering use cases like hiring, credit scoring, and biometric identification, were originally due August 2, 2026, but the Digital Omnibus package, which reached provisional political agreement on May 7, 2026, pushed standalone Annex III high-risk obligations out to December 2, 2027. High-risk AI embedded inside already-regulated products, like medical devices or industrial machinery, was originally due August 2, 2027, but the same Digital Omnibus agreement pushed that deadline to August 2, 2028, since it rides on existing product-safety conformity processes that needed their own alignment work. Enforcement powers for GPAI obligations still activate August 2, 2026, meaning the compliance clock for large model providers hasn't actually loosened — only the deadline for narrower high-risk deployments has.
Why do provenance and evidence keep showing up as the common thread?
Provenance and evidence keep showing up because every surviving framework — EU AI Act, NIST SSDF, NIST AI RMF, ISO/IEC 42001 — asks a version of the same question: can you produce a documented, traceable record of what went into this system and how it was tested? The EU AI Act's GPAI obligations require documentation of training data sources and a copyright-compliance summary. SSDF attestation under EO 14028 requires evidence that a secure development process, not just a secure end product, was followed. NIST AI RMF's "Map" and "Measure" functions expect a documented model inventory with declared risk characteristics. None of these frameworks care whether the enabling law is a Biden-era EO, a Trump-era EO, or an EU regulation — they all converge on the same underlying artifacts: a bill of materials for code, a bill of materials for models, and a signed, checkable chain of custody connecting training data to deployed weights.
What should enterprise security teams actually prioritize?
Enterprise security teams should prioritize building the evidence pipeline once, rather than reacting separately to each jurisdiction's paperwork, because the underlying artifacts overlap almost completely. A CycloneDX or SPDX SBOM produced for EO 14028 procurement compliance is largely the same object an auditor wants to see for ISO/IEC 42001 dependency tracking. A model-weight provenance record — hash, source registry, signing status — built to satisfy an internal AI governance policy is the same record the EU AI Act's documentation requirements ask for when a model is embedded in a product sold into the EU. Teams that treat each regulation as a bespoke checklist end up rebuilding the same evidence three or four times; teams that build a continuously-updated inventory of code dependencies and model artifacts can answer nearly any framework's evidence request by querying it, rather than starting a new audit project every time a deadline shifts.
How Safeguard Helps
Safeguard maps evidence to regulatory frameworks continuously rather than as a point-in-time audit exercise, which matters when the underlying orders themselves keep shifting. It generates and validates SBOMs against NTIA minimum elements and scores SSDF practice-level attestation for EO 14028, and it extends the same model to AI-specific obligations: an AI-BOM — emitted in CycloneDX ML-BOM extension format and the SPDX 3.0 AI profile — that captures model identity, weight provenance and hashes, signing status, fine-tune lineage, and training-data licensing for every model connected through Hugging Face, MLflow, SageMaker, Vertex AI, or a custom registry. That AI-BOM record is the same evidence Safeguard's compliance mapping references for EU AI Act model-provenance requirements, NIST AI RMF risk-profile mapping, and ISO/IEC 42001 control evidence — so when a deadline moves, as Annex III's did in the May 2026 Digital Omnibus agreement, the underlying evidence pipeline doesn't need to be rebuilt, only re-scoped.