Qualidade de software com IA exige dupla avaliação

Na qualidade de software com inteligência artificial, vale verificar tanto os componentes previsíveis quanto a adequação das respostas e ações ao uso esperado. Neste guia, chamamos essa segunda frente de avaliação de IA. As duas fazem parte da qualidade do software: uma funcionalidade pode compilar e passar nos testes de integração, mas ainda produzir uma resposta inadequada, uma ação incompleta ou uma decisão fora do limite aceito pela organização.

Como combinar testes de software e avaliação de IA

Os testes de componentes, integrações e fluxos continuam cobrindo uma parte decisiva do produto: regras de negócio, integrações, permissões, fluxos previsíveis, persistência de dados, observabilidade e tratamento de erro. Se uma tela não carrega, se uma API retorna dados incorretos, se um usuário sem permissão acessa uma informação restrita ou se um erro não é registrado, o problema não é “comportamento inteligente”. É software falhando.

A avaliação de IA começa quando a pergunta deixa de ser apenas “o sistema executou a regra?” e passa a ser “a resposta, recomendação ou ação produzida é aceitável para este contexto?”. Essa distinção parece simples, mas muda o desenho do processo de qualidade.

Imagine um exemplo fictício: uma empresa usa um assistente interno para resumir solicitações de clientes antes da reunião diária de operação. O fluxo técnico funciona. O usuário autentica, o assistente acessa as mensagens autorizadas, gera o resumo, grava o histórico e registra logs. Os testes de integração passam.

Mesmo assim, o resumo omite uma exceção relevante: um cliente havia condicionado a continuidade de uma entrega a uma resposta naquele dia. O assistente produziu um texto claro, gramaticalmente correto e aparentemente útil. Do ponto de vista técnico, nada quebrou. Do ponto de vista da decisão operacional, a resposta pode ser insuficiente.

As duas frentes se complementam. Os testes de componentes e integração verificam contratos conhecidos; os casos de avaliação examinam a adequação das saídas de IA ao uso esperado.

Em produtos com IA, a confiança não nasce de uma única evidência. Ela depende de camadas. Testes automatizados ajudam a detectar falhas nos comportamentos que cobrem. Avaliações de comportamento, que também podem ser automatizadas, examinam respostas inconsistentes, omissões relevantes e ações incompletas. Responsabilidade define quem aceita, limita ou interrompe a exposição quando a incerteza aparece.

Essa separação também evita um erro comum de gestão: transformar uma suíte de testes verde em autorização ampla de uso. Teste aprovado não é sinônimo de comportamento aprovado. É uma evidência necessária, mas parcial.

Para organizações que estão estruturando uma estratégia de inteligência artificial conectada ao negócio, essa distinção ajuda a tirar a discussão do entusiasmo genérico e levá-la para uma pergunta mais útil: que tipo de evidência precisamos antes de expor esta capacidade a pessoas, clientes ou operações?

Três perguntas para decidir exposição de uma funcionalidade com IA

Antes de discutir ferramentas, vale classificar o risco da funcionalidade. Não como exercício burocrático, mas como forma de decidir quanta avaliação é razoável antes da exposição.

A primeira pergunta é: a IA apenas sugere ou executa algo?

Uma funcionalidade que reescreve um texto para revisão humana tem um perfil de risco diferente de um agente que altera um cadastro, abre um chamado, envia uma mensagem ou aciona um fluxo operacional. Quanto mais perto da execução, maior deve ser a exigência de verificação do resultado no ambiente. Não basta avaliar se a resposta parece boa. É preciso confirmar se o efeito esperado ocorreu, se ocorreu no lugar certo e se não ultrapassou limites definidos.

A segunda pergunta é: o erro é reversível ou gera consequência operacional relevante?

Nem todo erro tem o mesmo peso. Uma sugestão de título ruim pode ser descartada. Uma classificação errada que move uma solicitação para a fila incorreta pode atrasar atendimento, confundir responsáveis ou exigir retrabalho. A avaliação deve refletir essa diferença. Casos raros com alto impacto não podem desaparecer dentro de uma média confortável.

