Relatório de Impacto à Proteção de Dados (RIPD)

Versão 2.2 — atualizado em julho/2026 · revisão semestral

1. Identificação

• Controladora: Tria Intermediação de Negócios e Tecnologia LTDA — CNPJ 67.500.188/0001-08 (nome fantasia: Factria) — dados cadastrais e KYC
• Operadora: Tria Intermediação de Negócios e Tecnologia LTDA — CNPJ 67.500.188/0001-08 (nome fantasia: Factria) — dados clínicos dos casos
• Encarregado (DPO): Gabriel Porto — dpo@factria.com.br
• SLA de atendimento: 15 dias (LGPD art. 19)

2. Inventário de Dados (ROPA)

Onde os dados do caso são armazenados. Os dados clínicos do caso ficam no modelo de casos do motor — as tabelas engine_cases (identificação do periciando), engine_case_documents (manifesto dos documentos enviados), case_facts (informações extraídas, sempre com a página de origem) e support_artifacts (rascunhos de apoio, nunca documento final). Toda informação sensível é gravada cifrada em repouso (AES-256), com isolamento por organização (RLS) e por vertical contratado. Continuam na mesma categoria, base legal e retenção acima; o expurgo/anonimização de 90 dias é estendido a essas tabelas antes de qualquer dado real ser gravado nelas.

Quando um vertical não clínico (jurídico, corporativo ou governamental) for contratado, este inventário recebe a categoria e a base legal correspondentes antes do primeiro tratamento — hoje apenas o vertical clínico (Doc) está ativo.

3. Suboperadores

4. Análise de Riscos (com IA generativa)

Veja também a Política de Uso de IA para detalhes do pipeline em cascata e do princípio de minimização.

5. Medidas Técnicas e Organizacionais

TLS 1.3; AES-256 em repouso; OAuth tokens no Vault; RLS habilitada em todas as tabelas — incluindo o modelo de casos do motor (engine_cases, engine_case_documents, case_facts, support_artifacts), com isolamento por organização e por vertical contratado; trilha de decisões imutável (case_audit, somente inserção); logs de acesso a PII (pii_access_audit_log); cron de anonimização (90d), a ser estendido às tabelas de caso acima antes da entrada de dados reais; runbook de incidentes; e2e tests cobrindo isolamento por tenant.

6. Acesso interno de revisão (cross-tenant) — revisor e gestão

No modelo de serviço (ALSP), a revisão humana da minuta de apoio é executada por equipe interna da Factria. Isso implica um acesso interno a dados de casos de múltiplas organizações-cliente — atividade de tratamento aqui documentada, com finalidade, base legal, minimização e controles próprios.

Papéis e superfície de acesso.

• Revisor interno (reviewer_internal): acessa o caso apenas quando ele está disponível para revisão (na_fila) e, após assumi-lo, somente o caso sob sua responsabilidade (em_revisao com claimed_by igual ao próprio revisor). Não há escolha de caso (sem seleção discricionária): o motor entrega o próximo. Não enxerga histórico de outras organizações nem casos fora desses estados.
• Gestão (ops_manager): não possui leitura de dados de caso. Vê apenas métricas agregadas, sem dado pessoal, entregues por função de banco com privilégio definido (security-definer) que retorna somente números.

Papel LGPD e base legal. A Factria atua como operadora (art. 39) — o escritório/perito-cliente permanece controlador. O acesso interno de revisão é medida operacional da própria operadora, executada sob instrução documentada do controlador (contrato/DPA), dentro das mesmas bases legais do titular: exercício regular de direitos em processo (art. 11, II, "d") e, no vertical clínico, tutela da saúde por profissional (art. 11, II, "f"). Não se invoca consentimento do titular (parte adversa) nem legítimo interesse para o dado sensível — a revisão é parte da execução do serviço contratado, não um tratamento autônomo da operadora. Incidem a minimização (art. 6º, III) e as medidas de segurança dos arts. 46-47.

Minimização e controles técnicos (art. 6º, III; art. 46).

• RLS aditiva escopada por estado: o revisor só alcança na_fila e o próprioem_revisao; as políticas de isolamento das organizações-cliente permanecem inalteradas.
• Toda decifragem de dado sensível pelo revisor é registrada em pii_access_audit_log como enforcement (não como boa vontade) — trilha de quem acessou o quê e quando.
• A gestão vê apenas agregados anonimizados (art. 12 — dado anonimizado não é dado pessoal); nunca PII.
• Equipe interna vinculada a dever de confidencialidade contratual; o acesso estende as medidas técnicas da operadora, não cria novo controlador.

Sigilo profissional. O acesso interno não afasta o sigilo do advogado (art. 7º, XIX, Lei 8.906/94) nem o sigilo médico — a equipe de revisão atua como extensão técnica do serviço contratado pelo profissional, sob confidencialidade, e o produto final permanece de autoria e assinatura do profissional (art. 20, LGPD — revisão humana da decisão).

Vedação preservada (art. 11, §4º). Não há compartilhamento de dados sensíveis de saúde entre controladores para vantagem econômica: o acesso é interno à operadora, para o mesmo fim contratado pelo controlador, e a gestão só recebe agregados sem PII.

7. Revisão

Este RIPD é revisado anualmente ou diante de qualquer mudança material no tratamento (novo suboperador, nova finalidade, nova categoria de dado).

Revisão 2.2 (julho/2026): documentada a atividade de tratamento "acesso interno cross-tenant de revisão (revisor/gestão)" — Seção 6 — do modelo de serviço ALSP: operadora sob instrução, minimização por escopo de estado (na_fila / próprio em_revisao), agregados sem PII para a gestão, e auditoria de todo acesso em pii_access_audit_log. Sem novo suboperador e sem nova base legal do titular. Referência técnica: migração de RLS do revisor (reviewer_internal / ops_manager).

Revisão 2.1 (julho/2026): inventário estendido ao modelo de casos do motor (engine_cases, engine_case_documents, case_facts, support_artifacts, case_audit) — mesma categoria clínica, base legal e retenção; sem novo suboperador nem nova finalidade. Encarregado (DPO) nomeado: Gabriel Porto. Pendência registrada: estender o expurgo de 90 dias às novas tabelas antes da entrada de dados reais.