O que garante isto, tecnicamente

Isolamento entre igrejas

• Cada igreja só vê os seus próprios dados

  175 tabelas na base, 161 delas com um identificador de igreja (church_id) e políticas de segurança ao nível da linha (Row Level Security) do Postgres — não um filtro que a aplicação possa esquecer de aplicar, mas uma regra que a própria base de dados impõe a qualquer consulta, venha de onde vier.

  information_schema.columns, schema public — lido a 2026-08-13

• A identidade da igreja vem de um token assinado, nunca do pedido

  Qual igreja é 'a minha' é decidido por uma claim assinada dentro da sessão autenticada (JWT), lida no servidor — nunca por um parâmetro que o pedido HTTP possa trazer. Um pedido a fingir-se de outra igreja não muda a resposta.

  current_church_id(), funções RLS do schema public

• 17 fronteiras que têm de recusar mesmo quando outra regra deixaria passar

  Em Postgres, uma política RESTRICTIVE só pode TIRAR acesso — nunca dar. 17 dessas políticas (contra 491 políticas comuns, que só podem dar acesso) protegem especificamente o que não pode ter um erro de programação a expor: notas pastorais, pedidos de oração, conversas com o assistente de IA.

  pg_policies WHERE permissive = 'RESTRICTIVE' — lido a 2026-08-13

• 186 relações que a base recusa fisicamente misturar entre igrejas

  186 das 443 chaves estrangeiras da base cruzam duas colunas (registo + igreja), não uma. Mesmo que uma regra de acesso mal escrita deixasse passar um pedido, a própria base recusa ligar o registo de uma igreja ao de outra — a integridade não depende só da política de segurança estar certa.

  information_schema.table_constraints/key_column_usage — lido a 2026-08-13

Pedidos de oração

• Um pedido de oração anónimo é anónimo mesmo para a equipa pastoral

  Quando alguém marca um pedido como anónimo, o nome e o identificador da pessoa nunca saem da base — as consultas que a equipa pastoral usa devolvem esse campo vazio (NULL) diretamente no servidor, não escondido depois na interface. Não há caminho de código onde o dado sai e a interface só decide não o mostrar.

  get_prayer_wall(), get_prayer_queue() — supabase/migrations/20260726161000_mural_oracao_servidor.sql

Inteligência artificial

• BYOK — a chave do modelo de IA é da igreja, não da plataforma

  Cada igreja pode usar a sua própria chave de API do fornecedor de IA (Bring Your Own Key). Os dados enviados ao modelo não passam por uma conta partilhada entre igrejas.

  src/lib/assistente/definicoes.server.ts, src/lib/assistente/pseudonimizacao.ts

• Pseudonimização antes de qualquer envio ao modelo

  Nomes e outros dados identificáveis são substituídos antes do texto sair para o modelo de IA, e repostos só na resposta final, no lado do servidor.

  src/lib/assistente/pseudonimizacao.ts

• Teto de custo mensal e travão de emergência

  Cada igreja define um limite de despesa mensal com IA; um interruptor manual (travão de emergência) corta imediatamente novas chamadas ao modelo, sem esperar pelo limite.

  src/lib/assistente/limites.server.ts (travaoActivo, limite_mensal_cents)

RGPD, no dia a dia

• Exportação dos próprios dados

  Qualquer pessoa pode pedir os seus dados pessoais em formato legível, gerado a pedido — não é um relatório interno reaproveitado.

  export_my_data(), src/lib/exportCsv.ts (exportToPrintableDocument)

• Anonimização, não só apagamento

  Uma pessoa pode ser anonimizada mantendo o histórico agregado íntegro (ex.: contagens de presenças), sem o nome nem o contacto continuarem associados a esse histórico.

  src/lib/escrita-verificada.ts (fluxo de anonimização)

• Consentimentos e retenção configuráveis por igreja

  Cada igreja define os seus próprios prazos de conservação de dados por tipo de registo, e regista consentimentos separadamente do resto do perfil.

  /admin/retencao, /admin/privacidade

Operação

• Backups exportáveis pela própria igreja

  Uma igreja pode gerar, a qualquer momento, uma cópia de segurança dos seus módulos centrais em CSV, sem depender de um pedido ao suporte.

  /admin/backup, src/lib/backup.server.ts

• Autenticação de dois fatores (TOTP)

  2FA por aplicação de autenticação (TOTP), independente de SMS.

  src/lib/security.ts (enrollTotp, listMfaFactors)

• Auditoria de acessos a dados sensíveis

  Consultas a episódios de cuidado pastoral ficam registadas em auditoria — quem acedeu, quando — não só quem editou.

  audit_log, políticas RESTRICTIVE de care_episode_notes

Em preparação

Estes dois pontos dependem de uma decisão e assinatura da entidade legal responsável — não são um facto técnico que o código já garanta hoje, por isso não entram na lista acima nem se inventam aqui.

• Acordo de Processamento de Dados (DPA)

  Em preparação — depende da entidade legal responsável assinar o acordo. Ainda não publicado.

• Lista pública de subprocessadores

  Em preparação — publica-se junto com o DPA, não antes.