Adoptar la IA fue fácil: ahora toca la parte dura, adaptar el trabajo a ella

El artículo, firmado por un responsable de operaciones y adopción de IA en Canary Technologies (una tecnológica en fase de crecimiento con sede en San Francisco), parte de una distinción central: adoptar la IA no es lo mismo que adaptarse a ella. Según el autor, el periodo 2023-2025 fue el de la adopción, meter la tecnología en manos de todo el mundo, conectarla a los datos de la empresa y lograr que se use a diario, y ese tramo ya está prácticamente cerrado en las empresas más avanzadas en IA que observa. Lo que viene ahora es distinto y mucho más difícil: adaptar la forma de trabajar, la manera en que funciona el negocio y hasta la propia tecnología, hasta que las ganancias se noten en los números. Esa es la fase que, según él, apenas ha empezado.

La razón de que la adopción fuera 'la parte fácil' es que no tocó el fondo del trabajo. El autor describe la adopción como cuatro capas apiladas sobre el flujo de trabajo tal cual existía: acceso (una licencia y un plan de equipo), conectividad (los conectores y MCP que permiten al modelo llegar a los datos), uso (un modelo abierto todo el día, con prompts y 'skills' que se pasan de mano en mano) y aplicación (pequeñas herramientas y automatizaciones que cada persona incorpora a la parte de su propio trabajo que puede controlar). El patrón dominante, dice, fue dar acceso a todos y dejar que florecieran mil iniciativas distintas, un enfoque que considera acertado como primer paso, pero que tiene un techo estructural: cada persona solo puede mejorar el trozo de proceso que está bajo su control, nunca el proceso completo, porque las costuras entre tareas no pertenecen a nadie en concreto.

Este proceso de adopción trajo consigo dos efectos secundarios que, según el autor, nadie planificó. El primero es el 'contador de tokens': las licencias por equipo ocultaban el coste real, y al pasar a planes empresariales la facturación por consumo se dispara a un múltiplo del plan de equipo, justo cuando los grandes laboratorios de IA han recortado sus precios de lista entre un 20% y un 80% desde 2023. Es decir, cada token individual se abarata mientras la factura de la empresa sube, porque lo que de verdad falta es un precio asentado: ni los laboratorios han hecho público lo que les cuesta servir un token, ni las empresas compradoras saben todavía cuánto están dispuestas a pagar por uno. El autor señala que las interrupciones que más escucha este año no tienen que ver con que el modelo falle, sino con el acceso: equipos que chocan con un techo de crédito, presupuestos pensados por puesto que chocan con una facturación por consumo, herramientas que se quedan sin servicio a mitad de una reunión porque nadie vigilaba la tarjeta que las pagaba. Según recoge, los propios proveedores ya han empezado a suavizar ese salto ofreciendo un 'crédito de transición': un año de crédito subvencionado al pasar a plan empresarial, apostando a que el cliente aprenda a gestionar el consumo real antes de que se acabe el subsidio. El texto apunta además a un cambio de unidad de facturación, del 'por puesto' hacia modelos que combinan puesto y consumo o que facturan por unidad de trabajo (cita como ejemplos a Microsoft y a los agentes de Salesforce, y una proyección de Gartner sobre un fuerte crecimiento de este modelo de aquí a 2028); los proveedores ya han decidido cuál es la unidad, pero, según el autor, está mucho menos claro en qué presupuesto acaba cayendo ese gasto.

El segundo efecto secundario, más silencioso pero más importante según el autor, es justamente ese techo de alcance: las ganancias de productividad quedan atrapadas dentro del puesto de cada persona, porque cada quien solo puede aplicar la IA a la parte del proceso que puede cambiar. Eso explica por qué casi todo el mundo se siente más rápido mientras casi nadie puede demostrarlo todavía con un número. Las ganancias se ven antes en roles operativos, donde el trabajo de una persona se traduce directamente en una cifra medible, y permanecen invisibles en áreas donde el resultado solo se ve al final de un trimestre, como buena parte de ventas, marketing o éxito de cliente.

Para defender que el verdadero salto de productividad exige rediseñar procesos completos y no solo añadir IA encima de los ya existentes, el autor recurre a varios datos de encuestas citadas en el artículo. De una encuesta de McKinsey, señala que, entre veinticinco posibles palancas organizativas, 'rediseñar fundamentalmente los flujos de trabajo' fue la que más se asoció con que la IA se notara en los resultados financieros, aunque solo una quinta parte de las empresas que usan IA lo había hecho; en una encuesta posterior de McKinsey, ya citada como de este mismo año, cerca de tres cuartas partes de las empresas con mejor desempeño habían rediseñado sus flujos de trabajo, frente a solo una de cada cuatro del resto. Como contraejemplo cita el caso, ya conocido, de un estudio de campo en atención al cliente en el que un asistente de IA se incorporó a un proceso que ya realizaban cinco mil agentes, logrando una mejora del 15% en incidencias resueltas por hora, con el mayor beneficio para los agentes menos experimentados; el autor explica que este caso funcionó porque todo el trabajo ya ocurría dentro de una ventana de texto, una condición que no se da en la mayoría de los procesos de una empresa. También recoge, atribuido a McKinsey y referido a grandes empresas, que un 40% ya está escalando el uso de agentes de IA pero solo un 37% percibe algún impacto en el beneficio operativo (una cifra que no habría cambiado respecto al año anterior), y, citando a PwC a principios de año, que un 56% de los directivos no vio ninguna mejora en absoluto.

