Build vs buy en IA: cuándo construir tu agente y cuándo comprarlo
Tu director de tecnología te ha dicho que pueden construir el agente internamente en seis semanas. Tu director financiero ha pedido tres demos a proveedores externos esta misma mañana. Ninguno de los dos está mintiendo. Ninguno de los dos te está dando la respuesta correcta tampoco. La pregunta de si construir o comprar IA en tu empresa no se resuelve por capacidad técnica ni por presupuesto. Se resuelve antes, cuando entiendes qué tipo de ventaja estás intentando construir.
En el 80% de las empresas medianas españolas que están metiendo IA en serio, esta decisión se toma por inercia. Si el CTO tiene equipo, se construye. Si no lo tiene, se compra. Y luego, doce meses después, el proyecto está en cajón por la razón equivocada: el que se construyó costaba mantener tres veces lo previsto, o el que se compró no se podía adaptar al proceso real.
Voy a darte los tres ejes que separan un caso de construir de un caso de comprar. No son tan obvios como parecen.
Eje 1: ¿La capa de IA es tu producto o es tu operación?
Si lo que estás automatizando con IA forma parte directa del producto que vende tu empresa al cliente final, vas hacia construir. Si es algo que sucede dentro, en tu operación, vas hacia comprar.
Esto suena obvio y no lo es. Una agencia de marketing que automatiza la generación de copy para sus clientes está construyendo producto, aunque “internamente” lo sienta como herramienta. Un fabricante industrial que automatiza el reporting interno con IA está mejorando operación, aunque su CTO quiera lucir el agente.
La regla: cuanto más cerca esté el agente de la propuesta de valor que cobras al cliente, más sentido tiene construirlo. Cuanto más lejos, más sentido tiene comprarlo. Si vas a vender el output del agente, lo controlas tú. Si solo lo usas, deja que otro mantenga la infraestructura.
Eje 2: ¿Cuánto cambia el proceso por debajo?
Los procesos que cambian poco son terreno de comprar. Los que cambian mucho, de construir.
Una empresa con un proceso de facturación estable desde hace cinco años no necesita construir nada para automatizar la conciliación bancaria con IA. Hay producto en el mercado que lo hace bien y se actualiza solo. Una empresa que cambia su pricing cada tres meses, atiende a sectores muy distintos y reorganiza el equipo comercial cada año va a sufrir con cualquier herramienta cerrada.
La regla: si tu proceso es estándar y estable, comprar. Si es vivo, distintivo y cambia con frecuencia, construir. La trampa más cara es comprar una herramienta rígida para un proceso vivo, porque acabas pagando dos veces: la licencia del producto y el coste de adaptar tu negocio al producto.
Eje 3: ¿Tienes equipo para mantener el agente o solo para lanzarlo?
Aquí casi todo el mundo se equivoca. Construir un agente de IA es lo barato. Mantenerlo es lo caro.
Un agente medianamente serio que toca datos de cliente, modelos que cambian cada tres o cuatro meses y procesos que evolucionan necesita, como mínimo, una persona dedicada a vigilarlo, reentrenarlo cuando hace falta y ajustar prompts conforme cambian los casos de uso. Si tu equipo de IT no tiene esa capacidad estable, lo que vas a tener no es un agente, es un cadáver técnico en producción.
La regla: solo construye lo que puedas mantener. Y “mantener” no es “tener un proyecto al año para revisarlo”, es presupuesto continuo de personas con criterio. Si no lo tienes, comprar te da garantía de continuidad.
El error más caro: construir sin haber comprado nunca
Hay un patrón que veo todos los meses en empresas técnicas. Tienen capacidad de programar, leen mucho sobre IA, y el primer agente lo construyen ellos. El problema es que no han usado nunca un producto serio de IA empresarial con todas las garantías. No saben dónde está el listón.
El resultado es predecible. Construyen algo que funciona en demo, cobra el primer trimestre por entusiasmo, y a los seis meses se ha quedado por detrás de cualquier herramienta del mercado en lo básico: trazabilidad, observabilidad, control de versiones del modelo, gestión de permisos. Cosas en las que un proveedor lleva trabajando dos años con cien clientes.
Antes de construir, compra al menos una vez. Aunque sea para un caso lateral. No para usarlo en producción si no quieres, sino para entender el listón mínimo de lo que el mercado considera aceptable. Después decide.
Cómo presentar la decisión al comité
Si llegas al comité con “vamos a construir esto” o “vamos a comprar lo otro”, la conversación se va a derivar a debates de ego: equipo interno orgulloso frente a compras conservadoras. No vas a decidir nada útil.
Llega con esta tabla:
- Caso de uso y a qué eje pertenece (producto vs. operación, proceso estable vs. vivo, equipo disponible vs. no)
- Coste de construir a 24 meses, incluyendo dos personas dedicadas y una iteración mayor de modelo
- Coste de comprar a 24 meses, incluyendo licencias, integración y rotación posible de proveedor
- Riesgo principal de cada vía: en construir, deuda técnica; en comprar, dependencia
- Reversibilidad: si en 12 meses te equivocas, ¿cuánto cuesta cambiar de vía?
Esa última fila, la de reversibilidad, es la que más decisiones inteligentes desbloquea. Cuando es fácil revertir, prueba la vía más rápida. Cuando es muy difícil, escoge la que mejor encaje en los tres ejes anteriores.
Cierre
La pregunta no es ideológica. No tiene que ver con si te gusta más programar o pagar licencias. Tiene que ver con dónde está tu ventaja, cuánto se mueve tu negocio por debajo, y si tienes el músculo para sostener un sistema vivo en el tiempo.
Si tu agente automatiza algo lateral, en un proceso estandarizado, sin equipo de mantenimiento, compra. Si toca el corazón de tu producto, en un proceso vivo, con equipo que sí puede cuidarlo, construye. Y si estás en medio, empieza comprando, aprende, y construye después solo el trozo que tu mercado no te va a dar igual.