Vibe coding y RGPD: qué obligaciones tienes si tu app trata datos personales

Por Kike Gandia · Co-Fundador y CEO, OSCP

El RGPD no pregunta cómo construiste la aplicación. Si trata datos personales de residentes en la UE —un nombre, un correo, una dirección IP—, las obligaciones son exactamente las mismas que si la hubieras desarrollado con un equipo de veinte personas. Y hay un matiz que sorprende a quien construye con IA: el reglamento exige seguridad "desde el diseño y por defecto", lo que significa que la configuración permisiva que trae un generador no es una excusa, es precisamente lo que la norma te pide cerrar.

Cuándo te aplica: casi siempre

Basta con que tu aplicación trate un dato que permita identificar a una persona, directa o indirectamente. Eso incluye lo evidente —nombre, correo, teléfono— y también lo que mucha gente no considera dato personal: la dirección IP, un identificador de dispositivo, o el contenido que un usuario sube si permite reconocerle.

No importa que seas autónomo, que la app sea gratuita, que tengas diez usuarios o que aún la llames MVP. Las excepciones del reglamento son estrechas y la actividad doméstica no cubre un producto que ofreces a terceros.

Tampoco te libra usar servicios de terceros. Si tu aplicación guarda datos en un proveedor cloud, tú sigues siendo el responsable del tratamiento y ese proveedor es tu encargado, con un contrato que debe existir por escrito.

Las cuatro obligaciones que más se incumplen

Base de legitimación. Necesitas una razón jurídica para tratar cada dato: consentimiento, ejecución de un contrato, interés legítimo u otra. "Lo pedí en el formulario porque el generador lo puso" no es una base de legitimación.

Minimización. Solo puedes tratar los datos necesarios para la finalidad. Las aplicaciones generadas tienden a lo contrario: el modelo crea tablas con campos de más porque parecían útiles. Cada campo que no usas es riesgo sin contrapartida.

Información al usuario. Una política de privacidad que diga de verdad qué recoges, para qué, dónde se aloja y con quién se comparte. Copiar una plantilla que no describe tu aplicación es, en sí mismo, un incumplimiento.

Seguridad del tratamiento. El artículo 32 exige medidas técnicas apropiadas al riesgo. Una base de datos accesible sin autenticación no las cumple, y es el fallo más común en aplicaciones generadas.

Qué pasa exactamente si se filtran los datos

Si hay una brecha que suponga un riesgo para los derechos de las personas afectadas, tienes 72 horas desde que la conoces para notificarla a la autoridad de control —la AEPD en España—. No desde que la resuelves: desde que la conoces.

Si el riesgo es alto, además hay que comunicárselo a los propios afectados, sin dilación indebida y en lenguaje claro.

Hay un detalle que juega en tu contra en este escenario concreto: cuando la filtración se produce porque la base de datos estaba accesible públicamente, no vas a poder acreditar que nadie accedió. Un acceso por la vía pública no deja el mismo rastro que una intrusión, y la carga de la diligencia recae en ti.

Y conviene documentar la evaluación aunque concluyas que no procede notificar. Esa documentación es exactamente lo que se pide después si alguien pregunta.

La relación con el AI Act, que es otra cosa

Se confunden a menudo y regulan cosas distintas. El RGPD regula el tratamiento de datos personales, con independencia de la tecnología. El AI Act regula los sistemas de inteligencia artificial según el uso al que se destinan.

Si usaste IA solo para escribir el código, el AI Act probablemente no te aplica: la herramienta fue un instrumento de desarrollo, no un sistema de IA que tú pongas en el mercado. Si tu aplicación incorpora IA —un chatbot, una clasificación automática, una recomendación— entonces sí entras, y con obligaciones que dependen del nivel de riesgo del uso.

El RGPD, en cambio, te aplica en los dos casos desde el primer dato personal que guardes.

Qué hacer, en orden

1. Inventaría qué datos guardas de verdad. Abre las tablas y mira. Casi siempre hay campos que nadie usa.
2. Borra lo que no necesites. Es la medida más barata y la que más riesgo elimina.
3. Comprueba que la capa de datos está cerrada. Sin eso, el artículo 32 no se cumple y lo demás es papel.
4. Escribe una política de privacidad que describa tu aplicación, no una plantilla genérica.
5. Firma los contratos de encargo con tus proveedores. La mayoría los ofrece firmados desde su panel.
6. Ten decidido qué harías ante una brecha antes de tenerla: a quién avisas y en qué plazo. Improvisar dentro de las 72 horas sale caro.

FAQ

Mi app es gratuita y no vendo datos, ¿me aplica el RGPD igual?

Sí. El reglamento no distingue por modelo de negocio ni por si hay ánimo de lucro: se activa con el tratamiento de datos personales, lo cobres o no. Lo que sí modula el reglamento es la proporcionalidad de las medidas, no su exigibilidad: se te pedirán medidas apropiadas al riesgo de tu tratamiento, no las de una multinacional.

Uso un proveedor cloud, ¿la responsabilidad no es suya?

No. Tú decides qué datos se tratan y para qué, así que eres el responsable del tratamiento; el proveedor es encargado y responde de lo que tú le encargas, bajo contrato. Si dejaste la base de datos accesible, la responsabilidad es tuya aunque la infraestructura sea de un tercero: la configuración de acceso es decisión tuya, no suya.

¿Necesito registrar la aplicación en la AEPD?

No existe un registro previo de ficheros desde 2018. Lo que sí tienes es la obligación de mantener un registro interno de actividades de tratamiento, con excepciones para organizaciones de menos de 250 empleados que en la práctica casi nunca aplican, porque decaen si el tratamiento no es ocasional o incluye categorías especiales de datos.