Ideias ganham valor quando saem da conversa e entram em ação.

Por Alexandre Itida · 24 de setembro de 2026

Executar uma tarefa não é o mesmo que comprovar seu resultado.

Um agente de inteligência artificial recebe uma tarefa, consulta ferramentas, toma decisões e apresenta uma resposta: “Concluído”. Mas o que essa palavra significa? Ele executou os passos que havia planejado? Produziu o resultado solicitado? Esse resultado foi confirmado no sistema de destino? Ele conseguiria repetir a tarefa em condições semelhantes?

Tenho interesse em estudar essa diferença porque quero utilizar agentes em projetos reais. Para isso, não basta que produzam respostas convincentes. Preciso compreender o que fizeram, quais evidências sustentam o resultado e quais limites permanecem desconhecidos.

Uma resposta correta não conta toda a história

Em uma avaliação tradicional de perguntas e respostas, podemos comparar a saída com uma resposta esperada. Um agente pode precisar navegar por páginas, consultar arquivos, executar código ou interagir com sistemas antes de chegar ao resultado. É possível atingir o objetivo por um caminho inadequado ou executar todos os passos planejados sem alcançar o objetivo.

O AgentBench (ICLR 2024) avalia modelos em ambientes interativos e considera decisões ao longo de múltiplas etapas. A pergunta prática é: estamos medindo a qualidade de uma resposta ou a capacidade de concluir uma tarefa no ambiente em que ela precisa acontecer?

O que significa dizer que uma tarefa foi concluída?

Imagine uma atualização de site. O agente pode editar arquivos e registrar a alteração no GitHub. Isso não demonstra, por si só, que o visitante está recebendo a página correta. Precisamos de outra evidência: conferir a versão entregue pelo site e observar se o comportamento esperado foi preservado.

No desenvolvimento do AI Itida, houve uma situação ilustrativa: depois de ajustarmos a marca do cabeçalho, uma prévia visual ainda mostrava a versão antiga. O código tinha sido alterado, mas o material apresentado para minha avaliação não refletia a mudança. A prévia foi corrigida e conferida novamente. Mais tarde, autorizei a nova versão e confirmei visualmente o resultado no endereço público.

Esse episódio não é uma avaliação científica da confiabilidade de agentes. É um exemplo operacional de por que executar uma ação, verificar seu efeito e demonstrar confiabilidade são afirmações diferentes.

Um acerto isolado não mede confiabilidade

Se um agente conclui uma tarefa uma vez, sabemos que conseguiu naquela tentativa e naquelas condições. Para estimar confiabilidade, é necessário definir critérios de sucesso, selecionar tarefas representativas, repetir tentativas quando apropriado e registrar falhas, tempo, custo e necessidade de intervenção.

A METR estuda capacidades de agentes em tarefas técnicas relacionando a probabilidade de sucesso ao tempo necessário para especialistas humanos concluírem essas tarefas. A organização ressalta que sua amostra se concentra em tarefas relativamente bem especificadas de software e áreas próximas. Esses resultados não devem ser interpretados como uma medida direta da automação de qualquer trabalho real.

Também precisamos avaliar a avaliação

Um teste pode conter instruções ambíguas, rejeitar soluções válidas ou aceitar resultados incompletos. Uma auditoria publicada pela OpenAI em julho de 2026 relatou problemas em tarefas do benchmark SWE-bench Pro. É uma análise produzida pela própria organização, mas ilustra uma questão mais ampla: antes de interpretar um número, precisamos examinar as tarefas, os critérios de correção e as limitações da amostra.

Da avaliação de desempenho à avaliação de riscos

Um agente pode alcançar um objetivo e, durante o processo, acessar informações indevidas ou executar ações fora de seu escopo. Por isso, medir capacidade e avaliar riscos são trabalhos relacionados, mas distintos. O AI Risk Management Framework do NIST trata avaliação e gestão de riscos como atividades que dependem do contexto de uso e de documentação das limitações.

Ao estudar agentes, pretendo distinguir três afirmações: “o agente executou uma ação”, “o objetivo foi alcançado” e “o sistema é confiável para esse tipo de tarefa”. A primeira pode ser comprovada por registros; a segunda exige verificar resultados; a terceira requer evidências mais amplas. É essa a abordagem que quero desenvolver aqui: mostrar o que foi demonstrado, o que é hipótese e o que ainda precisamos avaliar.

Por Alexandre Itida · 24 de setembro de 2026

Entender como um modelo produz respostas ajuda a compreender por que fluência e confiabilidade não são a mesma coisa.

É impressionante conversar com um modelo de linguagem capaz de explicar conceitos, escrever programas e ajudar a resolver problemas. Em algumas tarefas, a resposta parece tão bem construída que é fácil esquecer uma pergunta: de onde veio a informação e como saber se está correta?

Tenho interesse em estudar os modelos de linguagem justamente por essa diferença entre a qualidade aparente de uma resposta e a confiabilidade de seu conteúdo.

Como um modelo produz texto

A arquitetura Transformer, apresentada em 2017, tornou-se uma das bases dos modelos de linguagem modernos. Seu mecanismo de atenção permite processar relações entre elementos de uma sequência, oferecendo uma alternativa às arquiteturas recorrentes então comuns.

De forma simplificada, um modelo de linguagem autorregressivo aprende, durante o treinamento, a prever a continuação de uma sequência de tokens — unidades que podem representar palavras, partes de palavras ou outros elementos. Ao responder, ele gera novos tokens a partir do contexto disponível. Isso permite aprender padrões complexos, mas produzir uma continuação plausível não equivale a verificar uma afirmação no mundo real.

