How to audit your OpenAI dependency risk before a deadline does it for you

Somewhere in your business there is an AI thing that works. It drafts the quotes, or triages the inbox, or writes summaries into the CRM. Someone built it, possibly a contractor, possibly an enthusiastic person in operations, possibly an agency you no longer use. It has run quietly for a year. Nobody has looked at it since.

That is the exposure. Not the technology, and not the vendor. The exposure is that the platform underneath it has published a retirement schedule, and nobody in your business is on the distribution list.

OpenAI's deadlines cluster tightly across 2026, which makes them a useful worked example. The general point applies to every model vendor, and we will come to that.

The deadlines are already published, and several land within months

These are taken from OpenAI's own deprecations page, checked on 08 Aug 2026.

One naming trap is worth calling out, because the shared AgentKit branding invites the mistake. ChatKit is not part of this wind-down. Agent Builder and Evals are going. ChatKit, the embeddable chat interface toolkit, remains available. Do not rip out a working front-end because the word "Kit" appeared in a deprecation headline. The no-code side of it is covered in what to do with an agent built in Agent Builder.

The notice period is generous. The problem is that nobody reads it

OpenAI gave months of warning on all of the above, published it openly and wrote migration guides. By any reasonable standard that is fair treatment.

It does not help you if the person who receives platform emails left in March, or if the build was done by an agency whose contract ended, or if the account sits on a company card belonging to someone in finance who has no idea what a Responses API is.

So this is a governance problem, not a technical one. The failure mode is not "the vendor moved too fast". It is "the notice arrived and nobody owned reading it".

Here is the audit. An ops or IT leader can work through it in a few days, without writing code.

The seven-part audit

1. What is running, who built it, and is anyone maintaining it

List every AI-touching thing in the business. Not the ambition, the reality. Include the automations nobody calls AI any more.

For each one, write down three names: who asked for it, who built it, who maintains it now. A blank third column is an orphan, and orphans are where deadlines do their damage, because nobody's job is to notice.

Expect the list to be longer than you assumed, and expect at least one item where all three names are the same person.

2. Which platform pieces it depends on, and whether any are retiring

For each item, get a straight answer to one question: which API does it call?

You are looking for the Assistants API, threads, Agent Builder workflows, stored prompt objects, Evals, DALL-E, or the old Realtime beta. Everything on that list has a date against it above, and two of those dates have passed. What to do about that specific one is set out in the Assistants API retirement.

If the person who knows has gone, it is still recoverable from API usage in the OpenAI dashboard and from the code itself. An afternoon, not a project.

3. Custom GPT and workspace sprawl

Every workspace accumulates Custom GPTs that someone built once, loaded with a document, shared with a team and forgot. Some of those documents are pricing. Some are contracts. Some are staff data.

Ask what exists, who created each one, who it is shared with, and what is attached to it.

How well you can answer depends on your tier, and this is where businesses discover their governance ceiling. ChatGPT Business does not include SCIM, data residency, or the Compliance Platform that provides audit logging. Those are Enterprise-only. On Business you are relying on admin screens and asking people, rather than on logs.

Check the training defaults at the same time, because they differ by product and are easy to get backwards. Business and API data is opted out of training by default. Consumer ChatGPT is opted in and must be actively switched off. If staff are using personal accounts for work, that distinction is working against you.

4. Model pinning: are you pinned, or floating

There are two ways to get this wrong and most builds pick one without deciding.

Pinned to a dated snapshot gives you stable behaviour and a hard expiry date. gpt-5-2025-08-07 and o3-2025-04-16 are scheduled for removal on 11 Dec 2026. When that lands, a pinned call fails outright. Loud, but at least it is obvious.

Floating on a general alias means you never break, and instead your system quietly changes behaviour underneath you when the vendor moves the frontier. That is the more dangerous option for anything doing classification, extraction or scoring, because nothing errors. The output just gets subtly different and no one notices until a customer does.

