Aprova

As built na prefeitura: o que exigir e como validar

Redação Aprova 13 min de leitura
Engenheiro da prefeitura comparando o projeto as built impresso com o projeto aprovado

O as built chega à prefeitura quase sempre no fim do ciclo da obra, junto com o pedido de habite-se, e é nesse ponto que a análise costuma travar. O requerente entrega um conjunto de plantas, o analista abre o projeto aprovado ao lado e descobre que a área construída mudou, que uma abertura foi deslocada ou que um pavimento ganhou um uso diferente. Sem um critério definido para o que é aceitável, cada servidor decide de um jeito, e a mesma divergência recebe tratamentos distintos conforme quem pegou o processo.

Para a gestão, o projeto as built deixa de ser uma exigência técnica abstrata e passa a ser o documento que sustenta três decisões: a emissão do habite-se, a atualização da área construída no cadastro imobiliário e a base de cálculo do IPTU. Quando o as built é aceito sem conferência, a prefeitura certifica uma realidade que não verificou. Quando é rejeitado sem critério, trava obras regulares e abre espaço para recurso administrativo.

O volume de buscas pelo tema mostra que o assunto circula mais entre construtoras e engenheiros do que entre gestores. A maior parte do conteúdo disponível explica o conceito do ponto de vista de quem elabora, e quase nada trata do ponto de vista de quem recebe, confere e decide. Esse é o ângulo que importa para a Secretaria de Obras, o Planejamento Urbano e a Fazenda: qual documentação exigir, o que validar contra o projeto aprovado, quais divergências toleram regularização e quais exigem nova aprovação.

A seguir, o as built de projeto é tratado como um procedimento de análise: critérios de exigência, checklist de conferência, regras para divergência, impacto cadastral e tributário e a forma de tramitar o fluxo com rastreabilidade.

O que é as built do ponto de vista de quem analisa na prefeitura

O as built significado em português é “como construído”: o conjunto de desenhos e registros que documenta a edificação como ela foi de fato executada, com as alterações feitas em relação ao projeto original. O as built da obra não substitui o projeto aprovado. Ele o complementa com a realidade do canteiro, e é a comparação entre os dois que interessa à prefeitura.

Na rotina municipal, a pergunta o que é as built se resolve com uma definição operacional: é o documento, assinado por responsável técnico habilitado, que declara o que foi construído e permite ao analista verificar se o resultado respeita o que foi licenciado. A elaboração tem referência técnica na norma ABNT NBR 14645, que trata do “como construído” para edificações. O município deve verificar qual norma e quais requisitos o próprio código de obras adota, porque o que a prefeitura pode exigir está na legislação local, não na norma técnica isolada.

Como o as built difere do projeto aprovado, do projeto executivo e do projeto regularizado

Quatro documentos costumam ser confundidos no balcão, e a confusão gera exigências erradas:

  • Projeto aprovado: o que a prefeitura analisou e licenciou antes da obra. É a referência contra a qual toda a conferência é feita.
  • Projeto executivo: o detalhamento técnico para execução. Pertence ao responsável técnico e não é, por si só, documento de aprovação municipal.
  • As built: o registro do que foi construído. Pode coincidir com o projeto aprovado ou apresentar diferenças.
  • Projeto regularizado ou de regularização: o processo para legalizar uma edificação já construída em desacordo com a aprovação, seguindo o rito previsto na legislação municipal.

Na prática, um as built sem divergências confirma o projeto aprovado. Um as built com divergências aceitáveis é analisado e segue para o habite-se. Um as built com divergências relevantes entra em outro fluxo, o de modificação de projeto ou regularização, com ou sem penalidade conforme o código de obras.

Quando exigir o as built e quando ele pode ser dispensado

A regra geral não existe em lei federal única. O que a prefeitura exige é definido pelo código de obras e pelos decretos regulamentadores, e a dispensa também depende da regra local. Cabe ao gestor deixar a regra escrita, porque a ausência dela é a principal fonte de tratamento desigual entre processos.

