O humano hesita diante de uma tarefa ambígua. O agente de IA não hesita: ele entrega errado em minutos. Veja por que critérios de aceite deixaram de ser ritual ágil e viraram o ponto onde custo, qualidade e conformidade são decididos.

Definition of Ready é o conjunto de condições que um item de trabalho precisa cumprir antes de entrar em execução. Definition of Done é o conjunto de condições que ele precisa cumprir para ser considerado entregue. Por duas décadas, os dois funcionaram como acordo de equipe, úteis e frequentemente negligenciados sem consequência imediata. A execução assistida por IA acabou com essa tolerância, por um motivo simples de comportamento: diante de uma tarefa ambígua, uma pessoa hesita e pergunta, enquanto um agente não hesita e entrega. O que antes gerava uma dúvida no chat do time agora gera código errado em minutos, consumindo tokens, produzindo defeito que se propaga e, quando a tarefa toca dado pessoal, criando exposição que ninguém decidiu criar. Critério de aceite deixou de ser ritual e virou o ponto do processo onde custo, qualidade e conformidade são decididos de uma vez.

O humano hesita, o agente não

Vale examinar a diferença com cuidado, porque ela é a origem de tudo o que vem depois. Quando uma pessoa recebe uma tarefa mal especificada, acontece algo que raramente é reconhecido como controle de qualidade: ela trava. Manda mensagem para quem escreveu, pergunta o que significa determinado campo, descobre que a regra não foi decidida. Esse atrito é lento e irritante, e por isso ninguém o valoriza. Mas ele funciona como uma barreira: a ambiguidade é detectada antes de virar código.

Um agente de IA não tem esse comportamento. Diante da mesma ambiguidade, ele preenche a lacuna com o que parece plausível a partir do padrão que encontra e segue em frente com fluência. O resultado é uma entrega completa, bem escrita e possivelmente errada, produzida rápido demais para que alguém percebesse que a pergunta nunca foi feita. A barreira lenta desapareceu, e nada foi colocado no lugar dela.

A consequência prática é um encadeamento que se repete e que raramente é lido como uma coisa só:

tarefa ambígua → agente preenche a lacuna → entrega plausível e errada →

tokens gastos → retrabalho → defeito que ninguém classificou

A tese deste guia: o Definition of Ready deixou de ser um ritual de time e virou um controle econômico. Cada tarefa que entra em execução sem estar pronta é uma aposta paga em tokens, e a fatura chega no fim do mês sem indicar qual item a gerou. Do outro lado, o Definition of Done deixou de ser checklist de entrega e virou o ponto onde a conformidade é verificada, porque é a última barreira antes de o defeito chegar em produção. Os dois artefatos mais antigos do processo ágil se tornaram, sem alarde, os mais estratégicos.

O que precisa estar pronto antes: o DoR na era da IA

Um Definition of Ready desenhado para execução humana costuma exigir descrição clara, valor de negócio e estimativa. Isso continua valendo e ficou insuficiente. Quando parte da execução é assistida por IA, quatro condições passam a importar de forma nova.

A terceira e a quarta condições são as que mais surpreendem quem vem do ágil clássico, porque não existiam como preocupação. Elas conectam o item de trabalho a duas recomendações que o Gartner dirige a líderes de engenharia: tornar obrigatória a prática de engenharia de contexto, treinando as equipes a incluir apenas informação relevante e eliminar dado desnecessário, e alinhar a seleção de modelo à complexidade da tarefa, direcionando o que é simples e frequente para modelos menores e reservando os mais caros para trabalho complexo. Ambas dependem de uma informação que só existe se alguém a declarou antes: o que a tarefa exige e quão complexa ela é. Esse alguém é o DoR.

O que precisa ser verdade depois: o DoD como último portão

Se o DoR controla o que entra, o DoD controla o que sai, e é onde a conformidade tem sua última chance de ser verificada antes da produção. Quatro verificações merecem lugar explícito.

•     A entrega foi validada contra o critério declarado. Não contra a impressão de quem revisou. Se o critério era verificável, a validação é objetiva, e isso é o que permite aceitar entrega gerada sem depender de leitura linha a linha.

•     Os controles de proteção de dado foram aplicados neste ponto. Mascaramento, ausência de registro de teste, ausência de dado pessoal em log. A LGPD determina em seu artigo 46 a adoção de medidas de segurança aptas a proteger os dados pessoais de tratamento inadequado, e um controle aplicado em parte do sistema e ausente em outra é, naquele ponto, um controle não aplicado.

•     Está registrado o que foi gerado e com qual contexto. É a rastreabilidade aplicada à produção assistida, e é o que permite responder pela origem de um defeito gerado quando ele aparecer meses depois.

•     O defeito encontrado foi classificado. Com módulo, tipo e vínculo ao requisito violado. Sem isso, cada ocorrência parece inédita e o padrão nunca aparece, tema que tratamos em profundidade no artigo sobre QA e conformidade deste blog.

