Contrato de Tratamento de Dados Pessoais (DPA)

Última atualização: 2026-11-04

Sumário

• 1. Definições
• 2. Papéis: quem é controlador e quem é operador
• 3. Objeto e finalidade
• 4. Escopo do tratamento
• 5. Subprocessadores
• 6. Medidas de segurança
• 7. Direitos dos titulares
• 8. Eliminação ao término do contrato
• 9. Notificação de incidente
• 10. Retenção e backups
• 11. Auditoria
• 12. Transferência internacional
• 13. Vigência, alterações e disposições finais
• Anexo I — Subprocessadores
• Anexo II — O que este documento ainda não pode prometer

Qualificação das partes

Este adendo integra os Termos de Uso e prevalece sobre eles em qualquer conflito relativo a tratamento de dados pessoais.

1. Definições

Os termos dado pessoal, titular, controlador, operador, tratamento, eliminação e incidente de segurança têm o significado que lhes dá a Lei nº 13.709/2018 (LGPD).

Além deles, este documento usa:

2. Papéis: quem é controlador e quem é operador

A Controladora é a cliente. A Operadora é o SupaBrain. Esta é a cláusula da qual todo o resto decorre, e é por isso que ela vem antes de qualquer descrição técnica.

Em termos práticos:

A Operadora trata dados pessoais exclusivamente conforme instrução da Controladora, materializada nas fontes que ela seleciona no produto. A Operadora não usa o acervo de uma cliente para nenhuma finalidade própria — não o utiliza para treinar modelos, não o analisa para produzir estatísticas de mercado, e não o compartilha com outra cliente.

A escolha das fontes é a instrução. Não há um canal separado de instruções por escrito porque não há tratamento separado da seleção: o que a Controladora seleciona é exatamente o que é tratado, e o que ela não seleciona não é lido.

3. Objeto e finalidade

A Operadora trata o acervo para uma única finalidade: indexar as fontes designadas e permitir que membros autorizados da Controladora as recuperem por busca semântica, busca textual e respostas com citação da origem.

Isso compreende, e se esgota em:

1. Ler o conteúdo das fontes designadas;
2. Segmentá-lo, destilá-lo e resumi-lo para torná-lo recuperável;
3. Gerar vetores de embedding a partir do texto destilado;
4. Armazenar o texto bruto, o texto destilado, os vetores e os metadados;
5. Responder a buscas de membros autorizados, reordenando e citando trechos;
6. Construir um grafo de entidades sobre o material já indexado;
7. Registrar em log as buscas realizadas, para auditoria da própria Controladora;
8. Quando o armazenamento de mídia está ativado na instalação, reter os arquivos de mídia originais (fotos, mensagens de voz, documentos anexados) pelo prazo da Política de Armazenamento configurada pelo administrador da Controladora (1 a 730 dias), para que uma resposta que cite uma transcrição possa entregar o arquivo que a originou.

Qualquer finalidade fora desta lista exige nova instrução por escrito da Controladora.

Sobre o item 8 — retenção versus eliminação, sem confusão possível. A Política de Armazenamento é uma política de armazenamento: ao expirar o prazo, o arquivo é excluído do bucket, e as transcrições, o texto de OCR e o conhecimento extraído permanecem no acervo — eles são o conteúdo indexado objeto deste contrato. Reduzir o prazo exclui imediatamente os arquivos mais antigos que o novo limite, porque a expiração é calculada contra a política vigente, nunca contra a que estava em vigor quando o arquivo chegou. Um pedido de eliminação de titular (§7.4) é coisa distinta e mais ampla: ele exclui tanto os arquivos originais do titular quanto as transcrições, o texto de OCR e as linhas do acervo derivadas deles. A exclusão da organização (§7.3 e §8) remove o prefixo inteiro do bucket da organização, e a verificação pós-exclusão confere que o bucket ficou vazio.

4. Escopo do tratamento

O escopo não é uma promessa de política: é o comportamento padrão do banco de dados. Nas duas fontes suportadas, o padrão é nada selecionado.

4.1 WhatsApp — nenhum grupo é indexado sem seleção explícita

