Desarrollo con IA, seguridad y cumplimiento: RGPD, SOC 2 y PCI DSS en la práctica

Una IA escribió el código, así que ¿quién responde cuando trata mal datos personales? Tú. El uso de una herramienta de IA no elimina las obligaciones de cumplimiento: su distribución concreta depende del marco aplicable, del tratamiento realizado y de las funciones del producto, pero el RGPD, PCI DSS y SOC 2 no dejan de aplicarse por el hecho de que el código lo haya generado o asistido una IA.

Ese único hecho es el que más malinterpretan quienes compran y quienes venden desarrollo asistido por IA. La velocidad es real, pero no cambia ninguna de las reglas. Lo que sigue recorre los tres marcos que una empresa en crecimiento encuentra con más frecuencia, qué exige de verdad cada uno y por qué "lo escribió la IA" no es una defensa que acepte ningún regulador ni auditor. Léelo como guía de evaluación de proveedores, no como asesoramiento jurídico; confirma los detalles con tu propio asesor legal o delegado de protección de datos (DPO). Para el lugar que ocupa el cumplimiento en la práctica más amplia, empieza por el vibe coding y el desarrollo asistido por IA.

La regla que ningún prompt esquiva

Las regulaciones regulan resultados, no autorías. Cuando tu software guarda la dirección de un cliente, procesa el pago de una tarjeta o gestiona expedientes de personal, la obligación recae sobre ti como operador de ese software, sea quien sea o lo que sea que produjera el código.

Esto importa más con la IA de por medio, no menos, porque el código de IA sin revisar falla justo por las vías que los marcos de cumplimiento existen para prevenir. En el informe 2025 de seguridad del código generativo de Veracode, el 45 % de las muestras evaluadas introdujo vulnerabilidades de seguridad detectables en las pruebas; el resultado pertenece a ese protocolo de prueba y no debe extrapolarse como una tasa universal de todo el código generado por IA. Una validación de entrada ausente o una credencial escrita en el código es un fallo en cualquier base de código. En una que trata datos personales o de pago, ese mismo fallo es un incumplimiento con un plazo de notificación y una multa detrás. La velocidad de generación no reduce esa exposición; saltarse la revisión la ensancha.

RGPD: el marco que casi todas las empresas encuentran primero

El Reglamento General de Protección de Datos (RGPD) puede aplicarse a cualquier software que trate datos personales de personas en la UE aunque el negocio esté fuera de ella, cuando se cumplan las condiciones de ámbito territorial del artículo 3. Si tu aplicación guarda nombres, correos, direcciones o comportamiento, el RGPD se aplica, y usar una IA para construirla no cambia nada de eso. En España lo desarrolla la LOPDGDD y lo vigila la Agencia Española de Protección de Datos (AEPD).

Dos obligaciones moldean cómo hay que construir el software. Primera, protección de datos desde el diseño y por defecto: la seguridad y la privacidad se tienen que diseñar desde el principio, no añadir con calzador después de publicar. La AEPD explica que esta protección debe integrarse antes del inicio del tratamiento y mantenerse durante todo su ciclo de vida. El código de IA sin revisar suspende esta prueba de forma estructural, porque nadie decidió cómo se protegerían los datos personales; el modelo se limitó a producir algo que funcionaba. Segunda, notificación de brechas. Según el artículo 33, una brecha de datos personales que entrañe un riesgo para los derechos y libertades de las personas debe notificarse a la autoridad de control sin dilación indebida y, de ser posible, en un plazo de 72 horas, explicando los motivos del retraso si ese plazo no se cumple (Reglamento (UE) 2016/679, artículo 33: Notificación de una violación de la seguridad de los datos personales a la autoridad de control). Una base de código que nadie entiende vuelve brutal ese plazo: no puedes notificar lo que pasó si nadie sabe leer el código para averiguarlo.

El listón se puso alto a propósito. Para las infracciones más graves, las multas del RGPD llegan hasta 20 millones de euros o el 4 % de la facturación anual mundial total, la mayor de las dos cifras (Reglamento (UE) 2016/679, artículo 83). La forma de mantenerse lejos de eso es poco vistosa: datos personales tratados con intención, por código que una persona revisó, con los flujos de datos documentados lo bastante bien como para responder a las preguntas de un regulador.

PCI DSS: en cuanto tocas pagos con tarjeta

El estándar de seguridad de datos del sector de las tarjetas de pago (PCI DSS) está dirigido a las entidades que almacenan, procesan o transmiten datos de titulares de tarjeta, así como a las que pueden afectar a la seguridad del entorno de datos de tarjetas, con independencia del tamaño (PCI Security Standards Council). Una organización pequeña que almacena, procesa o transmite datos de titulares de tarjeta puede quedar dentro del ámbito de PCI DSS; el alcance y las obligaciones de validación dependen también del entorno de pagos y de los programas del adquirente o de las marcas. PCI DSS v4.0.1 es la única versión activa respaldada por el PCI SSC desde la retirada de la v4.0 el 31 de diciembre de 2024, y la fecha de efectividad de los nuevos requisitos siguió siendo el 31 de marzo de 2025 (PCI SSC), así que no queda ninguna prórroga en la que apoyarse.

