De las licencias a la capacidad: cómo abordar la adopción de IA en una organización

En el artículo anterior planteaba una idea sencilla: proporcionar una licencia de inteligencia artificial no transforma una empresa. Tener acceso a ChatGPT, Copilot, Claude o cualquier otra herramienta puede ser útil. Puede mejorar tareas concretas e incluso producir incrementos importantes de productividad individual. Pero desplegar una herramienta y transformar la forma de trabajar son problemas diferentes. De ahí parte este análisis: ¿cómo deberíamos abordar la adopción de IA dentro de una organización?

El punto de partida es el trabajo: identificar dónde la inteligencia artificial permite trabajar mejor y construir las condiciones para que esa mejora sea sostenible. Ese criterio cambia el enfoque.

Este es un marco de criterio profesional para orientar la adopción. Cada organización necesita contrastarlo con su trabajo, sus riesgos y una medición propia antes de atribuir resultados.

La tecnología no es el punto de partida

Las decisiones sobre asistentes, modelos, plataformas de agentes, entornos de desarrollo o proveedores llegan demasiado pronto si todavía no sabemos qué queremos transformar. El inventario inicial debe describir el trabajo que realiza la organización: sus decisiones, puntos de fricción y tareas recurrentes. Interesa localizar las búsquedas de información, los traslados de datos entre sistemas, los documentos repetitivos y las revisiones que podrían sistematizarse. También los cuellos de botella y las decisiones que obligan a consultar varias fuentes. Es ahí donde empezaría a buscar oportunidades. Preguntaría «¿Qué trabajo merece la pena mejorar y qué papel podría desempeñar la IA en esa mejora?». Así se diseña alrededor del problema.

Automatizar exige decidir el nivel de intervención

Después conviene clasificar las oportunidades, porque utilizar IA no implica necesariamente automatizar. En algunos casos queremos simplemente asistir a una persona. En otros queremos aumentar su capacidad. En otros podemos automatizar una parte del proceso. Y habrá situaciones donde tenga sentido automatizar prácticamente el flujo completo. Son niveles diferentes de intervención. Un profesional puede utilizar IA para explorar alternativas antes de tomar una decisión. Puede recibir una propuesta que después revisa. Puede delegar determinadas tareas y conservar los puntos de decisión importantes. O puede supervisar únicamente las excepciones de un proceso que funciona de forma autónoma la mayor parte del tiempo. No existe una respuesta universalmente mejor.

Depende del riesgo, la frecuencia, la reversibilidad de los errores, la calidad que podamos medir, los datos disponibles y el coste de una decisión incorrecta. Por eso no utilizaría como indicador de madurez el porcentaje de procesos automatizados. Una organización madura también debe saber qué no automatizar.

Antes de mejorar algo necesitamos saber cómo funciona hoy

Establecer una línea base es un paso poco vistoso y fundamental. Para distinguir una mejora real de una impresión, hay que conocer el tiempo y el coste del proceso, las personas implicadas, los errores y el retrabajo, el esfuerzo de revisión, el tiempo de aprendizaje, los puntos problemáticos y la calidad obtenida. No hace falta convertir cada iniciativa en un proyecto científico, pero sí conservar una referencia suficiente, porque con IA existe un sesgo especialmente peligroso: la velocidad es muy visible.

Vemos aparecer en segundos un documento que antes requería una hora. Vemos generarse en minutos código que habría llevado una mañana. Vemos resumirse cientos de páginas casi inmediatamente. La mejora parece evidente. Pero quizá ahora necesitamos veinte minutos adicionales para verificar el documento. Quizá el código genera más retrabajo posteriormente. Quizá el resumen ha eliminado información importante. Quizá hemos reducido el tiempo de ejecución de una tarea y aumentado el coste del proceso completo. Sin una referencia anterior es muy difícil saberlo.

Y aquí suele aparecer la parte difícil

Sobre el papel, analizar un proceso, establecer una línea base y rediseñarlo parece una secuencia ordenada. En una organización real rara vez lo es. Podemos descubrir que el proceso no está documentado, que diferentes equipos lo ejecutan de formas distintas, que nadie conoce realmente cuánto tiempo consume, que una parte de las decisiones depende de conocimiento que nunca se ha formalizado, que necesitamos datos a los que no podemos acceder, que la seguridad o la regulación impiden utilizar determinada información o que automatizar una tarea obliga primero a resolver problemas de integración acumulados durante años.

