Erro de projeto em obra pública: responsabilidade do projetista e do responsável técnico

Entenda quando um problema em obra pública caracteriza falha de projeto, como apurar a responsabilidade do projetista e do responsável técnico e quais evidências a Lei 14.133 exige para demonstrar nexo e dano.

Confira!

Um erro de projeto em obra pública não deve ser tratado apenas como uma incompatibilidade de desenho que “apareceu na obra”. Quando a falha de concepção, dimensionamento, especificação, levantamento, compatibilização ou detalhamento altera o custo, o prazo, a qualidade, a segurança ou a funcionalidade do empreendimento, ela passa a ter efeitos técnicos, contratuais e de responsabilidade profissional. A Lei nº 14.133/2021 determina expressamente que, se alterações de contratos de obras ou serviços de engenharia decorrerem de falhas de projeto, deve haver apuração de responsabilidade do responsável técnico e adoção das providências necessárias para ressarcir os danos causados à Administração.

Isso não significa, porém, que todo aditivo, toda RFI ou toda necessidade de revisão encontrada no campo seja automaticamente “erro do projetista”. A responsabilização tecnicamente consistente exige separar três situações diferentes: uma falha existente no projeto contratado; um defeito decorrente da execução ou dos materiais empregados; e uma alteração legítima causada por condição superveniente, nova necessidade da Administração ou risco que não poderia ter sido razoavelmente eliminado durante o desenvolvimento do projeto. Sem essa separação, o processo corre o risco de atribuir responsabilidade por presunção, quando o correto é demonstrar requisito, autoria, desvio, nexo causal e impacto.

A ART é parte importante dessa rastreabilidade porque identifica, para efeitos legais, os responsáveis técnicos pelas atividades de engenharia. Ela não substitui a análise do conteúdo efetivamente contratado e produzido, nem torna um único profissional responsável por todas as disciplinas de um empreendimento multidisciplinar. Para determinar a responsabilidade por uma falha, é necessário reconstruir quem tinha atribuição sobre a decisão técnica em questão, qual era o nível de desenvolvimento exigido, quais informações estavam disponíveis, qual versão do projeto foi liberada e de que forma o problema gerou o dano ou a necessidade de alteração.

O que caracteriza uma falha de projeto em uma obra pública

A Lei nº 14.133 define o projeto básico como o conjunto de elementos necessários e suficientes para definir e dimensionar a obra ou serviço, com nível de precisão adequado, e exige soluções suficientemente detalhadas para evitar, durante a elaboração do projeto executivo e a execução, reformulações ou variantes que afetem qualidade, preço e prazo. O projeto executivo, por sua vez, deve conter os elementos necessários e suficientes à execução completa da obra, detalhando as soluções previstas no projeto básico e especificando serviços, materiais e equipamentos.

Essa lógica é importante porque a expressão “falha de projeto” precisa ser relacionada ao nível de desenvolvimento que o documento deveria possuir. Uma omissão que seria aceitável em um estudo preliminar pode ser incompatível com um projeto básico pronto para licitação. Da mesma forma, uma decisão que ainda poderia estar aberta no projeto básico não deveria permanecer indefinida quando a frente correspondente da obra depende de projeto executivo liberado para construção.

Na prática, uma falha pode aparecer como:

• dimensionamento insuficiente ou tecnicamente inadequado;
• especificação incompatível com a condição real de instalação;
• quantitativo derivado de levantamento incompleto ou incorreto;
• ausência de uma solução necessária à execução do objeto;
• incompatibilidade entre disciplinas;
• interface não resolvida entre estrutura, arquitetura, instalações ou equipamentos;
• requisito normativo ou regulatório não incorporado;
• premissa técnica inconsistente com os dados disponíveis;
• detalhamento que não permite executar a solução sem reformulação relevante;
• documento desatualizado sendo utilizado como referência de construção;
• alteração de uma disciplina não propagada para documentos dependentes;
• solução que atende ao desenho isoladamente, mas não ao desempenho ou à funcionalidade do sistema integrado.

A existência de um problema em campo, entretanto, é apenas o primeiro indício. O diagnóstico deve verificar se o problema nasceu efetivamente da documentação de projeto ou se resultou de execução divergente, material substituído, condição desconhecida, interferência não cadastrada ou modificação posterior.