Una parte relevante del artículo se dedica a advertir sobre cómo se mide, o se mide mal, el impacto de la IA. El autor señala dos problemas: primero, las ganancias se producen persona a persona y tienden a diluirse en la media del equipo, ya que unos pocos empleados suelen concentrar buena parte del volumen de trabajo; segundo, y más importante, la propia herramienta de IA termina rellenando las métricas con las que se la evalúa (notas registradas, fichas actualizadas), de modo que el panel de control mejora antes de que el negocio haya cambiado realmente. Por eso defiende que la métrica fiable es otra: cuánto trabajo adicional absorbe un equipo sin contratar más personal, un indicador más lento, que tarda trimestres en manifestarse y que debe compararse con un punto de partida equivalente, descontando cambios de demanda o de plantilla, e incorporando también la calidad del trabajo y el coste de la propia IA. El autor advierte de que es normal, y hasta esperable, que la productividad medida empeore antes de mejorar mientras dura el rediseño, porque este se paga por adelantado en forma de horas de mapeo, reconstrucción y aprendizaje; una lectura plana a los seis meses podría ser simplemente esa fase intermedia y no un veredicto definitivo, aunque solo si hay evidencia de que las piezas ya rediseñadas son más rápidas o fiables sin trasladar el coste a otro lugar del proceso.

Otro bloque del artículo analiza la tendencia, todavía incipiente según el autor, de construir software propio y a medida para un puesto concreto, una especie de 'cabina de mando' que se apoya sobre los sistemas ya existentes (no sustituye a herramientas como Salesforce o Slack, sino que añade una capa de interacción). El texto sitúa esto en una perspectiva histórica: antes de la llegada del software empaquetado (SaaS), las empresas construían sus propias aplicaciones a medida; después, alquilar software estandarizado resultó más barato y se impuso durante años; las plataformas low-code llevan una década vendiendo exactamente ese regreso parcial hacia la construcción propia, dando lugar al fenómeno de los 'desarrolladores ciudadanos'. Lo verdaderamente nuevo con la IA, matiza el autor, no es que construir se haya abaratado (eso ya lo hizo el low-code), sino hasta dónde puede llegar alguien sin perfil técnico más allá de un editor visual. Esto traslada la pregunta clave al organigrama: si la construcción la asume el equipo de ingeniería de siempre, se obtiene una versión más rápida del mismo proceso; lo genuinamente distinto sería que el propio dueño del proceso construya la herramienta con ingenieros de apoyo, lo cual exige resolver cuestiones aún abiertas, como cuánto soporte técnico necesita cada herramienta, quién revisa lo que se pone en producción, qué condiciones deben cumplirse antes de que un equipo dependa de ella a diario, y cuándo debe la ingeniería asumir el control. El autor subraya que, por ahora, casi todo lo que observa es individual y discreto (alguien construye una pequeña herramienta para su propio trabajo y ni siquiera lo comunica), mientras que las aplicaciones a medida que sostienen a un equipo entero siguen siendo raras, más una frontera emergente que una práctica consolidada; además, escribir el código resulta rápido, pero verificar que es correcto no, lo que convierte la revisión en el nuevo cuello de botella, sin que esté resuelto quién es responsable de la herramienta cuando su creador original cambia de puesto.

En la última sección incluida en el material disponible, el autor empieza a desarrollar lo que llama los siete pasos necesarios para 'adaptarse' de verdad, de los cuales el texto recibido solo detalla los dos primeros. El primer paso es decidir, de forma activa y consciente, invertir en rediseñar un flujo de trabajo completo, partiendo de la base de que el valor de la IA dentro del proceso antiguo tiene un techo; a diferencia de la adopción, que ocurrió casi sola, el rediseño no sucede por inercia y exige una decisión explícita. El segundo paso es que ese rediseño necesita un propietario con autoridad real para cambiar el trabajo (alguien a nivel de función o área, capaz de reorganizar personas y agentes de IA en torno a una nueva forma de operar) y un presupuesto específico, ya que el mapeo del proceso, la reconstrucción y las horas de formación representan una inversión real que debe planificarse, algo que no hizo falta durante la fase de adopción, que encajaba dentro de presupuestos ya existentes.

Conviene advertir que el contenido descargado del artículo se corta de forma abrupta en mitad de una frase, justo al desarrollar ese segundo paso, por lo que el material recibido no incluye el desarrollo completo de los cinco pasos restantes que el propio índice del artículo anuncia (relacionados, según los titulares del sumario, con la unidad de trabajo, las dos formas de gasto, el mapa del proceso, el uso de más de un modelo, y la interfaz), ni el apartado final de conclusiones. Este resumen se ciñe estrictamente a lo que aparece de forma literal en el texto disponible y no completa ni especula sobre esas partes ausentes.