Hay una escena que se repite en oficinas de todo tipo, con distintos nombres y distintos logos, pero siempre con el mismo final. Un equipo lleva meses probando herramientas de inteligencia artificial. Alguien conectó un asistente para redactar correos, otra persona automatizó un reporte, un tercero prueba un chatbot en el sitio web. Todo funciona, en el sentido estricto de que hace lo que se le pidió. Y sin embargo, seis meses después, la operación se ve prácticamente igual que antes. Los mismos cuellos de botella siguen ahí. Las mismas horas se siguen perdiendo en los mismos procesos repetitivos y contraproducentes.

La pregunta que casi nadie hizo antes de empezar es simple, pero incomoda: ¿cuál es el problema real que se está tratando de resolver? No la herramienta que se quiere probar, ni la tendencia que domina las conversaciones del momento, sino las complicaciones en específico de esa operación en particular. Esa pregunta, y sobre todo quién puede responderla con precisión, termina siendo el factor que separa una estrategia de IA que transforma un negocio de una colección de experimentos sueltos que nunca despegan.

El patrón detrás del estancamiento

Cuando se observa de cerca a las organizaciones que prueban IA sin ver resultados que cambien su operación, aparece un patrón consistente. El punto de partida casi siempre es la herramienta o el caso de uso llamativo: "vamos a meter un chatbot", "probemos un agente que escriba propuestas", "automaticemos este reporte porque tarda mucho". Son decisiones razonables en apariencia, y ninguna es incorrecta por sí sola. El problema es el orden en que se toman.

Elegir primero la tecnología y después buscarle un lugar donde encaje es exactamente al revés de cómo funciona una estrategia. Es como comprar una herramienta especializada sin saber todavía qué se va a construir con ella. Puede que termine sirviendo para algo, pero casi nunca para lo que realmente movía la aguja del negocio.

El resultado de este orden invertido son iniciativas de IA que existen en paralelo a la operación real, en vez de integrarse a ella. Automatizan una tarea aislada, generan una demo impresionante en una presentación interna, y después se estancan porque nunca estuvieron conectadas al problema que de verdad le costaba tiempo, dinero o calidad a la empresa.

El diagnóstico es el trabajo, no el paso previo al trabajo

Aquí está la raíz del asunto: el diagnóstico de una operación no es un trámite rápido antes de la parte "interesante" del proyecto. Es, de hecho, la parte más difícil y la que determina si todo lo que viene después tiene sentido.

Ese diagnóstico depende casi por completo de las personas que viven el proceso todos los días, no de la tecnología que eventualmente se use. Son ellas quienes saben, aunque muchas veces no lo hayan puesto nunca por escrito, cuál es el verdadero cuello de botella. No el que aparece en el reporte trimestral, sino el que se resuelve todos los días a punta de criterio: el caso raro que llega el viernes por la tarde, la excepción que rompe el proceso estándar, el atajo que alguien del equipo inventó hace tiempo y que nadie más conoce del todo.

Ese tipo de conocimiento es tácito. Vive en la cabeza de quien lo ejecuta, no en un manual ni en un diagrama de flujo. Y es precisamente ese conocimiento el que una estrategia de IA necesita capturar antes de automatizar nada, porque es el material real con el que se construye algo que funcione a la medida de esa operación específica. Sin él, cualquier herramienta, por sofisticada que sea, se queda resolviendo el problema equivocado con mucha eficiencia.

Vale la pena detenerse en un ejemplo simple. Dos empresas del mismo sector pueden tener procesos que, vistos desde afuera, parecen idénticos: ambas concilian pagos, ambas generan cotizaciones, ambas atienden clientes por correo. Pero la manera en que cada equipo resuelve las excepciones, las prioriza y decide cuándo saltarse el proceso estándar es completamente distinta entre una y otra. Una estrategia de IA que ignore esas diferencias termina proponiendo la misma solución genérica a dos problemas que, en la práctica, no lo son.

Construir la tecnología alrededor del criterio, no al revés

El principio que separa a las estrategias que funcionan de las que se quedan en experimentos aislados es sencillo de enunciar, aunque exige disciplina para seguirlo: primero se entiende a las personas y su operación, después se diseña la arquitectura tecnológica alrededor de ese entendimiento.

Esto significa sentarse, literalmente, con quien concilia pagos a mano todos los días, con quien arma cotizaciones desde cero, con quien contesta el mismo tipo de correo una y otra vez. No para observar el proceso desde lejos, sino para entender por qué se toman las decisiones que se toman en cada paso, incluidas las que nunca quedaron documentadas en ningún manual.

De esas conversaciones sale algo mucho más valioso que una lista de tareas para automatizar: sale un mapa de dónde está el criterio humano que realmente importa, y dónde hay trabajo repetitivo que ese criterio ya no necesita seguir haciendo manualmente. La arquitectura tecnológica se diseña después, con ese mapa como base.

Un diagnóstico llevado a la práctica

Un caso reciente ilustra bien este principio. Una compañía que gestiona múltiples adquisiciones de empresas al mismo tiempo necesitaba escalar su operación sin perder control sobre ella. En vez de empezar por una herramienta, el trabajo arrancó con una evaluación rápida de la operación completa: se identificaron 75 oportunidades de mejora, se priorizaron 11 de alto impacto, y se desplegaron 7 equipos especializados en paralelo para atenderlas.

El resultado fue una ruta que va de la estrategia a 7 sistemas funcionando en producción en 10 semanas, con un impacto estimado de 20 millones de dólares en retención durante ese año. Ese resultado no salió de adoptar una herramienta de moda, sino de un diagnóstico riguroso que identificó exactamente dónde intervenir primero, y con qué prioridad.

Lo que de verdad separa a una estrategia de una colección de pruebas

El diferenciador entre una estrategia de IA que transforma una operación y una serie de experimentos que no logran despegar no es qué tan avanzada es la herramienta que se usa. Tampoco es el presupuesto disponible, ni la velocidad con la que se implementa. Es qué tan bien se leyó la operación antes de tocarla, y qué tan dispuesto está el proceso a partir de ese conocimiento acumulado por las personas, en lugar de partir de lo que la tecnología puede hacer en abstracto.

Las empresas que logran resultados sostenidos con IA no son necesariamente las que adoptaron primero la herramienta más nueva. Son las que se tomaron en serio la pregunta de fondo antes de escribir el primer requerimiento: ¿cuál es el problema real, y quién en el equipo lo entiende mejor que nadie? Esa pregunta, respondida con honestidad, hace toda la diferencia entre una IA que multiplica lo que el negocio ya sabía hacer bien y una IA que simplemente automatiza tareas sueltas sin cambiar nada de fondo.

Si algo de esto resuena con la operación de una empresa, probablemente ya tiene una parte importante del diagnóstico dentro de su propio equipo, solo falta ponerlo sobre la mesa antes de decidir qué herramienta usar.

En Creai empezamos exactamente por ahí. Antes de proponer cualquier arquitectura, nos sentamos con los equipos que viven la operación día a día para entender qué problema vale la pena resolver primero. La tecnología llega después, diseñada alrededor de ese criterio. creai.mx