La adopción de inteligencia artificial en la empresa ha entrado en una fase extraña. Casi todas las organizaciones quieren decir que ya están usando IA, muchas han comprado licencias corporativas y no pocas han montado pilotos con agentes, copilotos o automatizaciones internas. Pero cuando se pregunta qué ha cambiado de verdad en la operación, la respuesta suele ser bastante más pobre: algunos informes se preparan antes, se redactan más correos y ciertos equipos han ganado productividad individual, pero el negocio sigue funcionando casi igual.
La diferencia entre «usar IA» y «ser una organización diseñada para trabajar con IA» se está convirtiendo en una de las grandes brechas tecnológicas de 2026. No es un problema de falta de modelos, ni de ausencia de herramientas. Es una cuestión de arquitectura empresarial: procesos, datos, permisos, incentivos, métricas, flujos de aprobación y capacidad para rediseñar cómo se hace el trabajo.
McKinsey resume bien la paradoja en su informe The state of AI in 2025: Agents, innovation, and transformation. El 88 % de los encuestados afirma que su organización usa IA de forma regular en al menos una función de negocio, frente al 78 % del año anterior. Sin embargo, la mayoría sigue en fases de experimentación o piloto, y solo alrededor de un tercio dice haber empezado a escalar sus programas de IA a nivel de empresa.
El atasco empieza cuando la compra sustituye a la estrategia
El primer carril de adopción es el más lleno: comprar herramientas. Copilot, ChatGPT Enterprise, Claude, Gemini, Perplexity, soluciones verticales, generadores de presentaciones, asistentes de reuniones y decenas de productos que prometen productividad inmediata. Es una fase lógica. Una empresa necesita probar, formar a sus equipos y entender qué puede hacer la tecnología.
El error aparece cuando esa compra se presenta como transformación. Dar una licencia de IA a los empleados no cambia por sí solo la forma de vender, atender clientes, diseñar productos, analizar riesgos, gestionar incidencias o tomar decisiones. En muchos casos, solo añade una capa de ayuda individual encima de procesos que ya eran lentos, fragmentados o mal medidos.
El segundo carril es el de los pilotos. Aquí las compañías prueban casos de uso: un agente para soporte, un copiloto para ventas, un asistente para legal, una herramienta para marketing, un sistema de resumen documental. El problema es que muchos pilotos nacen sin propietario claro de negocio, sin integración con datos reales, sin métricas de impacto y sin plan de operación posterior. Funcionan en una demo, pero no sobreviven al contacto con producción.
El tercer carril es más interesante: construir agentes de IA. Estos sistemas ya no se limitan a responder preguntas. Pueden planificar pasos, consultar herramientas, leer documentos, preparar acciones, redactar borradores, clasificar tareas o activar flujos bajo supervisión. McKinsey define los agentes como sistemas basados en modelos fundacionales capaces de actuar en el mundo real, planificar y ejecutar varios pasos dentro de un flujo de trabajo. El 23 % de los encuestados afirma que su organización ya está escalando algún sistema de IA agéntica, mientras otro 39 % ha empezado a experimentar con agentes.
| Carril de adopción | Qué suele hacer la empresa | Riesgo principal |
|---|---|---|
| Comprar herramientas | Licencias de IA para empleados | Confundir acceso con transformación |
| Ejecutar pilotos | Pruebas en áreas concretas | No pasar a producción |
| Construir agentes | Automatizar tareas con contexto | Permisos, datos y fiabilidad |
| Escalar agentes | Extender usos a varias funciones | Falta de gobierno común |
| Rediseñar la organización | Cambiar procesos, roles y métricas | Resistencia interna y cambios de poder |
El cuarto carril es el escalado. Aquí la IA deja de vivir en pruebas aisladas y se integra en varias funciones, con gobierno, seguridad, control de costes y métricas. Es el punto donde empiezan las preguntas incómodas: quién responde si el agente se equivoca, qué salida requiere validación humana, qué datos puede usar, cómo se audita una acción y cómo se evita que cada departamento monte su propio sistema sin coordinación.
El quinto carril es el más vacío: rediseñar la organización. Ahí ya no se pregunta «qué herramienta compramos», sino «qué trabajo no debería hacerse igual». Este es el cambio real. Si la IA puede preparar propuestas, clasificar solicitudes, detectar anomalías, resumir contratos, crear código, generar informes y coordinar tareas, entonces algunas cadenas de trabajo deben reescribirse desde el inicio, no parchearse al final.
El problema no es el modelo: es el sistema que lo rodea
Durante 2023 y 2024, muchas conversaciones sobre IA empresarial giraban alrededor de la calidad del modelo. Qué chatbot respondía mejor, qué modelo razonaba más, cuál escribía mejor código o cuál tenía mejor ventana de contexto. Esa discusión sigue importando, pero en empresa el cuello de botella se ha desplazado.
Un modelo brillante aporta poco si no tiene acceso seguro a datos fiables. Un agente rápido puede ser peligroso si no tiene límites. Una herramienta de resumen puede ahorrar tiempo, pero no cambia nada si después el flujo de aprobación sigue igual. Una automatización puede parecer útil en un caso de prueba y fracasar cuando se enfrenta a excepciones, datos incompletos o responsabilidades mal definidas.
El informe The GenAI Divide: State of AI in Business 2025, elaborado en el marco de MIT NANDA, plantea una conclusión parecida desde otro ángulo. Según sus hallazgos preliminares, pese a una inversión empresarial de entre 30.000 y 40.000 millones de dólares en IA generativa, el 95 % de las organizaciones analizadas no obtiene retorno medible, mientras solo el 5 % de los pilotos integrados extrae millones en valor. El informe atribuye esa brecha menos a la calidad de los modelos o a la regulación y más al enfoque de implementación, la falta de adaptación al flujo real y la ausencia de aprendizaje contextual.
La cifra del 95 % debe leerse con cautela, porque procede de una investigación preliminar con metodología y alcance propios. Aun así, encaja con una observación repetida en muchas empresas: los empleados sacan valor individual de herramientas flexibles como ChatGPT, Claude o Copilot, pero los proyectos corporativos más estructurados se atascan al integrarse en procesos reales. MIT NANDA señala que los sistemas genéricos funcionan bien para tareas simples, mientras las soluciones empresariales fallan cuando no retienen contexto, no aprenden de las correcciones y no encajan en el trabajo diario.
La IA individual crece más rápido que la IA corporativa
Hay otro fenómeno que las empresas no siempre quieren mirar: la «IA en la sombra». Empleados que usan cuentas personales, herramientas externas o automatizaciones propias para hacer mejor su trabajo, muchas veces sin conocimiento del departamento de TI. No lo hacen necesariamente por incumplir normas, sino porque las herramientas oficiales llegan tarde, son demasiado rígidas o no resuelven el problema concreto.
MIT NANDA describe esa economía de uso informal como una señal de lo que sí funciona: herramientas flexibles, rápidas y adaptables al usuario. Según su investigación, mientras solo el 40 % de las compañías afirmaba haber comprado una suscripción oficial a un LLM, trabajadores de más del 90 % de las empresas encuestadas decían usar herramientas personales de IA para tareas laborales.
Esto genera una tensión clara. La empresa compra IA para controlar el despliegue, pero los empleados ya han descubierto usos propios. Si la organización no aprende de esos usos, terminará con dos mundos separados: una IA oficial, gobernada pero poco útil, y una IA informal, útil pero arriesgada.
La solución no es prohibir por reflejo. Es observar qué tareas están resolviendo los empleados con herramientas externas: redactar propuestas, resumir reuniones, revisar código, preparar informes, traducir documentación, limpiar datos, crear presentaciones, clasificar leads o responder tickets. Ahí están los primeros procesos que la empresa debería rediseñar de forma segura.
Los agentes obligan a pensar como arquitectos, no como compradores
La llegada de agentes cambia la escala del problema. Un chatbot responde. Un agente actúa. Puede leer un correo, buscar contexto, consultar un CRM, crear una tarea, generar un borrador, pedir una aprobación y dejar registro. Esa capacidad es útil porque se acerca al trabajo real, pero también obliga a tratar la IA como infraestructura de ejecución.
Para desplegar agentes en serio hacen falta capas que muchas empresas aún no tienen maduras: identidad, permisos por rol, acceso granular a datos, registro de acciones, revisión humana, evaluación continua, observabilidad, control de costes y entornos de prueba. Sin esas capas, el agente se convierte en una caja potente conectada a sistemas sensibles.
Por eso no basta con un «laboratorio de IA» aislado. Los proyectos que escalan suelen combinar tecnología y operación. Necesitan patrocinio ejecutivo, dueños de proceso, equipos de datos, seguridad, legal, ingeniería, negocio y usuarios finales. McKinsey señala que las organizaciones con mejores resultados tienden a tener prácticas más definidas para validar salidas de modelos, gestionar riesgos y rediseñar flujos de trabajo alrededor de la IA.
El cambio también afecta al presupuesto. Muchas empresas invierten en lo visible: ventas, marketing, atención al cliente, generación de contenido o asistentes para empleados. Son casos fáciles de explicar en una presentación. Pero parte del valor puede estar en procesos menos vistosos: back office, conciliaciones, documentación interna, soporte técnico, clasificación de incidencias, operaciones financieras o revisión de cumplimiento. MIT NANDA advierte de un sesgo de inversión hacia funciones de front office, pese a que algunas automatizaciones internas pueden ofrecer retornos más claros.
Qué diferencia a una empresa AI-native
Una empresa AI-native no es la que más licencias tiene ni la que más veces menciona agentes en sus presentaciones. Es la que reorganiza su forma de trabajar para que la IA participe de manera segura y medible en los flujos centrales.
Eso implica que un proceso no se diseña pensando solo en personas que hacen clic en pantallas, sino también en agentes que leen, proponen, ejecutan y escalan. Implica que los datos deben estar ordenados, las APIs documentadas, las reglas de negocio explícitas y las excepciones bien definidas. Implica también que los equipos humanos pasan de hacer tareas repetitivas a revisar, decidir, entrenar, corregir y mejorar sistemas.
En una compañía tradicional, la IA ayuda a un empleado a redactar un correo. En una compañía AI-native, el sistema detecta qué cliente necesita seguimiento, prepara el borrador con contexto, comprueba límites comerciales, sugiere la siguiente acción, lo deja pendiente de aprobación y actualiza el historial. La diferencia no está en la redacción. Está en el flujo completo.
En una compañía tradicional, el equipo de soporte usa IA para resumir tickets. En una AI-native, los tickets se clasifican, se enriquecen con historial, se comparan con casos similares, se proponen respuestas citando fuentes internas, se detectan patrones de producto y se generan tareas para ingeniería cuando aparece una incidencia repetida.
En una compañía tradicional, marketing pide ideas de contenido a un modelo. En una AI-native, el sistema cruza datos de búsqueda, rendimiento histórico, inventario de contenidos, campañas activas y calendario comercial para proponer un plan editorial, generar borradores, preparar variantes por canal y medir resultados.
La métrica equivocada: uso frente a impacto
Uno de los errores más comunes es medir adopción de IA con métricas de actividad: número de licencias activas, prompts enviados, usuarios mensuales, pilotos lanzados o agentes creados. Son datos útiles para saber si la herramienta se usa, pero no dicen si cambia el negocio.
Las métricas que importan son otras: reducción del tiempo de ciclo, aumento de conversión, menor tasa de error, reducción de backlog, mejora de satisfacción de cliente, ahorro operativo, incremento de capacidad por equipo, menor tiempo hasta resolución, mayor calidad de documentación o más velocidad de despliegue. La IA debe evaluarse como cualquier otra inversión tecnológica: por impacto, no por entusiasmo.
McKinsey apunta que solo el 39 % de los encuestados atribuye algún impacto de la IA en el EBIT a nivel empresarial, y la mayoría de quienes lo reportan dice que ese impacto representa menos del 5 % del EBIT. Al mismo tiempo, muchos sí perciben mejoras cualitativas en innovación, satisfacción de empleados, satisfacción de clientes y diferenciación competitiva.
Esa mezcla explica el momento actual. La IA ya se nota, pero todavía no siempre se traduce en cuenta de resultados. El valor existe, pero está mal capturado o demasiado disperso. La siguiente fase consistirá en convertir beneficios individuales en cambios de proceso y cambios de proceso en resultados financieros.
Una hoja práctica para salir del atasco
El primer paso es separar inventario de estrategia. Saber qué herramientas se usan, en qué equipos, con qué coste y para qué tareas. Muchas organizaciones descubrirán que tienen más IA de la que creen, pero menos control del que necesitan.
El segundo paso es escoger procesos, no tecnologías. En lugar de «vamos a desplegar agentes», conviene elegir tres procesos concretos: cualificación de leads, triaje de tickets, revisión de contratos, soporte interno, reporting financiero, gestión de incidencias o actualización de contenidos. Cada proceso debe tener una métrica de negocio asociada.
El tercer paso es rediseñar antes de automatizar. Automatizar un proceso malo solo lo hace fallar más rápido. Hay que simplificar pasos, eliminar aprobaciones innecesarias, ordenar datos, definir excepciones y establecer cuándo entra una persona.
El cuarto paso es crear una arquitectura de confianza: permisos mínimos, auditoría, evaluación, logs, entornos de prueba, control de versiones de prompts y herramientas, revisión humana para acciones sensibles y seguimiento de costes.
El quinto paso es formar perfiles híbridos. La IA empresarial no será solo cosa de científicos de datos. Harán falta responsables de proceso, product owners de IA, arquitectos de datos, especialistas en seguridad, equipos legales, diseñadores de experiencia y usuarios avanzados capaces de traducir el trabajo real en sistemas automatizables.
La IA no está fallando porque falten modelos. Está fallando donde se intenta meter una tecnología nueva en una organización vieja sin tocar nada más. Comprar herramientas era el primer paso. El paso que separará a unas empresas de otras será rediseñar la carretera.
Preguntas frecuentes
¿Por qué muchas empresas usan IA pero no obtienen transformación real?
Porque la aplican como herramienta individual sobre procesos existentes. El cambio aparece cuando la IA se integra en flujos de trabajo, datos, permisos, métricas y decisiones operativas.
¿Qué significa ser una empresa AI-native?
Significa diseñar procesos, roles y sistemas teniendo en cuenta que la IA puede leer, proponer, actuar y aprender bajo supervisión. No es solo comprar modelos o licencias.
¿Qué diferencia hay entre piloto y escalado de IA?
Un piloto prueba un caso concreto. El escalado implica llevar la solución a varias funciones o equipos, con gobierno, soporte, seguridad, control de costes y métricas de impacto.
¿Los agentes de IA son el siguiente paso lógico?
Sí, pero no deberían desplegarse sin arquitectura. Un agente necesita permisos, acceso controlado a datos, auditoría, validación humana y límites claros sobre qué puede ejecutar.
¿Cuál debería ser la primera acción de una empresa?
Elegir un proceso de alto impacto y rediseñarlo de extremo a extremo con IA integrada. Después debe medir resultados concretos antes de extender el modelo a más áreas.
