O IDS obriga o projetista a entregar a informação?

Anexo que ninguém referenciou não obriga ninguém.

O IDS existe, está completo, as facetas estão calibradas. O rule engine reprova a entrega. O gestor envia o relatório ao projetista. O projetista responde: onde no contrato está escrito que eu preciso cumprir esse arquivo? O gestor procura no contrato — não está. Procura no BEP — não está. O IDS é um arquivo XML que alguém colocou numa pasta do CDE. Ninguém o referenciou em nenhum documento vinculante. O projetista não é obrigado a cumprir.

O IDS é artefato técnico. O contrato é artefato jurídico. Se o IDS não é anexo do contrato ou não é referenciado pelo BEP como critério de aceitação, ele não tem força vinculante. É recomendação, não obrigação. O projetista pode ignorar o relatório de reprovação sem consequência contratual.

A ABNT NBR ISO 19650-2 estrutura a cadeia: o EIR (§5.1) declara os requisitos de informação; o BEP responde com critérios de aceitação (§5.2.1 c)); e a verificação da garantia da qualidade (§5.6.3) confere antes da troca. Nessa cadeia, o IDS é a tradução do EIR em regra verificável — mas a tradução só obriga se estiver vinculada. O IDS precisa ser citado no BEP como o mecanismo de verificação e o BEP precisa ser anexo do contrato.

Sem vínculo contratual, o IDS é ferramenta interna do gestor. Útil para diagnóstico, inútil para aceite. O relatório de reprovação vira recomendação que o projetista pode acatar ou não. E a §6.3.3 da ABNT NBR ISO 19650-1 — que exige processos de aprovação documentados e acordados — não se aplica a critério que ninguém formalizou.

1. 1

   Projetista ignora relatório de reprovação · o IDS reprova, o relatório é enviado, e o projetista não corrige. Alega que não é obrigação contratual.

2. 2

   IDS não está no BEP · o BEP lista entregas e critérios mas não menciona o IDS como mecanismo de verificação.

3. 3

   Contrato não referencia o IDS · o contrato menciona BEP, EIR, cronograma — mas não cita IDS nem arquivo de verificação automatizada.

4. 4

   IDS vive em pasta do CDE sem vínculo · o arquivo está no CDE como documento de referência, não como anexo de contrato ou do BEP.

5. 5

   Aceite feito sem IDS apesar de o IDS existir · o gestor aceita a entrega sem rodar o IDS porque sabe que o relatório não tem consequência.

1. 1

   IDS criado depois do contrato · o contrato foi assinado antes de o IDS existir. Não há como o contrato referenciar documento que ainda não existia.

2. 2

   BEP genérico sem citar mecanismo de verificação · o BEP lista critérios de aceitação em prosa mas não vincula a verificação automatizada por IDS.

3. 3

   Separação entre equipe técnica e jurídica · quem escreveu o IDS não participou da redação do contrato. Quem redigiu o contrato não sabia que o IDS existia.

4. 4

   IDS tratado como ferramenta, não como critério · a organização trata o IDS como instrumento interno de qualidade, não como critério contratual de aceite.

5. 5

   Sem cláusula de atualização · mesmo quando o IDS é referenciado, o contrato não prevê versionamento. IDS atualizado não substitui automaticamente o anterior.

1. 1

   Verificação sem consequência · o IDS reprova, o relatório existe, mas ninguém é obrigado a corrigir. A verificação é cosmética.

2. 2

   Aceite sem base contratual · o gestor usa o IDS para aceitar, mas o critério não está no contrato. Em disputa, o aceite não se sustenta.

3. 3

   Custo de elaboração sem retorno · a organização investiu em IDS, em rule engine, em fluxo de verificação — e nada disso tem força vinculante.

4. 4

   Projetista faz de conta · o projetista sabe que o IDS não obriga e ignora. O relatório de reprovação vira notificação que ninguém lê.

5. 5

   Disputa sem árbitro · contratante quer reprovar por IDS, fornecedor alega que o IDS não é contratual. Sem vínculo, o fornecedor tem razão.

Curto prazo (30 dias):

1. Verificar o vínculo contratual. Ler contrato, BEP e EIR e confirmar se o IDS é referenciado. Documentar a lacuna.

2. Incluir o IDS no BEP. Adicionar cláusula ao BEP referenciando o IDS como critério de aceitação, com versão e regra de atualização.

3. Obter ciência do projetista. Registrar que o projetista recebeu o IDS, entende que é critério de aceite, e sabe como verificar.

Médio prazo (60-90 dias):

4. Incluir cláusula de IDS no modelo de contrato. Para projetos futuros, o contrato prevê IDS como anexo, com versionamento e mecanismo de atualização.

5. Vincular IDS ao EIR formalmente. O EIR declara que a verificação de conformidade será por IDS (ISO 29481-3), e o IDS é anexo do EIR.

6. Publicar o IDS no CDE com estado controlado. O IDS não é arquivo solto — é contêiner de informação com estado, versão e trilha de auditoria.

1. 1

   IDS é anexo do contrato · o IDS é referenciado no contrato ou em anexo contratual como critério de aceitação. Sem vínculo, não obriga.

2. 2

   BEP vincula IDS ao aceite · o BEP cita o IDS como mecanismo de verificação e o projetista tem ciência antes da primeira entrega.

3. 3

   Versionamento previsto · o contrato prevê como o IDS é atualizado e qual versão vale para cada aceite. IDS sem versão é critério ambíguo.

4. 4

   IDS como contêiner no CDE · o IDS tem estado controlado no CDE — não é arquivo solto, é contêiner com versão, aprovação e trilha.

• ABNT NBR ISO 19650-2:2022Fase de entrega. §5.1 define o EIR como requisito de informação. §5.2.1 c) exige critério de aceitação por requisito. §5.6.3 institui verificação da garantia da qualidade antes da troca. Toda essa cadeia só funciona se o IDS estiver vinculado.
• ABNT NBR ISO 19650-1:2022Conceitos e princípios. §6.3.3 institui processos de aprovação documentados e acordados antes da troca. O IDS é processo de aprovação — precisa ser documentado e acordado, não imposto depois.
• buildingSMART IDS 1.0Information Delivery Specification. O IDS é artefato técnico. A força vinculante vem do contrato e do BEP, não do schema. IDS sem vínculo contratual é recomendação.
• ISO 29481-3Information delivery manual, Part 3. Formaliza o IDS como especificação de entrega de informação. A adoção contratual depende do projeto — a norma define o formato, não a obrigação.
• ABNT NBR ISO 7817-1:2024Level of information need (LOIN). O LOIN define o que o IDS verifica. Se o LOIN está no EIR e o EIR está no contrato, o IDS herda a força vinculante. Sem essa cadeia, o IDS flutua.