A terceira pergunta é: a validação depende de regra objetiva, julgamento humano ou observação em produção controlada?

Alguns comportamentos podem ser verificados por regra. Um chamado foi criado ou não foi. A categoria está entre as permitidas ou não está. O registro contém os campos mínimos ou não contém. Outros comportamentos exigem julgamento humano, como avaliar se um resumo preserva nuances suficientes para uma decisão. Há ainda situações em que a equipe precisa observar sinais em uma exposição controlada antes de ampliar o uso.

Essas três perguntas criam uma triagem inicial:

• Se a IA apenas informa, a avaliação pode priorizar precisão, completude e clareza.
• Se a IA recomenda, a avaliação precisa incluir critérios de aceitação da recomendação e limites de confiança.
• Se a IA prepara uma ação, a equipe deve verificar se a ação proposta respeita regras, permissões e contexto.
• Se a IA executa uma ação, a avaliação precisa medir o efeito real, prever contenção e definir autoridade para interrupção.

Essa triagem não substitui uma análise mais profunda de maturidade. Ela é um primeiro corte para evitar que funcionalidades muito diferentes sejam tratadas com o mesmo rito de aprovação. Em uma organização que ainda está diagnosticando seu ponto de partida, esse tipo de critério conversa diretamente com uma leitura de maturidade em IA: capacidade não é só ter modelos disponíveis, mas saber onde a incerteza entra no processo.

Testes de código ainda são a primeira barreira de confiança

A chegada da IA não torna testes automatizados obsoletos. Pelo contrário: quando o comportamento inteligente adiciona variabilidade, a parte determinística do sistema precisa ser ainda mais confiável.

Testes de unidade continuam verificando funções isoladas. Testes de integração continuam protegendo a comunicação entre serviços. Testes de contrato de API ajudam a identificar mudanças incompatíveis entre sistemas. Validações de autenticação e permissão continuam impedindo acessos indevidos. Logs e tratamento de erro continuam permitindo investigação quando algo falha.

Nada disso avalia, por si só, se uma resposta da IA foi boa. Mas sem essa base, a equipe fica tentando interpretar comportamento inteligente sobre um terreno instável.

O DORA recomenda testes ao longo do desenvolvimento, combinando automação e atividades manuais, como exploração e usabilidade. Também recomenda manter e revisar as suítes de teste, em vez de tratar qualidade como uma etapa posterior ao desenvolvimento. Esse ponto é especialmente relevante quando uma funcionalidade passa a depender de prompts, modelos, ferramentas externas, bases de conhecimento ou novas rotas de decisão.

Quando a funcionalidade muda, a suíte de testes também precisa ser revisada. Não porque todo teste antigo perdeu valor, mas porque parte do risco mudou de lugar.

Em uma funcionalidade tradicional, talvez bastasse verificar se o formulário validava campos, gravava dados e exibia confirmação. Em uma funcionalidade com IA, além disso, pode ser necessário testar se o sistema envia o contexto correto ao modelo, se remove dados que não deveriam ser enviados, se registra a versão da configuração usada, se lida com indisponibilidade do provedor e se impede ações fora do escopo permitido.

Esses são testes de software, não avaliações semânticas. Eles verificam se o sistema está preparado para operar a capacidade inteligente de forma controlada.

Há uma consequência prática para liderança: não use avaliação de IA para compensar engenharia frágil. Se a autenticação falha, se a integração é instável ou se os logs não permitem rastrear uma decisão, o problema deve ser resolvido como qualidade de software. A avaliação de comportamento entra depois, para responder a outra pergunta.

Também é útil separar produtividade de qualidade. A atualização de fevereiro de 2026 da METR considera seus novos dados um sinal pouco confiável do efeito atual da IA sobre produtividade, apontando seleção de participantes e tarefas e dificuldades de medir tempo com agentes concorrentes. Essa fonte não conclui sobre qualidade de produto. O cuidado aqui é operacional: velocidade de desenvolvimento, quando existir, não deve ser usada como prova de que o comportamento entregue é aceitável.

