Qué compró IBM cuando compró Confluent

El 17 de marzo de 2026 IBM cerró la compra de Confluent por 31 dólares la acción, unos once mil millones de dólares. Confluent dejó de cotizar en Nasdaq y pasó a ser una subsidiaria de IBM.

La pregunta que nos hacen desde entonces, en reuniones y en el desayuno ejecutivo que dimos hace poco, es casi siempre la misma: si Kafka es open source y gratis, ¿qué compró IBM exactamente?

La respuesta corta es que Kafka es una de siete piezas. La respuesta larga es este artículo.

Confluent no es Kafka con soporte

Es la confusión más común y la más cara, porque lleva a comparar una licencia contra cero y a concluir lo obvio.

Kafka resuelve un problema: guardar eventos en un log distribuido, ordenado y persistente, del que muchos consumidores pueden leer a su ritmo y releer el pasado cuando lo necesiten. Es la pieza central y es excelente en lo suyo.

Pero un backbone de eventos en producción necesita seis cosas más, y esas son las que un equipo termina construyendo a mano cuando no las compra.

Las siete piezas

Apache Kafka es el log de eventos. Ordenado, persistente, particionado para escalar en horizontal, con retención que permite releer el historial. Es la fuente única de la verdad de lo que está pasando ahora.

Connectors resuelve la conexión con el mundo real. Conectar el core, decenas de bases de datos y el SaaS de turno al backbone suele significar código a medida, frágil y caro de mantener. Aquí son más de ciento veinte conectores listos, con captura de cambios nativa para leer del core sin tocarlo. Es configuración, no desarrollo.

Apache Flink procesa en vivo. Los eventos crudos rara vez sirven solos: hay que unirlos, enriquecerlos y calcular sobre ellos en el momento, no en una consulta batch posterior. Flink SQL hace esa lógica declarativa y versionable, con resultados en milisegundos.

Stream Governance es la pieza que la mayoría subestima y la que decide si el proyecto pasa a producción en una entidad regulada. Sin control, un backbone de eventos se convierte en un caos de formatos donde nadie confía en el dato. Aquí hay un registro de esquemas con contratos versionados, reglas de calidad, linaje de punta a punta, cifrado y control de acceso.

Tableflow convierte los streams en tablas Iceberg o Delta de forma automática. Analítica e IA necesitan los mismos datos que la operación, y duplicarlos con un ETL nocturno es caro, lento y desincroniza las dos vistas. Un solo dato sirve a las dos.

Cluster Linking replica topics entre clusters en vivo. Un solo cluster es un punto único de falla, y los escenarios híbridos o multi-región necesitan los mismos datos disponibles en varios sitios a la vez. Habilita activo-activo, recuperación ante desastres y el puente entre on-premise y nube sin un ETL de por medio.

Confluent Intelligence es la pieza más nueva y la que explica el interés de IBM. Un agente alucina cuando le falta contexto fresco y confiable del negocio, y no puede actuar sobre lo que está pasando ahora. Esta capa le da contexto en vivo al agente y permite que ejecute dentro del propio flujo de eventos, sobre datos gobernados y trazables.

Cómo madura una plataforma así

Nadie llega al último nivel de entrada, y el error más común es intentarlo.

1. Integración. Se reemplazan las conexiones punto a punto por eventos. El objetivo es dejar de tener N sistemas hablando con N sistemas.
2. Backbone de eventos. El log deja de ser de un proyecto y pasa a ser de la empresa.
3. Stream processing. Se enriquece, se une y se calcula en vivo sobre ese backbone.
4. Contexto para IA. Los agentes consumen datos gobernados y en tiempo real, y actúan sobre ellos.

Cada nivel habilita más casos de uso y más volumen sobre la misma infraestructura. Microservicios desacoplados, fraude en vivo, cliente 360, modernización del core con captura de cambios, riesgo y exposición al instante, personalización en el momento en que el cliente actúa. Todos corren en paralelo sobre el mismo backbone, sin duplicar plataforma.

Qué gana la plataforma con IBM

El comunicado de IBM es claro en su intención: Confluent transmite eventos operativos en vivo directamente a watsonx.data, para que cada modelo, agente y flujo de trabajo corra sobre datos empresariales continuamente actualizados. Esa es la tesis de la compra, y es coherente con la cuarta capa de arriba.

Para quien ya opera Confluent, o está evaluando entrar, esto es lo que cambia en la práctica.

La plataforma queda respaldada por IBM. Once mil millones de dólares es una apuesta grande y es una señal. Confluent deja de responder a un mercado trimestral y pasa a ser parte del portafolio de datos de una compañía con décadas de presencia empresarial, contratos globales y soporte en la región.

El camino hacia los agentes se acorta. La integración con watsonx.data es justo la pieza que antes había que construir a mano: llevar el contexto vivo del negocio hasta el modelo. Ahora viene de fábrica y con gobierno.

La base sigue siendo open source. Kafka y Flink son proyectos de la Apache Software Foundation. Eso no cambió con la adquisición ni va a cambiar. La arquitectura de eventos que diseñes es tuya y es portable, y ninguna decisión corporativa te encierra.

Los contratos vigentes siguen su curso. Los acuerdos plurianuales corren hasta su término. La renovación es el momento natural para revisar el roadmap conjunto, y ahí conviene sentarse con alguien que conozca las dos casas.

El liderazgo del producto subió de nivel. En agosto de 2026 Jay Kreps, cofundador y creador de Kafka, entregó la dirección a Shaun Clowes, hasta entonces director de producto, que hoy es gerente general de Confluent y Datos en IBM. Es una buena señal: el data streaming no quedó como una línea más del catálogo, quedó con silla propia en la estrategia de datos de IBM.

Por dónde empezar

La adquisición no cambia el análisis técnico. Las siete piezas son las mismas, el patrón de arquitectura es el mismo y los casos de uso que habilita también. Lo que cambia es que ahora hay un respaldo más grande detrás y un camino más corto hacia los agentes.

Así lo hacemos nosotros, y funciona:

1. Assessment. Elegimos un caso de alto impacto, uno solo. No un plan a tres años.
2. Diseño de arquitectura. Modelamos la solución sobre las piezas que tu caso realmente necesita, ni una más.
3. Prueba de concepto gobernada. En Confluent Cloud, en semanas, con esquemas y linaje desde el primer día.

Llevamos siete años implementando Confluent en América Latina y hoy somos partners de IBM. Es la misma arquitectura que venimos haciendo desde antes de la compra, ahora con un socio más grande detrás.

---

Fuentes: el comunicado de cierre de la operación está en el newsroom de IBM, y el anuncio original de la adquisición en el blog de Confluent.