La verificación normativa automática de un modelo BIM consiste en leer los datos de cada elemento y compararlos, regla por regla, con el umbral que fija una norma. Una parte grande de ese trabajo se puede automatizar de forma determinista: encontrar los elementos, leer sus parámetros, aplicar el umbral y dejar constancia de dónde sale. Otra parte no: dar un proyecto por conforme con la normativa es un juicio profesional que firma una persona. Y hay un paso que no conviene dejar a una IA generativa: emitir el veredicto. Esta guía separa las tres cosas y explica cómo es un dictamen que un tercero puede comprobar.
Se llame verificación normativa, comprobación normativa, revisión de normativa, auditoría de modelo o model checking, el problema de fondo es el mismo: quien firma la entrega tiene que poder explicar, elemento por elemento, por qué da el modelo por revisado.
Qué es comprobar un modelo BIM contra una norma
Una norma de construcción está escrita para personas: artículos, tablas, excepciones y remisiones a otros documentos. Un modelo BIM está hecho de elementos con parámetros: muros, puertas, escaleras, forjados o losas, pilares o columnas, cada uno con sus dimensiones y propiedades. Comprobar el modelo contra la norma es tender un puente entre los dos mundos, y ese puente tiene cuatro tramos.
- Convertir el texto en una regla. Del artículo sale una condición que se puede medir: a qué elementos aplica, qué parámetro se mira y qué umbral se exige.
- Preparar el modelo. Los elementos tienen que traer ese parámetro, con un nombre y unas unidades que la regla entienda. Si el dato no está, no hay nada que medir.
- Ejecutar la comprobación. Para cada elemento, se compara el valor que trae el modelo con el umbral de la regla.
- Informar del resultado. Cada resultado queda registrado con el elemento, el valor observado, el umbral exigido y la fuente de la que sale.
Lo que cambia de una herramienta a otra es quién hace cada tramo y qué queda escrito al final. Un informe que solo dice «revisado» no deja ver ninguno de los cuatro.
Un ejemplo sencillo: una regla de anchura de paso en un recorrido de evacuación. La norma fija un ancho libre mínimo. El modelo tiene que traer el ancho libre de paso de cada puerta, y ese dato no es la anchura nominal de la familia: las familias de puerta suelen llevar la anchura de la hoja o del hueco, mientras que la norma mide lo que queda libre con la hoja abierta. Por eso el proyecto tiene que declarar un parámetro para ese dato, y es el tramo 2 el que lo hace posible. La comprobación compara uno con otro y registra el resultado junto al artículo del que sale el mínimo. No hace falta poner aquí una cifra para entender el método: lo que importa es que el umbral sale de un texto que cualquiera puede abrir y leer, y que el modelo trae el dato que ese texto mide.
Verificación normativa automática: qué hace una máquina y qué una persona
Determinista quiere decir que el mismo modelo, comprobado con la misma regla, da siempre el mismo resultado. Es la propiedad que permite que otra persona repita la comprobación y llegue al mismo sitio. No depende de cómo se formule una pregunta ni del día en que se haga.
| Paso | Quién debería hacerlo | Por qué |
|---|---|---|
| Encontrar los elementos a los que aplica la regla | Un evaluador determinista | Es una consulta sobre datos que el modelo debe traer: categoría, uso, nivel, tipo. Qué elementos entran lo fija la regla, no el evaluador |
| Leer el parámetro de cada elemento | Un evaluador determinista | Lee el parámetro que la regla declara, con su nombre y sus unidades. Qué parámetro representa el concepto de la norma se decidió al escribir la regla, y el modelo tiene que traerlo |
| Aplicar un umbral ya aprobado | Un evaluador determinista | Es una comparación: repetida mil veces, da mil veces lo mismo |
| Registrar el resultado con su cita | Un evaluador determinista | El rastro solo existe si el sistema obliga a escribirlo |
| Traducir un artículo a una regla | Una persona, con ayuda de IA | La IA puede proponer; una persona verifica la cita y aprueba |
| Decidir qué norma aplica al proyecto | Los datos del proyecto, revisados por una persona | País, fecha de depósito y, si hay un período de transición, el régimen que el proyecto declara; uso. Son datos del proyecto, no opiniones |
| Valorar excepciones y soluciones alternativas | Una persona | Es criterio técnico y lleva responsabilidad |
| Firmar el resultado | Una persona | La firma es de quien responde de la entrega |
La frontera no está entre lo fácil y lo difícil. Está entre lo que se puede repetir y comprobar, y lo que exige criterio y responsabilidad. Aplicar umbrales cae del primer lado; interpretar el texto de la norma y firmar, del segundo.
Por qué una IA generativa no debe emitir el veredicto
Los modelos de lenguaje son útiles para leer normativa: resumen un artículo, encuentran la tabla que aplica y explican en lenguaje llano por qué un elemento quedó fuera. El problema aparece cuando se les pide la última palabra. Hay tres razones de fondo.
- Pueden inventar el umbral. Un modelo de lenguaje produce texto verosímil, no texto verificado. Un trabajo de investigación de junio de 2026 sobre comprobación normativa con estos modelos advierte de que tienden a generar reglas incorrectas o alucinadas. Un umbral inventado y bien redactado es más peligroso que un error evidente, porque nadie lo cuestiona.
- No son reproducibles. La misma pregunta puede dar respuestas distintas según cómo se formule o qué versión del modelo responda. Un veredicto que no se repite igual no se puede defender ante un tercero.
- No dejan rastro verificable. Un párrafo convincente no es una comprobación. Si el resultado no dice qué regla aplicó, con qué versión, sobre qué dato del modelo y con qué cita, nadie puede revisarlo después.
La propia investigación va en esa dirección. Un trabajo de 2025 conecta modelos de lenguaje con Revit para interpretar normas, generar scripts y hacer comprobaciones que sus autores llaman semiautomáticas. Otro de julio de 2026 propone que los agentes de IA ayuden a escribir el código de verificación, pero con una orquestación determinista y un código que se pueda auditar. El reparto que se repite es siempre el mismo: la IA interpreta y propone, un procedimiento repetible comprueba y una persona decide. Los tres trabajos se consultaron como preprints en arXiv.
Nada de esto quita valor a la IA. Le asigna el sitio donde su error es barato: proponer una lectura del artículo que una persona confirma, redactar la explicación de un resultado ya calculado u ordenar qué conviene revisar primero. Un indicador de confianza puede ordenar una cola de revisión; no debería cambiar nunca el significado de un resultado.
¿Puede una IA decidir si un proyecto cumple la normativa?
No, y tampoco debería decidirlo un programa determinista. Que un proyecto se ajuste a la normativa es una conclusión profesional: la firma quien responde del proyecto y, cuando hace falta una licencia, la revisa la autoridad que la concede. Lo que una herramienta sí puede afirmar con rigor es algo más pequeño y más útil: este elemento, con este dato, queda dentro o fuera del umbral de esta regla, que sale de este artículo.
Por eso un buen sistema de verificación normativa no usa la palabra «cumple». No es prudencia: es que el sistema no tiene forma de saberlo. Un modelo puede tener todos sus elementos dentro de los umbrales comprobados y dejar fuera cosas que ninguna regla automatizada mira, como el cálculo estructural, una excepción justificada o una condición del solar.
Qué es una cita literal verificable
La cita es lo que convierte un resultado en algo que un tercero puede comprobar. «Según la normativa vigente» no es una cita: no dice qué documento, qué edición ni qué artículo. Una cita verificable tiene, como mínimo, estos campos.
| Campo | Qué contiene | Por qué importa |
|---|---|---|
| Documento | Nombre oficial de la norma y quién la emite | Distingue, por ejemplo, un reglamento anterior de un código nuevo |
| Edición y vigencia | Versión del texto y desde cuándo rige | Una regla correcta para una edición puede no valer para la siguiente |
| Ubicación | Artículo, tabla o página | Permite abrir el texto justo donde está el umbral |
| Texto literal | El fragmento copiado tal cual | Se puede comparar palabra por palabra con el original |
| Verificación | Quién comprobó la cita contra el texto y aprobó la regla | Una regla sin aprobar no debería dictaminar nada |
La regla práctica es corta: sin cita, no hay veredicto. Si un umbral no puede señalar el texto del que sale, no es defendible ante un tercero, por mucho que acierte.
Los cuatro resultados: OK, Revisar, Fuera de rango y No auditable
Un dictamen útil no se queda en sí o no, ni en una nota del 1 al 10. Necesita distinguir entre lo que se comprobó y salió dentro, lo que se comprobó y salió fuera, lo que pide criterio y lo que no se pudo juzgar. En OrionBIM ese vocabulario es cerrado: son cuatro resultados, siempre los mismos y siempre con el mismo nombre.
| Resultado | Qué significa | Qué no significa |
|---|---|---|
| OK | El dato del modelo está dentro del umbral de la regla citada | No dice que el proyecto esté en regla: eso lo valida quien lo firma |
| Revisar | Hay una señal, pero exige juicio profesional antes de darla por buena | No es un fallo ni un aprobado a medias |
| Fuera de rango | El dato del modelo queda fuera del umbral de la regla citada | No es una sanción: es un hallazgo con su cita, para corregir o justificar |
| No auditable | No hay juicio posible sobre ese punto | No es un incumplimiento ni un aprobado por omisión |
- OKEl dato del modelo está dentro del umbral de la regla citada.
- RevisarHay una señal que exige juicio profesional antes de darla por buena.
- Fuera de rangoEl dato del modelo queda fuera del umbral de la regla citada.
- No auditableNo hay base para juzgar ese punto: ni incumplimiento ni aprobado.
No hay un quinto resultado. No existe «probablemente bien» ni un porcentaje que lo resuma todo. Un vocabulario cerrado obliga a que cada resultado diga exactamente una cosa.
Por qué «No auditable» es un resultado honesto
«No auditable» es el resultado que más incomoda y el que más protege. Aparece cuando no hay base para juzgar, y las causas habituales son tres.
- No hay una regla aprobada para la norma, la edición o el país que corresponde al proyecto.
- El modelo no trae el dato que la regla necesita: el parámetro no existe o está vacío.
- La comprobación no se pudo ejecutar, por ejemplo porque falló la lectura del modelo. Un fallo técnico no es ni un acierto ni un error del proyecto.
La alternativa sería rellenar el hueco con un supuesto razonable: aplicar la norma de un país vecino, la edición anterior o un valor habitual. Es justo lo que no hay que hacer. Un resultado calculado con la norma equivocada parece una respuesta y no lo es. Por eso el comportamiento correcto es fallar cerrado: si no hay regla aprobada para esa jurisdicción, el resultado es «No auditable», nunca un veredicto prestado de otra.
La República Dominicana lo ilustra bien. Hasta el 10 de abril de 2027 conviven dos marcos técnicos, los reglamentos anteriores y el nuevo Código de Construcción, y la autoridad no admite mezclar criterios de los dos en un mismo proyecto. Una comprobación que no sepa qué régimen declaró el proyecto no debería dictaminar. Lo explicamos en la guía sobre la normativa de construcción en República Dominicana y la transición al CDCRD.
Cómo se reconoce un dictamen que un tercero puede comprobar
Antes de firmar un informe de verificación normativa, propio o ajeno, conviene pasarle esta lista. Si falta alguno de estos puntos, el documento puede servir para trabajar, pero no como respaldo de una firma.
- Identifica la revisión del modelo que se comprobó y su estado en el CDE, no solo el nombre del proyecto.
- Dice qué norma y qué edición se aplicaron, y por qué esa y no otra.
- Para cada resultado, nombra el elemento, el valor observado en el modelo y el umbral exigido.
- Cada umbral lleva su cita literal, con artículo o página.
- Cada regla tiene versión y alguien que la aprobó.
- Los resultados usan un vocabulario cerrado, y los casos sin juicio se declaran en lugar de esconderse.
- Se puede repetir: con el mismo modelo y las mismas reglas, sale lo mismo.
- Dice quién firma y cuándo, y no afirma más de lo que comprobó.
Cómo encaja esta comprobación en el flujo de una entrega lo explican las guías de control de calidad del modelo BIM antes de compartirlo y del estado Compartido al Publicado en el CDE. Si quieres ver cómo se presentan esos ocho puntos en un documento real, puedes ver cómo emite OrionBIM un dictamen con su cita.
Qué hace OrionBIM aquí y qué no
OrionBIM lee el modelo desde Revit, en vivo, con su propio complemento, y lo contrasta regla por regla contra las reglas aprobadas para el país donde se construye.
- Evalúa con un procedimiento determinista. La IA interpreta, busca y explica; no calcula ni decide el resultado.
- Solo dictamina con reglas que citan su fuente. Cada regla lleva su fuente y la cita literal de la que sale el umbral, y se comprueba que esa cita existe en el texto de la norma. Que el umbral coincida con lo que dice la cita lo tiene que confirmar una persona, y a 1 de octubre de 2026 esa revisión de las reglas ya cargadas sigue en curso. Desde septiembre de 2026, ninguna regla nueva entra en el motor sin que la apruebe una persona.
- Devuelve uno de cuatro resultados: OK, Revisar, Fuera de rango o No auditable. Mientras esa revisión sigue en curso, OrionBIM muestra como «Revisar» todo resultado que el evaluador habría dado como OK o Fuera de rango, con el valor medido, el umbral y la cita a la vista, y avisa de que ningún resultado sustituye la validación de un técnico competente.
- Exige firma humana. Para publicar una entrega en el entorno común de datos (CDE, o ECD) desde OrionBIM hacen falta tres cosas a la vez: que exista el veredicto, que no sea «No auditable» y que lo firme una persona. Un «No auditable» se puede firmar para dejar constancia, pero no habilita ninguna publicación. Es la compuerta de OrionBIM: no sustituye la autorización y la aceptación que fije el proyecto.
Y lo que no hace:
- No dice que un proyecto «cumple» ni emite certificados. Esa conclusión la valida quien firma el proyecto.
- No sustituye al proyectista ni a la autoridad que concede la licencia.
- No audita sin regla aprobada. Si no la hay para ese país o ese régimen, el resultado es «No auditable», y nunca se aplica la norma de otro país.
- La detección de colisiones entre disciplinas es otra función de OrionBIM, distinta de la comprobación normativa; esta guía no la describe.
Fuentes
- Large Language Model-Driven Code Compliance Checking in Building Information ModelingarXiv, Madireddy y otros (2025), consultada 2026-10-01
- Reinforcement learning to improve large language model-based automated code compliance systemsarXiv, Shi y otros (2026), consultada 2026-10-01
- ARCHER: Agentic Rule and Compliance Harness for Executable RegulationsarXiv, Anand y otros (2026), consultada 2026-10-01
- MIVHED establece período de transición de un año para implementación del Código de Construcción de la República DominicanaMinisterio de Vivienda, Hábitat y Edificaciones (MIVHED), consultada 2026-10-01