What OpenAI's retirement of GPT-4o, GPT-4.1 and its fine-tuning service means for large German enterprises — and what you actually bought when you paid to train a model.

OpenAI's notice against its own six-month policy and Microsoft's Azure schedule. Original graphic by neuland.ai; sources in notes 2, 3 and 5.

On 14 October 2026, OpenAI told developers that GPT-4o, GPT-4o mini, GPT-4.1 and GPT-4.1 mini will be removed from its API on 14 January 2027 — and that the custom versions companies paid to train on their own data will be switched off on the same day. The recommended replacement, GPT-6 Luna, cannot be fine-tuned at all, and OpenAI is closing its fine-tuning service to new jobs on 6 January. Its own policy promises at least six months' notice for models like these. Customers got thirteen weeks, and in most German enterprises those weeks include Christmas, the year-end change freeze and the annual budget cycle. If you paid to train a model on your own data, this is the week you find out what you actually bought.

This series has spent a year arguing that the value in enterprise AI sits in the layer around the model, not in the model itself.¹ The retirement notice is the most practical illustration of that argument so far, because it shows exactly which parts of an AI investment belong to the customer and which never did.

A fine-tune at someone else's provider is not an asset. It is a lease with no fixed term, and the landlord has just set one.

What OpenAI actually announced

The entry on OpenAI's deprecations page is short. Five model versions — two GPT-4o snapshots, GPT-4o mini, GPT-4.1 and GPT-4.1 mini — leave the API on 14 January 2027, with gpt-6-luna named as the replacement for all of them. One sentence carries most of the weight: fine-tuned versions of these models "follow the same shutdown schedule as their underlying base models".² There is no grace period for custom models.

Three related dates make it worse. OpenAI has been winding down self-serve fine-tuning since May: organisations that had never fine-tuned lost access first, organisations without recent fine-tuned usage followed in July, and from 6 January 2027 no customer can create new fine-tuning jobs at all.³ Audio and realtime variants follow on 20 January, and transcription models, including Whisper, on 26 February.⁴ And GPT-6 Luna — cheap, at around ten cents per million input tokens, and the smallest model in its family — does not support fine-tuning, so a fine-tuned GPT-4o or GPT-4.1 has no fine-tuned successor to move to.⁴

For companies using these models through Microsoft, the dates differ. Microsoft's own retirement schedule lists the base models leaving Azure on 14 April 2027, with fine-tuned deployments running until October 2027.5 That buys time. It does not change the destination.

Three months under a six-month policy

OpenAI's deprecations page sets out its notice periods: at least six months for generally available models, at least three for specialised variants, as little as two weeks for previews — unless safety or compliance concerns require faster action, in which case it promises as much notice as reasonably possible.² GPT-4o and GPT-4.1 were generally available. They got three months. No safety or compliance reason appears on the page.

Two weeks earlier, OpenAI had given two newer models, GPT-5.1 and GPT-5.3-codex, a shutdown date six months out.⁵ So the newer models received the runway the policy describes, and the older ones — the ones enterprises had the most time to build on, and to fine-tune — received half of it.

None of this is new. In July 2023, OpenAI announced that its older completion models would be retired in January 2024, and that customers who wanted to keep using models fine-tuned on their own data would have to train new ones on newer bases. It acknowledged, in its own words, that migrating off of models fine-tuned on your own data "is challenging".⁶ It is about to be challenging again, and this time there is no newer base to retrain on.

You paid to train it — you never owned it

It is worth being precise about what a fine-tune is, because the precision is where the cynicism comes from.

A fine-tuned model is a base model plus a set of learned adjustments — a delta — produced by training on your examples. When you fine-tune through a provider's API, three things happen. You upload your data. The provider trains the delta on its infrastructure. And the provider keeps the result: you get an endpoint, a model identifier and a bill, but never the weights. The base the delta depends on belongs to the provider, and so does the decision about how long it exists.

So when an enterprise "built a proprietary model" on GPT-4o — tuned to its product catalogue, its claims language, its legal clauses, its tone in German — what it actually built was a configuration of someone else's asset, rented by the token, with an expiry date it did not control and has now been told.

What the enterprise does still own is less glamorous, and more valuable than it has been treating it: the curated training data, the labelled examples, the evaluation set that proved the fine-tune worked, and the process knowledge behind all three. The most valuable thing a fine-tuning project produced was never the model. It was the data and the tests — the only parts you actually kept.

Figure 1. What a fine-tuning project through a provider's API leaves behind. Original diagram by neuland.ai.

Thirteen weeks in a German enterprise

A start-up can swap a model identifier over a weekend. A large German enterprise cannot, and not because its engineers are slower. In a regulated, co-determined organisation, a model change sets off several pieces of work, and every one of them has to finish before the same date.

Technical migration. Code, configuration and integration tests, against a replacement that, as the next section shows, behaves differently.

Re-evaluation. Every process that ran on a fine-tune has to be tested again on the company's own cases — without the fine-tune, because there is no fine-tuned successor.

Re-validation. Banks and insurers supervised by BaFin are expected to validate the algorithms they use in decision-making; pharmaceutical and medical-technology companies operate computerised systems under GxP change control.⁷ A forced change of the underlying model restarts that work.

Co-determination. Many AI deployments in German companies are covered by works agreements, because technical systems that can monitor employee behaviour or performance are subject to co-determination.⁸ Depending on how an agreement is written, changing the model inside an agreed system may need the works council's involvement again.

Documentation. Data protection impact assessments may need updating, and for systems that will fall under the high-risk rules of the AI Act from December 2027, a change of model is exactly the kind of modification that has to be assessed and documented.⁹

Procurement and budget. Many large companies run annual budget cycles, approval boards and a change freeze over the turn of the year. A notice issued in mid-October with a deadline in mid-January lands across all three.

Figure 2. Six workstreams in a regulated, co-determined enterprise. Illustrative; see notes 7 to 9. Original diagram by neuland.ai.

Luna is not a drop-in replacement

The replacement model is cheaper per token, by a wide margin. It is not the same kind of model. GPT-6 Luna reasons by default, at a medium effort setting; developers migrating to it report that function calling through the Chat Completions interface only works when reasoning is switched off, and that some request parameters older models accepted are now rejected.⁴ Reasoning models generally bill their reasoning as output, so the number that matters is cost per completed task, not price per token — and that has to be measured, not assumed.

Most importantly, Luna cannot be fine-tuned. The behaviour an enterprise paid to train into GPT-4o has to be recovered some other way — with prompts, retrieval and examples — or not at all. For many processes that will be fine; newer models follow instructions better than older ones did. For the processes where the fine-tune existed precisely because prompting was not enough, it is a regression with a deadline.

The cynical reading, and why it does not matter whether it is true

There is an obvious cynical reading of all this. A provider with enormous infrastructure commitments has every reason to consolidate traffic onto its newest models, to stop supporting a customisation path that ties capacity to old ones, and to move customers onto a family where it controls the roadmap more tightly. That reading may be unfair. OpenAI has not explained the shortened notice, and newer models are genuinely better at many tasks.

But it does not matter whether the cynical reading is true. What matters is that an enterprise's core processes can be rescheduled by a page on someone else's website, with whatever notice that page decides to give. This series has now documented a model suspended by an export directive, a model pulled before launch, an open-weight supplier closing its best model, and now a provider retiring the models — and the customisation — that enterprises had built on most heavily.¹⁰ The pattern is not malice. It is dependency, and dependency has a calendar you do not own.

What survives a retirement

The useful lesson is architectural, and it is not "never use American models". It is: put the things you paid for where a retirement cannot reach them.

Keep the training data and evaluation sets behind every fine-tune, and treat them as the asset they are. Keep domain knowledge in a knowledge layer you control — documents, an ontology of your business, retrieval with permissions — rather than baking it into a provider's weights. When a process genuinely needs a specialised model, train it on open weights you hold; the adapter is still tied to its base, but the base never disappears unless you retire it. And make the model behind each process a routing decision, so that a provider's deprecation becomes a configuration change rather than a programme.¹¹

Figure 3. Rented and portable specialisation. Original diagram by neuland.ai.

The retirement readiness check

Tick each statement that is true for your organisation today. In Word, click the box to tick it.

Your score:

Where neuland.ai stands on this

The neuland.ai HUB is built on the assumption that models will come and go, because they do. Domain knowledge lives in the customer's knowledge layer — ontology, documents, permissions — outside any single model. Routing is decided per task under the customer's policy, across open-weight models hosted in house, such as Mistral, Nemotron, GLM and Qwen, and proprietary models such as Claude and GPT where the customer allows them, so replacing a retired model is a change of route, not a rebuild. Evaluation runs against the customer's own cases, so a replacement can be tested in days. And where a process needs a specialised model, it can be trained on open weights the customer holds, on the customer's infrastructure.¹²

This is also the answer to the question we are now hearing from IT leaders who have fine-tuned models in production: what do we do before 14 January? Inventory every model you depend on, secure the data and tests behind every fine-tune, and move the knowledge out of the model and into a layer you own. The deadline is OpenAI's. The architecture should be yours.

Personal take

This piece is critical of OpenAI, and the facts support the criticism: a shortened notice without a stated reason, under a policy that promises longer, applied to the models enterprises had built on most. But the larger target is the way enterprise AI has been bought. "We fine-tuned our own model" has been presented in a great many steering committees as building a proprietary asset. It was renting a configuration.

I do not think the answer is to avoid frontier providers; they make excellent models, and we use them. The answer is to stop putting the things you cannot afford to lose — your knowledge, your tests, your specialisation — inside things you do not control. The company that kept its data, its evaluation set and its knowledge layer will spend January on a routing change. The company that kept only an endpoint will spend it explaining to its board why the model it paid for no longer exists.

We at neuland.ai would rather our customers own the parts of their AI that matter, so that the next retirement notice is a configuration change and not a crisis.

[1] Series articles available at https://neuland.ai/en/resources/insights.

[2] OpenAI, API deprecations page, https://developers.openai.com/api/docs/deprecations, entry of 14 October 2026 (GPT-4 series model deprecations: gpt-4o-2024-08-06, gpt-4o-2024-11-20, gpt-4o-mini-2024-07-18, gpt-4.1-2025-04-14 and gpt-4.1-mini-2025-04-14, shutdown 14 January 2027, recommended replacement gpt-6-luna), and the notice-period section of the same page.

[3] OpenAI deprecations page entries on fine-tuning of 7 May 2026, 2 July 2026 and the scheduled end of new fine-tuning jobs on 6 January 2027, as quoted by Developers Digest (October 2026) and reported by Startup Fortune (8 May 2026).

[4] DataNorth (15 October 2026), FourWeekMBA and DEV Community (October 2026) on GPT-6 Luna pricing, default reasoning behaviour and the absence of fine-tuning support; Zentor (October 2026) on function calling requiring reasoning effort set to none; DEV Community (October 2026) on the retirement of audio and realtime variants on 20 January 2027 and transcription models including Whisper-1 on 26 February 2027.

[5] Microsoft's model retirement schedule as reported by DEV Community (October 2026): base snapshots retiring on 14 April 2027; fine-tuned deployments until 1 October 2027 for gpt-4o and gpt-4o-mini and 14 October 2027 for gpt-4.1. On the six-month shutdown date given to gpt-5.1 and gpt-5.3-codex on 1 October 2026, see the same report, citing OpenAI's deprecations page.

[6] OpenAI, "GPT-4 API general availability and deprecation of older models in the Completions API", July 2023, https://openai.com/blog/gpt-4-api-general-availability.

[7] BaFin, "Big Data und künstliche Intelligenz: Prinzipien für den Einsatz von Algorithmen in Entscheidungsprozessen" (June 2021); EudraLex Volume 4, EU GMP Annex 11 (Computerised Systems).

[8] Betriebsverfassungsgesetz (BetrVG), § 87(1) no. 6, on co-determination over the introduction and use of technical equipment designed to monitor the behaviour or performance of employees. Whether a change of model requires renewed involvement of the works council depends on the agreement in place; this is not legal advice.

[9] Regulation (EU) 2024/1689 (AI Act), Article 3(23) on substantial modification; under the provisional Digital Omnibus agreement of 7 May 2026, Annex III high-risk obligations apply from 2 December 2027.

[10] See earlier pieces in this series on flexibility as an architectural property, on where an agent's limits actually live, and on the AI capital web.

[11] See earlier pieces in this series on distillation and customer-specific small models, and on the definition of an enterprise AI orchestration and management platform.

[12] neuland.ai HUB: customer-owned knowledge layer, ontology and permissions; per-task model routing under customer-set policy across self-hosted open-weight and proprietary models; evaluation against customer workloads; training of specialised models on open weights held by the customer; deployment on premises, in a European sovereign cloud or air-gapped. neuland.ai AG retains responsibility for content quality and clean delivery of results across all customer engagements.