Agentes de IA podem ajudar prefeituras a orientar o cidadão, localizar informações públicas e preparar o encaminhamento de uma solicitação. Para começar, limite o serviço a assuntos documentados, informe que há automação e mantenha um caminho claro para atendimento humano.
O projeto deve distinguir orientação, registro e decisão administrativa. Explicar os documentos de um serviço é diferente de receber um requerimento ou decidir sobre um direito. Essa separação precisa aparecer na interface, nas permissões do sistema e na responsabilidade dos servidores.
Resumo rápido
- Escolha um serviço com informações revisadas e responsáveis definidos.
- Avise o cidadão quando ele estiver interagindo com IA.
- Não apresente conversa como protocolo sem confirmação do sistema oficial.
- Ofereça acessibilidade e atendimento por pessoas.
- Proteja dados e teste erros antes de ampliar o escopo.
Quais tarefas fazem sentido no atendimento municipal
Um ponto inicial possível é responder dúvidas sobre endereço de unidades, documentos necessários e canais de atendimento. A prefeitura deve selecionar informações que consegue manter atualizadas e identificar a secretaria responsável por cada uma. O sistema recebe uma tarefa delimitada, em vez de uma autorização genérica para responder sobre toda a administração.
Um agente é um software que pode consultar fontes e executar etapas usando ferramentas conectadas. Esse acesso deve acompanhar o risco da tarefa. Para informar o endereço de um equipamento público, basta consultar a base aprovada. Para registrar um pedido, são necessários controles de identificação, confirmação e retorno da operação.
A comparação abaixo é uma proposta de desenho operacional. Ela não significa que determinado município já ofereça essas funções nem estabelece uma regra jurídica universal. Cada administração precisa avaliar competência, procedimentos locais e responsabilidades antes de implantar.
| Escopo | Possível uso | Evidência necessária | Controle sugerido |
|---|---|---|---|
| Orientação pública | Localizar documentos de um serviço | Página oficial revisada | Exibir fonte e canal humano |
| Consulta individual | Consultar situação de protocolo | Resposta do sistema autorizado | Verificar acesso ao registro |
| Registro | Preparar uma solicitação | Confirmação e protocolo real | Revisão antes do envio |
| Decisão administrativa | Analisar concessão de direito | Processo e critérios competentes | Fora do piloto de orientação |
Não use a facilidade de gerar texto como critério para incluir um assunto. Perguntas sobre saúde, benefícios, denúncias ou cobranças podem carregar consequências que um catálogo simples não resolve. Quando faltar competência ou informação, o agente deve reconhecer o limite e encaminhar.
Transparência que o cidadão consegue entender
O Guia de Design de Transparência do Governo Digital orienta interfaces que comuniquem a presença e as consequências do uso de IA. Ele serve como referência para construir avisos compreensíveis. Sua existência não dispensa a avaliação do contexto municipal nem comprova conformidade de um sistema particular.
Como aplicação prática, a primeira tela pode dizer: “Você está conversando com um assistente de IA para orientações sobre serviços. Para falar com a equipe, selecione atendimento humano”. Esse texto é ilustrativo e precisa refletir o funcionamento real. Não anuncie uma equipe disponível se o atendimento ocorrer somente em determinado período.
Ao responder, indique a origem da informação: página do serviço, unidade responsável e data de revisão da base, quando registrada. Evite apresentar um percentual de confiança sem explicação. Para o usuário, saber de onde veio a exigência de um documento é mais útil que receber um número produzido pelo sistema.
Separe os estados de uma ação. “Preenchi um rascunho” indica preparação. “Solicitação enviada” exige retorno do sistema receptor. “Protocolo gerado” deve vir acompanhado do identificador verdadeiro e de instruções para acompanhar o pedido. Se a comunicação falhar, mostre a falha e evite estimular envios repetidos sem verificar o registro.
Disponibilize uma página simples sobre o serviço automatizado: escopo, responsável, dados utilizados, limitações e formas de relatar problemas. A descrição deve acompanhar mudanças relevantes. Se o agente passar a consultar processos individuais, a explicação de uma versão anterior que só respondia dúvidas públicas deixa de ser suficiente.
Dados pessoais, acessibilidade e atendimento humano
A ANPD mantém orientação sobre tratamento de dados pelo poder público. A equipe responsável deve consultar esse material e avaliar finalidade, operações e responsabilidades do projeto. Não presuma que um aviso de consentimento resolve todas as situações de atendimento público.
Como medida de desenho, comece as orientações gerais sem pedir identificação. Para explicar onde solicitar um serviço, normalmente o sistema não precisa receber uma fotografia de documento. Se uma consulta individual exigir dados, direcione a pessoa ao ambiente autenticado apropriado e restrinja o acesso ao registro pertinente.
Defina quais informações podem aparecer em registros técnicos, quem os consulta e quando são eliminados. Uma conversa sobre situação familiar pode revelar detalhes que não deveriam circular em painéis amplos de suporte. Use casos fictícios nos testes e documente o fluxo de dados entre prefeitura e fornecedores.
O portal de Acessibilidade Digital do Governo Digital reúne referências, incluindo o eMAG. Esse conjunto ajuda a planejar verificações; inserir um botão de acessibilidade não demonstra que o atendimento inteiro funciona para todas as pessoas.
Teste navegação por teclado, rótulos dos campos, foco e leitura das mensagens por tecnologia assistiva. Ofereça texto para orientações apresentadas em áudio e evite depender exclusivamente de cores para comunicar erro. Em formulários, diga qual informação precisa ser corrigida sem apagar o preenchimento já feito.
O acesso humano deve continuar compreensível quando a pessoa não consegue usar o robô. Informe canais e horários confirmados e entregue contexto ao servidor, com os cuidados necessários. O artigo sobre transferência de atendimento com contexto apresenta práticas úteis para essa passagem.
Exemplo: orientação de serviços em uma prefeitura de Sorocaba
Considere um projeto hipotético de atendimento municipal em Sorocaba. O cenário é inteiramente ilustrativo: não descreve um sistema implantado pela prefeitura nem atribui resultados ao município. A equipe escolhe orientar dúvidas sobre serviços urbanos a partir de páginas públicas revisadas.
Uma pessoa pergunta como comunicar um problema de iluminação. O agente identifica o assunto e apresenta o canal que consta na base aprovada. Se houver mais de um responsável possível, solicita apenas o esclarecimento necessário. Não inventa telefone, prazo de reparo ou promessa de visita.
O piloto inicialmente fornece orientação, sem registrar a ocorrência. Por isso, a mensagem final informa que o relato ainda precisa ser enviado pelo canal indicado. Esse cuidado evita que o cidadão espere uma providência a partir de uma conversa que não chegou ao setor responsável.
Em uma fase posterior, a equipe poderia avaliar conexão com um sistema de solicitações. Antes disso, definiria quais campos são necessários, como o cidadão confirma o conteúdo e como a aplicação verifica o protocolo. A ampliação seria um projeto novo de integração, com testes próprios e permissão limitada.
Se a pessoa escrever que já tentou o canal e não conseguiu atendimento, o agente oferece o caminho humano previsto. Um resumo encaminhado ao servidor inclui assunto e tentativa anterior, sem classificar o cidadão por comportamento. A administração avalia o caso pelo procedimento adequado.
A equipe mede se as orientações foram corretas e se as pessoas conseguiram concluir o caminho indicado. Não presume economia, satisfação ou redução de filas. Se a página de referência estiver desatualizada, suspende a resposta afetada até a área responsável corrigir a informação.
Como preparar a base e testar o serviço
Monte uma ficha por serviço com nome oficial, unidade responsável, público atendido, documentos, canais e endereço da fonte. Marque campos desconhecidos em vez de preenchê-los por dedução. Designe alguém para revisar alterações e uma forma de suspender orientações que estejam em disputa.
Evite misturar páginas antigas com instruções vigentes sem regra de prioridade. Um agente que recupera trechos de documentos precisa distinguir versões e informar quando não encontra base suficiente. Compare o desenho com as práticas de acompanhamento de alterações de escopo em integrações, especialmente quando novas ferramentas forem conectadas.
Prepare perguntas variadas para o mesmo assunto, incluindo erros de digitação, linguagem informal e nomes populares de serviços. Acrescente pedidos fora do escopo, informações contraditórias e tentativas de fazer o agente ignorar suas regras. A avaliação deve observar a resposta entregue ao usuário e as ações realmente executadas.
Teste cenários de indisponibilidade: fonte fora do ar, consulta interrompida, protocolo não confirmado e transferência sem servidor disponível. O sistema precisa comunicar essas condições sem criar uma conclusão fictícia. Para operações de escrita, uma repetição após falha exige checagem para evitar solicitações duplicadas.
O material da CGU sobre ouvidorias e Fala.BR ajuda a distinguir orientação e manifestação encaminhada. Não assuma que qualquer prefeitura utiliza a mesma plataforma: verifique os canais do órgão responsável antes de indicá-los ao cidadão.
Na operação, acompanhe respostas corrigidas, falhas de encaminhamento e dificuldade de acesso. Revise amostras com servidores da área, respeitando os controles de dados. A contagem de conversas encerradas não basta: uma pessoa pode desistir sem ter recebido orientação adequada. Amplie o piloto somente depois de entender esses casos.
Erros comuns
Esconder a automação: a pessoa precisa compreender quem a atende e como buscar ajuda. Um nome de personagem não substitui essa informação.
Confundir orientação com decisão: o texto gerado não deve anunciar concessão, indeferimento ou obrigação sem o processo competente. Mantenha essas funções fora do piloto informativo.
Pedir documento para qualquer pergunta: desenhe a coleta conforme a necessidade da tarefa. Exigir identificação para informações públicas pode criar uma barreira evitável.
Prometer protocolo sem retorno: valide o identificador no sistema receptor. Uma mensagem amigável não confirma que a solicitação existe.
Oferecer atendimento humano apenas no aviso: teste o caminho inteiro. Se o canal estiver indisponível, apresente uma alternativa real e o que o cidadão pode fazer em seguida.
Perguntas frequentes
A prefeitura deve começar com um agente que executa ações?
Um piloto de orientação pública costuma permitir avaliação mais delimitada. Ações como registrar requerimentos exigem integração, confirmação e responsabilidades adicionais. Escolha o escopo conforme a capacidade de manter fontes e acompanhar falhas.
O agente pode substituir a ouvidoria?
O desenho recomendado preserva o encaminhamento ao canal competente. Um assistente pode explicar como acessá-lo, mas uma conversa não deve ser apresentada como manifestação formal sem o registro e os procedimentos correspondentes.
Como agir quando não há resposta na base?
Informe que a orientação não foi encontrada e indique a unidade responsável ou o atendimento humano confirmado. Registre a lacuna para revisão. Não deduza exigências ou prazos a partir de serviços parecidos.
É necessário testar com pessoas que usam leitores de tela?
Inclua esse uso na avaliação prática, além das verificações automáticas. Mensagens dinâmicas, foco e formulários podem dificultar uma conversa mesmo quando o restante da página parece acessível. Os testes devem cobrir a conclusão da tarefa.
Que indicador mostra se o atendimento melhorou?
Combine correção da orientação, conclusão do encaminhamento e relatos de dificuldade. Examine também erros e retrabalho dos servidores. Defina a comparação antes do piloto e não trate encerramento automático como solução comprovada.
