The continuity gap - the system that runs without its owner.Your AI governance strategy answers “how do we run this system well?” It rarely answers the question that matters more — what happens when you cannot run it at all. That gap is where the real risk lives.
This is the second field note in Governance Without a Body. Last week I argued that the governance of human capacity is the foundation beneath all the technical governance work — that rest is infrastructure, not reward, and that any system depending on a single present body is a risk wearing a system’s clothes. This week I want to take that principle and aim it directly at your AI governance program, because the most sophisticated AI governance strategy I have ever seen still had a hole straight through the middle of it: it was written entirely for the days when everything works.
Almost every AI governance strategy I review is written for the steady state. It assumes the team is present and competent, the model is performing within expected bounds, the data pipelines are flowing, and the regulatory environment is stable enough to plan against. Within those assumptions, these strategies are often genuinely good. They answer, sometimes with real rigor, the question they were built to answer: how do we run this system well?
And then I ask the question they were not built to answer, and the room goes quiet. What happens when you cannot run this system? Not when it runs badly — when you cannot run it at all. When the person who understands the model is unreachable for a month. When performance drops sharply on a protected group on a holiday weekend and no one is watching. When a regulatory inquiry arrives during the exact week the three people who could answer it are all out of the office. That silence, when it comes, is not a small thing. It is the sound of a governance program that has confused running a system well with governing it, and the difference between those two is the entire subject of this field note.
Running a system well is operations. Governing it includes operations, but it also includes the harder discipline that operations alone never forces you to confront: designing for the moment the operation fails, the people are absent, or the conditions you assumed no longer hold. That discipline has a name in nearly every mature field except, somehow, AI governance. In business it is called business continuity and disaster recovery. In engineering it is called graceful degradation and fault tolerance. In risk management it is called key-person risk. The concepts are old, well-understood, and battle-tested. They have simply not yet been carried across into how organizations govern their AI — and the gap between how seriously we take continuity for our data centers and how little we take it for our AI governance is, frankly, indefensible.
THE QUESTIONS A CONTINUITY PLAN ANSWERS
Let me make the gap concrete, because “you need a continuity plan” is the kind of advice that is easy to nod at and impossible to act on without specifics. A real AI governance continuity plan answers a set of questions most organizations have never once asked out loud.
Who owns each model if the primary owner is unavailable? Not in theory — in writing, with a named successor who actually has the access, the context, and the authority to act. In most organizations, model ownership is informal and singular; there is one person who really understands a given system, and the org chart has quietly organized itself around the assumption that this person will always be reachable. That assumption is a single point of failure, and single points of failure are governance risks whether they sit in your infrastructure or in your staffing.
How do you pause or degrade gracefully if performance drops on a protected population? This is the graceful-degradation question, borrowed directly from engineering, and it is one of the most revealing questions you can ask. A well-designed system, when it begins to fail, does not simply keep running at full confidence while producing harm; it degrades in a controlled way — falling back to a safer mode, routing to a human, or pausing entirely — until the problem is understood. If your honest answer is that the system would just keep running, at full speed, producing biased output until someone happened to notice and manually intervened, then you have no graceful degradation. You have a system with one operating mode — on — and no designed behavior for the moment it should not be.
What is your process when a regulatory inquiry arrives and the usual people are unavailable? At eighteen months into the EU AI Act, with non-discrimination obligations being tested against real deployments, a regulatory inquiry is no longer a remote hypothetical. The Act’s own logic — post-market monitoring, human oversight, documentation that must be producible on request — assumes an organization that can respond as an institution rather than as a few specific individuals. If your ability to respond to a regulator depends on one person being at their desk, your compliance itself has a continuity gap.
And can your accessibility and bias audits be carried out by someone other than the person who designed them? This is the documentation question, and it is the one that most reliably exposes governance that exists only in someone’s head. An audit that cannot be run from its documentation by a competent colleague is not a governance control. It is a personal practice that the organization has been fortunate enough to benefit from, and fortune is not a governance strategy.
If those questions produce uncomfortable silence in your organization, you have found the continuity gap. And the silence is the finding — it is the sound of governance that has been built entirely for the good days.
CONTINUITY IS NOT THE SAME AS REDUNDANCY YOU CAN BUY
I want to be precise about what a continuity plan actually requires, because there is a tempting and incomplete version of this that organizations reach for first: buy more tools, add more monitoring, and assume that technical redundancy is the same as governance continuity. It is not, and the difference matters.
Technical redundancy keeps the system running. Governance continuity keeps the system accountable. You can have a perfectly redundant, highly available AI system — failover servers, replicated data, ninety-nine-point-nine-nine-percent uptime — that is, from a governance standpoint, completely fragile, because the moment the one person who understood its fairness profile leaves, no one remaining can tell whether it is behaving equitably, respond to a regulator about it, or decide whether it should be paused. The system stays up. The governance falls over. Uptime is an operations metric; continuity, in the sense I mean it, is a governance property, and you cannot purchase it as a feature. It has to be designed into how knowledge, ownership, and authority are distributed across people, and that is organizational work, not procurement.
The mature frameworks already gesture at this, which is reassuring, because it means you are not inventing the discipline from scratch. The NIST AI Risk Management Framework organizes its entire approach around four functions, and the first — Govern — is explicitly about establishing the roles, accountability structures, and processes that persist independently of any individual. ISO/IEC 42001, the international standard for an AI management system, is built around exactly the lifecycle thinking that continuity requires: managing an AI system across its whole life, including the transitions and handoffs where continuity is most often lost. Neither framework will hand you a finished continuity plan, but both encode the same underlying truth — that governance is a property of the organization and its documented systems, not of the particular people who happen to be staffing them this quarter.
I BUILT MY OWN CONTINUITY PLAN. LITERALLY.
I am not arguing this from the outside. I built my own continuity plan this spring, in the most literal sense I can imagine, because my circumstances did not leave me the option of treating continuity as theoretical.
Building Me Back — the experiment I have been documenting all year — was, underneath the AI-governance critique it produced, a continuity project. I set out to build a version of my own voice that could operate when my body could not, because I live with sickle cell disease and I am undergoing gene therapy, and there are stretches when I simply cannot record, cannot be present, cannot be the engine the work runs on. The voice clone I built is functional. It is not me — a trained listener who knows my voice would hear the difference immediately — but it works well enough to carry presence when my body cannot supply it. That is, precisely, graceful degradation applied to a person: not full capacity, but a designed, acceptable fallback for the moment the first-best path is unavailable. I did not build it as a novelty. I built it as continuity.
The Lyfgenia: A Public Record documentation is a continuity instrument too, of a different kind. It is a public archive that exists independently of my capacity to maintain it on any given day — a system that holds the record even when the person keeping it cannot. And this very field note, reaching you from a queue I built in advance while I am largely offline, is the continuity plan operating in real time. The content runs. The argument holds. The system is accountable to you this week without my present body, because I designed it to be.
I am telling you this not as a personal aside but as proof of concept, because the discipline I built for myself out of medical necessity is exactly the discipline your organization needs out of operational necessity, and I have now stress-tested it on the hardest possible subject. If I can build continuity for an enterprise that runs on a single chronically ill body, your organization — with its teams, its budgets, and its redundancy you have not yet pointed at this problem — can certainly build it for its AI governance. The constraint was never capability. It was attention. You have not built a continuity plan because no one has asked you the question that makes the gap visible.
THREE QUESTIONS, AND WHAT TO DO WITH THE ANSWERS
So here is the version of the audit I am asking you to run this week. Three questions, and the instruction to treat the answers as findings rather than as conversation.
First: if your lead AI governance person were unavailable for thirty days, what specifically breaks? Trace it concretely — not “we’d manage,” but which exact controls, audits, responses, and decisions would stop or silently degrade. Name them. The list is your continuity gap, itemized.
Second: can someone outside your core team run your bias audit using only the documentation that exists today? Do not answer from optimism; test it, by actually handing the documentation to a competent colleague and watching where they get stuck. The points where they cannot proceed are the points where your governance lives in a head rather than in a system.
Third: when did you last test your AI system’s graceful degradation — its designed behavior when it fails — as opposed to its performance when it works? If the honest answer is never, then you have validated only the steady state, which means you have validated the easy half and left the half that actually determines whether harm gets caught entirely untested.
If you do not have good answers to these, that is not a gap in your competence. It is a gap in your design, and design gaps are fixable — they are, in fact, exactly the work I do at incluu. The organizations that will navigate the next few years well are not the ones whose AI governance never faces an absence, an outage, or an inquiry at the worst possible moment. Every program will face those. The ones that do well are the ones that decided, in advance, that the steady state was the easy half of the problem, and built deliberately for the other half — the half where the body is absent, the path has failed, and the system has to hold anyway.
That is governance without a body. It is the whole point of the month, and the continuity plan is how you build it.
incluu builds AI governance systems designed for more than the steady state — the documented model ownership and succession, the graceful-degradation protocols, the regulator-response readiness, and the audit documentation that lets a competent colleague run your controls without the person who designed them. We build for continuity, because a governance program that only works on its good days is not a governance program. It is a single point of failure you have not measured yet.
Consultation
incluu
Substack archive:
Dr. Dédé Tetsubayashi is a Black, queer, first-generation Togolese immigrant and transracial adoptee living with sickle cell disease. She is a TEDx speaker, a global advisor on AI governance and inclusive technology, and the organizer of Rest as Resistance retreats. → Work with Dr. Dédé at incluu.us.
This is Week 2 of Governance Without a Body — the June 2026 arc. Next in the series: The Missing Accessibility Audit, and the procurement questions that survive the regulatory deferral.
THE THREE-QUESTION PULSE
Two minutes. It points the rest of the arc at your real gaps.
Does your AI governance program have any documented continuity or succession plan, or is it built entirely for the steady state? (Documented / Partial / Steady-state only / I don’t know)
Which continuity gap worries you most: single-owner models, no graceful degradation, regulator-response readiness, or undocumented audits?
What would help most next: a continuity-plan template, a graceful-degradation checklist, a model-ownership/succession framework, or an audit-documentation standard?
Read more
