A ficha de aprovação para projetos de IA

1. Comece pela tarefa, não pelo modelo

A primeira pergunta da ficha deve ser: qual decisão ou atividade a IA executará? Escreva a tarefa como uma operação observável, com entrada, saída esperada e limite de atuação. “Ajudar o atendimento” é amplo demais. “Classificar mensagens em segunda via de fatura, cancelamento, dúvida técnica ou outro” permite verificar o resultado. “Rascunhar uma resposta com base em artigos aprovados” também é mais testável do que “responder clientes”.

Não misture tarefas diferentes na mesma aprovação. Classificação, extração de campos, geração de texto e execução de ações têm falhas distintas. Se o fluxo combina várias etapas, avalie cada uma separadamente e depois teste o encadeamento completo. Essa separação ajuda a descobrir se o problema está na interpretação da solicitação, na recuperação de dados, na escolha de uma ferramenta ou na resposta final.

• Defina quem fornece a entrada e em qual formato.
• Declare o que conta como saída correta, incompleta ou proibida.
• Registre o que a IA pode sugerir e o que ela não pode executar.
• Escolha um responsável pela decisão de liberar, pausar ou retirar o fluxo.

Fontes e referências: [1][2]

2. Monte uma amostra que represente o trabalho real

A amostra deve conter casos comuns, casos difíceis e entradas que costumam confundir pessoas ou sistemas. Use exemplos históricos permitidos, dados produzidos especificamente para teste e situações construídas por especialistas. Não basta selecionar apenas os exemplos mais fáceis ou os casos que confirmam a ideia inicial. A distribuição da amostra precisa se aproximar do uso esperado, sem esconder exceções importantes.

Separe uma parte da amostra para a decisão final. Se todos os casos forem usados para ajustar instruções, regras ou ferramentas, a ficha perde força como teste independente. Como ilustração hipotética, uma equipe poderia reservar 120 solicitações para a avaliação final, distribuídas entre situações frequentes, ambíguas e adversariais. Esse número é apenas um exemplo de planejamento, não um padrão de qualidade.

• Inclua variações de idioma, ortografia, formato e extensão quando forem plausíveis.
• Adicione pedidos com múltiplas intenções e contexto incompleto.
• Teste dados ausentes, contraditórios e campos com nomes ambíguos.
• Identifique quais exemplos contêm informação sensível e controle seu acesso.

Fontes e referências: [1]

3. Registre os erros críticos antes de calcular médias

Uma média pode esconder uma falha que torna o projeto inviável. Por isso, a ficha deve separar erros de gravidade diferente. Um texto ligeiramente mais longo talvez seja aceitável em um rascunho. Já inventar uma condição de contrato, enviar informação privada ou chamar uma ferramenta com o identificador errado pode exigir bloqueio imediato.

Descreva cada erro em termos observáveis. Em vez de “resposta ruim”, registre “atribui ao cliente um prazo que não aparece na fonte” ou “classifica cancelamento como dúvida geral”. Para cada categoria, indique consequência, frequência tolerável e reação esperada. A tolerância pode ser zero para algumas classes, especialmente quando a saída dispara uma ação externa ou expõe dados.

• Diferencie erro de conteúdo, erro de formato, erro de roteamento e erro de ação.
• Marque falhas que exigem bloqueio, correção automática, encaminhamento ou apenas registro.
• Teste tentativas de alterar as instruções por meio do conteúdo recebido.
• Para agentes, verifique ferramenta escolhida, argumentos enviados e limites de execução.

Fontes e referências: [3]

4. Compare com uma referência sem IA e use avaliação humana

A pergunta correta não é apenas se a IA funciona. É se ela melhora, acelera ou simplifica o processo em comparação com uma alternativa concreta. A referência pode ser uma regra existente, um classificador tradicional, uma busca estruturada ou o procedimento manual atual. Documente o custo operacional, o tempo, a taxa de encaminhamento e os tipos de erro dessa alternativa, sem presumir que ela seja perfeita.

