Lo que SAP y Databricks no te cuentan del "Autonomous Enterprise"

Por qué el lock-in de las plataformas cerradas de datos e IA le sale más caro a una empresa mediana que a una corporación grande.

SAP acaba de presentar su “Autonomous Enterprise” en Sapphire 2026: agentes de IA propios, orquestados dentro de su ecosistema, prometiendo que la empresa “corre sola”. Databricks, por su lado, lleva meses posicionando su warehouse como la única base seria si quieres hacer IA en serio con tus datos.

Ambos mensajes suenan igual de bien. Y ambos omiten la misma pregunta, la que casi nadie hace en la reunión de ventas: si en dos años quieres cambiarte, ¿cuánto te cuesta?

Esa pregunta no es un detalle técnico. Es la que separa una decisión de infraestructura de una hipoteca a diez años sobre cómo opera tu empresa.

El problema no es la plataforma, es lo que pasa después de firmarla

Ninguna de las dos plataformas es mala. SAP hace ERP de nivel corporativo desde hace décadas. Databricks resuelve problemas reales de procesamiento de datos a escala. El problema no es la capacidad técnica — es lo que ocurre una vez que tu empresa queda adentro.

Cuando tus datos viven en el formato propietario de una plataforma, tus flujos de trabajo corren sobre su motor y tu equipo se entrenó en su interfaz, salir deja de ser una decisión técnica. Se convierte en un proyecto de meses — a veces de más de un año — solo para terminar teniendo, en otro lado, más o menos lo mismo que ya tenías. Ese costo de salida tiene nombre: vendor lock-in. Y es, casi siempre, el costo que no aparece en ninguna propuesta comercial.

A una corporación con miles de empleados y un presupuesto de TI de ocho cifras, ese costo se le diluye. Puede absorber una migración de dos años sin que el negocio se detenga. A una empresa de 50 a 500 empleados — el tamaño donde hay presupuesto real pero no un equipo de datos propio — ese mismo costo no se diluye en nada. Se siente completo, y se siente una sola vez, en el peor momento posible: cuando la empresa ya creció más allá de lo que la plataforma original podía sostener a buen precio.

¿Qué significa “Autonomous Enterprise” en la práctica?

El mensaje de SAP es que los agentes de IA van a operar procesos completos — desde compras hasta finanzas — sin intervención humana constante. Es una promesa atractiva y, en el papel, técnicamente alcanzable.

Lo que no se dice con la misma claridad es que esos agentes autónomos corren exclusivamente dentro del stack de SAP. No es una capa de IA que se pueda mover a otra plataforma si el negocio decide cambiar de ERP, ni una que el cliente pueda auditar o modificar libremente: es una función más del ecosistema, con el mismo candado que el resto.

Esto no convierte al anuncio en una mala noticia para todos. Para una empresa que ya tiene toda su operación en SAP, que no planea moverse en los próximos diez años y que valora tener todo integrado bajo un solo proveedor con soporte 24/7, la propuesta puede tener sentido real. El problema aparece cuando una empresa mediana, que todavía está decidiendo cómo estructurar su infraestructura de datos, adopta ese mismo camino sin medir el costo de salida — simplemente porque el nombre suena a la solución definitiva.

¿Qué significa el warehouse de Databricks en la práctica?

El argumento de Databricks es distinto pero termina en el mismo lugar: centralizar todo tu procesamiento de datos e IA en su plataforma para tener “una sola fuente de verdad” con el rendimiento necesario para modelos de machine learning a escala.

Es una arquitectura sólida, usada por empresas serias. Pero de nuevo: los pipelines, los jobs de procesamiento y los modelos entrenados quedan atados a su motor (aunque parte de los datos se guarden en formatos abiertos como Delta Lake, la lógica operativa alrededor no lo es). Cambiar de proveedor de cómputo más adelante implica reescribir buena parte de esa lógica, no solo mover archivos.

Para una empresa que procesa terabytes diarios y necesita el rendimiento específico que Databricks ofrece, ese trade-off puede justificarse. Para una empresa mediana que necesita centralizar datos de un ERP, un CRM, algunas hojas de cálculo y WhatsApp Business — el escenario real de la mayoría de las empresas de 50 a 500 empleados en LATAM — es una arquitectura sobredimensionada, con un costo de entrada y de salida que no corresponde al problema que hay que resolver.

La alternativa: la misma capacidad, sin el candado

Existe un camino que llega al mismo destino — datos centralizados, dashboards, automatizaciones, IA aplicada al negocio — construido sobre herramientas abiertas: bases de datos estándar, motores de procesamiento open source, modelos de IA que se pueden intercambiar según el caso de uso en vez de atarse a uno solo.

