Los centros de datos de IA se están convirtiendo en el nuevo problema de IA en la sombra
La gobernanza de IA está bajando en la pila.
Durante los últimos dos años, la mayoría de los programas de riesgo de IA empresarial se han centrado en la capa visible: quién usa ChatGPT, qué equipos compran copilotos, qué datos pegan los empleados en los prompts y qué herramientas SaaS tienen funciones de IA activadas por defecto.
Ese trabajo sigue siendo importante. Pero ya no es suficiente.
NIST actualizó esta semana su página del programa de IA con un énfasis más claro en asegurar los centros de datos de IA, incluyendo un taller en julio sobre arquitectura, postura de seguridad y estándares emergentes. La agenda no es solo sobre edificios llenos de GPUs. Incluye explícitamente entrenamiento de modelos de IA, inferencia, flujos de trabajo de IA agente, control de acceso, software, hardware, almacenamiento de datos, cadena de suministro, tecnología operativa, seguridad del personal y desafíos regulatorios.
Esa es la dirección correcta, porque el riesgo ha cambiado. La IA empresarial ya no es solo una categoría de aplicaciones. Está convirtiéndose en infraestructura.
Y las fallas en infraestructura son diferentes.
El antiguo modelo de gobernanza de IA era demasiado centrado en aplicaciones
La mayoría de las organizaciones todavía tratan la gobernanza de IA como un problema de inventario de software.
Preguntan:
- ¿Qué herramientas de IA están aprobadas?
- ¿Qué proveedores han pasado la revisión de seguridad?
- ¿Qué empleados usan IA no aprobada?
- ¿Qué tipos de datos están permitidos en los prompts?
- ¿Qué contratos incluyen restricciones para entrenamiento de modelos?
Son buenas preguntas, pero solo cubren la superficie visible para el usuario.
La próxima generación de riesgos de IA está debajo de esas preguntas. Vive en el entorno de cómputo, capa de enrutamiento de modelos, almacenes vectoriales, marcos de orquestación, puertas de enlace API, proveedores de identidad, permisos de agentes, ecosistemas de plugins, registros, sistemas de memoria y pipelines de recuperación.
Una empresa puede tener una lista limpia de aplicaciones de IA aprobadas y aún así no tener visibilidad real de cómo las cargas de trabajo de IA se mueven a través de su infraestructura.
Ahí es donde aparece la nueva brecha de control.
Los centros de datos de IA no son solo regiones en la nube más grandes
Los líderes de seguridad deben resistir la tentación de tratar los centros de datos de IA como centros de datos normales con hardware más caro.
La infraestructura de IA introduce un modelo operativo diferente.
Los clústeres de entrenamiento concentran datos valiosos, pesos de modelos, propiedad intelectual y cómputo de alto rendimiento en un solo lugar. Los sistemas de inferencia están cerca de los flujos de trabajo de producción. Los sistemas agenticos conectan modelos con herramientas, archivos, identidades, bases de datos, plataformas SaaS y acciones de negocio. Los sistemas de recuperación copian conocimiento empresarial sensible en índices que pueden no estar gobernados como los sistemas fuente.
El resultado es una pila donde el límite entre datos, software, identidad y toma de decisiones se vuelve difuso.
Una vulneración tradicional de un centro de datos podría exponer sistemas o datos. Una vulneración en la infraestructura de IA puede exponer datos, alterar el comportamiento del modelo, envenenar el contexto de recuperación, robar activos del modelo, abusar del cómputo o manipular decisiones automatizadas.
Eso hace que la gobernanza sea más difícil, pero también más importante.
La IA agentiva convierte el riesgo de infraestructura en operativo
La frase que destacó en el alcance del taller de NIST es "flujos de trabajo de IA agentiva."
Eso importa porque los agentes transforman la IA de una capa de recomendación a una capa de ejecución.
Un chatbot responde. Un agente actúa.
Un agente puede leer tickets, consultar un CRM, inspeccionar código, redactar correos, actualizar registros, activar flujos de trabajo, abrir pull requests y llamar a APIs internas. Cuando esas acciones se ejecutan a través de la infraestructura empresarial, la pregunta de seguridad ya no es solo "¿Fue seguro el modelo?"
La mejor pregunta es:
"¿Qué podría hacer este sistema de IA si estuviera equivocado, comprometido, con permisos excesivos o manipulado?"
Esa pregunta abarca infraestructura, identidad, gobernanza y procesos de negocio.
Requiere controles que la mayoría de los programas de IA aún no tienen:
- Registros a nivel de acción para cambios iniciados por IA
- Límites de permisos para agentes y herramientas
- Flujos de aprobación para acciones de alto impacto
- Visibilidad en tiempo real del acceso a modelos, herramientas y datos
- Separación entre experimentación y ejecución en producción
- Vías de revocación para la memoria del agente y el contexto retenido
- Monitoreo para inyección de prompts, envenenamiento de recuperación y uso anómalo de herramientas
Estos no son documentos de políticas. Son controles operativos.
La IA en la sombra no se quedará en la capa del navegador
La IA en la sombra comenzó con empleados pegando datos en herramientas de consumo.
Esa versión sigue siendo real. Pero el riesgo más estratégico ahora es la infraestructura de IA en la sombra: equipos construyendo agentes, automatizaciones, copilotos internos y flujos de trabajo impulsados por modelos más rápido de lo que la gobernanza puede detectarlos.
Una unidad de negocio puede no pensar que está desplegando infraestructura de IA. Puede pensar que está conectando una API de modelo a un repositorio de documentos y una cola de tickets. Un desarrollador puede no pensar que está creando una ruta de automatización privilegiada. Puede pensar que está ahorrando tiempo en la clasificación. Un departamento puede no pensar que está creando un nuevo sistema de decisiones. Puede pensar que está mejorando la eficiencia del flujo de trabajo.
La intención no es el problema. La visibilidad sí lo es.
Si seguridad no puede ver el flujo de trabajo, no puede evaluar el riesgo. Si gobernanza no puede mapear la ruta de datos, no puede hacer cumplir la política. Si auditoría no puede reconstruir la acción, no puede probar qué ocurrió.
Por eso la gobernanza de IA debe pasar de la aprobación de herramientas a la visibilidad del flujo de trabajo.
Qué deben hacer ahora los equipos de seguridad
El movimiento inmediato no es esperar estándares perfectos. Los estándares ayudan, pero el riesgo ya está en marcha.
Los equipos de seguridad y gobernanza deberían empezar por mapear dónde existe infraestructura de IA hoy, aunque no se haya etiquetado así.
Busquen:
- Aplicaciones internas que llaman APIs de modelos
- Agentes conectados a herramientas SaaS o sistemas internos
- Bases de datos vectoriales o capas de recuperación que contienen datos empresariales
- Automatizaciones de flujos de trabajo que usan salidas de LLM para activar acciones
- Herramientas de desarrollo con acceso de escritura IA a código o tickets
- Copilotos construidos por departamentos que funcionan fuera de la revisión central de TI
- Pasarelas de modelos, capas proxy o herramientas de observabilidad usadas solo por un equipo
Luego hagan cinco preguntas prácticas de control.
1. ¿A qué datos puede acceder este sistema? 2. ¿Qué acciones puede realizar? 3. ¿Qué identidad usa cuando actúa? 4. ¿Dónde se registran prompts, salidas, memoria y contexto de recuperación? 5. ¿Quién puede revocar el acceso o detener el flujo de trabajo si algo va mal?
Si la respuesta a alguna de esas preguntas no está clara, el sistema aún no está gobernado.
El patrón ganador es habilitar con límites de seguridad
La respuesta equivocada es bloquear todos los flujos de trabajo de IA hasta que un comité central los apruebe. Eso solo empuja a los equipos a buscar soluciones alternativas.
La mejor respuesta es crear caminos pavimentados.
Ofrezcan a los equipos formas aprobadas de construir con IA. Proporcionen acceso a modelos a través de pasarelas gobernadas. Ofrezcan patrones estándar para recuperación, registro, permisos y aprobación humana. Hagan que el camino seguro sea más rápido que el camino en la sombra.
Así es como la gobernanza se convierte en infraestructura, no en papeleo.
Aquí es donde Aona también se enfoca: ayudar a las empresas a pasar de políticas estáticas de IA a visibilidad y control reales sobre cómo se usa la IA realmente. No solo qué herramientas se aprobaron hace seis meses, sino dónde actúa la IA hoy, qué datos toca y qué flujos de trabajo necesitan límites de seguridad.
La seguridad de centros de datos de IA puede parecer un tema de infraestructura de nicho. No lo es. Es una señal de que la gobernanza de IA se está convirtiendo en un problema de arquitectura empresarial.
Los equipos que entiendan eso temprano podrán adoptar la IA más rápido, con menos puntos ciegos. Los equipos que sigan tratando la IA como una lista de aplicaciones descubrirán la infraestructura más tarde, probablemente durante una auditoría, un incidente o una pregunta del consejo que no puedan responder.
Eso no es donde ningún CISO quiere estar.
