Ligado não é o mesmo que funcionando

Um atendente automático de mensagens foi configurado para reconhecer de qual anúncio a pessoa tinha vindo e citar o assunto na saudação. A informação chegava junto com o contato, pronta para ser lida. Só que nada no sistema a lia de verdade: a condição que deveria comparar o código do anúncio com a lista de campanhas voltava sempre falsa, todas as vezes, desde o primeiro dia. Todo contato vindo de anúncio foi recebido com a mesma saudação genérica que qualquer outro contato, sem nenhum erro aparecer em lugar nenhum. O painel mostrava mensagem entregue. A automação estava, sem dúvida nenhuma, ligada.

Esse episódio, dentro da própria operação que sustenta este texto, não foi causado por um fornecedor descuidado nem por uma ferramenta ruim. Foi causado por uma pergunta que ninguém fez na hora certa: será que a função faz o que promete fazer, ou só está acesa? São duas perguntas diferentes, e a segunda é bem mais fácil de responder do que a primeira. Basta olhar o painel de status. Abrir a caixinha verde. Ver o contador de mensagens enviadas subindo. Nenhuma dessas três coisas confirma que a lógica por dentro está correta, e é exatamente aí que mora o problema deste texto: quem vive da própria especialidade e delega uma tarefa de comunicação a uma automação raramente tem como saber, sem testar de propósito, se o que foi delegado está sendo cumprido ou só está rodando.

Nenhuma ferramenta comercial tem incentivo para dificultar essa confusão, e vale dizer isso sem rodeio antes de seguir adiante. O painel que mostra “ativo”, “conectado” e “mensagem enviada” existe para tranquilizar quem paga a mensalidade, e um painel que constantemente perguntasse “você tem certeza de que isso está certo” seria um painel ansiogênico, difícil de vender. A tranquilidade que a interface entrega é real, só que ela mede a coisa errada: mede se o sistema está de pé, não se o sistema está fazendo o que foi contratado para fazer. Ninguém que vende automação tem motivo comercial para deixar isso claro na tela principal, porque a distinção atrapalha a venda mais do que ajuda.

Este texto reúne três episódios reais, vividos dentro da própria operação, em que a automação parecia funcionar e não funcionava, e nenhum deles avisou sozinho. Também traz o que a pesquisa sobre uso de sistemas automatizados já documentou sobre por que as pessoas param de verificar justamente quando deveriam verificar mais, e um jeito concreto de testar antes de confiar, que não depende de entender uma linha de código.

Vale um alinhamento antes de seguir, sobre o que este texto não é. Não é um argumento contra automatizar atendimento, cadastro ou qualquer outra tarefa de comunicação repetitiva. A automação, quando faz o que promete, devolve exatamente o tempo que este site inteiro discute em outros artigos: tempo que volta para o consultório, para o escritório, para a obra, para quem paga a conta no fim do mês trabalhando na própria especialidade. O argumento aqui é mais estreito e mais incômodo: colocar uma automação no ar sem testar de propósito o que ela faz, além de se ela está ligada, transforma a economia de tempo prometida numa dívida que só aparece meses depois, na forma de um cliente perdido sem explicação ou de uma resposta errada que ninguém percebeu a tempo de corrigir.

Ligado é um estado. Funcionando é outro.

A distinção entre os dois estados parece óbvia quando escrita assim, lado a lado. Na prática, ela desaparece porque a interface de quase toda ferramenta só informa um deles. Um painel de automação mostra “ativo”, “conectado”, “rodando”, “mensagem enviada”. Nenhum desses rótulos responde à pergunta “a mensagem enviada é a mensagem certa”, porque medir isso exigiria a ferramenta saber, de antemão, o que “certo” significa para o seu caso específico, e ela não sabe.

Existe um corpo de pesquisa antigo, da área que estuda como pessoas interagem com sistemas automatizados em aviação, medicina e operações militares, que descreve com precisão por que essa lacuna é tão fácil de não notar. Um trabalho de revisão de 2010, que reuniu décadas de estudos sobre o tema, separa dois fenômenos que costumavam ser tratados como um só: a complacência da automação, que é a tendência de confiar no sistema automatizado e parar de checar o que ele está fazendo, e o viés da automação, que é aceitar a recomendação ou o resultado de um sistema mesmo quando ele está errado, sem buscar informação adicional que contradiga aquilo.¹ O achado mais incômodo desse trabalho não é que as pessoas confiam demais. É que essa confiança excessiva aparece tanto em quem nunca usou aquele sistema quanto em quem é especialista nele, e treinamento sozinho não resolve, porque o problema não é falta de conhecimento. É a forma como a atenção se distribui quando existe mais de uma tarefa competindo por ela ao mesmo tempo.¹

