Em artigo publicado na CIO em 7 de outubro de 2026, Dzianis Saroka, QA tech Lead na Gurtam, descreve a experiência da empresa usando IA para gerar testes de software. O ponto central: a IA tornou quase instantâneo gerar caso de teste, massa de dados e script de regressão. O gargalo que sobrou não é gerar, é decidir o que desse volume realmente importa.
A Gurtam construiu um assistente interno que lê a documentação de uma tarefa no sistema de rastreamento da empresa, cruza com o ticket e gera os casos de teste automaticamente. Existe uma interface pra revisar, editar e descartar o que não serve antes de enviar o conjunto final pro banco de testes. Saroka chegou a cogitar remover essa etapa de revisão humana e concluiu que a experiência da equipe ainda não dá confiança suficiente pra isso.
O artigo descreve dois extremos que a Gurtam observa na prática:
Isso expõe um problema antigo, não um novo. O modelo só trabalha com o contexto que recebe. Se o conhecimento crítico mora na cabeça de alguém, em incidente passado ou em decisão de arquitetura nunca documentada, a IA não inventa esse conhecimento sozinha.
A qualidade do release não é simplesmente a soma dos casos de teste que passaram. (original, en) Release quality is not simply the sum of passed test cases. (autor) Dzianis Saroka, QA tech Lead na Gurtam
Para quem responde por receita, o argumento de Saroka não é sobre QA de software: é sobre o que acontece em qualquer função onde a IA derruba o custo de produzir um artefato sem resolver o custo de julgar se esse artefato presta. RevOps já vive essa dinâmica. Ferramentas de IA hoje geram em minutos lista de lead qualificado por score, rascunho de proposta, plano de conta e linha de forecast por oportunidade.
A tabela abaixo mapeia o paralelo entre o que a Gurtam descreve em QA e o que acontece numa operação de receita madura:
| Camada | Em QA, segundo a Gurtam | Equivalente em revenue ops |
|---|---|---|
| Produção | IA gera dezenas de casos de teste a partir da documentação | IA gera lista de leads, proposta ou linha de forecast a partir do CRM |
| Revisão | QA engineer edita e descarta caso antes de enviar ao banco de testes | RevOps ou gerente de vendas valida o que entra no pipeline oficial |
| Decisão final | Pessoa decide se o release está pronto pra ir ao ar | CRO decide o commit de forecast que vai pro conselho |
A pergunta que a Gurtam faz sobre cada teste (esse caso importa? o que falta?) é a mesma que uma liderança de receita precisa fazer sobre cada lead, cada linha de forecast e cada proposta gerada por IA antes de assinar embaixo.
Assim como release pronto não é soma de teste aprovado, forecast confiável não é soma de oportunidade com score alto de IA. Entender o que mudou na conta, que dependência existe (aprovação orçamentária, concorrente ativo no ciclo, champion que trocou de emprego) e o que a IA não cobriu continua sendo trabalho humano. CRO que terceiriza o commit inteiro pro modelo de scoring corre o mesmo risco que Saroka descreve pra release: confiança alta, cobertura baixa.
Em resumo: a camada de revisão não é etapa cosmética nem perda de eficiência. É onde a decisão realmente acontece, tanto em QA quanto em forecast de receita.
Se a produção de software, incluindo teste, fica mais barata com IA, compradores corporativos (CIO, procurement) vão usar esse argumento pra pressionar preço: a IA já fez metade do trabalho, por que pagar o mesmo valor de antes? Quem vende tecnologia B2B, seja SaaS, serviço ou consultoria, vai ouvir essa objeção com mais frequência a partir de agora.
A resposta que o próprio relato da Gurtam sugere é separar duas coisas que o comprador tende a misturar de propósito. Custo de produção caiu, de fato: gerar teste, gerar proposta, gerar conteúdo ficou mais barato pra qualquer fornecedor. Valor de julgamento não caiu: a capacidade de decidir o que importa, modelar risco e garantir que o produto é bom o bastante antes de chegar ao cliente continua sendo trabalho humano caro.
Esse argumento só convence com evidência concreta. SLA documentado, taxa de incidente pós-entrega, tempo de resposta a risco e processo de revisão auditável são o material que sustenta a conversa de preço quando o comprador tenta comoditizar a oferta. Sem esses dados, o discurso de julgamento vira retórica vazia e a negociação vai pro preço mesmo.
Saroka cita um risco específico: exposição de dado sensível em aplicação com LLM, sobretudo quando o sistema processa dado pessoal, informação confidencial de negócio ou credencial. Ele diz que seria cauteloso em dar a modelo externo acesso a informação que a empresa não pode se dar ao luxo de expor.
O mesmo vale pra dado de CRM, contrato e histórico de negociação usado pra treinar ou alimentar ferramenta de IA de vendas. Antes de aprovar uma ferramenta que gera proposta, playbook ou plano de conta, revenue ops precisa fazer a mesma pergunta que QA já está fazendo: que dado sai da empresa, pra onde vai e sob qual contrato.
Saroka cita frameworks emergentes do NIST pra teste e validação de sistema de IA, incluindo LLM, modelo multimodal e agente, mas reconhece que ainda não existe prática universalmente estabelecida nessa área. Pra quem lidera receita, isso significa construir internamente o equivalente ao assistente e à interface de revisão que a Gurtam montou pra QA: uma camada que valida lead, linha de forecast e proposta gerados por IA antes de entrarem no pipeline oficial.
A decisão prática que sobra pra quem responde pela meta é onde investir o próximo real e o próximo headcount. Não necessariamente em mais ferramenta que gera volume de lead, proposta ou forecast, mas na camada de revisão e julgamento que decide o que desse volume merece confiança, exatamente como a Gurtam fez com os testes de software.