Cómo la IA realmente analiza documentos de negocio ambiguos: el problema de la multi-intención que nadie menciona

Toma cualquier documento operativo que realmente circule dentro de una empresa de 200 personas: el SOP de onboarding de clientes, la política de devoluciones, el manual de respuesta a incidentes, el checklist de aprobación de proveedores. Léelo una vez, despacio. Lo que encontrarás, casi sin excepción, no es un solo proceso. Son dos o tres procesos entrelazados, más una rama de excepción, más una nota de gobierno, más un párrafo que describe una subtarea como si fuera un procedimiento propio.

Esto no es mala redacción. Es cómo el conocimiento institucional se acumula en la realidad. Alguien escribió la versión uno del SOP de onboarding en 2018 para el camino feliz. Alguien añadió la excepción de alerta de fraude en 2020 después de que una cuenta falsa se colara. Alguien agregó la sección de escalado VIP en 2022 cuando el director de ventas se quejó de que los clientes enterprise eran tratados como registros self-service. El documento que lees hoy es el registro arqueológico de cinco años de aprendizaje operativo, y nadie tiene el presupuesto para reescribirlo desde cero.

Cuando un consultor lee ese documento, no intenta diagramarlo literalmente. Construye un modelo mental de qué partes describen el flujo principal, qué partes describen excepciones al flujo principal y qué partes describen un proceso completamente diferente que simplemente comparte algunos pasos. Esa división mental es el paso invisible que hace que el diagrama sea usable. Sáltatelo y el diagrama estará estructuralmente mal antes de dibujar la primera caja.

El resto de este artículo trata sobre esa parte difícil. Cómo se ven los tres patrones de enredo de intención en la práctica, qué hace un analizador ingenuo con ellos y qué debe hacer un analizador en su lugar para producir un diagrama que un dueño de proceso realmente apruebe.

Después de analizar unos cuantos miles de documentos operativos de pymes, tres patrones de fallo explican la abrumadora mayoría de intenciones enredadas. Aparecen en manuales de soporte al cliente, procedimientos de cierre financiero, guías de compras, paquetes de onboarding de RRHH y casi cualquier SOP escrito por el propio equipo de operaciones.

Patrón 1. Procedimiento, excepción y escalado en el mismo párrafo

El patrón más común. Un solo párrafo comienza describiendo el procedimiento principal (pasos uno a cuatro), luego se desliza hacia una excepción («si el cliente tiene una factura vencida, haz lo siguiente en su lugar»), y cierra con un escalado («si esto no puede resolverse en 48 horas, transfiérelo al account manager»). Para un lector humano los cambios son obvios por el contexto. Para un analizador literal, esos tres flujos se leen como un procedimiento continuo con lógica de ramificación que en realidad no tiene sentido.

Patrón 2. Camino feliz y caso extremo raro narrados como equivalentes

El segundo patrón es el aplanamiento narrativo. El documento describe el camino estándar que ocurre el 95 por ciento de las veces, luego da igual peso narrativo a un caso extremo que pasa una vez al trimestre. Ambos se describen como «lo que hacemos», con la misma voz, sin ninguna pista de frecuencia. Un diagrama que les da igual peso visual produce un proceso que se ve el doble de complejo de lo que realmente es, y el equipo de operaciones lo rechazará porque no coincide con la realidad que viven.

Patrón 3. Proceso macro y subtarea sin frontera

El tercer patrón es la colisión de escala. Una frase describe un resultado de negocio a nivel macro («cerrar los libros del mes»). La siguiente frase describe una acción mecánica a nivel de detalle («introducir el ajuste de conciliación en la línea 47 de la plantilla del GL»). No hay frontera de subproceso, ni pista de anidación, ni cambio de swimlane. El analizador promueve la acción mecánica a par del proceso macro, lo cual es absurdo, o degrada el proceso macro a una sola tarea, lo cual es peor.

• El enredo de procedimiento más excepción más escalado, que es el modo de fallo dominante en documentos orientados al cliente.
• El caso extremo de narrativa aplanada, que es el modo de fallo dominante en documentos de operaciones y cumplimiento.
• La colisión de escala entre proceso macro y subtarea, que es el modo de fallo dominante en documentos financieros y de back-office.

Un analizador de intención única asume que la entrada describe un proceso y trata cada frase como evidencia de ese proceso. Cuando se le alimenta un documento con tres intenciones entrelazadas, no se niega. Produce un diagrama. El diagrama está estructuralmente mal de una forma específica y predecible, y vale la pena nombrar el modo de fallo porque es lo que la mayoría de herramientas de IA a BPMN siguen entregando hoy.

La salida típica es un único swimlane con quince a treinta tareas en secuencia, más dos o tres gateways colocados donde apareció el párrafo de excepción, más un grupo suelto de eventos finales con los que nadie sabe qué hacer. El camino feliz queda enterrado dentro de la rama de excepción. El escalado se representa como tarea paralela en lugar de como traspaso. La subtarea del patrón tres se dibuja como par del proceso macro, dando al dueño un diagrama de flujo donde «cerrar los libros» y «introducir la línea 47» son cajas del mismo tamaño.

Cuando el dueño del proceso ve esto, la reacción nunca es «esto está mal de formas interesantes que podemos arreglar». La reacción es «este no es mi proceso», la herramienta pierde credibilidad y la conversación de transformación termina. Hemos visto este modo de fallo matar programas piloto más a menudo que cualquier otro problema técnico, porque aterriza en los primeros cinco minutos de la primera demo.

