Por que automatizar um processo obriga a prefeitura a decidir o que a lei nunca decidiu

Automatizar um processo administrativo não digitaliza uma regra que já existia — obriga alguém a escrever, pela primeira vez, uma regra que até então só existia na cabeça de quem analisava caso a caso. Quando o código de obras, o regimento interno ou a lei municipal deixam um critério em aberto, o papel esconde essa lacuna atrás da discricionariedade do analista; o sistema não esconde, porque precisa de uma resposta de sim ou não antes de deixar o processo avançar.

Configurar uma regra é decidir, não documentar

Pegue um caso comum em licenciamento de obras: duas edificações independentes erguidas no mesmo lote continuam sendo tratadas como unifamiliar, cada uma com seu processo, ou passam automaticamente a exigir enquadramento como multifamiliar? A resposta parece técnica, mas na prática depende de como a lei municipal define “área comum” e “unidade autônoma” — e boa parte dos códigos de obras municipais nunca precisou detalhar isso com a precisão que uma regra de sistema exige, porque, no papel, cada analista respondia essa pergunta do seu jeito, sem que ninguém comparasse duas respostas divergentes lado a lado.

No momento em que essa distinção precisa virar uma condição configurável — se X, então Y, senão Z — quem está com a tela de configuração aberta não está documentando uma norma existente. Está decidindo uma norma que nunca foi escrita com esse nível de detalhe. É uma decisão com efeito prático de regra geral, ainda que quem a tenha tomado não tivesse essa intenção, nem essa competência formal.

No papel, a ambiguidade não incomodava ninguém; no sistema, ela trava o primeiro caso fora da curva

Enquanto o processo tramitava em papel ou em um sistema genérico sem regra de negócio, a inconsistência entre analistas diferentes existia, mas passava despercebida — cada processo seguia seu próprio caminho, e ninguém tinha um painel único onde comparar como o mesmo tipo de pedido foi decidido em situações parecidas. A ambiguidade não gerava conflito porque nunca era confrontada consigo mesma.

Quando esse mesmo critério se torna regra de formulário, o primeiro protocolo que não se encaixa perfeitamente em nenhuma das opções previstas revela o problema imediatamente: o requerente fica travado, sem conseguir avançar, ou o sistema aplica um padrão que ninguém validou formalmente, só porque alguém precisava escolher algo na tela de configuração para o piloto não parar. É o mesmo mecanismo que aparece ao definir regras de compatibilidade entre categorias de obra no quadro de áreas ou ao decidir quando um habite-se pode ser parcial: a regra só fica visível — e discutível — depois que alguém tenta configurá-la.

Automação sem decisão prévia não elimina a ambiguidade, só a transforma em regra oficial escondida num clique de configuração

O risco maior não é a ambiguidade em si — é resolvê-la às pressas, na tela de implantação, sem levar a decisão para quem tem competência formal para normatizá-la. Um padrão definido apenas para o sistema funcionar, sem apoio em decreto, portaria ou parecer jurídico, se torna a regra de fato aplicada a todos os requerentes daquele município, mesmo sem nunca ter sido publicada como norma. O art. 2º da Lei nº 9.784/1999 exige que todo ato administrativo seja motivado — e uma decisão automática aplicada de forma uniforme, sem essa motivação formal por trás, é exatamente o tipo de lacuna que um requerente prejudicado, ou um órgão de controle, pode contestar depois.

Formulários condicionais bem configurados, como os descritos em como estruturar regras condicionais em processos administrativos, tornam qualquer critério fácil de aplicar de forma consistente. O que eles não fazem — porque não é papel de sistema nenhum fazer isso — é decidir qual critério é o correto quando a lei municipal nunca chegou a esse nível de detalhe. Essa etapa é jurídica e política, não técnica, e precisa acontecer antes de a regra virar configuração, não depois.

Conclusão

Digitalizar um processo não é neutro em relação à lei que o rege: é o momento em que qualquer lacuna de interpretação que sobrevivia informalmente no papel precisa ser resolvida, porque um sistema não aceita “depende de quem está analisando” como resposta. Tratar esse momento como puramente técnico — e deixar a decisão para quem está configurando a tela, sem levá-la à área jurídica ou à autoridade competente para normatizá-la — troca uma ambiguidade que pelo menos era visível por uma regra oficial que ninguém formalizou. Para ver como um projeto de implantação mapeia esses pontos de decisão antes de transformá-los em regra de sistema, agende uma demonstração da Aprova.