Perguntar ao ChatGPT sobre os dados do sistema
Vitor Ayres (abre em nova aba)
Um sistema de gestão para o setor médico e hospitalar tinha o problema de sempre: os dados estavam lá, os relatórios saíam, e quase ninguém olhava. Pedir um relatório novo era um chamado ao suporte, e a resposta chegava depois da pergunta ter perdido o sentido.
Este texto registra como esse sistema ligou o ChatGPT aos dados de cada cliente, por um servidor MCP, o Model Context Protocol. É um relato do que foi construído e do que a equipe aprendeu, não uma medição. O cliente não é citado, e os exemplos de perguntas são reais, com autorização.
Resumo
- Os usuários perguntam ao ChatGPT que já têm, pelo navegador, com o login do próprio sistema.
- O servidor MCP é uma aplicação separada, só de leitura, em Python com FastMCP.
- Ele lê uma cópia limitada dos dados, num bucket, e monta visões semânticas em cima dela.
- O isolamento entre clientes é o mesmo da aplicação multi-tenant.
- O SQL aberto é restrito a lacunas, porque a IA erra quando escreve SQL livre.
- O que deu trabalho: respostas grandes demais e o corte de resposta do conector, sem limite documentado.
- O que falta: cruzar tabelas, que hoje depende da IA.
O problema de sempre
Gerar relatórios. Ninguém olhava os dados. A lista de pedidos de relatório crescia e a maioria era uma pergunta de uma linha: quanto consumimos disso no fim de semana, quantos pacientes ficaram mais de 30 dias, onde o dinheiro de materiais está indo.
Cada uma dessas perguntas é uma consulta pequena sobre dados que o sistema já tem. O que faltava era um jeito de o usuário fazer a pergunta em português e receber a resposta sem esperar ninguém.
Como ficou
O usuário abre o ChatGPT no navegador, adiciona o sistema como conector, e entra com o login do próprio sistema, por OAuth. A partir daí, ele pergunta.
Por trás, um servidor MCP responde. Ele é uma aplicação separada da principal, em Python com FastMCP, e só lê. Poderia editar, mas a necessidade era consumir dados específicos, não o banco inteiro.
Os dados que ele lê não são os do banco da aplicação. Um bucket guarda um espelho só de leitura dos dados crus, e o MCP cria visões semânticas em cima desse espelho: consumo por período, internações, gastos mensais, histórico. Essa cópia limitada já é uma camada de segurança por si só. Se o servidor MCP fosse comprometido, o que ele alcança é uma cópia parcial e só de leitura.
O isolamento entre clientes não foi reinventado. A aplicação é multi-tenant, cada cliente acessa o próprio banco dentro dela, e o controle de acesso é o da própria aplicação. O MCP herda as duas coisas do login.
O que a IA pode fazer
As ferramentas são muitas: consultas específicas, agregações, dados históricos, análises. Entre elas há uma de SQL, e é a que merece explicação.
Na primeira versão, a IA podia escrever SQL. Ela errava. Não sempre, mas o bastante para a resposta não ser confiável, e um relatório errado é pior que nenhum. A ferramenta de SQL virou outra coisa: um preencher de lacunas, com a estrutura da consulta fixa e sem todas as palavras-chave disponíveis. A IA escolhe o que vai em cada lacuna, não a forma da consulta.
O sistema também tem um painel para gerenciar prompts, onde os usuários guardam prompts grandes, elaborados para as análises que repetem. O MCP tem acesso a esses prompts, então uma análise que levou tempo para ser escrita uma vez vira uma pergunta curta nas vezes seguintes.
Três perguntas reais de usuários:
- “Historicamente, quantos pacientes internados tiveram alta depois de 30 dias de internação?”
- “Qual material tem mais consumo nos fins de semana?”
- “Consulte os gastos mensais de materiais, relacione com o consumo e veja onde o dinheiro vai e possíveis otimizações.”
A terceira é o tipo de pergunta que antes virava um projeto. Aqui ela vira uma conversa, com a ressalva da seção sobre limites.
O que deu trabalho
Mostrar muitos dados. A primeira tentação é devolver linhas. Uma resposta com centenas de linhas não cabe bem na conversa, e o conector do ChatGPT corta respostas grandes para caber no que ele chama de orçamento de resposta da ferramenta. Esse limite não está documentado. Desenvolvedores relatam o corte no fórum da OpenAI, com a mensagem de erro e sem o número. A saída foi devolver menos: agregados em vez de linhas, campos a menos, visões já resumidas. É por isso que as ferramentas são visões semânticas, e não acesso à tabela.
SQL livre. Já contado acima. A IA tende a errar no SQL aberto, e a resposta foi fechar o SQL em vez de tentar ensinar a IA a acertar.
O de sempre com IA generativa. Respostas confiantes sobre dados que não vieram, formatação que muda de uma chamada para outra, e a necessidade de descrever cada ferramenta como se fosse para alguém que nunca viu o sistema. Nada disso é específico deste caso, e tudo isso tomou tempo.
O que surpreendeu
Não foi uma resposta da IA. Foi o fato de o cliente poder fazer tudo isso com a IA que já pagava, sem um plano novo, sem um produto de BI e sem uma ferramenta a mais para os usuários aprenderem. O ChatGPT que a pessoa já abria todo dia passou a saber responder sobre o sistema dela.
O que falta
Cruzar tabelas. Como o SQL é limitado a lacunas, nem sempre é possível rodar um join, e hoje é a IA que tem de combinar os resultados de duas ferramentas. Às vezes ela faz bem. Às vezes não dá. O uso está sendo rastreado para ver quais cruzamentos as pessoas pedem, e esses viram ferramentas próprias, com o join feito do lado do servidor.
Há outras limitações do mesmo SQL restrito, e a regra para todas é a mesma: ver o que as pessoas perguntam de verdade antes de abrir a ferramenta.
Como sabemos
Este post é um relato da equipe que construiu e opera o servidor, revisado antes de publicar. Não há medições publicadas: nem tempo de resposta, nem número de usuários, nem taxa de acerto da IA. O que está aqui é o desenho, as decisões e os problemas encontrados. O corte de resposta do conector vem do relato da equipe e do fórum da OpenAI, e o limite em si não é documentado. O cliente não é citado, e o setor é dito de forma genérica.
A parte técnica de um servidor MCP escrito do zero, com as duas gerações do protocolo e OAuth para o ChatGPT, está no post sobre um servidor MCP num Worker, de um caso menor. Uma busca que roda inteira no navegador, sem servidor, é outra forma de falar com os dados.
Se os usuários do seu aplicativo querem perguntar ao ChatGPT ou ao Claude sobre os próprios dados, é esse o trabalho que fazemos em falar com o seu banco de dados. Quando a resposta precisa de revisão humana, ou de uma ferramenta nova em vez de SQL, entra o que fazemos em soluções com IA.
Perguntas
- A IA tem acesso ao banco inteiro do sistema?
- Não. O servidor MCP lê uma cópia limitada dos dados, só de leitura, e expõe visões específicas. O banco da aplicação não é tocado, e a cópia já é uma camada de segurança por si só.
- Como um cliente não vê os dados de outro cliente?
- Pela mesma regra que a aplicação já aplica: cada cliente acessa o próprio banco dentro do sistema multi-tenant, e o MCP herda esse isolamento e o controle de acesso do login.
- O usuário precisa de um plano novo de IA?
- Não. Ele conecta o sistema ao ChatGPT que já usa, pelo navegador, com o login do próprio sistema via OAuth. Isso foi o que mais surpreendeu o cliente.
- A IA escreve SQL livremente?
- Não. O SQL aberto é restrito: é mais um preencher de lacunas do que um escrever consultas, sem todas as palavras-chave. A IA erra mais quando o SQL é livre, então ele foi fechado.
- O que o MCP ainda não faz bem?
- Cruzar tabelas. Como o SQL é limitado, nem sempre dá para rodar um join, e hoje é a IA que combina resultados. O uso está sendo rastreado para decidir o que otimizar.