O artigo sobre Projeto Básico x Projeto Executivo ajuda a compreender por que a análise da falha deve considerar a maturidade exigida em cada etapa. Já o conteúdo sobre obra sem projeto executivo trata do gate legal para execução, enquanto aqui o foco é outro: determinar tecnicamente a origem e a responsabilidade quando o projeto já produzido se mostra inadequado.

Como diferenciar falha de projeto, erro de execução e mudança legítima

A distinção é decisiva porque cada origem conduz a responsabilidades, registros e tratamentos contratuais diferentes.

Situação	Origem técnica predominante	Evidência típica	Tratamento inicial
Falha de projeto	Concepção, cálculo, especificação, levantamento, coordenação ou detalhamento inadequado	Projeto liberado, memória de cálculo, requisito, revisão, incompatibilidade	Revisão técnica, análise de nexo e eventual apuração de responsabilidade
Erro de execução	Obra executada em desacordo com projeto, especificação ou procedimento	Inspeção, RDO, fotos, ensaios, desenho IFC e condição construída	Não conformidade, correção pelo executor e fiscalização
Material inadequado	Material fornecido diferente do aprovado ou sem desempenho requerido	Submittal, certificado, ficha técnica, inspeção de recebimento	Rejeição, substituição e tratamento contratual
Condição imprevista	Condição física ou interferência não detectável com diligência razoável	Levantamento de campo, sondagem, cadastro, registro de descoberta	Avaliação de risco, solução técnica e eventual alteração contratual
Mudança da Administração	Novo requisito, uso, capacidade ou padrão solicitado após a baseline	Solicitação formal, ata, decisão administrativa, change request	Gestão de mudança e análise de impacto
Evolução técnica legítima	Otimização ou ajuste permitido pelo regime contratual e formalmente aprovado	Estudo comparativo, aprovação, matriz de risco	Change control e atualização de baseline

Um exemplo simples é uma tubulação que colide com uma viga. A colisão pode representar falha de compatibilização do projeto. Mas também pode ter sido criada porque a estrutura foi executada fora de posição, porque a tubulação instalada não seguiu a rota prevista ou porque uma revisão arquitetônica posterior deslocou o ambiente sem atualização das demais disciplinas. A imagem final da colisão é a mesma; a responsabilidade é completamente diferente.

Por isso, processos maduros usam Design Review, coordenação multidisciplinar, revisão de interfaces e controle de revisões antes da emissão para construção. A finalidade não é criar uma camada burocrática, mas reduzir a probabilidade de que uma inconsistência documental atravesse a fase de projeto e vire custo de obra.

A execução divergente não transforma automaticamente o projeto em culpado

A Lei nº 14.133 estabelece que o contratado deve reparar, corrigir, remover, reconstruir ou substituir, às suas expensas, o objeto em que sejam verificados vícios, defeitos ou incorreções resultantes da execução ou dos materiais empregados. A fiscalização não elimina essa responsabilidade.

Assim, se o projeto especificava corretamente o elemento e a contratada executou solução diferente sem aprovação, a origem primária não é projeto. Também não é correto atribuir ao projetista uma falha introduzida por substituição comercial de equipamento, alteração de rota em campo ou método executivo incompatível com a solução aprovada.

Nem toda revisão de projeto é uma falha

Projetos são desenvolvidos sobre uma determinada baseline de requisitos, levantamentos e premissas. Uma alteração posterior de necessidade, capacidade, legislação aplicável, condição de contorno ou estratégia de implantação pode exigir revisão sem que o documento original estivesse tecnicamente errado para a informação disponível quando foi emitido.

É por isso que a gestão de requisitos e a gestão de mudanças são essenciais. Sem histórico de requisito e configuração, uma mudança legítima ocorrida meses depois pode ser interpretada retrospectivamente como erro original.

O que a Lei 14.133 determina sobre falhas de projeto

O dispositivo central é o art. 124, §1º. Ele estabelece que, quando alterações de contratos de obras e serviços de engenharia decorrerem de falhas de projeto, essas alterações ensejarão apuração de responsabilidade do responsável técnico e adoção das providências necessárias para ressarcimento dos danos causados à Administração.