Complacência da automação

Tendência de reduzir a frequência com que se verifica manualmente o que um sistema automatizado está fazendo, à medida que a confiança nele aumenta. Aparece com mais força quando a pessoa tem outras tarefas competindo pela mesma atenção, e não se resolve sozinho com prática repetida, porque a origem do problema é a distribuição de atenção entre tarefas, não a falta de familiaridade com o sistema.¹

Viés da automação

Tendência de aceitar a saída de um sistema automatizado como correta, sem buscar informação independente que a confirme ou a conteste, mesmo quando o sistema está funcionando de forma imperfeita. Difere da complacência porque não é apenas parar de olhar: é continuar olhando e, ainda assim, não questionar o que se vê.¹

Quem trabalha sozinho, sem ninguém revisando por cima, está exposto às duas coisas ao mesmo tempo, e por um motivo simples: a tarefa de configurar a automação e a tarefa de verificar se ela funciona competem pela mesma cabeça, no mesmo dia, geralmente espremidas entre atendimentos de verdade. Configurar já consumiu a energia que sobraria para desconfiar do resultado. O caminho de menor esforço, depois de ligar qualquer coisa, é presumir que funciona até que alguém prove o contrário, e o problema é que, numa falha silenciosa, ninguém prova o contrário, porque ninguém percebe.

A saudação que nunca citava o anúncio

Voltando ao caso do começo: o defeito não morava numa parte complicada do sistema. Morava numa comparação simples, do tipo “se o código do anúncio bater com algum da lista, inclua o nome da campanha na saudação”. A condição estava escrita. Só que a variável que ela deveria comparar chegava num formato ligeiramente diferente do que a comparação esperava, e o resultado dessa comparação era sempre falso, silenciosamente, sem lançar erro algum, porque tecnicamente não havia erro nenhum acontecendo. Uma condição que nunca é verdadeira não trava nada. Ela só nunca faz o que deveria fazer.

O que corrigiu esse episódio não foi melhorar o aviso, porque não havia aviso nenhum para melhorar. Foi mudar a pergunta feita na hora de considerar a automação pronta: em vez de “está ligada”, passou a ser “eu, fingindo ser um contato vindo de um anúncio específico, recebo a saudação que deveria receber”. A segunda pergunta exige um teste ativo, feito de propósito, com um caso simulado. A primeira só exige olhar uma tela que já estava sendo mostrada de qualquer forma.

Essa mudança de pergunta é pequena de escrever e incômoda de praticar, porque ela devolve trabalho exatamente para a pessoa que a automação prometia liberar. É também a única forma real de saber se uma automação está fazendo o que promete, porque nenhuma interface de ferramenta comercial, até hoje, mostra “eu confiro se a lógica interna está correta” como parte do próprio painel. Ela mostra que está ligada. A parte de saber se está certa continua sendo trabalho de quem contratou.

Por que um erro que nunca aparece dura para sempre

O caso do anúncio ficou rodando errado desde o primeiro dia até ser encontrado por acidente, e essa é a característica mais perigosa de uma falha silenciosa: ela não tem prazo de validade. Um erro que trava alguma coisa força alguém a olhar, porque o trabalho para. Um erro que só entrega uma versão pior do que deveria, sem travar nada, pode durar meses, porque nada no fluxo normal de trabalho pede para ser conferido de novo depois que “está funcionando” já foi assumido uma vez.

Uma pesquisa recente com mais de 2.500 tomadores de decisão empresarial, publicada em 2026, encontrou que 74% das organizações que colocaram algum tipo de atendimento automatizado por IA no ar precisaram desligá-lo ou reverter a implantação em algum momento, e entre as que já tinham processo de controle e monitoramento considerado maduro para esse tipo de sistema, o número sobe para 81%.² Vale registrar a diferença de escala antes de usar esse número para qualquer coisa: a pesquisa fala de organizações, boa parte delas maiores que a operação de um especialista sozinho, com times inteiros dedicados a acompanhar esses sistemas. Se mesmo quem tem estrutura dedicada para monitorar automação erra na maioria das vezes, a chance de um erro silencioso passar despercebido é maior, não menor, para quem toca a própria operação sozinho e não tem ninguém de sobreaviso olhando aquilo em tempo integral.

