Rate Limits em Chatbots de IA: Limitar Custos e Carga de Forma Justa

Um chatbot de site acessível publicamente pode gerar mais trabalho de processamento em escassos segundos do que uma página de contacto tradicional durante uma visita inteira. Uma única mensagem pode iniciar processamento de retrieval, reranking, várias chamadas de modelos e verificações adicionais. Sem limites claros, não é preciso um grande ataque de bots: um cliente com falhas, múltiplos separadores abertos em simultâneo ou um loop automático de retries podem disparar os tempos de resposta e os custos.

Os rate limits em chatbots de IA não devem ser vistos como um bloqueio rígido. Bons limites distribuem recursos escassos de forma justa, protegem o orçamento e mantêm um serviço residual compreensível para utilizadores legítimos. Este guia prático mostra quais as quantidades que as equipas de sites devem limitar, como criar uma identificação justa e qual a resposta que o chatbot deve dar sob carga elevada.

Por que razão um simples limite de pedidos por minuto não é suficiente

Em APIs normais, dois pedidos têm frequentemente custos semelhantes. Num chatbot de IA, uma saudação curta pode precisar de apenas alguns tokens, enquanto uma análise longa de documentos, um retrieval abrangente ou múltiplos passos do modelo consomem substancialmente mais. A lista atual OWASP GenAI LLM Top 10 2026 classifica o consumo desenfreado de recursos como Unbounded Consumption. O ponto central é a assimetria de custos: um atacante ou cliente com falhas pode, com pouco esforço próprio, desencadear um processamento desproporcionalmente dispendioso.

Também a OWASP API4:2023 aponta, além da taxa de interação, outros limites como tempo de execução, memória, tamanho do upload, operações por pedido e despesas em serviços de terceiros. Para os chatbots, isto significa: a política não deve apenas contar pedidos, mas também orçamentar todo o fluxo de processamento.

Sete recursos que exigem orçamentos separados

Um conceito sólido começa com um pequeno mapa de recursos. Para cada dimensão, define-se quando um pedido é aceite, encurtado, atrasado ou rejeitado.

• Pedidos: quantidade por fase de pico (burst) e por janela temporária mais longa.
• Concorrência: respostas em execução simultânea por utilizador, sessão e organização.
• Entrada: carateres, anexos e tokens de input estimados antes de chamar um modelo.
• Saída: orçamento máximo de resposta, bem como um cancelamento útil em loops infinitos.
• Retrieval: número de variantes de pesquisa, resultados, candidatos a reranking e documentos recarregados.
• Fila de espera: tarefas em aberto e tempo máximo de espera antes de aplicar um fallback claro.
• Custos: orçamento diário ou mensal por organização, bem como um travão de emergência global.

Tratar surtos e janelas temporais longas separadamente

Estes limites estão interligados, mas não são permutáveis. Um orçamento diário generoso não previne um pico de carga num único segundo. Da mesma forma, um limite de pedidos não protege contra um único pedido extremamente caro. Para o tempo de execução técnico, vale a pena combinar isto com um orçamento explícito de latência, timeouts e retries controlados.

Identidade justa em vez de bloqueio genérico por IP

Por que razão um endereço IP isolado não chega

O padrão HTTP RFC 6585 deliberadamente não prescreve como um servidor identifica um utilizador ou conta pedidos. Isto é importante porque um endereço IP sozinho não é um identificador de utilizador fiável. Em empresas, hotéis, redes móveis ou ambientes familiares, muitas pessoas podem partilhar o mesmo endereço público. Por outro lado, um cliente automatizado pode alterar facilmente os seus endereços IP.

Combinar sinais com minimização de dados

Em áreas autenticadas, a organização, conta e ID do utilizador são as chaves mais fortes. Num chatbot público, recomenda-se uma combinação equilibrada entre sessão de curta duração com poucos dados, sinal genérico da rede e o padrão de risco atual. Prompts em bruto, fingerprints permanentes do dispositivo ou registos de IP desnecessariamente detalhados não são necessários para este fim. Onde forem utilizados dados de conta pessoais, os limites de um chatbot autenticado num portal de cliente têm de ser planeados separadamente.

