Build vs buy solución de IA: los criterios que definen la decisión

La decisión que se toma mal por apuro

La pregunta “¿construimos o compramos?” casi nunca se responde con datos: se responde con la opinión de la última persona que habló con el equipo de dirección. El área de tecnología quiere construir porque quiere control y aprendizaje interno. El área de operaciones quiere comprar porque quiere un resultado este trimestre. Los dos argumentos son legítimos y los dos están incompletos si no se comparan con los mismos criterios.

El error más común no es elegir mal, es elegir sin haber puesto sobre la mesa los mismos seis o siete criterios para las dos opciones. Se compara el precio de la licencia contra el sueldo de un desarrollador y ahí termina el análisis. Esta página no es el proceso completo de decisión (para eso existe la guía “Cómo decidir build vs buy en un proyecto de IA”), es la tabla de criterios que debería estar resuelta antes de sentarse con cualquier proveedor o con cualquier equipo de desarrollo.

Qué es cada opción, sin el marketing de por medio

Construir (build) es desarrollar una solución de IA a la medida del proceso del negocio: código propio, integraciones directas con modelos vía API y una arquitectura pensada para ese caso de uso específico. Puede hacerlo un equipo interno o un proveedor externo contratado para eso, la diferencia con “comprar” no es quién escribe el código, es que el resultado queda hecho a la medida del proceso y es propiedad de la empresa.

Comprar (buy) es licenciar una plataforma que ya existe y que ya resuelve una versión genérica del problema: un CRM con IA integrada, una plataforma de automatización con conectores listos como n8n, Make o Zapier, o un producto vertical armado para una industria específica. Se paga una suscripción, se configura, y se acepta trabajar dentro de los límites de lo que el producto permite.

Anthropic lo resume bien en su guía técnica sobre agentes efectivos: los sistemas que terminan funcionando en producción casi siempre empezaron simples y sumaron complejidad solo cuando quedó demostrado que hacía falta, no al revés. Esa lógica aplica también a la decisión de construir: no es “build todo desde cero” contra “buy la caja cerrada”, hay un rango intermedio real.

Las diferencias que sí mueven la decisión

Estas son las variables que deberían compararse punto por punto para las dos opciones, no una lista suelta de pros y contras genéricos. Si al evaluar un proveedor o un equipo de desarrollo no se puede responder cada una de estas preguntas con un número o un hecho concreto, la decisión todavía no está lista para tomarse.

• Costo inicial vs. costo total de propiedad: comprar casi siempre gana el primer trimestre. Construir casi siempre iguala o supera esa relación a partir del segundo año, si el proceso automatizado es central para el negocio.
• Velocidad de implementación: una plataforma se activa en semanas. Una solución a la medida se diseña, se prueba con datos reales y se ajusta en meses, no en semanas.
• Nivel de control y personalización: construir permite modelar el proceso exacto de la empresa, con sus excepciones y su forma real de operar. Comprar obliga a adaptar el proceso de la empresa al molde del producto.
• Dependencia del proveedor (vendor lock-in): comprar ata el negocio a los precios, los límites técnicos y el roadmap de otra empresa. Construir ata el negocio a la disponibilidad interna (o del proveedor de desarrollo) para mantenerlo.
• Mantenimiento a largo plazo: build exige presupuesto y equipo permanente para sostener el sistema. Buy traslada ese costo al proveedor, pero también le traslada el criterio de qué se arregla primero y cuándo.
• Dueño del conocimiento resultante: en build, lo que el sistema aprende sobre el proceso queda dentro de la empresa. En buy, ese aprendizaje queda dentro del producto del proveedor y se pierde si algún día se cambia de plataforma.
• Escalabilidad frente a casos límite: las plataformas genéricas empiezan a fallar cuando el proceso tiene excepciones reales y frecuentes. El código a la medida se ajusta a esas excepciones, al costo de más desarrollo y más tiempo.
• Riesgo de continuidad: un proveedor puede subir precios, descontinuar el producto o ser comprado por otra empresa. Una solución construida depende de que la empresa no pierda al equipo o al conocimiento que la sostiene.

Cuándo construir tiene sentido

Estas son señales concretas de que construir tiene más sentido que comprar, no una regla general:

• El proceso que se quiere automatizar es el que genera la ventaja competitiva del negocio, no una tarea de soporte administrativo.
• Ya se evaluaron dos o tres plataformas del mercado y ninguna cubre el caso sin workarounds forzados o integraciones frágiles.
• El volumen y la vida útil esperada del sistema justifican amortizar el desarrollo: no es un piloto de tres meses, es infraestructura para varios años.
• Existe presupuesto real para mantenimiento continuo, no solo para el desarrollo inicial (esto se olvida con frecuencia).
• El dato y el criterio que produce el sistema son parte del activo estratégico de la empresa, no un insumo desechable.

Cuándo comprar tiene sentido

Y estas son las señales de que comprar es la decisión correcta, al menos por ahora:

• El proceso es común a cualquier empresa del sector: no hay ventaja competitiva en reinventarlo desde cero.
• Se necesita el resultado operando en semanas, no en meses, para validar la hipótesis de negocio antes de invertir más.
• El equipo interno no tiene capacidad de mantenimiento técnico sostenido en el tiempo.
• El volumen todavía no justifica una inversión de desarrollo: es una fase de piloto o de validación, no de escala.
• Existe una plataforma madura que ya resuelve la mayor parte del caso sin necesitar personalización crítica.

Errores que se repiten al decidir esto

• Comparar solo el costo inicial y nunca proyectar el costo a tres años, incluyendo mantenimiento, soporte, ajustes y el costo de salir del proveedor si hace falta cambiar.
• Construir por orgullo técnico un sistema que una plataforma ya resuelve igual de bien, y gastar el presupuesto de varios meses reinventando algo genérico.
• Comprar sin revisar la portabilidad de los datos: firmar con un proveedor sin entender qué pasa con la información y el conocimiento acumulado si algún día se cancela la suscripción.
• Dejar la decisión en un solo lado: solo en manos de tecnología (que prioriza control) o solo en manos de negocio (que prioriza velocidad), sin cruzar los dos criterios en la misma conversación.
• No preguntar qué tan fácil es salir antes de firmar: aceptar el vendor lock-in sin haberlo decidido conscientemente es el error más caro de los cinco.

Cómo saber si la elección fue correcta

La elección se valida con señales concretas después de un tiempo operando, no con la sensación de que “ya funciona”.

• El costo real después de doce meses (licencias, ajustes, soporte, horas internas) se mantiene cerca de lo proyectado al decidir.
• El sistema sigue resolviendo el proceso cuando el volumen o la complejidad crecen, sin que cada excepción se convierta en un ticket urgente.
• Si hoy hubiera que cambiar de proveedor o de equipo de desarrollo, el conocimiento y los datos generados se pueden migrar sin reconstruir todo desde cero.

Una señal de alerta temprana: si a los seis meses de operar nadie en la empresa puede explicar cuánto cuesta realmente el sistema por mes (sumando licencias, horas de soporte interno y ajustes), la elección no se está midiendo, se está dando por hecho que salió bien.

Mi criterio