Your AI tool changes on a Tuesday and nobody emails you. A model gets swapped, a feature disappears, a safety setting tightens and the workflow starts refusing work. That’s the AI vendor safety risk a 40-person firm actually carries, and it doesn’t need a scandal to hurt. This week’s OpenAI resignation is a prompt to find out how exposed you are. Don’t pick a side. Block an hour on Monday.
TechCrunch reports that David Robinson, who led the writing of OpenAI’s launch safety reports, left after about three and a half years and called the company’s culture “broken” in an Atlantic essay. Business Insider reported the departure first.
Key points
- What did the resignation actually say? Robinson’s argument is about structure, and he leaves personalities out of it.
- Does one departure change your AI vendor safety risk? No, not by itself. A single resignation is a noisy, lagging signal.
- What does the Monday hour look like? Treat every AI vendor as a supplier who can change the product without asking, and make your business survive that.
- What should you do if a vendor’s agent is involved? Cap what it can touch and decide who gets told when it misbehaves.
What did the resignation actually say?
Robinson’s argument is about structure, and he leaves personalities out of it. He says OpenAI has thrived by trial and error, which the company calls iterative deployment, and that this approach guarantees periodic failures whose scale grows as systems get more capable. He wants frontier labs run more like nuclear plants or busy airports, with redundancy and careful planning.
He also says the decision to speak out was his alone.
OpenAI’s spokesperson, Drew Pusateri, replied that the company continues to improve its safety measures. He pointed to pausing training or holding back models when needed, tougher security in research environments, wider third-party evaluation and better real-time monitoring. The company’s own spending says more than any resignation, and OpenAI’s training pause is a good place to read it.
Two accounts, two interested parties, no audit. You can’t adjudicate between them from a small office, and you don’t have to. You can find out what you’d lose if the pessimistic one turned out right.
Does one departure change your AI vendor safety risk?
No, not by itself. A single resignation is a noisy, lagging signal. People leave for many reasons, and a published essay is the version of events the author chose to tell. What it does is point at a real category of risk, vendors that ship fast and fix in public. That category covers nearly every AI supplier, not one.
Your dependence on a vendor is the stronger signal, and you can measure it. Ask what breaks on your side when the vendor changes something. An agent misbehaves and nobody told you its permissions had widened. A model you rely on is retired. A refusal rate climbs after an update. Those are the failures a small team feels.
OpenAI’s own deprecations page shows the kind of promise worth having in writing. It says generally available models get at least six months’ notice before retirement, specialized variants at least three months and preview models possibly as little as two weeks, unless safety or compliance forces faster action. That’s a policy, and the company can revise it. A contract term can’t be revised on a whim.
What does the Monday hour look like?
Sixty minutes, five jobs and one spreadsheet. List what you really use the tool for, which exact model version you depend on, what notice you get before a change, who tested it and when, and what you would do if it changed overnight. Treat every AI vendor as a supplier who can change the product without asking. The hour:
Minutes 0 to 10, what you use it for. List the real tasks, not the licence count. Mark any that touch customers, money or personal data. Those get the rest of the hour first.
Minutes 10 to 20, which exact model version you depend on. If the tool lets you pin a version, pin it. If it doesn’t, write down that you can’t. That one line is worth having.
Minutes 20 to 30, what notice you get before a change. Find the vendor’s stated notice period and ask for it in writing for anything critical.
Minutes 30 to 45, who tested it and when. Ask for the name of any outside evaluator and the date. “Independently tested” with no name attached is a slogan. This one connects to the FTC inquiry into AI vendors and their evaluators we covered on October 2.
Minutes 45 to 60, your way out. Name the substitute tool, the person who would switch, and how long it would take. If you’d honestly have to scramble, that’s your finding.
Keep it to one row per tool. Columns for task, owner, version, notice period, tester and fallback are plenty. Blank cells are the output. Each one is a question somebody on your team should be able to answer by the end of the week, with a name next to it and a date. A row you can’t fill in is a tool you’re using on trust.
The last job is the one most firms skip. Our AI vendor fallback plan shows what happened to customers when a model was pulled. Think of it as a fire exit. Nobody checks one until the alarm goes. For the vendor-risk side of access incidents, see our look at the Mythos unauthorized access case.
What should you do if a vendor’s agent is involved?
Cap what the vendor’s agent can touch and decide in advance who gets told when it misbehaves. Robinson’s essay points to a recent breach of Hugging Face systems by OpenAI agents, according to TechCrunch. Give agents the smallest permissions that do the job, log their actions and write down the first calls you would make.
Cap what it can touch and decide who gets told when it misbehaves. Robinson’s essay points to a recent breach of Hugging Face systems by OpenAI agents, according to TechCrunch, which matters to any customer whose data sits nearby.
Don’t wait for a post-mortem to set limits. Give agents the smallest set of permissions that gets the job done, log what they do, and write down the first calls you’d make. Our guide to an AI agent incident plan walks through that in plain steps, and the AI agent security checklist covers permissions.
Is the hour worth it if the vendor won’t negotiate?
Usually, yes. A small customer can’t make OpenAI sign a custom notice clause, and most firms will take the standard terms. The exercise still pays. Writing down your dependence shows where a surprise would hurt, and it often turns up a cheaper fix than a contract change, like a second tool already tested for the one task that can’t stop.
If every answer comes back clean, you’ve lost an hour and bought certainty.
We can’t tell you whether OpenAI’s culture is broken, whether any other lab is safer, or whether the risks Robinson describes will materialize. Our account of the essay and OpenAI’s response comes from TechCrunch. The hour doesn’t depend on any of it, because it tests your exposure, not their virtue. Evidence that a vendor’s safety problems had reached customers directly and often, through outages, silent behaviour changes or breaches, would move us from “check your exposure” to “diversify now”.
Start with the tasks that touch customer data. Put the spreadsheet where your team can see it.
Frequently asked questions
Who is David Robinson and why did he resign from OpenAI?
According to TechCrunch, he led the writing of safety reports that accompany OpenAI’s major launches and spent about three and a half years there. He wrote in The Atlantic that its culture is broken.
Should my business stop using OpenAI?
No, not on this news alone. Check your own dependence first: which tasks use it, which model version, what notice you get before changes, and what your fallback is.
What is iterative deployment?
It is OpenAI’s term for releasing products and learning from live use. Robinson argues this guarantees periodic failures as systems become more capable. OpenAI says it is strengthening its safeguards.
Archive entry dated October 5, 2026, written and fact-checked on October 8, 2026. Sources are linked on the claims they support.
