Por qué la mayoría de las aplicaciones de IA generativa caducan poco después de que termine el proyecto que las creó
Un Data Project es una iniciativa acotada en el tiempo que entrega un conjunto de datos o un pipeline para un caso de uso concreto y se considera terminada cuando se entrega. Un Data Product es un activo de datos con un owner de dominio permanente, un contrato de calidad y frescura explícito, y una interfaz de consumo estable y descubrible.
Los modelos LLM corporativos; especialmente los sistemas RAG y los agentes de IA, necesitan Data Products, no Data Projects, porque dependen de que los datos fuente se mantengan frescos, correctos y accesibles de forma continua, mucho después de que el equipo que construyó el piloto haya pasado a otra cosa.
Este cambio de paradigma es el mismo que propone el enfoque de Data Mesh: tratar los datos como un producto con consumidores reales, no como el subproducto de un proyecto que ya se dio por cerrado.
Un piloto de IA generativa no deja de funcionar porque el modelo empeore. Deja de funcionar porque los datos que lo alimentan siguen envejeciendo después de que el proyecto se cerrara.
Es habitual que el primer piloto de IA generativa de una empresa funcione bien. Alguien seleccionó a mano los documentos correctos, los limpió, y construyó un índice que respondía razonablemente bien a las preguntas de la demo. El problema aparece seis meses después: los documentos fuente han cambiado tres veces, nadie ha vuelto a regenerar el índice, y las respuestas del sistema empiezan a estar sutilmente desactualizadas, sin que nadie lo note hasta que un cliente o un empleado se da cuenta primero.
El piloto no falló por el modelo. Falló porque nadie era, formalmente, el dueño de mantener los datos actualizados una vez terminado el proyecto.
Antes de la IA generativa, este mismo patrón de tener datos preparados para un proyecto puntual que se degradan con el tiempo ya existía, pero sus consecuencias eran menos visibles: un dashboard desactualizado se nota cuando alguien lo mira; una base de conocimiento desactualizada dentro de un sistema RAG genera respuestas incorrectas con la misma confianza que las correctas, algo que ya tratamos en detalle al hablar de los errores más comunes al implementar IA generativa en empresas. La IA generativa no crea este problema: lo convierte en visible, costoso y, en sectores regulados, potencialmente grave.
Un Data Project es una iniciativa con fecha de inicio y fin, orientada a entregar un resultado concreto: un pipeline, un dataset limpio, un primer índice para un piloto de RAG. Sus características típicas:
Nada de esto es un error de ejecución: es simplemente lo que un proyecto es, por diseño. El problema aparece cuando se espera que el resultado de un proyecto se comporte como una infraestructura permanente sin haberlo diseñado como tal.
Un Data Product es un activo de datos gestionado con la misma disciplina que un producto de software: tiene un equipo dueño, unos consumidores a los que trata como clientes internos, y un compromiso explícito sobre su calidad y disponibilidad. Sus características definitorias:
Un sistema RAG es tan bueno como el índice sobre el que recupera información. Si ese índice se construyó una vez, para un piloto, y nadie tiene la responsabilidad formal de regenerarlo cuando cambian los documentos fuente, la calidad de las respuestas se degrada de forma silenciosa: el sistema sigue respondiendo con la misma confianza, pero cada vez con información más desactualizada.
Cuando una organización empieza a construir varios agentes o aplicaciones de IA generativa, es habitual que varios de ellos necesiten la misma base de conocimiento, así como políticas internas, catálogo de producto, o documentación de soporte. Si esa base se trató como el resultado de un proyecto aislado, cada nuevo consumidor añade una dependencia frágil sobre algo que nadie mantiene activamente; si se trató como un Data Product, cada nuevo consumidor simplemente se conecta a una interfaz estable y ya gobernada.
El equipo que construye agentes o aplicaciones de IA generativa rara vez es el dueño natural de los datos de origen, que suelen ser RRHH, ventas, soporte, o legal. Cuando el mantenimiento de esos datos no está asignado a un owner de dominio, termina cayendo, de forma no planificada, sobre el equipo de IA, que ni tiene el contexto de negocio ni debería estar dedicando su tiempo a tareas de calidad de datos en lugar de a construir capacidades.
¿Tus agentes o aplicaciones de IA generativa dependen de datos que nadie tiene formalmente la responsabilidad de mantener?
En Galde ayudamos a convertir fuentes de datos críticas en Data Products con ownership, contrato de calidad y una interfaz de consumo estable, pensados para sostener casos de uso de IA generativa a largo plazo.
Desde gobernanza de datos, ayudamos a definir ownership, contratos de calidad y catálogo para que las fuentes de datos críticas dejen de depender de la memoria de una persona concreta.
Desde la IA generativa, diseñamos los sistemas RAG y los agentes para que consuman esos Data Products a través de interfaces estables, en lugar de acoplarse directamente a los sistemas de origen.
Y desde data platforms, construimos la infraestructura, constituida de pipelines, versionado y monitorización de consumo, que hace posible mantener esos Data Products vivos sin que el mantenimiento recaiga informalmente sobre un único equipo.
La diferencia entre una organización que escala su IA generativa y otra que colecciona pilotos que dejaron de funcionar rara vez está en el modelo. Está en si los datos que alimentan esos sistemas se gestionan como un Data Product (con owner, contrato y una interfaz estable) o como el resultado ya cerrado de un Data Project que nadie tiene el mandato de seguir manteniendo. Adoptar el paradigma de producto no es un ejercicio teórico de nomenclatura: es lo que determina si un sistema LLM corporativo sigue siendo fiable dentro de un año.
Un Data Project tiene fecha de entrega y se da por terminado al completarse. Un Data Product tiene un owner permanente, un contrato de calidad y frescura explícito, y se mantiene y evoluciona de forma continua, igual que un producto de software.
No. Se puede empezar a tratar como productos las dos o tres fuentes de datos más críticas para IA generativa, asignando owner, contrato y catálogo, sin necesidad de rediseñar toda la organización de datos según los cuatro principios de Data Mesh desde el primer día.
Porque el índice sobre el que recuperan información se degrada silenciosamente cuando los documentos fuente cambian y nadie tiene la responsabilidad formal de regenerarlo o actualizarlo. El sistema sigue respondiendo con la misma confianza, pero con información cada vez más desactualizada.
Idealmente, alguien del dominio de negocio que genera o gestiona ese dato de forma natural, como puede ser RRHH para políticas internas, o soporte para documentación de producto. No el equipo de IA o de datos, que son consumidores del producto, no su fuente de conocimiento de negocio.
Una pregunta simple lo revela: si la fuente de datos cambia mañana, ¿hay alguien con la responsabilidad explícita de actualizarla y avisar a quien la consume? Si la respuesta es no, o depende de que alguien se acuerde, sigue siendo un Data Project.
