Sua política diz que a IA protege dados. O teste prova?

A apresentação do fornecedor diz que dados pessoais são removidos antes de chegar ao modelo. A política interna afirma que há criptografia, acesso restrito e supervisão humana. O fluxograma mostra descarte depois da execução. Tudo parece protegido — até alguém perguntar: qual versão foi testada, com quais casos, qual resultado e qual evidência prova que o controle funcionou?

Essa pergunta ganhou uma referência brasileira muito concreta. Em 3 de novembro de 2026, a ANPD publicou os ciclos 4, 5 e 6 do Sandbox Regulatório de IA e Proteção de Dados. Os documentos acompanham três soluções nos setores de mobilidade, saúde e segurança de IA, relacionando documentos, testes, riscos, condicionantes, correções e retestes.

O aprendizado mais útil para uma empresa não é copiar a pontuação ou declarar que participou de um “sandbox interno”. É adotar uma disciplina simples: controle descrito não é controle implementado; controle implementado não é controle testado; teste aprovado em uma versão não é garantia permanente.

Este artigo transforma essa disciplina no método PROVA. Ele ajuda gestão, tecnologia, segurança e privacidade a criar evidência antes de ampliar dados, usuários ou autonomia. Não é parecer jurídico, selo de conformidade nem reprodução da metodologia oficial da ANPD.

O que os novos relatórios realmente mostram

O sandbox da ANPD tem caráter experimental, preventivo e de aprendizado institucional. A própria Agência ressalta que seus resultados não equivalem a aprovação plena da solução, comprovação integral de conformidade ou autorização de uso irrestrito. Nos relatórios, “êxito” significa produzir evidências e aprendizados sobre avanços, riscos, limites, condicionantes e requisitos dentro do escopo examinado.

Isso muda a conversa. Uma política bem escrita pode suprir uma lacuna documental sem provar eficácia operacional. Uma pontuação de maturidade pode avançar enquanto testes específicos ainda têm limites. Uma correção planejada continua pendente até ser identificada na versão, implantada e retestada. E um plano de descontinuidade não reduz risco sozinho: é preciso comprovar revogação de acessos, desativação de integrações e destino dos dados.

O 6º Relatório Parcial ainda pede que o acervo final seja organizado por participante, solicitação, versão, teste e evidência. Também recomenda distinguir condicionantes cumpridas, ressalvas, requisitos remanescentes e compromissos de melhoria. Essa rastreabilidade é aplicável a qualquer projeto empresarial: cada conclusão precisa apontar para o objeto que realmente foi observado.

A escada de evidência: cinco estados que não devem ser misturados

1. Declarado: alguém afirma que o controle existe. Exemplo: “removemos dados pessoais antes de enviar a solicitação ao modelo”. É uma hipótese a verificar.
2. Documentado: arquitetura, política, contrato ou procedimento descreve como deveria funcionar, quem responde e em quais condições.
3. Implementado: a funcionalidade está presente na versão e no ambiente examinados. Uma tela futura, uma configuração de laboratório ou item de roadmap não conta.
4. Testado: casos definidos exercitam o controle e produzem resultado observável, com critérios de aceite, registro e limite conhecidos.
5. Retestado: uma correção ou mudança volta ao mesmo conjunto relevante de casos e passa sem reabrir falhas antigas. Depois, o controle entra em monitoramento.

Use esses estados no inventário do projeto. “Temos anonimização” é amplo demais. “O detector de identificadores da versão 2.4, no ambiente de homologação, bloqueou os casos A a F e falhou no caso G; correção 2.4.1 aguarda reteste” é uma informação gerenciável.

Método PROVA: transforme obrigação em comportamento observável

