Lectura Auditora de la Norma: Requisito, Evidencia y Hallazgo
Lectura Auditora de la Norma: Requisito, Evidencia y Hallazgo
Auditar ISO/IEC 42001 no consiste en recitar el texto de la norma ni en marcar casillas verificando que existen documentos. Un auditor que se limita a comprobar la presencia de una política de IA, sin preguntarse si esa política orienta decisiones reales, no está auditando: está inventariando papeles. La auditoría verdadera exige una lectura auditora de la norma, es decir, la capacidad de leer cada cláusula como una fuente de la que se extraen criterios contra los cuales medir la realidad de un Sistema de Gestión de Inteligencia Artificial (SGIA).
Esa lectura persigue tres cosas simultáneamente: interpretar el requisito, obtener evidencia objetiva y emitir un juicio sobre si el SGIA demuestra conformidad, implementación y eficacia. Estos tres verbos no son sinónimos, y buena parte de la calidad de una auditoría depende de no confundirlos. Este capítulo desarrolla cómo se realiza esa lectura y cómo se distinguen tres conceptos que sostienen todo el proceso auditor: requisito, evidencia y hallazgo.
De cláusula a criterio de auditoría
Una cláusula de la norma es un texto normativo. Por sí sola no le dice al auditor qué debe observar; primero hay que traducirla. Una cláusula se convierte en criterio de auditoría cuando el auditor la utiliza como referencia concreta para comparar lo que la organización ha definido, implementado y documentado frente a lo que la norma exige.
Ese proceso de traducción puede estructurarse con cuatro preguntas encadenadas. Cada una responde a un elemento distinto del razonamiento auditor:
| Elemento | Pregunta guía |
|---|---|
| Cláusula | ¿Qué aspecto del SGIA regula este texto de la norma? |
| Criterio | ¿Qué condición concreta debe cumplirse para satisfacerlo? |
| Evidencia | ¿Qué información demuestra que esa condición se cumple? |
| Juicio auditor | ¿La evidencia es suficiente para concluir conformidad? |
El flujo mental del auditor recorre estas preguntas en orden, y cada respuesta condiciona la siguiente:
flowchart LR
A[Cláusula<br/>texto normativo] --> B[Criterio<br/>condición verificable]
B --> C[Evidencia<br/>información objetiva]
C --> D[Juicio auditor<br/>conformidad o no]
D -.retroalimenta.-> B
Consideremos un ejemplo concreto. La norma contiene un requisito sobre competencia de las personas que intervienen en el SGIA. Un auditor superficial preguntaría simplemente: «¿tienen capacitación?». Pero la cláusula de competencia, leída correctamente, genera un criterio mucho más exigente. El auditor debe verificar tres cosas: que la organización identificó las competencias necesarias para operar sus sistemas de IA (por ejemplo, evaluar sesgo en un modelo de scoring crediticio, o supervisar las salidas de un chatbot de atención al cliente); que las personas asignadas a esos roles son competentes para ejercerlos; y que existe información documentada que lo demuestre.
Convertir la cláusula en criterio, entonces, significa hacerla verificable. «Debe haber competencia» no es auditable; «la organización identificó que el equipo de datos requiere formación en detección de sesgo, designó a personas con esa formación acreditada y conserva los certificados» sí lo es. El criterio es la cláusula expresada en términos de una condición observable.
Diferenciar requisito, evidencia y hallazgo
Toda auditoría sólida descansa sobre la distinción nítida de tres conceptos. Confundirlos es la fuente más común de auditorías débiles o de hallazgos que no se sostienen ante una revisión.
| Concepto | Significado |
|---|---|
| Requisito | Lo que debe cumplirse según la norma, la propia organización o una obligación aplicable (legal, contractual o regulatoria). |
| Evidencia | Información verificable que demuestra qué ocurre realmente en la práctica. |
| Hallazgo | Resultado de comparar la evidencia contra el criterio de auditoría. |
El requisito es el «deber ser». Puede provenir de la norma ISO/IEC 42001, pero también de compromisos que la propia organización asumió en su política de IA, o de obligaciones externas como una regulación de protección de datos o un contrato con un cliente. Un buen auditor no reduce los requisitos a la norma: incorpora también lo que la organización se comprometió a cumplir.
La evidencia es el «lo que es». Es información verificable —no una impresión ni un comentario de pasillo— que muestra cómo opera realmente el SGIA. Registros, actas, configuraciones de sistemas, logs de un modelo en producción, resultados de una evaluación de impacto: todo eso es evidencia siempre que sea trazable y comprobable.
El hallazgo es la conclusión que surge de contrastar la evidencia con el criterio. Y aquí reside un principio irrenunciable: un hallazgo nunca debe basarse en opiniones, suposiciones o preferencias personales del auditor. Debe vincularse siempre a un criterio específico y a una evidencia objetiva. Si un auditor no puede señalar «este criterio, contra esta evidencia», no tiene un hallazgo: tiene una opinión.
flowchart TD
R[Requisito<br/>lo que debe cumplirse] --> C{Comparación<br/>evidencia vs criterio}
E[Evidencia<br/>lo que ocurre en la práctica] --> C
C -->|coincide| H1[Hallazgo:<br/>conformidad]
C -->|no coincide o falta| H2[Hallazgo:<br/>no conformidad]
Ejemplo aplicado a un SGIA
Supongamos que auditamos la gestión de información documentada de un sistema de recomendación en producción:
- Requisito: la organización debe conservar información documentada sobre una actividad del SGIA —en este caso, la evaluación de riesgos del sistema de recomendación.
- Evidencia: existen registros de esa evaluación, están disponibles, se encuentran bajo control de versiones y son trazables hasta el responsable que los aprobó.
- Hallazgo: si los registros existen y son adecuados, el hallazgo es de conformidad. Si la información requerida no está disponible, no es trazable, o existe pero no demuestra que la actividad se ejecutó realmente, el hallazgo es de no conformidad.
Nótese que el hallazgo no depende de si al auditor le gusta el formato del documento o preferiría otra herramienta. Depende exclusivamente de si la evidencia satisface el criterio derivado del requisito.
No auditar solo documentos: diseño, implementación y eficacia
La documentación es necesaria, pero jamás suficiente. Un SGIA puede exhibir políticas impecables, procedimientos detallados y matrices de riesgo completas, y aun así no estar implementado ni ser eficaz. Auditar únicamente la existencia de documentos produce una falsa sensación de conformidad: el papel está, pero el sistema no protege contra nada.
Por eso el auditor competente revisa cada requisito en tres niveles, y no da por satisfecho un criterio hasta haber ascendido por los tres:
| Nivel | Qué verifica |
|---|---|
| Diseño | El proceso, control o política está definido y documentado. |
| Implementación | Se aplica realmente en la operación cotidiana. |
| Eficacia | Produce el resultado esperado y contribuye a controlar el riesgo de IA. |
flowchart LR
D[Diseño<br/>¿está definido?] --> I[Implementación<br/>¿se aplica?]
I --> Ef[Eficacia<br/>¿funciona y controla el riesgo?]
D -.-> N1[Solo papel]
I -.-> N2[Se hace, pero ¿sirve?]
Ef -.-> N3[Riesgo bajo control]
El caso de la Declaración de Aplicabilidad (SoA) ilustra bien esta escalera. Una SoA puede declarar que cierto control —por ejemplo, la supervisión humana de las decisiones automatizadas de un modelo de scoring crediticio— es aplicable. En el nivel de diseño, el auditor confirma que el control está definido. Pero no puede detenerse ahí: en el nivel de implementación debe buscar evidencia de que existe un procedimiento real de revisión humana y que se ejecuta —revisores asignados, registros de decisiones revisadas, casos escalados—. Y en el nivel de eficacia debe preguntarse si esa supervisión realmente reduce el riesgo asociado: ¿detecta decisiones erróneas o sesgadas antes de que afecten al cliente?, ¿se corrigen?, ¿mejora el sistema como consecuencia?
Un control que solo existe en la SoA, sin evidencia de ejecución ni impacto sobre el riesgo, constituye una no conformidad por más completa que sea su descripción documental. La lectura auditora de la norma consiste, en definitiva, en no confundir el mapa con el territorio: los documentos describen el SGIA que debería existir; la evidencia de implementación y eficacia demuestra el SGIA que realmente existe.
Capítulo 5 de la serie ISO/IEC 42001 Auditor Interno — Continúa en el Capítulo 6: Contexto de la Organización (Cláusula 4)