El CIO ante la IA: de administrar tecnología a orquestar capacidades

Durante años, el trabajo del CIO se midió por dos cosas: que la infraestructura funcionara y que los proyectos se entregaran a tiempo y dentro del presupuesto. Ese trabajo sigue existiendo, pero ya no alcanza para explicar el rol. Buena parte de la infraestructura se consume como servicio, los equipos de producto entregan de forma continua y la IA, en especial los agentes que actúan sobre sistemas, introduce decisiones que no caben en un plan de proyecto ni en un contrato de soporte.

A esto se suma que la IA no llega solo por el área de Tecnología. Llega por las herramientas de productividad que compran otras áreas, por funciones nuevas que los proveedores activan en servicios ya contratados y por equipos que prueban modelos por su cuenta. Si el CIO no ofrece un camino gobernado y rápido, la organización encuentra caminos propios, sin inventario, sin control de datos y sin nadie que responda por los resultados.

La pregunta que el directorio le hace hoy al CIO ya no es "¿funciona?", sino "¿qué capacidades tenemos, qué riesgo asumimos con ellas y qué valor producen?". Responderla exige otro modo de trabajo: menos administración directa de activos y más orquestación de capacidades que dependen de muchos actores. Este artículo propone qué significa eso en la práctica.

Qué cambia en el rol

Administrar es asegurar que un activo funcione. Orquestar es combinar capacidades que no controlas por completo (datos de otras áreas, plataformas de terceros, modelos de proveedores, agentes que actúan con cierta autonomía, personas con perfiles nuevos) para que produzcan un resultado de negocio con un riesgo aceptado. La diferencia no es semántica. Cambia lo que el CIO decide, lo que delega y lo que reporta.

Tres fuerzas empujan el cambio:

• La IA depende de capacidades transversales. Un caso de uso de IA útil necesita datos de calidad, integraciones gobernadas, una plataforma donde ejecutarse y personas que sepan supervisarlo. Si falta una, el caso no escala.
• El riesgo se desplaza. Con agentes que ejecutan acciones, el riesgo ya no está solo en la disponibilidad de un sistema, sino en la calidad de decisiones automatizadas. Eso exige gobierno explícito.
• El costo se vuelve variable. El consumo de modelos y de nube crece con el uso, no con un contrato anual. Sin disciplina financiera, el éxito de un caso de uso puede convertirse en un problema de presupuesto.

Un mapa de capacidades para orquestar

Recomendamos que el CIO gestione su área como un mapa de capacidades, no como un inventario de sistemas. El diagrama muestra una forma de organizarlo.

Cada capacidad tiene un dueño, un nivel de madurez y una hoja de ruta. El CIO no necesita operar todas directamente, pero sí responder por cómo se combinan. Algunas ya las cubrimos en detalle: los datos listos para IA y las integraciones antes que los agentes.

Responsabilidades: antes y ahora

La tabla resume cómo se desplazan las responsabilidades. No es una lista de tareas nuevas que se suman a las anteriores; es un cambio de énfasis.

Ámbito	Antes: administrar	Ahora: orquestar
Infraestructura	Operar centros de datos y servidores	Ofrecer plataformas internas de autoservicio sobre nube propia y de terceros
Proyectos	Entregar a tiempo y en presupuesto	Financiar capacidades y productos con resultados medibles
Datos	Custodiar bases de datos	Asegurar calidad, linaje y acceso gobernado para usos analíticos y de IA
Proveedores	Negociar contratos y SLA	Gestionar dependencias de modelos y servicios, con planes de salida
Automatización	Scripts y tareas programadas	Agentes con niveles de autonomía, permisos mínimos y auditoría
Talento	Cubrir puestos técnicos	Formar por roles y rediseñar trabajo junto con agentes
Riesgo	Disponibilidad y continuidad	Además, riesgo de decisiones automatizadas, sesgo, privacidad y costo variable

Decisiones que el CIO no delega

Orquestar implica delegar mucho: los equipos de plataforma deciden su arquitectura, los equipos de producto deciden sus prioridades, los proveedores operan sus servicios. Pero hay decisiones que recomendamos que el CIO retenga, porque comprometen a toda la organización:

1. Qué casos de uso de IA se aprueban y con qué nivel de autonomía máximo. La evaluación técnica se delega; la aprobación final de casos con impacto en clientes o en cumplimiento, junto con Riesgo, no.
2. La arquitectura de referencia. Qué plataformas, patrones de integración y servicios de modelos son estándar, y cuándo se acepta una excepción.
3. Las dependencias críticas de proveedores. Aceptar que un proceso crítico dependa de un único proveedor de modelos o de nube es una decisión de riesgo, no de compras.
4. La asignación de inversión entre capacidades. Cuánto va a datos, a plataforma, a talento y a nuevos casos de uso. Si se decide caso por caso, las capacidades transversales siempre pierden.
5. Cuándo apagar. Quién puede detener un agente o un servicio de IA y en qué condiciones. Ese criterio debe estar firmado antes de que haga falta.

ISO/IEC 38500 ayuda a ordenar esta frontera. Distingue el gobierno de la TI, a cargo del órgano de gobierno (evaluar, dirigir y supervisar), de su gestión. COBIT 2019 de ISACA hace una distinción similar entre objetivos de gobierno y objetivos de gestión. El CIO vive entre ambos: prepara las decisiones de gobierno para el directorio y responde por la gestión.

Cómo reportar al directorio

El directorio no necesita el estado de cada proyecto. Necesita entender qué capacidades tiene la organización, qué riesgos asume y qué valor obtiene. Recomendamos un reporte trimestral breve con cuatro bloques:

• Valor: resultados de negocio de los casos de uso en producción, comparados con lo que se prometió al aprobarlos.
• Riesgo: casos de uso de IA por nivel de autonomía, incidentes relevantes, excepciones abiertas y dependencias críticas de proveedores.
• Capacidades: madurez de cada capacidad del mapa y brechas que limitan nuevos casos de uso.
• Decisiones pedidas: lo que el directorio debe aprobar, con opciones y riesgos de cada una.

Conviene que el reporte use siempre la misma estructura y los mismos indicadores, para que el directorio vea tendencias y no fotos aisladas. Y que cada riesgo relevante llegue con una propuesta: aceptarlo, mitigarlo con un costo estimado o retirar el caso de uso. Un directorio que solo recibe alertas sin opciones termina frenando todo por precaución.

El NIST AI RMF ofrece un vocabulario útil para el bloque de riesgo, con sus funciones Gobernar, Mapear, Medir y Gestionar. Si la organización opera un sistema de gestión de IA según ISO/IEC 42001, el reporte puede alimentarse de su revisión por la dirección; lo explicamos en ISO/IEC 42001 en la práctica.

Indicadores que sirven

Un error frecuente es reportar actividad (cantidad de pilotos, modelos probados, personas formadas) en lugar de resultados. Proponemos indicadores agrupados por pregunta:

• ¿Produce valor? Casos de uso en producción con resultado medido frente a la línea base; tiempo desde la aprobación hasta la producción.
• ¿Está bajo control? Porcentaje de casos de uso de IA inventariados y con dueño; casos por nivel de autonomía; tiempo de respuesta a incidentes de IA.
• ¿Es sostenible? Costo unitario por caso de uso (por ejemplo, costo por transacción atendida) y su tendencia; concentración del gasto en un solo proveedor.
• ¿Tenemos la base? Fuentes de datos críticas con calidad medida; integraciones expuestas por APIs gobernadas; cobertura de formación por rol.

Pocos indicadores, con una definición escrita y un dueño cada uno, valen más que un tablero extenso que nadie revisa. El costo merece atención especial: el gasto en modelos y en cómputo crece con el uso, y conviene medirlo por unidad de valor desde el primer caso en producción. Lo desarrollamos en FinOps para IA.

Checklist para el primer año

Si asumes el rol o quieres reorientarlo, este orden suele funcionar:

1. Inventariar los casos de uso de IA existentes, incluidos los que nadie aprobó formalmente.
2. Publicar el mapa de capacidades con un dueño y un nivel de madurez por capacidad.
3. Acordar con Riesgo y Cumplimiento la escala de autonomía y el proceso de aprobación de casos de uso.
4. Definir la arquitectura de referencia para integraciones, plataformas y servicios de modelos.
5. Revisar contratos con proveedores críticos: datos, continuidad y plan de salida.
6. Instalar el reporte trimestral al directorio con los cuatro bloques.
7. Lanzar un plan de formación por roles y medir su cobertura.

Antes de presentar al directorio el marco de aprobación y los niveles de autonomía, conviene validarlos con Cumplimiento, Legal y Riesgo, porque fijan responsabilidades que la regulación puede exigir.