Cómo cumplir la Ley de IA de la UE siendo startup (sin volverte loco ni quemar el runway)

Para qué sirve esta guía (y para qué no)

Si montas una startup con IA en Europa, o vendes a Europa, el Reglamento (UE) 2024/1689, el famoso RIA o AI Act, no es un PDF para el abogado del final del pasillo. Es un calendario con dientes. Esta guía no te va a contar la historia de cómo se negoció en Bruselas ni a venderte un curso de “compliance 10x”. Te va a decir qué plazos ya han caído, cuáles te pisan los talones y qué mover en el producto para no llegar al 2 de agosto de 2026 con la cara de “no lo vimos venir”.

Tampoco es un sustituto de un dictamen legal firmado. Es el mapa que un founder técnico necesita para no improvisar compliance como si fuera un sprint de features.

La promesa es concreta: al terminar, sabes si tu sistema puede ser de alto riesgo, qué bloque de obligaciones te toca, qué no puedes dar por aplazado todavía y cómo montar el trabajo sin convertir la empresa en un despacho de abogados con API.

Qué es el RIA en cristiano

El RIA (Reglamento de Inteligencia Artificial) clasifica sistemas de IA por nivel de riesgo y les pone obligaciones distintas. No castiga “usar IA”. Castiga usarla en contextos donde una cagada te arruina la vida a alguien: que te denieguen un crédito, que te descarten de un empleo, que te clasifiquen mal en un procedimiento sensible.

Hay tres capas que te importan como startup:

• Prácticas prohibidas: usos que la UE no quiere ni de broma.
• Modelos GPAI (general-purpose AI): los modelos de propósito general y su cadena de proveedores.
• Sistemas de alto riesgo: sobre todo los del Anexo III (empleo, crédito, seguros, migración, justicia y similares) y los metidos en productos ya regulados (Anexo I).

El dato base, según el análisis de Economist & Jurist (15-jul-2026): el reglamento entró en vigor el 1 de agosto de 2024 con aplicación escalonada. No es “todo aplica ya” ni “todo es 2027”. Es un embudo.

El calendario que de verdad manda (no el del PowerPoint del inversor)

Olvida la frase de “la regulación llega tarde” como excusa para no hacer nada. En este caso parte del tren ya pasó:

Hito	Fecha	Qué implica para ti
Entrada en vigor del RIA	1-ago-2024	El marco existe; empieza la cuenta atrás
Prácticas prohibidas	2-feb-2025	Si tocas usos vedados, estás fuera de juego
Modelos GPAI	2-ago-2025	Obligaciones de cadena de suministro / proveedores de modelos de propósito general
Alto riesgo, Capítulo III	2-ago-2026	El gran golpe para producto B2B en Annex III
Tope posible si el Ómnibus aplaza (Annex III)	2-dic-2027	Solo si el mecanismo de aplazamiento llega a existir de verdad
Tope posible si el Ómnibus aplaza (Anexo I / producto)	2-ago-2028	Igual: condicionado, no regalado

Importa el orden. Muchas startups viven en modo “ya veremos en 2027” porque han oído hablar del Ómnibus. Mal. A 15 de julio de 2026 el texto del Ómnibus no se ha publicado en el Diario Oficial de la UE, así que el RIA original sigue plenamente vigente. Eso no es un matiz de leguleyo: es la diferencia entre planificar con fecha firme y planificar con un rumor de alivio.

Si estás construyendo scoring de candidatos, motor de riesgo de crédito, triaje de pólizas o cualquier cosa que huela a Anexo III, el reloj que debes poner en la pared es el 2-ago-2026, no el hilo de Twitter del último lobby.

Paso 0: clasifica el sistema antes de “hacer compliance”

Antes de contratar una consultora, de rellenar plantillas o de pintar un diagrama bonito en Miro, haz una pregunta fea y concreta:

¿Qué decisión humana cambia tu modelo, sobre quién y con qué consecuencia?

Eso es clasificación de riesgo en la práctica. El Anexo III no mira si usas un transformer o un random forest de 2017. Mira el uso.

Señales de que puedes estar en alto riesgo (Anexo III)

Sin convertirlo en un checklist legal cerrado (eso no viene reglado aquí con el detalle de un manual oficial), estos son los contextos que el propio marco señala como de alto riesgo no cubiertos solo por legislación de producto:

• Contratación y empleo: filtrado de CVs, ranking de candidatos, evaluación de rendimiento, despidos “asistidos”.
• Crédito y acceso a servicios esenciales: scoring, límites, denegaciones.
• Seguros: tarificación y siniestralidad con impacto fuerte sobre el asegurado.
• Migración, asilo, control fronterizo.
• Justicia y procesos democráticos sensibles.

Si tu pitch dice “automatizamos la decisión” y el cliente es un banco, un insurer, un ATS enterprise o una administración, asume alto riesgo hasta que un abogado te demuestre lo contrario. El error clásico de startup es clasificarse a sí misma como “bajo riesgo porque solo somos un copiloto” mientras el botón de “Accept recommendation” es, de facto, la decisión.

Lo que no debes inventarte en la clasificación

No hay en el material un árbol oficial paso a paso ni un formulario mágico de la Comisión listo para startups. Así que no finjas tenerlo. Lo operativo es:

1. Escribe el caso de uso real (no el de marketing).
2. Identifica si hay decisión o influencia material sobre personas en ámbitos Annex III.
3. Separa componentes: modelo base, fine-tune, reglas, UI, logs, humanos en el circuito.
4. Documenta la conclusión con fecha y responsable. Aunque luego cambie, tendrás rastro.

Sin ese paso, todo lo demás es teatro de compliance.

Qué te exige el alto riesgo si te aplica el Capítulo III

Para sistemas de IA de alto riesgo del Anexo III, a partir del 2 de agosto de 2026 el paquete no es “pon un disclaimer en el footer”. Según el marco recogido en la fuente, implica cumplir con un bloque duro:

• Gestión de riesgos en todo el ciclo de vida
• Datos de entrenamiento de alta calidad
• Documentación técnica exhaustiva
• Transparencia
• Supervisión humana
• Robustez
• Ciberseguridad
• Gestión de calidad

Traducción a producto, sin humo:

1) Gestión de riesgos de verdad (no un Excel huérfano)

No es un PDF de “riesgos residuales: bajos” firmado el día antes de la demo. Es un proceso vivo: identificas modos de fallo (sesgo en candidatos de un código postal, deriva del modelo, abuso del cliente enterprise), mides impacto, metes controles y revisas cuando cambias datos, prompt o modelo.

Si despliegas cada semana y el registro de riesgos se actualiza cada equinoccio, no tienes gestión de riesgos: tienes folklore.

2) Datos de entrenamiento “de alta calidad”

Aquí es donde sangran las startups que entrenan o fine-tunan con scrapes alegres. “Alta calidad” en regulatorio no significa “nos funcionó el F1 en el notebook”. Significa procedencia, sesgos conocidos, representatividad respecto al uso, y capacidad de explicar qué datos tocaban la decisión.

Truco de sanidad mental: si no puedes responder en una reunión “¿de dónde salió este dataset y a quién perjudica si está torcido?”, no estás listo para Annex III.

3) Documentación técnica exhaustiva

No tenemos en las fuentes el índice mínimo oficial párrafo a párrafo, así que no te lo invento. Lo que sí puedes hacer ya, y te salva el culo operativo:

• Descripción del sistema y del uso pretendido (y del uso razonablemente indebido).
• Arquitectura: componentes deterministas vs modelo probabilístico.
• Versiones de modelo, datasets, prompts de sistema, guardrails.
• Métricas de evaluación sobre tu corpus, no solo benchmarks de marketing.
• Procedimientos de cambio (quién aprueba subir un modelo a prod).

Si quieres rigor de ingeniería y no de postureo, monta evaluación con datos propios en vez de fiarte del leaderboard; de eso va precisamente cómo montar un pipeline de evaluación de LLMs con datos propios.

4) Transparencia y supervisión humana

Transparencia no es un tooltip de “esto es IA ✨”. Es que el usuario afectado y el operador entiendan que hay un sistema automatizado, con qué límites y cómo reclamar o escalar.

La supervisión humana es el gran teatro del sector. Poner un becario que pulsa “Approve all” no es supervisión: es human-in-the-loop convertido en placebo. Si el humano no tiene tiempo, contexto ni autoridad real para tumbar la recomendación, el regulador no va a emocionarse con tu diagrama de cajitas.

5) Robustez, ciberseguridad y calidad

Robustez: el sistema no se desmonta con inputs raros, adversarial prompts o datos fuera de distribución. Ciberseguridad: el modelo, los embeddings, las tools y los logs no son un buffet libre. Calidad: trazabilidad de incidencias, rollback, dueños claros.

Para founders con stack híbrido, hay un criterio de diseño que evita dolores:

Diseña primero la máquina de estados (transiciones legales + auditoría). El LLM propone; el motor valida. El modelo no muta estado a lo bestia.

Eso no es romanticismo de arquitectura. Es la forma de poder demostrar supervisión, logs y límites cuando alguien pregunte “quién decidió qué”.

El elefante en la sala: las multas

Incumplir obligaciones de alto riesgo puede acarrear multas de hasta el 7% de la facturación global anual o 35 millones de euros. Léelo otra vez con la cabeza de startup: no es “7% del ARR europeo del producto X”. Es el tipo de cifra que usa la UE para que el board deje de tratar compliance como un nice-to-have del Q4.

No hace falta que te arruinen al máximo teórico para matarte. Una investigación, un bloqueo de despliegue en un cliente grande o una cláusula de indemnidad en un contrato enterprise te pueden dejar seca mucho antes.

Dimensiona el riesgo así, sin drama de película:

1. ¿Cuánto ARR depende de casos Annex III?
2. ¿Cuánto tardarías en apagar o degradar el sistema a reglas si te lo exigen?
3. ¿Tienes evidencia (logs, versiones, evaluaciones) o solo buenas intenciones?

Si la respuesta a la 3 es “lo tenemos en Notion… creo”, tu riesgo real no es la multa abstracta: es no poder defenderte.

El Ómnibus Digital: alivio posible, no indulto

El 19 de noviembre de 2025 se publicó la Propuesta de Reglamento Ómnibus Digital sobre IA. Su promesa política es clara: bajar carga administrativa y costes de cumplimiento para pymes, con un ahorro estimado de entre 297 y 433 millones de euros a nivel agregado. Ojo: eso es una estimación macro del paquete, no tu descuento personal en la factura del consultor.

Seamos justos: la propuesta no es un brindis al sol. Extender regímenes simplificados, estandarizar formularios y reducir registro para sistemas no-Annex III son medidas que, si llegan a materializarse, quitarían fricción real a startups que hoy dedican horas de engineering y asesoría externa a papeleo. El problema no es la intención; es que, a 15 de julio de 2026, ese alivio sigue siendo una promesa sin fecha de entrega.

Qué simplificaciones trae (en la propuesta)

Para pymes y small mid-caps (SMC), el Ómnibus apunta a:

• Extender regímenes simplificados.
• Documentación técnica y gestión de calidad simplificadas con formularios estandarizados.
• Eliminar o reducir requisitos de registro para sistemas no de alto riesgo del Anexo III.

Si de verdad calificas como pyme o SMC, esto puede ser oxígeno. No asumas que te cae encima solo por ser startup: hay que mirar definiciones, umbrales y el texto final cuando exista.

El aplazamiento condicionado (léase: condicionado)

El mecanismo de aplazamiento no es “lo movemos porque molesta”. La lógica descrita es:

1. La Comisión tiene que constatar que hay estándares armonizados, especificaciones comunes o directrices adecuadas.
2. A partir de ahí, las obligaciones del Capítulo III se aplicarían 6 meses después para sistemas del Anexo III y 12 meses después para sistemas integrados en productos regulados (Anexo I).
3. Con fechas tope: 2-dic-2027 (Annex III) y 2-ago-2028 (Anexo I / producto).

Traducción founder: aunque el Ómnibus saliera adelante tal cual, no tienes un aplazamiento automático hoy. Dependes de estándares y de un acto de la Comisión. Y, repito hasta que duela, a 15-jul-2026 el Ómnibus no está en el DOUE.

Planificar como si el 2-ago-2026 hubiera desaparecido es una forma elegante de suicidio regulatorio.

Lo que se movió en mayo de 2026 (y te puede pillar por banda)

El acuerdo político de mayo de 2026 metió dos cosas que muchas decks de “AI governance” aún no han actualizado:

1. Prohibición expresa de sistemas de IA para generar deepnudes o CSAM.
2. Reinstauración de la obligación de registro en la base de datos de la UE para ciertos sistemas de alto riesgo que estaban exentos.

Si tu producto toca imagen generativa, edición de personas o cualquier pipeline que pueda desviarse a desnudos no consentidos, no es un edge case de trust & safety: es zona de prohibición dura. Y si pensabas que por una exención te librabas del registro, verifica otra vez: el péndulo ha vuelto hacia más trazabilidad pública en algunos casos.

Plan de trabajo realista para una startup (90 días serios)

Esto no es el manual oficial de la AI Office. Es una secuencia que puedes ejecutar con equipo pequeño sin convertirte en Deloitte.

Días 1–15: inventario y dueño

1. Lista todos los flujos con modelo (prod, beta, “pilotito” con el cliente amigo).
2. Para cada uno: input, decisión, humano sí/no, sector del cliente, país.
3. Marca candidatos Annex III en rojo.
4. Nombra un dueño de cumplimiento de producto (no “el becario de legal”). Producto + engineering + legal en la misma mesa.
5. Congela un inventario versionado (fecha, commit, modelo, dataset).

Días 16–45: controles mínimos que se notan en el código

Para cada sistema rojo:

1. Contrato de entrada/salida tipado: el modelo devuelve una propuesta estructurada; reglas deterministas deciden si se aplica.
2. Logs de decisión: quién (sistema/usuario), qué versión, qué features, qué override humano.
3. Modo degradado: si falla el modelo o hay incidente, ¿sigues con reglas o paras?
4. Evaluación congelada: set de casos reales anonimizados; corres regresión antes de cada release relevante.
5. Política de datos: origen, retención, acceso, borrado. Sin novela: tablas y responsables.

Aquí vuelve el baseline fuerte: si tu “mejora con IA” solo gana contra un proceso ridículo, también tendrás problemas para defender calidad y gestión de riesgos. El baseline honesto, el que un ingeniero competente montaría sin LLM, te sirve para producto y para no autoengañarte con métricas hinchadas. Más sobre por qué eso importa en la manía de la IA y la toma de decisiones.

Días 46–75: documentación que no da vergüenza

Monta un “system file” vivo por producto:

• Uso pretendido y límites.
• Arquitectura (diagrama aburrido pero cierto).
• Datos y evaluación.
• Riesgos residuales y mitigaciones.
• Supervisión humana real (tiempos, colas, autoridad).
• Incident response: quién apaga qué en 60 minutos.

No esperes al formulario estandarizado del Ómnibus como a un mesías. Si llega, migrarás. Si no llega, no estás desnudo.

Días 76–90: contratos, clientes y go-to-market

1. Revisa cláusulas con clientes enterprise: auditoría, indemnities, ubicación de datos, derecho a suspender el sistema.
2. Deja de vender “decisión autónoma 100%” en sectores Annex III. Vende asistencia con control demostrable.
3. Si eres proveedor de un modelo embebido en el flujo de otro, aclara quién es proveedor del sistema de alto riesgo en el contrato. Las pelearás de todos modos; mejor por escrito.
4. Presupuesto: compliance no es solo abogado. Es tiempo de eng, evaluación, logging, y a veces certificados o auditorías externas cuando toque.

Errores comunes (los veo venir a kilómetros)

1) “Somos low risk porque el humano firma al final.”
Si el humano no puede discrepar con información y tiempo, eres high risk con postureo UX.

2) “El Ómnibus nos salva.”
No está en el DOUE a 15-jul-2026. El RIA original manda. Punto.

3) “Cumplimiento = política en Confluence.”
Sin enganche a releases, modelos y logs, es literatura.

4) “Ya usamos un modelo de un hyperscaler, ellos cumplen por nosotros.”
Ellos cumplen lo suyo (GPAI / plataforma). El sistema que montas tú sobre su API, con tu fine-tune y tu decisión de negocio, sigue siendo tuyo.

5) “Documentamos cuando tengamos product-market fit.”
El 2-ago-2026 no pregunta si ya eres unicornio. Si vendes hoy en verticales sensibles, el reloj corre sobre ingresos reales.

