En la parte anterior de nuestra serie respondimos a la pregunta, cuándo la IA puede operar de forma autónoma y cuándo necesita a una persona.
Mostramos que el nivel de autonomía debe depender, entre otras cosas, de:
- el riesgo,
- el coste del error,
- la reversibilidad de la decisión,
- el impacto en las personas,
- la calidad de los datos,
- la capacidad de supervisar el sistema.
También sabemos que simplemente añadir a una persona al proceso no garantiza la seguridad.
Puede haber un empleado que apruebe las decisiones de la IA, pero no darle tiempo suficiente para analizarlas. Se puede requerir aprobación, pero no mostrar por qué el sistema tomó una decisión concreta. Se puede crear un sistema que funcione bien durante un año y luego empiece a generar resultados incorrectos porque han cambiado los datos, el comportamiento de los usuarios o las condiciones del mercado.
Por eso, en cierto momento surge una pregunta mucho mayor que: "¿La IA funciona correctamente?"
Suena así: "¿Como organización somos capaces de controlar la IA que hemos desplegado?"
Y eso es exactamente de lo que se ocupa la Gobernanza de IA.
¿Qué es la Gobernanza de IA?
La Gobernanza de IA puede describirse, de forma simple, como el sistema de normas, procesos, responsabilidades y mecanismos de control relativos al uso de la inteligencia artificial en una organización.
No es un único documento. No es un único procedimiento. Tampoco es exclusivamente un asunto legal.
Una gobernanza madura de IA abarca muchas áreas:
- estrategia de uso de la IA,
- seguridad,
- protección de datos,
- gestión de riesgos,
- cumplimiento regulatorio,
- responsabilidad,
- monitorización de modelos,
- control de accesos,
- auditoría,
- gestión de cambios,
- respuesta a incidentes.
Se puede decir, por tanto, que la Gobernanza de IA responde a la pregunta: "¿Cómo conseguir que la inteligencia artificial actúe conforme a los objetivos de la organización, a las normas aplicables y a un nivel de riesgo aceptable?"
Esto es especialmente importante cuando la IA deja de ser una herramienta individual usada por un empleado y empieza a ser parte de los procesos de negocio.
La Gobernanza de IA no es un freno a la innovación
Uno de los malentendidos más comunes es tratar la gobernanza como burocracia.
En ese enfoque surge el miedo: "Si creamos demasiadas reglas, nadie querrá implementar IA."
El problema es que la ausencia de reglas también tiene su coste.
Imaginemos una empresa en la que:
- cualquier empleado puede usar cualquier herramienta de IA,
- nadie sabe qué datos llegan a los modelos,
- no se sabe qué procesos están automatizados,
- no existe un inventario de modelos utilizados,
- nadie monitoriza los resultados,
- nadie responde por los errores.
Al principio todo puede funcionar muy bien. Hasta que ocurre algo imprevisto.
Por tanto, la Gobernanza de IA no debería bloquear la IA. Debe crear marcos seguros en los que la IA pueda desarrollarse más rápido.
Una gobernanza bien diseñada permite responder a:
- qué podemos hacer,
- qué no podemos hacer,
- quién toma las decisiones,
- quién es responsable del sistema,
- cómo monitorizamos el riesgo,
- qué hacemos cuando algo sale mal.
No es un freno. Es un cinturón de seguridad.
¿Quién es responsable de la decisión de la IA?
Esta es una de las preguntas más difíciles.
Supongamos que un sistema de IA recomienda rechazar la solicitud de un cliente. ¿Quién es responsable de esa decisión? ¿El programador? ¿El proveedor del modelo? ¿La empresa que desplegó el sistema? ¿La persona que aprobó la recomendación? ¿El manager responsable del proceso? ¿O quizá la dirección?
La respuesta no siempre es sencilla...
Por eso la responsabilidad debe definirse antes del despliegue del sistema, y no sólo después de que ocurra un problema.
En la práctica, la organización debería definir claramente:
- quién es el propietario del proceso,
- quién es el propietario del sistema,
- quién responde por los datos,
- quién responde por el modelo,
- quién aprueba los cambios,
- quién monitoriza la operación,
- quién puede detener el sistema,
- quién toma decisiones en situaciones de emergencia.
En sistemas de IA complejos no basta con decir: "Lo hizo la inteligencia artificial."
La IA no es el sujeto responsable del proceso de negocio. La responsabilidad sigue recayendo en las personas y en la organización.
La Gobernanza de IA comienza por un inventario
Uno de los primeros pasos debería ser crear un AI Inventory, es decir, un registro de los sistemas y usos de IA empleados en la organización.
¿Suena banal? — En muchas empresas puede resultar sorprendentemente difícil.
Los empleados usan:
- ChatGPT,
- herramientas de generación de contenido,
- IA en sistemas CRM,
- herramientas de análisis de documentos,
- asistentes para desarrolladores,
- automatizaciones,
- agentes de IA.
Algunas de estas soluciones pueden estar oficialmente desplegadas por la empresa. Otras pueden ser usadas por empleados sin el conocimiento formal de la organización.
Este fenómeno se conoce a menudo como Shadow AI.
Shadow AI - cuando la IA opera fuera del control de la empresa
Shadow AI es el equivalente del conocido concepto de Shadow IT. Un empleado encuentra una herramienta que le ayuda a hacer su trabajo más rápido y empieza a usarla.
Nadie controla:
- qué datos se envían,
- dónde se procesan,
- quién tiene acceso a ellos,
- cuánto tiempo se almacenan,
- si la información puede usarse para entrenar modelos.
Desde la perspectiva del empleado todo parece genial. Desde la de la organización puede surgir un riesgo serio.
Por eso prohibir el uso de la IA no siempre es la mejor solución. Un enfoque mucho mejor es crear reglas claras.
El empleado debe saber:
- qué herramientas puede usar,
- qué datos no se pueden enviar,
- cuándo se requiere aprobación,
- qué soluciones recomienda la empresa.
Es mejor crear una vía segura para el uso de la IA que pretender que los empleados no la van a usar.
Datos - el fundamento de una IA responsable
No se puede hablar de gobernanza sin hablar de datos. Un sistema de IA puede ser muy bueno.
Pero si los datos son:
- erróneos,
- desactualizados,
- incompletos,
- inconsistentes,
- mal etiquetados,
los resultados del sistema también pueden ser problemáticos.
En la organización deberían existir reglas claras sobre:
- las fuentes de datos,
- la calidad de los datos,
- el acceso,
- el almacenamiento,
- la retención,
- la eliminación,
- la anonimización,
- la seudonimización,
- el control del uso de los datos.
La protección de datos personales tiene aquí un papel especial.
No toda la información que posee la empresa debería llegar a un modelo de IA.
E incluso si puede procesarse, hay que saber:
- ¿para qué?
- ¿en base a qué fundamento?
- ¿cómo?
- ¿durante cuánto tiempo?
- ¿quién tiene acceso?
Por eso la implantación de IA debería diseñarse de forma conjunta entre equipos tecnológicos, de negocio, legales y de seguridad.
AI Act - ¿por qué deberían interesarse las empresas?
En la Unión Europea el desarrollo de la inteligencia artificial también es objeto de regulación.
El ejemplo más importante es el AI Act, el reglamento europeo sobre inteligencia artificial. Uno de los elementos clave de este enfoque es la clasificación de los sistemas de IA según su nivel de riesgo.
A grandes rasgos podemos hablar de:
- sistemas que suponen un riesgo inaceptable,
- sistemas de alto riesgo,
- sistemas sujetos a ciertas obligaciones de transparencia,
- sistemas de riesgo limitado o mínimo.
Esto no significa que toda empresa deba crear un gran departamento de compliance.
Significa, sin embargo, que las organizaciones deben saber qué tipo de sistemas de IA usan y qué obligaciones pueden derivarse de ello.
También conviene recordar que la regulación no se aplica solo al modelo en sí. También importa el uso que se hace de la IA.
El mismo modelo puede emplearse para generar descripciones de producto o para apoyar un proceso que afecta a derechos humanos. La tecnología es la misma. El riesgo, completamente distinto.
Por eso la gobernanza debe analizar sobre todo el uso del sistema, no solo su nombre o su fabricante.
Explainable AI - ¿por qué el sistema debe poder explicarse?
Si la IA toma decisiones que afectan al negocio o a las personas, es natural preguntarse: "¿Por qué?"
¿Por qué el sistema consideró sospechosa la transacción?
¿Por qué rechazó el documento?
¿Por qué propuso un precio concreto?
¿Por qué derivó al cliente a un proceso determinado?
Aquí surge el concepto de Explainable AI (XAI). Es el conjunto de métodos y enfoques que ayudan a entender cómo el modelo llegó a un resultado. No siempre significa mostrar todo el proceso interno del modelo.
A veces basta presentar:
- los factores clave que influyeron en el resultado,
- los datos usados para el análisis,
- el nivel de confianza,
- las premisas más importantes,
- escenarios alternativos.
Para el usuario de negocio esto suele ser más relevante que una descripción técnica del modelo.
Logging - la memoria del sistema de IA
Si la IA toma decisiones, la organización debería ser capaz de reproducir lo que ocurrió. Por eso el registro (logging) es tan importante.
Según el tipo de sistema conviene registrar:
- cuándo se realizó la operación,
- qué modelo se usó,
- qué versión del modelo estaba activa,
- qué datos de entrada se usaron,
- qué resultado se generó,
- qué decisión se tomó,
- si una persona aprobó el resultado,
- si la decisión fue modificada,
- quién realizó el cambio.
Esto permite responder a la pregunta: "¿Qué ocurrió exactamente en el sistema?"
Sin un logging adecuado el análisis de un incidente puede ser muy difícil. Y en sistemas autónomos, incluso imposible.
Monitorización - la IA no es un "instala y olvida"
Esta es una de las piezas más importantes del puzle.
Un modelo puede funcionar correctamente el día del despliegue. Eso no significa que vaya a hacerlo igual dentro de un año.
Cambian:
- los datos,
- el comportamiento de los usuarios,
- las condiciones del mercado,
- los productos,
- los procesos,
- la regulación.
También puede cambiar el propio funcionamiento del sistema. Por eso hay que monitorizar no solo la infraestructura técnica, sino también la calidad de las decisiones.
Según el uso conviene observar:
- la precisión,
- el número de errores,
- el nivel de confianza,
- el porcentaje de decisiones derivadas a una persona,
- el número de intervenciones humanas,
- el número de reclamaciones,
- las discrepancias entre la recomendación de la IA y la decisión del experto.
Si de pronto la gente empieza a rechazar el 40% de las recomendaciones de la IA en lugar del 5% anterior, puede ser una señal de que algo ha cambiado.
El modelo sigue funcionando, pero su valor para el negocio ya no es el mismo.
Model Drift - cuando el mundo cambia más rápido que el modelo
Un problema importante es el model drift, es decir, el deterioro del rendimiento del modelo debido a cambios en los datos o en el entorno donde opera.
¿Ejemplo?
Un modelo predice la demanda de productos basándose en datos de los últimos cinco años.
De repente cambia el comportamiento de los consumidores.
Surge una nueva tendencia.
Cambia la situación económica.
El modelo sigue usando los patrones históricos.
El problema es que la realidad ya no es la misma.
La IA no "sabe" que la realidad ha cambiado.
Por eso el sistema debe monitorizarse y los modelos evaluarse periódicamente y, si es necesario, actualizarse.
Guardrails - límites que la IA no debe traspasar
En la parte anterior mencionamos los guardrails. En el contexto de la Gobernanza de IA su importancia es aún mayor.
Los guardrails pueden definir:
- qué datos puede usar la IA,
- qué acciones puede realizar,
- qué acciones no puede realizar,
- qué valores puede modificar,
- cuándo se requiere la aceptación humana,
- cuándo el sistema debe detenerse.
Por ejemplo, un agente de IA puede tener acceso al sistema de pedidos. Puede comprobar la disponibilidad de un producto. Puede preparar un pedido. Pero no puede aprobar por sí solo una compra superior a 10.000 PLN. Si la cantidad supera el límite, el sistema deriva el asunto a una persona.
Este es un ejemplo de un límite de autonomía bien diseñado.
Kill Switch - el sistema debe tener un botón STOP
Parece obvio. Pero es extremadamente importante.
Cualquier sistema autónomo debe disponer de un mecanismo de parada de emergencia.
Si:
- el modelo comienza a generar decisiones erróneas,
- el sistema realiza operaciones atípicas,
- surge un incidente de seguridad,
- los datos de entrada son incorrectos,
la organización debe poder detener el funcionamiento del sistema. No mañana. No tras abrir un ticket con soporte. ¡De inmediato!
Dependiendo de la arquitectura, esto puede significar:
- apagar el agente,
- bloquear el acceso a herramientas,
- parar el workflow,
- pasar a modo manual,
- hacer rollback a una versión anterior.
La autonomía sin la posibilidad de detenerse es muy arriesgada.
Respuesta a incidentes para IA
Las organizaciones llevan años teniendo procedimientos para reaccionar ante fallos de sistemas.
Con la IA necesitamos además escenarios específicos para decisiones erróneas de modelos.
¿Qué hacemos si:
- la IA empieza a generar recomendaciones incorrectas?
- un agente ejecuta acciones equivocadas?
- el modelo exhibe comportamientos no deseados?
- las entradas resultan ser erróneas?
- el sistema viola las reglas establecidas?
Debe existir un proceso claro: Detección → paro → análisis → corrección → restauración → monitorización
Esto es crucial especialmente en sistemas que operan de forma autónoma.
¿Quién debería responsabilizarse de la IA en la organización?
No hay una respuesta universal.
Según el tamaño de la empresa pueden participar:
- la dirección,
- el CTO,
- el CIO,
- el CISO,
- el departamento legal,
- compliance,
- Data Protection Officer,
- propietarios de procesos,
- equipos de IT,
- data scientists,
- ingenieros de ML,
- product managers,
- usuarios de negocio.
Es importante, sin embargo, que la responsabilidad no quede difusa.
"La IA es cosa de todos" suele significar en la práctica: "Nadie es responsable."
Por eso toda iniciativa relevante de IA debe tener un propietario claramente definido.
RACI para sistemas de IA
Una buena herramienta puede ser el clásico modelo RACI.
Permite definir:
Responsible - ¿quién ejecuta la tarea?
Accountable - ¿quién asume la responsabilidad última?
Consulted - ¿a quién se debe consultar?
Informed - ¿a quién se debe informar?
Por ejemplo, para un sistema de IA que soporte atención al cliente:
- IT es responsable de la infraestructura,
- el equipo de datos de los datos,
- el propietario del proceso del uso de la IA,
- compliance de la evaluación de requisitos regulatorios,
- el negocio de la aceptación de la solución.
Así, ante un problema se sabe quién debe reaccionar.
Gobernanza de IA en una empresa pequeña
La Gobernanza de IA no tiene por qué implicar crear un gran comité.
Una pequeña empresa puede empezar con algunos elementos sencillos:
1. Lista de herramientas de IA
Saber qué usamos.
2. Reglas sobre datos
Saber qué no se puede enviar a herramientas externas.
3. Clasificación de riesgos
Definir qué usos son de bajo, medio o alto riesgo.
4. Propietario de la IA
Nombrar a una persona responsable de la coordinación.
5. Reglas Human-in-the-Loop
Definir cuándo la decisión requiere a una persona.
6. Monitorización
Comprobar que el sistema sigue funcionando según lo previsto.
Esto ya es mucho.
Lo más importante es la conciencia.
Gobernanza de IA en una gran organización
En una empresa grande la situación es más compleja.
Puede necesitarse:
- un AI Governance Board,
- registro de modelos,
- clasificación de riesgos,
- un proceso de aprobación para nuevos usos,
- política de datos,
- monitorización de modelos,
- auditorías,
- procedimientos de incidentes,
- control de accesos,
- gestión de proveedores de IA,
- revisiones periódicas.
En grandes organizaciones la gobernanza debe además integrarse con procesos existentes:
- IT Governance,
- Security Governance,
- Data Governance,
- Risk Management,
- Compliance.
La IA no funciona en el vacío.
Se convierte en otro elemento del ecosistema de gestión de la organización.
Errores más comunes en la Gobernanza de IA
Error 1 - la gobernanza aparece solo tras el despliegue
Primero desplegamos IA.
Luego nos preguntamos quién es responsable.
Eso es al revés.
Error 2 - la gobernanza se limita a un documento
La política de IA por sí sola no resuelve nada.
Si nadie la aplica, solo queda un documento.
Error 3 - la responsabilidad recae solo en TI
La IA afecta a negocio, derecho, seguridad y personas.
No puede ser únicamente un problema del área tecnológica.
Error 4 - falta de monitorización
Se despliega un modelo.
Todos lo olvidan.
Al cabo de un año resulta que el sistema funciona de modo totalmente distinto al inicial.
Error 5 - falta de posibilidad de parar la IA
Si un sistema opera de forma autónoma pero nadie puede detenerlo con rapidez, la organización no controla el sistema.
Checklist práctica de Gobernanza de IA
¿Debería la organización tener:
☐ un registro de los sistemas de IA usados,
☐ un propietario definido para cada sistema significativo,
☐ una clasificación del nivel de riesgo,
☐ reglas sobre datos,
☐ una política de uso de IA,
☐ reglas sobre Shadow AI,
☐ mecanismos de control de acceso,
☐ logging de las actuaciones del sistema,
☐ monitorización de la calidad,
☐ un procedimiento de respuesta a incidentes,
☐ la capacidad de detener el sistema,
☐ reglas Human-in-the-Loop,
☐ revisiones periódicas de modelos,
☐ evaluación de requisitos regulatorios,
☐ reglas claras de responsabilidad.
Si la mayoría de las respuestas son "no", la empresa probablemente no tiene una Gobernanza de IA madura todavía.
Glosario
Gobernanza de IA
Conjunto de normas, procesos, responsabilidades y mecanismos de control relativos al diseño, despliegue y uso de la inteligencia artificial.
Shadow AI
Uso informal o no autorizado por parte de empleados de herramientas de IA fuera del proceso oficial de gestión de la organización.
AI Inventory
Registro de sistemas, modelos y usos de IA empleados en la organización.
Model Drift
Deterioro del rendimiento del modelo debido a cambios en los datos o en el entorno en que opera.
Explainable AI (XAI)
Enfoque y métodos que permiten comprender mejor los factores que influyen en los resultados de los modelos de IA.
AI Audit
Evaluación de un sistema de IA en cuanto a su funcionamiento, seguridad, cumplimiento, calidad de datos, riesgo y el cumplimiento de requisitos concretos.
Guardrails
Límites que definen qué acciones puede y no puede realizar un sistema de IA.
Kill Switch
Mecanismo que permite detener rápidamente un sistema o limitar su funcionamiento en una emergencia.
AI Incident
Evento relacionado con un sistema de IA que puede conducir a errores, vulneraciones de seguridad, incumplimientos u otras consecuencias indeseadas.
Conclusión principal
Human-in-the-Loop nos dice: "La persona debe seguir siendo parte del proceso."
La Gobernanza de IA va un paso más allá.
Dice: "La organización debe saber cómo controlar ese proceso."
Esa es una diferencia fundamental.
Podemos crear el agente de IA más avanzado. Podemos darle acceso a sistemas. Podemos permitirle planificar y ejecutar acciones.
Pero si no sabemos:
- qué hace,
- por qué lo hace,
- quién es responsable,
- con qué datos opera,
- cuándo empieza a fallar,
- cómo detenerlo,
no hemos creado un sistema inteligente; hemos creado un sistema que no sabemos controlar.
Y en un mundo de agentes cada vez más autónomos, ese control puede convertirse en una de las ventajas competitivas más importantes de una organización.
En la última, cuarta parte de la serie pasaremos de las reglas a la arquitectura.
Mostraremos cómo puede ser un sistema de IA diseñado pensando en la seguridad, el control y la responsabilidad: desde el modelo y el agente, pasando por la capa de decisión y las reglas de negocio, hasta el workflow, la monitorización, la posibilidad de anulación humana y los mecanismos de emergencia.
Porque, al final, la pregunta más importante no es: "¿Sabemos construir un agente de IA autónomo?"
Hoy en día cada vez más a menudo sí sabemos hacerlo.
La cuestión es: "¿Sabemos construir un agente sobre el que aún mantengamos el control?"
