El CTO Global de Campo Insta a los Líderes a Priorizar la Infraestructura de Datos antes de la IA
Descubre por qué los proyectos de IA empresarial fracasan sin una infraestructura de datos sólida y cómo los líderes pueden construir sistemas gobernados y en tiempo real que respalden una adopción confiable de la IA.
Kai Waehner
CTO Global de Campo en Confluent
Reconocimiento de Patrones: La experiencia de Kai Waehner abarca el mundo, brindando una ventaja única de reconocimiento de patrones en la IA empresarial.
Enfoque en Infraestructura: El éxito de la IA empresarial depende de la convergencia de capas de arquitectura: datos, automatización de procesos y estrategias de IA.
Preparación de los Datos: Los proyectos de IA suelen triunfar o fracasar por la infraestructura de datos, no por el modelo elegido.
IA Embebida: Integrar la IA en los flujos de trabajo existentes mejora el rendimiento, la gobernanza y la auditoría.
Preocupaciones de Seguridad: El código generado por IA puede introducir vulnerabilidades; la revisión y las pruebas rigurosas son esenciales.
Kai Waehner es Director Técnico Global de Campo en Confluent, y ha asesorado a grandes empresas como BMW y Siemens. Su enfoque está en la infraestructura de datos, la estrategia de integración y la adopción de IA.
Conversamos con Kai para comprender por qué fracasan tantas iniciativas de IA empresarial. Esto es lo que nos contó.
Una ventaja de reconocimiento de patrones
Mi nombre es Kai Waehner. He pasado los últimos nueve años como Director Técnico Global de Campo en Confluent, trabajando con cientos de empresas en Norteamérica, Europa y Asia-Pacífico. He asesorado a compañías como BMW, Volkswagen, Lufthansa, Siemens, DISH Networks y Globe Telecom. Trabajo con ejecutivos en estrategia tecnológica, ejecución para salir al mercado, evaluación de proveedores, arquitectura empresarial y creación de contenidos.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
El rol de CTO de campo es diferente a dirigir una única organización de ingeniería. Trabajo en docenas de entornos de clientes al mismo tiempo, asesorando a arquitectos y líderes de alto nivel sobre infraestructura de datos, estrategia de integración y adopción de IA. Esa amplitud me da una ventaja en el reconocimiento de patrones que es difícil de obtener desde el interior de una sola empresa.
Mi experiencia abarca toda la historia de la integración de datos empresariales: ETL, ESB, iPaaS y Gestión de API, luego nueve años enfocado en transmisión de datos con Apache Kafka y Flink como la columna vertebral de arquitecturas orientadas a eventos, y cada vez más, orquestación de procesos e IA en todo el espectro, desde aprendizaje automático predictivo hasta IA generativa y agente. Informo regularmente a analistas en Gartner y Forrester y publico mis propias investigaciones, cubriendo panoramas de proveedores, patrones de arquitectura y casos prácticos en la industria. También publiqué un libro sobre transmisión de datos.
La conversación sobre la transformación de la IA que tengo con líderes tecnológicos no trata principalmente sobre los modelos. Se trata de la infraestructura subyacente. Los sistemas de IA agente que toman acciones autónomas dentro de flujos de trabajo empresariales necesitan tres cosas para funcionar de forma fiable:
- Datos en tiempo real para que actúen sobre la realidad actual
- Inteligencia de procesos para definir lo que se les permite hacer
- Confianza incorporada a la arquitectura, no sólo al modelo
Mi pensamiento se centra en esa convergencia.
Por qué las capas de arquitectura deben converger para el éxito de la IA
En distintas industrias, veo constantemente que las empresas invierten mucho en tres capas separadas: una columna vertebral de integración de datos, una capa de automatización de procesos y, cada vez más, una iniciativa de IA. El problema es que estas tres casi nunca están diseñadas para funcionar juntas. La integración de datos mueve datos pero no conecta con las decisiones de negocio. La automatización de procesos aplica flujos de trabajo pero se ejecuta con contexto obsoleto. Los agentes de IA generan recomendaciones o realizan acciones, pero carecen de un límite gobernado respecto a lo que pueden hacer. Cada capa funciona de forma aislada. Falta la arquitectura convergente.
Los modelos de implementación que observo varían significativamente. Algunas organizaciones operan infraestructuras totalmente gestionadas y nativas de la nube sobre AWS, Azure o GCP, y las grandes empresas globales suelen incluir implementaciones en China continental sobre Alibaba Cloud, mantenidas deliberadamente separadas por razones legales, regulatorias y de privacidad de datos. Otras operan arquitecturas híbridas, con centros de datos locales conectados a la nube, impulsados por requisitos de soberanía de datos o sistemas heredados que no pueden mover rápidamente. Industrias reguladas como servicios financieros y salud casi siempre tienen requisitos multi-región o multi-nube, no por elección sino por mandato normativo. Los clientes de manufactura frecuentemente tienen implementaciones en el borde donde procesan los datos cerca de la planta de producción antes de agregarlos centralmente.
En todos estos entornos, la arquitectura orientada a eventos se ha convertido en una infraestructura crítica para la misión. Apache Kafka ha surgido como el estándar de facto para lograr desacoplamiento real entre sistemas, procesamiento en tiempo real a cualquier escala, e integración híbrida y multi-nube. PayPal procesa más de un billón de mensajes Kafka cada día. New Relic ingiere miles de millones de datos por minuto. Estas no son implementaciones experimentales; son la columna vertebral operativa del negocio.
Muchas empresas ya cuentan con las tres piezas necesarias para una IA agente y confiable. Lo que falta es el compromiso arquitectónico para hacerlas converger.
Por qué la preparación de los datos precede a la de la IA
Esto es lo que he comprobado: la IA no es la parte difícil. La infraestructura de datos subyacente sí lo es.
En la mayoría de las iniciativas empresariales de IA que he visto triunfar o fracasar en los últimos nueve años, importaba menos el modelo elegido y más si la organización contaba con una base fiable, gobernada y en tiempo real que alimentara ese modelo con datos actuales, precisos y confiables.
Un modelo bien alineado que recibe datos obsoletos o inconsistentes producirá resultados poco fiables. Un sistema de IA agente sin una capa de procesos que defina qué puede hacer acabará tomando acciones que nadie podrá explicar ni revertir. Estos no son problemas del modelo. Son problemas de infraestructura y arquitectura. Y son completamente predecibles antes de escribir una sola línea de código de IA.
La implicación práctica es que la preparación para la IA es preparación de datos. Antes de seleccionar un modelo, antes de elegir un proveedor de IA, antes de lanzar un piloto, un CTO debe ser capaz de responder honestamente a tres preguntas.
- ¿Tiene la organización acceso fiable a datos en tiempo real de sus sistemas operativos?
- ¿Existen procesos controlados que definan lo que un sistema de IA puede y no puede hacer de forma autónoma?
- ¿Existe un marco de confianza a nivel de arquitectura, no solo dentro del modelo, que pueda hacer cumplir esos límites en producción?
Si la respuesta a cualquiera de esas tres es no, el viaje hacia la IA debe empezar allí, no con el modelo.
Por qué la IA debe integrarse en los procesos empresariales existentes
El cambio más importante que he impulsado es pasar de construir la IA como una iniciativa separada a integrarla en los procesos empresariales existentes. Esto está altamente subinvertido y es trascendental. De hecho, diría que la mayoría de los CTOs deberían pasar de diseñar nuevos sistemas de IA a diseñar cómo la IA participa en los flujos de trabajo existentes, qué límites define la capa de procesos y cómo se construye la gobernanza y la auditabilidad, antes de desplegar un solo modelo.
Antes de hacer este cambio, el patrón era casi siempre el mismo. Un proyecto de IA comenzaba desconectado de los sistemas operativos. El modelo rendía bien en el laboratorio. En producción, carecía de acceso fiable a datos actuales, de un límite definido para sus acciones y de integración en los flujos de aprobación de los que dependía el negocio. Demo impresionante. Despliegue fallido.
El cambio por el que ahora abogo de forma consistente es doble.
- Primero, tratar la arquitectura existente orientada a eventos como la base para la adopción de la IA en lugar de un objetivo para reemplazar. Los sistemas permanecen. Los procesos de negocio permanecen. La IA participa en flujos de trabajo que ya están operativos, consumiendo eventos en tiempo real y actuando dentro de los límites que define la capa de procesos.
- Segundo, trasladar los límites de la IA fuera del modelo y hacia la capa de orquestación de procesos. Un modelo bien alineado no es suficiente. Una IA confiable en producción significa que la capa de flujo de trabajo aplica compuertas de aprobación, caminos de escalamiento y trazabilidad de auditoría para cada acción autónoma que realiza el agente.
Alpian, el primer banco digital privado totalmente licenciado de Suiza, es un claro ejemplo de cómo hacerlo bien desde el principio. Alpian construyó toda su plataforma orientada a eventos, utilizando Apache Kafka como sistema nervioso central que conecta microservicios, productos de datos de dominio y agentes de IA. Cuando introdujeron IA agente y RAG en los flujos de interacción con clientes, la arquitectura ya estaba preparada. Los eventos de Kafka daban a los agentes contexto en tiempo real. La capa de procesos imponía controles de cumplimiento. Implementaron cifrado a nivel de campo y gobernanza de esquemas desde el inicio.
El resultado fue una institución financiera regulada operando agentes de IA autónomos dentro de flujos de trabajo controlados y auditables, que es exactamente el patrón que ahora la mayoría de las empresas tradicionales intenta adaptar.
Las organizaciones que hacen esto bien tratan la adopción de IA como una disciplina arquitectónica, no como un sprint de proyecto.
Las organizaciones que logran esto tratan la adopción de IA como una disciplina arquitectónica, no como una carrera de proyecto… La diferencia entre buenos y malos resultados casi siempre proviene de si la infraestructura de datos estaba lista antes de la introducción de la IA.
Por qué la preparación de datos determina el éxito del despliegue de IA
Después de nueve años en Confluent y en cientos de entornos empresariales, los resultados de IA que he observado son muy desiguales. La diferencia entre buenos y malos resultados casi siempre proviene de una sola cosa: si la infraestructura de datos estaba lista antes de la introducción de la IA.
En el lado positivo, las cifras de implementaciones bien diseñadas son contundentes. BMW evita más de 500 minutos de tiempo de inactividad no planificado al año en una sola planta. Alpian opera un banco digital completamente regulado con IA agente incrustada en flujos de trabajo de clientes gobernados y auditables. El patrón cualitativo en las implementaciones exitosas es constante: menor tiempo de lanzamiento al mercado, reducción del costo operativo en flujos de trabajo repetitivos de alto volumen y una experiencia del cliente significativamente mejor cuando la IA accede a contexto en tiempo real en lugar de datos antiguos por lotes.
En el lado negativo, el patrón de fracaso es igualmente constante. Los proyectos de IA sin una base de datos gobernada casi siempre terminan igual: demostraciones impresionantes, implementaciones fallidas en producción. El modelo funciona en el laboratorio. En producción, recibe datos desactualizados o inconsistentes, fantasea en casos límite, toma acciones sin rastro de auditoría y debilita en vez de aumentar la confianza empresarial en la IA. Un estudio del MIT estima que alrededor del 95% de los pilotos de IA empresarial no logran ofrecer un impacto empresarial medible. Este dato coincide con mis observaciones en el campo.
El modo de fallo más reciente que estoy observando es la gobernanza incorporada demasiado tarde. Las organizaciones despliegan IA agente y después descubren, normalmente tras un incidente, que ninguna capa de procesos definió lo que el agente podía hacer, no había vía de escalamiento para salidas del modelo inciertas y no existía rastro de auditoría para reconstruir los eventos. Ese no es un problema de IA. Es un problema de arquitectura. Y es completamente prevenible.
Por qué la IA informa decisiones pero los humanos garantizan la responsabilidad
Observo constantemente un patrón: la IA informa y acelera. Toma decisiones autónomas dentro de límites definidos. Pero los humanos asumen la responsabilidad de las decisiones que más importan.
En el lado impulsado por IA, la síntesis de investigaciones, la creación de contenido, la generación de código para problemas bien delimitados, las pruebas automatizadas y el escaneo de seguridad agregan un valor claro. En mi propio trabajo, las herramientas de IA condensan días de síntesis de informes de analistas, conversaciones con clientes y documentación técnica. El resultado aún necesita validación experta, pero el punto de partida es mucho más avanzado.
En la toma de decisiones autónoma, los agentes de IA deben decidir de forma independiente cuando el riesgo está acotado y el proceso bien gobernado. La detección de fraude en servicios financieros es el ejemplo más claro. Por debajo de un umbral de riesgo definido, un agente de IA bloquea automáticamente una transacción sin intervención humana. A medida que aumenta el tamaño de la transacción y la exposición regulatoria, la capa de orquestación del proceso remite el caso a un analista humano antes de tomar cualquier acción. El límite no es fijo: lo define el negocio, lo codifica el flujo de trabajo y lo aplica la capa de procesos, no el modelo en sí.
En el ámbito exclusivamente humano, yo trazo la línea en decisiones con grandes implicaciones arquitectónicas, riesgos estratégicos para el negocio o responsabilidades regulatorias significativas. Elegir un patrón de arquitectura fundamental, seleccionar un proveedor tecnológico estratégico, diseñar el modelo de gobernanza para un sistema de IA agente: Estas siguen siendo decisiones humanas. Actuar más rápido no compensa las consecuencias de equivocarse.
Por qué la IA no cumple en tres áreas principales
La IA no ha logrado entregar el impacto técnico o de ingeniería que los clientes esperaban inicialmente en tres áreas.
La primera es la integración de datos empresariales. Se prometió que la IA simplificaría drásticamente la conexión de sistemas heterogéneos: mapeo de esquemas, control de calidad de datos, lógica de transformación y gobernanza en entornos híbridos complejos. En la práctica, la IA ayuda con esas tareas, pero no las resuelve. Un modelo no puede resolver de manera lógica la deuda arquitectónica subyacente, los sistemas heredados con modelos de datos no documentados, las semánticas inconsistentes entre unidades de negocio, la ausencia de metadatos y la fragmentación de la titularidad. Los ingenieros aún deben afrontar el trabajo difícil.
La segunda es la IA agente en flujos de trabajo empresariales complejos y de múltiples etapas. Las demos son convincentes. En producción, los agentes fallan de forma imprevisible cuando se encuentran con casos límite que los datos de entrenamiento no cubren, cuando la ventana de contexto carece de suficiente estado actual, o cuando la capa de procesos no detecta y maneja correctamente los errores del agente. La brecha entre lo que puede hacer un agente en un entorno controlado y lo que podemos confiarle de forma autónoma en un flujo regulado de producción sigue siendo significativa.
La tercera es la toma de decisiones arquitectónicas. Las herramientas de IA han acelerado de manera importante la codificación rutinaria, la elaboración de pruebas y la documentación. Pero no logran mejorar de manera fiable las decisiones sobre la arquitectura fundamental. Los modelos reflejan patrones del pasado. La arquitectura empresarial requiere juicio sobre restricciones futuras, trayectorias regulatorias y apuestas tecnológicas que los modelos no pueden realizar adecuadamente. Los equipos que dependen demasiado de la IA para las decisiones arquitectónicas tienden a producir sistemas que son localmente coherentes pero globalmente frágiles.
El hilo común en las tres áreas es este: la IA cumple cuando el problema está bien definido, los datos son limpios y actuales, y hay un humano con experiencia en el dominio involucrado en el proceso. No cumple allí donde el problema requiere juicio contextual, cambio organizacional o reflexión arquitectónica que va más allá de encontrar patrones en datos históricos.
Cómo la IA lucha con la seguridad y la escalabilidad en el código
La dificultad más frecuente que observo está en el límite entre el código generado por IA y el criterio de ingeniería de nivel de producción.
Las herramientas de generación de código por IA son realmente útiles para tareas bien definidas y repetitivas: boilerplate, casos de prueba, documentación y transformaciones sencillas. Los problemas aparecen cuando los equipos extienden esa confianza a decisiones arquitectónicas, código sensible a la seguridad o componentes críticos de escalabilidad sin una revisión humana rigurosa.
En el lado de la seguridad, el código generado por IA frecuentemente introduce vulnerabilidades sutiles que pasan los escaneos automáticos pero fallan en condiciones adversas. La inyección mediante prompts es el ejemplo más claro actualmente en sistemas de IA agentes. Un agente que genera o ejecuta código en función de la entrada del usuario sin una validación adecuada de la entrada y sin aislamiento crea superficies de ataque que son fáciles de pasar por alto y difíciles de detectar después. He visto este patrón en los primeros despliegues de IA agentes donde los equipos se enfocaban en la capacidad y la velocidad y trataban la revisión de seguridad como un paso posterior.
En cuanto a la escalabilidad, las herramientas de IA suelen generar soluciones que funcionan correctamente a pequeña escala pero que arrastran suposiciones ocultas sobre volumen de datos, concurrencia o latencia, que solo aparecen bajo carga de producción. Un consumidor de Kafka generado que funciona bien en pruebas puede fallar de forma impredecible a diez mil eventos por segundo si el código no contempla rebalanceo de particiones, gestión de offsets o manejo de backpressure. El modelo no conoce tu entorno de producción. Conoce patrones de los datos de entrenamiento.
La respuesta práctica no es dejar de usar IA para generar código. Es tratar el código generado por IA igual que tratarías el de un ingeniero capaz, pero junior, que nunca ha visto tu sistema de producción: revísalo. Pruébalo en condiciones realistas. Y nunca lo dejes cerca de caminos críticos de seguridad o escalabilidad a menos que un ingeniero senior lo apruebe.
Lo que los líderes tecnológicos deben hacer ahora
Aquí tienes tres consejos, en el orden en que importan:
Primero, invierte en tu base de datos antes que en tu ambición de IA. Las organizaciones que logran resultados medibles con IA no son las que más rápido adoptaron un nuevo modelo. Tenían datos limpios, en tiempo real y regulados circulando por sus sistemas antes de que empezara la conversación sobre IA. Si tus datos están aislados, desactualizados o carecen de gobernanza, soluciona eso primero. Ningún modelo compensa los malos datos a gran escala.
Segundo, trata la gobernanza de la IA como un problema de arquitectura, no solo de política. Escribir directrices sobre el uso responsable de la IA es necesario pero insuficiente. La capa de procesos es la que realmente gobierna el comportamiento de los agentes en producción: los accesos de los flujos de trabajo, los umbrales de aprobación, las rutas de escalamiento y los registros de auditoría que establecen límites independientemente de lo que recomiende el modelo. Incluye estos procesos en la arquitectura desde el principio. Implementar la gobernanza después del despliegue es costoso, poco fiable y suele hacerse solo después de que algo ha salido mal.
Tercero, piensa en ambas direcciones al mismo tiempo. La presión de abajo hacia arriba para lanzar casos de uso con IA rápidamente es real y legítima. También lo es la necesidad desde la dirección de una arquitectura estratégica que evite crear soluciones puntuales fragmentadas que pasarás años desenredando. Los CTO que veo navegar esto con éxito pueden sostener ambos enfoques a la vez: avanzar rápido en casos de uso concretos mientras mantienen una visión arquitectónica clara que hace que esos casos sean componibles y gobernables a largo plazo.
Las organizaciones que mirarán hacia atrás y verán esta época como una ventaja competitiva no serán las que adoptaron la IA primero. Construyeron la infraestructura para hacer que la IA fuera confiable y luego avanzaron rápido gracias a esa base.
Sigue el trabajo de Kai Waehner
Puedes seguir el trabajo de Kai Waehner en su sitio web, su blog y LinkedIn.
¡Próximamente más entrevistas de expertos en The CTO Club!