A avaliação humana deve usar uma rubrica curta, exemplos de níveis de qualidade e critérios de aprovação. Para tarefas subjetivas, peça que avaliadores classifiquem ou comparem respostas sem depender de uma impressão geral. Um avaliador automático pode ajudar a ampliar o teste, mas sua concordância com julgamentos humanos precisa ser verificada no contexto específico. Notas isoladas não substituem a análise dos casos reprovados.

• Defina os critérios antes de olhar os resultados da nova implementação.
• Use comparação lado a lado quando a pergunta for qual saída atende melhor ao objetivo.
• Registre discordâncias entre avaliadores e refine a rubrica quando necessário.
• Exija aprovação explícita para cada erro crítico, mesmo que a média geral seja boa.

Fontes e referências: [1]

5. Faça uma decisão de liberação com condições claras

A ficha precisa terminar com uma decisão que alguém consiga auditar: aprovar, aprovar com escopo limitado, voltar para desenvolvimento ou rejeitar. “Aprovado” não deve significar que a IA é confiável em qualquer situação. Pode significar que ela será usada apenas para rascunhos, com dados restritos, sem execução automática e com um mecanismo de interrupção.

Uma boa regra de decisão combina um resultado agregado com barreiras por categoria. Como exemplo hipotético, uma equipe pode exigir pelo menos 90 por cento de classificações corretas, nenhum caso de vazamento no conjunto de teste e encaminhamento obrigatório para entradas ambíguas. Esses limites são ilustrativos. Cada organização deve defini-los com base no impacto da tarefa, no custo do erro e na capacidade de recuperação.

A complexidade da arquitetura também deve ser justificada pela ficha. Se uma chamada simples ou um fluxo fixo resolve o problema, não adicione um agente autônomo apenas para aumentar flexibilidade. Sistemas com mais etapas, ferramentas ou repasses oferecem mais pontos para avaliar e mais caminhos para falhar. A recomendação é aumentar a complexidade somente quando o teste mostrar benefício mensurável para a tarefa.

• Delimite usuários, dados, ferramentas e horários do primeiro lançamento.
• Especifique condições que suspendem o fluxo automaticamente.
• Registre a versão das instruções, dos dados de referência e dos componentes usados.
• Defina quem pode alterar o sistema e quando uma nova avaliação é obrigatória.

Fontes e referências: [2][3]

6. Monitore o comportamento depois da operação

A aprovação é uma fotografia; o monitoramento acompanha o filme. Registre entradas relevantes, saídas, decisões de roteamento, chamadas de ferramentas, recusas, encaminhamentos e sinais de erro, respeitando as regras internas de acesso e retenção. Sem esses registros, será difícil distinguir uma mudança no modelo de uma mudança no perfil dos usuários, nos documentos disponíveis ou no sistema conectado.

Acompanhe métricas ligadas à tarefa, não apenas latência ou volume. Observe a proporção de casos encaminhados, a frequência de correções, os erros críticos, a distribuição das categorias e as reclamações relacionadas à saída. Crie uma fila de casos novos para ampliar a amostra de avaliação. Toda alteração relevante em instruções, ferramentas, fontes ou modelo deve passar novamente pelos testes que protegem contra regressões.

Para um fluxo que usa ferramentas, monitore argumentos inválidos, chamadas inesperadas e tentativas de agir fora do escopo. Conteúdo externo ou enviado por usuários não deve controlar diretamente uma instrução privilegiada. Campos estruturados, validações e confirmações para operações sensíveis reduzem caminhos de propagação de comandos indevidos, embora não eliminem a necessidade de testes contínuos.

• Defina limiares que acionam investigação e suspensão.
• Revise periodicamente uma amostra de casos reais e casos de borda.
• Compare a versão atual com a última versão aprovada.
• Mantenha um caminho simples para retornar ao procedimento sem IA.

Fontes e referências: [1][3]