Un agente no es capacidad operativa hasta que alguien acepta el pager
Por Equipo Quantum Developers
Resumir:
Tesis operativa
Un agente puede completar una demo y aun no pertenecer a la operación. La prueba no es si responde: es si alguien acepta una alerta, paga el costo recurrente, decide cuándo reducir autonomía y puede retirarlo sin perder casos. Si esas decisiones no tienen dueño, la empresa posee una demostración técnica, no una capacidad.
NIST pide inventario, roles claros, monitoreo continuo y procedimientos para desactivar sistemas de IA de forma segura en el AI RMF Core. El paso decisivo, por tanto, no es “pasar a producción”. Es firmar un estatuto operativo que asigne autoridad y recursos durante todo el ciclo de vida.
El estatuto que convierte software en servicio
El documento debe caber en dos páginas y apuntar a evidencia viva. Estos son sus bloques:
| Bloque | Decisión que deja explícita |
|---|---|
| Propósito | objeto, población, resultado y acciones prohibidas |
| Dueño | persona responsable del resultado y del riesgo residual |
| Autoridad | quién cambia política, permisos, modelos y alcance |
| Servicio | horario, SLO, dependencias y modo degradado |
| Guardia | alerta accionable, primera respuesta y escalamiento |
| Runbook | diagnóstico, pausa, recuperación y reconciliación |
| Presupuesto | construcción, uso, revisión, soporte y contingencia |
| Cambios | pruebas, aprobación, versión y rollback |
| Evidencia | eventos, artefactos, retención y acceso |
| Retiro | disparadores, responsable, destino de casos y credenciales |
Una lista de nombres no basta. El dueño necesita capacidad real para detener ejecución, negociar presupuesto y aceptar o rechazar riesgo. Si operaciones responde por incidentes pero producto puede ampliar el alcance sin su aprobación, la responsabilidad es ficticia.
Propósito y frontera antes del nombre del agente
Empiece por el objeto y la acción: “proponer asignación de cobro para casos con documentos completos”, no “agente financiero inteligente”. Declare población elegible, resultado observable y punto irreversible. Registre las acciones que siempre requieren persona y las fuentes que nunca pueden usarse.
Este bloque evita dos fallas. La primera es la expansión silenciosa: un agente útil recibe nuevas tareas sin nueva evaluación. La segunda es la responsabilidad difusa: cuando falla, cada equipo afirma que solo administraba una pieza. El estatuto identifica un único dueño de resultado y responsables específicos de datos, plataforma, control y respuesta.
Un SLO con consecuencia
Google define un SLO como objetivo sobre un indicador y distingue el acuerdo por las consecuencias asociadas en su capítulo de Service Level Objectives. Para un agente, el conjunto mínimo puede incluir:
- casos elegibles aceptados por el flujo;
- decisiones verificadas como correctas;
- excepciones asignadas dentro de la ventana;
- cierres con evidencia completa;
- acciones irreversibles con aprobación válida;
- antigüedad de la cola pendiente.
Cada incumplimiento necesita respuesta. La falta de evidencia bloquea cierre; la caída de calidad devuelve el agente a recomendación; una cola envejecida reduce el universo elegible; una dependencia caída activa el modo degradado. Un indicador sin consecuencia acordada informa, pero no gobierna.
Guardia y runbook: quién se despierta y qué puede hacer
No toda alerta merece pager. La alerta de guardia debe representar amenaza al resultado o al SLO y ser accionable. El capítulo de Google SRE sobre Being On-Call destaca rutas claras de escalamiento, procedimientos definidos y carga sostenible. Copiar una rotación sin capacidad suficiente solo convierte un vacío de diseño en agotamiento humano.
La tarjeta de alerta incluye objeto afectado, severidad, primera acción segura, permiso requerido y experto de dominio. El runbook separa cuatro fallas:
- Modelo o regla: salida anómala; cambiar a versión previa o recomendación.
- Herramienta: una acción externa falla; detener reintentos y proteger idempotencia.
- Datos: fuente tardía o inconsistente; congelar población afectada.
- Operación humana: cola o aprobación sin capacidad; priorizar por consecuencia.
Después de recuperar, el equipo reconcilia casos que quedaron en estados inciertos. “Reiniciar” no es resolución si pudo ejecutarse una acción antes del fallo.
Presupuesto con responsable
El costo operativo incluye consumo, integraciones, almacenamiento de evidencia, observabilidad, revisión, guardia, incidentes y cambios. Los principios de FinOps ponen el valor de negocio y la responsabilidad de uso y costo en el centro de la decisión tecnológica. El estatuto debe nombrar centro de costo, límite, señal de anomalía y persona autorizada para cambiarlo.
No se trata de imponer un techo que derribe el agente al final del mes. Se definen modos: dentro de presupuesto opera; cerca del límite reduce trabajo no prioritario; fuera del límite requiere decisión del dueño. El costo por resultado importa más que el costo por llamada.
Cambios y reautorización
Política, fuente, herramienta, modelo, prompt, permiso y población son componentes versionados. El estatuto clasifica cambios: rutinario, material o de emergencia. Un cambio material requiere prueba contra casos representativos, revisión del dueño y rollback. El de emergencia deja caducidad y revisión posterior.
La reautorización se activa cuando cambia la consecuencia posible, aparece una nueva población, se degrada evidencia o el costo deja de sostener valor. No espere una revisión anual si el contexto cambió hoy.
Retirar sin dejar una deuda invisible
La regla de retiro declara disparadores: propósito ya inexistente, control ineficaz, costo fuera de rango, reemplazo disponible, obligación cambiada o resultado no verificable. El plan detiene nuevas entradas, resuelve o transfiere casos, conserva evidencia según política, revoca identidades, elimina secretos y actualiza catálogo y runbooks.
En Quantum Automation Center, el catálogo, estados, cronologías, artefactos, logs, analítica, permisos y aprobaciones pueden conectar el estatuto con ejecuciones reales. La ficha no debe vivir como PDF olvidado; cada enlace debe llevar al objeto operativo vigente.
Prueba de aceptación
Antes de llamar “capacidad” al agente, pida una demostración:
- el dueño explica qué resultado acepta y qué acción no delega;
- la guardia recibe una alerta de prueba y encuentra el caso;
- el operador pausa nuevas entradas sin perder la cola;
- el equipo revierte un cambio y reconcilia el estado;
- finanzas identifica costo total y límite;
- control reconstruye una decisión desde evidencia;
- el responsable ejecuta un retiro simulado.
No son ceremonias. Revelan permisos ausentes, dependencia de una persona y documentación que nunca funcionó.
El mejor contraargumento
Exigir este estatuto completo puede encarecer la exploración. Un equipo pequeño podría dedicar más tiempo a guardias y documentos que a descubrir si la idea resuelve algo. La disciplina prematura también congela una arquitectura que aún debe cambiar.
El argumento es válido para pruebas aisladas y reversibles. Use una versión ligera: dueño, límite de datos, presupuesto pequeño y fecha de expiración. El contrato completo aparece antes de afectar producción o crear dependencia operativa. Lo que no debe ocurrir es que un “piloto” permanezca meses procesando trabajo real sin responsabilidad.
Cuándo no usar este enfoque
No aplique el contrato completo a un prototipo aislado que no toca producción, no conserva datos sensibles y puede eliminarse sin afectar trabajo. Defina, aun así, una expiración y un responsable.
Sí úselo en cuanto una persona dependa del resultado, una acción alcance un sistema de registro o una interrupción genere cola. En ese momento, dueño, pager, runbook, presupuesto y retiro dejan de ser burocracia: son la definición misma de capacidad operativa.
Sources
Temas del artículo
