Del piloto a operaciones: la prueba de preparación que un agente de IA debe aprobar
Por Equipo Quantum Developers
Resumir:
Un agente no está listo para producción porque responda bien en una demo, sino cuando cada decisión tiene autoridad definida y cada modo de fallo tiene un dueño capaz de intervenir. La prueba es concreta: si ante una salida equivocada el equipo no puede decir quién detiene, corrige, comunica y autoriza la reanudación, todavía tiene un experimento.
Una demo valida capacidad; producción exige responsabilidad
El piloto suele demostrar que el modelo entiende una solicitud, consulta una herramienta o propone una acción. Eso responde “¿puede hacerlo alguna vez?”. Operaciones necesita otra pregunta: “¿podemos aceptar, detectar y recuperar sus fallos durante todo el ciclo de vida?”.
La diferencia no se resuelve con más precisión promedio. Un agente puede acertar la mayoría de las veces y aun así fallar en el caso que compromete dinero, acceso o una relación con un cliente. Por eso la unidad de control es la decisión: qué evidencia la habilita, hasta dónde llega su autoridad y quién hereda el caso cuando sale de límites.
Ocho puertas de preparación para producción
La Production Readiness Review de Google SRE verifica estándares de operación, prepara a los dueños del servicio y transfiere responsabilidades progresivamente. La guía de Operational Readiness Review de AWS trata la revisión como proceso y checklist que debe ejecutarse antes del lanzamiento y repetirse durante el ciclo de vida. Adaptadas a agentes, esas ideas producen ocho puertas:
- Derecho de decisión. Está documentado qué puede recomendar, ejecutar, aprobar o nunca hacer el agente.
- Dueño de fallos. Cada clase de fallo tiene equipo, contacto y tiempo objetivo de primera acción.
- Límites de entrada. Fuentes permitidas, datos mínimos, antigüedad máxima y reglas ante información conflictiva.
- Evaluación. Casos representativos, casos adversos, criterio de aprobación y registro de la versión probada.
- Observabilidad. Identificador de objeto, decisión, herramienta, resultado, latencia, excepción y evidencia.
- Escalamiento humano. Cola, contexto entregado, prioridad y autoridad del revisor.
- Reversa y pausa. Mecanismo probado para suspender acciones, deshacer cuando sea posible y pasar a modo degradado.
- Costo y continuidad. Presupuesto operativo, límites de consumo, dependencia externa, runbook y condición de retiro.
Un “sí” verbal no abre una puerta. Debe existir un enlace a la política, prueba, tablero, runbook o registro correspondiente.
Matriz de derechos: proponer no es aprobar
Defina la autoridad por acción y consecuencia, no con una etiqueta general de “autonomía”.
| Acción | Agente | Operador | Dueño de negocio |
|---|---|---|---|
| Clasificar una solicitud reversible | ejecuta dentro de límites | revisa muestras y excepciones | acepta la política |
| Recomendar un ajuste financiero | propone con evidencia | valida datos | aprueba o rechaza |
| Publicar, pagar o revocar acceso | prepara el caso | comprueba requisitos | autoriza la acción irreversible |
| Cambiar una política | no autorizado | analiza impacto | aprueba cambio y fecha efectiva |
El AI RMF de NIST pide líneas de comunicación y responsabilidades claras, distingue funciones humanas en configuraciones humano-IA y asigna a la dirección responsabilidad por decisiones de riesgo. La matriz convierte esas expectativas en permisos verificables.
Un recorrido de fallo, no otro recorrido feliz
Ejemplo estrictamente ilustrativo: un agente prepara una respuesta a una disputa de factura. Encuentra el documento, pero el monto del ERP difiere del PDF. Una demo podría elegir la fuente más reciente y continuar. La prueba operativa inyecta el conflicto deliberadamente.
El comportamiento aprobado sería: marcar el objeto como excepción de datos; no modificar el ERP; adjuntar ambas referencias permitidas; asignar un código de razón; enrutar al dueño de cuentas por pagar; y mantener un reloj de escalamiento. Si el operador resuelve el conflicto, el registro conserva quién decidió, con qué evidencia y qué versión de política se aplicó. Si la cola supera su umbral interno, el servicio pasa al modo acordado: solo clasificación, sin acciones posteriores.
Este ejercicio revela más que cien respuestas agradables. Comprueba el límite, la transferencia de contexto, la autoridad humana y la recuperación.
Criterio de aprobación y evidencia mínima
Un agente aprueba la revisión únicamente cuando las ocho puertas tienen evidencia vigente y no existe una acción irreversible sin aprobador identificado. Además, el dueño del proceso debe aceptar explícitamente el riesgo residual: los fallos que pueden ocurrir aun con controles.
Para cada versión conserve como mínimo: conjunto y fecha de evaluación; configuración y herramientas habilitadas; resultados por tipo de caso, no solo promedio; excepciones conocidas; matriz de derechos; runbook; dueños; aprobaciones; y decisión de lanzar, limitar o rechazar. Evite guardar indiscriminadamente datos sensibles o conversaciones completas: la evidencia debe ser suficiente y proporcionada.
Cómo se observa en Quantum
Quantum Automation Center puede representar el agente en el catálogo, mostrar estado y línea de tiempo de ejecuciones, asociar artefactos y logs permitidos, y aplicar permisos o aprobación humana. El valor operativo surge al conectar esos elementos: desde un objeto afectado se navega a la decisión, la excepción y el responsable. Consulte el patrón de agentes de IA y la superficie del Automation Center.
La plataforma no sustituye la decisión organizacional. El área usuaria todavía debe definir autoridad; tecnología, el modo degradado; seguridad, los accesos; y operaciones, la respuesta a incidentes.
El contrapunto: ocho puertas pueden ahogar la experimentación
Es cierto si se aplican con el mismo peso a todo. Un asistente que resume documentos internos para revisión no necesita el mismo paquete que un agente capaz de liberar un pago. Una revisión desproporcionada desplaza el riesgo en lugar de reducirlo: equipos crean pilotos paralelos para evitarla.
La solución es variar la profundidad, no eliminar las puertas. Un caso reversible puede tener pruebas ligeras y soporte en horario hábil. Una acción financiera exige separación de autoridad, evidencia más fuerte y respuesta definida. En ambos casos debe existir dueño y botón de pausa.
Cuándo no usar un agente en producción
No lo promueva cuando el proceso es determinístico y una regla o automatización convencional ofrece un resultado más comprobable. Tampoco cuando la organización no dispone de personas para revisar la cola, cuando las fuentes no tienen derechos o calidad suficiente, o cuando nadie acepta la responsabilidad del resultado.
La decisión correcta puede ser mantener el agente como herramienta asistiva: propone, pero no actúa. Si incluso una propuesta podría inducir una decisión grave sin revisión competente, detenga el caso y corrija primero el diseño del proceso.
La reunión que decide de verdad
Reúna al dueño de negocio, operación, seguridad y equipo técnico. Elija una decisión importante y un fallo plausible. Recorra quién detecta, quién recibe, qué evidencia ve, qué puede hacer, cuándo escala y quién autoriza reanudar. Si aparece una frase como “el equipo lo miraría”, conviértala en nombre, cola, permiso y runbook. Esa precisión, no la fluidez de la demo, marca el paso de piloto a operación.
Sources
- Google SRE — Production Readiness Reviews — sre.google
- AWS Well-Architected — Ensure a consistent review of operational readiness — aws.amazon.com
- NIST AI Risk Management Framework Core — nist.gov
Temas del artículo
