Ensayo · Capital y contratos

El encierro que aún no ves: un marco para leer el costo de salida antes de firmar

Toda relación con un proveedor de tecnología empieza igual: una demostración convincente, un precio razonable, y un equipo de ventas asegurándote que cambiar después, si alguna vez llega el caso, será sencillo. Casi nunca lo es. El encierro no llega como un solo momento dramático. Se acumula en silencio, renovación tras renovación, integración tras integración, hasta el día en que te das cuenta de que el precio razonable del año uno se convirtió en una posición de negociación que el proveedor sostiene porque sabe exactamente lo caro que te sería irte ahora.

Las cifras se han vuelto más nítidas en 2026 de lo que eran hace apenas dos años, en buena medida porque las funciones de IA agregaron nuevas capas de dependencia encima de las que los ejecutivos ya sabían rastrear. Un análisis de 2026 sitúa el costo promedio de una migración empresarial de proveedor en unos 315,000 dólares, y encuentra que las organizaciones atrapadas en una situación de encierro sin planificación previa enfrentan costos de cambio hasta dieciséis veces mayores que las que incorporaron la planificación de salida en el contrato original.[1] La misma investigación identifica que los compradores de software empresarial en 2026 acumulan de rutina costos de cambio en cuatro o más relaciones con proveedores de IA simultáneamente — abarcando categorías como suites de productividad, CRM e infraestructura en la nube — casi sin ninguna metodología para medir qué significa esa acumulación para su posición negociadora en el siguiente ciclo de renovación.[1]

Tres tipos de encierro, y por qué se componen

Vale ser específico sobre los mecanismos, porque «encierro» como palabra única tiende a aplanar tres riesgos genuinamente distintos en uno solo, y cada uno requiere una mitigación diferente. El encierro de datos suele ser el más caro de escapar, porque involucra no solo los registros sino los metadatos, la configuración y el contexto histórico que le daban a los datos su valor operativo. El encierro de flujo de trabajo suele ser el más difícil de ver venir, porque después de dos o tres años construyendo procesos internos alrededor de la interfaz y la lógica específicas de un proveedor, «cambiar» no significa solo migrar datos: significa reconstruir los procesos de los que tus equipos han llegado a depender en silencio. Y el encierro de integración es lo que vuelve especialmente dolorosa la oportunidad de una salida: cada conexión de API construida a lo largo de los años asume el modelo de datos específico del proveedor, y migrar eso no es un proyecto de fin de semana. De rutina es un trimestre completo de ingeniería dedicada, a veces más.[1]

La meta no es cero encierro. Es un encierro con precio y entendido, asumido a propósito y no descubierto tres años después.

Preguntas que pertenecen a toda revisión de plataforma

Las organizaciones que evitan esta trampa no evitan las relaciones con proveedores; eso no es posible ni sensato en casi ninguna categoría. Hacen un conjunto específico de preguntas antes de firmar que casi todos los procesos de compras se saltan por completo, porque el proceso estándar está hecho para evaluar precio y funcionalidades, no costo de salida.

La primera es la portabilidad de datos, preguntada con un nivel de especificidad que incomoda visiblemente a casi todos los proveedores. No «¿podemos exportar nuestros datos?»: a esa todos dicen que sí. La pregunta real es: en qué formato, con qué nivel de completitud, y a qué costo en tiempo de ingeniería haría falta para operacionalizar esos datos exportados en otro lugar. Una exportación CSV de registros crudos, despojada de la configuración, la lógica de flujo de trabajo y el contexto histórico que hacían valiosa la plataforma, no es portabilidad. Es un comprobante en papel.

La segunda es la profundidad de integración frente a la superficie de integración. Un proveedor profundamente incrustado en tres flujos de trabajo genuinamente críticos representa un perfil de riesgo distinto que uno incrustado superficialmente en quince menores. La profundidad crea costo de cambio real aunque la superficie parezca manejable en un mapa de proveedores, porque desenredar un solo flujo profundamente incrustado puede tomar más tiempo y costar más que migrar diez superficiales juntos. Esto debería mapearse explícitamente durante cualquier revisión significativa de contrato, no estimarse a ojo según qué tan «importante» parece el proveedor.

La tercera es la estructura de precios bajo crecimiento, no el precio al firmar. Los proveedores fijan de rutina un primer contrato agresivo para ganar el trato, y luego estructuran el modelo de precios para capturar valor desproporcionado a medida que crece el uso: costo por usuario sin descuento por volumen, precios por consumo sin techo, o paquetes que vuelven prácticamente imposible una adopción parcial una vez que la empresa está incrustada. Los aumentos recientes de precios en el mercado SaaS ilustran el patrón: un proveedor importante de CRM subió precios doce por ciento, un proveedor de suite de productividad quince por ciento, y un proveedor de plataforma web veintitrés por ciento en un solo ciclo.[2] Pregunta específicamente cómo se ve el contrato con tres y diez veces el uso actual, no solo con el volumen de hoy, antes de firmar.

La cuarta, y la que los directorios en particular deberían estar preguntándole a la gerencia de frente, es qué pasa ante una consolidación de proveedores. ¿Cuál es la posición contractual y operativa de la empresa si este proveedor es adquirido por un competidor directo, descontinúa la línea de producto de la que la empresa depende, o es adquirido por una organización con cuyas prácticas de datos la empresa nunca habría elegido hacer negocios? No es una pregunta hipotética en un mercado de software que atraviesa tanta consolidación impulsada por IA como el actual.

El contraargumento honesto

Nada de esto argumenta contra las alianzas con proveedores, y tratar la dependencia como inherentemente peligrosa lleva directo de vuelta a la trampa de construir contra comprar, donde las organizaciones levantan alternativas internas carísimas para evitar una dependencia manejable y terminan con algo peor de lo que un proveedor maduro ya ofrecía. Algo de encierro es simplemente el precio de un producto genuinamente bueno, y una empresa que rechace toda dependencia significativa terminará construyéndolo todo ella misma a un costo enorme, o eligiendo perpetuamente proveedores inmaduros y no probados justamente porque son más fáciles de dejar, lo que cambia un riesgo de costo de cambio real y acotado por un riesgo de ejecución mucho mayor y mucho menos acotado. La meta no es cero encierro. Es un encierro con precio y entendido, asumido deliberadamente en lugar de descubierto tres años después durante una negociación de renovación para la que el proveedor lleva todo ese tiempo preparándose en silencio.

Tratar las cláusulas de salida con la misma seriedad que las de entrada es la disciplina a la que se reduce todo esto, porque las de salida son las que de verdad vas a necesitar en el año tres, cuando la relación cambió, el precio se movió y la palanca pasó decididamente al otro lado de la mesa. ¿Cómo se ve realmente la posición de salida de tu organización en los contratos de plataforma firmados este año, y alguien sabe la respuesta antes de que la conversación de renovación la saque a la luz?

Fuentes

  1. Investigación sobre encierro con proveedores de IA empresarial y costos de cambio, 2026. vaasblock.com
  2. Datos de aumentos de precios de proveedores SaaS, citados en «The 2026 SaaS Pricing Squeeze», Lynton Library. lyntonweb.com

Juan Vegarra es autor de El manual del outsider (próximamente). Las opiniones aquí son suyas. Más ensayos · Escríbeme