1. P — Processo e propósito: delimite o fluxo real, a finalidade, o titular afetado e o resultado permitido. Mapeie coleta, preparação, envio ao modelo, ferramentas, memória, logs, integrações, resposta, uso humano e eliminação. “Usar IA no atendimento” não é um processo testável.
2. R — Risco e requisito: associe cada risco a uma exigência verificável. Se o risco é expor dado de saúde ao provedor, o requisito pode ser bloquear identificadores e conteúdo desnecessário antes da inferência, registrar o evento e impedir envio quando a sanitização falhar.
3. O — Observação e oráculo: defina o que será observado e como saber se o resultado está correto. Inclua evento esperado, limite, evidência, responsável pela avaliação e fonte de verdade. O próprio modelo não deve ser o único juiz do comportamento que produziu.
4. V — Versão e variação: registre modelo, instruções, detector, base, integração, configuração, ambiente e data. Teste casos normais, bordas e ataques, além de variações de formato, idioma, áudio transcrito, anexos e dados incompletos que aparecem na operação.
5. A — Aceite e acompanhamento: decida aprovar, aprovar com limite, corrigir e retestar ou bloquear. Defina risco residual aceito, dono, validade da evidência, gatilho de novo teste, amostra em produção e plano de descontinuidade.

O PROVA não exige laboratório sofisticado para começar. Exige uma pergunta precisa, um caso reproduzível e um registro que permita a outra pessoa conferir o resultado. A profundidade cresce com a consequência, a sensibilidade dos dados e a dificuldade de reversão.

Cartão mínimo de teste

Para cada controle relevante, preencha um cartão com:

• afirmação: o que a equipe ou o fornecedor diz que o sistema faz;
• risco: qual dano o controle pretende reduzir e para quem;
• escopo: processo, versão, ambiente, integração e conjunto de dados;
• cenário: entrada, condição inicial, ação e variações testadas;
• resultado esperado: comportamento e limiar de aceite definidos antes da execução;
• evidência: log, captura, relatório, evento no sistema oficial ou validação independente;
• resultado observado: passou, falhou ou ficou inconclusivo, sem arredondar incerteza;
• decisão: liberar, limitar, corrigir, retestar ou bloquear;
• dono e validade: quem responde, até quando a evidência vale e o que dispara novo teste.

Não grave dados pessoais reais só para provar que o bloqueio funciona. Comece com dados sintéticos e casos controlados. Se a validade depender de ambiente real, planeje amostragem mínima, acesso restrito, retenção curta e supervisão compatível com o risco.

Exemplo: “removemos dados antes do modelo”

Uma clínica usa IA para preparar um resumo de mensagens pré-consulta. O fornecedor afirma que nome, CPF, telefone e e-mail são removidos. O teste ingênuo envia uma frase limpa, confirma que o nome desapareceu e aprova o projeto.

Um teste útil inclui nome composto, apelido, endereço, número do cartão, foto com texto, áudio transcrito, identificador no nome do arquivo, dados misturados à queixa e pedidos de correção como “meu CPF certo é...”. Também observa prompt, arquivo, metadado, log, memória, ferramenta chamada e saída — não apenas a resposta mostrada ao usuário.

Se o sistema troca identificadores por tokens reversíveis, isso pode ser uma salvaguarda, mas não transforma automaticamente o fluxo inteiro em anônimo. A LGPD considera a possibilidade de associação direta ou indireta e os meios técnicos razoáveis disponíveis. O relatório final do sandbox também destaca que retirada de identificadores, separação de bases e criptografia precisam ser avaliadas junto aos dados remanescentes, ao contexto e às integrações.

A decisão pode ser: liberar somente texto digitado; bloquear anexos até existir detector adequado; impedir inferência se a sanitização falhar; revisar amostra sob acesso restrito; corrigir os casos que escaparam; e retestar antes de aceitar áudio ou imagem. O ganho operacional permanece, mas o escopo nasce da evidência — não da demonstração comercial.

Matriz rápida por setor: qual controle merece prova primeiro?

• v7 Obras: teste se fotos, diários e documentos preservam apenas dados necessários; verifique acesso de terceiros e eliminação ao encerrar obra ou contrato.
• v7 Carteira: use pedidos reais anonimizados ou sintéticos para provar que CPF, dados bancários e contatos não vazam para integrações desnecessárias; reconcilie bloqueios e falsos positivos.
• v7 Agro: delimite produtor, propriedade, geolocalização e dado agronômico; teste compartilhamento com APIs e fornecedores em cada rota do fluxo.
• v7 Imob: verifique se documentos, renda, preferências e histórico saem da conversa quando não são necessários; prove segregação de acesso entre corretor, empreendimento e parceiro.
• v7 Clínicas Retorno: exercite dados de saúde, identificadores em texto e anexos, supervisão profissional, registro de acesso, resposta ao titular e encerramento do tratamento.
• v7 Custom: priorize o sistema que combina dados de mais fontes ou executa ação de maior consequência; teste fluxo ponta a ponta, não só a chamada ao modelo.

