Em avaliações de inteligência artificial, revisar respostas é só uma parte do trabalho. A equipe precisa separar três responsabilidades que costumam se misturar: quem define o critério, quem executa a avaliação e quem decide o que será feito com o resultado. Quando esses papéis ficam ambíguos, a equipe pode até testar bastante, mas não consegue explicar se uma falha veio da régua, da execução ou da decisão de liberar.
Quando a avaliação de IA precisa de responsáveis separados
A separação fica necessária quando a IA entra em uma etapa sensível do produto ou da operação. Não precisa ser uma decisão de alto risco regulatório para merecer cuidado. Basta que uma resposta errada gere retrabalho, confunda uma pessoa usuária, esconda um incidente ou empurre a equipe para uma decisão ruim.
Imagine uma liderança pedindo para usar IA na classificação de demandas de suporte. Uma pessoa cria exemplos de teste, outra revisa algumas respostas, alguém do produto aprova o uso limitado e, semanas depois, surge uma falha. A pergunta vem rápido: o critério estava errado, a avaliação foi mal executada ou a liberação foi precipitada?
Se ninguém sabe responder, falta desenho de decisão antes do teste.
A apresentação do DORA 2025 descreve a IA como amplificadora das forças e fraquezas existentes na organização e destaca a importância do sistema organizacional para o retorno do investimento. Essa observação não decide como sua empresa deve nomear responsáveis, mas sustenta a cautela de avaliar IA dentro do sistema de decisão, documentação e aprendizagem da equipe.
Por isso, a pergunta “quem avalia?” é incompleta. A pergunta melhor é: quem define a qualidade esperada, quem produz evidência e quem assume a consequência da decisão?
Três papéis que não devem ser tratados como um só
Em avaliações de IA, há pelo menos três papéis que precisam aparecer de forma explícita. Eles podem ser ocupados por pessoas diferentes ou acumulados em equipes pequenas, mas não deveriam desaparecer dentro de uma responsabilidade genérica chamada “revisão”.
O dono do critério traduz objetivo, risco e padrão mínimo aceitável. Essa pessoa define o que conta como bom, aceitável e inaceitável antes da execução. Também explicita quais erros são toleráveis, quais exigem revisão humana e quais impedem o uso naquele contexto.
O executor da avaliação aplica o protocolo. Ele reúne casos, roda testes, registra evidências, anota divergências e aponta incertezas. Sua função não é “sentir” se a IA está boa. É produzir uma base confiável para que outra pessoa, ou o grupo responsável, consiga decidir.
O decisor define o que acontece depois. Pode liberar, limitar escopo, pedir nova rodada, alterar o critério, voltar ao desenho da solução ou interromper o uso. Esse papel responde pela consequência operacional, técnica ou de produto da decisão.
A confusão nasce quando a mesma pessoa inventa a régua durante o teste, escolhe quais evidências quer considerar e ainda libera o uso porque “parece suficiente”. Em uma equipe pequena, acumular funções pode ser inevitável. O problema não é acumular. O problema é esconder o conflito.
A pergunta prática é simples: se algo der errado, a equipe conseguirá dizer qual papel falhou ou qual decisão precisa ser revista?
Como escolher quem define o critério de avaliação de IA
O dono do critério de avaliação de IA não precisa ser a pessoa mais sênior da sala. Precisa ser quem entende o impacto da decisão que a IA vai influenciar.
Esse papel deve ficar próximo do usuário afetado, do objetivo do produto e do risco operacional. Em uma classificação de chamados, por exemplo, a pessoa que define o critério precisa saber quando uma categoria errada apenas gera atraso e quando esconde um problema que deveria receber atenção imediata.
Bons critérios para escolher o dono da régua são:
- proximidade com o impacto de negócio ou de produto;
- conhecimento suficiente do usuário, cliente interno ou operação afetada;
- capacidade de distinguir erro tolerável de erro crítico;
- autoridade para ajustar o padrão quando surgirem casos não previstos;
- disposição para explicitar trade offs, e não apenas pedir “mais precisão”.
Esse último ponto muda a conversa. Pedir “a IA precisa acertar” não é critério. Dizer “respostas ambíguas devem ir para revisão humana” já começa a ser critério. Dizer “esta categoria não pode ser atribuída automaticamente sem evidência no texto do chamado” é ainda melhor.
A avaliação também precisa estar conectada ao tipo de decisão assistida por IA. Se a IA apenas sugere uma etiqueta interna, a régua pode ser diferente de uma IA que aciona uma comunicação para o cliente. O mesmo modelo, a mesma interface e a mesma taxa percebida de acerto podem exigir critérios diferentes conforme a consequência.
Esse ponto conversa com uma decisão anterior de maturidade. Antes de espalhar iniciativas, vale diagnosticar se a organização consegue sustentar critérios, papéis e registros mínimos. O artigo sobre maturidade em IA ajuda a olhar esse ponto de partida sem reduzir maturidade a ferramenta ou modelo próprio.
Como escolher quem executa a avaliação
O executor da avaliação deve ser escolhido pela disciplina de produzir evidência, não pela vontade de aprovar ou reprovar a ideia.
Executar uma avaliação de IA envolve seguir um protocolo combinado, registrar casos, preservar exemplos difíceis, reproduzir resultados quando possível e separar observação de interpretação. É um trabalho mais próximo de investigação organizada do que de opinião especializada.
A pessoa ou grupo executor precisa conseguir responder:
- quais casos foram avaliados;
- quais critérios foram aplicados;
- quais respostas ficaram corretas, incorretas ou ambíguas segundo a régua definida;
- quais incertezas apareceram durante a execução;
- quais situações não estavam cobertas pelo critério inicial.
Essa função não deve alterar a régua no meio do teste para salvar ou condenar a solução. Se o critério parecer inadequado, o executor registra a limitação e recomenda nova definição. Mudar o padrão depois de ver o resultado enfraquece a avaliação.
Aqui, documentação deixa de ser burocracia. O DORA trata qualidade da documentação por atributos como clareza, facilidade de localização e confiabilidade, além de recomendar criação e manutenção ativa da documentação em sua página sobre qualidade da documentação. Para avaliações de IA, a aplicação prática é manter registros que uma pessoa fora da rodada consiga encontrar, entender e questionar.
Um bom registro não precisa ser sofisticado. Precisa permitir que a equipe reconstrua a decisão. Qual era o objetivo? Qual era o risco? Quem definiu o critério? O que foi testado? O que ficou incerto? O que foi decidido?
Sem isso, a avaliação vira memória oral. E memória oral é frágil quando a equipe muda, quando o modelo muda ou quando a pressão por entrega aumenta.
Como escolher quem decide depois da avaliação
O decisor não é necessariamente quem entende mais de IA. É quem responde pela consequência da mudança.
Se a avaliação trata de uma funcionalidade de produto, a decisão pode estar com produto e engenharia. Se afeta operação, alguém responsável pela operação precisa estar envolvido. Se muda o risco técnico, a liderança técnica deve ter poder real de restrição. O desenho exato varia, mas a autoridade para decidir precisa aparecer antes do teste.
O decisor deve ter autorização para escolher entre alternativas, não apenas para carimbar uma recomendação. Depois de uma avaliação, o decisor precisa poder escolher entre:
- liberar o uso no escopo avaliado;
- limitar o uso a casos de menor risco;
- exigir revisão humana em situações ambíguas;
- pedir nova rodada de avaliação;
- alterar o critério e repetir a execução;
- voltar para o desenho da solução;
- interromper o uso naquele contexto.
Essa lista importa porque muitas avaliações nascem com uma decisão implícita: provar que a iniciativa pode ir adiante. Quando isso acontece, o executor tende a procurar evidências favoráveis e o decisor tende a tratar limitações como pendências menores.
Uma avaliação séria precisa aceitar a possibilidade de não liberar.
Isso não significa paralisar a adoção. Significa proteger a capacidade de aprender com o teste. A página do DORA sobre cultura de aprendizagem relaciona cultura de aprendizagem ao desempenho de entrega de software e propõe tratar aprendizagem como investimento da organização. Em avaliações de IA, aprender exige registrar não só o que funcionou, mas também por que a equipe decidiu restringir, repetir ou interromper.
Há uma diferença relevante entre avaliação e experimento. Uma avaliação verifica se a solução atende a critérios definidos para um uso. Um experimento precisa de hipótese testável, medida de impacto e iteração. A Microsoft descreve a ExP como uma plataforma para incorporar experimentação ao ciclo de desenvolvimento, validar hipóteses, medir impacto e iterar produtos. Isso não transforma toda avaliação interna em experimento de produto, nem significa que qualquer feedback retreine automaticamente um modelo.
Exemplo fictício: avaliando IA em triagem de chamados
Considere um exemplo fictício. Uma empresa de software quer usar IA para classificar chamados de suporte antes que eles cheguem à equipe. O objetivo é sugerir uma categoria inicial, não responder ao cliente automaticamente.
A liderança define que a primeira avaliação não decidirá uma implantação ampla. Ela decidirá apenas se a IA pode ser usada como sugestão interna em categorias de baixo risco. Esse recorte evita uma avaliação genérica demais.
O dono do critério fica com uma pessoa de produto junto de uma liderança de suporte. Elas definem as classes de chamados, descrevem exemplos aceitos e separam erros críticos de erros toleráveis. Um erro tolerável pode ser uma classificação que muda a fila, mas continua visível para triagem humana. Um erro crítico pode ser classificar um possível incidente de produção como dúvida comum.
O executor da avaliação fica com uma pessoa de qualidade ou engenharia que não decide a liberação. Ela aplica o protocolo sobre uma amostra definida pela equipe, registra divergências, marca casos ambíguos e não altera a régua durante a execução. Quando encontra chamados que não se encaixam bem nas classes existentes, registra a lacuna em vez de criar uma categoria nova no meio do teste.
O decisor fica com quem responde pelo fluxo de suporte e pela mudança no produto interno. Depois de analisar os registros, essa pessoa não libera a IA para todos os tipos de chamado. A decisão hipotética é restringir o uso a categorias de baixo risco, exigir revisão manual para qualquer sinal de incidente de produção e pedir nova rodada quando as classes forem revisadas.
Nenhum efeito desse exemplo deve ser tratado como resultado ocorrido. A hipótese a medir seria se a sugestão reduz ambiguidade na triagem sem aumentar erros críticos. Para isso, a equipe ainda precisaria definir evidências, acompanhar uso real e revisar a decisão em data combinada.
O valor do exemplo está na separação. Uma pessoa definiu a régua, outra produziu evidência, outra decidiu a consequência. Se algo falhar, a equipe tem como revisar o ponto certo.
Checklist para escolher responsáveis por avaliações de IA
Antes do primeiro teste, preencha um checklist curto. Ele evita que a avaliação comece como conversa informal e termine como decisão sem dono.
- Qual decisão será tomada com esta avaliação? Se o teste não muda uma decisão de liberação, restrição, redesenho ou interrupção, ele ainda não tem finalidade suficiente.
- Quem define o que conta como bom, aceitável e inaceitável? Escolha alguém com proximidade ao impacto do produto, conhecimento do usuário afetado e autoridade para ajustar o padrão quando surgirem casos não previstos.
- Quem executa a avaliação sem alterar o critério durante o teste? Escolha alguém capaz de seguir protocolo, registrar evidências, reproduzir casos e apontar incertezas sem transformar preferência pessoal em regra.
- Quem decide o que acontece depois do resultado? Escolha a pessoa que responde pela consequência operacional, técnica ou de produto da liberação. Senioridade ajuda, mas não substitui vínculo real com a consequência.
- Quais evidências serão aceitas? Defina exemplos, amostras, registros, revisões humanas ou medidas antes da execução. Não mude a régua depois de ver o resultado.
- Qual é a regra de parada? Defina quando a avaliação deve ser interrompida, refeita ou escalada. Erros críticos, baixa confiabilidade de registro ou ambiguidade de critério devem acionar revisão.
- Onde a decisão ficará documentada? Registre critério, execução, resultado, decisão e justificativa em local fácil de encontrar e manter. Sem documentação confiável, a avaliação vira memória oral.
Esse checklist não substitui estratégia, governança de IA ou desenho de produto. Ele cobre uma camada mais básica: impedir que uma avaliação seja tratada como opinião coletiva sem consequência clara.
Se a empresa ainda está organizando prioridades, vale conectar essa decisão ao roadmap de IA e à estratégia de inteligência artificial conectada ao negócio. Responsabilidade por avaliação não deve viver isolada do plano de adoção.
O próximo passo é montar uma matriz simples antes de avaliar qualquer uso relevante de IA: dono do critério, executor da avaliação e decisor da consequência. Se esses três campos não puderem ser preenchidos, a equipe ainda não está pronta para confiar no resultado do teste.
Se quiser discutir essa decisão no contexto da sua empresa, converse com a dooop.
Leituras para continuar
- Como preparar uma empresa de software para trabalhar com IA
- Como estabelecer acordos de uso de IA na equipe
- Como organizar a adoção de IA sem paralisar as entregas
Fontes
- DORA 2025
- DORA: cultura de aprendizagem
- DORA: qualidade da documentação
- Microsoft: Experimentation Platform ExP
Conversar sobre a aplicação na empresa
Conversa sobre o contexto da empresa de software
Conteúdo de dooop. O cadastro permite relacionar esta pauta à jornada do leitor e acompanhar o interesse pelo tema.