Durante los últimos años, buena parte de la inteligencia artificial empresarial se ha utilizado para responder preguntas, generar documentos o localizar información. La aparición de los agentes introduce un cambio importante: el sistema ya no se limita necesariamente a ofrecer una respuesta, sino que puede interactuar con aplicaciones y preparar o ejecutar determinadas acciones.
Un asistente puede consultar el estado de un pedido y explicárselo a una persona. Un agente, en cambio, podría detectar una incidencia, revisar el inventario, proponer una alternativa, actualizar el sistema de gestión y generar una comunicación para el cliente.
Este cambio es importante porque, cuando la IA comienza a intervenir en un proceso, un error puede tener consecuencias operativas. Ya no solo debemos evaluar la calidad de una respuesta, sino también qué información ha utilizado, qué acciones puede realizar, qué efectos pueden producir y quién conserva la responsabilidad sobre la decisión.
Un modelo avanzado no conoce por sí solo cómo funciona una empresa.
En agosto de 2026, SAP presentó una estrategia de inteligencia artificial especializada por industrias. Su planteamiento parte de una idea relevante: los modelos generalistas, por avanzados que sean, no bastan para resolver determinadas decisiones empresariales.
Según explica la compañía, situaciones como reorganizar a miles de técnicos después de una tormenta, mantener una línea de producción o responder ante una alteración de la cadena de suministro requieren datos, regulación, conocimiento sectorial y comprensión de los flujos de trabajo. Se trata de la visión corporativa de SAP, pero refleja una cuestión cada vez más presente en los proyectos de IA empresarial: el modelo es solamente una parte del sistema.
Conviene precisar qué significa aquí «comprender». Un agente no entiende un proceso como lo haría una persona. Lo que puede hacer es trabajar con una representación suficientemente completa de sus reglas, estados, participantes, datos, excepciones y límites.
El problema aparece cuando esa representación no coincide con la realidad. Un procedimiento puede indicar que todas las solicitudes superiores a determinada cantidad requieren aprobación. En la práctica, pueden existir excepciones según el proveedor, la urgencia, la disponibilidad o las condiciones contractuales. Si el agente solo conoce la regla general, su actuación puede parecer lógica y, sin embargo, ser incorrecta desde el punto de vista operativo.
Seis señales de que un proceso está preparado para incorporar agentes de IA.
Antes de decidir qué agente desarrollar o qué modelo utilizar, hay una pregunta más básica: ¿el proceso está suficientemente preparado? Nuestro IA Lead identifica seis señales:
1. El proceso existe más allá de la costumbre
Un proceso está suficientemente definido cuando se encuentra descrito y dos personas distintas pueden explicarlo de forma similar.
Si cada departamento ofrece una versión diferente, el primer trabajo no consiste en automatizar, sino en ordenar el proceso y acordar cómo debería funcionar. De lo contrario, el agente heredará esas contradicciones.
2. Los datos pueden ser consultados por una máquina
La información necesaria debe estar disponible mediante una API, una base de datos, un historiador u otro sistema accesible de manera controlada.
Si parte del contexto reside en correos electrónicos, conversaciones informales o un Excel guardado en el escritorio de una persona, el agente trabajará con una visión incompleta.
Esto no significa que todos los datos deban concentrarse en una única plataforma. Significa que deben estar identificados, ser accesibles y contar con una interpretación compartida.
3. El criterio de decisión puede explicarse
Una regla como «si el caudal desciende por debajo de X durante Y minutos, se realiza Z» puede traducirse en una lógica controlable y verificable.
Cuando la decisión depende exclusivamente de la experiencia tácita de una persona, todavía falta una fase previa: extraer, contrastar y documentar ese conocimiento.
No todo el criterio profesional puede convertirse en una regla sencilla. El agente, sin embargo, necesita saber qué condiciones puede evaluar y en qué situaciones debe solicitar ayuda.
4. El volumen o la criticidad justifican el esfuerzo
Un proceso puede ser candidato porque se repite cientos de veces o porque, aunque se produzca con menor frecuencia, sus consecuencias son relevantes.
Automatizar una tarea poco frecuente, sencilla y de bajo impacto puede exigir más esfuerzo del que ahorra. En cambio, una operación poco habitual pero relacionada con la continuidad del servicio, la seguridad o el cumplimiento puede justificar un desarrollo específico.
5. El resultado puede comprobarse
Después de la recomendación o actuación debe ser posible saber si fue correcta.
¿La anomalía se confirmó? ¿El pedido llegó a tiempo? ¿La intervención resolvió el problema? ¿La recomendación fue aceptada o modificada?
Si no podemos verificar el resultado, tampoco podremos medir el funcionamiento del agente ni mejorarlo.
6. Existe un responsable del proceso
El proyecto necesita una persona con conocimiento y autoridad para decidir sobre reglas y excepciones.
«Sin ese interlocutor, el proyecto se atasca en la primera duda», explica Monzón, IA Lead en MindDen.
El equipo técnico puede desarrollar integraciones, controles y modelos, pero no debería decidir por su cuenta cómo funciona el negocio ni qué excepción debe prevalecer.
El riesgo de automatizar únicamente el camino fácil.
Una de las dificultades más habituales es diseñar el agente alrededor de los casos más claros y dejar fuera las excepciones. Nuestro experto señala que el agente resuelve el 70 u 80% de los casos y el resto se convierte en trabajo manual adicional «con lo que la ganancia neta se evapora».
Imaginemos un agente que clasifica solicitudes de soporte y asigna cada una al equipo correspondiente. Los casos habituales funcionan correctamente, pero las incidencias que afectan a varios servicios quedan mal clasificadas. El equipo debe localizarlas, corregir su categoría y reconstruir parte del contexto.
La organización ha automatizado la parte sencilla, pero ha concentrado más trabajo y complejidad en el porcentaje restante.
Esto no significa que un agente tenga que resolver desde el primer día todos los casos. Las excepciones pueden derivarse a una persona. Lo importante es identificarlas, diseñar su tratamiento y medir cuánto trabajo generan.
Automatizar el desorden solo consigue que falle más rápido.
Un agente puede ejecutar con eficiencia un proceso mal diseñado. Eso no convierte el proceso en uno mejor.
Si existen pasos redundantes, responsabilidades poco claras, fuentes contradictorias o validaciones que llegan demasiado tarde, la automatización puede acelerar esos problemas y reproducirlos a mayor escala.
Antes de implantar el agente conviene preguntarse:
- ¿Este paso sigue siendo necesario?
- ¿Por qué se solicita dos veces la misma información?
- ¿Qué sistema contiene el dato correcto?
- ¿Quién puede resolver una discrepancia?
- ¿Qué parte del proceso no aporta valor?
- ¿Estamos automatizando una solución provisional que se convirtió en permanente?
En algunas ocasiones, analizar el proceso conduce a una conclusión poco espectacular, pero útil: no hace falta un agente. Una integración convencional, una regla de negocio o una mejora del sistema puede resolver el problema con menor complejidad.
Qué ocurre cuando el proceso no está suficientemente preparado.
Automatizar sin analizar las excepciones y dependencias puede trasladar los problemas existentes al agente y reproducirlos a mayor escala. Una modificación aparentemente sencilla puede afectar a otros sistemas relacionados con facturación, inventario, cuadros de mando o cumplimiento normativo.
También es importante comprobar qué significan realmente los datos. Un valor cero, por ejemplo, puede representar una medición real o indicar que un sensor se encuentra en mantenimiento. Si el agente no conoce esa diferencia, puede generar una recomendación coherente en apariencia, pero equivocada.
«El peor fallo es el silencioso: el agente hace algo plausible pero incorrecto y no se detecta hasta mucho después», explica Monzón.
Además, una primera versión que genere falsas alarmas o trabajo adicional puede provocar el rechazo del equipo. Por eso, antes de automatizar conviene identificar las dependencias, documentar las excepciones y comprobar que los resultados del agente pueden verificarse.
Antes de confiar en él, conviene observarlo.
Antes de permitir que un agente ejecute acciones, puede establecerse una fase en sombra: el sistema analiza situaciones reales y genera recomendaciones, pero todavía no interviene en el proceso.
Fase en sombra: probar antes de automatizar
Durante esta fase se comprueba:
- La tasa de falsas alarmas.
- La información que falta.
- Las excepciones no contempladas.
- La coincidencia con las decisiones del equipo.
- La utilidad y claridad de las recomendaciones.
- Los posibles efectos de una actuación automática.
La duración dependerá del volumen y la criticidad del proceso. Un flujo con cientos de operaciones diarias puede generar evidencias en poco tiempo; un proceso industrial con incidencias menos frecuentes requerirá una observación más prolongada.
Comprender antes de automatizar.
El marco de gestión de riesgos de inteligencia artificial de NIST organiza este trabajo alrededor de cuatro funciones: gobernar, contextualizar, medir y gestionar. Su propuesta es voluntaria, pero aporta una idea especialmente relevante: los riesgos y resultados deben analizarse durante todo el ciclo de vida del sistema y dentro de su contexto de uso.
Un agente no comprende un proceso porque tenga acceso a muchos datos. Necesita una representación suficientemente fiel de sus reglas, excepciones, dependencias y responsabilidades.
En algunos casos, el análisis confirmará que el proceso está preparado. En otros revelará que primero deben ordenarse los datos, aclararse las responsabilidades o rediseñarse determinados pasos.
Ambos resultados son valiosos. La finalidad no es introducir un agente en todos los procesos, sino identificar dónde puede mejorar realmente la forma de trabajar.
«Sin una línea base, cualquier mejora es opinable», resume nuestro experto.
En el próximo artículo analizaremos cómo conectar un agente con aplicaciones corporativas manteniendo los permisos, la trazabilidad y el control humano.