También podemos descubrir que las personas que participan en el proceso no consideran que el problema que hemos decidido resolver sea su principal problema. En ocasiones, el primer resultado de una iniciativa de IA no será un agente ni una automatización. Será descubrir que antes necesitamos simplificar el proceso, normalizar datos, aclarar responsabilidades o acordar criterios que hasta entonces eran implícitos. Eso no significa que el proyecto haya fracasado. Significa que la IA ha hecho visible una deuda organizativa que ya existía. Rediseñar el trabajo no es únicamente un problema tecnológico. También implica decisiones organizativas, cambios de hábitos, negociación entre equipos y gestión del cambio.

Diseñar la intervención antes de elegir la solución

Una vez identificado el problema y conocida la situación de partida —normalmente mediante iteraciones de exploración, diseño, evaluación y aprendizaje—, hay que diseñar cómo debe funcionar el nuevo trabajo. La cuestión es qué debería hacer el sistema. Supongamos que queremos mejorar un proceso que implica analizar documentación, consultar información corporativa y generar una recomendación. El modelo puede ayudarnos a interpretar los documentos y producir una respuesta. Pero todavía debemos decidir qué fuentes puede utilizar y con qué permisos, qué resultado esperamos y cómo se verifica. También cuándo interviene una persona, cómo responde el sistema ante información insuficiente o contradictoria y qué se registra para reconstruir lo sucedido. Estas decisiones forman parte de la solución tanto como el propio modelo. Por eso una automatización que funciona correctamente en una demostración puede estar muy lejos de ser un proceso preparado para funcionar dentro de una organización.

Separar asistencia, automatización y autonomía

También conviene separar soluciones muy diferentes que suelen reunirse bajo la etiqueta de «IA». Un asistente personal, una tarea automatizada y un agente que actúa sobre varios sistemas exigen controles distintos. A medida que aumenta la autonomía, cambian los permisos, los límites de actuación y la gestión de errores. También ganan peso la observabilidad, la recuperación y la autorización previa de las acciones irreversibles. La conversación tecnológica sobre agentes suele centrarse mucho en lo que son capaces de hacer.

En producción me preocupa al menos tanto cómo se comportan cuando algo falla. La autonomía debería crecer junto con nuestra capacidad para observar, limitar y evaluar el sistema. No antes.

Construir contexto organizativo reutilizable

Hay otra diferencia importante entre el uso individual y la capacidad organizativa. Cuando una persona aprende a utilizar muy bien una herramienta de IA puede acumular una cantidad enorme de conocimiento implícito: sabe cómo proporcionar contexto, qué documentos utilizar, qué instrucciones funcionan, qué errores suele cometer el modelo y qué comprobaciones debe realizar. Ese conocimiento puede producir una productividad individual considerable. Pero si permanece exclusivamente en la cabeza de esa persona, la organización no ha construido todavía una capacidad. Parte del trabajo consiste precisamente en externalizar ese conocimiento cuando sea posible mediante instrucciones, ejemplos, bases de conocimiento, herramientas, evaluaciones y controles reutilizables. Cada decisión que se sistematiza reduce la cantidad de conocimiento que otra persona tiene que reconstruir desde cero. Ese es uno de los puntos donde empezamos a pasar de productividad individual a capacidad organizativa.

Pero no intentaría convertir todo el criterio en instrucciones

Aquí pondría un límite importante. Cuando descubrimos que una persona obtiene resultados mucho mejores utilizando IA, resulta tentador intentar capturar exactamente cómo trabaja. Podemos documentar sus instrucciones, construir una capacidad reutilizable (skill), añadir ejemplos, definir un agente e incorporar reglas. Todo eso puede ser valioso. Pero existe conocimiento que no se transfiere de esa manera. Un desarrollador experimentado puede detectar que una implementación, aun funcionando, está conceptualmente mal diseñada. Un profesional de un dominio puede identificar que una respuesta aparentemente correcta ignora una excepción importante. Una persona con experiencia puede decidir que el problema planteado no es realmente el problema que deberíamos resolver. Podemos conseguir que la IA reproduzca determinados procedimientos.

Es mucho más difícil encapsular completamente el criterio que decide cuándo esos procedimientos dejan de ser adecuados. Por eso construir capacidad organizativa tiene dos componentes: uno tecnológico y otro humano. La IA no elimina la necesidad de desarrollar conocimiento profesional, pero cambia dónde utilizamos ese conocimiento.

