Veritas DigitalSeguridad · Reputación · IA
Centro de confianza

ISO/IEC 42001 — sistema de gestión de IA

La única certificación de tercero que tenemos, y qué implica de verdad en el día a día.

ISO/IEC 42001 — Sistema de gestión de IA (AIMS)

Estado publicado: Certificado — referencia en verificación. Ver el centro de confianza para la lectura exacta de esa etiqueta.

ISO/IEC 42001:2023, Information technology — Artificial intelligence — Management system, es la primera norma internacional de sistema de gestión para inteligencia artificial. No certifica un modelo ni un algoritmo: certifica que la organización gobierna su IA con un ciclo Planificar-Hacer-Verificar-Actuar, igual que ISO 9001 hace con la calidad o ISO/IEC 27001 con la seguridad de la información.

Esa distinción importa. Nadie está «certificado en IA». Lo que se audita es si existen políticas, roles, evaluación de impacto, control del ciclo de vida, gobierno de datos, transparencia hacia terceros y mejora continua — y si eso opera de verdad.


1. Alcance del AIMS

El sistema de gestión de IA de Veritas Digital cubre:

ElementoContenido
Sistemas en alcanceLos 11 agentes de automatización en producción de Veritas UGC y el conector de agentes de IA que permite a sistemas externos interactuar con la plataforma.
Rol de la organizaciónVeritas Digital actúa como desarrollador y proveedor de los sistemas de IA en alcance, y como usuario de modelos de terceros integrados en ellos.
Fuera de alcanceModelos fundacionales de terceros en su desarrollo (no los entrenamos). Sí está en alcance nuestro uso de ellos, su selección, su configuración y sus límites.
Función de los agentesAutomatización operativa y preparación de contenido. Ningún agente emite un certificado probatorio.

El límite del alcance está definido por una frase que es al mismo tiempo control técnico y decisión de gobierno: un agente solo crea borradores; nada se sella sin aprobación humana.


2. La evidencia real, antes del mapeo

Un AIMS que solo existe en documentos no sobrevive a una auditoría. Estos son los mecanismos implantados sobre los que se apoya todo lo que sigue.

Humano en el bucle, impuesto por arquitectura. El conector de agentes no expone la operación de sellado. Un agente puede preparar el material, describirlo y dejarlo en estado de borrador; el paso irreversible —el que genera huella SHA-256, el anclaje temporal y el certificado firmado— requiere una acción humana identificada. No es una política que alguien pueda saltarse por prisa: es que la ruta no existe.

Auditoría inmutable de cada acción. Toda acción sobre un objeto en la plataforma queda registrada de forma inmutable, incluida la autoría —humana o agente— y el instante. Esto convierte «el agente hizo X» en un hecho reconstruible, no en una suposición. Es la materia prima de cualquier investigación posterior y de la evaluación de impacto.

RBAC de tres roles. El acceso está segmentado en tres roles diferenciados con permisos distintos. Un agente opera siempre con el rol de menor privilegio compatible con su tarea; la capacidad de aprobar y sellar no es un permiso que un agente pueda tener.

Determinismo verificable en la salida. Lo que el sistema produce no depende de la confianza en el sistema: SHA-256 del original, anclaje en Bitcoin mediante OpenTimestamps con altura de bloque real, certificado PDF firmado RSA-SHA256 y verificación pública sin cuenta. Con el fichero .ots y una copia del original, un tercero prueba la fecha con software libre aunque Veritas desaparezca. Un AIMS cuyo resultado es auditable sin el proveedor es una posición defendible; uno que exige creer en el proveedor, no.

Fail-closed en el tratamiento de entradas. El análisis antivirus se ejecuta en cuarentena; si no se completa, el archivo se rechaza. Y el tipo de fichero se determina por magic bytes, no por la extensión declarada. Ante la duda, el sistema no procesa.


3. Mapeo a las cláusulas 4–10 de ISO/IEC 42001

Las cláusulas 4 a 10 son los requisitos auditables del sistema de gestión. Son de obligado cumplimiento; el Anexo A es un catálogo de referencia del que se seleccionan controles.

Cláusula 4 — Contexto de la organización

Determinamos las cuestiones internas y externas relevantes, las partes interesadas y sus requisitos, y fijamos el alcance del AIMS.

  • Partes interesadas identificadas: clientes que usan certificación probatoria, terceros que verifican un certificado sin ser clientes, autoridades ante las que un certificado puede presentarse, proveedores de modelos y de infraestructura.
  • Cuestión externa determinante: el resultado del sistema puede acabar en un procedimiento. Eso eleva el listón de trazabilidad muy por encima de una automatización de marketing.
  • El alcance está documentado en la sección 1 de este documento.