Avaliações de comportamento precisam medir resultado, não intenção

Avaliar IA não é perguntar se a resposta parece convincente. Também não é aceitar a mensagem final do agente como prova de conclusão. Em funcionalidades inteligentes, a aparência de competência pode esconder uma falha simples: o resultado esperado não aconteceu.

A Anthropic distingue a trajetória de execução do agente do resultado efetivo no ambiente. Uma mensagem dizendo que a tarefa terminou não basta para comprovar o resultado. A avaliação usa entradas, critérios de sucesso e verificadores, e pode exigir várias tentativas.

Essa distinção é muito útil para equipes de produto e qualidade. Uma avaliação de IA precisa de pelo menos três elementos:

• uma entrada ou situação inicial;
• um critério de sucesso;
• um verificador manual ou automatizado.

Voltemos a um exemplo fictício, sem qualquer caso real por trás. Um agente interno recebe a tarefa de abrir um chamado de suporte a partir de uma conversa com um cliente. Ao final, ele responde: “Chamado aberto com sucesso”. Essa frase não é evidência suficiente.

Uma avaliação mais forte verificaria se o chamado realmente existe no sistema, se foi associado ao cliente correto, se recebeu a categoria adequada e se contém dados mínimos para atendimento. Dependendo do risco, também poderia verificar se o agente não incluiu informações indevidas, não duplicou solicitações e não encaminhou o caso para uma fila incompatível.

Repare que a avaliação não precisa ser sofisticada para ser útil. Em muitos casos, um verificador simples é melhor do que uma revisão subjetiva e difusa. A pergunta não é “a IA foi inteligente?”. A pergunta é “o efeito que esperávamos pode ser observado por um critério definido?”.

Quando o comportamento envolve linguagem, o verificador pode combinar critérios objetivos e revisão humana. Por exemplo: o resumo menciona todos os itens obrigatórios? Não inventa compromissos? Preserva exceções sinalizadas? Está claro o suficiente para a próxima pessoa agir? Algumas dessas perguntas podem ser avaliadas automaticamente. Outras podem exigir amostragem humana, especialmente quando o custo de uma omissão é relevante.

O limite também precisa estar claro. Avaliações não eliminam erro de IA. Elas reduzem cegueira operacional. Ajudam a encontrar padrões de falha, comparar mudanças, bloquear exposições frágeis e decidir quando uma revisão humana deve permanecer no fluxo.

Essa é uma diferença importante: julgamento humano não deve aparecer apenas como correção tardia depois que a tecnologia errou. Ele pode ser parte do desenho do sistema. Em algumas funcionalidades, a IA prepara uma sugestão e a pessoa decide. Em outras, a IA executa apenas ações reversíveis. Em outras, a ação autônoma simplesmente não deve ser permitida sem evidência mais robusta.

Para quem está montando um roadmap de IA, esse ponto ajuda a priorizar. O custo de avaliar comportamento deve entrar na decisão de sequência. Uma oportunidade aparentemente simples pode exigir uma operação de avaliação maior do que a equipe consegue sustentar naquele momento.

Responsabilidade define quem pode aceitar ambiguidade

Responsabilidade em IA não é descobrir culpados depois da falha. É desenhar antes quem decide, com base em que evidência, até onde a funcionalidade pode ir e quando ela deve parar.

Toda funcionalidade com comportamento inteligente carrega algum grau de ambiguidade. A pergunta de gestão é: quem tem autoridade para aceitar essa ambiguidade?

Há pelo menos quatro responsabilidades que não deveriam ficar misturadas:

