The AI rulebook isn’t coming. The sign-off still is.

On April 17, 2026, the Federal Reserve, the FDIC, and the OCC issued new supervisory guidance on model risk management. SR 26-2 replaces SR 11-7, the 2011 document that has governed how banks manage model risk for fifteen years. In the section defining its scope, it says this:

Read that again. The regulators who wrote the book on model governance, the framework every bank examiner in the country has worked from since 2011, looked at the two fastest-moving categories of AI in the enterprise and said: not us. Not yet.

The guidance does say what should happen instead. A banking organization’s own “risk management and governance practices should guide the determination of appropriate governance and controls” for anything the document doesn’t cover. That sentence is doing a great deal of work. It means: you decide. And then you defend what you decided.

This is a pattern, not an exception

If SR 26-2 were an isolated case, you could wait it out. It isn’t.

The EU AI Act was supposed to be the world’s most comprehensive AI rulebook, with high-risk obligations landing in August 2026. The AI Omnibus, published in the Official Journal in July 2026, moved those obligations out to December 2027 for most high-risk systems and August 2028 for AI embedded in regulated products.

The long-awaited update to the HIPAA Security Rule, the first substantive overhaul in over a decade and the one health system CISOs expected to define security expectations for the AI era, has slipped to July 2027.

Colorado passed the first comprehensive state AI law in the country, aimed squarely at algorithmic discrimination in consequential decisions. In 2026 the legislature repealed it before its core duties ever took effect, replacing it with a narrower statute focused on transparency.

Four frameworks, four jurisdictions, one direction: delayed, narrowed, or explicitly opted out. Anyone whose AI governance plan amounts to “we’ll comply with the rules when they arrive” now has a plan with no date on it.

Why this is harder than “no rules means no constraints”

It would be convenient if a delayed rulebook meant a holiday from the obligation. The opposite is true, and everyone who has to answer to a board already knows it.

Your board still has to approve AI deployments, and board members are personally attentive to what they are approving on thin evidence. Your auditors still ask how the system is controlled, and “the regulation was postponed” has never once satisfied an auditor. Your cyber insurer’s questionnaire has grown an AI section. Your largest customers’ vendor security reviews have too. In healthcare, HHS enforcement of the existing Security Rule continues regardless of when the update lands, and AI systems that touch PHI are covered by the rule you already have.

What the delays actually did was move the obligation. It used to sit, prospectively, with the regulator: they would tell you what good looks like, and you would implement it. Now it sits with you. Someone in your organization has to be able to say what your AI systems are permitted to do, prove they stay within that boundary, and show their work after the fact. The regulators have, in writing, declined to do this for you. SR 26-2 says so in as many words.

That is uncomfortable. It is also an opening. The organizations that write a defensible framework now will spend the next two years operating AI while their peers are still waiting for permission that isn’t coming.

What a defensible framework actually contains

Strip away the vendor noise and an internal AI control framework has to answer five questions. They are the same five questions a board member, an auditor, or an examiner will ask, in roughly this order.

What is the system permitted to do? Not what it can do; what it is allowed to do. A written scope: the data it may touch, the decisions it may influence, the actions it may take without a human in the loop, and the actions it may never take at all. If you cannot state the boundary, you do not have a system, you have an experiment.

Who approved it, and on what basis? A named approver, a dated decision, and the evidence they saw: what was tested, what the failure modes were, what risk was accepted and by whom. Committees diffuse accountability; approvals concentrate it. When something goes wrong, the first question is who signed off. Better to have a good answer designed in advance.

What happens when it’s wrong? Every model is wrong sometimes; generative systems are wrong in fluent, confident sentences. The framework states what “wrong” looks like for each system, how it gets detected, who gets told, and what the fallback is. A system with no defined failure path fails into your incident response at the worst possible moment.

How would you evidence its behaviour after the fact? Logs, versioning, audit trails: if the system influenced a decision in March, can you reconstruct in September what it saw, what it produced, and which version was running? Discovery requests and examiner questions both arrive long after the event. Evidence is a design requirement, not a retrofit.

How is the boundary enforced: technically, or by policy? A policy that says “staff must not paste patient data into public AI tools” is a hope. A network control that blocks it is a control. Wherever the framework’s boundaries can be enforced in the architecture, through permissions, gateways, spend ceilings, and human-approval gates on destructive actions, they should be. Auditors know the difference between a rule that is written down and a rule that is built in, and they weight them accordingly.

Start from NIST, map to what you already have

None of this requires inventing a governance discipline from scratch, and it certainly doesn’t require a parallel bureaucracy.

The most usable skeleton available today is the NIST AI Risk Management Framework. It is voluntary, it is free, and its four functions, govern, map, measure, and manage, translate directly into the five questions above. It has the additional virtue of being the framework US regulators themselves keep pointing at while their own guidance is pending, which makes “we aligned to NIST AI RMF” the most defensible sentence you can currently put in front of an examiner.

The second move matters just as much: map AI controls onto the control frameworks you already operate. ISO 27001, the NIST Cybersecurity Framework, the HIPAA Security Rule safeguards you are audited against today. An AI system’s access controls, logging, vendor management, and change management are mostly your existing controls, extended. Standing up a separate AI governance regime with its own committee, its own register, and its own vocabulary doubles the work and halves the credibility. Your auditors already trust your ISO 27001 structure; hang the AI controls where they can see them.

Done this way, the framework is weeks of disciplined work, not a transformation programme. The hard part is not volume. It is judgment: knowing which systems deserve heavyweight controls and which need two paragraphs and a log file, and being able to defend the difference.

Where this leaves you

The uncomfortable summary: the frameworks everyone was waiting for have been delayed, narrowed, or have declined the job, and the people you answer to, boards, auditors, insurers, and customers, did not get the memo to stop asking. The rulebook obligation has moved to you, in writing.

This is the work we do at SGL Tech: writing control frameworks AI can actually operate under, and then building to them, in government, healthcare, and financial services environments where the sign-off is the hard part. We run production AI inside our own practice under exactly this kind of framework, which is why the advice doesn’t come from a slide.