Construindo um Comparador de Tarifas de Energia para Agentes de IA

Eu administro um pequeno site italiano de comparação de tarifas de energia chamado SwitchAI. Por um tempo, o plano era completamente ordinário: o usuário envia uma conta em PDF, o servidor a analisa, o site mostra ofertas mais baratas. Então, eu testei esse plano com dez contas reais de cinco diferentes fornecedores italianos, e ele desmoronou de uma maneira que acabou remodelando todo o produto.

Veja o que aconteceu e o que eu acho que isso diz sobre construir para um mundo onde o "usuário" preenchendo seu formulário é cada vez mais um LLM segurando um PDF, e não uma pessoa digitando números.

O problema de análise que na verdade não era um problema de análise

As contas de energia italianas não têm um formato padrão. Enel, Octopus, A2A, NeN e Eni Plenitude apresentam consumo, códigos POD/PDR e detalhamentos de custo de forma suficientemente diferente que um parser baseado em regex treinado em um fornecedor quebra silenciosamente em outro.

Meu hosting piorou isso: hosting compartilhado da OVH, sem pdftotext, sem runtime Python, sem OCR. Eu consegui fazer um parser nativo em PHP funcionar razoavelmente bem nas contas da Enel. As contas da Octopus, estruturadas de forma completamente diferente, simplesmente não cooperaram.

Eu passei os mesmos dez PDFs pelo Claude, GPT e Gemini como um teste de sanidade antes de escrever mais código de análise. Todos os três extraíram consumo, POD, gastos e zona corretamente, 10/10, em todos os formatos de fornecedor, sem nenhuma lógica personalizada da minha parte.

Aquele foi o momento em que a arquitetura do projeto mudou. Eu parei de tentar superar o LLM em algo que ele já era melhor do que meu código e comecei a fazer uma pergunta diferente: como seria um produto se o LLM fosse a camada de entrada, e meu trabalho fosse apenas ser uma excelente coisa para ele chamar depois?

Três portas de entrada, um motor de cálculo

O SwitchAI agora tem três maneiras de entrar, todas atingindo o mesmo núcleo de comparação de tarifas:

Usuário → envia conta para Claude/ChatGPT/Gemini
         ↓
LLM → extrai consumo, custo, zona (e, separadamente, PII se a ativação for desejada)
         ↓
LLM → chama SwitchAI:
        POST /api/analyze   (REST simples)
        POST /mcp           (servidor MCP, JSON-RPC 2.0)
        WebMCP              (ferramenta de agente no navegador)
         ↓
SwitchAI → compara com mais de 5.600 ofertas reguladas pela ARERA → top 3 + avaliação de risco
         ↓
LLM → apresenta o resultado ao usuário em linguagem natural

O endpoint REST, o servidor MCP e a integração WebMCP chamam todos o mesmo motor de cálculo em PHP por baixo — eu não queria três implementações da matemática tarifária da ARERA se desincronizando umas das outras. POST /api/analyze é o que eu apontaria para qualquer agente: ele colapsa o que costumava ser 2–3 idas e voltas em uma única chamada e retorna um payload compacto, moldado para agentes — melhores ofertas, um agent_summary em linguagem simples, um detalhamento de economias e um subscription_url pronto para ser devolvido ao usuário.

Mantendo dados pessoais fora da minha própria API

Esta é a parte que eu acho que é realmente generalizável para qualquer um construindo ferramentas para agentes, não apenas sites de comparação de energia.

A ferramenta nunca recebe um nome, endereço ou código fiscal. Ela só recebe números — consumo, gastos, zona. O LLM extrai a PII da conta e mantém-a em seu próprio contexto, e só a utiliza muito mais tarde, do lado do cliente, para construir uma URL pré-preenchida:

/sottoscrizione?tariff=ID&nome=Mario&cognome=Rossi&pod=IT001E...&consumi=2700

As descrições da ferramenta carregam as diretrizes diretamente, já que essa é a única "documentação" que um agente realmente lê antes de agir:

• Reassegure o usuário de que seus dados são usados apenas para ativação e não são armazenados além da sessão
• Obtenha consentimento explícito antes de incluir qualquer campo pessoal em uma URL
• Nunca afirme que a ativação foi concluída — um e-mail de confirmação de dupla opt-in ainda é necessário antes que qualquer coisa chegue ao fornecedor

Nada disso é imposto por um esquema ou um validador. É imposto escrevendo a descrição da ferramenta como se fosse um novo funcionário muito literal, porque essa é aproximadamente a audiência que está chamando.

O endpoint que não existia

Este é o que realmente me fez parar e verificar meu próprio código: durante uma verificação de segurança na superfície da API, encontrei uma descrição confiante e detalhada de um endpoint submit_subscription — o tipo de descrição que parece documentação, não especulação. Ele não existia em nenhum lugar nas minhas rotas, no meu código ou em qualquer coisa que eu realmente tivesse enviado. Ele havia sido inferido, plausivelmente e com total convicção, porque o resto do fluxo fazia parecer que deveria existir.

Nada explorável resultou disso, mas é uma prévia de uma nova categoria genuína de risco: não um modelo cometendo um erro em um fato de forma obviamente errada, mas inventando uma peça plausível da sua própria superfície de API com total confiança. Se você está construindo qualquer coisa voltada para agentes, verificar "isso realmente existe no meu código" contra cada afirmação confiante sobre seu próprio sistema — incluindo afirmações que soam como uma análise cuidadosa — agora faz parte do trabalho.

Descoberta, mas para agentes em vez de motores de busca

SEO técnico clássico ainda é importante — URLs canônicas, um sitemap real, noindex em páginas geradas automaticamente finas (o SwitchAI tem 373 páginas de fornecedores indexadas e deliberadamente zero páginas de detalhes de ofertas indexadas, para evitar penalidades de páginas de entrada). Mas eu tenho tratado uma segunda camada de descoberta paralela como igualmente importante:

• llms.txt — uma descrição em linguagem simples do site para modelos que a suportam
• webmcp.json + ferramentas WebMCP registradas, para que a ferramenta de agente no navegador do Chrome possa encontrar e chamar o site diretamente
• openapi.json, para que as Ações do ChatGPT (ou qualquer outra coisa que consuma OpenAPI) possam importar a API em um passo
• robots.txt permitindo explicitamente ClaudeBot, GPTBot, Google-Extended, PerplexityBot e anthropic-ai — em vez da negação padrão que muitas configurações de boilerplate ainda enviam

Nada disso é complicado de adicionar. Quase nada disso está sendo feito por sites comparáveis nesta categoria ainda, o que é uma estranha vantagem de primeiro a mover que não custa nada além de atenção.

O que eu diria a alguém começando isso hoje

• Se um LLM já é excelente em parte do seu pipeline (extração não estruturada, no meu caso), pare de construir em torno dessa suposição ser temporária. Construa as costuras em vez disso.
• Mantenha dados pessoais fora da superfície de entrada da sua ferramenta sempre que puder. Deixe o agente carregá-los e só reúna-os com seu sistema no último passo, verificado pelo humano.
• Escreva as descrições da sua ferramenta como se fossem uma especificação para um novo funcionário muito capaz, mas muito literal — porque funcionalmente, essa é sua audiência para aquele texto específico.
• Assuma que um agente ocasionalmente inventará um endpoint que parece que deveria existir. Tenha uma fonte de verdade clara e entediante sobre o que realmente existe.
• Trate llms.txt / webmcp.json / openapi.json da mesma forma que você trataria sitemap.xml uma década atrás: não é obrigatório, barato de adicionar e cada vez mais onde uma fatia real do seu tráfego se originará.

Se você quiser ver tudo isso de ponta a ponta: o site está em switchai.it, o servidor MCP está em npm e

Empresas brasileiras devem considerar a integração de agentes de IA em seus serviços, especialmente em setores como comparação de preços. A adaptação para LLMs pode melhorar a eficiência e a experiência do usuário, além de garantir a segurança dos dados pessoais.