La lección es que el analizador debe modelar explícitamente la posibilidad de que el documento contenga más de un proceso. Esto no puede inferirse de la limpieza estructural de la salida. Tiene que ser un paso de primera clase en el pipeline.

La detección de multi-intención es un paso de preprocesamiento que se ejecuta antes de la generación de BPMN. Su trabajo es producir una lista corta de procesos candidatos que describe el documento, con una clasificación de cómo cada candidato se relaciona con los demás (flujo principal, excepción del flujo principal, escalado del flujo principal, proceso separado que comparte vocabulario). El generador de BPMN downstream recibe entonces una entrada estructurada en lugar de texto crudo, y el diagrama de salida refleja la topología real.

Las pasadas heurísticas

La detección se ejecuta en tres pasadas. La primera pasada identifica frases kernel de proceso: verbos en voz operativa, roles nombrados, secuencia temporal. La segunda pasada agrupa estas frases por coherencia temática: qué frases kernel describen pasos que podrían pertenecer plausiblemente al mismo proceso y cuáles rompen la cadena. La tercera pasada etiqueta cada grupo con un rol (principal, excepción, escalado, separado) observando condiciones disparadoras, pistas de frecuencia y lenguaje de traspaso.

El paso de confirmación humana

A la detección no se le pide que acierte por sí sola. Se le pide que produzca un borrador que el usuario pueda confirmar o corregir en menos de 30 segundos. La interfaz muestra la lista de candidatos con resúmenes cortos: «Candidato 1: onboarding de clientes, el flujo principal descrito en las secciones 1 a 3. Candidato 2: excepción de fraude, se ramifica en el paso 4 del candidato 1. Candidato 3: escalado VIP, proceso separado que comparte el paso de creación de cuenta». El usuario hace clic para confirmar, fusionar o descartar. Esto toma menos tiempo del que tomó leer el documento, y es la única forma de manejar la ambigüedad que el propio documento introduce.

La decisión de fusionar o mantener separado

La llamada más difícil es la segunda. Los enredos del patrón uno (principal más excepción más escalado) se suelen mantener como un solo proceso con gateways explícitos y eventos finales explícitos para la ruta de escalado. Los enredos del patrón tres (macro más subtarea) se suelen separar, con la subtarea convirtiéndose en un subproceso invocado. El patrón dos (casos extremos aplanados) es una decisión de juicio: si la frecuencia del caso extremo está por encima del 10 por ciento, mantenlo en el flujo principal con un gateway; por debajo del 10 por ciento, sepáralo en un proceso de excepción separado que esté vinculado pero no dibujado en línea.

La detección de multi-intención de LucidFlow se ejecuta automáticamente en cada documento subido para generación de BPMN. El usuario ve un panel de procesos candidatos antes de que se dibuje el diagrama, con normalmente de dos a cuatro candidatos para un documento de entre tres y diez páginas. El usuario confirma o ajusta la separación, y el pipeline downstream produce un BPMN por cada candidato confirmado, más enlaces explícitos entre procesos relacionados (excepción-de, escala-a, invocado-por).

La detección está sesgada hacia separar en lugar de fusionar, porque un proceso separado por error es más fácil de arreglar en la interfaz que uno fusionado por error. Fusionar dos diagramas después requiere redibujar; separar un diagrama fusionado incorrectamente requiere deshacer la lógica de los gateways, que según nuestra experiencia los usuarios simplemente no harán. La mayor parte del tiempo abandonan el diagrama y empiezan de nuevo.

El paso de confirmación es deliberadamente rápido. Si el usuario pasa más de un minuto en él, la detección no está haciendo su trabajo. El objetivo son 20 a 30 segundos por documento, porque el valor de la detección de multi-intención es que previene una sesión de limpieza de 30 minutos en la etapa de revisión del diagrama, y esa cuenta solo funciona si el coste upstream se mantiene bajo.

La detección de multi-intención funciona bien en documentos operativos de pymes: de tres a quince páginas, perspectiva de un experto en la materia, lenguaje de una unidad de negocio. La razón por la que funciona es que la ambigüedad en estos documentos es local. Una frontera a nivel de párrafo o de sección es suficiente para separar las intenciones, y el conteo de candidatos es bajo (normalmente de dos a cinco).

A escala enterprise, el problema es más difícil de formas que esta clase de técnica aún no resuelve. Un manual de compras de 200 páginas escrito por comité tiene intenciones que cruzan secciones, vocabulario que deriva entre capítulos y capas de gobierno que editan los pasos operativos desde una altitud distinta. La respuesta correcta ahí probablemente implique catálogos de procesos explícitos a nivel de sección construidos por humanos, con la IA ayudando a reconciliar el lenguaje entre secciones en lugar de extraer intención desde cero.

Para una pyme entre 20 y 2000 empleados, los documentos están casi siempre en el rango donde la detección de multi-intención hace su trabajo. Si estás en ese rango y tu herramienta de IA a BPMN no está haciendo este paso explícitamente, está produciendo diagramas que parecen correctos y son estructuralmente incorrectos. El arreglo no es leer el documento con más cuidado. El arreglo es separar las intenciones antes de dibujar.