En el módulo 3 confirmamos que la idea es factible: hay datos, el problema entra en lo que la tecnología hace hoy, y el riesgo técnico está acotado. Salimos de ahí con un “sí, se puede”. Pero “se puede” no dice cómo. La misma capacidad — digamos, clasificar tickets de soporte y sugerir una respuesta — se puede resolver de cuatro maneras muy distintas, con precios, plazos y niveles de control que difieren en un orden de magnitud. Este módulo es esa decisión: ¿lo construimos nosotros, lo compramos hecho, o lo consumimos por API (Application Programming Interface — la interfaz por la que un programa le pide algo a un servicio ajeno y recibe la respuesta)? Elegir mal acá no rompe el producto de inmediato: lo encarece, lo atrasa y, en el peor caso, lo deja atado a un proveedor del que después no puedes salir.

La tesis del módulo

Construye solo lo que te diferencia; compra o consume por API todo lo que es commodity. La ventaja competitiva de un producto de IA casi nunca está en el modelo base — está en los datos, el flujo y la experiencia que lo rodean. El modelo que usas también lo puede usar tu competencia mañana. Lo que no puede copiar es tu dato propietario, tu conocimiento del dominio y la fricción que le quitaste al usuario.

Commodity (algo estandarizado, disponible para todos, donde la diferencia entre proveedores es marginal): el modelo de lenguaje base es hoy una commodity. Hay tres o cuatro que rinden parecido, se cambian con un cambio de configuración, y el mismo está a un clic de tu competidor. Gastar tu presupuesto de ingeniería en reconstruir esa pieza es como fabricar tu propia electricidad para abrir una panadería: técnicamente posible, estratégicamente absurdo.

El espectro de opciones, de menos a más control

“Build vs buy” suena binario, pero en IA es un espectro. Entre “consumo una API y no controlo nada del modelo” y “entreno un modelo desde cero y controlo todo” hay tres escalones intermedios. Cada uno que bajas te da más control y más independencia, y te cobra más dinero, más tiempo y más equipo.

API de modelo cerrado. Consumes un modelo alojado por el proveedor (OpenAI, Anthropic, Google). Mandas texto, recibes texto, pagas por uso. No ves los pesos del modelo, no lo hospedas, no lo mantienes. Máxima velocidad, mínimo control. Es el punto de partida por defecto.
Plataforma gestionada. Construyes sobre un proveedor que te da más que el modelo: orquestación, almacenamiento vectorial, evaluación, monitoreo, todo integrado (Azure OpenAI, Amazon Bedrock, Vertex AI). Compras el andamiaje además del modelo. Más rápido que armarlo tú; te acopla más al proveedor.
Modelo open-weight auto-hospedado. Open-weight (de pesos abiertos: el proveedor publica los parámetros del modelo y puedes descargarlo y correrlo en tu propia infraestructura — Llama, Mistral, Qwen). Ganas control total sobre dónde vive el dato y qué versión corres; pagas con la infraestructura de cómputo y el equipo que la opera. Esto ya es un problema de GPU y costos, desarrollado en producción, costos y decisiones de GPU.
Fine-tuning propio. Tomas un modelo (por API o auto-hospedado) y lo ajustas con tus datos para especializarlo. Fine-tuning (afinar: seguir entrenando un modelo ya entrenado con ejemplos tuyos para que rinda mejor en tu tarea específica). Sube el control sobre el comportamiento; te obliga a tener datos etiquetados y un ciclo de reentrenamiento. El cómo se hace es un curso propio; acá basta saber que es un escalón caro que se justifica pocas veces.
Modelo a la medida, desde cero. Entrenas tu propio modelo base. Control absoluto, costo absoluto. Para casi todo producto esto es un error: cuesta millones, tarda meses y compite contra laboratorios que gastan miles de millones. Se justifica solo si el modelo es el producto y tienes datos y capital que nadie más tiene.

La regla del espectro: no bajas un escalón porque puedes, bajas porque un número te obliga. Volumen, costo unitario, privacidad o latencia. Bajar por gusto de ingeniería es la forma más cara de sentirse dueño.

El criterio central: diferenciación vs commodity

La pregunta que ordena todo no es técnica, es de negocio: ¿esta pieza es tu ventaja competitiva, o es infraestructura que todos comparten? Cruzas eso con una segunda pregunta — ¿ya existe una solución madura en el mercado? — y obtienes cuatro cuadrantes que casi deciden solos.

      DIFERENCIACIÓN × MADUREZ DEL MERCADO

              baja madurez        alta madurez
            (no existe hecho)   (hay solución)
          ┌──────────────────┬──────────────────┐
   alta   │                  │                  │
  difer.  │    CONSTRUIR     │   BUILD + BUY    │
 (es tu   │  es tu ventaja   │  compra la base, │
ventaja)  │  y nadie la      │  construye la    │
          │  vende: hazla    │  capa que separa │
          ├──────────────────┼──────────────────┤
   baja   │                  │                  │
  difer.  │   API / esperar  │   COMPRAR / API  │
 (no es   │  no es tu foco   │  commodity puro: │
 tu       │  y aún es verde: │  consúmelo, no   │
ventaja)  │  consume por API │  lo reconstruyas │
          └──────────────────┴──────────────────┘

