El registro de entrega que recomendamos para un servicio privado de IA

El Marco de Gestión de Riesgos de IA de NIST aborda la confiabilidad en el diseño, desarrollo, uso y evaluación de sistemas de IA.[1] El período operativo merece su propia evidencia. Para un piloto privado de IA que pasa a uso rutinario, recomendamos un registro de entrega que permita al equipo receptor identificar la instalación, comprender sus límites y responder cuando algo deje de funcionar.

Este es nuestro formato propuesto de entrega, no un informe de una implementación auditada del cliente. Complementa la información técnica y de límites de datos en el centro de confianza de Software Tailor. Cada organización debe asignar las responsabilidades según su propio modelo operativo.

Nombre al propietario receptor y el trabajo permitido

Comience con un rol nombrado que acepte la responsabilidad del servicio. Registre su vía de contacto y el arreglo alternativo cuando el propietario habitual no esté disponible. Una dirección de soporte del proveedor es útil, pero la organización también necesita a alguien que pueda decidir si el servicio debe continuar funcionando durante un incidente.

Describa las tareas aprobadas para uso rutinario y las tareas aún confinadas al piloto. Incluya los grupos autorizados para usar el servicio y el horario operativo esperado. Un hallazgo no resuelto del piloto debe permanecer visible con un propietario y una fecha de decisión planificada; no debe desaparecer porque la instalación haya cambiado de estado.

Mantenga las suposiciones de capacidad y plazo utilizadas en la decisión de compra. Eso da al equipo receptor una razón para investigar cuando la carga de trabajo cambie.

Preserve la configuración que fue realmente verificada

Registre las versiones de la aplicación y del servidor, el tiempo de ejecución y la referencia exacta del modelo. Conserve la fuente de instalación y la configuración relevante mediante el proceso normal de documentos controlados de la organización. Almacene las credenciales a través del proceso de gestión de credenciales, con referencias en la entrega en lugar de copiar valores secretos.

Las tarjetas de modelo de Hugging Face proporcionan documentación sobre usos, limitaciones y evaluación del modelo.[2] Enlace la tarjeta y revisión relevantes, luego agregue los hallazgos locales del piloto. La descripción del editor y los resultados de prueba de la organización responden a preguntas diferentes; el equipo receptor debe poder localizar ambos.

Cuando el sistema tiene proveedores externos opcionales, registre qué rutas están habilitadas. Describa el límite de datos previsto para cada ruta y quién puede aprobar un cambio. Evite una etiqueta amplia como “local” cuando la configuración operativa requiere una explicación más precisa.

Asignar responsabilidad para acciones y permisos

Para una integración de agente, adjunte la lista de herramientas acordada y la identidad utilizada por cada conexión. OWASP recomienda limitar las capacidades y permisos del agente, y hacer cumplir la autorización en los sistemas descendentes.[3] Nuestra propuesta de entrega convierte esa recomendación en una cuestión de propiedad: ¿quién puede revisar o revocar cada concesión?

Incluya el resultado de las comprobaciones de integración de llamadas a herramientas, con cualquier restricción restante. Distinga el permiso para proponer una operación del permiso para ejecutarla. Si una persona debe aprobar una acción, identifique dónde ocurre esa aprobación y cómo se maneja una aprobación fallida o abandonada.

El propietario receptor también debe saber qué registros de diagnóstico existen, quién puede acceder a ellos y cuánto tiempo se conservan. Use la política configurada y un ejemplo verificado. No infiera que los prompts están ausentes en cada componente conectado simplemente porque un componente tenga un diseño de auditoría sin contenido.

Ensaye una interrupción antes de la entrega

Elija una interrupción acordada y no destructiva en un entorno de prueba. Haga que el equipo receptor siga las instrucciones de recuperación mientras el implementador original observa. Registre la información faltante que encuentren y actualice las instrucciones antes de la aprobación final.

El ejercicio debe establecer cómo reconocer el problema, quién puede detener el trabajo afectado y cómo verificar el servicio recuperado. Si la reversión forma parte del plan, identifique la versión retenida y el punto en que la reversión es apropiada. Mantenga las suposiciones de recuperación no probadas etiquetadas como no probadas.

Para una discusión de servicio de Software Tailor, un registro de configuración redactado y un relato claro del paso fallido son más útiles que una afirmación sin soporte de que todo el sistema está roto. La entrega debe explicar cómo recopilar esa información a través de la ruta de soporte aprobada por la organización.

Haga que la aprobación sea un registro útil

Finalice con la aceptación del propietario receptor, la fecha y los puntos no resueltos. Nombre los cambios que deberían desencadenar una revisión, como un modelo diferente, un nuevo conector o una tarea permitida más amplia. Esto es una disciplina operativa propuesta más que un esquema de certificación.

El registro está listo cuando el equipo receptor puede usarlo para tomar una decisión sin reconstruir el piloto de memoria.

Referencias

[1] NIST. AI Risk Management Framework. Framework 1.0 lanzado en 2023; guía de fondo. Consultado el 26-09-2026.

[2] Hugging Face. Fichas de Modelo. Guía permanente de documentación de modelos. Consultado el 26-09-2026.

[3] Proyecto de Seguridad OWASP Gen AI. LLM06:2025 Agencia Excesiva. Edición 2025. Consultado el 26-09-2026.