Usos no Setor Público

IA no setor público refere-se a sistemas de aprendizado de máquina (machine learning) e de decisão automatizada usados por órgãos governamentais (entidades locais, regionais, nacionais e empresas estatais) para prestar serviços, gerir recursos, fiscalizar leis e se comunicar com o público. Esses sistemas podem melhorar a velocidade e a consistência, mas também operam sob restrições mais rígidas do que muitas implementações no setor privado: responsabilização pública, devido processo legal, não discriminação, obrigações de transparência e supervisão democrática.

Este artigo se concentra em três temas interligados em contextos governamentais:

  • Aquisição (procurement): como órgãos públicos adquirem sistemas de IA (construir vs. comprar), avaliam fornecedores e estruturam contratos.
  • Transparência: como governos explicam o uso de IA ao público e às pessoas afetadas, e como documentam sistemas.
  • Uso responsável: como órgãos públicos gerenciam riscos legais, éticos e operacionais ao longo do ciclo de vida da IA.

Por que a IA no governo é diferente

A IA no governo costuma ser implementada em ambientes de “alto impacto”—benefícios, tributação, imigração, habitação, educação e segurança pública—em que erros podem afetar diretamente direitos, liberdade e acesso a serviços essenciais. Diversas características tornam a IA no setor público distinta:

  • Poder coercitivo ou de “porteiro” (gatekeeping): Decisões governamentais podem ser obrigatórias (por exemplo, ações de fiscalização) ou determinar elegibilidade (por exemplo, serviços sociais).
  • Direito administrativo e devido processo legal: Muitas jurisdições exigem notificação, justificativas e a possibilidade de recorrer de decisões.
  • Normas de transparência: Regimes de acesso à informação, leis de registros públicos e supervisão legislativa frequentemente se aplicam.
  • Obrigações de equidade: Governos geralmente têm deveres reforçados para evitar discriminação e assegurar acesso igualitário.
  • Restrições orçamentárias e de aprisionamento a fornecedor (vendor lock-in): Regras de contratação pública e contratos plurianuais podem engessar escolhas técnicas.
  • Legitimidade política: Mesmo sistemas tecnicamente “precisos” podem ser inaceitáveis se corroerem a confiança.

Essas restrições moldam não apenas o que deve ser construído, mas como os sistemas são comprados, testados, documentados, monitorados e governados.

Casos de uso comuns no setor público (e o que pode dar errado)

O uso de IA no setor público abrange uma faixa de maturidade—da automação básica à modelagem preditiva e à IA generativa (generative AI). Uma forma útil de categorizar sistemas é por quão diretamente eles afetam indivíduos.

Automação administrativa (menor impacto direto, mas ainda arriscada)

Exemplos:

  • Classificação e encaminhamento de documentos (por exemplo, triagem de solicitações recebidas)
  • Reconhecimento óptico de caracteres (OCR) e extração de informação
  • Previsão de filas e alocação de pessoal (centrais de atendimento, unidades de serviço)
  • Tradução e sumarização de materiais públicos

Modos típicos de falha:

  • Desigualdades linguísticas ou de acessibilidade (a qualidade da tradução varia por idioma)
  • Viés de automação (automation bias) (equipes confiam demais em saídas da máquina)
  • Degradação silenciosa de desempenho quando documentos ou fluxos de trabalho mudam

Apoio à decisão e pontuação de risco (maior impacto)

Exemplos:

  • Detecção de fraude, desperdício e abuso em programas tributários ou de benefícios
  • Priorização de inspeções (segurança alimentar, segurança do trabalho, meio ambiente)
  • Identificação de casos “em risco” no bem-estar infantil para intervenção mais precoce
  • Previsão de capacidade hospitalar e alocação de recursos

