Most advisers never asked themselves what happens if the AI model their firm runs on simply stops existing. Not degraded. Not quietly updated. Gone. On June 12, 2026, that question got answered for everyone, without warning.
That is why AI governance cannot be treated as a one-time vendor approval, a policy you adopt once, or an implementation project you close out. If the workflow is live, the governance has to stay live too. A regulated firm that builds on AI has to be able to absorb model changes, model removals, emergency migrations, and fallback decisions in real time. That is an operating discipline, not a document.
The event that proved the point: a US government export control directive forced Anthropic to disable two of its models, Fable 5 and Mythos 5, for every customer. This was not a product decision. It was not a deprecation on a published schedule. It was a federal order, received late in the business day, with no advance notice to the firms whose work depended on the model and no committed date for bringing it back. Anthropic disputed the basis and said it was working to restore access. None of that mattered to the workflow that stopped working that evening.
If your firm, or any client you advise, had standardized a process on Fable 5, and had no validated fallback ready, the process did not get slower. It ceased. And the compliance record built around that model went stale at the same moment.
This is the risk my last note to members described in the abstract. The Fable removal made it concrete, and worse than the version I sketched. I had framed the danger as the vendor’s roadmap being outside your control. This event proves the danger is larger than the vendor. A model can be removed by a third party the vendor itself cannot overrule.
What happened, briefly
According to Anthropic’s public statement dated June 12, 2026, the US government issued an export control directive, citing national security authorities, that suspended access to Fable 5 and Mythos 5 by any foreign national. By Anthropic’s own description, the practical effect was that it had to disable both models for all customers in order to comply. Anthropic said access to its other models was not affected. It said it received the directive at 5:21pm Eastern, that it disputed the basis, and that it was working to restore access. As Anthropic later described it, the government’s stated concern was a method of bypassing, or jailbreaking, a safeguard meant to prevent Fable 5 from being used to identify software vulnerabilities; Anthropic said it reviewed a demonstration of the technique, characterized the issue as a misunderstanding, and continued to dispute the basis for the order. The cause was a government action, not a vendor business decision. That difference is the whole point of this article.
Source: Anthropic, “Statement on the US government directive to suspend access to Fable 5 and Mythos 5,” anthropic.com, June 12, 2026.
What this looked like inside MTradecraft
We are not writing this from the outside. MTradecraft uses these models in our own threat-intelligence work, and when Fable 5 went dark on the evening of Friday, June 12, we spent the weekend re-pointing those workflows onto other models. We moved fast because the work matters — but doing it under time pressure is exactly what this article asks you to design out of your firm. The lesson cost us a weekend. We would rather you spend a calm afternoon instead.
What actually broke
Picture a firm with roughly $500M under management that had moved a real process onto Fable 5. Drafting assistance for client correspondence. Summaries of portfolio review notes. Maybe a first pass at ADV brochure language. The firm did the work. It validated the model, wrote the procedure, trained the staff, and retained output samples. By the evening of June 12 every piece of that pointed at a model the firm could no longer reach.
The damage did not arrive as one problem. It arrived as several at once, and the firm caused none of them.
Operations stopped, not degraded
A degraded tool gives you worse answers. A removed tool gives you nothing. If the firm had no validated fallback and no maintained manual path, the process did not merely slow down. It ceased. Staff who had built their day around the workflow had to revert to a manual process they had stopped maintaining, or wait. There was no graceful fallback because nobody had built one. The firm assumed the model would be there.
Rule 206(4)-7, the reasonably designed standard
The firm’s written procedures were validated around Fable 5. The instant that model was gone, the only way to keep the workflow alive was to point it at a different model nobody at the firm had tested. That replacement is a new control. It has not been through review. Telling an examiner the workflow remained reasonably designed across that swap is not a claim the firm could honestly make. The standard is continuous. It does not survive an untested emergency migration.
Rule 204-2, books and records
Records integrity requires that you can show what was produced, reviewed, changed, approved, and sent. The firm should not depend on the vendor or the model to reconstruct that later. If the prompt, the output, the review notes, the final communication, and the approval evidence are not retained in the firm’s own archive where the record is required, the firm may be unable to demonstrate any of it after the model is gone. The Fable removal is a clean illustration. The engine that drafted the document is no longer reachable, so the only durable record is the one the firm kept itself.
Regulation S-P, safeguarding and vendor oversight
Not every model failure is a privacy incident. An outage by itself is not a Reg S-P event. It becomes a safeguarding and vendor oversight issue when customer information moves through a new provider, endpoint, region, retention policy, or contractual framework. An emergency migration is exactly where that happens without anyone diligencing the new path. A team racing to restore a broken process over a single evening moves to whatever model is available, under whatever terms. A new model carrying customer information is a service provider relationship that has to be reviewed before it carries that information, not after the workflow is already running.
The amended rule gives this teeth. By June 3, 2026 the tiered Regulation S-P compliance dates have arrived for both larger and smaller covered institutions, so advisers should assume that AI service provider and data handling decisions will be viewed through that framework wherever customer information is involved. Two specifics matter for AI vendors. The rule requires written service provider oversight designed to ensure providers notify the firm of a breach of a customer information system as soon as possible and no later than 72 hours after becoming aware of it. And the customer notification obligation runs as soon as practicable but no later than 30 days after the firm becomes aware that unauthorized access is reasonably likely, unless a reasonable investigation determines that sensitive customer information is not reasonably likely to be used in a way causing substantial harm or inconvenience. An AI vendor that cannot commit in writing to that 72 hour notice is a gap against the rule, not merely a missed best practice.
Rule 206(4)-1, the Marketing Rule
If the firm’s ADV or marketing described AI capability tied to what Fable 5 did, that substantiation went stale the moment the model went away. A claim that was true on one model and untested on its replacement is a claim the firm can no longer support. Standing behind a stale AI claim is what produced the enforcement actions this market already knows by name.
Why a contract would not have saved you
My earlier note told members to negotiate deprecation notice and minimum support windows into vendor agreements. That advice is still correct. It would have done nothing here.
A vendor can be held to its contract. A government directive overrides the contract. No notice clause, no sunset window, and no service level commitment survives a federal order to disable a model. The firm that did everything right on the vendor diligence front still lost the model on the same evening as the firm that did nothing. This is the uncomfortable lesson. Against this category of event, the defense is not a better contract. The defense is not depending on any single model in the first place.
What we see in assessments
Firms treat the model as permanent infrastructure. There is no fallback model that has already been diligenced and validated. There is no business continuity plan that contemplates an AI tool disappearing. The critical workflow is single sourced to one model, which means one removal takes the whole process down. When MTradecraft runs a risk assessment, AI single sourcing rarely shows up as a risk the firm had already identified. Our threat detection work surfaces it as a dependency nobody owned and nobody had a plan for. June 12 turned that finding from a hypothetical into a dated event.
The defensible posture
You cannot stop a government from removing a model, and you cannot stop a vendor from complying. You can make sure that when it happens, your firm bends instead of breaking, your records survive, and you never operate outside the reasonably designed standard for a single day. The goal shifts from preventing the event to surviving it.
1. Do not single source a critical workflow
If a process matters enough that its loss would stop work or create a compliance gap, it must not depend on one model. Identify a second model, on a different provider where practical, that can run the same workflow. Diligence it and validate it before you need it. The cost of carrying a tested fallback is small next to the cost of building one during an outage.
2. Write AI into your business continuity plan
Your continuity plan already contemplates losing a building, a network, or a key vendor. Add the loss of an AI model to that list, with the same seriousness. Define the trigger, the fallback, the manual path of last resort, and the named person who decides which one the firm takes. Decide it now, on a calm afternoon, not at 6pm on the day a model goes dark.
3. Run a real model registry, not just an inventory
The AIBOM tells you which tools you use. The registry tells you which model version sits behind each workflow, what the fallback is, and where the validation evidence for both lives. A registry with a fallback column is the document that turns an outage into a procedure.
| Workflow | Primary model | Diligenced fallback | Continuity trigger and owner |
|---|---|---|---|
| Client correspondence drafting | Provider A, enterprise tier, validated 2026-Q1 | Provider B, enterprise tier, validated and pinned | Primary unavailable over 4 hours; CCO authorizes switch to fallback; manual drafting if both down |
4. Treat the switch to a fallback as a new tool, even in an emergency
When you move to the fallback, it still has to clear the gate. Compare its output to the retained samples from the primary. Confirm the data path was already diligenced. Update the registry and the AIBOM. Have the supervisory owner sign off and date it. If you validated the fallback in advance, this takes minutes instead of weeks. That record is your proof the control stayed reasonably designed across the transition.
5. Keep outputs and prompts in your own archive
The model can be removed by anyone. Your books and records cannot live in the vendor’s environment. Retain the output and the prompt that produced it inside your archiving system. When the model is gone, those artifacts are the only thing that lets you reconstruct a record and answer an examiner. If it is not in your archive, you do not control it, and June 12 showed how fast control can be taken away.
What this means for the CCO
The lesson is not that every model change requires panic. The lesson is that every material model change requires a controlled process. Identify the affected workflows. Determine whether customer information is involved. Confirm whether the records are preserved in your own systems. Validate the fallback. Update the registry. Document the approval. Decide whether any client facing or regulatory language has become stale. That work cannot begin after the outage. It has to be designed before the outage, so that on the day it happens the CCO is running a procedure instead of improvising one.
The firms that handle this well are not the firms with the longest AI policy. They are the firms with same day AI change management: a live registry, a tested fallback, retained evidence, a named decision maker, and a documented approval path.
Five questions to answer before the next removal
- Which specific model sits behind each AI assisted workflow at the firm right now?
- For each critical workflow, do you have a second model already diligenced and validated that can carry it tomorrow?
- If your primary model went dark this evening with no notice, what is your continuity trigger, and who executes it?
- Can you show what an AI assisted client communication produced, reviewed, and sent last quarter from your own archive, without the vendor or the model?
- Does your ADV or marketing describe AI behavior tied to a model you no longer control?
The honest framing
AI is not a category apart from the rest of your compliance program. A model removal is a vendor and continuity event, and continuity is something the firm already knows how to govern. The reason June 12 felt like a crisis is that almost no firm wrote it into the program. They assumed the tool would stay. The lesson is not to fear AI. The lesson is to treat any single model as something that can be taken away without your permission and without the vendor’s, and to build so that the loss is an inconvenience rather than a stop.
The firms that came through this calmly were not the ones on the best model. They were the ones who never bet a critical process on a single one. That is what protects client data when a migration is forced. That is what keeps you out of an enforcement conversation about a stale AI claim. That is what preserves client trust when the tool your staff relied on disappears overnight.
How MTradecraft helps
We are independent and vendor neutral. We do not resell software, we do not take vendor commissions, and we have no stake in which model you run. Our work on this risk takes one of three forms. A focused AI readiness review that builds the model registry, the validated fallback, and the continuity plan into your existing program. Inclusion of AI single sourcing and model continuity in our broader Cyber Risk Vulnerability Threat Assessment, where our risk assessment and threat detection work surfaces the dependencies the firm did not know it carried. Or ongoing Remote CISO advisory, where we keep the fallback tested and the continuity plan current so the next removal is a procedure and not a fire drill.
If a conversation would be useful, even just to compare notes on how peer firms handled June 12, reach out. There is no cost for the first call.
MTradecraft, LLC
Brian Hahn · info@mtradecraft.com · 210-201-2102 · www.mtradecraft.com · Dallas, TX
This article is provided for informational purposes only and does not constitute legal, tax, or compliance advice. Firms should consult their own legal and compliance counsel regarding the application of specific regulations to their circumstances.