Superinteligência no setor público

Superinteligência no setor público ainda é uma hipótese, não algo que um órgão consiga contratar hoje. O que servidores enfrentam na prática são modelos de IA cada vez mais capazes, e as regras que valem são as de sempre: legalidade, transparência, proteção de dados e responsabilidade de quem decide. O ponto central é garantir que a decisão continue humana, registrada e explicável, mesmo quando a ferramenta ficar mais poderosa.

Principais pontos

• Superinteligência é um conceito em debate. Os riscos e as obrigações de hoje vêm de IA generativa e de agentes, e é sobre eles que o servidor decide.
• Transparência não é opcional no setor público: o cidadão e os órgãos de controle precisam entender quando e como a IA participou de um ato.
• A LGPD se aplica ao poder público, com finalidade pública definida, necessidade, segurança e direito de revisão em decisões automatizadas.
• A responsabilidade administrativa não se transfere para o fornecedor nem para o modelo. Quem assina o ato responde por ele.
• Começar por um fluxo pequeno, com limites, registros e uma métrica combinada, reduz risco e gera evidência para decidir se expande, ajusta ou para.

O que significa superinteligência quando falamos de órgão público?

Na literatura sobre o tema, superinteligência designa um sistema que superaria o desempenho humano em praticamente todas as tarefas cognitivas relevantes. Ela não existe como produto. Quem quiser entender a origem do debate pode ler o resumo sobre o livro Superinteligência, de Nick Bostrom, e o que gestores aproveitam, e a explicação de por que o ChatGPT não é superinteligência.

Para o servidor, a pergunta útil é outra: o que acontece com a responsabilidade pública quando as ferramentas ficam mais capazes? Um modelo que redige bem, resume processos extensos e age em sistemas por meio de integrações aumenta a tentação de aceitar o resultado sem conferir. O risco cresce justamente com a qualidade aparente da resposta.

Vale separar três camadas, como recomendamos em qualquer texto técnico:

• Documentação oficial: o que a lei, a ANPD e os guias reconhecidos dizem. É a base para obrigações.
• Experiência de implementação: o que costuma funcionar e falhar quando se coloca IA em um fluxo real. É orientação, não norma.
• Hipótese: o que pode acontecer com sistemas muito mais capazes. Serve para planejar, não para justificar decisões de hoje.

Misturar essas camadas é o erro mais comum em apresentações para gestores. Um fornecedor que promete "inteligência quase humana" está oferecendo hipótese como se fosse documentação.

Transparência: o que o cidadão e o controle precisam poder saber

Os princípios da administração pública (legalidade, impessoalidade, moralidade, publicidade e eficiência) não pedem desculpa para a tecnologia. Se uma IA participa de um ato, deve ser possível reconstruir o caminho: qual informação entrou, quem revisou, quem decidiu e com base em quê.

Na prática, isso significa três cuidados:

• Aviso claro ao cidadão quando ele conversa com um assistente automatizado, inclusive em canais como o WhatsApp, e opção de falar com uma pessoa.
• Registro de uso: quais fluxos usam IA, com qual finalidade, com quais dados e sob responsabilidade de qual unidade.
• Capacidade de resposta a pedidos de informação e a auditorias, o que exige logs preservados e linguagem compreensível, não só relatórios técnicos.

O OECD AI Principles trata de transparência, explicabilidade e responsabilização como pilares de uma IA confiável. O NIST AI Risk Management Framework organiza a gestão de risco em funções de governar, mapear, medir e gerenciar. Nenhum dos dois substitui a lei brasileira, mas ajudam a montar uma governança que um controle interno consegue examinar.

Um cuidado frequente: tratar o modelo como caixa preta e se contentar com "o sistema recomendou". Para ato administrativo, a motivação precisa ser humana e verificável. Se o servidor não consegue explicar por que aceitou a sugestão, a transparência falhou, mesmo que o fornecedor entregue um painel bonito.

