LOGAR · DOCUMENTO PÚBLICO
Por qué la IA falla en empresas razonablemente organizadas
La causa rara vez está solo en el modelo. Está en la base sobre la que se implanta.
I — El síntoma que casi nadie nombra
La inteligencia artificial fracasa con más frecuencia de lo que se reconoce. La causa rara vez está solo en el modelo. Está en la base sobre la que se implanta.
En empresas caóticas el resultado es predecible: sobre dispersión, la IA produce dispersión amplificada. Pero el mismo fracaso aparece en empresas razonablemente organizadas, empresas que tienen ERP, correo corporativo, sistema de tickets y automatizaciones parciales, que han invertido años en estructura, y que aun así, cuando ponen una capa de IA encima, descubren que tener herramientas no es lo mismo que tener arquitectura.
La IA es un amplificador. Sobre procesos claros, amplifica capacidades. Sobre dispersión, amplifica dispersión.
El error habitual es empezar por la herramienta: qué modelo usar, qué plataforma integrar o qué automatizar primero. Es la pregunta equivocada. La pregunta correcta es otra: ¿sobre qué base va a operar esa inteligencia?
Esa base — procesos visibles, estados explícitos, trazabilidad real, datos definidos, responsabilidades claras — es lo que casi ninguna organización tiene del todo construido. No por negligencia, sino por orden histórico: las herramientas se compraron antes de que existiera el método de trabajo que las sostuviera. Funcionan a medias. Y cuando la IA llega encima, lo que amplifica es ese funcionamiento a medias.
II — Por qué la IA promete y decepciona
Hay un dato que conviene mirar de frente. Según el informe de MIT sobre el estado de la IA en la empresa, el 95% de las organizaciones que invirtieron en inteligencia artificial generativa no obtuvieron retorno medible en su cuenta de resultados. No retorno bajo. Cero retorno atribuible.
El dato no dice que la IA no funcione. Dice que la mayoría de las organizaciones la implantan sobre una base que no estaba preparada para sostenerla, y que la inversión no acaba generando retorno medible.
El patrón de inversión que sí funciona, documentado también por MIT, es el inverso del que se aplica de forma habitual: diez por ciento en algoritmos, veinte en tecnología e infraestructura, setenta en personas y procesos. Es decir: formación, rediseño de flujos de trabajo, definición de responsabilidades y adopción real por parte del equipo. La mayoría invierte al revés. Compra la herramienta, configura la integración y espera que el cambio ocurra solo.
Hay una razón por la que este error se repite, y es humana: las herramientas de IA son tangibles, comprables, demostrables en una reunión de cuarenta minutos. La base operativa no. Es lenta, poco vistosa, y no tiene demo.
MIT, The GenAI Divide: State of AI in Business, 2025.
III — La secuencia que sí funciona
Existe un orden. No es un eslogan. Es una secuencia técnica que determina si la inversión en inteligencia artificial crea capacidad operativa real o produce ruido caro.
Primero, control operativo. Antes de pensar en automatizar o en añadir IA, la organización necesita saber cómo funciona realmente. Qué procesos existen. Qué estados tienen esos procesos. Quién es responsable de qué. Qué datos son críticos. Dónde se producen. Dónde se almacenan. Qué puntos de control existen para detectar errores o cuellos de botella. Sin esa claridad, no hay base.
Después, automatización. Una vez que los procesos tienen estructura visible, es posible identificar qué parte es repetitiva, replicable y automatizable.
Finalmente, inteligencia artificial. Cuando existe base operativa y automatización consolidada, la IA puede añadir una capa de asistencia, búsqueda, razonamiento y decisión que multiplica el valor de todo lo anterior. En ese orden, la IA funciona. En otro orden, es un accesorio frágil.
Un proceso mal definido no mejora por automatizarlo. Primero hay que hacerlo visible, medible y gobernable.
¿Por qué este orden casi nunca se respeta? Por presión, casi siempre. El mercado empuja a adoptar IA ahora, los proveedores venden demos espectaculares y los responsables temen quedarse atrás mientras el de al lado avanza. Y así se invierte el ratio: primero la tecnología, y la base operativa después, cuando ya ha aparecido la frustración y hay dinero gastado que justificar.
IV — Caso 1: el despacho profesional
Un despacho de servicios profesionales. Equipo de entre ocho y doce personas. Varios años de actividad. Software vertical de gestión, calendario compartido, expedientes en carpeta, conocimiento operativo no documentado, acumulado en quienes llevaban más tiempo.
El diagnóstico inicial revelaba síntomas claros. La operación dependía de memoria individual: quién había hablado con qué cliente, en qué fase estaba cada expediente, qué estaba pendiente de respuesta. Los expedientes existían, pero estaban dispersos. No había una vista compartida de qué estaba activo, qué estaba bloqueado, qué facturación estaba pendiente. Cuando salieron personas clave, parte del conocimiento operativo se fue con ellas. No por negligencia. Simplemente porque el sistema no estaba diseñado para que ese conocimiento quedara en algún sitio.
Lo que el despacho creía necesitar era inteligencia artificial: leer documentos automáticamente, clasificar correos, responder consultas. Lo que necesitaba en realidad era otra cosa.
El trabajo comenzó por la base. Migración correcta de clientes al sistema. Código identificador estable para cada expediente. Estados explícitos con responsable asignado. Reducción de la duplicidad entre el sistema de gestión y el calendario, que hasta entonces obligaba a apuntar la misma cita en dos sitios y fiarse de que ambos coincidieran. Interfaz simplificada para que el equipo adoptara el circuito correcto sin que supusiera trabajo extra. Y desde el primer momento, una capa seria de protección de datos y control de accesos, dimensionada al alcance del proyecto.
El resultado no fue espectacular en términos de IA. Fue práctico en términos operativos: visibilidad real de qué está activo y quién lo lleva, trazabilidad de acciones, reducción de dependencia individual, capacidad de incorporar a alguien nuevo sin que el despacho perdiera continuidad.
La lección no es que la IA no sirva. Es que, sobre esa base desordenada, ninguna capa adicional habría funcionado. El despacho no pagó por funcionalidades. Pagó por eliminar fricción real. Y la base, una vez construida, es el único terreno sobre el que tiene sentido añadir cualquier capa de automatización o inteligencia.
V — Caso 2: la organización profesional madura
No todas las organizaciones que necesitan esta capa base están en caos. Algunas están razonablemente estructuradas. Tienen ERP, herramientas de ofimática corporativa y sistema de gestión de incidencias. Llevan varios años modernizando flujos y procesos. Han probado automatizaciones. Están evaluando herramientas de IA corporativa.
Y aun así, el mismo problema aparece. Con otra forma.
Una organización profesional con varios años de modernización activa presentaba exactamente ese perfil. No era una organización improvisada. Era una organización que había invertido en digitalización y que, sin embargo, seguía teniendo circuitos dispersos. Las solicitudes y comunicaciones entraban por canales distintos: tickets, correos genéricos, llamadas, contacto directo, mensajes por canales informales. Si entraba por ticket, había seguimiento. Si entraba por correo o por teléfono, podía quedar sin trazar. El resultado: dependencia de hábitos humanos, no de un circuito fiable. Parte del equipo seguía usando el teléfono y el contacto directo aunque existieran los canales correctos, no por resistencia, sino porque esos canales correctos no estaban diseñados para ser el camino más fácil. Y cuando lo fácil y lo correcto no coinciden, gana lo fácil.
La documentación interna tenía el mismo problema. Normativa, reglamentos, histórico de documentos, versiones finales, materiales compartidos. Todo existía. Pero encontrarlo, saber cuál era la versión vigente, saber quién podía editar y quién solo podía consultar: eso no tenía una respuesta clara.
En este tipo de organizaciones, el valor no aparece siempre como ahorro directo. A veces aparece como control: saber dónde está cada cosa, qué está pendiente y quién debe actuar.
Esa es exactamente la naturaleza del problema. No es un problema de ausencia de herramientas. Es un problema de arquitectura: las piezas existen, pero no están conectadas de forma que la organización pueda operar con fluidez, trazabilidad y control real.
La madurez tecnológica no elimina la necesidad de arquitectura operativa. La cambia de forma. En organizaciones menos maduras, el problema es caos básico. En organizaciones más maduras, el problema es fragmentación: herramientas que no hablan entre sí, circuitos que no cierran, conocimiento que no se encuentra.
En ambos casos, añadir IA sobre esa base produce el mismo resultado: una capa de asistencia que opera sobre información incompleta y genera respuestas que parecen útiles y no son fiables.
VI — Las cuatro preguntas
Antes de hablar de herramientas — cualquier herramienta, IA incluida — conviene responder cuatro preguntas.
¿Puedes responder, en cualquier momento, en qué estado está un caso o expediente concreto sin preguntar a una persona específica?
Si la respuesta es no o depende, hay un problema de trazabilidad. La organización opera con conocimiento no registrado en el sistema.
¿Tu documentación crítica vive en una estructura definida con permisos claros, o está repartida entre carpetas personales, correos y repositorios sin orden?
Si la respuesta es repartida, no hay base documental suficiente para que ninguna capa de búsqueda inteligente funcione de forma fiable.
¿Los procesos importantes tienen estados, responsables y puntos de control explícitos, o dependen de hábitos no documentados?
Si dependen de hábitos, automatizar esos procesos va a replicar los mismos problemas con más velocidad.
¿Cuando entra una solicitud por cualquier canal — correo, ticket, llamada, contacto directo — acaba en el mismo circuito trazable, o se pierde según por dónde haya entrado?
Si se pierde, el primer problema no es de IA. Es de diseño de circuito de entrada.
Si dos o más respuestas apuntan a problemas reales, la organización no necesita más herramientas. Necesita arquitectura.
VII — Qué hace Logar en la práctica
La tesis es clara. La pregunta razonable que sigue es: ¿y esto en qué se traduce? El trabajo no empieza eligiendo tecnología. Empieza por un proceso concreto y sigue un orden:
- 01
Cartografía el proceso real, con todas sus variables y excepciones.
- 02
Identifica los puntos de fuga: dónde se pierde información, dónde se rompe la trazabilidad y qué roles sostienen puntos críticos del flujo.
- 03
Define estados, responsables, datos mínimos y puntos de control. Hace explícito lo que hoy depende de hábitos no documentados y memoria operativa.
- 04
Evalúa qué tecnología encaja con ese proceso ya ordenado — y descarta la que no aporta — en lugar de partir de una herramienta y forzar el proceso a su alrededor.
- 05
Propone una primera implantación controlada: acotada, medible, con una interfaz que el equipo pueda adoptar sin que le suponga trabajo extra.
Solo después de esa base tiene sentido hablar de automatización. Y solo después, de inteligencia artificial. El método no cambia según el sector. La arquitectura, sí.
VIII — Por dónde empezar
El primer paso no es elegir herramienta. Nunca lo es. El primer paso es coger un proceso concreto — el que más duele, el que más depende de personas, el que más se cae cuando alguien falta — y definir su base operativa antes de automatizar nada.
Eso es lo que Logar hace en un diagnóstico inicial: revisa ese proceso, identifica dónde se rompe y lo convierte en una primera mejora implantable. Acotada, concreta, medible. No una transformación total prometida desde el primer día, sino un punto de partida sólido sobre el que lo demás puede construirse después.
Si quieres contrastar si este patrón existe en tu organización, el punto de partida es una conversación sobre un proceso concreto.