Volver al blog BIM e IFC
Entrega e ISO 19650 · 2026-08-07 · 10 min
Criterios de aceptación IFC: cómo aceptar o rechazar un modelo sin discusiones
«Este modelo no sirve» frente a «el modelo está bien» es una discusión sin final. Una tabla de aceptación de una página, acordada antes de la primera entrega, la convierte en una comprobación de cinco minutos con un resultado documentado.
Criterios de aceptación IFC: cómo aceptar o rechazar un modelo sin discusiones — IFC Viewer Online article cover
En todo proyecto llega un momento en el que un coordinador abre un modelo entregado, pasa veinte minutos descubriendo que no se puede usar, y escribe un correo que empieza con «lamentablemente». Lo que ocurre después depende casi por completo de una cosa: si alguien dejó por escrito, de antemano, qué aspecto tiene una entrega aceptable.
Si alguien lo hizo, el correo es corto, objetivo y no da pie a discusión. Si nadie lo hizo, el correo es el primer movimiento de una negociación sobre qué estándares se aplican, y se volverá a discutir en cada hito durante el resto del proyecto.
La aceptación es una checklist, no una opinión
El cambio de mentalidad es pequeño y lo cambia todo. Revisar una entrega no es valorar la calidad: es aplicar unos criterios acordados a un archivo. Eso tiene tres consecuencias que merece la pena dejar explícitas:
- El revisor no necesita más autoridad que la tabla acordada. No está juzgando la competencia de quien hizo el modelo; está comunicando un resultado.
- El autor puede predecir el resultado antes de entregar. Todo lo que se puede predecir se puede evitar, que es precisamente el objetivo.
- El desacuerdo, cuando lo hay, es sobre los criterios: una conversación que se puede tener una vez, con calma, en lugar de cada mes en mitad de una entrega.
No puedes rechazar una entrega por incumplir un estándar que quien la envió nunca aceptó. Solo puedes rechazarla por incumplir el que los dos acordasteis.
La tabla de criterios de aceptación
Este es el artefacto. Diez filas, una página, anexa al BEP (plan de ejecución BIM) o al EIR (requisitos de información). La tercera columna está vacía a propósito: el proyecto la rellena antes de la primera entrega, y es en ese acto de rellenarla donde ocurre el acuerdo de verdad.
| Criterio | Rechazar si… | Posición del proyecto |
|---|
| Integridad estructural | Cualquier hallazgo de esquema o espacial de gravedad error | Rechazar / aceptar con nota |
| Health Score | Por debajo del umbral acordado | Umbral: __ /100 |
| Cobertura de comprobaciones | Cualquier comprobación marcada como no ejecutada o fallida | Rechazar / requiere repetir la ejecución |
| Estabilidad de identificadores | Renovación de GUID por encima de un porcentaje acordado entre revisiones | Renovación máxima: __ % |
| Nombrado | El nombre del archivo no sigue la convención acordada | Rechazar / renombrar y registrar |
| Georreferenciación | El modelo no está sobre el punto de referencia compartido del proyecto | Rechazar |
| Unidades | Unidades de longitud no métricas | Rechazar |
| Clasificación | Elementos sin referencia de clasificación | Se aplica desde la fase: __ |
| Conjuntos de propiedades | Faltan los Pset requeridos para el nivel de necesidad de información declarado | Calendario de Pset: __ |
| Espacios | Espacios sin nombre, nombre largo o superficie | Se aplica desde la fase: __ |
Su objetivo no es ser estricta, sino estar decidida. Una tabla permisiva que todos han acordado vale más que una estricta que llega junto con el correo de rechazo.Las tres primeras filas son las que tienen más peso, y también las que más a menudo se dejan fuera. Las cláusulas que las incluyen en el BEP desde el principio se explican en las cláusulas del BEP que de verdad evitan entregas IFC deficientes.
La fila 3 merece su propio apartado: la cobertura de comprobaciones
La mayoría de las tablas de aceptación comprueban los resultados de una validación. Casi ninguna comprueba si esa validación llegó a ejecutarse de verdad, y ese agujero es lo bastante grande como para colar cualquier entrega.
Una comprobación que no se ha ejecutado tiene exactamente el mismo aspecto que una que ha pasado: las dos dan cero hallazgos. Un archivo grande agota el tiempo de espera, un worker se cae, una comprobación que depende de la geometría se rinde en silencio, y el informe vuelve limpio con una puntuación perfecta. La entrega se acepta habiéndose comprobado solo de nombre.
| Estado de la cobertura | Qué significa | Acción de aceptación |
|---|
| Ejecutada | La comprobación se completó. Cero hallazgos significa cero hallazgos. | Confía en el resultado. |
| No ejecutada | Se intentó pero no produjo resultado, normalmente por un tiempo de espera agotado o una ejecución cancelada. | Repite la ejecución antes de aceptar. Nunca la interpretes como un aprobado. |
| Fallida | La comprobación dio error. | Regístralo. Una puntuación calculada sobre comprobaciones fallidas no es comparable a una ejecución limpia. |
Revisar una entrega en cinco minutos
- Abre el contenedor y ejecuta el conjunto de reglas del proyecto. Menos de un minuto para la mayoría de modelos de disciplina.
- Comprueba primero la cobertura, y los resultados después. Si algo no se ha ejecutado, para: todavía no tienes una revisión.
- Lee la puntuación frente al umbral, y después los hallazgos de gravedad error. Todo lo demás es una nota, no un filtro.
- Compara con la revisión anterior. Los hallazgos nuevos son lo importante; los resueltos son la prueba de que se actuó tras la última revisión.
- Registra el resultado en el documento de transmisión o en el comentario del CDE (entorno común de datos): puntuación, conjunto de reglas, cobertura y cualquier hallazgo aceptado por acuerdo.
El paso 1 es la misma rutina que quien envía debería haber ejecutado antes de entregar; cómo comprobar un modelo IFC antes de la entrega lo explica desde el lado de quien envía. Cuando las dos partes ejecutan las mismas comprobaciones, la revisión deja de ser una inspección y se convierte en una confirmación.
Cómo redactar el rechazo
El tono importa tanto como el contenido, porque quien lo recibe suele ir con retraso y casi nunca es responsable personalmente. Tres reglas: nombra el criterio, no el modelo. Da la causa, no solo el síntoma. Di qué queda bloqueado y durante cuánto tiempo.
Hi {name},
We've run the agreed pre-acceptance check on {filename} (rev {n}) and it
comes back at {score}/100, below the {threshold} we set in clause {x} of
the BEP.
The two findings driving that are:
- {rule id} — {plain description} ({n} elements)
- {rule id} — {plain description} ({n} elements)
Both look like export settings rather than modelling, so they should be
quick — the report is attached with the element references.
We'll hold coordination on this container until the next issue.
Fíjate en lo que falta: cualquier adjetivo sobre el modelo, y cualquier especulación sobre por qué ha pasado. Un número, dos identificadores de regla, una causa probable y una consecuencia. Es un mensaje del que nadie tiene que defenderse, y por eso se actúa sobre él en lugar de escalarlo.
Cuándo aceptar un modelo que no ha superado la revisión
A veces la respuesta correcta es aceptar igualmente: la información que falta queda fuera del nivel de necesidad de información de esa fase, o un proveedor todavía no ha entregado su parte, o la alternativa es parar el proyecto. Aceptar una entrega que no ha superado la revisión es una decisión legítima. Aceptarla en silencio no lo es.
Un hallazgo dispensado necesita tener adjuntas tres cosas: un motivo, una persona que lo ha acordado y una fecha. Esa es toda la diferencia entre un hallazgo aceptado y uno ignorado, y es lo que evita que el mismo problema se redescubra como una crisis dos fases más tarde.
Esas dispensas tienen su sitio en el documento de transmisión, junto con el informe y todo lo demás que acompaña al contenedor: consulta qué entregar junto con un modelo IFC.
Criterios de aceptación IFC: cómo aceptar o rechazar un modelo sin discusiones