Política de Privacidade

O admpoiema, plataforma de gestão da rede de igrejas Poiema, é operado por [A DEFINIR: razão social completa da igreja], inscrita no CNPJ sob o nº [A DEFINIR: CNPJ], com sede em [A DEFINIR: endereço completo], aqui chamada “a igreja”.

Quando outras igrejas da rede passarem a usar o sistema, cada uma responde pelos próprios dados; a divisão de responsabilidades entre elas e a operadora da plataforma é [A DEFINIR: definir se há controladoria conjunta ou operador, e formalizar em contrato].

O admpoiema é organizado em módulos, hoje dois. Esta política vale para a plataforma inteira; onde o tratamento difere entre um módulo e outro, o texto diz qual.

• Finanças — lê o extrato financeiro mensal exportado do Conta Azul, classifica os lançamentos e mostra indicadores de saúde financeira da igreja: peso do custo operacional sobre dízimos e ofertas, reserva de emergência em meses, evolução por categoria. Substitui uma planilha de gestão manual.
• Inventário — controla o patrimônio: cada bem com código próprio e QR Code, localização, ministério e pessoa responsável, fotos, notas fiscais, movimentações, manutenções, baixas e conferências.

Nenhum dos dois é sistema contábil ou fiscal, e nenhum emite documento com valor legal.

Dados de quem usa o sistema. Nome, e-mail, perfil de acesso em cada módulo, se a verificação em duas etapas está ativa, data do último acesso e data em que a senha foi definida. A autenticação é feita por serviço de terceiro (item 9), que guarda a credencial — o sistema não armazena senha.

Registros de acesso e de auditoria. Cada ação relevante dos dois módulos (login, login negado, convite, alteração de acesso, importação de extrato, lançamento de saldo, expurgo, cadastro, alteração, movimentação, manutenção e baixa de patrimônio) é registrada com autor, data e hora, endereço IP e identificação do navegador. Esses registros existem para permitir apurar o que aconteceu e por quem, e não são apagados por ação de usuário.

Preferências de exibição. Tema claro/escuro e ajustes de acessibilidade, guardados no próprio navegador de quem acessa.

Chamados de suporte. Quando alguém usa “Ajuda e sugestões”, o sistema guarda o texto escrito, o nome e o e-mail de quem abriu, a igreja, a página em que a pessoa estava e a identificação do navegador. Isso fica visível para a própria pessoa e para os administradores da plataforma, que respondem por e-mail e pelo próprio sistema. Não escreva CPF, senha ou dado bancário em um chamado.

Dados financeiros do extrato. Data do movimento, competência, valor, natureza (entrada ou saída), categoria do plano de contas, centro de custo, conta bancária, forma de pagamento, situação e descrição do lançamento. Em despesas, a descrição costuma trazer o nome do fornecedor.

O arquivo bruto do extrato. A planilha enviada na importação é guardada como veio, em armazenamento privado, sem acesso público e sem link aberto.

Saldos informados manualmente. O saldo de cada conta bancária no fechamento do mês, digitado por quem opera o sistema.

Boa parte das receitas chega por Pix, e o extrato do banco traz o CPF de quem enviou dentro do texto da descrição. Esse é o ponto mais sensível do módulo Finanças, e ele é tratado assim:

• O CPF é extraído da descrição no momento da importação, antes de qualquer gravação.
• Ele é transformado em um código irreversível por HMAC-SHA256, com uma chave secreta que fica fora do banco de dados, em variável de ambiente do servidor. É esse código (chamado doador_ref) que fica gravado.
• O CPF é removido do texto antes de o lançamento ser gravado. O número em si não é armazenado em lugar nenhum — nem no banco, nem em log, nem no arquivo processado.
• O código serve apenas para saber que dois lançamentos vieram da mesma pessoa, o que permite análises agregadas (por exemplo, concentração da arrecadação). Nenhuma tela e nenhum endpoint do sistema devolve doador individual: o que sai do servidor é sempre número somado.
• O arquivo bruto do extrato, porém, é guardado como o banco o exportou — e ali o CPF ainda está no texto. É justamente por isso que ele fica em armazenamento privado e tem prazo de descarte próprio (item 10).