Alta diferenciación + baja madurez (arriba-izq): construir. Es tu ventaja y nadie la vende hecha. Acá va tu equipo. Ejemplo: el flujo específico con que tu producto convierte una consulta ambigua del usuario en la acción correcta, usando reglas de tu negocio.
Alta diferenciación + alta madurez (arriba-der): build + buy. Compras la base commodity (el modelo, el almacenamiento) y construyes encima la capa que te separa. Es el patrón ganador de casi todo producto de IA serio: buy the platform, build the differentiation.
Baja diferenciación + alta madurez (abajo-der): comprar o API. Commodity puro. Transcripción de audio, traducción, extracción de texto de un PDF. Consúmelo. Reconstruirlo es quemar presupuesto en subir el piso sin levantar el techo.
Baja diferenciación + baja madurez (abajo-izq): API o esperar. No es tu foco y todavía no hay algo sólido que comprar. Resuélvelo con lo mínimo (una API) o pospónlo hasta que el mercado madure.

Ojo: el error clásico es enamorarse de construir el cuadrante equivocado. Un equipo de IA disfruta entrenando modelos, así que “construye” la parte commodity (un clasificador que una API resolvía en una línea) y “compra” la parte diferenciadora (terceriza justo el flujo que era su ventaja). Invierte los cuadrantes y quema el presupuesto en el techo ajeno.

Vendor lock-in y cómo no quedar atrapado

Vendor lock-in (dependencia de proveedor: el costo — en dinero, tiempo y riesgo — de cambiarte a otro proveedor es tan alto que en la práctica quedas atrapado en el actual). En IA el lock-in no llega de golpe: se acumula en capas. Te acoplas al modelo, después a la orquestación del proveedor, después a su formato de datos, después a su evidencia de gobernanza, y cada caso de uso nuevo sube el costo de salir en todas esas capas a la vez.

El trade-off es real y no tiene solución gratis: velocidad vs independencia. Usar las features propietarias del proveedor te hace ir más rápido hoy y te encadena más para mañana. Ignorarlas te mantiene libre y te hace ir más lento. No hay respuesta única; hay una decisión consciente que se toma temprano, no un accidente que se descubre tarde. Mitigaciones concretas:

Abstrae al proveedor. Que tu código hable con una capa interna (generar(prompt)), no directamente con el SDK del proveedor. Cambiar de modelo debería ser tocar un archivo, no reescribir el producto.
Evita acoplarte a features propietarias. Cada función exclusiva de un proveedor que usas es un clavo más. Úsala solo si el valor supera claramente al costo de salida.
Cuida la portabilidad de prompts y datos. Tus prompts, tus ejemplos y tus datos de evaluación son tuyos. Guárdalos en un formato que no dependa del proveedor, para poder llevártelos.
Ten estrategia multi-modelo. Poder enrutar a un segundo proveedor no es solo defensa ante lock-in: es continuidad de negocio cuando el primero falla o sube el precio.

Por qué empezar por la API casi siempre

La recomendación por defecto, salvo que un número te empuje hacia abajo, es empezar por la API de modelo cerrado. Tres razones:

Time-to-value (tiempo hasta entregar valor). Una API te tiene generando resultados en horas. Auto-hospedar un modelo te tiene contratando y aprovisionando GPU durante semanas antes del primer resultado útil.
Valida el producto antes de invertir en infra. El riesgo más grande no es que el modelo no rinda: es que nadie quiera el producto. La API te deja descubrir eso barato. Auto-hospedar para un producto que el usuario no adopta es pagar por una fábrica sin clientes.
Solo bajas de nivel cuando un número lo justifica. Cuando el volumen es tan alto que el costo por token en API supera lo que costaría tu propia infraestructura; cuando la privacidad exige que el dato no salga de tu perímetro; cuando la latencia o el control de versión lo requieren. Ese cálculo es de presupuesto y se aborda de lleno en presupuesto y FinOps, y su cara técnica en el módulo de GPU.

Cuidado: “vamos a auto-hospedar desde el día uno para no depender de nadie” suena maduro y casi siempre es prematuro. Es optimizar un costo que aún no existe (no tienes volumen) a cambio de retrasar la única pregunta que importa al principio (¿le sirve esto a alguien?). Primero valida con API; después, con datos de uso reales, decide si bajar de escalón paga.

Las consideraciones que inclinan la balanza

Más allá de la diferenciación, hay cinco fuerzas que empujan la decisión hacia un lado u otro. Ninguna decide sola; se ponderan.

Privacidad de datos. Si el dato es tan sensible que no puede salir de tu perímetro (salud, financiero, secreto industrial), eso empuja fuerte hacia auto-hospedar. Se conecta directo con riesgo y cumplimiento.
Costo a escala. A bajo volumen la API es imbatiblemente barata. A volumen muy alto, el costo por uso puede superar el de infraestructura propia. El punto de cruce es un cálculo, no una corazonada.
Latencia. Si necesitas respuestas en milisegundos y control fino del rendimiento, un modelo propio cerca de tu aplicación puede ganarle a la latencia de red de una API.
Control. Fijar la versión del modelo, garantizar que no cambie bajo tus pies, ajustar comportamiento: todo eso vive en los escalones de abajo del espectro.
Cumplimiento. Ciertos marcos regulatorios exigen residencia del dato o auditabilidad que una API pública quizá no ofrezca. El requisito legal manda sobre la conveniencia técnica.

