El POC no es el 20% del trabajo. Es el 5%.
Un agente que extrae datos de una factura y responde preguntas funciona en un cuaderno de pruebas la primera semana. Lo que no existe todavía es todo lo demás: qué pasa cuando el modelo se actualiza y el comportamiento cambia sin que nadie toque el código, cómo se detecta que la tasa de error sube del 2% al 9% en un tipo de documento concreto, cuánto cuesta cada expediente procesado cuando el volumen se multiplica por cincuenta, y qué evidencia queda de cada decisión cuando auditoría interna pide el expediente de marzo.
En software tradicional esa disciplina se llama operaciones y nadie discute su necesidad. Con agentes tiene una dificultad añadida que lo cambia todo: el sistema es no determinista. El mismo input puede producir outputs distintos, el proveedor actualiza el modelo bajo tus pies, y la definición de "funciona bien" no es un test unitario que pasa o falla — es una distribución estadística que hay que medir de forma continua.
Los números que siguen salen de sistemas reales: los agentes de validación documental UCP 600 en trade finance de banca corporativa y los agentes de operaciones que trabajan en entidades del Top-5 de banca y seguros en España.
Los cuatro pilares de AgentOps
Da igual el stack — Bedrock AgentCore, Azure AI Foundry, Vertex o un framework propio sobre MCP —: la operación de agentes se sostiene sobre cuatro pilares. Si falta uno, el sistema funciona hasta que deja de hacerlo, y nadie sabe por qué.
El cuadro de mando que el comité entiende
Estas son las seis métricas que mantenemos en el panel de cualquier agente en producción. Ninguna es exótica; la disciplina está en medirlas todas las semanas y en que cada una tenga un umbral de actuación acordado antes del despliegue, no después del primer incidente.
| Métrica | Qué responde | Umbral típico de actuación |
|---|---|---|
| Task success rate | ¿El agente completa la tarea correctamente? (medido contra golden dataset y muestreo en producción) | < 95% en tareas automatizadas → revisar antes de ampliar alcance |
| Tasa de escalado a humano | ¿Cuánto trabajo sigue necesitando personas? | Sin tendencia a la baja en 3 meses → revisar diseño del feedback |
| Coste por interacción | ¿Salen las cuentas frente al proceso manual? | > 30% del coste del proceso manual equivalente → optimizar routing/contexto |
| Latencia p95 | ¿La experiencia es utilizable en el flujo real? | Depende del canal: segundos en conversacional, minutos en backoffice |
| Desviación en evals | ¿Ha cambiado el comportamiento sin cambiar el código? | Caída > 2 puntos vs. baseline → congelar cambios y diagnosticar |
| Incidentes por intervención del agente | ¿Cuántas acciones del agente generan un problema aguas abajo? | Cualquier incidente severo → post-mortem con la traza completa |
El detalle que casi nadie versiona: todo
En software clásico se versiona el código. En AgentOps hay que versionar cinco cosas a la vez, porque cualquiera de ellas cambia el comportamiento del sistema: el prompt (y sus plantillas), el modelo (proveedor y versión concreta), las herramientas expuestas al agente (y sus permisos), el corpus de contexto (índices RAG, memoria) y el golden dataset de evaluación. Un despliegue reproducible es la combinación exacta de las cinco. Cuando algo se degrada, la primera pregunta del diagnóstico es cuál de las cinco cambió — y si la respuesta es "ninguna", el proveedor actualizó el modelo y tu suite de evals es lo único que te lo va a contar.
El error más caro: anclar el sistema a un alias de modelo ("latest") en lugar de a una versión concreta. Todos los proveedores actualizan los modelos detrás de los alias, y una mejora general puede ser una regresión concreta en tu caso de uso. Versión fijada + evals en cada cambio de versión + ventana de rollback. Siempre.
AgentOps es tu expediente del AI Act (casi gratis)
Hay una convergencia que conviene aprovechar: lo que montas para operar agentes es, en gran parte, lo que el AI Act exige a los sistemas de alto riesgo a partir de diciembre de 2027. El registro automático de eventos del artículo 12 es tu traza de observabilidad. La supervisión humana efectiva del artículo 14 es tu diseño HITL con métricas. La precisión y robustez del artículo 15 son tus evals con umbrales declarados. La documentación técnica del Anexo IV se escribe sola si el pipeline ya versiona prompts, modelos y datasets.
La lectura práctica: si construyes AgentOps como disciplina de ingeniería hoy, el cumplimiento regulatorio de 2027 es un ejercicio de documentación, no un proyecto nuevo. Si lo dejas para el final, pagarás dos veces por lo mismo.
El runbook de 8 semanas
La secuencia que usamos para llevar un agente de la idea a producción con ROI medible — el mismo patrón que en los casos de trade finance y operaciones citados arriba:
Contexto regulatorio: el calendario del AI Act cambió en junio con el Digital Omnibus — el alto riesgo se aplaza a diciembre de 2027, pero la transparencia entra en agosto de 2026. Publiqué el análisis completo y un checklist de 12 controles imprimible para el comité de riesgos.
La conclusión incómoda
La mayoría de las organizaciones no tiene un problema de modelos — los modelos de 2026 son más que suficientes para los casos de uso de backoffice que concentran el ROI. Tiene un problema de operación: pilotos sin evals, agentes sin trazas, costes sin unit economics y supervisión humana sin diseño. Esa brecha no la cierra el siguiente modelo más potente. La cierra un equipo que trate a los agentes como lo que son: software crítico no determinista que necesita su propia disciplina de operaciones.
La buena noticia: es una disciplina aprendible, el tooling ha madurado mucho en el último año, y ocho semanas bien secuenciadas bastan para el primer caso en producción con números defendibles ante cualquier comité.