Por que dar a mesma permissão a quem fiscaliza e a quem só analisa é um risco jurídico

Batizar com o mesmo nome de permissão um servidor que só instrui processo e outro que lavra auto de infração, notificação ou interdição parece um atalho de configuração — mas desloca o risco jurídico do ato para o momento em que um órgão de controle externo pergunta por que aquele usuário tinha competência para praticá-lo. Dentro de um sistema de processo eletrônico, o nome da permissão deixa de ser um detalhe de TI e passa a compor a defesa do próprio ato administrativo.

Permissão de sistema também vira prova em auditoria

Quando um processo tramita em papel, a competência para lavrar um auto de infração está na portaria de nomeação, no organograma e na assinatura manuscrita no documento. Quando o mesmo processo tramita num sistema eletrônico, essa competência é registrada de outra forma: pelo nome da permissão associada ao usuário que praticou o ato.

Isso muda o que um órgão de controle externo consegue verificar — e questionar. Uma auditoria não olha mais só o auto de infração isolado; olha o log do sistema, o usuário que o gerou e a permissão sob a qual ele agiu. Se dois cargos com competências legais distintas — um que instrui e analisa, outro que fiscaliza em campo e pode lavrar atos de poder de polícia — aparecem no sistema sob a mesma etiqueta genérica de “analista”, a defesa do ato fica mais frágil exatamente no ponto em que deveria ser mais sólida.

Função no sistema e competência legal não são a mesma coisa

É comum configurar permissões pensando só na tela que cada perfil precisa acessar: quem preenche formulário, quem aprova, quem visualiza. Esse recorte é operacional e não erra por si só. O problema aparece quando essa mesma lógica funcional é usada para nomear perfis que a legislação municipal já separa por competência — normalmente porque um deles concentra poder de polícia administrativa e o outro não.

Um agente que percorre o exercício do poder de polícia — restringir, condicionar ou sancionar em nome do interesse coletivo — pratica atos com efeito diferente de um analista que apenas confere documentação e movimenta o processo internamente. Se o sistema não reproduz essa distinção no nome da permissão, ele está, na prática, tratando como equivalentes dois níveis de responsabilidade que a lei trata como distintos. Dar nomes de permissão que espelham a competência legal do cargo — e não apenas a tela que ele acessa — é o que sustenta essa distinção também dentro do sistema.

O custo aparece depois do ato, não na hora de configurar

Na hora de implantar um sistema, unificar nomes de permissão parece economia de tempo: menos perfis para manter, menos linhas para explicar no treinamento. O custo dessa escolha não aparece na implantação — aparece quando um auto de infração é contestado e a defesa do autuado alega vício de competência, ou quando o controle externo, numa auditoria de rotina, pergunta por que um usuário com permissão genérica de “analista” praticou um ato que exige poder de polícia.

Nesse momento, corrigir a nomenclatura de permissão não resolve os atos já lavrados sob o nome errado. O órgão público precisa reconstituir, ato a ato, se quem praticou tinha de fato a competência legal correspondente — um trabalho que poderia ter sido evitado com uma decisão tomada uma única vez, na configuração do sistema.

Conclusão

Nomear permissão por função de sistema é suficiente enquanto nenhum ato praticado sob aquele nome for contestado. A partir do momento em que um processo eletrônico sustenta atos de poder de polícia, o nome da permissão para de ser escolha de TI e passa a ser parte da cadeia de competência que sustenta o ato — e é isso que um auditor, um advogado de defesa ou um tribunal de contas vai olhar primeiro. Ao configurar processos eletrônicos com o Aprova, o órgão público define permissões personalizadas por competência legal, não apenas por função de tela, exatamente para que essa distinção fique registrada onde ela importa.