Um AI crawler pode varrer o seu site dezenas de milhares de vezes e mandar de volta um único visitante. A WIRED documentou como um crawler varreu propriedades da Condé Nast milhares de vezes sem gerar visitas proporcionais de volta — crawl massivo, retorno mínimo. Para um portal que depende de pageviews e receita de anúncios, isso é custo crescente de infraestrutura sem retorno proporcional.
Durante décadas, o modelo da web foi baseado numa troca implícita: crawlers indexavam conteúdo e direcionavam usuários aos sites de origem. Com a popularização da AI generativa, essa dinâmica mudou. Hoje, diferentes tipos de bots acessam o mesmo conteúdo por motivos diferentes, e tratá-los todos da mesma forma leva a decisões erradas.
Os três tipos de AI bots que você precisa conhecer
A distinção entre AI bots é uma distinção de intenção. Intenções diferentes exigem respostas diferentes.
Search bots: indexação para responder depois
Search bots coletam e indexam conteúdo para responder perguntas mais tarde. Eles não agem em tempo real: constroem um banco de dados do seu site que será consultado quando um usuário fizer uma pergunta num assistente ou buscador.
O mecanismo é o mesmo dos crawlers tradicionais, mas o destino do conteúdo mudou. Em vez de aparecer como link numa página de resultados, o seu texto aparece como resposta direta num chat, sem clique, sem visita, sem impressão de anúncio.
Search bots ainda podem gerar tráfego de volta. São os mais ambíguos: bloquear indiscriminadamente pode custar visibilidade. A decisão certa é monitorar, não bloquear por padrão.
Agent bots: ação em tempo real por um humano
Agent bots agem no momento, em nome de um usuário humano que está esperando do outro lado. Um agent pode estar lendo uma página de produto para comparar preços, preenchendo um formulário ou extraindo informações para responder a uma pergunta agora. Há uma pessoa, em algum lugar, aguardando o resultado dessa automação.
Agents consomem recursos como um usuário real (bandwidth, processamento, conexões de banco de dados), mas não geram receita. Não clicam em anúncios. Não compram. Em APIs e endpoints de autenticação, o risco é mais direto: agents sofisticados podem saturar rate limits, testar credenciais em escala e gerar custo de infraestrutura sem nenhuma contrapartida.
Saiba mais: Segurança de API para AI Agents: rate limits e auth — como adaptar rate limits, autenticação e observabilidade para tráfego de agents sem impactar integrações legítimas.
Training bots: captura permanente para treinar modelos
Training bots capturam conteúdo para treinar ou fazer fine-tuning de modelos de linguagem. O dado extraído não é consultado depois: é incorporado permanentemente à arquitetura do modelo. Ele molda como o modelo responde perguntas, para sempre, sem atribuição e sem compensação.
Sem acordo comercial explícito, não há justificativa para permitir o acesso. Para e-commerces, isso significa que catálogos de produtos, descrições e avaliações de clientes podem virar datasets de treinamento gratuitos para competidores.
Diferenças entre Search bots, Agent bots e Training bots
Tipo | O que faz | Há usuário humano esperando? | Pode gerar tráfego de volta? | Principal risco |
Search | Indexa para responder depois | Não | Sim (às vezes) | Resposta sem clique, sem visita |
Agent | Age em tempo real | Sim | Não | Consumo de infra sem receita |
Training | Captura para treinar modelo | Não | Não | Extração de propriedade intelectual sem compensação |
Quando um mesmo AI bot tem múltiplos propósitos
Alguns bots fazem mais de uma coisa ao mesmo tempo. Um crawler pode indexar conteúdo para search e usar o mesmo conteúdo para training. Uma regra de “bloquear Training” aplicada de forma ampla pode inadvertidamente bloquear indexação legítima, dependendo de como o bot está configurado e como a sua proteção o identifica.
A decisão de controle não pode ser binária. “Bloquear AI bots: sim ou não” não é uma política. A política real precisa considerar três camadas:
- O que o bot declara que faz (via User-Agent e documentação pública do operador)
- O que o bot realmente faz (padrão de comportamento, frequência de acesso, endpoints visitados, volume por período)
- Qual é a sua posição para cada finalidade (porque Search, Agent e Training podem e devem ter respostas diferentes)
O maior desafio não é bloquear bots claramente maliciosos. É decidir como tratar bots com comportamento misto, User-Agent legítimo e operadores que exercem mais de uma finalidade.
Por que User-Agent não é suficiente
A proteção baseada em lista de User-Agents conhecidos só funciona contra bots que se identificam honestamente.
Bots sofisticados falsificam User-Agent. Um bot de training pode se apresentar como navegador comum. Um agent pode simular tráfego orgânico. A lista precisa ser atualizada continuamente, e bots evasivos simplesmente não aparecem nela até que alguém os identifique e documente.
O que distingue o tráfego automatizado do tráfego humano não é a string declarada no cabeçalho da requisição, mas o comportamento ao longo de uma sessão. Humanos erram, voltam, hesitam e abrem novas abas. Bots tendem a seguir caminhos previsíveis com um padrão de tempo difícil de reproduzir manualmente. Rolagem de página, foco em campos de formulário e velocidade de leitura também ajudam a diferenciar usuários reais de automação. Training bots, por sua vez, costumam percorrer sitemaps, categorias e páginas de produto em sequência lógica, um comportamento incomum para usuários reais.
Cada sinal isolado pode parecer plausível. Avaliados em conjunto, ao longo de uma sessão inteira, formam um padrão difícil de falsificar de forma consistente.
É por isso que plataformas de proteção modernas, como o Bot Manager da Azion, trabalham com pontuação de risco por requisição: combinam fingerprint de dispositivo, assinatura de browser, padrão comportamental e reputação de rede. A classificação é atualizada a cada nova ação na sessão, não apenas na primeira requisição.
Saiba mais: Defesa Contra Automação Maliciosa com AI Inference — como combinar Bot Manager, AI Inference e observabilidade para classificar e responder a automação maliciosa em tempo real.
Como controlar Search bots, Agent bots e Training bots
A estrutura abaixo não é um tutorial de ferramenta. É um framework de decisão que você pode aplicar independente de qual solução estiver usando.
O bot está declarando identidade?
│
├── Não → Tratar como suspeito.
│ Bloquear ou aplicar desafio de verificação.
│
└── Sim → Qual é a finalidade declarada?
│
├── Training
│ ├── Sem acordo comercial → Bloquear
│ └── Com acordo → Permitir + monitorar volume e padrão
│
├── Agent
│ ├── API pública → Rate limiting granular por endpoint
│ ├── Site de conteúdo → Verificar se seus termos de uso
│ │ permitem acesso automatizado
│ └── E-commerce → Proteger páginas de produto,
│ catálogo e checkout
│
└── Search → Monitorar crawl-to-referral ratio
├── Ratio razoável → Permitir
└── Ratio abusivo (ex: >1.000:1) → Throttle ou negociar compensaçãoBloquear tudo é simples, mas caro: você pode perder indexação legítima e visibilidade em assistentes de AI que geram referral. Permitir tudo é arriscado: você subsidia treinamento de modelos concorrentes e consome infraestrutura sem receita. A resposta é ter uma política explícita e diferenciada para cada tipo de bot.
Uma boa solução de proteção vai além do bloqueio. Ela oferece ações granulares: rate limiting, redirect, respostas customizadas, atraso aleatório para elevar o custo operacional do bot sem revelar que ele foi detectado, hold de conexão. Cada ação tem um contexto onde é mais adequada do que um bloco direto.
Como monitorar o tráfego de AI bots
Ter uma política é o primeiro passo. Saber se ela está funcionando é o segundo, e poucos times olham para isso direito.
As métricas para gestão de AI bots não são as mesmas que você olha para tráfego humano. O mais revelador é o crawl-to-referral ratio por operador: para cada empresa cujos bots visitam seu site, quantas visitas você recebe de volta por cada crawl? Um ratio de 2:1 é o padrão histórico de search engines tradicionais. Ratios na casa dos milhares indicam extração sem retorno.
Além disso, vale acompanhar a distribuição de score de risco ao longo do tempo. Que porcentagem das requisições está sendo classificada como alta suspeita? Esse número sobe em determinados horários ou regiões? Search bots tipicamente acessam sitemaps e páginas de conteúdo. Training bots varrem mais amplamente. Agent bots concentram acesso em endpoints específicos. Desvios desses padrões indicam algo fora do esperado.
A Azion Web Platform oferece visibilidade em tempo real sobre esse perfil de tráfego pelo Real-Time Metrics e pelo Data Stream, com distribuição de bots por tipo, top origens de ataque, scores de risco e exportação para SIEM.
robots.txt ainda funciona?
Sim, como sinalização de preferência. Não como controle ativo. O robots.txt comunica ao bot o que o proprietário do site quer. Bots bem-comportados respeitam. Bots evasivos ou mal-intencionados ignoram completamente. A instrução no arquivo não executa nenhuma regra: ela depende da boa-fé de quem lê.
Há iniciativas no mercado para estender robots.txt com sinais de intenção de uso do conteúdo. A ideia é que o arquivo declare não apenas “pode ou não pode crawlar”, mas o que o operador está autorizado a fazer: indexar para search, resumir e reproduzir, ou apenas interagir sem armazenar. Ainda está em discussão.
robots.txt é necessário e insuficiente. É o equivalente a colocar uma placa de “propriedade privada” num terreno sem cerca. O controle real acontece na camada de infraestrutura, com capacidade de avaliar comportamento real, não apenas declarações de intenção.
Como criar uma política para AI bots
O mercado ainda não fechou as regras para esse problema. A taxonomia Search/Agent/Training é um começo, mas bots continuam mudando: combinam finalidades, falsificam identidade e ficam mais difíceis de classificar pelo que declaram.
Sites sem uma política ativa estão tomando uma decisão por omissão. As consequências aparecem no relatório de receita antes de aparecerem nos logs de acesso.
Quer entender como o tráfego de AI bots está afetando o seu site? Fale com o time da Azion.
Perguntas Frequentes
Qual a diferença entre AI Search bot, AI Agent bot e AI Training bot? Search bots indexam conteúdo para responder perguntas depois, construindo um banco de dados do seu site. Agent bots agem em tempo real por um usuário humano, navegando e extraindo informação naquele momento. Training bots capturam conteúdo para treinar ou ajustar modelos de linguagem, e o dado extraído é incorporado permanentemente ao modelo.
Devo bloquear todos os AI bots do meu site? Não. Bloquear Search bots indiscriminadamente pode reduzir sua visibilidade em buscadores e assistentes de AI que geram referral. A abordagem mais eficaz é ter políticas diferentes para cada tipo: monitorar Search com atenção ao crawl-to-referral ratio, controlar Agents com rate limiting por endpoint, e bloquear Training salvo acordo comercial explícito.
Se eu bloquear Training bots, vou afetar minha indexação no Google? Potencialmente sim, dependendo de como as regras são configuradas. Alguns crawlers combinam Search e Training num mesmo bot, e uma regra de bloqueio ampla pode impactar indexação. O controle eficaz exige identificação granular por comportamento, não uma regra aplicada a toda uma categoria.
O que é crawl-to-referral ratio e por que importa? É a proporção entre quantas vezes um bot crawlou seu site e quantos visitantes reais ele enviou de volta. Crawlers de search tradicionais tinham ratios próximos de 2:1. A WIRED documentou casos de AI crawlers varrendo propriedades da Condé Nast milhares de vezes sem gerar visitas proporcionais de volta. Para sites que dependem de tráfego e anúncios, esse número determina se um operador de bot está contribuindo ou só consumindo.
robots.txt é suficiente para bloquear AI bots? Não. robots.txt sinaliza preferência: bots bem-comportados respeitam, bots evasivos ignoram. Controle efetivo exige regras ativas na camada de infraestrutura, com capacidade de detectar comportamento suspeito além do que o bot declara no cabeçalho da requisição.
Como identificar AI bots que falsificam User-Agent? Por padrão de comportamento de sessão. Bots evasivos se revelam por navegação linear sem desvio, timing milimétrico entre ações, ausência de sinais de interação humana (variação de rolagem, foco em campos), e padrões sistemáticos de acesso a URLs que nenhum usuário real geraria. Uma plataforma de proteção que trabalha com score de risco por requisição, combinando fingerprint de dispositivo, reputação de rede e análise comportamental, detecta esses padrões mesmo quando o User-Agent está correto.
