Un vendor security review me mató el deal. La checklist de 12 puntos que ahora corro antes del demo
En febrero perdí un deal de cuatro meses por un cuestionario de seguridad de 64 preguntas. Aquí está la checklist que escribí después — y el punto que fue el verdadero asesino del deal.
En febrero perdí un deal en el que había trabajado cuatro meses. El trabajo estaba hecho. El contrato estaba sobre la mesa del abogado. Entonces apareció el equipo de seguridad del cliente.
Mandaron un cuestionario de vendor security review con 64 preguntas. Ocho las respondí bien, doce las respondí mal y cuarenta y cuatro tuve que inventar la respuesta en tiempo real, porque nadie de nuestro lado se había hecho esas preguntas antes.
Tres semanas de email tennis después, el deal murió. La nota de procurement decía: "supplier unable to meet our minimum data-handling standards." Nada personal. Solo verdad.
Volví a casa, abrí el cuestionario y reescribí toda la infraestructura contra él. Aquí está la checklist que salió de esa bofetada.
Esta lista no es asesoría legal. Son las preguntas que un equipo de procurement o seguridad de enterprise realmente hace antes de firmar contigo. La mayoría no tiene nada que ver con el texto de la GDPR y todo que ver con cómo está construido el software.
1. Mapa de flujo de datos. Dibuja el diagrama. El cliente ingresa X. Va a tu servidor. De tu servidor va a A, B, C — servicios de terceros, proveedor de LLM, analytics. Cada flecha en el diagrama. Si no puedes dibujarlo, ningún enterprise te compra.
2. Inventario de PII. En cada campo de cada formulario: cuál es personalmente identificable, cuál es sensible, cuál no es ninguno de los dos. El revisor pedirá esa lista. La cruzará con el código. Las inconsistencias matan deals.
3. Política de datos en LLM. Qué va a OpenAI / Anthropic / Google, qué se loguea, qué puedes probar con screenshots de la consola del proveedor. "Usamos la API en modo privado" no es respuesta — muestra el ajuste y el contrato.
4. Audit trail. Quién hizo qué y cuándo — quién inició sesión, quién exportó datos, quién borró un registro. Todo con timestamps y una política de retención que has escrito en algún sitio. Audit trail sin retención es solo un archivo que crece hasta caerse.
5. Modelo de acceso. Roles, permisos, rutas de escalada. Dónde se exige MFA. Dónde no — y por qué. Si la respuesta es "todos en la empresa tienen admin", fallas el review en esa línea.
6. Cifrado — en reposo y en tránsito. TLS en transporte, AES-256 en disco, política de rotación de claves. Cifrado de disco en el servidor. Claves fuera del repo. Sí, también en el entorno de dev.
7. Backups y recuperación. Dónde viven los backups. Cuánto tiempo se guardan. Cuánto tarda restaurar. El revisor quiere números de RPO y RTO, no "tenemos backups."
8. Respuesta a incidentes. Qué pasa cuando algo se filtra. Quién llama a quién. En cuánto tiempo notificas al cliente — la ventana de la GDPR es 72 horas, y comprobarán que lo sabes. Cuál fue el último incidente, y qué hiciste.
9. Lista de subprocesadores. Cada tercero con el que tu software habla: nombre, país, propósito, estado del DPA. Sí, incluido el widget de chat SaaS en tu sitio de marketing. El abogado del revisor lo encontrará si tú no.
10. Flujo de borrado. El cliente pide ser olvidado. ¿Cuál es el camino? Base, embeddings, prompts en caché, logs, backups. Con plazo documentado. "En 30 días" sirve. "Ya veremos" no.
11. Historial de vendor security review. ¿Has pasado uno antes? ¿Puedes compartir el resultado? La mayoría de las startups no han pasado. El revisor respeta la honestidad. "Es el primero" sirve. "Pasamos SOC 2 de AWS" cuando no lo pasaste es fatal.
12. Data residency. Dónde viven físicamente los datos del cliente. ¿Cliente de la UE? Probablemente tiene que quedarse en la UE. ¿Healthcare en EE.UU.? Probablemente necesita regiones HIPAA-compatibles. Si la respuesta es "AWS us-east-1 porque es donde siempre hago deploy" — el deal se detiene ahí.
Once puntos habrían salvado mi deal de febrero. El duodécimo — data residency — fue el asesino real. No tenía región en la UE. El cliente era un fabricante alemán. No podían firmar aunque todo lo demás fuera perfecto.
La lección no fue jurídica. La lección fue que entregué un producto que funcionaba precioso para mí pero no sobrevivía a quince minutos de conversación con un equipo de seguridad de verdad.
Si tu producto de IA va a acercarse a un cliente B2B serio en 2026, pasa esta checklist antes del demo, no después — y definitivamente no cuando el área legal pregunte.
Ahora construyo esta capa para los clientes como parte del producto, no como sprint de pánico dos semanas antes del procurement. Veinte horas de trabajo: revisión arquitectural, cuestionario de seguridad pre-rellenado, plan de cierre de los agujeros. El deal que sobrevive a este review vale más que cinco demos que no.