Evaluación de preparación para ISO 42001 y SOC 2
Mapea la implementación de referencia ai-agent-eval-harness-healthtech frente a
la norma ISO/IEC 42001:2023 (Sistema de Gestión de IA) y los Criterios de Servicios de Confianza de SOC 2.
Esta es una evaluación honesta de preparación: el sistema es una implementación de referencia
y no ha sido auditado frente a ninguna de las dos normas. La evaluación valora qué
controles existen, cuáles están parcialmente abordados y qué requeriría un proceso formal
de certificación.
Léase junto con el mapeo del NIST AI RMF y el plan de registro de auditoría.
ISO/IEC 42001:2023 — Sistema de Gestión de IA
Section titled “ISO/IEC 42001:2023 — Sistema de Gestión de IA”ISO 42001 es la primera norma internacional para sistemas de gestión de IA. Proporciona un marco para establecer, implementar, mantener y mejorar continuamente un sistema de gestión de IA dentro de una organización. La norma sigue la estructura armonizada de las normas de sistemas de gestión de ISO (Planificar-Hacer-Verificar-Actuar).
Mapeo cláusula por cláusula
Section titled “Mapeo cláusula por cláusula”Cláusula 4: Contexto de la organización
Section titled “Cláusula 4: Contexto de la organización”| Requisito | Implementación actual | Brecha |
|---|---|---|
| 4.1 Comprensión de la organización y su contexto | El alcance del repositorio (implementación de referencia), los invariantes y las partes interesadas previstas (ingenieros, revisores de gobernanza) se describen en la visión general del repositorio y el proceso de divulgación de seguridad | El contexto cubre el repositorio; un SGSI formal necesitaría un contexto organizacional que incluya la estrategia de negocio, el mercado y el panorama regulatorio |
| 4.2 Comprensión de las necesidades y expectativas de las partes interesadas | Usuarios previstos definidos en la ficha del modelo: ingenieros, revisores de gobernanza; postura regulatoria definida en la postura regulatoria | No hay un análisis formal de partes interesadas; el proyecto de autor único tiene una diversidad limitada de partes interesadas |
| 4.3 Determinación del alcance del sistema de gestión de IA | Alcance definido en la especificación del sistema y la postura regulatoria: coach de bienestar para la adherencia a la medicación, orientado al paciente, sin funciones clínicas | El alcance es a nivel de repositorio; el alcance de un SGSI cubriría todo el ciclo de vida de la IA dentro de la organización |
| 4.4 Sistema de gestión de IA | El arnés de evaluación como sistema de medición; los registros de decisiones de arquitectura como registros de decisiones; las barreras de seguridad como controles; OpenTelemetry como monitoreo; la postura regulatoria como política | Demuestra el patrón; no es un sistema de gestión formal con procedimientos, responsabilidades y ciclos de revisión definidos |
Cláusula 5: Liderazgo
Section titled “Cláusula 5: Liderazgo”| Requisito | Implementación actual | Brecha |
|---|---|---|
| 5.1 Liderazgo y compromiso | El compromiso del autor con la gobernanza se demuestra mediante un extenso conjunto de documentos de gobernanza y registros de decisiones de arquitectura, el arnés de evaluación y declaraciones honestas de limitaciones | Autor único; no hay una estructura de compromiso de la alta dirección; no hay un proceso de asignación de recursos |
| 5.2 Política | La postura regulatoria sirve como política regulatoria; el registro de decisión operativa recoge las políticas operativas | No hay un documento de política de IA formal; las políticas están distribuidas en múltiples artefactos |
| 5.3 Roles, responsabilidades y autoridades organizacionales | Propiedad de los módulos documentada (barreras de seguridad, evaluaciones, observabilidad); propiedad de cada registro de decisión | No hay definiciones formales de roles; no hay delegación de autoridad; no hay separación de funciones |
Cláusula 6: Planificación
Section titled “Cláusula 6: Planificación”| Requisito | Implementación actual | Brecha |
|---|---|---|
| 6.1 Acciones para abordar riesgos y oportunidades | El modelo de amenazas OWASP / ATLAS mapea amenazas; el mapeo del NIST AI RMF mapea funciones de riesgo; el arnés de evaluación detecta regresiones; el red-team nocturno pone a prueba riesgos adversarios | No hay un registro de riesgos formal; no hay un plan de tratamiento del riesgo; no hay un registro de oportunidades |
| 6.2 Objetivos de IA y planificación para alcanzarlos | La especificación del sistema define los objetivos; los umbrales de evaluación definen metas medibles; el historial de versiones se publica | Los objetivos son a nivel de repositorio; no hay objetivos de IA organizacionales ni planes de recursos |
| 6.3 Evaluación de riesgos de IA | Modelo de amenazas (OWASP/ATLAS), mapeo del NIST AI RMF, declaraciones honestas de limitaciones en la ficha del modelo | La evaluación es cualitativa y está documentada; no hay puntuación de riesgo cuantitativa; no hay aceptación del riesgo residual |
Cláusula 7: Apoyo
Section titled “Cláusula 7: Apoyo”| Requisito | Implementación actual | Brecha |
|---|---|---|
| 7.1 Recursos | Objetivo de costo de $0/mes; infraestructura de capa gratuita; herramientas existentes (pytest, OpenTelemetry, Promptfoo) | No hay un proceso de planificación de recursos; no hay asignación de presupuesto; no hay gestión de capacidad |
| 7.2 Competencia | El autor demuestra competencia en el dominio a través de las decisiones de arquitectura, el mapeo regulatorio y la documentación de gobernanza | No hay un marco de competencias; no hay registros de capacitación; no hay un proceso de evaluación de competencias |
| 7.3 Concientización | El control de cambios de la postura regulatoria requiere un registro de decisión para los cambios de alcance; el proceso de divulgación de seguridad | No hay un programa formal de concientización; no hay métricas de concientización |
| 7.4 Comunicación | Documentos de gobernanza públicos; la ficha del modelo; la postura regulatoria; los registros de decisiones de arquitectura | La comunicación es pasiva (documentos publicados); no hay un plan activo de comunicación con las partes interesadas |
| 7.5 Información documentada | Registros de decisiones de arquitectura, documentos de gobernanza, la especificación del sistema, la postura regulatoria, la declaración de datos, la ficha del modelo | La documentación es integral; bajo control de versiones; no hay un sistema formal de gestión documental |
Cláusula 8: Operación
Section titled “Cláusula 8: Operación”| Requisito | Implementación actual | Brecha |
|---|---|---|
| 8.1 Planificación y control operativos | El arnés de evaluación controla cada cambio; las barreras de seguridad hacen cumplir el alcance; OpenTelemetry monitorea la ejecución; presupuestos de costo/latencia aplicados | Los controles operativos existen; no hay un plan operativo formal; no hay un proceso de gestión de cambios |
| 8.2 Evaluación de riesgos de IA (operativa) | El clasificador de alcance se ejecuta en cada entrada; la detección de escalamiento se ejecuta en cada entrada; la redacción de PII se ejecuta en cada entrada/salida | Evaluación de riesgos en tiempo real para funciones críticas de seguridad; no hay una evaluación de riesgos operativa más amplia |
| 8.3 Tratamiento de riesgos de IA | Arquitectura con barreras de seguridad antes del LLM; rechazo ante lo que queda fuera de alcance; escalamiento ante señales de alarma agudas; exigencia de citaciones | Los tratamientos del riesgo están implementados y probados; no hay un plan de tratamiento formal con responsable, cronograma y criterios de aceptación |
Cláusula 9: Evaluación del desempeño
Section titled “Cláusula 9: Evaluación del desempeño”| Requisito | Implementación actual | Brecha |
|---|---|---|
| 9.1 Seguimiento, medición, análisis y evaluación | Arnés de evaluación (7 dimensiones, 315 casos); spans de OpenTelemetry; compuertas de costo/latencia; aplicación de la paridad entre locales | El monitoreo es integral para la implementación de referencia; no hay un reporte de desempeño a nivel de revisión por la dirección |
| 9.2 Auditoría interna | No hay auditoría interna formal | No hay un programa de auditoría; no hay criterios de auditoría; no hay seguimiento de hallazgos de auditoría |
| 9.3 Revisión por la dirección | No hay revisión por la dirección formal | No hay un ciclo de revisión; no hay entradas/salidas de revisión; no hay puntos de acción derivados de la revisión |
Cláusula 10: Mejora
Section titled “Cláusula 10: Mejora”| Requisito | Implementación actual | Brecha |
|---|---|---|
| 10.1 Mejora continua | Los hallazgos del red-team se incorporan al banco de semillas; la regresión de evaluación impulsa correcciones de código; el historial de versiones se publica | La mejora es reactiva e interna al repositorio; no hay un programa formal de mejora continua |
| 10.2 No conformidad y acción correctiva | La regresión de evaluación falla la verificación de CI (una señal, no una compuerta de fusión dura - sin protección de rama forzada); el proceso de divulgación de seguridad | No hay una gestión formal de no conformidades; no hay un proceso de análisis de causa raíz; no hay seguimiento de acciones correctivas |
Mapeo de los Criterios de Servicios de Confianza de SOC 2
Section titled “Mapeo de los Criterios de Servicios de Confianza de SOC 2”SOC 2 (Controles de Sistemas y Organizaciones 2) evalúa a las organizaciones de servicios frente a cinco Criterios de Servicios de Confianza: Seguridad, Disponibilidad, Integridad del Procesamiento, Confidencialidad y Privacidad.
Criterios Comunes (Seguridad) — Requeridos para todos los compromisos
Section titled “Criterios Comunes (Seguridad) — Requeridos para todos los compromisos”| Control | Implementación actual | Brecha |
|---|---|---|
| CC6.1 Controles de acceso lógico | Sin autenticación en tiempo de ejecución para la API de demostración; acceso a nivel de repositorio; sin gestión de identidad de usuario | Producción necesitaría procesos de autenticación, autorización y revisión de acceso |
| CC6.2 Controles de acceso físico | Heredado del proveedor de nube (Google Cloud Run; sin infraestructura física gestionada por el cliente) | Producción con componentes locales necesitaría controles de acceso físico |
| CC6.3 Cifrado de datos | HTTPS en Google Cloud Run (provisto por la plataforma); sin cifrado en reposo (sin almacenamiento persistente) | Producción necesitaría TLS 1.3 como mínimo; AES-256 en reposo para cualquier dato almacenado |
| CC7.1 Gestión de cambios | Los registros de decisiones de arquitectura documentan los cambios; el arnés de evaluación controla los cambios; versionado semántico; notas de versión | No hay un proceso formal de gestión de cambios con flujos de aprobación y procedimientos de reversión |
| CC7.2 Mitigación de riesgos | Barreras de seguridad, arnés de evaluación, red-team, redacción de PII, monitoreo con OpenTelemetry | Los controles existen; no hay un programa formal de mitigación de riesgos con seguimiento y reporte |
| CC7.3 Respuesta a incidentes | El proceso de divulgación de seguridad; escaneo de secretos | No hay un plan formal de respuesta a incidentes; no hay clasificación de severidad; no hay procedimientos de notificación |
| CC8.1 Gestión de cambios (detallada) | Flujo de trabajo basado en cambios; pruebas de regresión de evaluación; control de versiones | No hay una junta formal de aprobación de cambios; no hay una lista de verificación de validación previa al despliegue |
Disponibilidad
Section titled “Disponibilidad”| Control | Implementación actual | Brecha |
|---|---|---|
| A1.1 Disponibilidad del sistema | Única instancia scale-to-zero de Google Cloud Run (scale-to-zero, arranque en frío en la primera solicitud tras inactividad; cerca de $0 a escala de demo); sin SLA | Producción necesitaría objetivos de disponibilidad, monitoreo, alertas y escalamiento de incidentes |
| A1.2 Respaldo y recuperación | No se necesita respaldo (sin datos persistentes); corpus de evaluación y KB bajo control de versiones | Producción con datos persistentes necesitaría procedimientos de respaldo, pruebas de recuperación, objetivos de RTO/RPO |
Integridad del procesamiento
Section titled “Integridad del procesamiento”| Control | Implementación actual | Brecha |
|---|---|---|
| PI1.1 Integridad del procesamiento | El arnés de evaluación valida la calidad de la salida (fidelidad, alucinación, citación); las barreras de seguridad hacen cumplir el alcance; compuerta determinista en CI | El procesamiento se mide frente a umbrales definidos; no hay controles de integridad del procesamiento visibles para el usuario final |
| PI1.2 Procesamiento de entrada | El clasificador de alcance valida la entrada; la redacción de PII sanea la entrada; límites de longitud de entrada | La validación de entrada existe por seguridad; no hay controles más amplios de calidad de la entrada |
Confidencialidad
Section titled “Confidencialidad”| Control | Implementación actual | Brecha |
|---|---|---|
| C1.1 Protecciones de confidencialidad | Sin PHI/PII en almacenamiento; texto del usuario excluido de los spans de OpenTelemetry; redacción de PII en entrada/salida; el escaneo de secretos previene la exposición de secretos | La confidencialidad se mantiene al no almacenar datos sensibles; producción necesitaría controles de confidencialidad activos para los datos almacenados |
Privacidad
Section titled “Privacidad”| Control | Implementación actual | Brecha |
|---|---|---|
| P1.1 Aviso de privacidad | Aviso de demostración en cada respuesta; la ficha del modelo; la postura regulatoria | No hay un aviso de privacidad formal; no hay divulgación de recopilación de datos; no hay gestión de consentimiento |
| P2.1 Gestión del consentimiento | Consentimiento de voz (modal de divulgación, interruptor de aceptación, avisos de “El audio NO se conserva”) | El consentimiento existe solo para voz; no hay gestión de consentimiento para el procesamiento de datos en general |
| P3.1 Recopilación de datos | No se recopilan datos personales; 100% sintético | Producción necesitaría políticas de recopilación de datos, limitación de propósito y procedimientos de minimización |
| P4.1 Acceso y eliminación de datos | No hay datos personales que acceder o eliminar | Producción necesitaría procedimientos de solicitud de acceso y eliminación por parte del titular de los datos |
| P6.1 Retención de datos | Sin datos persistentes; no se necesita retención | Producción necesitaría cronogramas de retención, procedimientos de eliminación segura y monitoreo de la retención |
Estado actual
Section titled “Estado actual”La implementación de referencia demuestra una postura de gobernanza que se alinea con los principios tanto de ISO 42001 como de SOC 2, implementada a la profundidad que un proyecto de referencia de autor único puede lograr razonablemente:
-
Alineación con ISO 42001: Trazabilidad basada en registros de decisiones (Cláusula 7.5), el arnés de evaluación como sistema de medición (Cláusula 9.1), las barreras de seguridad como tratamiento del riesgo (Cláusula 8.3), evaluación honesta del riesgo (Cláusula 6.3), documentación transparente (Cláusulas 4, 7.4)
-
Alineación con SOC 2: El arnés de evaluación como control de integridad del procesamiento (PI1.1), las barreras de seguridad y la redacción de PII como controles de confidencialidad (C1.1), privacidad por diseño (P1-P6), monitoreo con OpenTelemetry como control de seguridad (CC7.2), gestión de cambios basada en registros de decisiones (CC7.1)
La evaluación honesta es que esto es una implementación de referencia consciente de la gobernanza, no un sistema de gestión certificado. No se ha realizado ninguna auditoría de ISO 42001. No se ha realizado ningún compromiso de SOC 2. El valor está en demostrar que los patrones de gobernanza se comprenden y se implementan a un nivel que aceleraría una certificación formal en caso de que se persiguiera.
Camino a producción
Section titled “Camino a producción”Lograr la certificación ISO 42001 o la atestación SOC 2 Tipo II:
-
SGSI formal (ISO 42001): Sistema de gestión de IA documentado con alcance definido, compromiso del liderazgo, registro de riesgos, objetivos, planes operativos, evaluación del desempeño y programa de mejora continua; programa de auditoría interna; ciclo de revisión por la dirección
-
Preparación para SOC 2 Tipo I: Controles documentados para todos los Criterios de Servicios de Confianza aplicables; recopilación de evidencia para la existencia de los controles; evaluación de preparación por una firma de contadores públicos certificados (CPA) cualificada
-
Atestación SOC 2 Tipo II: 6-12 meses de evidencia operativa para todos los controles; auditoría independiente por una firma de CPA; informe de atestación que cubra el período de observación
-
Automatización de la recopilación de evidencia: Recopilación y organización automatizadas de la evidencia de auditoría (registros de ejecuciones de evaluación, registros de cambios, registros de acceso, informes de incidentes, registros de capacitación); repositorio de evidencia con políticas de retención
-
Monitoreo continuo: Monitoreo en tiempo real de la eficacia de los controles; alertas automatizadas ante fallas de controles; pruebas periódicas de controles; panel para la visibilidad del estado de los controles
-
Gestión de proveedores: Evaluaciones de riesgos de terceros para todos los proveedores de servicios (proveedores de LLM, plataformas de observabilidad, proveedores de alojamiento); BAA donde corresponda; requisitos contractuales de seguridad
Los patrones de gobernanza del repositorio — trazabilidad por registros de decisiones, control mediante el arnés de evaluación, arquitectura con barreras de seguridad primero, instrumentación de OpenTelemetry, documentación honesta — proporcionan la base técnica. La brecha está en las capas organizacionales, procedimentales y de preparación para auditorías.
Véase también
Section titled “Véase también”- Mapeo del NIST AI RMF — mapeo del NIST AI RMF
- Plan de registro de auditoría — plan de registro de auditoría
- Preparación para HIPAA — preparación para HIPAA
- Modelo de amenazas OWASP / ATLAS — modelo de amenazas
- Decisión de observabilidad — diseño de observabilidad