SPEC-Driven Development · MOFU · IT

Critérios de aceite e Definition of Done para projetos de IA

Por Adriano Schneider · · 8 min de leitura

"Está funcionando" não é Definition of Done. Em projetos de IA, "funcionando" pode significar coisas muito diferentes para engenheiros, stakeholders e equipes jurídicas. Este artigo define o que "pronto" realmente significa em features de IA — e entrega o checklist que você vai querer ter antes de qualquer merge.

O problema com "pronto" em projetos de IA

Em software convencional, "pronto" é mais fácil de definir: os testes passam, a funcionalidade funciona conforme especificado, o código foi revisado e está em produção. Simples o suficiente.

Em projetos de IA, a definição de "pronto" tem camadas extras que a maioria dos times descobre da maneira difícil — quando algo dá errado em produção:

Cada um desses problemas poderia ter sido capturado por um DoD bem definido. Vou ser direto: um DoD para IA não é burocracia — é o que separa "parece funcionar no demo" de "está pronto para usuários reais".

DoD vs Critérios de Aceite — a diferença prática

Antes do checklist, é importante distinguir os dois conceitos:

Critérios de aceite são específicos de cada requisito. Eles respondem: "O que esta feature específica precisa fazer para ser considerada correta?" São escritos junto com o requisito, revisados pelo stakeholder de negócio, e validados nos testes da feature.

Exemplo de critério de aceite (específico): "Dado um ticket de suporte com a palavra 'urgente', o agente deve classificar como prioridade alta em 90% dos casos no dataset de teste."

Definition of Done (DoD) é transversal ao projeto. Ele responde: "Além de fazer o que especificamos, a feature atende a todos os padrões de qualidade, segurança e compliance que se aplicam a qualquer coisa que mergemos?" É acordado pela equipe uma vez e aplicado a toda feature — não precisa ser reescrito a cada requisito.

Uma feature pode passar em todos os critérios de aceite e ainda falhar no DoD. E aí ela não entra em produção.

O DoD para features de IA

O checklist abaixo é o artefato central deste artigo. Ele está organizado em 5 categorias: Funcional, Segurança, Performance, Observabilidade e LGPD/Compliance. Adapte os limites numéricos ao seu projeto — o que não é negociável é a estrutura e a intenção de cada item.

Categoria 1 — Funcional

  • ☐ Testes automatizados passando com dataset representativo
    Mínimo de 50 casos de teste, incluindo casos de borda identificados no piloto. Taxa de acerto ≥ ao threshold definido no requisito.
  • ☐ Comportamento de fallback testado e funcionando
    O sistema se comporta de forma definida quando o modelo retorna resposta inválida, quando a confiança está abaixo do threshold, ou quando uma ferramenta falha.
  • ☐ Casos de borda documentados e cobertos
    Input vazio, input muito longo (acima do limite de tokens), input em idioma não suportado, input com caracteres especiais — todos testados.
  • ☐ Requisito funcional atualizado se o comportamento mudou durante a implementação
    Código e documento de requisito estão sincronizados. Divergências são exceção documentada, não a regra.
  • ☐ Revisão de código realizada com foco em lógica de IA
    Além de revisão de código convencional, um segundo par de olhos revisou a construção do contexto, o system prompt e a lógica de seleção de ferramentas.

Categoria 2 — Segurança

  • ☐ Teste de prompt injection realizado e resultados documentados
    Tentativas de injeção de instrução no input do usuário foram testadas. O sistema ignora ou rejeita tentativas de manipulação do system prompt.
  • ☐ PII não entra no modelo sem mascaramento
    CPF, CNPJ, e-mail, telefone, dados de saúde — qualquer dado pessoal identificável é mascarado ou pseudonimizado antes de entrar na context window.
  • ☐ Escopo de ferramentas do agente verificado (princípio do menor privilégio)
    O agente tem acesso apenas às ferramentas que esta feature específica precisa. Ferramentas de escrita são avaliadas separadamente das de leitura.
  • ☐ Output do modelo validado antes de exibir ao usuário ou executar ação
    Para features com efeito externo (escrita em banco, envio de e-mail, chamada de API), o output passa por validação de schema e sanitização antes de ser executado.
  • ☐ Credenciais e chaves de API em secret manager, não em código
    Nenhuma chave de modelo, chave de banco vetorial ou token de API hardcoded no código ou em variáveis de ambiente em texto plano.

Categoria 3 — Performance

  • ☐ Latência medida e dentro do SLO definido
    Latência p50 e p95 medidas em ambiente de staging com volume representativo. SLO típico para assistentes: p50 ≤ 3s, p95 ≤ 8s (ajustar conforme UX do produto).
  • ☐ Custo por operação estimado e dentro do orçamento
    Tokens consumidos por operação típica calculados. Custo mensal estimado com volume projetado dentro do orçamento aprovado.
  • ☐ Cache implementado onde aplicável
    Queries idempotentes com resposta previsível (ex.: classificação de categorias fixas) têm cache configurado para evitar chamadas repetidas ao modelo.

