RGPD y Ley de IA de la UE para SaaS en DACH: marco actual de planificación

Si vendes SaaS en DACH y utilizas IA, pueden aplicarse tanto el RGPD como la Ley de IA de la UE, pero no todos los controles corresponden a todas las funciones. Empieza por el caso de uso, el tratamiento de datos personales y tu papel en la cadena de valor de la IA. Según el calendario actual de aplicación de la Comisión Europea, la transparencia del artículo 50 se aplica desde el 2 de agosto de 2026, los requisitos para sistemas de alto riesgo del anexo III desde el 2 de diciembre de 2027 y los requisitos para sistemas de alto riesgo integrados en productos regulados del anexo I desde el 2 de agosto de 2028. Los responsables jurídicos y de gobernanza confirman el análisis; los equipos de producto e ingeniería generan las pruebas pertinentes para el sistema.

Esta es una perspectiva de ingeniería, no asesoramiento jurídico. Hemos entregado funciones de IA para clientes de DACH bajo el RGPD y hemos ajustado proyectos activos al calendario de la Ley de IA.

¿Cuál es el calendario de aplicación que debo planificar?

La Ley de IA se aplica por etapas. Las fechas relevantes dependen del papel y del sistema:

• 2 de febrero de 2025. Se aplican las prácticas prohibidas (art. 5) y la obligación de alfabetización en IA (art. 4).
• 2 de agosto de 2025. Empezaron a aplicarse las disposiciones de gobernanza y las obligaciones para proveedores de modelos de IA de uso general, con reglas transitorias para modelos anteriores.
• 2 de agosto de 2026. Las obligaciones del artículo 50 se aplican a determinadas interacciones con IA y a contenido generado o manipulado.
• 2 de diciembre de 2027. Comienzan a aplicarse los requisitos para sistemas de alto riesgo del anexo III conforme al calendario del Ómnibus de IA.
• 2 de agosto de 2028. Comienzan a aplicarse los requisitos para IA de alto riesgo integrada en productos regulados del anexo I.

La supervisión del RGPD depende de la jurisdicción y del contexto del tratamiento. Alemania cuenta con autoridades federales y regionales; Austria tiene la Datenschutzbehörde. La aplicación de la Ley de IA recae principalmente en las autoridades nacionales competentes de vigilancia del mercado, mientras que la Oficina de IA y el Supervisor Europeo de Protección de Datos son responsables en ámbitos definidos. Confirma la autoridad competente en vez de asumir que un regulador concreto revisa cada SDLC.

¿Mi función de IA es de alto riesgo según el anexo III?

El anexo III abarca usos específicos en biometría, infraestructuras críticas, educación, empleo, servicios esenciales, aplicación de la ley, migración, justicia y procesos democráticos. Importan la finalidad exacta y las condiciones. Algunos ejemplos son determinados sistemas de selección de currículos, supervisión de trabajadores y evaluación de solvencia, pero ni una etiqueta sectorial ni el mero uso de IA deciden la clasificación. Consulta el proyecto actual de directrices de la Comisión sobre sistemas de alto riesgo junto con el texto legal y comprueba si se publican directrices finales posteriores.

1. ¿La finalidad prevista encaja en una categoría del anexo I o III y cumple sus condiciones? Si no, evalúa otras obligaciones de la Ley de IA y del RGPD en vez de asumir que solo queda el artículo 50.
2. Para el anexo III, ¿el artículo 6.3 excluye el sistema porque no presenta un riesgo significativo y cumple una condición enumerada? Los sistemas de elaboración de perfiles no reciben esa exclusión. Documenta la evaluación y comprueba cualquier deber de registro.
3. Si el sistema es de alto riesgo, asigna las obligaciones específicas del proveedor, responsable del despliegue y demás papeles. El conjunto completo de controles del proveedor no corresponde automáticamente a cada responsable del despliegue de un SaaS.

¿Qué pruebas pueden necesitar los equipos de desarrollo y gobernanza?

No existe una lista universal de nueve artefactos que sean responsabilidad de ingeniería. La aplicabilidad y la rendición de cuentas dependen del papel, el tratamiento y la clasificación del sistema. Un mapa práctico de pruebas puede incluir:

