Four rules with real teeth, what each one actually requires, and the one evidence pipeline that satisfies all of them.
Most of the AI regulation coverage I read is written for lawyers, and most of it is wrong about timing. The headline this spring was that the EU pushed its scariest AI rules out to 2027. True, and also a trap. If you are an engineering leader and you read "deferred" and exhaled, you misread the calendar. The part that can fine you a percentage of global revenue did not move. It activates this August.
So here is the map I keep on one page. Four things with teeth, when they bite, and what your team should build instead of what your policy deck should say. I write this as a practitioner who has run cloud security and platform teams in regulated environments, not as anyone's compliance department. The good news at the end: these four converge onto one technical control, so you are not building four programs.
The EU AI Act did not get easier, it got more specific
The "Digital Omnibus" package, published on 7 May, deferred the high-risk obligations under Annex III to December 2027. That is the long list: conformity assessments, risk management systems, the heavy documentation for systems that touch credit, employment, and the like. Real relief, real engineering time bought back.
But the obligations for general-purpose AI models, the GPAI tier, were not deferred. The Commission's enforcement powers there switch on 2 August 2026, with fines up to 3 percent of global annual turnover. Read that as a function, not a threat. If you fine-tune, host, or build on a foundation model and you put it on the EU market, you inherit GPAI obligations, and the enforcer has standing in August whether or not your specific use case is "high-risk."
The practical move is unglamorous and you can start it Monday. For every model you use, including the ones reached through a cloud provider, collect and store the provider's documentation: the model card, the training-data summary, the acceptable-use and copyright posture, the published evaluations. The Act expects this to flow downstream. Most teams discover they cannot produce it for half their models. That gap is the work.
Here is why the documentation discipline is not bureaucratic theater. Models move under you. GPT-5.5 Instant became the ChatGPT default on 5 May and is exposed as a floating "chat-latest" alias, which means the thing answering your users can change without a version bump on your side. In the other direction, Fable 5 and Mythos 5 launched on 9 June and were pulled offline three days later under a US export-control directive, the first time a major US lab's flagship went dark within days of release. If your compliance evidence points at "the model" as an abstraction, both of those events break your audit trail. Pin model IDs. Treat a pinned ID, like the stable "claude-opus-4-8" identifier, as a compliance artifact, not a convenience.
The US has no AI Act, which is exactly why the sector rules matter more
People keep waiting for a federal framework and treating the absence of one as the absence of rules. In financial services that reading is dangerous, because the binding guidance is already here, just sector-shaped.
On 19 February, US Treasury published a Financial Services AI Risk Management Framework with 230 control objectives across seven domains. Two hundred and thirty. That is not a position paper, that is a control catalog, and control catalogs are how examiners think. You do not have to be a bank for this to matter. If you sell into one, their third-party risk process will hand you a subset of those 230 and ask you to evidence them, and "we take AI safety seriously" is not an answer to a control objective.
NIST AI RMF is the lingua franca, so adopt it as your internal source of truth
Here is the contrarian part: stop treating each regulation as its own project. The EU's GPAI documentation, Treasury's 230 controls, and the state laws below all describe the same underlying functions in different dialects. NIST AI RMF gives you the dialect they all translate into. Govern, Map, Measure, Manage. If you organize your evidence by those functions once, you answer most questionnaires by reindexing, not by re-doing.
Texas makes this concrete. TRAIGA, the Texas Responsible AI Governance Act, has been in force since 1 January, and it includes something most laws do not: a safe harbor for organizations that follow a recognized framework, with NIST AI RMF named explicitly. Read that for what it is. A regulator telling you the price of the framework is lower than the price of an incident, and offering a discount for adopting it in advance. Take the discount.
The fourth corner is security-specific. On 16 December NIST published a preliminary Cyber AI Profile, IR 8596, which maps AI systems onto the cybersecurity controls your security team already runs. This is the bridge that keeps "AI governance" from spawning as a parallel org that never talks to your SOC. The threats it anticipates are not hypothetical. OWASP mapped prompt injection to 6 of its 10 agentic-AI Top 10 categories on 11 June. SearchLeak, CVE-2026-42824, was disclosed on 15 June as a one-click data-exfiltration flaw in Microsoft 365 Copilot, the second exfiltration class of its kind after EchoLeak. Your AI risk register and your vulnerability management need to be the same register.
The one thing to build: an evidence pipeline, not a binder
If I could make every engineering leader do exactly one thing this quarter, it would be this. Compliance fails at audit time not because the controls were absent but because the proof was not captured when the control ran. So capture it at runtime.
A workable evidence pipeline has four parts, and none of them is a document. First, an inventory that updates itself: every model, every agent, every dataset, with its pinned version, its provider documentation link, and its owner. If a human maintains it by hand, it is already stale. Second, request-level attribution: log which model version served which request, at what cost, under which budget. Amazon Bedrock added request-level usage attribution on 20 May, and Microsoft's renamed Foundry shipped project-level cost attribution on 31 May. The same per-request record that proves your FinOps story proves your provenance story. Third, automated control checks wired to NIST AI RMF functions, emitting pass or fail evidence continuously, the way you already run cloud security posture checks, with each check mapped to the relevant Treasury control and EU obligation once, in metadata. Fourth, retention and tamper-evidence on all of it, because the whole point is to answer a question asked twelve months from now about a model that no longer exists.
Build that, and the four regulations on this page stop being four programs. They become four views of one dataset. Two dates for your calendar before you close the tab. 2 August 2026, when EU GPAI enforcement and its 3 percent fines go live. December 2027, when the high-risk obligations you just got a reprieve on come due, which is sooner than it sounds once you price the engineering.
I am curious where others draw the line between governing the model and governing the application around it, because most of the real risk I see lives in the application. Tell me how you are splitting it.