A política deve também permitir repetições legítimas. Um utilizador pode reenviar por causa de uma ligação instável ou precisar de mais interações devido a tecnologias de acessibilidade. Por isso, um sinal isolado raramente é suspeito, mas sim a combinação de frequência elevada, inputs longos, muitas sessões paralelas e a utilização repetida de rotas dispendiosas.

Derivar limites de métricas reais, não de palpites

Um bom valor inicial resulta de conversas reais e bem-sucedidas. Durante algumas semanas, a equipa mede tokens de entrada e saída, resultados de retrieval, tempo de execução, concorrência e custos por tarefa concluída. Em seguida, a utilização normal, os picos e os desvios são analisados separadamente. O limite deve situar-se acima de um pico legítimo plausível, mas abaixo da zona em que um único interveniente coloca em risco o serviço ou o orçamento.

Exemplo: a maioria das conversas requer no máximo três respostas por minuto e fica muito abaixo do orçamento de tokens. Sendo assim, um curto pico de tráfego pode aceitar mais mensagens, enquanto uma janela temporal mais longa limita a quantidade total. Rotas de análise dispendiosas recebem adicionalmente um contingente separado e menor. O aspeto decisivo não é o valor concreto vindo de outro sistema, mas a relação documentada com testes de carga, modelo de custos e comportamento dos utilizadores.

As alterações devem ser introduzidas inicialmente num Shadow Mode de observação. O sistema regista que sessões legítimas teriam atingido um limite planeado, sem as bloquear de imediato. Desta forma, os limiares são calibrados gradualmente e bloqueios desnecessários tornam-se visíveis.

Uma cadeia de proteção em vários níveis para cada pedido

1. Verificar à entrada: tamanho do payload, tipo de ficheiro, sessão e repetições evidentes são avaliados antes do retrieval e da chamada ao modelo.
2. Estimar os custos antecipadamente: tamanho da entrada, resposta pretendida, amplitude do retrieval e classe do modelo determinam o peso aproximado do pedido.
3. Reservar orçamentos atomicamente: sessão, utilizador, organização e pool global são verificados em conjunto. Pedidos que cheguem em paralelo não podem consumir o mesmo orçamento restante múltiplas vezes.
4. Limitar o tempo de execução: timeouts, máximo de passos do modelo e uma fila de espera limitada interrompem bloqueios dispendiosos.
5. Registar o consumo real: após a conclusão, o consumo real substitui a estimativa. Cancelamentos e erros do fornecedor permanecem visíveis como métricas próprias.

Esta cadeia reside no lado do servidor. Um botão de envio oculto no navegador é uma ajuda útil de UX, mas não uma barreira de segurança. O mesmo se aplica a instruções no prompt: não substituem um rate limiter técnico nem a proteção contra Prompt Injection em chatbots de sites.

429, Retry-After e o perigo de uma onda de repetição

Quando uma cota relativa ao utilizador se esgota, o código HTTP 429 Too Many Requests é a resposta adequada para processamento automático. O RFC 6585 recomenda uma explicação e permite um cabeçalho Retry-After. O cliente deve respeitar esse momento, não retransmitir imediatamente e exibir o estado do envio de forma clara. Idealmente, múltiplos clientes devem receber um pequeno intervalo aleatório para não recomeçarem exatamente ao mesmo tempo.

Em caso de sobrecarga geral temporária, o código HTTP 503 Service Unavailable pode ser mais adequado. O RFC 9110 descreve que o Retry-After pode ser enviado como data HTTP ou como tempo de espera em segundos. Ações não idempotentes nunca devem ser repetidas sem verificação: é necessário esclarecer primeiro se uma reserva ou transferência já foi efetuada.

Na interface do chat, a resposta técnica precisa de uma mensagem simples para pessoas: por que motivo a mensagem não está a ser processada agora, quando faz sentido tentar de novo e que alternativa resta. A mensagem deve ser reconhecível por tecnologias de apoio. A explicação do W3C sobre as Mensagens de Estado WCAG 2.2 mostra como comunicar alterações de estado sem forçar uma mudança de foco.

