7. Privacidade e segurança: quem vê o quê

Quem é responsável pelos dados

A prefeitura é a responsável pelos dados (a controladora, na linguagem da lei de proteção de dados — LGPD). A Schadler Tech, empresa que constrói e opera a AtalaIA, é a operadora: trata os dados só para as finalidades da prefeitura. Antes de qualquer dado de servidor ou de cidadão entrar no sistema (nome, contato, manifestação de ouvidoria), é preciso um contrato formal entre as duas partes — esse contrato ainda não existe. Isso não vale para dado público de agente público (por exemplo, nome e cargo de um secretário já publicado no diário oficial): esse tipo de dado já está no organograma de Cascavel, porque é informação pública por natureza, e é tratado com o cuidado de rótulo e fonte descrito no item 6.

O mínimo de dado pessoal possível

• Um servidor público vai entrar no sistema só com nome, cargo, unidade e contato institucional — nunca CPF, endereço pessoal ou outro dado sensível. Essa é a regra de design do produto.
• Um cidadão só vai entrar no sistema quando fizer uma manifestação pela ouvidoria, e só com o que ele mesmo informar para aquele atendimento.
• CPF nunca deve aparecer numa tela pública. É uma regra do produto, não uma opção. Hoje, o único mecanismo automático de publicação que existe de verdade é específico do organograma (item 6 e abaixo): uma lista de permissão (allowlist) que só deixa passar campos explicitamente liberados. Uma verificação automática genérica, que procure CPF (ou outro dado sensível) em qualquer informação antes dela virar tela pública, ainda é previsto — ainda não foi construída.

Quem vê o quê (isolamento por perfil)

Esta parte inteira descreve o desenho do produto quando os painéis e o controle de acesso existirem. Hoje não existe login, nem perfil de usuário, nem controle de acesso por cargo em nenhuma tela ou API da AtalaIA — quem acessa a API pública hoje (item 10) vê exatamente o que a allowlist do organograma e a lista de obras liberam, sem diferenciar quem está perguntando.

Quando estiver pronto:

• o prefeito vai ver tudo;
• cada secretário vai ver a própria pasta;
• cada diretor vai ver a própria diretoria;
• a procuradoria e a controladoria vão ver o que a lei garante a elas e o que for encaminhado a elas;
• um cidadão, sem login, vai ver só a área pública: o que já é informação de interesse geral (obras, atos publicados, preços de referência) — nunca pendências internas, rascunhos ou dados de gabinete.

Essa separação também vai valer para os assistentes de IA: o assistente de uma secretaria não vai ler dados de outra secretaria, a não ser que exista um grupo de trabalho autorizado formalmente e essa autorização fique registrada.

A versão pública do organograma (isso já existe, de verdade)

O organograma da prefeitura (módulo M11) tem duas versões pensadas: uma para dentro do gabinete (com pendências e informação de trabalho interno, ainda não construída) e uma pública. A versão pública já existe e já funciona por uma lista de permissão (allowlist), em três níveis: só sai o que está explicitamente liberado no código para cada nível do documento (o documento inteiro, cada órgão, e o responsável de cada órgão). Uma chave nova que apareça no dado no futuro fica de fora por padrão — em vez de aparecer por engano, ela simplesmente não é mostrada até alguém decidir liberá-la de propósito. É intencional: é mais seguro que um campo novo, esquecido na hora de configurar, fique de fora por padrão do que apareça por engano.

Dentro dessa allowlist, o nome de um responsável só sai da API pública quando aquele órgão específico tiver sido marcado, um por um, como liberado para publicação (publicavel: true) — e essa liberação é sempre uma decisão do dono, órgão por órgão. Nesta versão, nenhum órgão foi liberado ainda, então a API pública do organograma não mostra nenhum nome de responsável, mesmo para os que já são FATO (item 6).

Trilha de auditoria

É previsto que todo acesso a dado, toda pergunta feita a um assistente, toda resposta dada, toda aprovação e todo envio fiquem registrados numa trilha que nunca é apagada nem alterada, só recebendo novos registros — isso é previsto, ainda não construído por completo. O que já é real hoje: a tabela dessa trilha já existe no banco de dados e já é protegida por uma regra do próprio banco que impede alteração ou apagamento (isso é testado automaticamente). Nesta versão, porém, a trilha não recebe nenhum registro de produção: nenhum código do produto está em uso, e o guardião de custo (item 5, M16) só gravaria algo nela se algum teto estivesse configurado e fosse ultrapassado — hoje todos os tetos estão vazios, então isso nunca acontece. Um endpoint que grave o acesso de uma pessoa a um dado, uma pergunta feita a um assistente, ou uma forma de a controladoria puxar essa trilha para fora, é previsto, não construído ainda.

O que a AtalaIA faz com dado de inteligência artificial

Quando um assistente precisa usar um modelo de inteligência artificial para responder algo, a ideia é mandar só o mínimo necessário para aquela tarefa específica. Hoje já existe uma decisão concreta nessa linha: a busca na base de leis (item 5, M15) usa um modelo que roda dentro do próprio servidor para transformar texto em vetor de busca, então nenhum texto de lei sai do servidor para gerar essa busca — isso está registrado nas decisões técnicas do projeto. Para os módulos que ainda vão usar modelos de IA para redigir, resumir ou analisar (itens 5, M1 a M9, M13), o provedor a ser usado e as condições de retenção de dados desse provedor ainda precisam ser conferidas e registradas — isso é previsto, ainda não documentado por completo.

Segurança da infraestrutura

A verdade sobre o ambiente de homologação de hoje (setembro de 2026) é esta, sem maquiagem: a API não tem autenticação nenhuma (qualquer um que souber o endereço consegue consultar o organograma público e a lista de obras); dentro do contêiner que roda a API, o programa roda com o usuário padrão da imagem (não um usuário próprio, restrito), e o proxy na frente dela fica acessível em todas as interfaces de rede da máquina, não só localmente; e o ambiente está configurado sem HTTPS automático, porque ainda não há um domínio próprio apontado para ele (ver item 10). Um limite de quantas vezes cada bot ou cada parte do sistema pode ser chamada num curto período, para evitar abuso, é previsto, ainda não existe. Cópias de segurança do banco de dados também são previstas (diárias, guardadas fora do servidor principal) — ver item 10 para o estado exato. Um endurecimento desse ambiente (usuário próprio no contêiner, rede fechada, HTTPS, autenticação) é previsto antes de qualquer dado real de servidor ou cidadão entrar no sistema.