Exportar os dados e mudar de fornecedor

Art. 26.º

Métodos e formatos de exportação

Um admin do workspace exporta todos os dados de uma vez, sem pedir ao suporte.

• Na aplicação: Equipa → Zona de risco → Exportar dados (JSON).
• Pela API: GET /api/v1/workspace/export, autenticado como admin do workspace.
• Formato: um ficheiro JSON em UTF-8 (application/json; charset=utf-8), no formato datavault-export/2, descrito por um JSON Schema público.
• A exportação não tem custo.

O ficheiro tem todas as secções do registo de formatos, onde também está o que fica de fora e o motivo.

Outros formatos legíveis por máquina

Partes dos dados também saem noutros formatos abertos, pela API:

• API REST pública, só de leitura, com o contrato OpenAPI publicado

  Norma: OpenAPI 3.1 · Tipo: application/json

  Ver página

• Regras e contrato de cada dataset como testes dbt

  Norma: dbt (schema.yml) · Tipo: application/yaml

  • GET /api/v1/datasets/{dataset_id}/rules.dbt.yml
  • GET /api/v1/datasets/{dataset_id}/contract.dbt.yml

• Regras de cada dataset, ou do workspace inteiro, como checks SodaCL

  Norma: SodaCL · Tipo: application/yaml

  • GET /api/v1/datasets/{dataset_id}/rules/export
  • GET /api/v1/rules/export

• Regras de cada dataset como suite do Great Expectations

  Norma: Great Expectations 1.x (suite JSON) · Tipo: application/json

  • GET /api/v1/datasets/{dataset_id}/rules/export

• Tabelas de auditoria, SLO, dimensões, PII, governança e registo de consultas

  Norma: CSV (RFC 4180) · Tipo: text/csv

  • GET /api/v1/admin-events/export.csv
  • GET /api/v1/dashboard/slo.csv
  • GET /api/v1/dashboard/dimensions.csv
  • GET /api/v1/dashboard/pii.csv
  • GET /api/v1/governance/scorecard.csv
  • GET /api/v1/catalog/metadata-quality.csv
  • GET /api/v1/cde/dossier.csv
  • GET /api/v1/connections/{connection_id}/query-log/export

• Relatórios, README de datasets, evidência de governança e dossiês

  Norma: Markdown, PDF · Tipo: text/markdown, application/pdf

  • GET /api/v1/reports/{report_id}/export.pdf
  • GET /api/v1/datasets/{dataset_id}/readme.md
  • GET /api/v1/governance/evidence.md
  • GET /api/v1/cde/dossier.md
  • GET /api/v1/compliance/ai-systems/{system_id}/art10.md

Arts. 25.º e 26.º

Registo de formatos

A lista exaustiva do que a exportação inclui e do que fica de fora, com o motivo de cada exclusão. O registo é gerado a partir do código do BeryX que monta a exportação.

Formato

datavault-export/2

JSON Schema

Descarregar o JSON Schema (datavault-export-2.schema.json)

Dialeto

https://json-schema.org/draft/2020-12/schema

Motivos de exclusão

Cada exclusão abaixo remete para um destes motivos.

1. 1.Segredo operacional: password, token, chave ou configuração cifrada de uma conexão, canal ou integração. Não sai em claro num ficheiro; as credenciais das fontes são do cliente e ele já as tem.
2. 2.Cópia do email de quem agiu, guardada para a auditoria. O export identifica a pessoa pelo id do utilizador da mesma linha (secção users).
3. 3.Emails dos destinatários, cifrados em repouso. Ficam fora do export nesta versão do formato; os canais de entrega saem em channel_ids.
4. 4.Identificadores da faturação da BeryxTech no Stripe (subcontratante de pagamentos).
5. 5.Estado interno do funcionamento do serviço (contadores de sessão e de MFA), sem significado fora do DataVault.
6. 6.Estado temporário que expira sozinho (fluxos de login SSO, sessões abertas, progresso de um scan, perguntas ao bot do Slack à espera de resposta).
7. 7.Derivado de dados que já saem no export e regenerável: vetores (embeddings) das entradas da base de conhecimento.
8. 8.Dados da organização, que pode ter vários workspaces. O export é de um workspace e não leva dados dos outros.
9. 9.Registo interno das ações da equipa de suporte da BeryxTech.

Topo do ficheiro

O objeto workspace tem os dados do próprio workspace (tabela workspaces).

Secções

129 secções, por categoria. Cada uma é uma chave do JSON com as linhas de uma tabela do workspace.

Campos excluídos

