Gobernanza de IA para equipos de desarrollo: lo que aprendí de quien ya lo ha implantado

Pensaba que la gobernanza de la IA era problema del equipo de legal. Salí con una lista de cosas que tengo que cambiar en cómo desarrollo.

FRANK LACROIX
Software Engineer

Cuando vi el título de la sesión de Knowledge Sharing, asumí que el contenido me iba a rozar de lejos. Trabajo construyendo agentes y sistemas con LLMs: mi labor es que las cosas funcionen, no gestionar marcos regulatorios. La gobernanza de IA para equipos de desarrollo me parecía, llanamente, un problema de otro departamento.

La sesión la impartió Beatriz G. Pozo, Project Manager con más de diez años de experiencia y tres implantando modelos de gobernanza de IA en grandes corporaciones. En los primeros diez minutos entendí por qué me equivocaba.

El Reglamento Europeo de IA no va de papeleo: va de lo que construyes

El Reglamento Europeo de Inteligencia Artificial —el primer marco legal integral de IA en el mundo— entra completamente en vigor en agosto de 2026. Las empresas pueden ser auditadas a partir de esa fecha, con multas de hasta 35 millones de euros o el 7% de su facturación global. El objetivo de estas sanciones es hacer que el cumplimiento sea real, no solo formal: porque lo que la ley evalúa no es si el riesgo está presente en tu proyecto, sino si has tomado medidas concretas para gestionarlo.

Lo que más me sorprendió es la lógica con la que la ley clasifica el riesgo. No lo define el nombre del proyecto ni la tecnología que usas, sino lo que hace tu sistema y el contexto en el que opera. Beatriz lo bautizó coloquialmente como el risquímetro, y tiene cuatro niveles —de menor a mayor riesgo:

• Riesgo mínimo: automatizaciones internas sin interacción directa con personas ni toma de decisiones con impacto.
• Riesgo limitado: la mayoría de los proyectos con interacción humana, incluyendo asistentes virtuales. La exigencia central es la transparencia algorítmica: el usuario tiene que saber que está hablando con una IA.
• Alto riesgo: proyectos en sectores críticos como salud, educación, infraestructuras o recursos humanos. Documentación exhaustiva y cumplimiento estricto.
• Riesgo inaceptable: sistemas de vigilancia biométrica masiva, manipulación psicológica, scoring social por parte de gobiernos. Prohibidos directamente. Línea roja sin matices.

El riesgo alto no es el fin del mundo, es decir, hay mecanismos para mitigarlo. Beatriz puso un ejemplo al que me quedé dando vueltas: si construyes un agente que hace mailing masivo y usas nombres y correos electrónicos, tienes datos personales y el riesgo sube automáticamente. Pero si los usuarios han firmado un consentimiento previo, el riesgo baja. Si anonimizas los datos en cuanto puedes, baja más. Lo que la ley evalúa es si has demostrado que te has preguntado sobre el riesgo y has intentado reducirlo, no si has logrado eliminarlo.

Esto encaja con algo que en los proyectos con IA ya aplicamos de forma habitual: documentar decisiones de diseño no para el archivo, sino para que sean reproducibles y auditables. La gobernanza no añade un proceso nuevo desde cero. Extiende uno que, si trabajas bien, ya existe.

Gobernanza de IA para equipos de desarrollo: lo que cambia en cómo trabajo

La segunda parte fue la que más me afectó directamente. Beatriz pasó del marco regulatorio a los proyectos concretos, y lo hizo desde la perspectiva del equipo que desarrolla, no del que supervisa.

La primera implicación tiene que ver con responsabilidad. Si eres el proveedor que desarrolla la IA, la responsabilidad legal es tuya. Si el cliente le pone su nombre al sistema, la responsabilidad pasa a ser suya, pero el cliente te va a buscar si hay un problema. En cualquiera de los dos casos, tu cobertura es la documentación: no una genérica, sino la respuesta a preguntas específicas sobre lo que hace tu sistema.

Hay cuatro elementos que cualquier equipo de desarrollo debería integrar en sus procesos:

1. Pruebas negativas. No solo testear lo que la IA debe contestar, sino lo que no debe contestar. Preguntas inesperadas, situaciones con potencial discriminatorio, escenarios límite. El objetivo es acreditar que has buscado activamente los fallos, aunque el sistema final no sea perfecto.
2. Transparencia algorítmica. El equipo tiene que poder explicar por qué el sistema respondió lo que respondió, no ante el usuario, sino ante un auditor. Para los sistemas de riesgo limitado, la transparencia algorítmica es el requisito central del Reglamento, no un opcional.
3. Supervisión humana. Los sistemas que toman decisiones autónomas tienen un nivel de riesgo automáticamente más alto, por lo que añadir un punto de revisión humana para decisiones con impacto real baja ese nivel de forma directa. No lo veas como un parche sino como una decisión de arquitectura.
4. Trazabilidad. Quién hizo qué prueba, en qué fecha, con qué modelo y con qué resultado. No para el archivo, sino para poder respaldarlo cuando alguien lo pregunte.

Otro momento interesante de la sesión fue cuando nuestro compañero Carlos Jiménez, software architect, preguntó en qué momento se puede «dormir tranquilo» con el nivel de compliance. La respuesta de Beatriz fue más concreta de lo que esperaba: cuando tienes un inventario de lo que usas, puedes explicar lo que hace tu sistema y, además, tienes documentadas las pruebas que has realizado. No hace falta un repositorio de cientos de páginas: basta con poder demostrar que te has hecho las preguntas correctas, lo que la ley llama diligencia.

Esto también aplica al Shadow AI: las herramientas que usan los miembros del equipo fuera del stack oficial, muchas veces sin que nadie lo sepa. Inventariarlas no es para controlar a nadie: es para saber si alguien está enviando documentos confidenciales a una herramienta que los usa para entrenamiento. Es el primer paso hacia cualquier forma de control real.

Documentar a velocidad ultra-ágil: el problema que la ley no resuelve del todo

La pregunta que llevaba toda la sesión queriendo hacer era esta: los LLMs han acelerado el desarrollo de forma exponencial. Iteramos sobre modelos semana a semana. ¿Cómo llevas el ritmo de la gobernanza en ese contexto? Si el marco de gestión de riesgos de IA del NIST o la norma ISO 42001 describen procesos pensados para ciclos de madurez lentos, ¿qué pasa cuando tu sistema cambia cada semana?

El problema de fondo, que Beatriz confirmó, es que los modelos no son determinísticos. Le puedes hacer la misma pregunta diez veces y obtienes respuestas diferentes. Las pruebas que hiciste con un modelo no son válidas automáticamente para el siguiente. Y la documentación que refleja el comportamiento de un sistema en un momento concreto queda desactualizada tan pronto como el sistema evoluciona.

La solución que ella ha aplicado es usar IA para documentar y evaluar sus propios proyectos con IA. En el último modelo de gobernanza que implantó, construyó un agente de evaluación de riesgo entrenado no con información de internet, sino con la documentación interna de la organización: sus marcos éticos, sus criterios de riesgo, sus decisiones de diseño previas. Cuando un equipo manda la ficha de un nuevo proyecto, el agente lo evalúa según esos criterios y genera el primer borrador de la documentación de riesgo.

No te creas que lo he hecho yo sola. Me ha ayudado la IA, claro.

BEATRIZ G. POZO
Project Manager

Yo señalé que los sistemas de razonamiento no son determinísticos y no puedes cubrir todas las casuísticas. Su respuesta fue que la cobertura legal no requiere que el sistema sea perfecto sino que puedas demostrar que has intentado que lo sea. La batería de pruebas, el disclaimer al usuario y la supervisión continua son lo que la ley llama diligencia. Otro de nuestros compañeros ingenieros, Nacho Mangas, aportó un nuevo ángulo: dar al usuario una herramienta para reportar respuestas problemáticas genera retroalimentación gratuita además de cobertura legal. Es el mismo principio que hay detrás de los botones de feedback en los asistentes comerciales: el usuario hace testing de forma continua sin que nadie se lo pida.

Lo que me parece más interesante de este enfoque es que no es una carga añadida encima del trabajo de ingeniería, sino la misma lógica que hay detrás de los tests automatizados: no para garantizar que no habrá bugs, sino para demostrar que los buscamos antes de desplegar. Y así como nadie en el equipo discute si merece la pena escribir tests, la gobernanza de IA debería ocupar el mismo sitio mental.

El paso concreto que tengo en mente es definir qué documentación mínima se necesita al cierre de cada proyecto con IA, crear plantillas de evaluación de riesgo propias —como las que Beatriz construyó en Confluence y Notion— y, sobre todo, incorporar las pruebas negativas al proceso de desarrollo, no como paso final, sino como parte del ciclo desde el principio.

Si quieres explorar el marco completo que Beatriz presentó, puedes acceder a la presentación de la sesión o ver el vídeo a continuación.

Preguntas frecuentes

¿El Reglamento Europeo de IA afecta a empresas que solo usan IA internamente, sin exponerla a clientes?
Sí. El Reglamento aplica desde el momento en que los empleados usan herramientas de IA en su trabajo, aunque no haya ningún producto de cara al público. La obligación de formación de los empleados en el uso responsable de IA es uno de los requisitos que ya está en vigor.

¿Qué pasa si mi proyecto tiene riesgo alto? ¿Hay que cancelarlo?
No. El riesgo alto no prohíbe el proyecto: exige mayor rigor en la documentación y las medidas de mitigación. La clave está en identificar el riesgo, tomar medidas concretas para reducirlo y documentar ese proceso. La ley evalúa diligencia, no perfección.

¿Con qué nivel de documentación es suficiente para estar cubierto?
La ley no especifica un volumen ni un formato. Lo que pide es que puedas explicar qué hace tu sistema, por qué lo hace así, qué pruebas has realizado y qué medidas has tomado para reducir el riesgo. Un inventario actualizado, una batería de pruebas documentada y un proceso de revisión periódica cubre la mayor parte de los proyectos de riesgo limitado.