Entrega BIM sem evidência auditável: cadê o relatório assinado?

Um ano depois da entrega do projeto executivo, o cliente abre uma disputa contratual. Afirma que a entrega estava incompleta — propriedades faltando, classificações ausentes, materiais não declarados. Pede ao BIM Manager que estava no projeto para apresentar a evidência do que foi verificado antes do aceite formal.

O BIM Manager procura no CDE. Encontra o IFC arquivado como "Published". Encontra atas de reunião que dizem "modelo revisado, aprovado". Encontra emails trocados na fase de review. Não encontra relatório formal de conformidade — porque não foi gerado. A verificação foi feita em reuniões, na cabeça de quem revisou, sem output documental auditável. Um ano depois, é palavra contra palavra: cliente diz que faltava, BIM Manager diz que estava lá.

A única forma de resolver é abrir o IFC arquivado, rodar a verificação agora, e ver se as propriedades estão lá. Mas isso prova só o estado atual do arquivo — não prova que a verificação foi feita antes do aceite. E se o arquivo tiver sido alterado desde então (mesmo por engano, mesmo em novo commit sobre o mesmo nome), a evidência já não vale.

Esse é o problema estrutural: verificação BIM sem produção de evidência arquivável. A verificação existiu — mas não deixou rastro auditável. O CDE guardou o arquivo, não guardou a decisão.

A resposta canônica pra esse problema é a rotina de auditoria automatizada por IDS com relatório versionado e publicado no CDE como parte integrante do estado de informação aceito. Cada rodada de verificação gera três artefatos que juntos formam o pacote contratual:

• O arquivo .ids que foi executado (com hash SHA e versão declarada) — prova quais requisitos exatos foram verificados.
• O relatório de auditoria gerado pela ferramenta oficial (IDS-Audit-tool da buildingSMART em C# .NET, ou implementadores como BlenderBIM Ifctester, ACCA usBIM.IDS, Solibri) — prova o resultado quantitativo (quantos objetos foram avaliados, quantos passaram, quantos falharam, em quais specifications).
• O IFC verificado (com hash SHA e versão declarada) — prova qual estado do modelo foi avaliado, sem ambiguidade.

Os três artefatos são arquivados juntos no CDE, sob o estado de informação "Published", com timestamp e assinatura digital do autor da rodada de verificação. Isso é evidência contratual arbitrável: qualquer disputa futura pode ser resolvida com rodada de auditoria sobre o mesmo .ids no mesmo IFC, produzindo o mesmo relatório — replicabilidade determinística, característica que auditor, perito judicial ou advogado reconhecem como prova formal.

1. 1

   Cliente questiona conformidade de entrega já aceita e o BIM Manager não consegue produzir report em menos de 15 minutos

2. 2

   CDE guarda o IFC 'Published' mas não guarda qual verificação foi feita, com que critério, com que resultado

3. 3

   Atas de reunião de review dizem 'modelo aprovado' sem lista de specifications verificadas nem métrica objetiva de conformidade

4. 4

   Rodadas de review dependem de gestor experiente que 'sabe olhar' — ninguém consegue reproduzir a verificação sem esse gestor específico

5. 5

   Ferramentas de checagem semântica (Solibri, BIMcollab, ACC) são usadas em modo interativo, sem exportar report versionado pro CDE

6. 6

   Ao trocar de gestor da informação no meio do projeto, o novo gestor perde 2 semanas 'entendendo o histórico' porque nenhuma decisão anterior foi documentada em formato auditável

7. 7

   Auditor externo (banco, seguradora, corpo de bombeiros, órgão público) pede 'evidência de verificação' e recebe atas de reunião — que não são aceitas como evidência técnica formal

8. 8

   Disputa contratual ativa termina em 'palavra contra palavra' porque não há report neutro pra resolver quem tem razão

9. 9

   Perícia judicial pede replicar a verificação e não é possível porque o modelo mudou desde o aceite e o `.ids` original não foi arquivado

Causa 1 · Verificação BIM tratada como conversa, não como procedimento. O modo default de review é reunião. Gestor abre o modelo, olha na tela, diz "ok" ou "corrige isso e reenvia". Não gera output documental. Não gera arquivo. A qualidade do review depende inteiramente da experiência subjetiva do gestor — não é auditável nem replicável nem transferível.

Causa 2 · Ferramentas de checagem semântica usadas em modo interativo. Solibri, BIMcollab, Navisworks, ACC — todas geram reports quando o usuário explicitamente exporta. Em muitas operações essa etapa é pulada. O usuário roda a checagem, vê o resultado na tela, resolve o que precisa resolver, fecha a ferramenta. Nenhum artefato persistente é gerado. Auditoria futura fica dependente da memória e da tela do momento.

Causa 3 · CDE trata IFC como arquivo, não como estado de informação verificado. Estados de informação (WIP → Shared → Published → Archive) previstos na ISO 19650-1 são mecanismos formais de transição de responsabilidade com pacote associado. Muitas operações usam CDE como Dropbox — sobem arquivo, marcam "Published", pronto. Nenhum pacote de evidência é exigido pra transitar o estado. Nenhum requisito de "quais reports acompanham essa versão" está formalizado.

Causa 4 · Fluxo de aprovação sem gate técnico. O aprovador contratual é frequentemente o cliente ou o gerente de projeto — não o gestor da informação técnica. Aprovação vira ato comercial ("liberar próxima parcela") sem passar por gate técnico que exija report de auditoria. Sem gate técnico obrigatório, ninguém gera o report.

Causa 5 · Ausência de padrão institucional pra .ids + report como artefato contratual. Empresas maduras têm template contratual que exige entrega de IFC acompanhado de report de conformidade. Muitas operações brasileiras ainda estão na fase de discutir IDS como conceito — não têm ainda tratado o report como parte integrante da entrega. Como não é esperado, não é produzido. Como não é produzido, não é auditável.

• Disputa contratual perdida por falta de evidência. Cliente afirma que faltava; empresa afirma que estava. Sem report, o árbitro (perito ou juiz) tem que rodar auditoria retroativa sobre arquivo que pode ter sido alterado — inconclusivo por definição. Custo direto: pagamento de aditivo indevido, retrabalho não recuperável, honorário jurídico.
• Perícia judicial em desvantagem estrutural. Em disputa técnica, a parte que apresenta report versionado + .ids original + IFC hasheado tem vantagem probatória enorme. A parte que apresenta ata de reunião perde por falta de rigor técnico.
• Handover para operação inutilizável. Cliente que assume o ativo precisa validar o modelo antes de integrar no CMMS/CAFM. Sem report histórico do que foi verificado, ele tem que refazer toda a verificação do zero — custo que pode ser alegado como falha de entrega original.
• Falha em auditoria de compliance. Órgãos públicos, bancos de fomento, seguradoras, certificadoras (LEED, BREEAM) exigem cada vez mais evidência formal. Ata de reunião não vale. Report versionado em formato aberto (HTML/XML/BCF/JSON) vale.
• Perda de aprendizado institucional. Sem histórico auditável de reports, a empresa não consegue medir sua própria evolução — qual disciplina tem mais divergência, qual specification quebra mais, quais problemas se repetem entre projetos. Melhoria contínua fica impossível.

Gravidade 3-4. Ausência de evidência auditável é problema latente: não causa dano imediato ao projeto, mas cria fragilidade estrutural que pode explodir a qualquer momento — na primeira disputa contratual, na primeira auditoria externa, na primeira transição de gestor. Gravidade 3 quando o projeto ainda está em fase inicial e há tempo pra formalizar rotina. Gravidade 4 quando o projeto já teve vários marcos aceitos sem report, e um deles é questionado.

Entrega BIM está em conformidade auditável quando:

• Cada marco de entrega gera um pacote de três artefatos versionados e assinados: o .ids executado, o report do IDS-Audit-tool (ou implementador equivalente conforme XSD normativo), o IFC verificado — todos com hash SHA declarado, publicados juntos no CDE sob o estado de informação "Published" que foi aceito.
• Report gerado por ferramenta oficial ou conforme — IDS-Audit-tool da buildingSMART (C# .NET, MIT License), BlenderBIM Ifctester, ACCA usBIM.IDS, Solibri IDS module, entre outros implementadores conformes. Report em formato aberto (HTML, XML, JSON, BCF) que qualquer terceiro consegue abrir sem software proprietário específico.
• Transição de estado no CDE bloqueada sem pacote de evidência. Estado "WIP" → "Shared" só é aceito se o autor anexa report do próprio pré-aceite. Estado "Shared" → "Published" só é aceito se o gestor da informação anexa report da rodada de aceitação formal. Fluxo do CDE torna a evidência obrigatória.
• Meta de conformidade em regra IDS: zero violações não-justificadas — cada objeto reprovado tem justificativa técnica registrada (exceção contratual, waiver aprovado, correção prevista em próximo marco). Regra formal não admite tolerância estatística; o critério ISO/buildingSMART ancorado no diagnóstico é binário.
• Replicabilidade determinística garantida. Qualquer profissional externo (perito, auditor, cliente futuro) consegue reexecutar o .ids original sobre o IFC arquivado e obter o mesmo report — sem ambiguidade, sem dependência de qual software foi usado (desde que seja implementador conforme).

Curto prazo (semanas 1-4):

• Definir e publicar procedimento institucional de auditoria BIM: quais artefatos formam o pacote de evidência, onde arquivar, quem assina, qual timestamp. Templar como norma interna vinculante.
• Rodar auditoria retroativa nos últimos 3 marcos aceitos. Gerar reports agora, mesmo que fora do momento contratual — fecha o gap probatório imediato e serve como baseline.
• Criar estrutura de pastas no CDE por marco de entrega, contendo: <marco>/ids/, <marco>/report/, <marco>/ifc/, <marco>/ata/. Padronizar nomenclatura de arquivo com versão e hash.

Médio prazo (meses 2-4):

• Integrar geração de report ao fluxo de aprovação do CDE — via webhook, script CI/CD ou plugin do CDE. Objetivo: transição de estado só é possível quando report está publicado.
• Migrar equipe do modo "review interativo" pro modo "audit automatizado": review humano continua importante pra qualidade técnica, mas resultado tem que ser cristalizado em report da ferramenta oficial, não em ata.
• Estabelecer política de retenção: reports arquivados por prazo contratual + prazo legal (5 anos mínimo). Backup redundante.
• Treinar time em leitura de report — tanto gestores quanto projetistas devem saber interpretar HTML/XML/JSON do report antes de submeter novo marco.

Evidência auditável é resultado de disciplina institucional sistemática — não de esforço individual. Prevenção:

• Cláusula contratual obrigando pacote de evidência. EIR e BEP devem exigir explicitamente que cada entrega BIM seja acompanhada de .ids executado + report de auditoria + IFC hasheado. Sem cláusula, a evidência é opcional; com cláusula, é entregável contratual.
• Gate técnico no CDE. Transição de estado de informação vinculada à presença de report versionado. Automação: se report não está anexado, transição é rejeitada. Não depende de disciplina humana no momento.
• Rotina de auditoria interna trimestral independente do fluxo do projeto. Amostragem aleatória de marcos aceitos, replicação da verificação por profissional que não estava na rodada original, comparação de resultados. Cria cultura de "sempre auditável", não "auditável quando alguém pergunta".
• Padrão institucional de retenção e formato. Report sempre em formato aberto (HTML/XML/JSON/BCF). Nunca PDF de screenshot. Nunca imagem. Nunca depender de software proprietário pra abrir. Padrão institucional documentado e revisado anualmente.

• IDS-Audit-tool v1.0.0 (out/2024)Ferramenta oficial buildingSMART pra auditoria de arquivos .ids conforme XSD normativo. Linguagem C# .NET, MIT License, disponibilizada como CLI executável, biblioteca reutilizável e via documentação técnica separada. Repositório: github.com/buildingSMART/IDS-Audit-tool. Verifica conformidade do próprio .ids; para verificar IFC contra IDS usar implementadores conformes (Ifctester, usBIM.IDS, Solibri).
• IDS Schema/ids.xsdXSD normativo publicado em standards.buildingsmart.org/IDS/1.0/ids.xsd. Todo software conforme deve validar .ids contra este schema antes de execução. Report gerado por implementador conforme é determinístico dado o mesmo .ids e o mesmo IFC.
• ABNT NBR ISO 19650-2:2022Organização e digitalização das informações — Parte 2: Fase de entrega dos ativos. Define estados de informação (Work in Progress, Shared, Published, Archive) e responsabilidades de transição. Estado Published só é atingido após aceitação formal — que exige evidência arbitrável.
• ABNT NBR ISO 19650-1:2022Conceitos e princípios. Estabelece requisitos de troca de informação (EIR) como base contratual e o Common Data Environment (CDE) como ambiente único de gestão do ciclo de vida da informação, incluindo pacote de evidência associado a cada estado.
• buildingSMART BCFFormato aberto pra comunicar issues técnicos com contexto de câmera e objeto. Pode ser gerado como parte do relatório de auditoria pra rastreabilidade individual de cada não-conformidade — cada issue BCF é rastreável ao GlobalId do objeto, ao momento da rodada e ao autor.
• ISO 12911:2023Framework for the specification of information management according to ISO 19650. Ancora a governança da informação em processos formais e artefatos rastreáveis — base normativa pra procedimentos de auditoria e evidência.