Do lado de quem recebe o atendimento automatizado, existe um segundo número que aponta na mesma direção. Um levantamento de 2026 com mais de vinte mil consumidores em quatorze países, feito no terceiro trimestre de 2025, encontrou que quase um em cada cinco consumidores relata não ter recebido nenhum benefício real de uma interação de atendimento por IA, uma taxa de fracasso quase quatro vezes maior do que a de qualquer outro uso de IA medido na mesma pesquisa.³ A causa apontada não é falta de inteligência da ferramenta. É que a maior parte dos sistemas de atendimento automatizado é construída para reduzir volume de contato, não para resolver o problema de quem está do outro lado, e por isso falha exatamente nos casos que exigem lembrar o contexto da conversa, executar uma ação concreta ou seguir uma regra específica daquele negócio, que é justamente o tipo de caso em que uma condição mal escrita, como a do anúncio, aparece.

Dá para organizar esse problema numa grade simples, cruzando o que o painel de controle mostra com o que a pessoa do outro lado de fato recebeu. É nesse cruzamento que aparece o quadrante mais perigoso dos quatro, e ele não é o que a maioria imagina de cara ao pensar em “automação que deu errado”.

O quadrante que mata mais silenciosamente é o de baixo, à esquerda: painel verde, cliente mal atendido. Não é o alarme falso, que só custa um tempo de investigação chato. Não é a falha visível, que dói, mas que pelo menos força alguém a olhar. É o ponto cego, porque nada nele pede atenção de ninguém, e ele pode durar meses exatamente pelo mesmo motivo que o caso da saudação genérica durou: nenhum sinal disponível diferenciava aquele contato mal atendido de qualquer outro contato normal.

“Quebrou o site”, e a minha lista dizia que não

O segundo episódio não envolveu nenhuma automação com inteligência artificial. Envolveu uma conferência manual malfeita, e serve para mostrar que o problema de checar a coisa errada não é exclusivo de sistema complexo. Depois de mexer no site de um cliente, a rotina de conferência era simples: o endereço abre, os links do menu levam para onde deveriam levar, as imagens aparecem. Os três itens passaram. A conclusão, comunicada ao cliente, foi que estava tudo certo.

O cliente disse que o site tinha quebrado. A resposta, com as três conferências na mão, foi que não, estava tudo certo. Ele insistiu. Insistiu de novo. Só na segunda insistência é que veio a checagem que faltava: abrir a página e olhar, de verdade, como ela aparecia, e não apenas testar se o endereço respondia. O rodapé estava sendo desenhado no topo da página, e boa parte da folha de estilo visual tinha sumido no meio da mudança. Nenhuma das três conferências da rotina detectava esse tipo de problema, porque nenhuma delas olhava a aparência renderizada da página. Olhavam se o servidor respondia, se os links existiam, se as imagens carregavam. Três perguntas corretas, sobre a coisa errada.

Esse é exatamente o par de conceitos que a prática de monitorar sistema chama de monitoramento sintético e monitoramento de usuário real, e a distinção entre os dois explica com precisão o que aconteceu. O primeiro roda um roteiro fixo, programado de antemão, testando sempre os mesmos pontos, de fora para dentro. O segundo registra o que aconteceu de fato com quem visitou a página, incluindo aparência, tempo de carregamento e erro visual, exatamente como cada pessoa viu.⁷ Um roteiro sintético só encontra o que alguém pensou em escrever nele. Um problema novo, fora do roteiro, passa batido para sempre, porque o roteiro continua reportando sucesso.

O material que a equipe de confiabilidade de sistemas do Google publicou sobre monitoramento de sistemas em grande escala chega numa conclusão parecida por outro caminho: um painel de monitoramento útil não é o que mede o máximo de coisas possível, é o que mede os sinais que de fato correspondem ao que quem usa o sistema experimenta, como latência percebida, taxa de erro real e saturação, em vez de medir só o que é fácil de medir por dentro do próprio sistema.⁴ A distinção entre “o servidor respondeu” e “a pessoa que visitou a página teve uma experiência correta” é exatamente essa: a primeira é fácil de instrumentar e barata de checar; a segunda é o que de fato importa, e costuma exigir olhar de fora, do ponto de vista de quem chega, não de dentro, do ponto de vista de quem construiu.

Monitoramento sintético