Modos típicos de falha:

  • Ciclos de retroalimentação (feedback loops): maior escrutínio gera mais incidentes detectados em certas comunidades, reforçando as crenças do modelo.
  • Discriminação por proxy (proxy discrimination): variáveis como CEP podem codificar características protegidas.
  • Danos por limiar (threshold harms): pequenas diferenças de pontuação podem inverter resultados (auditoria vs. não auditoria), levantando questões de justiça e contestabilidade.

Segurança pública e justiça (maior escrutínio)

Exemplos:

  • Triagem de perícia digital
  • Alocação de recursos (onde patrulhar, onde implantar serviços)
  • Análises de detecção de disparos (nem sempre é aprendizado de máquina, mas com questões de governança semelhantes)
  • Ferramentas de avaliação de risco em contextos de audiência de custódia (altamente controversas)

Modos típicos de falha:

  • Impacto desigual e preocupações de legitimidade
  • Rótulos de verdade de referência (ground truth) de baixa qualidade (por exemplo, prisões refletem padrões de policiamento, não o crime subjacente)
  • Exagero de causalidade a partir de modelos correlacionais

Infraestrutura, meio ambiente e sistemas urbanos

Exemplos:

  • Otimização de semáforos usando aprendizado por reforço (reinforcement learning)
  • Manutenção preditiva para pontes, ferrovias ou sistemas de água
  • Modelagem de risco de incêndios florestais; previsão de enchentes; previsão de demanda de energia

Modos típicos de falha:

  • Mudança de distribuição (distribution shift) (mudanças climáticas, novos padrões)
  • Lacunas de sensores e dados ausentes correlacionados com a renda do bairro
  • Otimização excessiva em conflito com objetivos de política pública (por exemplo, equidade vs. vazão)

Comunicação pública e IA generativa (em rápida expansão)

Exemplos:

  • Chatbots em sites governamentais e redução de chamadas para centrais de atendimento
  • Assistência de redação para memorandos internos de política pública
  • Sumarização de comentários públicos durante processos normativos
  • Tradução e reescrita em linguagem simples

Modos típicos de falha:

  • Alucinações (hallucinations) apresentadas como orientação oficial
  • Vazamento de privacidade via prompts ou logs
  • Injeção de prompt (prompt injection) por conteúdo web não confiável
  • Respostas inconsistentes entre idiomas ou dialetos

Sistemas de IA generativa podem ser valiosos, mas exigem cláusulas de aquisição e monitoramento diferentes das de modelos preditivos tradicionais. Veja também: Arquitetura Transformer e IA Explicável para contexto sobre comportamento de modelos e limites de interpretabilidade.

Aquisição: obtendo sistemas de IA de forma responsável

A aquisição governamental não é apenas uma etapa de compra—frequentemente é o melhor ponto de alavancagem para garantir transparência e uso responsável. Uma vez que um sistema de caixa-preta (black box) é incorporado às operações, torna-se difícil auditar, alterar ou descontinuar.

Construir vs. comprar vs. parceria: um arcabouço prático de decisão

  • Construir (internamente): Máximo controle e auditabilidade; exige talentos, infraestrutura e capacidade de manutenção de longo prazo.
  • Comprar (produto de fornecedor): Implementação mais rápida; risco de aprisionamento a fornecedor, transparência limitada e inadequação à política local.
  • Parceria (academia/consórcio/ONG): Pode melhorar legitimidade e acesso a expertise; pode complicar a responsabilização se os papéis não forem claros.

Um padrão comum é comprar + configurar + governar: adquirir um sistema, mas exigir contratualmente acesso, documentação e direitos de auditoria para que o órgão possa governá-lo como infraestrutura crítica.

Pré-aquisição: defina o problema e as restrições antes do modelo