Há um paralelo técnico que ajuda a enxergar o DoD como mecanismo, e não como formulário. Em pipelines de dados, a Databricks documenta as expectations como regras de qualidade declarativas que validam o dado na ingestão, permitindo barrar ou colocar em quarentena o registro que não passa, em vez de deixá-lo contaminar as camadas seguintes. O DoD cumpre exatamente esse papel no fluxo de entrega de software: é a regra declarativa que impede o que não atende ao critério de seguir adiante. A diferença é que, no pipeline de dados, quase ninguém questiona a necessidade dessa barreira, enquanto no fluxo de entrega ela costuma ser tratada como excesso de processo.

Por que isso é, antes de tudo, uma conversa sobre custo

A leitura econômica dessa mudança é a que costuma destravar a decisão na diretoria. O Gartner prevê que, até 2028, os custos de AI coding superarão o salário médio de um desenvolvedor, puxados pela alta no consumo de tokens e pela migração do licenciamento por assento para o licenciamento por consumo. E, segundo o analista sênior Nitish Tyagi, a disciplina de tokens não emergirá apenas da escolha do desenvolvedor, porque desenvolvedores tendem a otimizar por velocidade e conveniência em vez de eficiência de custo. Sem um modelo operacional de engenharia governado, os custos podem escalar mais rápido que os ganhos de produtividade que a ferramenta deveria entregar.

Traduzindo para o processo: o momento em que a economia de tokens é efetivamente decidida não é o momento do prompt, é o momento em que a tarefa é considerada pronta para execução. É ali que se define quanto contexto será necessário, se a complexidade justifica um modelo caro e se o resultado poderá ser validado sem revisão manual exaustiva. Uma tarefa que entra ambígua consome tokens duas vezes, na tentativa errada e na correção, e nenhuma das duas aparece separada na fatura.

Vale registrar que a economia de contexto tem também um fundamento técnico. Pesquisa recente de arquiteturas de sequência, publicada como preprint e ainda sem revisão por pares, descreve que memória crescente traz complexidade quadrática e alto uso de memória em inferência, e explora justamente mecanismos de seleção do subconjunto relevante em vez de carregamento integral. O princípio de projeto é o mesmo que o DoR aplica no plano do processo: relevância selecionada rende mais que volume enviado por precaução.

Onde o DoR e o DoD deixam de ser slide (consultoria Jira)

Definição de pronto que vive em página de wiki não barra nada. Para funcionar como controle, ela precisa estar embutida no fluxo em que o trabalho já se move, com três características que não são opinativas.

•     Impedimento real, não recomendação. O workflow não permite que o item avance sem as condições mínimas preenchidas. Se é possível avançar ignorando, a definição é decorativa.

•     Campos que capturam o que importa. Critério de aceite, classificação de sensibilidade e vínculo entre defeito e requisito precisam existir como estrutura, e não como texto solto na descrição, ou não são consultáveis depois.

•     Histórico que responde à auditoria. O registro de transições, com autor e data, é o que demonstra quando cada condição foi cumprida. É a diferença entre afirmar diligência e comprová-la.

No Jira, isso significa desenhar tipos de item, campos, esquemas de permissão e workflow para refletir o processo real, e não o processo que o time gostaria de ter.

É trabalho de configuração deliberada, e é onde a consultoria Jira encontra o tema de IA sem forçar a conexão: o mesmo sistema que organiza o trabalho humano é o que precisa organizar, registrar e barrar o trabalho assistido.

O elo de dados: o contrato que precede o critério (governança de dados)

A primeira condição do DoR, o contrato de dado explícito, merece atenção separada porque é a que mais falta e a que mais custa. Um critério de aceite não consegue ser verificável se o dado que ele descreve não tem definição acordada.

Não há como validar objetivamente que um campo está correto quando não existe consenso sobre o domínio de valores que ele aceita.

Em operação com múltiplas fontes, isso escala para o problema de dados mestres: quando a mesma entidade tem versões divergentes entre sistemas, nenhum critério de aceite local resolve, porque o desacordo está acima do item de trabalho. Tratamos desse ponto no artigo sobre dados mestres no Databricks, e a formulação de lá vale aqui: dado mestre não é o dado que você tem, é o acordo sobre qual versão vale. Do lado da plataforma, o Unity Catalog é descrito na documentação da Databricks como a camada unificada de governança para dados e IA, com controle de acesso, linhagem e auditoria centralizados, o que dá ao contrato de dado um lugar onde ser governado e uma linhagem que responde de onde cada valor veio.

Por que isso exige competências que costumam estar separadas: o contrato de dado é engenharia de dados. O critério verificável é engenharia de qualidade. O escopo de contexto e a política de modelo são arquitetura de IA. E o lugar onde as três viram condição que barra é gestão do trabalho. A CSP Tech atua nas quatro frentes, com atuação como especialistas Databricks na camada de dado governado, consultoria Jira como Atlassian Gold Partner na camada de fluxo e 34 anos construindo software corporativo na camada de qualidade. Um DoR desenhado só pelo time ágil ignora a camada de dado; um desenhado só pela engenharia de dados não barra nada.

