Evaluar y operar sistemas de IA en producción: calidad, fiabilidad, observabilidad e incidentes · Módulo 5: Operación continua
Preparar readiness y plan de operación
Proyecto final que reúne scope, SLOs, evals, seguridad, observabilidad, rollout, incidentes, ownership, excepciones y retirada.
Objetivo de aprendizaje
Emitir una decisión de readiness para un alcance concreto mediante evidencia verificable, responsables, runbooks, drills y blockers explícitos.
Un sistema está listo para una exposición concreta, no «para producción» en abstracto.
Un piloto interno de solo lectura puede estar listo mientras una versión con escrituras automáticas no lo está.
El readiness review reúne la evidencia y obliga a hacer explícitos los riesgos residuales.
Define alcance
Registra:
- usuarios;
- volumen;
- tenants;
- datos;
- herramientas;
- autonomía;
- regiones;
- horario;
- soporte.
La aprobación solo vale para ese scope.
Evidencias mínimas
Producto
- outcome;
- owners;
- límites.
Evaluación
- dataset;
- rúbricas;
- regression;
- critical cases.
Seguridad
- threat model;
- permissions;
- abuse tests.
Operación
- SLOs;
- dashboards;
- alerts;
- runbooks.
Release
- version manifest;
- rollout;
- rollback.
Dependencias
- modelos;
- proveedores;
- índices;
- tools.
Gobierno
- retención;
- privacidad;
- revisiones.
Clasifica requisitos
PASS Cumplido.
ACCEPTED RISK Existe riesgo residual aceptado por owner.
BLOCKER No desplegar.
N/A No aplica con motivo.
Una media no compensa un blocker.
Excepciones con caducidad
Una excepción necesita:
- owner;
- razón;
- mitigación;
- fecha;
- condición de cierre.
Evita «temporal» sin deadline.
On-call y ownership
Define:
- quién recibe alertas;
- quién puede rollback;
- quién cambia modelo;
- quién responde seguridad;
- quién habla con usuarios.
Un sistema sin owner operativo no está listo.
Runbooks
Al menos:
- provider outage;
- latency;
- bad quality;
- cost spike;
- invalid output;
- RAG stale;
- tool failure;
- security incident.
Cada runbook:
- trigger;
- diagnóstico;
- mitigación;
- escalation;
- restore;
- verify.
Drills
Prueba runbooks antes de necesitarlo.
Google SRE recomienda entrenar y practicar incident response en escenarios controlados.
Un documento no probado puede contener pasos imposibles.
Error budget policy
Incluye qué ocurre cuando:
- SLO se incumple;
- calidad cae;
- error budget se agota.
La política debe influir en release velocity.
Plan de revisión
Calendario para:
- evals;
- providers;
- deprecations;
- cost;
- permissions;
- data;
- security;
- incidents.
Retirada
Define cómo:
- desactivar;
- exportar;
- archivar;
- borrar;
- revocar;
- cerrar jobs.
La retirada forma parte del ciclo de vida.
Dossier final
Entrega:
- scope;
- architecture;
- SLOs;
- dataset;
- eval report;
- traces;
- dashboard;
- alert policy;
- release plan;
- runbooks;
- incident process;
- ownership;
- exceptions;
- provider dependencies;
- retirement.
Decisión
El comité o owner debe responder:
READY Para el scope.
READY WITH CONDITIONS Con condiciones y caducidad.
NOT READY Blockers.
No uses:
«parece bien».
NIST y riesgo
Puedes usar NIST AI RMF para organizar el análisis de riesgo, siempre indicando que es un marco voluntario.
No lo utilices como certificado.
Readiness meeting
Antes de la reunión distribuye el dossier.
La sesión decide; no debería ser la primera vez que alguien ve riesgos.
Participantes según alcance:
- product;
- engineering;
- ops;
- security;
- privacy.
No invites a todo el mundo por defecto.
Evidence links
Cada PASS debe enlazar evidencia:
Regression PASS → run 123
Rollback tested → drill 18Evita checkboxes sin prueba.
Residual risk
Describe:
- riesgo;
- probabilidad;
- impacto;
- control;
- owner.
No uses solo «medium».
Capacity
Comprueba:
- rate limits;
- workers;
- queues;
- storage;
- observability.
Una demo de 10 usuarios no prueba 10.000.
Haz load testing cuando proceda.
Cost readiness
Define:
- budget;
- alert;
- owner;
- shutdown rule.
No descubras el gasto mensual después.
Security readiness
Verifica:
- secrets;
- least privilege;
- tenant isolation;
- audit;
- incident route.
Operational acceptance
El on-call debe aceptar el servicio.
Si solo el equipo de proyecto sabe resolverlo, no está transferido a operaciones.
Handover
Incluye:
- architecture;
- dashboards;
- common failures;
- contacts.
Haz una sesión práctica.
Lifecycle review
Ready no es permanente.
Triggers:
- major model change;
- new tool;
- new data;
- new population;
- incident.
Puede requerir nuevo readiness.
Sunset criteria
Define:
- bajo uso;
- coste;
- proveedor;
- riesgo;
- sustitución.
Retirar software también es ingeniería.
Ejercicio final
Realiza un readiness review de un sistema.
Entrega:
- 10 PASS;
- 3 accepted risks;
- 2 blockers.
Después corrige los blockers y repite.
Simula un drill de incidente antes de emitir READY.
Cierre del curso
Operar IA en producción significa poder responder continuamente:
- ¿funciona?
- ¿para quién?
- ¿con qué calidad?
- ¿qué cambió?
- ¿qué cuesta?
- ¿qué riesgo introduce?
- ¿podemos detenerlo?
- ¿podemos volver atrás?
- ¿sabemos investigar un fallo?
- ¿sabemos cuándo retirarlo?
La madurez no consiste en eliminar todos los fallos. Consiste en convertirlos en señales detectables, decisiones previsibles y aprendizaje acumulativo.