La formación tendría que estar ligada al trabajo real

Por la misma razón, la formación debería ir más allá de un curso general sobre redacción de instrucciones para toda la compañía. Hay conocimientos comunes que merece la pena compartir: funcionamiento básico de los modelos, contexto, privacidad, seguridad, verificación y limitaciones. Después, la adopción debe acercarse al trabajo real de cada colectivo. Las técnicas, los riesgos y los mecanismos de verificación de un desarrollador, una persona de producto o quien atiende incidencias son diferentes. Cada cual necesita aprender a ejercer mejor su profesión utilizando IA, incluido cuándo prescindir de ella.

Explorar antes de sistematizar

Una parte de las oportunidades de la IA puede identificarse analizando procesos de forma estructurada. Pero no asumiría que todas van a aparecer así. Las personas que realizan el trabajo diariamente suelen descubrir usos que no estaban previstos inicialmente: una forma diferente de consultar información, una tarea que puede delegarse parcialmente, una comprobación que puede sistematizarse o una combinación de herramientas que elimina una fricción aparentemente pequeña. Por eso dejaría también espacio para la experimentación descentralizada. Proporcionaría acceso dentro de unos límites claros de seguridad, privacidad y uso de la información, permitiría experimentar y observaría qué patrones aparecen. No intentaría industrializar inmediatamente cada uso individual.

Primero hay que distinguir entre una mejora puntual y una capacidad que merece convertirse en algo reutilizable. El recorrido avanza desde la exploración y la observación hasta la selección, el diseño, la medición, la sistematización y la ampliación.

Explorar permite encontrar oportunidades; diseñar, medir y sistematizar permite convertirlas en capacidad organizativa.

Ver a tamaño originalCerrar

La exploración puede surgir desde los propios equipos. La capacidad organizativa aparece cuando conseguimos convertir los aprendizajes que funcionan en procesos, conocimiento, herramientas y patrones reutilizables. El descubrimiento descentralizado puede encontrar oportunidades. La sistematización es lo que permite convertirlas en capacidad organizativa.

La adopción no debe ser homogénea

La adopción no tiene por qué ser homogénea. No todas las personas tienen las mismas necesidades. No todos los equipos trabajan con los mismos procesos. No todos los casos de uso producen el mismo retorno. Y no todos los usuarios están preparados para utilizar el mismo nivel de autonomía. Por eso conviene comenzar por colectivos y procesos cuyo impacto pueda observarse con claridad. Los problemas deben ser relevantes y, a la vez, estar suficientemente acotados para evaluarlos junto con quienes conocen el proceso. A partir de ahí se construyen patrones reutilizables, se mide el resultado, se corrige y solo entonces se amplía el alcance.

Eso puede parecer más lento que desplegar miles de licencias simultáneamente. El despliegue solo da acceso; la adopción cambia prácticas, y la transformación cambia la forma de trabajar.

La gobernanza debería acompañar al diseño, no aparecer al final

Otro error sería construir primero y preguntar después a seguridad, legal, datos o arquitectura si podemos ponerlo en producción. La gobernanza debe formar parte del diseño. Hay que decidir qué información utiliza cada solución, dónde se procesa, quién accede y qué acciones puede realizar. También cómo se registran las operaciones, cómo se evalúan las nuevas versiones y cómo se responde a un aumento de coste o a la desaparición del proveedor.

Cuanto más profundamente integremos IA en los procesos de una organización, más importantes serán estas preguntas, porque dejamos de utilizar una herramienta auxiliar y empezamos a construir dependencia operativa.

Introducir la evaluación desde el principio

Si tuviera que elegir una disciplina que muchas iniciativas de IA todavía infravaloran, sería la evaluación. En el software tradicional está asentada la exigencia de probar lo que se construye. Con sistemas basados en modelos probabilísticos necesitamos ampliar esa disciplina. No basta con probar varias veces el sistema y comprobar que «parece funcionar». Necesitamos conjuntos representativos de casos normales, límite y problemáticos; resultados esperados; criterios de calidad; evaluaciones automáticas cuando sean posibles; revisión humana cuando sea necesaria; y mecanismos para detectar regresiones cuando cambiamos instrucciones, modelos, herramientas, fuentes o contexto. Esto es especialmente importante porque estos sistemas evolucionan continuamente. Podemos modificar un prompt y mejorar veinte casos mientras empeoramos otros diez.