LGPD no setor público: finalidade, necessidade e revisão

A LGPD alcança o poder público e traz regras próprias para o tratamento de dados por ele. O tratamento deve atender a uma finalidade pública, no exercício de competências legais, e informar de forma clara as hipóteses em que ocorre. Os princípios gerais continuam valendo: finalidade, adequação, necessidade, transparência, segurança, prevenção e responsabilização.

Para quem avalia IA, isso se traduz em perguntas objetivas:

• Que dados pessoais o fluxo realmente precisa? Colar um processo inteiro em uma ferramenta de chat quando bastaria um trecho viola a ideia de necessidade.
• Para onde os dados vão? Serviços de IA muitas vezes processam informações fora do país. O texto sobre transferência internacional de dados com IA e o que a LGPD exige detalha esse ponto.
• O encarregado pelo tratamento de dados foi consultado antes do uso, e há avaliação de impacto quando o risco justifica?
• O contrato com o fornecedor define papéis, retenção, uso dos dados para treinamento e resposta a incidentes?

Há ainda o direito de revisão de decisões tomadas unicamente com base em tratamento automatizado que afetem os interesses do titular. Esse tema é explicado em decisões automatizadas na LGPD e o direito de revisão. No setor público, a consequência prática é simples: não deixe a IA concluir sozinha algo que conceda, negue, puna ou classifique um cidadão.

Para orientações oficiais, o ponto de partida é a página da ANPD. Quanto a uma lei específica de IA, o caminho mais seguro é acompanhar a tramitação e a regulamentação, como resumimos em marco legal da IA no Brasil, sem tratar texto em debate como obrigação vigente.

Quem responde quando a IA erra? Responsabilidade e decisão humana

A responsabilidade administrativa recai sobre o agente público que pratica ou valida o ato e sobre a autoridade que autoriza o uso da ferramenta. Dizer que "o modelo errou" não funciona como justificativa, assim como não funcionaria dizer que "a planilha errou". O fornecedor pode responder contratualmente por falhas dele, mas a competência pública continua com o órgão.

Por isso a decisão humana precisa ser real, não um carimbo. Três sinais mostram que virou carimbo:

• O revisor recebe volume maior do que consegue conferir com atenção.
• A interface mostra só a conclusão da IA, sem as fontes ou os trechos que a sustentam.
• Ninguém registra discordâncias, então não se sabe com que frequência a IA é corrigida.

Uma divisão de papéis ajuda. A IA pode resumir, classificar para triagem, sugerir minuta e localizar normas internas. O servidor decide, motiva e assina. Quando o sistema ganha autonomia para agir (enviar mensagens, alterar cadastro, abrir processo), as permissões devem ser mínimas, com aprovação humana para ações irreversíveis ou que afetem direito de alguém. O OWASP Top 10 para aplicações com LLM lista riscos concretos, como injeção de instruções em textos que o modelo lê e excesso de autonomia, que importam bastante quando o sistema lê documentos enviados por terceiros.

Um princípio de governança resume o assunto: quanto mais capaz a ferramenta, mais cedo o órgão deve definir quem pode desligá-la, quem recebe alertas e como se reverte um ato praticado com apoio dela.

Checklist para adotar IA em um órgão sem perder o controle

O método que aplicamos em projetos de IA para empresas serve de esqueleto também para o setor público, respeitando as regras próprias de contratação e de controle: mapear, limitar, pilotar e transferir. Em formato de passos:

• Mapear: descreva o fluxo atual, quem faz o quê, quais dados circulam e qual é a situação de partida (tempo de resposta, retrabalho, reclamações). Sem esse retrato, não há como dizer depois se a IA ajudou.
• Mapear: classifique o fluxo por impacto sobre o cidadão. Atendimento informativo e resumo interno têm risco diferente de análise de benefício ou fiscalização.
• Limitar: defina quais dados a IA pode ver, quais ações pode executar e o que ela deve recusar. Dados sensíveis e decisões que afetam direitos ficam fora do escopo inicial.
• Limitar: formalize a base legal, a finalidade, o papel do encarregado e as cláusulas contratuais sobre retenção, treinamento e localização dos dados.
• Pilotar: escolha um único fluxo real, com logs de entrada, saída, fontes consultadas e revisão humana, e uma métrica de sucesso acordada antes de começar.
• Pilotar: teste com casos difíceis e com tentativas de induzir o sistema ao erro, usando avaliações repetíveis, não impressão de quem testou.
• Transferir: entregue a operação à equipe do órgão com documentação, responsáveis nomeados, rotina de monitoramento e critério para decidir se expande, ajusta ou encerra.

Se o órgão preferir manter dados sob controle local, pode avaliar modelos executados em infraestrutura própria, tema tratado em Ollama na empresa e modelo local. A escolha depende de segurança, equipe disponível e necessidade, não de preferência por moda.

Cenário ilustrativo: triagem de pedidos em um canal de atendimento

Cenário ilustrativo: uma secretaria municipal recebe pedidos de segunda via de documentos, dúvidas sobre prazos e solicitações de serviços por mensagem. Hoje, atendentes leem tudo e encaminham manualmente.

O órgão mapeia o fluxo e define o piloto: um assistente que identifica o tipo de pedido, responde dúvidas com base em uma página oficial de orientações e encaminha o restante a uma fila humana. Ele não analisa mérito de pedido nenhum, não pede documentos sensíveis e informa logo no início que é um atendimento automatizado, com opção de falar com uma pessoa.

Os limites ficam escritos: lista de assuntos permitidos, resposta padrão para o que está fora do escopo e encaminhamento imediato quando o cidadão relata urgência ou reclamação grave. Cada conversa gera um registro com a classificação feita e a fonte usada. Um servidor revisa uma amostra semanal e anota as correções.

No fim do piloto, a equipe compara com o retrato inicial e com a métrica combinada antes. Se a classificação errou em casos delicados, ajusta as regras ou reduz o escopo. Se o resultado foi bom, expande para outro tipo de pedido, mantendo a mesma disciplina. O desenho do atendimento por mensagem pode se apoiar em práticas descritas em como integrar IA no WhatsApp da empresa, adaptadas às exigências do setor público.

O exemplo é hipotético e não representa resultado de nenhum órgão. Ele mostra o formato: escopo estreito, dados mínimos, humano no comando e evidência para decidir o próximo passo.

Perguntas frequentes

Superinteligência já existe no setor público? Não. O que existe são modelos e agentes de IA cada vez mais capazes, que já exigem governança. Tratar o tema como hipótese futura não dispensa o órgão de cumprir hoje as regras de transparência, proteção de dados e responsabilidade.

Um servidor pode usar um chatbot público para resumir processos? Depende da política do órgão e dos dados envolvidos. Dados pessoais, sigilosos ou de terceiros não devem ser colados em ferramentas sem contrato, base legal e avaliação do encarregado. O mais seguro é ter uma regra interna clara sobre o que pode e o que não pode ser enviado.

A IA pode decidir um pedido do cidadão? Em atos que concedam, neguem ou classifiquem direitos, a decisão deve ser humana, motivada e revisável. A IA pode apoiar com resumo ou triagem, mas o servidor responsável precisa conferir as fontes e assumir o ato. Isso protege o cidadão e o próprio agente público.

Por onde um órgão deve começar? Pelo mapeamento de um fluxo pequeno e de baixo impacto, com dados mínimos, registros e uma métrica de sucesso definida antes. Depois do piloto, a equipe decide com base em evidência se expande, ajusta ou interrompe. Nesse caminho, vale envolver cedo o encarregado de dados, o controle interno e a área jurídica.

Fontes

• NIST AI Risk Management Framework
• OECD AI Principles
• ANPD: Autoridade Nacional de Proteção de Dados
• OWASP Top 10 for LLM Applications