O problema não tem uma única causa

Quando um modelo apresenta informação incorreta com aparência de certeza, costuma-se dizer que “alucinou”. O termo reúne situações diferentes: inventar uma referência, misturar fatos, interpretar mal uma fonte ou acrescentar detalhes não sustentados pelo material consultado. Nem todo erro surge pelo mesmo mecanismo e nenhuma técnica isolada elimina todas essas possibilidades.

Há diferença entre conhecimento adquirido durante o treinamento e informações consultadas para responder a uma pergunta específica. A geração aumentada por recuperação (RAG) combina modelos com consulta a fontes externas. Pode melhorar o desempenho em tarefas dependentes de conhecimento, mas não substitui a verificação da relevância das fontes e da resposta final.

Seguir instruções também exige avaliação

O trabalho sobre InstructGPT (NeurIPS 2022) investigou o treinamento com demonstrações e preferências humanas para melhorar o seguimento de instruções. Seus resultados mostram uma abordagem para aproximar o comportamento dos modelos das intenções dos usuários, não uma garantia de que deixem de cometer erros.

Para quem desenvolve aplicações com IA, isso traz uma consequência prática: não devemos confundir produzir uma resposta convincente, seguir uma instrução e fornecer informação correta. Um sistema pode apresentar bons resultados em uma dessas capacidades e ainda exigir melhorias nas outras.

O que muda em um projeto real?

Se eu pedir uma ideia, posso avaliar a utilidade da proposta. Se pedir um dado técnico, preciso conferir a fonte. Se pedir uma alteração em um sistema, preciso verificar o efeito da ação. O nível de verificação deve acompanhar a tarefa e as consequências de um erro.

Não vejo os limites dos modelos como motivo para ignorar suas capacidades. Vejo-os como conhecimento necessário para utilizá-los melhor. Quanto mais compreendermos o que um modelo faz, o que não verifica sozinho e como seus resultados podem falhar, mais precisas serão as decisões sobre onde aplicá-lo.

Por Alexandre Itida · 24 de setembro de 2026

Permissões, supervisão e controle tornam-se questões concretas quando a IA deixa de apenas responder e passa a agir.

Existe uma diferença importante entre pedir a uma IA que explique como executar uma tarefa e permitir que ela execute essa tarefa em nosso nome. No primeiro caso, avaliamos uma resposta. No segundo, precisamos considerar os efeitos de uma ação: sistemas acessados, dados modificados, autorizações e formas de identificar erros.

Essa distinção me interessa porque quero desenvolver projetos nos quais agentes possam realizar trabalho útil. Para isso, preciso entender como oferecer capacidade de ação sem abrir mão dos controles necessários.

Autonomia não é tudo ou nada

Um agente pode pesquisar e apresentar uma proposta; preparar uma alteração para revisão; executar tarefas autorizadas dentro de limites definidos; ou atuar sobre sistemas com consequências difíceis de reverter. Essas situações não exigem o mesmo grau de supervisão.

Uma tarefa de baixo impacto, com resultado facilmente verificável, pode admitir mais execução automática. Operações com informações sensíveis ou mudanças irreversíveis exigem controles proporcionais às suas consequências. A pergunta deixa de ser apenas “o agente consegue fazer?” e passa a incluir “em quais condições devemos permitir que faça?”.

O risco não está apenas na resposta

Ao utilizar ferramentas e consultar conteúdo externo, um agente pode encontrar instruções que não fazem parte do pedido legítimo do usuário. Uma página ou documento pode conter texto criado para desviar o sistema: um caso de injeção de prompt.

A OWASP recomenda separar conteúdo externo das instruções autorizadas, restringir privilégios e exigir aprovação para ações de maior risco. Sua orientação sobre autonomia excessiva reforça a necessidade de permissões mínimas e controles aplicados pelos sistemas que executam as ações, não apenas pelo próprio modelo.

Um exemplo do que estamos construindo

No AI Itida, adotamos uma separação entre preparar uma mudança e liberá-la para o site. Uma proposta visual pode ser revisada antes de sua publicação. A versão autorizada fica em uma branch específica, e um executor configurado para o site realiza a atualização. O agente que ajuda a preparar conteúdo não precisa de acesso administrativo irrestrito ao servidor.

Esse caso ilustra uma decisão de arquitetura em um projeto específico. Não comprova que o sistema está protegido contra todas as falhas possíveis. Uma afirmação mais ampla de segurança exigiria testes adicionais, inclusive diante de erros e tentativas de uso indevido.

Controle também significa observar e corrigir

O AI Risk Management Framework do NIST organiza a gestão de riscos em quatro funções: governar, mapear, medir e gerenciar. O acompanhamento deve considerar o contexto de utilização e continuar ao longo do ciclo de vida do sistema.

Aplicado a agentes, isso sugere perguntas recorrentes: a tarefa foi concluída? Os limites foram respeitados? Houve consequências imprevistas? É possível interromper a operação, investigar o ocorrido e recuperar um estado anterior?

Meu objetivo não é manter pessoas executando manualmente cada etapa automatizável, nem conceder a um agente acesso ilimitado porque concluiu algumas tarefas. Quero explorar um caminho intermediário: automatizar o que podemos delimitar, verificar e controlar; reservar decisões humanas para o que exige julgamento ou autorização; e ampliar a autonomia conforme reunimos evidências.