Desarrollar aplicaciones empresariales con LLM y APIs: arquitectura, herramientas, seguridad y operación · Módulo 5: Entrega de producto
Desplegar un piloto y operar la aplicación LLM
Proyecto final con despliegue gradual, flags, observabilidad, runbook, rollback y criterios explícitos de ampliación o parada.
Objetivo de aprendizaje
Entregar un piloto LLM reproducible y operable con alcance limitado, observabilidad, respuesta a incidentes y capacidad de reversión.
El proyecto final debe demostrar algo más que una demo funcional. Debe poder desplegarse para un alcance limitado, observarse, detenerse y revertirse sin depender de la persona que escribió el primer prototipo.
ready no significa «abrir a toda la empresa».
Define el alcance del piloto
Selecciona:
- usuarios;
- tareas;
- datos;
- herramientas;
- límites;
- periodo;
- métricas;
- riesgos;
- responsable.
No amplíes durante el piloto cada vez que aparezca una petición nueva. Registra nuevas necesidades para otra versión.
Prepara configuración y secretos
Antes de desplegar revisa:
- variables;
- claves;
- roles;
- endpoints;
- modelos;
- herramientas;
- migraciones propias;
- límites;
- feature flags;
- política de logs;
- alertas.
Separa entornos y evita reutilizar secretos sin necesidad.
Usa flags y kill switches
Debe ser posible:
- desactivar generación;
- desactivar una tool;
- cambiar de modelo;
- pasar a modo solo lectura;
- bloquear una función;
- desviar a flujo manual.
Un kill switch no sirve si requiere desplegar código durante un incidente.
Expón por fases
Una progresión razonable:
- desarrollo;
- evaluación offline;
- equipo interno;
- shadow mode;
- cohorte pequeña;
- ampliación.
Cada transición necesita evidencia.
No copies umbrales universales. Define criterios según riesgo.
Observa el piloto
Revisa:
- calidad;
- permisos;
- tool errors;
- latencia;
- coste;
- tasa de revisión;
- feedback;
- incidentes;
- tareas completadas.
Mantén comparación con baseline o proceso anterior cuando sea posible.
Crea un runbook
Incluye al menos:
- proveedor caído;
- rate limit;
- coste anómalo;
- output inválido;
- degradación de calidad;
- tool equivocada;
- posible filtración;
- corrupción de estado;
- job atascado.
Para cada incidente define:
- detección;
- severidad;
- contención;
- responsable;
- diagnóstico;
- rollback;
- comunicación;
- verificación de recuperación.
Diseña rollback
Poder volver atrás significa conocer:
- versión anterior;
- configuración;
- esquema;
- estado;
- compatibilidad de datos.
Si una nueva versión crea efectos irreversibles, rollback del código no revierte automáticamente esos efectos. El runbook debe distinguir software y estado de negocio.
Entregable final
Entrega:
- código;
- contratos;
- configuración;
- adaptadores;
- tool schemas;
- evals;
- threat model;
- observabilidad;
- runbook;
- flags;
- resultados;
- costes;
- limitaciones;
- decisión.
Documenta también qué no se probó.
Criterio de cierre
La aplicación está preparada para ampliar su uso cuando otro equipo puede:
- desplegarla;
- entender sus contratos;
- reproducir tests;
- interpretar métricas;
- limitar tools;
- investigar un fallo;
- activar un modo degradado;
- revertir una versión.
El siguiente curso de producción puede profundizar en operación transversal, incidentes, evals continuos y cambio de modelos.
Separa infraestructura, aplicación y política
Una misma versión de código puede comportarse de forma distinta por:
- modelo;
- prompt;
- tools;
- flags;
- políticas;
- corpus;
- secretos;
- límites.
Por eso el despliegue debe versionar configuración además de código.
No es suficiente decir «producción corre commit X». Debes poder reconstruir qué configuración efectiva estaba activa.
Diseña migraciones compatibles
Si el piloto introduce estado persistido, planifica cambios de esquema.
Evita despliegues donde una nueva versión requiera una migración irreversible antes de demostrar estabilidad.
Una estrategia común es:
- añadir campos compatibles;
- desplegar código capaz de leer viejo y nuevo;
- migrar datos;
- activar función;
- retirar compatibilidad antigua más tarde.
El patrón exacto depende del stack, pero la idea es mantener posibilidad de rollback.
Define SLOs del piloto
Ejemplos:
- disponibilidad;
- latencia p95;
- tasa máxima de error;
- coste por tarea;
- tasa de revisión humana;
- tasa de tools fallidas;
- tiempo máximo para desactivar una capacidad.
No copies cifras universales. Define objetivos según proceso y riesgo.
Prueba el kill switch
No basta con implementarlo. Simula:
- desactivar una tool;
- cambiar de modelo;
- bloquear una función;
- pasar a solo lectura.
Comprueba cuánto tarda y qué ocurre con jobs en ejecución.
Gestiona compatibilidad de resultados
Si cambias esquema de salida o tool contract, una tarea iniciada con la versión anterior puede terminar después del despliegue.
Decide cómo procesar:
- jobs antiguos;
- eventos pendientes;
- resultados tardíos;
- cachés;
- respuestas guardadas.
La compatibilidad temporal forma parte de la operación.
Revisa dependencia de proveedor
Documenta qué ocurre si:
- el modelo desaparece;
- cambia límite;
- cambia precio;
- cambia comportamiento;
- una región no está disponible.
Mantener un adaptador no elimina la dependencia, pero reduce el acoplamiento y facilita probar una alternativa.
Cierra el piloto con una decisión explícita
No uses «ha ido bien».
La decisión debe ser una de:
- ampliar;
- mantener limitado;
- corregir y repetir;
- cambiar arquitectura;
- retirar.
Y debe estar apoyada por resultados, riesgos y limitaciones documentadas.
Ejercicio final
Construye un dossier de decisión con:
- alcance;
- arquitectura;
- permisos;
- evaluaciones;
- resultados;
- fallos;
- coste;
- latencia;
- riesgos;
- rollback;
- runbook;
- criterio de avance.
La decisión puede ser desplegar, restringir, repetir el piloto o detener. Un piloto profesional produce evidencia para decidir, no una obligación de continuar.