Custom GPTs Param em 11 de Dezembro. A OpenAI Escreveu o Checklist. Falta o Seu Inventário.

“Custom GPTs stop running.” É assim que a central de ajuda da OpenAI descreve o dia 11 de dezembro de 2026, data agendada para a aposentadoria dos custom GPTs que o FAQ cobre. O mesmo FAQ data o restante da sequência: aviso aos administradores em 11 de setembro, meta de migração em 17 de setembro (“a target, not a guarantee”) e fim planejado da criação de novos custom GPTs em 25 de setembro. Toda data vem com a mesma ressalva: “the dates are subject to change.”

Li a página do mesmo jeito que li o código de conduta de agentes da Microsoft: cláusula por cláusula, perguntando o que cada uma obriga uma empresa a fazer. A resposta é que esta é a primeira aposentadoria agendada de uma classe de artefato de agente construído pelo usuário que já vi documentada, e o documento que a aposenta é também o texto mais claro de governança de ciclo de vida para agentes que li de um fornecedor. Cortes datados. Migração restrita ao criador ou a um administrador. Duas permissões separadas para compartilhar e publicar. Integrações que não transferem e precisam ser avaliadas e reconstruídas. Um teste de comportamento antes da liberação ampla. Um redirecionamento que não concede acesso.

Se a sua organização deixou a equipe criar GPTs, você tem agora um problema de inventário, um problema de permissões e um problema de integração, com um relógio de aproximadamente doze semanas a partir de hoje.

O que migra, e o que fica para trás em silêncio

O FAQ descreve o resultado da migração em duas frases: “the GPT’s instructions become a skill within the new plugin. Connected apps are added to the plugin as apps.” Arquivos de referência são levados junto, mas precisam ser revisados.

Depois vem a lista do que não viaja. O modelo selecionado no GPT não é mantido; em workspaces Enterprise, valem os padrões do Enterprise. Sugestões de conversa e chats anteriores “may not copy.” E a linha que transforma uma migração em projeto de reconstrução:

“GPT custom actions do not transfer through the migration workflow. The person maintaining the workflow will need to assess and rebuild required integrations using a supported connector or custom MCP server.”

Custom actions são o ponto em que um GPT tocava um sistema fora do chat: uma API interna ou uma ferramenta de tickets. Essas chamadas foram configuradas por quem construiu o GPT, e nas implantações que já vi isso aconteceu sem revisão de engenharia, e o FAQ entrega a reconstrução para “the person maintaining the workflow.” Na maioria das empresas com que trabalho, ninguém ocupa esse cargo. O GPT tem um criador, que pode ter trocado de time, e usuários, que não fazem ideia de quais actions ele chama.

O FAQ então ajusta a expectativa sobre a versão reconstruída: “A rebuilt integration should not be assumed to provide every capability of the original action.” O fornecedor está dizendo, por escrito, que paridade está fora da promessa. É honesto, e é também o motivo pelo qual a lista de integrações precisa existir antes de dezembro.

Quem tem permissão para migrar

Só o criador de um GPT ou um administrador do workspace pode migrá-lo, e só quando duas condições valem: plugins habilitados no workspace e GPT publicado. Rascunhos não migram. Publicar não exige compartilhamento público, então um rascunho sem compartilhamento do qual um time depende em silêncio precisa ser publicado antes de ser movido.

A cláusula que eu pregaria na parede é esta: “Permission to use someone else’s GPT does not give you permission to migrate it.”

Uso e propriedade ficam separados. Um departamento que roda o trabalho diário em um GPT construído por um contratado que já saiu fica sem caminho para migrá-lo por conta própria; um administrador precisa fazer isso. Multiplique por todos os GPTs de um workspace grande e a fila do administrador vira o gargalo do programa inteiro.

O escopo segue a criação, e a consulta ao uso engana: “Public GPTs created in affected Enterprise workspaces are included in the Enterprise transition, even if you access them from a personal account or another workspace. What matters is where the GPT was created.” Um inventário montado a partir do que as pessoas usam deixa de fora GPTs criados em outro lugar, e um inventário montado a partir do que o workspace criou inclui GPTs que ninguém lá dentro usa mais.

Duas permissões, e uma política por cima

O modelo de permissões depois da migração é mais granular do que o que os clientes com quem trabalho rodavam para GPTs. Duas permissões administrativas separadas governam a distribuição: “Share plugins,” que cobre pessoas e grupos, e “Publish plugins to workspace,” que cobre o diretório. Usar um plugin migrado exige uma terceira coisa, a permissão “Use plugins,” mais uma política de workspace que permita o uso. A migração embutida dispensa “Upload plugins” e a permissão de MCP customizado.

Isso pesa no plano de liberação porque uma migração que dá certo tecnicamente ainda pode deixar o plugin invisível para os antigos usuários até alguém conceder a combinação certa. O administrador que migra e o administrador que publica podem ser pessoas diferentes, e a política que permite o uso de plugins pode ainda nem existir.