Uma conta de WhatsApp pareada enxerga todos os grupos de que o aparelho participa, inclusive os pessoais. O SupaBrain lista os grupos para que a Controladora escolha, e nenhuma mensagem de um grupo não selecionado entra no acervo.

Tecnicamente, a coluna is_selected da tabela whatsapp_groups é not null default false: um grupo recém-descoberto nasce fora do acervo, e todo caminho de ingestão filtra por essa coluna. Desmarcar um grupo elimina as linhas dele, não as oculta.

Implementado por WA-05; o comportamento é verificado por services/baileys/src/groups.test.ts, cujo teste 2 falha se qualquer grupo recém-sincronizado nascer selecionado.

4.2 Google Drive — nenhuma pasta é indexada sem seleção explícita

Vale o mesmo, e o risco é maior: uma conta Google conectada alcança arquivos de RH, planilhas de salário e documentos societários. A coluna is_selected da tabela drive_folders é igualmente not null default false, a seleção é feita pasta a pasta, e include_subfolders é uma decisão por seleção — "esta pasta e tudo abaixo dela" e "só esta pasta" são coisas diferentes e ambas são comuns.

Nenhum arquivo fora de uma pasta selecionada é lido. Desmarcar uma pasta elimina as linhas dela.

Implementado por GD-03; verificado por services/ingest-worker/src/connectors/gdrive/folders.test.ts, cujo teste 4 é a garantia de opt-in.

5. Subprocessadores

5.1 A lista, e o que a mantém verdadeira

Os suboperadores da Operadora estão no Anexo I deste contrato e, em versão pública e comentada, em `docs/SUBPROCESSORS.md` e na página /subprocessadores. As três superfícies descrevem a mesma lista.

Uma lista de suboperadores escrita à mão fica correta exatamente uma vez. Por isso ela não é mantida à mão: scripts/check-subprocessors.ts roda no CI, varre o código em busca de destinos de rede e reprova o build nos dois sentidos — um fornecedor que o código chama e a lista não menciona, e um fornecedor listado que o código não referencia mais. O segundo caso importa tanto quanto o primeiro, porque declarar um fornecedor que já não é usado exagera o compartilhamento dos dados da Controladora.

Implementado por SEC-04; verificado por scripts/check-subprocessors.test.ts, e o Anexo I deste contrato é comparado célula a célula com docs/SUBPROCESSORS.md por scripts/check-commitments.ts.

5.2 Aviso prévio de alteração

A Operadora avisará a Controladora antes de contratar um novo suboperador que receba conteúdo do cliente — isto é, um que veja o texto que as pessoas da Controladora escreveram. Fornecedores que recebem apenas identificadores ou metadados operacionais são incluídos na lista e comunicados na atualização periódica, sem aviso individual.

Ainda não verificado. Não existe hoje nenhum mecanismo que dispare esse aviso: o CI garante que a lista publicada esteja correta, e não que alguém tenha sido avisado antes da mudança. O compromisso é contratual e depende de processo humano. Um prazo de aviso e um direito de objeção da Controladora precisam ser definidos na revisão jurídica.

6. Medidas de segurança

Esta seção é deliberadamente segmentada. Cada subseção separa o que é verificado por teste automatizado do que é descrição de configuração — porque um contrato que mistura as duas coisas transforma uma intenção de arquitetura em uma garantia contratual sem que ninguém perceba.

6.1 Credenciais em repouso: AES-256-GCM

As credenciais de conector — a sessão do WhatsApp pareado e o token OAuth do Google Drive — são cifradas com AES-256-GCM antes de tocarem o banco, com IV aleatório por operação e byte de versão no cabeçalho. A chave vem de ENCRYPTION_KEY e é guardada no cofre de segredos, fora do banco que ela protege.

GCM e não CBC porque é autenticado: adulteração falha alto na decifragem, em vez de produzir lixo plausível que segue adiante. O que se protege aqui é categoricamente pior que conteúdo indexado — uma sessão do Baileys é um login funcional do WhatsApp da Controladora, e um refresh token do Drive é acesso contínuo ao Drive dela.