O texto possui três consequências práticas importantes.

Primeiro, a necessidade de alterar o contrato não encerra o assunto. Resolver tecnicamente a obra e formalizar o aditivo pode ser necessário para preservar o empreendimento, mas a Administração ainda deve avaliar se a alteração decorreu de falha de projeto e se houve dano associado.

Segundo, a responsabilização pressupõe uma relação demonstrável entre a falha e a alteração. O simples fato de existir aditivo não prova erro de projeto. Obras podem ser alteradas por modificação legítima da Administração, condição superveniente, desapropriação, licenciamento, mudança de demanda ou outros eventos previstos na própria legislação.

Terceiro, o texto fala em responsável técnico. Isso torna a rastreabilidade de autoria, atribuição, ART, disciplina e escopo fundamental. Em projeto multidisciplinar, não é tecnicamente adequado tratar todos os profissionais como responsáveis indistintamente por qualquer problema surgido no empreendimento.

O recebimento do projeto não extingue a responsabilidade por falha

Outro dispositivo relevante está no art. 140. A Lei determina que o recebimento definitivo de projeto não exime o projetista ou consultor da responsabilidade objetiva por danos causados por falha de projeto.

Isso corrige uma interpretação perigosa: a aprovação administrativa do entregável não funciona como uma quitação técnica absoluta. A Administração deve revisar e aceitar o produto conforme seu processo de contratação, mas a descoberta posterior de uma falha capaz de causar dano não deixa automaticamente de ser analisável porque o documento havia sido recebido.

Ao mesmo tempo, essa regra não dispensa a Administração de manter um processo de revisão e aceite tecnicamente robusto. Aprovar projetos sem critérios, sem evidências ou sem capacidade técnica aumenta a exposição do empreendimento. A gestão de requisitos, evidências e critérios de aceite reduz essa fragilidade ao tornar explícito o que deve ser verificado antes de cada liberação.

ART, autoria e responsabilidade técnica: o que realmente precisa ser rastreado

A Lei nº 6.496/1977 determina que os contratos para execução de obras ou prestação de serviços profissionais de engenharia ficam sujeitos à Anotação de Responsabilidade Técnica e estabelece que a ART define, para efeitos legais, os responsáveis técnicos pelo empreendimento de engenharia.

A ART, portanto, é peça de rastreabilidade essencial. Mas a investigação técnica não deve parar na existência do documento. É necessário confrontar a ART com o contrato, a disciplina, o escopo efetivamente produzido, a autoria das peças, as revisões e as decisões que conduziram ao elemento questionado.

A Lei nº 5.194/1966 reforça essa lógica ao tratar da autoria e da responsabilidade dos profissionais que colaboram em partes de um projeto. Em empreendimentos complexos, a responsabilidade técnica deve ser relacionada às partes efetivamente desenvolvidas e assumidas por cada profissional.

Uma matriz mínima de rastreabilidade costuma incluir:

• empresa ou profissional contratado para o projeto;
• objeto e escopo contratual;
• disciplina técnica;
• responsável técnico e ART correspondente;
• autores e verificadores de cada documento;
• código e revisão do documento;
• data de emissão;
• status documental, como preliminar, para aprovação ou liberado para construção;
• requisito ou premissa que originou a solução;
• aprovações e comentários recebidos;
• mudanças posteriores e respectivos responsáveis;
• documento efetivamente utilizado pela obra.

Essa cadeia é especialmente relevante quando há mudança de equipe, substituição de projetista, contratação de disciplinas separadas ou desenvolvimento de projeto por consórcio. Sem ela, a apuração pode acabar vinculando um problema à empresa ou ao profissional errado.

Como comprovar tecnicamente que o dano nasceu do projeto

A apuração de responsabilidade não deveria começar pela pergunta “quem errou?”, mas por uma reconstrução objetiva do evento. O objetivo é estabelecer uma cadeia verificável:

requisito aplicável → informação disponível → solução projetada → desvio técnico → manifestação na obra → alteração necessária → impacto de custo/prazo/qualidade → responsável técnico pela decisão.

