A imagem que a IA gerou não abre mais: os quatro relógios que decidem se ela ainda existe

Quando a imagem que a IA gerou não abre mais, "sumiu" são três coisas diferentes

Você gerou o retrato ontem à noite, fechou a aba e foi dormir. Hoje volta na conversa para baixar o arquivo em resolução decente e encontra um retângulo cinza, um botão de download que devolve erro, ou nada. Quando a imagem que a IA gerou não abre mais, a primeira reação é sempre recarregar a página e limpar o cache, e na maior parte dos casos isso não resolve: o que aconteceu não é falha do seu navegador, é prazo publicado.

Antes de qualquer conserto, separe o que aconteceu em três estados, porque cada um deixa uma sobra diferente:

• A imagem nunca chegou ao seu aparelho. Ela foi renderizada na tela e você a viu, mas o arquivo nunca desceu para a pasta de downloads. Nesse estado o que existe é uma imagem na memória do navegador, e ela morre quando a sessão morre.
• O arquivo existe, mas o endereço morreu. O objeto continua guardado no armazenamento do fornecedor e o que expirou foi a autorização de acesso. Aqui a foto quase sempre volta, e volta sozinha, com um endereço novo.
• A superfície onde a imagem morava foi embora. A conversa foi apagada, ou o prazo de retenção da atividade venceu. Nesse caso não existe endereço novo para assinar, porque não existe mais o lugar de onde ele sairia.

A central de ajuda do fornecedor cobre esse território com dois nomes de erro e uma instrução. Na página de solução de problemas de mensagens de erro, aberta em 30/08/2026, os erros aparecem com estes nomes: "Falha no download" e "Arquivo não encontrado". E a orientação vem literal, na própria versão em português: "Verifique se o arquivo foi gerado recentemente, pois os arquivos gerados pelo ChatGPT expiram rapidamente" (no original em inglês, "files generated by ChatGPT expire quickly"). A mesma página traz um teto declarado de 512 MB para o arquivo baixado.

Repare no que a fonte não faz: ela não publica o número. "Rapidamente" é a palavra que a empresa escolheu. Quem publica prazo é a documentação de outras camadas, e é de lá que vêm os números deste artigo. Nas dez páginas e discussões que medimos em 30/08/2026, entre resultados de busca, discussões do fórum oficial de desenvolvedores e reportagens em português, a expressão "60 minutos" apareceu zero vez, "48 horas" zero, "72 horas" zero e "link assinado" zero, contando português e inglês. É uma amostra de conveniência de quatro consultas, num dia, a partir de um endereço no Brasil.

A tabela abaixo é a triagem por sintoma. Encontre o seu caso na primeira coluna antes de tentar qualquer coisa.

Os quatro relógios, e quem publica cada um

A confusão vem de tratar como evento único o que é uma corrida de quatro cronômetros independentes. Eles não começam juntos, não terminam juntos e não pertencem à mesma empresa.

Relógio 1: o link

A referência da API de imagens da OpenAI, lida em 30/08/2026, publica o prazo com todas as letras no campo response_format: "URLs are only valid for 60 minutes after the image has been generated". Traduzindo: as URLs valem apenas 60 minutos depois de a imagem ser gerada. Só que essa frase tem endereço certo. Ela vale para os modelos dall-e-2 e dall-e-3, na camada de API. Não é regra do aplicativo de conversa, e estender esse número para o chat é o erro mais comum da primeira página do Google.

A mesma página fecha uma porta que quase ninguém percebeu: para a família GPT image o campo de URL é "Unsupported for the GPT image models", porque esses modelos "always return base64-encoded images". Existe, portanto, uma família inteira em que não há endereço para expirar, e tampouco para reabrir depois: a imagem chega dentro da própria resposta.

Relógio 2: o arquivo no fornecedor

A documentação da Files API do Gemini publica o prazo e o tamanho na mesma frase: "The Files API lets you store up to 20 GB of files per project, with a per-file maximum size of 2 GB. Files are stored for 48 hours". A versão em português da mesma página diz "os arquivos são armazenados por 48 horas", e outro trecho reforça que eles são apagados automaticamente depois desse prazo. Do lado da OpenAI existe um paralelo: a política de retenção de conversas e arquivos declara que arquivos não salvos na Biblioteca podem expirar por conta própria, e que em contas Enterprise expiram em 48 horas, salvo período diferente.

