Un viernes por la tarde, el equipo de operaciones recibe veinte incidencias parecidas: pedidos duplicados, un stock que no cuadra y varios clientes esperando respuesta. Alguien propone “poner un agente de IA” para que clasifique los casos, prepare respuestas y abra tareas en el ERP. La idea suena razonable hasta que aparece la pregunta importante: ¿quién decide qué puede hacer el agente y qué no?
La IA operativa no fracasa por falta de inteligencia; fracasa cuando la empresa le pide resolver un proceso que ella misma no ha gobernado.
Mi tesis es simple: un agente de IA para operaciones solo merece entrar en producción cuando reduce fricción sin introducir ambigüedad. Si tu proceso ya es frágil, automatizar la fragilidad solo hace que el error viaje más rápido.
El problema real no es “usar IA”, es delegar decisiones sin diseño
En una empresa mediana, un agente de IA puede ser útil para tareas concretas y repetitivas: clasificar incidencias, extraer datos de correos, proponer respuestas, detectar órdenes anómalas o preparar resúmenes para un responsable. Pero eso solo funciona si el proceso tiene límites claros.
Tres señales de que aún no estás listo:
- Los equipos resuelven incidencias de forma distinta según la persona de turno.
- No existe una taxonomía estable de motivos, estados o prioridades.
- Nadie sabe qué excepciones requieren revisión humana obligatoria.
Si el agente aprende de historiales inconsistentes, amplificará esa inconsistencia. Si el dato maestro del ERP está sucio, el agente no lo corrige: lo convierte en una respuesta convincente.
Qué sí puede hacer un agente útil en operaciones
Un agente bien acotado no sustituye a una persona. Reduce el tiempo entre un evento y una acción correcta.
Ejemplos realistas:
- Lee un email de un cliente, identifica el pedido y propone el tipo de incidencia.
- Consulta el ERP y el sistema logístico antes de redactar una respuesta.
- Abre una tarea con el contexto mínimo necesario para que un operador humano actúe.
- Escala automáticamente si detecta importes altos, devoluciones sensibles o errores de inventario.
La clave es que el agente no “decida” todo. Debe operar como un asistente con permisos limitados y salidas verificables. En práctica, eso significa:
- entradas estructuradas
- acciones permitidas por tipo de caso
- registro de cada paso
- revisión humana en los umbrales correctos
Si no puedes auditar por qué tomó una ruta, todavía no está listo para producción.
Un escenario realista: menos correos, más control
Imaginemos una empresa de distribución con Shopify, ERP y soporte por correo. Cada día llegan incidencias por pedidos incompletos, cambios de dirección y dudas sobre estados de envío. El equipo tarda demasiado en triage porque la información está dispersa.
Un agente bien diseñado puede hacer tres cosas útiles:
- Extraer pedido, cliente, almacén y estado desde varios sistemas.
- Clasificar la incidencia según reglas de negocio.
- Preparar un borrador de respuesta y crear una tarea interna.
El valor no está en “responder como humano”. El valor está en que el operador recibe una propuesta razonable con contexto consolidado.
Pero incluso aquí hay límites: si hay discrepancia entre ERP y plataforma ecommerce, el agente no debería ocultarla con una respuesta pulida. Debe señalarla.
La incomodidad: automatizar demasiado pronto suele empeorar la operación
La decisión controvertida es esta: a veces conviene prohibir al agente hacer más cosas de las que técnicamente podría hacer.
Eso incomoda porque los equipos quieren eficiencia visible. Pero en operaciones reales, el coste de un error autónomo suele ser mayor que el ahorro de unos minutos. Un agente que puede reembolsar, cambiar un pedido o cerrar un ticket sin validación puede convertir un problema menor en uno contable, logístico y de atención al cliente.
Antes de automatizar una acción, pregúntate:
- ¿Es reversible?
- ¿Tiene impacto financiero o regulatorio?
- ¿Depende de una excepción rara pero crítica?
- ¿Podemos explicar después por qué se hizo?
Si alguna respuesta es incómoda, el agente debe sugerir, no ejecutar.
Criterios para saber si estás listo
Un proyecto serio de agente operativo debería empezar por un caso estrecho y medible. No por “IA para todo”.
Yo usaría cuatro criterios:
- alto volumen repetitivo
- bajo riesgo por caso individual
- datos relativamente accesibles
- reglas de negocio estables
Y añadiría tres señales operativas antes de pasar a producción:
- tasa de revisión humana por debajo de un umbral razonable
- reducción real del tiempo de triage
- cero ambigüedad sobre quién asume la acción final
Si el equipo no confía en el resultado, el sistema no está listo aunque el demo impresione.
La pregunta correcta no es si un agente de IA puede hacer el trabajo. Es si tu operación ya está preparada para convivir con un asistente que actúa rápido, pero debe actuar dentro de límites. En Codefuente solemos empezar precisamente por ese diseño: qué automatizar, qué vigilar y qué dejar en manos humanas.