Essa sequência evita conclusões baseadas apenas em percepção de campo.

1. Identificar o requisito que deveria ter sido atendido

O primeiro passo é determinar qual requisito, norma, dimensão, desempenho, interface ou condição deveria ser observado. Sem requisito não há referência técnica para caracterizar desvio.

A fonte pode estar no programa de necessidades, Termo de Referência, projeto básico, norma técnica, memorial, requisito de fabricante, legislação, contrato, matriz de interfaces ou decisão formal da Administração.

2. Verificar quais dados estavam disponíveis ao projetista

Uma solução pode parecer inadequada depois que uma informação nova surge. A análise deve verificar se essa informação já existia ou deveria razoavelmente ter sido obtida durante o levantamento e o desenvolvimento do projeto.

Exemplos incluem:

• topografia;
• cadastro de redes existentes;
• sondagem;
• levantamento arquitetônico;
• dados de carga;
• requisitos operacionais;
• informações de concessionárias;
• características dos equipamentos existentes;
• condições ambientais;
• restrições de implantação.

Se o contrato previa levantamento e o dado relevante poderia ter sido identificado com o método contratado, a ausência pode integrar a falha. Se a condição era oculta e não detectável pelas diligências razoáveis previstas, a análise muda de natureza.

3. Fixar a baseline documental correta

É necessário saber qual revisão estava válida quando a obra tomou a decisão. Em muitos conflitos, a análise falha porque compara condição construída com um PDF que não era a revisão vigente.

A governança documental deve permitir identificar emissão, revisão, transmittal, aprovação e distribuição. E-mails soltos ou arquivos com nomes como “final_v2_corrigido” não são uma baseline confiável para um empreendimento relevante.

4. Caracterizar tecnicamente o desvio

O desvio deve ser descrito de forma mensurável. “Projeto ruim” não é conclusão técnica. É necessário apontar, por exemplo, que a seção calculada era insuficiente para a carga de projeto, que faltava espaço físico para manutenção, que duas disciplinas ocupavam o mesmo volume, que a especificação não atendia ao ambiente ou que o quantitativo não correspondia ao levantamento disponível.

5. Demonstrar o nexo causal

Em seguida, deve-se demonstrar que o desvio gerou a consequência alegada. Uma falha pode existir e não ter causado o dano reclamado; outra pode ter contribuído junto com erro de execução, atraso de decisão ou modificação posterior.

A análise de nexo deve separar causa raiz, fatores contribuintes e consequências. Em casos complexos, técnicas de análise de causa raiz ajudam a evitar que o primeiro desvio visível seja tratado como única causa.

6. Quantificar o impacto incremental

O dano decorrente da falha não é necessariamente igual ao valor total da solução corretiva. Parte do custo poderia existir mesmo se o projeto estivesse correto desde o início.

A análise deve separar:

• custo que já seria necessário no escopo original;
• custo de demolição ou retrabalho causado pela falha;
• materiais perdidos;
• horas improdutivas;
• mobilização adicional;
• efeito no caminho crítico;
• custo indireto de extensão de prazo quando demonstrado;
• novos projetos, ensaios ou licenças necessários exclusivamente pela correção;
• outros efeitos diretamente atribuíveis ao evento.

Essa separação é essencial para evitar superestimativa do dano.

Falhas multidisciplinares exigem análise de interface, não busca de um único culpado

Grande parte dos problemas relevantes de projeto não está dentro de uma única disciplina. Eles aparecem nas fronteiras: estrutura x instalações, arquitetura x equipamentos, elétrica x automação, drenagem x terraplenagem, utilidades x processo, obra civil x fabricante.

Uma tubulação pode ter sido corretamente dimensionada e ainda assim estar impossível de instalar porque a passagem estrutural não foi coordenada. Um quadro elétrico pode estar eletricamente correto e, ao mesmo tempo, sem área de acesso e manutenção. Um equipamento pode atender à especificação, mas exigir infraestrutura de alimentação, exaustão, fundação ou rede que não foi incorporada pelas demais disciplinas.