Relógio 3: a conversa

Aqui os dois fornecedores divergem bastante. A ajuda da OpenAI escreve que "chats are saved to your account until you delete them manually", isto é, a conversa fica até você apagar. Apagou, a página é dura: "once you delete a chat, you cannot recover it", e ela é agendada para exclusão permanente dos sistemas em até 30 dias, com as duas exceções que a própria página lista: conversa já desidentificada e obrigação legal ou de segurança que force retenção maior. Nos apps do Gemini, a página de privacidade da atividade descreve exclusão automática configurável, com as opções de "18 meses (padrão), 3 meses, 36 meses ou indefinido". E existe um relógio muito mais curto na mesma página: conversas momentâneas, ou conversas feitas com a configuração "Manter Atividade" desativada, ficam retidas na conta por 72 horas. É o prazo mais curto deste artigo e explica boa parte dos "voltei e não tinha nada".

Relógio 4: a superfície onde a imagem mora

Este é o que não tem prazo próprio, e por isso passa despercebido. A página de ajuda sobre imagens dentro da ferramenta de conversa declara que "all images you create with ChatGPT are automatically saved under Images": tudo o que você cria é salvo numa galeria própria. Boa notícia, até você ler a frase seguinte da mesma página, que é assunto de uma seção inteira mais adiante.

E existe um quinto, que é o ponto do artigo: o arquivo que já está no seu aparelho não tem relógio nenhum. É a única cópia sobre a qual nenhum fornecedor publica prazo, porque nenhum fornecedor manda nela. O resto deste texto existe para você chegar nessa cópia antes de qualquer um dos quatro cronômetros zerar.

O link não é o arquivo: como ler a hora da morte dentro do endereço

Um link assinado não é um atalho para o arquivo: ele é uma autorização temporária escrita dentro do próprio endereço. A documentação de presigned URL da Cloudflare R2 descreve o mecanismo em uma linha: o endereço autoriza qualquer pessoa que o tenha a executar uma operação específica "until the URL expires", até que ele expire. E publica a faixa permitida: "Expiry: Timeout from 1 second to 7 days (604,800 seconds)". O exemplo publicado na própria página carrega os dois parâmetros que interessam, X-Amz-Date=20251201T180512Z e X-Amz-Expires=3600.

Ou seja: na maioria dos casos dá para descobrir a hora da morte do link sem abrir o link. Data de assinatura mais validade em segundos é toda a conta. O script abaixo faz isso, só com biblioteca padrão do Python 3, sem rede:

# relogio_do_link.py  ·  le a validade dentro do proprio endereco, sem abrir o link
import sys, datetime as dt
from urllib.parse import urlparse, parse_qs

q = parse_qs(urlparse(sys.argv[1]).query)
g = lambda k: (q.get(k) or [None])[0]

if g("X-Amz-Date") and g("X-Amz-Expires"):          # padrao S3, R2, MinIO, Backblaze
    ini = dt.datetime.strptime(g("X-Amz-Date"), "%Y%m%dT%H%M%SZ")
    ini = ini.replace(tzinfo=dt.timezone.utc)
    fim = ini + dt.timedelta(seconds=int(g("X-Amz-Expires")))
elif g("se"):                                       # janela explicita st (inicio) / se (fim)
    fim = dt.datetime.fromisoformat(g("se").replace("Z", "+00:00"))
else:
    print("Nenhum prazo dentro da URL: ou o link e aberto,")
    print("ou o prazo mora no servidor e daqui ninguem consegue ler.")
    raise SystemExit(1)

agora = dt.datetime.now(dt.timezone.utc)
resta = (fim - agora).total_seconds()
print("Morre em .:", fim.isoformat())
print("Situacao .:", "VIVO" if resta > 0 else "JA EXPIROU", "(%.1f h)" % (abs(resta) / 3600))

Salve o texto acima e rode python3 relogio_do_link.py "<endereço>" com o endereço entre aspas. Por que cada trecho existe: o parse_qs separa os parâmetros sem baixar nada, então funciona mesmo com o link já morto; o primeiro ramo cobre o formato AWS SigV4, padrão em S3, R2, MinIO e Backblaze; o segundo cobre a janela explícita de início e fim, lendo o fim dela, que é o que decide se o endereço ainda vale, escrita como st e se; e o ramo final é o mais honesto do script, porque avisa que não há o que ler em vez de chutar um prazo.