Antes de redigir um RFP (request for proposal), os órgãos devem concluir uma fase de “enquadramento do problema”:

  • Clareza do objetivo de política pública: Que resultado está sendo melhorado (velocidade, equidade, precisão, acesso)?
  • Mapeamento da decisão: Em que ponto do fluxo de trabalho a IA será usada e quem permanece responsável?
  • Prontidão de dados: Quais dados existem, qual sua proveniência e qual base legal sustenta seu uso?
  • Classificação de risco: Trata-se de uma automação de baixo risco ou de uma ferramenta de apoio à decisão de alto impacto?
  • Análise de partes interessadas: Quem é afetado e quais são os canais de recurso/reclamação?
  • Comparação com a linha de base: Qual é a taxa de erro e o perfil de desigualdade do sistema atual? (Sem isso, “melhoria” é difícil de medir.)

Muitas jurisdições agora esperam alguma forma de avaliação de impacto (impact assessment) ou avaliação de risco para IA de alto impacto. Isso se conecta diretamente a temas mais amplos de conformidade discutidos em Panorama da Regulação de IA.

Redigindo um RFP de IA: requisitos que importam

Uma aquisição de IA deve especificar não apenas funcionalidades, mas também evidências, documentação e “ganchos” de governança. Elementos comuns de RFP incluem:

1) Finalidade e limites do sistema

  • Uso pretendido e usos explicitamente proibidos
  • População-alvo e ambiente operacional
  • Se o modelo é consultivo ou determinativo

2) Desempenho e avaliação

  • Métricas exigidas (por exemplo, precisão/recall, calibração, latência)
  • Exigências de reporte por subgrupo quando legalmente permitido e apropriado
  • Planos de teste de robustez e expectativas de análise de erros

3) Justiça e não discriminação

  • Requisito de avaliar impacto desigual e explicar etapas de mitigação
    (veja: Justiça no Aprendizado de Máquina)
  • Restrições sobre atributos sensíveis e proxies
  • Processos para lidar com reclamações de viés

4) Entregáveis de transparência

5) Privacidade e proteção de dados

  • Minimização de dados, limites de retenção e controles de acesso
  • Requisitos de métodos de preservação de privacidade quando relevantes (por exemplo, Privacidade Diferencial)
  • Suporte a direitos do titular quando aplicável (acesso, correção, exclusão)

6) Segurança

  • Modelagem de ameaças e gestão de vulnerabilidades
  • Proteção contra envenenamento de dados e evasão (veja: Aprendizado de Máquina Adversarial)
  • Para LLMs (large language models): defesas contra injeção de prompt, filtragem de conteúdo e uso seguro de ferramentas

7) Auditoria e contestabilidade

  • Direito a auditorias independentes (incluindo auditorias de terceiros)
  • Suporte a revisão de casos, substituições manuais (overrides) e fluxos de recurso (veja: Humano no Loop)
  • Requisitos de reprodutibilidade para decisões contestadas

8) Gestão de mudanças

  • Regras para retreinamento, ajuste fino (fine-tuning) ou atualizações do modelo
  • Requisitos de notificação e gatilhos de revalidação
  • Procedimentos de versionamento e rollback

9) Estratégia de saída

  • Portabilidade de dados, portabilidade do modelo (onde viável) e suporte à migração
  • Depósito em custódia (escrow) de documentação e planejamento de continuidade

Avaliando propostas: um exemplo de rubrica de pontuação

Uma forma prática de evitar decisões “apenas por acurácia” é pontuar propostas em múltiplas dimensões:

evaluation_criteria:
  technical_performance: 25   # validated on agency-defined test set where possible
  fairness_and_equity: 15     # bias testing plan, mitigation, subgroup reporting
  transparency_and_docs: 15   # model cards, dataset provenance, explanation tooling
  privacy_and_security: 15    # DPIA support, retention, access controls, threat model
  governance_support: 10      # logging, auditability, change management, overrides
  vendor_track_record: 10     # deployments, incident history, references
  cost_and_total_ownership: 10 # not just license fees: staffing, hosting, monitoring

Se viável, exija um piloto com tempo delimitado com critérios de sucesso claramente definidos e um plano para o que acontece se o piloto falhar (por exemplo, não expandir, desativação segura).