Los requisitos del estándar se leen como una lista de comprobación que el código de IA sin revisar suspende punto por punto: cifra los datos de la tarjeta, restringe quién puede acceder a ellos, prueba la seguridad con regularidad, registra y supervisa los accesos. Nada de eso ocurre por sí solo en un pago hecho con vibe coding. La arquitectura más segura es también la más simple de cumplir: no guardes tú los datos de la tarjeta en absoluto. Encamina los pagos a través de una pasarela de pago conforme, de modo que los datos de la tarjeta nunca toquen tu base de datos, lo que reduce tu ámbito PCI a la integración en lugar del sistema entero. Es una decisión de diseño deliberada que toma una persona, y es justo la clase de decisión que se salta cuando nadie revisa la construcción. También es la razón por la que los flujos de pago son una zona de revisión intensiva en nuestro trabajo de desarrollo ecommerce a medida.

SOC 2: cuando son tus clientes quienes te auditan

Antes de SOC 2, conviene situar la referencia europea, porque es la que un comprador español encuentra primero. La ISO 27001 y la certificación del Esquema Nacional de Seguridad (ENS) son los sellos de seguridad que un cliente o una administración españoles pedirán ver, cada uno con su organismo, su número y su fecha de caducidad.

SOC 2 es distinto en naturaleza. No es una ley ni una certificación pública. Es un marco de auditoría del Instituto Americano de Contadores Públicos Certificados (AICPA), construido sobre cinco Trust Services Criteria: seguridad, disponibilidad, integridad del tratamiento, confidencialidad y privacidad (AICPA). El AICPA define estos criterios de control para su uso en trabajos de atestación o consultoría, precisamente el tipo de evaluación que un auditor independiente aplica al examinar tus controles y emitir su informe. SOC 2 no se "aprueba"; recibes un informe que tus clientes, normalmente empresas más grandes que evalúan a un proveedor, leen antes de confiarte sus datos. Un comprador español se topa con él sobre todo al tratar con un proveedor SaaS estadounidense o al venderle a uno.

Para un negocio de software en crecimiento, cualquiera de estos informes suele llegar como requisito de venta: un cliente grande no firmará hasta que puedas enseñarlo. Llegar ahí descansa sobre el mismo cimiento que los otros dos marcos. Necesitas controles que existan de verdad, pruebas de que funcionan y una base de código cuyo comportamiento una persona pueda avalar. Una atestación construida sobre salida de IA sin revisar es una atestación construida sobre arena, porque en cuanto un auditor pregunta cómo se aplica un control en el código, alguien tiene que ser capaz de leer el código y responder.

Lo que une a los tres: una persona que leyó el código

Los tres marcos parecen distintos sobre el papel y descansan sobre el mismo cimiento por debajo. Cada uno da por supuesto que una persona puede explicar cómo trata el software los datos sensibles, demostrar que un control está realmente en su sitio y arreglar un problema cuando aparece. Todas esas suposiciones se rompen en el instante en que el código está sin leer.

Por eso la revisión no es un adorno de cumplimiento, sino la práctica que sostiene el peso. Un ingeniero sénior leyendo cada línea es lo que convierte "la aplicación parece funcionar" en "sabemos por dónde fluyen los datos personales, dónde no van los datos de tarjeta y qué control aplica qué requisito". Cubrimos qué caza esa revisión en la revisión humana del código generado por IA, y el instrumental de seguridad alrededor, el análisis de dependencias en cada build y lo demás, en cómo aseguramos cada construcción. El punto para el cumplimiento es estrecho y firme: no puedes certificar, notificar ni defender un código que nadie ha leído.

Qué preguntarle a un proveedor de desarrollo con IA sobre el cumplimiento

Antes de las preguntas, sitúa el resto del marco legal español, porque delimita la conversación. Por encima del RGPD está el Reglamento europeo de Inteligencia Artificial (AI Act), el Reglamento (UE) 2024/1689, y aquí conviene deshacer una confusión que sale cara: regula los sistemas de IA que se comercializan o se ponen en servicio, no el hecho de que un software se escribiera con ayuda de IA, según la síntesis oficial de la Unión Europea sobre normas para una IA fiable. Si el producto que te entregan incorpora funciones de IA, su categoría de riesgo decide tus obligaciones; en España, la supervisión y aplicación del Reglamento de IA se distribuyen entre las autoridades competentes según el sistema, el sector y la materia, y la Agencia Española de Supervisión de la Inteligencia Artificial (AESIA) es una de las instituciones relevantes, por lo que conviene comprobar la asignación competencial vigente. Si tu software se escribió con IA pero no contiene IA, el Reglamento no te alcanza por esa vía. Suma el ENS (Real Decreto 311/2022) si vas a trabajar con el sector público o para él, y la Directiva NIS2 si operas en un sector esencial o importante, donde la seguridad de la cadena de suministro alcanza también al software a medida que encargas.

