Inteligencia artificial en construcción: validar el cumplimiento BIM

Un modelo BIM llega a obra con una puerta clasificada como cortafuegos, pero sin el property set de resistencia al fuego cumplimentado. El validador automático de la constructora no lo detecta porque busca el atributo FireRating en Pset_DoorCommon, y el autor del modelo lo introdujo como texto libre en la descripción. El resultado: una RFI, dos semanas de retraso y una revisión manual que debería haberse resuelto en el modelo de diseño, no en obra.

Este escenario se repite en la mayoría de proyectos que usan inteligencia artificial en construcción de forma incompleta: comprobadores basados solo en reglas rígidas. Herramientas como Solibri Model Checker o los validadores nativos de Revit funcionan bien cuando el modelo sigue el estándar al pie de la letra, pero fallan sistemáticamente ante la variabilidad real de nomenclaturas, convenciones de oficina y criterios de clasificación entre subcontratistas.

La alternativa que estamos desplegando en proyectos de infraestructura y edificación combina un motor de reglas deterministas para los casos que sí tienen respuesta binaria, con un LLM (modelo de lenguaje de gran escala) para los casos ambiguos que ninguna regla fija cubre. El motor decide en milisegundos; el LLM interviene solo cuando hace falta criterio.

El problema técnico en detalle

Un modelo BIM contiene miles de entidades IFC (Industry Foundation Classes), cada una con nomenclatura, property sets (Psets) y clasificaciones normativas asociadas. Tres fuentes de variabilidad generan la mayoría de los errores de cumplimiento:

• Nomenclatura: ISO 19650 define principios, pero cada organización aplica variantes propias (abreviaturas, separadores, orden de campos). Un mismo tipo de elemento puede nombrarse de cinco formas distintas entre disciplinas.
• Property sets: IFC define Psets estándar (Pset_DoorCommon, Pset_WallCommon), pero los autores del modelo a menudo rellenan campos equivalentes en Psets personalizados, o dejan el estándar vacío y describen el atributo en texto libre.
• Clasificaciones normativas: sistemas como Uniclass 2015, OmniClass o las tablas de clasificación de EN 13501 (resistencia al fuego) se aplican con criterio distinto según el ingeniero, especialmente en elementos límite (puertas cortafuegos en compartimentaciones mixtas, por ejemplo).

El coste de no detectarlo antes de obra no es solo el de la RFI. Un elemento mal clasificado que llega a fabricación puede implicar sustitución física, con semanas de plazo y sobrecoste que ya no se resuelve con software.

Cómo funciona el método

El pipeline arranca con la extracción de entidades, Psets y clasificaciones del archivo IFC. A partir de ahí, un motor de reglas codificado como especificaciones IDS (Information Delivery Specification, el estándar de buildingSMART para validación) comprueba cada elemento contra la convención de nomenclatura, los Psets obligatorios y los pares clasificación-valor esperados.

Piensa en el motor de reglas como el control de planta con plantilla: cada elemento pasa por un checklist fijo y, si cumple todos los puntos, se aprueba sin intervención humana. Es rápido, auditable y determinista: mismo input, mismo output siempre.

Los elementos que fallan de forma clara se marcan como no conformes. Pero un subconjunto no encaja en ninguna de las dos categorías: el atributo existe pero en un campo no estándar, la nomenclatura se desvía ligeramente del patrón sin romperlo semánticamente, o la clasificación normativa depende de contexto (tipo de compartimentación, uso del espacio) que la regla no puede evaluar sola.

Estos casos ambiguos se enrutan a un LLM con RAG (retrieval-augmented generation) que recupera el fragmento relevante del BEP (BIM Execution Plan), la norma aplicable (CTE DB-SI para resistencia al fuego en España, EN 13501-2 para clasificación europea) y ejemplos previos ya validados por un técnico. El modelo devuelve un veredicto estructurado: clasificación propuesta, nivel de confianza y justificación textual trazable a la fuente normativa citada.

Tipo de caso	Motor de reglas	LLM + RAG
Pset ausente, valor claro esperado	Detecta y bloquea	No interviene
Nomenclatura con variante no prevista	Falso positivo frecuente	Interpreta y sugiere corrección
Clasificación dependiente de contexto	No evaluable	Propone con justificación y confianza
Volumen de elementos por modelo	Miles, sin coste marginal	Decenas (solo ambiguos)