Quando esse rigor é desproporcional

•     Time pequeno, produto sem dado pessoal e sem uso de IA na execução. O acordo informal funciona quando poucas pessoas conhecem todo o contexto e a velocidade de produção não excede a capacidade de revisão. O rigor deve acompanhar a escala e a exposição, não a ambição.

•     Exploração e descoberta. Trabalho investigativo, protótipo descartável e prova de conceito não devem passar por portão de aceite completo, porque o objetivo ali é aprender, não entregar. O erro é promover o protótipo a produção sem submetê-lo ao portão.

•     Antes de existir acordo sobre o que é qualidade. Implantar campos obrigatórios sem que a empresa tenha definido o que considera pronto produz preenchimento por obrigação, que é dado ruim com aparência de processo. Definir primeiro, instrumentar depois.

Perguntas frequentes

O que é Definition of Ready e Definition of Done?

Definition of Ready é o conjunto de condições que um item precisa cumprir para entrar em execução; Definition of Done é o conjunto de condições para ser considerado entregue. Em times que usam IA na execução, o primeiro passou a controlar quanto contexto será enviado, qual complexidade a tarefa tem e se a entrega poderá ser validada objetivamente, e o segundo passou a ser o último ponto onde controles de proteção de dado e classificação de defeito são verificados antes da produção.

Por que critérios de aceite ficaram mais importantes com a IA?

Porque a barreira informal desapareceu. Diante de uma tarefa ambígua, uma pessoa costuma parar e perguntar, o que detecta o problema antes de virar código. Um agente preenche a lacuna com o que parece plausível e entrega rápido, de forma fluente e possivelmente errada. Sem critério explícito e verificável, não há contra o que validar a entrega, e a validação subjetiva não acompanha a velocidade da produção assistida.

Como critérios de aceite reduzem o custo de tokens?

Porque a economia é decidida antes do prompt, não durante. Um item pronto declara qual informação a tarefa exige, o que evita enviar contexto por precaução, e declara a complexidade envolvida, o que permite direcionar tarefas simples a modelos menores. São as duas recomendações que o Gartner dirige a líderes de engenharia, engenharia de contexto e seleção de modelo por complexidade, e ambas dependem de informação que só existe se foi declarada antes. Item ambíguo consome tokens duas vezes: na tentativa errada e na correção.

O que a governança de dados tem a ver com critérios de aceite?

Um critério só é verificável se o dado que ele descreve tem definição acordada, com tipo, domínio de valores e regra de validação. Sem contrato de dado, a validação vira opinião. Em operações com múltiplas fontes, o desacordo sobe para o nível de dados mestres, quando a mesma entidade tem versões divergentes entre sistemas, e nenhum critério local resolve. Por isso o contrato de dado é a primeira condição de prontidão, e não um detalhe técnico posterior.

Próximo passo

Se o seu time já usa IA na execução e convive com retrabalho recorrente, custo que ninguém consegue atribuir a uma entrega específica ou defeitos que reaparecem sem que alguém consiga agrupá-los, o ponto de intervenção provavelmente não está no modelo nem na ferramenta: está no que a sua definição de pronto deixa passar. Solicite um diagnóstico de prontidão de entrega com a CSP Tech e receba o mapa do seu ciclo: o que hoje entra em execução sem estar pronto, o que sai sem ser verificado e quais condições precisam virar impedimento real no fluxo.

Autor: Guilherme Matos, estrategista de conteúdo e IA, certificado HubSpot, Google, Anthropic e Semrush. Revisão técnica por especialistas de engenharia, dados e Atlassian da CSP Tech (Atlassian Gold Partner, Microsoft Gold Partner, parceira Databricks, participante do Anthropic Partner Network, 34 anos de mercado).

Fontes (2026): Gartner, press release sobre consumo de tokens e custos de AI coding (gartner.com/en/newsroom, 24/jun/2026), quanto à previsão para 2028, às declarações do analista sênior Nitish Tyagi e às recomendações de engenharia de contexto e de seleção de modelo por complexidade, mantidas como previsão e recomendação atribuídas, com horizonte original preservado. Lei nº 13.709/2018 (LGPD), artigo 46, sobre a adoção de medidas de segurança técnicas e administrativas; a caracterização de infração e eventual sanção cabe à autoridade competente ao final de processo administrativo. Databricks Documentation, expectations de qualidade em pipelines e Unity Catalog como camada de governança para dados e IA (docs.databricks.com). Atlassian, documentação de Jira sobre tipos de item, campos, workflow e histórico de transições (atlassian.com, developer.atlassian.com). Behrouz, A. et al., “Memory Caching: RNNs with Growing Memory”