Checklist de auditoría de seguridad de sistemas de IA para 2026

Las auditorías de seguridad de sistemas de IA requieren un checklist distinto a las auditorías de software tradicional. La superficie de amenaza incluye el modelo mismo, su pipeline de entrenamiento, su API de inferencia, el contenido que procesa, y las acciones que puede tomar —todas con clases de ataque que las revisiones estándar de seguridad de software no cubren—.

Este checklist está estructurado en seis dominios de control. Está diseñado para profesionales realizando una revisión de seguridad de primer pase de un sistema de IA que entra a producción, o auditando un despliegue existente contra una línea base mínima de seguridad. No es exhaustivo; trátalo como punto de partida, no como marco de certificación.

Dominio 1: Entradas del modelo — Inyección de prompts y validación de entrada

1.1 Controles de inyección directa

El prompt de sistema no es legible por el usuario ni exfiltrable mediante consultas normales.
Las instrucciones en el prompt de sistema incluyen guía explícita de rechazo para intentos de override (“ignora instrucciones anteriores”, solicitudes de persona de roleplay, etc.).
Los patrones conocidos de jailbreak se bloquean o marcan en la capa de aplicación antes de llegar al modelo.
No hay mecanismo por el cual la entrada de usuario pueda concatenarse directamente al contexto a nivel de prompt de sistema sin sanitización.

Por qué importa: los ataques de inyección directa hacen que los modelos sobrescriban instrucciones a nivel de sistema con las del usuario. Los prompts de sistema son la frontera primaria de instrucción y deben tratarse como frontera de confianza.

1.2 Controles de inyección indirecta

Todas las fuentes de contenido externo que el modelo procesa (documentos recuperados, páginas web, correos, cuerpos de ticket, salidas de herramientas) están identificadas y documentadas.
El contenido externo está segregado de los canales de instrucción confiables en la construcción del contexto. El contenido recuperado está claramente delimitado (envuelto en delimitadores estilo XML) y el modelo es instruido a tratarlo como dato, no instrucción.
El contenido externo se escanea por patrones de inyección antes de incluirse en el contexto del modelo.
La capacidad del modelo de incluir contenido externo en respuestas literalmente o actuar sobre instrucciones de contenido externo está restringida por validación de salida.

Por qué importa: la inyección indirecta vía contenido recuperado o enviado por usuario es OWASP LLM01. Es operacionalmente más peligrosa que la inyección directa porque el ataque viene de infraestructura que el modelo confía, no del usuario humano.

1.3 Procedencia de entrada

Cada pieza de contenido en el contexto del modelo está atribuida a una fuente (entrada de usuario, prompt de sistema, documento recuperado, salida de herramienta).
La atribución de fuente se preserva en logs para revisión forense.

Dominio 2: Pipeline de entrenamiento — Envenenamiento de datos y cadena de suministro

2.1 Procedencia de datos de entrenamiento

Los datasets de entrenamiento y fine-tuning tienen cadenas de procedencia documentadas. Las fuentes son conocidas y verificables.
Los datos de entradas de usuario o contribuciones comunitarias no se reinyectan a entrenamiento sin revisión humana.
El acceso de escritura a almacenes de datos de entrenamiento está auditado y restringido a principales autorizados.

Por qué importa: los ataques de envenenamiento requieren acceso de escritura a datos de entrenamiento. Si el pipeline puede ser alimentado con datos arbitrarios por partes externas, pueden introducirse backdoors o degradación de rendimiento.

2.2 Seguridad de artefactos de modelo

Los pesos de modelo cargados de fuentes externas se verifican contra checksums o firmas criptográficas antes de usarse.
Los archivos de modelo en formato pickle (.pkl, .pt) de fuentes no confiables no se cargan sin verificación. Se prefiere formato Safetensors donde esté disponible.
trust_remote_code=True no se usa con repositorios comunitarios sin investigar.
Los artefactos de modelo en producción están fijados a commit hashes o etiquetas de versión específicas, no latest.

Por qué importa: los archivos de modelo maliciosos pueden ejecutar código arbitrario al cargar. Esta es una amenaza activa de cadena de suministro; el hub de Hugging Face ha alojado modelos maliciosos con payloads pickle.

2.3 Aislamiento de fine-tuning

Los trabajos de fine-tuning corren en entornos aislados con egreso de red restringido a endpoints conocidos.
Los datos de fine-tuning se revisan por muestras adversarias antes de las corridas de entrenamiento.
La integridad del modelo base se verifica antes de que comience el fine-tuning.

Dominio 3: Salidas del modelo — Exfiltración y validación

3.1 Filtrado de salida

Las salidas del modelo se escanean por PII, secretos (claves API, credenciales) y categorías de datos sensibles antes de devolverse a usuarios o sistemas aguas abajo.
Las salidas se validan contra esquemas o formatos esperados antes de que sistemas aguas abajo actúen sobre ellas.
El renderizado markdown de salidas del modelo no recupera URLs remotas sin confirmación del usuario.

