Llevo más de quince años construyendo modelos de aprendizaje automático en sitios donde una predicción equivocada no es un mal trimestre. En inspección industrial, un defecto de fabricación que el modelo no detectara podía convertirse en un fallo estructural con todas sus consecuencias. En imagen médica, un error era una enfermedad que no se detecta a tiempo. En esos sitios se aprende rápido una verdad incómoda: entrenar el modelo es la parte fácil. Demostrar que es seguro y conforme es la difícil.
Y casi todo el mundo lo está demostrando mal, por una razón muy concreta: ha levantado un muro. En el desarrollo de software ya conocíamos ese muro —el que separaba a quien escribía el código de quien lo ponía en producción—. DevOps lo derribó: construir y operar dejaron de ser dos mundos enfrentados. En la IA de alto riesgo el muro ha vuelto a crecer, esta vez entre el equipo de cumplimiento y el equipo que construye los modelos. Y el Reglamento de IA se lanza por encima, como quien pasa un marrón al otro lado.
La escena es habitual. Faltan semanas para poner el sistema en servicio. Antes tiene que pasar la evaluación de conformidad, y cumplimiento pide al equipo técnico "la documentación del sistema". El equipo se sienta a redactar el expediente técnico de conformidad a base de reuniones, correos y capturas de pantalla; a reconstruir de memoria las decisiones de diseño de los últimos meses: con qué datos se entrenó, qué casos límite se descartaron, por qué el modelo prioriza a un paciente —o concede un crédito, o marca un fraude— como lo hace. Lo que sale es un documento huérfano, separado del sistema que dice describir. No aguanta el primer tirón.
La intención, casi siempre, era buena: "que lo lleve cumplimiento y así le quitamos el lío regulatorio a los desarrolladores". Y consigue lo contrario. Porque en el lado técnico del muro vive un malentendido todavía más caro: "alto riesgo es cosa de legal, no va conmigo". Sí va. Los artículos 9 a 15 del Reglamento —gestión de riesgos, gobierno del dato, trazabilidad, supervisión humana, exactitud y robustez— no son cláusulas para abogados. Son una especificación de ingeniería: dictan cómo tiene que estar construido tu sistema, no solo cómo tiene que estar contado.
Cuando lo lees así, el Reglamento deja de ser un trámite del final y vuelve a ser lo que siempre fue: una cuestión de cómo desarrollas. (Y si estás en banca, súmale DORA; en salud, el MDR: el mismo trabajo de fondo, resuelto una vez en el desarrollo.)
Y antes de que pienses que tienes tiempo: la obligación para la IA de alto riesgo del Anexo III se aplazó a diciembre de 2027. No te has librado —el sistema que entrenas y despliegas hoy es el que tendrás que defender entonces—.
De ahí estas cinco preguntas. Son un autodiagnóstico honesto para cualquier equipo que desarrolle o despliegue IA de alto riesgo:
- ¿Tus procesos de MLOps están listos para el Reglamento de IA? Para cualquier decisión de tu modelo, ¿puedes decir con qué versión de código, de modelo y de datos se tomó? Y con el modelo ya en producción, ¿detectas y registras cuándo se desvía de lo que validaste?
- ¿Sabes identificar los riesgos de tu sistema? Los concretos —los de tu caso de uso, tus datos y las personas a las que afecta—, no una lista genérica copiada de una plantilla.
- ¿Gestionas esos riesgos como un bucle continuo? No como un informe que se escribe el último día, sino como un bucle que dirige decisiones de diseño —igual que las pruebas dirigen el desarrollo guiado por pruebas.
- ¿La supervisión humana es real o decorativa? La persona que revisa cada decisión, ¿tiene contexto y poder para anular al modelo —y queda registrado cuándo lo hace—, o es un botón de "aceptar" que nadie cuestiona?
- ¿Capturas la evidencia mientras construyes? Firmada y reproducible, generada desde el propio desarrollo. O la fabricas a mano, después, cuando ya nadie recuerda por qué se tomó cada decisión.
Si te has quedado en "no" en más de una, no es un problema de tu departamento de cumplimiento. Es una conversación que tiene que cruzar el muro.
Porque la conformidad de la IA de alto riesgo no es un documento que se redacta al final: es una disciplina de ingeniería que se diseña desde el principio. Y la progresión ya la conoces. DevOps acercó la operación al desarrollo. DevSecOps le sumó la seguridad. MLOps trajo los modelos a ese mismo flujo —donde tu equipo ya trabaja a diario—. Falta el paso natural: llevar también la conformidad ahí dentro, al flujo donde vive el modelo. A eso lo llamo GovOps, y es muy concreto: cada entrenamiento emite un manifiesto firmado —qué datos, qué código, qué métricas, quién lo aprobó— y cada decisión en producción queda atada a esa versión. Así el expediente no se redacta: sale por construcción.
Y a esa capa —gobernanza demostrada, no prometida— la llamo aseguramiento: la que prueba lo que la gobernanza se limita a declarar.
Eso es lo que defiendo: pruebas, no promesas. La evidencia se genera, no se redacta.
En las próximas semanas voy a desgranar cada una de estas cinco preguntas: qué significan en la práctica, qué cambian en tu arquitectura y cómo se captura la evidencia sin frenar al equipo. Si trabajas en esto, suscríbete y seguimos.
— Rodrigo