Cláusulas contratuais que evitam falhas previsíveis

Documentos de aquisição devem traduzir objetivos em obrigações exigíveis. Cláusulas de alta alavancagem incluem:

  • Direitos de auditoria (incluindo acesso à documentação do modelo, resultados de avaliação e logs)
  • Prazos de reporte de incidentes (incidentes de segurança, saídas nocivas, grandes regressões)
  • Objetivos de nível de serviço para disponibilidade e latência (quando relevante)
  • Governança de atualização do modelo (sem mudanças silenciosas; revalidação obrigatória)
  • Restrições de uso de dados (sem uso secundário, sem treinamento em dados do órgão sem permissão explícita)
  • Indenizações e alocação de responsabilidade (alinhadas com Responsabilidade Civil & Accountability)
  • Divulgação de subcontratados (especialmente para provedores de modelos fundamentais (foundation models) e corretores de dados)

Transparência: o que o governo deve ao público (e o que é viável)

Transparência em IA no setor público não é uma coisa só. Ela abrange divulgação ao público, explicações individuais e rastreabilidade institucional.

Tipos de transparência

1) Transparência do sistema (divulgação pública)

  • O que o sistema faz, por que existe e quais decisões ele apoia
  • Quais fontes de dados usa em alto nível
  • Limitações conhecidas e casos de uso apropriados

2) Transparência da decisão (explicação no nível do caso)

  • Por que um indivíduo recebeu um resultado (ou uma pontuação de risco)
  • Quais fatores foram influentes (com cuidado para evitar manipulação ou vazamentos de privacidade)
  • Como recorrer ou solicitar revisão humana

3) Transparência do processo (governança e supervisão)

  • Quem é responsável pelo sistema
  • Como foi adquirido e avaliado
  • Como desempenho e reclamações são monitorados ao longo do tempo

Mecanismos práticos de transparência

  • Registros de algoritmos (algorithm registers): Inventários públicos listando sistemas de IA em uso, finalidade, fornecedor e pontos de contato.
  • Documentação padronizada: Cartões de Modelo, Fichas de Dados para Conjuntos de Dados, relatórios de avaliação.
  • Ferramentas de explicação: Modelos interpretáveis quando possível; explicações pós-hoc quando necessário (veja: IA Explicável).
  • Relatórios públicos: Desempenho agregado, estatísticas de reclamações, resumos de auditoria e histórico de atualizações.
  • Avisos claros ao usuário: Ao interagir com um chatbot ou sistema de triagem automatizada, usuários devem saber que é automatizado e o que ele pode/não pode fazer.

Transparência vs. segredos comerciais e segurança

Uma tensão comum é a alegação de informação proprietária por fornecedores. Governos podem lidar com isso sem abandonar a transparência ao:

  • Publicar descrições de alto nível e sumários de impacto publicamente
  • Exigir divulgações confidenciais a auditores/reguladores
  • Negociar escrow de código-fonte ou acesso controlado para investigações
  • Separar o que deve ser público do que deve estar disponível para supervisão

A transparência deve ser tratada como um requisito de design e de aquisição, não como um complemento posterior.

Uso responsável: gestão de riscos ao longo do ciclo de vida da IA

“IA responsável” no governo deve ser operacionalizada como gestão de riscos com controles exigíveis, não como princípios aspiracionais. Isso se cruza com conformidade legal (privacidade, igualdade, direito administrativo) e boas práticas técnicas (avaliação, robustez, monitoramento).

Fundamentos legais e de política pública (alto nível)

Embora os detalhes variem por jurisdição, pilares comuns incluem:

Justiça e não discriminação na prática

Realidade técnica essencial: justiça não é uma métrica única. Órgãos devem escolher definições alinhadas com objetivos de política pública e restrições legais (por exemplo, igualdade de oportunidade, calibração, paridade demográfica), e devem documentar trade-offs.

