Una persona pregunta por un pedido y recibe una respuesta. Otra pide resolver una incidencia y el sistema consulta información, crea un caso y comunica el siguiente paso. Ambas experiencias pueden empezar en la misma ventana de chat, pero delegan responsabilidades diferentes.
La autonomía que necesita un producto depende de las decisiones y acciones que conviene delegar, de sus consecuencias y de la evidencia disponible para hacerlo con confianza. Mi punto de partida es definir qué tarea queremos resolver y qué control necesita conservar la persona.
En esta guía propongo una forma de tomar esa decisión desde producto e ingeniería: distinguir la interfaz del funcionamiento, delimitar acciones y evaluar si la autonomía mejora el resultado completo.
1. Chatbot, workflow y agente: qué cambia realmente
Un chatbot describe, ante todo, una experiencia conversacional. Puede responder con reglas, recuperar documentos o servir como interfaz de un sistema capaz de actuar. Ver una caja de mensajes no permite saber cuánta autonomía tiene lo que hay detrás.
Un workflow, o flujo de trabajo, sigue un recorrido definido. Puede incluir IA sin delegar en el modelo la elección general de los pasos.
Un agente puede decidir los pasos, utilizar herramientas y ajustar el recorrido según los resultados. Desde producto, esa flexibilidad necesita un alcance que podamos explicar y supervisar.
La distinción entre recorridos predefinidos y decisiones dinámicas aparece en Building effective agents, de Anthropic. La uso como referencia arquitectónica; los niveles prácticos que propongo a continuación son una herramienta de análisis propia, no una clasificación oficial.
Un flujo y un agente también pueden convivir. Por ejemplo, un agente puede investigar una incidencia dentro de un proceso que exige aprobación antes de modificar un pedido.
2. Define la autonomía por acción
Hablar de un producto “autónomo” en general deja demasiadas preguntas abiertas. Prefiero hacer un inventario de las acciones concretas y decidir el alcance de cada una.
Esta escala es una propuesta para conversar con el equipo; no implica que todos los productos deban avanzar por todos sus niveles.
| Alcance | Qué hace el sistema | Qué conviene definir |
|---|---|---|
| Informar | Explica o recupera información | Fuentes disponibles, acceso y tratamiento de la incertidumbre |
| Proponer | Prepara una respuesta o un plan | Qué debe revisar la persona antes de utilizarlo |
| Ejecutar con aprobación | Prepara una acción y espera confirmación | Qué se va a cambiar, sobre qué elemento y con qué consecuencia |
| Ejecutar dentro de límites | Realiza acciones previamente autorizadas | Condiciones verificables, seguimiento y recuperación |
| Coordinar una tarea | Elige pasos y herramientas dentro de un objetivo | Presupuesto, permisos, condiciones de parada y escalamiento |
La última fila describe cómo se organiza una tarea, no un permiso universal. Un agente que coordina varios pasos puede tener que pedir aprobación en uno de ellos. Del mismo modo, un workflow fijo puede ejecutar automáticamente una acción bien delimitada.
Autonomía para elegir el recorrido y permiso para actuar son decisiones relacionadas, pero diferentes. Documentarlas por separado evita que “puede resolver el caso” se convierta accidentalmente en “puede hacer cualquier cambio”.
3. Un ejemplo: ayudar con un pedido retrasado
Este caso es hipotético y no presenta resultados de un proyecto real.
Imagina una tienda cuyo equipo de soporte recibe consultas sobre entregas. La necesidad del cliente es saber qué ocurre y obtener un siguiente paso útil. El equipo quiere reducir búsquedas repetitivas sin perder control sobre los cambios en los pedidos.
Una primera versión podría recuperar el estado del envío y preparar una respuesta con sus fuentes. Si la información es contradictoria, tendría que reconocerlo y derivar el caso, en lugar de inventar una fecha de entrega.
Más adelante, el sistema podría crear una incidencia interna cuando se cumplan condiciones acordadas. Cambiar la dirección de entrega, cancelar un pedido o prometer una compensación tendrían permisos distintos. Cada acción necesita su propia decisión de producto y una validación con quienes son responsables del proceso.
| Acción del ejemplo | Alcance inicial que propondría | Motivo |
|---|---|---|
| Consultar el seguimiento | Lectura con acceso limitado al pedido autorizado | Obtener contexto sin modificar el pedido |
| Redactar una respuesta | Borrador para revisión | Comprobar claridad y respaldo antes de enviar |
| Crear una incidencia interna | Con aprobación durante el piloto | Evaluar clasificación y evitar duplicados |
| Cambiar datos de entrega | Aprobación explícita de la acción concreta | Un error puede afectar a la entrega y a otras personas |
| Resolver información contradictoria | Escalar a soporte | Falta una base suficiente para actuar |
Si consultar, clasificar y proponer siguen siempre el mismo recorrido, empezaría evaluando un workflow. Si investigar exige elegir fuentes y variar los pasos según cada caso, probaría una parte más flexible. La comparación debería considerar el resultado para el cliente y el trabajo del equipo.
4. Diseña permisos que el sistema pueda hacer cumplir
Una instrucción en el prompt ayuda a expresar la intención, pero los permisos también necesitan controles en las herramientas y servicios que ejecutan las acciones.
OWASP identifica el exceso de funciones, permisos y autonomía como causas de la vulnerabilidad que denomina Excessive Agency. Esa referencia refuerza una pregunta de diseño: ¿estamos dando una capacidad porque la tarea la necesita o porque la integración la incluye?
Para el ejemplo anterior, propondría:
- Acceso acotado: consultar únicamente los pedidos que corresponden a la persona autenticada y a su función.
- Herramientas específicas: separar consultar un envío, crear una incidencia y modificar un pedido, con validaciones propias.
- Confirmación comprensible: mostrar el pedido afectado, el cambio propuesto y su consecuencia antes de solicitar aprobación.
- Límites de ejecución: fijar tiempo, intentos y consumo máximo, y definir qué hacer al alcanzarlos.
- Prevención de duplicados: comprobar el resultado de una operación antes de reintentar una acción que pudo haberse completado.
- Recuperación: disponer de una forma de detener el proceso, revisar lo ocurrido y corregir cambios cuando sea posible.
También separaría el contenido consultado de las instrucciones autorizadas. Un mensaje o documento recuperado no debería poder conceder permisos por sí mismo.
En Trustworthy agents in practice, Anthropic explica que el comportamiento depende tanto del modelo como de las herramientas y el entorno, y que ninguna defensa aislada garantiza protección frente a instrucciones maliciosas incrustadas en contenido. Es una razón para diseñar controles en varias capas.
5. Mide la resolución completa, incluida la supervisión
Un producto puede completar muchas acciones y seguir dejando a las personas el trabajo difícil: detectar errores, rehacer pasos o explicar decisiones al cliente.
Para decidir si ampliar autonomía, usaría una línea base del proceso actual y observaría:
| Pregunta de producto | Señal que mediría |
|---|---|
| ¿La necesidad quedó resuelta? | Casos resueltos correctamente, con criterios revisados por el equipo |
| ¿Se redujo el esfuerzo total? | Tiempo de ejecución, revisión, corrección y escalamiento |
| ¿Se respetaron los límites? | Acciones fuera de alcance, bloqueos y aprobaciones omitidas |
| ¿Qué ocurre al fallar? | Incidentes, recuperación y tareas que quedan sin salida |
| ¿Es viable operarlo? | Costo por caso correctamente resuelto y carga de supervisión |
Revisaría los resultados por tipo de caso. Un promedio favorable puede ocultar que los casos ambiguos reciben respuestas incorrectas o necesitan más trabajo humano.
Los criterios para continuar deben acordarse antes del piloto. Si aparecen cambios no autorizados o errores que el equipo no puede reconstruir, revisaría el alcance antes de delegar más. Un porcentaje de éxito, por sí solo, no explica la gravedad de lo que falló.
6. Usa una ficha de autonomía antes de construir
Esta ficha conecta la conversación de producto con las decisiones de implementación:
| Campo | Qué dejar claro |
|---|---|
| Objetivo | La tarea que debe quedar resuelta y para quién |
| Contexto permitido | Datos, fuentes y recursos a los que puede acceder |
| Acciones | Qué puede consultar, preparar y modificar |
| Aprobaciones | Qué requiere confirmación y quién puede darla |
| Límites | Tiempo, intentos, consumo y alcance de cada acción |
| Incertidumbre | Cuándo pedir información, escalar o detenerse |
| Evidencia | Qué registrar para revisar el resultado sin guardar datos innecesarios |
| Recuperación | Cómo interrumpir, corregir o volver al proceso habitual |
| Evaluación | Casos de prueba y condiciones para ampliar o reducir autonomía |
| Responsable | Quién supervisa la operación y atiende incidentes |
Empezaría con un grupo pequeño de tareas, casos representativos y un alcance que el equipo pueda supervisar. Ampliaría permisos cuando exista evidencia sobre esas acciones concretas. Algunas pueden seguir requiriendo aprobación aunque otras ya funcionen de manera automática.
Preguntas frecuentes
¿Conectar un chatbot a una API lo convierte en agente?
No necesariamente. Puede ejecutar una consulta dentro de un recorrido fijo. Conviene observar quién decide los pasos, cómo se utilizan los resultados y qué acciones están permitidas, además del nombre comercial del sistema.
¿Un agente necesita autonomía total?
Puede elegir cómo investigar y, aun así, requerir aprobación antes de actuar. El objetivo del producto es resolver la tarea con un alcance adecuado y comprensible para quienes lo usan.
¿Cuándo basta con un workflow?
Cuando puedes definir el recorrido y sus excepciones de manera razonable. Compáralo con una alternativa más flexible usando los mismos casos y criterios de evaluación.
¿Qué debería aprobar una persona?
En mi propuesta, las acciones con consecuencias relevantes, difíciles de revertir o fuera del alcance previamente autorizado necesitan una decisión explícita. La política concreta debe acordarse con los responsables del producto y del proceso.
Para mí, conectar producto e ingeniería significa convertir una promesa como “resolver una incidencia” en decisiones verificables sobre acceso, acciones, límites y resultados. Ahí es donde la autonomía se vuelve una característica que podemos diseñar y evaluar.
Si estás definiendo una iniciativa, puedes continuar con la guía sobre cómo conectar producto e inteligencia artificial, conocer mi enfoque o conectar conmigo en LinkedIn.