207 BIM data-driven. El modelo como subproducto

207 BIM data-driven. El modelo como subproducto

La propuesta central del paper presentado por Evelio en EUBIM 2026 parte de una inversión completa del flujo de trabajo habitual. En lugar de construir primero la geometría y utilizar después esa geometría como soporte para almacenar información, el proceso se reorganiza alrededor de una base de datos que actúa como núcleo del proyecto. La información se estructura, se relaciona y se gobierna de forma independiente, mientras que la geometría pasa a convertirse en una representación que puede generarse cuando sea necesaria.

Dicho así puede parecer un simple cambio técnico, pero en realidad supone un cambio de enfoque mucho más profundo. Significa dejar de pensar en el modelo como el lugar donde reside la verdad del proyecto para empezar a entenderlo como una vista particular de una realidad mucho más amplia. Una realidad donde conviven datos geométricos, relaciones funcionales, información de operación, cálculos, presupuestos y cualquier otro elemento necesario para describir el activo.

Es una idea especialmente provocadora porque ataca directamente uno de los reflejos más arraigados del sector: cuando aparece un nuevo dato, tendemos automáticamente a preguntarnos cómo incorporarlo al modelo. La propuesta de Evelio consiste precisamente en plantear la pregunta contraria. Antes de decidir dónde representar la información, conviene preguntarse dónde debería vivir realmente esa información y cuál es la mejor herramienta para gestionarla.

El problema de confundir modelo y archivo

Un aspecto especialmente interesante aparece cuando se aborda una confusión que llevamos años arrastrando de forma casi inconsciente. En BIM hablamos constantemente de modelos, pero muchas veces cuando decimos modelo en realidad estamos pensando en archivos. El archivo de Revit. El archivo de Archicad. El archivo IFC. El archivo que alguien tiene abierto en pantalla.

Puede parecer una diferencia puramente terminológica, pero las consecuencias prácticas son importantes. Cuando identificamos el modelo con un archivo concreto terminamos aceptando también las limitaciones de ese archivo como si fueran limitaciones inherentes al proyecto. Lo que no cabe en la herramienta parece que no existe. Lo que la herramienta no gestiona bien se convierte automáticamente en un problema del flujo de trabajo.

Sin embargo, si entendemos el modelo como una representación de una realidad compuesta por múltiples fuentes de información, la conversación cambia por completo. La geometría sigue siendo importante, por supuesto, pero deja de ocupar una posición privilegiada frente al resto de datos. El presupuesto, la planificación, los cálculos eléctricos o las relaciones funcionales entre sistemas pasan a formar parte del mismo modelo conceptual, aunque no necesariamente residan en el mismo contenedor.

Lo que una planta solar puede enseñarnos sobre BIM

El caso de estudio utilizado en el paper resulta especialmente interesante porque pone de manifiesto limitaciones que normalmente pasan desapercibidas en otros tipos de proyectos. Una planta fotovoltaica puede contener miles de elementos repetitivos cuya complejidad individual es mínima, pero cuya gestión conjunta termina convirtiéndose en un desafío importante para cualquier herramienta basada exclusivamente en geometría.

Cuando intentamos representar toda esa realidad mediante modelos cada vez más detallados, aparece una paradoja curiosa. Cuanto más precisa es la representación geométrica, más difícil resulta gestionar la información que realmente importa. Los modelos crecen, las operaciones se vuelven lentas y gran parte del esfuerzo termina dedicándose a mantener una estructura que no aporta valor directo al proyecto.

La solución propuesta consiste en desplazar el foco. En lugar de utilizar el modelo para responder preguntas sobre la información, se utiliza una base de datos espacial capaz de gestionar relaciones, localizaciones y atributos de forma mucho más eficiente. La geometría sigue existiendo, pero aparece únicamente cuando alguien necesita visualizarla o utilizarla dentro de un proceso concreto.

La discusión real

Aunque buena parte del episodio gira alrededor de PostgreSQL, APIs, bases de datos espaciales o arquitecturas distribuidas, en realidad ninguno de esos elementos constituye el núcleo del debate. Son simplemente las herramientas que permiten materializar una idea más profunda.

La verdadera discusión es sobre gobernanza de información. Sobre quién controla los datos. Sobre dónde reside la fuente de verdad del proyecto. Y sobre hasta qué punto tiene sentido seguir depositando esa responsabilidad en herramientas que fueron concebidas principalmente para producir geometría.

El contenido conecta constantemente con conceptos presentes en ISO 19650 como la fuente única de verdad, los contenedores de información o los entornos comunes de datos. No porque la propuesta pretenda sustituir esos principios, sino porque intenta llevarlos a un terreno donde la información puede independizarse de las plataformas concretas que utilizamos para representarla.

Al final, la cuestión no es si el modelo geométrico desaparece. No desaparece. La cuestión es si estamos dispuestos a aceptar que quizá nunca debió ocupar el lugar central que le hemos otorgado durante todos estos años.

Quizá el verdadero activo nunca fue el modelo

Una de las conclusiones que deja la conversación es que el enfoque Data-Driven no pretende reemplazar BIM ni demostrar que los modelos geométricos son innecesarios. Lo que plantea es que tal vez hemos estado confundiendo durante demasiado tiempo el medio con el fin.

Porque cuando observamos cómo evolucionan las plataformas tecnológicas modernas, cómo escalan los grandes sistemas de información o cómo se gestionan infraestructuras digitales complejas, resulta evidente que la información se independiza cada vez más de las interfaces que utilizamos para consumirla.

Quizá el sector AECO termine recorriendo el mismo camino.

Quizá dentro de unos años sigamos utilizando modelos geométricos, visores tridimensionales y herramientas de autoría muy similares a las actuales. Pero puede que para entonces hayamos aceptado algo que hoy todavía genera cierta incomodidad: que el verdadero activo no era el modelo.

El verdadero activo siempre fueron los datos.