Noventa días para probar un agente, no para prometer autonomía
Por Equipo Quantum Developers
Resumir:
Tesis operativa
Noventa días no son una promesa de despliegue. Son una ventana para reducir incertidumbre en tres tramos: definir y observar, probar sin autonomía y cerrar casos reales. El calendario solo organiza aprendizaje; un agente no avanza a acción productiva hasta que el equipo observe cierres, excepciones resueltas y resultados verificables dentro de su población elegible.
NIST establece que los sistemas de IA deben probarse antes del despliegue y monitorearse en operación, con métricas, límites y condiciones de uso documentadas en el AI RMF Core. Una demo mide comportamiento en ejemplos seleccionados. El programa mide si la organización puede gobernar decisiones cuando datos, personas y dependencias reales intervienen.
Antes del día uno: elegir una pregunta, no un departamento
El patrocinador debe formular una decisión que pueda cambiar al final: ampliar un modo asistido, autorizar una acción reversible, rediseñar el proceso o detener. “Explorar IA en logística” no es una pregunta. “¿Puede el agente clasificar excepciones de embarque con evidencia suficiente para reducir la espera sin aumentar desvíos incorrectos?” sí lo es.
Compare candidatos con cinco filtros:
- resultado observable dentro de la ventana;
- población y fuente identificables;
- acción inicial reversible;
- excepciones con dueño y costo;
- alternativa actual que sirve como referencia.
Elija uno, no una lista. Si varios candidatos comparten una dependencia crítica, se puede probar esa dependencia como entregable, pero no declarar cinco pilotos.
Días 1–30: contrato, línea base y casos cerrados históricos
El primer tramo no construye una interfaz vistosa. Produce el contrato de evidencia:
| Entregable | Pregunta que debe resolver |
|---|---|
| tarjeta de decisión | ¿qué objeto, acción y población están dentro? |
| línea base | ¿cómo funciona hoy y con qué denominadores? |
| resultado de cierre | ¿qué evento confirma éxito, error o daño? |
| catálogo de excepción | ¿qué no puede decidir el agente y quién recibe? |
| contrato de datos | ¿qué fuente, versión, frescura y permiso aplican? |
| límite de acción | ¿qué permanece en recomendación o aprobación? |
| plan de evaluación | ¿qué comparación y cobertura serán suficientes? |
El Magenta Book de HM Treasury distingue evaluación de proceso e impacto y resalta el contrafactual para atribuir cambios. En este tramo, el equipo decide si usará cohorte paralela, introducción escalonada u otra comparación proporcional. No espera al final para escoger la métrica favorable.
Use casos históricos con resultado conocido para descubrir clases, pero no confunda ese ejercicio con producción. Al cierre del día treinta deben existir razón de exclusión, dueño de datos y definición del cierre. Si el resultado no puede observarse, el caso cambia o el programa se detiene.
Días 31–60: sombra, asistencia y prueba de operación
El agente trabaja sobre entradas actuales, primero sin actuar. Cada propuesta se liga al objeto, fuente, versión, regla y resultado posterior. Un revisor no solo marca correcto o incorrecto: registra razón, severidad y si faltó evidencia.
Después de cobertura suficiente en sombra, puede asistir a una persona en una población estrecha. Asistencia significa que el humano conserva decisión y acceso al contexto; no es una aprobación automática disfrazada. El equipo mide:
- cobertura de casos con resultado observable;
- calidad por tipo y consecuencia;
- tiempo y causa de excepción;
- desacuerdo entre agente y revisor;
- evidencia completa por cierre;
- costo técnico y humano por caso;
- cola y antigüedad de revisión.
También prueba fallas: fuente tardía, herramienta no disponible, aprobación sin capacidad y resultado incierto. AWS describe sus Operational Readiness Reviews como un mecanismo basado en preguntas y lecciones de incidentes para eliminar causas conocidas de impacto. Aquí, la revisión usa los hallazgos del propio piloto, no un checklist genérico.
La compuerta del día sesenta no pregunta “¿funcionó el modelo?”. Pregunta si la operación puede detectar, contener y reconstruir una decisión.
Días 61–90: cerrar el ciclo y decidir el siguiente nivel
El último tramo conserva la población para permitir que los casos maduren hasta resultado. La tentación es ampliar para mostrar volumen; resístala. Sin cierre, solo crece el inventario de decisiones no verificadas.
Puede habilitarse una acción reversible y acotada únicamente si ya existe evidencia previa de cierre, aprobación del dueño y rollback probado. El objetivo no es alcanzar autonomía total, sino demostrar la cadena:
entrada → propuesta → revisión o acción → resultado operativo → excepción cerrada → evidencia.
El equipo compara con la línea base, identifica segmentos donde el resultado cambia y calcula costo total. Los beneficios no observados se reportan como hipótesis. Al día noventa hay cuatro decisiones legítimas:
- detener porque la hipótesis o datos fallaron;
- rediseñar y repetir un tramo;
- mantener asistencia porque agrega valor sin justificar autonomía;
- autorizar autonomía limitada para una población probada.
“Escalar” sin población, límite y siguiente compuerta no es una decisión.
Artefacto: tablero 30/30/30
El tablero ejecutivo usa una fila por evidencia:
| Evidencia | 1–30 | 31–60 | 61–90 | Dueño | Decisión |
|---|---|---|---|---|---|
| población | definida y perfilada | observada en vivo | segmento probado | operaciones | mantener o restringir |
| resultado | evento de cierre | cobertura inicial | comparación madura | negocio | valor o no valor |
| riesgo | consecuencias y límites | fallas ensayadas | riesgo residual | control | aceptar o detener |
| operación | dueño y runbook | alerta y escalamiento | recuperación probada | tecnología | listo o no listo |
| economía | línea base y costo | costo por caso | realización observada | finanzas | financiar o cerrar |
No use porcentajes universales. Cada umbral se fija según consecuencia, volumen y capacidad de revisión.
En Quantum Automation Center, el catálogo, estados, cronologías, artefactos, logs, analítica, permisos y aprobaciones pueden reunir la evidencia por ejecución. La plataforma no decide si un resultado es material; el dueño del proceso lo valida.
Métricas de cierre que bloquean la autonomía
Una métrica de cierre aparece después de la acción: factura contabilizada sin reversión, excepción logística resuelta dentro de ventana, cotización aceptada con margen validado o caso de servicio sin reapertura durante el periodo definido. También importa cerrar la excepción: asignada, resuelta, causa registrada y objeto en estado consistente.
Si el programa solo conoce “respuesta generada” o “usuario aceptó sugerencia”, todavía mide producción o proxy. Puede mantener asistencia, pero no justificar acción autónoma irreversible.
El mejor contraargumento
Esperar cierres puede ralentizar procesos cuyo resultado aparece meses después. Un programa puede terminar sin la narrativa ejecutiva de éxito, aunque haya aprendido que los datos son malos o que la revisión cuesta demasiado.
La crítica es válida. Use resultados intermedios solo si una teoría de cambio explica su relación con el cierre y conserve autonomía limitada. El aprendizaje negativo también es una decisión valiosa: evita financiar una apuesta mayor. Cambiar la ventana para declarar éxito destruye el programa.
Cuándo no usar este enfoque
No use el formato cuando el resultado aparece mucho después de noventa días, el volumen no permite observar una cohorte o una obligación exige actuar sin experimento. Adapte la ventana, use evaluación retrospectiva o implemente el control requerido sin fingir causalidad.
Sí úselo cuando hay casos repetidos, cierre observable y una decisión reversible. La disciplina 30/30/30 no garantiza que el agente llegue a producción; garantiza que, si llega, no será porque el calendario venció.
Sources
Temas del artículo
