Google Sheets como banco de dados para IA: quando serve e quando migrar

Google Sheets como banco de dados para IA: quando serve e quando migrar

Google Sheets serve como base de um agente de IA quando o volume é baixo, poucas pessoas editam e o agente apenas lê ou escreve em um fluxo simples e reversível. Deixa de servir quando surgem escritas simultâneas, dados que cada perfil só pode ver em parte ou a necessidade de uma trilha de auditoria confiável. Nesse ponto, migrar para um banco de dados é uma decisão de controle de risco, não de modismo técnico.

Principais pontos

• A planilha é uma boa base de piloto: o time já a conhece, o custo de montar é baixo e dá para corrigir dados na mão.
• O primeiro limite real é a concorrência: planilhas não oferecem transações, então duas escritas ao mesmo tempo podem se sobrepor ou duplicar registros.
• Permissões de planilha são pensadas para pessoas, não para um agente com acesso mínimo: quem lê o arquivo costuma ler tudo o que há nele.
• O histórico de versões ajuda a investigar, mas não substitui um log de decisões do agente com entrada, ação e resultado.
• Migre quando o agente passar a escrever dados que movem dinheiro, estoque, agenda ou dados pessoais, e não quando a planilha estiver apenas grande.

Por que a planilha tenta tanto, e o que ela entrega bem

Quase toda empresa pequena e média já opera em planilhas: lista de clientes, tabela de preços, controle de pedidos, agenda de equipe. Quando alguém propõe um agente de IA, o caminho mais curto é apontar o agente para esse arquivo. É compreensível, e em muitos casos é a escolha certa para começar.

A planilha entrega bem algumas coisas em um piloto. A primeira é a visibilidade: o dono do processo abre o arquivo e vê exatamente o que o agente leu e escreveu. A segunda é a correção rápida: um preço errado se arruma em segundos, sem desenvolvedor. A terceira é a flexibilidade: mudar uma coluna não exige migração de esquema.

Para leitura de dados de referência, como catálogo, horários de funcionamento, regras de garantia ou tabela de preços aprovada, a planilha costuma funcionar bem. O agente consulta, responde e não altera nada. O risco é pequeno e o ganho de aprender com o processo real é grande.

O problema começa quando a planilha deixa de ser referência e vira registro operacional, isto é, quando o agente cria pedidos, reserva horários, baixa estoque ou registra consentimentos. Aí as limitações deixam de ser detalhe.

Concorrência: onde a planilha quebra primeiro

Um banco de dados foi desenhado para aceitar muitas operações ao mesmo tempo sem perder consistência. Ele oferece transações (ou tudo acontece, ou nada acontece), restrições de unicidade e bloqueios. Uma planilha não foi desenhada para isso.

Na prática, com um agente de IA atendendo no WhatsApp, vários clientes escrevem ao mesmo tempo. Se o agente lê a última linha livre, decide e grava, outra execução pode ter feito o mesmo no intervalo. O resultado são dois clientes na mesma vaga de agenda, o mesmo pedido gravado duas vezes ou uma atualização sobrescrevendo a outra.

Há mitigações, e vale conhecê-las antes de descartar a planilha:

• Usar operações de acréscimo (append) em vez de ler e reescrever linhas, para que cada registro seja novo e nunca sobrescreva outro.
• Gerar um identificador único por solicitação e conferir se ele já existe antes de gravar, o que dá idempotência ao fluxo.
• Serializar as escritas por uma fila ou por um único serviço, de modo que apenas um processo grave na planilha.
• Evitar que pessoas editem manualmente as mesmas linhas que o agente atualiza.

Essas medidas reduzem o problema, mas todas elas empurram para o seu código a responsabilidade que um banco já resolve. Quanto mais mitigação você precisa construir, mais perto está o momento de migrar. Consulte também a documentação atual da API do Google Sheets sobre cotas e limites de requisição, porque eles mudam com o tempo e um agente em loop pode esgotá-los. Sobre esse risco, vale ler Agente de IA em loop infinito: limites de passos, tempo e gasto.

Permissões: o agente enxerga mais do que deveria

O compartilhamento de uma planilha funciona em torno do arquivo: quem pode ver, comentar ou editar. Existem proteções de intervalo, mas elas servem principalmente para impedir edição, não para esconder dados de quem consegue abrir o arquivo. Quem tem acesso de leitura tende a ver todas as abas e colunas.

