Checklist de despliegue de IA on-premise

Datos y frontera de red

Enumera datos de entrada y salida, fuentes, usuarios, servicios externos y registros. Aclara qué comunicaciones salientes quedan permitidas y cómo se supervisan.

Carga, modelos y hardware

Mide el flujo esperado, concurrencia, latencia y memoria. Comprueba con datos representativos; un benchmark aislado no dimensiona la operación.

Actualizar, observar y recuperar

Define identidad y permisos, versiones de modelos, métricas de servicio, copias, restauración y reversión. Deja responsables y procedimiento de transferencia por escrito.

Preguntas para la prueba de aceptación

• ¿Responde el servicio dentro del tiempo acordado con el número de usuarios previsto?
• ¿Puede un usuario sin permiso acceder a una fuente por respuesta, registro o caché?
• ¿Se puede actualizar un modelo o índice y revertir el cambio sin perder trazabilidad?
• ¿Se ha probado restaurar una copia, además de generar copias?

Escribe quién ejecutará cada comprobación y qué evidencia conservará. Una prueba de aceptación no consiste sólo en que el equipo de desarrollo muestre una demo: debe permitir al equipo operador repetir los pasos. Ajusta el checklist a la criticidad del flujo; algunas preguntas necesitarán especialistas de red o seguridad.

1. Clasificar los datos y la frontera del despliegue

Enumera documentos, grabaciones, prompts, salidas y registros operativos que tocará el sistema. Identifica responsable, sensibilidad, conservación y personas con permiso para cada grupo. Indica si el sistema vivirá en un centro de datos del cliente, una red segmentada, un dispositivo de borde o una arquitectura híbrida; «on-premise» no define por sí solo el límite. Marca cualquier servicio que pueda seguir siendo externo, incluso actualizaciones, telemetría y soporte.

2. Dimensionar desde el trabajo real

Anota usuarios simultáneos, picos, longitud de contexto, volumen documental, objetivos de latencia y tolerancia al fallo. Prueba un modelo y una cadena de recuperación representativos con esos datos. Registra memoria al iniciar y durante carga sostenida, profundidad de cola y latencia de cola, no sólo una respuesta de demostración. Repite si cambia cuantización o versión del modelo: ambas pueden afectar calidad y capacidad.

3. Decidir quién puede acceder a qué

Dibuja los flujos de red permitidos entre clientes, identidad, inferencia, índice, almacenamiento y observabilidad. Nombra puertos, protocolos, dependencias salientes y acceso de administración. Define roles de servicio y de usuario, rotación de credenciales y revocación. Para un asistente documental, prueba que una fuente restringida no salga en una respuesta citada, caché o registro. Pide a responsables de seguridad y red que confirmen los supuestos; un diagrama no es una aprobación.

4. Preparar cambios y recuperación antes de publicar

Versiona modelo, configuración y proceso de construcción del índice. Acuerda cómo se evalúa y promociona una versión, cómo se revierte modelo e índice y quién autoriza el cambio. Haz copias de datos y configuración y restaura una muestra en otro entorno. Registra el tiempo observado en esa muestra y lo no probado. Tener un fichero de copia no equivale a poder recuperar el servicio.

5. Transferir la operación

Observa salud, latencia de inferencia, fallos de recuperación, almacenamiento, colas y eventos de acceso sin registrar por defecto contenido sensible. Escribe quién recibe alertas, gestiona incidencias y mantiene dependencias. La transferencia debe incluir mapa del sistema, instrucciones, límites conocidos, conjunto de pruebas y responsables de cambios futuros. Pide al equipo operador que repita despliegue, reversión y recuperación antes de dar el servicio por listo.

Este checklist acompaña al servicio de despliegue on-premise y a la guía de capacidad GPU. Los umbrales de aceptación deben salir del trabajo real; nada de lo anterior representa una prueba de cliente ya ejecutada.