Cuando alguien entra en una reunión diciendo «necesitamos un agente de IA», la conversación suele empezar demasiado tarde. Ya se ha elegido la herramienta, pero todavía nadie ha explicado con precisión qué falla, cuánto cuesta ni qué tendría que cambiar para considerar resuelto el problema.
Ese orden produce demostraciones vistosas. También produce bastantes pilotos que nunca encuentran su sitio en el trabajo diario.
La tecnología suele llegar demasiado pronto a la conversación
«Queremos usar IA para revisar contratos». «Necesitamos automatizar el soporte». «¿Podemos poner un agente en compras?». Son ideas razonables, pero aún no son casos de uso. Falta saber quién hace el trabajo, dónde se atasca, qué excepciones existen y qué riesgo tiene equivocarse.
Un caso bien planteado se parece más a esto: «El equipo jurídico tarda varios días en localizar diferencias entre contratos y plantillas aprobadas. Queremos reducir ese tiempo sin dejar pasar cláusulas que exigen revisión». Aquí ya aparecen un proceso, un usuario, una fricción y una condición de calidad. Se puede investigar.
La distinción importa porque una tarea técnicamente posible puede tener poco valor, y una mejora pequeña en un flujo muy frecuente puede liberar bastante capacidad. La guía de evaluación de flujos de OpenAI Academy, actualizada en junio de 2026, propone precisamente empezar por evidencia sobre frecuencia, alcance, retrasos, reprocesos, dependencias y preparación. También recomienda no dar por supuestos el impacto, la viabilidad o el retorno.
Hay otra razón menos evidente. Cuando se introduce una solución demasiado pronto, el equipo empieza a describir el proceso pensando en lo que la herramienta sabe hacer. Las partes incómodas —correos fuera del sistema, aprobaciones informales, datos que faltan, decisiones que nadie quiere asumir— quedan fuera del dibujo. Luego reaparecen en producción.
Síntoma, problema y causa: tres conversaciones distintas
Imaginemos una bandeja de atención al cliente que acumula mensajes.
El síntoma es visible: hay demasiados correos sin responder. El problema operativo podría ser que las incidencias urgentes superan el tiempo de servicio acordado. La causa, sin embargo, puede estar en varios lugares: una clasificación manual lenta, solicitudes que llegan incompletas, una aprobación redundante o información repartida entre tres aplicaciones.
Cada causa pide una intervención diferente. Un clasificador puede ayudar con la primera. Un formulario mejor diseñado puede resolver la segunda. Eliminar una firma quizá arregle la tercera. Y conectar los sistemas puede tener más efecto que añadir un modelo.
Por eso conviene redactar el problema sin mencionar todavía la solución:
En [proceso], [grupo de usuarios] sufre [fricción observable], lo que afecta a [resultado]. Lo sabemos por [evidencia disponible] y consideraremos que mejora cuando cambie [medida] sin deteriorar [condición de calidad o riesgo].
Si no podemos completar esa frase con datos u observaciones, aún estamos ante una hipótesis. No pasa nada. Lo que no conviene es tratarla como un proyecto aprobado.
Seis preguntas antes de hablar de modelos
No hace falta documentar durante semanas cada variante del proceso. Para una primera evaluación suelen bastar seis preguntas, contestadas por quienes hacen el trabajo y contrastadas con alguna evidencia del sistema.
-
¿Dónde empieza y termina el flujo? «Gestionar facturas» es demasiado amplio. «Resolver facturas que no coinciden con el pedido, desde la detección de la discrepancia hasta su aprobación o devolución» permite trabajar.
-
¿Qué resultado debería producir? No preguntes aún cuánto tiempo puede ahorrar la IA. Pregunta qué debería ocurrir: resolver antes, cometer menos errores, absorber más volumen o aplicar el mismo criterio en todos los casos.
-
¿Cómo funciona de verdad? Hay que seguir entradas, decisiones, esperas, traspasos, sistemas y excepciones. El procedimiento oficial ayuda, aunque rara vez cuenta toda la historia. Una hoja paralela o una cadena de correos suele explicar mejor el atasco que el diagrama corporativo.
-
¿Qué tamaño tiene la fricción? Volumen, frecuencia, tiempo activo, tiempo de espera, devoluciones, correcciones y trabajo pendiente. No hacen falta veinte indicadores. Sí hace falta conservar la unidad, el periodo y el método de medición. La recomendación de OpenAI Academy sobre evidencia de valor es útil aquí: «tiempo ahorrado» dice poco si no conocemos la línea base, y terminar antes no es una mejora si después aumenta la revisión.
-
¿Por qué ocurre? Una demora puede venir de una tarea lenta, pero también de una cola, una responsabilidad difusa o datos que llegan mal desde el paso anterior. Automatizar la tarea equivocada apenas moverá el tiempo total del proceso.
-
¿Quién responde por el resultado? Hace falta un propietario capaz de cambiar el flujo, definir qué significa «bien» y decidir qué hacer con las excepciones. El responsable técnico de la solución no sustituye al responsable operativo.
Esta exploración separa hechos, indicios y lagunas. Por ejemplo: los registros pueden demostrar que una solicitud espera dos días; el equipo puede atribuirlo a una aprobación; y quizá todavía no sepamos cuántas solicitudes necesitaban realmente esa aprobación. Las tres cosas tienen distinto peso.
No todo cuello de botella necesita IA
Una vez entendida la causa, se puede elegir la intervención. Este orden suele ahorrar bastante discusión:
| Lo que encontramos | Primera opción que conviene evaluar |
|---|---|
| Un paso que ya no aporta valor | Eliminarlo |
| Demasiados traspasos o variantes | Simplificar y estandarizar el flujo |
| Una regla estable y datos estructurados | Automatización convencional |
| Texto, imágenes, voz o documentos variables | IA para interpretar o generar información |
| Una decisión ambigua que puede revisarse | IA como apoyo, con supervisión humana |
| Varios pasos entre sistemas, con límites verificables | Un agente con herramientas y permisos acotados |
| Un error difícil de detectar o revertir | Mantener la decisión humana o reducir mucho la autonomía |
La solución puede mezclar varias opciones. De hecho, suele hacerlo. Las reglas son mejores para comprobar límites exactos; un modelo puede interpretar una explicación escrita; una persona puede autorizar la excepción; y el sistema debe registrar quién hizo qué.
Usar un agente para una clasificación puntual añade piezas que no aportan mucho: herramientas, memoria, permisos, trazas y condiciones de salida. En cambio, si el trabajo exige consultar varias fuentes, actuar en distintos sistemas y adaptar el siguiente paso según el resultado anterior, esa complejidad puede estar justificada.
Un ejemplo: las facturas que nadie consigue cerrar
Pensemos en una empresa donde las facturas de proveedores llegan en PDF, se comparan con pedidos y, cuando hay una diferencia, circulan por correo hasta encontrar a alguien que la resuelva. La petición inicial es previsible: «queremos una IA que procese facturas».
Al observar el flujo aparece algo más concreto. Las facturas correctas ya se tramitan razonablemente bien. El atasco está en las discrepancias: faltan referencias, las tolerancias cambian según la compra y algunas incidencias rebotan entre Compras, Administración y el responsable del pedido.
La oportunidad no consiste en «procesar facturas con IA». Consiste en reducir el tiempo y el reproceso de las excepciones sin debilitar el control financiero. Para saber si merece la pena se medirían, al menos, el volumen de discrepancias, sus causas, cuánto tiempo pasan esperando, cuántas veces cambian de manos y qué correcciones se hacen después.
Una primera solución podría extraer campos de documentos variables, aplicar reglas para importes y tolerancias, consultar los sistemas autorizados y proponer a quién corresponde cada excepción. Los pagos y los cambios sensibles seguirían necesitando aprobación. También habría que registrar la fuente utilizada y las correcciones humanas, porque ahí se verá si el sistema está ayudando o desplazando trabajo.
No hace falta comenzar por todo el proceso. Una prueba con un tipo frecuente de discrepancia puede responder antes a la pregunta decisiva: ¿podemos reducir la espera sin aumentar errores ni carga de revisión?
Cuándo parar antes del piloto
Hay procesos que todavía no están preparados. Si nadie puede delimitar el flujo, el criterio de calidad cambia según la persona o no existe acceso legítimo a los datos, construir primero rara vez aclara las cosas.
También conviene frenar cuando la incidencia es esporádica, cuando el error sería difícil de detectar o cuando el proceso está cambiando por una reorganización. En esos casos, observar, estabilizar o simplificar es trabajo del proyecto, aunque no produzca una demo.
Y falta una condición básica: acordar de antemano qué evidencia permitirá avanzar. La prueba debería tener usuarios reales, casos normales y excepciones, una medida comparativa y un criterio para detenerse. Sin eso, cualquier resultado admite una interpretación favorable.
Preguntas frecuentes
¿Cómo sé si un problema es adecuado para IA?
La IA suele encajar cuando la fricción procede de interpretar información variable, comparar contenido, generar una respuesta o aplicar juicio dentro de límites revisables. Si el trabajo se describe con reglas estables y datos estructurados, una automatización convencional será normalmente más simple y predecible.
¿Necesito minería de procesos para hacer este análisis?
No necesariamente. Para un flujo acotado pueden bastar entrevistas, observación, registros de los sistemas y una muestra de expedientes. La minería de procesos resulta especialmente útil cuando hay mucho volumen, numerosas variantes y trazas digitales fiables.
¿Cuándo tiene sentido utilizar un agente?
Cuando el trabajo exige varios pasos, herramientas distintas y decisiones que dependen de resultados intermedios. Deben existir límites de acción, permisos mínimos, comprobaciones y una vía de escalado. Para extraer un dato o clasificar un documento, probablemente no haga falta un agente.
¿Cómo evitamos que la prueba se quede en una demo?
Probándola dentro de un proceso real, con usuarios reales y un propietario operativo. La línea base, las excepciones, los controles y la decisión posterior deben definirse antes de empezar. Una demo demuestra que algo puede funcionar; una prueba operativa comprueba si mejora el trabajo en condiciones representativas.
La pregunta que evita meses de trabajo
Antes de discutir qué modelo, plataforma o agente utilizar, merece la pena hacer una última pregunta: si mañana desapareciera esta tecnología, ¿seguiríamos queriendo resolver el problema?
Si la respuesta es sí, probablemente haya una necesidad real. Entonces podremos elegir la herramienta con criterio, medirla y cambiarla si aparece una opción mejor. Si la respuesta es no, quizá lo que teníamos era interés por la tecnología. Es un punto de partida legítimo para aprender, pero no debería confundirse con un proyecto de transformación.
En INSTINTIA utilizamos este diagnóstico para convertir una fricción operativa en algo que se pueda decidir: un flujo delimitado, una línea base, una causa contrastada y una primera prueba con límites. A veces conduce a un agente. A veces, afortunadamente, conduce a una solución mucho más sencilla.
Fuentes y lecturas recomendadas
- Evaluate AI workflow readiness — OpenAI Academy, publicado el 7 de mayo de 2026 y actualizado el 12 de junio de 2026.
- Gather appropriate evidence of value — OpenAI Academy, 17 de julio de 2026.
- How frontier firms are pulling ahead — OpenAI, 6 de mayo de 2026.
- Introducing Frontier Alliances — OpenAI, 23 de febrero de 2026.
Fuentes consultadas y vigencia revisada el 18 de agosto de 2026.