El CTO Global de Campo Insta a los Líderes a Priorizar la Infraestructura de Datos Antes que la IA
Descubra por qué los proyectos de IA empresarial fracasan sin una infraestructura de datos sólida y cómo los líderes pueden crear 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 es global, brindando una ventaja única en el 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 tener éxito o fracasar según la infraestructura de datos y no por el modelo elegido.
IA Integrada: 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; es esencial realizar revisiones y pruebas rigurosas.
Kai Waehner es Director Técnico de Campo Global 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.
Hablamos con Kai para entender por qué fracasan tantas iniciativas de IA empresarial. Esto es lo que nos contó.
Una Ventaja de Reconocimiento de Patrones
Me llamo Kai Waehner. He pasado los últimos nueve años como Director Técnico de Campo Global 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 la estrategia tecnológica, la ejecución de lanzamiento al mercado, la evaluación de proveedores, la arquitectura empresarial y la creación de contenido.
¿Quieres más de The CTO Club?
Crea una cuenta gratuita para terminar de leer este contenido y unirte a una comunidad de CTOs y líderes de ingeniería que comparten marcos, herramientas y conocimientos reales para diseñar, desplegar y escalar tecnología impulsada por IA.
Have an account? Log In
El rol de Director Técnico de Campo es diferente de liderar un único equipo de ingeniería. Trabajo simultáneamente en docenas de entornos de clientes, asesorando a arquitectos y líderes de nivel C en 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 trayectoria abarca toda la historia de la integración de datos empresariales: ETL, ESB, iPaaS y Gestión de APIs, luego nueve años enfocado en transmisión de datos con Apache Kafka y Flink como columna vertebral para 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 agentica. Informo regularmente a analistas de Gartner y Forrester y publico mis propias investigaciones, abarcando panoramas de proveedores, patrones de arquitectura y estudios de casos reales de la industria. Además, publiqué un libro sobre transmisión de datos.
La conversación sobre la transformación de la IA que tengo con los líderes tecnológicos no se centra principalmente en los modelos. Se trata de la infraestructura que hay debajo de ellos. Los sistemas de IA agentica que toman acciones autónomas dentro de los flujos de trabajo empresariales necesitan tres cosas para funcionar de manera confiable:
- Datos en tiempo real para que actúen sobre la realidad actual
- Inteligencia de procesos para definir qué se les permite hacer
- Confianza incorporada en la arquitectura, no solo en el modelo
Mi enfoque está en esa convergencia.
Por Qué las Capas de Arquitectura Deben Converger para el Éxito de la IA
En los distintos sectores, veo constantemente que las empresas invierten fuertemente 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 la información pero no la conecta con las decisiones del negocio. La automatización de procesos aplica los flujos de trabajo pero opera con contexto desactualizado. Los agentes de IA generan recomendaciones o toman acciones, pero carecen de límites gobernados sobre lo que pueden hacer. Cada capa funciona en aislamiento. Falta la arquitectura convergente.
Los modelos de implementación que observo varían significativamente. Algunas organizaciones ejecutan infraestructuras totalmente gestionadas y nativas de la nube en 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, impulsadas por requisitos de soberanía de los datos o sistemas heredados que no pueden migrar rápidamente. Los sectores regulados como los servicios financieros y la salud casi siempre exigen requisitos multi-región o multi-nube, no por elección sino por mandato de cumplimiento. Los clientes de manufactura con frecuencia tienen implementaciones en el extremo (edge), 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 infraestructura crítica. Apache Kafka ha emergido como el estándar de facto para la distribución de eventos que permite el 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 de Kafka al día. New Relic ingiere miles de millones de datos por minuto. Estos no son despliegues experimentales. Son la columna vertebral operativa del negocio.
Muchas empresas ya cuentan con las tres piezas que necesitan para una IA agentica confiable. Les falta 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 encontrado: la IA no es la parte difícil. La infraestructura de datos que la sustenta, sí lo es.
La mayoría de las iniciativas de IA empresarial que he visto tener éxito o fracasar en los últimos nueve años dependieron menos del modelo elegido y más de si la organización contaba con una base confiable, gobernada y en tiempo real para alimentar 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 lo que puede hacer acabará tomando una acción que nadie puede explicar o revertir. Estos no son problemas del modelo. Son problemas de infraestructura y arquitectura. Y estos son totalmente previsibles antes de escribir una sola línea de código de IA.
La implicancia práctica es que la preparación para 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 debería poder responder sinceramente tres preguntas.
- ¿Tiene la organización acceso fiable y en tiempo real a los datos de sus sistemas operativos?
- ¿Existen procesos gobernados que definan lo que un sistema de IA puede y no puede hacer de forma autónoma?
- ¿Hay un marco de confianza implementado a nivel de arquitectura, no solo dentro del modelo, que pueda hacer cumplir esos límites en producción?
Si la respuesta a alguna de esas tres es no, el viaje hacia la IA debe comenzar ahí, no con el modelo.
Por qué la IA debe integrarse en los procesos empresariales existentes
El cambio más significativo que he impulsado es pasar de construir IA como una iniciativa separada a integrarla en los procesos de negocio ya existentes. Esto está altamente infravalorado y tiene grandes consecuencias. 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 actuales, qué límites impone la capa de procesos y cómo se incorporan 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 funcionaba bien en el laboratorio. En producción, carecía de acceso fiable a datos actualizados, de un límite definido para sus acciones y de integración en los flujos de aprobación que necesitaba el negocio. Demostración impresionante. Despliegue fallido.
El cambio que ahora impulso de forma consistente es doble.
- Primero, tratar la arquitectura existente orientada a eventos como la base para la adopción de IA en lugar de un objetivo a reemplazar. Los sistemas se quedan. Los procesos de negocio se quedan. La IA participa en flujos de trabajo ya en marcha, consumiendo eventos en tiempo real y actuando dentro de los límites definidos por 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 hace cumplir puertas de aprobación, rutas de escalado y registros de auditoría para cada acción autónoma que toma el agente.
Alpian, el primer banco digital privado suizo totalmente licenciado, es un gran ejemplo de cómo hacer esto bien desde el primer día. Alpian construyó toda su plataforma orientada a eventos, utilizando Apache Kafka como el 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 lista. Los eventos en Kafka daban a los agentes contexto en tiempo real. La capa de procesos imponía los 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 con agentes de IA autónomos dentro de flujos de trabajo gobernados y auditables, que es exactamente el patrón que la mayoría de las empresas tradicionales ahora están tratando de incorporar después.
Las organizaciones que hacen esto bien ven la adopción de la IA como una disciplina arquitectónica, no como una entrega rápida de proyecto.
Las organizaciones que hacen esto bien tratan la adopción de la IA como una disciplina arquitectónica, no como una entrega rápida de proyecto… La brecha entre buenos y malos resultados casi siempre surge 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 en el despliegue de IA
Después de nueve años en Confluent y en cientos de entornos empresariales, los resultados de IA que he visto son profundamente desiguales. La brecha entre buenos y malos resultados casi siempre proviene de una sola cosa: si la infraestructura de datos estaba lista antes de introducir la IA.
En el lado positivo, las cifras procedentes de implementaciones bien arquitecturadas son convincentes. BMW evita más de 500 minutos de paradas imprevistas en la producción al año en una sola planta. Alpian gestiona un banco digital totalmente regulado con IA agente incorporada en flujos de trabajo de clientes gobernados y auditables. El patrón cualitativo entre los despliegues exitosos es consistente: reducción del tiempo de salida al mercado, menores costes operativos en flujos de trabajo repetitivos de gran volumen y una experiencia de cliente significativamente mejor cuando la IA accede a contexto en tiempo real en vez de datos en lote obsoletos.
En el lado negativo, el patrón de fracaso es igual de consistente. Los proyectos de IA sin una base de datos gobernada casi siempre entregan el mismo resultado: demostraciones impresionantes y fallos en el despliegue en producción. El modelo funciona en el laboratorio. En producción, recibe datos obsoletos o inconsistentes, alucina ante casos límite, toma acciones sin rastro de auditoría y erosiona, en vez de construir, la confianza empresarial en la IA. Una investigación del MIT estima que cerca del 95% de las pruebas piloto de IA empresarial no logran generar un impacto empresarial medible. Este número coincide con mis observaciones en el campo.
El modo de fallo más reciente que observo es producción gobernada demasiado tarde. Las organizaciones despliegan IA agente y descubren, a menudo después de un incidente, que ninguna capa de proceso definía lo que el agente podía hacer, no había ruta de escalada para salidas inciertas del modelo y no existía rastro de auditoría para reconstruir los eventos. Eso no es un problema de IA. Es un problema de arquitectura. Y es completamente prevenible.
Por qué la IA informa las decisiones pero los humanos garantizan la responsabilidad
Observo de forma constante un patrón: la IA informa y acelera. Toma decisiones autónomas dentro de límites definidos. Pero los humanos asumen la responsabilidad por las decisiones más importantes.
En el plano informado por IA, la síntesis de investigaciones, creación de contenido, generación de código para problemas bien acotados, pruebas automatizadas y escaneo de seguridad aportan valor claro. En mi propio trabajo, las herramientas de IA comprimen días de síntesis de informes de analistas, conversaciones con clientes y documentación técnica. El resultado aún requiere validación experta, pero el punto de partida está mucho más avanzado.
En cuanto a decisiones autónomas, 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 de procesos deriva el caso a un analista humano antes de actuar. El límite no es fijo. La empresa lo define, el flujo de trabajo lo codifica y la capa de proceso lo refuerza; no es el modelo en sí.
Por el lado explícitamente humano, yo marco el límite en decisiones con grandes consecuencias arquitectónicas, riesgo estratégico de negocio o responsabilidad regulatoria significativa. 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: todas siguen siendo decisiones humanas. Avanzar más rápido no compensa las consecuencias de equivocarse en estas decisiones.
Por qué la IA queda corta en tres áreas principales
La IA no ha entregado 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. La IA prometió simplificar de forma extraordinaria 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 en estas tareas pero no las resuelve. Un modelo no puede razonar para salir de la deuda arquitectónica subyacente, sistemas heredados con modelos de datos no documentados, semánticas inconsistentes entre unidades de negocio, metadatos faltantes y titularidad fragmentada. Los ingenieros siguen teniendo que hacer el trabajo duro.
La segunda es la IA agente en flujos de trabajo empresariales complejos y de varios pasos. Las demostraciones son convincentes. En producción, los agentes fallan de manera impredecible cuando se enfrentan a casos límite que los datos de entrenamiento no cubrieron, cuando la ventana de contexto carece del estado actual suficiente o cuando la capa de proceso no detecta ni gestiona adecuadamente los errores de los agentes. La distancia entre lo que puede hacer un agente en un entorno controlado y lo que podemos confiarle de manera autónoma en un flujo de trabajo regulado es aún significativa.
La tercera es la toma de decisiones arquitectónicas. Las herramientas de IA han acelerado significativamente la codificación rutinaria, la escritura de pruebas y la documentación. Pero no mejoran de forma fiable las decisiones sobre arquitectura fundamental. Los modelos reflejan patrones del pasado. La arquitectura empresarial requiere criterio sobre restricciones futuras, trayectorias regulatorias y apuestas tecnológicas que los modelos no pueden hacer adecuadamente. Los equipos que dependen en exceso de la IA para decisiones arquitectónicas tienden a producir sistemas coherentes localmente pero frágiles a nivel global.
El hilo común en las tres áreas es el siguiente: la IA aporta cuando el problema está bien definido, los datos están limpios y actualizados, y un humano con experiencia en el dominio está involucrado. Se queda corta cuando el problema requiere juicio contextual, cambios organizativos o pensamiento arquitectónico que va más allá de reconocer patrones en datos históricos.
Cómo la IA Lucha con la Seguridad y la Escalabilidad en el Código
La dificultad más constante que observo está en la frontera 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 con IA son realmente útiles para tareas bien definidas y repetitivas: plantillas, casos de prueba, documentación y transformaciones sencillas. Los problemas surgen cuando los equipos extienden esa confianza a decisiones arquitectónicas, código sensible a la seguridad o componentes críticos para la escalabilidad, sin una revisión humana rigurosa.
En materia de seguridad, el código generado por IA con frecuencia introduce vulnerabilidades sutiles que pasan los escaneos automáticos pero fallan en condiciones adversas. La inyección mediante instrucciones es el ejemplo más claro actualmente en sistemas de IA agentica. Un agente que genera o ejecuta código basado en la entrada del usuario, sin la debida validación y aislamiento de entradas, crea superficies de ataque fáciles de pasar por alto y difíciles de detectar posteriormente. He visto este patrón en los primeros despliegues de IA agentica, donde los equipos se enfocaron en capacidad y velocidad, y dejaron la revisión de seguridad para más adelante.
En cuanto a la escalabilidad, las herramientas de IA tienden a generar soluciones que funcionan correctamente a pequeña escala, pero que llevan supuestos ocultos sobre el volumen de datos, la concurrencia o la latencia, los cuales sólo afloran bajo carga real en producción. Un consumidor de Kafka generado que funcione bien en pruebas puede fallar de manera impredecible a diez mil eventos por segundo si el código generado no contempla el reequilibrio de particiones, la gestión de offsets o el manejo de presión. El modelo no conoce tu entorno de producción. Conoce patrones extraídos de los datos de entrenamiento.
La respuesta pragmática no es dejar de usar la IA para la generación de código. Es tratar el código generado por IA como tratarías el código de un ingeniero capaz pero junior, que nunca ha visto tu sistema en producción. Revísalo. Pruébalo en condiciones realistas. Y nunca permitas que se acerque a rutas críticas de seguridad o escalabilidad a menos que un ingeniero sénior lo apruebe.
Qué Deben Hacer a Continuación los Líderes Tecnológicos
Aquí van tres recomendaciones, en el orden en el que importan:
Primero, invierte en tu base de datos antes que en tu ambición con IA. Las organizaciones que logran resultados medibles con IA no son las que adoptaron rápido un nuevo modelo. Ya tenían datos limpios, en tiempo real y gobernados circulando por sus sistemas antes incluso de empezar a hablar de IA. Si tus datos están en silos, desactualizados o sin gobernanza, arregla eso primero. Ningún modelo compensa datos deficientes a gran escala.
Segundo, trata la gobernanza de IA como un problema de arquitectura, no de políticas. Es necesario redactar directrices de uso responsable de la IA, pero no suficiente. Lo que realmente gobierna el comportamiento de los agentes en producción es la capa de procesos: los controles en el flujo de trabajo, los umbrales de aprobación, las rutas de escalado y las trazas de auditoría que hacen cumplir los límites, sin importar lo que recomiende el modelo. Incorpóralos en la arquitectura desde el comienzo. Modificar la gobernanza a posteriori es caro, poco fiable y suele darse cuando ya ocurrió algún problema.
Tercero, piensa en ambas direcciones a la vez. La presión desde abajo para lanzar rápidamente casos de uso de IA es real y legítima. Igual de legítima es la necesidad de una arquitectura estratégica que evite crear soluciones parciales y fragmentadas que después pasarás años desenredando. Los CTOs que veo navegar bien esta situación logran sostener ambos imperativos a la vez: avanzar deprisa en casos de uso concretos, manteniendo un norte arquitectónico claro que haga esos casos componibles y gobernables a lo largo del tiempo.
Las organizaciones que mirarán hacia atrás este periodo como una ventaja competitiva no serán las que adoptaron la IA antes que nadie. Serán las que construyeron la infraestructura para hacer la IA de confianza y después aceleraron sobre esa base.
Sigue la Conversación
Puedes seguir el trabajo de Kai Waehner en su sitio web, blog y en LinkedIn.
¡Pronto más entrevistas con expertos en The CTO Club!