Limite honesto desta técnica: o código não pode ser revertido, mas pode ser reproduzido. Quem tiver ao mesmo tempo o banco de dados e a chave secreta consegue testar CPFs até achar quais estão ali. Por isso a chave nunca é guardada junto do banco, e por isso existe o descarte do vínculo antigo (item 10). O mesmo mecanismo, usado a favor do titular, é o que permite localizar os registros de uma pessoa que apresente o próprio CPF ao exercer seus direitos (item 12).

O inventário é, na maior parte, cadastro de coisas — mas três pontos dele são dado pessoal, e a diferença em relação ao módulo financeiro importa: aqui não há pseudonimização, o dado fica como foi digitado ou lido.

• Dados do bem. Nome, descrição, categoria e subcategoria, marca, modelo, número de série, data e valor de aquisição, fornecedor (texto livre), garantia, quantidade, campus, prédio e ambiente, ministério ou departamento, estado de conservação, situação e origem.
• Pessoas ligadas a um bem. A pessoa responsável por um bem, quem o movimentou, quem abriu ou conduz uma manutenção e quem cadastrou uma nota são sempre contas do próprio sistema — não existe cadastro de pessoas à parte. Ministérios e departamentos são apenas nomes de grupos.
• Doação de bem. Quando um bem entra por doação, o sistema guarda o nome de quem doou, a data, o valor estimado e o documento anexado. Esse nome é digitado por quem cadastra e fica gravado em claro — é o dado pessoal de terceiro mais exposto do módulo.
• Notas fiscais. O arquivo da nota é guardado, e dele são extraídos CNPJ e nome do fornecedor, número, série, data de emissão, valor total, a chave de acesso de 44 dígitos e os itens (descrição, marca, modelo, número de série, quantidade e valores), além da saída bruta da leitura. A chave de acesso merece nota própria: os dígitos 7 a 20 dela são o CNPJ do emitente, e com ela em mãos qualquer pessoa consulta a nota inteira no portal da SEFAZ, com valores e itens. Por isso ela é tratada como dado sensível de fornecedor dentro do sistema (itens 9 e 11).
• Fotos e documentos. Fotos do bem, documentos anexados, comprovante de doação, documento de baixa e anexos de manutenção ficam em armazenamento privado, sem link público, em um caminho que começa pelo identificador da igreja. As imagens são exibidas por links temporários, válidos por uma hora.
• Movimentações, manutenções e conferências. Origem e destino de cada movimentação, quem movimentou, motivo e observações; tipo, descrição do problema, fornecedor, responsável, custo e situação de cada manutenção; e as sessões de conferência com o resultado de cada leitura.
• Câmera, no leitor de QR Code. A câmera só é aberta depois de um clique na tela do leitor, nunca ao carregar a página. A imagem é processada dentro do próprio aparelho, pelo navegador: nenhuma foto e nenhum quadro de vídeo é enviado ao servidor — o que sai do aparelho é apenas o código lido da etiqueta.

A etiqueta impressa de um bem abre uma página que não exige login. É o único ponto da plataforma em que dado gravado sai para fora do círculo de quem tem conta, então vale detalhar o que ela mostra e o que não mostra.

• Mostra: código, nome do bem, categoria, marca, modelo, estado de conservação, campus, prédio, ambiente, ministério, nome da pessoa responsável pelo bem, a foto principal e o nome da igreja.
• Não mostra: valor de aquisição, nota fiscal, fornecedor, dados de doação, manutenções, movimentações e qualquer histórico — esses campos não existem na consulta pública, nem para quem a executa no servidor.
• Não permite listar. A consulta é sempre por um código exato, que só conhece quem tem a etiqueta na mão; não há busca, índice nem listagem de bens, e a foto é servida por link temporário de uma hora.

O nome da pessoa responsável é, portanto, publicado sem autenticação junto do bem sob sua guarda. [A DEFINIR: avaliar com o jurídico se o nome do responsável deve continuar aparecendo nessa página, ou se basta o ministério].