En proyectos piloto, el motor de reglas resuelve entre el 75% y el 85% de las comprobaciones sin ambigüedad. El LLM procesa el resto, y los casos con confianza baja (umbral configurable, típicamente por debajo del 70%) se derivan a revisión humana, nunca se aprueban automáticamente. Este enfoque es coherente con lo que documentamos al analizar cómo los LLM detectan y corrigen defectos de propiedades en BIM sin reglas fijas: el modelo de lenguaje aporta valor precisamente donde la regla determinista se queda corta.

Integración práctica

La adopción sigue un ciclo de cuatro fases, adaptable a la mayoría de entornos con BIM e inteligencia artificial ya en uso parcial:

1. Auditoría de estándares (2-4 semanas): recopilar convención de nomenclatura, BEP, tablas de clasificación y un histórico de RFIs relacionadas con no conformidades de modelo.
2. Codificación de reglas en IDS: traducir la convención documental a especificaciones ejecutables, validadas contra un subconjunto de modelos ya aprobados.
3. Piloto controlado: ejecutar el pipeline sobre 3-5 modelos activos en paralelo a la revisión manual actual, comparando resultados y ajustando umbrales de confianza del LLM.
4. Despliegue como gate del CDE: integrar la validación como paso obligatorio antes de subir un modelo al Common Data Environment (Trimble Connect, BIM 360, Autodesk Construction Cloud), con dashboard para el equipo de coordinación BIM.

Los datos mínimos necesarios son el archivo IFC (2x3 o IFC4), el BEP del proyecto, las tablas de clasificación aplicables y, si existe, un histórico de RFIs de proyectos previos para calibrar qué tipo de ambigüedad es más frecuente en la organización.

Despliegue air-gapped y on-premise

Defensa, infraestructura crítica y buena parte de la administración pública operan bajo políticas que prohíben llamadas a APIs en la nube. Este requisito no descarta el enfoque híbrido; cambia dónde vive cada componente.

El motor de reglas nunca depende de conectividad: es lógica determinista ligera que corre en cualquier estación de trabajo o servidor local sin necesidad de GPU. La parte que exige rediseño es el LLM.

En despliegue air-gapped, sustituimos la API cerrada por un modelo de pesos abiertos (familias Llama, Mixtral o variantes fine-tuned más pequeñas) alojado en un servidor on-premise con GPU dedicada (una L40S o A100 cubre la carga de la mayoría de proyectos medianos). El RAG se apoya en una base vectorial local que indexa la normativa aplicable y el BEP, sin salida a internet en ningún punto del pipeline.

La contrapartida es previsible: un modelo local suele rendir por debajo de las APIs frontera en razonamiento normativo complejo. Se compensa con tres medidas: grounding más estricto (el modelo solo cita fragmentos recuperados, nunca genera criterio sin fuente), umbral de confianza más conservador (más casos derivados a revisión humana) y actualización de las bases de reglas y normativa mediante paquetes versionados entregados por canal seguro, no por conexión directa.

Limitaciones y condiciones de uso

El sistema no sustituye la firma de un técnico competente en clasificaciones con implicación de seguridad, como resistencia al fuego o capacidad estructural. Es una capa de detección temprana, no una certificación.

La calidad del motor de reglas depende enteramente de qué tan bien se codifiquen las especificaciones IDS: reglas mal definidas generan falsos positivos que erosionan la confianza del equipo en el sistema.

El LLM necesita un volumen mínimo de casos ambiguos históricos (recomendamos al menos 200-300 ejemplos etiquetados) para calibrar umbrales de confianza fiables; por debajo de ese volumen, el sistema tiende a ser demasiado conservador o demasiado permisivo. En proyectos con normativa multilingüe o convenciones de nomenclatura muy heterogéneas entre subcontratistas, la fase de auditoría inicial se alarga y debe presupuestarse.

Lo que esto significa para el sector

El cambio de fondo no es tecnológico, es de momento de la validación. Pasar de una revisión puntual antes de la entrega a una comprobación continua durante el diseño desplaza el coste del error de obra (alto) a modelo (bajo).

Las constructoras que integren esta capa de validación en su flujo BIM pueden ofrecer garantías de calidad documental en licitación, algo cada vez más valorado en contratos públicos con exigencias de trazabilidad normativa. Combinado con capacidades de visión artificial en obra y modelos predictivos de coste, forma parte de una estrategia más amplia de digitalización donde la detección temprana reduce tanto el riesgo técnico como el financiero.

Si tu organización evalúa incorporar validación automatizada de cumplimiento en sus modelos BIM, con o sin restricciones de conectividad, podemos ayudarte a diseñar el piloto y a definir qué reglas codificar primero.