Verificação automatizada que roda um roteiro fixo e previamente definido contra um sistema, checando pontos específicos como resposta do servidor, presença de um link ou carregamento de uma imagem, sem levar em conta a experiência real de quem usa o sistema. Encontra apenas os problemas que alguém pensou em incluir no roteiro com antecedência.⁷

Existe um nome antigo para uma parte desse problema, cunhado décadas atrás por quem escreveu um dos livros de referência sobre teste de software: o paradoxo do pesticida. A ideia é que, se os mesmos testes forem repetidos indefinidamente, eles param de encontrar bugs novos, porque o sistema, metaforicamente, “desenvolve resistência” àquele conjunto específico de verificações, do mesmo jeito que uma praga desenvolve resistência a um pesticida usado sempre da mesma forma.⁶ Uma checklist de três itens, usada sempre igual depois de toda mudança no site, vira exatamente isso: eficaz contra os problemas que ela foi desenhada para pegar, cega para qualquer problema novo, porque nenhum teste fixo se atualiza sozinho para cobrir um tipo de falha que ainda não tinha aparecido da última vez em que a lista foi escrita.

Paradoxo do pesticida

Fenômeno em que um mesmo conjunto de testes, repetido sempre da mesma forma, perde eficácia progressiva para encontrar problemas novos, porque continua cobrindo apenas as categorias de erro para as quais foi originalmente desenhado. A correção não é repetir o mesmo teste com mais frequência. É revisar periodicamente o que o teste cobre, à luz dos problemas que já escaparam dele antes.⁶

O teste que funciona uma vez não é o teste

O terceiro episódio aconteceu numa frente diferente: automatizar o cadastro e a renovação de clientes a partir de um processo manual que antes era feito passo a passo, à mão, sempre igual. Antes de considerar a automação pronta, ela foi testada com oito registros idênticos, um atrás do outro, de propósito. O primeiro cadastro funcionou. A renovação dele também funcionou. O segundo registro, na sequência imediata, falhou na etapa de busca, e os seis que vieram depois falharam pelo mesmo motivo.

O detalhe que importa aqui não é a causa técnica da falha, que é irrelevante para quem lê este texto sem tocar em código. É o padrão: “funcionou” e “funciona” são frases diferentes, e a diferença entre elas só aparece na repetição. Um teste único, mesmo bem feito, prova que a automação é capaz de funcionar. Não prova que ela vai continuar funcionando na segunda vez, na terceira, na décima, porque muita automação carrega um estado interno, algo que muda depois de cada execução, e é justamente esse estado acumulado que costuma quebrar depois da primeira rodada, não a lógica em si.

O critério de “pronto”, depois desse episódio, passou a exigir repetição e comportamento consistente ao longo de várias execuções seguidas, não apenas sucesso na primeira tentativa. Isso custa tempo, e vale dizer isso sem meias palavras: testar oito vezes leva mais tempo do que testar uma vez, e para quem já está sem tempo sobrando, a tentação de parar no primeiro sucesso é real e compreensível. O custo de não fazer isso, no entanto, tende a ser maior, porque uma automação que falha na segunda execução, sem ninguém testando a segunda execução antes de colocá-la para valer, vai falhar exatamente na hora em que estiver lidando com um cliente de verdade, não com um teste.

A razão técnica por trás desse tipo de falha, sem entrar em detalhe de código, costuma ser simples de entender por analogia: pense numa ficha de cadastro em papel, preenchida à mão. A primeira ficha de um arquivo vazio é fácil de guardar, porque não existe nada antes dela para confundir. A segunda ficha precisa ser comparada com a primeira antes de ser guardada, para não duplicar, e é justamente esse passo de comparação, ausente na primeira execução por não haver nada ainda para comparar, que costuma esconder o defeito. Automação funciona do mesmo jeito: o primeiro registro nunca exercita o caminho que lida com “já existe algo parecido guardado”, porque não existe nada parecido ainda. Só o segundo exercita esse caminho, e é exatamente ali, na comparação com o que já foi feito antes, que a lógica malfeita apareceu.

Vale registrar também o que esse episódio não foi: não foi um problema de a ferramenta escolhida ser ruim, nem de falta de conhecimento técnico de quem configurou. Foi um problema de critério de aceitação malfeito, o tipo de erro que qualquer pessoa, técnica ou não, comete ao testar qualquer coisa nova pela primeira vez. O alívio de ver o primeiro teste dar certo é real, e é justamente esse alívio que empurra para a comemoração antecipada, antes de a segunda rodada provar se o primeiro resultado era sorte ou era, de fato, o comportamento esperado.