Por isso, a gestão de interfaces deve definir quem fornece informação, quem recebe, qual documento registra a interface e quem verifica o fechamento. Sem essa estrutura, a investigação posterior pode encontrar múltiplos documentos tecnicamente corretos em isolamento e um sistema globalmente inviável.

A responsabilidade pode ser compartilhada quando diferentes profissionais tinham obrigações complementares sobre a interface. Mas essa conclusão precisa nascer dos contratos, das atribuições técnicas e dos registros, não de uma divisão arbitrária de percentuais.

Contratação integrada e semi-integrada mudam a alocação de risco de projeto

O regime de execução contratual altera a análise. Na contratação integrada, o contratado desenvolve o projeto básico a partir do anteprojeto e assume os riscos associados ao projeto nos termos da Lei e do contrato. Na semi-integrada, o projeto básico é fornecido pela Administração, mas pode haver possibilidade de alteração pelo contratado, mediante autorização e demonstração da superioridade da inovação, com assunção dos riscos associados à alteração.

Isso significa que a pergunta “quem projetou?” é insuficiente. É necessário identificar qual versão da solução pertence a qual parte, quem possuía liberdade de alteração, qual risco foi alocado e qual documento foi efetivamente aprovado.

A matriz de alocação de riscos deve conversar com o regime, com a maturidade dos projetos e com as interfaces. Cláusulas genéricas que transferem “todos os riscos de projeto” sem coerência com os documentos fornecidos tendem a criar disputas em vez de governança.

O papel da fiscalização quando aparece um possível erro de projeto

O fiscal não deve improvisar uma nova solução no campo sem processo formal. Ao identificar uma condição possivelmente decorrente de falha de projeto, o registro deve preservar a evidência e evitar que a correção destrua o histórico necessário à análise.

Uma sequência tecnicamente prudente inclui:

1. registrar a condição encontrada no RDO ou sistema equivalente;
2. identificar a documentação vigente relacionada;
3. interromper apenas a frente afetada quando necessário por segurança ou risco de retrabalho, sem transformar automaticamente o evento em paralisação total;
4. emitir RFI, consulta técnica ou não conformidade conforme o processo contratual;
5. obter manifestação do projetista ou responsável pela solução;
6. avaliar alternativas e impactos;
7. formalizar a decisão pela autoridade competente;
8. atualizar documentos, orçamento e cronograma quando aplicável;
9. preservar o dossiê do evento para eventual apuração de responsabilidade.

A Lei nº 14.133 permite que terceiros sejam contratados para assistir e subsidiar o fiscal com informações técnicas. O apoio técnico à fiscalização é particularmente útil quando o objeto possui alta complexidade multidisciplinar ou quando a equipe pública não possui todas as especialidades necessárias internamente. Esse apoio não substitui a competência legal do fiscal; ele aumenta a qualidade da evidência e da decisão técnica.

Como tratar a correção sem apagar a evidência da falha

Existe uma tensão prática: a obra precisa continuar, mas a Administração também precisa preservar elementos para determinar origem e impacto. A pior abordagem é corrigir rapidamente sem registrar a baseline anterior e tentar reconstruir o evento meses depois.

Antes da intervenção, devem ser preservados, conforme relevância:

• desenhos e modelos na revisão vigente;
• memória de cálculo;
• especificações;
• fotos e vídeos da condição encontrada;
• levantamento dimensional;
• RDO;
• RFI e respostas;
• atas de decisão;
• orçamento original do item;
• orçamento da correção;
• programação da frente afetada;
• material já adquirido ou instalado;
• registros de inspeção;
• identificação de profissionais envolvidos.

Quando a correção exigir alteração contratual, a análise técnica de aditivos deve separar a necessidade objetiva de modificar o contrato da apuração sobre quem suportará o dano decorrente da origem da alteração.

Essa separação evita um falso dilema: reconhecer a necessidade do aditivo não significa reconhecer automaticamente que a Administração deve absorver todos os seus custos.

Como prevenir falhas de projeto antes da licitação

A prevenção começa antes de publicar o edital. Quanto mais cedo uma inconsistência é encontrada, menor a quantidade de decisões, aquisições e serviços que precisam ser desfeitos.

Levantamentos compatíveis com o risco do empreendimento