Neither is wrong. Having never made the choice is wrong. Write down which one each system uses, and why.

One related thing goes stale in older builds. Reasoning depth is now a parameter on the current GPT-5.6 family, not a reason to call a separate o-series model. Anything routing "hard questions" to a legacy reasoning model is solving a 2025 problem.

5. Cost attribution: can you say which workflow spends what

Most businesses can tell you their total OpenAI spend and nothing else. That is enough to approve an invoice and not enough to make a decision.

Tag usage by project so spend maps to a workflow and an owner. Then check the obvious economics, because the pricing model rewards specific patterns. Input and output tokens are priced separately. Repeated prompt prefixes are billed at a discount through prompt caching. Work that does not need an instant answer can go through the Batch or Flex tiers rather than synchronous calls, and there is a premium tier for guaranteed speed.

The question is whether each workflow sits on the tier that matches its urgency. Bulk enrichment running on the fast synchronous path is a standing overpayment.

6. The bus factor

For each system, ask what happens if the person who built it is unavailable for a month. Is the source code in your repository or theirs, do you hold the API keys, is the account in the company's name, and is there any written description of what it does?

A surprising number of production AI workflows fail all four. This is the cheapest item here to fix and the one most likely to be quietly failing now.

7. Contractual and data exposure if you had to move

You do not need a legal opinion to answer these. They are procurement and engineering questions.

• Retention. Some endpoints keep application state until you delete it. Conversations, vector stores and assistants objects nobody cleaned up are retained indefinitely by design. Do you know what is sitting there?
• Zero Data Retention. Approved by OpenAI's sales team rather than a self-serve toggle, and it carries safety-retention carve-outs. If someone says ZDR is on, confirm it.
• Residency. Set when an API project or Enterprise workspace is created and not addable afterwards. Not available on ChatGPT Business at all. Retrofitting means new projects and a move.
• Counterparty. A UK customer's DPA counterparty is OpenAI OpCo, LLC in the US, and the transfer mechanism named in the DPA is the ICO's UK Addendum to the EU standard contractual clauses.
• Sub-processors. The DPA gives a 30-day window to object to a new sub-processor. Somebody has to be receiving that notice for the window to mean anything.
• Portability. If you moved vendor next quarter, what would you rebuild? Prompts and business logic usually port. Anything leaning on a vendor-specific hosted feature does not.

Every vendor does this, and the answer is governance rather than switching

None of this is an argument against OpenAI, and we are not making one. We are an OpenAI Select Partner and we build on the platform.

It is also not an argument for moving to Anthropic, Google or anyone else. Anthropic retires models and deprecates APIs on its own schedule too, as does every serious vendor in this market. A firm that tells you their preferred model has solved this for you is selling you something.

The frontier moves at roughly a monthly cadence across all of them. That is the cost of the capability and a reasonable trade. What it demands in return is that someone owns the schedule.

In practice that means a named owner for each system, a named person who reads vendor deprecation notices, and a review at a fixed interval rather than when something breaks. Model choice is an engineering decision per workload, and one to revisit. It is not a hedge against this, because there is no vendor where this does not happen.

That is why we run AI implementation work on a model-neutral basis. We resell nothing and take no margin on your usage, so we have no reason to talk you into a platform or out of one, including the AI you already pay for.

The decision in front of you

Run the seven items above. Most of it is asking people questions and reading a dashboard, and an ops or IT lead can get through it in a week. If everything comes back clean, you have bought certainty for a week of effort.

If it does not come back clean, the usual finding is not one catastrophic thing. It is three orphaned systems, one Custom GPT holding something it should not, and nobody who can say what the spend buys.

The alternative is to have it done for you. We audit what is running, work out what breaks and when, then either hand you the plan or do the migration. Our OpenAI implementation and Claude implementation teams work on the same terms, and we will tell you if the honest answer is that nothing needs to change.

For how this sits against the alternatives, see the full guide to OpenAI for UK businesses.

Request a quote and we will start with what you already have running.