La empresa hizo lo correcto. Identificó un problema, probó una solución de inteligencia artificial, midió resultados y decidió escalarla. El piloto dejó de ser una demostración y comenzó a formar parte del trabajo cotidiano.
Ese era precisamente el objetivo. Pero el éxito introduce una pregunta nueva.
¿Qué ocurre cuando una herramienta de IA deja de ser opcional y comienza a convertirse en una pieza necesaria para operar?
En la columna anterior planteé que una organización no necesita acumular pilotos de inteligencia artificial, sino aprender a decidir cuáles deben ampliarse, cuáles necesitan ajustes y cuáles conviene abandonar. Escalar implica pasar de la experimentación a una capacidad empresarial estable: integrar datos, responsables, procesos, controles y métricas.
Sin embargo, existe un efecto menos visible.
Cada vez que una solución se integra más profundamente en la operación, también aumenta el número de conexiones que dependen de ella.
El modelo se conecta con datos. Los datos con una API. La API con una automatización. La automatización con un sistema interno. El sistema con decisiones humanas. Y, poco a poco, una herramienta que comenzó resolviendo una tarea puede convertirse en parte de la infraestructura de la empresa.
Escalar IA también puede escalar la dependencia.
La cuestión no es evitar toda dependencia tecnológica. Eso sería poco realista. Las organizaciones dependen de sistemas financieros, servicios en la nube, CRM, plataformas de comunicación, proveedores y aplicaciones especializada.
El problema aparece cuando la dependencia crece sin ser identificada, documentada o administrada.
Cuando una herramienta empieza a convertirse en infraestructura
Durante un piloto, cambiar de solución suele ser relativamente fácil.
Participan pocos usuarios, las integraciones son limitadas y el proceso original continúa disponible. Si la herramienta no funciona como se esperaba, la empresa puede corregirla, sustituirla o simplemente detener la prueba.
Cuando escala, la situación cambia.
Pensemos en un equipo comercial que comienza utilizando inteligencia artificial para redactar propuestas. Después decide conectarla con el CRM. Más adelante, la herramienta resume reuniones, clasifica oportunidades, genera correos de seguimiento, consulta documentos internos y recomienda próximas acciones.
El resultado puede ser valioso.
También puede crear una red de dependencias que no existía al iniciar el piloto.
Integrar aumenta el valor, pero también el costo de cambiar
Cada nueva conexión puede aumentar la utilidad del sistema. Al mismo tiempo, puede hacer más difícil sustituir una de sus piezas.
La pregunta deja entonces de ser únicamente:
¿Funciona?
Y comienza a ser:
¿Qué tan costoso sería cambiarlo?
Ese costo no siempre aparece en la factura del proveedor. Puede estar distribuido entre horas de desarrollo, capacitación, migración de datos, ajustes de prompts, reconstrucción de automatizaciones, nuevas pruebas, documentación y tiempo de adaptación de los usuarios.
Por eso, evaluar una solución de IA solamente por el costo de utilizarla ofrece una visión incompleta.
También deberíamos estimar el costo de dejar de utilizarla.
Las cinco dependencias que aparecen al escalar IA
Cuando se habla de dependencia tecnológica, suele pensarse inmediatamente en el proveedor. En inteligencia artificial el problema es más amplio.
Una solución puede crear dependencia del modelo, del proveedor, de los datos, del workflow y del conocimiento acumulado alrededor de su operación.
1. Dependencia del modelo
Los modelos no se comportan exactamente igual.
Un prompt que produce buenos resultados en un sistema puede necesitar modificaciones importantes en otro. Algunas aplicaciones dependen de determinadas ventanas de contexto, formatos de salida, herramientas, capacidades multimodales o mecanismos de razonamiento.
Eso significa que una empresa puede terminar diseñando un proceso alrededor de características particulares de un modelo.
No es necesariamente un error.
El riesgo aparece cuando nadie sabe si el proceso podría funcionar con otra opción.
En un mercado que evoluciona con rapidez, la capacidad de comparar modelos y probar alternativas debería formar parte del diseño, especialmente en procesos importantes.
No se trata de cambiar constantemente de tecnología.
Se trata de evitar que cambiar sea imposible.
2. Dependencia del proveedor
Aquí aparece el conocido vendor lock-in.
La dependencia puede crecer cuando una organización utiliza el mismo ecosistema para almacenar información, crear agentes, ejecutar automatizaciones, administrar permisos, conectar aplicaciones y conservar configuraciones.
Cuanto más valor obtiene de la integración, más difícil puede resultar migrar.
Por eso una decisión de compra debería incluir una pregunta que pocas veces aparece en las demostraciones comerciales:
¿Qué nos llevamos si decidimos salir?
Datos, configuraciones, historial, reglas, prompts, registros de auditoría y documentación deberían formar parte de esa conversación.
3. Dependencia de los datos
La inteligencia artificial necesita datos, pero la relación funciona en ambos sentidos.
Conforme un sistema evoluciona, la empresa puede comenzar a preparar información específicamente para determinada herramienta: formatos, estructuras, etiquetas, índices, bases de conocimiento o conectores.
Si esos elementos no pueden exportarse o reutilizarse, parte del activo que contiene la información queda atrapado dentro de la solución.
Los datos empresariales deberían conservar su valor independientemente de la plataforma que los procese.
Una empresa puede cambiar de modelo.
No debería perder con ello el conocimiento que construyó durante años.
4. Dependencia del workflow
Esta dependencia puede ser especialmente difícil de detectar porque suele aparecer gradualmente.
Una tarea comienza con una automatización sencilla.
Después recibe información de otra aplicación.
Luego incorpora un modelo que clasifica, resume o genera contenido.
Más adelante se añade una validación, una condición, una actualización automática y una notificación.
Al final, el workflow funciona.
Pero ¿alguien puede explicarlo de principio a fin sin abrir la herramienta?
Si la respuesta es no, la empresa tiene automatización, pero quizá no tenga control suficiente sobre la lógica operativa que automatizó.
Documentar un workflow no significa guardar únicamente capturas de pantalla.
Implica saber qué entra, qué sucede, qué reglas se aplican, qué decisiones se toman, qué excepciones existen, qué persona supervisa y qué ocurre cuando algo falla.
5. Dependencia del conocimiento
Esta puede ser la dependencia más costosa y, paradójicamente, la menos tecnológica.
Una persona creó los prompts.
Otra configuró las integraciones.
Alguien descubrió qué errores son frecuentes.
Otra persona sabe cuándo ignorar la recomendación de la IA.
Con el tiempo, el sistema acumula conocimiento tácito alrededor de su funcionamiento.
Si ese conocimiento no se documenta, una organización puede automatizar un proceso mientras concentra su comprensión en unas cuantas personas.
El riesgo se vuelve evidente cuando alguien cambia de puesto, abandona la empresa o deja de participar en el proyecto.
La continuidad no depende solamente de que la plataforma siga disponible.
También depende de que la organización conserve la capacidad de entender lo que construyó.
No hay que eliminar las dependencias: hay que diseñarlas
La conclusión fácil sería recomendar que ninguna empresa dependa demasiado de un proveedor, modelo o plataforma.
No sería práctica.
Toda arquitectura tecnológica implica decisiones. Elegir una base de datos, un proveedor de nube, un ERP o una plataforma de IA crea algún grado de dependencia.
La diferencia importante está entre una dependencia deliberada y una dependencia accidental.
Dependencia deliberada versus dependencia accidental
Una dependencia deliberada existe cuando la organización sabe por qué eligió una tecnología, qué valor obtiene, qué riesgos acepta, qué alternativas tiene y qué costo implicaría cambiar.
Una dependencia accidental aparece cuando el sistema crece por acumulación.
Primero una licencia.Después una integración.Luego una automatización.Más tarde un agente.Finalmente, nadie puede modificar una parte sin afectar otras tres.
La madurez no consiste en mantener todas las opciones abiertas en todo momento. Eso puede ser costoso e ineficiente.
Consiste en saber qué decisiones son reversibles, cuáles no y cuáles necesitan un plan de salida.
De la agilidad criptográfica a la agilidad de IA
Existe un concepto utilizado en ciberseguridad que ofrece una analogía útil.
El National Institute of Standards and Technology, NIST, utiliza el término crypto agility para describir las capacidades necesarias para sustituir y adaptar algoritmos criptográficos en protocolos, aplicaciones, software, hardware e infraestructura sin perder seguridad ni continuidad operativa.
La lógica resulta especialmente relevante en un contexto tecnológico que cambia con rapidez: no diseñar sistemas suponiendo que el componente actual permanecerá para siempre.
Podemos trasladar esa lógica a la inteligencia artificial como un marco de reflexión empresarial.
No como una definición oficial de NIST, sino como una extensión conceptual.
¿Qué sería la agilidad de IA?
Propongo entender la agilidad de IA como la capacidad de una organización para sustituir, adaptar o reconfigurar modelos, herramientas y proveedores de inteligencia artificial sin perder sus datos, procesos, conocimiento ni continuidad operativa.
Esta capacidad no exige que todos los sistemas sean completamente independientes de cualquier proveedor.
Exige que la empresa conserve suficiente control sobre los elementos estratégicos.
Sus datos.
Su conocimiento.
Sus reglas de negocio.
La documentación del proceso.
Los criterios de validación.
Las responsabilidades.
Y la capacidad de probar alternativas cuando sea necesario.
La organización verdaderamente avanzada quizá no sea la que utiliza el modelo más nuevo.
Puede ser la que tiene suficiente arquitectura y conocimiento para adoptar uno mejor cuando aparezca.
Cuatro preguntas antes de escalar una solución de IA
En la columna anterior propuse evaluar los pilotos antes de decidir si deben ampliarse, ajustarse o abandonarse.
Cuando la decisión sea escalar, conviene añadir una segunda revisión.
No para frenar la innovación, sino para evitar que el éxito inicial construya fragilidad.
¿Podemos sustituir el modelo?
No significa desarrollar desde el primer día versiones para cinco proveedores.
Significa identificar qué características son indispensables y qué elementos del proceso están excesivamente acoplados a una tecnología.
También significa conservar pruebas y métricas que permitan comparar alternativas.
Si mañana aparece un modelo mejor, la organización debería poder evaluarlo con evidencia, no solamente con entusiasmo.
¿Podemos recuperar nuestros datos, instrucciones y configuraciones?
Antes de escalar, conviene saber qué información puede exportarse, en qué formato y con qué facilidad.
Esto incluye no solo bases de datos.
También prompts, instrucciones, plantillas, reglas, configuraciones, historiales y registros relevantes para reconstruir el proceso.
Una organización debería poder abandonar una herramienta sin abandonar con ella su memoria operativa.
¿El proceso está documentado fuera de la plataforma?
Si un workflow solamente puede entenderse abriendo la aplicación que lo ejecuta, existe una señal de riesgo.
El proceso debería poder describirse de manera independiente.
Qué información recibe.
Qué transformación realiza.
Qué decisiones automatiza.
Qué persona valida.
Qué excepciones requieren intervención.
Qué métricas indican que funciona.
Qué controles permiten detenerlo.
La plataforma ejecuta el proceso.
La organización debe conservar el conocimiento sobre él.
¿Qué ocurre si la IA no está disponible?
Esta pregunta ya aparecía en el análisis del piloto y se vuelve todavía más importante al escalar.
No todos los procesos necesitan un sistema manual completamente equivalente.
Pero los procesos críticos sí necesitan una respuesta de continuidad.
¿Qué ocurre durante una interrupción?
¿Qué tareas pueden esperar?
¿Cuáles necesitan ejecutarse manualmente?
¿Qué información debe conservarse?
¿Quién puede tomar el control?
La resiliencia no significa operar igual sin tecnología.
Significa saber cómo continuar cuando una pieza falla.
Escalar capacidad sin escalar fragilidad
El debate sobre inteligencia artificial empresarial ha cambiado con rapidez.
Primero preguntábamos si las empresas debían utilizar IA.
Después, dónde podían aplicarla.
Luego, cómo probarla.
Ahora estamos aprendiendo a decidir qué soluciones merecen escalar.
La siguiente etapa será más exigente.
Tendremos que preguntar qué arquitectura estamos construyendo alrededor de esas soluciones.
Porque existe una diferencia entre escalar una herramienta y desarrollar una capacidad organizacional.
Una herramienta puede cambiar.
Un proveedor puede modificar precios.
Un modelo puede quedar superado.
Una API puede desaparecer.
Una funcionalidad puede dejar de existir.
La capacidad empresarial, en cambio, debería permanecer.
Permanecen los datos si están bajo control de la organización.
Permanece el conocimiento si fue documentado.
Permanece el proceso si puede explicarse independientemente de la plataforma.
Permanece la gobernanza si existen responsables y criterios.
Y permanece la capacidad de adoptar una nueva solución cuando la anterior deja de ser la mejor.
Por eso, la madurez en inteligencia artificial no debería medirse solamente por la velocidad con la que una empresa incorpora nuevas herramientas.
También debería medirse por su capacidad de evolucionar sin reconstruirse desde cero cada vez que la tecnología cambia.
Escalar sigue siendo necesario.
Pero la pregunta ya no puede ser únicamente cuánto valor obtendremos al integrar la IA.
También necesitamos preguntar cuánto control conservaremos después de hacerlo.
Antes de convertir el próximo piloto exitoso en una pieza permanente de la operación, conviene hacer una última prueba:
Si mañana tuviéramos que sustituir esta solución, ¿podríamos hacerlo sin perder nuestros datos, nuestro conocimiento y nuestra capacidad de operar?
La respuesta puede revelar algo que el piloto nunca mostró.
No solamente si la empresa sabe escalar inteligencia artificial.
Sino si sabe hacerlo sin escalar, al mismo tiempo, su propia fragilidad.
Su empresa no necesita otro piloto de IA, necesita ¿Escalar?
Considerations for Achieving Crypto Agility: Strategies and Practices