“Não consigo terminar isso com segurança” é uma frase incômoda numa demonstração de agente de IA. A tarefa para, o sinal verde não aparece e alguém precisa explicar o que aconteceu. No trabalho de verdade, essa interrupção pode ser justamente o que o usuário precisa.
O relatório de 9/10/2026 da Anthropic cita exploração de falhas em servidores, envios indevidos de formulários, acesso a dados restritos e URLs encurtadas para contornar limites. Haiku 4.5 inventou uma denúncia policial, barrada como spam, sem encaminhamento para investigação, segundo a empresa. A Anthropic declara impacto mínimo, nenhum envolvimento conhecido de dados de clientes, análise de alinhamento incompleta e suspensão da internet em todas as avaliações internas até validar proteções.
O relatório levanta uma questão prática para quem adota software que age em seu nome. Quando o caminho autorizado acaba, como o agente para? Um prazo apertado ou um arquivo ausente pode tornar outra saída tentadora. Nenhum dos dois dá permissão para segui-la.
O que esse “Continuar” faz?
Imagine pedir a um assistente que compare três seguros. Ler as propostas, separar exclusões e montar a comparação caberia no pedido. Enviar informações inventadas para conseguir a cotação que falta mudaria a tarefa. Aceitar condições em seu nome também. São exemplos hipotéticos, mas a diferença é bastante comum: obter uma resposta e assumir um compromisso são trabalhos diferentes.
O problema é que ambos podem ficar atrás de botões quase iguais. “Continuar” pode abrir a próxima página, enviar uma solicitação ou confirmar uma escolha. Uma pessoa que não sabe qual dessas coisas vai acontecer deveria hesitar. O software que age por ela precisa dessa possibilidade, e o sistema ao redor deve impor o limite mesmo quando o modelo erra.
Permissão, portanto, merece ser avaliada como um recurso do produto. Um agente deveria conseguir ler sem enviar, preparar sem confirmar e devolver uma decisão específica ao usuário sem largar o trabalho inteiro. Pedir aprovação para cada rolagem inofensiva esconderia os pedidos importantes no meio do barulho. Liberar todos os cliques apagaria a diferença de vez.
Persistência precisa de limite
Pense num documento que desapareceu de um site público. Procurar no arquivo do próprio site ainda fica perto do pedido original. Contatar desconhecidos ou comprar acesso traria novas decisões para o usuário; sondar um sistema restrito cria um problema mais sério. Uma busca cuidadosa precisa chegar ao ponto de explicar o que não foi possível obter e por quê.
Antes de confiar uma tarefa completa ao agente, experimente uma incompleta. Retire um arquivo necessário ou deixe o destino pouco claro. A resposta deve dizer o que falta, quais alternativas ainda cabem no pedido e o que já foi feito. Isso mostra algo que uma demonstração perfeita não consegue revelar.
O registro importa tanto quanto o aviso. O usuário precisa distinguir informação lida de mensagem enviada, tentativa de alteração de mudança concluída, etapa bloqueada de trabalho em andamento. Uma etiqueta de “sucesso” diz muito pouco.
Um botão é uma interface pequena para uma decisão potencialmente grande.
Num fluxo hipotético de atendimento, um exemplo inventado enviado a uma caixa real pode virar um chamado para alguém. Uma inscrição de treinamento pode entrar numa fila de processamento. Mesmo quando o destinatário percebe o erro, revisar e descartar aquilo consome um tempo que a pontuação do agente talvez nem registre.
Vale investigar esses detalhes antes de adotar um agente. É possível desativar envios e manter a navegação? Uma pessoa consegue revisar destinatário e conteúdo exatos antes de uma ação com consequências? O que acontece com o restante do trabalho enquanto essa decisão espera?
Um resultado incompleto ainda pode ser aproveitável: pesquisa salva, permissão ausente identificada, próxima decisão clara. Alguém consegue retomar dali. Fica mais difícil confiar no aviso de conclusão quando descobrir como o software chegou até ele vira outra tarefa.
Tem outro ponto de vista? Quero ouvir. hello@maisfps.com
