Economía de los modelos fundacionales: cómo poner IA en producción sin tener un laboratorio frontera

La Stanford Emerging Technology Review 2026 pone números a algo que la mayoría de equipos de producto llevan dos años señalando vagamente: los modelos fundacionales son un tipo de objeto distinto al software que solíamos desplegar, y la economía que hay detrás condiciona cada decisión aguas abajo.

He leído el informe desde la silla de quien construye, no desde la del analista. La pregunta que me importa no es quién gana la carrera de la frontera — es qué implica esta economía para los equipos que lanzan funcionalidades de IA sin laboratorio propio, porque ahí es donde paso mis horas de trabajo.

Algunas cifras que conviene tener en la cabeza:

• El corpus de entrenamiento de GPT-4 era el equivalente textual a unos 100 millones de libros — alrededor de 10 billones de palabras.
• El entrenamiento usó unos 25.000 chips Nvidia A100 durante ~100 días, a unos 10.000 dólares por chip solo en hardware.
• Electricidad de la fase de entrenamiento para un modelo tipo GPT-4: ~50 millones de kWh, la energía anual de unos 4.500 hogares estadounidenses.
• Inferencia por consulta de ChatGPT: ~2 Wh — frente a 0,3 Wh de una búsqueda en Google y los 2 Wh que contiene una pila AAA.
• Mercado global de IA proyectado en 244,22 mil millones de dólares en 2025. La inversión privada en IA alcanzó los 150,79 mil millones en 2024, con la IA generativa sola en 33,94 mil millones.
• Goldman Sachs estima que la IA generativa, ampliamente adoptada, podría aumentar el PIB global en ~7 billones de dólares y el crecimiento de la productividad en 1,5 puntos porcentuales durante una década.

Si estás construyendo productos sobre estos modelos, tres de esas cifras importan más que el resto: el coste de inferencia por consulta, la trayectoria de ese coste a medida que se generalizan los modelos de razonamiento, y el ritmo al que las alternativas open-weight cierran la brecha de capacidad.

El entrenamiento no es tu problema. La inferencia, sí

Casi nadie que lea este post va a entrenar un modelo frontera. La economía lo hace inviable incluso para cualquier "grupo razonablemente grande de las principales universidades de investigación de EE. UU." — el planteamiento es del propio informe de Stanford — y mucho menos para una empresa mid-market en solitario. La pregunta interesante no es "¿deberíamos entrenar un modelo fundacional?" — es "¿cómo ejecutamos la inferencia a un coste unitario que no mate el modelo de negocio?"

El informe de Stanford señala algo que importa aquí: los modelos de razonamiento — modelos fundacionales que "piensan" los problemas paso a paso antes de responder — han encarecido sustancialmente la inferencia en el último año. No es una nota al pie menor. Un producto cuyo precio asume que una consulta de usuario equivale a una llamada al modelo ahora debe asumir que una consulta puede equivaler a docenas de llamadas internas, más invocaciones de herramientas, más reintentos. La economía unitaria de "una consulta, una respuesta" no se sostiene con cargas agénticas y de razonamiento.

Qué significa esto en la práctica:

• Deja de fijar el precio de las funcionalidades de IA sobre el coste de inferencia por token como si fuera estable. Las cadenas de razonamiento, los bucles agénticos y las entradas multimodales hacen saltar esa premisa por los aires. Pon precio sobre el valor para el usuario, con holgura de margen para el encarecimiento de la inferencia.
• Construye observabilidad de costes en el sistema desde el día uno. Necesitas telemetría de coste de inferencia por funcionalidad, por usuario, por tenant. Si no puedes responder "¿cuánto nos cuesta este usuario este mes?", no puedes operar el negocio.
• Trata la destilación y los fallbacks a modelos pequeños como trabajo de ingeniería de primer orden. El informe describe explícitamente la destilación — comprimir modelos grandes en otros más pequeños y rápidos — como una dirección clave. Los equipos que sepan enrutar las consultas fáciles a un modelo pequeño y reservar las llamadas al modelo frontera para las difíciles operarán a la mitad del coste de inferencia que los que no lo hagan.

Open-weight va en serio. Trátalo como una decisión de compras

El informe nombra a los líderes obvios — cerrados (GPT, Claude, Gemini), open-source/open-weight (Llama 4, Gemma 2, Command R) — y añade algo menos obvio: los lanzamientos open-source de DeepSeek están acelerando la adopción global y socavando los esfuerzos de contención estadounidenses. Pienses lo que pienses sobre la geopolítica, la implicación de ingeniería es clara: la brecha entre los modelos cerrados frontera y los open-weight competentes se está cerrando lo bastante rápido como para que elegir un único proveedor de modelo cerrado como base arquitectónica de tu producto sea un riesgo de aprovisionamiento, no solo técnico.