Passos práticos comuns:

  • Avaliar taxas de erro entre grupos relevantes onde legalmente permitido e metodologicamente sólido
  • Investigar características proxy e viés estrutural nos rótulos
  • Usar mitigações direcionadas (reponderação, otimização com restrições, melhoria na coleta de dados)
  • Validar com especialistas do domínio: uma métrica “justa” ainda pode ser operacionalmente injusta se ignorar o contexto

Para aprofundamento, veja Justiça no Aprendizado de Máquina.

Privacidade e governança de dados

Órgãos públicos frequentemente detêm dados sensíveis. IA responsável exige:

  • Limitação de finalidade: dados coletados para um programa não são automaticamente válidos para outro
  • Minimização de dados: usar apenas o necessário para o objetivo definido
  • Limites de retenção: modelos e logs não devem se tornar arquivos indefinidos
  • Controles de acesso: menor privilégio, logs de auditoria, segmentação de campos sensíveis
  • Técnicas de preservação de privacidade: em alguns casos, Privacidade Diferencial ou abordagens federadas podem reduzir risco de exposição

Um erro comum é ignorar “dados secundários”—logs, prompts, saídas do modelo, embeddings—que também podem ser sensíveis.

Segurança, robustez e resistência a mau uso

A IA no setor público pode ser alvo de comportamento adversarial: pessoas podem tentar evadir detecção, provocar saídas nocivas ou manipular entradas.

Controles frequentemente incluem:

  • Red-teaming e testes adversariais (veja: Aprendizado de Máquina Adversarial)
  • Monitoramento de deriva de dados e padrões incomuns
  • Separação estrita entre conteúdo não confiável e ações privilegiadas (especialmente para “agentes” de LLM)
  • Práticas seguras de cadeia de suprimentos de modelos (varredura de dependências, artefatos assinados)

Um requisito recorrente de governança é que a IA não deve se tornar uma autoridade incontestável.

Padrões operacionais que ajudam:

  • Revisão humano no loop para decisões de alto impacto (veja: Humano no Loop)
  • Mecanismos claros de override e documentação de overrides
  • Recursos “significativos”: capacidade de contestar entradas, raciocínio e resultados
  • Treinamento para equipes evitarem viés de automação e entenderem modos de erro

Implementação: um playbook prático de ciclo de vida para órgãos públicos

Um ciclo de vida compacto e repetível reduz riscos técnicos e legais:

  1. Seleção do caso de uso: Comece com problemas em que erros são toleráveis e benefícios são mensuráveis.
  2. Avaliação de impacto e risco: Identifique populações afetadas, danos e restrições legais.
  3. Auditoria de dados: Proveniência, qualidade, dados ausentes, representatividade, riscos de vazamento (leakage).
  4. Desenvolvimento do modelo ou avaliação de fornecedor: Prefira evidências a alegações; exija avaliações reprodutíveis.
  5. Piloto com salvaguardas: Escopo limitado, monitoramento forte, critérios claros de rollback.
  6. Documentação: Cartão de modelo, ficha do conjunto de dados, documentação do fluxo decisório, materiais de aviso ao público.
  7. Implantação com controles: Controle de acesso, logging, versionamento, resposta a incidentes.
  8. Monitoramento: Desempenho, métricas por subgrupo (quando apropriado), deriva, sinais de reclamações, efeitos sobre carga de trabalho.
  9. Auditoria periódica: Revisões internas e/ou externas; reavaliar se o sistema permanece necessário e proporcional.
  10. Aposentadoria: Descomissionar com segurança; gerenciar retenção de dados; publicar avaliação final, se apropriado.

Exemplo trabalhado: adquirindo um chatbot de LLM para uma agência de benefícios

Cenário: Uma agência de benefícios quer um assistente web para responder perguntas comuns (“Como faço para solicitar?”, “Que documentos preciso?”), reduzir volume de ligações e melhorar acessibilidade.

Principais escolhas de aquisição e governança:

