Del LOD al LOIN — la normativa BIM está cambiando de lenguaje

 El nivel de detalle adecuado no es un número. Es una pregunta.

Un pliego de condiciones te pide un modelado con LOD 300. Sabes hacerlo, lo has hecho decenas de veces. El problema es que, al otro lado de la mesa — el colaborador calculista, el BIM manager del cliente, el compañero que debe extraer los Schedule — ese mismo LOD 300 se lo imagina de forma ligeramente distinta a la tuya.

No es un problema de competencia. Ninguno de los dos se equivoca, técnicamente. La cuestión es que "LOD 300" por sí solo no dice qué debe contener el modelo — solo dice un número en una escala que, dependiendo de quién la lea, se interpreta con diferentes márgenes. Y en un proyecto BIM, un margen de interpretación sobre un dato compartido es el punto exacto donde empiezan las repeticiones de trabajo.

Es el mismo problema que afrontamos a nivel de cada familia —te hablé de ello al tratar sobre geometría, parámetros e información como tres niveles distintos de calidad de una Familia de Revit. Pues bien: lo que vale para una familia vale, a mayor escala, para un modelo completo. Y la normativa se dio cuenta antes que nosotros — tanto es así que el concepto mismo de LOD se está reescribiendo desde dentro.

LOD, LOG y LOI: la lectura italiana

Empecemos por la base, porque es sobre la que todavía se construye hoy la mayor parte de la contratación BIM en Italia: la norma UNI 11337-4.

Antes de continuar, una aclaración terminológica: cuando la normativa habla de LOD, LOG y LOI, habla de "objetos digitales" — un lenguaje deliberadamente neutro que no conoce Revit, Archicad o Tekla. "Familia" es el nombre que le damos nosotros a ese objeto cuando trabajamos dentro de Revit. Misma sustancia, vocabulario diferente.

La norma italiana define el LOD como el "nivel de desarrollo de los objetos digitales" — no es casualidad que el acrónimo, en su versión local, no traduzca literalmente el inglés Level of Development. Es una escala que va de A a G y que describe cuánto se ha profundizado y estabilizado un objeto a medida que el proyecto avanza: desde un concepto aún indicativo hasta un modelo listo para obra, actualizado como "as-built".

Hasta aquí, nada diferente de lo que probablemente ya conozcas por experiencia directa en pliegos de condiciones. La parte interesante — la que a menudo queda en segundo plano — es que la UNI 11337-4 no se detiene en una única letra. Descompone el LOD en dos componentes distintos:

• LOG — Level of Geometry: cuán definida está, dimensional y formalmente, la geometría del objeto. Es la pregunta: "¿qué forma tiene y cuán precisa es esa forma?"
• LOI — Level of Information: cuántos y cuáles datos alfanuméricos lleva consigo el objeto. Es la pregunta: "¿qué sé de este objeto, además de cómo está hecho?"

¿Te suena familiar? Debería: es exactamente la misma distinción entre geometría e información de la que te hablé al tratar las Familias de Revit como activos BIM, solo que allí la aplicábamos a una única familia en el Editor de Familias, y aquí la norma la aplica al nivel de todo el modelo, con una escala estandarizada y contractualmente vinculante.

Y es aquí donde nace el primer problema práctico: LOG y LOI no siempre crecen a la misma velocidad. Un objeto puede tener una geometría detalladísima y cero parámetros útiles para el Schedule. O viceversa: geometría simplificada, pero un LOI riquísimo porque es lo que realmente se necesita en esa fase. La letra única del "LOD 300" esconde esta asimetría. Y es precisamente esa la grieta desde la cual, a nivel europeo, ha nacido algo distinto.

No es un detalle menor: un LOG que crece sin control —geometría importada directamente de un software externo, detalles escultóricos que nadie verá nunca en planta — es exactamente el tipo de decisión que destruye el rendimiento de un modelo. Más detalle nunca es un objetivo en sí mismo: solo lo es si responde a una necesidad informativa real.

Por qué se empieza a hablar de LOIN

El límite del sistema LOD/LOG/LOI, en el fondo, es el mismo que el de cualquier escala de letras: comprime información compleja en un símbolo simple. Es cómodo para el pliego, pero menos cómodo cuando la realidad del proyecto no encaja ordenadamente en siete casillas.

A nivel europeo, este límite se ha afrontado directamente. Desde 2016, una mesa de trabajo internacional —dirigida, entre otros, por una experta italiana— ha desarrollado un marco nuevo: el LOIN, Level of Information Need. El texto se formalizó primero en la norma europea EN 17412-1 (adoptada en Italia como UNI EN 17412-1:2021) y posteriormente se elevó a estándar internacional: hoy la referencia oficial es la UNI EN ISO 7817-1:2024.

La idea central sigue siendo un cambio de perspectiva claro: ya no es "¿cuánto detalle tiene este objeto según una escala estándar?", sino "¿cuánto detalle hace falta realmente, para quién, para hacer qué y en qué fase?". No es casualidad que a nivel europeo se decidiera no condensar el concepto en un acrónimo llamativo; el riesgo, declarado abiertamente por quienes redactaron la norma, era que todos simplemente sustituyeran "LOD" por "LOIN" sin cambiar realmente de enfoque.