Degradação graciosa mantém um serviço residual útil

Um bloqueio total e rígido nem sempre é a melhor resposta. Sob carga elevada, o chatbot pode opcionalmente fornecer respostas mais curtas, verificar menos resultados de retrieval ou ignorar uma análise que não seja crítica em termos de tempo. A transparência é essencial: o utilizador deve perceber que está ativo um modo limitado. Fontes, verificações de segurança e autorização não podem ser removidas em silêncio.

Para assuntos urgentes, deve existir uma opção simples de contacto ou transição para um humano. Se esse caminho também estiver sobrecarregado, o sistema mostra uma alternativa fiável em vez de uma promessa inventada. Os critérios para degradação, desligamento e reinício pertencem ao plano de resposta a incidentes e rollback.

Que métricas tornam a proteção gerível

O número simples de respostas 429 diz muito pouco. Um painel de controlo útil separa as métricas por dimensão de limite e classe de utilizador: pedidos aceites e limitados, execuções paralelas, tempo de espera, tokens de entrada e saída, amplitude de retrieval, custos por conversa com sucesso e erros do fornecedor. Adicionalmente, é necessária uma amostragem de sessões bloqueadas para detetar falsos alarmes.

Os alertas devem responder a alterações: aumento invulgar de custos por minuto, crescimento rápido da fila de espera, muitos inputs longos provenientes de sessões em alteração ou uma elevada proporção de repetições imediatas apesar do Retry-After. Para isso, contadores pseudónimos e metadados técnicos costumam ser suficientes; o conteúdo integral das conversas não pertence automaticamente aos registos de carga. O NIST AI RMF Core destaca que os sistemas de IA devem ser medidos e testados antes do arranque e regularmente durante a operação.

Plano de testes antes da ativação definitiva

• Conversas individuais normais e pequenos picos legítimos funcionam sem limitações.
• Inputs muito longos são limitados antes de chamadas dispendiosas de modelos ou retrieval.
• Múltiplos separadores paralelos partilham o mesmo orçamento de sessão ou conta corretamente.
• Vários utilizadores legítimos sob o mesmo IP público não são bloqueados de forma genérica.
• Respostas 429 e 503 contêm informação de espera consistente e compreensível.
• Os clientes respeitam o Retry-After e não geram uma onda de retries.
• O modo limitado preserva as fronteiras de fontes, proteção de dados e segurança.
• Um limite de custos global interrompe o caminho dispendioso sem afetar a página de estado ou as opções de contacto.

Lista de verificação prática para equipas de sites

1. Medir o caminho dos recursos e os custos por conversa bem-sucedida.
2. Definir limites separados para pedidos, tokens, concorrência, retrieval, fila de espera e orçamento.
3. Dar prioridade a identidades autenticadas e combinar sinais anónimos com minimização de dados.
4. Testar os limites primeiro em Shadow Mode contra o tráfego real.
5. Validar o comportamento de 429, 503 e Retry-After na API e na interface.
6. Documentar a degradação graciosa, transição para humano e o travão de emergência global.
7. Avaliar conjuntamente bloqueios indevidos, custos e carga de forma regular.

Conclusão: Bons rate limits protegem o serviço e os utilizadores

Os rate limits para chatbots de IA são uma tarefa de arquitetura, não um número isolado na CDN. Apenas a combinação de orçamentos associados a volumes, tokens, concorrência e custos evita o consumo desenfreado. Uma identificação justa, semântica clara de repetições e um serviço residual transparente garantem que a proteção não se transforma numa má experiência para o utilizador.

Quem pretende operar o seu chatbot de site de forma estável deve começar com um mapa de recursos medido e ajustar a política de forma controlada. Verifique para a sua implementação com o ChatReact quais os orçamentos adequados ao tráfego do seu site e teste os limites antes de os ativar em definitivo.

Fontes

• OWASP GenAI LLM Top 10 2026
• OWASP API4:2023 – Unrestricted Resource Consumption
• RFC 6585 – 429 Too Many Requests
• RFC 9110 – Retry-After
• W3C WCAG 2.2 – Status Messages
• NIST AI Risk Management Framework Core