IA y Flujos Agénticos
Diseña la autoridad antes de dar herramientas al agente.
Diseño agentes que razonan sobre el contexto de negocio, usan herramientas acotadas, se detienen cuando la ambigüedad pasa a tener consecuencias y hacen que cada acción sea explicable y auditable.
Una solicitud, de un email no estructurado a un registro confirmado en el CRM. Selecciona un paso para ver qué lee el agente, qué herramienta puede usar, cuánta autoridad tiene—y qué deja en la traza de auditoría.
- Leer y razonar
- Borrador · reversible
- Autoridad humana
- Registro
Identificar los productos
Empareja dos líneas con el catálogo; una referencia podría corresponder a dos productos.
- Lee
- Catálogo, referencias cruzadas e historial de pedidos del cliente
- Herramienta
matchProducts- Autoridad
- Recomendar
- Deja en la auditoría
- Emparejamiento por línea, alternativas, marca de ambigüedad
No es “añadir un chatbot”. Es un componente de razonamiento acotado dentro de un proceso real.
Trato la IA como un participante más del proceso operativo: lee el contexto que se le da, usa las herramientas que tiene permitidas, se detiene donde empieza la consecuencia y deja un rastro que una persona puede seguir.
Añadir un chatbot junto al CRMDar a un modelo acceso sin restricciones a las APIUsar una puntuación de confianza como permisoSuponer que la IA puede reparar datos fragmentadosAutomatizar todas las decisionesDejar que los prompts definan el gobiernoTratar una demo como arquitectura de producción
- Tarea de negocioEl trabajo real que el agente ayuda a completar—y qué significa “terminado”.
- ContextoContexto relevante, fiable y actual, ensamblado—no volcado.
- Acceso a herramientasSolo las acciones que la tarea necesita, cada una tras un contrato.
- AutoridadLeer, recomendar, borrador, ejecutar, aprobación o prohibido—por acción.
- AmbigüedadRecuperar, preguntar, escalar o detenerse—decidido antes de que ocurra.
- RevisiónEl juicio humano, situado donde las consecuencias son reales.
- EvidenciaCada recomendación lleva sus fuentes y su incertidumbre.
- EvaluaciónPuntuada por dimensión sobre un conjunto fijo—nunca una única cifra de precisión.
- AlternativaUn camino definido cuando falla el agente, una herramienta o un modelo.
- ResultadosMedidos como resultados del proceso, con un responsable de negocio.
- 01La confianza no es autoridad.
Una puntuación dice cuán seguro está el modelo, no qué puede hacer.
Confianza frente a consecuencia - 02El agente debe saber qué tiene permitido hacer antes de decidir qué quiere hacer.
La autoridad se diseña por acción, antes de que existan las herramientas.
Modelo de autoridad - 03La IA no puede arreglar una identidad poco fiable.
Puede ordenar candidatos; los confirma una clave de confianza o una persona.
Modelo de contexto - 04Human-in-the-loop es una decisión de diseño, no un parche para una IA deficiente.
La revisión se sitúa donde está la consecuencia, incluso con confianza alta.
Human-in-the-loop
De la tarea de negocio a la mejora segura.
Diez movimientos desde el trabajo que el agente debe ayudar a completar hasta el ciclo que lo mejora sin cambiar su comportamiento en silencio. Los prompts llegan después del cuarto.
01Partir de la tarea de negocio
¿Qué trabajo real debe ayudar a completar el agente?
Una tarea con definición de terminado—no «un asistente».
- Clasificar una solicitud entrante
- Identificar al cliente
- Resumir el contexto de la cuenta
- Preparar un borrador de oferta
- Proponer la siguiente acción
- Clasificar una solicitud de servicio
Sin una tarea no hay nada que evaluar—solo demos
Partir de la tarea de negocio
¿Qué trabajo real debe ayudar a completar el agente?
Una tarea con definición de terminado—no «un asistente».
- Clasificar una solicitud entrante
- Identificar al cliente
- Resumir el contexto de la cuenta
- Preparar un borrador de oferta
- Proponer la siguiente acción
- Clasificar una solicitud de servicio
Definición de la tareaSin una tarea no hay nada que evaluar—solo demos
Definir la superficie de decisión
¿Qué información necesita el agente para razonar bien?
Relevante, fiable y a tiempo—reunida, no volcada.
- Datos estructurados de sistemas
- Texto no estructurado
- Contexto histórico
- Políticas
- Acciones previas
- Intención del usuario
Modelo de contextoMás contexto no siempre es mejor contexto
Definir la autoridad
¿Qué puede hacer el agente?
Por acción, antes de que exista ninguna herramienta.
- Leer
- Recomendar
- Redactar
- Ejecutar
- Requerir aprobación
- Prohibida
Matriz de autoridadEl agente debe saber qué puede hacer antes de decidir qué quiere hacer
Definir las herramientas
¿Qué acciones de sistema se exponen al agente?
Cada herramienta es un contrato, no un endpoint.
- Buscar cuenta
- Crear borrador de oportunidad
- Obtener producto
- Actualizar clasificación
- Enviar notificación
- Solicitar aprobación
Contrato de herramientaUn agente no puede hacer mal uso de una capacidad que nunca se le dio
Definir la respuesta a la duda
¿Qué debe ocurrir cuando el agente no está seguro?
Se decide por acción y por consecuencia.
- Continuar
- Preguntar al usuario
- Buscar más contexto
- Escalar
- Detenerse
Política de ambigüedadLa confianza no es autoridad
Definir la revisión humana
¿Dónde se vuelve obligatorio el criterio humano?
Donde está la consecuencia, no donde el modelo es débil.
- Decisiones con consecuencias
- Acciones irreversibles
- Compromisos financieros
- Comunicación con el cliente
- Coincidencias de baja confianza
Modelo de revisiónLa persona en el circuito es una decisión de diseño, no un parche para una IA mala
Diseñar la ejecución
¿Cómo avanza el agente por el flujo de trabajo?
Una ejecución con estado y puntos de parada.
- Plan
- Uso de herramientas
- Estado intermedio
- Reintentos
- Puntos de parada
- Escalado
Flujo del agenteUn buen agente sabe cuándo parar
Definir evidencia y auditoría
¿Puede una persona entender por qué actuó el agente?
La traza se diseña; no se registra por accidente.
- Entrada
- Contexto
- Herramientas usadas
- Recomendación
- Evidencia
- Decisión humana
- Acción final
Modelo de auditoríaUna recomendación sin evidencia pide a los revisores que confíen, no que juzguen
Evaluar
¿Cómo sabemos que el agente es lo bastante bueno?
Puntuado por dimensión sobre un conjunto fijo—nunca con un único número.
- Conjunto de evaluación
- Resultado esperado
- Precisión de extracción
- Emparejamiento de entidades
- Corrección de las acciones
- Calidad del escalado
- Falsa autonomía
- Latencia y coste
Marco de evaluaciónUna precisión agregada esconde el único fallo que importa
Mejorar de forma segura
¿Cómo aprende el agente sin cambiar su comportamiento en silencio?
Cada cambio se versiona y pasa pruebas de regresión.
- Revisión de fallos
- Versionado de prompts y políticas
- Regresión de la evaluación
- Correcciones humanas
- Despliegue controlado
Ciclo de mejoraEditar un prompt es una release
Los síntomas llegan como “la IA se ha equivocado”.
Normalmente hizo lo que nada le impedía hacer. Debajo, nunca se diseñó una tarea, una regla de identidad, un nivel de autoridad o un conjunto de evaluación.
Las solicitudes llegan por email y adjuntos; alguien las vuelve a teclear en el CRM.
Lo que suele faltarUna tarea de entrada definida con un contrato de extracciónEl agente elige un cliente cuando dos cuentas parecen la misma.
Lo que suele faltarUna regla de identidad, y una parada cuando no se cumpleSe confirman resultados de baja confianza porque nada decía lo contrario.
Lo que suele faltarUna política de ambigüedad ligada a la consecuenciaLas credenciales del agente permiten mucho más de lo que su tarea necesita.
Lo que suele faltarUna matriz de autoridad y herramientas de mínimo privilegioLos revisores aprueban lo que propone la IA sin ver por qué lo propuso.
Lo que suele faltarUna ficha de revisión con evidencia e incertidumbreLa política de negocio vive en prompts que nadie versiona.
Lo que suele faltarPolíticas como datos, prompts como configuración versionadaLa calidad se juzga por una buena demo y unas cuantas anécdotas.
Lo que suele faltarUn conjunto de evaluación puntuado por dimensiónNadie puede reconstruir por qué actuó el agente.
Lo que suele faltarUn modelo de auditoría y una traza de ejecución
Entregables que hacen que un agente pueda entrar en un proceso real.
Cada uno responde a una pregunta que una demo nunca tiene que responder.
- Flujo del agente¿Qué pasos, qué actores, dónde se detiene?
- Arquitectura de contexto¿Qué sabe el agente, de qué fuente y con qué frescura?
- Matriz de autoridadLeer, recomendar, borrador, ejecutar, aprobar o prohibir—por acción
- Catálogo y contratos de herramientasEntrada, salida, precondiciones, efecto lateral, reversibilidad
- Modelo de salvaguardas¿Qué se comprueba antes y después de cada acción?
- Modelo de revisión humanaQué ve el revisor y qué provoca cada decisión
- Política de ambigüedadRecuperar, preguntar, escalar o detenerse—¿cuándo?
- Política de confianzaCómo se combinan confianza y consecuencia
- Modelo de evidencia¿Qué fuentes respaldan cada recomendación?
- Modelo de alternativa y escalado¿Qué pasa cuando falla el agente o una herramienta?
- Conjunto de evaluaciónCasos puntuados por dimensión, no una única cifra de precisión
- Traza de auditoríaEntrada, contexto, herramientas, evidencia, decisión, acción
- Modelo de observabilidad¿Qué traza muestra lo que hizo el agente, paso a paso?
- Ciclo de mejoraCómo las correcciones se convierten en casos de evaluación
- Gobierno de versionesPrompts y políticas versionados, con regresión como control de paso
Más contexto no es siempre mejor contexto.
Un agente razona sobre lo que recibe. Seis capas de contexto, leídas de dos maneras: volcadas en un único prompt o ensambladas desde los sistemas que son dueños de cada dato.
El agente razona sobre un contexto tipado, con origen y actual: cada elemento con su clave y su marca de tiempo.
- Relevante
Necesario para esta tarea y este paso—no todo lo que el agente podría leer.
- +Fuente fiable
Del sistema que es dueño del dato, con su clave.
- +Estado actual
Lo bastante fresco para la decisión, con su marca de tiempo.
La IA no puede arreglar una identidad poco fiable. Puede ordenar candidatos. Una clave de confianza—o una persona—los confirma.
Dónde se diseñan la identidad y la autoridad: Datos e Integraciones
Una herramienta es un contrato de arquitectura, no un endpoint de API.
El agente solo puede hacer lo que sus herramientas permiten; por eso cada herramienta declara su propósito, entrada, salida, permisos, precondiciones, efecto lateral, fallo y reversibilidad, y los hace cumplir en código.
approveDiscountUn derecho de decisión comercial. El agente puede ver la política; no puede ejercerla.
createErpCustomerEl alta legal y financiera pasa por el proceso orquestado con validación de finanzas.
mergeAccountsLa autoridad sobre los datos maestros es de los data stewards; el agente solo puede sugerir candidatos.
createOpportunityDraft
Autoridad del agente: EjecutarUna persona confirma después—en la revisión
- Propósito
- Preparar un borrador revisable a partir de datos confirmados
- Entrada
- Clave de la cuenta, líneas de producto, ID de la solicitud de origen
- Salida
- ID del borrador y cada valor con su origen
- Permisos
- Solo crear borradores; ni etapa, ni responsable, ni importe más allá del borrador
- Precondiciones
- Cuenta confirmada o marcada para revisión; solicitud aún sin borrador
- Efecto lateral
- Solo crea un borrador—invisible para pipeline, forecast y cliente
- Fallo
- ID de solicitud duplicado → devuelve el borrador existente; error de validación → se detiene con el motivo
- Reversibilidad
- Totalmente reversible: los borradores caducan si no se aprueban
Los flujos agénticos son procesos con estado
El mismo modelo de ejecución que cualquier orquestación: estados, transiciones válidas, quién mueve cada una—agente, sistema, persona, temporizador—y resultados terminales. Selecciona un estado.
Esperando revisión
Una persona tiene la decisión; el borrador y la evidencia están listos.
- ConfirmadaAprobada (quizá con ediciones)Persona
- RechazadaRechazada con un código de motivoPersona
- Contexto listoEl revisor pide más contextoPersona
Se llega desde Razonando, Escalada.
La máquina de estados de ejecución que hay detrás: Automatización
Human-in-the-loop es una decisión de diseño, no un parche para una IA deficiente.
El revisor ve qué cree el agente, por qué, la evidencia de origen, la incertidumbre y exactamente qué hará la aprobación; y cada decisión queda registrada con su motivo.
RFQ de un distribuidor · tres líneas
Es una RFQ de un distribuidor existente para dos productos conocidos y un probable sustituto.
| Valor | Confianza | Evidencia |
|---|---|---|
| ClienteCuenta de distribuidor · entidad regional | Alta | El dominio y la firma del remitente coinciden con la cuenta; cuatro RFQ previas de este contacto |
| Línea 1Producto A-100 × 200 | Alta | Referencia exacta del catálogo en el adjunto |
| Línea 2Producto B-220 × 50 | Alta | Referencia cruzada a un código de la competencia, comprado dos veces el año pasado |
| Línea 3Producto C-310X × 20 | Baja | “C310” coincide con dos productos; la variante X se pidió una vez |
Crear una oportunidad en Cualificada para el responsable de la cuenta, con tres líneas; la línea 3 como C-310 salvo que se edite. No se envía ningún email.
- Código de motivo
- Variante de producto incorrecta
- Qué ocurre
- La línea 3 pasa a C-310X; se confirma el borrador editado.
- Qué enseña
- La corrección se convierte en un caso de evaluación etiquetado para el emparejamiento de productos.
- Responsabilidad
Una persona con nombre tomó la decisión con consecuencias, sobre evidencia registrada.
- Datos de aprendizaje
Cada edición y cada rechazo, con su código de motivo, es un ejemplo etiquetado.
- Auditabilidad
Cualquiera puede ver qué propuso el agente y qué cambió la persona.
La confianza no es autoridad.
La confianza dice cuán seguro está el modelo. La consecuencia dice qué pasa si se equivoca. Elige una acción y mueve su confianza: en la fila de consecuencia alta, ninguna puntuación llega a “ejecutar”.
Inseguro y con consecuencias: detenerse y entregar todo lo reunido.
Seguro, pero con consecuencias: prepararlo perfectamente—confirma una persona.
Conseguir más contexto es barato. Recuperar, preguntar al solicitante o pasarlo a una persona.
Consecuencia baja y confianza alta: actuar, de forma visible y reversible.
Aprobación humana Una confianza alta no concede autoridad: una persona confirma.
Una buena demo no es una evaluación.
La calidad del agente se puntúa sobre un conjunto fijo, por dimensión y contra su propio objetivo; nunca como una única cifra de “precisión de la IA”. Y cada ejecución se puede leer paso a paso.
- Clasificación¿Identificó correctamente la solicitud?97 %objetivo 95 %0
- Extracción¿Capturó los datos obligatorios?95 %objetivo 90 %+4
- Emparejamiento de entidades¿Identificó la cuenta y los productos correctos?93 %objetivo 90 %+4
- Razonamiento¿Eligió el siguiente paso correcto?93 %objetivo 90 %+1
- Uso de herramientas¿Llamó a la herramienta correcta con los argumentos correctos?96 %objetivo 95 %-1
- Autoridad¿Se detuvo cuando debía?98 %objetivo 100 % · bloqueante-2
- Evidencia¿Respaldó su recomendación?96 %objetivo 95 %0
- Resultado¿Terminó el proceso como se esperaba?88 %objetivo 85 %+2
Bloqueada. Una mejor extracción y un mejor emparejamiento no compensan una sola parada omitida: el umbral de autoridad es del 100 %.
Una ejecución, como traza
Hora, actor, acción, evidencia y resultado de cada paso. Las operaciones con IA deben poder inspeccionarse.
- SistemaSolicitud recibidaEvidencia: Mensaje desde el dominio de un distribuidor, un adjuntoResultado: Ejecución R-7F3 creada
- AgenteContexto recuperadoEvidencia: Cuentas candidatas, 12 meses de pedidos, política de RFQ v4Resultado: Contexto listo
- AgenteCuenta emparejadaEvidencia: Dominio + firma + cuatro RFQ previasResultado: Un candidato, confianza alta
- AgenteProducto 1 emparejadoEvidencia: Referencia exacta del catálogoResultado: A-100 × 200
- AgenteProducto 2 ambiguoEvidencia: “C310” coincide con C-310 y C-310XResultado: Marcado; el agente no lo resuelve
- AgenteRevisión humana solicitadaEvidencia: Borrador, evidencia y una pregunta abiertaResultado: Tarea para el responsable de la cuenta
- PersonaProducto corregidoEvidencia: El revisor eligió C-310X · motivo: variante incorrectaResultado: Corrección guardada como caso de evaluación
- SistemaBorrador confirmadoEvidencia: Referencia de aprobación en el registroResultado: Oportunidad creada
Cinco agentes, cada uno con su frontera.
Escenarios B2B sintéticos. El agente de entrada de RFQ es el caso insignia: el diseño del agente detrás del laboratorio, la arquitectura de referencia y el caso de proceso ya publicados, a los que enlaza en lugar de repetirlos.
- Caso 01Caso seleccionadoAutoridad, herramientas y confirmación humana
Diseñar un agente de entrada de RFQ asistido por IA
Las RFQ llegan como emails de texto libre y adjuntos, y se espera que un agente “las gestione”—sin que nadie haya dicho qué puede hacer.
¿Cuándo es fiable un emparejamiento de cliente, qué pasa con un producto ambiguo—y qué no puede hacer nunca el agente, por muy seguro que esté?
BuzónAgente de IACRMCatálogo de productosArquitectura de ProcesosArquitectura de Sistemas y CRM - Caso 02Ensamblado de contexto, hecho frente a inferencia
Preparar el contexto de la cuenta antes de una visita comercial
Los comerciales preparan las visitas abriendo seis pantallas—o no las preparan—y se propone un resumen con IA que puede inventarse lo que no encuentra.
¿Qué fuentes son de referencia, qué frescura deben tener—y cómo separa el informe los hechos de las inferencias?
CRMERPPlataforma de datosCalendarioRevenue OperationsDatos e Integraciones - Caso 03Taxonomía, enrutamiento e intención mixta
Convertir el email comercial en trabajo estructurado
Un buzón comercial compartido mezcla RFQ, consultas de precio, reclamaciones, preguntas técnicas, leads y consultas de pedido—y el tiempo de respuesta depende de quién mire primero.
¿Qué clases pueden enrutarse automáticamente con seguridad, qué pasa con la intención mixta—y puede el agente crear tareas o enviar respuestas?
BuzónAgente de IACRMService deskArquitectura de ProcesosAutomatización - Caso 04Resumen con evidencia, decide el responsable
Revisión de cuentas asistida por IA, con evidencia
Las revisiones mensuales de cuentas empiezan con los responsables reuniendo cifras; la conversación que sigue tiene poco tiempo y ninguna evidencia compartida.
¿Qué puede preparar el agente para una revisión de rendimiento—y dónde debe detenerse antes del juicio comercial?
Plataforma de datosCRMPlanificaciónRevenue OperationsDatos e Integraciones - Caso 05Sugerir con evidencia, decide el data steward
IA para la calidad de datos sin darle autoridad sobre los datos maestros
El CRM tiene probables cuentas duplicadas, nombres incoherentes y clasificaciones que faltan—y una propuesta para que un modelo lo arregle.
¿Dónde ayuda la IA a la calidad de datos—y por qué fusionar, renombrar y reclasificar debe seguir en manos de una persona?
CRMERPPlataforma de datosCola del data stewardDatos e IntegracionesArquitectura de Sistemas y CRM
Toda petición de IA tiene una segunda capa.
La petición visible es donde empieza el diseño, no donde termina.
“Añade un asistente de IA al CRM.”
Un panel de chat que responde preguntas sobre cualquier registro.
4 de 5 preguntas a la vista
“Responder a todo” no tiene definición de terminado y no se puede evaluar.
El proceso define la tarea. Los sistemas guardan la verdad. El agente trabaja entre ambos.
IA y Flujos Agénticos
- Arquitectura de Procesos
El proceso define la tarea, los derechos de decisión y los puntos de revisión dentro de los que trabaja el agente.
- Arquitectura de Sistemas y CRM
Los sistemas de registro son dueños de la identidad y del estado; el agente los lee y solo escribe mediante herramientas acotadas.
- Datos e Integraciones
El contexto solo es tan bueno como su fuente, su clave y su frescura—la IA no puede arreglar una identidad poco fiable.
- Automatización
Los flujos agénticos son ejecuciones con estado: los mismos estados, guardas, reintentos y recuperación que cualquier orquestación.
- Revenue Operations
La revisión de cuentas y la preparación de visitas convierten señales gobernadas en informes respaldados por evidencia.
- Modelo Operativo Digital
Alguien es responsable del agente tras el go-live: de sus políticas, su evaluación y sus versiones.
Decisiones de arquitectura
Laboratorio, referencia y artículos
Un flujo agéntico no es un modelo con acceso. Es un proceso diseñado con
- Una tarea
- Contexto
- Autoridad
- Herramientas
- Reglas de ambigüedad
- Revisión
- Evidencia
- Evaluación
- Control de versiones
Un buen agente sabe cuándo detenerse.
Diseña la autoridad antes de dar herramientas al agente.
¿Un agente que luce en la demo—y nadie ha decidido qué puede hacer?
- ¿Cuáles de sus acciones son reversibles?
- ¿Qué hace cuando dos clientes parecen el mismo?
- ¿Cómo sabrías que ha empeorado tras un cambio de prompt?