A validação foi contra o exemplo publicado pela própria Cloudflare: assinatura em 01/12/2025 às 18:05:12 UTC, validade de 3.600 segundos, e o script devolve 2025-12-01T19:05:12+00:00, que bate com a documentação. Contra um endereço comum, sem assinatura, ele avisa que não há prazo dentro da URL. A restrição de uso é essa: quando o serviço guarda o prazo do lado do servidor, o que é o caso de boa parte das interfaces de conversa, não existe nada legível no endereço.

O que isso muda no diagnóstico

Se o relógio que venceu foi o do link, o arquivo quase certamente continua vivo. É a diferença entre desistir e recarregar a página. Para ser concreto com o que dá para conferir no código: aqui no fotoslinkedin o endereço da foto gerada é assinado e vale 24 horas; passado esse prazo o endereço morre, mas o arquivo continua no armazenamento e a página assina um endereço novo quando você volta. Ele só desaparece de verdade quando você apaga a geração. É exemplo de mecanismo, não recomendação: o que muda de produto para produto é o número de horas.

O caso oposto também é mecanismo. Quando o modelo devolve a imagem codificada em base64, ela chega dentro da resposta e não existe endereço nenhum, nem vivo nem morto. Codificar assim custa bytes, e o custo é fixo: mais 33,33%. Medimos em três imagens reais deste blog e deu idêntico nas três: 1.560.187 bytes viram 2.080.252; 1.487.773 viram 1.983.700; 705.578 viram 940.772. É aritmética de codificação e não diz nada sobre velocidade nem custo de rede. A consequência para você é uma só: nessa família, a única cópia durável é a que você salvou.

Vale registrar como esse número circula errado. No fórum oficial de desenvolvedores, a discussão sobre a validade da URL de imagem está aberta desde fevereiro de 2023 e traz duas respostas que se contradizem na mesma página, uma chutando cerca de uma hora e outra afirmando duas. Ninguém abre a referência.

Guardado não quer dizer recuperável

Se o fornecedor ainda tem o arquivo por 48 horas, ele deveria poder devolver, certo? A documentação responde que não, e responde com uma frase só.

Na página da Files API, logo depois de dizer que os arquivos ficam armazenados por 48 horas, vem o trecho decisivo: "During that time, you can use the API to get metadata about the files. However, you can't download user-uploaded files. You can download files generated by models, such as videos, using the files.download method." Em português, e com as duas metades no lugar: durante esse período você consegue obter metadados dos arquivos, mas não consegue baixar arquivos enviados pelo usuário; arquivos gerados por modelos, como vídeos, esses sim podem ser baixados por um método próprio.

As duas metades importam, e citar só a primeira inverte o sentido. O que você mandou para lá, a selfie que serviu de referência, fica guardado e não volta. O que a ferramenta criou tem caminho de download declarado. A assimetria não é acidente: a documentação separa entrada e saída de propósito.

Do lado da OpenAI existe um comportamento vizinho. A política de retenção fala em fluxos de upload transitórios ou não suportados e escreve que esses arquivos podem expirar independentemente da configuração de retenção da conversa, com 48 horas declaradas para contas Enterprise. Repare no cuidado da frase original: o número está amarrado a um tipo de conta, e generalizar para a sua conta pessoal seria inventar spec.

A leitura prática é curta: contar com o armazenamento do fornecedor como backup é apostar em duas coisas ao mesmo tempo, que o prazo não venceu e que existe porta de saída documentada. Na maioria das combinações uma das duas falha. Para entender o percurso do arquivo depois do envio, o blog já publica para onde a sua foto vai quando você usa uma ferramenta de IA; aquele artigo responde "para onde", este aqui responde "por quanto tempo continua alcançável".

A superfície onde a imagem mora tem a regra oposta à que você imagina

Este trecho não exige interpretação nenhuma: são duas frases publicadas pela mesma empresa, em duas páginas de ajuda, lidas no mesmo dia.

