MSTech Geeks

La regulación antes de la innovación

Durante años, ser desarrollador de IA significaba dominar modelos, datos y despliegues. En 2026, eso ya no es suficiente. Ahora necesitas entender algo mucho más incómodo: tu sistema no solo tiene que funcionar, tiene que ser legal, auditable y justificable.

Tu sistema no solo tiene que funcionar. Tiene que ser legal, auditable y justificable.

Bienvenido al mundo de la AESIA.

Qué es AESIA (y por qué deberías preocuparte)

La ALa Agencia Española de Supervisión de la Inteligencia Artificial no es otro organismo más de los que se anuncian y se olvidan. Es el punto exacto donde el desarrollo de IA deja de ser puramente técnico y pasa a ser regulado: supervisa el uso de la IA en España, garantiza el cumplimiento del Reglamento Europeo de IA, y tiene capacidad para inspeccionar sistemas en producción y sancionar los incumplimientos que detecte.

AESIA no regula ideas, regula sistemas que ya están funcionando. Y con ella cambia la pregunta que te tienes que hacer antes de lanzar algo. Hasta hace poco, el criterio era simple: ¿funciona? Adelante. Ahora hace falta responder a bastante más: ¿puedes explicar cómo funciona? ¿Puedes demostrar que el sistema no es discriminatorio? ¿Puedes auditar cada decisión y tener trazabilidad de lo que pasa dentro? El foco de la regulación no es el desarrollo en sí, es el impacto que ese desarrollo tiene en el mundo real, en las empresas y en la gente. No basta con construir un sistema con inteligencia artificial, hay que tener previsto todo lo que se puede hacer con él, incluyendo cómo alguien con malas intenciones podría usarlo.

Lo que importa no es el desarrollo. Es el impacto.

Cómo funciona: los cuatro niveles de riesgo

El Reglamento Europeo de IA, y por extensión AESIA, parte de una idea simple pero potente: no toda la IA es igual, y se regula según el riesgo que representa. Son cuatro niveles.

🟥 Riesgo inaceptable. Directamente prohibido: manipulación subliminal, scoring social.

🟧 Alto riesgo. Sistemas que afectan a derechos fundamentales: contratación, crédito, sanidad, justicia. Aquí es donde la cosa se pone seria de verdad.

🟨 Riesgo limitado. Obligaciones de transparencia, como informar de que estás hablando con un chatbot.

🟩 Riesgo mínimo. Uso libre, sin obligaciones añadidas.

Lo que cambia si trabajas en sistemas de alto riesgo

Si tu desarrollo cae en la categoría de alto riesgo, AESIA introduce obligaciones que no son opcionales: documentación técnica exhaustiva, trazabilidad de cada decisión, gestión activa de datos y sesgos, mecanismos de supervisión humana, y validación continua en el tiempo, no solo en el lanzamiento. Ya no basta con el código del proyecto. Hay que tener en cuenta todo lo que hay alrededor de él.

Y AESIA no se queda en el papel. Tiene un sandbox para probar sistemas antes de lanzarlos, emite guías prácticas de cumplimiento, inspecciona sistemas ya en producción, y tiene capacidad sancionadora. Esta última es probablemente la función que más deberías tener presente a la hora de plantear cualquier desarrollo: en producción no se puede improvisar, porque los cambios de última hora ya no cuestan solo tiempo y dinero, pueden costar sanciones y reputación.

El nuevo stack, y el nuevo rol

El stack clásico que todos usábamos hasta ahora era Python, modelos de IA (Microsoft Foundry, Hugging Face, Vertex AI…), APIs, MCPs, skills. Ahora hay que sumarle compliance, auditoría y explicabilidad, y no como un extra opcional, sino como parte estructural del propio sistema.

El rol también cambia con esto. Antes construíamos modelos. Ahora somos responsables de sistemas con impacto legal real, lo que en la práctica significa tres cosas: entender la regulación que te afecta, diseñar con trazabilidad desde el primer día, y anticipar que en algún momento te van a auditar. Porque si algo falla en un sistema de alto riesgo, ya no es solo un bug, es un problema legal.

No es opcional. Es estructural.

De ML Engineer a AI System Owner

El rol también cambia.

Antes construíamos modelos, ahora somos responsables de sistemas con impacto legal real. Lo que implica 3 puntos:

• Entender regulación
• Diseñar con trazabilidad
• Anticipar auditorías

Porque si algo falla, no es solo un bug, es un problema legal.

Por qué muchos equipos van tarde, y cómo no ser uno de ellos

El error más común que estoy viendo es tratar esto como «cosa de legal, ya lo veremos luego». No funciona así. La regulación no se añade al final del proyecto, tiene que estar dentro de la infraestructura desde el principio, igual que la seguridad o el rendimiento.

No hace falta convertirse en abogado, pero sí conviene interiorizar tres ideas. Diseña con trazabilidad desde el inicio: si no puedes explicar una decisión de tu sistema, ya tienes un problema, lo sepas o no. Trata los datos como un riesgo, no solo como un recurso: un sesgo no es un bug menor, es una responsabilidad que alguien va a tener que asumir. Y asume que tu sistema será auditado, porque probablemente lo será.

AESIA no viene a frenar la innovación, viene a forzar que sea responsable. Eso cambia el tipo de ingeniería que hacemos: menos «funciona en mi máquina» y más «puedo demostrar que funciona correctamente». En este nuevo contexto, el verdadero skill ya no es solo generar código. Es construir sistemas que puedan defenderse por sí solos, incluso cuando tú no estás delante para explicarlos.