Stacking GDPR + EU AI Act: Lo Que un Founder SaaS DACH Tiene Que Lanzar para 2026

Si vendes SaaS en DACH y tu producto tiene un feature de IA, dos rulebooks se apilan uno sobre el otro. GDPR está en vivo desde 2018. El EU AI Act (Regulación 2024/1689) entra por fases desde febrero de 2025 hasta agosto de 2027. A mediados de 2026, las prohibiciones de prácticas prohibidas y las obligaciones de alfabetización en IA ya están en vigor, las reglas GPAI aplican, y las obligaciones de sistemas de alto riesgo aterrizan el 2 de agosto de 2026. Tu equipo de build es dueño de nueve artefactos. Tu DPO es dueño de cuatro. El CEO los firma.

Esto es perspectiva de ingeniería, no asesoría legal. Hemos lanzado features de IA para clientes DACH bajo el régimen GDPR y hemos vuelto a hacer scope de builds activos contra la línea de tiempo del AI Act.

¿Cuál es la línea de tiempo real de enforcement contra la que necesito planificar?

El AI Act aplica por etapas. Las que importan para un founder SaaS DACH corriendo un feature de IA:

• 2 de febrero de 2025. Prácticas prohibidas (Art. 5) y deber de alfabetización en IA (Art. 4) en vigor.
• 2 de agosto de 2025. Obligaciones de proveedores General-Purpose AI (GPAI), gobernanza, marco de sanciones.
• 2 de agosto de 2026. Obligaciones de sistemas de alto riesgo (Anexo III) y deberes de transparencia (Art. 50) aplican.
• 2 de agosto de 2027. Sistemas de alto riesgo embebidos en productos regulados (Anexo I) cubiertos.

Los reviewers del SDLC de Alemania (BfDI y las DPAs de los estados) y la DSB de Austria liderarán el enforcement de GDPR; las autoridades de vigilancia de mercado para enforcement del AI Act están siendo designadas por cada estado miembro a lo largo de 2026.

¿Es mi feature de IA de alto riesgo bajo el Anexo III?

El árbol de decisión es corto. Tu sistema es de alto riesgo si cae bajo categorías del Anexo III: identificación biométrica, infraestructura crítica, acceso a educación y formación profesional, empleo y gestión de trabajadores, acceso a servicios privados y públicos esenciales (incluyendo credit scoring y pricing de seguros), aplicación de la ley, migración, administración de justicia, procesos democráticos. Para la mayoría de SaaS B2B, el bucket de alto riesgo se toca por features de cribado de CVs, monitoring de empleados, credit scoring y pricing de seguros.

1. ¿Está el caso de uso en el Anexo III? Si no, salta solo a los deberes de transparencia del Art. 50.
2. Si sí, ¿aplica la derogación del Art. 6(3) (puramente preparatorio, procedimental estrecho, desviación de decisión previa, detección de patrones)? Si sí, registra pero con obligaciones reducidas.
3. Si no hay derogación. Aplica el stack completo del Capítulo III. Risk-management system, data governance, documentación técnica, logging, transparencia al deployer, human oversight, accuracy y robustness, sistema de gestión de calidad, evaluación de conformidad, registro en base de datos UE, post-market monitoring.

¿De qué artefactos es realmente dueño el equipo de build?

Esta es la parte que la mayoría de proyectos de compliance liderados por legal hacen mal. Los artefactos de compliance no son documentos Word escritos en el launch. Son subproductos de cómo se construye el sistema. Los nueve de los que es dueño el equipo de ingeniería:

1. Registros de tratamiento (Art. 30 GDPR). Generados desde infrastructure-as-code y diagramas de flujo de datos, mantenidos en sincronía vía CI.
2. DPIA (Art. 35 GDPR) para tratamiento de alto riesgo. Almacenado junto a los architecture decision records, no en el SharePoint de legal.
3. Documentación técnica (AI Act Anexo IV). Model card, resumen de datos de training, métricas de performance, limitaciones conocidas.
4. Logging (AI Act Art. 12). Log de eventos tamper-evident de inputs del modelo, outputs, versión, operador. Retenido seis meses mínimo.
5. Diseño de human oversight (Art. 14). Superficies UX para review, override, abort. Documentado en la spec del producto.
6. Aviso de transparencia (Art. 50). Disclosure cuando un usuario interactúa con IA o ve contenido generado por IA.
7. Disclosure de copyright para datos de training GenAI (Art. 53(1)(d)) si haces fine-tune.
8. Pipeline de reporte de incidentes (Art. 73). Reporte de incidente serio dentro de 15 días a la autoridad de vigilancia de mercado.
9. Post-market monitoring (Art. 72). Detección de drift, alertas de regresión de performance, revisión periódica.

¿Cómo se ve realmente la matriz del compliance-stack para un equipo de 5 personas?

El Compliance Theater falla porque nadie es dueño del artefacto. Aquí está la tabla que usamos en conversaciones de scoping. Ajusta roles a tu organización.

"El diseño de compliance empieza en arquitectura, no en launch. Si no puedes señalar la línea de código que produce el artefacto, el artefacto es ficción."

¿Cómo se apila GDPR encima del AI Act en la práctica?

Los dos regímenes se solapan mucho, y los solapes son donde los founders tropiezan:

• Datos de training. Base legal de GDPR (Art. 6) más data governance del AI Act (Art. 10). Si entrenas sobre datos personales de la UE sin una base limpia, ambos rulebooks muerden.
• Decisiones automatizadas. El GDPR Art. 22 requiere una ruta a intervención humana; el AI Act Art. 14 requiere human oversight by design. El mismo problema, dos hooks de compliance.
• Transparencia. Deberes informativos del GDPR Art. 13/14 en la recolección; AI Act Art. 50 en la interacción. Escribirás ambos.
• Records. Documentación de GDPR Art. 30 y AI Act Art. 11. Construye una fuente única de verdad, renderiza dos vistas.
• Evaluación de riesgo. El DPIA de GDPR y el risk-management del AI Act Art. 9 se solapan. La práctica moderna los combina en un documento con ambos anexos legales.

¿Y los proveedores GPAI vs deployers?

La mayoría de founders SaaS DACH son deployers de foundation models de OpenAI, Anthropic, Mistral o pesos open-source. Las obligaciones de deployer son más ligeras que las de provider pero no ausentes. Si haces fine-tune de un modelo y lo despliegas bajo tu marca, puedes convertirte en provider a efectos del AI Act, asumiendo documentación técnica, disclosure de copyright y (para alto riesgo) el stack completo del Capítulo III. Lee el Art. 25 cuidadosamente antes de hacer fine-tune, porque el salto de coste regulatorio en "ahora soy provider" es significativo.

¿Cuánto cuesta esto en build-time?

Del historial de engagements de Wavect en builds de features de IA: apilar los artefactos de compliance en un SaaS existente añade del 10 al 20 por ciento al tiempo de ingeniería cuando se hace retrofit. Construido desde arquitectura, el coste marginal está más cerca del 3 al 5 por ciento. El movimiento caro es atornillarlo en el launch. El movimiento barato es ser dueño de los artefactos como código desde el sprint uno. Los features RAG y de agent tocan primero los requisitos de transparencia y logging; las integraciones de tools MCP necesitan la historia del audit trail antes de lanzar.