LLMOps es la disciplina para convertir aplicaciones con modelos de lenguaje en servicios controlables. Una pyme no necesita una plataforma enorme: necesita saber qué modelos usa, evaluar tareas reales, versionar prompts y conocimiento, desplegar con puertas, observar calidad y coste, gestionar incidentes y poder volver a una versión segura.
Inventario mínimo
Cada aplicación debe registrar:
- propietario;
- finalidad;
- modelo y proveedor;
- versión y región;
- prompt/política;
- datos y RAG;
- herramientas;
- permisos;
- métricas;
- coste;
- estado y fecha.
Las funciones de IA incluidas en SaaS también cuentan: sin este registro es imposible saber cuántas aplicaciones con modelos de lenguaje operan realmente en la empresa.
Entornos
Separar desarrollo, evaluación y producción. Las pruebas no usan datos reales sin necesidad. Las credenciales y límites son distintos.
El paso a producción requiere aprobación y evidencia. No se edita el prompt directamente en producción sin versión, porque ese control evita cambios improvisados que después nadie puede explicar ni revertir.
Versionar el sistema completo
La respuesta depende de:
- modelo;
- parámetros;
- prompt;
- herramientas;
- política;
- índice y documentos;
- código;
- formato de salida.
Una «versión del agente» debe fijar todas estas dependencias para reproducir un fallo; sin esa fijación, dos ejecuciones aparentemente idénticas pueden dar resultados distintos.
Evaluación
El conjunto contiene casos ordinarios, límites, preguntas sin respuesta, datos incompletos, ataques y fallos de herramientas.
Métricas:
| Capa | Métrica |
|---|---|
| Resultado | exactitud, completitud y formato |
| Fidelidad | soporte en fuentes |
| Seguridad | fuga, inyección y acción prohibida |
| Operación | latencia, disponibilidad y coste |
| Humana | correcciones, escalados y adopción |
| Impacto | reclamaciones y daño |
Las clases críticas tienen tolerancia cero: un fallo en ellas bloquea el paso a producción aunque el resto de métricas mejore.
Pruebas de regresión
Se ejecutan al cambiar modelo, prompt, proveedor, fuente, herramienta o política. Se comparan nueva y anterior con el mismo conjunto.
No se promueve una versión porque sea mejor en promedio si empeora casos críticos.
Despliegue gradual
- Sombra sin acciones.
- Usuarios internos.
- Población limitada.
- Automatización de bajo impacto.
- Ampliación condicionada.
Cada fase tiene criterios de salida y rollback, porque avanzar sin cumplirlos traslada el riesgo directamente a los usuarios reales.
Observabilidad
La traza incluye:
- solicitud e identidad;
- versión;
- fuentes;
- herramientas;
- validaciones;
- respuesta;
- aprobación;
- tokens, coste y latencia;
- feedback.
Se minimizan datos personales y secretos. Los logs no son una copia indiscriminada de conversaciones: el objetivo es poder reconstruir qué ocurrió, no acumular información innecesaria.
Alertas
- subida de errores;
- aumento de abstención;
- coste anómalo;
- latencia p95;
- herramientas rechazadas;
- cambios de distribución;
- documentos obsoletos;
- acceso denegado;
- bucles.
Cada alerta tiene propietario y runbook, porque una alerta que nadie atiende equivale a no tener alerta.
Seguridad y cadena de suministro
OWASP destaca riesgos en modelos, datos, dependencias y plataformas. Se revisan:
- procedencia de modelos;
- hashes y firma;
- paquetes;
- permisos;
- prompt injection;
- salida no confiable;
- secrets;
- proveedores;
- SBOM cuando proceda.
Una salida del modelo nunca se ejecuta sin validación: la confianza en el modelo no sustituye a la verificación de lo que produce.
Gestión de costes
Se fijan presupuestos por aplicación, usuario y tarea. Se mide coste por resultado válido.
Técnicas:
- enrutamiento por dificultad;
- modelos pequeños;
- contexto mínimo;
- caché con caducidad;
- límites de pasos;
- recuperación selectiva;
- procesamiento por lotes.
No se reduce coste sacrificando evidencia o seguridad, porque ese ahorro suele salir más caro en cuanto aparece un incidente.
Incidentes
El procedimiento permite:
- detener;
- revocar credenciales;
- identificar versión;
- reconstruir acciones;
- revertir;
- evaluar personas y datos;
- corregir conjunto de pruebas;
- comunicar.
El aprendizaje se incorpora a evaluación, de modo que el mismo fallo no vuelva a pasar inadvertido en la siguiente versión.
Proveedores
Monitorizar cambios de términos, modelos, precios, regiones, subencargados y límites. Un cambio anunciado por el proveedor activa regresión y, si procede, revisión de privacidad.
Gobierno ligero
| Rol | Responsabilidad |
|---|---|
| Product owner | valor y alcance |
| Equipo técnico | arquitectura y operación |
| Seguridad | amenazas y respuesta |
| Legal/DPO | obligaciones y datos |
| Negocio experto | conjunto y aceptación |
| Dirección | riesgo y recursos |
Plan de 60 días
Días 1–15
Inventario, propietarios y riesgos.
Días 16–30
Conjunto, métricas y versiones.
Días 31–45
Trazas, alertas, seguridad y costes.
Días 46–60
Piloto, rollback e incidentes.
Errores frecuentes
- Versionar solo el modelo.
- Probar con ejemplos del prompt.
- Medir gusto subjetivo.
- Cambiar de proveedor sin regresión.
- Registrar secretos.
- No limitar el coste.
- Carecer de rollback.
- No probar ataques.
- Ignorar el RAG.
- No tener propietario.
Checklist
- Inventario.
- Versionado completo.
- Evaluación independiente.
- Puertas críticas.
- Entornos.
- Trazas y alertas.
- Seguridad y supply chain.
- Presupuestos.
- Incidentes y rollback.
- Revisión de proveedor.
Preguntas frecuentes
¿LLMOps es solo para grandes empresas?
No. Los controles pueden implementarse con herramientas sencillas si son reproducibles.
¿Hay que guardar todos los prompts?
No indiscriminadamente. Debe guardarse la evidencia necesaria con minimización y seguridad.
¿Qué desencadena una regresión?
Cualquier cambio de modelo, prompt, herramienta, datos, índice, política o proveedor.
Fuentes consultadas
Summum IA puede implantar evaluación, observabilidad, seguridad y control de costes sobre tus aplicaciones con modelos de lenguaje, en coordinación con tus agentes de IA.