Por que a integração com gov.br dá errado mesmo parecendo simples?
O gov.br é, em termos técnicos, integração padrão de OAuth/OpenID Connect — algo que qualquer time de desenvolvimento web consegue implementar em poucas semanas. Tutorial existe, documentação oficial está em ordem, ecossistema de bibliotecas é maduro. E ainda assim, projetos reais em prefeituras e secretarias estaduais frequentemente derrapam em armadilhas previsíveis.
A razão é que integração com gov.br não é só tarefa técnica — é decisão de produto, de segurança, de operação e de gestão de mudança ao mesmo tempo. Quando uma dessas camadas é negligenciada, o resultado aparece em forma de cidadão que não consegue acessar serviço, equipe interna sobrecarregada de chamados ou portal que substituiu um login pior por outro pior.
Os sete erros abaixo cobrem a maior parte dos casos observados em projetos reais. Cada um tem correção objetiva — o desafio é identificá-lo antes do lançamento, não depois.
Erro 1: exigir nível Ouro para tudo
O sintoma: cidadão tenta acessar serviço de consulta simples (segunda via de IPTU, agendamento de saúde) e o portal exige nível Ouro. Cidadão sem biometria validada não consegue acessar, abre chamado na ouvidoria. A taxa de conversão do serviço cai pela metade.
Causa: equipe técnica ou jurídica adotou "nível Ouro" como padrão único por considerar a opção "mais segura". Esqueceu que o gov.br oferece três níveis precisamente para calibrar a barreira de acesso conforme a sensibilidade do serviço.
Correção: calibrar nível por serviço, com regra clara — Bronze para consulta sem efeito jurídico (segunda via, agendamento), Prata para a maior parte dos serviços com efeito administrativo (requerimento de alvará, emissão de certidão), Ouro só para atos com efeito jurídico relevante (assinatura formal, acesso a dado sensível, abertura de processo administrativo formal). Documentar a justificativa do nível para cada serviço.
Erro 2: confundir autenticação com autorização
O sintoma: cidadão autentica com gov.br no portal da prefeitura e acessa serviço que não deveria — porque não tem vínculo com o município, ou não é o titular do imóvel, ou não é o responsável legal pelo dado consultado. Vazamento de informação ou ação indevida acontece sem que ninguém perceba imediatamente.
Causa: equipe de desenvolvimento tratou o login do gov.br como ponto final do controle de acesso. "O cidadão está autenticado, então pode acessar" — sem fazer a pergunta separada: "este cidadão específico tem direito a este serviço específico?"
Correção: depois de autenticar via gov.br, o sistema do ente local precisa fazer autorização contra suas próprias regras — cidadania (cidadão tem vínculo com este município?), vínculo (é o titular do imóvel, é o responsável legal?), histórico (já tem cadastro ativo neste serviço?). gov.br resolve autenticação; autorização permanece responsabilidade do sistema local.
Erro 3: confiar cegamente nos dados retornados no login
O sintoma: o sistema do ente local recebe os dados do cidadão pelo retorno do gov.br (nome, e-mail, telefone, endereço) e usa esses dados em decisão crítica — gera certidão com nome desatualizado, envia notificação para e-mail que cidadão não usa mais, contesta posse de imóvel com base em endereço que está errado há anos.
Causa: equipe técnica assumiu que dados do gov.br são autoritativos — quando, na verdade, eles refletem o que o cidadão declarou na sua conta gov.br, que pode estar desatualizado em relação às bases oficiais.
Correção: para dados não críticos (nome, foto, e-mail), aceitar o que o gov.br retorna — geralmente está correto. Para dados críticos (endereço, situação tributária, vínculo empregatício, status de benefício), consultar bases autoritativas via ConectaGov ou APIs específicas (Receita, SUS, Dataprev). A regra: gov.br informa quem é o cidadão; ConectaGov informa o que as bases oficiais dizem sobre ele.
Erro 4: esquecer plano de contingência para indisponibilidade do gov.br
O sintoma: o gov.br fica indisponível por algumas horas (acontece esporadicamente). Cidadãos que tentam acessar serviços críticos da prefeitura batem em parede — não há login alternativo, não há fluxo manual de emergência, e o atendimento presencial fica sobrecarregado.
Causa: equipe acreditou que "gov.br é serviço federal, sempre disponível" — sem prever cenário de indisponibilidade. Mesmo serviço federal tem janelas de manutenção, incidentes operacionais e instabilidade ocasional.
Correção: para serviços críticos (emissão de certidão urgente, agendamento de consulta, atendimento social), manter caminho alternativo de identificação — login local em fallback, atendimento manual com identificação documental, ou simplesmente comunicação clara de que o serviço retornará quando o gov.br normalizar. Plano de contingência documentado e treinado é diferencial em emergência.
Erro 5: ignorar consentimento explícito ao consumir dados adicionais
O sintoma: o portal do ente, depois do login gov.br, consulta automaticamente bases adicionais (SUS, CadÚnico, situação tributária) e exibe os dados sem perguntar autorização ao cidadão. Em caso de questionamento (cidadão pergunta "como vocês têm esse dado meu?"), o ente não tem registro de consentimento e fica exposto em fiscalização da ANPD.
Causa: equipe técnica entendeu que login gov.br = autorização para consultar tudo. Não há contraste claro entre identificação ("este cidadão é fulano") e consentimento ("este fulano autoriza acesso ao SUS dele").
Correção: para consulta a base que vai além do escopo natural do serviço local, pedir consentimento explícito ao cidadão — com finalidade declarada e registro auditável. Pode ser embutido em fluxo de uso (tela de aceite no primeiro acesso, com data e horário), mas precisa existir formalmente. LGPD se aplica dentro e fora do gov.br.
Erro 6: não migrar usuários do login antigo
O sintoma: o portal passou a oferecer login gov.br, mas o login local antigo continua disponível. Cidadãos antigos não migram porque não há gatilho para mudar; o ente fica com base dividida — alguns usuários no gov.br, outros no login local. Custo de manutenção dobrado, complexidade técnica permanente.
Causa: equipe lançou gov.br como opção "em paralelo" ao login local, esperando que migração orgânica acontecesse. Migração orgânica raramente acontece — usuário cria conta nova só se obrigado.
Correção: após estabilizar o gov.br no portal, definir cronograma de migração — período em que login local continua disponível mas com avisos crescentes de migração obrigatória. Após o prazo, login local é desativado. Em três a seis meses, a maior parte da base ativa migra; o restante reativa quando volta a usar o serviço.
Erro 7: não medir adoção e fricção pós-lançamento
O sintoma: o portal está no ar com gov.br, mas ninguém sabe se ele está sendo usado de fato. Não há dashboard de adoção, não há monitoramento de erros de autenticação, não há análise de funil de uso do cidadão. Quando alguém pergunta "está funcionando?", a resposta é vaga.
Causa: o projeto entregou a integração técnica como objetivo final, sem instrumentar a operação para medir o uso real. Métrica do sucesso ficou implícita.
Correção: instrumentar o portal desde o lançamento — taxa de login bem-sucedido, taxa de abandono no fluxo gov.br, erros de autenticação por tipo, tempo médio até completar serviço após login. Esses dados orientam ajuste: nível mal calibrado, etapa confusa no fluxo, mensagem de erro pouco clara. Sem medição, otimização é palpite.
Como prevenir esses sete erros em um novo projeto?
Primeiro: tratar a integração com gov.br como projeto de produto, não como projeto de TI. Equipe deve incluir alguém que pensa na jornada do cidadão, alguém que pensa em segurança e privacidade, alguém que pensa em gestão de mudança interna. Sem essa diversidade, o projeto fica capenga em alguma dimensão.
Segundo: instrumentar desde o início. Métricas de adoção, taxa de erro e tempo de fluxo precisam estar no escopo do MVP — não como funcionalidade extra para depois.
Terceiro: pilotar com um serviço antes de fazer tudo. Migrar primeiro um serviço bem escolhido — alta demanda, baixa criticidade — gera aprendizado prático que orienta os serviços seguintes. Tentar migrar tudo de uma vez aumenta risco sem ganho proporcional.
Quarto: documentar decisões. Por que esse serviço usa Prata e aquele usa Ouro? Por que esse fluxo pede consentimento adicional? Documentação registrada protege em fiscalização e facilita evolução futura sem perda de contexto.
Os sete erros são previsíveis — mas só evitáveis quando alguém olha conscientemente para eles antes do lançamento. Depois, a correção é mais cara e a sequência de chamados na ouvidoria conta a história.