La diferencia no está en lo que la empresa puede hacer con sus datos — en ambos caminos puede automatizar procesos, tener reportes en tiempo real y usar IA para tomar mejores decisiones. La diferencia está en quién controla lo que pasa después: el precio que puede subir sin aviso, la función que puede descontinuarse, la migración que puede volverse obligatoria el día que el proveedor cambie de estrategia.

Con un stack abierto, esas decisiones las toma la empresa. El cliente es 100% dueño de lo construido y puede decidir si quiere mantenerlo por sus propios medios o seguir trabajando con quien se lo construyó — es una decisión suya, no una cláusula contractual que lo obliga.

¿Invertir en infraestructura propia realmente rinde, o es solo idealismo técnico?

La objeción más razonable a todo este argumento es: “suena bien en la teoría, pero construir algo propio en vez de comprar una plataforma lista, ¿de verdad compensa el esfuerzo?”

Hay evidencia concreta de que sí. dbt Labs — una de las herramientas de transformación de datos más usadas en stacks abiertos — publicó en julio de 2026 que sus clientes recuperaron en promedio el equivalente a 58.7 posiciones de tiempo completo en capacidad operativa, por un valor de 1.75 millones de dólares al año, simplemente por invertir en infraestructura de datos propia bien diseñada en vez de depender de procesos manuales o de plataformas cerradas que no se ajustaban a su operación real.

Ese número no viene de una plataforma vendiendo su propio producto — viene de medir el efecto de tener control real sobre la infraestructura de datos, sin importar qué herramientas específicas se usen debajo. Es la misma lógica que sostiene la elección de un stack abierto: no es una postura ideológica sobre software libre, es una decisión económica sobre quién controla el costo a largo plazo.

Cómo se ve esto en una empresa mediana real

Un caso anonimizado que ilustra el problema con números: una empresa manufacturera de la región, de unos 180 empleados, contrató hace tres años una plataforma de BI en la nube integrada a su ERP. La promesa era la de siempre — un solo panel para todo, sin necesidad de armar nada por fuera.

Funcionó bien mientras la empresa tuvo un solo país de operación y un volumen de datos moderado. Cuando abrió una segunda planta y empezó a vender en dos países más, el volumen de datos y de usuarios creció, y el costo de licencias de esa plataforma se triplicó en 18 meses — el modelo de precios estaba atado a usuarios activos y a volumen de consultas, no a un plan fijo.

Cuando la empresa evaluó migrar a algo más ajustado a su tamaño real, se encontró con que los reportes, los modelos de datos y las automatizaciones que había construido en tres años vivían enteramente dentro del formato propietario de esa plataforma. Migrarlos no era “exportar un archivo” — era reconstruir la lógica de negocio desde cero en otra herramienta, con el equipo interno aprendiendo una sintaxis nueva mientras el negocio seguía operando con reportes duplicados durante la transición.

El costo de esa migración terminó siendo comparable a lo que hubiera costado construir la solución completa desde el principio con herramientas abiertas — con la diferencia de que esta vez ya habían pagado tres años de licencias antes de siquiera empezar.

Ese es exactamente el escenario que un stack abierto evita, no porque sea gratis o mágico, sino porque separa la herramienta de la lógica de negocio: si la empresa crece o cambia de dirección, se reemplaza la pieza que dejó de servir sin tener que reconstruir todo lo demás.

Qué significa “stack abierto” en la práctica, servicio por servicio

No es un concepto abstracto — se traduce en decisiones concretas sobre cada pieza de la infraestructura:

• Centralización de datos (Data Lake & Warehouse): las fuentes (ERP, CRM, hojas de cálculo, WhatsApp Business, bancos) se integran sobre motores de base de datos estándar, no sobre un formato propietario que solo una plataforma puede leer.
• Integración de fuentes (ETL): los pipelines que mueven y transforman los datos quedan documentados y son portables — se pueden mover a otro motor de cómputo sin reescribir la lógica de negocio desde cero.
• Dashboards (Business Intelligence): se construyen sobre herramientas como Metabase, que leen directamente de la base de datos de la empresa — no exigen que los datos “vivan” dentro de la herramienta de visualización para funcionar.
• Búsqueda inteligente (RAG documental) y agentes de IA: se conectan a los modelos de lenguaje que mejor convengan en cada momento — sin atarse a un solo proveedor de IA que puede subir precios o cambiar condiciones de uso sin aviso.
• Automatizaciones: corren sobre n8n, una herramienta abierta que la empresa puede alojar donde quiera, en vez de depender de un flujo que solo existe dentro del ecosistema de un vendor específico.

Cada una de esas piezas se puede reemplazar de forma independiente si el negocio lo necesita, sin arrastrar al resto del sistema en la migración.

Tabla comparativa: stack propietario vs. stack abierto

	Stack propietario (SAP, Databricks)	Stack abierto
