> ## Documentation Index
> Fetch the complete documentation index at: https://docs.switchbord.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Data Protection & GDPR

> How Switchbord handles personal data, implements GDPR data subject rights, pseudonymizes PII for AI, and manages sub-processor relationships.

## What PII Switchbord Stores

Switchbord processes personal data on behalf of its tenant organizations (data controllers). The categories of personal data processed include:

| Data Category       | Examples                                      | Storage Location                    |
| ------------------- | --------------------------------------------- | ----------------------------------- |
| Contact identifiers | Phone numbers (E.164 format), names           | `contacts` table                    |
| Message content     | Inbound and outbound WhatsApp message bodies  | `messages` table                    |
| Contact metadata    | Custom fields, tags, notes added by operators | `contacts`, `contact_fields` tables |
| User identifiers    | Email addresses of workspace members          | Supabase Auth                       |
| Audit records       | Actor IDs, action types, entity references    | `audit_logs` table                  |

<Warning>
  Switchbord operators are responsible for ensuring they have a lawful basis under GDPR Art.6 for processing their contacts' personal data via the platform.
</Warning>

## Data Retention

Each workspace configures its own data retention policy via the `data_retention_days` setting (default: **730 days / 2 years**).

* Contacts and messages older than the retention window are eligible for automated deletion
* The retention window applies per-workspace and can be adjusted by workspace owners and admins
* Soft-delete fields (`deleted_at`, `deletion_requested_at`) track the deletion lifecycle

```typescript theme={null}
// Workspace settings — configurable per tenant
const workspace = {
  data_retention_days: 730, // default, configurable per workspace
};
```

## GDPR Data Subject Rights

### Right of Access & Portability (Art. 15 / Art. 20)

Contacts can request a full export of all personal data held about them. This is implemented via:

```
GET /api/contacts/{contactId}/gdpr
```

**Authorization:** Requires `admin` or `owner` role in the contact's workspace.

**Response:** A JSON payload containing all PII fields associated with the contact, including:

* Contact record (phone, name, custom fields)
* All message history linked to the contact
* Any audit log entries referencing the contact

This endpoint satisfies the obligation to provide data in a structured, commonly used, machine-readable format (Art.20).

### Right to Erasure (Art. 17)

Contacts can request erasure of their personal data. This is implemented via:

```
DELETE /api/contacts/{contactId}/gdpr
```

**Authorization:** Requires `admin` or `owner` role in the contact's workspace.

**What happens on erasure:**

1. PII fields in the `contacts` record are overwritten with anonymized placeholder values
2. Message bodies linked to the contact are anonymized in-place
3. The contact record is soft-deleted (`deleted_at` set to current timestamp)
4. An audit log entry is written recording the erasure, actor, and timestamp

```typescript theme={null}
// Anonymization in-place — data is overwritten, not deleted
await db.update(contacts)
  .set({
    phoneNumber: `ERASED-${contactId}`,
    name: null,
    email: null,
    deletedAt: new Date(),
  })
  .where(eq(contacts.id, contactId));

// Message bodies anonymized
await db.update(messages)
  .set({ body: '[Content erased per GDPR Art.17 request]' })
  .where(eq(messages.contactId, contactId));

// Audit trail
await writeAuditLog({
  action: 'gdpr_erasure',
  entityType: 'contact',
  entityId: contactId,
  actorUserId: userId,
  workspaceId,
});
```

<Note>
  Audit log entries for erasure operations are **retained** after erasure to demonstrate compliance with the erasure request itself. The audit log records the fact of erasure, not the erased PII.
</Note>

## PII Pseudonymization for AI

When contact data is passed to an AI model for draft generation or analysis, Switchbord pseudonymizes PII before it leaves the platform.

### How It Works

The `pii-redactor.ts` utility (`packages/ai/src/pii-redactor.ts`) provides two functions:

```typescript theme={null}
// Replaces PII with reversible tokens before sending to AI
const { redactedText, tokenMap } = redactPII(originalText, mode);

// Restores original values in the AI response
const restoredText = restorePII(aiResponse, tokenMap);
```

### Pseudonymization Modes

| Mode                       | What is Replaced                      | Token Format                           |
| -------------------------- | ------------------------------------- | -------------------------------------- |
| **Conservative** (default) | Phone numbers, email addresses        | `[PHONE-1]`, `[EMAIL-1]`               |
| **Aggressive**             | Phone numbers, emails, detected names | `[PHONE-1]`, `[EMAIL-1]`, `[NAME-1]`   |
| **Disabled**               | Nothing — raw PII sent to AI          | Only allowed with self-hosted provider |

### Privacy-First Default

The default mode is **conservative pseudonymization — enabled by default for all workspaces**. Disabling pseudonymization is only permitted when the workspace has configured a self-hosted AI provider (Ollama or vLLM), ensuring PII never leaves the operator's infrastructure.

```
Settings → AI Providers → Privacy & Data Protection
```

<Warning>
  Disabling PII pseudonymization while using a cloud AI provider (OpenAI, Anthropic, OpenRouter) is blocked at the application level. The toggle will be unavailable until a self-hosted provider is configured and tested.
</Warning>

### Self-Hosted AI: Keeping PII On-Premises

For organizations that cannot allow PII to leave their infrastructure (healthcare, legal, financial services), Switchbord supports two self-hosted AI providers:

<CardGroup cols={2}>
  <Card title="Ollama" icon="server">
    Runs locally on your infrastructure. No data leaves your network. Suitable for CPU/GPU servers and developer environments.
  </Card>

  <Card title="vLLM" icon="microchip">
    High-throughput GPU cluster deployment with OpenAI-compatible API. Suitable for production workloads requiring fast inference.
  </Card>
</CardGroup>

Both providers are configured in **Settings → AI Providers** and include a connection test to verify reachability before activation.

## Sub-Processors

Switchbord relies on the following sub-processors for data processing:

| Sub-Processor      | Role                           | Data Processed                  | Location                 |
| ------------------ | ------------------------------ | ------------------------------- | ------------------------ |
| **Supabase**       | Database, Auth, Storage, Vault | All structured data, secrets    | EU (configurable region) |
| **Vercel**         | Web & API hosting              | HTTP request/response, logs     | Global CDN (US primary)  |
| **Railway**        | Background worker hosting      | Job payloads, logs              | Configurable region      |
| **Meta Cloud API** | WhatsApp message delivery      | Phone numbers, message content  | Meta infrastructure      |
| **OpenAI**         | AI draft generation (optional) | Pseudonymized text (if enabled) | US                       |
| **Anthropic**      | AI draft generation (optional) | Pseudonymized text (if enabled) | US                       |
| **OpenRouter**     | AI routing (optional)          | Pseudonymized text (if enabled) | US                       |
| **Sentry**         | Error monitoring               | Stack traces, request metadata  | US/EU                    |
| **Better Stack**   | Log aggregation                | Application logs                | Configurable             |

<Note>
  Cloud AI providers (OpenAI, Anthropic, OpenRouter) only receive pseudonymized text unless explicitly disabled by the workspace admin with a self-hosted provider configured. Self-hosted providers (Ollama, vLLM) never transmit data externally.
</Note>

## Data Processing Agreements

Organizations subject to GDPR must ensure a Data Processing Agreement (DPA) is in place with Switchbord and each relevant sub-processor. Key considerations:

* **Supabase** provides a standard DPA covering GDPR Art.28 obligations
* **Vercel** provides a DPA for enterprise customers
* **Meta** requires acceptance of their Platform Terms, which include data processing terms
* Cloud AI providers offer DPAs; review their data retention and training policies before use

For self-hosted deployments, the operator acts as both data controller and data processor, which simplifies the DPA landscape.

## Compliance Mapping

| Standard | Article/Control                      | Implementation                                                                   |
| -------- | ------------------------------------ | -------------------------------------------------------------------------------- |
| GDPR     | Art.5 — Principles of processing     | Data minimization, purpose limitation enforced by design                         |
| GDPR     | Art.6 — Lawful basis                 | Operator responsibility; platform supports legitimate interest and consent flows |
| GDPR     | Art.15 — Right of access             | `GET /api/contacts/[id]/gdpr`                                                    |
| GDPR     | Art.17 — Right to erasure            | `DELETE /api/contacts/[id]/gdpr` with in-place anonymization                     |
| GDPR     | Art.20 — Right to portability        | Machine-readable JSON export via Art.15 endpoint                                 |
| GDPR     | Art.25 — Privacy by design           | PII pseudonymization on by default; self-hosted AI for sensitive workloads       |
| GDPR     | Art.28 — Processor obligations       | DPA framework with sub-processors                                                |
| GDPR     | Art.32 — Security of processing      | Encryption, access controls, audit logging                                       |
| NIS2     | Art.21 — Cybersecurity risk measures | PII handling controls, incident response (planned BORD-166)                      |

<Tip>
  For the full compliance control mapping, see the [Compliance Matrix](/security/compliance-matrix).
</Tip>