Implementado por SEC-01; verificado por packages/core/src/crypto/aes.test.ts, que assegura, entre outras coisas, que duas cifragens do mesmo texto produzem saídas diferentes (frescor do IV) e que nenhuma mensagem de erro carrega material de chave ou texto claro.

6.2 O acervo em repouso não é cifrado em nível de aplicação

Ainda não verificado. A cifragem descrita em §6.1 cobre credenciais, não o acervo. O texto bruto, o texto destilado, os vetores e os metadados ficam em colunas comuns do PostgreSQL, protegidos pelo isolamento lógico de §6.5 e pelos controles de acesso da infraestrutura — não por criptografia de aplicação. Se a Railway cifra o volume subjacente em repouso, isso não foi verificado a partir deste repositório e não é afirmado aqui.

Dizer "seus dados são criptografados" seria verdade para um pedaço pequeno do sistema e falso para a parte que a Controladora tem em mente ao fazer a pergunta.

6.3 Em trânsito, na borda pública

O aplicativo web é servido exclusivamente por HTTPS, com HSTS de dois anos incluindo subdomínios, X-Frame-Options: DENY, X-Content-Type-Options: nosniff e Referrer-Policy: strict-origin-when-cross-origin. Todas as chamadas para fornecedores de IA e para as APIs do Google e da Meta são feitas sobre https://.

Implementado por WEB-12; os cabeçalhos são exigidos por apps/web/deploy.test.ts, que reprova o build se qualquer um deles sair da configuração de deploy.

6.4 Em trânsito, entre os componentes internos

Ainda não verificado. O tráfego interno tem duas naturezas e nenhum teste automatizado as afirma:

• Vercel → PostgreSQL da Railway. É a única aresta em que tráfego de banco sai da rede da Railway, e a documentação de operação a descreve como TLS público (DEPLOYMENT). Não há, no código, nenhuma asserção de que a string de conexão exija TLS — a exigência mora na configuração da variável de ambiente, e uma configuração pode ser trocada sem reprovar o build.
• Entre serviços dentro da Railway. Usa http://, e não https://, deliberadamente: o salto já trafega dentro da rede privada cifrada por Wireguard e não há terminador TLS atrás de um hostname interno. É seguro pelo transporte subjacente, não por TLS, e a diferença é registrada aqui porque um questionário de conformidade que pergunta "TLS em todas as conexões?" merece esta resposta e não um "sim".

6.5 Isolamento entre clientes

Toda tabela que carrega dados de cliente tem row-level security habilitada no PostgreSQL, com política de leitura por organização. A identidade de quem consulta chega como variável de sessão local à transação, e uma conexão que nunca a definiu não enxerga nada — falha fechada, não aberta.

A tabela do acervo tem uma política dupla: além da organização, ela respeita a lista de acesso da própria linha, porque a lista amplia visibilidade dentro de uma organização e nunca substitui a participação nela. O aplicativo web conecta com um papel que detém apenas SELECT e não é superusuário — o papel padrão da Railway ignoraria todas as políticas.

Implementado por FND-11; verificado por packages/core/src/db/rls.test.ts, que testa a aplicação das políticas e não apenas o formato delas: um membro lê a própria organização e nenhuma linha da outra, em ambos os sentidos.

7. Direitos dos titulares

7.1 Prazo

A Operadora auxiliará a Controladora a atender pedidos de titulares em até 15 (quinze) dias contados do recebimento do pedido pela Operadora, prazo alinhado ao art. 19 da LGPD.

Ainda não verificado. É um compromisso de processo, não uma propriedade do sistema: nada mede esse prazo, não há fila de pedidos instrumentada e não há alerta de vencimento. Além disso, os mecanismos de §7.3 e §7.4 ainda não estão implementados, de modo que hoje o prazo só é cumprível para o direito de acesso (§7.2), e manualmente para os demais.

7.2 Acesso: exportação completa do acervo da organização

A Controladora pode exportar, a qualquer momento e sem intervenção da Operadora, todo o acervo da sua organização: organização e membros, conectores e sua configuração, projetos, conteúdo indexado com texto bruto e texto destilado, o log de buscas e o registro de consultas a bases públicas.

Três características importam mais do que parecem:

• O conteúdo sai em JSONL, uma linha por item, para que um acervo de vários gigabytes seja transmitido e processado em fluxo, sem precisar caber na memória de ninguém.
• Nenhuma credencial é exportada. Sessões e tokens ficam de fora integralmente: um export é um arquivo que a Controladora encaminha por e-mail, e ele não pode conter um login funcional do WhatsApp dela.
• O arquivo traz um README.md em português explicando cada formato, porque quem o recebe costuma ser o encarregado de dados, não uma pessoa de engenharia.

Implementado por SEC-02; verificado por packages/core/src/export/org-export.test.ts, cujos testes 7 e 8 são os que impedem que um export vire um vazamento, e cujo teste 11 assegura que o acervo de outra organização está ausente.

7.3 Eliminação do acervo da organização, com recibo

A eliminação completa de uma organização — treze tabelas, o armazenamento de sessões cifradas, o grafo de conhecimento, o cache de destilação e a fila de trabalhos — está especificada em SEC-03 e ainda não está implementada. O teste que a comprova, packages/core/src/deletion/org-deletion.test.ts, não existe no repositório nesta data.

O que a especificação prevê, e o que será verdade quando ela estiver implementada: eliminação irreversível mediante confirmação do nome da organização por um titular da conta, uma varredura pós-eliminação que procura resíduo em todas as tabelas, e um recibo com as contagens do que foi removido e o resultado dessa varredura. A varredura é o ponto: código de eliminação que esquece uma tabela é idêntico, por fora, a código que funciona.

A implementação existe e é executável de ponta a ponta: a exclusão roda como um trabalho assíncrono sob a função de serviço do banco, porque a função do aplicativo web não tem — deliberadamente — permissão de exclusão. A varredura de verificação deriva a lista de tabelas do próprio esquema (pg_class), de modo que uma tabela criada no mês que vem é coberta sem que ninguém edite código.

Uma ressalva honesta: o grafo de conhecimento (Cognee) não é limpo por este procedimento, e o recibo registra isso como cogneeCleared: false. A exclusão do acervo em PostgreSQL não é bloqueada por isso.

7.4 Direitos de um titular individual, que nunca assinou nada

Esta é a cláusula que a Controladora mais precisa entender antes de indexar WhatsApp.

Os grupos de WhatsApp de uma empresa contêm mensagens de clientes, fornecedores, candidatos e ex-funcionários. O SupaBrain persiste todas elas. A Controladora é quem recebe um pedido de acesso ou de eliminação de uma dessas pessoas — que nunca assinou contrato algum com ninguém — e é quem tem de atendê-lo.

Atender esse pedido não é apagar uma linha. Depois da destilação, uma pessoa está no texto bruto, no transcript retido para busca textual, no resumo destilado que pode citá-la, nos metadados de participantes, no vetor derivado do texto que a menciona, nas linhas filhas e no grafo de entidades. Apagar o documento de origem inteiro seria outra violação, porque ele carrega as mensagens das outras pessoas da conversa. O procedimento correto é redigir dentro do payload e re-derivar o que dele descende.

Isso está especificado em SEC-08 e está implementado. O ponto que torna a garantia real é o vetor: apagar o texto e deixar o embedding para trás parece conformidade e não é, porque o vetor ainda codifica o conteúdo removido e ainda responde a buscas sobre aquela pessoa. O teste 8 de subject.test.ts falha exatamente nesse atalho.

Uma mensagem compartilhada é redigida dentro da carga original e as unidades afetadas são re-destiladas e re-vetorizadas; apagar a conversa inteira eliminaria os dados dos outros participantes, o que seria outra violação.

8. Eliminação ao término do contrato

Encerrado o contrato, e ressalvado o §10, a Operadora eliminará o acervo da Controladora em até 30 (trinta) dias, contados do término ou do pedido expresso de eliminação, o que ocorrer primeiro. A Controladora tem, nesse mesmo período, o direito de exportar o acervo por §7.2 antes da eliminação.

A eliminação produz o recibo descrito em §7.3, com as contagens por tabela e o resultado da varredura de verificação. É o mesmo mecanismo de SEC-03, acionado pelo término em vez de por um pedido.

9. Notificação de incidente

