Exportar los datos y cambiar de proveedor

Art. 26

Métodos y formatos de exportación

Un admin del workspace exporta todos los datos de una vez, sin pedirlo al soporte.

• En la aplicación: Equipo → Zona de peligro → Exportar datos (JSON).
• Por la API: GET /api/v1/workspace/export, autenticado como admin del workspace.
• Formato: un fichero JSON en UTF-8 (application/json; charset=utf-8), en el formato datavault-export/2, descrito por un JSON Schema público.
• La exportación no tiene coste.

El fichero tiene todas las secciones del registro de formatos, donde también está lo que queda fuera y el motivo.

Otros formatos legibles por máquina

Partes de los datos también salen en otros formatos abiertos, por la API:

• API REST pública, solo de lectura, con el contrato OpenAPI publicado

  Estándar: OpenAPI 3.1 · Tipo: application/json

  Ver página

• Reglas y contrato de cada dataset como tests dbt

  Estándar: dbt (schema.yml) · Tipo: application/yaml

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

• Reglas de cada dataset, o del workspace entero, como checks SodaCL

  Estándar: SodaCL · Tipo: application/yaml

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

• Reglas de cada dataset como suite de Great Expectations

  Estándar: Great Expectations 1.x (suite JSON) · Tipo: application/json

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

• Tablas de auditoría, SLO, dimensiones, PII, gobernanza y registro de consultas

  Estándar: 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

• Informes, README de datasets, evidencia de gobernanza y dosieres

  Estándar: 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 y 26

Registro de formatos

La lista exhaustiva de lo que incluye la exportación y de lo que queda fuera, con el motivo de cada exclusión. El registro se genera a partir del código de BeryX que monta la exportación.

Formato

datavault-export/2

JSON Schema

Descargar el JSON Schema (datavault-export-2.schema.json)

Dialecto

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

Motivos de exclusión

Cada exclusión de abajo remite a uno de estos motivos.

1. 1.Secreto operativo: contraseña, token, clave o configuración cifrada de una conexión, canal o integración. No sale en claro en un fichero; las credenciales de las fuentes son del cliente y ya las tiene.
2. 2.Copia del email de quien actuó, guardada para la auditoría. La exportación identifica a la persona por el id de usuario de la misma fila (sección users).
3. 3.Emails de los destinatarios, cifrados en reposo. Quedan fuera de esta versión del formato; los canales de entrega se exportan en channel_ids.
4. 4.Identificadores de facturación de BeryxTech en Stripe (subencargado de pagos).
5. 5.Estado interno del servicio (contadores de sesión y de MFA), sin significado fuera de DataVault.
6. 6.Estado temporal que caduca solo (flujos de login SSO, sesiones abiertas, progreso de un escaneo, preguntas al bot de Slack pendientes de respuesta).
7. 7.Derivado de datos que ya salen en la exportación y regenerable: vectores (embeddings) de las entradas de la base de conocimiento.
8. 8.Datos de la organización, que puede tener varios workspaces. La exportación es de un workspace y no lleva datos de los demás.
9. 9.Registro interno de las acciones del equipo de soporte de BeryxTech.

Inicio del fichero

El objeto workspace tiene los datos del propio workspace (tabla workspaces).

Secciones

129 secciones, por categoría. Cada una es una clave del JSON con las filas de una tabla del workspace.

Campos excluidos

• 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)

Tablas que no se exportan

Estas tablas quedan fuera por completo.

Arts. 28 y 32

Jurisdicción y acceso gubernamental

Dónde funciona la infraestructura de BeryX, bajo qué jurisdicción, y qué medidas protegen los datos no personales frente a un acceso gubernamental internacional contrario al Derecho de la UE.

Infraestructura

• La aplicación, la base de datos y el procesamiento funcionan en Google Cloud, en la región europe-west1 (Bélgica), y las copias de seguridad están en la multirregión UE de Google. El contrato es con Google Cloud EMEA Limited (Irlanda).
• La cola de mensajes funciona en CloudAMQP (84codes AB, Suecia), en la región AWS eu-west-1 (Irlanda).
• Los Términos de Servicio se rigen por la ley portuguesa.

Qué puede salir de la UE

• Los logs de la plataforma, con la dirección IP de cada petición, están en Cloud Logging de Google en ubicación global y pueden guardarse fuera de la UE.
• Los secretos de la plataforma están en Secret Manager de Google, con réplicas que elige Google y que pueden estar fuera de la UE.
• El código fuente enviado a Cloud Build está en un bucket en la multirregión de EE. UU.
• El soporte de Google puede acceder desde fuera del EEE, con cláusulas contractuales tipo en el contrato de tratamiento de datos de Google.
• Subencargados que tratan datos fuera del Espacio Económico Europeo: Anthropic, Resend, Stripe, Voyage AI, GitHub, Sentry y Twenty (a partir del 16 de noviembre de 2026). La finalidad, los datos y el mecanismo de transferencia de cada uno están en la Política de Privacidad (en inglés).
• Con la IA activada, Anthropic (EE. UU.) recibe metadatos y muestras limitadas de las fuentes y, por defecto, es el único proveedor de modelos que recibe muestras. Con la IA desactivada en la política del workspace, nada sale hacia proveedores de modelos.

Medidas frente al acceso gubernamental

• En reposo, Google cifra todo con AES-256 y claves gestionadas por Google. El SaaS compartido no usa claves gestionadas por el cliente (CMEK).
• Las credenciales de las fuentes y los secretos de integración se cifran en la aplicación (Fernet) antes de guardarse, y la clave está en otro servicio (Secret Manager).
• El acceso a las fuentes del cliente es solo de lectura, y BeryX guarda metadatos, métricas y muestras limitadas.
• El equipo de BeryxTech solo entra en un workspace con la aprobación de un admin del cliente, solo para lectura y durante 72 horas como máximo. La petición, la decisión y el primer acceso quedan en el registro de auditoría del workspace.
• En el plan Enterprise, los modelos Claude pueden funcionar en la cuenta AWS (Amazon Bedrock) o Google Cloud (Vertex AI) del cliente, en una región europea.
• Medidas contractuales y procedimiento de BeryxTech ante una petición de acceso de una autoridad de un tercer país: por confirmar

Arts. 25 y 29

Cambio de proveedor

Las cláusulas de cambio de proveedor están en los Términos de Servicio. En resumen:

Preaviso

2 meses para pedir el cambio a otro proveedor o a infraestructura propia, o solo el borrado de los datos (máximo legal; por confirmar).

Transición

Hasta 30 días después del preaviso, con el servicio funcionando. Si es técnicamente inviable, BeryxTech avisa en 14 días hábiles y el plazo puede llegar a 7 meses. Puedes prorrogarla una vez.

Recuperación de los datos

Al menos 30 días después de la transición (por confirmar).

Borrado

Al final, BeryxTech borra todos los datos del workspace de forma definitiva. En las copias de seguridad, los datos solo desaparecen cuando estas caducan.

Gastos de cambio

Hasta el 11 de enero de 2027, como máximo el coste directo del cambio. A partir del 12 de enero de 2027, ninguno, incluida la salida de los datos. La exportación en la aplicación no tiene coste.

Penalizaciones por rescisión anticipada

por confirmar

Fin del contrato

Cuando el cambio esté concluido y BeryxTech te informe. Si solo pides el borrado, al final del preaviso.