Documentation Index
Fetch the complete documentation index at: https://docs.emergence.ai/llms.txt
Use this file to discover all available pages before exploring further.
GDPR Compliance
CRAFT is designed to support organizations in meeting their obligations under the General Data Protection Regulation (GDPR). This page covers data handling, Right to Be Forgotten (RTBF) implementation, audit logging, and data residency controls.CRAFT provides the technical mechanisms for GDPR compliance. Organizations are responsible for configuring and operating the platform in accordance with their specific GDPR obligations, Data Protection Impact Assessments (DPIAs), and legal counsel.
Data Processing Principles
The platform implements GDPR’s data processing principles at the architecture level:| Principle | Implementation |
|---|---|
| Lawfulness | Platform enforces authenticated access controls; deploying organizations must establish and document their Article 6 lawful basis (e.g., legitimate interests, contract performance, consent) for each processing activity in their Records of Processing Activities (RoPA) |
| Purpose limitation | Data connections are scoped to specific projects with defined purposes |
| Data minimization | Agent Cards apply data minimization to provider contact information |
| Accuracy | Audit logs record all data modifications with timestamps |
| Storage limitation | Configurable retention policies per tenant and data type |
| Integrity and confidentiality | Encryption at rest (AES-256) and in transit (TLS 1.2 minimum) |
| Accountability | Immutable audit logs with full traceability |
Personal Data Inventory
The platform processes the following categories of personal data:| Category | Location | Sensitivity | Purpose | Suggested Lawful Basis |
|---|---|---|---|---|
| User identity (email, name) | Keycloak realms | Restricted | Authentication | Contract performance or legitimate interests |
| User IP address | Audit logs | Restricted | Security monitoring | Legitimate interests |
| User agent string | Audit logs | Internal | Debugging | Legitimate interests |
| Agent Card provider contact | Assets database | Confidential | Agent registration | Contract performance |
| Session data | Redis, PostgreSQL | Confidential | Multi-turn conversations | Contract performance |
| Query results | Solution databases | Confidential | Data analytics | Determined by organization based on data source |
The “Suggested Lawful Basis” column provides guidance only. Organizations must confirm the lawful basis for each processing activity in their specific deployment context and document it in their Records of Processing Activities (RoPA).
Right to Be Forgotten (RTBF)
The platform implements RTBF using crypto-shredding — destroying the encryption key rather than locating and deleting every instance of the data.How Crypto-Shredding Works
PII fields are encrypted per principal
When audit log entries are created, PII fields (
actor identity, ip_address) are encrypted using a per-principal encryption key.RTBF request is received
An administrator or the data subject initiates an RTBF request via the Governance API.
Encryption key is destroyed
The principal’s encryption key is permanently deleted. Without the key, encrypted fields become unrecoverable.
Data Deletion Matrix
When an RTBF request is processed, data is deleted across all storage systems:| Storage | Action | Timing |
|---|---|---|
| PostgreSQL | Hard-delete rows from all tables | Immediate |
| OpenFGA | Delete authorization relationship tuples | Immediate |
| Object storage | Delete skill package artifacts | Immediate |
| Redis | Invalidate cached entries | Immediate |
| Event bus (Redis Streams) | Events are ephemeral (7-day retention) | No action needed beyond retention expiry |
| WAL/PITR backups | Backup retention must not exceed RTBF compliance deadline | Per backup retention policy |
| Operational logs | PII limited to tenant_id and actor; 90-day max retention | Retention-based expiry |
Audit Logging
Every state-changing operation produces an immutable audit entry:| Field | Type | Description |
|---|---|---|
id | ULID | Unique entry identifier |
tenant_id | string | Tenant scope |
action | string | e.g., agent.register, agent.approve, policy.update |
actor | string | Authenticated principal (encrypted with per-principal key) |
actor_type | enum | USER, SERVICE_ACCOUNT, SYSTEM |
resource_type | string | Target resource type |
resource_id | string | Target resource identifier |
timestamp | timestamp | When the action occurred |
details | JSONB | Old/new values, approval comments, policy violations |
ip_address | string | Client IP (encrypted with per-principal key) |
trace_id | string | OpenTelemetry trace ID for end-to-end correlation |
Audit Log Properties
- Append-only: No updates or deletes in normal operation
- Retention: Configurable per tenant (default 1 year; extended retention only where required by specific regulation, e.g., financial record-keeping)
- Export:
GET /governance/admin/audit-logs?format=csvfor compliance reporting - SIEM integration: Forward to Splunk, Datadog, or SIEM via OpenTelemetry Collector (customer-configurable exporters)
- Filterable: By actor, action, date range, and resource
Breach Notification
GDPR Article 33 requires that in the event of a personal data breach, the controller must notify the competent supervisory authority without undue delay and, where feasible, no later than 72 hours after becoming aware of it. Article 34 requires notification to affected data subjects where the breach is likely to result in a high risk to their rights and freedoms. The platform supports breach detection and timely reporting through:- SIEM integration: Real-time forwarding of security events via OpenTelemetry Collector for anomaly detection
- Audit log analysis: Identify unauthorized access patterns via audit log queries and export
- OpenTelemetry alerting: Configure alerts for unusual access patterns (high volume queries, off-hours access, privilege escalation)
- Trace correlation:
trace_idin audit logs enables end-to-end investigation of suspected breaches
Data Residency
For GDPR Article 44-49 compliance (international data transfers):- Region labels: Each tenant is tagged with a data residency region (EU, US, APAC, custom)
- Geo-fenced storage: Database partitioning by region ensures EU data stays in EU
- Regional API endpoints: Optional per-region API gateway routing (e.g.,
eu.platform.example.com) - Cross-region search: Federated queries can span regions only with explicit opt-in
- Data location attestation: API endpoint returns storage location metadata per entity
Legal Transfer Mechanisms
Technical geo-fencing alone does not constitute GDPR-compliant transfer controls. Cross-border data flows require a valid legal transfer mechanism under GDPR Chapter V:- Standard Contractual Clauses (SCCs) (Art. 46(2)(c)) — the most common mechanism for international transfers
- Adequacy decisions (Art. 45) — transfers to countries with an adequate level of data protection
- Binding Corporate Rules (Art. 47) — for intra-group international transfers
Consent and Access Controls
| GDPR Right | Platform Mechanism |
|---|---|
| Right of access (Art. 15) | Audit logs and data export APIs. Organizations must respond to DSARs within one month of receipt (Art. 12(3)), extendable by two months for complex requests |
| Right to rectification (Art. 16) | Standard CRUD APIs for data correction |
| Right to erasure (Art. 17) | Crypto-shredding + data deletion matrix |
| Right to restrict processing (Art. 18) | Tenant-level freeze / per-resource access controls |
| Right to data portability (Art. 20) | JSON/CSV export APIs |
| Right to object (Art. 21) | Organizations must implement a process to receive and act on individual objection requests. Platform supports per-user processing restrictions via access controls. Tenant-level processing settings provide additional scope controls |
Data Protection Impact Assessment (DPIA)
When deploying the platform for processing personal data, consider the following for your DPIA:Data flows
Data flows
Map the flow of personal data through the platform: authentication tokens, audit logs, data connections, query results, and agent interactions. Identify which components process personal data and the legal basis for each.
Data minimization
Data minimization
Configure the platform to collect only the data necessary for your use case. Disable anonymous access logging if not needed. Configure audit log retention to the minimum required period.
Third-party processors
Third-party processors
If using cloud-managed services (Cloud SQL, RDS, Azure Database), ensure your Data Processing Agreement (DPA) with the cloud provider covers the data being processed. If using cloud-based LLM APIs, a DPA with the LLM provider is required.
High-risk processing scenarios
High-risk processing scenarios
A formal DPIA is mandatory under Art. 35 for processing likely to result in high risk, including: systematic profiling, large-scale processing of sensitive data (e.g., healthcare via Data Insights), and automated decision-making. Engage your Data Protection Officer (DPO) per Art. 37 in reviewing the DPIA, and consult your supervisory authority under Art. 36 if residual risk remains high after mitigation.
Compliance Reporting
The platform provides compliance reports via the admin API:| Report | Content |
|---|---|
| Data processing inventory | All data connections, their purposes, and access patterns |
| Access review | All users and their permissions per tenant |
| Audit trail export | Full audit log for a specified date range |
| RTBF confirmation | Confirmation of data deletion across all storage systems |
Next Steps
SOC 2 Controls
See how the platform maps to SOC 2 Trust Service Criteria.
HIPAA Compliance
Review HIPAA compliance considerations for healthcare deployments.
Data Classification
Understand data classification levels and encryption requirements.
Backup & Restore
Configure backup retention to align with GDPR requirements.