• Critério de qualidade: definir o que conta como resposta aceitável, ação correta, omissão intolerável e exceção relevante. Essa responsabilidade costuma exigir proximidade com produto, operação e usuário, não apenas engenharia.
• Aprovação de exposição: decidir se a evidência disponível autoriza avançar, limitar ou bloquear. Passar nos testes e avaliações não deveria ativar automaticamente a funcionalidade para todos.
• Revisão de exceções: analisar, classificar e decidir se um caso difícil vira novo critério, ajuste de produto, limitação de uso ou aceitação consciente.
• Interrupção: definir quem pode reduzir a exposição, desligar uma configuração ou interromper uma capacidade quando os sinais indicam comportamento inadequado. Se a resposta for “todo mundo acompanha”, provavelmente ninguém decide.

Uma forma prática de organizar essa conversa é separar comportamentos em três grupos.

• Comportamentos aceitos por métrica: podem avançar quando critérios objetivos e sinais acompanhados permanecem dentro do limite definido pela equipe.
• Comportamentos que exigem revisão humana: podem ser usados como apoio, mas a decisão final precisa de uma pessoa em pontos específicos do fluxo.
• Comportamentos que bloqueiam lançamento: não devem ser expostos enquanto a equipe não tiver controle, evidência ou contenção suficiente.

O valor dessa separação não está em criar governança pesada. Está em impedir que decisões de risco sejam tomadas por inércia técnica. Uma funcionalidade não deve avançar apenas porque “já está pronta”. Pronta para deploy não significa pronta para impacto.

Esse raciocínio também evita uma armadilha cultural: tratar responsabilidade como desconfiança da equipe. Na prática, é o contrário. Quando critérios e autoridades estão claros, a equipe consegue experimentar com mais honestidade, porque sabe quais sinais importam e quais limites não podem ser ultrapassados.

Na atuação da liderança, essa é uma extensão natural do tema de liderança e humano ampliado: a tecnologia amplia capacidade quando o processo deixa claro onde a máquina sugere, onde executa e onde a pessoa precisa sustentar a decisão.

Lançar com IA exige separar disponibilização de código e ativação de comportamento

Colocar código em produção não precisa significar liberar uma capacidade inteligente para todos. Essa separação é uma das decisões mais úteis para reduzir risco sem paralisar entrega.

O capítulo de Google SRE sobre lançamentos graduais trata da avaliação de uma mudança em uma parcela do tráfego antes de ampliar a exposição. Também distingue disponibilizar código de ativar funcionalidades e discute o uso de configurações para separar essas decisões.

Aplicado a IA, isso significa que uma equipe pode publicar a infraestrutura técnica, manter a funcionalidade desativada para a maioria dos usuários, ativar para um grupo controlado e observar sinais antes de ampliar. Esses sinais podem incluir falhas técnicas, inconsistências de resposta, necessidade de intervenção humana, abandono do fluxo, correções manuais ou ocorrências de exceções previstas.

Não se trata de prometer que um lançamento gradual encontrará todos os problemas. Ele não encontra. O que ele faz é criar uma forma controlada de observar comportamento real sem transformar a primeira exposição em aposta total.

A separação entre deploy e ativação também muda a conversa com a liderança. Em vez de aprovar “o lançamento da IA”, a organização aprova etapas de exposição:

• código disponível, funcionalidade desativada;
• ativação interna ou para grupo restrito;
• ativação para um recorte controlado de uso;
• ampliação condicionada a sinais definidos;
• interrupção ou redução de exposição quando um limite é ultrapassado.

Essas etapas precisam ser possíveis tecnicamente. Se a única forma de conter o risco é remover código às pressas, a estratégia de lançamento está frágil. Configuração, segmentação de usuários, limites de uso e desligamento controlado não são detalhes operacionais. São parte da qualidade de software com IA.

Também aqui vale separar observação de validação absoluta. Produção controlada ajuda a enxergar comportamento em contexto, mas não substitui testes de software nem avaliações prévias. Ela complementa as camadas anteriores com sinais do ambiente real.

Checklist de separação entre teste, avaliação e responsabilidade