Sobre o arquivo que você enviou, a política de retenção diz: "Chats and Library files are managed separately: deleting a chat does not delete files saved to Library." Conversas e arquivos da Biblioteca são gerenciados separadamente, e apagar uma conversa não apaga os arquivos salvos lá. A própria página condiciona: vale quando a Biblioteca existe para a sua conta ou para o seu espaço de trabalho.

Sobre a imagem que a ferramenta criou, a página de imagens diz: "To delete an image from My images, delete the conversation where the image was created." Para excluir uma imagem de "Minhas imagens", exclua a conversa onde ela foi criada.

Junte as duas e o resultado é o contrário do que quase todo mundo assume: apagar a conversa não leva embora o que você subiu, mas é o caminho documentado para levar embora o que foi gerado. É a resposta direta para o "apaguei o chat sem querer e a foto foi junto". Não foi azar nem falha: é a única rota de exclusão que a página descreve para a imagem criada.

Uma ressalva de leitura, porque aqui é fácil exagerar. Essas páginas documentam superfícies e rotas de exclusão; nenhuma afirma que a imagem gerada é destruída no mesmo instante. O seguro é ficar no que está escrito: a única rota de exclusão documentada para a imagem criada passa por apagar a conversa, e a página do arquivo enviado documenta exatamente o oposto.

Some a isso o relógio da conversa e o desenho fecha. Conversa apagada não pode ser recuperada e é agendada para exclusão permanente dos sistemas em até 30 dias; conversa momentânea, ou com "Manter Atividade" desligada nos apps do Gemini, tem retenção declarada de 72 horas. Nos dois casos a galeria de imagens vai junto, porque ela é uma vitrine da conversa e não um cofre independente.

Esse eixo é diferente de outro que o blog já cobre: quem se preocupa com quem consegue ver a imagem que você acabou de gerar está tratando de visibilidade. Aqui o assunto é durabilidade, e as duas perguntas são independentes: uma imagem pode estar perfeitamente privada e mesmo assim deixar de existir para você.

Os cinco passos antes de fechar a aba, na hora em que a imagem aparece

Tudo o que veio até aqui converge para um hábito curto, de menos de um minuto, que leva a imagem para a única superfície sem prazo publicado: o seu aparelho.

1. Baixe no tamanho original, não a miniatura. O nome do controle importa, porque ele é literal: na ajuda sobre gerar e editar imagens nos apps do Gemini, a instrução é passar o cursor sobre a imagem e clicar em "Baixar no tamanho original"; a mesma página declara que a resolução muda conforme o plano de IA do Google associado à conta, entre 1K e 2K. Do outro lado, a ajuda sobre imagens da OpenAI lista copiar, salvar para baixar no dispositivo e compartilhar. Botão direito e "salvar imagem" costuma pegar a versão exibida na tela, que é menor.
2. Renomeie com a data na frente. Algo como 2026-08-30-retrato-blazer-azul-v3. A data na frente ordena a pasta sozinha, e o sufixo de versão evita que a quarta tentativa sobrescreva a segunda, que era a boa.
3. Guarde na mesma pasta do pedido que gerou a imagem. Arquivo sem o texto que o criou vira um retrato órfão: você gosta dele e não sabe refazer nada parecido.
4. Abra o arquivo fora da ferramenta. No visualizador do sistema, não na aba do navegador: é o teste que confirma que existe arquivo, e não só imagem desenhada na tela. Confira as dimensões; se vier bem menor do que você esperava, baixou a miniatura.
5. Só então feche a aba. Enquanto a aba está aberta você ainda tem uma sessão viva, e sessão viva é a última chance barata de recuperar qualquer coisa.

O passo 3 tem um vizinho que já é dono do assunto aqui no blog: guardar a imagem junto do pedido é parte de o kit de reprodução que fica ao lado da foto aprovada, que reúne o que permite recomeçar de perto numa variação. Não vou repetir a lista aqui.

E o que este procedimento não é: ele não substitui backup. Um arquivo na pasta de downloads que você limpa todo mês continua vulnerável, agora à sua própria faxina. Se o retrato vai para um perfil profissional, mande a pasta para a nuvem que você já usa.

Quando só sobrou o que está na tela: a rota do print e o que ela custa

Existe um estado intermediário: a imagem aparece grande e nítida na conversa e nenhum botão de download funciona. Sobrou a renderização, e a captura de tela vira a única saída. Ela funciona, e é cara, com o preço medido em pixels.

