11 de julio de 20267 min lectura

Una demo aprobada cubre solo una de siete compuertas de producción

QD

Por Equipo Quantum Developers

Siete fichas alineadas frente a una pantalla de proceso: seis verdes con marca de verificación y una azul con flecha.
Compartir

Una demostración puede ejecutar el camino feliz y aun así no estar lista para recibir una sola decisión real. El dato fue escogido, el operador conoce el guion y alguien puede corregir manualmente cualquier sorpresa fuera de cámara. Por eso una demo aprobada cubre solo una de siete compuertas: producción requiere evidencia de valor, datos, comportamiento, autoridad, seguridad, operación y lanzamiento.

El objetivo no es elevar el número de documentos. Es cambiar la pregunta de “¿funciona?” a “¿bajo qué condiciones aceptamos operarlo y quién puede detenerlo?”. El NIST AI Risk Management Framework Core trata gobernanza, mapeo, medición y gestión como funciones continuas, e insiste en documentar alcance, supervisión humana y riesgos de componentes. Un video de la interfaz no responde a esas obligaciones operativas.

El paquete de aceptación

El paquete debe tener un índice único. Cada compuerta apunta a artefactos versionados, un responsable y una decisión de salida. “No aplica” es válido solo si alguien explica por qué y acepta el riesgo residual.

Compuerta Pregunta de aceptación Evidencia mínima de salida
1. Resultado y dueño ¿Qué decisión o tarea mejora y quién responde por el resultado? Alcance, línea base, dueño y criterio de éxito
2. Datos y derechos ¿La entrada es válida, vigente y autorizada para este uso? Contrato, calidad, linaje, retención y acceso
3. Comportamiento ¿Cumple el contrato fuera del guion de la demo? Evaluaciones, casos adversos, límites y versión
4. Autoridad ¿Qué puede informar, recomendar, ejecutar o escalar? Matriz de decisiones, aprobaciones y prohibiciones
5. Integración y seguridad ¿Puede producir efectos duplicados, indebidos o irreversibles? Permisos, idempotencia, secretos, reversión y prueba
6. Operación ¿Quién observa, atiende y recupera el servicio? Métricas, alertas, runbooks, soporte y relevo
7. Lanzamiento ¿Cómo se expone, detiene y evalúa con tráfico real? Plan gradual, dueño de lanzamiento, rollback y cierre

Las compuertas son dependientes, no una lista para marcar al final. Un hallazgo de datos puede cambiar la evaluación de comportamiento; un límite de autoridad puede exigir otra integración; un escenario de recuperación puede revelar que el objetivo de negocio no tolera la latencia humana.

Compuerta 1: resultado, cohorte y responsabilidad

Defina el objeto de negocio y la decisión concreta. “Ayudar a finanzas” no basta; “clasificar excepciones de conciliación para que un analista decida” sí establece una frontera verificable. Documente la cohorte incluida, la línea base comparable y las condiciones que invalidan la comparación. No invente un porcentaje de ahorro antes de observar resultados.

La salida debe tener un dueño de negocio que pueda aceptar calidad y consecuencias, no solo un patrocinador del presupuesto. Si nadie puede explicar qué resultado compensa el riesgo y el costo operativo, el agente todavía es una demostración tecnológica.

Compuerta 2: contrato de datos y derechos de uso

Enumere cada fuente, identidad, esquema, momento de observación, expectativa de frescura, finalidad permitida, acceso y regla de rechazo. Pruebe ausencia, duplicado, cambio de formato y dato fuera de alcance. Una captura de datos limpios demuestra presentación, no resiliencia.

La salida incluye una decisión sobre retención y evidencia. Guardar todo “por si acaso” puede contradecir la finalidad autorizada; guardar solo la respuesta final impide explicar una decisión. El paquete debe indicar qué se conserva, dónde y quién puede consultarlo.

Compuerta 3: contrato de comportamiento

Especifique formato, hechos que debe citar, restricciones determinísticas, acciones prohibidas y respuesta esperada cuando no sabe. Evalúe casos representativos y adversos; mantenga separado el conjunto usado para ajustar del usado para aceptar. Registre modelo, instrucciones, herramientas y política, porque “el mismo agente” deja de ser una identidad útil cuando cualquiera cambia.

La compuerta no exige perfección. Exige límites conocidos y una regla para enviar casos inciertos a revisión. Un promedio aceptable no compensa una clase pequeña de errores con daño alto.

Compuerta 4: derechos de decisión

Construya una matriz de verbos: leer, resumir, recomendar, crear borrador, enviar, modificar, comprometer fondos, cancelar y aprobar. Para cada uno, indique alcance, condición, aprobador y evidencia. La supervisión humana solo es real si la persona tiene contexto, tiempo y autoridad para detener la acción.

La salida debe probar que el agente no puede saltar del verbo autorizado al efecto final. Un prompt que dice “pida permiso” no reemplaza un permiso técnico ni una compuerta de política.

Compuerta 5: integración, seguridad y reversibilidad

Revise el mínimo privilegio, aislamiento de secretos, validación de parámetros, límites de herramientas, idempotencia y estado remoto. Pruebe qué ocurre cuando la respuesta se pierde después de una escritura. Diseñe compensación para efectos reversibles y aprobación previa para los que no lo sean.

Incluya dependencias externas y su modo degradado. Si una herramienta crítica no responde, el agente debe detener, poner en cola o cambiar a solo lectura según una política visible; no improvisar otra ruta.

Compuerta 6: operabilidad

La revisión de preparación operativa de AWS propone validar arquitectura, procesos, gestión de eventos y calidad antes del lanzamiento, y volver a revisar durante el ciclo de vida. Para el agente, entregue paneles, alertas accionables, clases de falla, playbooks, contactos, relevo y capacidad de soporte.

Ejecute al menos un ejercicio de contención y recuperación por modo relevante. La salida no es que la alerta llegó; es que un responsable interpretó evidencia, detuvo el efecto correcto y verificó la recuperación.

Compuerta 7: lanzamiento y salida

El capítulo de Google SRE sobre lanzamientos confiables describe una función de coordinación y listas de lanzamiento que trasladan conocimiento de confiabilidad al producto. Para un agente, nombre una persona con autoridad para avanzar, pausar o revertir, y defina la exposición gradual mediante cohortes observables.

El plan debe incluir modo sombra cuando sea útil, asistencia humana antes de autonomía y una regla de rollback vinculada a señales, no a sensaciones. También necesita una fecha de revisión: aceptar producción no significa aceptar para siempre.

Manifiesto de evidencia

El índice del paquete puede ser pequeño si es preciso:

  • identidad y versión del agente;
  • objeto, cohorte y dueño de negocio;
  • contrato y evaluación de datos;
  • reporte de comportamiento y límites;
  • matriz de decisiones y permisos;
  • arquitectura, dependencias y reversión;
  • paneles, alertas, runbooks y soporte;
  • acta de lanzamiento, excepciones y firmantes.

Cada artefacto debe tener versión, propietario, fecha y relación con la compuerta. Una presentación que copia conclusiones sin enlazar evidencia no es el paquete.

En Quantum Automation Center, el manifiesto puede conectar catálogo, versión, estado de ejecución, línea de tiempo, artefactos, logs, permisos y aprobaciones. La documentación del Automation Center muestra las superficies de gobierno y observabilidad que ayudan a conservar esa relación. El veredicto sigue perteneciendo a los dueños de las compuertas, no a la interfaz.

El contrapunto: las compuertas pueden frenar el aprendizaje

Aplicar el mismo peso a un asistente interno y a un agente que compromete dinero produce teatro de control. La solución es dimensionar evidencia por impacto, reversibilidad y alcance. Una compuerta puede declarar no-aplicabilidad o una evidencia ligera, pero no desaparecer sin decisión. Así el equipo conserva velocidad y deja visible qué supuesto está aceptando.

Cuándo no usar el paquete completo

No lo use para una exploración aislada sin usuarios, datos reales, persistencia ni acciones externas. En ese caso bastan un objetivo, límites de datos y registro de aprendizaje. Tampoco replique controles certificados de una herramienta determinística solo para llenar casillas; enlace la evidencia existente.

Sí úselo cuando el piloto vaya a tocar decisiones reales. La pregunta final no es si la demo impresionó. Es si las siete personas o funciones responsables pueden señalar evidencia, aceptar el riesgo residual y detener el agente cuando esa evidencia deje de ser válida.

Sources