Con el marco sobre la mesa, lleva estas preguntas a una llamada de alcance y escucha los detalles concretos.

• ¿Quién responde del cumplimiento en el contrato? La respuesta honesta te nombra a ti como responsable del tratamiento y al proveedor como encargado con obligaciones definidas, no una promesa vaga de que "todo cumple".
• ¿Cómo se tratan los datos personales en la arquitectura? Quieres un flujo de datos descrito, no una tranquilización. ¿Dónde se guardan los datos, quién puede llegar a ellos y qué se registra?
• ¿Llegan los datos de tarjeta a tocar la base de datos? Para cualquier cosa con pagos, la respuesta correcta suele ser no, con una pasarela conforme nombrada.
• ¿Quién revisa el código, y puede responder a las preguntas de un regulador o un auditor sobre él? Si ninguna persona puede leer la base de código y explicar un control, ninguna certificación construida sobre él vale nada.
• ¿Adónde van mis datos cuando la IA genera el código? El proveedor envía tu base de código, y a veces tus datos, a un modelo alojado en algún sitio. Pregunta en cuál, bajo qué condiciones, y si tus datos de producción llegan a transitar por él.

Y desconfía del "cumplimos el RGPD" enarbolado como un sello: no debe confundirse el cumplimiento del RGPD con una certificación única y universal que se exhiba a demanda como un ISO 27001, aunque pueden existir mecanismos de certificación y sellos acreditados para operaciones concretas, conforme a los artículos 42 y 43 del RGPD. El RGPD es una obligación legal, no un trofeo. Nuestro circuito completo de construcción, del alcance escrito a la entrega revisada, está documentado en cómo definimos el alcance, construimos y revisamos, y está montado para que estas preguntas tengan respuestas claras.

Preguntas frecuentes

¿El código generado por IA cumple el RGPD?

No por defecto, y el cumplimiento del RGPD nunca es una propiedad del código a solas. Depende de cómo trata el software los datos personales: protección diseñada desde el principio, flujos de datos documentados y controles que una persona pueda avalar. La IA puede generar código conforme una vez que un ingeniero lo revisa y lo verifica.

¿Usar IA para construir software elimina mis obligaciones de cumplimiento?

No. El uso de una herramienta de IA no elimina las obligaciones de cumplimiento; su distribución concreta depende del marco aplicable, del tratamiento realizado y de las funciones del producto. El hecho de que el código haya sido generado o asistido por IA no modifica por sí solo los requisitos del RGPD, PCI DSS o SOC 2, aunque el alcance de cada marco debe analizarse por separado. "Lo escribió la IA" no es una defensa que acepte ningún regulador ni auditor.

¿Tengo que cumplir PCI DSS si la IA construyó mi pago?

Sí, si el software almacena, procesa o transmite datos de titulares de tarjeta, con independencia de quién lo construyó o cómo. La vía de menor riesgo es encaminar los pagos por una pasarela conforme para que los datos de tarjeta nunca toquen tu base de datos, lo que reduce tu ámbito PCI a la integración.

¿Puede un software hecho con vibe coding pasar una auditoría SOC 2?

Solo si los controles detrás existen de verdad y alguien puede demostrar que funcionan. SOC 2 es una atestación independiente, no una casilla que marcar. La organización debe poder demostrar que sus controles están diseñados e implementados y aportar evidencias; un código sin comprender puede dificultar esa demostración cuando un auditor pregunta cómo se aplica un control, aunque no permite afirmar automáticamente que toda atestación fracasará.

¿Cuál es el mayor riesgo de cumplimiento con el código de IA sin revisar?

Que un fallo de seguridad que el modelo copió de sus datos de entrenamiento, presente en una proporción relevante de las muestras del estudio de Veracode de 2025 (45 % en ese protocolo de prueba), salga a un software que trata datos personales o de pago. Un fallo se vuelve una brecha con un plazo de notificación de 72 horas y una multa, en vez de un comentario cazado en la revisión.

¿Cómo gestiona Globaprom el cumplimiento en las construcciones asistidas por IA?

Los requisitos de cumplimiento se acotan y se presupuestan por adelantado, los flujos de datos personales y de pago se diseñan con intención, y un ingeniero sénior revisa cada línea para que los controles se puedan demostrar. No somos tu asesor legal, así que trabajamos junto a tu abogado o tu DPO, no en su lugar.

Constrúyelo conforme desde el primer commit

El cumplimiento es más barato y más seguro cuando forma parte del diseño desde el principio, no cuando se descubre tras la publicación. Cuéntanos qué regulaciones tiene que cumplir tu software y lo acotaremos de forma explícita, construiremos con cada línea revisada y te entregaremos una base de código que puedas defender de verdad ante un regulador o un auditor.

Pide un presupuesto cerrado →