La respuesta corta
Un agente de IA no debería decidir por sí solo si una propuesta es válida y ejecutarla a continuación. En procesos empresariales conviene separar cuatro funciones: el agente interpreta y propone; código determinista comprueba reglas y datos actuales; una persona revisa las excepciones; y un componente limitado ejecuta la acción aprobada.
AWS publicó el 14 de septiembre de 2026 una arquitectura de referencia que aplica este patrón a varios agentes coordinados con Step Functions y Bedrock AgentCore. El ejemplo es específico de AWS, pero la decisión de diseño es más amplia: reservar la IA para el contexto y mantener fuera del modelo los controles que deben producir el mismo resultado ante la misma entrada. El AI RMF de NIST respalda esa disciplina al pedir roles definidos, evaluación documentada, supervisión adecuada y comportamiento seguro ante fallos.
Separa propuesta, validación y acción
La primera frontera es conceptual. Una propuesta generada por IA no es todavía una orden. Puede contener una clasificación, un borrador, una ruta, un importe sugerido o una lista de alternativas, pero debe entrar en el flujo con un estado que deje claro que sigue pendiente de comprobación.
Después llega la validación. En la referencia de AWS, un agente propone alternativas de viaje y una función comprueba disponibilidad, reglas de tarifa y validez de la ruta con datos actuales. La documentación de Step Functions confirma que los agentes pueden invocarse como una tarea dentro de una máquina de estados, de modo que el flujo no necesita entregarles también el control de la orquestación. Para una pyme, el equivalente puede ser comprobar existencias, límites de descuento, estado de un cliente o presencia de campos obligatorios.
- Propuesta: salida flexible que admite interpretación y puede estar incompleta.
- Validación: comprobaciones reproducibles sobre datos, reglas y permisos.
- Decisión: ruta automática de bajo riesgo o excepción para revisión.
- Acción: cambio externo limitado, autorizado y registrado.
Qué debe quedar fuera del modelo
Una regla es buena candidata para código determinista cuando el equipo puede expresarla sin lenguaje ambiguo y necesita el mismo resultado cada vez. Los estados Choice de Step Functions, por ejemplo, evalúan condiciones verdaderas o falsas y dirigen la ejecución por una rama definida. El servicio también recomienda una ruta por defecto para los casos que no cumplen ninguna condición, una idea útil aunque se utilice otra plataforma.
No hace falta convertir toda la política de negocio en un árbol enorme. Basta con sacar del modelo las restricciones que protegen dinero, datos, clientes o continuidad operativa. NIST pide demostrar que el sistema es válido y fiable en condiciones similares a las de despliegue, documentar las pruebas y preparar un fallo seguro cuando el sistema sale de sus límites. Esa evidencia es más sencilla si las reglas críticas están identificadas y pueden probarse por separado.
- Existencia y estado actual del registro sobre el que se actuará.
- Límites de importe, descuento, horario, territorio o volumen.
- Permiso del usuario, agente o cuenta de servicio para esa acción.
- Campos obligatorios y formatos aceptados por el sistema de destino.
- Casos que siempre requieren aprobación humana o que nunca deben automatizarse.
Diseña la revisión humana como una ruta operativa
Enviar todas las excepciones a una persona no resuelve el problema si esa persona recibe una alerta sin contexto. La revisión necesita la entrada original, la propuesta del agente, las reglas que han fallado, las fuentes consultadas y las acciones disponibles. También debe existir un tiempo máximo y una salida segura si nadie responde.
La arquitectura de AWS utiliza una tarea que espera una señal externa y un tiempo límite para detener el caso o devolverlo a una cola. NIST, por su parte, pide diferenciar los papeles y responsabilidades en configuraciones humano-IA y documentar la supervisión. La traducción práctica es asignar un propietario funcional, no solo un administrador técnico, y definir qué puede aprobar, rechazar o devolver para corrección.
- Motivo exacto del escalado, expresado como regla o ausencia de datos.
- Información mínima para revisar sin reconstruir todo el expediente.
- Opciones limitadas: aprobar, rechazar, corregir o solicitar información.
- Plazo de respuesta y comportamiento seguro al vencer.
- Registro de quién decidió, cuándo y con qué evidencia.
Evita que un reintento duplique la acción
Los flujos reales se reintentan. Una llamada puede agotarse, una respuesta puede perderse o un operador puede volver a lanzar una ejecución. Si el sistema repite una acción sin reconocer que ya se realizó, puede crear dos pedidos, enviar dos comunicaciones, duplicar una reserva o aplicar dos veces un cambio de estado.
El ejemplo de AWS deriva una clave de idempotencia a partir del caso y de la decisión validada, y la entrega a las API que reservan o pagan. La idea no depende del proveedor: cada acción con efecto externo debería aceptar una referencia estable que permita responder que ese resultado ya existe. La clave debe generarse después de validar la propuesta y antes de ejecutar, y debe conservarse junto con el resultado.
- Define qué combinación identifica de forma única la decisión aprobada.
- Guarda la clave antes de llamar al sistema externo.
- Haz que el destino rechace o reutilice una operación ya procesada.
- Distingue un reintento técnico de una nueva decisión de negocio.
- Prueba cortes de red y respuestas tardías antes del piloto real.
Conserva una cadena de evidencia
Una traza útil no es una captura del chat. Debe permitir reconstruir qué recibió el flujo, qué propuso cada agente, qué reglas se evaluaron, qué excepción apareció, quién aprobó y qué contestó el sistema de destino. Step Functions registra transiciones e inputs y outputs por estado; en otras plataformas habrá que construir una evidencia equivalente sin almacenar más datos de los necesarios.
El AI RMF de NIST recomienda procesos de prueba, evaluación, verificación y validación documentados, además de supervisar el comportamiento en producción. El objetivo no es acumular registros indefinidamente. Es poder investigar una incidencia, medir dónde falla el diseño y decidir si la siguiente mejora corresponde al prompt, a los datos, a la regla, al permiso o al proceso.
- Identificador del caso y versión del flujo.
- Entrada autorizada y fuentes utilizadas.
- Propuesta estructurada de cada agente.
- Resultado de cada regla y motivo de la ruta elegida.
- Aprobación humana, clave de idempotencia y respuesta final.
Un piloto de dos semanas
El primer piloto debería actuar sobre un proceso reversible y con una salida correcta que el equipo pueda reconocer. Durante la primera semana se ejecuta en modo sombra: el flujo propone y valida, pero no modifica sistemas externos. Se comparan las propuestas con casos conocidos y se revisan todas las excepciones.
En la segunda semana se habilita una acción limitada, siempre con idempotencia y aprobación para los casos de mayor impacto. La decisión de continuar no depende de que el agente parezca convincente, sino de la proporción de propuestas válidas, excepciones comprensibles, retrabajo, fallos de datos y capacidad de detener el flujo. No se deben fijar objetivos numéricos universales: el umbral depende del riesgo y del proceso.
- Días 1 y 2: mapa del proceso, acciones y consecuencias de error.
- Días 3 y 4: reglas deterministas, datos actuales y casos de prueba.
- Día 5: revisión humana, tiempo límite y parada segura.
- Semana 2: ejecución limitada, reintentos controlados y registro completo.
- Cierre: ampliar, ajustar o detener con evidencia del piloto.
Checklist antes de permitir acciones reales
El patrón no exige una plataforma concreta. Puede implementarse con una máquina de estados, una cola, funciones pequeñas o un orquestador ya existente. Lo importante es que el modelo no controle a la vez la propuesta, la validación y el permiso para actuar.
Antes de ampliar el piloto, tecnología y el responsable del proceso deberían poder responder juntos a esta lista. Si una respuesta depende de confiar en que el agente se comportará bien, el control todavía no está terminado.
- Cada salida del agente tiene un esquema y un estado pendiente de validar.
- Las reglas críticas consultan datos vigentes y se prueban sin invocar al modelo.
- Las excepciones llegan a una persona con contexto, opciones y plazo.
- Las acciones externas usan mínimo privilegio e idempotencia.
- Existe una parada segura y se ha ensayado antes de producción.
- La evidencia permite reconstruir el caso sin depender de la memoria del equipo.
Siguiente paso recomendado
Escoge un proceso donde hoy una persona revise una propuesta antes de actualizar otro sistema. Dibuja cuatro cajas —proponer, validar, revisar y ejecutar— y coloca debajo los datos, reglas, permisos y evidencias de cada una. Esa separación mostrará rápidamente qué parte necesita IA y qué parte ya puede resolverse con automatización convencional.
Si el equipo no puede describir una salida correcta o una parada segura, todavía no necesita más agentes. Necesita aclarar el proceso. AUTOINTELLIA puede ayudar a convertir esa definición en un piloto medible, reversible y conectado con las herramientas reales de la empresa.