Por qué importa: los ataques de inyección y extracción de datos de entrenamiento pueden causar que los modelos incluyan contenido sensible en salidas. El renderizado markdown es un canal confiable de exfiltración para instrucciones inyectadas.

3.2 Integridad de respuesta

Las salidas del modelo no se tratan como instrucciones confiables por sistemas aguas abajo sin validación.
Las salidas de llamada a herramienta generadas por el modelo se validan contra una whitelist de nombres de herramienta y esquemas de parámetro permitidos antes de ejecución.
El contenido generado por IA que se envía a usuarios (borradores de correo, reportes, resúmenes) pasa por revisión humana para categorías de alto impacto.

Dominio 4: Control de acceso

4.1 Acceso al modelo

El acceso API al modelo está autenticado. No se permite acceso anónimo en producción.
Se imponen límites de tasa por usuario y por tenant para limitar extracción a escala.
Las claves API están limitadas a operaciones específicas y rotadas en un cronograma definido.

4.2 Acceso a herramientas e integraciones

Los agentes de IA tienen listas explícitas de herramientas permitidas y se les niega acceso a herramientas no en la lista.
Los permisos de herramientas siguen mínimo privilegio: agentes que solo necesitan acceso de lectura no tienen permisos de escritura o borrado.
Las acciones de herramienta de alto impacto (enviar correo, borrar datos, hacer llamadas a APIs externas) requieren aprobación humana antes de ejecución.
Las credenciales de acceso a herramientas no son visibles en el contexto del modelo y no pueden recuperarse mediante inyección de prompts.

Por qué importa: el acceso a herramientas es el amplificador que convierte un exploit de inyección de prompts de “el modelo dice algo incorrecto” a “el modelo toma acción no autorizada”. El acceso de mínimo privilegio es la mitigación de mayor impacto para seguridad de agentes.

4.3 Acceso a datos

El corpus de recuperación del modelo (corpus RAG, base de conocimiento) impone los mismos controles de acceso que los datos subyacentes. El modelo no puede sacar a la superficie documentos a usuarios sin acceso a ellos.
El aislamiento de datos entre tenants está verificado: las consultas de un usuario no pueden causar que el modelo recupere datos de otro corpus.

Dominio 5: Logging y monitoreo

5.1 Logging de entrada y salida

Todas las entradas del modelo (incluido contexto completo: prompt de sistema, historial de conversación, contenido recuperado) se loguean con timestamps e identificadores de usuario.
Todas las salidas del modelo se loguean.
Los logs se escriben en almacenamiento a prueba de manipulación. El proceso del modelo no puede modificar sus propios logs.
La retención de logs cumple requisitos de compliance para el contexto de despliegue.

Por qué importa: los ataques de inyección de prompts tienen éxito silenciosamente. La reconstrucción de un incidente requiere logs completos de entrada/salida.

5.2 Detección de anomalías

Hay alertas configuradas para patrones inusuales de consulta: alto volumen de un solo usuario, consultas que sondean el contenido del prompt de sistema, consultas con características estructurales de ataques conocidos.
Los logs de llamadas a herramienta se monitorean por secuencias inesperadas, parámetros inesperados o llamadas a endpoints fuera de patrones operacionales normales.
Las anomalías de respuesta se monitorean: salidas que fallan validación de esquema, salidas que incluyen categorías de contenido bloqueado, longitudes de salida inusuales.

5.3 Respuesta a incidentes

Hay un procedimiento documentado para deshabilitar el acceso API al modelo sin derribar la aplicación más amplia.
Los logs son accesibles a respondedores de incidentes que no son los operadores del sistema.
Hay un contacto de divulgación responsable para problemas de seguridad de IA en el producto desplegado.

Dominio 6: Requisitos de red team

6.1 Alcance mínimo de red team antes del despliegue en producción

La inyección directa de prompts ha sido probada contra el prompt de sistema con técnicas actuales de jailbreak.
La inyección indirecta ha sido probada contra cada fuente de contenido externo que el modelo procesa.
Si el modelo tiene acceso a herramientas: la explotación multi-paso de agente ha sido probada (instrucciones inyectadas que encadenan llamadas a herramientas).
Si el modelo procesa contenido cargado por usuario: la inyección basada en archivo ha sido probada (PDFs, documentos de Office, imágenes con texto embebido).
La cadena de suministro ha sido revisada: integridad de artefactos de modelo, versiones de dependencia, procedencia de datos de entrenamiento.

6.2 Cadencia continua de red team

Los ejercicios de red team se conducen al menos anualmente, o tras cambios significativos al modelo, sus herramientas o sus fuentes de contenido.
Los hallazgos se rastrean a resolución con SLAs.
La investigación de seguridad externa se monitorea y las técnicas divulgadas nuevas se evalúan contra el despliegue de producción.

Referencias y lectura adicional

Este checklist se basa en tres marcos primarios: