Construí três assistentes de IA. Dois deles vazariam dados de clientes
Três POCs em seis meses. Dois sem arquitetura de privacidade. O que aconteceria no dia em que entrassem em produção — e o teste de cinco perguntas que agora aplico antes de qualquer demo.
Nos últimos seis meses entreguei três POCs de assistente de IA. Uma ferramenta interna para o time de vendas, um copiloto para suporte, um Q&A sobre documentos de procurement. Os três demos foram bonitos. Os clientes ficaram contentes. Dois deles vazariam dados de clientes no primeiro dia em produção.
Quero falar sobre os buracos concretos, porque vejo a mesma forma de erro em um a cada dois POCs de IA que me mandam para revisão.
O padrão é sempre o mesmo. O founder quer IA. O founder contrata um vibe-coder (às vezes eu, antes de aprender). O vibe-coder entrega em duas semanas. A coisa funciona. O founder diz "vamos lançar." O advogado diz "espera."
Aqui está o que entreguei e onde cada um tinha buraco.
Assistente nº 1 — sales copilot. Lia notas de vendas no Notion, gerava rascunhos de follow-up, devolvia para o CRM. Funcionava lindo. Três problemas que só percebi relendo com atenção:
- As notas continham nomes de clientes, telefones e valores de contrato. Tudo isso ia para a API da OpenAI em cada requisição. O DPA do cliente com seus próprios clientes não permitia isso. Estávamos a um screenshot de um processo de verdade.
- Sem trilha de auditoria. Se um usuário final perguntasse "que dados meus a sua IA viu?", não saberíamos responder. Não "não queremos" — não conseguíamos.
- Logs de todas as respostas do modelo ficavam num VPS em texto puro. Retenção padrão: para sempre. Ninguém decidiu outra coisa. Ninguém pensou.
Assistente nº 2 — support copilot. Sugeria respostas para tickets de suporte. O tutorial de vibe-coding diz: passe o ticket completo mais o histórico do cliente. Foi o que fizemos. O histórico tinha endereços, mensagens de falha de pagamento e um caso que prefiro não descrever por escrito. Tudo foi para o LLM. Não avisamos o cliente.
Assistente nº 3 — procurement Q&A. Esse construí depois, e construí direito. Duas camadas — um PII scrubber na entrada, uma camada de redaction na saída — trilha de auditoria de cada prompt e resposta com retenção de 30 dias, e SSO com acesso baseado em papéis: o time jurídico via tudo, o time de procurement via só as próprias consultas.
A diferença entre o nº 3 e os outros não foi habilidade em IA. Quando o construí, eu já tinha entendido que a IA é a parte fácil. A canalização ao redor da IA é a parte que decide se você vende isso para um enterprise de verdade ou passa seis meses refazendo na semana antes do fechamento.
Este é o teste que agora rodo em todo assistente de IA antes de liberar o demo.
Para onde vão os dados. Quais campos saem do seu servidor e acabam nos logs do provedor de LLM? Você precisa apontar para o prompt template e dizer "este campo, este campo, este não." Se não consegue, não está pronto.
O que é logado. Cada prompt. Cada resposta. Com timestamps, IDs de usuário e uma política de retenção que você escreveu em algum lugar. Se o CTO responde "a gente loga tudo no CloudWatch" — isso não é trilha de auditoria, é cemitério.
Quem vê o quê. Acesso por papel na interface da IA, não só no banco. O estagiário não pode consultar a thread do CEO. O agente de suporte não pode levantar a planilha de salários.
O que acontece no delete. Quando o cliente pede para ser esquecido, você consegue esquecer de verdade — não só no banco, mas nos embeddings, nos prompts em cache, nos logs, nos backups? Se a resposta começa com "tecnicamente…" — recomece.
O que você prometeu ao cliente. O DPA, a política de privacidade, o consentimento. Nenhum desses documentos é primeiro uma questão jurídica antes de ser uma questão de engenharia. O engenheiro que constrói a camada de dados precisa saber o que foi prometido.
Conto essa história porque a conversa sobre AI compliance em 2026 está acontecendo quase toda na ponta errada. Todo mundo compra templates de política GDPR/IA de escritórios de advocacia. Quase ninguém constrói a camada de dados que faz essas políticas serem reais.
Um advogado não resolve por você o compliance do seu assistente de IA. Um advogado só diz o que você prometeu. Quem cumpre a promessa é a arquitetura — o que sai, o que é logado, o que é mascarado, o que é apagado, quem tem acesso, qual trilha de auditoria comprova tudo.
Faço esse trabalho como serviço. Engenharia, não consultoria jurídica. Mapa do fluxo de dados na IA. Marcação de campos PII. Scrubber, trilha de auditoria, política de retenção, modelo de acesso. Transformar promessas GDPR/LGPD/DPA em verdade, não só em assinatura.
Não é o trabalho mais empolgante de 2026. É o trabalho que impede o trabalho empolgante de IA de virar escândalo nove meses depois.
Se você está lançando um assistente de IA e as respostas para as cinco perguntas acima te deixam desconfortável, vamos conversar.