¿Es nuestra forma de construir y desplegar IA segura por construcción?
Baseline: 3Enhanced: 6Advanced: 312 controles
A quién se aplica
Se entra solo en los sistemas que integráis, configuráis o entrenáis (B1). Llega hasta donde alcance la letra del sistema, e implántalo en tu modo.
Por qué existe
Extiende la disciplina que ya aplicas a la construcción de software para que cubra lo que la construcción de IA implica de verdad, porque la IA se cuela en producción por puertas que el software corriente no puede usar. El trabajo con IA empieza explorando: analistas y especialistas de datos experimentan en cuadernos interactivos, sobre datos reales, con credenciales reales a mano, fuera de la revisión y de los controles que gobiernan tu código de producción; y el experimento que sale bien tiene la costumbre de convertirse en el sistema de producción sin pasar por ninguna compuerta. Mientras tanto, el sistema terminado depende no solo de código, sino de modelos descargados y conjuntos de datos externos, dependencias hacia las que tus comprobaciones de cadena de suministro nunca apuntaron. Apúntalas hacia allí, y cierra esas puertas.
Qué hacer
Analiza las dependencias de modelos y de datos, no solo las bibliotecas de código. Tu cadena de construcción ya comprueba si los componentes de software que arrastra un sistema tienen problemas conocidos. Extiende exactamente esa comprobación a lo que la IA arrastra además: los modelos que descarga y los conjuntos de datos que consume. Un modelo retirado por quien lo publicó, o un conjunto de datos que resulta estar envenenado o tener un origen ilícito, es un incidente de cadena de suministro en todos los sentidos en que lo es una biblioteca de software comprometida; la lista de componentes del inventario de gobernanza te dice qué analizar y a qué afecta cuando suena la alarma.
Trata los cuadernos de experimentación como la superficie de fuga que son. Los cuadernos interactivos en los que se explora el trabajo con IA acumulan de forma rutinaria justo lo que nunca debería salir de terreno controlado: credenciales pegadas, extractos de datos de clientes, código sin revisar. Analízalos en busca de secretos incrustados como cuestión de rutina, mantén las credenciales de producción fuera de los entornos en los que se ejecutan y —la regla que más importa— exige que nada pase del cuaderno a producción sin superar la misma revisión que cualquier otro código. El camino del experimento a producción tiene que pasar por la compuerta, no rodearla.
Haz del visto bueno de seguridad una compuerta de publicación para la IA de alto riesgo. Para los sistemas por encima del umbral de riesgo que definiste en gobernanza, una revisión de seguridad —incluidas pruebas adversarias cuando lo que está en juego lo justifique— es condición para publicar, con autoridad para decir que no. Un hallazgo que llega después del lanzamiento es un incidente; la compuerta existe para que llegue antes.
Genera la lista de componentes en la cadena, como subproducto de construir. El registro de qué entró en cada modelo —modelo base, conjuntos de datos, componentes— debería producirlo automáticamente la propia construcción, y no reconstruirse a mano después. Los registros montados a posteriori están incompletos el día en que se escriben y desfasados la semana siguiente; los que genera la cadena son correctos por construcción, y son los que convierten un futuro «¿nos afecta?» en una consulta en vez de en una investigación.
Confirma que los paquetes que sugiere la IA existen antes de incorporarlos. Una IA que escribe código nombrará a veces un paquete de software que no existe, y los atacantes vigilan los nombres que se inventa, publican paquetes maliciosos con exactamente esos nombres y esperan a que el siguiente desarrollador instale uno por consejo del modelo. Verifica que toda dependencia sugerida por una IA existe, que es la que se pretendía y que viene de una fuente de confianza antes de que entre en una construcción.
Condiciona la publicación a la evaluación. Ejecuta la evaluación previa a la publicación como una compuerta automatizada dentro del proceso de publicación: un modelo que no supere su conjunto de evaluación documentado no se publica.
Sea cual sea lo que está en juego, comprueba lo que has construido antes de apoyarte en ello. Una integración que configuraste o un modelo que entrenaste crean riesgos que existen solo porque los construiste tú. Incluso para un uso con poco en juego, valídalo antes de producción y, para los modelos que entrenes, decide por adelantado qué significa «suficientemente bueno» y mantén cada cambio trazable.
Controles
Baseline3 controles
Control 124
Valida la integración antes de que llegue a producción.
BaselineDetectivointegrador o desarrollador (deployer+)por sistema
Qué es
Una comprobación documentada, antes de la puesta en producción y después de cada cambio, de que la IA integrada se comporta como se pretende con entradas representativas, respeta sus límites de acceso y falla de forma segura.
Cómo implantarlo · Pasos
Prepara entre 20 y 50 entradas representativas con su resultado esperado: casos típicos, límite y erróneos a propósito
Comprueba que las salidas son correctas y útiles para la tarea prevista; marca superado o fallido por caso
Comprueba los límites de acceso: intenta que la IA alcance datos o funciones que no debe
Comprueba el fallo seguro: proveedor no disponible, entrada mal formada, límites alcanzados
Registra el resultado con la firma del responsable del sistema; repítelo tras cualquier cambio de modelo, instrucciones, configuración o datos conectados
Cómo arrancar
Antes de la puesta en producción, escribe los casos de prueba en una sola hoja con el resultado esperado junto a cada uno.
Evidencia
La hoja de pruebas fechada, con resultados y firma del responsable, por cada publicación.
Modo: ligero / estándar / completo
ligero
Quien montó la integración ejecuta los casos a mano desde una hoja de cálculo y firma la dirección.
estándar
Los casos de prueba se guardan con el código de la integración y el equipo de desarrollo los ejecuta antes de cada publicación.
completo
Los casos se ejecutan automáticamente en el flujo de publicación y un equipo de calidad revisa y firma los resultados.
Control 125
Evalúa cada modelo que entrenes o adaptes frente a criterios de aceptación escritos antes de usarlo.
BaselineDetectivodesarrollador (developer)por sistema
Qué es
Antes del entrenamiento se fijan un conjunto de prueba reservado y los criterios que el modelo debe cumplir; el modelo solo se usa si los cumple, y el resultado se registra.
Cómo implantarlo · Pasos
Antes de entrenar, redacta los criterios de aceptación: métrica, umbral numérico y rendimiento mínimo en los grupos de casos clave
Reserva un conjunto de prueba que nunca se use para entrenar ni ajustar
Tras entrenar, ejecuta el modelo sobre el conjunto de prueba y compara con cada criterio
Usa el modelo solo si cumple todos los criterios; si no, reentrena o descártalo
Registra el resultado, la versión del modelo, la versión del conjunto de prueba y quién decidió
Cómo arrancar
Para el próximo modelo, redacta entre tres y cinco criterios con umbrales numéricos y haz que se aprueben antes de empezar a entrenar.
Evidencia
Los criterios aprobados y el registro de evaluación de cada versión del modelo.
Modo: ligero / estándar / completo
ligero
Quien entrena el modelo redacta los criterios en una página y la dirección aprueba el resultado.
estándar
Criterios y resultados se guardan con cada versión del modelo y los revisa alguien distinto de quien entrena.
completo
Un equipo de evaluación independiente fija los criterios con el responsable de negocio y ejecuta la evaluación.
Control 126
Mantén trazable cada cambio en un modelo que construyas.
BaselineDetectivodesarrollador (developer)por sistema
Qué es
Cada versión registra qué cambió (datos, código, parámetros), quién lo aprobó y por qué, de modo que cualquier resultado pueda vincularse a la versión que lo produjo.
Cómo implantarlo · Contenido mínimo
Identificador de versión de cada modelo que se pone en uso
Qué cambió: versión de datos, versión de código, parámetros, modelo base
Por qué cambió
Quién lo aprobó y cuándo
Resultado de evaluación de esa versión
Dónde y cuándo entró en producción; cada salida o entrada de registro lleva la versión del modelo
Cómo arrancar
Abre hoy un registro de cambios con la versión que está en uso y anota cada cambio posterior antes de desplegarlo.
Evidencia
El registro de cambios de cada modelo, con aprobaciones, y la etiqueta de versión en los registros de salida.
Modo: ligero / estándar / completo
ligero
Quien construye el modelo lleva el registro de cambios en una hoja de cálculo y etiqueta las salidas con la versión a mano.
estándar
El control de versiones y un registro de modelos guardan cambios, aprobaciones y la versión estampada en cada salida.
completo
La plataforma de aprendizaje automático registra cada cambio automáticamente y vincula cada salida en producción con su versión exacta.
Enhanced6 controles
Control 127
Extiende el análisis de dependencias y de secretos a los modelos, los conjuntos de datos y los cuadernos experimentales.
EnhancedDetectivointegrador o desarrollador (deployer+)por sistema
Qué es
Las comprobaciones de la cadena de suministro que aplicas al código se aplican a todo lo que la IA incorpora adicionalmente.
Cómo implantarlo · Reglas mínimas
Modelos: origen, integridad (suma de verificación o firma), avisos de retirada del editor, formatos de fichero que pueden ejecutar código al cargarse
Conjuntos de datos: origen, licencia y cualquier aviso de envenenamiento o retirada
Cuadernos experimentales: contraseñas, claves, tokens y extractos de datos de clientes incrustados, también en salidas guardadas
Alcance tomado de la lista de materiales; vuelve a analizar cuando se publique un aviso nuevo
Acción: detén la compilación o marca el hallazgo, avisa al responsable y sigue la corrección
Cómo arrancar
Apunta tu detector de secretos a las carpetas de cuadernos y relaciona los modelos y datos que descarga cada sistema.
Evidencia
Informes de análisis del flujo de compilación que cubran modelos y datos, y los resultados del análisis de secretos en cuadernos.
Modo: ligero / estándar / completo
ligero
Un servicio contratado o el análisis de la plataforma de código cubre los cuadernos; el origen de los modelos se comprueba a mano.
estándar
El flujo de compilación analiza código, modelos y datos en cada compilación, y las carpetas de cuadernos cada semana.
completo
El equipo de seguridad de aplicaciones analiza de forma continua todos los activos de IA.
Control 128
Mantén las credenciales de producción y los datos masivos de clientes fuera de la experimentación.
EnhancedPreventivointegrador o desarrollador (deployer+)por sistema
Qué es
La exploración se hace con datos separados y sin claves de producción; las infracciones son hallazgos.
Cómo implantarlo · Reglas mínimas
Los entornos de experimentación están separados de las redes de producción y del almacén de secretos de producción
Sin claves de producción: los experimentos usan credenciales propias, de bajo privilegio y con caducidad
Datos: muestras sintéticas, anonimizadas o minimizadas; datos masivos de clientes solo por excepción registrada con aprobador y fecha de fin
Analiza cuadernos y almacenamiento de experimentación en busca de claves de producción y patrones de datos de clientes
Toda infracción es un hallazgo: se registra, se rota la credencial, se eliminan los datos y se informa al responsable
Cómo arrancar
Emite un juego de credenciales propio para experimentación y rota cualquier clave de producción ya encontrada en cuadernos.
Evidencia
La configuración de separación de entornos, el registro de excepciones y el registro de hallazgos.
Modo: ligero / estándar / completo
ligero
Quien lidera la IA separa las claves de experimentación en la consola del proveedor y anota las excepciones en una hoja de cálculo.
estándar
Los experimentos se ejecutan en un entorno dedicado con credenciales propias y los análisis son semanales.
completo
Una plataforma de experimentación gestionada impone la separación y el enmascaramiento de datos, y las infracciones se elevan automáticamente como hallazgos de seguridad.
Control 129
Haz pasar por la revisión de código todo lo que vaya de la experimentación a producción.
EnhancedPreventivointegrador o desarrollador (deployer+)por sistema
Qué es
Ningún cuaderno pasa a producción mediante copiar y pegar.
Cómo implantarlo · Reglas mínimas
El código de producción vive solo en el repositorio con control de versiones; los cuadernos nunca se despliegan directamente
Todo cambio que llega a producción lo revisa alguien distinto de su autor
La revisión cubre secretos, acceso a datos, dependencias, gestión de errores y pruebas
El flujo de despliegue rechaza cambios sin revisar y ficheros de cuaderno
Las excepciones urgentes se registran y se revisan después dentro de un plazo fijado
Cómo arrancar
Configura el flujo de despliegue para rechazar cualquier cambio sin revisión aprobada y pasa a código revisado cualquier cuaderno que esté en producción.
Evidencia
Los registros de revisión del código que pasó de experimento a producción y la regla del flujo que impone la revisión.
Modo: ligero / estándar / completo
ligero
Una segunda persona, interna o contratada, revisa el código antes de su puesta en producción y la revisión consta en el registro del cambio.
estándar
La revisión entre pares es obligatoria en el sistema de control de versiones para todos los repositorios de IA.
completo
La protección de ramas y los controles del flujo imponen la revisión de forma central, y el equipo de seguridad audita las excepciones.
Control 130
Verifica que las dependencias sugeridas por la IA existen y son de confianza antes de que entren en una compilación.
EnhancedPreventivointegrador o desarrollador (deployer+)por sistema
Qué es
Protege frente a la instalación de un paquete malicioso publicado con un nombre que coincide con uno inventado por el modelo.
Cómo implantarlo · Reglas mínimas
Comprueba cada paquete que sugiera un asistente de programación con IA antes de instalarlo, no después
Existe en un repositorio aprobado con exactamente el nombre previsto; atención a grafías parecidas
Señales de confianza: editor, antigüedad, historial de descargas, mantenimiento, vulnerabilidades conocidas
Instala solo mediante un espejo interno o repositorios aprobados; los paquetes nuevos requieren aprobación
Registra cada comprobación: paquete, versión, quién lo verificó y fecha
Cómo arrancar
Canaliza la instalación de paquetes por una lista de permitidos o un espejo interno y avisa a los desarrolladores de que los paquetes nuevos sugeridos por IA requieren comprobación previa.
Evidencia
Los registros de verificación de dependencias y la configuración de la lista de permitidos o del espejo.
Modo: ligero / estándar / completo
ligero
Los desarrolladores comprueban cada paquete nuevo en la página del repositorio y lo anotan en una hoja de cálculo compartida antes de instalarlo.
estándar
Un espejo interno contiene los paquetes aprobados y los nuevos se solicitan mediante una revisión breve.
completo
El sistema de compilación bloquea todo paquete que no esté en la lista aprobada y los controles de cadena de suministro se ejecutan automáticamente en cada solicitud.
Control 131
Plasma el ciclo de vida de desarrollo de la IA en un estándar escrito con compuertas de seguridad definidas.
EnhancedPreventivointegrador o desarrollador (deployer+)por sistema
Qué es
Indica, para cada etapa desde la admisión hasta la retirada, el trabajo de seguridad requerido y el punto en el que puede denegarse la publicación.
Cómo implantarlo · Estructura mínima
Alcance: los sistemas de IA y tipos de trabajo cubiertos (integración, configuración, entrenamiento)
Etapas de la entrada a la retirada: entrada, diseño, datos, construcción, evaluación, publicación, operación, retirada
Trabajo de seguridad por etapa: p. ej., clasificación de riesgo, revisión de amenazas, análisis de dependencias y secretos, validación
Puertas: dónde puede denegarse la publicación, quién decide y qué evidencia hace falta para pasar
Reglas para pasar experimentos a producción y verificar dependencias
Responsable, periodicidad de revisión y vía de excepciones
Cómo arrancar
Reconstruye cómo pasó realmente tu último sistema de IA de la idea a producción y marca dónde un control de seguridad debería haber podido pararlo.
Evidencia
La norma escrita aprobada y los registros de las puertas de cada sistema.
Modo: ligero / estándar / completo
ligero
Una norma breve que custodia quien lidera la IA, con una puerta antes de publicar firmada por la dirección.
estándar
La norma amplía la política de desarrollo de software existente, con puertas integradas en el proceso de publicación.
completo
Una norma específica cuya responsable es el equipo de arquitectura de seguridad, con puertas impuestas en el flujo y auditadas.
Control 135
Evalúa los modelos generativos frente a un conjunto de evaluación documentado antes de su publicación.
EnhancedDetectivodesarrollador (developer)por sistema
Qué es
La seguridad, la protección y el rendimiento en la tarea se miden sobre un conjunto fijo, y los resultados se registran y se comparan entre versiones.
Cómo implantarlo · Contenido mínimo
Casos de la tarea con respuestas esperadas o guía de puntuación
Casos de daño: peticiones dañinas, salida tóxica, consejos peligrosos en tu ámbito
Casos de seguridad: ataques con instrucciones ocultas, fuga de datos, extracción de las instrucciones del sistema
Un conjunto fijo y versionado, sin cambios entre las versiones que se comparan
Un umbral por categoría; resultados registrados por versión del modelo y comparados con la anterior
Cómo arrancar
Construye un primer conjunto de unos 100 casos de tarea, contenido dañino y seguridad, versiónalo y ejecútalo sobre el modelo actual para fijar la referencia.
Evidencia
Las versiones del conjunto de evaluación y los resultados de cada versión del modelo.
Modo: ligero / estándar / completo
ligero
Quien entrena el modelo guarda el conjunto y los resultados en una hoja de cálculo y lo ejecuta con un script sencillo.
estándar
El conjunto se versiona con el código del modelo y se ejecuta antes de cada publicación.
completo
Un equipo de evaluación mantiene el conjunto, lo ejecuta automáticamente y publica comparativas entre versiones.
Advanced3 controles
Control 132
Condiciona las publicaciones de alto riesgo a una aprobación de seguridad con autoridad para denegarlas.
AdvancedPreventivointegrador o desarrollador (deployer+)por sistema
Qué es
Incluidas pruebas adversariales cuando lo que está en juego lo justifique.
Cómo implantarlo · Pasos
Aplica el umbral de riesgo fijado en Gobernanza para decidir qué publicaciones pasan por la puerta
Haz la revisión de seguridad: amenazas, salvaguardas, accesos, dependencias, resultados de validación
Añade pruebas adversariales cuando lo justifique lo que está en juego: decisiones sobre personas, sistemas que actúan, exposición pública
Firma de un revisor nombrado e independiente del equipo de desarrollo, con autoridad escrita para denegar
Registra la decisión (aprobada, aprobada con condiciones, denegada) y sigue los hallazgos
Cómo arrancar
Nombra al revisor de seguridad, recoge su autoridad para denegar en la norma del ciclo de desarrollo y aplícala a la próxima publicación de alto riesgo.
Evidencia
Las firmas y denegaciones de la puerta, con los hallazgos de la revisión.
Modo: ligero / estándar / completo
ligero
Un revisor externo contratado hace la revisión y la dirección acepta formalmente su facultad de denegar.
estándar
El equipo de seguridad custodia la puerta y se contratan pruebas adversariales para las publicaciones de mayor riesgo.
completo
Un comité de revisión de seguridad con equipo adversarial propio custodia la puerta, impuesta en el flujo de publicación.
Control 133
Genera automáticamente la lista de materiales en la canalización de compilación.
AdvancedPreventivodesarrollador (developer)por sistema
Qué es
Producida por construcción, no por arqueología.
Cómo implantarlo · Contenido mínimo
Modelo base: nombre, versión, origen y suma de verificación
Conjuntos de datos: identificadores y versiones, enlazados a sus registros de linaje
Código y bibliotecas: versiones tal como las resuelve la compilación
Configuración de entrenamiento: parámetros y entorno
Resultados de evaluación de la compilación
Generada por el paso de compilación, guardada con el artefacto del modelo y enlazada al inventario de IA
Cómo arrancar
Añade al flujo de entrenamiento un paso que escriba el modelo base, las versiones de los datos y la lista de bibliotecas en un fichero guardado junto al modelo.
Evidencia
La lista de materiales generada por el flujo para cada versión del modelo.
Modo: ligero / estándar / completo
ligero
Un script breve al final de cada entrenamiento escribe el registro en la carpeta del modelo.
estándar
El flujo de entrenamiento genera la lista de materiales y la guarda en el registro de modelos.
completo
La plataforma genera y firma la lista de materiales en cada compilación y la envía al inventario y al análisis de dependencias.
Control 134
Ejecuta comprobaciones de regresión de seguridad y protección antes de cada despliegue.
AdvancedDetectivointegrador o desarrollador (deployer+)por sistema
Qué es
Un modelo que empieza a fallar una comprobación que antes superaba no se publica.
Cómo implantarlo · Pasos
Mantén un conjunto de regresión: intentos de inyección, prompts de fuga de datos, prompts de contenido dañino, casos clave de la tarea
Añade cada incidente y cada hallazgo de pruebas como un caso nuevo
Ejecuta el conjunto automáticamente con cada cambio de modelo, instrucciones, configuración o salvaguardas
Compara con la última versión que lo superó; cualquier caso que pase a fallar bloquea la publicación
Registra los resultados por versión; toda excepción requiere aprobación documentada
Cómo arrancar
Convierte los hallazgos de tus últimas pruebas e incidentes en un primer conjunto de casos de regresión y ejecútalo contra la versión actual.
Evidencia
Los resultados de las comprobaciones de regresión de cada despliegue.
Modo: ligero / estándar / completo
ligero
Un servicio contratado o una persona nombrada ejecuta el conjunto con un script antes de cada despliegue y guarda los resultados.
estándar
El conjunto se ejecuta en el flujo de publicación y bloquea los despliegues que fallan.
completo
Un equipo de calidad mantiene un conjunto amplio y versionado que se ejecuta con cada cambio, con informes de tendencia entre versiones.
Evidencia
Los registros de validación de la integración; los criterios de aceptación y los resultados de evaluación de cada versión del modelo; el registro de cambios de cada modelo; los informes de análisis de la cadena de construcción, que cubren modelos y conjuntos de datos; los resultados del escaneo de secretos en los cuadernos; los registros de revisión del código que pasa a producción; las aprobaciones y los rechazos en cada compuerta; las listas de componentes que genera la cadena; los resultados de las comprobaciones de regresión. Los registros de verificación de dependencias y la norma escrita del ciclo de vida de desarrollo. Los conjuntos y los resultados de evaluación previos a la publicación de cada versión.