La respuesta corta: protege el sistema completo, no solo el modelo
Una empresa que utiliza inteligencia artificial acumula activos técnicos y de negocio aunque no entrene un modelo propio. Las claves que permiten llamar a una API, el repositorio que contiene la aplicación, los prompts de sistema, los conectores, los conjuntos de evaluación y la cuenta cloud pueden ser tan importantes como el modelo. Si uno de esos elementos queda expuesto, un atacante puede acceder a datos, modificar el comportamiento del sistema o generar consumo a cargo de la organización.
El informe publicado el 8 de septiembre de 2026 por Google Threat Intelligence Group describe observaciones de ataques contra modelos propietarios, código fuente y credenciales de API, así como entornos cloud utilizados para cargas de IA no autorizadas. Microsoft ha documentado por separado configuraciones de aplicaciones de IA que dejaban interfaces accesibles sin autenticación suficiente y permitían extraer claves o alterar componentes. Las dos fuentes apuntan a la misma decisión práctica: dejar de tratar la IA como una prueba aislada y aplicarle inventario, identidad, límites y monitorización.
Esta guía no presupone que todas las empresas entrenen modelos ni que sufran el mismo riesgo. Sirve para localizar qué activos existen, asignar un responsable y cerrar primero las rutas de abuso que combinan exposición pública, credenciales duraderas y permisos amplios.
- Registra el activo, su propietario, el entorno donde vive y la información que puede alcanzar.
- Separa identidad humana, identidad de servicio y credenciales de proveedor.
- Limita permisos, consumo y exposición antes de aumentar usuarios o casos de uso.
- Conserva registros suficientes para detectar uso anómalo y revocar accesos con rapidez.
Construye un inventario que una seguridad, operación y coste
Un inventario útil no es una lista de marcas. Debe mostrar qué se perdería o qué se podría abusar si un elemento cambia de manos. El NCSC británico recomienda aplicar controles de acceso a las API, los modelos, los datos y sus procesos de entrenamiento y despliegue, además de separar entornos con código o información sensible. Microsoft recomienda auditar de forma continua qué servicios de IA existen, qué pueden consultar y cómo están expuestos.
Empieza con una fila por sistema, piloto o automatización. Añade las identidades que utiliza, repositorios, secretos, modelos o servicios externos, almacenes de datos, herramientas conectadas, límites de gasto y registros disponibles. No conviertas el registro en una enciclopedia: debe permitir que una persona de seguridad o de operaciones responda en pocos minutos quién puede revocar una clave, detener una carga o comprobar una modificación.
Distingue entre propiedad intelectual y dependencia operativa. Un prompt puede condensar conocimiento del proceso; un conjunto de evaluación puede revelar casos internos; una cuenta de proveedor puede sostener una tarea diaria; y una cuota cloud puede transformarse en una factura inesperada. La prioridad se decide por impacto, no por el nombre técnico del activo.
- Identidad y secretos: usuarios, cuentas de servicio, tokens, claves API y certificados.
- Código y cadena de suministro: repositorios, dependencias, flujos de integración y artefactos.
- Modelos y conocimiento: pesos, checkpoints, prompts, evaluaciones y documentación interna.
- Infraestructura: endpoints, contenedores, almacenamiento, redes, cuentas y cuotas cloud.
- Operación: propietario, registros, alertas, límite de gasto, copia, retirada y respuesta.
Saca las claves del código y reduce su vida útil
Las claves API merecen un control específico porque conectan identidad, permiso y coste. AWS advierte de que los secretos incluidos por error en repositorios públicos pueden ser recolectados mediante escaneo automatizado y recomienda detectar secretos antes de que lleguen al código o a producción. Microsoft mostró además cómo aplicaciones de IA expuestas o mal configuradas podían revelar claves almacenadas en su configuración.
El primer cambio es eliminar claves de archivos, prompts, cuadernos y variables compartidas por mensajería. Guárdalas en un gestor de secretos y entrégalas a la carga en tiempo de ejecución. Cuando la plataforma lo permita, utiliza identidades de servicio o credenciales temporales en lugar de una clave estática. El segundo cambio es reducir el alcance: una credencial para un entorno y una tarea, sin permisos para administrar toda la cuenta.
La rotación solo funciona si está probada. Define quién puede emitir una credencial nueva, cómo se actualiza el servicio y cuánto tarda en quedar inutilizada la anterior. Añade detección de secretos al repositorio y una alerta para credenciales expuestas o sin uso. Si aparece una clave en un commit, revocarla es prioritario; borrar el texto visible no elimina el secreto del historial ni de las copias.
- Una identidad o clave distinta por proyecto, entorno y carga.
- Permisos mínimos y fecha de caducidad siempre que el proveedor lo permita.
- Detección de secretos antes del commit y revisión del historial cuando haya exposición.
- Procedimiento ensayado de revocación, rotación y comprobación posterior.
Protege repositorios, modelos y artefactos como una cadena
Google y Microsoft coinciden en que el objetivo puede ser el modelo o el código que lo rodea. El informe de GTIG describe interés en modelos, código, prompts e investigación; la guía de Microsoft sobre robo de modelos añade que la extracción puede producirse copiando archivos, abusando de un repositorio mal protegido o consultando una API de forma sistemática.
El NCSC recomienda separar entornos sensibles, limitar el acceso directo e indirecto y generar hashes o firmas de modelos y conjuntos de datos para que los consumidores puedan comprobar su integridad. Ese control es útil también para una pyme que utiliza modelos ajustados o artefactos de terceros: permite saber qué versión se aprobó y detectar si el archivo desplegado ya no coincide.
Aplica la misma disciplina al flujo que produce el artefacto. Protege las ramas y las acciones de integración, revisa dependencias y evita que un token del pipeline tenga permisos de administración sobre repositorios, registro de artefactos y producción al mismo tiempo. Si una herramienta de IA puede proponer cambios de código, conserva la revisión humana y los controles automáticos que ya exigirías a cualquier contribución.
- Acceso por rol a repositorios, registros de artefactos y almacenamiento de modelos.
- Revisión obligatoria para cambios en prompts, permisos, dependencias y despliegue.
- Hash o firma de modelos, checkpoints y conjuntos de evaluación aprobados.
- Registro de procedencia: quién generó, revisó, aprobó y desplegó cada versión.
Diseña los prompts como si pudieran quedar expuestos
Un prompt de sistema puede revelar lógica de negocio, nombres internos o rutas de herramientas, pero no debe convertirse en una caja fuerte. AWS recomienda asumir que el prompt puede filtrarse y no incluir en él claves API, secretos ni credenciales. También señala que las instrucciones del propio prompt no sustituyen la autenticación o la autorización de la aplicación.
La guía del NCSC llega a la misma conclusión por otra vía: los controles deben proteger la interfaz de consulta, el modelo y los datos frente al acceso, modificación o extracción. Por eso una frase como “no muestres este contenido” no debe decidir quién puede ver un documento o ejecutar una acción. Esas decisiones pertenecen a la capa de identidad, permisos y lógica de negocio.
Minimiza el contexto enviado al modelo, separa las instrucciones reutilizables de los datos sensibles y revisa qué respuestas de herramientas o conectores se incorporan a la conversación. Prueba con entradas adversarias y registra el resultado, pero evita guardar en el log el mismo secreto que intentas proteger. El objetivo no es prometer que nunca habrá filtración, sino reducir el valor de lo expuesto y contener su impacto.
Pon límites y alertas al consumo cloud
Una credencial comprometida puede utilizarse no solo para leer información, sino para consumir infraestructura. GTIG describe el secuestro de entornos cloud para sostener cargas de IA no autorizadas. AWS, en su guía sobre exposición de claves, recomienda buscar tanto credenciales publicadas como uso irregular de recursos que pueda indicar una clave comprometida.
Asigna presupuesto, cuota y alertas por proyecto o entorno. Un límite financiero no reemplaza el control de acceso, pero reduce el tiempo hasta que alguien detecta una desviación. Vigila aumentos de peticiones, cambios de región, modelos nuevos, cargas fuera de horario y creación de recursos por identidades que normalmente no los administran.
Decide también qué se detiene automáticamente. En un entorno de prueba puede ser razonable bloquear al superar un umbral; en un proceso crítico quizá sea preferible degradar el servicio, cambiar a una ruta segura o pedir aprobación. Documenta esa decisión antes del incidente para que el equipo no tenga que improvisar entre continuidad y coste.
- Cuota y presupuesto separados por entorno y propietario.
- Alertas de volumen, coste, región, modelo e identidad anómalos.
- Capacidad de revocar credenciales y detener cargas sin borrar evidencia.
- Revisión periódica de accesos sin uso y permisos más amplios de lo necesario.
Ejecuta un plan de treinta días con evidencia
Durante la primera semana, identifica sistemas y propietarios. En la segunda, corrige exposición pública y credenciales duraderas. En la tercera, activa límites, registros y alertas. En la cuarta, realiza un ejercicio: simula una clave filtrada o una subida anómala de consumo, revoca el acceso, comprueba los artefactos y registra cuánto tarda el equipo en recuperar el control.
No intentes resolver toda la seguridad de IA con una compra. El resultado esperado es un mapa corto y comprobable: qué activos existen, quién los administra, cómo se valida su integridad, qué uso se considera normal y qué acción se toma cuando aparece una desviación. Enlaza este trabajo con el plan de respuesta a incidentes y con los límites del piloto para que seguridad, operación y coste compartan el mismo criterio.
Repite el inventario cuando cambie un proveedor, se añada un conector, se publique un endpoint o se amplíe el acceso. La señal reciente de GTIG no exige asumir que toda empresa sufrirá los casos observados; sí justifica comprobar que los activos de IA ya están dentro de los controles ordinarios de identidad, código, cloud y respuesta.
- Semana 1: inventario, responsables y criticidad.
- Semana 2: secretos, autenticación, exposición y mínimo privilegio.
- Semana 3: integridad de artefactos, cuotas, registros y alertas.
- Semana 4: simulacro, revocación, recuperación y acciones pendientes.