• Calcular e apresentar os indicadores de saúde financeira da igreja.
• Permitir que a comissão de contas acompanhe receitas, despesas, orçado × realizado e variações fora do padrão.
• Localizar, identificar e conferir o patrimônio da igreja, acompanhar movimentações e manutenções e manter o histórico de cada bem.
• Controlar quem acessa o sistema e registrar o que cada um fez.
• Enviar convite de acesso, redefinição de senha e alertas de fechamento por e-mail.

Os dados não são usados para publicidade, não são vendidos e não são compartilhados com terceiros além dos prestadores listados no item 9.

Base legal do tratamento: [A DEFINIR: mapear a base legal de cada finalidade (art. 7º e, se aplicável, art. 11 da LGPD) com o jurídico — obrigação legal/regulatória, legítimo interesse, execução de contrato ou consentimento. Incluir no mapeamento o nome de doador de bem, que é dado de terceiro digitado por quem cadastra, sem contato prévio do titular com o sistema]. Este rascunho não afirma nenhuma base legal por conta própria.

Dentro da igreja. O acesso é por perfil, definido módulo a módulo — a mesma pessoa pode ter um perfil em um módulo e nenhum acesso a outro. Visualizador vê os painéis e listagens da própria igreja (em Finanças, números agregados, sem identificador de doador); operador executa a rotina do módulo (importar extrato, resolver a fila de revisão e lançar saldos; cadastrar bens, importar notas, movimentar, registrar manutenção, conferir); administrador ajusta configurações e vê a auditoria do módulo. Verificação em duas etapas é obrigatória para todo usuário, independentemente do perfil.

Entre igrejas. Cada igreja enxerga apenas os próprios dados, e essa separação não depende só da aplicação: é imposta pelo banco de dados, que filtra cada consulta pela igreja do usuário autenticado. Existe, porém, um perfil administrativo da rede — hoje com pouquíssimas pessoas — que enxerga todas as igrejas: escolhe qual está visualizando, alcança os dados de qualquer uma delas nos dois módulos e gere usuários e acessos de todas. Toda troca de igreja e toda alteração de acesso fica registrada na auditoria e dispara alerta aos administradores.

Prestadores. Para funcionar, o sistema se apoia em:

• Supabase — banco de dados, autenticação e armazenamento privado dos arquivos (extrato bruto, fotos, notas fiscais e documentos do inventário).
• Vercel — hospedagem e execução da aplicação.
• Resend — envio de e-mail transacional (convite, redefinição de senha, alerta de fechamento). Recebe nome e e-mail do destinatário.
• Sentry — registro de erros da aplicação. Antes de sair, cada relatório passa por uma higienização que mascara CPF, valor monetário, chave de acesso de NF-e e CNPJ, descarta campos cujo nome indica dado sensível, remove o corpo da requisição, os cookies e a query string, e reduz a identificação de quem usava o sistema a um identificador interno — sem nome, e-mail ou IP.
• Telegram — canal auxiliar de alerta de segurança para os administradores, usado só em eventos de acesso: convite, login negado, troca de igreja por administrador da rede, alteração de acesso, concessão ou revogação do perfil administrativo da rede, ativação e desativação de conta, expurgo e criação de igreja nova. Recebe o nome da igreja, o nome de quem agiu, o e-mail da conta envolvida, o módulo e o perfil alterado, e as contagens do expurgo. Não recebe dado financeiro, não recebe CPF e nenhuma ação do módulo de inventário gera alerta.

Região de armazenamento e transferência internacional: [A DEFINIR: confirmar a região do projeto Supabase e da hospedagem, e o instrumento de transferência internacional aplicável (art. 33 da LGPD)]. Contratos de operador com cada prestador: [A DEFINIR: formalizar com o jurídico].

Em Finanças, o sistema tem prazo de retenção configurável para os dois itens de maior exposição, e um expurgo que o administrador executa de forma deliberada — com prévia do que será apagado e confirmação explícita. Não há apagamento automático e silencioso.

• Arquivo bruto do extrato — apagado do armazenamento depois do prazo. É o item que ainda contém CPF em texto.
• Vínculo pseudonimizado do doador — o código doador_ref é removido dos lançamentos antigos, que passam a não ter mais nenhuma ligação com a pessoa que doou.

O que o expurgo não apaga: os lançamentos em si (data, valor, categoria), os fechamentos, as metas, os registros de auditoria e todos os números dos painéis. O histórico financeiro da igreja continua íntegro depois do expurgo.

Prazo padrão configurado no sistema: 60 meses para os dois itens. O prazo definitivo depende de [A DEFINIR: prazo de guarda exigido pela legislação contábil/fiscal e pelas normas internas da igreja, a confirmar com contabilidade e jurídico].

Em Inventário não existe expurgo. Dizer o contrário seria falso: a retenção configurável alcança hoje apenas os dois itens financeiros acima. Fotos, notas fiscais com CNPJ e chave de acesso, nome de quem doou um bem, movimentações e manutenções permanecem enquanto o registro do bem existir — e a baixa de um bem não apaga a linha, apenas a marca como baixada, para preservar o histórico. Prazo de guarda e destino desses dados: [A DEFINIR: definir prazo de guarda para os dados do inventário — especialmente nome de doador de bem, notas fiscais e fotos — e se haverá expurgo equivalente ao do módulo financeiro]. Os demais dados — cadastro de usuário, lançamentos, auditoria — também não têm prazo de descarte definido neste rascunho: [A DEFINIR: definir prazo de guarda para cada categoria].

Chamados de suporte ficam guardados enquanto a conta de quem abriu existir e são apagados junto com ela. Não há prazo de descarte automático além disso.

• Todo acesso exige autenticação em duas etapas, em qualquer perfil.
• Cada consulta ao banco é filtrada pela igreja do usuário autenticado, por regra do próprio banco de dados e não apenas por código da aplicação. Vale para os dois módulos.
• Os arquivos — extrato, fotos, notas fiscais e documentos — ficam em armazenamento privado, sem link público, isolados por igreja no próprio caminho do arquivo, e são exibidos por links temporários de uma hora.
• A chave que gera o código do doador fica fora do banco de dados.
• Relatórios de erro são higienizados antes de sair da aplicação: CPF, valor, chave de NF-e e CNPJ são mascarados, e campos de nome sensível são descartados inteiros.
• Tentativas repetidas de login e de recuperação de senha são limitadas, e a página só carrega recursos da própria origem.
• Toda alteração relevante é registrada com autor, data, hora e origem.
• Nenhuma medida elimina risco por completo. Em caso de incidente com risco relevante aos titulares, a comunicação segue o previsto no art. 48 da LGPD: [A DEFINIR: definir procedimento e prazo interno de resposta a incidente].

A LGPD assegura ao titular, entre outros, os direitos de confirmar a existência de tratamento, acessar seus dados, corrigi-los, solicitar anonimização, bloqueio ou eliminação, e obter informação sobre com quem foram compartilhados (art. 18).

Na prática, para contribuintes vale o seguinte: como o CPF não é armazenado, o sistema não consegue procurar alguém por nome. Ele consegue localizar os lançamentos de quem apresentar o próprio CPF, recalculando o código a partir dele.

Para quem doou um bem ao inventário, o caminho é o inverso: o nome está gravado em texto e pode ser localizado por busca, junto do bem doado, da data e do valor estimado.

O atendimento a esses pedidos, os documentos exigidos para comprovar identidade e o prazo de resposta são [A DEFINIR: definir procedimento de atendimento ao titular]. Canal para exercer esses direitos: [A DEFINIR: e-mail ou formulário de contato do titular].

Encarregado (DPO): [A DEFINIR: nome]. Contato: [A DEFINIR: e-mail e telefone do encarregado]. A indicação e a divulgação do encarregado são exigidas pelo art. 41 da LGPD.

Esta política pode ser atualizada. A forma de aviso aos titulares e a política de versões anteriores são [A DEFINIR: definir]. Versão atual: rascunho, sem data de vigência — [A DEFINIR: data de vigência após aprovação]. Última revisão técnica do texto, feita sobre o código: 21/09/2026.