Estándares técnicos de IA
Normas aplicables por capa: datos, modelo, servicio y operación. Cada norma se traduce en un control con prueba asociada.
Procedimiento de verificación por estados: qué se registra, cómo se contrasta y con qué evidencia se cierra cada control. Sin registro no hay veredicto; sin veredicto no hay conformidad.
El mapa de cumplimiento fija la relación entre cada requisito declarado y el control técnico que lo satisface. La revisión opera sobre tres entradas: inventario de modelos, registro de decisiones y trazas de ejecución en producción. Cada entrada lleva un identificador estable; sin ese identificador la evidencia se rechaza en la matriz y el control permanece abierto.
El contraste se ejecuta contra marcos publicados: ISO/IEC 42001 como referencia de gestión, las funciones del NIST AI RMF como estructura de proceso y las directrices internas del operador. El mapeo no es una traducción literal: un control de ISO puede cubrir dos funciones del RMF y exigir dos pruebas distintas. La tabla de correspondencias se versiona junto al modelo, nunca por separado.
Los detalles por capa del sistema están en estándares técnicos de IA, y la asignación de responsabilidades entre propietario del modelo, seguridad y plataforma se documenta en gobernanza algorítmica. Sin esa asignación, el mapa de cumplimiento queda sin firma y no entra en ciclo de auditoría.
El rastro de auditoría es la secuencia verificable de estados por la que pasa cada modelo. Se compone de eventos con marca temporal, autor y payload firmado; cualquier hueco en la secuencia invalida el tramo completo. Los módulos siguientes describen las piezas del proceso.
Una decisión que no puede reconstruirse paso a paso se trata como no conforme, aunque su resultado haya sido correcto.
Cada fila fija qué se presenta, con qué frecuencia y quién responde. La frecuencia se cuenta desde la última verificación exitosa; un retraso superior a un ciclo abre incidencia automática. La matriz se revisa completa en cada versión mayor del modelo.
| Control | Evidencia requerida | Frecuencia | Responsable |
|---|---|---|---|
| Registro de modelo | Versión, hash y fecha de despliegue | Por despliegue | Operación |
| Robustez adversarial | Informe firmado con tasa de evasión | Trimestral | Seguridad |
| Registro de decisiones | Log inmutable con motivo y contexto | Continua | Producto |
| Deriva de datos | Métrica con umbral y alerta asociada | Semanal | Datos |
| Acceso a datos | Lista de permisos vigente y revisada | Mensual | Plataforma |
El ciclo opera como un bucle cerrado con cinco estados. Cada transición exige evidencia de salida; si falta, el control permanece en el estado anterior y consume presupuesto de riesgo. La duración objetivo del ciclo completo es de catorce días operativos para incidencias altas.
El cierre no lo firma quien ejecutó el parche: la verificación se asigna a un revisor distinto del equipo que introdujo el cambio. El detalle de los criterios de muestreo está descrito en la metodología de evaluación.
La alerta supera el umbral definido y genera incidencia con identificador único.
Se limita la exposición del modelo afectado: tráfico reducido o congelación de versión.
Parche aplicado con registro de diff, autor y motivo del cambio.
Repetición de la prueba que originó la alerta y de la batería completa de regresión.
Veredicto firmado por revisor independiente y actualización de la matriz de evidencia.
Una vez por ciclo anual y siempre tras un cambio mayor de modelo, de fuente de datos o de proveedor externo. Los cambios menores entran por muestreo.
El control se marca como no conforme y entra en el ciclo de remediación con plazo asignado. No existe cierre parcial por declaración del equipo.
Sí, con contrato de acceso a trazas y pruebas de caja negra. Los requisitos mínimos figuran en ciberseguridad en machine learning.
Controles verificados sobre controles declarados, en porcentaje. La desviación se reporta por capa del sistema y no se promedia entre capas.