¿Qué es la adopción de la IA?

Cómo funciona

La adopción de la IA se entiende mejor como una secuencia de etapas, cada una con su propio propósito y su propia forma de salir mal. Las etapas no son rígidamente lineales, habrá retrocesos, pero sí se construyen unas sobre otras. Saltarse las primeras es la causa más común de fracasos costosos más adelante.

Evaluar la preparación: datos, habilidades, infraestructura y liderazgo

La preparación es un inventario honesto que se realiza antes de gastar dinero, no después. La pregunta que responde no es "¿estamos entusiasmados con la IA?", sino "¿tenemos lo necesario para que un uso específico de la IA funcione de manera fiable?". Cuatro áreas son las más importantes.

Los datos son lo primero, porque son la razón más común por la que los proyectos se derrumban. La IA trabaja con la información que se le proporciona, y la mayoría de las organizaciones descubren que sus datos están dispersos entre sistemas, son inconsistentes, están desactualizados o están bloqueados en formatos difíciles de usar. Un piloto a menudo tiene éxito con una muestra limpia y curada, y luego fracasa en el mundo real porque los datos de producción son desordenados. Evaluar la preparación de los datos significa preguntarse qué información se tiene, dónde reside, si es suficientemente precisa y si los sistemas que la almacenan pueden conectarse a las herramientas que se quieren usar. Es un trabajo poco glamuroso y es donde suele residir la dificultad real.

Las habilidades ocupan el segundo lugar, pero no de la manera que la gente teme. Para la mayoría de las organizaciones que adoptan la IA a través de herramientas disponibles en el mercado, la necesidad no es un equipo de científicos de datos. Lo que se necesita es contar con personas que entiendan tanto la tecnología como el proceso de negocio lo suficiente como para tender un puente entre ambos, y tener suficiente confianza general en toda la organización para que una nueva forma de trabajar sea adoptada en lugar de ignorada en silencio. Las preguntas más profundas sobre habilidades y personas, formación, confianza, resistencia, corresponden al artículo complementario sobre personas y cultura, pero una evaluación de preparación debería al menos identificar dónde están las brechas.

La infraestructura suele ser un obstáculo menor de lo que los líderes esperan. Las herramientas modernas de IA son en gran medida basadas en la nube y están diseñadas para conectarse a los sistemas existentes a través de interfaces estándar. Las preguntas que vale la pena hacerse son si los sistemas actuales pueden comunicarse con las herramientas de IA, si la postura de seguridad es lo suficientemente sólida para conectarlos de forma segura y cuánto costarían las actualizaciones necesarias. Para muchas organizaciones más pequeñas, la respuesta honesta es que la infraestructura es adecuada y el trabajo real está en los datos y los procesos.

El liderazgo es el multiplicador silencioso. Las organizaciones que obtienen valor de la IA son consistentemente aquellas cuyos directivos asumen el esfuerzo, marcan la dirección y se mantienen comprometidos en lugar de delegarlo y pasar a otra cosa. Una evaluación de preparación debe confirmar que existe un patrocinio genuino, un sentido acordado de para qué sirve la IA y voluntad de financiar los cimientos poco glamurosos. Cuando el liderazgo trata la IA como el proyecto de otra persona, la adopción tiende a estancarse independientemente de la tecnología.

Una revisión práctica de la preparación no tiene por qué ser un ejercicio extenso. Para una organización pequeña o mediana, puede consistir en unas pocas semanas de trabajo enfocado en examinar honestamente los datos, los procesos, las personas y los sistemas, y valorar dónde están las brechas. El objetivo es resolver los problemas baratos antes de que se conviertan en problemas costosos.

Identificar y priorizar casos de uso

Un caso de uso es una aplicación específica de la IA a una tarea empresarial concreta, con un resultado que se puede medir. "Usar la IA en marketing" no es un caso de uso. "Redactar primeras versiones de correos electrónicos a clientes para que el equipo dedique menos tiempo a la escritura rutinaria" sí lo es.

El error más común en esta etapa es elegir el caso de uso antes de entender el proceso subyacente. Los líderes tienden a elegir el trabajo que parece más doloroso o más visible, enmarcarlo como algo que la IA debería hacer y asegurar el presupuesto, todo antes de que nadie haya examinado si los datos existen o si el proceso es lo suficientemente consistente para sustentarlo. La disciplina que previene esto es comenzar reuniendo una lista amplia de usos candidatos y luego filtrar con rigor.

