Las empresas que más están avanzando en la adopción de inteligencia artificial están construyendo infraestructuras cada vez más complejas. Cada nueva capacidad puede hacer más poderoso al sistema, pero también más difícil de cambiar.
Las empresas que más están avanzando en la adopción de inteligencia artificial están construyendo infraestructuras cada vez más complejas. LLMs (Large Language Models, o grandes modelos de lenguaje), agentes, RAG (Retrieval-Augmented Generation, o generación aumentada por recuperación), embeddings (representaciones numéricas de la información), MCP (Model Context Protocol), memoria, automatizaciones, seguridad y nuevas capas de datos. Cada nueva capacidad puede hacer más poderoso al sistema, pero también más difícil de cambiar.
Hoy una empresa que decide incorporar inteligencia artificial puede terminar construyendo algo parecido a esto: 1. Un modelo de lenguaje. 2. Después conecta sus datos. 3. Incorpora RAG (*Retrieval-Augmented Generation* o generación aumentada por recuperación). 4. Desarrolla agentes. 5. Agrega memoria. 6. Conecta herramientas mediante APIs (*Application Programming Interfaces* o interfaces de programación de aplicaciones) o MCP (*Model Context Protocol*). 7. Implementa seguridad. 8. Observabilidad. 9. Automatizaciones.
Y, poco a poco, lo que comenzó como la adopción de una herramienta termina convirtiéndose en una infraestructura tecnológica completa.
Por eso hay una pregunta que creo que cualquier empresa que esté construyendo seriamente con inteligencia artificial debería hacerse:
Si mañana desaparece el modelo que utilizas o aparece uno diez veces mejor, ¿puedes cambiarlo sin reconstruir todo tu negocio?
Pensemos en algo tan cotidiano como una computadora de escritorio. Puedes cambiar el monitor sin cambiar el teclado. Puedes aumentar la memoria. Reemplazar un disco duro. Cambiar algunos componentes sin tener que comprar nuevamente todo el equipo. Cada pieza tiene una función y existen interfaces que permiten que diferentes componentes trabajen juntos. Eso es una arquitectura modular.
Ahora pensemos en un producto donde las piezas fueron diseñadas específicamente para funcionar entre sí. Cambiar una puede afectar el desempeño de las demás. Separarlas es más difícil porque el valor está, precisamente, en cómo trabajan juntas. Eso es una arquitectura interdependiente.
Ninguna es mejor por definición. Y esto es importante: - La modularidad nos permite cambiar piezas con mayor facilidad. - La interdependencia nos permite optimizar profundamente cómo funciona el sistema completo.
Una privilegia la flexibilidad. La otra puede privilegiar el desempeño. La decisión estratégica está en entender dónde necesitas cada una.
Esa interdependencia le permite optimizar cosas que serían mucho más difíciles si cada componente tuviera que funcionar con decenas de alternativas desarrolladas por terceros.
Nvidia construyó una ventaja parecida. Su posición no se explica únicamente por sus GPUs (*Graphics Processing Units* o unidades de procesamiento gráfico). Durante años construyó alrededor de ellas un ecosistema de software, especialmente CUDA (*Compute Unified Architecture*), que permitió a desarrolladores y empresas aprovechar profundamente su hardware. Mientras más valor generaba el ecosistema completo, más valioso se volvía permanecer dentro de él. Y también más costoso salir.
El problema cambia cuando la dependencia está en manos de alguien más.
Imaginemos que una empresa comienza hoy un proceso serio de adopción de inteligencia artificial. Encuentra un modelo extraordinario, conecta sus datos, construye agentes, desarrolla automatizaciones, diseña procesos alrededor de sus capacidades, capacita a sus equipos e integra diferentes áreas de la organización. Durante tres años mejora y optimiza el sistema. Funciona.
El problema aparece cuando surge una alternativa mejor. Quizá el nuevo modelo cuesta una fracción. Quizá razona mejor. Quizá tiene capacidades que antes no existían. O quizá el proveedor original simplemente cambia sus condiciones.
Y cambiarla puede implicar mucho más que cancelar una licencia. Puede significar reconstruir agentes, modificar procesos, cambiar integraciones, reentrenar personas, reorganizar datos, o volver a evaluar seguridad y cumplimiento.
Eso no significa que cambiar de proveedor sea tan sencillo como presionar un botón. Nunca lo es. Pero sí significa que la arquitectura fue diseñada pensando en que algunas piezas eventualmente cambiarán.
Si cada conexión depende completamente de la tecnología que elegiste hoy, cada nueva decisión aumenta tu dependencia. Si existen interfaces suficientemente estandarizadas, aumenta tu capacidad de sustituir piezas. Y en un mercado donde la tecnología cambia prácticamente cada mes, esa diferencia puede valer mucho.
Sería fácil concluir que la solución es construir todo de manera modular. No necesariamente.
Si Apple hubiera priorizado desde el principio que cualquier componente pudiera ser reemplazado fácilmente por uno de cualquier proveedor, probablemente no tendría el mismo control sobre su experiencia. Si Nvidia hubiera construido CUDA pensando únicamente en facilitar que sus clientes cambiaran de hardware, probablemente su ventaja competitiva sería diferente.
¿Dónde queremos construir nuestra dependencia?
Porque si una parte de tu negocio es realmente estratégica, quizá tenga sentido controlarla, integrarla profundamente y construir capacidades propias alrededor de ella. Pero si una tecnología se está convirtiendo rápidamente en un *commodity*, construir toda tu operación alrededor de un solo proveedor puede ser una decisión completamente distinta.
Y creo que este punto será especialmente importante con los modelos de inteligencia artificial.
En el primer ensayo de esta serie, Innovación vs. disrupción, hablamos de cómo el acceso masivo a los LLMs (*Large Language Models* o grandes modelos de lenguaje) está acelerando su comoditización. Cada vez más empresas tienen acceso a modelos capaces, los costos bajan y el desempeño mejora.
Ahí la decisión entre modularidad e interdependencia deja de ser una conversación tecnológica. Se convierte en una decisión sobre dónde quieres construir tu ventaja competitiva: - Construye interdependencia donde esa integración te haga diferente. - Construye modularidad donde necesites conservar la libertad de cambiar.
Si estás diseñando tu estrategia de IA, el primer paso es definir con precisión metodológica el Job to Be Done de tu cliente para no construir interdependencias en el lugar equivocado.
Si no sabes por dónde comenzar para identificar tu Job to Be Done, he diseñado una herramienta interactiva para que lo generes paso a paso y descargues tu matriz final en alta resolución: