A informação morre na passagem projeto para obra para operação

A informação morre na passagem projeto para obra para operação.

A equipe de projeto produziu modelos, propriedades, documentos. Centenas de horas de trabalho. Quando o ativo transiciona para a fase operacional, metade dessa informação se perde: formatos incompatíveis, dados não solicitados pela operação, handover improvisado, ninguém do lado da operação pronto para receber.

A ABNT NBR ISO 19650-3:2025 trata exatamente essa costura. A §4.2 é o coração do problema: quando a parte requerente da fase de entrega difere da parte requerente da operação, ambas devem estabelecer e comunicar responsabilidades. Deve haver consistência entre o padrão de informação de ativos (operação) e o padrão de informação do projeto (entrega), e entre os respectivos métodos e procedimentos de produção. Sem essa costura, o que a entrega produz não atende ao que a operação precisa.

A §5.1.5 exige que a parte requerente identifique os eventos-gatilho previsíveis para os quais a informação deve ser gerenciada na operação. A §5.7 e §5.8 tratam da aceitação e agregação ao AIM (modelo de informação do ativo) — o passo final que consolida a informação aceita no repositório operacional.

Na prática brasileira, a transição é trauma. O projeto entrega "as-built" em PDF ou modelo congelado, e a operação recebe sem saber o que fazer com aquilo. Não houve AIR na origem, não houve consistência de padrões, não houve planejamento de eventos-gatilho. A informação morre na fronteira.

Esta página trata dessa perda. A irmã "Onde o BIM entra no ciclo de vida, do projeto à operação?" cobre o conceito de ciclo de vida. Aqui é a dor operacional: a informação que deveria atravessar a fronteira e não atravessa.

1. 1

   As-built entregue em PDF sem dados estruturados · o handover é um pacote de PDFs e pranchas estáticas. A informação alfanumérica que estava no modelo se perde na conversão. A operação recebe imagem, não dado.

2. 2

   Operação não participou da definição de requisitos · facilities, manutenção e gestão de ativos não definiram AIR na origem. O modelo foi produzido para o projeto, não para quem vai operar.

3. 3

   Padrão de informação do projeto diverge do padrão da operação · o projeto usou classificação OmniClass; a operação usa sistema próprio de gestão de ativos. Ninguém costurou a consistência (§4.2 da 19650-3).

4. 4

   Handover é evento pontual, não processo · a transição acontece em uma reunião no final do projeto. A norma prevê processo com eventos-gatilho identificados antecipadamente (§5.1.5).

5. 5

   AIM não existe ou está vazio · o modelo de informação do ativo (AIM) — repositório operacional que a §5.1.11 da 19650-3 exige — não foi estabelecido. A informação aceita não tem onde ser agregada.

6. 6

   Ninguém do lado da operação sabe receber · a §5.1.1 da 19650-3 exige que a parte requerente nomeie responsável pela gestão da informação na operação. Sem esse papel, o handover não tem quem receba formalmente.

1. 1

   Parte requerente da entrega difere da parte requerente da operação · a §4.2 da 19650-3 identifica esse cenário como crítico. Quem contratou o projeto não é quem vai operar o ativo — e as duas partes não conversaram sobre requisitos.

2. 2

   AIR não foi definido na origem · sem AIR (requisitos de informação do ativo), a equipe de entrega não sabe o que a operação vai precisar. Produz o que o projeto pede, não o que o ativo precisa.

3. 3

   Padrões de entrega e operação não foram costurados · a §4.2 da 19650-3 exige consistência entre padrão de informação do projeto e padrão de informação do ativo. Sem essa costura, os dados produzidos não servem à operação.

4. 4

   Eventos-gatilho não foram mapeados · a §5.1.5 da 19650-3 exige identificar eventos previsíveis para os quais a informação operacional deve ser gerenciada. Sem esse mapeamento, a transição é reativa.

5. 5

   Handover tratado como fim do projeto, não como início da operação · a equipe de projeto vê o handover como encerramento. A norma vê como transferência de informação que precisa ser aceita, validada e agregada ao AIM.

6. 6

   Parte 3 da norma não é lida · a ABNT NBR ISO 19650-3:2025 foi publicada recentemente. Muitas equipes brasileiras ainda não incorporaram a fase operacional ao seu fluxo de gestão da informação.

1. 1

   Investimento em BIM sem retorno operacional · centenas de horas de modelagem que não servem à operação. O ativo digital morre no handover — 80% do custo do ciclo de vida está na operação, e a informação não chega lá.

2. 2

   Operação sem dados para manutenção preventiva · sem propriedades operacionais (fabricante, modelo, garantia, intervalo de manutenção), facilities opera no escuro. Manutenção preventiva vira corretiva.