Isso conflita com um princípio básico de agentes: acesso mínimo. Se o agente de atendimento só precisa saber o status de um pedido, ele não deveria ter acesso à coluna de CPF, ao telefone de outros clientes ou à margem de lucro. Se a credencial do agente abre o arquivo inteiro, uma falha de instrução ou uma injeção de prompt pode expor tudo. O OWASP descreve esse tipo de risco na lista de ameaças a aplicações com LLM, e vale conhecê-la.

O ponto de partida é separar a identidade do agente da identidade de pessoas. Use uma conta de serviço ou um fluxo OAuth com escopos restritos, conforme a documentação de OAuth 2.0 do Google, em vez de colocar o agente para operar com a conta pessoal de um sócio. E trate autorização como uma camada própria, não como efeito colateral do compartilhamento do arquivo, seguindo princípios como os do guia de autorização do OWASP.

Uma alternativa prática dentro da planilha é criar um arquivo separado, só com os dados que o agente pode ver, alimentado por uma rotina controlada. O agente nunca toca na planilha principal. Isso melhora a permissão, mas cria outra cópia para manter sincronizada, e esse é um sinal de que a base está pedindo uma estrutura melhor.

Se a planilha contém dados pessoais, entram as obrigações da LGPD: finalidade, minimização, segurança e, quando o modelo roda fora do país, as regras de transferência. O texto Transferência internacional de dados com IA: o que a LGPD exige detalha esse ponto. Para orientação oficial, acompanhe a ANPD.

Auditoria: dá para reconstruir o que o agente fez?

Quando algo dá errado, a pergunta é sempre a mesma: o que o agente leu, o que decidiu e o que gravou? O histórico de versões de uma planilha mostra quem alterou uma célula e quando. É útil, mas tem limites para auditar um agente:

• Ele registra a mudança, não o motivo. Você vê que o status virou aprovado, mas não vê a mensagem do cliente nem a regra aplicada.
• Ele não liga a alteração a uma conversa, a uma versão do prompt ou a uma chamada de ferramenta.
• Ele pode ser agrupado, navegado com dificuldade e, dependendo das permissões, editado ou apagado por quem tem acesso de edição.
• Ele não foi feito para consultas do tipo: liste todas as ações do agente que alteraram valor de pedido na última semana.

Por isso, mesmo com a planilha como base de dados, mantenha um log de decisões em separado, com data, identificador da conversa, entrada resumida, ferramenta chamada, parâmetros, resultado e se houve aprovação humana. Os conceitos de rastreabilidade em observabilidade do OpenTelemetry ajudam a pensar nisso sem inventar um formato próprio. E o projeto das ferramentas que o agente chama, com poucas ações bem delimitadas, está bem explicado no guia da Anthropic sobre como escrever ferramentas eficazes para agentes.

Para validar entradas e saídas antes de qualquer gravação, veja Guardrails para agentes de IA: entrada, saída e ação na prática.

Cenário ilustrativo: distribuidora com pedidos pelo WhatsApp

Imagine uma distribuidora pequena de materiais de limpeza. Ela mantém uma planilha com catálogo, preços e estoque, e quer um agente no WhatsApp que responda dúvidas de produto e registre pedidos para a equipe confirmar. Este é um cenário ilustrativo, não um caso real.

Na primeira fase, o agente apenas lê o catálogo e os preços, em um arquivo separado e somente leitura para ele. Não há escrita, não há dado pessoal na planilha. A planilha é suficiente, e o aprendizado sobre as perguntas reais dos clientes é valioso.

Na segunda fase, o agente passa a registrar pedidos em uma aba de rascunho, sempre por acréscimo de linha, com um identificador único por conversa. Um funcionário confirma cada pedido antes de qualquer baixa de estoque. A concorrência é controlada porque nenhuma linha existente é reescrita pelo agente, e a aprovação humana funciona como freio. A planilha ainda serve.

Na terceira fase, a empresa quer que o agente reserve estoque na hora, avise o cliente sobre prazo e aceite alterações de pedido durante o dia, enquanto vendedores também editam as mesmas linhas. Agora há escritas simultâneas sobre os mesmos registros, dados de clientes (nome, endereço, telefone) e a necessidade de provar depois quem alterou o quê. Esse é o momento de migrar o registro de pedidos e estoque para um banco, mantendo a planilha apenas como interface de consulta ou importação.

Quando migrar para um banco: sinais práticos

Use esta lista como guia de decisão. Se duas ou mais afirmações forem verdadeiras, planeje a migração. Se a primeira ou a segunda for verdadeira, trate como prioridade.

