Construí tres asistentes de IA. Dos de ellos habrían filtrado datos de clientes
Tres POCs en seis meses. Dos sin arquitectura de privacidad. Qué habría pasado el día que entraran en producción — y el test de cinco preguntas que ahora paso antes de cualquier demo.
En los últimos seis meses entregué tres POCs de asistente de IA. Una herramienta interna para el equipo de ventas, un copiloto para soporte, un Q&A sobre documentos de procurement. Los tres demos salieron bonitos. Los clientes quedaron contentos. Dos de ellos habrían filtrado datos de clientes el primer día en producción.
Quiero hablar de los agujeros concretos, porque veo la misma forma de error en uno de cada dos POCs de IA que me llegan para revisión.
El patrón es siempre el mismo. El founder quiere IA. El founder contrata a un vibe-coder (a veces yo, antes de aprender). El vibe-coder entrega en dos semanas. La cosa funciona. El founder dice "lanzamos." El abogado dice "espera."
Esto es lo que entregué y dónde tenía cada uno el agujero.
Asistente nº 1 — sales copilot. Leía notas de ventas en Notion, generaba borradores de follow-up, los escribía de vuelta al CRM. Funcionaba precioso. Tres problemas que solo vi al releer con atención:
- Las notas contenían nombres de clientes, teléfonos y valores de contrato. Todo eso iba a la API de OpenAI en cada request. El DPA del cliente con sus propios clientes no lo permitía. Estábamos a un screenshot de una demanda real.
- Sin audit trail. Si un usuario final preguntaba "¿qué datos míos vio tu IA?", no podíamos responder. No "no queremos" — no podíamos.
- Los logs de todas las respuestas del modelo vivían en un VPS en texto plano. Retención por defecto: para siempre. Nadie decidió otra cosa. Nadie lo pensó.
Asistente nº 2 — support copilot. Sugería respuestas a tickets de soporte. El tutorial de vibe-coding dice: pasa el ticket completo más el historial del cliente. Eso hicimos. El historial tenía direcciones, mensajes de pago fallido y un caso que prefiero no describir por escrito. Todo fue al LLM. Al cliente no le dijimos.
Asistente nº 3 — procurement Q&A. Este lo construí después, y lo construí bien. Dos capas — un PII scrubber a la entrada, una capa de redaction a la salida — audit trail de cada prompt y respuesta con retención de 30 días, y SSO con acceso por rol: el equipo legal veía todo, el equipo de procurement solo sus propias consultas.
La diferencia entre el nº 3 y los otros no fue habilidad en IA. Cuando lo construí, ya había entendido que la IA es la parte fácil. La fontanería alrededor de la IA es la parte que decide si vendes esto a un enterprise de verdad o pasas seis meses rehaciéndolo la semana antes del cierre.
Este es el test que ahora paso a cada asistente de IA antes de permitir el demo.
A dónde van los datos. ¿Qué campos salen de tu servidor y acaban en los logs del proveedor de LLM? Tienes que poder apuntar al prompt template y decir "este campo, este campo, este no." Si no puedes, no estás listo.
Qué se loguea. Cada prompt. Cada respuesta. Con timestamps, IDs de usuario y una política de retención que has escrito en algún sitio. Si el CTO responde "logueamos todo en CloudWatch" — eso no es audit trail, es cementerio.
Quién ve qué. Acceso por rol en la propia interfaz de la IA, no solo en la base. El becario no debería poder consultar el hilo del CEO. El agente de soporte no debería poder sacar la hoja de salarios.
Qué pasa al borrar. Cuando el cliente pide ser olvidado, ¿puedes olvidarlo de verdad — no solo en la base, sino en los embeddings, en los prompts cacheados, en los logs, en los backups? Si la respuesta empieza con "técnicamente…" — empieza de nuevo.
Qué le prometiste al cliente. El DPA, la política de privacidad, el consentimiento. Ninguno de estos documentos es primero una cuestión jurídica antes de ser una cuestión de ingeniería. El ingeniero que construye la capa de datos tiene que saber qué se prometió.
Cuento esta historia porque la conversación sobre AI compliance en 2026 ocurre casi entera en el extremo equivocado. Todo el mundo compra plantillas de política GDPR/IA a despachos de abogados. Casi nadie construye la capa de datos que hace esas políticas reales.
Un abogado no resuelve por ti el compliance de tu asistente de IA. Un abogado solo dice qué prometiste. Quien cumple la promesa es la arquitectura — qué sale, qué se loguea, qué se enmascara, qué se borra, quién tiene acceso, qué audit trail lo demuestra.
Hago este trabajo como servicio. Ingeniería, no asesoría legal. Mapa del flujo de datos en la IA. Marcado de campos PII. Scrubber, audit trail, política de retención, modelo de acceso. Convertir las promesas GDPR/LGPD/DPA en verdad, no solo en firma.
No es el trabajo más emocionante de 2026. Es el trabajo que impide que el trabajo emocionante de IA se convierta en escándalo nueve meses después.
Si estás lanzando un asistente de IA y las respuestas a las cinco preguntas de arriba te incomodan, hablemos.