Placar: meça cobertura de evidência, não volume de documentos

• controles por estado: quantos estão declarados, documentados, implementados, testados e retestados;
• cobertura de risco crítico: riscos altos com pelo menos um teste válido e responsável;
• taxa de escape: casos em que dado ou ação ultrapassou o controle;
• falso bloqueio: tarefas legítimas interrompidas e custo operacional causado;
• tempo de correção e reteste: da falha descoberta à nova evidência;
• evidência vencida: testes que já não correspondem à versão em produção;
• reconstrução: amostras em que outra pessoa identifica versão, entrada, controle, resultado, decisão e dono;
• resultado líquido: tempo, qualidade e custo depois de revisão, exceção, incidente e manutenção.

Doze perguntas antes de ampliar o piloto

1. Qual processo, finalidade e grupo de titulares estão realmente no escopo?
2. Que dados entram por texto, arquivo, áudio, imagem, integração, memória e log?
3. Qual parte do fluxo envolve controlador, operador, suboperador ou transferência internacional?
4. Quais controles estão apenas declarados ou documentados?
5. Qual versão e ambiente cada evidência representa?
6. O critério de aceite foi definido antes do resultado?
7. Quem atua como fonte independente de verdade?
8. Testamos casos raros, formatos alternativos e tentativas de contorno?
9. Uma falha interrompe o envio ou apenas gera alerta que ninguém assume?
10. Correções foram retestadas contra falhas antigas e novas?
11. O que revoga acessos, desliga integrações e determina o destino dos dados?
12. Qual mudança invalida a evidência e exige nova rodada?

Piloto orientado a evidência em 20 dias úteis

1. Dias 1 a 4: delimite processo, finalidade, dados, atores, sistemas, versões e riscos; avalie com privacidade se o tratamento pode exigir RIPD.
2. Dias 5 a 8: converta riscos prioritários em requisitos observáveis e escreva cartões de teste com critério de aceite.
3. Dias 9 a 12: execute casos normais, bordas e adversos em ambiente controlado; registre falhas sem alterar o limiar depois de ver o resultado.
4. Dias 13 a 16: corrija causas, identifique a nova versão, reteste e faça um exercício de incidente e descontinuidade.
5. Dias 17 a 20: decida o escopo liberado, risco residual, amostra de produção, métricas, responsáveis e gatilhos de retorno ao teste.

A orientação da ANPD sobre o RIPD recomenda elaborá-lo antes de iniciar tratamento que possa gerar alto risco, documentar fatores e medidas e revisar continuamente quando operações ou riscos mudarem. O cartão de teste não substitui esse relatório; ele produz evidência operacional para verificar se salvaguardas descritas funcionam no fluxo.

O ponto de vista da V7 Agents

IA não fica segura porque a política usa as palavras certas. Ela fica mais controlável quando finalidade, dados, versão, comportamento esperado, evidência, responsável e rotina de revisão se encontram no mesmo processo.

Esse trabalho também protege o ROI. Um controle que bloqueia tudo paralisa a operação; um controle que só existe no documento deixa o risco intacto. O objetivo é descobrir cedo o equilíbrio verificável entre utilidade, proteção e esforço humano. O V7 IA Ready mapeia processos, dados, riscos, integrações e critérios de aceite antes da implantação; a v7 Custom transforma esse desenho em automação com trilha, testes e acompanhamento operacional.

Fontes consultadas

• ANPD — publicação dos 4º, 5º e 6º Relatórios Parciais do Sandbox Regulatório, 3 de novembro de 2026.
• ANPD — 4º Relatório Parcial de Monitoramento: Fase de Teste, Ciclo 4.
• ANPD — 5º Relatório Parcial de Monitoramento: Fase de Teste, Ciclo 5.
• ANPD — 6º Relatório Parcial de Monitoramento: Fase de Teste, Ciclo 6.
• ANPD — perguntas e respostas sobre Relatório de Impacto à Proteção de Dados Pessoais, atualizado em setembro de 2026.
• Presidência da República — texto compilado da Lei Geral de Proteção de Dados Pessoais.