Um vendor security review matou meu deal. A checklist de 12 itens que agora rodo antes do demo
Em fevereiro perdi um deal de quatro meses por causa de um questionário de segurança de 64 perguntas. Aqui está a checklist que escrevi depois — e o item que foi o verdadeiro assassino do deal.
Em fevereiro perdi um deal em que eu tinha trabalhado quatro meses. O trabalho estava feito. O contrato estava na mesa do advogado. Aí apareceu o time de segurança do cliente.
Eles mandaram um questionário de vendor security review com 64 perguntas. Oito eu respondi bem, doze respondi mal, e quarenta e quatro tive que inventar a resposta em tempo real, porque ninguém do nosso lado tinha se feito aquelas perguntas antes.
Três semanas de email tennis depois, o deal morreu. A nota do procurement dizia: "supplier unable to meet our minimum data-handling standards." Nada pessoal. Só verdade.
Voltei para casa, abri o questionário e reescrevi a infraestrutura inteira contra ele. Aqui está a checklist que saiu daquela bofetada.
Esta lista não é consultoria jurídica. São as perguntas que um time de procurement ou segurança de enterprise vai fazer de fato antes de assinar com você. A maioria não tem nada a ver com o texto da GDPR e tudo a ver com como o software está construído.
1. Mapa de fluxo de dados. Desenhe o diagrama. O cliente insere X. Vai para o seu servidor. Do seu servidor vai para A, B, C — serviços terceiros, provedor de LLM, analytics. Cada seta no diagrama. Se não consegue desenhar, nenhum enterprise compra de você.
2. Inventário de PII. Em cada campo de cada formulário: qual é pessoalmente identificável, qual é sensível, qual não é nenhum dos dois. O revisor vai pedir essa lista. Vai cruzar com o código. Inconsistências matam deals.
3. Política de dados no LLM. O que vai para OpenAI / Anthropic / Google, o que é logado, o que você consegue provar com screenshots do console do provedor. "Usamos a API em modo privado" não é resposta — mostre a configuração e o contrato.
4. Trilha de auditoria. Quem fez o quê e quando — quem logou, quem exportou dados, quem deletou um registro. Tudo com timestamps e uma política de retenção que você escreveu em algum lugar. Trilha de auditoria sem retenção é só um arquivo que cresce até cair.
5. Modelo de acesso. Papéis, permissões, caminhos de escalada. Onde MFA é obrigatório. Onde não é — e por quê. Se a resposta é "todo mundo na empresa tem admin", você falha o review nessa linha.
6. Criptografia — em repouso e em trânsito. TLS no transporte, AES-256 em disco, política de rotação de chaves. Criptografia de disco no servidor. Chaves fora do repo. Sim, inclusive no ambiente de dev.
7. Backup e recuperação. Onde os backups vivem. Por quanto tempo são guardados. Quanto tempo leva para restaurar. O revisor quer números de RPO e RTO, não "temos backup."
8. Resposta a incidentes. O que acontece quando algo vaza. Quem liga para quem. Em quanto tempo você notifica o cliente — a janela da GDPR é 72 horas, e vão verificar que você sabe disso. Qual foi o último incidente, e o que você fez.
9. Lista de subprocessadores. Cada terceiro com quem seu software conversa: nome, país, propósito, status do DPA. Sim, incluindo o widget de chat SaaS no seu site de marketing. O advogado do revisor vai achar se você não achar.
10. Workflow de deleção. O cliente pede para ser esquecido. Qual o caminho? Banco, embeddings, prompts em cache, logs, backups. Com prazo documentado. "Em até 30 dias" serve. "A gente vê" não.
11. Histórico de vendor security review. Já passou por um antes? Pode compartilhar o resultado? A maioria das startups não passou. O revisor respeita honestidade. "É o nosso primeiro" serve. "Passamos no SOC 2 da AWS" quando não passou é fatal.
12. Data residency. Onde fisicamente vivem os dados do cliente. Cliente da UE? Provavelmente precisa ficar na UE. Healthcare nos EUA? Provavelmente precisa de regiões HIPAA-compatíveis. Se a resposta é "AWS us-east-1, porque é onde sempre faço deploy" — o deal para aqui.
Onze itens teriam salvado meu deal de fevereiro. O décimo segundo — data residency — foi o assassino de verdade. Eu não tinha região na UE. O cliente era um fabricante alemão. Não podiam assinar mesmo que tudo o resto estivesse perfeito.
A lição não foi jurídica. A lição foi que entreguei um produto que funcionava lindo para mim mas não sobrevivia a quinze minutos de conversa com um time de segurança de verdade.
Se seu produto de IA vai chegar perto de um cliente B2B sério em 2026, rode esta checklist antes do demo, não depois — e definitivamente não quando o jurídico perguntar.
Agora construo essa camada para os clientes como parte do produto, não como sprint de pânico duas semanas antes do procurement. Vinte horas de trabalho: revisão arquitetural, questionário de segurança pré-preenchido, plano de fechamento dos buracos. O deal que sobrevive a esse review vale mais do que cinco demos que não.