Cláusula 5 — Liderazgo

La dirección asume la responsabilidad del AIMS, aprueba la política de IA y asigna roles.

  • Política de IA aprobada por la dirección, coherente con la política de seguridad de la información.
  • Responsabilidad final del AIMS: dirección de Veritas Digital LLC. Responsabilidad operativa: Responsable de Cumplimiento.
  • Principio rector aprobado: ninguna decisión con efecto jurídico o probatorio se automatiza sin intervención humana.

Cláusula 6 — Planificación

Riesgos y oportunidades, objetivos de IA y planificación de cambios.

Riesgos de IA identificados y tratados en el diseño:

RiesgoTratamiento implantado
Un agente sella contenido que un humano no ha revisadoImposibilidad arquitectónica: el agente no dispone de la operación de sellado
Atribución errónea de una acción entre humano y agenteRegistro de auditoría inmutable con autoría e instante por acción
Escalada de privilegios de un agenteRBAC de tres roles; principio de mínimo privilegio; aprobación fuera del alcance de cualquier rol de agente
Entrada maliciosa procesada por el sistemaCuarentena y análisis fail-closed; detección de tipo por magic bytes
Dependencia del proveedor para probar un hechoAnclaje OpenTimestamps verificable con software libre e independiente de Veritas
Deriva o cambio silencioso del modelo de un terceroRegistro de versión de modelo por acción; revisión de cambios de proveedor

Cláusula 7 — Soporte

Recursos, competencia, concienciación, comunicación e información documentada.

  • Recursos de cómputo, datos y herramientas inventariados (ver A.4).
  • Competencia: quien aprueba un sellado debe conocer qué afirma y qué no afirma un certificado. La distinción entre «probar existencia e integridad» y «registrar propiedad intelectual» es materia de formación obligatoria, no un matiz de marketing.
  • Información documentada: este documento, la política de IA, los registros de auditoría y las evaluaciones de impacto.

Cláusula 8 — Operación

Planificación y control operacional, evaluación de impacto de los sistemas de IA y gestión de cambios.

  • Ningún agente entra en producción sin definición escrita de tarea, rol RBAC asignado y punto de aprobación humana identificado.
  • Cambios en el comportamiento de un agente: gestionados como cambio con revisión previa.
  • Incidentes que involucren a un agente: tratados por el procedimiento de respuesta a incidentes, con el registro inmutable como fuente de reconstrucción.

Cláusula 9 — Evaluación del desempeño

Seguimiento, medición, auditoría interna y revisión por la dirección.

  • Indicadores operativos: proporción de borradores generados por agente que son rechazados en la revisión humana, y tiempo entre borrador y decisión humana. Un índice de rechazo que cae a cero es señal de alarma, no de éxito: sugiere aprobación automática de hecho.
  • Auditoría interna del AIMS con periodicidad definida y revisión por la dirección.

Cláusula 10 — Mejora

No conformidades, acción correctiva y mejora continua.

  • Toda no conformidad se registra con causa raíz y acción correctiva verificada.
  • Los hallazgos externos recibidos por el canal de divulgación responsable entran en el mismo circuito cuando afectan a un sistema en alcance.

4. Mapeo al Anexo A de ISO/IEC 42001

El Anexo A agrupa los controles de referencia en objetivos A.2 a A.10. Se seleccionan mediante Declaración de Aplicabilidad, proporcionalmente al riesgo identificado.

