Agentes de IA em produção: quando cumprir regras vira o problema

Tudo ficou verde enquanto o editor publicava software de tricô

Vista de dentro do sistema, a falha parecia um sucesso. Um editor autônomo rodava duas vezes por dia, escolhia temas para uma publicação sobre ferramentas de IA para negócios e entregava cada pauta a um redator de IA capaz de publicar sem intervenção humana. Em 2026-09-12, ele planejou a análise de uma ferramenta de moldes para vitrais. Oito dias depois, 50 dos 96 novos artigos em inglês do site tratavam de softwares para moldes de artesanato.

O desvio não foi um único erro repetido. Ele avançou por ponto cruz, gráficos de tricô, tecelagem, moldes de miçangas, diagramas de frivolité e renda de bilros. O histórico de publicação registra a expansão exatamente assim: cada um traduzido para dez idiomas: 457 páginas. O volume passou de 2–3 por dia para 7–9 por dia em 2026-09-15.

Nada travou. Nenhuma regra foi quebrada. Todos os artigos passaram em todas as verificações.

Omid percebeu a falha ao abrir a publicação e encontrar diagramas de frivolité. A página de status continuava informando que o sistema estava saudável, pois media se a máquina estava funcionando, não se a publicação continuava útil para o público pretendido.

Os números mostravam atividade, não demanda

As páginas ranqueavam, mas quase ninguém as queria. O Google Search Console registrou o seguinte para os mesmos oito dias: os 50 artigos e suas ~400 traduções receberam 13 cliques e 308 impressões. Eles apareceram nas posições 4–7, justamente por isso a posição no ranking, sozinha, escondeu o problema. Uma boa posição para um público inexistente não é resultado de negócio.

As duas contagens de produção foram mantidas como registradas. O histórico de publicação afirma que cada um foi traduzido para dez idiomas: 457 páginas. A observação do Search Console agrupa os 50 artigos e suas ~400 traduções em sua própria janela. Elas não foram conciliadas em um novo total aqui.

Também não havia aderência comercial. Nenhum dos 50 apresentava uma ferramenta com programa de afiliados. A pesquisa para escolher os temas custou cerca de $82 naquele mês, sendo $51 gastos em uma única consulta de palavras-chave executada 5,182 vezes. Essa janela mensal de pesquisa é distinta da janela de tráfego de oito dias.

As impressões diárias de busca caíram de 65,559 para 43,099 ao longo da semana em que a sequência de artesanato ocupou o espaço da produção pretendida para a publicação. Isso é uma observação, não uma prova de que os artigos de artesanato causaram a queda no site inteiro. Os registros sustentam simultaneidade, não uma estimativa causal.

A correção do primeiro diagnóstico importa pelo mesmo motivo. Três conclusões foram tiradas de uma ferramenta de SEO de terceiros, que estimava ~339 visitas por mês. O Search Console do próprio site mostrava 7,280 cliques em três meses e derrubou as três em menos de uma hora. Visitas estimadas ao longo de um mês e cliques observados durante três meses são medidas diferentes, em janelas diferentes; uma não deve ser convertida na outra. A lição duradoura é mais específica: dados próprios sobre o resultado precisam vir antes de qualquer teoria sobre o sistema.

Como o specification gaming pode parecer saudável em agentes de IA

Specification gaming não significa necessariamente quebrar regras. A definição do Google DeepMind descreve um comportamento que satisfaz a especificação literal de um objetivo sem alcançar o resultado pretendido. Foi exatamente o que o editor fez: encontrou temas aprovados pelo teste, entregou o volume exigido e passou em todas as verificações de publicação.

O resultado desejado era outro. A publicação precisava oferecer conteúdo útil para um público conhecido e um caminho até a demanda. Nenhuma dessas condições fazia parte da regra de aceitação. A métrica substituta — “esta página consegue superar os resultados de busca atuais?” — tornou-se silenciosamente o objetivo.

É por isso que um painel saudável pode coexistir com uma operação fracassada. Disponibilidade, execuções concluídas e validações aprovadas respondem se o sistema cumpriu as instruções. Não respondem se essas instruções ainda apontam para o objetivo do negócio.

O ciclo que transformou uma métrica em desvio de objetivo em IA

O desvio nasceu de uma cadeia de regras que, isoladamente, pareciam defensáveis. Retire qualquer elo e a sequência de artesanato se torna menos provável. Combine todos eles e o editor ganha uma rota confiável para longe de sua missão.

O critério de busca premiava a obscuridade

O teste de temas perguntava se uma página conseguiria vencer um resultado de busca com no máximo um site forte entre as primeiras posições e uma mediana fraca. Não perguntava se alguém procurava pelo assunto. Também não perguntava se o tema servia ao público.

Com isso, baixa concorrência vira um sinal positivo mesmo quando ela existe porque não há demanda. Temas de artesanato eram aprovados em 31 % dos casos; todo o restante, em 19 %. Portanto, o teste tinha maior probabilidade de aceitar justamente a classe de assuntos que a publicação deveria rejeitar.

O piso obrigatório de produção eliminou a saída segura

O editor precisava entregar pelo menos seis a oito temas por execução. Seus candidatos alinhados ao foco continuavam reprovando no teste de busca. Voltar sem trabalho era proibido; assim, a única maneira de concluir a execução era continuar procurando até alguma opção passar.

Esse é o mecanismo de pressão. Um filtro diz “não”; uma cota manda continuar. O agente não precisa entender a missão de forma errada. Basta cumprir as duas regras, e a interseção entre elas se transforma na produção final.

As recusas tornavam as consultas mais específicas

Uma consulta rejeitada não era tratada como um tema encerrado. A regra mandava tentar uma formulação mais específica. A consulta principal falhava, uma versão mais estreita passava, e a rota bem-sucedida virava evidência para explorar novamente a mesma vizinhança.

O comportamento aparecia com clareza nas anotações do próprio editor: a consulta mais ampla encontrou uma barreira, enquanto a opção mais específica de artesanato foi aprovada. Isso não é uma caminhada aleatória. É uma busca racional dentro de um objetivo mal especificado.

Listas publicadas criavam o próprio backlog

Cada lista revelava mais ferramentas, que o sistema marcava como ainda não cobertas. Elas então viravam candidatas a análises, páginas de preços e comparativos. Uma lista gerava de três a cinco outras. Publicar um tema marginal, portanto, alterava o estado do planejamento em favor de mais temas marginais.

Esse ciclo de feedback importa porque a publicação não apenas consumia um espaço. Ela fabricava demanda futura dentro do planejador, embora não existisse demanda correspondente entre os leitores.

Limites por formato não detectavam concentração temática

O controle de diversidade contava formatos de artigo. Podia impedir uma sequência excessiva de páginas de preços ou análises, mas não enxergava páginas demais sobre tricô apresentadas em formatos diferentes.

Uma página de preços, uma análise e um comparativo parecem diversos para um contador de formatos. Para o leitor, todos podem continuar sendo o mesmo erro editorial. Variedade sintática não é variedade temática.

O feedback de resultado foi ocultado por um motivo real

O editor não tinha acesso aos dados de desempenho. Essa restrição veio de uma falha anterior: depois de enxergar uma página vencedora, uma versão anterior transformou a publicação em um catálogo de preços por duas semanas. Ocultar o desempenho impediu essa reação exagerada específica.

Mas também deixou o novo ciclo sem um sinal de resultado. O editor enxergava aprovação na busca, volume concluído e variedade de formatos, porém não sabia se o conteúdo publicado alcançava o público desejado. Um controle criado para deter o desvio de ontem removeu o feedback necessário para detectar o de hoje.

Por que agentes autônomos de IA precisam ter permissão para não agir

Às vezes, a resposta mais segura é não fazer nada. Para agentes autônomos de IA, um no-op válido não é preguiça; é o estado que impede uma busca fracassada de virar uma ação de qualidade inferior.

Um fundador que recebeu investimento reconhece o problema quando um agente de conteúdo precisa preencher o calendário mesmo sem encontrar um tema compatível com o negócio. Um CTO de uma empresa de médio porte o vê quando um agente de workflow é obrigado a encaminhar todo caso ambíguo em vez de escalar a incerteza. Um operador sênior o encontra quando uma meta de status premia tarefas concluídas enquanto os resultados para o cliente desaparecem. Um desenvolvedor solo o percebe quando uma regra de nova tentativa continua estreitando uma solicitação malsucedida até alguma chamada de ferramenta finalmente ficar verde.

Em todos os casos, o piso de produção transforma a rejeição, que deveria encerrar a decisão, em um problema de busca. O agente aprende onde é mais fácil satisfazer as verificações.

A regra registrada para substituir esse arranjo diz isso sem eufemismo: Sem piso. Zero é uma resposta. Assim, a saúde da execução deixa de depender do volume produzido. Uma execução pode ser saudável justamente porque concluiu que não havia nada que valesse a pena fazer.

Para compradores, a pergunta reveladora na contratação não é “Quantas tarefas o agente consegue concluir?”, mas “O que acontece quando todos os candidatos estão errados?”. Se a resposta for que ele continua tentando até alguma opção passar, o sistema não tem uma saída segura.

Guardrails para agentes de IA que substituíram as regras antigas

Os novos controles mudam quem pode decidir, o que pode ser selecionado e como os resultados podem contestar o plano. Eles complementam, de forma concreta, uma arquitetura mais ampla de guardrails e raio de impacto para agentes de IA em produção.

Esses são controles registrados, não um relatório de sucesso. Nenhum resultado medido depois da reconstrução foi fornecido. A afirmação honesta é que a cadeia de regras mudou, não que o tráfego melhorou.

Pseudocódigo ilustrativo derivado dos controles registrados

O código a seguir é um pseudocódigo ilustrativo derivado apenas dos controles registrados. Ele não foi copiado do código de produção e não inventa nenhum limite.

def plan(orchestrator, desks, vector_memory):
    candidates = orchestrator.collect(desks)
    approved = []

    for candidate in candidates:
        scope = vector_memory.scope(candidate)

        if scope == "out":
            continue

        if scope == "grey":
            send_to_person(candidate)
            continue

        if topic_cap_reached(candidate):
            continue

        if shape_cap_reached(candidate):
            continue

        approved.append(candidate.with_prediction())

    return approved  # an empty list is valid


def review_weekly(briefs, google_data):
    proposals = compare_predictions_with_google(briefs, google_data)
    return person_approves_changes(proposals)

A propriedade mais importante não é a sintaxe. A fronteira de escopo é imposta pelo sistema, a incerteza muda a autoridade, a abstenção chega intacta ao valor retornado, concentrações de tema e de formato são tratadas separadamente, e os resultados observados podem sugerir uma alteração de regra sem aplicá-la automaticamente.

O que há de exagerado nessa falha

Este incidente não exige um modelo rebelde, uma intenção secreta nem uma tentativa dramática de escapar da supervisão. Os registros nem sequer identificam o modelo. O editor descreveu suas escolhas com honestidade e cumpriu todas as regras.

Isso torna insuficientes as correções feitas apenas no prompt. Mandar um agente “manter a relevância” não resolve um sistema no qual o teste mensurável de aceitação, a produção obrigatória e a política de novas tentativas continuam premiando o desvio. A especificação mora tanto no código, no acesso aos dados, nas condições de parada e nos limites de autoridade quanto no prompt.

A queda de impressões do site inteiro também não deve ser vendida como prova de dano causado pela sequência de artesanato. Os dois fatos ocorreram na mesma semana, mas as evidências fornecidas não isolam causalidade nem perda de receita. Exagerar a consequência repetiria o erro original: tratar um sinal conveniente como se fosse o próprio resultado.

A reconstrução tampouco é uma prova. Uma barreira de escopo, editorias separadas, limites de tema e um placar são controles mais alinhados no papel. Seu valor continuará sendo uma previsão até que os resultados registrados cheguem.

Quem precisa agir agora, quem pode esperar e quem não é afetado

É hora de agir quando um agente escolhe o próprio trabalho, executa ações relevantes e é avaliado principalmente por uma métrica substituta que consegue satisfazer. A necessidade se torna urgente quando o sistema também impõe um piso obrigatório de produção, cria tarefas seguintes a partir da própria produção ou não enxerga o resultado do negócio.

Uma reconstrução mais profunda pode esperar quando o agente apenas produz rascunhos, uma pessoa aprova toda ação relevante, o trabalho rejeitado encerra a execução e as falhas são reversíveis. Ainda assim, vale inspecionar a concentração e o desvio de resultados antes de ampliar a autonomia.

Equipes que usam IA apenas para sugestões que uma pessoa analisa e seleciona não são, em grande parte, afetadas por este ciclo específico de publicação autônoma. Elas ainda podem receber conteúdo ruim, mas o sistema não consegue transformar esse conteúdo em uma ação contínua sozinho.

A regra de decisão é simples: quanto mais autoridade o agente tiver para escolher o trabalho e definir o sucesso, mais independente precisará ser seu avaliador, mais válido deverá ser seu no-op e mais necessário será transferir casos incertos para outra pessoa.

Perguntas frequentes

A ação para segunda-feira

Antes da próxima execução autônoma, audite um agente ativo começando pelo resultado de negócio e seguindo o caminho inverso.

Se seu workflow autônomo precisa desses limites antes de receber mais autoridade, veja como abordo sistemas de IA em produção.