Gemini API aceita arquivos via GCS, URLs assinadas e payload inline maior

O Google ampliou as formas de entrada de arquivos na Gemini API, com suporte a objetos no Google Cloud Storage, URLs HTTP públicas ou assinadas e um limite maior para dados enviados inline.¹ A mudança parece operacional, mas toca um ponto central para quem tenta colocar aplicações multimodais em produção: mover bytes costuma ser uma das partes mais frágeis, caras e pouco elegantes do fluxo.

Antes, muitos times precisavam baixar arquivos de um storage já existente, reenviar para a Files API e lidar com uma janela de persistência limitada. Isso é aceitável em protótipos, mas cria fricção em pipelines que analisam vídeo, áudio longo, PDFs extensos, imagens de alta resolução ou documentos corporativos mantidos em buckets próprios.

Arquivos passam a ficar onde já estão

O suporte a Google Cloud Storage permite registrar arquivos já presentes em buckets, sem copiar o conteúdo para outro armazenamento intermediário.¹ Para empresas que padronizaram ingestão, retenção, auditoria e permissões em GCS, a vantagem é clara: a camada de IA pode consumir o dado no local em que ele já é governado.

Esse desenho reduz duplicação e simplifica trilhas de controle. Em vez de criar uma segunda cópia temporária para cada chamada, a aplicação passa a referenciar o objeto existente. Ainda há requisitos de autenticação e autorização, mas eles se aproximam do modelo que equipes de plataforma já usam para controlar acesso a buckets e contas de serviço.

As URLs externas ampliam a mesma lógica para fora do ecossistema Google. Arquivos públicos podem ser passados diretamente, e URLs assinadas permitem acesso temporário a conteúdo privado em serviços como AWS S3, Azure Blob Storage ou outros provedores compatíveis com esse padrão.¹ A Gemini API busca o conteúdo durante o processamento, evitando que o backend da aplicação funcione como ponte manual entre storages e modelo.

O limite inline maior ajuda protótipos e fluxos rápidos

O limite de dados inline sobe de 20 MB para 100 MB, com variações conforme o tipo de dado e codificação em base64.¹ Esse aumento não elimina a necessidade de storage para cargas grandes, mas melhora muito a ergonomia de testes, aplicações em tempo real e experiências em que um arquivo moderado precisa viajar junto com a requisição.

Para desenvolvedores, a escolha passa a ser mais explícita. Dados pequenos ou temporários podem seguir inline. Arquivos recorrentes e maiores podem ser registrados no GCS. Conteúdo distribuído em outros clouds pode entrar via URL assinada. Essa matriz reduz a tendência de resolver tudo com um único caminho, mesmo quando ele é ruim para custo, latência ou governança.

Produção multimodal exige menos improviso

A atualização também sinaliza uma maturidade maior da camada de API para IA multimodal. Modelos capazes de raciocinar sobre texto, imagem, áudio e vídeo dependem de uma ingestão que converse com a arquitetura real das empresas. O problema não é apenas aceitar mais formatos; é aceitar formatos sem forçar migrações desnecessárias.

Para times de produto, isso encurta o caminho entre acervo existente e recurso inteligente. Um sistema de suporte pode analisar anexos armazenados em bucket. Uma plataforma de mídia pode resumir vídeos sem copiá-los para outro serviço. Uma aplicação jurídica pode trabalhar com PDFs assinados por URLs temporárias, mantendo controle de acesso no storage original.

A parte sensível continua sendo governança. URLs assinadas precisam de expiração adequada, escopo mínimo e logs úteis. Objetos em GCS exigem IAM bem desenhado. Dados inline devem respeitar limites de privacidade e observabilidade do backend. A novidade reduz atrito técnico, mas não substitui política de dados.

No conjunto, a Gemini API fica mais próxima do modo como aplicações de produção realmente operam: dados distribuídos, controles de acesso já existentes e necessidade de evitar cópias desnecessárias. É uma melhoria menos vistosa do que um novo modelo, mas muito relevante para quem precisa transformar multimodalidade em produto confiável.