El filtrado viene antes que la puntuación. Cada idea debe pasar por un conjunto de preguntas simples de sí o no: ¿aborda un problema real y recurrente?; ¿existen datos utilizables?; ¿es el proceso lo suficientemente consistente para soportar una herramienta?; ¿está permitido bajo las normas aplicables?; ¿alguien usará realmente el resultado? Las ideas que fallan en datos o riesgo se descartan de inmediato, por atractivo que parezca su valor. Solo las que superan el filtro se puntúan.

La puntuación se realiza habitualmente en dos ejes: cuánto valor generaría el uso y cuán factible es llevarlo a cabo. Representar los candidatos en esa cuadrícula produce cuatro grupos. Alto valor y alta factibilidad son las victorias rápidas con las que empezar. Alto valor y baja factibilidad son apuestas estratégicas hacia las que avanzar una vez que se ha aprendido más. Bajo valor y alta factibilidad son tareas menores que vale la pena hacer si hay capacidad disponible. Bajo valor y baja factibilidad se descartan. Los primeros usos que se persigan deben ser victorias rápidas, no porque sean los más valiosos, sino porque financian y reducen el riesgo de todo lo que viene después. Los resultados tempranos y visibles generan la confianza y el presupuesto para el trabajo más difícil que vendrá después.

Para quien adopta la IA por primera vez, los candidatos más sólidos tienden a compartir un patrón: tareas repetitivas, con mucho texto, que siguen un proceso claro, ocurren con frecuencia y producen un resultado que un humano puede verificar fácilmente antes de que salga. Redactar correspondencia rutinaria, resumir documentos extensos, organizar el conocimiento, gestionar consultas habituales de clientes con una ruta clara hacia un humano: estos usos están bien trillados porque funcionan. Este patrón se confirma en la práctica: entre las empresas del Reino Unido que ya usan IA, el 85 por ciento la utiliza para procesamiento del lenguaje natural y generación de texto, con diferencia la aplicación más común. Es prudente centrarse en un número reducido de usos con el retorno más claro, en lugar de las ideas más emocionantes, y resistir el impulso de hacer todo a la vez.

Una nota sobre dónde reside realmente el valor. Existe una tendencia persistente a volcar el esfuerzo en usos orientados al cliente y al marketing porque son visibles, cuando algunos de los retornos más sólidos se reportan en trabajos de back-office menos glamurosos, como el procesamiento de documentos, la recuperación de conocimiento interno y la administración rutinaria. Seguir lo visible en lugar de lo valioso es una trampa reconocida. Hay que elegir con base en evidencia, no en instinto.

El papel de los pilotos y las pruebas de valor

Un piloto es una prueba pequeña y deliberadamente limitada de un caso de uso en condiciones reales. Su función es reducir el riesgo y producir evidencia antes de comprometer dinero o disrupciones serias. La disciplina crucial es que un piloto debe estar acotado en el tiempo y debe tener su definición de éxito acordada por escrito antes de comenzar. La investigación es contundente al respecto: los proyectos con métricas de éxito definidas de antemano tienen tasas de éxito mucho más altas que los que no las tienen, y una gran proporción de los proyectos fallidos no tenía ninguna definición de éxito acordada.

Dos ideas se confunden a menudo aquí, y la distinción es genuinamente útil. Una prueba de concepto responde a la pregunta "¿puede esto funcionar en absoluto?". Es una verificación técnica: ¿puede la herramienta hacer lo que se le pide, con nuestro tipo de datos, con un estándar aceptable? Una prueba de valor responde a una pregunta diferente y más importante: "¿vale la pena hacerlo?". Va más allá de si la herramienta funciona para determinar si realmente ahorra tiempo, reduce costes, mejora la calidad o aumenta los ingresos una vez integrada en un proceso real, y si las personas la usarán. Una prueba de concepto puede superarse mientras una prueba de valor falla. La herramienta funciona, pero el ahorro es demasiado pequeño, o el cambio en el flujo de trabajo es demasiado disruptivo, o nadie confía suficientemente en el resultado como para depender de él.

Para la mayoría de las adopciones ordinarias, la prueba de valor es la que importa. Es perfectamente posible confirmar que la IA puede redactar los informes y aun así concluir que no debería hacerlo, porque el tiempo ahorrado queda absorbido por el tiempo dedicado a verificar. Un buen piloto, por tanto, mide el efecto real sobre la tarea real frente a una línea base capturada previamente, no solo si la tecnología se comporta correctamente.