Os cenários mais comuns de exigência são:

  • Obras com alteração em relação ao projeto aprovado: quando houve modificação durante a execução, o as built é o instrumento para registrar o que mudou.
  • Obras de maior porte ou complexidade: edificações com múltiplos pavimentos, uso misto ou impacto urbanístico costumam exigir a documentação completa do construído.
  • Pedido de habite-se parcial: quando o município admite emissão por bloco ou pavimento, o as built precisa delimitar a parte concluída.
  • Regularização de obra existente: o levantamento do construído é a base do processo.

Já nas obras de baixo risco, alguns municípios adotam modelos simplificados, como o habite-se autodeclaratório, em que o responsável técnico declara a conformidade e a prefeitura fiscaliza por amostragem. Nesse modelo, a exigência do as built pode ser substituída ou reduzida, desde que haja previsão normativa e capacidade de auditoria posterior. O fluxo do habite-se está detalhado em habite-se na prefeitura, e o as built se apoia no projeto aprovado no momento do alvará de construção.

Definir a regra por faixa de risco, e não por exceção, também ajuda a equipe técnica. Um critério simples, publicado na carta de serviços, reduz a quantidade de exigências complementares e o tempo que o analista gasta explicando por que um processo precisa do documento e outro não.

O que conferir no as built contra o projeto aprovado

A conferência é o centro do procedimento. O analista não precisa refazer o projeto, mas precisa de um roteiro que torne a comparação reprodutível. Um bom roteiro separa o que é documental do que é técnico.

Checklist documental

  • Identificação do imóvel, com inscrição imobiliária, endereço e número do alvará de construção vinculado.
  • Responsável técnico identificado e habilitado, com a ART ou o RRT correspondente ao registro do as built.
  • Peças gráficas legíveis: plantas, cortes e fachadas com a indicação de que se trata do construído.
  • Quadro de áreas atualizado, com a área construída final.
  • Declaração do responsável técnico sobre a conformidade ou sobre as alterações realizadas.

A Anotação de Responsabilidade Técnica é prevista na Lei nº 6.496/1977, e os arquitetos e urbanistas registram o RRT no CAU. Conferir se o profissional é o mesmo do projeto e da execução, ou se houve substituição formal, evita questionamentos futuros sobre autoria.

Checklist técnico

  • Compatibilidade da implantação com o lote: recuos, afastamentos e taxa de ocupação.
  • Coeficiente de aproveitamento e área construída em relação ao permitido.
  • Número de pavimentos, altura e usos de cada pavimento.
  • Acessibilidade, ventilação e iluminação nos parâmetros do código de obras.
  • Aprovações complementares, quando aplicáveis, como a do Corpo de Bombeiros.

A conferência do relatório fotográfico contra o projeto é um dos pontos de maior retrabalho. Em municípios que usam análise apoiada por IA, a Lume, agente de IA da Aprova, já analisou mais de 4 mil documentos de licenciamento, deixando ao fiscal os casos que exigem julgamento técnico. A decisão permanece com o servidor.

Quais divergências são toleráveis e quais exigem nova aprovação

Esta é a pergunta que mais gera decisões inconsistentes. Não há tolerância nacional única: o limite depende do código de obras e dos decretos do município. O que o gestor pode fazer é classificar as divergências em categorias e atribuir a cada uma um caminho.

Uma matriz simples, que cada município deve ajustar à sua legislação, costuma ter três níveis:

  • Sem efeito urbanístico: ajustes internos que não alteram área, uso, recuos ou parâmetros. Em geral, são aceitos com a atualização do as built.
  • Com efeito urbanístico leve: alterações dentro de margem prevista no código, como pequenas variações de área. Podem exigir justificativa e eventual recolhimento de taxa.
  • Com efeito urbanístico relevante: aumento de área acima do aprovado, mudança de uso, avanço sobre recuo ou alteração estrutural. Exigem modificação de projeto ou regularização, com análise completa.