Ainda não verificado. A Operadora comunicará à Controladora qualquer incidente de segurança que possa acarretar risco ou dano relevante aos titulares em até 48 (quarenta e oito) horas do momento em que dele tomar conhecimento, informando o que se sabe até então: natureza dos dados atingidos, titulares envolvidos, medidas técnicas já adotadas e riscos identificados. A comunicação à ANPD e aos titulares, quando devida, cabe à Controladora, e a Operadora fornecerá as informações necessárias para que ela a faça.

O compromisso é de processo e não existe procedimento documentado por trás dele: não há runbook de resposta a incidente neste repositório, não há canal de plantão definido e nada mede as 48 horas. O relato de erros de aplicação (Sentry) recebe apenas identificadores, nunca conteúdo, o que significa que ele detecta falha de software e não detecta acesso indevido a dados.

10. Retenção e backups

10.1 Os backups retêm dados já eliminados

Ainda não verificado. Esta é a exceção honesta a §7.3 e §8, e ela é material: uma eliminação remove o dado do sistema em operação, não dos backups. Enquanto uma cópia de segurança que contenha aquele dado existir, ele é tecnicamente recuperável por quem opera a infraestrutura.

A retenção prevista em `docs/RUNBOOK-BACKUP.md` é:

Portanto, o horizonte máximo em que um dado eliminado ainda pode existir em alguma cópia é de aproximadamente 3 (três) meses. Após a expiração da cópia mais antiga que o contenha, ele deixa de existir também ali.

Duas ressalvas que impedem que esses números sejam apresentados como garantia: a retenção acima é a prevista no runbook, e o próprio runbook registra que não foi confirmado, a partir do ambiente em que foi escrito, se os agendamentos de backup da Railway estão de fato habilitados; e a retenção efetivamente configurada ainda não foi anotada. Enquanto isso não for feito, o número de três meses é um teto de projeto e não uma medição.

10.2 Verificação dos backups

Ainda não verificado. scripts/verify-backup.ts verifica se o backup mais recente existe, se é recente o bastante para o objetivo de ponto de recuperação (1 hora), se tem tamanho plausível e se cobre todas as tabelas que as migrações declaram — a falha que ele existe para pegar é "os backups pararam há seis semanas e ninguém notou".

A lógica desse verificador é testada por scripts/verify-backup.test.ts (OPS-07). O que não está estabelecido é o mais importante: nenhum ensaio de restauração foi realizado. O runbook diz isso com todas as letras — "não cite este runbook como prova de que os backups do SupaBrain são restauráveis; eles são, nesta data, não testados" — e um backup não testado não é um backup. Um verificador de inventário confirma que existe um arquivo; ele não confirma que o arquivo restaura.

10.3 Minutas redigidas pelo SupaLaw, e o uso para treinamento

Quando a organização usa o modo de redação de minutas do SupaLaw, o pedido do usuário e a minuta gerada contêm, por natureza, dados pessoais: nomes das partes, CPF/CNPJ, endereço do imóvel e valores. Três decisões de projeto delimitam o que acontece com esse material, e todas são verificáveis no código.

1. A conversa fica no acervo da organização e é eliminável. Conversas, mensagens e todas as versões de cada minuta ficam em tabelas próprias (agent_conversations, agent_messages, agent_draft_versions), visíveis apenas ao usuário que as criou dentro da organização. O botão "Limpar histórico" faz eliminação definitiva com cascata — não é marcação lógica — e registra apenas identificadores e contagens, nunca conteúdo (agent_conversation_deletions). É a superfície de eliminação do §7.4 aplicada a este material.

2. O log de auditoria recebe o texto pseudonimizado, nunca o original. query_log é append-only por concessão (migração 0072): a aplicação pode inserir e nada mais, de modo que um dado pessoal ali gravado não pode ser editado depois. Por isso a decisão é tomada antes da inserção: em turnos de redação, nomes qualificados por documento, CPF, CNPJ, CEP, e-mail, telefone, endereço e valores monetários são substituídos por marcadores estáveis (<CPF_1>, <VALOR_1>) por answer/pseudonymize.ts. Os marcadores são tokens, não supressões: preservam a estrutura do documento sem preservar a pessoa. Isto é pseudonimização (art. 13, §4º da LGPD), não anonimização, e não é apresentado como tal — a linha de auditoria continua atribuída à organização e ao usuário.

3. Uso para treinamento depende de consentimento contratual expresso. Nenhum material de uma organização alimenta o treinamento de modelo sem um registro de consentimento em org_training_consent, criado por operação mediante base contratual identificada, nunca pela aplicação. A ausência de registro significa ausência de consentimento, o que torna a recusa o comportamento padrão de toda organização anterior a esta cláusula. Sem esse registro, o turno não recebe a etiqueta training e nenhum par de treinamento é gravado — a verificação cobre as duas escritas relevantes, e não apenas a etiqueta.

Retenção. O material de redação segue a retenção geral desta seção; as linhas pseudonimizadas de query_log seguem a política de retenção do log de consultas. A janela específica para material marcado para treinamento é de, no máximo, 12 (doze) meses a contar da coleta.

11. Auditoria

Ainda não verificado. A Operadora fornecerá à Controladora, anualmente e mediante solicitação, um resumo de segurança contendo: a lista vigente de suboperadores, as medidas técnicas do §6, os incidentes do período e o resultado do teste de isolamento entre clientes.

O teste de isolamento está especificado em SEC-07 — ele ataca todas as superfícies por onde dado pode sair (API de busca, MCP, CLI, aplicativo web, grafo de conhecimento, export e eliminação) usando duas organizações com dados deliberadamente homônimos, para que um vazamento apareça como conteúdo de uma na resposta da outra e não como uma semelhança ambígua.

Ele ainda não foi executado. Nem tests/security/tenant-isolation.test.ts nem o relatório docs/security/PENTEST-2026-07.md existem nesta data. Esta cláusula não afirma que existam resultados de teste de intrusão para entregar; ela cria a obrigação de entregá-los quando existirem. O isolamento que hoje é verificado é o do §6.5, no nível do banco de dados, e não a composição de todas as superfícies.

12. Transferência internacional

12.1 O conteúdo da Controladora é enviado para fora do Brasil

O SupaBrain envia o conteúdo indexado — mensagens de WhatsApp e documentos — para a OpenAI, para a OpenRouter e para a Cohere, e as três o processam nos Estados Unidos. Com o agente SupaLaw, a pergunta, os trechos oficiais recuperados e o texto de arquivos anexados naquele turno também vão para o Tinker (Thinking Machines Lab), nos Estados Unidos. É dito antes de qualquer outra coisa nesta seção porque, para alguns compradores, isso é um impedimento e não uma nota de rodapé.

Como cada uma o vê:

Nenhuma dessas consegue gerar um embedding, destilar um texto, reordenar resultados ou amostrar o adaptador jurídico sem ler o texto. Não há configuração que mantenha esse processamento no Brasil: a alternativa é a versão com embeddings auto-hospedados, prevista para a V2.

Um caso é diferente dos demais e está listado aqui por completude, não por risco: a Hetzner (Inference API), na Alemanha, gera parte do corpus de treino do modelo de domínio a partir do texto oficial das leis brasileiras. Ela não recebe nenhum dado da Controladora — nem conteúdo indexado, nem busca, nem identificador — e a Hetzner declara não armazenar o conteúdo das requisições nem das respostas. O treino LoRA no Tinker usa esse mesmo corpus já selado e, nessa etapa, também não recebe dados da Controladora; a transferência de conteúdo do cliente no Tinker é só a amostragem do SupaLaw, descrita na tabela acima.

Além dessas, também tratam dados fora do Brasil, em alguma medida: Railway (todo o acervo, nos Estados Unidos), Firecrawl (captura das páginas públicas do site informado no onboarding), Hyperbrowser (índices oficiais de diários que recusam um cliente scriptado), Bright Data (egress ISP brasileiro para hosts oficiais .jus.br), SupaSec GLiNER (extração de entidades), TypeSafe (Jev) (julgamentos calibrados sobre texto na esteira de ingestão), Google (conector do Drive), Meta (WhatsApp) (conector do WhatsApp), Resend (e-mails de convite), Stripe (cobrança da assinatura e do excedente de créditos), Sentry (apenas identificadores de erro) e PostHog (métricas de uso, na União Europeia). Ficam no Brasil a computação do aplicativo web na Vercel (gru1, São Paulo), as consultas a registros públicos pela InfoSimples e o conector do ERP Omie. O detalhe de cada um está no Anexo I.

