Se entra en cada sistema de IA. Algunos de sus controles solo aplican si lo integráis, lo configuráis o lo entrenáis (B1). Llega hasta donde alcance la letra del sistema, e implántalo en tu modo.
Por qué existe
Decide qué se permite ejecutar, y haz cumplir esa decisión en los propios sistemas, no en un documento que alguien debería recordar. Un parque de IA que cualquiera puede ampliar con cualquier modelo, conectado a cualquier sistema interno y capaz de alcanzar cualquier dirección de internet, no es una arquitectura: es una superficie abierta esperando su primer incidente. El inventario que construiste en gobernanza te dice qué existe. Esta área decide qué está permitido, y asegura cada componente permitido.
Qué hacer
Fija la versión exacta del modelo en producción; nunca ejecutes contra un «último» flotante. Los proveedores ofrecen alias cómodos que siempre apuntan a su modelo más nuevo. Detrás de un nombre que no cambia, el modelo sí cambia cuando el proveedor publica una actualización, y con él el comportamiento, el tono y las propiedades de seguridad que probaste, sin que haya cambiado una sola línea de tus sistemas. Fija la versión exacta en cada despliegue de producción, y haz de cualquier cambio de versión un evento deliberado y controlado: revisado, vuelto a probar y conectado con el aviso de cambio de modelo que aseguraste del proveedor en el área de aprovisionamiento.
Mantén una lista de modelos aprobados, y que nada de fuera de ella llegue a producción. Mantén una lista explícita de qué modelos, en qué versiones, pueden usarse siquiera: para qué tipos de uso y por qué equipos. Es la misma disciplina que ya aplicas al software: el personal no instala programas arbitrarios en los equipos de la empresa, y los equipos no conectan modelos arbitrarios a los procesos de la empresa. Un modelo que no esté en la lista no llega a producción, por buenas que sean sus puntuaciones en las pruebas de referencia; la compuerta es la lista, no el entusiasmo.
Escribe las reglas de despliegue como reglas que hacen cumplir los sistemas, no como orientaciones que alguien debe recordar. Expresa «este servicio puede usar este modelo, con estos poderes, sobre esta clase de datos» como política comprobable por máquina: reglas que tus plataformas verifican automáticamente en el despliegue y en cada llamada. La revisión humana es imprescindible e insuficiente: quien revisa rota, se olvida y no está a las tres de la mañana; una política aplicada por la máquina, no. Cuanto más crece tu parque de IA, más peso carga esta sola medida.
Trata las instrucciones permanentes del modelo como configuración controlada, y mantén los secretos fuera de ellas. La mayoría de los sistemas de IA desplegados están moldeados por un conjunto permanente de instrucciones escritas que le dice al modelo qué es, qué puede hacer y cómo comportarse. Allí donde esas instrucciones determinan el comportamiento de forma significativa, ponlas bajo control de cambios como cualquier configuración crítica: versionadas, revisadas y con un historial de quién cambió qué. Y nunca metas credenciales, claves ni direcciones internas dentro de ellas: los atacantes engañan a los modelos de forma rutinaria para que revelen sus instrucciones, y todo lo que esté ahí incrustado se filtra en cuanto lo consiguen.
Limita adónde pueden enviar datos los componentes de IA. Un componente de IA que puede alcanzar cualquier dirección de internet es un canal listo para robar datos: quien manipule el sistema puede hacer que transmita todo lo que ve adonde el atacante quiera. Deniega las conexiones de salida por defecto y permite solo los destinos concretos que cada componente necesita de verdad. Esta sola restricción desactiva una parte grande de los ataques prácticos contra sistemas de IA, porque la mayoría terminan con un intento de enviar algo hacia fuera.
Escribe las reglas aplicadas en un lenguaje de políticas. «Este servicio puede usar este modelo, con estos poderes, sobre esta clase de datos» se expresa en un lenguaje declarativo de políticas, se versiona junto al código y la plataforma lo evalúa automáticamente en el momento del despliegue y en el de la llamada.
Controles
Baseline3 controles
Control 80
Versiona cada modelo que entrenes o adaptes.
BaselinePreventivodesarrollador (developer)por sistema
Qué es
Cada artefacto entrenado tiene un identificador de versión único, almacenado con el modelo y referenciado en el inventario.
Cómo implantarlo · Contenido mínimo
Identificador de versión: único, nunca reutilizado, guardado en los metadatos del fichero del modelo y en el inventario
Modelo base y su versión exacta, si has adaptado uno existente
Referencia a la instantánea de datos de entrenamiento, revisión del código y parámetros clave
Huella (hash) del fichero de modelo resultante
Fecha, autor y sistemas que usan esta versión
Regla: todo reentrenamiento o ajuste, por pequeño que sea, genera una versión nueva
Cómo arrancar
Acuerda un esquema de nombres (por ejemplo nombre-mayor.menor-fecha) y aplícalo a los modelos ya en uso, registrando cada uno en el inventario.
Evidencia
El registro de versiones y las entradas del inventario que muestran qué versión ejecuta cada sistema.
Modo: ligero / estándar / completo
ligero
Una persona designada lleva las versiones en una hoja de cálculo y guarda cada fichero en una carpeta con el nombre de su versión.
estándar
El proceso de entrenamiento asigna la versión y la guarda en un registro de modelos junto con su ficha de entrenamiento.
completo
Un registro central de modelos asigna versiones automáticamente y la plataforma de despliegue rechaza cualquier artefacto sin versión.
Control 81
Fija versiones exactas del modelo en cada despliegue en producción.
BaselinePreventivointegrador o desarrollador (deployer+)por sistema
Qué es
Los cambios de versión son eventos controlados, con revisión y nuevas pruebas, nunca actualizaciones silenciosas.
Cómo implantarlo · Reglas mínimas
Toda configuración de producción indica el identificador completo de versión que publica el proveedor, nunca un alias como “latest”
Abarca todas las llamadas en producción: aplicaciones, integraciones, tareas programadas y agentes
Un cambio de versión es una solicitud de cambio: motivo, nueva versión, resultados de pruebas, aprobador
Antes de cambiar, vuelve a ejecutar las pruebas del sistema y compara las salidas con la versión actual
Los avisos del proveedor sobre cambios o retirada de modelos llegan al responsable del sistema con fecha prevista de cambio
Cómo arrancar
Enumera todas las configuraciones de producción que llaman a un modelo y sustituye cualquier alias por el identificador exacto de versión.
Evidencia
La configuración con las versiones fijadas y el registro de cambio de cada cambio de versión.
Modo: ligero / estándar / completo
ligero
Quien montó la integración fija la versión en sus ajustes y anota cada cambio, con una prueba rápida, en un registro sencillo.
estándar
Las versiones fijadas están en configuración versionada y los cambios siguen el proceso de cambios habitual con una nueva prueba documentada.
completo
Comprobaciones automáticas rechazan cualquier despliegue que use un alias, y cada cambio de versión lanza la batería de pruebas antes de aprobarse.
Control 82
Somete las instrucciones permanentes a control de versiones, sin secretos incrustados.
BaselinePreventivointegrador o desarrollador (deployer+)por sistema
Qué es
Versionadas, revisadas y libres de credenciales, claves y direcciones internas.
Cómo implantarlo · Reglas mínimas
Guarda las instrucciones permanentes de cada sistema en un repositorio versionado o en la configuración versionada de la plataforma; nada de edición en caliente
Cada cambio registra autor, fecha, motivo y un revisor distinto del autor
Contenido prohibido: contraseñas, claves de API, tokens, cadenas de conexión, nombres de servidores y direcciones IP internas
Analiza las instrucciones en busca de secretos por patrón antes de cada publicación
Las instrucciones desplegadas coinciden siempre con una versión guardada y revisada
Cómo arrancar
Exporta las instrucciones permanentes actuales de cada sistema a un almacén versionado, elimina credenciales o direcciones internas y rota cualquier credencial encontrada.
Evidencia
El historial de versiones de las instrucciones con sus revisores y el último resultado del análisis de secretos.
Modo: ligero / estándar / completo
ligero
Guarda las instrucciones en un documento compartido con historial de cambios y haz que una segunda persona lea cada cambio antes de publicarlo.
estándar
Guárdalas en el repositorio de código con revisión entre pares y análisis automático de secretos en cada cambio.
completo
Los cambios de instrucciones pasan por el proceso de publicación con revisión obligatoria y análisis de secretos, y solo se despliegan desde el repositorio.
Enhanced4 controles
Control 83
Gestiona la lista de modelos aprobados como compuerta de producción.
EnhancedPreventivotodos los rolespor sistema
Qué es
Modelos y versiones aprobados por uso y por equipo; nada que esté fuera de la lista se despliega.
Cómo implantarlo · Contenido mínimo
Nombre del modelo o servicio de IA y versión exacta aprobada
Usos aprobados y clases de datos permitidas (p. ej. pública, interna, confidencial, personal)
Equipos o sistemas autorizados a usarlo
Aprobador, fecha de aprobación, condiciones y qué obliga a reaprobar (nueva versión, nuevo uso)
Estado: aprobado, en evaluación, retirado
Regla de paso: las solicitudes de despliegue y compra se contrastan con la lista; lo que no figura se rechaza
Cómo arrancar
Construye la lista a partir del inventario de IA, marca cada modelo en uso como aprobado o pendiente de revisión y comunica que nada nuevo llega a producción sin estar en ella.
Evidencia
La lista vigente y los registros de solicitudes aprobadas o rechazadas conforme a ella.
Modo: ligero / estándar / completo
ligero
Una persona designada mantiene la lista en una hoja de cálculo y la consulta antes de comprar, conectar o desplegar cualquier herramienta de IA.
estándar
La lista vive en el sistema de cambios o de compras, y toda solicitud de despliegue o compra debe citar una entrada.
completo
La lista está en un registro que la plataforma de despliegue consulta automáticamente, bloqueando cualquier modelo o versión no incluidos.
Control 84
Mantén estándares de bastionado por tipo de componente.
EnhancedPreventivotodos los rolespor sistema
Qué es
Un estándar escrito de configuración segura para los servicios de modelos, los agentes, las herramientas y los servidores MCP y demás conectores, aplicado en el despliegue.
Cómo implantarlo · Estructura mínima
Una sección por tipo de componente: servicios de modelo, agentes, herramientas, servidores MCP y otros conectores
Ajustes obligatorios por tipo: autenticación activa, credenciales por defecto eliminadas, registro activo, depuración desactivada, límites de uso
Exposición de red: ningún punto de acceso público sin aprobación; destinos de salida limitados
Ajustes de datos: opciones de retención y de uso para entrenamiento del proveedor, cifrado en tránsito y en reposo
Lista de verificación por tipo, firmada antes del despliegue; desviaciones con responsable y fecha de caducidad
Revisión al adoptar un nuevo tipo de componente o proveedor, y al menos una vez al año
Cómo arrancar
Redacta el estándar del tipo de componente que más despliegas, a partir de tu instancia mejor configurada, y amplíalo a los demás.
Evidencia
Los estándares y las listas de verificación completadas de cada componente desplegado.
Modo: ligero / estándar / completo
ligero
Una lista de verificación breve por tipo, que mantiene la persona que configura las herramientas de IA y rellena antes de cada puesta en marcha.
estándar
El responsable de seguridad es dueño de los estándares y la lista de verificación forma parte del proceso de publicación.
completo
Un equipo de plataforma publica los estándares como plantillas de configuración y verifica automáticamente los componentes desplegados.
Control 85
Elabora y mantén un estándar de seguridad escrito para agentes, herramientas, servidores MCP y conectores.
EnhancedPreventivotodos los rolespor sistema
Qué es
Establece cuánta autonomía puede tener cada tipo de componente, cómo se restringen sus herramientas y los parámetros de estas, cómo se otorga confianza a los conectores y servidores MCP y cómo se aíslan, y qué debe cumplir un componente de cada tipo antes de que se permita su despliegue.
Cómo implantarlo · Estructura mínima
Niveles de autonomía por tipo de componente: solo sugerir, actuar tras aprobación, actuar solo dentro de límites definidos
Restricciones de herramientas: herramientas permitidas por agente, límites de parámetros (importes, destinatarios, rutas), leer separado de actuar
Confianza en conectores y servidores MCP: fuentes aprobadas, verificación antes de usar, versiones fijadas, aislamiento entre ellos
Requisitos de identidad y credenciales para cada tipo de componente
Requisitos previos al despliegue: responsable designado, revisión de seguridad, pruebas superadas, registro activado
Vía de excepciones y revisión anual
Cómo arrancar
Inventaría los agentes, herramientas y conectores en uso, agrúpalos por tipo y redacta el nivel de autonomía y las comprobaciones previas al despliegue de cada grupo.
Evidencia
El estándar aprobado y los registros previos al despliegue que muestran que cada componente lo cumple.
Modo: ligero / estándar / completo
ligero
Un estándar de dos páginas, a cargo del responsable de IA, aplicado como lista de verificación antes de activar cualquier agente o conector.
estándar
El responsable de seguridad mantiene el estándar y la revisión de arquitectura o de cambios comprueba cada nuevo componente frente a él.
completo
Una función dedicada mantiene el estándar, traslada sus restricciones a la plataforma de agentes y bloquea los componentes que no lo cumplen.
Control 86
Gestiona los modelos como activos controlados conforme a un estándar escrito de gestión de modelos.
EnhancedPreventivotodos los rolespor sistema
Qué es
Un registro único de qué modelos existen y en qué versiones, cómo se aprueba cada uno para su uso, se revalida cuando cambia, se comprueba su integridad y se retira; la disciplina que vincula la lista de modelos aprobados con las comprobaciones de integridad de la dimensión de Integridad del Modelo.
Cómo implantarlo · Estructura mínima
Registro: cada modelo y versión, responsable, origen, huella, sistemas que lo usan
Aprobación: quién aprueba un modelo para qué uso, y su vínculo con la lista de modelos aprobados
Cambio: revalidación y pruebas obligatorias cuando cambian la versión, el proveedor o la adaptación
Integridad: comprobación de origen y huella antes del primer uso y al cargar
Retirada: criterios, aviso a los usuarios, baja de la lista, revocación de accesos
Funciones y revisión anual del estándar
Cómo arrancar
Fusiona el inventario y la lista de modelos aprobados en un único registro y redacta a su alrededor las reglas de aprobación, cambio y retirada.
Evidencia
El estándar, el registro y los registros de aprobaciones, revalidaciones y retiradas.
Modo: ligero / estándar / completo
ligero
Una hoja de cálculo, a cargo del responsable de IA, sirve de registro y de lista, con las reglas en una sola página.
estándar
El registro vive en un registro de modelos o sistema de activos, y las aprobaciones y revalidaciones pasan por el proceso de cambios.
completo
Una función de gestión de modelos opera el registro, que gobierna automáticamente la aprobación, las comprobaciones de integridad y la retirada.
Advanced2 controles
Control 87
Aplica las reglas de despliegue como políticas comprobadas automáticamente.
AdvancedPreventivotodos los rolespor sistema
Qué es
El modelo, las facultades y la clase de datos se verifican automáticamente en el momento del despliegue y en el de cada llamada.
Cómo implantarlo · Reglas mínimas
Política por servicio: modelo y versión permitidos, facultades y herramientas permitidas, clases de datos permitidas
Escrita en un lenguaje declarativo de políticas, versionada con el código y revisada como código
En el despliegue: el proceso rechaza cualquier despliegue que incumpla la política
En cada llamada: la pasarela o la plataforma contrasta cada llamada al modelo con modelo, facultad y clase de datos
Cada denegación se registra con servicio, regla y motivo; las excepciones se aprueban y caducan
Cómo arrancar
Traduce la lista de modelos aprobados en la primera regla aplicada en el proceso de despliegue y añade después facultades y clases de datos.
Evidencia
El repositorio de políticas y los registros de despliegues y llamadas denegados.
Modo: ligero / estándar / completo
ligero
Usa las reglas de autorización integradas del proveedor o la plataforma para modelos y permisos, configuradas por quien gestiona el despliegue.
estándar
Las políticas se escriben en el lenguaje de políticas y se comprueban en el proceso de despliegue, con controles en cada llamada en una pasarela central.
completo
Un equipo de plataforma es dueño del conjunto de políticas, las aplica en cada despliegue y llamada, y envía las denegaciones a la vigilancia de seguridad.
Control 88
Deniega por defecto las conexiones salientes de los componentes de IA.
AdvancedPreventivotodos los rolespor sistema
Qué es
Cada componente solo llega a los destinos que tiene permitidos explícitamente.
Cómo implantarlo · Reglas mínimas
Regla por defecto: se bloquean todas las conexiones salientes de los componentes de IA
Lista de permitidos por componente: los dominios o direcciones y puertos que de verdad necesita (punto de acceso del modelo, servicios internos concretos)
Abarca servidores de modelos, agentes, entornos de ejecución de código y conectores
Las direcciones generadas por el modelo (enlaces, URL de imágenes, retornos de llamada) no se consultan salvo que estén permitidas
Los intentos bloqueados se registran y se avisa al responsable
Listas revisadas en cada cambio del componente y al menos cada seis meses
Cómo arrancar
Registra dos semanas el tráfico saliente de cada componente para conocer sus destinos reales, crea la lista de permitidos y pasa a denegar por defecto.
Evidencia
Las listas de permitidos por componente y el registro de intentos bloqueados.
Modo: ligero / estándar / completo
ligero
Aplica la regla en el cortafuegos o la red de la plataforma con una lista corta que mantiene tu proveedor informático; en herramientas alojadas, desactiva el acceso web innecesario.
estándar
Los equipos de red y seguridad mantienen las listas por componente en el cortafuegos o el proxy de salida, con alertas ante bloqueos.
completo
La salida se controla de forma centralizada por carga de trabajo, las listas se versionan con el despliegue y los bloqueos alimentan la vigilancia de seguridad.
Evidencia
La lista de modelos aprobados; la configuración que fija la versión; el historial de cambios de las instrucciones; las normas de fortificación y los registros de su aplicación; las reglas de política aplicadas; las listas de conexiones de salida permitidas. La norma de seguridad de agentes, herramientas y MCP, y la norma de gestión de modelos.