Uma pergunta que raramente entra no contrato e deveria: ao final do projeto, o que exatamente você recebe? A resposta tem consequência prática por muitos anos, e a diferença entre as opções é maior do que parece.

Três níveis de entrega

O primeiro nível é o conjunto de pranchas, normalmente em PDF. É o que a obra usa e o que os órgãos analisam. É suficiente para construir e insuficiente para qualquer coisa depois: um PDF é uma imagem de decisões, não as decisões.

O segundo nível é o modelo em formato aberto de intercâmbio. O IFC é o padrão consolidado para isso, mantido por uma organização independente de fabricantes de software. Ele carrega geometria e informação — o que cada elemento é, de que material, com que propriedades, pertencente a que sistema. Pode ser aberto por diversas ferramentas, inclusive gratuitas.

O terceiro é o arquivo nativo do software de modelagem. Ele contém tudo, inclusive a lógica paramétrica que gerou os elementos, e é o que permite continuar o projeto de onde parou. Em compensação, só é plenamente útil para quem tem a mesma ferramenta e, muitas vezes, a mesma versão.

Por que o formato aberto muda a relação

O ponto central não é técnico, é de dependência. Quando a única entrega é o nativo de uma ferramenta específica, a continuidade do projeto fica atrelada a quem tem aquela ferramenta e sabe operá-la. Trocar de escritório significa, com frequência, remodelar.

Com IFC, a informação do projeto sobrevive à troca de fornecedor e à troca de software. É o mesmo raciocínio de preferir um documento em formato aberto a um formato proprietário: o conteúdo continua acessível quando o programa que o criou não estiver mais em uso.

Há uma contrapartida honesta: o IFC é um formato de intercâmbio, não de edição. Ele transporta o resultado, não a inteligência paramétrica. Editar um modelo recebido em IFC é possível, mas não é a mesma experiência de trabalhar no nativo.

Onde a ISO 19650 entra

A ISO 19650 é a norma internacional que trata da gestão da informação ao longo do ciclo de vida de empreendimentos usando BIM. Ela não define formato de arquivo nem software: define processo. Como a informação é requisitada, produzida, verificada, aprovada e entregue; quem é responsável por quê; e como o ambiente comum de dados organiza tudo isso.

O conceito de ambiente comum de dados é a contribuição mais prática. Ele estabelece um repositório único onde a informação transita por estados definidos — em desenvolvimento, compartilhada, publicada, arquivada. Cada estado tem regras sobre quem pode ver e quem pode alterar.

O problema que isso resolve é banal e universal: versão. Obras se atrasam e erram por decisões tomadas sobre arquivo desatualizado, enviado por e-mail, renomeado à mão como "final_v3_revisado". Um ambiente comum de dados existe para que a pergunta "qual é a versão válida?" tenha resposta única.

O que definir no contrato

Quatro itens resolvem quase toda a ambiguidade posterior.

Quais formatos serão entregues — pranchas, IFC, nativos — e em que momentos. Qual o uso pretendido do modelo, porque ele determina o nível de informação necessário. Como as versões serão controladas e onde os arquivos ficam disponíveis. E quem é responsável por consolidar o modelo federado quando há mais de um projetista envolvido.

Esse último ponto costuma ficar sem dono. Cada disciplina entrega o seu, ninguém junta, e a coordenação que justificava o BIM não acontece.

Uma observação sobre expectativa

Vale alinhar desde o início que modelo em IFC não é um "projeto editável universal". Ele é a informação do projeto em formato durável e independente de fornecedor. Para quem vai operar o edifício, orçar, planejar ou coordenar, é exatamente o que serve. Para quem vai dar continuidade ao desenvolvimento com outra equipe, vale negociar também os nativos — e deixar isso escrito antes, não depois.