Agentes de IA en operaciones: responder no es operar

Una demo puede mostrar a un agente que entiende una petición, consulta varios sistemas y resuelve un caso. En producción, los pedidos llegan con campos vacíos, parte de las reglas no está escrita y el software de gestión tiene quince años. La diferencia no depende solo del modelo de IA. Depende de si el agente se limita a responder o tiene autoridad para operar.

Responder no es operar

Un agente que responde recibe una entrada y devuelve una salida: contesta una pregunta, resume un documento, redacta un borrador. Es útil, tiene riesgo bajo y se despliega rápido, porque no toca nada. Si se equivoca, alguien lee algo incorrecto y lo descarta.

Un agente que opera actúa en tus sistemas. Registra el pedido, emite el abono, actualiza el inventario o responde al cliente en firme. Necesita una identidad propia con permisos, límites de actuación, un registro de cada acción y una ruta de escalado. Si se equivoca, el error ya ha afectado al sistema.

La palabra “agente” cubre las dos cosas, así que una demostración de respuesta puede presentarse como si probara capacidad de operación. Cuando un directivo me dice que ya tiene agentes funcionando, pregunto qué permisos tienen. La respuesta indica qué acciones se han delegado.

Qué funciona hoy

Ya hay agentes operando procesos. En los casos que he visto de cerca se repiten las mismas condiciones.

Funcionan sobre procesos acotados: clasificar y enrutar pedidos o incidencias, contrastar datos entre sistemas, preparar operaciones para aprobación, ejecutar conciliaciones y vigilar excepciones que antes se detectaban tarde. Son tareas de volumen, con reglas expresables y resultado verificable.

Las considero requisitos: el proceso tiene un responsable identificado, las entradas y salidas se pueden verificar, las excepciones tienen una ruta de escalado y el agente empieza con permisos mínimos que se amplían según su historial. En mi práctica como Chief Product & Technology Officer aplico este patrón en la operación de producto.

Qué sigue siendo demo

El agente de propósito general que se incorpora y aprende una empresa por sí solo no opera hoy sin un trabajo previo de integración y definición del proceso.

La demostración usa datos preparados, casos previstos y sistemas disponibles. La operación incluye campos heredados que cambiaron de significado, pedidos recibidos fuera del sistema y reglas como no reclamar a cierto proveedor hasta el día 20. Un agente no puede aplicar una regla que nadie ha documentado ni conectado a su contexto.

Un producto cerrado puede cubrir el flujo estándar y quedarse sin mecanismos para las excepciones al pasar a producción, un patrón que analizo en por qué fracasan los pilotos de IA. Mejorar el modelo no documenta esas reglas. Hay que codificarlas, como explico en el modelo operativo como código.

Permisos, límites y trazabilidad

Cuando un agente pasa de responder a operar, el proyecto necesita permisos, límites y trazabilidad.

Permisos: el agente tiene una identidad y solo puede hacer lo que exige su función. Límites: se detiene ante determinados importes, volúmenes o tipos de acción. Trazabilidad: cada acción permite reconstruir qué hizo, con qué información y por qué. También debe existir un mecanismo de parada. Desarrollo esta capa en gobernanza de agentes. Sin ella, el agente puede producir una respuesta, pero no se le puede delegar una operación.

En el mapa de Wardley, este es el eslabón que sigue en fase custom. Los modelos ya son utility y los frameworks de orquestación avanzan hacia producto. Conectarlos con un proceso concreto, sus permisos y sus excepciones exige trabajo específico durante el despliegue. No significa entregar software a medida: el proveedor puede mantener una plataforma común y configurar dentro de ella cada operación, como explico en el manifiesto de la fase custom.

Ese modelo importa cuando la empresa no tiene un departamento de producto o tecnología. El responsable interno define el proceso y decide sus reglas. Un forward-deployed engineer conecta y adapta el sistema, y el proveedor mantiene los agentes al día. La empresa compra la operación, no una base de código que deba sostener.

Cómo comprobarlo en una reunión de una hora

Cinco preguntas permiten comprobar si el sistema puede operar:

• Enséñamelo funcionando sobre nuestros datos, no sobre los vuestros.
• ¿Qué permisos exactos tendría en nuestros sistemas y quién los concede?
• ¿Qué pasa con el caso que no sabe resolver? ¿A quién llega y cómo?
• ¿Dónde queda registrado lo que hace y quién revisa ese registro?
• ¿Cómo lo paramos, y qué ha pasado hasta ahora cuando ha fallado?

Un proveedor con sistemas en producción puede enseñar permisos, escalados, registros e incidentes anteriores. Si no puede explicar qué ocurrió cuando el sistema falló, todavía no hay evidencia de operación.

Si las respuestas de tu propia casa tampoco existen aún, esa es la señal de por dónde empezar. He escrito una guía de ese punto de partida en preparar tu empresa para agentes.

Preguntas que me hacen los comités

¿Empezamos por atención al cliente, que es lo que hace todo el mundo?

Empieza donde el proceso tenga responsable, resultado medible y excepciones acotadas, sea atención al cliente o conciliación de facturas. Si se elige por popularidad y no por esas condiciones, el piloto tendrá difícil pasar a producción.

¿Qué riesgo corremos si el agente se equivoca?

El que tú hayas diseñado, y esa es la disciplina: el radio de daño se decide antes de encender nada, con permisos y límites. Un agente con permiso de lectura y propuesta no puede romper nada. Uno con permisos de escritura acotados puede equivocarse dentro de un perímetro conocido y trazado. El riesgo inaceptable es el del agente desplegado sin esa capa.

¿Esto no es RPA con otro nombre?

El RPA automatiza clics sobre pantallas y se rompe en cuanto algo varía, por eso se quedó en tareas rígidas. Un agente con un LLM detrás tolera variación e interpreta casos nuevos, que es su ventaja y su riesgo: por eso necesita límites y trazabilidad que al RPA ni se le pedían. Comparten promesa comercial, no mecanismo.

¿Cuánta supervisión humana hace falta?

Al principio, más de la que te gustaría: revisión frecuente, permisos cortos, mucho escalado. Es lo esperable y es barato comparado con la alternativa. La supervisión se reduce con evidencia acumulada, proceso a proceso, no con un acto de fe el primer día.

¿Y si no tenemos equipo de producto o tecnología?

Necesitas un responsable del proceso, no crear un departamento de IA. Ese responsable fija reglas, límites y prioridades. En un servicio operado, el proveedor asume la integración, la fiabilidad y la actualización técnica. El forward-deployed engineer traduce los cambios del negocio al sistema.