O ponto central é que a classificação seja objetiva e publicada. Quando o analista decide caso a caso sem referência, o município perde previsibilidade e fica exposto a questionamentos de tratamento desigual. Quando existe regra escrita, a decisão é reproduzível e auditável por Procuradoria, controle interno e tribunal de contas.

Divergências relevantes também precisam de comunicação com a fiscalização. Uma obra que cresceu além do licenciado é, em muitos casos, um caso de fiscalização de obras na prefeitura, com notificação, prazo e eventual penalidade conforme o código local.

Como o as built se conecta ao habite-se, à averbação e ao IPTU

O as built não substitui o habite-se. Ele é uma das peças que o fundamentam. O habite-se atesta a conclusão da obra conforme o projeto aprovado, e o as built é a evidência de que o construído foi comparado com o aprovado.

Essa ligação tem três efeitos diretos para a gestão.

O primeiro é a regularidade documental. Com o habite-se emitido, o proprietário costuma averbar a construção na matrícula, conforme a Lei de Registros Públicos (Lei nº 6.015/1973) e as exigências do cartório local. Um as built inconsistente produz habite-se contestável e retrabalho com o registro de imóveis.

O segundo é o cadastro. A área construída declarada no as built deve alimentar o cadastro imobiliário municipal. Se a atualização depende de redigitação, a base fica defasada e o imóvel segue tributado por uma área que já não é a real.

O terceiro é o IPTU. A diferença entre a área construída cadastrada e a área efetivamente construída afeta a base de cálculo do imposto, conforme as regras da legislação tributária municipal. Atualizar a área no momento do habite-se evita que a correção só aconteça meses depois, em recadastramento ou revisão fiscal.

Para a Fazenda, a lógica é a mesma do ISS da construção civil: quanto mais cedo a informação correta entra no sistema, mais cedo o município arrecada o que é devido. Em Cascavel (PR), o prefeito Leonaldo Paranhos relacionou a emissão rápida do alvará e do habite-se autodeclaratórios à arrecadação mais ágil, e Florianópolis (SC) emite alvarás de construção em poucos minutos pela plataforma. O ponto comum é que o ganho só se sustenta quando o dado cadastral acompanha o documento.

Como tramitar a análise do as built em fluxo digital

Um as built analisado por e-mail, papel e planilhas gera os problemas conhecidos: arquivo desatualizado, versão errada do projeto e nenhuma trilha de quem aprovou o quê. A tramitação digital resolve isso quando o fluxo é desenhado em torno de etapas e responsabilidades, não apenas de um formulário.

Um fluxo mínimo costuma incluir:

  1. Protocolo vinculado ao alvará de construção e ao responsável técnico.
  2. Checklist de entrada, que barra processos sem ART ou RRT, sem quadro de áreas ou com peças ilegíveis, antes de chegarem à análise.
  3. Análise técnica com comparação registrada entre projeto aprovado e as built.
  4. Classificação da divergência conforme a matriz do município, com encaminhamento automático para o caminho correspondente.
  5. Decisão e assinatura digital, com registro de quem analisou e quando.
  6. Atualização do cadastro e comunicação à Fazenda.

Os prazos devem estar visíveis para o analista e para a chefia, com alertas de processos parados. Os indicadores mais úteis para a secretaria são o tempo médio entre o protocolo do as built e a decisão, a taxa de processos devolvidos por documentação incompleta, o volume de divergências por categoria e o estoque de análises pendentes. Esses números ajudam a separar um problema de norma, quando o código é ambíguo, de um problema operacional, quando a fila simplesmente não anda.

A solução de planejamento urbano da Aprova organiza essa tramitação em uma plataforma de governo digital, com formulários parametrizados, checklist de entrada, análise, despacho, assinatura e trilha de auditoria. A tecnologia padroniza o fluxo e registra as decisões, mas não substitui o critério técnico do servidor. As regras de tolerância e de exigência continuam sendo as do município.