# premissa: testar uma vez leva 5 minutos, ja com a preparacao pronta
# premissa: repetir o teste mais duas vezes, com a preparacao ja feita,
# leva 3,5 minutos cada repeticao (nao reinicia do zero)
minutos_teste_unico = 5
minutos_por_repeticao_extra = 3.5
repeticoes_extras = 2
custo_testar_direito = minutos_teste_unico + (minutos_por_repeticao_extra * repeticoes_extras)
print(custo_testar_direito)  # 12.0 minutos, contra 5 de testar uma vez so

Doze minutos contra cinco. A diferença de sete minutos é o preço de saber, antes de qualquer cliente real passar por ali, se a automação aguenta ser usada mais de uma vez. Comparado ao tempo gasto depois, corrigindo um cadastro que travou no meio, explicando para o cliente por que a renovação dele não processou, ou pior, sem nunca descobrir quantos outros passaram pela mesma falha sem avisar, sete minutos é o tipo de custo que parece caro só até a segunda vez que alguém decide pular esse passo.

Quando o erro chega ao paciente antes de qualquer pessoa ver

Existe uma diferença que separa automação de atendimento automático de qualquer outro tipo de conteúdo produzido com apoio de ferramenta: um texto redigido para publicar depois passa, ou deveria passar, por uma revisão antes de sair no ar. Uma automação que responde em tempo real não passa por revisão nenhuma antes de chegar a quem está do outro lado, porque a proposta inteira dela é justamente não precisar de uma pessoa no meio naquele momento. Isso muda o tamanho do risco para quem atua em profissão regulada, porque o texto que sai errado não fica esperando aprovação. Ele já foi entregue quando alguém, enfim, percebe que a condição estava quebrada.

A Resolução CFM nº 2.336/2023 veda, no artigo 11, inciso XII, que o médico garanta, prometa ou insinue bons resultados de tratamento, em qualquer meio de comunicação.⁸ A norma não faz exceção para mensagem gerada por automação, e não poderia fazer, porque a responsabilidade pelo que sai em nome do profissional não muda conforme quem ou o que escreveu a frase. Uma saudação automática mal configurada, que por erro insira um trecho de texto comercial padrão numa conversa sobre um procedimento específico, sem ninguém ter revisado aquela combinação específica antes de ela existir, corre o mesmo risco de qualquer outra peça de comunicação da clínica. A diferença é que, numa peça publicada, alguém leu antes de publicar. Numa automação com uma condição quebrada, ninguém leu, porque a mensagem nasceu e morreu dentro de uma conversa privada, sem passar pelos olhos de ninguém além do paciente que a recebeu.

Isso não é motivo para não automatizar. É motivo para tratar a fase de teste de uma automação de atendimento, em profissão regulada, com o mesmo cuidado que se teria revisando uma peça antes de publicá-la, e não com o cuidado que se teria configurando um recurso qualquer de conveniência. Testar a automação simulando os cenários mais sensíveis, não só o cenário feliz em que tudo corre como esperado, é o que substitui a revisão que, nesse formato, não existe no momento em que a mensagem sai.

Vale separar dois momentos que costumam ser confundidos na hora de decidir se uma automação de atendimento é segura para uma profissão regulada. O primeiro é revisar o conteúdo que a automação pode enviar: os textos, modelos e variações que ela tem disponíveis para combinar. Essa parte, feita uma vez, com calma, antes de qualquer coisa entrar no ar, é comparável a revisar uma peça de divulgação. O segundo momento, bem mais negligenciado, é revisar as combinações que a lógica da automação pode produzir ao juntar esses textos com dado variável, como nome, procedimento ou origem do contato. Um texto sóbrio, revisado e aprovado isoladamente, pode formar uma frase promissora ou enganosa quando combinado, por erro de lógica, com a variável errada. O problema do caso da saudação genérica não estava em nenhum texto isolado. Estava na combinação que a condição quebrada deixava de produzir, e ninguém tinha testado essa combinação especificamente antes de considerar o sistema pronto.

O que muda conforme quem revisa

Quem toca a operação inteiramente sozinho carrega o problema mais difícil dos três formatos, porque a mesma pessoa que configura a automação é a única que poderia testá-la de propósito, e o tempo para as duas tarefas sai do mesmo bloco do dia, quase sempre espremido entre atendimentos reais. Nessa condição, o caminho de menor resistência é presumir que funciona, porque testar de propósito, simulando um cenário adverso, exige parar de fazer o trabalho remunerado para simular um problema que talvez nem exista. É trabalho que compete diretamente com o trabalho que paga a conta, e por isso costuma perder.

Com uma pessoa de apoio fixa, uma secretária ou um auxiliar administrativo, existe a chance real de dividir as duas tarefas: quem configura não precisa ser, necessariamente, quem testa. Mas essa divisão só funciona se a pessoa de apoio souber o que está testando, e não apenas se está testando alguma coisa. Pedir “veja se está funcionando” produz o mesmo resultado que o próprio especialista produziria sozinho, olhando o painel e vendo verde. Pedir “finja ser um cliente que chegou pelo anúncio X e me diga exatamente o que a automação respondeu” produz um teste de verdade, porque descreve o comportamento esperado, não apenas a intenção de testar.

Quem trabalha com sócio ganha um segundo par de olhos, mas ele só ajuda se enxergar de um ângulo diferente do primeiro. Duas pessoas testando a mesma automação da mesma forma encontram os mesmos problemas, ou a mesma ausência deles. O ganho real de ter sócio, nesse contexto específico, aparece quando um dos dois testa pensando como quem configurou o sistema, checando se a lógica está certa, e o outro testa pensando como quem chega de fora, sem saber nada sobre como o sistema foi montado por dentro, exatamente como o cliente vai chegar.

Existe um quarto formato, menos comum entre quem lê este texto, mas que vale nomear: a operação grande o bastante para ter alguém de apoio dedicado só a testar, sem acumular essa função com nenhuma outra. É um luxo raro para quem vive da própria especialidade sozinho ou com equipe mínima, e é também o formato que mais se aproxima do que operações de tecnologia de grande porte fazem, com times inteiros dedicados só a garantir que sistemas automatizados se comportem como deveriam. A distância entre esse formato e o de quem testa sozinho, no meio de um dia cheio de atendimento, não é de conhecimento técnico. É de tempo disponível para dedicar a uma tarefa que não gera faturamento direto naquele momento, e essa distância explica por que a maioria das falhas silenciosas descritas neste texto acontece exatamente em operações pequenas, não porque quem as toca seja menos cuidadoso, mas porque o tempo para o cuidado extra simplesmente não sobra do mesmo jeito.

A objeção real: “e se der problema depois que eu já paguei?”

Um cliente, negociando o conserto de uma loja virtual por mensagem, perguntou algo que aparece quase sempre da mesma forma, em quase toda negociação: existe algum tipo de garantia depois que o trabalho termina, se acontecer algum defeito ou problema depois? A resposta dada foi que sim, existe um período de suporte depois de qualquer ajuste, normalmente o tempo suficiente para o próprio uso revelar se algo ficou errado, mas que isso raramente é necessário quando o que foi feito é configuração, não alteração de código, porque configuração malfeita costuma aparecer rápido, enquanto código malfeito pode aparecer só meses depois.

Essa distinção, entre o que aparece rápido e o que pode demorar para aparecer, é o cerne deste texto inteiro, só que aplicada a uma pergunta que a maioria não pensa em fazer antes de contratar: quanto tempo uma automação de atendimento pode rodar errada antes de alguém perceber, e o que exatamente vai fazer alguém perceber? Se a resposta for “só quando um cliente reclamar”, como no caso do site que “quebrou”, o período de garantia contratual não resolve o problema de fundo, porque o defeito pode aparecer bem depois do prazo de suporte terminar, e vai continuar rodando até então, sem gerar reclamação nenhuma, porque ninguém reclama de uma saudação genérica. Reclama-se do que incomoda visivelmente. Uma condição que retorna sempre falsa não incomoda ninguém, porque ninguém do outro lado sabe que deveria ter recebido outra coisa.

A resposta honesta para quem faz essa pergunta não é prometer um prazo de garantia mais longo. É explicar que garantia de tempo cobre o defeito que aparece sozinho, e que o defeito silencioso, por definição, não aparece sozinho: ele precisa ser procurado. Nenhum contrato, por mais generoso que seja o prazo de suporte, substitui o hábito de testar de propósito antes de considerar qualquer automação pronta para valer.

Segunda ordem: quando a própria checagem está cega

