Soporte: Recursos, Competencia, Comunicación e Información Documentada (Cláusula 7)
Soporte: Recursos, Competencia, Comunicación e Información Documentada (Cláusula 7)
Un plan solo vale lo que valen los medios para ejecutarlo. La cláusula 7 de ISO/IEC 42001 se ocupa precisamente de esos medios: los habilitadores que hacen posible que el SGIA funcione en la práctica. Si la cláusula 6 definió qué hacer, la cláusula 7 asegura que la organización tenga con qué y con quiénes hacerlo, y que la información que sostiene todo el sistema esté disponible, actualizada y protegida.
La cláusula se articula en cinco bloques que actúan como pilares del soporte:
mindmap
root((Cláusula 7<br/>Soporte))
7.1 Recursos
Personas
Infraestructura
Datos
Presupuesto
7.2 Competencia
Educación
Formación
Experiencia
7.3 Toma de conciencia
Política de IA
Contribución
Implicaciones
7.4 Comunicación
Qué / Cuándo
Con quién / Cómo
7.5 Información documentada
Generalidades
Creación y actualización
Control7.1 Recursos
La subcláusula 7.1 establece que la organización debe determinar y proporcionar los recursos necesarios para establecer, implementar, mantener y mejorar continuamente el SGIA. El verbo clave es doble: no basta con determinar qué se necesita, hay que proporcionarlo efectivamente.
En el contexto de ISO/IEC 42001, los recursos van mucho más allá del presupuesto. Incluyen todo lo que un sistema de IA requiere para gestionarse de forma responsable:
| Tipo de recurso | Ejemplo en un SGIA |
|---|---|
| Personas | Científicos de datos, especialistas en ética de IA, auditores |
| Infraestructura | GPUs, entornos de entrenamiento, plataformas MLOps |
| Herramientas | Frameworks de evaluación de sesgos, monitoreo de modelos |
| Datos | Conjuntos de entrenamiento, validación y prueba de calidad |
| Sistemas | Repositorios de modelos, registros de versiones |
| Presupuesto | Costos de cómputo, licencias, API de terceros |
| Tiempo | Ventanas para revisión, pruebas y supervisión humana |
| Soporte externo | Consultores, proveedores de modelos, auditores externos |
Ejemplo concreto. Una aseguradora que despliega un modelo de detección de fraude descubre en su auditoría interna que carece de un entorno de pruebas separado del de producción. Sin ese recurso de infraestructura, cada actualización del modelo se probaba directamente sobre datos reales de clientes. Determinar y proporcionar ese entorno de staging es un cumplimiento directo de 7.1.
Nota. Los objetivos de control y controles relacionados con recursos para sistemas de IA se encuentran en A.4 del Anexo A, y la guía de implementación correspondiente se desarrolla en B.4.
7.2 Competencia
La subcláusula 7.2 establece que la organización debe determinar la competencia necesaria de las personas que realizan trabajos bajo su control y que afectan el desempeño de IA. La competencia no se presume: se determina, se asegura y se evidencia.
La organización debe asegurar que estas personas sean competentes con base en educación, formación o experiencia apropiada. Cuando sea aplicable, debe tomar acciones para adquirir la competencia necesaria y evaluar la eficacia de esas acciones. Además, debe conservar información documentada apropiada como evidencia de competencia.
flowchart LR
D[Determinar<br/>competencia necesaria] --> A{¿Las personas<br/>son competentes?}
A -->|Sí| E[Conservar evidencia<br/>de competencia]
A -->|No| AC[Tomar acciones:<br/>formación, tutoría,<br/>contratación...]
AC --> EV[Evaluar eficacia<br/>de las acciones]
EV --> E
style D fill:#dbeafe,stroke:#2563eb
style E fill:#dcfce7,stroke:#16a34a
style AC fill:#fef9c3,stroke:#ca8a04En un SGIA, la competencia se relaciona con áreas muy específicas de la IA:
- Gestión de riesgos de IA.
- Evaluación de impacto del sistema de IA.
- Operación de controles.
- Supervisión humana.
- Gestión de datos.
- Relación con proveedores.
- Comunicación.
- Uso responsable de sistemas de IA.
Nota 1. La guía de implementación sobre recursos humanos y experiencia necesaria se encuentra en B.4.6.
Nota 2. Las acciones para adquirir competencia pueden incluir formación, tutoría, reasignación de personas dentro de la organización, contratación o vinculación de personas competentes.
Ejemplo concreto. Un hospital que introduce un sistema de IA de apoyo al diagnóstico no exige que sus radiólogos se conviertan en científicos de datos. En cambio, determina que necesitan competencia en supervisión humana: saber cuándo el sistema puede equivocarse y cómo anular su recomendación. Diseña una formación específica, evalúa su eficacia con casos prácticos y conserva los certificados como evidencia.
7.3 Toma de conciencia
La subcláusula 7.3 establece que las personas que realizan trabajos bajo el control de la organización deben tomar conciencia de tres cosas:
- La política de IA.
- Su contribución a la eficacia del SGIA.
- Las implicaciones de no cumplir los requisitos del sistema.
La distinción con la competencia (7.2) es sutil pero importante. La competencia es la capacidad de hacer bien un trabajo; la toma de conciencia es la comprensión de por qué ese trabajo importa dentro del sistema. No todas las personas necesitan el mismo nivel de conocimiento, pero sí deben comprender aquello que es pertinente para su rol.
flowchart TD
P[Persona bajo control<br/>de la organización] --> C1[Conoce la<br/>política de IA]
P --> C2[Entiende su<br/>contribución al SGIA]
P --> C3[Comprende las<br/>implicaciones de<br/>no cumplir]
C1 & C2 & C3 --> R[Actúa de forma<br/>responsable en su rol]
style R fill:#dcfce7,stroke:#16a34aEn el contexto de IA, la toma de conciencia puede incluir conocer límites de uso, responsabilidades, canales de reporte, requisitos de supervisión humana, criterios de comunicación o prácticas internas para el uso responsable de sistemas de IA.
Ejemplo concreto. Un agente de atención al cliente que usa un asistente de IA generativa no necesita entender la arquitectura del modelo. Sí necesita tomar conciencia de que no debe pegar datos personales de clientes en el prompt, de que existe un canal para reportar respuestas incorrectas y de que él es el responsable último de lo que se comunica al cliente. Esa conciencia previene incidentes que ningún control técnico atraparía por sí solo.
7.4 Comunicación
La subcláusula 7.4 establece que la organización debe determinar las comunicaciones internas y externas pertinentes al SGIA. La comunicación deja de ser algo espontáneo y se convierte en un proceso planificado.
Para cada comunicación, la organización debe definir cuatro elementos:
flowchart LR
COM[Comunicación<br/>del SGIA] --> QUE[¿Qué<br/>comunicará?]
COM --> CUANDO[¿Cuándo lo<br/>comunicará?]
COM --> QUIEN[¿Con quién se<br/>comunicará?]
COM --> COMO[¿Cómo realizará<br/>la comunicación?]
style COM fill:#dbeafe,stroke:#2563ebLa comunicación puede referirse a la política de IA, responsabilidades, cambios relevantes, requisitos aplicables, resultados del SGIA, controles, incidentes, relación con partes interesadas o información necesaria para el uso responsable de sistemas de IA.
El propósito es asegurar que la información relevante del SGIA llegue a las personas o partes interesadas correspondientes de manera oportuna y coherente.
Ejemplo concreto. Ante un incidente en el que un modelo de recomendación mostró contenido inapropiado, la organización activa su plan de comunicación: qué (naturaleza del incidente y medidas), cuándo (dentro de las 24 horas), con quién (usuarios afectados y regulador), cómo (notificación en la aplicación y reporte formal). Sin esta planificación previa, la respuesta sería caótica y probablemente incompleta.
7.5 Información documentada
La información documentada es la memoria del SGIA. Es lo que permite demostrar conformidad, sostener la trazabilidad y aprender de la experiencia. La subcláusula 7.5 se divide en tres partes.
flowchart LR
G[7.5.1<br/>Generalidades<br/>¿Qué documentar?] --> CA[7.5.2<br/>Creación y<br/>actualización<br/>¿Cómo se hace?]
CA --> CO[7.5.3<br/>Control<br/>¿Cómo se protege<br/>y gestiona?]
style G fill:#dbeafe,stroke:#2563eb
style CA fill:#fef9c3,stroke:#ca8a04
style CO fill:#dcfce7,stroke:#16a34a7.5.1 Generalidades
El SGIA debe incluir tanto la información documentada requerida explícitamente por ISO/IEC 42001 como la que la organización determine necesaria para la eficacia del sistema. Es decir, la norma marca un mínimo, pero la organización debe pensar por sí misma qué más necesita para planificar, operar, controlar, evaluar y mejorar el SGIA.
La extensión de la documentación varía entre organizaciones y depende de factores como:
- El tamaño de la organización.
- La complejidad de sus procesos.
- Los sistemas de IA incluidos en el alcance.
- Los riesgos asociados.
- La competencia del personal.
- La interacción con proveedores o terceros.
Nota. Un SGIA más complejo o con sistemas de IA de mayor impacto normalmente requerirá mayor nivel de documentación y trazabilidad.
7.5.2 Creación y actualización
Al crear y actualizar información documentada, la organización debe asegurar su identificación, descripción, formato, medio, revisión y aprobación.
| Aspecto | Qué garantiza |
|---|---|
| Identificación y descripción | Reconocer claramente cada documento o registro |
| Formato y medio | Adecuación del soporte (digital, base de datos, reporte) |
| Revisión y aprobación | Que el documento sea adecuado antes de su uso |
La revisión y aprobación son especialmente importantes: evitan que se utilicen versiones no aprobadas, desactualizadas o inconsistentes dentro del SGIA. En un sistema de IA, usar una versión antigua de una evaluación de riesgos puede llevar a decisiones basadas en supuestos que ya no son válidos.
En el contexto de IA, esta subcláusula se aplica a documentos como la política de IA, evaluaciones de riesgos, evaluaciones de impacto, la Declaración de Aplicabilidad, planes de tratamiento, registros de monitoreo, criterios de control, evidencias de competencia o resultados de revisión.
7.5.3 Control de la información documentada
La información documentada requerida por el SGIA debe controlarse para asegurar que esté disponible y sea adecuada para su uso, cuando y donde sea necesaria. Además, debe protegerse contra pérdida de confidencialidad, uso indebido, pérdida de integridad o deterioro.
El control puede incluir un conjunto de actividades a lo largo del ciclo de vida del documento:
flowchart TD
subgraph Ciclo de control documental
A[Distribución] --> B[Acceso]
B --> C[Recuperación y uso]
C --> D[Almacenamiento y<br/>preservación]
D --> E[Control de cambios]
E --> F[Conservación]
F --> G[Disposición]
end
style A fill:#dbeafe,stroke:#2563eb
style G fill:#fce7f3,stroke:#db2777Un punto que a menudo se pasa por alto: cuando exista información documentada de origen externo necesaria para la planificación y operación del SGIA, la organización debe identificarla y controlarla según corresponda. En un SGIA, esto incluye documentación de proveedores, contratos, reportes técnicos, requisitos legales, evaluaciones externas, documentación de sistemas de IA o evidencia entregada por terceros.
Ejemplo concreto. Una empresa que consume un modelo fundacional a través de una API recibe del proveedor una “tarjeta del modelo” (model card) con sus limitaciones y sesgos conocidos. Ese documento externo es crítico para su gestión de riesgos, por lo que debe identificarlo, controlar su versión y almacenarlo en el repositorio del SGIA, no dejarlo perdido en la bandeja de correo de un ingeniero.
Ejemplos de evidencia:
- Repositorio controlado de documentos del SGIA.
- Control de versiones.
- Registros de aprobación.
- Permisos de acceso.
- Registros de conservación o disposición.
Síntesis del capítulo
La cláusula 7 es el andamiaje sobre el que se sostiene todo lo demás. Sin recursos (7.1) no hay ejecución; sin competencia (7.2) no hay calidad; sin toma de conciencia (7.3) no hay cultura de responsabilidad; sin comunicación (7.4) no hay coordinación; y sin información documentada controlada (7.5) no hay memoria, trazabilidad ni evidencia de conformidad.
Para el auditor interno, esta cláusula ofrece evidencias muy tangibles: presupuestos y asignaciones de infraestructura, matrices de competencias con certificados, registros de campañas de concienciación, planes de comunicación, y —sobre todo— un repositorio documental controlado con versiones, aprobaciones y permisos. La solidez de estos habilitadores suele predecir la salud general del SGIA.
Capítulo 9 de la serie ISO/IEC 42001 Auditor Interno — Continúa en el Capítulo 10: Operación: Planificación Operacional, Riesgos e Impacto (Cláusula 8)