Seção 01
Multi-tenant + LGPD
Operação multi-tenant exige clareza de papéis e prazos. Esta matriz separa o que já está em código (verificável no repositório), o que vai no anexo contratual e o que está mapeado para Y2-Y3 conforme volume escalar — sem zona cinza em fiscalização.
01 · Implementado · em código
Ativo · verificável hoje
Controles técnicos rodando em produção. Inspecionáveis no repositório.
- Multi-tenant isolationToda query carrega workspaceId. Server Actions chamam assertWorkspaceAccess antes de qualquer mutation. Vetores RAG isolados por tenant — zero leakage cross-cliente.
- HMAC verification em webhooksMeta WABA e callbacks externos assinados com X-Hub-Signature-256. Payload não-autêntico é rejeitado antes do parse.
- Opt-in explícito (LGPD art. 7º)Banner de consent rastreia preferências por categoria. Sem aceite, automações de tracking e bot WhatsApp não persistem conteúdo.
- Audit log de efeitos colateraisToda ação destrutiva ou tool call em IA gera log com timestamp, ator, payload e workspace. Auditável por admin e exportável.
- Lista de permissões de entrada do botBot WhatsApp só lê campos explicitamente autorizados antes de executar tool. Bloqueia exfiltração de dados sensíveis via prompt injection.
- AES-256-GCM em credenciaisTokens Google Ads/Meta Ads, secrets externos. TLS 1.3 in-transit. Postgres com encryption-at-rest. Vault para segredos.
- Tracking sem PIIEventos agregados, scoring 0–10, sem identificador pessoal no payload. Logs de produto separados de logs de comunicação.
02 · Contratual · anexo
Anexo LGPD do contrato
Cláusulas formais que regem responsabilidades, direitos e prazos. Anexadas ao contrato-base.
- Papéis definidos (LGPD art. 5º)Controlador: cliente. Operador: Crux9. Titular: usuário final. Cláusula explícita evita ambiguidade em fiscalização ANPD.
- Direitos do titular operacionalizadosAcesso, retificação, eliminação, portabilidade e revogação de consentimento — atendidos via portal ou contato com SLA contratual.
- Lista de subprocessadoresProvedores de LLM, infra, email e storage listados em /legal §3. Atualização notificada com 30 dias de antecedência.
- Retenção configurávelDefault 12 meses para conversas. Cliente ajusta por categoria (lead, deal fechado, escalonamento). Eliminação automática após prazo.
- Resposta a incidentes · 72hVazamento confirmado → notificação ao cliente em ≤4h, à ANPD em ≤72h, aos titulares afetados conforme art. 48.
- Portabilidade na saídaRescisão → export em JSON estruturado (conversas, leads, audit log) entregue em ≤15 dias. Eliminação verificada com hash.
- DPO · canal de contatoCliente designa Encarregado formal. Crux9 mantém canal técnico para incident response e direitos de titular.
03 · Roadmap · conforme escalar
Y2-Y3 · disparado por gatilho
Itens mapeados, ativados quando volume ou exigência regulatória justificar. Não vendidos como Y1.
- Right-to-be-forgotten automatizadoHoje é manual via canal de contato. Y2 → portal self-serve com confirmação por SMS e eliminação verificável em ≤72h.
- RIPD/DPIA formalRelatório de Impacto à Proteção de Dados disparado quando volume passar de N conversas/dia ou agente assumir nova categoria sensível.
- Auditoria externa anualY2 · empresa terceira certificada audita perímetro (webhook, portal, DB). Relatório compartilhado com clientes contratantes.
- Bias check semestralTestes adversariais no agente (gênero, raça, faixa de renda, sotaque regional). Falha → ajuste de prompt + RAG documentado.
- Logs SOC2-gradeY2-Y3 · audit trail imutável (append-only), retenção 7 anos, separação de papéis no acesso. Pré-requisito para clientes enterprise.
- ANPD compliance review anualRevisão jurídica anual com escritório especializado em proteção de dados. Atualizações regulatórias incorporadas no anexo.
- Plataforma de gestão de consentimentoY3 · se volume justificar, integração com CMP padrão (OneTrust ou similar). Hoje consentimento é auditável mas não centralizado em UI.
O que isso significa em prática: a Crux9 é responsável tecnicamente por implementar e manter os controles. O cliente é responsável legalmente por definir finalidade e responder a titulares. O contrato deixa essa divisão explícita.
Seção 02
Autenticação & criptografia
- Link mágico ou credencial. Sessões em cookie httpOnly + sameSite=lax, persistidas em banco com TTL curto. Sem token em localStorage.
- Criptografia AES-256-GCM em tokens sensíveis (Google Ads, Meta Ads). Hashing forte em senhas.
- TLS 1.3 end-to-end. Banco sem exposição pública (só rede privada).
- RBAC com 5 papéis. Cada Server Action checa role antes da mutation.
Seção 03
Infraestrutura própria
- Auto-hospedado em KVM dedicado — sem tenancy compartilhado em cloud pública.
- SSH autenticado por chave, login root bloqueado, banco só via rede privada.
- Backup diário com hash SHA-256 verificado. Retenção local 14d + offsite em repositório privado independente do host.
- Gestão de processos com reinicialização automática e monitoramento contínuo.
Seção 04
Deploy controlado
- Verificações de qualidade: tipos, lint, build e testes passam antes de qualquer merge.
- Staging valida antes de prod. Soak time obrigatório.
- Promoção pra prod exige clique humano. Agentes de IA não podem disparar deploy de produção.
- Observabilidade + verificação externa monitoram cada release. Reversão rápida.