Un piloto bien ejecutado tiene un alcance estrecho, un límite de tiempo fijo medido en semanas en lugar de meses abiertos, una línea base de cómo se realiza la tarea hoy, dos o tres medidas de éxito claras y una decisión incorporada al final. Esa decisión tiene tres opciones honestas: escalarlo, detenerlo o ajustarlo y volver a probarlo. La disposición a detenerse es una característica, no un fracaso, y se aborda más adelante.

Una advertencia sobre los pilotos que parecen mejores de lo que son. Un piloto ejecutado por un grupo seleccionado de entusiastas en casos relativamente fáciles producirá resultados halagadores que no sobrevivirán al contacto con el resto de la organización y los casos más difíciles. Un piloto que mide el entusiasmo en lugar de la adopción genuina es engañoso. Los pilotos más fiables están acotados a una tarea única y bien definida con un resultado medible, y se prueban en condiciones realistas en lugar de ideales.

Pasar del piloto a la producción: el paso más difícil

Aquí es donde mueren la mayoría de los recorridos de adopción, y donde los líderes son sorprendidos con más frecuencia. La brecha entre un piloto exitoso y un sistema de producción funcional es tan común que tiene nombre: el purgatorio de los pilotos, o la brecha entre el piloto y la escala. En las principales encuestas, la mayoría de las organizaciones permanece en las etapas de experimentación o pilotaje, con solo alrededor de un tercio que declara haber comenzado a escalar sus programas de IA y solo alrededor del siete por ciento completamente escalado, y una gran proporción de pilotos que funcionan en el laboratorio nunca llegan a la operación cotidiana.

Las razones son principalmente organizativas, no técnicas. Un piloto funciona con un conjunto de datos curado que no existe en producción. Un piloto sirve a un grupo de usuarios amigables; la plantilla más amplia es más variada y más escéptica. Una tasa de error pequeña que parece manejable en un puñado de casos se convierte en una avalancha de excepciones a pleno volumen. Nadie es responsable del sistema una vez que está en funcionamiento, por lo que cuando su rendimiento se deteriora, nadie lo nota. La integración con los sistemas reales, la seguridad, el cumplimiento normativo y los bordes desordenados del trabajo real nunca se construyeron porque el piloto no los necesitaba.

Las organizaciones que cruzan esta brecha tienden a hacer algunas cosas de forma consistente. Diseñan los pilotos con las condiciones de producción en mente desde el principio, en lugar de construir un prototipo e intentar endurecerlo después, porque incorporar los requisitos de producción a posteriori suele ser más costoso que incluirlos desde el inicio. Acotan el alcance con precisión: los usos estrechos y de tarea única escalan de forma mucho más fiable que los amplios y abiertos. Establecen una titularidad clara, alguien responsable del sistema una vez que está en funcionamiento, incluido su seguimiento y la respuesta cuando algo sale mal. Y tratan el paso a producción como un cambio en la forma de trabajar, que es donde la dimensión humana y cultural se vuelve decisiva. Una herramienta que funciona técnicamente pero que las personas evitan no entrega nada.

La lección práctica es tratar "escalar" no como activar el piloto para todos, sino como un despliegue deliberado y por etapas: ampliar gradualmente el grupo de usuarios, exponer la herramienta a casos más difíciles, observar qué se rompe y construir la infraestructura de soporte sobre la marcha. Precipitar este paso es la forma en que los buenos pilotos se convierten en decepciones costosas.

Construir un modelo operativo de IA

A medida que más usos demuestran su valor y pasan a producción, la organización necesita una forma de gestionarlos todos de manera coherente. Eso es lo que es un modelo operativo: el conjunto de disposiciones que determinan cómo se posee, financia, gobierna y conecta al negocio el trabajo de IA. Sin él, cada equipo ejecuta sus propios experimentos en su propio calendario con sus propias herramientas, la gobernanza es irregular y el valor no se acumula. El modelo operativo es la diferencia entre un conjunto disperso de pilotos desconectados y un programa que se construye sobre sí mismo.

