¿Comprar o construir la IA? La elección de la plataforma para una pyme

Cuando una pyme decide adoptar la IA en un proceso, la pregunta que oye con más frecuencia es «¿qué software compro?». Pero antes hay una que pesa más, y que casi nadie plantea: ¿conviene comprar una plataforma ya hecha o construir algo a medida? La respuesta cambia los plazos, los costes y los riesgos mucho más que la elección entre dos tool competidoras. Aquí intentamos responder con un criterio, no a instinto — y luego miramos el panorama de las herramientas con las que, en la práctica, se «compra».

Comprar o construir: la pregunta antes de la pregunta

Los frameworks de build-vs-buy más usados en 2026 hacen evaluar un caso de uso en tres ejes:

• Unicidad — hasta qué punto el flujo es específico de su empresa, en lugar de genérico y ya resuelto por otros mil.
• Sensibilidad de los datos — ¿un proveedor externo puede tocar estos datos, o deben permanecer bajo su control?
• Valor estratégico — ¿es un diferenciador competitivo o una actividad de back-office que solo quiere despachar bien?

La lectura es sencilla: alto en los tres → construir tiene sentido. Dos o más ejes bajos → comprar. La mayor parte de los flujos que una pyme quiere automatizar primero — clasificación de tickets, seguimientos comerciales, conciliaciones, informes — es genérica, de baja sensibilidad y de back-office. Es decir: para comprar.

Comprar gana en velocidad: las plataformas gestionadas se activan en días o pocas semanas, y el retorno se ve en 1–6 meses. Construir gana a largo plazo pero es lento — 12–24 meses para el ROI — y requiere un equipo mínimo (un ingeniero de IA, un desarrollador backend, un product owner, y para un agente en producción también quien se ocupa de DevOps y de la evaluación). Casi ninguna pyme tiene ese equipo en casa.

Hay también un umbral de volumen útil que tener en mente: por debajo de aproximadamente un millón de interacciones al año, comprar gana casi siempre por la rapidez de integración; solo por encima de ese volumen la economía «por token» de lo construido empieza a compensar. Muy pocas pymes cruzan esa línea — y quien la cruza ya no es una pyme en ese proceso.

La vía intermedia que en 2026 es casi el estándar: el híbrido

La elección no es tajante. El modelo que la mayor parte de las implementaciones serias adopta hoy es híbrido: se compra el modelo lingüístico (las API de OpenAI o Anthropic) y se construye solo la orquestación y las integraciones sobre un framework open-source. Reduce en un 40–50% los plazos respecto a hacerlo todo desde cero, pero deja el control sobre la lógica de negocio donde debe estar: de su lado. Es la forma sobre la que, en nuestra experiencia, debería aterrizar casi todo proyecto: compra el modelo, injerta la lógica.

Las plataformas con las que se «compra»

Cuando el caso de uso es para comprar, el mercado de las herramientas de automatización y de los agentes se reduce a pocas plataformas horizontales. No existe una «mejor» en absoluto: existe la adecuada para su stack y su volumen. He aquí cómo se distinguen.

Make — la mejor relación operaciones/precio

Constructor visual de escenarios, más de 3.000 apps conectables, con un agent builder en beta. Su fuerza es económica: el plan de entrada cubre decenas de miles de operaciones por un gasto contenido, y sigue siendo el más económico de los tres incluso al crecer en volumen. Es la elección de default cuando los flujos son muchos y frecuentes y cuenta el coste por operación.

Zapier — la cobertura más amplia

El constructor de «zaps» más extendido, con un copiloto en lenguaje natural y agentes autónomos que actúan entre las apps. Su virtud son las integraciones: más de 8.000, el parque más extenso. Debe elegirse cuando el stack del cliente está hecho de software de nicho y de cola larga — no cuando el volumen de actividad es alto, porque es el modelo que peor escala en coste al crecer las operaciones.

n8n — la capacidad agéntica más profunda

Node-based y autoalojable; la versión 2.0 (enero de 2026) trae la integración nativa con LangChain, unos 70 nodos de IA, memoria persistente, nodos para RAG y vector-DB y esquemas con el humano en el proceso. Es la elección adecuada cuando hace falta un flujo realmente agéntico — no solo desencadenado por un evento — y cuando se puede alojar la plataforma en casa, manteniendo los datos bajo control. Es el punto en el que «comprar» se difumina en el híbrido.

