Cenário ilustrativo. Numa segunda-feira de campanha, o agente de atendimento que funciona às mil maravilhas o resto do ano recebe numa hora o que costuma receber num dia. As primeiras mensagens saem bem. Passados vinte minutos começam as repetições, a fila cresce, o fornecedor do modelo devolve erros de limite e a caixa das pessoas, que devia apanhar o que o agente não resolve, enche-se de uma vez. Ninguém partiu nada: o sistema nunca tinha ensaiado aquele dia.
A tese numa linha: um agente dimensionado para o dia médio não falha no pico por ser mau, falha porque ninguém decidiu antes o que se degrada primeiro. O pico não se sobrevive com mais potência; sobrevive-se com uma ordem de queda combinada de antemão.
Porque é que um agente de IA falha nos picos de procura?
Porque os picos de procura não põem à prova o que testaste (a qualidade da resposta), mas o que davas por garantido (tudo o que a rodeia). Quatro pontos de rutura, quase sempre os mesmos:
- Limites de pedidos e quotas. O fornecedor do modelo limita quantos pedidos e quantos tokens por minuto aceitas. Se vários agentes partilham uma chave, o pico de um come a quota dos outros. Os limites reais dependem do teu fornecedor e do teu plano: vê-os antes, não durante.
- Filas e repetições. Uma repetição sem travão transforma uma falha pontual numa avalanche: cada pedido falhado volta a entrar e agrava o engarrafamento que o fez falhar.
- Custo. Com mais volume, conversas mais longas e mais ferramentas chamadas, a despesa cresce mais depressa do que o tráfego. Sem um teto, só sabes no fim do mês, quando já não há nada para decidir.
- Pessoas sobrecarregadas. O agente encaminha os casos difíceis para pessoas; no pico encaminha mais, e todos ao mesmo tempo. Se a caixa humana não aguenta, o gargalo não desaparece: muda de sítio.
Repara no que falta na lista: o modelo. Quase nunca é o modelo. É tudo o que está pendurado nele, e isso ensaia-se.
O que ensaiar antes do pico?
Ensaiar é fazer, com tempo, a versão pequena do desastre. Não é preciso um simulacro gigante; é preciso um honesto. Uma sequência mínima:
- Mede o teu dia médio e fixa o pico esperado com dados reais das últimas campanhas ou fechos, não com intuição. Sem histórico? Parte das tuas piores horas conhecidas.
- Sobe a carga num ambiente de testes e vê onde aparece o primeiro limite: pedidos, fila, ferramenta externa ou pessoa. Esse é o teu gargalo real, não o que supunhas.
- Testa a falha, não só a carga. Corta de propósito a ferramenta externa, simula o erro de limite do fornecedor e vê o que o agente faz: se inventa, se cala ou repete sem fim, já sabes o que corrigir. Testar alterações sem estragar a automatização serve também para isto.
- Põe tetos de gasto e alertas por sistema, com aviso antes do teto e não depois, e uma pessoa com nome que o receba durante o pico.
- Ensaia a passagem para humanos. Quantos casos por hora absorve quem está de piquete e o que acontece ao resto? É o que quase ninguém testa e o que mais se nota; o desenho do humano no circuito decide se essa pessoa é um travão ou uma rede.
E mede enquanto ensaias: sem deteção de falhas nas automatizações, um pico degradado pode parecer um pico tranquilo.
O que degradar de propósito para não cair?
Degradar com elegância é decidir, antes de ser preciso, o que o agente deixa de fazer primeiro. É a lógica dos níveis de autonomia de um agente aplicada ao tempo: no pico, o agente desce um degrau em vez de cair do prédio.
| O que se parte | Degradação possível | O que proteges |
|---|---|---|
| Quota do fornecedor esgotada | Passar a um modelo mais leve para as consultas simples e reservar o potente para as críticas | Os casos importantes continuam a ter resposta |
| Fila a crescer | Aviso de receção imediato com um prazo realista e processamento em segundo plano | A confiança do cliente: sabe que o caso dele existe |
| Custo acima do teto | Limitar ferramentas caras e o tamanho das conversas; encaminhar o resto para um formulário | O orçamento, sem desligar o serviço |
| Pessoas sobrecarregadas | Triar por urgência e adiar o não urgente com data, em vez de encaminhar tudo | As pessoas e os casos que não podem esperar |
Nada disto tem glamour, e é por isso que funciona: são decisões de operação, tomadas com calma numa terça-feira de outubro, não às nove da manhã da Black Friday. Se preferes que as sustente quem opera o sistema, é exatamente o que cobrem garantir a disponibilidade da IA e monitorizar a IA em produção.
Quem decide o que se desliga durante o pico?
Uma degradação combinada só serve se alguém tiver autoridade para a ativar no momento. A meio de um pico não há tempo para convocar uma comissão, por isso a decisão toma-se antes: escreve-se uma página com três coisas.
- O gatilho. O sinal concreto que ativa cada degradação: a fila passa de certo tamanho, a despesa ultrapassa certa percentagem do teto, o fornecedor devolve erros de limite durante vários minutos seguidos. Sem gatilho mensurável, cada decisão vira debate.
- O responsável. Uma pessoa com nome, mais um suplente, que pode ativar a degradação sem pedir licença a ninguém. A autoridade delegada de antemão é o que transforma um plano num interruptor.
- O caminho de volta. Como e quando se repõe o comportamento normal, e quem revê o que ficou adiado durante o pico. Uma degradação que ninguém desativa torna-se o novo padrão sem que ninguém o tenha decidido.
Com essa página, o pico deixa de ser improviso às nove da manhã e passa a ser um procedimento. E o que aprendeste nesse dia fica anotado para a próxima: o que disparou cada degradação, quanto durou e o que farias de outra forma.
Quando não é preciso preparar o pico?
Quando o pico é previsível e pequeno, quando o agente não está no caminho crítico (se cai, as pessoas esperam, nenhuma encomenda se perde) ou quando estar em baixo um bocado custa menos do que preparar. Um agente interno de consulta mais usado às segundas não precisa de simulacro; um que recebe encomendas durante uma campanha precisa. Preparar demais também é teatro.
A frase para levar: não dimensiones para o dia médio nem para o dia de sonho; decide por que ordem cai o dia mau, e ensaia-o.
Nota: este artigo não usa números de terceiros. Os limites de pedidos e os preços dependem do fornecedor e do plano, e mudam; confirma a documentação do teu fornecedor antes de dimensionar. O cenário inicial é ilustrativo.