Para una gran empresa esto puede ser una estructura elaborada. Para una organización pequeña o mediana debe ser deliberadamente ligero, pero igualmente debe existir. Como mínimo, responde a un puñado de preguntas. Quién decide qué usos de IA se persiguen y en qué orden. Quién es responsable de cada uso activo una vez que está en funcionamiento. Qué reglas simples rigen dónde puede y no puede usarse la IA, cómo se verifica su trabajo y cómo se mantienen seguros los datos. Cómo se financia el trabajo de IA. Y cómo se hace seguimiento de los resultados para que la organización aprenda.

Tres elementos reaparecen en las descripciones fiables de un modelo operativo: una forma de estructurar quién hace qué, incluido cómo los equipos de negocio y el soporte técnico comparten la responsabilidad; una gobernanza que envuelve todo el esfuerzo para mantenerlo seguro y conforme a medida que crece; y una base de datos utilizables, bien gestionados y sistemas conectados. La gobernanza aquí no es burocracia por sí misma. Tratar el uso responsable, la seguridad y la protección de datos como una ocurrencia tardía es una vía documentada hacia el cierre de proyectos, a veces después de haber causado daño. Incorporar salvaguardas ligeras desde el principio es más barato que añadirlas tras un incidente.

Un patrón común y sensato para organizaciones medianas es un pequeño punto central de coordinación, a menudo una sola persona o un grupo reducido, que establece los estándares simples y ayuda a priorizar, combinado con equipos de negocio que son responsables de los usos más cercanos a su trabajo. Esto mantiene el esfuerzo conectado a los problemas reales del negocio y evita el libre albedrío que produce riesgo y desperdicio. El modelo operativo debe crecer a medida que crece el número de usos. Es un error construir maquinaria pesada antes de que haya algo que gestionar, y un error igualmente grave seguir escalando usos sin ninguna estructura.

Medir los resultados y el retorno

La medición es lo que convierte la actividad en conocimiento, y es donde muchos esfuerzos de adopción son más débiles. Una proporción llamativa de líderes declara no ver ni ahorro de costes ni crecimiento de ingresos derivados del gasto en IA, y una causa principal es que nunca establecieron la medición para averiguarlo. Hacer seguimiento de que el personal usa una herramienta no es lo mismo que demostrar que generó valor.

Una buena medición comienza antes del piloto, capturando una línea base: cuánto tiempo lleva la tarea hoy, cuánto cuesta, con qué frecuencia sale mal, qué produce. Sin una línea base, cualquier afirmación posterior de mejora es una suposición. Frente a esa línea base se hace seguimiento de un número reducido de medidas que importan para el uso específico: tiempo ahorrado, errores reducidos, coste por tarea, tiempo de ciclo, satisfacción del cliente o ingresos donde realmente aplica.

El retorno sobre la inversión, el valor obtenido frente al coste, es la medida que los líderes más desean y la que con más frecuencia se calcula mal. Tres errores son comunes. El primero es contar solo el coste obvio de construcción e ignorar el coste continuo de operar un sistema de IA, los cargos por uso, el mantenimiento, la verificación humana, que pueden crecer considerablemente a medida que el uso escala. Un uso que parecía viable en un piloto puede convertirse en una carga presupuestaria en producción una vez que esos costes operativos se multiplican entre muchos usuarios. El segundo es medir en un único punto en el tiempo, cuando las herramientas de IA pueden deteriorarse en rendimiento y necesitan atención continua para seguir entregando valor. El tercero es tratar cada uso de forma aislada en lugar de como una cartera, donde algunas apuestas dan resultado y otras no. Un cálculo realista del retorno sobre la inversión tiene en cuenta el coste total de propiedad a lo largo del tiempo, no solo el precio de comenzar.

También ayuda ser honesto sobre los plazos. El valor de la IA rara vez llega en el primer trimestre. La investigación del sector sugiere que la mayoría de las organizaciones tarda un año o más, a menudo de dos a cuatro años, en alcanzar el punto de equilibrio en una inversión seria en IA, mientras que la paciencia de los consejos de administración suele agotarse alrededor de los doce meses. Establecer las expectativas en consecuencia, y elegir usos tempranos que puedan mostrar un resultado rápidamente, protege el programa más amplio de ser interrumpido antes de que madure. Parte del valor también es genuinamente difícil de cuantificar, como decisiones más rápidas o una mejor experiencia del personal. Estos aspectos deben reconocerse y seguirse donde sea posible, pero no deben usarse como sustituto de los números concretos cuando estos están disponibles.