Servicios de Ciberseguridad Gestionados: El CISO no asume la responsabilidad exclusiva
Benedikt Langer
8 Min. de lectura En muchas empresas, el CISO es considerado la persona responsable de la seguridad. ...
7 Min. de lectura
El 37 por ciento de los CIO afirman tener visibilidad completa sobre todas las herramientas de IA en su organización. El resto toma decisiones de gobernanza sobre un sistema que no comprenden completamente. La IA autónoma agrava este vuelo a ciegas: cuando los modelos toman decisiones por sí mismos, a menudo no solo falta la explicabilidad, sino también el camino completo de la decisión.
Lo más importante en resumen
Relacionado:CIOs bajo presión: el 62 por ciento en gobernanza de IA / Informe CIO de Logicalis 2026: solo el 37 por ciento tiene visibilidad completa
¿Qué es la IA autónoma? Un sistema de IA se considera autónomo cuando toma decisiones operativas o desencadena acciones sin que un humano revise cada caso individual. El criterio no es la tecnología, sino el proceso: decisiones de crédito, detección de anomalías en instalaciones de producción o preselección de personal pueden funcionar de manera autónoma – si lo hacen o no, lo decide la arquitectura, no el modelo.
La IA autónoma toma decisiones. Ese es el punto. No: la IA apoya decisiones – ese es el lenguaje de la fase piloto. La pregunta «¿Tenemos una gobernanza de IA?» a menudo llega uno o dos años después de la pregunta «¿Tenemos IA autónoma?». Esa es la verdadera brecha.
El EU AI Act categoriza los sistemas en clases de riesgo. Las aplicaciones de alto riesgo – decisiones de crédito, herramientas de personal, infraestructura crítica – requieren documentación de transparencia, pruebas regulares y supervisión humana. Esto suena a cumplimiento. Pero primero es una cuestión de ingeniería: ¿quién tiene una visión general de lo que se decide y quién puede rastrearlo?
El primer problema es el Shadow AI. Los empleados utilizan herramientas de IA a través de extensiones de navegador, cuentas SaaS y accesos API que nunca aparecen en la adquisición de TI. Esto no es malicia, es eficiencia. Cuando estas herramientas toman decisiones o proporcionan bases para decisiones, no existen para fines de gobernanza.
Tres preguntas aclaran el riesgo: ¿Hay resultados generados por IA que se incluyen en procesos empresariales documentados sin estar marcados como generados por IA? ¿Se facturan los accesos a herramientas de IA a través de cuentas personales para evitar la adquisición de TI? ¿Ha descubierto el departamento de TI en los últimos seis meses una herramienta de IA de la que no sabía nada antes? Un «sí» es suficiente: entonces la gobernanza falla estructuralmente demasiado tarde.
El segundo problema es la confusión entre explicabilidad y auditoría. Los métodos XAI como SHAP o LIME explican por qué un modelo ha tomado una decisión en un caso específico. Esto es útil, pero no es una auditoría. Una auditoría documenta: ¿Qué modelo, qué versión, qué datos, qué marca de tiempo, quién utilizó la decisión? En la práctica, los CIO implementan XAI y creen que la explicabilidad está resuelta.
La explicabilidad es una característica. La trazabilidad es un requisito. Ambas se confunden con demasiada frecuencia en el contexto de la gobernanza.
El tercer problema llega más tarde, pero golpea más fuerte: el bloqueo del proveedor en los modelos de IA. Quien ajusta un modelo de base de un proveedor de cloud tiene pesos propietarios en una infraestructura propietaria. Un cambio significa exportación de datos, reentrenamiento, validación, recertificación. En sistemas de alto riesgo, esto suele tardar entre seis y dieciocho meses. Esto no es un problema en la fase piloto. Se convierte en un problema cuando un proveedor cambia las condiciones o ya no cumple con los requisitos de cumplimiento.
El Reglamento de IA prescribe para los sistemas de alto riesgo: documentación técnica, sistema de gestión de riesgos, documentación del conjunto de datos, registro, supervisión humana, métricas de precisión. Este es el marco regulatorio mínimo.
Lo que no proporciona el Reglamento de IA: un marco de gobernanza para la organización detrás de él. ¿Quién es responsable internamente de un sistema de alto riesgo? ¿Qué proceso decide si una nueva herramienta de IA es de alto riesgo? ¿Qué sucede si un sistema se utiliza para una nueva aplicación que posteriormente se clasifica como de alto riesgo? Estas preguntas debe responderlas cada organización por sí misma. El Reglamento de IA es la barrera de entrada, no el marco.
Lo que ayuda estructuralmente
Lo que es teatro de gobernanza
La primera: ¿Qué decisiones toma el sistema y con qué consecuencias? No: «¿Qué problema resuelve?» Sino: ¿Qué pasa si el sistema se equivoca? ¿Quién asume las consecuencias: legal, operativa y reputacionalmente?
La segunda: ¿Quién puede detener la decisión? Todo sistema autónomo necesita un camino de escalada definido. Sin camino significa: la decisión se toma hasta que ocurra algo grave.
La tercera: ¿Cuánto tiempo se tarda en reemplazar el sistema? Responder a esta pregunta antes de que el sistema esté en uso. Después, la respuesta es irrelevante.
Los registros de riesgo para IA autónoma son útiles si alguien realmente los consulta y si las preguntas en ellos apuntan a sistemas concretos, no a categorías abstractas. El NIST AI Risk Management Framework proporciona aquí una introducción práctica que va más allá del estándar mínimo del AI Act.
Un sistema se considera autónomo cuando toma decisiones o desencadena acciones sin que una persona revise cada caso individual. El criterio no es la tecnología, sino el proceso: si un empleado adopta rutinariamente la decisión del sistema sin revisarla en cuanto a su contenido, el sistema opera de facto de manera autónoma.
El Anexo III del AI Act enumera ocho áreas: identificación biométrica, infraestructura crítica, educación, empleo, servicios esenciales, aplicación de la ley, gestión de fronteras, justicia. Dentro de estas áreas, depende del propósito concreto de uso. La mayoría de las empresas subestiman cuántas de sus herramientas internas están potencialmente afectadas.
Los métodos XAI (SHAP, LIME, Counterfactuals) explican por qué un modelo tomó una decisión en un caso concreto. Un Audit-Trail, por otro lado, documenta todo el camino de la decisión: versión del modelo, datos de entrada, marca de tiempo, persona que lo usa. Ambos son necesarios; uno no reemplaza al otro. Los CIO que solo usan XAI no tienen una trazabilidad adecuada para el cumplimiento.
Primero: inventariar en lugar de sancionar. Los empleados usan herramientas de IA por razones de eficiencia, no para sabotear las directrices de TI. Un enfoque pragmático combina procesos regulares de auto-divulgación (reporte trimestral de herramientas), monitoreo de extensiones del navegador y comunicación clara sobre qué herramientas están aprobadas. Las políticas de tolerancia cero sin alternativas empujan la IA en la sombra a una mayor invisibilidad.
Cuatro pasos en este orden: (1) Crear un inventario de IA: todos los sistemas utilizados, responsables, propósito de uso. (2) Clasificación de riesgos según el AI Act: ¿qué sistemas caen en categorías de alto riesgo? (3) Asignar propiedad: un nombre por sistema, no «el departamento de TI». (4) Establecer ciclos de revisión: actualización trimestral del inventario, revisión anual de riesgos, revisión inmediata en caso de cambios en el sistema o su uso.
Fuente de la imagen: Pexels / Vlada Karpovich