Podemos cambiar de modelo y alterar comportamientos que dábamos por supuestos. Podemos añadir una nueva fuente de información y provocar respuestas diferentes. Si una capacidad de IA se convierte en parte de un proceso empresarial, su comportamiento también necesita un ciclo de vida de ingeniería.

Medir el sistema completo

Después llega probablemente la parte más difícil: decidir si hemos mejorado. Las métricas de adopción —usuarios, conversaciones o producción— describen el uso, pero su alcance no demuestra valor. La medición debe abarcar el tiempo de ciclo, el coste por resultado, la calidad, el retrabajo y el resultado que justificaba la iniciativa. Hay una pregunta que utilizaría continuamente:

¿Qué podemos hacer ahora mejor que antes y qué evidencia tenemos de ello?

Si no podemos responderla, probablemente todavía no sepamos si nuestra iniciativa de IA está funcionando.

Medir también los efectos secundarios

Además, vigilaría algo que las métricas de productividad pueden esconder. Una mejora local puede generar un problema en una fase posterior. Un equipo puede producir especificaciones más rápido y saturar al equipo que debe implementarlas. Los desarrolladores pueden generar código más deprisa y aumentar la carga de revisión. Podemos automatizar respuestas y multiplicar posteriormente las reclamaciones. Podemos generar más contenido y trasladar el cuello de botella a quienes deben validarlo. La IA puede mover el problema en lugar de resolverlo. Por eso no mediría únicamente la tarea asistida por la IA. Mediría el flujo de valor completo en el que esa tarea participa. Esta diferencia resulta fundamental. Optimizar una actividad no significa necesariamente optimizar el sistema.

Extender patrones, no experimentos

Solo después empezaría a plantear seriamente la ampliación. Cuando una iniciativa demuestra valor, intentaría entender qué parte puede reutilizarse. Quizá sea una integración, una arquitectura, una forma de evaluar, un conjunto de controles, una skill, una base de conocimiento, un patrón de interacción, una infraestructura común, una política o una forma de medir. Ese conocimiento reutilizable es mucho más importante que copiar exactamente una solución, porque diferentes departamentos pueden tener problemas distintos, pero compartir capacidades. Ahí es donde una organización empieza a construir una plataforma interna alrededor de la IA en lugar de acumular experimentos independientes y donde arquitectura, seguridad, datos, ingeniería y gobierno empiezan a aportar componentes y servicios compartidos que agilizan el trabajo, en lugar de convertirse en controles añadidos posteriormente.

El objetivo es mejorar el valor del trabajo

Una estrategia madura de adopción de IA tiene como objetivo maximizar el valor del trabajo, no el uso de la tecnología. Habrá procesos donde la IA produzca una transformación enorme; otros donde aporte una mejora incremental; otros donde una automatización convencional sea más sencilla, barata y fiable; y algunos donde no merezca la pena cambiar nada. Ser capaz de distinguirlos también forma parte de la madurez. Por eso no mediría el éxito de una estrategia de IA por cuántas licencias hemos desplegado, cuántos agentes hemos construido o cuántos procesos contienen un modelo.

Lo mediría por nuestra capacidad para hacer cosas que antes no podíamos hacer, hacer mejor las que ya hacíamos o hacerlas con menos recursos sin trasladar el coste a otro lugar.

De utilizar herramientas a construir una capacidad

Proporcionar acceso a inteligencia artificial puede hacerse relativamente rápido. Construir capacidad organizativa exige entender el trabajo, diseñar procesos, integrar sistemas, establecer controles y aprender antes de ampliar. La tecnología es una parte imprescindible, aunque la transformación ocurre alrededor de ella. La cuestión decisiva es qué tendría que cambiar en nuestra forma de trabajar para que la IA produzca una mejora real.

La diferencia entre ambas preguntas es, probablemente, la diferencia entre desplegar una herramienta y construir una capacidad. El siguiente problema es demostrar si ese cambio está produciendo realmente valor: «Cómo saber si la IA está aumentando realmente la productividad». La diferencia se observa al comprobar si la organización continúa adoptando herramientas o ya está rediseñando sus procesos y formas de trabajo alrededor de la IA.