Categoria 4 — Observabilidade

  • ☐ Logging de todas as chamadas ao modelo configurado
    Cada chamada registra: timestamp, ID de sessão, modelo usado, tokens de input/output, latência, resultado (sucesso/erro). Input e output são armazenados com anonimização de PII.
  • ☐ Métricas de qualidade sendo coletadas
    Ao menos uma métrica de qualidade automatizada rodando: taxa de recusa, score de satisfação do usuário, taxa de escalada para humano, ou score de avaliação LLM-as-judge.
  • ☐ Alertas configurados para degradação de qualidade
    Alerta ativo se taxa de erro superar 5%, latência p95 superar o SLO, ou custo diário superar 150% da média histórica.
  • ☐ Rastreamento de versão de prompt e modelo
    Cada log de chamada registra a versão do prompt e o modelo utilizado. Permite correlacionar mudanças de qualidade com mudanças de versão.

Categoria 5 — LGPD e Compliance

  • ☐ Dados enviados ao modelo avaliados sob LGPD
    DPO ou responsável de privacidade revisou quais dados são enviados à API do provedor. Termo de processamento de dados do provedor verificado.
  • ☐ Usuário informado que está interagindo com IA
    Interface informa claramente que a resposta é gerada por IA. LGPD art. 20 e regulamentação do Banco Central (para setor financeiro) exigem transparência.
  • ☐ Política de retenção de logs definida e implementada
    Prazo de retenção de logs de conversa documentado. Processo de exclusão de dados do usuário testado e funcionando (direito ao esquecimento).
  • ☐ Finalidade de uso dos dados documentada
    A finalidade do processamento de dados pelo sistema de IA está documentada e é compatível com o consentimento obtido do usuário.

Como adaptar o DoD ao seu projeto

O checklist acima é um ponto de partida. Para adaptar ao seu contexto:

Remova o que não se aplica — com critério

Um projeto de IA para uso interno (sem dados de clientes externos) pode remover ou simplificar vários itens de LGPD. Um projeto sem agente autônomo pode simplificar os itens de escopo de ferramentas. Mas documente o motivo da remoção — "não se aplica porque X" é muito diferente de "pulamos porque deu preguiça".

Adicione itens específicos do seu domínio

Setor financeiro: adicionar verificação de conformidade com resoluções do BACEN. Setor de saúde: adicionar revisão de privacidade de dados clínicos e CFM. Setor jurídico: adicionar revisão de outputs por advogado antes de exibir ao cliente.

Calibre os limites numéricos com dados reais

O SLO de latência, o threshold de acurácia e o limite de custo precisam ser baseados em medições reais do piloto, não em estimativas otimistas. Se o piloto mostrou p95 de 6 segundos, definir SLO de 3 segundos sem mudança arquitetural é ilusão.

Como implementar na prática sem criar burocracia

O maior risco de um DoD é se tornar uma lista que todos fingem verificar mas ninguém verifica de verdade. Para evitar isso:

Automatize o que for automático

Testes passando, latência dentro do SLO, chaves não hardcoded, logging configurado — tudo isso pode ser verificado automaticamente em CI/CD. Items automáticos não consomem tempo humano e não são esquecidos.

Torne o manual explícito e rápido

Para itens que precisam de julgamento humano (revisão de LGPD, revisão de qualidade com usuário de negócio), crie um processo específico com responsável definido e prazo máximo. Se a revisão de LGPD não tem dono e prazo, vai ficar sempre "em andamento".

Revise o DoD a cada trimestre

Um DoD criado no mês 1 do projeto pode estar desatualizado no mês 6. Novos requisitos de segurança, novo modelo com características diferentes, novas regulamentações — tudo isso pode exigir atualização do DoD. Coloque no calendário.

A relação com requisitos e a abordagem SPEC-driven

DoD e critérios de aceite funcionam dentro do ecossistema SPEC-driven da seguinte forma:

Na arquitetura SPEC-driven, o DoD é um documento de primeiro nível — versionado, revisado, referenciado no PLAN.md. Não é uma lista em post-it no quadro branco.

O que acontece quando o DoD não existe

O cenário que descrevo abaixo acontece com frequência previsível em projetos sem DoD:

A feature está "pronta" segundo o desenvolvedor. Os testes da feature passam. O stakeholder de negócio aprova no demo. Vai para produção. Duas semanas depois, o time de compliance descobre que dados de clientes estão sendo enviados para a API do modelo sem avaliação jurídica. O produto é suspenso. A análise de impacto leva 3 semanas. A correção leva mais 2. O relançamento, mais 1. Custo total: 6 semanas de atraso, crise com clientes, revisão de toda a base de dados processada.

Um item de 30 minutos no DoD ("dados avaliados sob LGPD antes do merge") teria evitado tudo isso.

Conclusão: DoD é o contrato da equipe com o produto

Em projetos de IA, "funciona" tem uma barra de exigência mais alta do que em software convencional — porque o modelo pode alucinar, porque os dados são sensíveis, porque o comportamento é probabilístico, e porque o impacto de um erro pode ser externo e irreversível.

O DoD não é uma lista de verificação burocrática. É o contrato que a equipe faz consigo mesma sobre o que significa entregar algo com qualidade. Times que têm um DoD claro e o levam a sério entregam menos — mas o que entregam fica de pé.