3. 3

   Reconstrução retroativa da informação · a operação precisa de dados que o projeto tinha mas não entregou. Reconstruir retroativamente custa mais do que teria custado pedir na origem.

4. 4

   AIM fragmentado ou inexistente · sem AIM formalmente estabelecido (§5.1.11 da 19650-3), a informação do ativo fica dispersa em sistemas, planilhas e pastas. Governança operacional é impossível.

5. 5

   Disputa sobre completude do handover · a operação alega que o handover foi incompleto; o projeto alega que entregou tudo. Sem AIR e critérios de aceitação, a disputa é sobre expectativas não declaradas.

6. 6

   Gêmeo digital inviável · qualquer ambição de gêmeo digital depende de informação estruturada na operação. Se o handover perdeu a informação, o gêmeo digital é inviável desde a base.

Todos os testes podem ser executados pelo gestor da informação ou pelo gestor de ativos. Baseiam-se na ABNT NBR ISO 19650-3:2025 (fase operacional) e na ABNT NBR ISO 19650-1:2022 (conceitos).

O problema é considerado resolvido quando todos os itens abaixo forem verdadeiros, em aderência à ABNT NBR ISO 19650-3:2025 e ABNT NBR ISO 19650-1:2022:

Curto prazo (30-45 dias — planejar a transição):

1. Definir AIR com participação da operação. Mapear o que facilities, manutenção e gestão de ativos precisam — antes de o projeto avançar. AIR retroativo é melhor que nenhum.

2. Costurar padrões de entrega e operação. Verificar se classificação, nomenclatura e propriedades do projeto são compatíveis com o sistema de gestão de ativos. Onde divergem, planejar tradução.

3. Mapear eventos-gatilho operacionais. Identificar os eventos previsíveis (manutenção, reforma, mudança de uso) e a informação necessária para cada um (§5.1.5 da 19650-3).

4. Nomear responsável pela gestão da informação na operação. A transição precisa de quem receba formalmente — não de quem "está disponível".

Médio prazo (60-120 dias — executar a transição):

5. Estabelecer o AIM. Criar o repositório operacional conforme §5.1.11 e definir processo para mantê-lo (§5.1.12).

6. Planejar handover como processo, não evento. Definir critérios de aceitação para o handover operacional, revisar e aceitar (§5.7), e agregar ao AIM (§5.8).

7. Treinar equipe de operação no vocabulário ISO 19650-3. Sem domínio dos conceitos, a equipe não sustenta a gestão da informação na fase operacional.

1. 1

   AIR definido antes do projeto começar · a operação declara o que precisa antes de a equipe de entrega produzir. Não depois do handover.

2. 2

   Padrões costurados desde a origem · classificação, nomenclatura e propriedades são consistentes entre projeto e operação (§4.2 da 19650-3). Costura planejada, não improvisada.

3. 3

   Eventos-gatilho mapeados antecipadamente · a parte requerente identifica eventos previsíveis da operação e a informação necessária para cada um. A gestão é preventiva.

4. 4

   AIM estabelecido antes do handover · o repositório operacional existe e tem processo de manutenção (§5.1.11/§5.1.12) antes de receber a primeira informação.

5. 5

   Handover planejado com critérios de aceitação · a transição é processo com etapas, revisão e aceitação (§5.7). Não é reunião de encerramento.

6. 6

   Responsável pela gestão da informação operacional desde o início · o profissional que vai receber o handover participa da definição de requisitos desde a origem. Não é surpreendido no final.

• ABNT NBR ISO 19650-3:2025Fase operacional dos ativos. Referência canônica desta página. A §4.2 trata da ponte entrega-operação e da consistência de padrões. A §5.1.5 exige mapeamento de eventos-gatilho. A §5.1.11/§5.1.12 estabelecem o AIM. A §5.7 e §5.8 cobrem aceitação e agregação.
• ABNT NBR ISO 19650-1:2022Conceitos e princípios. Base conceitual do ciclo de vida da informação e da gestão do CDE que sustenta a transição entre fases.
• ABNT NBR ISO 19650-2:2022Fase de entrega. Define o processo de produção que deve produzir informação compatível com os requisitos operacionais — o AIR é insumo do EIR (§5.2.1 a).
• ABNT NBR ISO 55000Gestão de ativos — Visão geral, princípios e terminologia. Define gestão de ativos como atividade coordenada para realizar valor (referenciada pela §3.1.1 da 19650-3). O AIR deve derivar desta estratégia.
• ABNT NBR ISO 7817-1:2024Level of information need. O LOIN calibra o que cada objeto precisa ter para servir à operação — por propósito, por marco, por ator.
• ISO 12911:2023Framework for BIM implementation specification. BIS corporativas (sufixo B/C) podem incluir cláusulas de transição operacional, formalizando o handover como especificação testável.