El marco LOIN trabaja junto a la serie UNI EN ISO 19650, la que regula en Italia la gestión informativa de los proyectos BIM (Plan de Ejecución BIM, requisitos del cliente, etc.). La 19650 dice que hace falta una necesidad informativa; la 17412-1 dice cómo especificarla de forma coherente: propósito de la información, actores involucrados, hitos de entrega, y requisitos geométricos y alfanuméricos.

Y aquí llega la parte más honesta de contar: en Italia estamos en una fase de transición, no de sustitución. La UNI EN ISO 7817-1:2024 ya es norma italiana a todos los efectos. Pero la UNI 11337-4 — la que vimos en el bloque anterior, con LOD/LOG/LOI — todavía está trabajando para alinearse con este nuevo marco. El resultado práctico es que hoy, en la contratación real, los dos lenguajes conviven: pliegos que aún piden "LOD 300" junto a clientes más avanzados — a menudo aquellos acostumbrados a trabajar con la ISO 19650 — que comienzan a especificar requisitos informativos en términos de LOIN.

No es un defecto de la normativa. Es simplemente el tiempo que le toma a todo un sector cambiar su vocabulario sin romper todo lo que ya está en funcionamiento.

Un ejemplo concreto: el mueble de cocina (Kitchen Utensil Cabinet)

Tomemos el mismo mueble portautensilios de cocina del que ya te hablé en el artículo sobre activos BIM, e intentemos leerlo bajo la óptica de LOG y LOI en lugar de la genérica de "geometría, parámetros, información".

En una fase conceptual (LOD bajo), ese mueble podría existir en el modelo como un simple paralelepípedo con el volumen correcto; el LOG es mínimo, solo el espacio que ocupará en planta. El LOI, en esta fase, podría no ser cero: basta un parámetro de clasificación o de destino de uso para empezar a hacerlo dialogar con el Schedule de costes preliminares. Geometría baja, información ya presente. Este es exactamente el tipo de asimetría que la escala LOD única tiende a ocultar.

Avanzando en el proyecto, el LOG crece: aparecen las dos configuraciones — cuatro contenedores o dos, gestionadas por el parámetro de visibilidad — la estructura de madera toma forma real, los contenedores de mimbre se convierten en geometría verdadera y no en un bloque genérico. En paralelo, aunque no necesariamente al mismo ritmo, crece también el LOI: materiales de la encimera y del armazón como parámetros de ejemplar, dimensiones editables — espesor de la encimera, espesor del armazón, deslizamiento de los contenedores — todos datos que alimentan los Schedule y permiten que el mueble responda a una coordinación real con otros profesionales.

Aquí el razonamiento desde la perspectiva LOIN se vuelve concreto. ¿Quién usará ese modelo y para qué? Si el modelo sirve para un render de presentación, hace falta LOG alto y LOI bajo: la forma debe ser convincente, los datos importan poco. Si el modelo sirve para una medición (computo métrico) o para una gestión futura de mantenimiento, ocurre lo contrario: hace falta LOI alto, con datos sobre materiales y componentes, mientras que el LOG puede permanecer más simplificado sin dañar el uso final. Preguntarse "¿qué LOD necesita este mueble?" es una pregunta incompleta. Preguntarse "¿quién usará este dato y para qué propósito?" es la pregunta que el marco LOIN intenta poner en el centro; no un detalle más alto por definición, sino el detalle adecuado para el propósito.

El nivel de detalle adecuado no es un número. Es una pregunta.

Cuando empecé a observar el mueble de cocina con las lentes de LOG y LOI, me di cuenta de una cosa: la pregunta que me había hecho durante años — "¿qué LOD necesita esta familia?" — nunca había sido la pregunta correcta. Era solo la más cómoda. Una letra para poner en un pliego, fácil de escribir, fácil de comprobar, difícil de interpretar de la misma manera por ambas partes de la mesa.

El LOIN no añade complejidad a la normativa BIM. La elimina, desplazándola donde debe estar: ya no es "¿cuánta cantidad de detalle, genéricamente?", sino "¿qué detalle, para quién, para hacer qué y en qué fase?". Es un cambio de perspectiva que se parece al que cada modelador hace ya instintivamente cada vez que decide si un parámetro debe ser de ejemplar o de tipo: no se trata de añadir control por principio, se trata de dar el justo, donde hace falta.

Vale para una sola familia en el Editor de Familias. Vale para un modelo entero en un pliego de condiciones. La pregunta no cambia, solo cambia la escala a la que te la planteas.

Hay que decir una cosa con honestidad, y es bueno cerrar con esto: la normativa italiana en este frente sigue en movimiento. La UNI 11337-4 aún no ha incorporado definitivamente el marco LOIN, y hasta que ese trabajo no concluya (en el momento de escribir este artículo, octubre de 2026, aún no se ha publicado la revisión definitiva), LOD y LOIN seguirán conviviendo en los pliegos que leemos cada día. No es un límite que deba ignorarse; es simplemente el estado de las cosas, y es probable que volvamos sobre esto en un próximo artículo cuando la norma haya adoptado su forma definitiva.

Si te interesa remontarte aún más atrás, a quien primero imaginó un objeto de construcción como contenedor de información y no solo de forma, el punto de partida es El Profeta del BIM — Charles M. Eastman. Buena lectura.