La comparación que la mayoría de las empresas hace antes de firmar un contrato de plataforma de agente mira precio por conversación, límite de mensajes y SLA de respuesta. Ninguna de esas líneas mide lo que decide el costo real de la elección en los próximos cinco años: cuánto cuesta salir. En abril de 2026, el analista Kai Waehner publicó el mapeo más completo hasta ahora sobre ese punto ciego — cruzando confianza del proveedor con grado de aprisionamiento — y la conclusión incomoda a quien ya firmó: los proveedores más confiables no son, necesariamente, los más fáciles de dejar.
La pregunta que toda propuesta comercial de plataforma de agente evita responder es simple: si la empresa quiere cambiar de proveedor dentro de tres años, ¿cuánto cuesta eso — en dinero, en tiempo, en contexto reconstruido desde cero? La respuesta nunca está en la tabla de precios. Está repartida en cuatro capas distintas, y cada una aprisiona de una forma diferente.
El mapa que separa confianza de aprisionamiento
El framework de Waehner cruza dos ejes que el mercado suele tratar como si fueran lo mismo: confianza — gobernanza de seguridad del modelo, tratamiento de datos, postura regulatoria — y lock-in — dependencia técnica que aumenta el costo de cambiar. Son ejes independientes. Según su clasificación, proveedores como Microsoft, Salesforce, AWS y SAP caen en el cuadrante de confianza más baja y aprisionamiento más alto — no porque el modelo sea peor, sino porque la integración con el resto del ecosistema (nube, CRM, suite de productividad) empuja el costo de salida hacia arriba, sin importar la calidad técnica del agente.
Confiar en un proveedor de agente y quedar atrapado en él son decisiones distintas — tratarlas como la misma elección es el error que sale caro recién a los tres años de contrato.
Del otro lado del mapa, las opciones técnicamente más abiertas cargan mayor duda sobre gobernanza y soberanía de datos. No existe proveedor que resuelva los dos ejes gratis — existe el proveedor que esconde mejor en qué cuadrante está, generalmente detrás de un discurso de integración que suena a conveniencia y funciona como candado.
Los cuatro vectores que aprisionan, no el proveedor que promete
El mapeo identifica cuatro mecanismos de aprisionamiento válidos para cualquier plataforma de agente, sin importar la marca en el contrato:
- Dependencia de API. La arquitectura del agente se moldea a las decisiones de diseño del proveedor — formato de llamada, límites de contexto, comportamiento de reintento — y cada decisión técnica construida encima se vuelve reescritura cuando el proveedor cambia.
- Captura de framework. La capa de orquestación propietaria — cómo el agente decide qué herramienta llamar, en qué orden, con qué guardrail — se acumula con el tiempo, sin una vía simple de exportación hacia otro motor.
- Gravedad de datos. Contexto acumulado, historial de conversación, ajuste fino hecho sobre el agente: cuanto más invierte la empresa en dejar el agente "calibrado", más caro resulta reconstruir ese aprendizaje en otro lugar.
- Entrelazamiento de ecosistema. Integración nativa del agente con nube, CRM, ERP o suite de productividad — cambiar el agente deja de ser un proyecto aislado y se vuelve renegociación de todo lo que lo rodea.
Son los mismos cuatro vectores, adaptados al mundo de los agentes, que ya mapeamos entre Databricks, Snowflake y BigQuery en el mundo de los data warehouses — la lógica de aprisionamiento se repite, solo cambia la capa donde vive.
El modelo se volvió commodity — el lock-in subió de piso
Un dato de mercado confirma que al menos un vector se está debilitando de verdad: según un relevamiento de Menlo Ventures, la participación de OpenAI en el gasto empresarial de API de LLM cayó de cerca del 50% en 2023 a 27% a fines de 2025, mientras Anthropic subió a casi 40% en el mismo período. Las empresas cambian de modelo con una frecuencia impensable hace dos años — el modelo, aislado, se volvió un ítem de configuración.
El problema es que el lock-in no bajó junto con eso — subió de piso. En febrero de 2026, el término "harness engineering" entró al vocabulario común del sector, popularizado por Mitchell Hashimoto y la fórmula que LangChain ayudó a difundir: agente es igual a modelo más harness. El harness es todo lo que queda entre la llamada al modelo y el resultado de negocio — conexión con herramientas, memoria de contexto, lógica del loop del agente, guardrails, infraestructura de ejecución. Después de dieciocho meses de operación, el modelo se vuelve una línea de configuración; el harness se vuelve la arquitectura real — y ahí vive la capa más difícil de arrancar: la memoria de contexto acumulada.
Un servidor MCP bien diseñado es hoy la fuerza que devuelve algo de portabilidad a la conexión entre agente y herramienta — la única capa del harness que camina hacia un estándar abierto en vez de un formato propietario. El resto — loop de decisión, guardrail, memoria — sigue siendo propietario por diseño, y ahí es donde cada proveedor de plataforma de agente apuesta su retención de clientes.
Cuatro preguntas antes de firmar un contrato de agente
Antes de cerrar un contrato anual de plataforma de agente, cuatro preguntas separan una decisión informada de una apuesta:
- ¿Cuánto del harness es exportable sin reescritura? Orquestación, guardrails y lógica de loop propietarios se vuelven reescritura completa cuando el proveedor cambia — pedir esa estimación antes de firmar, no después.
- ¿Cuánto contexto acumulado queda atado al formato del proveedor? Historial de conversación, embeddings y ajuste fino hechos dentro de la plataforma rara vez se exportan en un formato que otro motor pueda leer.
- ¿Cuántas integraciones nativas con el resto del stack dependen específicamente de este agente? Si el agente está entrelazado con el CRM, ERP o suite de productividad de la propia empresa, cambiar el agente significa cambiar todo el entorno alrededor.
- ¿Cuál es el plazo real de una migración completa — incluyendo el sistema alrededor, no solo el agente? La propuesta comercial mide tiempo de implementación; rara vez mide tiempo de salida.
En el caso de Agentforce, los seis modelos de precios que no se mezclan entre sí ya funcionan, por sí solos, como un vector de aprisionamiento adicional — cambiar de plataforma de agente ahí significa también reconstruir toda la lógica de presupuesto, no solo la integración técnica.
El aprisionamiento que nadie está precificando
El costo de salida rara vez es abstracto — suele venir incluido en otro proyecto que la empresa ni llamaría "cambiar de agente". Dejar Agentforce, por ejemplo, implica evaluar una migración simultánea de CRM — proyecto que típicamente dura entre 18 y 36 meses, según un análisis de switching cost publicado en 2026. Del otro lado, la penetración de Copilot se ubicó en cerca del 3,3% de las licencias corporativas de Microsoft 365 en el tercer trimestre fiscal de 2026 — un número leído, a primera vista, como adopción estancada. En la práctica, esconde una dependencia de flujo de trabajo que se acumula sin importar el volumen de uso: cada automatización construida sobre Copilot Studio, cada dato corporativo indexado, profundiza el vector de ecosistema aun con adopción formal baja.
El pico de exposición al lock-in rara vez es general — es específico de la cuenta, y nadie dentro de la empresa es formalmente dueño de sumarlo antes de que se renueve el contrato.
Buena parte de los pilotos de agente ni siquiera llega a ese punto: una investigación del MIT encontró en 2025 que el 95% de los pilotos empresariales de IA fracasa en escalar, con apenas el 5% entregando impacto de ganancia medible. El detalle que pasa desapercibido es que ese 5% que escala rara vez auditó el lock-in antes de firmar — el éxito técnico hace crecer la exposición junto con el uso, no la reduce. Una consultoría especializada, sin incentivo de reventa de ningún lado, es quien puede hacer esa auditoría mirando los cuatro vectores — no el discurso comercial del proveedor que está del otro lado de la mesa.
Preguntas que siempre vuelven
Para cerrar, las dudas más comunes sobre lock-in en plataforma de agentes de IA.
¿Qué es el lock-in en plataforma de agentes de IA?
El lock-in en plataforma de agentes es la dependencia técnica y operativa acumulada en cuatro vectores — dependencia de API, captura del framework de orquestación, gravedad de datos de contexto y entrelazamiento con el resto del ecosistema — que hace que cambiar de proveedor cueste más de lo que sugiere el contrato original. No es una cláusula única en el contrato; es la suma de decisiones técnicas tomadas a lo largo del tiempo de uso.
¿La confianza en el proveedor garantiza menos lock-in?
No. Un mapeo de abril de 2026 cruzó ambos ejes y mostró que se mueven de forma independiente: proveedores con gobernanza de seguridad y postura regulatoria sólidas — confianza alta — pueden cargar un aprisionamiento igualmente alto cuando su integración con la nube, el CRM o la suite de productividad es profunda. Lo inverso también aplica: las opciones técnicamente más flexibles suelen levantar mayores dudas sobre gobernanza. Evaluar solo uno de los dos ejes deja la decisión incompleta.
¿Cómo medir el lock-in antes de firmar un contrato de agente?
Con cuatro preguntas objetivas: cuánto del harness (orquestación, guardrails, lógica de loop) es exportable sin reescritura; cuánto contexto acumulado — historial, embeddings, ajuste fino — queda atado al formato del proveedor; cuántas integraciones nativas con el resto del stack dependen específicamente de este agente; y cuál es el plazo real de una migración completa, incluyendo el sistema alrededor, no solo el agente aislado. Un proveedor que no sabe responder la cuarta pregunta, o la esquiva, es una señal de alerta.