Voltar ao blog de BIM e IFC
Privacidade e segurança · 2026-06-28 · 19 min
Validação de IFC no navegador vs. na nuvem: a decisão de arquitetura que as equipes de BIM erram
Validação de IFC offline via WebAssembly — nada é enviado, funciona em obra. Verificador de IFC no navegador vs. na nuvem: privacidade, GDPR, velocidade de upload, uso offline e quando cada arquitetura vence.
Validação de IFC no navegador vs. na nuvem: a decisão de arquitetura que as equipes de BIM erram — IFC Viewer Online article cover
- 0 bytes — enviado na validação no navegador
- 40 s — para enviar 50 MB a 10 Mbps
- 44 — regras verificadas no lado do cliente
- 10× — mais rápido em recarregamentos via cache OPFS
Quando um coordenador BIM pergunta 'onde posso validar meu arquivo IFC?', a resposta que costuma receber é uma URL. Um serviço na nuvem. Enviar o modelo, esperar, receber o relatório. Esse é o modelo mental padrão para a validação de IFC — e é a escolha errada para uma parcela significativa dos projetos em que é aplicado.
Existem duas arquiteturas fundamentalmente diferentes para a validação de IFC. Entender a diferença — e saber qual é a certa para cada projeto — é, cada vez mais, uma competência profissional para gerentes de BIM e equipes de construção digital. A arquitetura escolhida determina, em uma única decisão, privacidade, velocidade, conformidade regulatória e disponibilidade offline.
Duas arquiteturas completamente diferentes
A distinção não é um detalhe de produto. É uma questão de onde o processamento acontece — e isso determina tudo o que vem depois.
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
Na Arquitetura A, o arquivo IFC é processado por uma infraestrutura que você não controla. Ele atravessa uma rede, fica armazenado em um servidor de terceiros e é manipulado por um software que você não implantou. Na Arquitetura B, a mesma lógica de validação roda dentro do seu navegador usando WebAssembly compilado a partir do mesmo código C++ que alimenta as ferramentas BIM de desktop nativas — nada sai do dispositivo, e nenhum terceiro participa do processamento.
Por que os modelos IFC contêm informações sensíveis
O instinto de tratar arquivos IFC como PDFs — compartilháveis, enviáveis, arquiváveis em qualquer lugar — subestima o que está embutido em um modelo de edificação complexo. Um arquivo IFC é um banco de dados estruturado de informações do ativo. Para muitos tipos de projeto, essa informação é genuinamente sensível, restrita ou classificada.
Infraestrutura governamental e cívica
Tribunais, órgãos públicos, data centers, utilidades críticas. Dados de vulnerabilidade estrutural, layouts de sistemas de emergência e esquemas de infraestrutura de segurança embutidos como geometria e propriedades IFC.
Aeroportos e terminais de transporte
Geometria de pontos de controle de segurança, layouts de limites do lado aéreo, posicionamento de CFTV e sensores, roteamento de sistemas de emergência. Sujeitos à classificação de segurança da aviação e de segurança nacional na maioria das jurisdições.
Hospitais e saúde
Infraestrutura de fluxo de pacientes, redundância de fornecimento de gases medicinais, layouts de unidades de terapia intensiva. Sujeitos aos requisitos do NHS IG (Reino Unido) e à HIPAA (EUA). Dados estruturais de sistemas de segurança da vida.
Ferrovias e transporte crítico
Geometria de túneis, infraestrutura de sinalização, rotas de fuga de emergência, topologia de fornecimento de energia. Frequentemente classificados como infraestrutura nacional crítica, com proibições explícitas de envio a terceiros.
Plantas industriais e de processo
Layout de equipamentos de processo, geometria de contenção de materiais perigosos, posicionamento de sistemas de segurança. Sujeitos às regulamentações COMAH / SEVESO III na UE. Dados de processo comercialmente sensíveis.
Defesa e militar
Explicitamente restritos na maioria dos países por regulamentações de aquisição de defesa. Arquivos IFC de infraestrutura militar não podem, legalmente, ser enviados a serviços comerciais na nuvem sem autorização de segurança específica e aprovação contratual.
Além do tipo de projeto, os arquivos IFC embutem metadados que se qualificam como sensíveis sob múltiplos regimes legais. O campo FILE_NAME do cabeçalho do arquivo STEP contém nomes de autor e de organização. As propriedades de IfcProject carregam identificadores de cliente e de projeto. Modelos de planejamento de espaços podem incluir contagens de ocupantes e distribuição de equipe. Os conjuntos de propriedades podem revelar capacidades de sistemas, especificações estruturais e características operacionais de uma instalação — o tipo de informação que viabiliza a espionagem industrial.
O ângulo do GDPR e do tratamento de dados
O Artigo 4 do GDPR define dado pessoal de forma ampla — inclui qualquer informação relacionada a uma pessoa natural identificada ou identificável. No BIM, isso abrange: nomes de ocupantes em atribuições de espaço, dados de contato do proprietário nos metadados de IfcProject, contagens de pessoal em cálculos de evacuação contra incêndio e, às vezes, códigos de referência de ativos, quando esses se relacionam a indivíduos identificáveis por meio de outros conjuntos de dados.
Na prática, a maioria das grandes empresas de AEC e órgãos do setor público tem políticas de tratamento de dados que, tecnicamente, proíbem o envio de modelos de projeto a serviços de terceiros não aprovados. Essas políticas são frequentemente ignoradas no nível do coordenador porque a política fica em um sistema de gestão de documentos e a URL do verificador foi compartilhada em um fórum da comunidade. A validação no navegador transforma a conformidade no caminho de menor resistência — ela elimina completamente a decisão de enviar ou não o arquivo.
Como o WebAssembly mudou as ferramentas BIM no navegador
Entender por que a validação no navegador hoje é tecnicamente confiável exige entender o que mudou. Antes de 2017, rodar um parser de IFC genuíno em um navegador não era levado a sério por nenhum fornecedor de software BIM. O navegador só conseguia executar JavaScript, e o JavaScript é a linguagem errada para processar o formato STEP da ISO 10303-21 na velocidade de produção.
Antes do WebAssembly — a situação pré-2017
- O processamento de IFC exigia processamento no lado do servidor — os verificadores na nuvem existiam não como uma conveniência, mas como a única arquitetura viável. Não havia alternativa competitiva em desempenho.
- Os visualizadores de IFC no navegador usavam formatos intermediários pré-processados (extratos de geometria em JSON, malhas simplificadas) em vez de processamento de IFC em tempo real. O que você via não era o IFC — era uma aproximação gerada pelo servidor.
- Um arquivo IFC de 50 MB processado em JavaScript puro levava minutos e provocava travamentos da aba em máquinas com memória limitada. Um arquivo de 200 MB era praticamente impossível em um contexto de navegador.
- A renderização 3D era WebGL em estágio inicial — acelerada por GPU, mas limitada a complexidades de cena administráveis em JavaScript. Modelos estruturais grandes com centenas de milhares de elementos eram inviáveis.
- Os Web Workers forneciam isolamento de thread, mas nenhuma forma de rodar código nativo compilado. O desempenho era limitado pelas pausas de coleta de lixo do JavaScript e pelo modelo de execução de thread única.
Depois do WebAssembly — o que é possível hoje
O WebAssembly (WASM) é um formato binário de instruções para uma máquina virtual baseada em pilha que roda no navegador em velocidade quase nativa. Código escrito em C, C++ ou Rust é compilado para WASM e executa a aproximadamente 60–90% da velocidade nativa dentro de qualquer navegador moderno — sem plugins, sem instalação, com isolamento total de memória e sandbox garantido. O WASM se tornou um padrão do W3C em 2019 e está disponível em todos os principais navegadores.
Especificamente para o IFC: o web-ifc — o parser usado pela biblioteca @thatopen/components — é compilado de C++ para WebAssembly. Ele processa o formato STEP do IFC na mesma classe de velocidade das bibliotecas de desktop nativas. Um arquivo IFC de 50 MB é processado em menos de 10 segundos em um notebook moderno, dentro de uma aba do navegador, sem nenhum servidor envolvido. A mesma classe de desempenho do Solibri ou do Navisworks carregando um arquivo local — mas no navegador.
WASM: velocidade de C++ no navegador
O web-ifc é compilado de C++ para WebAssembly. O processamento do formato STEP do IFC roda a 60–90% da velocidade nativa — a mesma classe de desempenho das ferramentas BIM de desktop. Um modelo de 50 MB é processado em menos de 10 segundos em um notebook moderno.
Web Workers: paralelismo real
O processamento em WASM roda em um Web Worker dedicado — uma thread separada do sistema operacional. A interface do navegador permanece responsiva durante o carregamento de modelos pesados. A validação roda em um worker paralelo, fornecendo resultados enquanto a geometria carrega.
OPFS: cache local persistente
O Origin Private File System é uma API de armazenamento nativa do navegador, isolada por origem e inacessível a servidores. A geometria processada é gravada no OPFS após o primeiro carregamento. As recargas são ~10× mais rápidas — sem reprocessamento, sem reenvio.
WebGL / WebGPU: renderização por GPU
O Three.js abstrai o WebGL para renderização 3D de alto desempenho. O gerenciamento de cena baseado em fragmentos lida com modelos com centenas de milhares de elementos em taxas de quadros interativas. O suporte a WebGPU está a caminho para a renderização de próxima geração.
O cache OPFS: por que as recargas mudam o fluxo de trabalho
O Origin Private File System é uma camada de armazenamento nativa do navegador, isolada para a origem web atual. Outras origens, outras abas do navegador e — o que é essencial — servidores remotos não conseguem acessar seu conteúdo. Ele persiste entre sessões do navegador. Para fluxos de trabalho com IFC, o OPFS resolve o atrito mais doloroso das ferramentas de modelos pesados: o custo do reprocessamento.
Um arquivo IFC de 250 MB processado do zero leva de 20 a 40 segundos em uma máquina moderna. O mesmo arquivo carregado a partir do cache do OPFS carrega em 2 a 3 segundos. Para um coordenador BIM que abre o mesmo modelo de projeto várias vezes ao dia, o OPFS é a diferença entre uma ferramenta que parece rápida e uma que parece um exercício de espera. E, como o armazenamento do OPFS é isolado por origem e vive no sistema de arquivos local, os dados do modelo em cache nunca chegam a um servidor — herdam a mesma garantia de privacidade da própria validação no navegador.
O gargalo do upload — números reais
O custo mais subestimado da validação de IFC na nuvem é o tempo de upload. Ele é invisível nas comparações entre produtos, mas dominante no fluxo de trabalho real. Veja como fica o envio de tamanhos comuns de arquivo IFC em tipos realistas de conexão — e como o processamento local no navegador se compara:
| Tamanho do arquivo IFC | Escritório (10 Mbps de upload) | 4G móvel (3 Mbps) | Em 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 |
Apenas o tempo de upload — some o processamento do servidor: 50 MB +5–15 s · 250 MB +30–90 s · 1 GB +2–6 min · 2 GB +5–15 min. Validação no navegador: upload de 0 s em todos os casos.Um modelo de 250 MB: minutos antes que a checagem possa começar
- Navegador, processamento local (sem upload): 0.7 min — 20–40 s no primeiro processamento em uma workstation moderna
- Upload do escritório (10 Mbps): 3.3 min
- Upload via 4G (3 Mbps): 11 min
- Upload da obra (1 Mbps): 33 min
Apenas o tempo de upload para ferramentas baseadas em servidor; o processamento delas soma mais 30–90 s.
Um arquivo IFC de 250 MB — um modelo de coordenação típico para um projeto comercial de médio porte — leva mais de 3 minutos para ser enviado em uma conexão de escritório rápida. Em 4G, leva 11 minutos. Para um coordenador BIM que roda checagens de pré-entrega várias vezes ao dia, só o tempo de upload já soma horas de espera morta por semana. A validação em si leva uma fração do tempo de upload.
Em obras, onde a conectividade 4G é a norma e a banda é compartilhada entre os escritórios de obra e os tablets de BIM, enviar um arquivo IFC de 1 GB é um compromisso de 45 minutos antes que uma única regra de validação seja executada. A validação no navegador processa o mesmo arquivo localmente em 90 a 180 segundos, sem nenhuma dependência de rede — e em 2 a 5 segundos nas sessões seguintes, graças ao cache do OPFS.
A comparação completa: validação de IFC no navegador vs. na nuvem
| Dimensão | Validação no navegador | Validação na nuvem |
|---|
| Privacidade | ✅ O arquivo nunca sai do dispositivo | ⚠️ O arquivo é enviado a um servidor |
| Soberania de dados | ✅ Nenhuma custódia por terceiros | ⚠️ Custódia de dados por terceiros |
| Conformidade com o GDPR | ✅ Em conformidade por design | ⚠️ Exige DPA + base legal |
| Projetos sensíveis | ✅ Única opção em muitos casos | ❌ Frequentemente proibida |
| Velocidade (pequenos <50 MB) | ✅ Quase instantânea | ⚠️ Atraso de upload + processamento |
| Velocidade (grandes >250 MB) | ✅ Sem penalidade de upload | ❌ Gargalo de upload |
| Recargas | ✅ Cache OPFS (~10× mais rápido) | ❌ Reenvio completo a cada vez |
| Tempo de upload | ✅ Zero | ❌ Proporcional ao tamanho do arquivo |
| Disponibilidade offline | ✅ Suporte offline total | ❌ Exige internet |
| Uso em campo, em obra | ✅ Funciona em 4G ou offline | ❌ Lento / instável em obra |
| Dependência de internet | ✅ Nenhuma (após o carregamento inicial) | ❌ Necessária a cada execução |
| Processamento em lote | ❌ Manual, um de cada vez | ✅ Automação via API / lote |
| Integração com CI/CD | ❌ Não adequada | ✅ Webhook/API nativos |
| Trilha de auditoria da equipe | ⚠️ Somente local | ✅ Histórico centralizado |
| Relatórios em toda a organização | ⚠️ Não agregados | ✅ Painel entre projetos |
| Segurança (dados) | ✅ Sem risco de trânsito / servidor | ⚠️ Exposição em trânsito + servidor |
| Segurança (violação) | ✅ Nenhum servidor a comprometer | ⚠️ Depende do provedor de nuvem |
| Arquivos muito grandes >2 GB | ⚠️ Limitado pela RAM do dispositivo | ✅ O servidor tem mais RAM |
| Custo | ✅ Gratuito a baixo custo | ⚠️ Por uso ou assinatura |
| Peso de infraestrutura | ✅ Zero — roda no navegador | ✅ Gerenciado pelo provedor |
| Complexidade de configuração | ✅ Abrir a URL, arrastar o arquivo | ⚠️ Exige conta / chave de API |
Onde a validação na nuvem é genuinamente melhor
Uma comparação que só destaca um dos lados é advocacia, não análise. A validação de IFC na nuvem tem vantagens reais em contextos específicos — e aplicar a validação no navegador a esses contextos é a decisão errada.
Pipelines automatizados de CI/CD
Validação disparada automaticamente a cada commit do modelo — análogo aos testes unitários de software. APIs na nuvem com respostas via webhook são a única arquitetura para automação sem interface (headless). Não há sessão de navegador para rodar WASM em um pipeline no lado do servidor.
Processamento em lote em escala de portfólio
Auditar centenas de arquivos IFC existentes em um portfólio de projetos — uma migração de dados legados, uma auditoria de arquivo do CDE — é prático via APIs de lote na nuvem e impraticável para rodar manualmente no navegador, arquivo por arquivo.
Relatórios centralizados para a equipe
Um gerente de BIM precisa de uma visão única do histórico de validação entre vários projetos e originadores — tendências de score, frequência de problemas, conformidade ao longo do tempo. Serviços na nuvem agregam isso. Ferramentas de navegador produzem apenas resultados locais.
Integração com o gateway do CDE
Alguns CDEs validam automaticamente os uploads de IFC recebidos antes de aceitá-los. Isso é, por natureza, uma operação no lado do servidor — o servidor do CDE processa o arquivo, não o navegador de um usuário. As APIs de validação na nuvem são o ponto de integração.
Validação no navegador — melhor encaixe
- Projetos governamentais e do setor público
- BIM de defesa, infraestrutura e aeroportos
- Modelos de instalações hospitalares e de saúde
- Plantas industriais e engenharia de processo
- Modelos com políticas de GDPR ou restrição de dados
- Validação em obra e offline
- Pré-checagem antes do envio formal à nuvem
- Coordenadores individuais e equipes pequenas
Validação na nuvem — melhor encaixe
- Pipelines automatizados de validação de CI/CD
- Auditorias de qualidade em lote de todo o portfólio
- Painéis centralizados de qualidade BIM
- Gateway de CDE e portões automatizados de entrega
- Projetos comerciais não sensíveis em escala
- Automação de fluxo de trabalho multiequipe corporativo
- Integração via API com outros sistemas
- Arquivos muito grandes, além da RAM do dispositivo local
Cinco equívocos sobre a validação de IFC no navegador
Equívoco 1: "Aplicativos de navegador são mais lentos que a nuvem"
Isso era verdade em 2015. Não é mais. O código WebAssembly roda a 60–90% da velocidade nativa do C++ dentro de um navegador moderno. O mecanismo de processamento de IFC (web-ifc) é compilado a partir de C++ — a mesma categoria de desempenho das bibliotecas que alimentam o Solibri, os importadores de IFC da Autodesk e o IfcOpenShell. Combinada com latência de upload zero, a validação no navegador é frequentemente mais rápida que a nuvem para tamanhos de modelo típicos, especialmente em conexões mais lentas que 50 Mbps de upload.
O equívoco persiste porque as pessoas comparam o JavaScript do navegador (lento e com coleta de lixo) com aplicativos nativos compilados (rápidos). As ferramentas BIM modernas de navegador não rodam em JavaScript para o processamento pesado — elas rodam WASM compilado em velocidade quase nativa, com o JavaScript apenas orquestrando o fluxo de trabalho. A distinção entre JS e WASM é tão significativa quanto a diferença entre Python e C++.
Equívoco 2: "Você precisa enviar um arquivo IFC para validá-lo"
Isso é falso. Quando você abre um arquivo IFC em um verificador de navegador, o navegador cria um objeto File na memória local — acessível ao WASM e ao JavaScript rodando naquele contexto do navegador, mas não transmitido a nenhum endpoint de rede, a menos que o código chame explicitamente uma API de fetch ou XHR. Você pode verificar isso sozinho: abra o inspetor de rede do navegador (F12 → aba Network) e confirme que nenhum upload ocorre quando um modelo é aberto e validado.
Equívoco 3: "Arquivos IFC grandes não rodam em um navegador"
Navegadores modernos conseguem alocar vários gigabytes de RAM em hardware de workstation típico. Um arquivo IFC de 250 MB em memória ocupa 250 MB — bem dentro do que um processo de navegador pode alocar em uma máquina com 16 GB. Os Web Workers estendem isso com acesso a memória fora da thread principal. Para arquivos acima de 500 MB, o carregamento espacial em blocos torna o processamento no navegador viável mesmo sob restrições de memória mais apertadas. O OPFS garante que um modelo grande, processado uma vez, nunca precise ser reprocessado nas sessões seguintes.
Equívoco 4: "A nuvem é sempre mais segura"
Segurança é multidimensional, não um atributo único. Serviços na nuvem tipicamente criptografam dados em trânsito (TLS 1.3) e em repouso (AES-256), o que resolve a interceptação passiva. Mas eles introduzem superfícies de ataque que o processamento no navegador elimina por completo: comprometimento no lado do servidor, buckets de armazenamento mal configurados, acesso interno por funcionários do provedor de nuvem, ataques à cadeia de suprimentos na infraestrutura do provedor e violações de residência de dados, caso o servidor esteja localizado fora das jurisdições exigidas contratualmente.
Um arquivo que nunca sai do dispositivo tem exposição zero a qualquer ameaça baseada em rede. A questão de segurança não é 'qual arquitetura é mais segura em termos absolutos?', mas 'quais modelos de ameaça são mais relevantes para este projeto?'. Para o modelo de uma instalação de um Ministério da Defesa, o processamento no navegador elimina completamente o vetor de ameaça do upload. Para um projeto comercial não sensível em que o registro centralizado importa, os controles da nuvem podem ser a escolha certa.
Equívoco 5: "A validação no navegador não é de nível corporativo"
Software de nível corporativo é definido por confiabilidade, profundidade de recursos e suporte institucional — não pela arquitetura de implantação. Figma, AutoCAD Web, Google Earth e Microsoft Office para a Web são aplicativos de nível corporativo que rodam no navegador usando WebAssembly e APIs web modernas. O mesmo runtime WASM, os mesmos Web Workers e a mesma infraestrutura WebGL que alimentam esses aplicativos também alimentam a validação de IFC no navegador. "Baseado em navegador" é uma decisão de arquitetura sobre onde o processamento acontece — não é um teto de qualidade.
Solucionando problemas de validação no navegador
O modelo carrega, mas a validação parece lenta
A validação roda em um Web Worker separado e não bloqueia a interface — o modelo 3D deve permanecer interativo enquanto a validação roda em segundo plano. Se o processo de carregamento geral parecer lento, verifique se o modelo está carregando do cache do OPFS (rápido) ou sendo processado do zero (mais lento para arquivos grandes). No primeiro carregamento, um arquivo de 200 MB levará de 20 a 40 segundos para ser processado, mesmo localmente. As cargas seguintes a partir do cache levam de 2 a 5 segundos.
Falta de memória em arquivos muito grandes
Arquivos acima de 400–500 MB podem esgotar a memória do navegador em máquinas com 8–16 GB de RAM. Sintomas: a aba do navegador trava ou fica sem resposta. Soluções: feche outras abas do navegador para liberar memória, use uma máquina com 16 GB de RAM ou mais, ou divida um modelo federado em arquivos específicos por disciplina antes de carregar. Para arquivos consistentemente acima de 500 MB, a validação na nuvem pode ser a arquitetura mais adequada — o hardware de servidor tipicamente tem mais margem de RAM.
O cache do OPFS cresce muito com o tempo
O OPFS armazena fragmentos de geometria processada para cada modelo carregado. Para uma equipe de projeto que carrega muitos modelos ao longo de semanas, o cache pode crescer para vários gigabytes. O Gerenciador de Cache do verificador mostra todos os arquivos em cache com seus tamanhos e permite exclusão seletiva. As configurações de armazenamento do navegador também permitem limpar todo o armazenamento da origem. O cache fica armazenado no dispositivo local e não é acessível a nenhum servidor remoto.
Os resultados de validação diferem entre navegador e nuvem
Se os resultados diferem, a causa mais comum é que conjuntos de regras diferentes estão sendo aplicados. A validação no navegador (44 regras de qualidade) e a validação de schema na nuvem (conformidade com a ISO 10303-21) verificam coisas diferentes — não as mesmas regras em lugares diferentes. Consulte o guia das camadas de validação para entender a distinção entre a checagem de schema do Nível 1, a checagem de qualidade do Nível 2 e o IDS do Nível 3. Um resultado de IDS deve ser idêntico entre quaisquer dois mecanismos conformes com a especificação que rodem o mesmo arquivo .ids contra o mesmo modelo.
Onde o IFC Viewer Online se encaixa nessa arquitetura
O IFC Viewer Online é uma implementação baseada em navegador da Arquitetura B. O parser de IFC (web-ifc compilado para WASM), o mecanismo de validação com 44 regras, o cálculo do Health Score, o mecanismo de checagem IDS 1.0, o painel de BCF e o renderizador 3D (Three.js via WebGL) rodam todos no navegador. Nada é enviado. A arquitetura impõe isso no nível da implementação — não existe um endpoint no lado do servidor para o qual enviar os dados do modelo.
Processamento em WASM em um Web Worker
O web-ifc (C++ → WASM) roda em uma thread worker dedicada. A interface permanece responsiva durante o carregamento de modelos grandes. Um arquivo de 50 MB é processado em menos de 10 segundos. Um arquivo de 200 MB, em 20 a 40 segundos. O primeiro resultado: local. Sempre.
Cache do OPFS para recargas
Os fragmentos de geometria processada persistem no OPFS após a primeira sessão. As recargas são ~10× mais rápidas — sem reprocessamento, sem dependência de rede. O cache é privado à origem do navegador e inacessível a servidores remotos.
44 regras de qualidade + IDS 1.0
44 regras de qualidade de modelo (integridade estrutural, ISO 19650, Psets, classificação, LOD, MEP), além de um mecanismo IDS 1.0 da buildingSMART testado contra os 100 casos de teste oficiais da bSI — tudo no lado do cliente.
Edição não destrutiva de propriedades
Nomes de elementos, valores de conjuntos de propriedades e GlobalIds podem ser editados em arquivos IFC recebidos sem passar de volta pelo software de autoria — e sem enviar nada a nenhum servidor.
Recomendações de especialistas: escolhendo a arquitetura certa
A escolha entre validação no navegador e na nuvem é uma decisão de governança em nível de projeto, não uma preferência de ferramenta. Veja a lógica de decisão para os cenários mais comuns:
- Projetos governamentais, de defesa, aeroportos, ferrovias, hospitais e plantas industriais: a validação no navegador deve ser a suposição padrão. Verifique se a política de tratamento de dados da sua organização permite o envio de modelos antes de considerar a nuvem. Se a política não trata do assunto, assuma que o envio é proibido e busque esclarecimento com o encarregado de proteção de dados.
- Projetos comerciais sem classificação de dados: qualquer uma das arquiteturas é viável. Use a nuvem para trilhas de auditoria centralizadas e integração com CI/CD. Use o navegador para velocidade, preferência por privacidade e capacidade offline.
- Checagens diárias de qualidade pré-entrega feitas por coordenadores individuais: a validação no navegador é mais rápida, mais simples, não exige conta e elimina a espera do upload. Rode localmente antes de qualquer envio formal ao CDE.
- Auditorias de portfólio ou avaliações de conformidade com o CDE em muitos modelos: o processamento em lote na nuvem é a ferramenta certa. Rodar 200 modelos por uma API na nuvem e obter um relatório de qualidade consolidado é impraticável em um navegador.
- Portão automatizado de entrega dentro de um CDE: a validação na nuvem com integração via API é a única arquitetura prática. Não existe contexto de navegador disponível em um fluxo de trabalho automatizado no lado do servidor.
- Fluxo de trabalho híbrido: use a validação no navegador como o portão diário de qualidade (rápido, privado, sem necessidade de conta) e reserve a nuvem para o envio formal ao CDE, onde uma trilha de auditoria, a integração via API ou a automação em lote agregam valor genuíno. Essas arquiteturas são complementares.
Perguntas frequentes
A validação de IFC no navegador é realmente privada?
Sim, quando implementada corretamente. O WebAssembly roda em um contexto isolado (sandbox) do navegador. O objeto File que contém os dados do IFC é criado na memória local do navegador. Para que esses dados cheguem a um servidor, o código precisa chamar explicitamente uma API de rede. Um verificador de navegador implementado corretamente não faz nenhuma chamada desse tipo para o arquivo IFC. Verifique isso abrindo o inspetor de rede do navegador (F12 → aba Network) e confirmando que nenhum upload ocorre ao abrir e validar um modelo.
A validação no navegador funciona offline?
Sim, com uma ressalva. O próprio aplicativo precisa ser carregado ao menos uma vez enquanto online — o binário WASM e os pacotes JavaScript são baixados na primeira visita. Depois disso, um aplicativo web progressivo pode rodar totalmente offline. Os modelos em cache no OPFS carregam sem nenhum acesso à rede. Para visitas a obras onde a conectividade é instável, carregar o aplicativo e pré-armazenar em cache o modelo do projeto na noite anterior garante disponibilidade offline no dia seguinte.
Qual é o limite prático de tamanho de arquivo para a validação no navegador?
Em hardware com 16 GB de RAM (uma workstation moderna típica ou um notebook de alto desempenho), arquivos de até 400–500 MB são processados de forma confiável. Em máquinas com 8 GB, o limite prático fica em torno de 200–250 MB, antes que a pressão de memória cause instabilidade. O cache do OPFS elimina o custo de reprocessamento — então o primeiro processamento é a única vez em que você paga o custo total. Para arquivos consistentemente acima de 500 MB, a validação na nuvem pode oferecer mais margem.
O WebAssembly introduz riscos de segurança?
O WASM roda no mesmo ambiente isolado que o JavaScript — não consegue acessar o sistema de arquivos, o sistema operacional ou a rede sem passar pelas APIs do navegador, sujeitas às mesmas políticas de segurança de qualquer conteúdo web. A pergunta de segurança relevante não é o runtime do WASM em si, mas quais chamadas de rede o aplicativo faz — e um verificador de navegador implementado corretamente não faz nenhuma para o arquivo IFC.
Posso usar as duas arquiteturas no mesmo fluxo de trabalho do projeto?
Sim — esse costuma ser o arranjo mais prático. Os coordenadores rodam a validação no navegador localmente como uma pré-checagem antes de qualquer envio formal. O gateway do CDE usa validação na nuvem com uma API para o registro de auditoria e a aceitação automatizada. A checagem no navegador é rápida e privada; a checagem na nuvem fornece o registro oficial e os relatórios em toda a organização. As duas arquiteturas atendem a necessidades diferentes e se complementam.
Resumo
Para onde vai um arquivo IFC durante a validação não é um detalhe técnico. É uma decisão de governança de dados que determina a conformidade regulatória para uma grande parcela dos projetos de AEC.
Blog do IFC Viewer
Projetos sensíveis: navegador em primeiro lugar
Projetos governamentais, de defesa, de saúde e de infraestrutura devem adotar por padrão a validação no navegador. Costuma ser a única opção em conformidade — não apenas a mais conveniente. Os dados nunca saem do dispositivo.
Automação e lote: nuvem
Pipelines de CI/CD, auditorias de portfólio e relatórios centralizados exigem arquitetura na nuvem. Uma sessão de navegador não consegue participar de fluxos de trabalho automatizados sem interface (headless) nem agregar resultados entre equipes.
Validação diária: o navegador vence em velocidade
Tempo de upload zero, recargas aceleradas pelo OPFS e nenhuma conta necessária. Para as checagens de pré-entrega que definem o fluxo de trabalho diário de um coordenador, o processamento no navegador é mais rápido que a nuvem em todos os tamanhos de modelo comuns.
Para entender o que as 44 regras de qualidade realmente verificam — e como elas se relacionam com a validação de schema e o IDS —, veja o guia completo do verificador de modelos IFC. Para o Health Score que resume a qualidade em um único número, veja o guia do Health Score de IFC. Se você precisa corrigir valores de propriedades ou GUIDs em um arquivo IFC recebido sem enviá-lo a lugar nenhum, o editor de IFC online gratuito aplica a mesma arquitetura de navegador em primeiro lugar à edição não destrutiva de propriedades.
Validação de IFC no navegador vs. na nuvem: a decisão de arquitetura que as equipes de BIM erram