Nota a cuatro manos: esta la firmo yo, Vanina Morrone. Soy analista funcional y abogada. Cuando Virginia construye un sistema —sobre todo si lleva IA dentro, toca datos personales o automatiza decisiones— yo soy el último filtro antes del despliegue. Estas son las cosas que reviso. Sirven como checklist interno nuestro, pero también como guía para cualquiera que esté por lanzar un sistema parecido.

Por qué un desarrollador, por muy senior que sea, necesita un filtro legal

No porque programe mal. Porque el derecho y la ingeniería resuelven problemas distintos. Un sistema puede funcionar perfecto, estar bien arquitecturado y cumplir todos los tests, y aun así ser ilegal o exponerte a una sanción. Algunos ejemplos reales —anonimizados— que he visto:

• Un chatbot con IA entrenado a partir de conversaciones reales de atención al cliente, sin consentimiento y sin anonimizar los datos personales que aparecían dentro.
• Un sistema de scoring automático que rechazaba solicitudes sin dejar a la persona pedir revisión humana —algo que el RGPD prohíbe literalmente.
• Una API pública que devolvía, sin querer, datos de usuarios de la empresa al responder errores con demasiado detalle.
• Un sistema con IA cuyas decisiones no quedaban registradas en ningún log: imposible auditarlas cuando un afectado reclamó.

Ninguno de estos problemas es un bug en el sentido clásico. Son decisiones de diseño que un ingeniero no necesariamente considera si no tiene a alguien al lado mirando el mismo código con otros ojos.

Mi checklist antes de que un sistema con IA pase a producción

1. Bases legales del tratamiento de datos

Si el sistema procesa datos personales —y con IA casi siempre los procesa— necesito saber:

• Qué base legal aplicamos (consentimiento, contrato, interés legítimo, obligación legal). Cada una tiene consecuencias distintas.
• Dónde y cómo se informa a la persona de ese tratamiento. El aviso de privacidad no es decorativo: tiene que ser claro, específico y accesible.
• Si hay transferencias internacionales de datos (casi siempre las hay cuando usamos APIs de OpenAI, Anthropic u otros proveedores en EE. UU.) y si están bien amparadas.

2. Datos que salen del sistema al proveedor de IA

Esta parte la veo olvidada más veces de lo que me gustaría. Cuando mandamos un prompt a Claude o a OpenAI, le estamos enviando datos. Pregunto:

• ¿Qué datos concretos salen del sistema hacia el proveedor?
• ¿Están mínimamente anonimizados lo que no hace falta que vaya identificado?
• ¿El plan del proveedor garantiza que no se usen para entrenar modelos? Los planes API de Claude y OpenAI sí lo garantizan. Los gratuitos y de usuario final, no siempre.
• ¿Tenemos firmado el acuerdo de encargo de tratamiento (DPA) con el proveedor?

3. Decisiones automatizadas y revisión humana

El RGPD (art. 22) tiene una regla simple y muy ignorada: una persona tiene derecho a no ser objeto de decisiones únicamente automatizadas con efectos significativos. Eso no significa que la IA no pueda decidir, significa que:

• La persona tiene que saber que hay una decisión automática.
• Tiene que poder pedir revisión humana, y eso tiene que estar implementado de verdad, no en una página de "contáctanos".
• La empresa tiene que poder explicar qué criterios usó la decisión —aunque vengan de una IA.

Si un sistema con IA toma decisiones relevantes (admisiones, créditos, priorizaciones, recomendaciones con peso), reviso que estas tres cosas estén cubiertas. Sin ellas, no sale.

4. Trazabilidad y logs

Un sistema con IA tiene que poder responder a la pregunta "¿por qué le dijiste esto a esta persona?" tres meses después. Eso significa:

• Logs de cada decisión automatizada: qué entró, qué salió, qué modelo, qué versión.
• Retención coherente: ni infinita ni demasiado corta. Lo mínimo que me permita auditar y ejercer derechos de los afectados.
• Acceso controlado a esos logs. No sirve que existan si cualquiera los puede consultar o si se pierden al primer reinicio.

5. Sesgo y evaluación del modelo

Sobre todo cuando el sistema toma decisiones sobre personas (clasificación de candidatos, priorización de clientes, moderación de contenidos), reviso que haya:

• Un plan de evaluación del modelo antes de pasar a producción, con datasets que incluyan casos límite.
• Métricas de calidad separadas por grupos cuando hay riesgo de sesgo (edad, género, origen). Si el modelo acierta el 95% en general pero el 70% en un subgrupo, hay problema aunque la media sea buena.
• Un proceso para corregir si aparecen problemas después.

6. Accesibilidad

Esto se olvida casi siempre en sistemas B2C. La Directiva europea 2019/882 (European Accessibility Act) obliga desde junio de 2025 a que muchos servicios digitales cumplan estándares de accesibilidad WCAG. No es un "bonus de usabilidad": es obligatorio para bancos, comercio electrónico, transporte, comunicaciones y más. Reviso que el sistema sea usable con lector de pantalla, navegable con teclado y con contrastes adecuados.

7. Derechos de las personas afectadas

RGPD da a cualquier persona derechos concretos: acceso, rectificación, supresión, oposición, portabilidad. Si el sistema no tiene una forma clara y operativa de atender esos derechos, es un problema esperando a pasar. Reviso que:

• Hay un procedimiento documentado (no solo un email genérico).
• Técnicamente se puedan ejecutar en un plazo razonable.
• Los datos se puedan borrar de verdad, no solo marcar como inactivos.

8. Contrato con el cliente

Si el sistema se entrega a un cliente, reviso que el contrato refleje la realidad de lo que estamos haciendo con datos, con IA y con qué responsabilidades. Sobre todo en proyectos B2B de cierto tamaño, un contrato genérico "de desarrollo web" ya no sirve.

Qué NO es mi trabajo

Para que quede claro y no se malinterprete:

• No soy asesora legal externa. Para eso, el cliente contrata un despacho, y muchas veces recomendamos nosotras.
• No firmo cumplimiento, no emito dictámenes. Mi revisión es interna, para que Virginia no despliegue algo que obviamente no debería salir como está.
• No sustituyo un DPO (Delegado de Protección de Datos) cuando el cliente lo necesita.

Por qué lo contamos

Porque esta parte del trabajo —la que hace que un sistema no solo funcione sino que esté bien hecho en sentido amplio— rara vez se ve en el presupuesto ni en la demo. Pero es la que evita que tres meses después de desplegar, alguien llame diciendo que ha llegado una reclamación, una inspección o una queja en la AEPD.