Capacidad técnica	Alta, probada a gran escala	Alta, equivalente para el 90% de los casos de empresas medianas
Costo de entrada	Suele incluir licencias, mínimos de consumo o compromisos anuales	Se cotiza por el alcance real del proyecto, sin mínimos de licencia
Costo de salida	Alto — migrar implica reconstruir lógica y reentrenar al equipo	Bajo — los datos y la lógica quedan en formatos y herramientas estándar
Quién controla el roadmap	El proveedor	La empresa, con el proveedor que ella elija en cada momento
Soporte integrado 24/7 propio del vendor	Sí, como parte del contrato	Depende del proveedor de servicios elegido, no de la herramienta en sí
Ideal para	Empresas grandes, ya integradas al ecosistema, sin planes de migrar	Empresas medianas que están definiendo su infraestructura y quieren mantener el control

¿Cuándo tiene sentido el stack propietario, y cuándo no?

Ser honesto sobre esto es lo que diferencia un análisis real de un argumento de venta. El lock-in no es automáticamente negativo — es un costo que a veces vale la pena pagar.

Tiene sentido cuando: la empresa ya opera con miles de usuarios sobre un ERP como SAP y separar los módulos sería más costoso que quedarse. También cuando el volumen de datos exige el rendimiento específico que una plataforma como Databricks ofrece de fábrica, y no hay equipo interno con tiempo para operar una arquitectura propia. En esos casos, pagar por integración y soporte todo-en-uno es una decisión razonable, no un error.

No tiene sentido cuando: la empresa todavía está definiendo cómo estructurar sus datos, tiene entre 50 y 500 empleados, y no tiene la certeza (ni la necesidad) de comprometerse con un solo proveedor por los próximos diez años. En ese escenario, adoptar una plataforma cerrada “porque es la que usan las empresas grandes” suele significar pagar por capacidad que no se va a usar, y comprar un costo de salida que nadie calculó antes de firmar.

Lo que puedes hacer esta semana

Antes de firmar cualquier contrato de plataforma “todo en uno” — de datos, de IA o de ERP — pide una respuesta concreta a esta pregunta: si en dos años decidimos migrar, ¿cuánto cuesta y cuánto tiempo toma? Pide que te lo pongan por escrito, no como estimado verbal en la reunión de ventas.

Si la respuesta es vaga, o si nadie en la sala quiere comprometerse con un número, ya tienes la respuesta real a la pregunta que de verdad importa.

Si ya firmaste ese contrato hace tiempo y no tienes esa respuesta, el ejercicio igual vale la pena: pide a tu equipo (o a quien te dé soporte) que documente qué pasaría si tuvieran que migrar mañana. No para hacerlo — solo para saber, con números reales, qué tan atada está hoy tu operación a un solo proveedor. Esa cifra, aunque no la uses de inmediato, es la que te permite negociar mejor la próxima renovación de contrato, y la que te avisa con tiempo si conviene empezar a planear una salida gradual en vez de esperar a que el costo de quedarse se vuelva insostenible.

Preguntas frecuentes

¿Un stack abierto es más barato que uno propietario?

No siempre en el costo inicial — a veces cuesta lo mismo o más armar la solución a medida. La diferencia real está en el costo de salida: con stack abierto es bajo, con plataformas cerradas puede ser el gasto más alto de todo el proyecto.

¿Usar herramientas open source significa que Raifen no da soporte?

No. El soporte lo da el equipo de Raifen (o el proveedor que la empresa elija), no una mesa de ayuda genérica de la herramienta. La diferencia es que ese soporte no es obligatorio de por vida — la empresa puede prescindir de él sin perder lo construido.

¿Empresas grandes también usan stack abierto?

Sí, muchas de las plataformas de datos más grandes del mundo (Netflix, Airbnb, Uber, entre otras) construyen su infraestructura core sobre herramientas open source, justamente para no depender de un solo proveedor a esa escala.

¿Cómo sé si mi empresa ya está en una situación de lock-in?

Una señal clara: si nadie en tu equipo puede explicar cómo se extraerían todos los datos y procesos si mañana cambiaran de proveedor, ya estás dentro de un lock-in — aunque todavía no lo hayas sentido como un problema.

¿Raifen solo trabaja con stack abierto?

Sí, por diseño. Es la base de la propuesta: sin dependencia de proveedores propietarios como SAP, Power BI o Snowflake, con cada proyecto cotizado sobre su alcance real para llegar a la mejor estimación posible desde el principio.

¿Qué pasa si mi empresa ya invirtió en una plataforma cerrada y no puede migrar ahora mismo?

No hace falta migrar todo de un día para otro. Lo más común es empezar por la pieza más nueva o menos integrada — por ejemplo, un dashboard adicional o una automatización puntual — construida ya sobre stack abierto, mientras el resto sigue operando como está. Con el tiempo, esa proporción se invierte, sin el riesgo ni el costo de una migración total de golpe.