Entenda o que é CDE BIM, como funciona um Ambiente Comum de Dados segundo a ISO 19650 e como controlar revisões, estados, aprovações, acessos, entregas e rastreabilidade.
Confira!
Um projeto pode ter todos os arquivos centralizados em uma plataforma na nuvem e ainda assim operar com informação pouco confiável. Basta imaginar uma equipe com três versões do mesmo projeto elétrico chamadas ELETRICA_FINAL.pdf, ELETRICA_FINAL_02.pdf e ELETRICA_REV3_APROVADO.pdf. Todos os documentos estão no mesmo repositório, mas ninguém consegue responder com segurança qual revisão está válida para coordenação, qual foi apenas checada internamente, qual está autorizada para execução, quem aprovou a mudança ou qual versão foi substituída.
Esse cenário mostra por que CDE BIM — Common Data Environment, ou Ambiente Comum de Dados — não deve ser entendido como sinônimo de pasta compartilhada, drive corporativo ou software de armazenamento. O CDE é parte do processo de gestão da informação: precisa sustentar identificação, estados, revisões, classificação, permissões, transições, registros de responsabilidade e critérios que permitam saber não apenas onde a informação está, mas em que condição ela pode ser usada.
A ABNT NBR ISO 19650-2 trata o CDE como infraestrutura necessária à produção colaborativa da informação. A norma estabelece que o ambiente deve permitir identificação única dos contêineres de informação, codificação acordada, atribuição de estado, revisão e classificação, transição controlada entre estados, registro de usuário e data e controle de acesso no nível do contêiner. Depois, o mesmo processo normativo conecta o CDE à verificação da qualidade, revisão, aprovação para compartilhamento, autorização, aceitação e arquivamento.
A tese deste artigo é direta: um CDE só gera valor quando transforma armazenamento em governança operacional da informação. Tecnologia é necessária, mas o resultado depende de requisitos, papéis, regras de transição, metadados, critérios de aceite e disciplina de uso.
CDE não é “onde o arquivo está”. É o ambiente que permite saber qual informação é válida, em que revisão, para qual finalidade, sob responsabilidade de quem e com qual evidência de aprovação ou aceite.
O que é CDE BIM e por que ele não é apenas uma pasta na nuvem
CDE é a sigla para Common Data Environment, expressão normalmente traduzida como Ambiente Comum de Dados. No contexto da gestão da informação BIM, o CDE funciona como o ambiente no qual contêineres de informação são produzidos, compartilhados, revisados, autorizados, aceitos e preservados de forma controlada.
O termo “contêiner de informação” é importante porque o CDE não lida apenas com modelos tridimensionais. Um contêiner pode ser um modelo BIM, uma prancha, um memorial, uma planilha, um relatório, uma especificação, um arquivo de cálculo, um registro ou outro conjunto identificável de informação que faça parte do processo de entrega.
Por isso, a discussão sobre CDE é mais ampla do que escolher uma plataforma BIM. O problema real é criar uma fonte controlada de informação para o empreendimento.
Centralização não é a mesma coisa que controle
Considere uma obra com arquitetura, estrutura, elétrica, climatização e gerenciamento. Todas as equipes recebem acesso ao mesmo armazenamento em nuvem. Cada projetista cria suas próprias pastas e publica arquivos quando entende que uma revisão está pronta.
Em poucas semanas aparecem arquivos como:
ARQ_FINAL.rvt
ARQ_FINAL_NOVO.rvt
ARQ_REV04_COORD.rvt
ESTRUTURA_OK.ifc
ELETRICA_APROVADO.dwg
ELETRICA_APROVADO_CORRIGIDO.dwg
A centralização existe. A governança, não.
A equipe ainda precisa descobrir, por interpretação humana, qual arquivo está vigente, o que significa “OK”, quem autorizou “APROVADO”, se a revisão anterior continua válida, se o documento é apenas para coordenação ou para execução e quem deve ser informado sobre uma substituição.
Esse tipo de processo funciona enquanto o projeto é pequeno, as pessoas se conhecem e a memória da equipe resolve as ambiguidades. Em empreendimentos multidisciplinares, contratos longos, múltiplas empresas ou transição de profissionais, ele se torna um risco de engenharia.
A pergunta central do CDE é: “para que esta informação pode ser usada?”
Imagine que o projetista elétrico terminou uma revisão do modelo. Antes de compartilhá-la com as demais disciplinas, sua própria equipe ainda precisa verificar nomenclatura, parâmetros obrigatórios, consistência técnica e coordenação interna.
O arquivo existe, mas ainda não deve ser utilizado por outras disciplinas.
Mais tarde, a equipe conclui a revisão interna e libera o modelo para coordenação. A informação agora pode ser utilizada como referência pelas demais equipes, mas isso não significa necessariamente que ela esteja autorizada para execução da obra.
Em outro momento, determinado conjunto de documentos pode ser autorizado como entrega formal.
Portanto, o CDE precisa permitir que a condição de uso seja distinguida da mera existência do arquivo.
A diferença parece administrativa, mas possui efeito técnico. Uma equipe de climatização que coordena dutos contra uma revisão elétrica ainda em desenvolvimento pode gerar dezenas de interferências falsas. Uma construtora que utiliza uma prancha compartilhada para coordenação como se estivesse liberada para execução pode materializar uma solução ainda não autorizada.
CDE não é um produto específico
Outro erro frequente é transformar a sigla CDE em sinônimo de uma determinada plataforma comercial.
Existem softwares capazes de suportar workflows de CDE, controle documental, modelos, revisões, aprovações, issues, permissões e histórico. Mas o conceito de CDE não pertence a um fabricante específico.
Uma solução tecnológica deve ser avaliada contra os requisitos do processo. Ela precisa sustentar o fluxo estabelecido para aquele empreendimento, com as permissões, metadados, transições, registros e integrações necessários.
Essa distinção é importante também na contratação. Escrever “usar plataforma X” não substitui a definição de como a informação será identificada, classificada, checada, compartilhada, autorizada e aceita.
A própria ABNT NBR ISO 19650-2 prevê que a parte requerente possa hospedar e gerenciar o CDE diretamente, contratar um terceiro ou transferir posteriormente determinadas funções a uma parte fornecedora líder. O requisito é funcional: o ambiente precisa atender ao processo estabelecido.
Um CDE pode ser distribuído
Outro ponto relevante é que Ambiente Comum de Dados não significa obrigatoriamente “um único sistema físico onde tudo acontece”. A ABNT NBR ISO 19650-2 contempla, na mobilização, a configuração e o teste do CDE do projeto e também de um CDE distribuído da equipe de entrega, incluindo sua conexão com o ambiente do projeto quando aplicável.
Isso corresponde melhor à realidade de muitos empreendimentos. Uma projetista pode possuir seu ambiente interno de produção; o coordenador pode usar uma plataforma específica para federação e issues; o contratante pode manter o ambiente oficial de entrega. O desafio é garantir que as fronteiras e trocas sejam controladas.
A governança precisa responder:
1. onde a informação é produzida; 2. em que momento ela deixa o ambiente interno; 3. quais verificações ocorrem antes do compartilhamento; 4. como a informação entra no CDE oficial; 5. quem pode utilizá-la e para qual finalidade; 6. como revisões e substituições são registradas; 7. como o entregável final é autorizado e aceito.
Sem essa definição, múltiplas plataformas apenas multiplicam os pontos de incerteza.
O valor do CDE está na confiança, não no volume armazenado
Um CDE com terabytes de documentos pode ser tecnicamente pior do que um ambiente menor e bem governado.
A métrica de sucesso não é a quantidade de arquivos. É a capacidade de responder perguntas como:
- qual é a revisão vigente?
- qual o estado daquela informação?
- quem é o autor responsável?
- quem checou e aprovou?
- quando ocorreu a transição de estado?
- qual classificação foi aplicada?
- quem possui acesso?
- para que uso a informação está liberada?
- o que foi substituído?
- qual evidência demonstra a aceitação?
Quando essas respostas são rastreáveis, o CDE deixa de ser repositório e passa a funcionar como infraestrutura de decisão.
O artigo sobre Gestão da Informação em BIM e ISO 19650 apresenta o processo mais amplo no qual o CDE está inserido. Aqui o foco é entender como essa infraestrutura se materializa no fluxo cotidiano do projeto.
Como funciona o fluxo de informação dentro de um CDE
Um CDE maduro não trata todos os arquivos como equivalentes. A informação atravessa estados e pontos de controle conforme amadurece.
Na prática, diferentes organizações podem adotar nomenclaturas ou implementações específicas, mas o princípio é estável: uma informação em elaboração não deve possuir a mesma condição de uso que uma informação revisada, compartilhada, autorizada ou aceita.
Trabalho em andamento: a informação ainda pertence à equipe autora
No início do fluxo, a equipe produz sua informação em ambiente de trabalho.
Imagine o modelo elétrico de uma edificação. O projetista está ajustando rotas de eletrocalhas, posição de quadros, alimentadores e espaços técnicos. Durante essa etapa, a equipe pode salvar dezenas de vezes por dia. Parte das mudanças está incompleta. Alguns objetos foram deslocados provisoriamente. Outros ainda aguardam cálculo ou decisão do coordenador.
Seria inadequado que cada salvamento se transformasse automaticamente em referência para arquitetura, estrutura e climatização.
A informação de trabalho precisa permanecer claramente identificada como em desenvolvimento até passar pelas verificações estabelecidas.
Isso não significa esconder o projeto. Significa preservar a responsabilidade do autor e impedir que informação provisória seja interpretada como referência válida.
Checagem e garantia da qualidade vêm antes do compartilhamento
A ABNT NBR ISO 19650-2 determina que cada equipe realize verificação da garantia da qualidade de seus contêineres antes da revisão para compartilhamento.
Essa distinção é importante porque “arquivo abre” não significa “arquivo está conforme”.
A checagem pode verificar, por exemplo:
- convenção de identificação;
- presença dos metadados obrigatórios;
- estrutura do contêiner;
- padrões de informação;
- requisitos de nomenclatura;
- integridade do arquivo;
- propriedades ou classificações exigidas;
- consistência com procedimentos da organização.
Parte dessas verificações pode ser automatizada. Mas a própria norma alerta, em essência, que verificação de conformidade não substitui revisão e aprovação da adequação técnica da informação.
Isso produz uma distinção útil:
checagem de conformidade responde se o contêiner segue regras estabelecidas;
revisão técnica responde se a informação é adequada ao uso pretendido.
Um modelo pode estar perfeitamente nomeado, classificado e preenchido e ainda conter uma solução de engenharia incorreta.
Aprovar para compartilhamento não é o mesmo que autorizar como entrega
Depois da checagem, a equipe revisa a informação e decide se ela pode ser compartilhada.
Considere novamente o modelo elétrico. A equipe concluiu a análise interna e entende que aquela revisão pode ser utilizada por estrutura e HVAC para coordenação. Ela então atribui o estado correspondente e libera a informação no fluxo.
A partir desse momento, outros participantes podem utilizá-la conforme a finalidade definida.
Entretanto, compartilhamento não deve ser confundido com autorização final do modelo de informação.
No processo da ABNT NBR ISO 19650-2, antes da entrega à parte requerente, as equipes submetem suas informações à parte fornecedora líder para autorização. A parte líder verifica o modelo contra MIDP, requisitos de troca, critérios de aceitação e nível necessário de informação.
Somente depois dessa autorização a informação segue para revisão e aceitação pela parte requerente.
Essa sequência cria controles diferentes:
produção da equipe → checagem → revisão → compartilhamento → coordenação → submissão → autorização → aceitação.
Um bom CDE precisa sustentar essas diferenças sem depender de nomes improvisados no arquivo.
Exemplo completo: da revisão elétrica ao aceite do contratante
Considere o contêiner ELE-Z01-M3, correspondente ao modelo elétrico de determinada zona.
A equipe elétrica produz a revisão R05 em seu ambiente de trabalho. Durante a produção, o arquivo não deve ser usado pelas outras disciplinas porque contém alterações ainda não verificadas.
Quando a equipe conclui a revisão, executa as checagens previstas. O modelo possui identificação correta, classificação, parâmetros requeridos e estrutura válida. Em seguida, o responsável técnico revisa o conteúdo e aprova a R05 para compartilhamento.
Arquitetura, estrutura e HVAC passam a utilizar a R05 na coordenação. Surgem duas questões: uma eletrocalha interfere em uma viga e um painel possui zona de manutenção insuficiente. As issues retornam à equipe elétrica.
A equipe corrige o modelo e produz R06. A nova revisão passa novamente por checagem e revisão antes do compartilhamento.
Ao atingir o marco de entrega, a parte fornecedora líder consolida os contêineres previstos no MIDP e verifica o modelo de informação. Se a entrega atende aos requisitos, ela é autorizada para submissão ao contratante.
A parte requerente então revisa o pacote contra seus requisitos e critérios de aceitação. Se aceito, aquele conjunto passa a constituir um entregável formal.
Observe que o mesmo “modelo elétrico” atravessou várias condições de uso. O CDE deve tornar essa história rastreável.
Revisão, estado e finalidade não são sinônimos
Esse ponto evita muitos erros.
Revisão indica uma evolução do contêiner.
Estado indica sua condição dentro do fluxo.
Finalidade ou adequabilidade indica para que uso ele está liberado.
Uma revisão mais nova não é automaticamente a revisão válida para qualquer finalidade.
Por exemplo, R06 pode estar em desenvolvimento enquanto R05 continua sendo a última revisão aprovada para coordenação. Se a plataforma simplesmente ordenar por data e mostrar “R06” como arquivo mais recente, um participante pode utilizar informação ainda não liberada.
O CDE precisa preservar a diferença entre mais recente e vigente para determinado uso.
Mais recente não significa automaticamente vigente. Uma nova revisão pode continuar em desenvolvimento enquanto a anterior permanece válida para coordenação, execução ou outro uso definido.
A transição precisa deixar rastro
A ABNT NBR ISO 19650-2 requer que o CDE registre o nome do usuário e a data quando revisões de contêineres transitam entre estados.
Esse registro tem valor técnico, contratual e gerencial.
Se uma obra executou determinada solução, a equipe deve ser capaz de reconstruir qual informação estava autorizada naquele momento. Se uma revisão foi substituída, deve ser possível identificar a transição. Se houve uma aprovação equivocada, o histórico precisa mostrar quem realizou a ação e quando.
Sem histórico, a plataforma pode apresentar a situação atual, mas não explica como o projeto chegou até ela.
Arquivamento não é simplesmente mover arquivos antigos para outra pasta
Ao final da fase de entrega, a ABNT NBR ISO 19650-2 determina o arquivamento do conjunto dos contêineres aceitos no CDE, considerando futura necessidade para o modelo de informação do ativo, requisitos de acesso, reúso e políticas de retenção.
Isso significa que o encerramento deve preservar contexto.
Um arquivo antigo sem metadados, estado, revisão, autoria ou vínculo com a entrega pode ter pouco valor anos depois. Já um conjunto arquivado com rastreabilidade permite auditoria, manutenção, retrofit, expansão, disputas contratuais e reconstrução da história técnica.
É aqui que o CDE começa a se conectar ao As-Built em Engenharia e à governança do ativo durante a operação.
O que um CDE precisa controlar para ser confiável
Uma plataforma pode possuir dezenas de funcionalidades e ainda assim falhar nos controles básicos. Por isso, a avaliação de um CDE deve começar pelas dimensões de governança, não pelo catálogo comercial do software.
A ABNT NBR ISO 19650-2 fornece uma base particularmente objetiva ao exigir identificador único, codificação, estado, revisão, classificação, transições registradas e acesso controlado no nível do contêiner.
A tabela abaixo traduz esses fundamentos para perguntas de engenharia.
| Dimensão | O que o CDE precisa controlar | Pergunta de auditoria |
| identificação | código único do contêiner | é possível distinguir inequivocamente este documento/modelo? |
| codificação | valores padronizados dos campos | todos usam a mesma convenção ou cada empresa inventa sua própria nomenclatura? |
| revisão | evolução do contêiner | qual revisão está vigente e quais foram substituídas? |
| estado/adequabilidade | condição de uso | esta informação pode ser usada para trabalho interno, coordenação, autorização ou execução? |
| classificação | contexto e organização da informação | a classificação permite localizar, filtrar e interpretar o conteúdo? |
| autoria | responsável pela produção | quem responde pela informação? |
| transição | mudança entre estados | quem alterou a condição de uso e quando? |
| acesso | leitura, alteração e aprovação | cada participante possui somente a autoridade necessária? |
| histórico | registro das transações | é possível reconstruir a sequência de decisões? |
| aceitação | resultado da revisão do entregável | existe evidência de que o requisito foi atendido? |
Identificação única evita que o nome do arquivo carregue toda a inteligência
Em ambientes informais, as pessoas tentam colocar no nome do arquivo tudo aquilo que o sistema não controla.
Aparecem nomes como:
ELETRICA_BLOCOA_EXECUTIVO_REV4_APROVADO_FINAL_07-08-26.pdf
O nome tenta informar disciplina, localização, fase, revisão, estado e data ao mesmo tempo.
O problema é que cada pessoa pode interpretar ou escrever de maneira diferente. Pequenas diferenças quebram filtros e automações. Uma equipe usa ELE; outra EL; outra ELETRICA. Um participante escreve REV04; outro R4.
No CDE, a identificação deve seguir convenção acordada e documentada, com campos e códigos consistentes. O nome deixa de ser narrativa livre e passa a fazer parte de um sistema de informação.
Revisão precisa ser controlada sem apagar a história
Sobrescrever o arquivo anterior e manter apenas a última cópia reduz a rastreabilidade.
Um processo de engenharia precisa saber o que mudou e em que sequência. Isso é especialmente importante quando diferentes revisões foram utilizadas em reuniões, compras, execução ou aprovação.
A gestão adequada de revisões não significa que todos tenham acesso irrestrito a todas as versões. Significa que o sistema preserva a história e apresenta a revisão correta conforme o contexto e as permissões.
Estado precisa ter significado operacional
Um rótulo só gera valor quando muda o comportamento do processo.
Se “compartilhado” e “autorizado” aparecem como dois nomes diferentes, mas qualquer usuário pode tratar ambos da mesma maneira, a governança é apenas decorativa.
Estados precisam estar associados a regras:
- quem pode promover a informação;
- quais verificações são necessárias antes da transição;
- quem pode utilizar o contêiner após a transição;
- para qual finalidade ele pode ser utilizado;
- que registro fica gravado;
- como ocorre rejeição ou retorno para correção.
Essa lógica transforma o workflow em mecanismo de controle.
Estado sem regra é apenas etiqueta. Para gerar governança, cada transição precisa ter autoridade, verificações, condição de uso e registro de auditoria claramente definidos.
Classificação permite encontrar e reutilizar informação de forma consistente
A ABNT NBR ISO 19650-2 relaciona a classificação do contêiner à estrutura definida pela ABNT NBR ISO 12006-2.
Na prática, classificação é uma camada adicional de significado. Ela ajuda a organizar informação por sistemas, elementos, tipos ou outras estruturas necessárias ao projeto e ao ativo.
A questão é semelhante à discutida no artigo sobre Classificação da Informação em BIM e NBR 15965: quando equipes usam conceitos diferentes para descrever a mesma coisa, a busca, integração e reutilização se deterioram.
Acesso não deve ser “todo mundo edita tudo”
Colaboração não significa ausência de controle.
Um projetista precisa editar os contêineres sob sua responsabilidade. Um coordenador pode precisar revisar e comentar. Uma parte fornecedora líder pode possuir autoridade para autorizar. O contratante pode precisar aceitar. Outros participantes podem ter somente leitura.
Se qualquer usuário consegue alterar um entregável aceito, o valor do aceite é reduzido.
Por isso, acesso deve ser pensado no nível necessário, considerando leitura, escrita, revisão, transição de estado, autorização e administração.
A norma também prevê que a parte requerente especifique requisitos funcionais e não funcionais quando a hospedagem, gestão ou suporte do CDE for contratada a terceiros. Isso abre espaço para critérios como disponibilidade, desempenho, segurança, interoperabilidade, retenção e continuidade, conforme o contexto do empreendimento.
Metadados são parte da engenharia da informação
Um arquivo contém conteúdo. Metadados explicam o contexto desse conteúdo.
Disciplina, zona, tipo de contêiner, revisão, estado, classificação, autoria e finalidade são exemplos de informações que permitem filtrar, controlar e automatizar o ambiente.
Imagine um projeto com 15 mil contêineres. Navegar manualmente por pastas é insuficiente. A equipe precisa consultar, por exemplo:
todos os documentos de elétrica da zona 03, em determinada revisão, autorizados para determinada finalidade e modificados após um marco específico.
Isso só é confiável se os metadados forem estruturados.
O CDE precisa controlar a informação sem criar burocracia inútil
Governança excessivamente complexa também falha.
Se cada transição exige vinte campos, cinco aprovações e tarefas que não alteram risco ou qualidade, os usuários começam a procurar atalhos. Surgem planilhas paralelas, e-mails de aprovação e compartilhamentos externos ao ambiente oficial.
O processo deve ser proporcional à complexidade, risco e necessidade do empreendimento.
Projetos pequenos podem operar com workflows mais simples. Grandes programas de capital, infraestruturas críticas, data centers, hospitais ou empreendimentos com múltiplas contratadas podem exigir controles mais sofisticados.
O princípio é manter controle suficiente para que a informação seja confiável, sem transformar o CDE em obstáculo à produção.
CDE, ISO 19650 e os demais instrumentos de gestão da informação
O CDE não funciona isoladamente. Ele é a infraestrutura operacional de um sistema maior de requisitos, responsabilidades e planos de entrega.
Na ABNT NBR ISO 19650-2, a parte requerente primeiro estabelece necessidades, requisitos de informação, marcos de entrega, padrões, métodos e procedimentos, informações de referência e recursos compartilhados. Nesse contexto, estabelece o CDE e o protocolo de informação.
Depois, as equipes respondem à contratação, desenvolvem e confirmam o BEP, detalham responsabilidades e estruturam TIDP e MIDP. Durante a mobilização, tecnologia e CDE são configurados e testados. Só então a produção colaborativa ocorre de maneira controlada.
Essa sequência explica por que simplesmente comprar software no início do projeto raramente resolve o problema.
Requisitos dizem o que precisa ser entregue; o CDE sustenta como a entrega é controlada
Um contratante pode precisar receber um modelo federado em determinado marco com propriedades específicas, documentação associada e critérios de aceitação definidos.
Esse requisito não nasce do CDE. Ele nasce da necessidade de informação da organização, do projeto ou do ativo.
O CDE entra como infraestrutura para garantir que os contêineres produzidos contra esse requisito sejam identificados, revisados, compartilhados, autorizados e aceitos de forma rastreável.
Portanto:
requisito sem CDE pode produzir entregas difíceis de controlar;
CDE sem requisito pode controlar perfeitamente informação que ninguém precisava produzir.
As duas camadas precisam estar conectadas.
O BEP organiza a estratégia de gestão da informação
O BEP BIM explica como a equipe de entrega pretende conduzir os aspectos de gestão da informação do compromisso.
No BEP podem aparecer estratégia de entrega, papéis, responsabilidades, federação, padrões, métodos, procedimentos, software, hardware e infraestrutura de TI.
O CDE é o ambiente em que parte relevante dessas regras se torna operacional.
Se o BEP diz que modelos devem passar por determinada checagem antes da federação, o workflow do CDE deve suportar essa regra. Se define uma convenção de identificação, o ambiente deve aplicá-la. Se estabelece responsáveis por aprovação, as permissões precisam refletir esses papéis.
Um BEP desconectado do CDE vira documento de intenção. Um CDE desconectado do BEP vira ferramenta sem processo.
BEP e CDE precisam conversar. O BEP define regras de gestão da informação; o CDE deve transformar essas regras em identificação, permissões, transições, entregas e evidências controláveis.
TIDP e MIDP transformam entregas em compromisso planejado
Cada equipe de tarefas desenvolve seu TIDP — Task Information Delivery Plan, indicando os contêineres que produzirá, dependências, nível necessário de informação, duração, autor responsável e datas de entrega.
A parte fornecedora líder combina esses planos no MIDP — Master Information Delivery Plan.
O CDE deve conversar com essa programação.
Imagine que o MIDP prevê entrega do modelo elétrico, memorial de cálculo e diagrama unifilar para determinada data-marco. A plataforma pode conter centenas de arquivos elétricos, mas o processo precisa reconhecer quais contêineres constituem formalmente aquela entrega.
É essa relação que permite medir completude, identificar atraso, revisar pacote e registrar aceite.
CDE e modelo federado: compartilhar não significa mesclar autoria
Na coordenação BIM, modelos de diferentes disciplinas podem ser federados para análise conjunta.
O CDE fornece os contêineres compartilhados com o estado adequado. O coordenador utiliza essas informações para compor o modelo federado e realizar análises.
Isso não significa que o coordenador passa a ser autor dos modelos disciplinares.
Se uma interferência é encontrada entre eletrocalha e estrutura, a issue retorna às equipes responsáveis. O projetista corrige sua informação na origem, passa novamente pelo workflow e publica nova revisão.
Essa lógica preserva responsabilidade e se conecta diretamente aos artigos sobre Open BIM, Arquivo IFC e Clash Detection.
CDE e LOD/LOIN: o ambiente precisa saber o que deveria estar ali
O artigo sobre LOD BIM e LOIN mostrou que qualidade não significa produzir o máximo de detalhe possível.
Da mesma forma, o CDE não deve premiar volume de informação.
Uma entrega precisa ser avaliada contra o nível necessário de informação. A ABNT NBR ISO 19650-2 exige que critérios de aceitação considerem o nível necessário para cada requisito.
Isso muda a auditoria. Não basta perguntar “o arquivo está no CDE?”. É preciso perguntar:
o contêiner entregue contém a informação que deveria conter para este marco e esta finalidade?
CDE, PIM, AIM e transição para operação
Durante a fase de entrega, o modelo de informação do projeto — PIM — é desenvolvido progressivamente. Ao encerramento, informações relevantes podem alimentar o modelo de informação do ativo — AIM — para suportar operação e manutenção.
O CDE precisa preservar essa continuidade.
A ABNT NBR ISO 19650-2 orienta que, após a aceitação do modelo de informação do projeto concluído, os contêineres sejam arquivados considerando aquilo que será necessário como parte do AIM, acesso futuro, reúso e retenção.
Isso faz do encerramento um problema de governança, não apenas de backup.
Um As-Built sem histórico de aprovação, documentos de fornecedores sem associação ao ativo, modelos sem revisão válida ou registros espalhados por e-mail reduzem a qualidade da transição.
Esse ponto cria uma ponte direta entre CDE, As-Built de Engenharia e gestão documental ao longo do ciclo de vida.
CDE e ENGiOS: governança além do projeto
O CDE é particularmente importante durante o fluxo de produção e entrega da informação de um empreendimento. Mas organizações de engenharia possuem desafios mais amplos: contratos, documentos técnicos, revisões, evidências, aceite, As-Built, ativos, histórico de projetos e conhecimento institucional.
Por isso, o CDE pode ser entendido como uma camada de uma arquitetura maior de governança técnica digital.
A solução Ambiente Comum de Dados e Gestão da Informação BIM estrutura especificamente requisitos, processos, responsabilidades e tecnologia para o CDE. Já o ENGiOS™ amplia a discussão para gestão técnica, documentação e governança de engenharia.
A conexão não deve ser feita por promessa genérica de software. O critério continua sendo o mesmo: cada camada tecnológica precisa atender aos requisitos e processos que a organização realmente pretende governar.
Como implementar, auditar e evitar os erros mais comuns em um CDE
Implantar um CDE não começa criando pastas. Começa definindo o processo que aquelas pastas, metadados, permissões e workflows deverão suportar.
A sequência mais defensável é:
necessidade → requisitos → papéis → padrão de informação → contêineres → metadados → estados → transições → permissões → tecnologia → testes → mobilização → produção → auditoria.
Essa ordem reduz o risco de adaptar a engenharia às limitações de uma ferramenta escolhida cedo demais.
1. Defina o objetivo do ambiente
Antes de configurar qualquer plataforma, determine o que o CDE precisa resolver.
O objetivo pode incluir coordenação multidisciplinar, entrega documental, gestão de modelos, aprovação técnica, controle de revisão, recebimento de contratadas, transição para operação ou combinação desses usos.
Um ambiente voltado apenas à coordenação de projeto terá requisitos diferentes de um CDE destinado a um programa de capital com dezenas de contratos e transição para gestão de ativos.
A pergunta não é “qual software vamos usar?”. A pergunta inicial é:
quais decisões e entregas precisam ser suportadas pela informação?
2. Defina responsáveis e autoridade
Todo workflow precisa de papéis claros.
Quem administra o CDE?
Quem define padrões?
Quem cria usuários?
Quem pode alterar metadados?
Quem aprova para compartilhamento?
Quem autoriza entregas?
Quem aceita em nome do contratante?
Quem trata rejeições?
Quem preserva o arquivo no encerramento?
Essas funções podem ser distribuídas entre contratante, gerenciadora, projetistas, construtora e terceiros. O importante é evitar autoridade implícita.
3. Estruture identificação, classificação e metadados antes de migrar arquivos
Criar milhares de documentos antes de fechar a taxonomia gera retrabalho.
A equipe deve definir convenções e códigos que serão usados no ambiente. Isso inclui campos suficientes para distinguir os contêineres e permitir filtros relevantes.
O princípio é encontrar equilíbrio. Poucos metadados geram ambiguidade; metadados demais geram baixa adesão e preenchimento inconsistente.
Uma pergunta prática ajuda:
quais filtros serão necessários para localizar, revisar, entregar e auditar a informação?
Se ninguém usa determinado campo para decisão, automação, busca ou controle, talvez ele não deva ser obrigatório.
4. Modele os estados e transições
O workflow precisa ser desenhado antes de ser automatizado.
Para cada transição, defina:
- estado de origem;
- estado de destino;
- responsável pela ação;
- verificações prévias;
- campos obrigatórios;
- condição de uso resultante;
- notificação necessária;
- possibilidade de rejeição;
- registro de auditoria.
Isso transforma o fluxo em um processo verificável.
Um exemplo:
| Transição | Responsável | Verificação mínima | Resultado |
| produção → pronto para revisão | autor | campos e arquivo completos | contêiner disponível ao revisor interno |
| revisão → compartilhamento | responsável da equipe | conformidade + adequação técnica | referência disponível à coordenação |
| compartilhado → submissão | parte fornecedora | issues tratadas e marco atendido | entrega pronta para autorização |
| submissão → autorizado | parte fornecedora líder | MIDP + EIR + critérios de aceite | pacote autorizado ao contratante |
| autorizado → aceito | parte requerente | requisitos e critérios de aceitação | entregável formalmente aceito |
A tabela é ilustrativa. O workflow real precisa refletir o contrato e a governança definida para cada empreendimento.
5. Configure permissões coerentes com a responsabilidade
Uma plataforma pode ter workflow perfeito no papel e falhar porque os usuários possuem privilégios excessivos.
Se um autor consegue aprovar o próprio documento quando deveria existir segregação de função, o controle perde força. Se qualquer participante pode excluir evidências ou alterar informação já aceita, a rastreabilidade é comprometida.
Permissões precisam ser testadas por cenário, não apenas conferidas em uma matriz.
Crie usuários de teste com papéis diferentes e simule criação, edição, leitura, compartilhamento, rejeição, autorização, aceitação, substituição e arquivamento.
6. Teste o CDE antes da produção real
A mobilização é um ponto explícito da ABNT NBR ISO 19650-2. A parte fornecedora líder deve configurar e testar software, hardware e infraestrutura de TI, o CDE do projeto, eventuais ambientes distribuídos, trocas entre equipes e entrega à parte requerente.
Isso significa que o primeiro marco crítico não deve ser o primeiro teste real do processo.
Um piloto pode utilizar um pacote pequeno de documentos e modelos para verificar convenção de identificação, permissões, notificações, revisão, rejeição, transições, download e visualização, interoperabilidade, auditoria, relatórios, comportamento de revisão substituída e consulta ao histórico.
Problemas encontrados nessa etapa custam muito menos do que problemas descobertos durante uma entrega contratual.
7. Treine o processo, não apenas a interface
Ensinar “onde clicar” é insuficiente.
O usuário precisa compreender por que não deve compartilhar informação em desenvolvimento, o que significa determinado estado, quando uma revisão substitui outra e quais consequências existem ao autorizar um entregável.
Sem esse entendimento, a equipe usa a plataforma como drive sofisticado.
Treinamento precisa incluir cenários de engenharia. Por exemplo:
“Você é o projetista elétrico. Terminou a R04, mas a verificação encontrou propriedades obrigatórias ausentes. O que deve acontecer?”
“Você é o coordenador. Existe R05 em elaboração e R04 compartilhada. Qual pode entrar na federação?”
“Você é a parte requerente. O pacote foi autorizado pela líder, mas falta evidência de um requisito. Você aceita ou rejeita?”
Esse tipo de exercício cria entendimento operacional.
8. Audite o comportamento real do ambiente
Um CDE pode estar bem configurado e ser mal utilizado.
A auditoria deve observar não apenas a configuração, mas o comportamento real dos usuários.
Indicadores úteis incluem contêineres sem identificação válida, revisões duplicadas, estados incompatíveis com a fase, entregas sem responsável, rejeições sem justificativa, aprovações fora do workflow, arquivos enviados por e-mail em paralelo, permissões excessivas, itens compartilhados sem checagem, entregáveis vencidos no MIDP e informação aceita sem evidência de critérios.
A auditoria também deve verificar se a equipe criou um “CDE sombra”: pastas externas, grupos de mensagem, links públicos ou planilhas paralelas que passaram a ser a fonte real da informação.
Os erros mais comuns em projetos
A tabela abaixo resume sinais de que o ambiente existe tecnicamente, mas a governança ainda é fraca.
| Sintoma | Risco | Correção de processo |
| arquivos chamados “final” | condição de uso ambígua | controlar revisão e estado por metadados/workflow |
| todos editam tudo | perda de responsabilidade | permissões por papel e contêiner |
| revisão nova substitui a antiga sem histórico | impossibilidade de auditoria | preservar versões e transições |
| compartilhamento por e-mail | fonte paralela de verdade | obrigar troca formal pelo ambiente definido |
| aprovação em mensagens informais | aceite sem evidência | registrar decisão no workflow |
| modelo mais recente entra automaticamente na federação | uso de informação não liberada | filtrar por estado adequado |
| metadados opcionais preenchidos de formas diferentes | busca e automação frágeis | códigos controlados e validação |
| software escolhido antes do processo | workflow adaptado à ferramenta | definir requisitos funcionais antes da seleção |
| centenas de campos obrigatórios | baixa adesão e dados fictícios | aplicar proporcionalidade e LOIN |
| encerramento tratado como backup | perda de contexto para operação | arquivar com revisão, estado, acesso e retenção definidos |
Como saber se um CDE está maduro
Um CDE maduro permite que alguém que não participou das conversas diárias do projeto compreenda o estado da informação.
Essa é uma boa prova.
Se um novo coordenador entra na equipe e precisa telefonar para três pessoas para descobrir qual desenho usar, o ambiente ainda depende de memória tácita.
Se ele consegue identificar a revisão vigente, condição de uso, autor, histórico, critérios e documentos relacionados diretamente no sistema, a informação está mais institucionalizada.
A maturidade também aparece quando uma decisão pode ser auditada depois de meses ou anos sem reconstrução manual de e-mails.
Na estruturação de Ambiente Comum de Dados e Gestão da Informação BIM, a A3A conecta requisitos, responsabilidades, metadados, workflows, critérios de aceite, mobilização e auditoria do ambiente.
CDE como instrumento de contratação e aceite
O tema possui implicação comercial importante.
Em contratos de engenharia, definir “entrega via CDE” é pouco. O contrato ou seus documentos associados precisam estabelecer, conforme aplicável, estrutura de contêineres, convenção de identificação, estados e finalidades, revisões, responsabilidades, requisitos de informação, critérios de aceitação, datas-marco, formatos, regras de acesso, propriedade intelectual, licenciamento, retenção e entrega final.
Isso transforma o CDE em mecanismo de medição e aceite.
Uma entrega deixa de ser “mandou o arquivo” e passa a ser “entregou o conjunto previsto, na revisão correta, com estado adequado, informação requerida e evidência de aceitação”.
Essa abordagem é particularmente relevante em Owner’s Engineering, gerenciamento, contratos EPC/EPCM, projetos executivos, obras multidisciplinares e recebimento técnico.
Quando contratar apoio especializado para estruturar o CDE
O apoio externo tende a gerar mais valor quando o empreendimento possui múltiplas contratadas, grande volume documental, requisitos BIM formais, transição para operação, contratos com marcos complexos ou histórico de falhas de revisão e aprovação.
Nesses cenários, o desafio não é apenas configurar uma plataforma. É transformar requisitos de engenharia em processo operacional, matriz de responsabilidades, nomenclatura, metadados, workflow, critérios de aceite, plano de mobilização, treinamento e auditoria.
A A3A estrutura essa camada por meio da solução de Ambiente Comum de Dados e Gestão da Informação BIM, conectando o CDE à gestão da informação, coordenação, documentação técnica e governança do empreendimento.
Conclusão
CDE BIM não é apenas um lugar comum para armazenar arquivos. É uma infraestrutura de gestão da informação capaz de distinguir aquilo que está em desenvolvimento daquilo que pode ser compartilhado, autorizado, aceito e preservado.
A ABNT NBR ISO 19650-2 fornece requisitos objetivos para essa infraestrutura: identificação única, codificação acordada, estado, revisão, classificação, transição entre estados, registro de usuário e data e acesso controlado por contêiner. O processo normativo ainda conecta o ambiente à checagem da qualidade, revisão, autorização, aceitação e arquivamento.
O resultado prático é uma mudança importante de pergunta. Em vez de “onde está o arquivo?”, a equipe passa a perguntar:
qual informação é esta, quem responde por ela, em que revisão está, para qual finalidade pode ser utilizada, quem autorizou seu estado e qual evidência demonstra que o requisito foi atendido?
Essa é a diferença entre armazenamento e governança.
A tecnologia continua essencial, mas não é suficiente. Um CDE maduro exige requisitos claros, papéis definidos, metadados consistentes, estados com significado operacional, permissões coerentes, testes de mobilização, treinamento e auditoria contínua.
Quando essas camadas funcionam em conjunto, o ambiente reduz ambiguidades, melhora coordenação, fortalece rastreabilidade contratual e cria uma base mais confiável para projeto, construção, recebimento, As-Built e operação.
Por isso, a decisão mais importante em uma implantação de CDE não é escolher primeiro a plataforma. É definir qual fluxo de informação precisa ser governado e quais evidências permitirão confiar nele.
Referências técnicas
[1] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19650-1:2018 — Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM) — Information management using building information modelling — Part 1: Concepts and principles. Geneva: ISO, 2018.
[2] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19650-2:2018 — Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM) — Information management using building information modelling — Part 2: Delivery phase of the assets. Geneva: ISO, 2018.
Perguntas frequentes
CDE BIM é o Ambiente Comum de Dados utilizado para controlar a produção, compartilhamento, revisão, autorização, aceitação e preservação de informações de um empreendimento. Ele não é apenas armazenamento: precisa sustentar estados, revisões, identificação, classificação, acessos e rastreabilidade.
CDE significa Common Data Environment, expressão normalmente traduzida como Ambiente Comum de Dados. No contexto da série ISO 19650, é parte essencial da infraestrutura de gestão da informação.
Não. Plataformas comerciais podem implementar workflows e funcionalidades de CDE, mas CDE é um conceito e processo de gestão da informação. A ferramenta deve ser selecionada e configurada de acordo com os requisitos do empreendimento.
Uma pasta compartilhada centraliza arquivos. Um CDE deve também controlar identificação, revisão, estado, classificação, permissões, transições, histórico e condição de uso da informação. Centralização sem esses controles não garante governança.
A ABNT NBR ISO 19650-2 estabelece, entre outros pontos, identificador único do contêiner, codificação acordada, estado, revisão, classificação, transição entre estados, registro de usuário e data e acesso controlado no nível do contêiner.
Revisão registra a evolução do contêiner. Estado representa sua condição dentro do processo e influencia para que finalidade a informação pode ser utilizada. Uma revisão mais nova pode ainda estar em desenvolvimento enquanto a revisão anterior continua válida para coordenação.
A ABNT NBR ISO 19650-2 recomenda que o CDE do projeto esteja em funcionamento antes do convite à proposta, permitindo compartilhar informação com organizações proponentes de forma controlada. Na mobilização, o ambiente e as trocas devem ser configurados e testados.
O BEP organiza a estratégia de gestão da informação da equipe. TIDP e MIDP planejam quais contêineres serão produzidos e quando. O CDE sustenta operacionalmente a produção, compartilhamento, revisão, autorização, entrega e aceite dessas informações.
Sim. A ABNT NBR ISO 19650-2 contempla a possibilidade de CDE distribuído da equipe de entrega conectado ao CDE do projeto. O ponto crítico é controlar as fronteiras, responsabilidades, estados e trocas entre os ambientes.
Um sinal de maturidade é conseguir identificar sem depender de memória ou conversas paralelas qual é a revisão vigente, seu estado, autor, finalidade, histórico, aprovação e critério de aceite. O ambiente também deve evitar fontes paralelas de informação fora do workflow oficial.
Materiais técnicos complementares
Soluções
- Ambiente Comum de Dados e Gestão da Informação BIM
- Gestão de Requisitos, Evidências e Critérios de Aceite
- Gestão Eletrônica de Documentos Técnicos e Controle de Revisões
- ENGiOS™
Serviços
- Compatibilização e Integração de Projetos
- Projeto Executivo de Engenharia
- Gerenciamento / Owner’s Engineering
Guias técnicos
- Guia Completo de BIM e Compatibilização de Projetos
- Guia Completo de Compatibilização de Projetos
- Guia Completo sobre Gerenciamento de Projetos
Whitepapers
Artigos técnicos
- Gestão da Informação em BIM e ISO 19650
- BEP BIM
- Arquivo IFC no BIM
- Open BIM
- LOD BIM
- Coordenação de Projetos de Engenharia
eBook
