NIST AI Risk Management Framework 1.0 — correspondencia de alineación
Esta página se genera a partir de la tabla de requisitos que el motor de AiSSAY incluye para este marco. Cuando el motor produce un paquete de evidencias, cada fila de abajo recibe un estado calculado a partir de los propios registros del operador en ese momento. Esta página muestra la tabla, no los resultados de nadie.
Correspondencia informativa preparada con las propias herramientas del operador. No es un dictamen jurídico, ni una certificación, ni sustituye el asesoramiento de un abogado. Organiza los registros del operador en relación con los requisitos citados; determinar si esos registros cumplen los requisitos corresponde al operador, a su asesor jurídico y al examinador.
El NIST AI RMF es un marco voluntario. No existe ninguna certificación del NIST y no se puede afirmar tenerla; la declaración pública correcta es que el operador SE ALINEA con el marco, mediante autoevaluación, y que esta correspondencia puede regenerarse a partir del almacén de evidencias en cualquier momento.
La tabla de requisitos
11 filas: 7 de mecanismo, 3 organizativas, 1 carencia señalada
| Requisito | Mecanismo, obligación o carencia | Tipo |
|---|---|---|
| GOVERN 1.1–1.4 — políticas, estructuras de rendición de cuentas y tolerancia al riesgo documentadas a lo largo del ciclo de vida de la IA | organizativo: una política escrita de gobernanza de la IA que designe los registros de AiSSAY como mecanismo de evidencia | organizativo |
| GOVERN 2.1 — se definen los roles y las responsabilidades respecto del riesgo de la IA | PARCIAL, y no gracias al software. Los registros nombran a un revisor cuando alguien refrendó, y la barrera nombra quién puede liberar una acción retenida; pero el sistema no tiene roles, ni permisos, ni noción de quién está autorizado a hacer qué. Definir la rendición de cuentas es un acto organizativo; el almacén solo puede registrarla a posteriori. | organizativo |
| GOVERN 4.3 — los incidentes y errores se comparten y se documentan | registros sellados de los fallos, registros de carencias de captura y el mecanismo de bifurcación reconocida: los incidentes se convierten en entradas de la cadena, nunca en correos electrónicos | mecanismo |
| MAP 1.1/2.3 — se documentan el contexto, la finalidad y los supuestos del uso de la IA | cada registro lleva el mandato de la tarea, los supuestos declarados por el agente, las ambigüedades y las condiciones de validez | mecanismo |
| MEASURE 2.5 — se supervisa el desempeño del sistema de IA con métricas | hallazgos de conciliación, cobertura del entregable y análisis de deriva por tipo de tarea, calculados por ejecución | mecanismo |
| MEASURE 2.7(a) — evaluación adversarial del sistema de IA | honeypots, pruebas con registros falsificados, análisis de inyecciones y adjudicación entre modelos en cada ejecución medida | mecanismo |
| MEASURE 2.7(b) — seguridad y resiliencia del sistema desplegado | IMPLEMENTADO EN PARTE, y las partes están identificadas. Aquí las pruebas adversariales evalúan el relato que la IA hace de su trabajo, no la seguridad del software que lo transporta. En cuanto al software: las dependencias se analizan en el momento de la publicación con una comprobación de antigüedad, un verificador estático limitado se ejecuta sobre este árbol, y se aplica fuzzing a los analizadores que leen entradas externas; cada uno de estos controles se prueba contra un defecto introducido a propósito en lugar de darse por bueno. Sigue sin haber pruebas de penetración ni revisión de la criptografía por terceros. | carencia señalada |
| MEASURE 2.8 — se mantienen registros de transparencia y rendición de cuentas | cadena de hashes de solo anexión, registro de accesos completo, anclaje externo | mecanismo |
| MEASURE 3.1–3.3 — se hace seguimiento de los riesgos a lo largo del tiempo; se evalúa la propia medición | el perfil del instrumento: un registro firmado y versionado de lo que aprendió el verificador, sellado en cada registro que evaluó | mecanismo |
| MANAGE 2.3/2.4 — mecanismos para responder a incidentes y recuperarse de ellos | PARCIAL. La restauración del registro, el diagnóstico de bifurcaciones, el sellado de carencias de captura y la retención legal son MECANISMOS de recuperación y funcionan; a quién se avisa, en qué plazo y quién decide activarlos es un procedimiento de respuesta a incidentes que ningún software aporta. | organizativo |
| MANAGE 4.1 — seguimiento posterior al despliegue con supervisión humana | marcado de pendiente de revisión, refrendos de los revisores que alimentan la calibración e informes iniciales previos a cada ejecución a partir de correcciones verificadas | mecanismo |
Cómo se obtiene un estado
- Acreditado
- se ejecutó una comprobación determinista sobre sus registros y los recuentos respaldan la fila. Un almacén que no contiene registros pertinentes figura como no acreditado: una afirmación verdadera, no un aprobado. Vacío nunca cuenta como limpio.
- Delegado
- el mecanismo lo hace cumplir un sistema en el que usted ya confía: un almacén sellado por su propio gestor de claves le delega a este el control de acceso, y el paquete indica que el registro que lo hace cumplir es el de su gestor de claves, no el nuestro. El paquete nombra el endpoint en el que se contactó con el gestor de claves. Un endpoint de AWS distinto del predeterminado de AWS para la región figura como delegado a ese endpoint, con una solicitud para que usted confirme que es su servicio de gestión de claves. Un backend —AWS KMS— se ha ejecutado contra el servicio real de AWS KMS; ningún otro backend lo ha hecho.
- Punto de integración de prueba
- sellado por un backend de prueba dentro del proceso —un stub, o un sustituto del cliente de AWS— y el estado indica cuál. Ningún gestor de claves controla el acceso. El punto de integración está construido y probado, y el paquete se niega a llamar a eso delegación.
- Parcialmente acreditado
- el mecanismo está construido y algunas de sus ejecuciones llevan su evidencia, pero no todas, normalmente porque se sellaron antes de que existiera el mecanismo. El paquete indica cuántas ejecuciones hay en cada grupo y nunca cuenta como aprobadas las que faltan.
- Organizativo
- el requisito es un procedimiento que solo pueden llevar a cabo personas. El paquete lo señala como responsabilidad suya en lugar de disfrazar una política de mecanismo.
- Carencia señalada
- el paquete no puede acreditarlo —o bien el mecanismo no está construido, o bien ningún software puede aportarlo— y dice cuál de los dos casos es. La carencia se imprime, porque un revisor debería leerla aquí y no descubrirla después.
Ningún estado se introduce a mano: cada estado se recalcula a partir del almacén cada vez que se produce un paquete, el texto de los requisitos y de los mecanismos se redacta y revisa como parte del motor, y la evidencia sobre dependencias procede de nuestro análisis de cada versión. Un mecanismo que falla nunca puede interpretarse como evidencia de que el control funciona.