Data Protection

Rela AI processes sensitive industrial data — sensor readings, client contracts, WhatsApp conversations, extracted documents — and each one requires a different protection level. This page describes how the information is encrypted, isolated, retained, and erased across the platform.

What is it for?

A platform that consolidates a plant's operational history is a valuable target for attackers and a compliance risk if it doesn't meet local regulations (GDPR in Europe, LFPDPPP in Mexico, LPDP in Argentina). Data protection is what lets a CIO sign the agreement without raising risks that can't be closed.

• Multi-tenant isolation — one tenant never sees another tenant's data.
• Encryption — at-rest on MongoDB/GCS, in transit via TLS 1.3.
• Secret management — external credentials kept out of the database.
• Configurable retention — purge stale data per tenant policy.
• Right to be forgotten — export and delete data for a specific subject.

How it works

flowchart LR
  C[Client] -->|TLS 1.3| LB[Load Balancer]
  LB --> API[FastAPI<br/>JWT + tenant_id]
  API --> S[Scoped to tenant_id]
  S --> M[(MongoDB<br/>at-rest AES-256)]
  S --> G[(GCS<br/>at-rest AES-256)]
  API --> SM[(GCP Secret Manager<br/>MQTT / Postmark / external APIs)]
  M --> R[Retention jobs]
  R -->|MongoDB TTL| Prune[Automatic deletion]

1. Encryption in transit. Every request enters over HTTPS (TLS 1.3). HSTS enabled with max-age=63072000; includeSubDomains; preload.
2. Encryption at-rest. MongoDB Atlas and GCS encrypt with AES-256 managed by GCP KMS. Keys rotate every 90 days with zero downtime.
3. Per-tenant isolation. Every MongoDB document carries tenant_id and every query filters by it (enforced at the service layer). No cross-tenant collections.
4. Secret management. Integration credentials (MQTT broker, Postmark API keys, external tokens) live in GCP Secret Manager. Only the backend service account has access; they never appear in code, logs, or JSON responses.
5. Retention. Each operational collection can configure TTL (_machine_events: 90d default, _alerts: 180d, _audit_trail: 7 years). TTL is handled natively by MongoDB.
6. Right to be forgotten. POST /api/v1/privacy/erase-subject flags and erases every document linked to a subject (name, phone, email) inside the tenant — complies with GDPR Art. 17.

Configuration parameters

How to use it

Configure retention

1. Administration → Data Protection → Retention.
2. Adjust days per collection.
3. Save. MongoDB TTL updates on the next sync (typically < 5 min).

Reducing retention does NOT retroactively delete — it only applies to documents crossing the new threshold after the change. To purge history manually, use the selective delete endpoint.

Export subject data (GDPR Art. 15, right of access)

POST /api/v1/privacy/export-subject
{
  "subject_id": "john.smith@client.com",
  "format": "json"
}

Returns a signed URL to a ZIP containing: conversations, extracted records, associated tasks, CSAT responses, audit trail of actions performed on the subject. URL valid for 24 h.

Erase subject data (GDPR Art. 17, right to be forgotten)

POST /api/v1/privacy/erase-subject
{
  "subject_id": "john.smith@client.com",
  "reason": "request from data subject",
  "preserve_audit": true
}

preserve_audit=true keeps the audit trail but redacts it: replaces subject_id with an irreversible SHA-256 hash. Meets the legal obligation without breaking audit trail compliance.

Auto-redact PII in transcripts

For conversations where the user may share third-party PII (e.g., an agent collecting banking data):

1. Administration → Data Protection → PII Auto-redact → on.
2. Pick categories: email, phone, id_number, credit_card.

Transcripts stored in _conversations keep the conversational context but replace detected tokens with [redacted:<type>].

Use cases

1 · GDPR audit during EU client onboarding. A European company evaluates Rela AI. During legal due-diligence they ask: at-rest encryption (✓ AES-256), data deletion on request (✓ erase-subject endpoint), configurable retention (✓ per-tenant), data residency (✓ GCS europe-west1 region). Onboarding closed with no legal blockers.

2 · Retention shrink after migration. A client migrates from a legacy system with 7 years of events. In Rela AI they choose to keep only 2 years of _machine_events (older ones archived to their data lake). Set retention.machine_events_days=730, save. Events older than 730 days get cleaned by the next TTL cycle (~24 h).

3 · Former employee requests data erasure. A former technician requests the right to be forgotten. Admin fires POST /api/v1/privacy/erase-subject with their email. The system deletes their support-agent conversation, removes their CSAT answer, redacts their email from the audit trail with a SHA-256 hash. The audit preserves "anonymous user created task X" but it can no longer be traced back. Compliance closed.

Limits and assumptions

• PII redaction is best-effort. The email/phone pattern detector works well; for local-specific identifiers (Mexican CURP, Italian codice fiscale) it may miss. Don't rely 100% — sample-check.
• preserve_audit=false is destructive. Using it removes the subject reference even from audit — weigh local legal obligations before.
• Export signed URLs are temporary (24 h). If the subject doesn't download in time, regenerate.
• Shrinking retention does NOT purge history instantly. MongoDB TTL runs every ~24 h; for immediate purges use POST /api/v1/privacy/purge-old with an explicit older_than.
• GCS data residency is fixed at setup. Changing region requires tenant re-provisioning.

Key benefits

• End-to-end encryption: TLS 1.3 in transit, AES-256 at-rest with 90-day key rotation.
• Multi-tenant isolation enforced at the service layer, not just query filter.
• External secrets living in GCP Secret Manager, never in DB or code.
• Per-tenant configurable retention with native MongoDB TTL.
• GDPR compliance: dedicated export + erase endpoints.
• PII auto-redact to protect third parties mentioned in conversations.
• Immutable audit trail that survives subject redaction.