Una demo valida una capacidad; producción valida un sistema. El piloto está listo para avanzar cuando supera casos representativos, trabaja con fuentes y permisos reales, falla de forma controlada, tiene observabilidad, coste asumible, despliegue gradual, rollback y un responsable operativo. “Ha funcionado diez veces” no es un gate de producción.
La mayoría de sorpresas aparecen fuera del modelo: datos que cambian, APIs lentas, permisos, concurrencia, excepciones y operación. El objetivo no es eliminar todo fallo, sino saber detectarlo, contenerlo y recuperar el proceso sin improvisar.
Si una de estas respuestas es “ya lo veremos”, el piloto puede estar listo para aprender más, pero no para ampliar exposición.
Incluye casos normales, ambiguos, incompletos, adversariales y casos donde el sistema debería abstenerse o escalar. Versiona dataset, prompt, modelo, tools y configuración relevante.
No necesitas miles de casos para empezar; necesitas suficiente cobertura para detectar regresiones que el equipo considera material.
Un prototipo sobre archivos preparados no descubre documentos obsoletos, duplicados, permisos por rol ni carreras de estado. Antes de ampliar, conecta la fuente autoritativa y el sistema donde termina la acción.
Cuando el resultado depende de identidad o contexto, ese dato debe viajar de forma explícita durante todo el flujo.
Timeouts, cuotas, respuestas fuera de esquema y APIs caídas ocurrirán. Define qué se reintenta, cuántas veces, qué operaciones son idempotentes y cuándo el caso queda en cola o escala a una persona.
Un retry mal diseñado puede duplicar correos, pedidos o cambios de estado. La recuperación forma parte del producto.
| Capa | Qué necesitas distinguir |
|---|---|
| Datos/retrieval | Fuente incorrecta, ausente o sin permiso. |
| Modelo | Interpretación o salida incorrecta. |
| Tool | Selección o argumentos erróneos. |
| Integración | API, timeout, estado o validación. |
| Operación | Coste, latencia, escalado y carga humana. |
Sin esta separación, cualquier incidente termina resumido como “la IA se equivocó” y se vuelve difícil corregirlo.
Si el sistema escala el 20 % de los casos, ese volumen debe caber en la operación. Mide cuántos casos llegan, cuánto tarda la revisión y qué información recibe la persona.
Human-in-the-loop no es un botón mágico. Si el revisor tiene que reconstruir desde cero todo lo que hizo la IA, el ahorro puede desaparecer.
Diez ejecuciones no muestran concurrencia, colas, límites de API ni el coste de los reintentos. Simula un volumen representativo y observa p50/p95 de latencia, errores transitorios, consumo y throughput.
Conecta este dato con ROI de IA: el sistema puede ser técnicamente bueno y económicamente inviable al volumen real.
Hay varias formas de reducir riesgo: ejecutar en sombra sin producir efectos, limitar a un grupo de usuarios, activar un porcentaje del tráfico o permitir lectura/propuesta antes de escritura automática.
La idea es aumentar exposición cuando la evidencia lo justifica. Microsoft Agent Framework ya trata checkpoints, human-in-the-loop y observabilidad como capacidades de producción de workflows, no como extras.
Microsoft Agent Framework · Workflow capabilities.
Una regresión puede venir de prompt, modelo, embedding, fuente, tool, lógica de negocio o configuración. Versiona los componentes que pueden cambiar el comportamiento y define cómo desactivar una capacidad sin romper el proceso.
En sistemas con acciones, también necesitas reconciliar qué ocurrió antes de la reversión.
Alguien debe responder por métricas, fuentes, accesos, incidentes y cambios. Define un runbook: señal de alerta, responsable, cómo aislar el problema, cómo degradar la función y qué evidencia guardar.
Los primeros 30–90 días no son “mantenimiento”: son la fase en que el sistema aprende del trabajo real. Sólo se amplía lo que mantiene calidad, coste y riesgo dentro del contrato operativo.
Para aplicar estas comprobaciones a una operación concreta, utiliza el recorrido de CRM a ERP: preparar y registrar un pedido con revisión. Permite acordar qué ocurre con una venta ambigua, una versión modificada y una respuesta del destino que todavía no se ha confirmado. Para presupuestar esa conexión, delimita las operaciones de integración de IA con CRM y ERP y quién acepta cada resultado.
Respuestas directas para convertir la pregunta en una decisión de proyecto.
Cuando supera criterios acordados de calidad y riesgo con casos representativos y tiene resueltos datos, permisos, fallos, observabilidad, coste y ownership.
Producción añade usuarios reales, volumen, fuentes que cambian, permisos, errores externos, soporte y obligación de mantener el comportamiento.
Calidad, errores por causa, latencia, coste por tarea, reintentos, escalados, acciones externas y cambios de fuentes o componentes.
Depende del riesgo y de la capacidad de validación automática. Si existe, hay que medir su carga y diseñar un handoff útil.
Shadow mode, grupos limitados, canary, autonomía progresiva, comparación con baseline y capacidad de rollback.
Se revisa arquitectura, alcance o hipótesis. Un piloto técnico no obliga a producción si el coste por tarea útil no compensa.
Convertimos la prueba en un production gate medible: evals, permisos, fallos, observabilidad, coste, rollout y operación.