Como restringir a visibilidade de processos internos na carta de serviços que também atende o cidadão

Restringir a visibilidade de processos internos significa configurar a carta de serviços de um órgão público para que solicitações de uso exclusivamente interno — pedido de férias, comunicação oficial entre setores, abertura de processo de compras — apareçam apenas para quem trabalha na instituição, enquanto o cidadão, ao acessar o mesmo portal, só enxerga os serviços que pode de fato solicitar. Não é criar dois sistemas separados: é o mesmo ambiente de tramitação, com uma regra de visibilidade que decide o que cada perfil de usuário vê na hora de abrir um novo processo.

Este guia cobre por que misturar processos internos e externos na mesma tela costuma gerar confusão e risco de exposição de dado, o passo a passo para configurar essa segmentação e como medir se ela está funcionando na prática.

O que é segmentação de processos internos e externos

Toda instituição pública — prefeitura, câmara municipal, autarquia ou órgão público — tem dois tipos de demanda que tramitam pelo mesmo sistema de processos, mas nascem de lugares diferentes. A demanda externa vem de fora da estrutura: um munícipe pedindo alvará, uma empresa solicitando certidão, um requerente acompanhando um licenciamento. A demanda interna nasce dentro da própria instituição: um servidor pedindo férias para o RH, um setor abrindo um processo de compras, uma secretaria enviando um ofício para outra.

Segmentar essas duas naturezas de processo dentro da mesma carta de serviços significa que o card de “processo de compras” ou “comunicação oficial” simplesmente não aparece na lista de opções de quem acessa o portal como cidadão externo — nem por engano, nem por curiosidade. Já quem está logado como servidor enxerga a carta de serviços completa, incluindo os fluxos internos que são da sua competência abrir.

Por que essa segmentação importa

Sem essa distinção clara, dois problemas aparecem com frequência. O primeiro é o de confusão de navegação: o cidadão abre o portal de atendimento e se depara com dezenas de opções, muitas delas processos que nunca vai precisar solicitar — pedido de diária de servidor, requisição de material de almoxarifado, abertura de processo licitatório. Isso não é só um problema estético: um portal com opção demais antes de a pessoa saber o que veio buscar aumenta erro de protocolo e atendimento humano corretivo depois.

O segundo problema é mais sério: exposição indevida de informação. Um processo interno de compras, por exemplo, pode conter dado orçamentário, negociação em andamento ou informação de fornecedor que não deveria ficar acessível para consulta pública antes da fase correta de publicidade. Se a regra de visibilidade da carta de serviços não separa isso do que é aberto ao cidadão, a instituição corre o risco de expor, sem querer, uma etapa de processo que ainda não deveria estar pública.

Passo a passo para restringir a visibilidade de processos internos

1. Classifique cada processo da carta de serviços como interno ou externo

Antes de mexer em qualquer configuração, percorra a carta de serviços inteira e marque cada tipo de processo com uma etiqueta: é uma demanda que só nasce de dentro da instituição, ou pode nascer de um requerente externo? Processos que aceitam as duas origens — como um requerimento que às vezes vem de um servidor representando terceiro — precisam de uma regra à parte, não da classificação binária simples.

2. Configure a visibilidade por perfil de acesso, não por login

A regra não deve depender de quem está logado individualmente, e sim do perfil vinculado àquele acesso: servidor interno de determinado setor, requerente externo autenticado, ou usuário anônimo consultando informação pública. Um mesmo processo pode, inclusive, ter etapas com visibilidade diferente da etapa inicial — mas a decisão de “quem pode abrir este tipo de processo” deve estar amarrada ao perfil, não a uma lista de exceções mantida manualmente.

3. Oculte o card do processo interno da tela de abertura externa

Depois de classificar e definir o perfil, o passo técnico é simples: o card daquele tipo de processo some da tela de “criar processo” para quem acessa como requerente externo. Ele continua existindo e disponível normalmente para quem acessa com perfil interno.

4. Separe também o que aparece na consulta pública

Visibilidade na abertura não é a mesma coisa que visibilidade na consulta de andamento. Um processo interno de compras, mesmo que ninguém de fora possa abri-lo, não deveria aparecer também numa eventual busca pública por número de protocolo antes do momento em que a lei determina sua publicidade. As duas camadas — abertura e consulta — precisam da mesma regra de segmentação, configuradas separadamente.

5. Revise a régua sempre que um processo novo for criado

Toda vez que a instituição parametriza um processo novo na carta de serviços, a classificação interno/externo deve ser uma pergunta obrigatória da configuração — não um passo esquecido que só é notado quando alguém de fora relata ter visto algo que não deveria.

6. Teste com um usuário externo real antes de publicar

Antes de liberar qualquer processo novo, valide a tela de abertura logado como um requerente externo comum, não como administrador do sistema. É a única forma confiável de confirmar que a regra de visibilidade está aplicada e não apenas configurada na teoria.

O que a legislação exige

A Lei Geral de Proteção de Dados (Lei nº 13.709/2018), no art. 6º, III, fixa o princípio da necessidade: o tratamento de dado deve se limitar ao mínimo necessário para a finalidade do serviço. Expor um processo interno — com dado de servidor, de negociação ou de fornecedor — numa tela pensada para atendimento externo vai além dessa finalidade e expõe a instituição a risco de tratamento indevido.

Já a Lei de Acesso à Informação (Lei nº 12.527/2011) trata a transparência ativa como regra para informação pública, mas isso não significa publicidade automática de processo interno em qualquer fase: a lei disciplina quando e como a informação deve ser disponibilizada, o que reforça a necessidade de controlar o momento certo de exposição — e não simplesmente misturar tudo num único portal de acesso indiscriminado.

Como o Aprova resolve isso

• Cada processo da carta de serviços é marcado como interno ou externo na própria configuração do fluxo, sem depender de regra paralela mantida fora do sistema.
• O card do processo interno não aparece na tela de abertura de quem acessa como requerente externo, mesmo que esse usuário já tenha outros processos em andamento no mesmo portal.
• O permissionamento por perfil e setor controla, além da abertura, quem pode visualizar e tramitar cada processo internamente — sem exigir configuração processo a processo.
• A consulta pública por número de protocolo respeita a mesma regra de visibilidade, sem expor processo interno numa busca externa.

Indicadores para medir a segmentação

• Número de tentativas de acesso de usuário externo a processo classificado como interno, registradas pelo controle de permissão.
• Percentual de processos da carta de serviços já classificados como interno ou externo, em relação ao total ativo.
• Volume de solicitações de suporte relacionadas a “processo que não deveria aparecer” antes e depois da configuração.
• Tempo entre a criação de um processo novo e a definição da sua regra de visibilidade, para identificar se a classificação virou etapa padrão da configuração.

FAQ sobre visibilidade de processos internos e externos

Um processo pode ser interno e externo ao mesmo tempo?

Pode, quando a demanda nasce de fora mas depende de uma etapa interna equivalente — por exemplo, um requerimento de terceiro que também gera um processo espelho de controle interno. Nesses casos, o ideal é tratar como dois processos vinculados, cada um com sua própria regra de visibilidade, em vez de um único processo com regra ambígua.

A segmentação substitui o controle de sigilo dentro do processo?

Não. Marcar um processo como interno resolve quem pode abri-lo e vê-lo na carta de serviços; o controle de sigilo de campo ou documento específico dentro de um processo já aberto é uma camada complementar, útil mesmo dentro de processos internos com mais de um setor envolvido.

Servidores de outros setores enxergam todos os processos internos?

Depende do permissionamento configurado. É possível — e recomendável — que um servidor veja apenas os processos internos da sua própria competência, e não a carta de serviços interna inteira da instituição.

Essa configuração exige suporte técnico toda vez que um processo novo é criado?

Não, quando a classificação interno/externo é parte do formulário de configuração de qualquer processo novo. O trabalho manual de suporte só aparece quando essa etapa é tratada como exceção, e não como pergunta padrão da parametrização.

Câmaras municipais também precisam dessa segmentação?

Sim. Uma câmara municipal tem tanto processos voltados ao cidadão — como pedidos de informação ou acompanhamento de projeto de lei — quanto processos internos, como requerimento de servidor ou tramitação interna entre comissões. A lógica de segmentação é a mesma, independente do tipo de instituição.

Conclusão

Separar processos internos de externos na mesma carta de serviços não é uma questão de organização visual — é o que evita que dado que não deveria estar público apareça numa tela pensada para atendimento ao cidadão. Classificar cada processo, amarrar a visibilidade ao perfil de acesso e revisar essa régua toda vez que um fluxo novo é criado transforma uma carta de serviços única em um portal seguro tanto para quem atende de dentro quanto para quem solicita de fora. Para entender como estruturar a carta de serviços como um todo antes de aplicar essa segmentação, veja o guia sobre o que é uma carta de serviços digitais. Quer ver como configurar essa regra de visibilidade dentro do fluxo da sua instituição? Agende uma demonstração do Aprova.