O checklist abaixo é uma proposta prática para orientar a decisão de exposição. Ele não é uma certificação, não elimina julgamento e não transforma comportamento probabilístico em garantia. Sua utilidade é forçar a equipe a separar correção do software, avaliação do comportamento e responsabilidade operacional.

O risco da funcionalidade foi classificado pelo tipo de ação?

Marque se a IA apenas informa, recomenda, prepara uma ação ou executa uma ação. Quanto mais próxima da execução, maior deve ser a exigência de avaliação e controle de exposição.

Se a equipe não consegue dizer o que a IA pode fazer, a funcionalidade não deve avançar para exposição ampla. Antes de avaliar qualidade, é preciso delimitar capacidade.

Os testes de software cobrem o funcionamento previsível do sistema?

Verifique autenticação, permissões, integração, persistência, tratamento de erro, observabilidade e fluxos conhecidos antes de discutir se a resposta da IA é boa.

Se o sistema falha em regras determinísticas, não faz sentido usar avaliação de IA para compensar uma base instável. Corrija a engenharia antes de interpretar o comportamento inteligente.

A avaliação mede resultado verificável, não apenas resposta plausível?

Defina entrada, critério de sucesso e verificador. Em uma tarefa de agente, confirme se o efeito esperado ocorreu no ambiente, não apenas se a mensagem final parece convincente.

Se a única evidência é a própria IA dizendo que terminou, a avaliação é fraca. Uma boa avaliação precisa olhar para o resultado, não para a autodeclaração do sistema.

Há casos que representam uso normal, exceções relevantes e falhas intoleráveis?

Separe casos comuns de casos raros com alto impacto. O objetivo não é cobrir todo o universo possível, mas impedir que a média esconda riscos que a organização não aceita.

Se uma falha rara pode causar dano operacional significativo, ela precisa de tratamento próprio. Não deve ficar enterrada em uma nota agregada que parece aceitável.

Existe um responsável por aceitar, limitar ou interromper a exposição?

Defina quem aprova a mudança de etapa, quem acompanha sinais de qualidade e quem tem autoridade para reduzir ou desligar a funcionalidade.

Se todos acompanham, mas ninguém decide, a responsabilidade está mal desenhada. A ambiguidade da IA precisa de dono no processo, não apenas de boas intenções.

A ativação pode ser controlada sem novo deploy?

Verifique se a equipe consegue disponibilizar código e ativar a funcionalidade de forma separada, por configuração, grupo de usuários ou fatia controlada de tráfego.

Se a única forma de conter o risco é remover código às pressas, a estratégia de lançamento está frágil. Controle de exposição é parte da qualidade, não um acessório de operação.

A decisão de qualidade muda quando o software passa a se comportar

A pergunta central não é se a organização deve confiar ou desconfiar da IA. A pergunta é que evidência ela exige para cada tipo de comportamento.

Um sistema pode estar tecnicamente correto e ainda entregar uma resposta inadequada. Um agente pode declarar sucesso e não ter produzido o efeito esperado. Uma funcionalidade pode estar pronta para deploy e ainda não estar pronta para exposição ampla. Essas distinções parecem pequenas, mas evitam uma falsa sensação de segurança.

Para governar essa exposição, o processo de qualidade precisa operar em três camadas: testes para correção do software, avaliações para comportamento inteligente e responsabilidade para autorizar, limitar ou interromper a exposição. Quando essas camadas têm critérios e responsáveis próprios, a organização deixa de aprovar IA pela aparência de funcionamento e passa a decidir pelo nível de evidência que o risco exige.

A próxima decisão não é escolher mais uma ferramenta de teste. É definir, para cada capacidade com IA, qual evidência autoriza exposição, qual sinal exige revisão humana e qual limite interrompe o uso.

Para levar essa separação à sua agenda de produto, engenharia ou liderança, converse com a dooop.

Leituras para continuar

• IA no desenvolvimento de software: processo, produto e aprendizagem

Fontes

• DORA: automação de testes
• Anthropic: avaliações de agentes
• Google SRE: lançamentos graduais
• METR: limites da medição de produtividade