• workspace: stripe_customer_id, stripe_subscription_id (motivo 4)
• users: password_hash, mfa_secret_encrypted (motivo 1); mfa_last_step, token_version (motivo 5)
• api_tokens: token_hash (motivo 1)
• support_grants: staff_label (motivo 2)
• chat_account_links: token_hash (motivo 1)
• connections: config_encrypted (motivo 1)
• dataset_public_shares: token_hash, token_encrypted (motivo 1)
• domain_public_shares: token_hash, token_encrypted (motivo 1)
• remote_profiler_runs: ingest_claim_hash, ingest_token_hash (motivo 1)
• contract_proposals: token_hash, token_encrypted (motivo 1)
• notification_channels: config_encrypted (motivo 1)
• workspace_llm_credentials: key_encrypted (motivo 1)
• catalog_integrations: token_encrypted (motivo 1)
• dbt_cloud_integrations: secret_encrypted, api_token_encrypted (motivo 1)
• git_integrations: token_encrypted (motivo 1)
• ticket_integrations: config_encrypted (motivo 1)
• pipeline_integrations: credentials_encrypted (motivo 1)
• bi_integrations: credentials_encrypted (motivo 1)
• openlineage_configs: api_key_encrypted (motivo 1)
• mcp_servers: secret_encrypted (motivo 1)
• collaboration_integrations: config_encrypted (motivo 1)
• report_schedules: recipients_encrypted (motivo 3)
• report_public_shares: token_hash, token_encrypted (motivo 1)
• assistant_action_requests: requested_by_label, decided_by_label (motivo 2)
• admin_events: actor_label (motivo 2)

Tabelas que não são exportadas

Estas tabelas ficam de fora por inteiro.

Arts. 28.º e 32.º

Jurisdição e acesso governamental

Onde corre a infraestrutura do BeryX, sob que jurisdição, e que medidas protegem os dados não pessoais contra um acesso governamental internacional contrário ao direito da UE.

Infraestrutura

• A aplicação, a base de dados e o processamento correm na Google Cloud, na região europe-west1 (Bélgica), e os backups ficam na multi-região UE da Google. O contrato é com a Google Cloud EMEA Limited (Irlanda).
• A fila de mensagens corre na CloudAMQP (84codes AB, Suécia), na região AWS eu-west-1 (Irlanda).
• Os Termos de Serviço regem-se pela lei portuguesa.

O que pode sair da UE

• Os logs da plataforma, com o endereço IP de cada pedido, ficam no Cloud Logging da Google em localização global e podem ser guardados fora da UE.
• Os segredos da plataforma ficam no Secret Manager da Google, com réplicas que a Google escolhe e que podem ficar fora da UE.
• O código-fonte enviado ao Cloud Build fica num bucket na multi-região dos EUA.
• O suporte da Google pode aceder a partir de fora do EEE, com cláusulas contratuais-tipo no contrato de tratamento de dados da Google.
• Subcontratantes que tratam dados fora do Espaço Económico Europeu: Anthropic, Resend, Stripe, Voyage AI, GitHub, Sentry e Twenty (a partir de 16 de novembro de 2026). A finalidade, os dados e o mecanismo de transferência de cada um estão na Política de Privacidade.
• Com a IA ligada, a Anthropic (EUA) recebe metadados e amostras limitadas das fontes e, por omissão, é o único fornecedor de modelos que recebe amostras. Com a IA desligada na política do workspace, nada sai para fornecedores de modelos.

Medidas contra o acesso governamental

• Em repouso, a Google cifra tudo com AES-256 e chaves geridas pela Google. O SaaS partilhado não usa chaves geridas pelo cliente (CMEK).
• As credenciais das fontes e os segredos de integração são cifrados pela aplicação (Fernet) antes de gravados, e a chave fica noutro serviço (Secret Manager).
• O acesso às fontes do cliente é só de leitura, e o BeryX guarda metadados, métricas e amostras limitadas.
• A equipa da BeryxTech só entra num workspace com a aprovação de um admin do cliente, só para leitura e por 72 horas, no máximo. O pedido, a decisão e o primeiro acesso ficam no registo de auditoria do workspace.
• No plano Enterprise, os modelos Claude podem correr na conta AWS (Amazon Bedrock) ou Google Cloud (Vertex AI) do cliente, numa região europeia.
• Medidas contratuais e procedimento da BeryxTech perante um pedido de acesso de uma autoridade de um país terceiro: a confirmar

Arts. 25.º e 29.º

Mudança de fornecedor

As cláusulas de mudança de fornecedor estão nos Termos de Serviço. Em resumo:

Pré-aviso

2 meses para pedir a mudança para outro fornecedor ou para infraestrutura própria, ou só o apagamento dos dados (máximo legal; a confirmar).

Transição

Até 30 dias depois do pré-aviso, com o serviço a funcionar. Se for tecnicamente inviável, a BeryxTech avisa em 14 dias úteis e o prazo pode ir até 7 meses. Podes prolongá-la uma vez.

Recuperação dos dados

Pelo menos 30 dias depois da transição (a confirmar).

Apagamento

No fim, a BeryxTech apaga todos os dados do workspace de forma definitiva. Nos backups, os dados só desaparecem quando estes expiram.

Encargos de mudança

Até 11 de janeiro de 2027, no máximo o custo direto da mudança. A partir de 12 de janeiro de 2027, nenhum, incluindo a saída dos dados. A exportação na aplicação não tem custo.

Penalizações por rescisão antecipada

a confirmar

Fim do contrato

Quando a mudança estiver concluída e a BeryxTech te informar. Se pedires só o apagamento, no fim do pré-aviso.