• O agente grava informações que movem dinheiro, estoque, agenda ou prazos, e um erro gera prejuízo ou retrabalho real.
• A planilha contém dados pessoais, e nem todos os usuários ou o próprio agente deveriam ver todas as colunas.
• Várias pessoas ou processos editam as mesmas linhas ao mesmo tempo que o agente.
• Você precisa responder a perguntas de auditoria, de cliente ou de titular de dados sobre o que foi feito e por quê.
• A equipe criou fórmulas, scripts e abas auxiliares só para evitar duplicidade e conflito.
• Alguém já corrigiu manualmente um erro causado por escrita simultânea.
• Outros sistemas, como ERP, CRM ou site, também precisam ler e gravar esses dados. Veja os caminhos e riscos em Integrar IA ao Bling, Omie ou Tiny: caminhos via API e riscos.

Repare que tamanho não aparece como critério principal. Uma planilha pequena com dados sensíveis e escrita concorrente é mais arriscada do que uma grande, somente leitura.

Como migrar sem parar a operação

A migração não precisa ser um projeto longo. O método que seguimos é mapear, limitar, pilotar e transferir, e ele se aplica bem aqui.

Mapear: liste as abas e colunas que o agente lê e as que ele escreve. Separe dados de referência (catálogo, regras) de dados operacionais (pedidos, agenda, consentimentos). Registre a situação atual do processo, como tempo de resposta e retrabalho, para ter uma linha de base de comparação.

Limitar: defina quais ações o agente pode fazer e quais exigem aprovação humana. Dê a ele acesso apenas ao que precisa. Quando for para o banco, crie um usuário com permissões mínimas, por exemplo leitura em algumas tabelas e inserção em outra.

Pilotar: migre um fluxo real, o mais crítico em concorrência ou risco, e mantenha o resto na planilha. Rode com logs de decisão e uma métrica de sucesso combinada com o time. O texto Como Medir um Piloto de Automação com IA: Métricas e Gates de Decisão ajuda a definir esses critérios.

Transferir: documente o esquema, as permissões, o log e o procedimento de correção, e entregue ao responsável do negócio. Só então decida se expande, ajusta ou interrompe.

Um passo a passo mínimo para a troca:

• Crie as tabelas com chaves únicas para evitar duplicidade, como identificador de conversa ou número de pedido.
• Importe os dados atuais e confira uma amostra manualmente contra a planilha.
• Aponte o agente para o banco em modo de leitura e compare as respostas com as da versão em planilha.
• Ative a escrita com aprovação humana e acompanhe os logs por um período definido.
• Mantenha a planilha como visão de consulta, gerada a partir do banco, e não como fonte de verdade.
• Defina quem pode corrigir dados, como as correções são registradas e como reverter um erro.

Perguntas frequentes

Posso usar Google Sheets como banco de dados para um agente de IA em produção? Pode, desde que o escopo seja restrito: dados de referência, volume baixo, poucas pessoas editando e ações reversíveis. Se o agente grava dados que geram custo ou obrigação, como pedidos, agenda ou consentimentos, recomendamos um banco ou, no mínimo, escrita por acréscimo com aprovação humana e log separado.

O histórico de versões do Google Sheets basta como auditoria? Ele ajuda a ver quem mudou uma célula e quando, mas não registra a conversa, a regra aplicada nem a ferramenta chamada. Para auditar um agente, mantenha um log próprio de decisões, com entrada, ação, resultado e aprovação humana, em um local que o agente não consiga editar.

Como proteger dados pessoais em uma planilha usada por um agente? Separe os dados que o agente precisa em um arquivo próprio, use uma credencial com escopo mínimo e evite compartilhar o arquivo principal com a conta do agente. Se houver dados pessoais, aplique minimização e as demais obrigações da LGPD, e consulte um advogado ou o encarregado de dados da empresa para os casos de dúvida.

Qual é o melhor momento para sair da planilha e ir para um banco? Quando o agente passar a escrever dados críticos, quando houver escrita simultânea sobre os mesmos registros ou quando for necessário provar o que foi feito e por quê. Se a equipe já está criando fórmulas e scripts para evitar conflitos, o custo de manter a planilha provavelmente já superou o de migrar.

Fontes

• Google: OAuth 2.0 authorization
• OWASP: Authorization Cheat Sheet
• OpenTelemetry: observability concepts
• Anthropic: Writing effective tools for agents