The Fable 5 lesson for AI governance

"The risk is not that one model disappears. The risk is that nobody knows which workflow depended on it."

The Fable 5 lesson is operational

Anthropic launched Claude Fable 5 and Claude Mythos 5 on June 9. Three days later, Anthropic said access to both models had been suspended after a US government directive.

Most of the internet treated it like a model drama.

For a regulated AI team, I would treat it as a dependency drill.

The useful question is not whether Fable 5 was good, overhyped, political, or temporary. The useful question is quieter:

Which business workflows would break if a model path changed overnight?

That is the part most AI governance programs still do not know.

A team may have an approved tool list. Procurement may have a vendor record. Legal may have a contract. Security may have reviewed the workspace. None of that proves the actual operating dependency.

A workflow can become dependent long before the control register catches up.

A policy team uses AI to summarize circulars. A risk team uses it to compare obligations. A legal team uses it to review clause changes. An operations team uses it to clean customer notes before a handoff. A product team uses it to draft release language.

Then the provider path changes.

Nobody panics, because no single system is officially down. But the work slows, people route around the approved path, and the evidence trail starts to disappear.

That is the control gap.

The control is a map

A policy says what people should do.

A map shows what the business is actually depending on.

For each AI workflow, I would record six fields before calling it governed:

• Workflow: what business process now depends on AI.

• Owner: who can pause, approve, or change the workflow.

• Data class: what enters the model or tool.

• Provider path: which model, region, connector, workspace, and account tier the workflow needs.

• Evidence kept: prompts, outputs, logs, approvals, review notes, and exception records.

• Fallback: what happens if access, terms, routing, or retention changes.

The last line is the one most teams skip.

Fallback is boring until it is the only thing that matters.

The dependency test

Ask one sentence:

"If this model path disappeared tomorrow, what would break by Friday?"

If the answer is nothing, the use case is probably still experimental.

If the answer is a named process, customer journey, risk review, reporting deadline, board pack, compliance check, or client deliverable, it belongs in the control register.

Not because AI is dangerous by default.

Because operations are depending on it.

This is the same reason third-party risk reviews exist in the first place. A vendor is not only a contract. It is an operating dependency. AI just makes the dependency more fluid because the model, product, routing, feature set, and policy limits can move faster than a normal review cycle.

Old SaaS review AI workflow review

Vendor name Workflow dependency

Data residency Data class plus prompt/output path

Security questionnaire Evidence kept during real use

Contract owner Workflow owner and approval owner

Exit plan Fallback if model access changes

Annual review Trigger review after product or model change

What I would do this week

Do not start with a 60-page policy rewrite.

Start with the ten workflows people actually use.

Then ask five practical questions:

• What changed because AI entered this workflow?

• Who owns the decision when the workflow changes?

• Which data class is involved?

• Which provider path does the workflow depend on?

• What proof would we have if someone reviewed this three months later?

That is enough to separate experiments from operating dependencies.

The work becomes much clearer after that.

A low-risk brainstorming prompt does not need the same evidence as a customer complaint workflow. A generic research workflow does not need the same fallback as a regulatory response workflow. A public-source draft does not need the same approval path as a client file summary.

The problem is when all of those sit under one phrase: approved AI tool.

That phrase hides the work.

The better board pack

A useful board or risk update should not say, "We approved these AI tools."

It should say:

• These are the workflows now using AI.

• These are the owners.

• These are the data classes.

• These are the provider paths.

• These are the evidence gaps.

• These are the fallback gaps.

• These are the decisions we need this month.

That is evidence-grade controls in plain English.

It also makes the revenue case easier. The goal is not to slow down useful work. The goal is to approve useful work without leaving the firm blind when something changes.

A control that only works while every provider behaves exactly as expected is not a control.

It is a hope with a spreadsheet attached.

The lesson from Fable 5 is simple.

Frontier access can change faster than governance cycles.

So the governance cycle needs a map of dependency, evidence, and fallback before the next change arrives.

The part teams miss

The hardest part is not writing the first register.

The hard part is keeping the register close to real work.

If the map only lives in a compliance folder, it goes stale. The workflow keeps changing while the evidence sits untouched. A new connector appears. A product team changes the approved prompt. A vendor adds a feature. A manager tells staff to use a faster route because the official one is too slow.

That is why I would keep the control register small, but alive.

Do not ask for twenty fields nobody updates.

Ask for the few fields that change the decision:

• what workflow is affected

• what data is involved

• which provider path is used

• which evidence exists

• which fallback is approved

• who owns the decision

Review those fields when the workflow changes, not only when the annual policy calendar says it is time.

A small live map beats a large stale policy.

The operating test

Before a workflow becomes approved, ask the owner to finish this sentence:

"If access changes, we will..."

If they cannot finish it, the workflow is not ready. It may still be useful. It may still be low risk. But it is not yet governed in a way that survives provider movement.

That distinction matters.

Good governance should not pretend every AI use case is dangerous.

It should show which use cases are experiments, which are operating dependencies, and which ones need a fallback before they become business-critical.