Key Takeaways
- SOC 2 e ISO 27001 certifican los controles de su organización, no una herramienta — nunca afirme "Ollama cumple con SOC 2" o "vLLM está certificado ISO 27001". Presente todo como preparación para los controles que un auditor revisará.
- SOC 2 evalúa según cinco Trust Services Criteria (seguridad, disponibilidad, confidencialidad, integridad de procesamiento, privacidad); ISO 27001 evalúa según los controles Annex A dentro de un ISMS documentado.
- El endpoint de inferencia necesita control de acceso y registro estructurado de solicitudes — la mayoría de los motores autoalojados (Ollama, vLLM, TGI) no ofrecen nada de esto por defecto y necesitan un gateway delante.
- Cifre los pesos del modelo y los registros de prompts/respuestas en reposo (cifrado de disco) y en tránsito (TLS) — los mismos controles que ya aplica a cualquier otro almacén de datos de producción.
- Incluso los modelos open-weight necesitan una evaluación documentada de riesgo de proveedor: identidad del publicador, verificación de checksum, condiciones de licencia y CVEs conocidas en el stack de servicio.
- Las plataformas de automatización de cumplimiento (Vanta, Drata, Secureframe) pueden extraer evidencia automáticamente de infraestructura en la nube, pero un servidor de inferencia autoalojado suele necesitar una integración a medida o carga manual de evidencia.
- Este artículo no es asesoría legal ni de cumplimiento — su auditor toma la decisión final de alcance y controles.
¿Esto Es Asesoría Legal o de Cumplimiento?
No — esta guía no es asesoría legal ni de cumplimiento. Explica, a nivel técnico, las categorías de controles que un auditor de SOC 2 o ISO 27001 suele revisar y cómo se aplican a un despliegue de LLM autoalojado. Si un control específico satisface su auditoría depende del criterio de su auditor, la evaluación de riesgos de su organización y la declaración exacta de alcance que presente. Consulte a un auditor calificado o a su equipo de cumplimiento antes de programar una auditoría o hacer cualquier declaración de cumplimiento.
¿Qué Exigen los Trust Services Criteria de SOC 2?
SOC 2 evalúa a una organización según cinco Trust Services Criteria (TSC), y cada uno aplica a un sistema de LLM autoalojado en el momento en que toca datos de producción. Un auditor no prueba el modelo — prueba si su organización puede demostrar que el control existió y funcionó durante el periodo de revisión.
| Criterio | Qué revisan los auditores | Control en el stack de LLM |
|---|---|---|
| Seguridad | Control de acceso, registro, gestión de vulnerabilidades | RBAC + MFA en el gateway de inferencia |
| Disponibilidad | Tiempo de actividad, redundancia, plan de DR | Servicio multi-nodo + backups probados |
| Confidencialidad | Clasificación de datos, necesidad de saber | Pesos + registros cifrados en reposo |
| Integridad de procesamiento | Exactitud, integridad, oportunidad | Modelos fijados por versión + registros de salida |
| Privacidad | Aviso, consentimiento, minimización de datos | Política documentada de retención de prompts |
¿Qué Exige el Annex A de ISO 27001?
ISO 27001 certifica el Sistema de Gestión de Seguridad de la Información (ISMS) de una organización, y el Annex A es la lista de referencia de controles de la que se nutre el ISMS — no una checklist aplicada directamente a un solo sistema. Un LLM autoalojado se sitúa dentro del alcance del ISMS como cualquier otro activo: necesita una evaluación de riesgos, una entrada en la Declaración de Aplicabilidad, y evidencia de que los controles relevantes funcionan.
| Área Annex A | Aplicación al stack de LLM |
|---|---|
| A.5 Organizacional | Revisión de riesgo de proveedor del publicador del modelo |
| A.5.19–22 Relaciones con proveedores | Procedencia del modelo y verificación de licencia |
| A.8 Tecnológico | Endurecimiento de endpoint, cifrado, registro |
| A.8.16 Actividades de monitoreo | Registros de auditoría de solicitudes/respuestas |
| A.8.24 Criptografía | TLS en tránsito, cifrado de disco en reposo |
| A.5.29 Continuidad | Runbook de respuesta a incidentes para el servicio de modelo |
¿Qué Control de Acceso y Registro Necesita el Endpoint de Inferencia?
Un auditor espera ver quién llamó al modelo, con qué credencial y cuándo — un requisito que ninguno de los motores autoalojados comunes cumple sin un gateway delante. Ollama se vincula por defecto a `127.0.0.1:11434` y no tiene cuentas de usuario; vLLM y Hugging Face TGI exponen una API HTTP compatible con OpenAI sin autenticación integrada.
Use un API gateway (Kong, Envoy, o la capa de gestión de API de un proveedor cloud) delante del motor de inferencia para añadir claves API u OAuth2 por llamador, y registre cada solicitud con identidad, marca temporal, versión del modelo y conteo de tokens hacia un sistema que su SIEM pueda ingerir.
- Autenticación: claves API u OAuth2 en el gateway, nunca un token compartido por todos los llamadores
- Autorización: acceso basado en roles — quién puede llamar a qué modelo, quién ve los endpoints de admin/métricas
- Campos del registro de auditoría: identidad del llamador, marca temporal, modelo + versión, endpoint llamado, estado de respuesta
- Acceso admin: MFA obligatoria para cualquiera con acceso shell o de configuración al host de inferencia
¿Cómo Cifrar los Pesos del Modelo y los Registros de Prompts?
Los pesos del modelo, los registros de prompts y de respuestas necesitan el mismo cifrado en reposo y en tránsito que un auditor ya espera para cualquier otro almacén de datos de producción. Los pesos en sí no suelen ser secretos, pero el disco del servidor de inferencia suele contener también prompts en caché, adaptadores fine-tuneados y registros que sí lo son.
Use cifrado de disco completo (LUKS en Linux, BitLocker en Windows, FileVault en macOS) en el host de inferencia como línea base. Añada terminación TLS en el gateway para cada llamada API entrante — nunca exponga el puerto de inferencia sin cifrar sobre HTTP en texto plano, ni siquiera dentro de una VPC.
- En reposo: cifrado de disco completo en el host, volumen cifrado para la base de datos de registros de prompts
- En tránsito: TLS entre llamador → gateway → motor de inferencia, sin salto interno en texto plano
- Gestión de claves: claves almacenadas en un KMS/vault, rotadas según un calendario documentado
¿Cómo Es la Gestión de Cambios para Actualizaciones de Modelo?
Todo cambio de versión de modelo, cambio de cuantización o edición de prompt de sistema es un cambio de producción y necesita el mismo rastro de aprobación que un despliegue de código. Los auditores buscan específicamente evidencia de que los cambios fueron revisados y aprobados antes de salir a producción.
- Fijar el artefacto exacto del modelo (checksum, no un tag mutable "latest")
- Exigir un paso de aprobación documentado antes de cualquier cambio de modelo o prompt de sistema en producción
- Registrar cada cambio con quién lo aprobó, cuándo y por qué
- Mantener una ruta de rollback al artefacto anterior fijado por versión
¿Cómo Evaluar el Riesgo de Proveedor en Modelos Open-Weight?
"Open-weight" no significa "sin proveedor" — el publicador del modelo es una parte de la cadena de suministro igual que un proveedor SaaS, y un auditor espera una evaluación de riesgo documentada al respecto. Este es uno de los controles más comúnmente omitidos: los equipos tratan un archivo GGUF o safetensors descargado como interno, no como de terceros, aunque se originó fuera de la organización.
- Identidad del publicador: organización conocida (Meta, Mistral AI, Alibaba/Qwen, Microsoft) vs. fuente anónima
- Verificación de checksum: coincidencia SHA-256 con el hash publicado por el editor antes del despliegue
- Revisión de licencia: condiciones de uso comercial, restricciones de redistribución
- CVEs del stack de servicio: rastrear vulnerabilidades conocidas en llama.cpp, vLLM o TGI — no solo el archivo del modelo
¿Cómo Es la Respuesta a Incidentes para un Sistema de Servicio de Modelo?
Un sistema de servicio de modelo tiene categorías de incidentes que un runbook estándar de aplicación web no cubre — exfiltración del modelo, inyección de prompts que filtra datos a través de la propia salida del modelo, y compromiso del endpoint de inferencia — cada una necesita una ruta de respuesta nombrada.
- Ejemplos de disparadores: cambio no autorizado del archivo de pesos, pico de solicitudes a nivel de credencial, patrón de inyección de prompts en los registros
- Paso de contención: capacidad de aislar o desconectar el endpoint de inferencia sin una interrupción total del sistema
- Preservación de evidencia: conservar los registros brutos durante la ventana del incidente
- Frecuencia de pruebas: ejercicio de mesa al menos anual, documentado
¿Qué Debe Cubrir una Política de Retención para Registros de Prompts?
Los registros de prompts son los datos de mayor riesgo que produce su stack de LLM, porque suelen contener el mismo contenido sensible que un usuario escribiría en cualquier otro sistema de negocio. Una política de retención por escrito es un control que un auditor pedirá ver específicamente, no algo que pueda inferirse de su política general de retención de datos.
- Ventana de retención: defina un número específico de días/meses, no "indefinidamente"
- Control de acceso: el almacén de registros de prompts tiene su propia lista de acceso restringida
- Minimización: registre metadatos por defecto; registro de contenido completo solo cuando esté justificado y limitado en el tiempo
- Proceso de eliminación: documentado e idealmente automatizado
¿Cómo Debería Segmentarse el Servidor de Inferencia en la Red?
El servidor de inferencia debe estar en su propia zona de red, accesible solo a través del gateway autenticado — no en el mismo subnet que los servidores de aplicación generales. Esto limita el radio de impacto si se compromete otro servicio en la red y le da al auditor un diagrama de red claro para revisar.
¿Qué Herramientas Autoalojadas Ofrecen Controles Relevantes para Auditoría?
Ninguno de los motores de inferencia comunes entrega un rastro de auditoría terminado — la diferencia está en cuánto debe construir usted frente a cuánto ya ofrece una plataforma. Esto es una comparación de preparación, no una declaración de cumplimiento sobre ninguna de estas herramientas.
| Herramienta | Auth/Registro integrado | Instrumentación necesaria |
|---|---|---|
| Ollama | Ninguno (se vincula a localhost) | Reverse proxy + auth + exportación SIEM |
| vLLM | Solo métricas Prometheus | API gateway (OAuth2/claves) + registro de auditoría |
| Hugging Face TGI | Solo métricas Prometheus | API gateway + registro de auditoría, igual que vLLM |
| Plataformas empresariales | RBAC + registro de auditoría integrados | Aún requiere documentación ISMS |
¿Puede una Plataforma de Automatización de Cumplimiento Ayudar con un LLM Autoalojado?
Las plataformas de automatización de cumplimiento — Vanta, Drata y Secureframe son las tres más usadas — extraen evidencia automáticamente de infraestructura cloud, sistemas de RRHH y proveedores de identidad, pero un servidor de inferencia autoalojado on-prem suele quedar fuera de su lista de integraciones por defecto.
Use una plataforma de automatización de cumplimiento si gestiona un programa SOC 2 o ISO 27001 más amplio en toda la empresa y quiere monitoreo continuo para todo excepto la capa de LLM autoalojada.
| Plataforma | Enfoque |
|---|---|
| Vanta | Amplia cobertura de frameworks, común en startups |
| Drata | Monitoreo continuo de controles, integraciones profundas |
| Secureframe | Flujos combinados SOC 2 + ISO 27001 |
Estas plataformas automatizan la recopilación de evidencia para su entorno de control más amplio — no certifican su infraestructura de LLM autoalojada por sí mismas, y PromptQuorum no tiene actualmente relación de afiliación con ninguna de ellas (solo enlaces de producto divulgados).
¿Cuáles Son los Errores Más Comunes en la Preparación para Auditoría?
La mayoría de los hallazgos de auditoría en LLMs autoalojados provienen de tratar el servidor de inferencia como algo fuera del entorno normal de control de TI.
- Error: Asumir que una herramienta open source "auditable" (código visible) ya está auditada. Corrección: documente su propia evaluación de riesgo del publicador y el stack de servicio.
- Error: Dejar la API de inferencia accesible sin gateway "porque es solo interna". Corrección: la accesibilidad de red no es lo mismo que control de acceso — añada autenticación de todos modos.
- Error: Registrar el texto completo del prompt en el mismo log de acceso usado para monitoreo de disponibilidad. Corrección: separe ambos almacenes.
- Error: Tratar un cambio de versión de modelo como un despliegue rutinario sin rastro de aprobación. Corrección: aplique la misma aprobación de gestión de cambios que para despliegues de código.
- Error: No tener un plan de respuesta a incidentes específico para los modos de falla del servicio de modelo. Corrección: añada estos disparadores a su plan de IR existente y pruébelos al menos una vez.
¿Cuál Es la Checklist de Preparación para Auditoría de un LLM Autoalojado?
Recorra esta checklist antes de que empiece el trabajo de campo de su auditor — cada punto corresponde a una categoría de control cubierta arriba.
- 1Añadir el sistema de LLM autoalojado a su declaración de alcance ISMS/SOC 2
Why it matters: Un sistema no documentado dentro del alcance es un hallazgo aunque cada control técnico esté implementado. - 2Mapear los Trust Services Criteria o controles Annex A relevantes a su stack real
Why it matters: Los auditores prueban contra el mapeo que usted provee. - 3Colocar un gateway autenticado delante de cada endpoint de inferencia
Why it matters: Elimina el hallazgo más común: una API de modelo sin autenticación. - 4Activar el registro estructurado de solicitudes con identidad del llamador y marcas temporales
Why it matters: Es la evidencia principal que un auditor solicita para el criterio de seguridad. - 5Cifrar el disco del host y el almacén de registros de prompts; exigir TLS en el gateway
Why it matters: Satisface el criterio de confidencialidad y los controles criptográficos A.8.24. - 6Escribir y seguir un procedimiento de gestión de cambios para actualizaciones de modelo
Why it matters: Prueba integridad de procesamiento y da una ruta de rollback documentada. - 7Documentar una evaluación de riesgo de proveedor para cada modelo open-weight en producción
Why it matters: Cierra el control más comúnmente omitido. - 8Publicar una política de retención y eliminación para registros de prompts/respuestas
Why it matters: Directamente requerido para el criterio de privacidad. - 9Segmentar el servidor de inferencia en su propia zona de red
Why it matters: Limita el radio de impacto y da al auditor un diagrama de red claro. - 10Escribir un runbook de respuesta a incidentes con disparadores específicos del modelo y probarlo una vez
Why it matters: Los auditores verifican que el plan existe y ha sido ejercitado.
Preguntas Frecuentes
¿Este artículo es asesoría legal o de cumplimiento?
No. Esta guía explica, a nivel técnico, las categorías de controles que un auditor de SOC 2 o ISO 27001 suele revisar. No sustituye a un auditor calificado ni a su equipo de cumplimiento — consulte a uno antes de programar una auditoría o hacer cualquier declaración de cumplimiento.
¿Usar Ollama, vLLM o Hugging Face TGI hace que nuestra infraestructura de IA cumpla con SOC 2?
Ninguna herramienta por sí sola hace que una organización sea conforme. El cumplimiento es un resultado de auditoría sobre el conjunto completo de controles de su organización. Ollama, vLLM y TGI pueden sustentar los requisitos técnicos (una vez que añada autenticación, registro y cifrado), pero ninguno es "compatible con SOC 2" ni "certificado ISO 27001" como producto de software.
¿Cuál es la diferencia entre SOC 2 Type I y Type II para infraestructura de IA?
Type I evalúa si los controles fueron diseñados adecuadamente en un momento dado. Type II evalúa si esos controles funcionaron eficazmente durante un periodo de revisión, normalmente 6–12 meses. Para un endpoint de inferencia, Type II significa que sus registros de acceso y evidencia de gestión de cambios deben existir de forma continua durante toda esa ventana.
¿Los modelos open-weight necesitan una evaluación de riesgo de proveedor aunque no exista un proveedor de software?
Sí. El publicador del modelo (Meta, Mistral AI, Alibaba/Qwen u otros) es una parte de la cadena de suministro igual que un proveedor SaaS. Una evaluación documentada debe cubrir identidad del publicador, verificación de checksum de los pesos descargados, condiciones de licencia y CVEs conocidas en el stack de servicio que carga el modelo.
¿Autoalojar un LLM reduce nuestro alcance de auditoría frente a una API de LLM en la nube?
Cambia el alcance más que reducirlo simplemente. Autoalojar elimina la relación de procesador de datos de terceros que crea una API en la nube, pero también significa que su organización ahora posee todos los controles que antes manejaba el proveedor cloud.
¿Qué registro espera un auditor en el endpoint de inferencia?
Como mínimo: identidad del llamador (clave API o usuario autenticado), marca temporal, modelo y versión llamados, endpoint y estado de respuesta, exportados a un almacén con acceso de escritura restringido. El contenido completo de prompts/respuestas suele guardarse en un almacén separado y más estrictamente controlado.
¿Cuánto tiempo debemos retener los registros de prompts como evidencia de auditoría?
No hay un número universal — depende de la evaluación de riesgo de su organización y las expectativas de su auditor, equilibradas con los principios de minimización de datos bajo cualquier ley de privacidad aplicable. Defina una ventana de retención específica por escrito, nunca "indefinidamente".
¿Pueden plataformas como Vanta, Drata o Secureframe monitorear un servidor de LLM autoalojado?
Automatizan bien la recopilación de evidencia para infraestructura cloud, proveedores de identidad y sistemas de tickets, pero un servidor de inferencia autoalojado on-prem suele quedar fuera de su lista de integraciones por defecto.
¿Cuál es el hallazgo de auditoría más común en infraestructura de IA autoalojada?
Una API de inferencia accesible sin autenticación, justificada internamente como "solo es accesible dentro de nuestra red". Accesibilidad de red y control de acceso son afirmaciones distintas — un auditor espera autenticación en el endpoint independientemente de la ubicación en la red.
¿Deberíamos elegir vLLM/TGI o una plataforma de inferencia empresarial para facilitar la preparación de auditoría?
vLLM y Hugging Face TGI dan control total pero requieren que usted construya la capa de autenticación, registro y cifrado. Las plataformas empresariales suelen incluir RBAC y registro de auditoría integrados, reduciendo el trabajo de instrumentación — pero de todos modos necesita la documentación ISMS y la evaluación de riesgo de proveedor circundantes.
¿Dónde Puede Encontrar Fuentes Adicionales?
- AICPA SOC 2 Trust Services Criteria (aicpa-cima.com) — el framework oficial de Trust Services Criteria contra el que se evalúan las auditorías SOC 2
- ISO/IEC 27001:2022 (iso.org) — el texto oficial del estándar y la referencia de controles Annex A
- OWASP Top 10 for LLM Applications (owasp.org/www-project-top-10-for-large-language-model-applications) — riesgos de seguridad específicos de despliegues de LLM, incluyendo riesgo de cadena de suministro e inyección de prompts