Why Every AI System Needs a Named Owner Before Launch

Somewhere in your company, a vendor is about to email someone about a model you depend on, and nobody on the project will read it. That is the case for naming one AI system owner before launch: a single person who answers for the system after the demo glow fades.

By the end you will have a short definition of the job, a service catalog entry that records it, and one weekly check that turns a surprise shutdown into a calendar item.

Why an AI system owner matters when vendors retire models

Vendors retire models on their own schedule. OpenAI's deprecations page lists a large batch of legacy GPT, o-series and fine-tuned snapshots shutting down on 23 October 2026, including gpt-4-0613, o1 and o3-mini. Snapshots of GPT-5 and o3 from 2025 follow on 11 December 2026. OpenAI says it emails customers who are actively using a deprecated model, with about six months' notice for generally available models and as little as two weeks for previews.

Google's Gemini API changelog says the 2.5 models are not deprecated and will be served "until further notice", but access is limited to users who have actively used them before. "Until further notice" is not a date you can plan around. Meanwhile the Gemini deprecations page lists gemini-2.5-flash-preview-tts and gemini-2.5-pro-preview-tts for shutdown on 17 November 2026.

An email is only as good as the inbox it lands in. Six months of notice is generous only if somebody reads the first message.

What an AI system owner is accountable for

One name per production system, not one per department. That person owns four things:

• Budget: the monthly token or GPU bill, and who gets told when it doubles.
• Deprecations: reading vendor notices and setting the migration date.
• Incidents: first call when the system misbehaves, and the author of the postmortem.
• Eval results: confirming the evals still pass after every model swap or prompt change.

Owners do not do all the work. They make sure someone does, and they are the person you ask when nobody seems to know. Add a named deputy so a holiday is not a gap.

The objection: our team owns it, and we have a RACI chart

A team is the right unit for doing work and the wrong unit for being accountable. When a retirement notice arrives, "the team" produces a thread in which everyone assumes someone else has it. A RACI chart drawn at kickoff freezes whoever was in the room that week, while the catalog entry is what someone actually looks up at 2am.

To be fair, a four-person team with a real on-call rotation can name its lead as the owner and be fine. The test is simple: when a deprecation email lands, can anyone say in ten seconds whose job it is?

Record the AI system owner in your service catalog

If you run Backstage, the owner already has a home. The descriptor format describes spec.owner as the entity that "bears ultimate responsibility for the component." A bare name defaults to a Group, so naming a person needs the full user:default/<name> reference. Use it.

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: support-triage-agent
  description: LLM agent that triages inbound support tickets
  annotations:
    example.com/model-id: <provider-model-id>
    example.com/deputy: user:default/<deputy-name>
  tags:
    - llm
    - production-ai
spec:
  type: service
  lifecycle: production
  owner: user:default/<owner-name>
  system: <your-system-name>

The example.com/* annotations are custom keys, so rename them to your own domain. Recording the model ID next to the owner is what lets someone match a retirement notice to a system. No Backstage? Put the same four fields (owner, deputy, model ID, notice inbox) in your launch checklist.

Give the owner a weekly deprecation check

Do not rely on email alone. OpenAI's models endpoint returns a shutdown_date field, which is null when no date has been announced.

curl -s https://api.openai.com/v1/models -H "Authorization: Bearer $OPENAI_API_KEY" |
  jq -r '.data[] | select(.shutdown_date != null) | [.shutdown_date, .id] | @tsv' |
  sort

This prints every model your key can see that has an announced shutdown date, soonest first. Compare the list with the model IDs in your catalog. Remember that null means "not announced", not "safe". Gemini publishes its dates on the deprecations page, so put that URL in the owner's calendar.

Start with one field this week

Pick the AI system closest to production and add owner and deputy to its launch checklist as required fields, with launch blocked if either is blank. Then send the owner a list of every model ID the system calls, with any shutdown dates attached.

A vendor retirement notice is a deadline with your system's name on it, and in production someone's name has to be on it too.