Existe uma camada mais incômoda ainda, que só aparece depois que alguém já aceitou testar de propósito, simulando cenários, repetindo a execução várias vezes: e se o próprio roteiro de teste estiver testando a coisa errada? Um roteiro de verificação, escrito uma vez, carrega os mesmos limites do paradoxo do pesticida descrito antes. Ele pega o que foi pensado na hora de escrevê-lo. Não pega o que ninguém imaginou que pudesse dar errado.

A prática de engenharia que lida de frente com esse problema, dentro de operações de tecnologia de grande porte, se chama engenharia do caos, e o princípio central dela é provocar falha de propósito, em ambiente controlado, para descobrir antecipadamente o que um sistema faz quando algo sai fora do esperado, em vez de esperar que a falha aconteça sozinha, sem aviso, num momento pior.⁵ A versão possível disso, para quem opera sozinho e não tem ambiente de teste separado, não exige a mesma sofisticação. Exige o mesmo espírito: em vez de testar só o caminho feliz, aquele em que tudo dá certo, testar de propósito o caminho que deveria falhar, mandando um dado errado, um código de anúncio que não existe, um nome com caractere estranho, e conferir se a automação reage do jeito esperado a isso, ou se ela simplesmente ignora o problema e segue em frente como se nada tivesse acontecido.

O que cada tipo de verificação pega, e o que ela deixa passar

Tipo de verificação	O que ela pega	O que ela deixa passar
Olhar o painel de status	se a ferramenta está ligada e sem erro declarado	se a lógica interna faz o que deveria fazer
Testar uma vez, no caminho feliz	se a automação é capaz de funcionar	se ela continua funcionando na segunda e na terceira vez
Testar várias vezes seguidas, sempre do mesmo jeito	falhas de repetição e de estado acumulado	problemas fora do roteiro original de teste
Simular o cenário que deveria falhar	se a automação reage certo a um dado fora do esperado	o que nem você imaginou que pudesse dar errado
Olhar como quem chega de fora, sem saber como foi montado	erro visual e de experiência que o próprio autor não percebe mais	o que só aparece com volume real de uso, ao longo do tempo

Nenhuma linha dessa tabela é suficiente sozinha. Cada uma cobre um ponto cego diferente das outras quatro, e é por isso que confiar apenas na mais fácil de fazer, olhar o painel, deixa passar exatamente os problemas que mais duram sem serem notados.

O checklist antes de confiar que está funcionando

Reunir os três episódios deste texto numa única pergunta ajuda mais do que lembrar cada um separadamente: a automação faz o que promete fazer, testado de propósito, mais de uma vez, e do jeito que quem recebe vai de fato experimentar, ou ela só está ligada?

Nenhuma pergunta dessa lista garante que nada vai dar errado depois. O objetivo não é esse. É reduzir a chance de que, quando alguma coisa der errado, ela fique rodando invisível por meses, do jeito que a saudação genérica ficou, até alguém descobrir por acaso ou até um cliente insistir duas vezes para ser ouvido.

Vale um último cuidado sobre como usar essa lista, porque ela mesma corre o risco de virar, com o tempo, mais um roteiro fixo sujeito ao paradoxo do pesticida descrito antes. As sete perguntas cobrem os três episódios narrados aqui, mais o que a pesquisa sobre automação documentou. Não cobrem, com certeza, todo tipo de falha silenciosa que ainda vai aparecer, em automações que ainda nem existem hoje. Usar essa lista como ponto de partida, revisando e somando item a ela conforme novos problemas aparecerem na sua própria operação, é mais honesto do que tratá-la como resposta definitiva e completa para qualquer automação futura.

O que continua sem resposta

Nem tudo neste texto está fechado, e dizer isso é parte da régua que ele mesmo defende. Não existe, dentro da própria operação descrita aqui, um protocolo formal e documentado de quantas vezes uma automação nova precisa ser testada antes de valer para um cliente real. O critério usado hoje nasceu dos episódios que já deram errado, não de um plano desenhado antes deles acontecerem, e isso significa que ele provavelmente ainda tem lacunas parecidas com as que os três casos deste texto revelaram, só que ainda não descobertas.

Também não há uma resposta pronta para quanto tempo, em média, uma falha silenciosa leva para ser percebida quando ninguém está procurando por ela de propósito. O caso da saudação genérica só foi descoberto porque alguém, por outro motivo qualquer, revisou aquele fluxo de perto. Não existe registro de quantas outras automações, dentro da mesma operação, podem estar rodando de forma parecida, erradas e silenciosas, simplesmente porque ainda ninguém parou para testá-las do jeito descrito neste texto. Essa é a parte mais desconfortável de escrever sobre verificação: o próprio texto que defende testar de propósito não pode garantir que já testou tudo que deveria.

