Un canary de agentes debe limitar consecuencias, no solo tráfico
Por Equipo Quantum Developers
Resumir:
Un canary de agentes reduce riesgo solo cuando limita la consecuencia empresarial y la autoridad de acción de una cohorte comparable, no cuando envía un porcentaje aleatorio de casos a una versión nueva. Dos solicitudes técnicamente similares pueden tener exposiciones radicalmente distintas: una recomendación descartable y una modificación financiera no pertenecen al mismo experimento.
El objeto del canary es una conducta versionada
Un agente no cambia solo con código. Puede cambiar el modelo, el prompt, una herramienta, una política, una fuente de datos o los permisos. El release_candidate debe identificar la combinación exacta y evitar que otro cambio simultáneo contamine la lectura.
El capítulo de Google SRE sobre canarying define el canary como un despliegue parcial y limitado en el tiempo que se compara con un control para decidir si continuar. También advierte sobre aislamiento imperfecto y contaminación de señales. Para agentes, la unidad parcial debe incluir población, conducta y autoridad, no solo infraestructura.
Segmente primero por consecuencia y reversibilidad
| Cohorte | Conducta permitida | Consecuencia máxima | Salida requerida |
|---|---|---|---|
| Sombra | observar y proponer sin mostrar ni escribir | ninguna acción externa | comparación con decisión vigente |
| Asistiva | mostrar recomendación a operador | reversible por descarte | aceptación, edición y razón |
| Escritura acotada | ejecutar acciones idempotentes y compensables | impacto limitado por política | confirmación y prueba de compensación |
| Sensible | preparar, nunca autorizar en solitario | financiera, legal o de derechos | aprobación humana y evidencia reforzada |
Después subdivida por tipo de objeto, fuente, complejidad, canal, jurisdicción y capacidad de revisión. Una muestra aleatoria puede concentrar casos fáciles o mezclar consecuencias que exigen criterios distintos.
La cohorte de control conserva la versión anterior o la decisión humana acordada. Debe recibir una población comparable y compartir la misma ventana de observación. Si el canary actúa y el control solo simula, documente esa diferencia al interpretar resultados.
Contrato de cohorte
Cada cohorte necesita:
- cohort_id, criterio de inclusión y exclusiones;
- versiones de modelo, prompt, política, herramienta y datos;
- acción máxima y sistemas accesibles;
- control, ventana y población comparable;
- métricas técnicas, de decisión, de consecuencia y evidencia;
- stop_conditions, rollback_owner y canal de incidente;
- estado: preparado, activo, detenido, promovido o retirado;
- referencias de decisiones y resultados.
El NIST AI RMF organiza la gestión en Govern, Map, Measure y Manage. Un canary útil mapea contexto y personas afectadas, mide comportamiento y riesgo y asigna acciones de respuesta. No convierta la tasa de acierto en el único criterio.
Cuatro compuertas antes de ampliar
Calidad de decisión: la salida respeta políticas, razones y límites; los desacuerdos se clasifican. Seguridad de acción: no hubo autoridad excedida, duplicación no controlada ni compensación fallida. Salud operativa: colas, escalaciones y revisores absorben la carga. Integridad de evidencia: entradas, versiones, aprobaciones y resultados pueden reconstruirse.
Promueva solo la dimensión evaluada. Superar sombra autoriza una recomendación asistiva; no autoriza escritura. Superar una escritura acotada para una fuente no habilita otra fuente o una población más material.
Gates de detención y rollback
Detenga ante una acción no autorizada, pérdida de evidencia requerida, resultado material fuera de política, duplicado con efecto, fallo de compensación, cola sin dueño o incapacidad para distinguir canary y control. No espere a que un promedio agregado se deteriore.
Rollback de un agente puede exigir más que reinstalar código:
- retirar permisos de acción o desactivar la política;
- detener nuevas asignaciones y preservar trabajo en curso;
- identificar acciones ya emitidas por decision_id;
- compensar las que tengan mecanismo aprobado;
- enrutar casos restantes al modo degradado;
- conservar evidencia y comunicar a responsables.
La guía de AWS sobre revisiones de preparación operativa recomienda una revisión consistente antes de una carga de producción y reutilizar aprendizajes de revisiones previas. Para el canary, eso se traduce en comprobar rollback, observabilidad, soporte y dueños antes de exponer la primera cohorte.
Ejemplo ilustrativo: clasificación de facturas
Este escenario es ilustrativo. Una versión nueva clasifica facturas y propone la cola adecuada. En sombra, procesa objetos duplicados de la corriente vigente y se compara por razón de desacuerdo. Casos con documentos incompletos permanecen excluidos hasta que exista una política.
En modo asistivo, analistas ven la recomendación pero eligen la cola. Se registran aceptación, edición y tiempo de revisión. Solo después, una cohorte de documentos con identidad y regla determinísticas permite una escritura idempotente de clasificación. Ninguna cohorte permite aprobar o publicar pagos.
Un error de ruta activa rollback de permisos, identifica objetos afectados y los devuelve a revisión. El despliegue puede seguir siendo técnicamente saludable y aun así detenerse por consecuencia empresarial.
Medición sin esconder colas pequeñas
Compare por clase de razón y nivel de riesgo: desacuerdo con control, edición humana, escalamiento correcto, acción revertida, evidencia incompleta, reapertura y resultado adverso. Informe denominador y exclusiones. Una tasa total puede ocultar que la cohorte sensible casi no tuvo casos o que una fuente importante quedó fuera.
Use medidas absolutas para condiciones inaceptables y comparativas para tendencias. Google SRE señala que canary y control pueden verse afectados juntos; por eso una comparación relativa no sustituye límites absolutos.
Cómo representarlo en Quantum
En Quantum Automation Center, el catálogo puede identificar cada versión; permisos limitan herramientas y acciones; objetos de negocio asignan cohortes; ejecuciones, líneas de tiempo, artefactos y logs conservan evidencia; aprobación humana protege transiciones sensibles. Analíticas separan canary y control por resultado. La documentación de seguridad y gobernanza ubica permisos y trazabilidad dentro del control operativo.
El rollout debe ser un objeto gobernado con dueño, estado, gates y rollback, no una etiqueta informal en el nombre del agente.
El contrapunto: segmentar por riesgo introduce sesgo
Segmentar por riesgo puede sesgar la muestra y prolongar el despliegue; el plan debe declarar ese sesgo, mantener un control comparable y ampliar exposición solo cuando exista evidencia suficiente para el siguiente tipo de consecuencia. Una cohorte fácil prueba su propio contrato, no el universo.
La velocidad mejora al preparar cohortes y gates antes del release, no al mezclar riesgos para obtener volumen. Si una población rara necesita más observación, mantenga asistencia humana.
Cuándo no usar un canary en producción
No exponga una conducta que pueda causar daño irreversible, carezca de rollback o compensación, ocurra con frecuencia insuficiente para evaluar el canary o requiera consentimiento que la prueba no tiene. Use datos sintéticos, replay controlado, sombra o revisión previa según el caso.
Tampoco use canary para evitar una evaluación obligatoria de seguridad, privacidad o cumplimiento. Es una capa de evidencia de despliegue, no una exención.
La prueba de promoción
Antes de ampliar, nombre la consecuencia máxima de la siguiente cohorte, muestre el control comparable, los gates aprobados y una demostración de rollback. Si la justificación se resume en “el porcentaje anterior salió bien”, todavía no existe un canary gobernado para agentes.
Sources
- Google SRE Workbook: Canarying Releases — sre.google
- NIST AI Risk Management Framework Core — nist.gov
- AWS Well-Architected — Ensure a consistent review of operational readiness — aws.amazon.com
Temas del artículo