Para o município que ainda não tem essas regras escritas, o código de obras é o lugar certo para começar: definir quando o as built é exigido, o que ele deve conter e qual caminho segue cada tipo de divergência. Sem isso, qualquer sistema apenas digitaliza a inconsistência.

Perguntas frequentes

O as built é obrigatório para emitir o habite-se?

Depende da legislação municipal. Não existe uma regra federal única que obrigue todos os municípios a exigir o as built. O código de obras e os decretos definem os casos de exigência, e alguns municípios dispensam o documento em modelos simplificados, como o habite-se autodeclaratório de obras de baixo risco. O gestor deve deixar a regra publicada na carta de serviços.

Quem assina o as built?

O as built deve ser assinado por profissional habilitado, com a ART ou o RRT correspondente. Em geral, é o responsável técnico pela execução da obra, mas pode ser outro profissional, desde que a substituição esteja formalizada. A prefeitura deve conferir a habilitação e o registro do profissional no conselho competente.

Qual a diferença entre as built e projeto executivo?

O projeto executivo detalha como a obra deve ser executada e é elaborado antes ou durante a construção. O as built registra como a obra foi efetivamente construída, incluindo as alterações feitas em relação ao projeto. Para a prefeitura, o documento que interessa na conferência final é o as built, comparado ao projeto aprovado.

O as built substitui o habite-se?

Não. O as built é uma das peças que sustentam o habite-se, porque demonstra o que foi construído. O habite-se é o ato administrativo que atesta a conclusão da obra conforme o projeto aprovado e as exigências do município. Um as built com divergência relevante pode, inclusive, impedir a emissão até que o projeto seja regularizado.

Conclusão

O as built é, para a prefeitura, menos um documento de engenharia e mais um ponto de controle. Ele reúne o que foi licenciado, o que foi construído e o que passa a constar no cadastro e na base do IPTU. Quando a conferência é feita sem critério, a prefeitura emite habite-se sobre uma realidade que não verificou. Quando é feita com critério escrito, o município ganha previsibilidade, reduz recursos e protege a arrecadação.

O primeiro passo prático é transformar decisões pessoais em regra publicada. Isso significa definir em quais obras o as built é exigido e em quais pode ser dispensado, listar a documentação mínima, incluindo ART ou RRT e quadro de áreas, e classificar as divergências em categorias, cada uma com um caminho: aceitar, justificar e recolher, ou regularizar. Com a matriz definida, o analista deixa de decidir no improviso e passa a aplicar um procedimento.

O segundo passo é conectar a análise ao resto do ciclo. O as built validado precisa atualizar o cadastro imobiliário e informar a Fazenda, para que a área construída tributada acompanhe a área real. E precisa conversar com a fiscalização, porque a divergência relevante é, muitas vezes, uma obra fora do licenciado.

O terceiro é a tramitação. Um fluxo digital com checklist de entrada, comparação registrada, assinatura e trilha de auditoria reduz o retrabalho e permite medir o que importa: tempo de análise, devolução por documentação incompleta e estoque de pendências. Os números mostram onde o problema é de norma e onde é de operação.

Nenhuma ferramenta substitui a legislação local nem o julgamento técnico do servidor. O papel da tecnologia é tornar a regra executável e a decisão verificável. Para o gestor, o ganho mais concreto está em ter uma resposta consistente quando alguém pergunta por que um processo foi aprovado e outro não, e em poder demonstrá-la com documentos, datas e responsáveis registrados.

Aprova

Redação Aprova

A Redação Aprova produz conteúdos sobre gestão pública, legislação e transformação digital para apoiar prefeitos, secretários e equipes municipais. Os artigos são desenvolvidos com base em fontes oficiais, boas práticas do setor público e a partir da experiência da Aprova no desenvolvimento de soluções para modernizar a administração municipal.

Postagens relacionadas

Ver mais postagens →