Projeto confiável depende de dados confiáveis. Levantamento cadastral, topografia, sondagem, inspeções, dados de utilidades e requisitos operacionais precisam ser proporcionais à complexidade e ao nível de decisão da etapa.

Economizar no diagnóstico para “ganhar prazo” pode apenas transferir incerteza para a obra, onde cada descoberta custa mais para ser resolvida.

Critérios objetivos de maturidade

A Administração pode usar gates de prontidão para impedir que um pacote avance apenas porque a data planejada chegou. Conteúdos sobre Project Readiness e PDRI mostram como maturidade do escopo pode ser tratada de forma estruturada.

Um pacote pronto para contratação deve permitir responder, entre outras questões:

• requisitos estão definidos e rastreados?
• levantamentos críticos foram concluídos?
• disciplinas estão coordenadas?
• interferências relevantes foram tratadas?
• memoriais e desenhos são coerentes?
• quantitativos refletem a documentação?
• orçamento é rastreável aos projetos?
• requisitos de licenciamento e concessionárias estão incorporados?
• riscos residuais foram explicitados?
• documentos possuem revisão e status controlados?

Revisão independente nos pontos de maior consequência

Nem todo projeto exige o mesmo esforço de revisão. Uma abordagem baseada em risco concentra Design Review, cálculo independente, clash detection e Project Assurance nos elementos cujo erro produziria maior efeito em segurança, custo, prazo ou operação.

O serviço de Design Review em projetos de engenharia atua justamente nessa fronteira: verificar coerência, maturidade, interfaces e riscos antes que o documento se torne uma instrução cara de obra.

Termo de Referência deve definir o que significa projeto aceito

Se o TR exige apenas “entrega de projeto executivo” sem definir disciplinas, conteúdo mínimo, critérios de revisão, formato, compatibilização, memórias de cálculo, responsabilidades e processo de aprovação, o contrato cria uma disputa futura sobre o que deveria ter sido produzido.

Uma revisão técnica do Termo de Referência antes da licitação reduz esse risco ao verificar se os produtos de engenharia são verificáveis e suficientes para a decisão que irão suportar.

Quando faz sentido contratar uma análise independente da falha

Uma análise independente tende a gerar mais valor quando o evento possui uma ou mais destas características:

• impacto econômico relevante;
• risco de paralisação;
• múltiplos projetistas ou contratadas envolvidos;
• conflito entre fiscalização, projetista e executor;
• necessidade de aditivo expressivo;
• possível pedido de reequilíbrio ou claim;
• risco de segurança ou desempenho;
• necessidade de apuração de responsabilidade;
• ausência de equipe pública na especialidade necessária;
• documentação extensa ou versões conflitantes.

O escopo não deve ser formulado como “encontrar o culpado”. Uma boa análise independente define o evento, reconstrói requisitos e baseline, identifica causas e fatores contribuintes, verifica responsabilidades contratuais, quantifica impactos e apresenta conclusões sustentadas por evidências.

A Engenharia do Proprietário pode assumir esse papel de integração técnica ao longo do empreendimento, criando a governança necessária para que divergências sejam identificadas antes de se transformarem em litígios.

Exemplo prático: alteração de fundação durante a execução

Considere uma obra em que, após a escavação, a equipe conclui que a fundação prevista não pode ser executada como projetada. Dizer imediatamente que “houve erro de projeto” é prematuro.

A análise deveria perguntar:

1. quais sondagens eram exigidas e quais foram realizadas;
2. a condição encontrada estava representada nos boletins de sondagem?
3. o projetista recebeu esses dados?
4. a memória de cálculo usou parâmetros coerentes com os resultados?
5. a execução chegou à cota e ao local especificados?
6. ocorreu mudança de implantação depois da sondagem?
7. houve condição geotécnica localizada não capturada pela campanha razoavelmente dimensionada?
8. qual solução seria necessária mesmo se a condição tivesse sido conhecida antes?
9. qual parcela da correção representa custo incremental causado pelo evento?

Se a sondagem indicava claramente a condição e o cálculo desconsiderou o dado, a evidência aponta para falha de projeto. Se a campanha contratada era inadequada por deficiência do próprio escopo da Administração, a análise pode envolver falha de planejamento. Se a condição era geologicamente imprevisível no nível de investigação razoável, o evento pode pertencer a outro risco contratual.

