La importancia de los modelos de IA.
Si el modelo de IA ya no es el diferencial, el valor real empieza a concentrarse en al menos cinco capas que rara vez aparecen en la conversación pública sobre inteligencia artificial, pero que terminan definiendo si un proyecto escala o muere.
Cada vez que una organización arranca un proyecto de inteligencia artificial, la primera pregunta suele ser siempre la misma: ¿qué modelo van a usar? La hacen los directivos, los comités de innovación, incluso la prensa cuando cubre estos anuncios. No es la única pregunta relevante, pero suele ser la primera, y sin embargo cada vez pesa menos de lo que parece.
Quienes trabajan del lado de la arquitectura de soluciones tecnológicas, ayudando a organizaciones a definir e implementar proyectos de IA en industrias donde el margen de error es mínimo, coinciden en un patrón que se repite sin importar el rubro: se le dedica una atención desproporcionada a qué motor de inteligencia artificial corre por debajo, como si esa elección definiera por sí sola el éxito del proyecto. La realidad, cada vez más, es otra: este soporte dejó de ser el diferencial.
Hoy los modelos de las principales compañías del sector, entre ellas OpenAI, Anthropic, Google y Meta, además de los desarrollos chinos como DeepSeek o Qwen, que ya compiten de igual a igual en buena parte de las tareas, son para la enorme mayoría de los casos de uso reales prácticamente intercambiables. Cuando una organización cambia de proveedor de modelo y el sistema deja de funcionar, el problema nunca fue el modelo en sí: fue que se construyó mal todo lo demás.
Hay un matiz que pesa cada vez más, sobre todo en sectores con datos sensibles. Varios de estos, incluidos algunos de origen chino, ya pueden correr on-premise, dentro de la propia infraestructura de la organización, sin que la información salga hacia servidores externos. En sectores como la salud o las finanzas, donde el dato es lo más sensible que existe, esto cambia la conversación por completo: la pregunta relevante deja de ser qué modelo es más inteligente y pasa a ser qué arquitectura garantiza que el dato no salga de los propios servidores. Esa ya no es una decisión sobre inteligencia artificial. Es una decisión de infraestructura.
Hay una escena que se repite en organizaciones de todos los tamaños y que resulta cada vez más familiar: una prueba de concepto de IA que funciona espectacular en la demo, genera entusiasmo, aplausos, hasta una comunicación interna celebrando el hito, y que seis meses después nadie recuerda. Quedó archivada entre los pilotos que "andaban" pero nunca llegaron a ningún lado. La explicación fácil suele ser "problemas de adopción" o "resistencia al cambio", y hay algo de cierto en eso, pero la razón de fondo es más simple y más incómoda: la prueba de concepto se construye alrededor del modelo, y nunca se termina de construir todo lo que hace falta a su alrededor para que sobreviva en producción.
Una prueba de concepto necesita un modelo que responda bien a diez preguntas armadas por un equipo técnico. Un sistema en producción necesita, en cambio, integrarse con datos reales, muchas veces sucios, incompletos o dispersos en sistemas legados. Necesita que alguien defina qué pasa cuando el sistema se equivoca y quién es responsable de eso. Necesita trazabilidad, supervisión humana en los puntos críticos, y una arquitectura de despliegue que respete dónde puede vivir el dato. Y necesita medirse no por cuánto rinde en un benchmark, sino por si la gente que tiene que usarlo lo sigue usando al mes siguiente. Nada de eso es el modelo. Todo eso es lo que lo rodea.
Si el modelo ya no es el diferencial, el valor real empieza a concentrarse en al menos cinco capas que rara vez aparecen en la conversación pública sobre inteligencia artificial, pero que terminan definiendo si un proyecto escala o muere. En primera medida, destaca la calidad de los datos y su integración; es decir, qué tan bien conectado está el sistema con la información real de la organización y qué tan estructurada está esta. También es esencial la orquestación del flujo de trabajo, o si la herramienta se inserta en la rutina real de las personas que la van a usar en lugar de exigirles cambiar su forma de trabajar para adaptarse a ella. Por otro lado, el gobierno y la supervisión humana son clave, entendidos como quién audita las decisiones y quién responde cuando algo falla. Lo mismo sucede con la seguridad y el cumplimiento normativo, esto es dónde vive el dato y quién puede acceder a él. Y, finalmente, la adopción real: si meses después del lanzamiento la herramienta se sigue usando o quedó como una curiosidad institucional. Consultoras tecnológicas como Ingenia, que acompañan a organizaciones de distintos sectores en este tipo de implementaciones, observan que ese patrón se repite con independencia de la industria o el tamaño de la empresa.
En la comunidad técnica de inteligencia artificial empieza a circular un concepto para nombrar justamente esto: la disciplina de diseñar bien todo lo que rodea al modelo, sus herramientas, su contexto, su supervisión, importa hoy más que la elección del modelo en sí. Cuando ese diseño está bien hecho, cambiar el modelo por debajo apenas se nota. Cuando está mal realizado, no hay modelo, por sofisticado que sea, que lo salve.
La próxima vez que alguien presente un proyecto de inteligencia artificial, junto con la pregunta de qué modelo usa vale la pena sumar otras, tales como de dónde salen los datos, dónde vive esa información, quién es responsable cuando el sistema se equivoca, cómo se va a medir si funciona más allá del primer mes, y qué pasa si en dos años cambia el proveedor del modelo por debajo. Porque en dos años, el modelo que se elija hoy va a estar obsoleto. Lo que se construya alrededor, si está bien hecho, es lo único que va a seguir funcionando.
