Superinteligência na prefeitura: o que o agente orienta ao cidadão

Na prefeitura, um agente de IA serve bem para orientar o cidadão sobre serviços, documentos exigidos, canais de atendimento e prazos já publicados, citando sempre a fonte oficial. Ele não deve decidir sobre benefício, multa, recurso, exceção ou interpretação de regra: esses temas precisam ser encaminhados a um servidor com o contexto já organizado. A divisão só se sustenta com uma política escrita e um registro de cada conversa, para que a administração consiga explicar o que foi dito e por quê.

Principais pontos

• O agente orienta com base em conteúdo oficial e publicado, citando a origem da informação.
• Decisões administrativas, exceções, recursos e casos com dados sensíveis vão para um servidor, sem exceção.
• Cada atendimento gera registro: pergunta, resposta, fonte usada, encaminhamento e motivo.
• O cidadão sabe que está falando com uma IA e como chegar a uma pessoa.
• Antes de ampliar o uso, faz sentido começar com uma única rotina, métricas combinadas e revisão periódica.

Superinteligência é o termo certo para o que a prefeitura vai usar?

Na discussão pública, superinteligência costuma designar sistemas hipotéticos muito acima da capacidade humana em qualquer tarefa. Nenhum órgão público precisa disso para atender o cidadão. O que existe hoje são modelos de linguagem combinados com regras, bases de conhecimento e sistemas de registro, e é isso que precisa ser avaliado. Se o termo aparece no planejamento, vale traduzi-lo para perguntas operacionais: o que o agente responde, o que ele não responde, quem revisa e onde fica o histórico. Para uma leitura mais cuidadosa desses termos, o texto sobre mitos sobre superinteligência ajuda a separar a discussão conceitual da decisão prática.

O que o agente pode orientar ao cidadão

O agente é útil quando responde perguntas com resposta publicada e verificável. Em geral, isso inclui:

• requisitos e documentos listados na página oficial de cada serviço;
• horários, endereços e canais de atendimento do órgão;
• passo a passo para agendar um atendimento presencial ou abrir um protocolo;
• consulta ao andamento de um protocolo, quando houver integração autorizada;
• orientação sobre onde encontrar formulários oficiais e taxas já publicadas pelo próprio órgão.

Um ponto de atenção: o agente deve responder a partir de uma base de conteúdo aprovada pela equipe responsável, com data de atualização. Se a página oficial mudou e a base não, a resposta fica errada com aparência de certeza. Por isso, a base precisa ter dono e rotina de revisão.

O que deve ser encaminhado a um servidor

A regra prática é simples: quando a resposta depende de interpretação, de juízo sobre um caso concreto ou de poder de decisão, o agente não responde como se fosse a decisão. Ele coleta o essencial e encaminha. Entram nessa lista, por exemplo:

• pedidos de revisão, recursos e contestações de multas ou cobranças;
• pedidos de isenção, benefício ou exceção que dependem de critério subjetivo;
• dúvidas sobre como uma norma se aplica a uma situação específica;
• relatos de risco à pessoa, como violência ou situação de saúde urgente, que devem seguir o protocolo de emergência do órgão;
• reclamações formais e pedidos que envolvam dados de terceiros.

A LGPD prevê o direito de solicitar revisão de decisões tomadas unicamente com base em tratamento automatizado que afetem interesses do titular. Por isso, o agente não pode ser a última palavra em nenhum desses casos. O tema tem desdobramentos próprios, que o texto sobre decisões automatizadas e o artigo 20 da LGPD detalha.

Como registrar cada atendimento com transparência

Transparência, aqui, significa que a administração consegue reconstruir o atendimento depois, sem depender da memória de ninguém. Um bom registro não guarda tudo, guarda o necessário. A referência geral para organizar esse tipo de controle é o NIST AI Risk Management Framework, que estrutura a gestão de risco de IA em torno de governar, mapear, medir e gerir. Na prática, o registro mínimo de cada atendimento deve conter:

• data, hora e canal do atendimento;
• a pergunta do cidadão e a resposta dada pelo agente;
• a fonte oficial usada na resposta e a versão da base vigente;
• o motivo do encaminhamento e o setor que recebeu o caso;
• se o cidadão pediu atendimento humano e se ele foi efetivamente oferecido;
• o resumo entregue ao servidor, para que ninguém precise repetir tudo ao cidadão.

Dados pessoais devem aparecer no registro apenas quando forem necessários, e CPF e outros identificadores podem ser mascarados. Quem tem acesso aos logs também precisa ser definido. Registro que ninguém lê não é transparência, e registro que todos leem sem critério é um problema de privacidade.

Cenário ilustrativo: segunda via e pedido de isenção

Cenário ilustrativo: um cidadão entra em contato pelo WhatsApp e pede a segunda via de uma guia. Em seguida, pergunta se consegue isenção por ser de baixa renda. O agente informa, a partir da página oficial, como emitir a segunda via e quais canais estão disponíveis. Na parte da isenção, ele explica que a análise é feita pela equipe responsável, lista os documentos publicados como exigidos e não indica se o pedido será aceito. Em seguida, abre o encaminhamento com um resumo: serviço solicitado, documentos que o cidadão já informou, pedido de isenção e canal de retorno preferido. O servidor responde dentro do prazo publicado, e o registro mostra cada etapa, incluindo a fonte usada e o motivo do encaminhamento.

Quais limites técnicos impedem que o agente extrapole?

Uma instrução escrita no prompt, do tipo "não conceda isenções", não é uma barreira confiável. Mensagens de cidadãos podem, intencionalmente ou não, tentar convencer o agente a ignorar essas instruções, e a OWASP documenta essa classe de ataque como injeção de prompt. A proteção deve estar na arquitetura: o agente deve ter acesso apenas de leitura à base oficial, não deve ter permissão para alterar cadastros ou aprovar pedidos, e toda ação sensível deve passar por uma etapa de aprovação humana. A regra vale mesmo quando a conversa parece convincente.

Como aplicar o método em um piloto

O método que aplicamos segue quatro passos: mapear, limitar, pilotar e transferir. Primeiro, mapeia-se o atendimento atual, com volume aproximado por tipo de pedido e os gargalos que o cidadão enfrenta. Depois, definem-se os dados e as ações que o agente pode usar. No piloto, escolhe-se um único serviço, com logs e uma métrica combinada antes do início, como o tempo até o encaminhamento correto. Ao final, a equipe decide se expande, ajusta ou interrompe. Esse caminho é mais lento que um lançamento amplo, mas permite explicar cada decisão ao gestor e à controladoria.

Perguntas frequentes

O agente pode responder dúvidas sobre tributos e cobranças? Pode responder sobre o que está publicado, como prazos, locais de pagamento e documentos exigidos, sempre citando a fonte. Cálculo de valor devido, parcelamento ou contestação devem seguir para o setor responsável, com o caso já registrado.

O cidadão precisa saber que está falando com uma inteligência artificial? Sim, essa é a prática recomendada e a que dá mais segurança à administração. A mensagem inicial deve dizer que é um assistente automatizado, explicar o que ele faz e informar como chegar a um servidor.

Quais dados devem ficar guardados no histórico do atendimento? Guarde o que permite reconstruir a decisão de encaminhamento: pergunta, resposta, fonte, motivo e setor. Dados pessoais devem ser limitados ao necessário e, sempre que possível, mascarados, com acesso restrito a quem tem função no caso.

Como começar sem montar um projeto grande? Escolha um serviço de alto volume e baixo risco, como orientação sobre documentos, e faça um piloto com logs e uma métrica acordada. A experiência do piloto mostra o que a base oficial precisa melhorar antes de qualquer expansão. Um texto sobre SAC com IA e o que automatizar ajuda a separar as perguntas que podem ser respondidas das que exigem uma pessoa.

Fontes

• NIST AI Risk Management Framework
• OWASP: Prompt Injection Prevention Cheat Sheet
• ANPD: Autoridade Nacional de Proteção de Dados