Como testar uma funcionalidade de IA antes de a equipa depender dela?

Um protótipo responde bem a algumas perguntas. Agora alguém quer disponibilizá-lo à equipa. Antes de concordar, peça ao fornecedor que mostre como lida com o trabalho que essas pessoas lhe vão realmente pedir, incluindo as perguntas a que não consegue responder.

Pode tornar a conversa bastante concreta. Escolha uma tarefa, defina o que é um resultado útil e analisem os resultados de um conjunto de exemplos realistas com alguém que conheça o trabalho. Assim, terá uma base para decidir se está pronto a ser lançado.

Comece por uma tarefa e pelos seus limites

Imagine uma funcionalidade que prepara respostas preliminares com base em orientações internas aprovadas. Um membro da equipa lê cada rascunho antes de o utilizar. É um exemplo hipotético, mas ajuda a perceber melhor o que significa aceitar o resultado.

Registe que fontes a funcionalidade pode utilizar, para quem se destina e o que produz. Neste exemplo, redige uma resposta com base nas orientações a que essa pessoa tem autorização para aceder. Enviar a resposta ou alterar um registo seriam capacidades diferentes que teriam de ser testadas.

Depois, defina o que conta como útil. O rascunho deve responder à pergunta, corresponder ao material aprovado, preservar as condições importantes e indicar a fonte que o sustenta. Se o material não permitir responder, deve dizê-lo. Admitir claramente que falta informação pode ser um bom resultado.

Uma regra inventada, a omissão de uma condição que altera a resposta ou uma resposta confiante baseada nas orientações erradas tornariam o rascunho inútil. Defina estas diferenças antes de analisar os resultados. Caso contrário, uma resposta fluente pode ser surpreendentemente convincente.

Experimente as perguntas que as pessoas vão realmente fazer

Para o exemplo das respostas preliminares, inclua pelo menos estes tipos de situação:

• Uma pergunta habitual. As orientações contêm uma resposta clara. O rascunho usa-a corretamente e indica a fonte certa?
• Uma pergunta ambígua. Podem aplicar-se dois procedimentos. A funcionalidade pede o detalhe necessário para escolher, em vez de escolher silenciosamente um deles?
• Falta de informação. As orientações aprovadas não abrangem o pedido. A funcionalidade explica o que falta e deixa a resposta para uma pessoa resolver?

Estes exemplos são um ponto de partida. Construa o conjunto de testes com base na mistura real de trabalho: pedidos frequentes, informação incompleta, formulações difíceis e erros com consequências importantes. Utilize dados representativos autorizados ou exemplos preparados em segurança, e mantenha registos confidenciais fora de serviços não aprovados.

As orientações de avaliação da Microsoft recomendam interações representativas e casos difíceis. Para quem gere a equipa, a pergunta útil é se os exemplos abrangem as situações em que as pessoas precisam de ajuda. Um teste geral a modelos não responde a essa pergunta para a sua aplicação.

Peça a alguém que conheça o trabalho para avaliar os resultados

Peça a alguém familiarizado com a tarefa que reveja as respostas segundo os critérios acordados. Essa pessoa deve conseguir explicar por que razão uma resposta é útil, está errada ou é incerta. Uma segunda análise ajuda quando há desacordo ou quando um erro pode ter consequências importantes.

O Quadro de Gestão de Risco de IA do NIST, de aplicação voluntária, apoia testes documentados, condições semelhantes às da utilização real e a participação de especialistas relevantes. É uma referência útil para perguntar o que foi testado e quem verificou os resultados. Não define uma nota mínima universal para a sua funcionalidade.

Mantenha alguns exemplos de avaliação separados dos exemplos usados para melhorar a funcionalidade. Se o fornecedor continuar a ajustá-la com base em todas as perguntas de teste, ficará a saber como lida com essas perguntas conhecidas. Exemplos separados permitem verificar melhor como responde a tarefas para as quais não foi ajustada.

A pontuação automática pode ajudar a organizar os resultados, mas também é preciso verificar as avaliações. As pessoas podem não detetar erros, e uma IA usada para avaliar outra IA também pode estar errada. Peça para ver respostas concretas e os motivos das pontuações.

Analise as falhas que a média esconde

Uma pontuação global pode ajudar a comparar versões. Além dela, peça resultados agrupados pelas situações e pelos erros relevantes. As perguntas habituais podem correr bem, enquanto as perguntas sem fonte levam repetidamente a respostas inventadas. A média esconde uma decisão que tem de tomar sobre aquele uso específico.

Registe as falhas ocorridas, a gravidade e o que continua incerto. Decida quais impedem a utilização prevista. O erro aceitável depende da tarefa e do que acontece depois de uma falha; não existe uma percentagem que resolva esta questão para todas as empresas.

Se a funcionalidade também executar ações, verifique o que aconteceu realmente no sistema ligado. Por exemplo, se disser que atualizou um registo, confirme se o registo correto ficou com o valor pretendido. O artigo da Anthropic de janeiro de 2026 sobre avaliação de agentes de IA explica por que razão o resultado final importa quando o software executa ações. Uma mensagem a dizer que a tarefa está concluída não prova que tenha sido bem-sucedida.

A qualidade das respostas é uma parte da aceitação. A segurança, as permissões, a privacidade e o resto do fluxo de trabalho precisam das suas próprias verificações adequadas. Uma boa pontuação nas respostas não prova que esses aspetos funcionem.

Torne a decisão de lançamento específica

Peça ao fornecedor um registo breve da tarefa e dos seus limites, dos casos de teste e dos resultados esperados, de quem os analisou, das falhas importantes, das incertezas restantes e da versão testada. Inclua o modelo, as instruções, o material de origem e o software ligado quando afetarem o resultado. Acorde quais as verificações a repetir se algum destes elementos mudar.

Essa evidência deve apoiar uma de três decisões:

• Aprovar um uso limitado. Os resultados sustentam uma tarefa definida dentro de limites claros. A equipa sabe quando rever, parar ou regressar ao processo atual.
• Corrigir e voltar a testar. É preciso corrigir falhas específicas. Acorde quais os casos a repetir e que exemplos separados verificarão se a correção resulta.
• Adiar o lançamento. Continuam por resolver falhas importantes ou as evidências são insuficientes para sustentar o uso proposto.

Um projeto-piloto limitado pode acrescentar evidência obtida no trabalho real. Defina antecipadamente quem participa, as tarefas, as permissões, o processo de revisão e a alternativa a seguir. Designe alguém responsável por acompanhar os problemas e interromper o projeto-piloto, se necessário. Bons resultados num projeto pequeno sustentam esse uso limitado, mas não provam fiabilidade geral.

No fim da conversa sobre a aceitação, deve saber em que é que a equipa pode confiar, quando uma pessoa ainda tem de decidir e o que obrigaria a repetir os testes. Se está a planear uma funcionalidade de IA para uma aplicação empresarial à medida, podemos conversar sobre a tarefa pretendida e sobre a evidência necessária antes de a aceitar.