ObjetivoControlAplicación en Veritas DigitalEstado
A.2 Políticas relativas a la IAA.2.2 Política de IAPolítica de IA aprobada por la direcciónImplementado
A.2.3 Alineación con otras políticasAlineada con la política de seguridad y con el marco de privacidadImplementado
A.2.4 Revisión de la política de IARevisión anual y ante cambio material de alcanceImplementado
A.3 Organización internaA.3.2 Roles y responsabilidades de IADirección, Responsable de Cumplimiento, Responsable de Ingeniería; RBAC de tres roles en plataformaImplementado
A.3.3 Comunicación de inquietudesCanal interno de escalado y canal externo de divulgación responsableImplementado
A.4 Recursos para sistemas de IAA.4.2 Documentación de recursosInventario de agentes, modelos, herramientas y dependenciasImplementado
A.4.3 Recursos de datosLos datos de entrada son ficheros del cliente; no se usan para entrenamientoImplementado
A.4.4 Recursos de herramientasCadena de herramientas documentada (orquestación, modelos, análisis de ficheros)Implementado
A.4.5 Recursos de sistema y cómputoInfraestructura propia endurecida, con capacidad y aislamiento documentadosImplementado
A.4.6 Recursos humanosAprobadores humanos identificados y formados por rolImplementado
A.5 Evaluación de impactosA.5.2 Proceso de evaluación de impactoEvaluación previa obligatoria antes de poner un agente en producciónImplementado
A.5.3 Documentación de las evaluacionesEvaluación archivada por agente y revisada ante cambioImplementado
A.5.4 Impacto sobre individuos o gruposAnalizado el efecto de un certificado erróneo sobre un tercero; mitigado con aprobación humana y verificación pública abiertaImplementado
A.5.5 Impactos socialesAnalizado el uso indebido para dar apariencia de autoridad a contenido falso; mitigado limitando explícitamente lo que el certificado afirmaImplementado
A.6 Ciclo de vida del sistema de IAA.6.1.2 Objetivos de desarrollo responsableObjetivo declarado: asistencia, nunca decisión autónoma con efecto probatorioImplementado
A.6.1.3 Procesos de diseño y desarrollo responsablePunto de aprobación humana como requisito de diseño, no como configuraciónImplementado
A.6.2.2 Requisitos y especificaciónCada agente tiene tarea, entradas, salidas y límites escritosImplementado
A.6.2.3 Documentación de diseño y desarrolloDocumentación por agente bajo control de versionesImplementado
A.6.2.4 Verificación y validaciónValidación previa al despliegue y revisión humana de salidas en operaciónImplementado
A.6.2.5 DespliegueDespliegue controlado con rol RBAC asignadoImplementado
A.6.2.6 Operación y seguimientoSeguimiento de rechazos en revisión humana y de erroresImplementado
A.6.2.7 Documentación técnicaMantenida para los sistemas en alcanceImplementado
A.6.2.8 Registro de eventosAuditoría inmutable de cada acción, con autoría e instanteImplementado
A.7 Datos para sistemas de IAA.7.2 Datos para desarrollo y mejoraLos datos de clientes no se emplean para entrenar ni mejorar modelosImplementado
A.7.3 Adquisición de datosDatos aportados por el cliente bajo encargo del tratamientoImplementado
A.7.4 Calidad de los datosTipo determinado por magic bytes; rechazo fail-closed si el análisis no concluyeImplementado
A.7.5 Procedencia de los datosHuella SHA-256 y sello temporal anclado como registro de procedenciaImplementado
A.7.6 Preparación de los datosPreparación acotada y registrada; sin transformación silenciosa del originalImplementado
A.8 Información para partes interesadasA.8.2 Documentación e información para usuariosEl certificado declara qué prueba y qué no prueba; FAQ pública extensa en 7 idiomasImplementado
A.8.3 Reporte externoVerificación pública sin cuenta ni entrega de datosImplementado
A.8.4 Comunicación de incidentesProcedimiento de notificación a afectados y a autoridad cuando procedaImplementado
A.8.5 Información para partes interesadasEste documento y el centro de confianzaImplementado
A.9 Uso de sistemas de IAA.9.2 Procesos para el uso responsableUso restringido a preparación de borradoresImplementado
A.9.3 Objetivos de uso responsableReducir trabajo manual sin trasladar la decisión a la máquinaImplementado
A.9.4 Uso previstoUso previsto y usos excluidos declarados por agenteImplementado
A.10 Terceros y clientesA.10.2 Asignación de responsabilidadesReparto documentado entre Veritas, proveedores de modelo y clienteImplementado
A.10.3 ProveedoresVer registro de subencargadosImplementado
A.10.4 ClientesCondiciones de uso y DPA; canal de reclamaciónImplementado

Regla de asignación de estado: solo se marca Implementado cuando existe evidencia documental o técnica verificable. Ante duda, se marca Parcial o Pendiente. El sesgo de este registro es siempre hacia declarar de menos.


5. Lo que este AIMS no afirma

  • No afirma que los modelos no se equivoquen. Afirma que un error de modelo no puede convertirse por sí solo en un certificado emitido.
  • No afirma seguridad absoluta. Ningún sistema la tiene.
  • No cubre los modelos de terceros en su desarrollo. Cubre nuestra selección, configuración, límites y supervisión de ellos.
  • No sustituye a una evaluación de conformidad bajo el Reglamento de IA de la UE cuando esta resulte exigible por la clasificación de un caso de uso concreto. Son marcos distintos con obligaciones distintas.

Fuentes