El patrón es conocido; los detalles aquí son ilustrativos. Un equipo lanza un agente de prospección y, por prudencia, exige que un comercial apruebe cada correo de primer contacto. En pocas semanas la cola acumula unos cientos de borradores al día, los comerciales los aprueban en lotes entre llamadas y la tasa de edición cae casi a cero. La dirección lo interpreta como prueba de que el agente es preciso. Mientras tanto, un agente de deduplicación, que nadie consideró arriesgado porque "solo limpia datos", fusiona cuentas por su cuenta. Una fusión absorbe una filial en su matriz, reasigna una renovación abierta al responsable equivocado y envía una dirección de facturación modificada a través de la sincronización con facturación. Nadie lo aprobó porque a nadie se le ocurrió poner una puerta ahí.
El equipo puso una puerta a la acción barata y recuperable y dejó libre la cara y difícil de deshacer: puertas colocadas por ansiedad y no por consecuencia.
Los equipos son prudentes con la autonomía. La encuesta de Gartner a 360 líderes de aplicaciones de TI (realizada de mayo a junio de 2025 y publicada en septiembre de 2025) concluyó que, aunque el 75% tenía algún tipo de agente de IA en piloto o en producción, solo el 15% consideraba, probaba o desplegaba agentes totalmente autónomos, solo el 19% confiaba mucho o por completo en la protección contra alucinaciones de sus proveedores y solo el 13% estaba totalmente de acuerdo en que contaba con la gobernanza adecuada. La encuesta de Stack Overflow de junio de 2026 a unos 1.100 desarrolladores y profesionales de tecnología, según informó IT Brief, concluyó que el 63% rara vez o nunca deja que los agentes trabajen sin intervención humana, y el 60% afirmó que los agentes tienen bloqueado hacer cambios no aprobados en los sistemas.
Los compradores quieren menos humanos. La encuesta de Gartner a 632 compradores B2B (realizada de agosto a septiembre de 2024 y publicada en junio de 2025) concluyó que el 61% prefiere una experiencia de compra general sin comerciales y que el 73% evita activamente a los proveedores que envían mensajes irrelevantes. Y quienes aprueban no son revisores fiables por defecto: el estudio global de la Universidad de Melbourne y KPMG, con más de 48.000 personas en 47 países (2025), concluyó que, en el trabajo, el 66% de los empleados confía en los resultados de la IA sin evaluar su precisión y el 56% ha cometido errores en su trabajo por culpa de la IA.
Así que la pregunta no es si mantener a un humano en el bucle. Es dónde aporta el humano un criterio que el sistema no tiene, y dónde es un simple sello de aprobación que frena al comprador y da a la dirección una falsa tranquilidad. Es un problema de sistemas, y no se resuelve con un memorando de políticas ni con un interruptor de "modo de aprobación", porque el riesgo está en la acción, en los datos que toca y en los sistemas que dependen de ella.
Dónde se rompe
Los diseños human-in-the-loop fallan de cinco maneras recurrentes, y cada una deja una puerta que parece control en un diagrama y en producción no controla nada.
Puertas de sello: aprobación sin revisión
Una puerta que se activa cientos de veces al día sobre resultados de baja variación entrena al revisor para hacer clic en aprobar. El registro de aprobación existe; la revisión no ocurrió. Dos campos que la mayoría de los equipos nunca registra lo revelan: review_duration_ms y edit_distance entre el borrador del agente y lo que se envió. Cuando el tiempo de revisión se desploma a segundos y las ediciones tienden a cero mientras la cola crece, la puerta mide la fatiga del revisor, no la calidad del agente. Registrar esos campos forma parte de una práctica más amplia de fiabilidad de agentes y registro de decisiones.
Puertas asignadas a agentes en lugar de a acciones
La mayoría de las plataformas expone la aprobación como un ajuste del agente: supervisado o autónomo. Pero un mismo agente realiza acciones con consecuencias muy distintas. Un agente de renovaciones que actualiza Renewal_Risk__c, redacta un correo de seguimiento y propone un descuento plurianual necesita tres tratamientos diferentes. Un interruptor a nivel de agente obliga a elegir entre poner puerta a todo, lo que produce sellos automáticos, o a nada, lo que deja pasar el descuento.
Irreversibilidad escondida dentro de una acción "segura"
Algunas acciones parecen internas pero disparan efectos secundarios irreversibles. Una fusión de cuentas es difícil de deshacer una vez que los registros hijos, la actividad y la propiedad se han reasignado. Inscribir a alguien en una secuencia parece una actualización de campo, pero programa envíos externos. Closed Won puede disparar un webhook de aprovisionamiento o una sincronización con facturación. Una acción es tan reversible como su efecto posterior menos reversible, lo que obliga a saber qué disparadores, flujos y sincronizaciones están suscritos a cada campo. Un diseño de CRM orientado a eventos hace visibles esos suscriptores en lugar de dejarlos enterrados en automatizaciones activadas por registros.
Aprobaciones que viven fuera del sistema de registro
Un pulgar arriba en un canal de chat es una aprobación que nadie puede auditar: no hay approval_id en la escritura, no hay registro de lo que vio quien aprobó y no hay respuesta a "quién aceptó este descuento" tres meses después. El caso de Air Canada es la versión aleccionadora: en febrero de 2024, el Civil Resolution Tribunal de la Columbia Británica declaró a la aerolínea responsable de una política de reembolsos que el chatbot de su web había descrito mal, y rechazó su argumento de que el chatbot era una entidad separada responsable de sus propios actos. Los compromisos que un agente asume con un cliente son compromisos de la empresa, los haya aprobado alguien o no.
Puertas estáticas que nunca se mueven
Las puertas suelen fijarse una vez, en el lanzamiento, por intuición. Rara vez se endurecen cuando una fuente de datos se degrada y casi nunca se relajan cuando la evidencia muestra que una acción es segura, porque ningún flujo de datos conecta la calidad observada con la ubicación de las puertas.
Arquitectura de referencia
El diseño empieza por la matriz. El coste del error es el daño que causa una acción equivocada: el dinero en juego, quién la ve y si crea un compromiso. La reversibilidad indica si la acción y todos sus efectos posteriores pueden deshacerse antes de que afecte a alguien fuera de la empresa. Cuatro cuadrantes, cuatro puertas:
| Cuadrante | Ejemplos en un stack de ingresos | Puerta |
|---|---|---|
| Coste bajo, reversible | Escrituras de enriquecimiento marcadas como originadas por el agente, creación de tareas, notas de investigación de cuentas, un siguiente paso sugerido, un correo de primer contacto a un nuevo prospecto dentro de plantillas aprobadas y límites de volumen | Autónoma. Registra cada acción y revisa cada semana una muestra de proporción fija |
| Coste alto, reversible | Enrutamiento de leads y cuentas, reasignación de responsable, higiene de etapas de oportunidades, sugerencias de categoría de forecast, pausar una secuencia | Actuar y luego revisar. Se ejecuta de inmediato y entra en una cola de revisión con una ventana para deshacer y reversión masiva por ID de ejecución |
| Coste bajo, difícil de revertir | Fusiones de registros, bajas y supresiones, invitaciones a reuniones a contactos sénior, cerrar un caso de soporte, mensajes a un cliente existente | Aprobar la política. Deciden reglas aprobadas de antemano; todo lo que queda fuera del conjunto de reglas o por debajo de un umbral de confianza escala a una aprobación de un clic |
| Coste alto, difícil de revertir | Precios, descuentos, condiciones de contrato y renovación, créditos y reembolsos, cambios de etapa que disparan facturación o aprovisionamiento, cualquier envío a una cuenta estratégica identificada | Decide un humano. El agente redacta, reúne la evidencia y recomienda; un responsable con nombre aprueba dentro del sistema de registro |
Dos modificadores escalan cualquier acción un nivel: baja confianza o falta de evidencia, y novedad (un segmento o tipo de cuenta con el que el agente nunca fue evaluado).
La reasignación de responsable es el caso típico de actuar y luego revisar: debe ocurrir rápido, y una asignación equivocada puede revertirse si cada cambio queda registrado. El motor de reglas de propiedad cubre las excepciones manuales y el registro de auditoría que hacen real esa ventana para deshacer.
Componentes: cambios en registros del CRM, envíos de formularios y eventos de producto, fuentes de enriquecimiento e intención, correo entrante y datos de calendario.
Contrato con la calidad de datos: cada evento lleva una fuente, una marca de tiempo y un ID de registro canónico. Ningún agente actúa sobre un webhook en bruto.
Componentes: resolución de identidad a una sola cuenta y un solo contacto, comprobaciones de esquema y frescura, una cola de cuarentena.
Contrato con las políticas: el evento llega con una puntuación de calidad de datos. Una puntuación débil es en sí misma una señal de escalado, porque la confianza del agente no puede superar la de sus entradas.
Componentes: un registro de acciones con cada tipo de acción, su clase de riesgo y sus efectos posteriores, un motor de políticas que elige la puerta para cada acción propuesta, y presupuestos y límites de frecuencia por agente. Una tabla de reglas en tu herramienta de flujos de trabajo (por ejemplo n8n o Workato) o un pequeño servicio.
Contrato con agentes y aprobadores: los agentes proponen acciones; nunca las ejecutan directamente. El motor de políticas devuelve execute, execute_and_review, request_approval o block.
Componentes: tareas de aprobación en el CRM o en la superficie de trabajo del comercial, con el borrador, la evidencia y una decisión de un clic; cada escritura lleva el ID de ejecución, la clase de política y el approval_id.
Contrato con la activación: nada sale de la empresa sin una clase de política que lo permita o una aprobación humana registrada.
Componentes: los propios agentes (investigación, prospección, enrutamiento, renovación, forecast) y un proceso de evaluación que puntúa las acciones muestreadas y aprobadas, incluidas las ediciones de los revisores.
Contrato de vuelta con las políticas: la precisión medida, la tasa de edición y el número de incidentes por tipo de acción alimentan las reglas de promoción y degradación.
El registro de acciones es el artefacto que hace funcionar todo lo demás. Basta una fila por tipo de acción:
action_registry: action_type: send_first_touch_email | merge_accounts | propose_discount object, fields: Contact / Account.ParentId / Quote.Discount__c cost_class: low | high reversibility: reversible | hard_to_reverse downstream_effects: [sequence_send, billing_sync, provisioning_webhook] gate: execute | execute_and_review | request_approval | human_only confidence_floor: 0.80 # below this, escalate one level approver_role: owner | manager | deal_desk undo_window_hours: 24 promote_after: evidence rule, e.g. sustained low edit rate over a set sample demote_on: any external incident or a drop in sampled accuracy
Secuencia de construcción
Seis pasos, cada uno con una prueba.
Inventaria acciones, no agentes
Enumera cada acción que puede realizar cada agente y cada automatización, con el objeto, los campos y el canal externo que toca. Hazlo en modo de solo lectura; el playbook de diagnosticar antes de construir explica el método. Prueba: para cualquier mensaje saliente o escritura de campo, puedes nombrar el tipo de acción que lo produjo.
Rastrea los efectos posteriores y clasifica
Para cada acción, enumera los flujos, disparadores, webhooks y sincronizaciones suscritos a los campos que escribe, y después puntúa el coste del error y la reversibilidad usando el efecto posterior menos reversible. Prueba: cada acción tiene un cuadrante y al menos dos personas coinciden en la ubicación de las de coste alto.
Construye el registro y haz pasar cada acción por él
Pon en marcha el registro de acciones y el motor de políticas, y elimina cualquier vía por la que un agente escriba o envíe directamente. Prueba: un agente que intenta ejecutar una acción no registrada queda bloqueado y registrado.
Pon las aprobaciones donde ya trabaja quien aprueba
Muestra el borrador, la evidencia del agente, el motivo de la puerta y la opción de aprobar, editar o rechazar con un clic. Guarda la decisión, review_duration_ms y las ediciones en el registro. Prueba: un auditor puede reconstruir quién aprobó un descuento concreto y qué vio.
Valida las puertas con tu propio historial
Reproduce unos veinte casos pasados por tipo de acción y compara las propuestas del agente con lo que tu equipo hizo realmente. Exigimos el mismo listón a todos los sistemas: 85 por ciento de aciertos en los casos pasados del propio cliente, o no se pone en producción, y las acciones por debajo de ese nivel siguen con puerta. Prueba: cada tipo de acción tiene una precisión medida antes de fijar su puerta.
Escribe las reglas de promoción y degradación
Decide de antemano qué evidencia lleva una acción a una puerta más ligera (precisión sostenida y una tasa de edición baja sobre un número fijo de acciones revisadas) y qué la devuelve (un incidente externo, una caída de la precisión muestreada, una alerta de calidad de datos). Los números que elijas son un punto de partida, no un benchmark. Prueba: las reglas se ejecutan de forma programada y cada cambio de puerta queda registrado con su motivo.
Construir o comprar: compensaciones
La decisión es dónde vive la política y si las aprobaciones son auditables. Las herramientas son ejemplos, no recomendaciones.
| Enfoque | Encaje | Coste de propiedad | Riesgo de fallo |
|---|---|---|---|
| Aprobaciones nativas del CRM (por ejemplo, procesos de aprobación de Salesforce o aprobaciones en flujos de trabajo de HubSpot en torno a agentes nativos del CRM) | Agentes que actúan sobre todo en objetos del CRM, con aprobaciones tipo deal desk sobre presupuestos y descuentos | El más bajo. Usa conocimientos de administración, historial de campos y modelos de permisos que ya tienes | Las puertas suelen fijarse por agente o por objeto, no por acción. Los efectos en herramientas externas y sincronizaciones quedan fuera de la vista |
| Herramienta de flujos de trabajo con pasos human-in-the-loop (por ejemplo, n8n o Workato con pasos de espera de aprobación que publican en Slack o Teams) | Agentes que abarcan enriquecimiento, prospección y CRM, con pocas acciones con puerta | Moderado. Añadir un paso de pausa y aprobación es rápido; el registro y las reglas de promoción hay que construirlos igualmente | Las aprobaciones se desplazan al chat sin un approval_id en la escritura; las puertas se multiplican por flujo y divergen |
| Servicio de políticas propio con un registro de acciones y una API de aprobaciones | Muchos agentes, acciones de cara al cliente o compromisos con consecuencias financieras | El más alto. Tiempo de ingeniería y un responsable con nombre para el registro | El control más coherente; el riesgo es un registro sin gobierno que solo un ingeniero puede modificar |
La mayoría de los equipos acaba con un modelo híbrido: aprobaciones nativas para precios y contratos, y un registro de acciones compartido que cada flujo consulta antes de ejecutar.
Operarlo en producción
Sigue cuatro cifras por tipo de acción: aprobaciones por revisor y día, tiempo mediano de revisión, tasa de edición y precisión muestreada. Un tiempo de revisión que baja mientras sube el volumen indica un sello automático; una tasa de edición que sube indica que el agente o sus datos se están degradando. Sigue también el tiempo desde la propuesta hasta la acción visible para el comprador, porque cada puerta cuesta velocidad.
Cuando salta una alerta de calidad de datos o cae la precisión muestreada, el motor de políticas degrada automáticamente las acciones afectadas: la autónoma pasa a actuar y luego revisar, y actuar y luego revisar pasa a aprobación. Cada escritura lleva un ID de ejecución y una clase de política, de modo que todo lo ejecutado durante el periodo degradado puede localizarse y revertirse en bloque.
Bastan tres frases: cada acción que un agente puede realizar está clasificada según lo que cuesta un error y si se puede deshacer; los precios, los contratos y todo lo que no podemos revertir siguen necesitando la aprobación de una persona con nombre; y las puertas solo se mueven cuando la precisión medida en nuestros propios casos lo justifica.
Dónde encaja en el sistema
Cada sistema agéntico del stack de ingresos necesita una capa de control explícita. El Signal-Based Outbound Engine ordena las cuentas y redacta mensajes, pero nunca envía sin aprobación. Speed-to-Lead redacta y enruta respuestas a consultas entrantes; requiere aprobación para enviar salvo que cambies ese límite por escrito. El Handoff Orchestrator sigue y escala los traspasos; nunca cambia por sí solo el propietario de una cuenta. El Pipeline Hygiene Sentinel señala registros estancados sin editar los negocios, mientras que el Forecast Assistant informa de lo que dicen los registros sin ajustar la cifra. Renewal Radar escala el riesgo y programa acciones sin comprometer al equipo a descuentos o concesiones. Estos límites de producto muestran dónde termina la autonomía; la matriz anterior es un marco de diseño propuesto, no permiso para saltarse esos límites. El mapa completo está en la página de sistemas.
La misma matriz explica los dos debates sobre prospección. Pasar de secuencias a agentes con autonomía acotada es una cuestión de qué acciones de prospección están en el cuadrante autónomo, y el scorecard de preparación por etapa para SDR de IA es una cuestión de qué etapas de la conversación se lo han ganado. Ninguno funciona sin la base de datos descrita en por qué la IA en RevOps necesita primero los cimientos.
Quién es responsable del registro y de las reglas de promoción es una cuestión organizativa; el árbol de decisión GTM engineer vs. RevOps vs. growth engineer ayuda a tomar esa decisión. En un modelo de forward-deployed engineering, el registro se construye primero a partir del propio historial de acciones del cliente, de modo que las puertas reflejan los riesgos que el equipo asume de verdad y no los que presupone la configuración por defecto de un proveedor.
Fuentes: Gartner, Gartner Survey Finds Just 15% of IT Application Leaders Are Considering, Piloting, or Deploying Fully Autonomous AI Agents (360 líderes de aplicaciones de TI, de mayo a junio de 2025; publicado en septiembre de 2025). Stack Overflow, encuesta sobre agentes de IA en el trabajo (unos 1.100 desarrolladores y profesionales de tecnología de 177 países, publicada en junio de 2026, según informó IT Brief). Gartner, Gartner Sales Survey Finds 61% of B2B Buyers Prefer a Rep-Free Buying Experience (632 compradores B2B, de agosto a septiembre de 2024; publicado en junio de 2025). Universidad de Melbourne y KPMG, Trust, Attitudes and Use of Artificial Intelligence: A Global Study 2025 (más de 48.000 personas en 47 países, de noviembre de 2024 a enero de 2025). Civil Resolution Tribunal de la Columbia Británica, Moffatt v. Air Canada, 2024 BCCRT 149 (febrero de 2024), según el resumen de Manatt.
