Agente, automatización o software: decida por incertidumbre, repetición y diferenciación
Por Equipo Quantum Developers
Resumir:
La solución correcta depende de tres variables observables —incertidumbre de la decisión, repetición del flujo y diferenciación estratégica—, no de si un agente de IA parece más moderno que una automatización o software convencional. Si esas variables no se describen con evidencia, la selección se convierte en una preferencia de proveedor y el costo de corregirla aparece después en excepciones, mantenimiento y riesgo.
Antes del triángulo: formule el problema completo
No empiece con “necesitamos un agente”. Describa usuario, objeto de negocio, resultado, recorrido, excepciones, sistemas, decisión y consecuencia. El Service Standard de GOV.UK recomienda resolver el problema completo del usuario en lugar de organizar el servicio alrededor de una tecnología o de un fragmento administrativo.
Pregunte también si debe construir algo. Un ajuste de política, una mejora de datos o una función ya disponible en el sistema de registro puede eliminar el problema con menos superficie operativa.
Eje uno: incertidumbre
La incertidumbre es la cantidad de interpretación necesaria para convertir evidencia variable en una propuesta. Es baja cuando entradas y reglas son completas y estables. Es alta cuando hay lenguaje no estructurado, fuentes contradictorias o contexto que cambia.
Un agente puede ayudar a clasificar, resumir, buscar evidencia y proponer bajo incertidumbre. Eso no le concede autoridad. Cuanto mayor sea la consecuencia del error, más estrecho debe ser el límite de acción y más clara la revisión.
Eje dos: repetición
La repetición no es solo volumen. Un proceso es repetible cuando conserva estados, reglas, entradas y salidas similares. Un flujo frecuente pero rediseñado en cada caso no es buen candidato para una automatización rígida; uno menos frecuente pero totalmente estable puede serlo.
La especificación BPMN 2.0 de OMG ofrece vocabulario para tareas, eventos, gateways, errores, escalamiento y compensación. Modelar el proceso revela si existe una secuencia gobernable o solo una colección de decisiones tácitas.
Eje tres: diferenciación
La diferenciación mide si la capacidad codifica una ventaja o un modelo operativo propio que la organización necesita controlar y evolucionar. Alta diferenciación puede justificar software a medida: identidad, estado, reglas, experiencia o integración que forman parte central del negocio.
Baja diferenciación favorece producto existente o automatización sobre interfaces estables. Construir un sistema propio para una función genérica crea mantenimiento sin ventaja.
Matriz de elección primaria
| Incertidumbre | Repetición | Diferenciación | Mecanismo primario |
|---|---|---|---|
| baja | alta | baja | producto existente o automatización determinística |
| baja | alta | alta | software a medida con reglas explícitas |
| alta | suficiente | baja | agente asistivo sobre un flujo gobernado |
| alta | suficiente | alta | software propio con componentes de IA acotados |
| alta | baja | cualquiera | trabajo humano, investigación o rediseño |
| baja | baja | baja | no construir o usar una herramienta simple |
“Suficiente” depende de estabilidad y aprendizaje disponible, no de un umbral universal. La tabla selecciona el núcleo; integraciones, interfaz y controles pueden combinar mecanismos.
Árbol de decisión
- ¿Un producto existente resuelve el recorrido y sus controles? Sí: configure o compre antes de construir.
- ¿La entrada, regla y resultado son determinísticos? Sí: use workflow, integración o RPA según la superficie.
- ¿La ambigüedad puede producir una propuesta verificable? Sí: use un agente asistivo con fuentes y razones.
- ¿La acción es reversible y está acotada por política? Sí: considere autonomía graduada; no: mantenga aprobación.
- ¿La capacidad diferencia al negocio y requiere estado propio? Sí: diseñe software a medida y ubique IA solo donde aporte interpretación.
- ¿No hay dueño, datos ni criterio de resultado? No construya todavía.
El NIST AI RMF pide mapear contexto, responsabilidades, impactos y riesgos antes de medir y gestionar. La elección de IA debe seguir ese análisis, no precederlo.
Ejemplos ilustrativos
Estos ejemplos son ilustrativos, no recomendaciones universales.
Copiar datos entre portales con campos estables: incertidumbre baja y repetición alta. Una integración o automatización determinística es más auditable que un agente interpretando cada pantalla.
Clasificar correos de proveedores y preparar respuesta: incertidumbre moderada, resultado revisable y diferenciación baja. Un agente asistivo puede proponer categoría y borrador; una persona conserva envío en casos sensibles.
Motor de asignación que incorpora reglas comerciales propias y estado histórico: repetición alta y diferenciación alta. El núcleo pertenece a software a medida; un modelo puede explicar texto de entrada, pero no debe esconder las reglas de asignación.
Decisión excepcional sin precedentes ni criterio acordado: incertidumbre alta y repetición baja. Mantenga análisis humano. Automatizar una política inexistente solo vuelve opaca la improvisación.
Compare alternativas con un expediente común
La guía de costos de GAO recomienda línea base técnica, supuestos, datos, alternativas, sensibilidad y actualización con costos reales. Para cada opción documente:
- alcance incluido y excepciones;
- costo de construcción, licencia, integración y cambio;
- operación, revisión, incidentes y mantenimiento;
- dependencia de proveedores, modelos e interfaces;
- riesgo y costo de salida;
- resultado esperado y criterio de detener.
No compare una licencia anual con solo el costo inicial de desarrollo. Tampoco valore un agente sin revisión, evaluación y observabilidad.
Arquitectura híbrida con fronteras explícitas
Una solución frecuente usa software para identidad y estado, automatización para transiciones determinísticas, un agente para ambigüedad y personas para autoridad irreversible. Cada frontera necesita contrato: entradas, salida, razones, timeout, error, reintento y compensación.
El agente no debería convertirse en pegamento universal. Si una API estable puede validar o escribir, úsela. Reserve interpretación para evidencia que realmente la necesita.
Cómo representarlo en Quantum
Quantum Automation Center puede catalogar agentes y automatizaciones sin obligar a que todos compartan motor. Ejecuciones, estados, líneas de tiempo, artefactos y logs permiten observar el recorrido; permisos y aprobación humana limitan acciones; analíticas comparan resultados. La documentación de automatizaciones ubica capacidades heterogéneas bajo un plano de control común.
La decisión arquitectónica permanece fuera del eslogan de plataforma: Quantum observa y gobierna los componentes elegidos.
El contrapunto: casi todo es híbrido
Las soluciones reales suelen ser híbridas y no caben en una sola categoría; el triángulo no prescribe una plataforma única, sino el mecanismo primario y las fronteras entre componentes. Una clasificación híbrida no elimina la decisión: obliga a justificar cada parte.
Si todos los cuadros terminan marcados como “agente más software más RPA”, el análisis no hizo su trabajo. Nombre dónde vive el estado, dónde se aplican reglas, dónde se interpreta ambigüedad y quién autoriza.
Cuándo no usar este árbol
No lo use como sustituto de compra frente a construcción, evaluación legal o diseño del servicio completo. No construya ninguna opción cuando un producto existente resuelve el problema sin diferenciación relevante.
Tampoco decida antes de estabilizar el proceso. Si equipos distintos no acuerdan objeto, resultado o excepción, prototipe el servicio y la política antes de automatizar.
La prueba de elección
Explique la solución sin nombrar tecnología: qué incertidumbre resuelve, qué parte se repite, qué capacidad diferencia, dónde vive el estado y qué acción requiere autoridad. Si esa explicación conduce naturalmente al mecanismo elegido y muestra por qué las alternativas pierden, la arquitectura tiene una razón defendible. Si empieza con “queremos IA”, todavía falta la decisión.
Sources
Temas del artículo