1. Registros de actividades de tratamiento cuando los exija el artículo 30 del RGPD, respaldados por registros actualizados de flujos de datos y sistemas.
2. Una EIPD cuando sea probable que el tratamiento genere un alto riesgo para los derechos y libertades de las personas conforme al artículo 35 del RGPD.
3. Documentación técnica del anexo IV cuando la empresa tenga la obligación correspondiente como proveedora de un sistema de alto riesgo.
4. Registros adecuados al papel y al sistema aplicables según la Ley de IA. La regla de seis meses del artículo 19 se refiere a los registros generados automáticamente por un sistema de alto riesgo mientras estén bajo el control del proveedor, salvo que otra norma disponga algo distinto.
5. Medidas de supervisión humana para los sistemas de alto riesgo aplicables, incluidas personas competentes, autoridad y controles utilizables.
6. Avisos del artículo 50 o marcado legible por máquina para las interacciones y categorías de contenido cubiertas por la disposición.
7. Material sobre contenido de entrenamiento y política de derechos de autor para IA de uso general cuando la empresa sea realmente proveedora de un modelo de este tipo, no solo porque utilice ajuste fino.
8. Un flujo de trabajo para incidentes graves de proveedores de sistemas de alto riesgo que refleje los plazos de dos, diez y quince días del artículo 73.
9. Seguimiento posterior a la comercialización cuando lo exijan las obligaciones del proveedor, proporcionado al sistema y a las pruebas necesarias.

El texto consolidado de la Ley de IA en EUR-Lex es la referencia de control para los requisitos específicos de cada papel.

¿Cómo puede ser una matriz ilustrativa de responsabilidades?

Lo siguiente es un ejemplo de coordinación, no una asignación legal ni una lista completa. Una empresa de cinco personas puede combinar papeles, recurrir a asesores externos o asignar otros responsables. Primero marca cada control como aplicable o no aplicable.

"El diseño del cumplimiento comienza en la arquitectura, no en el lanzamiento. Si no puedes señalar la línea de código que produce la prueba, esa prueba es ficción."

¿Cómo se superponen el RGPD y la Ley de IA en la práctica?

Los regímenes pueden solaparse, pero cada supuesto debe evaluarse por separado:

• Datos de entrenamiento. El RGPD exige una base jurídica y el cumplimiento de sus demás principios cuando se tratan datos personales. Los requisitos de gobernanza de datos del artículo 10 de la Ley de IA se aplican a los sistemas de alto riesgo pertinentes.
• Decisiones automatizadas. El artículo 22 del RGPD se refiere a decisiones basadas únicamente en tratamientos automatizados que producen efectos jurídicos o de importancia similar. Las salvaguardias de intervención humana se aplican en casos de excepción determinados. El artículo 14 de la Ley de IA aborda por separado la supervisión de sistemas de alto riesgo.
• Transparencia. Los artículos 13 y 14 del RGPD pueden exigir información sobre el tratamiento de datos personales; el artículo 50 de la Ley de IA abarca interacciones y contenidos determinados. Ninguno exige un aviso universal para cada resultado de IA.
• Registros. Los registros del artículo 30 del RGPD y la documentación técnica del artículo 11 de la Ley de IA tienen supuestos y responsables diferentes. Las pruebas compartidas pueden reducir duplicidades sin confundir los requisitos legales.
• Evaluación de riesgos. Una EIPD del RGPD y un sistema de gestión de riesgos de la Ley de IA pueden reutilizar pruebas, pero no son intercambiables ni tienen que ser siempre un único documento.

Consulta el texto oficial del RGPD en EUR-Lex al mapear los artículos 22, 30 y 35.

¿Qué ocurre con proveedores y responsables del despliegue de IA de uso general?

Una empresa SaaS de DACH que integra un modelo de terceros puede ser responsable del despliegue de ese modelo y proveedora de su propio sistema de IA, según lo que desarrolle y comercialice. Los papeles deben evaluarse por separado. El ajuste fino no convierte automáticamente a la empresa en proveedora de un nuevo modelo de IA de uso general. Las directrices de la Comisión para proveedores de IA de uso general indican que las modificaciones significativas pueden cambiar ese papel, mientras que las modificaciones menores, por lo general, no. El artículo 25 aborda por separado cuándo otro actor asume las obligaciones de proveedor de un sistema de IA, por ejemplo mediante una modificación sustancial o un cambio de finalidad prevista.

¿Cómo se debe estimar el coste durante el desarrollo?

No existe un porcentaje universal defendible para adaptar o diseñar estas pruebas. Estímalo a partir de los controles aplicables, la arquitectura actual, el linaje de datos, el acceso al modelo y al proveedor, las carencias de pruebas, el estado de la documentación, los controles de seguridad, la frecuencia de revisión y la verificación externa. Clasificar pronto puede evitar retrabajo, pero no hace gratuitas las pruebas de cumplimiento. Para funciones de RAG, agentes y MCP, define las necesidades de transparencia, registro y control humano según el papel y el caso de uso reales.

Otros regímenes pueden afectar a la misma hoja de ruta, pero sus fechas de aplicación y alcance técnico requieren un análisis separado. Nuestro resumen de Stripe Billing y la facturación electrónica alemana trata los requisitos de facturación de forma independiente.

Un proveedor de privacidad o una capa de seudonimización puede cambiar los riesgos y los flujos de datos, pero no elimina ni conserva automáticamente todos los deberes del responsable. Lee qué cambia una pasarela de seudonimización en el alcance del RGPD y vuelve a evaluar el tratamiento y los papeles concretos.