Os conectores da V2 tratam dados fora do Brasil pela mesma natureza de leitura inversa da Google e da Meta — o conteúdo já está com eles: Slack (canais), Microsoft (OneDrive e SharePoint), Notion e Atlassian (Confluence) (documentação), todos nos Estados Unidos. O conector Lynx não tem host público: cada implantação informa o seu, e o local de processamento é portanto definido pela instalação da Controladora — que é a única resposta honesta possível antes de ela existir. Nenhum desses conectores recebe qualquer dado antes de um administrador da Controladora conectá-lo.

Documentado por SEC-04; a lista e os locais são verificados por scripts/check-subprocessors.test.ts, e o Anexo I é comparado com docs/SUBPROCESSORS.md por scripts/check-commitments.ts.

12.2 O acervo é armazenado na Virgínia, e isso não é configurável

O banco PostgreSQL que guarda o acervo, o grafo de conhecimento e o volume associado ficam na região us-east4 da Railway, na Virgínia, Estados Unidos.

A Railway não oferece região na América do Sul. As regiões disponíveis são Califórnia, Virgínia, Amsterdã e Singapura; a Virgínia foi escolhida por ser a mais próxima de gru1. Se o requisito da Controladora é armazenamento em território nacional, hoje o SupaBrain não atende, e nenhuma opção de configuração muda isso.

Vale registrar que são duas decisões separadas, porque tratá-las como uma só é o erro mais comum na leitura desta seção: mudar a região do banco não mudaria a saída de conteúdo descrita em §12.1, já que embeddings, destilação e reordenação acontecem nos Estados Unidos em qualquer configuração.

O aplicativo web roda em São Paulo, mas lê desse banco nos Estados Unidos — a localização da computação não implica localização do dado.

Documentado por SEC-04; verificado por scripts/check-subprocessors.test.ts.

13. Vigência, alterações e disposições finais

1. Vigência. Este adendo vige enquanto vigerem os Termos de Uso, e sobrevive a eles no que for necessário para completar a eliminação do §8 e a expiração dos backups do §10.1.
2. Alterações. Alterações materiais serão comunicadas à Controladora antes de entrarem em vigor. A data no topo deste documento é a da última revisão.
3. Subcontratação. A Operadora responde perante a Controladora pelos atos dos suboperadores do Anexo I como se fossem seus.
4. Auxílio. A Operadora auxiliará a Controladora, na medida do razoável, em relatórios de impacto e em solicitações da ANPD relativas ao tratamento aqui descrito.
5. Lei aplicável e foro. Lei brasileira. O foro é definido nos Termos de Uso e precisa de decisão comercial e revisão jurídica antes da primeira assinatura.

Anexo I — Subprocessadores

A tabela abaixo é copiada literalmente de `docs/SUBPROCESSORS.md`, e scripts/check-commitments.ts compara as duas célula a célula: nome, finalidade, resposta sobre recebimento de conteúdo e local de processamento. Uma divergência entre este anexo e o documento público reprova o build, o que é a única forma conhecida de um anexo contratual não envelhecer.

O documento público traz duas colunas a mais — o detalhe do que cada um recebe e o ponto do código em que a integração aparece — além da situação de instalação de cada credencial em produção, que é a informação que envelhece mais rápido e por isso não é reproduzida em um anexo contratual.

Anexo II — O que este documento ainda não pode prometer

Um DPA que promete o que o sistema não faz é um passivo, não um documento comercial: a diferença aparece durante uma auditoria ou um incidente, que é exatamente quando ela custa mais caro. As cláusulas abaixo carregam Ainda não verificado. e o motivo está registrado, item a item, em `COMMITMENTS.md`.

Documentos relacionados: Termos de Uso · Política de Privacidade · Subprocessadores · Mapa interno de compromissos