Artefacto: matriz de decisión build/buy/API

Aquí está el equivalente de gestión al “código real”: una matriz de decisión ponderada. Defines los criterios que importan, les das un peso según tu contexto, puntúas cada opción de 1 a 5, y multiplicas. El número no decide por ti — ordena la conversación y hace explícito el porqué. Ejemplo ilustrativo (las cifras son inventadas para mostrar el método, no datos de un caso real): un producto que sugiere respuestas a soporte, donde el flujo es la ventaja pero el modelo base es commodity.

Caso: "asistente de sugerencia de respuestas a soporte"
Escala por criterio: 1 (malo) … 5 (excelente) para ESA opción.

| Criterio          | Peso | API | Platf. | Self-host | A medida |
|-------------------|------|-----|--------|-----------|----------|
| Diferenciación*   |  1   |  3  |   3    |     3     |    4     |
| Costo a escala    |  2   |  3  |   3    |     4     |    2     |
| Time-to-market    |  3   |  5  |   4    |     2     |    1     |
| Control           |  2   |  2  |   3    |     4     |    5     |
| Riesgo (bajo=alto)|  2   |  4  |   3    |     3     |    1     |
| Ponderado (Σ p·s) |      | 36  |  33    |    31     |   23     |

* El modelo base no es la diferenciación de este caso: el flujo alrededor sí. Por eso “diferenciación” puntúa parecido entre opciones y pesa poco: se construye encima de cualquiera de ellas, no dentro del modelo.

Cómo se lee: la API gana (36) porque este producto vive o muere por el time-to-market y por validar rápido, y su diferenciación no está en el modelo sino en el flujo, que construirás igual sobre lo que elijas. Si mañana el volumen se dispara, recalculas: “costo a escala” y “control” suben de peso y el resultado puede migrar a self-host. La matriz no es una sentencia; es un instrumento que se recalcula cuando cambian los pesos.

API vs plataforma vs self-hosted vs a medida

Opción	Control	Costo inicial	Velocidad	Cuándo elegirla
API de modelo	Bajo	Muy bajo	Muy alta	Empezar, validar, MVP; el modelo es commodity
Plataforma gestionada	Medio	Bajo-medio	Alta	Necesitas orquestación/monitoreo ya integrados
Open-weight self-hosted	Alto	Alto	Baja	Volumen alto, privacidad estricta, control de versión
A la medida (desde cero)	Total	Muy alto	Muy baja	El modelo es el producto; datos y capital únicos

La lectura vertical importa tanto como la horizontal: bajar en la tabla cambia el signo de cada columna. Ganas control y lo pagas con velocidad y costo inicial. No existe la opción que gane en todo; existe la que gana en lo que hoy te importa.

Errores comunes

Construir el modelo base “para tener control”. El modelo es commodity; tu ventaja está en los datos, el flujo y la experiencia. Reconstruirlo es quemar presupuesto subiendo el piso sin levantar el techo.
Auto-hospedar desde el día uno. Optimizas un costo de escala que aún no existe y retrasas la validación, que es la única pregunta urgente al principio. Empieza por API; baja de escalón cuando un número lo pida.
Invertir los cuadrantes. Construir la parte commodity porque es divertida y comprar la parte diferenciadora porque es difícil. Terceriza tu ventaja y reinventa lo que venían regalando.
Ignorar el lock-in hasta que duele. El acoplamiento se acumula en silencio, capa por capa, y el día que quieres salir descubres el costo. Abstrae al proveedor desde el principio; es barato hacerlo temprano y carísimo después.
Tratar la matriz como oráculo. El número ordena la discusión, no la reemplaza. Si el resultado te sorprende, revisa los pesos: casi siempre el desacuerdo está ahí, no en los puntajes.
Elegir por moda de ingeniería, no por número. “Todos están auto-hospedando” no es un criterio. Volumen, costo unitario, privacidad y latencia sí lo son. Sin un número que te empuje, quédate arriba del espectro.

La frase para llevarse

“El modelo que usas hoy lo usará tu competencia mañana; construir eso no te diferencia, te distrae. Construye lo que solo tú puedes construir — tu dato, tu flujo, tu experiencia — y consume por API todo lo demás hasta que un número, no un gusto, te obligue a bajar de escalón.”

Qué viene

Con la decisión build/buy/API tomada, ya sabes con qué vas a construir. El módulo 5 arma el roadmap: cómo se secuencia un producto de IA en el tiempo cuando la incertidumbre técnica es alta, por qué el roadmap de IA se parece más a una serie de apuestas escalonadas que a un plan lineal, y cómo comunicar avance a la organización cuando lo que entregas primero es aprendizaje, no features.

Producto de IA — Módulo 4: build vs buy vs API