IA local: gobernanza antes de la compra de hardware
Benedikt Langer
10 min de lecturaCuatro desarrollos en dos semanas demuestran que la IA operada en local va mucho más ...
7 Min. Lectura
Quien adopta un modelo de IA en producción asume la responsabilidad de su comportamiento, sus riesgos y su mantenimiento. Que sea un modelo alemán nuevo desarrollado por un consorcio financiado, no cambia eso. El CIO no puede delegar esa responsabilidad en el origen o en una licencia abierta. La soberanía se evidencia en cómo una organización gestiona, controla y documenta el uso.
LO ESENCIAL EN BREVE
RELACIONADO:Nube Soberana: Cuándo el recargo realmente compensa / Muse Spark obliga a los CIOs a replantearse
Muchas organizaciones inician la evaluación de un nuevo modelo a partir del rendimiento. Así empiezan por el extremo equivocado. Primero deben contar con sus propias estructuras de gobernanza. Un modelo consorciado, como el que recientemente presentó el proyecto Soofi, surge de la unión de varias instituciones de investigación y empresas. La decisión de adoptarlo no recae solo en el área de TI; afecta a cumplimiento, al departamento legal y, al final, al consejo de administración.
El Reglamento de la Unión Europea sobre IA (EU AI Act) exige transparencia, clasificación de riesgos y supervisión humana. Estas obligaciones se aplican sin importar si el modelo proviene de un proyecto financiado públicamente. Las políticas internas deben determinar en qué casos de uso un modelo con madurez comercial limitada está autorizado a entrar en funcionamiento. Si falta esa definición, el conflicto aparecerá más adelante cuando un área funcional quiera usar el modelo en producción y la base legal no quede aclarada.
Además, está la responsabilidad. Un proveedor comercial establece límites de responsabilidad pactados contractualmente. En un consorcio la asignación resulta menos clara, ya que la responsabilidad se reparte entre varias instituciones. El director de tecnología (CIO) debería definir desde temprano qué riesgos asume la propia organización y cuáles pueden cubrirse mediante acuerdos.
Una licencia abierta desplaza la dependencia. No la elimina.
Integrar una infraestructura IT existente es más que una cuestión de compatibilidad técnica. Se trata de definir quién se encarga de la disponibilidad, de los parches de seguridad y de adaptar el sistema a nuevas exigencias. Un consorcio de investigación no está pensado para un soporte operativo a largo plazo. Los fondos del Ministerio de Economía y los de la UE dejan de fluir en una fecha determinada. Después, alguien debe asumir la responsabilidad.
En la práctica, muchos equipos parten de la suposición de que la licencia abierta les permite continuar el modelo por su cuenta. Sin capacidades propias para ajustes finos, auditorías de seguridad y monitoring, rápidamente se crea una nueva dependencia. Esta vez no se dirige contra un proveedor único, sino contra la continuidad de las instituciones involucradas o la disposición de una comunidad para mantener el modelo.
El punto ciego
La disponibilidad no es control. Hacer que un modelo funcione en un centro de datos propio no significa que lo domines. Sin monitoreo de los flujos de datos, sin control de versiones y sin un camino de escalamiento definido, la soberanía queda solo en papel.
La soberanía implica que la organización decida por sí misma cómo se implementa el modelo, qué datos procesa y cuándo se adapta o sustituye. Para ello se necesitan roles y procesos que sustenten esas decisiones. A menudo la competencia recae en pocos especialistas de TI. El área funcional conoce los requisitos, el consejo directivo los riesgos estratégicos. Sin una distribución clara de roles aparecen precisamente esas lagunas.
Los problemas de estructura se manifiestan cuando no se define una instancia que decida sobre el uso en un nuevo caso de aplicación. Los problemas de personal se presentan cuando un experto individual se ausenta y nadie puede asumir la responsabilidad. Ambos deben abordarse simultáneamente. El desarrollo de capacidad de control, por tanto, requiere dos cosas: derechos de decisión definidos y un desarrollo focalizado de competencias en los equipos que sostienen el modelo.
El proyecto Soofi indica como objetivo la plena control sobre datos, procedencia e infraestructura. Para el usuario eso significa verificar si esa control llega a la propia organización. Adoptar un modelo de un consorcio sin crear mecanismos propios de supervisión de flujos de datos y versiones del modelo solo traslada la dependencia a otro lugar.
Revisión, supervisión y clientes preguntan cada vez más cómo una organización ejerce realmente el control sobre sus sistemas de IA. La afirmación de que un modelo es soberano solo porque se desarrolló en Europa no basta en una auditoría. El CIO debe poder demostrar qué datos entraron en el entrenamiento, cómo se documentan los cambios y qué mecanismos de control están en vigor durante la operación.
En particular, cuando los modelos provienen de contextos de investigación, la documentación de los datos de entrenamiento y los procedimientos suele carecer del nivel de detalle que exige una auditoría. Esta brecha también fue señalada por la comunidad especializada en el informe Soofi. Para el usuario queda la cuestión de si puede verificar de forma independiente la información del consorcio y qué conclusiones extraer para su propia evaluación de riesgos.
Sin pruebas sólidas ante auditorías internas o externas, la soberanía se queda en una afirmación. Por eso, la creación de rastros de auditoría y la capacidad de ofrecer información detallada bajo demanda deben formar parte de la planificación desde el inicio. En sectores regulados, donde la supervisión exige pruebas concretas, este aspecto determina la autorización.
¿Qué es la Gobernanza de IA? KI-Governance es el marco vinculante que establece derechos de decisión, criterios de riesgo, obligaciones de documentación y puntos de control, definiendo quién decide la selección, el uso y la retirada de un modelo y quién asume la responsabilidad en caso de incidente. Sin este marco, el despliegue resulta incontrolable y no demostrable en una auditoría. Esto se aplica tanto a un modelo de consorcio como a un proveedor comercial.
El principal argumento en contra pesa mucho: un modelo públicamente financiado, con licencia permisiva desarrollado por un amplio consorcio europeo supone ya un avance frente a alternativas propietarias. Reduce la dependencia de proveedores extranjeros y permite la personalización propia. Este argumento se mantiene mientras la alternativa ofrezca realmente menos control. Sólo se pasa por alto un detalle: la disponibilidad formal de un modelo no implica automáticamente que la organización disponga de control operativo. Precisamente ese control debe generar el CIO.
En los primeros 30 días, un equipo integrado por profesionales de TI, Legal, Cumplimiento y un representante del área especializada elabora un catálogo de criterios. Este documento recoge los requisitos que deben cumplirse en la propia organización en cuanto a procedencia de los datos, procesos de actualización, rutas de escalado y evidencias. El CIO actúa como patrocinador, mientras que la dirección operativa recae en el CISO.
Durante los siguientes 30 días, se desarrolla una matriz de dependencias de los usos actuales de IA. Por cada sistema, esta matriz identifica al propietario funcional, el nivel de escalado en caso de incidencia y la presencia o ausencia de pruebas sobre el origen de los datos y su control. La matriz revela en qué áreas aún no se ha designado a nadie que asuma la responsabilidad en caso de duda.
En los últimos 30 días, se definen las primeras medidas contractuales y organizativas para un escenario piloto seleccionado. Entre ellas, se incluye aclarar quién debe ser capaz de actuar en un plazo de 48 horas ante un cambio de modelo o una vulnerabilidad de seguridad, así como cómo demostrar esa capacidad de actuación.
En un modelo de un consorcio de investigación, las preguntas de responsabilidad suelen estar menos definidas que con proveedores comerciales. La organización debe evaluar en qué medida asume la responsabilidad por daños derivados del comportamiento del modelo. Los contratos con los socios del consorcio solo ayudan en cierta medida, ya que la responsabilidad se reparte entre varias instituciones.
Comienza definiendo roles y procesos de decisión y puede extenderse durante varios meses hasta un año, dependiendo de la situación inicial. La integración técnica es más rápida. La capacidad de evaluar, supervisar y, si fuera necesario, sustituir un modelo por uno propio requiere un desarrollo específico de competencias y experiencia práctica.
Una beta cerrada significa que el modelo aún no se ha puesto a disposición del público en general y que su arquitectura, comportamiento y soporte aún pueden modificarse. Quienes lo evalúan deben aclarar qué garantías de desarrollo y soporte se aplican más allá de la beta. Sin esas garantías, el uso productivo conlleva una alta incertidumbre.
Más del medio MBF Media Netzwerk
Más para leer en Digital Chiefs
Digital ChiefsCinco lugares donde se rompe el software de la cadena de suministroDigital ChiefsServicios gestionados: La factura que nadie hace públicaDigital ChiefsCuando el taller y el centro de cómputo se convierten en una redFuente de la imagen: Generada por IA (julio 2026)