Skip to content

GDPR

Jump to bottom
Valerio edited this page Apr 25, 2026 · 1 revision

GDPR Compliance

Harpyx can store and process personal data inside uploaded documents, extracted text, chat prompts, chat responses, audit events, user accounts, API keys, and operational logs. Hosting a Harpyx instance for EU users or EU organisations therefore requires both technical safeguards and governance controls.

This page is a practical checklist for operators and data owners. It is not legal advice; use it with a DPO, privacy counsel, or the organisation responsible for GDPR compliance.

Official references:

Roles and Responsibilities

Define the GDPR role before production use:

Role Typical Harpyx case
Controller The organisation deciding why documents are uploaded and how Harpyx is used
Processor The party hosting or operating Harpyx on behalf of the controller
Sub-processor External providers used by the operator, such as cloud hosting, email, object storage, observability, or LLM APIs

Document the role split in a Data Processing Agreement (DPA). If Harpyx is self-hosted by the same organisation that uses it, the same organisation may be both application operator and controller for its internal use. If Harpyx is hosted for a customer, the hosting party is usually a processor and must act under the controller's documented instructions.

Hosting Location

For a straightforward GDPR posture, host the whole Harpyx processing stack inside the EEA or another jurisdiction covered by an adequacy decision.

Minimum recommendation:

  • WebApp, Worker, SQL Server, MinIO/S3, Redis, RabbitMQ, OpenSearch, logs, backups, and monitoring data stay inside the EEA.
  • Administrative access is restricted to EU/EEA-based authorised personnel where possible.
  • Backup storage and disaster recovery locations are explicitly documented.
  • Remote support access is logged, time-limited, and covered by the DPA.

If any personal data leaves the EEA, document the transfer mechanism. Common options include an adequacy decision, Standard Contractual Clauses (SCCs), and any required transfer impact assessment or supplementary measures.

LLM Providers and RAG Context

Harpyx may send selected document chunks, user prompts, system prompts, and chat history to a configured chat or OCR provider. Treat each external LLM provider as a possible sub-processor or independent controller depending on the provider terms and the configured processing mode.

Before enabling an LLM provider in production:

  • Review provider terms, data-processing addendum, retention settings, training opt-out, region controls, and subprocessors.
  • Prefer EU/EEA endpoints where available.
  • Disable provider-side training on customer content.
  • Minimise what is sent: select only required documents and keep prompts focused.
  • Record the provider in the sub-processor list and privacy documentation.
  • For non-EEA providers, complete the required transfer assessment and safeguards.

BYO API keys reduce central secret exposure but do not remove GDPR duties. The uploaded content and transmitted prompts still need a valid processing basis, appropriate safeguards, and documented provider terms.

Lawful Basis and Transparency

The controller must identify the lawful basis for each processing purpose. Typical internal deployments may rely on contract, legitimate interests, legal obligation, or consent depending on the context and local policy.

Prepare a privacy notice or internal policy that explains:

  • what categories of documents and personal data may be uploaded;
  • why Harpyx processes them;
  • which providers and subprocessors are used;
  • whether data may be transferred outside the EEA;
  • how long data is retained;
  • how users can exercise their GDPR rights;
  • who to contact for privacy requests.

Avoid using Harpyx as an unrestricted dump for unrelated personal data. The principle of data minimisation still applies: upload only documents needed for the specific project or workflow.

Security Baseline

Implement the technical controls described in:

Minimum GDPR-oriented security posture:

  • strong authentication and limited admin access;
  • tenant/workspace/project access rules reviewed before production;
  • SQL Server TLS and TDE;
  • encrypted MinIO/S3 storage and encrypted backups;
  • encrypted LLM API keys via Encryption__MasterKey;
  • malware scanning for uploads;
  • audit logging for security-relevant events;
  • least-privilege access to production infrastructure;
  • documented restore and incident-response procedures.

Retention and Deletion

Define retention rules before accepting real customer or employee data.

Operational checklist:

  • Decide how long projects, documents, extracted text, chunks, chat history, and audit events are kept.
  • Use temporary projects and project expiration where possible.
  • Delete MinIO objects, SQL rows, and OpenSearch chunks when a document or project is deleted.
  • Verify backups have a defined retention period and deletion schedule.
  • Document exceptions for legal hold, audit, billing, or security investigations.

GDPR deletion requests may require coordinated deletion across SQL Server, MinIO/S3, OpenSearch, backups, logs, and any external LLM provider retention systems.

Data Subject Rights

Prepare an operational process for:

  • access requests;
  • rectification;
  • erasure;
  • restriction of processing;
  • portability where applicable;
  • objection;
  • questions about automated processing or profiling.

Harpyx can help locate projects, documents, users, prompts, and audit records, but the controller must decide how to verify identity, evaluate exemptions, and respond within the required timeframe.

DPIA

Run a Data Protection Impact Assessment when the Harpyx deployment is likely to create high risk for individuals. This is especially relevant when processing:

  • large volumes of personal documents;
  • special categories of data, such as health, biometric, political, religious, union, or similar sensitive content;
  • employee monitoring or HR records;
  • legal, financial, insurance, or public-sector documents;
  • automated decision-support workflows based on document analysis;
  • cross-border LLM processing.

The DPIA should cover data flows, risks, safeguards, provider choices, transfer mechanisms, access controls, encryption, retention, incident response, and residual risk acceptance.

Breach Response

Maintain a breach-response process before go-live.

At minimum:

  • detect and triage security incidents;
  • record when the organisation became aware of the incident;
  • assess whether personal data confidentiality, integrity, or availability was affected;
  • notify the controller without undue delay if acting as processor;
  • notify the supervisory authority within 72 hours where required;
  • notify affected individuals without undue delay where high risk is likely;
  • preserve logs and evidence for investigation.

Encryption, access controls, and audit logs can materially reduce breach impact, but the risk assessment must be done per incident.

Production Checklist

  • GDPR role split documented: controller, processor, sub-processors.
  • DPA signed where Harpyx is operated on behalf of another organisation.
  • Hosting, backups, logs, and monitoring are inside the EEA or covered by a documented transfer mechanism.
  • LLM providers reviewed for DPA, retention, training use, regions, and subprocessors.
  • Privacy notice or internal policy prepared.
  • Retention and deletion policy defined.
  • Data subject request process defined.
  • DPIA completed where high-risk processing is likely.
  • Security baseline implemented and tested.
  • Breach-response process documented.
  • Access to production and backups limited to authorised personnel.

Clone this wiki locally