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.

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 clasificaría las oportunidades por el reparto de trabajo que necesitan. Un profesional puede utilizar IA para explorar alternativas y decidir por sí mismo, revisar una propuesta antes de aplicarla o delegar tareas dentro de límites. En un proceso suficientemente conocido, quizá pueda supervisar solo las excepciones. Son grados distintos de intervención; automatizar más pasos no mejora necesariamente el resultado.

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.

A medida que aumenta la autonomía, hay que precisar los permisos, los límites, la recuperación y la autorización previa de las acciones irreversibles. En producción me preocupa tanto lo que el sistema puede hacer como su comportamiento cuando falla. La autonomía debería crecer junto con la capacidad para observarlo, limitarlo y evaluarlo.

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.

Cuando el proceso todavía no está claro

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.

Construir contexto organizativo reutilizable

Cuando una persona aprende a utilizar una herramienta de IA, reúne conocimiento práctico: qué contexto aportar, qué documentos consultar, qué errores esperar y cómo revisar la respuesta. Si todo permanece en su cabeza, las demás personas tienen que reconstruirlo al empezar.

Documentaría lo que se pueda compartir mediante instrucciones, ejemplos, fuentes, herramientas, evaluaciones y controles reutilizables. La capacidad organizativa empieza a construirse cuando otra persona puede aplicar y comprobar esa práctica sin depender de quien la descubrió.

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 adopción no debe ser homogénea

Cada equipo necesita un alcance distinto según sus procesos, la preparación de las personas y el resultado que se pueda comprobar. 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

Definiría la evaluación antes de ampliar el uso. Probar varias veces el sistema y comprobar que «parece funcionar» deja sin resolver qué calidad se acepta y qué fallo obliga a detenerlo. Necesitamos casos normales, límite y problemáticos, resultados esperados y criterios que puedan comprobarse mediante pruebas automáticas o revisión humana.

Cada cambio de instrucciones, modelo, herramientas, fuentes o contexto debe activar las comprobaciones correspondientes. 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. El ahorro de una tarea pierde sentido si obliga a otra persona a dedicar más tiempo a corregirla.

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.

Para comprobar si esa mejora existe, continúo con cómo medir la productividad de la IA: qué línea base conservar, qué costes incluir y cómo distinguir el tiempo de ejecución del resultado que recibe la organización.