Fica também sem resposta fechada uma pergunta de fundo, mais filosófica do que operacional: quanto tempo vale a pena gastar testando antes de aceitar que, em algum ponto, é preciso confiar e seguir em frente. Testar demais também tem custo, e um custo real, medido em horas que poderiam ir para atendimento pago. Este texto não resolve esse equilíbrio com uma fórmula. Oferece só um critério mínimo, o mais barato de aplicar: testar mais de uma vez, testar o cenário que deveria falhar e testar do ponto de vista de quem recebe. Onde exatamente parar depois disso continua sendo uma decisão de quem toca a própria operação, caso a caso, sem régua pronta que sirva para todos.

Glossário

Complacência da automação

Tendência de reduzir a frequência com que se verifica manualmente o que um sistema automatizado está fazendo, à medida que a confiança nele aumenta. Aparece com mais força quando a pessoa tem outras tarefas competindo pela mesma atenção, e não se resolve sozinho com prática repetida, porque a origem do problema é a distribuição de atenção entre tarefas, não a falta de familiaridade com o sistema.¹

Monitoramento sintético

Verificação automatizada que roda um roteiro fixo e previamente definido contra um sistema, checando pontos específicos como resposta do servidor, presença de um link ou carregamento de uma imagem, sem levar em conta a experiência real de quem usa o sistema. Encontra apenas os problemas que alguém pensou em incluir no roteiro com antecedência.⁷

Paradoxo do pesticida

Fenômeno em que um mesmo conjunto de testes, repetido sempre da mesma forma, perde eficácia progressiva para encontrar problemas novos, porque continua cobrindo apenas as categorias de erro para as quais foi originalmente desenhado. A correção não é repetir o mesmo teste com mais frequência. É revisar periodicamente o que o teste cobre, à luz dos problemas que já escaparam dele antes.⁶

Viés da automação

Tendência de aceitar a saída de um sistema automatizado como correta, sem buscar informação independente que a confirme ou a conteste, mesmo quando o sistema está funcionando de forma imperfeita. Difere da complacência porque não é apenas parar de olhar: é continuar olhando e, ainda assim, não questionar o que se vê.¹

Referências

1. ↑ Raja Parasuraman; Dietrich H. Manzey. Complacency and Bias in Human Use of Automation: An Attentional Integration. Human Factors: The Journal of the Human Factors and Ergonomics Society, vol. 52, issue 3. 2010. consultar Acesso em 2026-09-28.
2. ↑ Sinch. When AI Chatbots Fail In Customer Support: The True Cost. Sinch Blog (pesquisa com mais de 2.500 tomadores de decisão empresarial). 2026. consultar Acesso em 2026-09-28.
3. ↑ Qualtrics XM Institute. AI-Powered Customer Service Fails at Four Times the Rate of Other Tasks. Qualtrics (2026 Consumer Experience Trends Report, mais de 20.000 consumidores em 14 países, Q3 2025). 2026. consultar Acesso em 2026-09-28.
4. ↑ Google (Site Reliability Engineering). Google SRE monitoring ditributed system - sre golden signals. Google SRE Book, capítulo Monitoring Distributed Systems. 2026. consultar Acesso em 2026-09-28.
5. ↑ comunidade de engenharia de caos (originado na Netflix). PRINCIPLES OF CHAOS ENGINEERING - Principles of chaos engineering. principlesofchaos.org. 2026. consultar Acesso em 2026-09-28.
6. ↑ Katalon (conceito original de Boris Beizer, 1990, livro Software Testing Techniques). Pesticide Paradox: Why Old Tests Stop Finding Bugs. Katalon Resources Center. 2026. consultar Acesso em 2026-09-28.
7. ↑ DebugBear. Synthetic Monitoring vs. Real User Monitoring (RUM): A Comparison. DebugBear Blog. 2026. consultar Acesso em 2026-09-28.
8. ↑ Conselho Federal de Medicina. Resolução CFM nº 2.336/2023, Art. 11, XII (veda garantir, prometer ou insinuar bons resultados). CFM, publicada em 13/09/2023, Edição 175, Seção 1, Página 312. 2023. consultar Acesso em 2026-09-28.