Onde os dados ficam e quem enxerga o quê.

• Onde o sistema roda

  Aplicação, banco de dados PostgreSQL e arquivos enviados rodam na região southamerica-east1 do Google Cloud, em São Paulo — os três em região única, sem réplica em outra região. A cópia de segurança é caso à parte, no item Backup abaixo.

  Região única quer dizer também que não há segunda zona de espera: o banco é uma instância só. É uma escolha de custo, não um descuido, e ela entra na conversa de contrato junto com disponibilidade.

• O que não fica no Brasil

  Três coisas do dado do ente saem dessa região — por isso não dizemos que todo dado fica no Brasil.

  A senha. Quem confere é o serviço de identidade do Google (Firebase Authentication). O cadastro da pessoa, os papéis e o vínculo com o ente ficam no banco, no Brasil.

  O e-mail. Convite, aviso e redefinição de senha saem por um provedor de e-mail transacional (Resend). Não vai só o nome e o endereço de quem recebe: o convite leva o link de primeiro acesso, e os avisos levam o conteúdo da mensagem — nome da organização, objeto da parceria, datas, resultado do monitoramento e o que o servidor escreveu por extenso, como o relato de um indício em visita ou a fundamentação de uma resposta a impugnação. Nenhum e-mail leva valor de repasse nem documento anexado.

  A leitura automática de documento. Quando alguém usa o recurso — leitura de nota fiscal ou de contrato, ditado do relatório de visita —, o arquivo enviado vai para o serviço de inteligência artificial do Google (Gemini), que não tem região fixada. Hoje o recurso é ligado para o ambiente inteiro; desligá-lo para um ente específico ainda não é configuração do sistema.

  O endereço do sistema é servido pela rede de distribuição do Google (Firebase Hosting), que é global: a conexão chega ao serviço em São Paulo por ela.

  As credenciais do próprio sistema — senhas de banco e chaves de serviço — ficam no cofre de segredos do Google, com replicação automática, sem região fixada.

  Nos termos da lei, isso é transferência internacional de dados; é por isso que está dito aqui, e não em nota de rodapé.

  LGPD · art. 33

• Produção e homologação

  São serviços e bancos separados. Homologação recebe cada alteração aprovada; produção só recebe versão marcada.

  A instância de banco é a mesma para os dois, com bancos distintos.

• Backup

  O backup automático do banco está ligado.

  A cópia de segurança não tem região fixada no nosso ambiente hoje: se o seu ente exigir backup em território nacional, é ajuste de configuração e entra no contrato. Janela, retenção e tempo de recuperação também não são publicados aqui — entram no contrato.

• Cada ente só enxerga o seu

  As telas de trabalho do ente falam com o banco por um usuário que não é dono das tabelas: ele não pode desligar a regra de isolamento nem ler linha de outro ente.

  A regra mora no banco de dados, não só no aplicativo — é o recurso do PostgreSQL chamado segurança em nível de linha (row level security). Uma verificação automática roda antes de cada alteração entrar e reprova a mudança se alguma tabela perder a regra.

  Existe uma segunda conexão, de dono das tabelas, que não passa por essa regra. Ela é usada pelo console da plataforma — provisionar e parametrizar o ente — e por rotinas da área da organização, que é cadastro comum a vários entes: ali o filtro é feito no código, depois de conferida a posse, e não no banco. Cada alteração por essa conexão fica na trilha, com o ente a que se refere. A consulta — a listagem de usuários e de parâmetros do ente no console — não é registrada hoje.

• O que é compartilhado entre municípios

  O cadastro da organização é um só, identificado pelo CNPJ — é o que evita a OSC repetir o mesmo cadastro em cada prefeitura.

  Dados de dirigente, que incluem CPF, não seguem essa regra: um município só enxerga os dirigentes de organizações que têm parceria com ele.

• Perfis e papéis por pessoa

  O que cada pessoa do ente pode fazer vem de um catálogo fechado de papéis — gestor da parceria, fiscal, membro de comissão, controle interno, usuário da OSC —, somado às designações que ela recebe em cada parceria.

  Não existe perfil de acesso total para usuário de município. Existe um perfil de administrador da plataforma, que é nosso, e está no par abaixo.

• Acesso da Pactivo

  Provisionar o ente, parametrizar prazos e limites e administrar vínculos de usuário é feito num console separado das telas do ente.

  Para entrar nesse console é preciso um perfil de administrador da plataforma, que não é dado a usuário de município nenhum. É um perfil de alcance amplo: opera fora da sessão do ente. Nenhuma tela do console abre o conteúdo de uma parceria — das tabelas de parceria ele só pergunta quantas existem, para saber quais regimes o ente já usa.

  Nas listagens do console o CPF aparece sempre mascarado. Cada alteração fica na trilha, com o ente a que se refere; a consulta — a listagem de usuários e de parâmetros do ente — não é registrada hoje.

• Acesso só por convite

  Não existe autocadastro. Entrar com uma conta que não foi convidada não cria usuário nenhum: o acesso é negado.

  O convite é nominal, feito por quem já tem permissão no ente, e o link expira em sete dias.

• Trilha de auditoria

  Cada ato registrado guarda quem fez, quando e o que mudou. O usuário de banco que o sistema usa pode escrever na trilha e não pode alterar nem apagar: o privilégio foi retirado no próprio banco.

  Cada registro leva uma assinatura encadeada à do registro anterior — há uma cadeia por ente e por tipo de registro —, e recomputar as cadeias mostra se algum elo foi mexido.

  Hoje essa conferência roda nos testes automáticos do sistema. Sobre a base de um ente ela ainda não tem caminho de execução: não há rota, comando nem relatório de integridade — nem para o ente, nem para nós.

• Certificação

  Não temos ISO 27001 nem SOC 2, e não exibimos selo de conformidade de ninguém.

• Login Gov.br

  O acesso é por e-mail e senha. A entrada pelo Gov.br está no plano e ainda não existe.

• Segundo fator

  Não há verificação em duas etapas.

• Termos e Política de Privacidade

  Os dois textos estão publicados e ainda não passaram por revisão jurídica externa — eles próprios dizem isso. É a revisão que a sua procuradoria faz junto, na implantação.

• Pedido de titular pela plataforma

  A lei dá ao titular o direito de pedir acesso, correção, portabilidade e eliminação dos dados dele. Hoje esse pedido se faz ao ente, pelo canal dele — salvo o contato comercial pelo site, que é com a Pactivo: a plataforma ainda não tem tela nem serviço próprio para atendê-lo.

• Prazo de eliminação

  Os prazos de guarda e de eliminação por tipo de dado estão definidos no projeto e ainda não rodam: não há expurgo automático hoje. A trilha de auditoria, por decisão registrada, é permanente.

• Rito de incidente

  Não publicamos prazo nem procedimento de comunicação de incidente de segurança. O compromisso de avisar o ente controlador é assumido em contrato.

• Número de disponibilidade

  Não publicamos percentual de tempo no ar nem prazo de recuperação. Esses números pertencem ao contrato, discutidos com a sua procuradoria.

Por que a Pactivo existe