El 7 de abril de 2026 es la fecha que NIST da para su nota conceptual sobre un perfil del Marco de Gestión de Riesgos de IA para infraestructura crítica.[1] La distinción es importante: una nota conceptual describe el trabajo hacia una guía. No es evidencia de que un producto particular haya pasado una evaluación. Para los compradores de IA privada, la respuesta práctica es hacer que el despliegue propuesto sea lo suficientemente específico para examinarlo.

Nuestra posición es que el registro piloto más sólido sigue una tarea real a través de su límite operativo. El documento debe nombrar lo que el sistema puede hacer, lo que no puede hacer y quién toma el control cuando no se puede confiar en la salida. Una etiqueta como “on-premises” no puede proporcionar esas respuestas por sí sola.

Separe la fuente de la interpretación

NIST describe el AI RMF como voluntario e identifica la publicación original del marco en enero de 2023. Su visión general actual también describe el trabajo de revisión y la iniciativa del perfil para infraestructura crítica.[1] Esos son hechos útiles para preservar con sus fechas. No deben reescribirse como una nueva obligación legal o una garantía de que una lista de verificación existente esté completa.

Un informe interno puede mantener esta distinción visible con dos párrafos cortos. El primero informa lo que la fuente realmente dice y enlaza a ella. El segundo indica lo que la organización propone hacer en respuesta. Eso hace que las actualizaciones posteriores sean manejables: una fuente cambiada no requiere adivinar qué partes del informe eran hechos y cuáles decisiones locales.

Este artículo propone una forma de reunir evidencia técnica. No determina qué obligaciones sectoriales específicas aplican a una organización ni si un despliegue las satisface.

Dibuje el límite operativo real

Un asistente de documentación de mantenimiento y un sistema que cambia configuraciones de equipo son propuestas diferentes. Describa la primera tarea permitida en términos ordinarios antes de discutir modelos. Indique la entrada, la persona que usa el resultado y la acción que esa persona está autorizada a tomar. Incluya la consecuencia de una respuesta incorrecta en la misma descripción.

Luego trace la ruta de los datos. Un despliegue de AI Server propuesto pertenece en un diagrama con sus clientes, sistemas de identidad y almacenamiento. Las descargas de modelos, diagnósticos y rutas opcionales del proveedor merecen sus propias entradas. La cuestión es dónde se ejecuta cada actividad y quién la opera, no si todo puede caber bajo una etiqueta de producto tranquilizadora.

Para un piloto solo documental, el equipo podría prohibir que el texto generado desencadene directamente una acción operativa. Registre esa restricción como una decisión real de integración. Simplemente añadir una frase a una diapositiva de formación no establece lo que el software puede invocar.

La visión general de la plataforma empresarial proporciona un punto de partida para discutir la topología. Un registro de compra aún necesita la configuración elegida para el sitio particular.

Preservar la identidad de lo que se probó

Hugging Face documenta las tarjetas de modelo como un lugar para la información del modelo, incluyendo el uso previsto, limitaciones y evaluación.[2] Guarde la tarjeta del candidato con la referencia de revisión utilizada durante la evaluación. Registre el tiempo de ejecución y la configuración de despliegue junto con ella. Un revisor posterior no debería tener que inferir qué archivo de modelo estaba detrás de un resultado antiguo.

Mantenga las entradas de prueba bajo los controles de acceso propios de la organización. El registro de revisión puede referirse a un conjunto de pruebas aprobado sin copiar documentos fuente confidenciales en una presentación de adquisición. Indique quién puede recuperar las entradas y cómo se puede repetir la prueba.

Registre también el flujo de trabajo circundante. Una respuesta generada a partir de una colección de documentos diferente es una prueba distinta, incluso si el archivo del modelo no cambió. También lo es una respuesta evaluada contra una regla de aceptación relajada. Versionar solo el modelo deja esos cambios invisibles.

Pruebe la falla y la transferencia

Elija ejemplos que expongan los límites de la tarea. Para un asistente de documentos, incluya una pregunta sin respuesta en los documentos permitidos, dos pasajes que entren en conflicto y una página escaneada cuyo orden de lectura sea incómodo. Acuerde de antemano cómo el revisor juzgará cada respuesta. Estos son casos de prueba sugeridos, no un conjunto de evaluación certificado.

La evidencia de rendimiento también necesita sus condiciones. MLCommons describe los benchmarks de inferencia usando cargas de trabajo definidas, objetivos de calidad y escenarios de medición.[3] Un resultado obtenido bajo esas condiciones es útil en su contexto adecuado. No es un nivel de servicio observado para una instalación no probada.

Para el piloto, mida el flujo de trabajo real de revisión y documente qué sucede cuando el servicio se detiene. ¿Quién recibe la falla? ¿Puede el usuario volver al documento original? ¿Qué registro sobrevive a una solicitud cancelada? Ejercite esos caminos mientras el sistema aún es lo suficientemente pequeño para que el equipo lo entienda.

La recuperación merece un responsable nombrado. Mantenga la configuración conocida previa disponible bajo el proceso de cambios de la organización y defina quién puede aprobar el retorno a ella. Una solución de respaldo propuesta que nadie pueda ejecutar es una parte incompleta del diseño.

Haga que la siguiente decisión sea específica

La revisión debe terminar con una decisión delimitada: continuar esta tarea bajo estas condiciones, repetir estas pruebas tras un cambio o detenerse hasta que se aborde una deficiencia nombrada. Evite convertir un piloto de documentos exitoso en un respaldo de usos operativos no relacionados.

El registro de costos debe usar el mismo límite. Nuestro artículo sobre costo por tarea aceptada explica por qué las salidas revisadas y rechazadas pertenecen a ese cálculo. Los revisores técnicos y financieros pueden entonces discutir la misma unidad de trabajo.

Use la AI Server información para identificar las preguntas de despliegue, luego incorpore la tarea propuesta y el registro de aceptación en la evaluación. La evidencia se vuelve útil cuando otra persona puede repetir la prueba y entender la decisión.

Referencias

  1. NIST. Marco de Gestión de Riesgos de IA. Consultado el 12-09-2026.
  2. Hugging Face. Fichas de Modelos. Consultado el 12-09-2026.
  3. MLCommons. MLPerf Inferencia: Centro de Datos. Consultado el 12-09-2026.

Artículos relacionados

Get it from Microsoft