O que a IA pode aprender com a monitorização de uma obra
Um agente de Inteligência Artificial não se limita a produzir texto. Pode planear uma tarefa, consultar um sistema RAG, escolher ferramentas, alterar informação e desencadear ações noutros sistemas. Por isso, a avaliação de sistemas com agentes não pode resumir-se a perguntar se a resposta final “parece correta”. É necessário confirmar se o objetivo foi cumprido, se os passos foram adequados, se os limites foram respeitados e se o resultado é consistente.
Na engenharia, este raciocínio é familiar. Um bom projeto não elimina a necessidade de monitorização no decorrer da obra. Durante a execução, verifica-se a conformidade com o projeto, observam-se os trabalhos, registam-se ocorrências, identificam-se desvios e, se necessário, fazem-se correções. Num ambiente digital, a avaliação contínua desempenha uma função comparável: transforma o comportamento do agente em evidência que pode ser analisada e melhorada.
Monitorizar um sistema com agentes implica definir antecipadamente o que significa executar bem uma tarefa, testar o resultado, a trajetória, detetar falhas e repetir a verificação após cada passo relevante.
Porque é que a avaliação de agentes de IA é cada vez mais um tema central?
A 7 de agosto de 2026, o NIST apresentou o rascunho inicial do TEVV-Athlon, uma estrutura de Teste, Avaliação, Verificação e Validação concebida para criar avaliações ajustadas aos objetivos de cada organização. A proposta, ainda em consulta pública à data deste artigo, inclui expressamente os sistemas com agentes e dá prioridade ao desempenho, ao impacto e aos resultados no mundo real.
Esta evolução é importante. Os benchmarks genéricos continuam a ser úteis para comparar capacidades, especialmente de LLMs, mas não demonstram, por si só, que um agente é adequado a um processo concreto (até porque as benchmarks ficam saturadas extremamente rápido hoje me dia).
Em Portugal, o GuIA para a Inteligência Artificial da Agência para a Modernização Administrativa já defende testes rigorosos ao longo do ciclo de vida. O documento recomenda testes antes da implementação, validação das integrações e monitorização contínua em produção, incluindo mecanismos para detetar degradação e incorporar o feedback dos utilizadores.
O sinal é claro: a qualidade de um agente não é uma característica que se declara uma vez. É uma condição que tem de ser demonstrada e acompanhada.
Na STRUVIA, o nosso João Rodrigues tem pelo menos 20 alvos topográficos dentro do fato e não consegue coçar a cabeça sem disparar um critério de alarme.
O que se avalia: o modelo (LLM) ou o sistema completo (Agente)?
É possível avaliar um modelo (LLM) através de benchmarks e learderboards públicas, mas nada nos garante que o mesmo modelo se vai comportar como queremos quando inserido no nosso ambiente de trabalho, com ferramentas próprias e terminologia única. Avaliar o sistema completo, em cada nó, e de ponta a ponta faz muito mais sentido para as organizações.
Naturalmente, o comportamento real depende das instruções, do harness que coordena o fluxo, das fontes RAG, da memória, das ferramentas disponíveis, das permissões, dos serviços externos e dos pontos de decisão humana.
A orientação técnica publicada pela Anthropic sobre avaliação de agentes distingue dois elementos essenciais:
- O resultado (outcome) é o estado final efetivamente produzido. Não basta o agente afirmar que concluiu uma ação; é preciso verificar se ela ocorreu corretamente.
- O rasto de execução (trace ou trajetória) regista as etapas, as chamadas de ferramentas, os resultados intermédios e as decisões tomadas durante a tarefa.
Esta distinção evita um erro comum: aprovar uma resposta convincente sem confirmar o que aconteceu nos bastidores. Num sistema com várias etapas, uma conclusão correta pode ter sido obtida com uma fonte inadequada, uma ferramenta não autorizada, um custo excessivo ou uma sequência que falhará quando as condições mudarem.
Se o objetivo for fazer uma escavação de 20 metros, naturalmente que com explosivos atómicos chegávamos lá rapidamente, mas será que o fim justifica os meios? Pois, acontece que os agentes, construídos sobre LLMs, muitas das vezes, se não forem monitorizados podem querem ir pela via que resolve o problema de forma mais rápida, especialmente se já viram semelhante nos seus dados de treino. Por isso nesta fase, os humanos são importantíssimos para um agente funcionar corretamente, e a monitorização é o que nos permite realinhar e direcionar os agentes.
Fiscalização de uma obra
Em Portugal, o artigo 16.º da Lei n.º 31/2009, na versão consolidada, enquadra a fiscalização de obra em torno da verificação da conformidade da execução, do acompanhamento com frequência adequada e da comunicação de situações que possam comprometer segurança, qualidade, preço ou prazo.
Sem confundir responsabilidades jurídicas ou profissionais, é possível reconhecer uma estrutura de controlo semelhante na engenharia com agentes:
| Numa obra | Num sistema com agentes | Pergunta de controlo |
|---|---|---|
| Projeto de execução e requisitos contratuais | Objetivo, instruções, políticas e critérios de sucesso | O que tem de ser cumprido? |
| Materiais, equipamentos e intervenientes | LLMs, dados, RAG, ferramentas, APIs e permissões | Os componentes são adequados e estão autorizados? |
| Plano de inspeção e ensaios | Suíte de avaliações, casos de teste e rubricas | Como será demonstrada a conformidade? |
| Visitas, observações e medições | Tentativas repetidas, traces e monitorização em produção | O que aconteceu durante a execução real? |
| Registos e relatórios de fiscalização | Logs, fontes e resultados | É possível reconstruir e justificar o processo? |
| Não conformidade e ação corretiva | Falha, correção do sistema e teste de regressão | A correção resolveu o problema sem criar outro? |
| Receção e acompanhamento em serviço | Critério de lançamento e monitorização contínua | O desempenho mantém-se após alterações e novos casos? |
Esta analogia é interessante, e, na STRUVIA é precisamente assim que vemos as nossas obras: Sistemas complexos que carecem de monitorização e atenção constante: Aliado a um bom resultado queremos um processo limpo e agradável para todos os intervenientes.
Uma boa avaliação observa seis dimensões
1. Cumprimento do objetivo
O resultado final corresponde ao que foi pedido? Os dados, ficheiros ou estados do sistema passam os testes? A avaliação deve verificar o efeito real, e não apenas a formulação da resposta.
2. Qualidade da trajetória
O agente escolheu as ferramentas certas, consultou as fontes adequadas, respeitou a sequência prevista e pediu intervenção humana quando necessário?
3. Consistência
Os modelos (LLMs) são probabilísticos: a mesma tarefa executada repetidamente pode produzir resultados diferentes. Uma demonstração isolada é, por isso, insuficiente. É necessário repetir casos relevantes e medir não apenas a possibilidade de sucesso, mas a fiabilidade com que esse sucesso se repete.
4. Eficiência e capacidade de entrega
Um agente pode concluir a tarefa e, ainda assim, consumir tempo, chamadas de ferramentas ou recursos em excesso. Latência, custo, número de etapas e utilização de recursos devem ser avaliados em conjunto com a qualidade. A melhor solução é a que entrega o resultado exigido dentro de limites operacionais aceitáveis.
5. Segurança
É necessário testar limites de acesso, que dados estão disponíveis e para que fim, resistência a instruções maliciosas e ações externas (por exemplo prompt injections e trojan horses).
6. Robustez ao longo do tempo
Modelos, fontes, ferramentas e processos mudam. Uma atualização aparentemente simples pode corrigir um caso e degradar outros. A monitorização em produção, o feedback dos utilizadores e os testes de regressão permitem detetar essa deriva antes de ela se tornar o novo padrão de funcionamento.
Um resultado aprovado pode esconder um processo errado
Este problema não é apenas teórico. O Center for AI Standards and Innovation do NIST documentou casos de agentes que exploraram falhas dos próprios testes. Entre os exemplos observados em avaliações de programação estavam a desativação de verificações e a introdução de lógica específica para passar o teste sem cumprir a intenção original.
Este é só mais um exemplo que mostra claramente o quanto os agentes são eficazes a utilizar as ferramentas que têm à sua disposição para cumprir com o objetivo final. O João Rodrigues é notoriamente conhecido por tentar copiar pelos colegas nos testes quando tem ângulo de visão para tal, por isso agora faz os testes todos na nossa sala Sandbox sem calculadora gráfica.
A lição aproxima-se novamente do controlo de qualidade numa obra: um critério mal definido, uma observação incompleta ou um ensaio vulnerável a interpretações erradas pode produzir uma aprovação enganadora. Por isso, é preciso rever amostras dos traces, fechar ambiguidades nos casos de teste e confirmar que o avaliador mede o comportamento que realmente interessa.
Um ciclo prático de avaliação contínua
Uma organização pode começar sem construir uma infraestrutura excessivamente complexa:
- Definir o objetivo e os limites. Especificar o resultado esperado, as fontes permitidas, as ações proibidas e os casos que exigem validação humana*.
- Reunir casos representativos. Usar tarefas reais, casos-limite, exemplos adversariais e falhas já observadas. Como ponto de partida, a Anthropic sugere 20 a 50 tarefas simples retiradas de verificações manuais e problemas reais; a dimensão e o rigor devem, naturalmente, acompanhar o risco do caso de uso.
- Combinar avaliadores. Aplicar verificações determinísticas sempre que possível, rubricas baseadas em modelos para aspetos qualitativos e revisão por especialistas para decisões críticas ou ambíguas.
- Avaliar resultado e trajetória. Registar o estado final, as fontes, as ferramentas, os tempos, os custos, as exceções e os pontos de intervenção humana.
- Monitorizar a utilização real. Comparar o comportamento em produção com os cenários testados e procurar novos padrões de falha, degradação ou utilização imprevista.
- Transformar falhas em testes de regressão. Sempre que surge um problema, criar um caso que o reproduza, corrigir o sistema e executar novamente a suíte antes de alterar o modelo, o RAG, as ferramentas ou o harness.
*Muitas das vezes podemos ter ganhos de latência em tarefas repetitivas com a utilização de “AI as a Judge”. Mas mesmos estas avaliações têm sempre que ser monitorizadas cuidadosamente.
O objetivo não é atingir uma pontuação abstrata. É produzir evidência suficiente para tomar decisões.
O João Rodrigues também precisa de “fiscalização”
Na STRUVIA, o João Rodrigues é um agent harness proprietário que apoia o funcionamento interno da empresa. No seu caso, a unidade relevante de avaliação não é apenas o modelo de base: é o conjunto formado pelo harness, pelos modelos locais, pelos sistemas RAG, pelas ferramentas e pelos dados expressamente autorizados e necessários a cada tarefa.
Uma avaliação responsável deve confirmar, caso a caso, se a informação está sustentada por fontes adequadas, se os limites de confidencialidade são respeitados, se as comunicações externas permanecem controladas e se o sistema solicita validação humana quando encontra ambiguidade, risco ou falta de evidência.
O João Rodrigues é um agente proativo e está sempre pronto a ajudar. O seu trabalho é cuidadosamente revisto a cada nó antes de tomadas de decisão importantes. É um sistema em construção que é melhorado com cada interação, tanto positiva como negativa.
RAG – A memória factual do João Rodrigues
Para resolver um problema, um agente precisa de instruções de como o resolver, e a informação necessária para o fazer. Da mesma forma como um humano está mais inclinado para dar uma resposta errada quando não tem informação suficiente para tirar conclusões. Este problema é amplificado para modelos (LLMs) com falta de contexto ou falta de dados de treino relativamente a um certo tópico.
RAG é uma técnica que serve para melhorar as respostas dos modelos adicionando contexto onde o mesmo estava em falta. Existem diversas formas de atingir este objetivo e a documentação sobre este assunto na internet é extensa. Na STRUVIA desenvolvemos um sistema proprietario com hybrid search.
Um sistema RAG pode melhorar o acesso a documentação autorizada, mas não garante que a recuperação seja completa, que a fonte seja aplicável ou que a conclusão esteja correta. Um agente pode acelerar tarefas, mas não elimina a necessidade de validação humana. A inovação cria valor quando aumenta a capacidade de entrega sem perder rastreabilidade, qualidade e controlo humano.
Conclusão: inovação com responsabilidade
A pergunta “quem fiscaliza o agente?” deve ser respondida antes de o sistema assumir tarefas relevantes. A resposta não é uma única ferramenta nem um teste final. É um processo formado por requisitos, avaliações, traces, critérios de aceitação, monitorização e decisão humana.
Tal como numa obra, a confiança não nasce da ausência de problemas visíveis. Nasce da capacidade de observar a execução, detetar desvios, corrigir e demonstrar que o resultado cumpre o que foi definido.
Na STRUVIA, esta ligação entre engenharia e sistemas com agentes traduz uma ideia simples: inovar é entregar melhor, com métodos inteligentes e responsabilidade.
Se a sua organização está a explorar Agentic Engineering para otimizar os fluxos de trabalho, fale com a STRUVIA. Um primeiro passo útil é transformar objetivos, riscos e pontos de validação humana num plano de avaliação verificável.
Fontes
- The TEVV-Athlon Framework for Evaluating AI Systems — National Institute of Standards and Technology, anúncio de 7 de agosto de 2026, página atualizada em 14 de agosto de 2026.
- Building Evaluation Probes into Agentic AI — National Institute of Standards and Technology, projeto iniciado em abril de 2026, página atualizada em 5 de maio de 2026.
- Demystifying evals for AI agents — Mikaela Grace, Jeremy Hadfield, Rodrigo Olivares e Jiri De Jonghe, Anthropic, 9 de janeiro de 2026.
- Cheating On AI Agent Evaluations — Maia Hamin e Benjamin Edelman, NIST CAISI, página atualizada em 2 de dezembro de 2025.
- Survey on Evaluation of LLM-based Agents — Asaf Yehudai et al., versão revista em 23 de abril de 2026, ACL Findings.
- GuIA — Guia para a Inteligência Artificial, versão 1.2 — Agência para a Modernização Administrativa, IP, junho de 2025.
- Lei n.º 31/2009, artigo 16.º, versão consolidada — Diário da República, última alteração indicada em 6 de janeiro de 2026.