El contraargumento merece su espacio: los modelos cerrados de frontera siguen por delante en las tareas más difíciles, y si estás prototipando, coger la mejor API y lanzar es la decisión correcta. El riesgo no es usar un modelo cerrado — es construir de forma que nunca puedas dejar de hacerlo.

Tres cosas para las que diseñar:

1. Abstracción de proveedor. Cada ruta de prompt de tu sistema debería poder intercambiar el modelo subyacente. El vendor lock-in vía formatos de tool-calling específicos del SDK, embeddings propios del proveedor o filtros de seguridad propios del proveedor es deuda técnica que acaba pasando factura.
2. Niveles de capacidad. Ordena tus prompts según cuán capaz necesita ser el modelo. La mayoría de prompts en la mayoría de productos no necesitan la frontera. Los equipos que resuelven esto se ahorran millones al año.
3. Self-hosted como opción real. Si tus datos son sensibles, tu volumen es alto y tus requisitos de latencia son ajustados, un modelo open-weight afinado corriendo en tu propia infraestructura es una opción creíble — no un proyecto de investigación.

El coste oculto: datos, no cómputo

El informe es directo: "Las futuras ganancias de IA dependerán cada vez más no solo de gran capacidad de cómputo y grandes cantidades de datos, sino también de datos específicos del dominio e innovaciones centradas en eficiencia."

Lee esa frase otra vez, porque es la más importante del capítulo para los equipos de producto. Los proveedores de modelos frontera ya se han comido el internet públicamente disponible. La siguiente ronda de ventaja competitiva sale de los datos específicos de dominio que los proveedores frontera no tienen.

Si operas en una industria regulada, especializada o intensiva en datos propietarios — legal, salud, servicios financieros, sistemas industriales, comercio regional — tu foso de datos es el activo, no el modelo. El trabajo de ingeniería que se deriva de esto:

• Generación de datos sintéticos. El informe destaca los datos sintéticos — generados artificialmente para imitar las propiedades estadísticas de los datos reales — como respuesta a la oferta limitada de datos reales. Esto es ya una competencia normal de ingeniería, no investigación exótica.
• Fine-tuning antes que prompting. La mayoría de equipos depende en exceso de los prompts e infrainvierte en fine-tuning. Para tareas repetitivas de dominio, un modelo pequeño afinado supera a un modelo frontera con prompts en coste, latencia y consistencia.
• RAG bien hecho. Retrieval-augmented generation es el estándar de facto, pero la mayoría de implementaciones son un refrito del MVP de alguien. Un RAG de verdad requiere suites de evaluación, ajuste del retrieval y curación continua de datos. Los equipos que se lo toman en serio ponen en producción productos que funcionan; los que no, ponen demos.

Dónde deja esto a los equipos de ingeniería mid-market

Si eres CTO o fundador y lanzas funcionalidades de IA sin presupuesto de laboratorio frontera, el planteamiento de Stanford deja el manual de juego más claro que hace un año. Esto es lo que haría yo:

1. No entrenes. Destila, afina, enruta.
2. No te encierres. Abstracción de proveedor, niveles de capacidad, opciones self-hosted preparadas.
3. Sí invierte en datos. Datos de dominio, datos sintéticos, suites de evaluación, infraestructura RAG.
4. Sí mide el coste de inferencia por usuario, por funcionalidad, por tenant. Los equipos que operen así sobrevivirán a los que no.

Dónde encaja Conectia

Construimos Conectia sobre una observación: los ingenieros capaces de operar dentro de este manual son una población distinta de "los ingenieros que saben usar ChatGPT". Las habilidades se solapan con la ingeniería senior clásica — diseño de sistemas, observabilidad, disciplina de costes, seguridad — y añaden una capa de criterio específico de IA: cuándo afinar y cuándo basta con un prompt, cuándo es suficiente un modelo pequeño, cómo escribir evaluaciones que detecten regresiones, cómo abstraer proveedores sin caer en la sobreingeniería.

Nuestros ingenieros nearshore están validados en cinco pilares, incluida la competencia en IA, con evaluación explícita de estas decisiones — no solo "¿has usado Copilot?". Si estás construyendo funcionalidades de IA y a tu equipo le falta esa capa de criterio, ese es el hueco que estamos diseñados para cerrar. Mira cómo funciona la validación.

La economía de los modelos frontera no va a cuadrar con tu roadmap hasta que tu cultura de ingeniería trate el coste de inferencia, la calidad de los datos y la portabilidad de proveedor como preocupaciones de primer orden. Y eso es un problema de contratación antes que un problema de herramientas.