O valor da engenharia está em produzir essa distinção antes da decisão administrativa.

Exemplo prático: equipamento não cabe no ambiente projetado

Outro caso comum ocorre quando um equipamento especificado não consegue ser instalado, transportado ou mantido no espaço disponível.

As possíveis causas incluem:

• dimensões do equipamento conhecidas e não coordenadas pela arquitetura;
• equipamento alterado posteriormente sem atualização do layout;
• fornecedor entregou modelo diferente do aprovado;
• rota de transporte não foi considerada;
• infraestrutura construída reduziu o espaço útil;
• requisitos de manutenção não estavam definidos.

A solução corretiva pode ser idêntica — ampliar abertura, alterar layout, desmontar componentes — mas a origem e a responsabilidade mudam conforme a cadeia documental.

Esse tipo de problema demonstra por que projeto não é apenas conjunto de desenhos. É um sistema de requisitos, interfaces, decisões e configurações que precisa permanecer coerente até a entrega do ativo.

Checklist para apurar possível erro de projeto

Antes de concluir pela responsabilidade do projetista, verifique se o processo consegue responder:

• Qual requisito foi descumprido?
• Qual documento deveria atender ao requisito?
• Qual revisão estava vigente?
• Quem elaborou e quem assumiu responsabilidade técnica por essa parte?
• A ART correspondente está identificada?
• Quais informações estavam disponíveis quando a solução foi desenvolvida?
• O projeto atendia ao nível de maturidade contratado?
• A execução seguiu integralmente a solução projetada?
• Houve mudança posterior de requisito, equipamento ou condição de contorno?
• Existem fatores contribuintes de execução, suprimento ou fiscalização?
• O desvio foi tecnicamente demonstrado?
• Existe nexo causal entre o desvio e o dano alegado?
• O impacto incremental foi separado do custo que já existiria normalmente?
• A correção está formalmente aprovada e refletida na documentação vigente?
• As evidências anteriores à correção foram preservadas?

Se essas perguntas não puderem ser respondidas, a prioridade deveria ser completar a instrução técnica antes de formular uma conclusão de responsabilidade.

Considerações finais

A Lei nº 14.133 tornou explícita uma obrigação que, tecnicamente, já deveria fazer parte da boa governança de obras: alterações decorrentes de falhas de projeto não podem ser tratadas apenas como ajuste de planilha. A Administração deve investigar a responsabilidade técnica e adotar providências para ressarcir os danos quando demonstrados.

A qualidade dessa apuração depende menos de opiniões retrospectivas e mais da rastreabilidade construída durante o projeto e a obra. Requisitos claros, ART, controle de revisões, Design Review, registros de campo, RFIs, medições e gestão de mudanças transformam um conflito potencial em uma questão tecnicamente analisável.

O objetivo não é eliminar toda mudança — algo irreal em empreendimentos complexos —, mas distinguir de forma consistente o que é falha evitável, o que é execução inadequada, o que é condição superveniente e o que é mudança legítima. Essa distinção protege o interesse público, reduz disputas e melhora a qualidade das decisões de engenharia.

Referências técnicas

[1] BRASIL. Lei nº 14.133, de 1º de abril de 2021. Lei de Licitações e Contratos Administrativos. Disponível em: https://www.planalto.gov.br/ccivil_03/_ato2019-2022/2021/lei/l14133.htm. Disponível em: https://www.planalto.gov.br/ccivil_03/_ato2019-2022/2021/lei/l14133.htm.

[2] BRASIL. Lei nº 5.194, de 24 de dezembro de 1966. Regula o exercício das profissões de Engenheiro, Arquiteto e Engenheiro-Agrônomo. Disponível em: https://www.planalto.gov.br/ccivil_03/leis/l5194.htm. Disponível em: https://www.planalto.gov.br/ccivil_03/leis/l5194.htm.

[3] BRASIL. Lei nº 6.496, de 7 de dezembro de 1977. Institui a Anotação de Responsabilidade Técnica na prestação de serviços de engenharia, arquitetura e agronomia. Disponível em: https://www.planalto.gov.br/ccivil_03/leis/l6496.htm. Disponível em: https://www.planalto.gov.br/ccivil_03/leis/l6496.htm.

[4] TRIBUNAL DE CONTAS DA UNIÃO. Licitações e Contratos: Orientações e Jurisprudência do TCU. Disponível em: https://licitacoesecontratos.tcu.gov.br/. Disponível em: https://licitacoesecontratos.tcu.gov.br/.

Perguntas frequentes

Todo aditivo de obra causado por revisão de projeto caracteriza erro do projetista?

Não. O aditivo pode decorrer de mudança legítima da Administração, condição superveniente, risco contratual, alteração de requisito ou falha de execução. Para caracterizar falha de projeto é necessário demonstrar requisito, desvio técnico, autoria, nexo causal e impacto.

O que diz a Lei 14.133 sobre erro de projeto em obra pública?

O art. 124, §1º estabelece que alterações contratuais decorrentes de falhas de projeto ensejam apuração de responsabilidade do responsável técnico e adoção das providências necessárias para ressarcimento dos danos causados à Administração.

A aprovação ou recebimento definitivo do projeto elimina a responsabilidade do projetista?

Não. A Lei 14.133 prevê que o recebimento definitivo de projeto não exime o projetista ou consultor da responsabilidade objetiva por danos causados por falha de projeto.

A ART define quem deve responder por qualquer falha do empreendimento?

A ART identifica os responsáveis técnicos para efeitos legais, mas a apuração deve relacionar a ART ao escopo, disciplina, autoria, revisão e decisão técnica efetivamente associada à falha. Em projetos multidisciplinares pode haver responsabilidades distintas ou compartilhadas.

Como diferenciar erro de projeto e erro de execução?

É necessário comparar a condição executada com o documento vigente, os requisitos e as especificações. Se a solução projetada estava correta e a obra divergiu dela, a origem tende a ser de execução. Se a própria solução liberada era insuficiente ou incompatível, há indício de falha de projeto.

Quem deve analisar um possível erro de projeto em uma obra pública?

A Administração deve instruir o processo com sua fiscalização e responsáveis competentes, podendo utilizar apoio técnico especializado. Em eventos complexos, uma análise independente de engenharia pode reconstruir baseline, causas, responsabilidades e impactos sem substituir as competências legais do gestor e do fiscal.

Como calcular o dano causado por uma falha de projeto?

O cálculo deve considerar apenas impactos atribuíveis ao evento, separando o custo que já seria necessário no escopo original do retrabalho, perda de materiais, extensão de prazo, mobilização adicional e outros efeitos incrementais diretamente demonstrados.

Materiais técnicos complementares

Soluções relacionadas

• Gestão de Requisitos, Evidências e Critérios de Aceite
• Gestão de Pendências, RFIs e Não Conformidades
• Gestão de Processos, Workflows e Aprovações Técnicas
• Gestão de Contratos, Escopo e Entregáveis

Serviços relacionados

• Design Review em Projetos de Engenharia
• Projeto Executivo de Engenharia
• Engenharia do Proprietário (Owner’s Engineering)
• Apoio Técnico à Fiscalização de Obras e Contratos de Engenharia
• Análise Técnica de Aditivos, Alterações de Escopo e Pleitos em Contratos de Engenharia

Conteúdos principais sobre o tema

• Obra sem projeto executivo? O que a Lei 14.133 exige antes de começar
• Projeto Executivo de Engenharia: o que é, etapas, detalhamento e entregáveis
• Projeto Básico x Projeto Executivo: Diferenças na Contratação de Engenharia Consultiva

Conteúdos técnicos correlatos

• Design Review em Projetos de Engenharia: revisão técnica, interfaces e maturidade do projeto
• Projeto Multidisciplinar de Engenharia: disciplinas, coordenação, interfaces e entregáveis
• Matriz de Alocação de Riscos em Contratos de Engenharia
• Aditivo Contratual em Obras e Serviços de Engenharia
• Project Readiness em Engenharia
• Owner’s Engineering: framework executivo para contratação, governança e aceite
• Guia Completo sobre Engenharia Consultiva