Defina os limites

  • Permitido: perguntas e respostas informativas gerais, ajuda de navegação em formulários, horários de atendimento, checklists de documentos.
  • Não permitido: determinações de elegibilidade, aconselhamento jurídico personalizado, instruções que contornem salvaguardas.

Projete para confiabilidade

  • Geração aumentada por recuperação (retrieval-augmented generation, RAG): o chatbot deve responder a partir de fontes aprovadas (páginas de política, formulários).
  • Citações: o bot deve linkar para a página exata de política pública que usou.
  • Recusa e escalonamento: se a confiança for baixa ou a pergunta for específica do caso, encaminhar para um canal humano.

Especifique logging e privacidade

  • Não armazenar prompts brutos do usuário indefinidamente.
  • Redigir identificadores (nomes, SSNs) na ingestão quando possível.
  • Separar análises de logs operacionais; impor limites de retenção.

Adicione controles de segurança

  • Prevenir injeção de prompt por conteúdo web não confiável.
  • Desabilitar ações diretas por ferramentas que possam alterar registros (sem comportamento de “agente”) a menos que formalmente autorizado e em sandbox.

Exemplo de um artefato de configuração orientado a políticas que uma agência poderia exigir de fornecedores:

{
  "intended_use": "Public informational assistance for benefits program",
  "prohibited_use": [
    "eligibility determination",
    "case-specific advice",
    "collecting sensitive identifiers"
  ],
  "response_requirements": {
    "must_cite_sources": true,
    "must_use_approved_knowledge_base": true,
    "must_include_escalation_guidance_when_uncertain": true
  },
  "privacy_controls": {
    "pii_redaction": "on_ingest",
    "log_retention_days": 30,
    "no_training_on_user_prompts": true
  },
  "monitoring": {
    "hallucination_sampling_rate": 0.01,
    "harmful_output_reporting_sla_hours": 24
  }
}

Isso transforma “uso responsável” em compromissos testáveis e auditáveis.

Armadilhas comuns e anti-padrões

  • Comprar uma caixa-preta sem direitos de auditoria: Depois você não consegue explicar resultados, validar alegações de justiça ou investigar incidentes.
  • Implantar sem uma linha de base: Se você não medir o desempenho atual e as desigualdades, não consegue provar melhoria.
  • Tratar correlação como causalidade: Especialmente em contextos de segurança pública ou fraude, modelos podem codificar padrões de fiscalização.
  • Atualizações silenciosas do modelo: Mudanças do fornecedor podem alterar o comportamento sem aprovação de política pública ou revalidação.
  • Viés de automação: Equipes deferem a pontuações mesmo quando o modelo está fora do escopo pretendido.
  • Usar IA generativa como autoridade: Sem fundamentação, citações e escalonamento, chatbots podem produzir desinformação confiante.
  • Sem plano de saída: O aprisionamento a fornecedor impede a troca mesmo quando o sistema falha em atender expectativas públicas.

Práticas e tendências emergentes

  • Avaliações de impacto algorítmico e registros de IA estão se tornando mais comuns como ferramentas padrão de governança.
  • Auditorias externas e red-teaming (inclusive para LLMs) são cada vez mais esperados para sistemas de alto impacto.
  • Padrões abertos de documentação (cartões de modelo, fichas de dados) estão deixando de ser “bom ter” para virar requisito de aquisição.
  • Análises com preservação de privacidade (por exemplo, Privacidade Diferencial) estão ganhando tração onde órgãos publicam estatísticas ou compartilham conjuntos de dados.
  • Governança de modelos fundamentais (foundation model governance) está evoluindo rapidamente, especialmente em torno de autenticidade de conteúdo, segurança e concentração de fornecedores.

Artigos relacionados

A IA no setor público tem sucesso quando é tratada não como uma compra pontual de tecnologia, mas como um sistema sociotécnico governado—com controles de aquisição, transparência e uso responsável incorporados desde o início.