Tratamos do portão de revisão que uma skill deveria atravessar no texto sobre skills de agente em oito idiomas. As instruções do GPT migrado chegam como algo que o fornecedor também chama de skill, dentro de um plugin, então a revisão que a sua organização aplica a skills passa a valer para cada GPT migrado. Revisão zero para skills significa revisão zero para a migração.

Teste antes de liberar, porque o comportamento muda

O FAQ diz que o plugin migrado “may respond differently” e prescreve o teste mínimo: rodar “a familiar prompt” e “at least one harder case” antes de uma liberação mais ampla.

Dois fatos da página bastam, na minha leitura, para explicar por que o comportamento muda. O modelo selecionado não é mantido, então um GPT ajustado contra um modelo agora roda no padrão do workspace. E as custom actions somem até serem reconstruídas, então qualquer resposta que dependia de uma chamada ao vivo agora sai só das instruções. O teste prescrito é pequeno. O que importa é que o fornecedor está pedindo um, e que um status de “migrado” sem resultado de teste registrado é uma afirmação sem verificação.

O redirecionamento que não concede acesso

Depois da migração, o GPT original vira somente leitura, mas “remains usable until retirement.” Na aposentadoria, os links têm previsão de redirecionar para o substituto “for people who have access.” E então a frase que vai importar nos tickets de suporte de dezembro: “A redirect does not grant access to the plugin.”

Cada favorito e cada link de wiki interna que aponta para um GPT vai resolver para o plugin apenas para quem recebeu acesso sob o novo modelo. Todo o resto cai em um redirecionamento que leva a lugar nenhum. A concessão de acesso precisa ser feita por alguém com a permissão “Share plugins” ou “Publish plugins to workspace”, e os usuários ainda precisam de “Use plugins”.

O que isso é, para além de um fornecedor

Escrevemos sobre o risco de um fornecedor com botão de desligar que um governo pode apertar no texto sobre disponibilidade de modelo. Este é um risco diferente. Ele tem calendário e vem com checklist. Nada aqui é surpresa; a surpresa está apenas em que a maioria dos clientes que vejo não consegue executar o checklist, porque os três pré-requisitos nunca foram construídos:

Um inventário de todo GPT criado no workspace, incluindo os que são usados a partir de contas pessoais e de outros workspaces.
Um dono nomeado por artefato, alguém que consiga rodar a migração ou esteja autorizado a pedir a um administrador.
Um registro de quais custom actions cada GPT chama, e de qual sistema está do outro lado de cada chamada.

Esses três déficits ultrapassam os GPTs. Espero que skills, plugins e agentes de todo fornecedor recebam o mesmo tratamento: corte de criação, janela de migração, data de aposentadoria e um caminho de migração que carrega as instruções e descarta as integrações. O FAQ é um modelo para o ciclo de vida de qualquer classe de artefato de agente, e os controles corporativos que ele pressupõe são os mesmos em cada caso.

Faça isso agora: construa o inventário que o FAQ pressupõe que você tem

Comece nesta semana, com 11 de dezembro no calendário e o lembrete de que a OpenAI diz que a data pode mudar.

Levante a lista de todo GPT publicado ou em rascunho criado no seu workspace Enterprise. O local de criação é a regra de escopo, então filtre pelo workspace que criou, e deixe para depois a pergunta sobre quem usa.
Para cada um, nomeie o criador e verifique se ele ainda está na organização. Onde o criador saiu, designe um administrador agora, porque permissão de uso não dá permissão de migração.
Abra a configuração de cada GPT e liste as custom actions, com o sistema de destino de cada uma. Essa lista é o backlog da revisão de segurança, e o FAQ diz que as integrações de que você ainda precisa têm de ser reconstruídas por um conector suportado ou por um servidor MCP customizado.
Decida, por GPT, se ele migra, se é reconstruído do zero, ou se pode simplesmente parar de rodar em 11 de dezembro. Nem todo GPT merece reconstrução.
Para os que migram: publique os rascunhos primeiro, migre, rode o prompt familiar e o caso mais difícil, registre o resultado, e só então compartilhe o plugin com as pessoas ou grupos que precisam dele, ou publique no diretório do workspace, e confirme que eles têm “Use plugins” sob uma política que permita o uso.
Mantenha o inventário depois de dezembro. A próxima classe de artefato vai, espero, ganhar um FAQ de aposentadoria próprio, e as organizações que terminam este no prazo são as que já tinham a lista.

O fornecedor escreveu um bom documento de ciclo de vida. Cada cláusula pressupõe uma empresa que já tem o inventário e a lista de donos. A maioria não tem, e as doze semanas servem para descobrir isso.

Fontes

OpenAI. “Custom GPT retirement and migration FAQ.” Setembro de 2026. Todas as datas da página são declaradas como sujeitas a mudança; citações conforme a página lida em 18 de setembro de 2026.

A Victorino ajuda empresas a inventariar seus artefatos de agente, nomear donos e revisar integrações antes que a data de aposentadoria de um fornecedor faça isso por elas: contato@victorino.com.br | www.victorino.com.br