Microsoft Copilot Studio y Salesforce Agentforce — solo si ya está dentro

Copilot Studio (agentes de pago por consumo dentro del ecosistema Microsoft 365/Azure) y Agentforce (agentes por licencia sobre el CRM de Salesforce) tienen sentido en un solo caso: si la empresa ya vive en esa plataforma. Los datos, el runtime y la elección del modelo quedan ligados al cloud del proveedor, y el umbral de precio — por puesto o por conversación — parte demasiado alto para el presupuesto de una pyme que no sea ya cliente. Fuera de ese stack, raramente cuadran las cuentas.

Cómo se paga cuenta más que el precio de tarifa

Las tarifas cambian; el modelo de precio permanece, y es la verdadera palanca de decisión. Antes de mirar la cifra, mire cómo se paga, porque es lo que determina si el coste se disparará con el crecimiento:

• Por operación o por tarea (Make, Zapier) — predecible en los volúmenes bajos, a modelar con atención si las automatizaciones se multiplican.
• Autoalojado (n8n) — el coste es la infraestructura y quien la gestiona, no una licencia por consumo: conviene en los volúmenes altos y cuando los datos no deben salir.
• Por mensaje (Copilot Studio) — premia las acciones breves, castiga las conversaciones largas y elaboradas.
• Por conversación o por puesto (Agentforce) — lo contrario: aguanta bien las interacciones de varios pasos, menos los grandes volúmenes de micro-solicitudes.

La regla práctica para una pyme: Make y n8n son el default sostenible — un gasto mensual contenido, o el solo coste del hosting — coherente con la idea de llevar la IA a la empresa sin la factura de una gran consultoría. Copilot Studio y Agentforce entran en juego solo cuando el cliente ya está dentro de ese mundo.

Cuándo, en cambio, conviene construir

Si un caso de uso es alto en unicidad, sensibilidad de los datos y valor estratégico, comprar no basta. Pero incluso entonces, «construir» en 2026 no significa partir de la hoja en blanco: significa tomar los andamiajes open-source ya estándar para la orquestación de los agentes — LangChain/LangGraph, CrewAI — y apoyarlos sobre un modelo comprado vía API, en lugar de entrenar uno propio. Es la forma concreta del híbrido anterior, y es también el único modo en que una pyme puede permitirse lo «construido»: si alguien le proporciona ese equipo como injerto, en lugar de tener que contratarlo.

Aquí la sensibilidad de los datos se convierte en la restricción que lo decide todo. Si el flujo toca datos personales o regulados, la elección de la plataforma no es solo técnica: es una elección de conformidad. Vale la pena pasarla antes por el overlay de conformidad — nivel de riesgo, EIPD, dónde residen los datos — y luego decidir si auto-alojar y qué auto-alojar.

Cómo elegir, en la práctica

Resumiendo el recorrido, sin atajos:

1. Valore el caso de uso en los tres ejes (unicidad, sensibilidad, valor estratégico). Dos o más bajos → se compra.
2. Si se compra, elija la plataforma por el modelo de precio y por su stack, no por la tarifa: Make por el coste por operación, Zapier por la cobertura, n8n por la profundidad agéntica y el control de los datos.
3. Si se construye, piense híbrido: compre el modelo, construya solo la orquestación — y valore quién le pone el equipo.
4. En ambos casos, haga pasar primero los datos sensibles por los controles de conformidad, no después.

Es exactamente el método con el que trabajamos: primero entender dónde está y qué conviene automatizar, luego elegir la plataforma adecuada — comprada, construida o injertada a medias — con los controles alrededor. No una herramienta impuesta desde arriba, sino un injerto que arraiga en su stack.

¿No sabe por qué proceso empezar, antes incluso de elegir la herramienta? La evaluación de AI-readiness le da una primera indicación en dos minutos; y en la página Servicios encuentra, departamento por departamento, cómo es un AI Workflow Design concreto.

Los criterios de build-vs-buy citados sintetizan frameworks públicos de 2026 (entre otros Composio y Pharos); las características y las cifras de tarifa de las plataformas son autoinformadas por los respectivos proveedores (Make, Zapier, n8n 2.0, Microsoft Copilot Studio, Salesforce Agentforce), varían con el tiempo y deben leerse como indicativas — no como un presupuesto. Este artículo tiene finalidad orientativa y no constituye asesoramiento jurídico ni una evaluación de conformidad.