En la era de los agentes, la distancia entre el lugar donde ocurre el negocio y el lugar donde se analiza se convierte en deuda de arquitectura, con efecto directo en riesgo, gobernanza y capacidad de decisión.
Durante décadas, la arquitectura de datos aceptó una división casi natural: por un lado, los sistemas transaccionales; por otro, los entornos analíticos. Funcionó durante mucho tiempo. En la era de los agentes, esa división cobra intereses.
«The foundation is invisible until it isn’t.»
En el Data + AI Summit 2026, Databricks anunció LTAP, o Lake Transactional/Analytical Processing: una arquitectura que unifica transacciones, analítica, streaming y datos operacionales en una sola copia de almacenamiento en el lake. Según Ali Ghodsi, cofundador y CEO de Databricks:
«For decades, complicated data infrastructure was a tax that teams were forced to pay. Then agents arrived (…) The infrastructure that powered the last era of computing is now the bottleneck that no one can afford. LTAP removes it.»
La ambición declarada es alta: rehacer la fundación de la arquitectura de datos justo cuando, según la propia Databricks, la IA ya ayuda a los desarrolladores a escribir cerca de 50 veces más aplicaciones que antes, gran parte de ellas operadas por agentes.ever cerca de 50 vezes mais aplicações do que antes, boa parte delas operada por agentes.
El problema: la empresa opera en un lugar y decide en otro
En la arquitectura tradicional, el dato nace en los sistemas operacionales: core banking, ERP, CRM, plataformas de atención, e-commerce, sistemas de riesgo, cobranza, logística, siniestros o antifraude. Es el mundo OLTP, creado para registrar la operación.
Después, ese dato se mueve mediante pipelines de ETL, ELT, CDC, batch o streaming hacia los entornos analíticos. Allí se transforma, se agrega, se modela y se pone a disposición de BI, ciencia de datos, gobernanza, modelos de IA y aplicaciones de negocio. Es el mundo OLAP, creado para interpretar la operación.
Ese modelo generó valor y generó dependencias. Cada copia de dato aumenta el costo de almacenamiento, procesamiento y control, y cada pipeline suma latencia, fragilidad y mantenimiento. A eso se suma la inconsistencia que introduce cada capa intermedia, además de las políticas propias de acceso, auditoría, lineage y retención que exige cada entorno separado.
El resultado es conocido por muchos CIOs y CTOs. La empresa invierte en datos y aún discute cuál número es el correcto. Invierte en IA y tiene dificultad para explicar de dónde vino el dato. Moderniza plataformas y, aun así, sigue atada a pipelines críticos y poco visibles.
La pregunta que importa hoy es una sola: ¿la empresa tiene una fundación confiable para transformar el dato operacional en una decisión auditable?
Qué es LTAP
LTAP significa Lake Transactional/Analytical Processing. Según Databricks, la propuesta acerca el procesamiento transaccional, el procesamiento analítico, el streaming, las aplicaciones de datos y la IA a una fundación lakehouse gobernada, eliminando ETL, réplicas y pipelines por diseño.
En términos simples, LTAP une el lugar donde ocurre el negocio con el lugar donde el negocio se analiza. Aplicaciones, analítica y agentes pasan a trabajar sobre la misma copia de dato, con gobernanza unificada a través de Unity Catalog.
Esta convergencia convive con sistemas legacy. Los sistemas transaccionales antiguos siguen existiendo, y no todo workload OLTP u OLAP necesita migrar a una sola plataforma. Aun así, la separación rígida entre dato operacional y dato analítico es cada vez menos sostenible para quien quiere operar IA en producción.
Por qué esto importa en la era de los agentes
La IA generativa trajo una primera ola de productividad: copilotos, asistentes, búsqueda semántica, generación de texto, análisis de documentos y automatización de tareas. La siguiente ola es más exigente, porque los agentes ejecutan acciones.
Un agente corporativo consulta el estado de un cliente, analiza riesgo, recomienda una acción, activa un workflow, registra la decisión y monitorea el impacto. Opera en un ciclo continuo: lee contexto, interpreta datos, decide o recomienda, ejecuta, registra el resultado y aprende del retorno.
Ese ciclo exige dato fresco, contexto confiable, gobernanza consistente y capacidad de escribir de vuelta en los sistemas correctos. Cuando el dato operacional vive en un entorno, el analítico en otro, los modelos en una tercera capa y los agentes operan por fuera de esa cadena, la arquitectura se vuelve frágil. El agente lee un dato atrasado, ignora una política, usa una métrica inconsistente, actúa sin trazabilidad o genera un resultado difícil de auditar.
Para empresas reguladas o de operación crítica, esto es un problema de confianza, con impacto directo en riesgo y auditoría.
Cómo presenta Databricks el LTAP
LTAP se apoya en Lakebase, lanzado en 2025 como base de datos serverless en Postgres integrada al lakehouse. Según Databricks, Lakebase ya sirve a miles de clientes, incluyendo Block, Ensemble, Superhuman y Zillow, y procesa 12 millones de lanzamientos de base de datos por día. Como resume Grant Veazey, CTO de Ensemble, sobre la fundación construida con Databricks:
«Lakebase and LTAP extend that foundation by unifying operational and analytical workloads on a single layer, giving our RCM-native AI the real-time access it needs to perform in live operations.»
La gobernanza corre sobre Unity Catalog: identidad, permisos, auditoría y lineage unificados para datos y activos de IA, tanto en Lakebase como en el lakehouse. Alrededor de esta fundación, Databricks también presentó otras piezas de lo que llama la era agentic: Genie One como copiloto agentic de datos, Agent Bricks para construir agentes sobre datos propios, Omnigent para políticas de gobernanza de agentes, OpenSharing para compartir datos entre organizaciones, y aplicaciones como Lakewatch (SIEM agentic) y CustomerLake (CDP agentic).
Juntas, estas piezas sostienen la narrativa central de Databricks: aplicaciones, analítica, agentes y gobernanza operan sobre una fundación común. Según el propio comunicado de prensa, LTAP «is coming soon as a part of Lakebase»: es una arquitectura anunciada, todavía no disponible de forma general.
Otra pieza de esta fundación es Lakehouse//RT, un nuevo warehouse en tiempo real, hoy en beta, cuyo motor Reyden entrega, según pruebas de la propia Databricks, hasta 16 veces más rendimiento que las capas de serving dedicadas, con latencia sub-100 milisegundos a 12.000 queries por segundo.
Por qué esto es relevante
La separación OLTP/OLAP sobrevivió a todos los ciclos tecnológicos, de Oracle y Teradata a Snowflake y Redshift. Los nombres cambiaron cada década; la arquitectura se mantuvo. Hoy los competidores responden por integración: Snowflake avanza con su propia estrategia Postgres y Microsoft construye Azure HorizonDB. Databricks apuesta a eliminar la separación; los competidores, a integrarla mejor.
Ya hubo un ensayo de esta historia. Cuando Databricks acuñó el término «lakehouse» en 2020, la idea fue tratada como un antipatrón, y hoy buena parte de los grandes proveedores de nube usa el término. El escepticismo con LTAP repite el patrón. Aun así, el contrapunto honesto sostiene la vara: nadie unió OLTP y OLAP en cuatro décadas, y la tesis todavía debe probarse a escala, en workloads críticos y bajo exigencias regulatorias, ya que el propio LTAP sigue en fase de lanzamiento.
El impacto para CIOs y CTOs
Para CIOs y CTOs, LTAP es una señal de mercado: la arquitectura de datos entra en una nueva fase. Durante años, la prioridad fue consolidar datos para análisis y, después, escalar plataformas de analítica y machine learning. Ahora la presión es construir una fundación capaz de sostener agentes, aplicaciones inteligentes y decisiones automatizadas con confianza.
Esto cambia la agenda ejecutiva. La conversación amplía su alcance: de la modernización del data stack a la capacidad de la organización de decidir y actuar con confianza en entornos complejos. Por eso, algunas preguntas se vuelven centrales:
- ¿Cuántas copias existen de los datos críticos del negocio?
- ¿Cuál es la latencia entre un evento operacional y su visibilidad analítica?
- ¿Quién gobierna el dato cuando sale del sistema transaccional y llega a la capa de IA?
- ¿El lineage permite rastrear una decisión desde el evento original hasta la acción tomada?
- ¿Los agentes pueden leer y escribir datos con control, contexto y auditoría?
- ¿La arquitectura actual reduce o aumenta la superficie de falla?
- ¿La empresa tiene una fundación de datos o una colección de integraciones frágiles?
Estas preguntas pesan más que la elección de una herramienta aislada, ya que el riesgo vive en la desconexión entre la base de datos, el pipeline y el modelo, un efecto que ninguno de ellos resuelve por sí solo..
LTAP cambia dónde se resuelve la complejidad
LTAP no resuelve por sí solo la complejidad de las organizaciones. Las grandes empresas siguen con sistemas legacy, dominios distribuidos, exigencias regulatorias, restricciones de residencia de datos, contratos históricos, aplicaciones críticas y múltiples plataformas.
La cuestión es otra. LTAP obliga a una discusión de arquitectura: ¿qué datos, decisiones y aplicaciones deben seguir distribuidos en capas separadas, y cuáles deben converger hacia una fundación gobernada común?
Esa decisión exige criterio. No todo workload transaccional pertenece al lakehouse, ni todo caso analítico exige tiempo real. El permiso de un agente para escribir de vuelta en sistemas operacionales requiere el mismo criterio, evaluado por dominio, criticidad, latencia, gobernanza, costo, dependencia operacional e impacto en el negocio. Así, la adopción madura comienza por el diagnóstico de la fundación.
La lectura estratégica para empresas de operación crítica
Para empresas de alta complejidad, LTAP ilumina una deuda que suele quedar invisible: la fragmentación entre los sistemas que sostienen la operación y los sistemas que sostienen la decisión.
Aparece en síntomas conocidos:
- múltiples versiones de la verdad;
- dashboards que no coinciden con los sistemas operacionales;
- pipelines críticos sin ownership claro;
- decisiones ejecutivas basadas en datos desactualizados;
- baja trazabilidad entre evento, análisis y acción;
- dificultad para escalar IA a producción;
- gobernanza inconsistente entre datos, modelos y aplicaciones;
- dependencia de integraciones manuales o reverse ETL;
- aumento de la superficie de falla.
En la IA agéntica, estos síntomas se agravan, ya que cuanto mayor es la autonomía de los sistemas, mayor debe ser la claridad de la fundación. Los agentes amplifican las consecuencias de una arquitectura fragmentada.
Qué significa esto para la estrategia de datos e IA
Antes de acelerar la adopción de agentes, evalúe si la fundación de datos está lista para sostener decisiones automatizadas. La pregunta va más allá de tener modelos, pipelines o una plataforma moderna: es si la arquitectura permite que datos operacionales, datos analíticos, contexto de negocio, gobernanza y ejecución convivan con confianza. Esto exige una visión integrada de la fundación:
- Origen y ownership de los datos críticos. ¿Qué datos sostienen decisiones relevantes? ¿Dónde nacen? ¿Quién responde por calidad, actualización y significado?
- Latencia decisoria. ¿Cuánto tiempo pasa entre un evento operacional y su disponibilidad para análisis, automatización o acción?
- Gobernanza de punta a punta. ¿Las políticas de acceso, auditoría, lineage y retención acompañan al dato a lo largo de todo su recorrido?
- Capacidad de escritura segura. ¿Las aplicaciones y los agentes registran decisiones o activan sistemas con control, sin crear riesgo operacional?
- Observabilidad de la decisión. ¿La organización rastrea no solo sistemas y pipelines, sino decisiones, impactos y responsables?
- Costo estructural de la fragmentación. ¿Cuánto de la operación de datos existe solo para compensar la separación entre sistemas transaccionales y analíticos?
Estas dimensiones separan la modernización real del simple cambio de herramienta.
El rol de TreeID
En TreeID, leemos LTAP como señal de un cambio mayor: datos, integración, IA, gobernanza y operación forman una fundación única, no disciplinas aisladas gestionadas en paralelo.
Cuando el dato operacional no dialoga con el analítico, la gobernanza no acompaña la ejecución, la IA opera sin contexto suficiente y la arquitectura depende de integraciones frágiles, el cuello de botella pasa a ser la decisión. TreeID actúa en la raíz: ayuda a organizaciones complejas a entender su fundación de datos, identificar riesgos estructurales, decidir caminos de arquitectura y construir la capacidad correcta con el equipo que asume la corresponsabilidad de la entrega.
En síntesis, LTAP funciona mejor como invitación a una pregunta más importante: ¿su arquitectura acerca o aleja el evento de la decisión? El siguiente paso es evaluar la fundación de datos antes de escalar agentes en producción. Hable con TreeID sobre el Foundation Review para datos e IA. Somos partners de Databricks.
Fuentes
- Databricks Launches LTAP: The First Lake Transactional/Analytical Processing Architecture — comunicado de prensa, 16/jun/2026
- From monolith to Lakebase to LTAP: rethinking the database from storage up — Reynold Xin, 30/jun/2026
- A New Era of Databases: Lakebase — Ali Ghodsi et al., 12/jun/2025 (actualizado 24/feb/2026)
- Introducing Lakehouse//RT — 16/jun/2026
- Lakebase (página de producto)
- Unity Catalog · OpenSharing · Lakewatch · CustomerLake
- Databricks Launches Genie One — 16/jun/2026
- Contextual Policies in Omnigent — 7/jul/2026