O blog já publicou essa conta, e ela vale ser lida antes de você decidir: a conta de quanto rosto sobra num print mostra que uma cabeça que ocupa cerca de 1.890 px de altura no arquivo original cai para algo em torno de 524 px quando a foto é capturada em tela cheia, e para cerca de 131 px quando o print pega a miniatura. Os números são daquele artigo e ficam com ele; o que interessa aqui é a ordem de grandeza.

A regra de decisão é simples. Se a imagem está sendo exibida grande na tela e o destino é pequeno, uma foto de perfil circular, por exemplo, o print resolve e ninguém vai notar. Se a imagem está pequena na tela, ou o destino é qualquer coisa que amplia, gerar de novo sai mais barato do que aceitar um arquivo que já nasce com um terço da resolução. Um detalhe operacional: capture com o navegador em zoom de 100% e a imagem aberta em tamanho cheio, e não a conversa inteira.

O que este artigo não resolve

Quatro coisas ficam explicitamente de fora daqui:

• Gerar de novo não devolve a mesma foto. Se você perdeu o arquivo e recorreu ao mesmo pedido, o que volta é uma variação nova. O motivo e o que fazer estão em por que o mesmo pedido não repete a mesma foto, que é dono desse assunto. Este artigo trata de perder o arquivo que já existiu, não de reproduzi-lo.
• Quantas imagens você consegue gerar é outro objeto. Cota de geração, esgotamento e troca de ferramenta ficam em o orçamento de tentativas antes de a ferramenta parar. Lá a imagem ainda não existe; aqui ela já existiu.
• Imagem retirada por decisão de um destino é um problema diferente. Quando uma plataforma remove a sua foto do perfil, houve avaliação humana ou automática e existe caminho de recurso, o que está descrito em quando foi o destino que retirou a sua foto. Neste artigo ninguém decidiu nada: venceu um prazo.
• Apagar a sua foto porque você quer é o oposto disto. Pedir a exclusão do que você enviou para uma ferramenta é um percurso próprio, com formulário, prazo de resposta e base legal. O blog ainda não tem esse artigo, e por isso ele está citado aqui sem link, para não mandar você para uma página que não existe.

Existe ainda a validade das próprias fontes, e essa é a ressalva mais importante. Cada página citada aqui diz o que diz na data em que foi lida, 30/08/2026. Política de retenção muda, prazo de API muda, nome de menu muda. Antes de decidir sobre um arquivo que importa, abra a página do seu fornecedor e confira o número. Na dúvida, o caminho seguro nunca muda: baixe e guarde.

Resumo e próximos passos

A imagem gerada não some num lugar só, e é por isso que "limpe o cache" quase nunca resolve. São quatro relógios, cada um com dono, prazo e sobra próprios. O do link é o mais benigno: 60 minutos publicados para dall-e-2 e dall-e-3, faixa de 1 segundo a 7 dias no padrão de link assinado, e o arquivo em geral continua no servidor quando ele vence. O do arquivo no fornecedor são as 48 horas da Files API do Gemini, com a ressalva de que nem dentro do prazo o arquivo enviado volta. O da conversa é o mais destrutivo: apagou, não recupera, com exclusão dos sistemas em até 30 dias, e nos apps do Gemini o padrão de 18 meses cai para 72 horas em conversa momentânea. E o da superfície de imagem é o mais contraintuitivo, porque a rota documentada para excluir a imagem criada é apagar a conversa, enquanto o arquivo enviado sobrevive a exatamente essa ação.

O quinto não tem relógio e é o único que depende de você: o arquivo baixado no seu aparelho. Se levar só uma coisa daqui, leve os cinco passos antes de fechar a aba: baixar no tamanho original, renomear com a data, guardar junto do pedido, abrir o arquivo fora da ferramenta e só então fechar.

Para colocar isso num contexto maior, de qual ferramenta usar, o que pedir e como avaliar o que voltou, comece por o guia de foto profissional com IA em 2026, que é o mapa deste bloco do blog. Se o seu problema for a resolução do que sobrou, o caminho é entender o que cada envio tira do arquivo. E se a próxima pergunta for sobre quantas tentativas você ainda tem, o artigo sobre quantas fotos a ferramenta gera antes de parar responde essa.