6) “Registro y deepnudes no van con nosotros.”
Verifica. El acuerdo de mayo de 2026 endureció prohibiciones y reabrió registro en ciertos altos riesgos exentos. Mejor un check aburrido que una sorpresa en due diligence.

Cómo organizar el equipo sin crear el Ministerio del Cumplimiento

Startup de 8–30 personas no necesita un chief AI ethics officer con linkedin azul. Necesita:

• Producto: dueño del uso pretendido y de lo que se promete al cliente.
• Engineering: versionado, logs, modos degradados, evals en CI.
• Legal/externo puntual: clasificación, contratos, lectura del Anexo y del estado del Ómnibus.
• Founder/CEO: prioriza. Si compliance solo se discute cuando hay term sheet, ya vas tarde.

Cadencia recomendada hasta agosto de 2026:

• Revisión quincenal del inventario de sistemas.
• Gate de release en sistemas rojos (eval + riesgos + aprobación).
• Simulacro trimestral de incidente (sesgo grave, fuga de prompts, uso indebido).

Barato comparado con rehacer el producto bajo amenaza de multa o de un cliente que te expulsa del panel de proveedores.

Qué hacer esta misma semana

No “explores el framework”. Haz esto:

1. Abre una hoja con tus flujos de IA en producción y pilotos.
2. Marca los que toquen empleo, crédito, seguros, sector público sensible o decisiones de acceso a servicios.
3. Para el más crítico: escribe en una página uso pretendido, versión de modelo, datos, y si hay override humano real.
4. Pon el 2-ago-2026 en el calendario de company-wide con un owner.
5. Encarga a legal una lectura corta de: estado del Ómnibus + si tu caso huele a Annex III + exposición contractual.
6. Si generáis imagen de personas, revisa filtros y políticas anti deepnude/CSAM como prioridad de prohibición, no como nice-to-have de marca.

Si solo haces una cosa: deja de tratar el aplazamiento como un hecho. Trátalo como un escenario. Construye para la fecha que hoy está vigente.

El desfase entre la velocidad del modelo y la de la ley es real, de eso va el desfase regulatorio de la IA, pero aquí la trampa es la inversa: la ley ya puso fecha y el mercado sigue fingiendo que es niebla eterna. La niebla es el Ómnibus sin publicar. La fecha, de momento, no.

Preguntas frecuentes

¿Cuándo empiezan las obligaciones de alto riesgo del RIA para startups?

Las obligaciones del Capítulo III para sistemas de alto riesgo aplican desde el 2 de agosto de 2026, dentro del calendario escalonado del RIA en vigor desde el 1 de agosto de 2024. Las prácticas prohibidas ya aplican desde el 2 de febrero de 2025 y las de modelos GPAI desde el 2 de agosto de 2025. A 15 de julio de 2026 el Ómnibus no está en el DOUE, así que no puedes dar por hecho un aplazamiento.

¿Qué multa arriesga una startup si no cumple el alto riesgo?

El incumplimiento de las obligaciones de alto riesgo puede acarrear multas de hasta el 7% de la facturación global anual o 35 millones de euros. Además del máximo teórico, el daño práctico suele llegar antes por fricción comercial, auditorías de clientes y bloqueos de despliegue. Conviene dimensionar exposición por producto Annex III y por capacidad de demostrar controles.

¿El Ómnibus Digital ya retrasa el 2 de agosto de 2026?

No. La propuesta de Ómnibus (19-nov-2025) plantea un aplazamiento condicionado a que existan estándares o directrices adecuadas, con topes el 2-dic-2027 (Annex III) y el 2-ago-2028 (Anexo I). Pero a 15-jul-2026 el texto no se ha publicado en el Diario Oficial de la UE, por lo que el RIA original sigue plenamente vigente.

¿Qué simplificaciones pueden tener las pymes con el Ómnibus?

La propuesta incluye regímenes simplificados, documentación técnica y gestión de calidad más ligeras con formularios estandarizados, y menos registro para sistemas que no sean de alto riesgo del Anexo III. Está orientado a pymes y small mid-caps, con un ahorro agregado estimado de 297–433 millones de euros. No implica beneficio automático individual ni sustituye cumplir si eres alto riesgo bajo el marco actual.