Volver al blog BIM e IFC
Privacidad y seguridad · 2026-06-28 · 19 min
Validación de IFC en el navegador frente a la nube: la decisión de arquitectura que los equipos BIM suelen equivocar
Validación de IFC sin conexión mediante WebAssembly: nada se sube, funciona en obra. Validador IFC en el navegador frente a la nube: privacidad, RGPD, velocidad de subida, uso sin conexión y cuándo gana cada arquitectura.
Validación de IFC en el navegador frente a la nube: la decisión de arquitectura que los equipos BIM suelen equivocar — IFC Viewer Online article cover
- 0 bytes — subidos en la validación en el navegador
- 40 s — para subir 50 MB a 10 Mbps
- 44 — reglas comprobadas en el cliente
- 10× — más rápido en cargas repetidas gracias a la caché OPFS
Cuando un coordinador BIM pregunta «¿dónde puedo validar mi archivo IFC?», la respuesta que suele recibir es una URL. Un servicio en la nube. Subir el modelo, esperar, obtener el informe. Este es el modelo mental por defecto para la validación de IFC, y es la opción equivocada para una parte importante de los proyectos en los que se aplica.
Existen dos arquitecturas fundamentalmente distintas para la validación de IFC. Entender la diferencia -y saber cuál conviene a cada proyecto- es cada vez más una competencia profesional para los BIM managers y los equipos de construcción digital. La arquitectura que elijas determina, en una sola decisión, la privacidad, la velocidad, el cumplimiento normativo y la disponibilidad sin conexión.
Dos arquitecturas completamente distintas
La distinción no es un detalle de producto. Es una cuestión de dónde ocurre el cálculo, y eso determina todo lo que viene después.
ARCHITECTURE A — Cloud Validation
══════════════════════════════════
Your Machine Internet Cloud Server
──────────── ──────── ────────────
① Open IFC file
│
│ ② UPLOAD ──────────────────────────────► Server receives file
│ 50 MB → ~40 s at 10 Mbps │
│ 250 MB → ~3 min at 10 Mbps ③ Server parses IFC
│ 1 GB → ~13 min at 10 Mbps │
│ ④ Validation runs
│ │
│ ⑤ RESULTS ◄───────────────────────────────────────┘
│
⑥ View report
Data custody: Your machine → Transit (TLS) → Third-party server
ARCHITECTURE B — Browser-Based Validation
══════════════════════════════════════════
Your Machine Internet
──────────── ────────
① Open IFC file
│
② WASM binary loads (Nothing uploaded.
│ Nothing leaves the device.
③ Web Worker: IFC parsing Ever.)
│
④ 44 validation rules run
│
⑤ Health Score calculated
│
⑥ WebGL renders 3D model
│
⑦ Results: instant, local
OPFS cache: parsed geometry persists → repeat load ~10× faster
Data custody: Your machine only
En la arquitectura A, el archivo IFC lo procesa una infraestructura que no controlas. Atraviesa una red, reside en un servidor de terceros y lo gestiona software que no has desplegado tú. En la arquitectura B, la misma lógica de validación se ejecuta dentro de tu navegador mediante WebAssembly, compilado a partir del mismo código en C++ que usan las herramientas BIM de escritorio nativas: nada sale del dispositivo y no interviene ningún tercero en el procesamiento.
Por qué los modelos IFC contienen información sensible
El instinto de tratar los archivos IFC como si fueran PDF -algo que se puede compartir, subir y archivar en cualquier sitio- subestima lo que hay incrustado en un modelo de edificio complejo. Un archivo IFC es una base de datos estructurada de información de activos. En muchos tipos de proyecto, esa información es realmente sensible, restringida o clasificada.
Administración pública e infraestructuras cívicas
Juzgados, edificios administrativos, centros de datos, infraestructuras críticas de suministro. Datos de vulnerabilidad estructural, distribución de los sistemas de emergencia y esquemas de infraestructura de seguridad incrustados como geometría y propiedades IFC.
Aeropuertos y grandes nodos de transporte
Geometría de los controles de seguridad, límites del lado aire, ubicación de cámaras CCTV y sensores, trazado de los sistemas de emergencia. Sujeto a normativa de seguridad aeroportuaria y clasificación de seguridad nacional en la mayoría de jurisdicciones.
Hospitales y centros sanitarios
Infraestructura de flujo de pacientes, redundancia del suministro de gases medicinales, distribución de las unidades de cuidados críticos. Sujeto a los requisitos de gobernanza de la información del NHS (Reino Unido) y a HIPAA (EE. UU.). Datos estructurales de los sistemas de seguridad vital.
Ferrocarril y transporte crítico
Geometría de túneles, infraestructura de señalización, vías de evacuación de emergencia, topología del suministro eléctrico. A menudo clasificado como infraestructura crítica nacional, con prohibiciones explícitas de subida a terceros.
Plantas industriales y de proceso
Distribución de equipos de proceso, geometría de contención de materiales peligrosos, ubicación de los sistemas de seguridad. Sujeto a la normativa COMAH / Seveso III en la UE. Datos de proceso comercialmente sensibles.
Defensa y ámbito militar
Restringido de forma explícita en la mayoría de países por la normativa de contratación de defensa. Los archivos IFC de infraestructura militar no se pueden subir legalmente a servicios comerciales en la nube sin una habilitación de seguridad específica y aprobación contractual.
Más allá del tipo de proyecto, los archivos IFC incrustan metadatos que se consideran sensibles bajo varios marcos legales. El campo FILE_NAME de la cabecera del archivo STEP contiene el nombre del autor y de la organización. Las propiedades de IfcProject llevan identificadores del cliente y del proyecto. Los modelos de planificación de espacios pueden incluir recuentos de ocupantes y distribución del personal. Los conjuntos de propiedades pueden revelar capacidades de sistemas, especificaciones estructurales y características operativas de una instalación: el tipo de información que hace viable el espionaje industrial.
El ángulo del RGPD y el tratamiento de datos
El artículo 4 del RGPD define los datos personales de forma amplia: incluye cualquier información relativa a una persona física identificada o identificable. En BIM, esto abarca: nombres de ocupantes en la asignación de espacios, datos de contacto del propietario en los metadatos de IfcProject, recuentos de personal en los cálculos de evacuación contra incendios y, en ocasiones, códigos de referencia de activos si permiten identificar a personas concretas cruzándolos con otros conjuntos de datos.
En la práctica, la mayoría de las grandes empresas de AEC y los organismos públicos tienen políticas de tratamiento de datos que, técnicamente, prohíben subir modelos de proyecto a servicios de terceros no aprobados. Estas políticas se ignoran con frecuencia a nivel de coordinador porque la política está guardada en un gestor documental y la URL del validador se compartió en un foro de la comunidad. La validación en el navegador convierte el cumplimiento en el camino de menor resistencia: elimina por completo la decisión de subir el archivo.
Cómo WebAssembly cambió las herramientas BIM en el navegador
Para entender por qué la validación en el navegador es hoy técnicamente creíble hay que entender qué cambió. Antes de 2017, ningún fabricante de software BIM se planteaba en serio ejecutar un parser de IFC real en un navegador. El navegador solo podía ejecutar JavaScript, y JavaScript es el lenguaje equivocado para analizar el formato STEP de la norma ISO 10303-21 a velocidad de producción.
Antes de WebAssembly: la situación previa a 2017
- Analizar IFC exigía procesamiento del lado del servidor: los validadores en la nube no existían por comodidad, sino porque eran la única arquitectura viable. No había ninguna alternativa competitiva en rendimiento.
- Los visores IFC en el navegador usaban formatos intermedios preprocesados (extractos de geometría en JSON, mallas simplificadas) en lugar de analizar el IFC en tiempo real. Lo que veías no era el IFC, sino una aproximación generada por el servidor.
- Analizar un archivo IFC de 50 MB en JavaScript puro tardaba minutos y hacía que la pestaña se colgara en equipos con poca memoria. Un archivo de 200 MB era, en la práctica, inviable en un navegador.
- El renderizado 3D estaba en las primeras fases de WebGL: acelerado por GPU, pero limitado a niveles de complejidad de escena manejables desde JavaScript. Los modelos estructurales grandes, con cientos de miles de elementos, resultaban inviables.
- Los Web Workers ofrecían aislamiento de hilos, pero no forma de ejecutar código nativo compilado. El rendimiento estaba limitado por las pausas del recolector de basura de JavaScript y por su modelo de ejecución en un solo hilo.
Después de WebAssembly: lo que ahora es posible
WebAssembly (WASM) es un formato binario de instrucciones para una máquina virtual basada en pila que se ejecuta en el navegador a una velocidad cercana a la nativa. El código escrito en C, C++ o Rust se compila a WASM y se ejecuta aproximadamente al 60-90 % de la velocidad nativa dentro de cualquier navegador moderno: sin plugins, sin instalación, con aislamiento total de memoria y sandbox garantizado. WASM se convirtió en estándar del W3C en 2019 y está disponible en todos los navegadores principales.
En el caso concreto de IFC: web-ifc, el parser que usa la librería @thatopen/components, está compilado de C++ a WebAssembly. Analiza el formato STEP de IFC en el mismo orden de velocidad que las librerías nativas de escritorio. Un archivo IFC de 50 MB se analiza en menos de 10 segundos en un portátil moderno, dentro de una pestaña del navegador, sin ningún servidor de por medio. El mismo nivel de rendimiento que Solibri o Navisworks al cargar un archivo local, pero en el navegador.
WASM: velocidad de C++ en el navegador
web-ifc está compilado de C++ a WebAssembly. El análisis del STEP de IFC funciona al 60-90 % de la velocidad nativa: el mismo nivel de rendimiento que las herramientas BIM de escritorio. Un modelo de 50 MB se analiza en menos de 10 segundos en un portátil moderno.
Web Workers: paralelismo real
El análisis WASM se ejecuta en un Web Worker dedicado, un hilo del sistema operativo independiente. La interfaz del navegador sigue respondiendo mientras se carga un modelo pesado. La validación se ejecuta en un worker paralelo, y da resultados mientras la geometría se sigue cargando.
OPFS: caché local persistente
El Origin Private File System (OPFS) es una API de almacenamiento nativa del navegador, aislada por origen y sin acceso posible desde servidores. La geometría analizada se guarda en OPFS después de la primera carga. Las cargas siguientes son unas 10 veces más rápidas: sin volver a analizar, sin volver a subir nada.
WebGL / WebGPU: renderizado por GPU
Three.js abstrae WebGL para ofrecer renderizado 3D de alto rendimiento. La gestión de la escena basada en fragmentos maneja modelos con cientos de miles de elementos a tasas de fotogramas interactivas. El soporte de WebGPU llegará para el renderizado de nueva generación.
La caché OPFS: por qué las cargas repetidas cambian el flujo de trabajo
El Origin Private File System es una capa de almacenamiento nativa del navegador, aislada al origen web actual. Otros orígenes, otras pestañas y -de forma crítica- los servidores remotos no pueden acceder a su contenido. Persiste entre sesiones del navegador. Para los flujos de trabajo con IFC, OPFS resuelve la fricción más molesta al trabajar con modelos pesados: el coste de volver a analizar el archivo cada vez.
Analizar desde cero un archivo IFC de 250 MB tarda entre 20 y 40 segundos en un equipo moderno. El mismo archivo, cargado desde la caché de OPFS, tarda entre 2 y 3 segundos. Para un coordinador BIM que abre el mismo modelo de proyecto varias veces al día, OPFS marca la diferencia entre una herramienta que se percibe rápida y otra que se percibe como una espera. Y como el almacenamiento de OPFS está aislado por origen y vive en el sistema de archivos local, los datos del modelo en caché nunca llegan a un servidor: heredan la misma garantía de privacidad que la propia validación en el navegador.
El cuello de botella de la subida: cifras reales
El coste más infravalorado de la validación IFC en la nube es el tiempo de subida. Es invisible en las comparativas de producto, pero domina el flujo de trabajo real. Así es como se ve la subida de tamaños habituales de archivo IFC en distintos tipos de conexión realistas, y cómo se compara con el procesamiento local en el navegador:
| Tamaño del archivo IFC | Oficina (10 Mbps de subida) | Móvil 4G (3 Mbps) | En obra (1 Mbps) |
|---|
| 50 MB | ~40 segundos | ~2 min 15 s | ~7 minutos |
| 250 MB | ~3 min 20 s | ~11 minutos | ~33 minutos |
| 1 GB | ~13 minutos | ~45 minutos | ~2 h 15 min |
| 2 GB | ~27 minutos | ~1 h 30 min | ~4 h 30 min |
Solo tiempo de subida; hay que sumar el procesamiento del servidor: 50 MB +5-15 s · 250 MB +30-90 s · 1 GB +2-6 min · 2 GB +5-15 min. Validación en el navegador: 0 s de subida en todos los casos.Un modelo de 250 MB: minutos antes de poder empezar la comprobación
- Navegador, análisis local (sin subida): 0.7 min — 20-40 s en el primer análisis, en un equipo moderno
- Subida desde la oficina (10 Mbps): 3.3 min
- Subida por 4G (3 Mbps): 11 min
- Subida desde obra (1 Mbps): 33 min
Solo tiempo de subida para las herramientas basadas en servidor; su procesamiento añade otros 30-90 s.
Un archivo IFC de 250 MB -un modelo de coordinación típico para un proyecto comercial mediano- tarda más de 3 minutos en subirse con una conexión de oficina rápida. Por 4G, tarda 11 minutos. Para un coordinador BIM que ejecuta comprobaciones previas a la entrega varias veces al día, solo el tiempo de subida añade horas de espera muerta a la semana. La validación en sí tarda una fracción del tiempo de subida.
En obra, donde el 4G es la norma y el ancho de banda se comparte entre las oficinas de obra y las tablets BIM, subir un archivo IFC de 1 GB supone un compromiso de 45 minutos antes de que se ejecute una sola regla de validación. La validación en el navegador procesa el mismo archivo en local en 90-180 segundos, sin ninguna dependencia de la red, y en 2-5 segundos en sesiones posteriores gracias a la caché de OPFS.
La comparativa completa: validación IFC en el navegador frente a la nube
| Aspecto | Validación en el navegador | Validación en la nube |
|---|
| Privacidad | ✅ El archivo nunca sale del dispositivo | ⚠️ El archivo se sube al servidor |
| Soberanía del dato | ✅ Sin custodia de terceros | ⚠️ Custodia de datos por terceros |
| Cumplimiento del RGPD | ✅ Cumple por diseño | ⚠️ Requiere DPA + base legal |
| Proyectos sensibles | ✅ Única opción en muchos casos | ❌ A menudo prohibido |
| Velocidad (archivos <50 MB) | ✅ Prácticamente instantánea | ⚠️ Retraso por subida + procesamiento |
| Velocidad (archivos >250 MB) | ✅ Sin penalización de subida | ❌ Cuello de botella en la subida |
| Cargas repetidas | ✅ Caché OPFS (~10 veces más rápido) | ❌ Hay que volver a subir todo cada vez |
| Tiempo de subida | ✅ Cero | ❌ Proporcional al tamaño del archivo |
| Disponibilidad sin conexión | ✅ Soporte completo sin conexión | ❌ Requiere internet |
| Uso en campo/obra | ✅ Funciona con 4G o sin conexión | ❌ Lento / poco fiable en obra |
| Dependencia de internet | ✅ Ninguna (tras la carga inicial) | ❌ Necesaria en cada ejecución |
| Procesamiento por lotes | ❌ Manual, de uno en uno | ✅ Automatización por API / lotes |
| Integración CI/CD | ❌ No adecuado | ✅ Webhook/API nativos |
| Registro de auditoría del equipo | ⚠️ Solo local | ✅ Historial centralizado |
| Informes a nivel de organización | ⚠️ Sin agregación | ✅ Panel unificado entre proyectos |
| Seguridad (datos) | ✅ Sin riesgo en tránsito ni en servidor | ⚠️ Exposición en tránsito y en servidor |
| Seguridad (brechas) | ✅ No hay servidor que comprometer | ⚠️ Depende del proveedor cloud |
| Archivos muy grandes >2 GB | ⚠️ Limitado por la RAM del dispositivo | ✅ El servidor tiene más RAM |
| Coste | ✅ Gratis o de bajo coste | ⚠️ Por uso o suscripción |
| Carga de infraestructura | ✅ Ninguna: se ejecuta en el navegador | ✅ Gestionada por el proveedor |
| Complejidad de puesta en marcha | ✅ Abrir la URL, arrastrar el archivo | ⚠️ Requiere cuenta / clave API |
Dónde la validación en la nube es realmente mejor
Una comparativa que solo destaca un lado es propaganda. La validación IFC en la nube tiene ventajas reales en contextos concretos, y aplicar la validación en el navegador en esos contextos es la decisión equivocada.
Pipelines de CI/CD automatizados
Validación que se dispara automáticamente en cada commit del modelo, de forma análoga a los tests unitarios de software. Las API en la nube con respuestas por webhook son la única arquitectura posible para la automatización sin interfaz (headless). No hay ninguna sesión de navegador en la que ejecutar WASM dentro de un pipeline del lado del servidor.
Procesamiento por lotes a escala de cartera de proyectos
Auditar cientos de archivos IFC existentes en toda una cartera de proyectos -una migración de datos heredados, una auditoría del archivo del CDE- resulta práctico mediante API por lotes en la nube, e inviable hacerlo manualmente en el navegador archivo a archivo.
Informes centralizados de equipo
Un BIM manager necesita una vista única del historial de validación en varios proyectos y autores del modelo: tendencias de la puntuación, frecuencia de incidencias, cumplimiento a lo largo del tiempo. Los servicios en la nube agregan esta información. Las herramientas en el navegador solo producen resultados locales.
Integración con la pasarela del CDE
Algunos entornos comunes de datos (CDE) validan automáticamente los archivos IFC entrantes antes de aceptarlos. Esto es, por naturaleza, una operación del lado del servidor: es el servidor del CDE el que procesa el archivo, no el navegador del usuario. Las API de validación en la nube son el punto de integración.
Validación en el navegador: mejor opción para
- Proyectos de administración pública y sector público
- BIM de defensa, infraestructuras y aeropuertos
- Modelos de hospitales y centros sanitarios
- Plantas industriales e ingeniería de proceso
- Modelos sujetos al RGPD o a políticas de restricción de datos
- Validación en obra y sin conexión
- Comprobación previa antes del envío formal a la nube
- Coordinadores individuales y equipos pequeños
Validación en la nube: mejor opción para
- Pipelines de validación CI/CD automatizados
- Auditorías de calidad por lotes a nivel de cartera
- Paneles centralizados de calidad BIM
- Pasarelas de CDE y controles de entrega automatizados
- Proyectos comerciales no sensibles a gran escala
- Automatización de flujos de trabajo multiequipo en empresas
- Integración con otros sistemas mediante API
- Archivos muy grandes que superan la RAM del dispositivo local
Cinco ideas equivocadas sobre la validación de IFC en el navegador
Idea equivocada 1: «Las aplicaciones en el navegador son más lentas que la nube»
Esto era cierto en 2015. Ya no lo es. El código WebAssembly se ejecuta al 60-90 % de la velocidad nativa de C++ dentro de un navegador moderno. El motor de análisis de IFC (web-ifc) está compilado de C++, la misma categoría de rendimiento que las librerías que usan Solibri, los importadores de IFC de Autodesk e IfcOpenShell. Combinado con una latencia de subida nula, la validación en el navegador suele ser más rápida que la de la nube para los tamaños de modelo habituales, sobre todo en conexiones con menos de 50 Mbps de subida.
La idea equivocada persiste porque se compara el JavaScript del navegador (lento y con recolector de basura) con aplicaciones nativas compiladas (rápidas). Las herramientas BIM modernas en el navegador no ejecutan el procesamiento pesado en JavaScript: ejecutan WASM compilado a una velocidad cercana a la nativa, y JavaScript solo orquesta el flujo de trabajo. La diferencia entre JS y WASM es tan relevante como la diferencia entre Python y C++.
Idea equivocada 2: «Hay que subir un archivo IFC para poder validarlo»
Es falso. Cuando abres un archivo IFC en un validador del navegador, el navegador crea un objeto File en memoria local, accesible para el WASM y el JavaScript que se ejecutan en ese contexto, pero que no se transmite a ningún destino de red salvo que el código llame explícitamente a una API fetch o XHR. Puedes comprobarlo tú mismo: abre el inspector de red del navegador (F12 → pestaña Network/Red) y confirma que no se produce ninguna subida al abrir y validar un modelo.
Idea equivocada 3: «Los archivos IFC grandes no se pueden procesar en un navegador»
Los navegadores modernos pueden reservar varios gigabytes de RAM en el hardware habitual de un puesto de trabajo. Un archivo IFC de 250 MB ocupa 250 MB en memoria, muy por debajo de lo que puede reservar un proceso del navegador en un equipo con 16 GB. Los Web Workers amplían esto con acceso a memoria fuera del hilo principal. Para archivos de más de 500 MB, la carga espacial por fragmentos hace viable el procesamiento en el navegador incluso con restricciones de memoria más ajustadas. OPFS garantiza que un modelo grande, analizado una vez, no necesite volver a analizarse en sesiones posteriores.
Idea equivocada 4: «La nube siempre es más segura»
La seguridad tiene varias dimensiones, no es un atributo único. Los servicios en la nube suelen cifrar los datos en tránsito (TLS 1.3) y en reposo (AES-256), lo que cubre la interceptación pasiva. Pero introducen superficies de ataque que el procesamiento en el navegador elimina por completo: compromiso del lado del servidor, buckets de almacenamiento mal configurados, acceso interno de empleados del proveedor cloud, ataques a la cadena de suministro de la infraestructura del proveedor e infracciones de residencia de datos si el servidor está fuera de las jurisdicciones exigidas contractualmente.
Un archivo que nunca sale del dispositivo tiene exposición cero a cualquier amenaza basada en red. La pregunta de seguridad no es «¿qué arquitectura es más segura en términos absolutos?», sino «¿qué modelos de amenaza son más relevantes para este proyecto?». Para un modelo de una instalación de un ministerio de Defensa, el procesamiento en el navegador elimina por completo el vector de amenaza de la subida. Para un proyecto comercial no sensible en el que importa el registro centralizado, los controles en la nube pueden ser la solución de compromiso adecuada.
Idea equivocada 5: «La validación en el navegador no es de nivel empresarial»
El software de nivel empresarial se define por su fiabilidad, la profundidad de sus funciones y su soporte institucional, no por su arquitectura de despliegue. Figma, AutoCAD Web, Google Earth y Microsoft Office para la Web son aplicaciones de nivel empresarial que funcionan en el navegador mediante WebAssembly y las API web modernas. El mismo runtime WASM, los mismos Web Workers y la misma infraestructura WebGL que impulsan esas aplicaciones son los que impulsan la validación de IFC en el navegador. «Basado en el navegador» es una decisión de arquitectura sobre dónde ocurre el cálculo, no un techo de calidad.
Solución de problemas de la validación en el navegador
El modelo carga, pero la validación parece lenta
La validación se ejecuta en un Web Worker independiente y no bloquea la interfaz: el modelo 3D debería seguir siendo interactivo mientras la validación se ejecuta en segundo plano. Si el proceso de carga en general se percibe lento, comprueba si el modelo se está cargando desde la caché de OPFS (rápido) o se está analizando desde cero (más lento para archivos grandes). En la primera carga, un archivo de 200 MB tardará entre 20 y 40 segundos en analizarse, incluso en local. Las cargas siguientes desde caché tardan entre 2 y 5 segundos.
Falta de memoria con archivos muy grandes
Los archivos de más de 400-500 MB pueden agotar la memoria del navegador en equipos con 8-16 GB de RAM. Síntomas: la pestaña del navegador se cuelga o deja de responder. Soluciones: cerrar otras pestañas para liberar memoria, usar un equipo con 16 GB de RAM o más, o dividir un modelo federado en archivos por disciplina antes de cargarlo. Para archivos que superan de forma habitual los 500 MB, la validación en la nube puede ser la arquitectura más adecuada: el hardware de servidor suele tener más margen de RAM.
La caché de OPFS crece con el tiempo
OPFS guarda fragmentos de geometría analizada de cada modelo cargado. Para un equipo de proyecto que carga muchos modelos a lo largo de semanas, la caché puede crecer hasta varios gigabytes. El gestor de caché del validador muestra todos los archivos en caché con su tamaño y permite eliminarlos de forma selectiva. La configuración de almacenamiento del navegador también permite borrar todo el almacenamiento del origen. La caché se guarda en el dispositivo local y no es accesible desde ningún servidor remoto.
Los resultados de la validación difieren entre el navegador y la nube
Si los resultados difieren, la causa más habitual es que se están aplicando conjuntos de reglas distintos. La validación en el navegador (44 reglas de calidad) y la validación de esquema en la nube (cumplimiento de ISO 10303-21) comprueban cosas distintas, no las mismas reglas en sitios distintos. Consulta la guía de niveles de validación para la distinción entre la comprobación de esquema de nivel 1, la comprobación de calidad de nivel 2 y el nivel 3 de IDS. Un resultado de IDS debería ser idéntico entre dos motores conformes a la especificación que ejecuten el mismo archivo .ids sobre el mismo modelo.
Dónde encaja IFC Viewer Online en esta arquitectura
IFC Viewer Online es una implementación en el navegador de la arquitectura B. El parser de IFC (web-ifc compilado a WASM), el motor de validación de 44 reglas, el cálculo del Health Score, el motor de comprobación IDS 1.0, el panel BCF y el renderizador 3D (Three.js sobre WebGL) se ejecutan todos en el navegador. No se sube nada. La arquitectura lo impone a nivel de implementación: no existe ningún endpoint del lado del servidor al que enviar los datos del modelo.
Análisis WASM en un Web Worker
web-ifc (C++ → WASM) se ejecuta en un hilo worker dedicado. La interfaz sigue respondiendo durante la carga de modelos grandes. Un archivo de 50 MB se analiza en menos de 10 segundos. Uno de 200 MB, en 20-40 segundos. El primer resultado: siempre local.
Caché OPFS para cargas repetidas
Los fragmentos de geometría analizada persisten en OPFS después de la primera sesión. Las cargas siguientes son unas 10 veces más rápidas: sin volver a analizar, sin depender de la red. La caché es privada del origen del navegador y no es accesible desde servidores remotos.
44 reglas de calidad + IDS 1.0
44 reglas de calidad del modelo (integridad estructural, ISO 19650, Psets, clasificación, LOD, MEP) más un motor IDS 1.0 de buildingSMART probado contra los 100 casos de prueba oficiales de bSI, todo del lado del cliente.
Edición no destructiva de propiedades
Los nombres de elementos, los valores de los conjuntos de propiedades y los GlobalId se pueden editar en archivos IFC recibidos sin necesidad de volver a pasar por el software de autoría, y sin subir nada a ningún servidor.
Recomendaciones de experto: elegir la arquitectura adecuada
La elección entre validación en el navegador y en la nube es una decisión de gobernanza a nivel de proyecto, no una preferencia de herramienta. Esta es la lógica de decisión para los escenarios más habituales:
- Proyectos de administración pública, defensa, aeropuertos, ferrocarril, hospitales y plantas industriales: la validación en el navegador debería ser la opción por defecto. Comprueba si la política de tratamiento de datos de tu organización permite subir el modelo antes de plantearte la nube. Si la política no lo aborda, asume que la subida está prohibida y pide aclaración a tu delegado de protección de datos.
- Proyectos comerciales sin clasificación de datos: cualquiera de las dos arquitecturas es viable. Usa la nube para registros de auditoría centralizados e integración con CI/CD. Usa el navegador por velocidad, preferencia de privacidad y capacidad sin conexión.
- Comprobaciones de calidad diarias antes de la entrega, hechas por coordinadores individuales: la validación en el navegador es más rápida, más sencilla, no requiere cuenta y elimina la espera de la subida. Ejecútala en local antes de cualquier envío formal al CDE.
- Auditorías de cartera o evaluaciones de cumplimiento del CDE en muchos modelos: el procesamiento por lotes en la nube es la herramienta adecuada. Pasar 200 modelos por una API en la nube y obtener un informe de calidad consolidado es inviable en un navegador.
- Control de entrega automatizado dentro de un CDE: la validación en la nube con integración por API es la única arquitectura práctica. No hay ningún contexto de navegador disponible en un flujo de trabajo automatizado del lado del servidor.
- Flujo de trabajo híbrido: usa la validación en el navegador como control de calidad diario (rápida, privada, sin necesidad de cuenta), y reserva la nube para el envío formal al CDE, donde un registro de auditoría, la integración por API o la automatización por lotes aportan un valor real. Ambas arquitecturas se complementan.
Preguntas frecuentes
¿Es realmente privada la validación de IFC en el navegador?
Sí, cuando está implementada correctamente. WebAssembly se ejecuta en un contexto de navegador aislado (sandbox). El objeto File que contiene los datos IFC se crea en la memoria local del navegador. Para que esos datos lleguen a un servidor, el código tendría que llamar explícitamente a una API de red. Un validador en el navegador bien implementado no hace ninguna llamada de ese tipo para el archivo IFC. Puedes comprobarlo abriendo el inspector de red del navegador (F12 → pestaña Network/Red) y confirmando que no se produce ninguna subida al abrir y validar un modelo.
¿Puede la validación en el navegador funcionar sin conexión?
Sí, con una salvedad. La propia aplicación debe cargarse al menos una vez con conexión: el binario WASM y los paquetes de JavaScript se descargan en la primera visita. A partir de ahí, una aplicación web progresiva puede funcionar completamente sin conexión. Los modelos guardados en caché en OPFS se cargan sin acceso a la red. Para visitas a obra donde la conectividad es poco fiable, cargar la aplicación y precargar en caché el modelo de proyecto la noche anterior garantiza la disponibilidad sin conexión al día siguiente.
¿Cuál es el límite práctico de tamaño de archivo para la validación en el navegador?
En equipos con 16 GB de RAM (un puesto de trabajo moderno típico o un portátil de gama alta), los archivos de hasta 400-500 MB se procesan de forma fiable. En equipos con 8 GB, el límite práctico ronda los 200-250 MB, a partir de los cuales la presión de memoria provoca inestabilidad. La caché de OPFS elimina el coste de volver a analizar el archivo, así que la primera carga es la única vez que asumes el coste completo de procesamiento. Para archivos que superan de forma habitual los 500 MB, la validación en la nube puede ofrecer más margen.
¿WebAssembly introduce riesgos de seguridad?
WASM se ejecuta en el mismo entorno aislado que JavaScript: no puede acceder al sistema de archivos, al sistema operativo ni a la red sin pasar por las API del navegador, sujetas a las mismas políticas de seguridad que cualquier contenido web. La pregunta relevante de seguridad no es el runtime de WASM en sí, sino qué llamadas de red hace la aplicación, y un validador en el navegador bien implementado no hace ninguna para el archivo IFC.
¿Puedo usar ambas arquitecturas en el mismo flujo de trabajo del proyecto?
Sí, y a menudo es el planteamiento más práctico. Los coordinadores ejecutan la validación en el navegador en local como comprobación previa a cualquier envío formal. La pasarela del CDE usa validación en la nube con una API para el registro de auditoría y la aceptación automática. La comprobación en el navegador es rápida y privada; la de la nube aporta el registro oficial y los informes a nivel de organización. Ambas arquitecturas cubren necesidades distintas y se complementan.
Resumen
Dónde va a parar un archivo IFC durante la validación no es un detalle técnico. Es una decisión de gobernanza del dato que determina el cumplimiento normativo de una gran parte de los proyectos de AEC.
IFC Viewer Blog
Proyectos sensibles: navegador por defecto
Los proyectos de administración pública, defensa, sanidad e infraestructuras deberían usar por defecto la validación en el navegador. A menudo es la única opción que cumple la normativa, no solo la más cómoda. Los datos nunca salen del dispositivo.
Automatización y lotes: la nube
Los pipelines de CI/CD, las auditorías de cartera y los informes centralizados requieren arquitectura en la nube. Una sesión de navegador no puede participar en flujos de trabajo automatizados sin interfaz ni agregar resultados entre equipos.
Validación diaria: el navegador gana en velocidad
Tiempo de subida cero, cargas repetidas aceleradas por OPFS y sin necesidad de cuenta. Para las comprobaciones previas a la entrega que definen el día a día de un coordinador, el procesamiento en el navegador es más rápido que la nube en todos los tamaños de modelo habituales.
Para entender qué comprueban en realidad las 44 reglas de calidad, y cómo se relacionan con la validación de esquema y con IDS, consulta la guía completa del verificador de modelos IFC. Para el Health Score que resume la calidad en un único número, consulta la guía del Health Score de IFC. Si necesitas corregir valores de propiedades o GUID en un archivo IFC recibido sin subirlo a ningún sitio, el editor de IFC online gratuito aplica la misma arquitectura basada en el navegador a la edición no destructiva de propiedades.
Validación de IFC en el navegador frente a la nube: la decisión de arquitectura que los equipos BIM suelen equivocar