Contexto técnico
Vi una entrevista reciente con Martin Kleppmann no por las discusiones generales sobre IA. Me interesaba otra cosa: cómo una persona del mundo de los sistemas intensivos en datos readapta sus principios para la implementación de IA, ahora que los modelos acceden a datos, flujos de trabajo y APIs internas.
Y aquí es donde se puso interesante. Kleppmann no vende magia; básicamente dice: si la IA va a cambiar algo en un sistema, no puedes simplemente darle acceso a la base de datos y esperar lo mejor.
Su línea de pensamiento es muy sensata: los modelos deben operar a través de interfaces seguras donde los cambios se puedan verificar, discutir y fusionar, casi como si fuera código. Para mí, esta es una señal fuerte: la automatización de IA adecuada en productos serios no se construirá en torno a “el agente lo hizo todo solo”, sino en torno a operaciones controladas con un claro registro de auditoría.
La segunda parte importante se refiere a los datos en sí. La arquitectura clásica ya no cubre todas las cargas de trabajo de IA, porque junto a los índices tradicionales ahora conviven embeddings, búsqueda vectorial, búsqueda semántica y RAG. Además, existen datos multimodales para los cuales los antiguos formatos de almacenamiento suelen ser inconvenientes o simplemente lentos.
Otro punto con el que me identifico: no hay que perder la comprensión del bajo nivel. Cuando hay demasiadas abstracciones y herramientas de IA, el equipo olvida rápidamente cómo funcionan realmente los motores de almacenamiento, la replicación, la consistencia y los compromisos multirregionales. Y luego se sorprenden de por qué el agente escribe un código bonito, pero el sistema se desmorona bajo carga.
Al mismo tiempo, Kleppmann no abandona los fundamentos de DDIA. La replicación sigue siendo clave, y el sharding manual ya no parece el héroe universal, especialmente en la nube y en máquinas grandes. Lo nuevo no anula los cimientos, sino que se construye sobre ellos.
Qué cambia esto para el negocio y la automatización
Destacaría tres conclusiones prácticas. Primero: si estás construyendo soluciones de IA para empresas, la capa de datos ahora debe diseñarse desde el principio para la recuperación, revisión e implementación segura de cambios, en lugar de añadirlo después.
Segundo: ganan los equipos que no confunden las demos con la producción. Pierden aquellos que dan a los agentes demasiada libertad sin límites de API, registro y control humano.
Tercero: el coste del error está aumentando. Una integración de IA incorrecta hoy en día no solo afecta a la UX, sino también a los datos, los procesos y los riesgos legales.
Justamente analizo estos puntos críticos en los proyectos de Nahornyi AI Lab: dónde se necesita RAG, dónde basta con una búsqueda normal, dónde se necesita un agente y dónde es mejor un flujo de trabajo rígido. Si tu automatización de IA ya se enfrenta al caos de datos o a permisos de acceso peligrosos, podemos sentarnos y diseñar una arquitectura que realmente ayude al negocio, en lugar de crear una nueva clase de problemas.