Data protection by design: Building an AI platform without retrofitting GDPR

Art. 25 GDPR: Data protection as an architectural principle

Art. 25 GDPR requires data protection by design. How tenant separation, encryption and local processing put this into practice.

Article 25 of the GDPR has the unwieldy German title “Data protection through technology design and through privacy-friendly default settings”. The English version sounds catchier: Data Protection by Design and by Default. The core of the provision is revolutionary in its simplicity: data protection must not be an afterthought, but must be built into the technical architecture from the outset.

Specifically, Art. 25(1) requires that the controller, “both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organisational measures”. This means: if you are planning a software platform, you must integrate data protection into the design, not add it on as a patch after launch.

Art. 25(2) supplements the principle of privacy-friendly default settings (Privacy by Default): By default, only the personal data that is necessary for the specific purpose may be processed. Users should not have to take action to improve their data protection. The secure setting must be the default.

Art. 25 is particularly relevant for AI platforms, because AI systems by their nature process large volumes of data: documents, chat histories, search queries, usage patterns. Without consistent Privacy by Design, an AI platform becomes a data protection risk. With consistent Privacy by Design, it becomes the safest place for company data.

The following sections show how we have implemented this principle in every layer of the Nexoria architecture, not as a marketing feature, but as an unchangeable technical property. Data protection that cannot be switched off.

Tenant separation: every customer in their own world

The most fundamental data protection decision for a multi-tenant platform is the question: how are different customers' data isolated from one another? For many SaaS providers, the answer is: a shared database with a tenant ID filter. All customers share one database, and a WHERE filter in every SQL query is supposed to ensure that customer A does not see customer B's data.

With this model, separation depends on every single filter in the application logic.

Nexoria takes a different approach: complete tenant separation at database level.

• Separate database schemas per tenant: Each tenant operates in its own isolated schema. There is no shared table from which data belonging to other customers could be queried
• Separate vector collections: AI search is based on vector databases. Each tenant has its own collection with its own vectors. A search query in tenant A physically cannot access vectors belonging to tenant B
• JWT-enforced isolation: Every API request contains a signed JSON Web Token with the tenant ID. The backend service extracts the tenant ID from the token, not from the request body or URL parameters. As the token is signed and verified on the server side, a client cannot manipulate its tenant ID
• Connection pooling per tenant: A dedicated connection pooler manages database connections in transaction mode and ensures that connections are correctly assigned to the respective tenant schema

The result: even if a serious software error were to occur (a forgotten filter, a faulty JOIN condition), it cannot cause a cross-tenant data leak, because the separation is not based on application logic but enforced at infrastructure level.

Under Art. 32 GDPR, technical measures must reflect the “state of the art”. Separate schemas and JWT-based isolation go beyond the minimum. They set the standard against which others must be measured.

Encryption at every level

Encryption is not a feature that can be switched on or off. It is a property of all communication and storage in the platform. Art. 32 GDPR explicitly names “encryption” as a technical measure to ensure data security. At Nexoria, encryption is implemented at four levels:

1. Transport encryption

Every connection between client and server uses state-of-the-art transport encryption. This applies to the website, the dashboard application, the API endpoints and the WebSocket connections of the chatbots and VoiceBots. Unencrypted HTTP connections are automatically redirected to HTTPS. Between the servers on the internal network, data traffic runs over an encrypted VPN, a modern, lean protocol that has been rated secure in independent audits.

2. Configuration encryption

Sensitive configuration data (API keys for external services, OAuth tokens, SMTP credentials) is not stored in plain text in the database. Instead, AES-based symmetric encryption with integrity protection is used. The encryption key is managed separately and is not stored in the database. Even in the event of a hypothetical database dump, the sensitive configurations would not be readable.

3. Password hashing

User passwords are not encrypted. They are hashed, using a memory-intensive and time-intensive method recommended by the BSI (Federal Office for Information Security) that is hardened against modern brute-force and side-channel attacks. The parameterisation is chosen so that, even with dedicated hardware, an attack on a single password takes a disproportionately long time.

4. Backup encryption

All server backups are encrypted with a modern, audited encryption tool that combines strong asymmetric key exchange methods with authenticated symmetric encryption. The backups are encrypted locally after creation and only then transferred to the backup server. The private key is held exclusively by the person responsible for backups and is not stored on the backup server.

Together, these four levels form a defence-in-depth strategy, as recommended by ENISA (European Union Agency for Cybersecurity) in its guidelines on data encryption: no single layer bears sole responsibility, and a failure at one level is caught by the next.

File storage and search in Germany, answers from France

One of the most common concerns about AI platforms is: “Are my documents being sent to OpenAI or Google?” The question is justified, because data flows differ depending on the provider, product and configuration. If user data is passed on to models from providers that are subject to US law, the CLOUD Act applies to those providers.

At Nexoria, we distinguish file storage, knowledge index and semantic search in Germany from AI answer generation by Mistral AI in France. Additional services and activated integrations are described separately on the Security page.

What is processed entirely locally:

• Document embeddings: When you upload a document, it is converted into vectors on our own server. For this, we use a specialised embedding model that runs locally on our dedicated GPU. This information relates to indexing; for a subsequent AI answer, relevant content may be transmitted to Mistral AI in France
• Local text extraction for the index: Text is extracted with PyMuPDF, tables are detected with our own algorithms and data is structured locally. This is distinct from functions such as OCR and AI answer generation, in which content is transmitted to Mistral AI in France
• Semantic search: The vector database runs locally. Search queries are converted into vectors locally and matched locally against your document vectors. The entire RAG pipeline (Retrieval Augmented Generation), up to chunk selection, takes place on our own server
• Query expansion and HyDE: To deliver better search results, the AI generates additional search terms and hypothetical answers. This also happens locally, with a local language model on our GPU
• Semantic Cache: Frequently asked questions are stored with their answers in a local vector cache, so that repeated or similar queries are answered directly without contacting an external model

What is processed externally, and why:

• Final answer generation: Mistral AI processes the content required for the answer in France. Under the individual data processing agreement, the data transmitted by Nexoria is not used for model training
• Optionally connected AI providers: ChatGPT (OpenAI), Claude (Anthropic), Gemini (Google) and Langdock can optionally be connected to Nexoria. Nexoria also works without these integrations. If an integration is used, shared content is transmitted to the respective provider. That provider's terms, processing locations and settings then apply.

Which content is transmitted to Mistral AI depends on the function: for answers from knowledge search, it may be relevant text excerpts; for document functions such as OCR, it may also be document content. France is confirmed as the processing location for the Nexoria configuration. Other services, including technical error monitoring via Sentry, as well as activated integrations, are listed separately on the Security page. The information above describes the core platform; additional data flows are described individually there.

In its IT-Grundschutz modules, the BSI recommends data minimisation for cloud services (APP.5.3). At Nexoria, the content transmitted for each function and the services involved need to be considered separately; the component overview describes the data flows.

Audit logs: who did what and when

Art. 5(2) GDPR sets out the accountability principle as follows: the controller must be able to demonstrate compliance with the GDPR principles. No data protection officer or auditor is satisfied with “Trust us”. You need evidence, and it has to be complete.

Nexoria maintains a comprehensive, immutable audit trail, which logs every relevant action. Not just “User logged in”, but granular and rich in context:

What is logged:

• Authentication: Every login attempt (successful and failed), logout, token renewal, MFA verification, MFA reset by administrators
• Data access: Every search query in the knowledge base, every document access, every chatbot interaction with timestamp and user ID
• Data changes: Every creation, modification and deletion of documents, knowledge bases, chatbots, VoiceBots and users
• Administration: Role changes, user deactivations, user reactivations, permanent deletions, configuration changes to chatbots and VoiceBots
• External communication: Emails sent via the platform, VoiceBot calls with duration and outcome status, chatbot email notifications

How it is logged:

• Every log entry contains: timestamp (UTC), user ID, tenant ID, action, affected resource, IP address and user agent
• Audit logs are stored separately from the application data and are accessible to the application layer only in append mode; existing entries can neither be overwritten nor deleted
• Rate limiting on all 289 configured API endpoints ensures that the access patterns themselves can also be logged and checked for anomalies

These audit logs serve several purposes at once:

• GDPR compliance: Evidence that personal data is processed only for its specified purpose and by authorised persons (Art. 5(1)(b) and (f))
• Right of access: In the event of a subject access request under Art. 15 GDPR, you can prove exactly which data relating to a data subject was processed and who accessed it
• Incident response: In the event of a security incident (Art. 33 GDPR), the logs provide the information you need for the 72-hour notification to the supervisory authority: what happened, when, which data was affected, and on what scale
• EU AI Act: Art. 26(6) of the EU AI Act requires deployers to retain automatically generated logs for high-risk AI. Nexoria's audit logs already meet this requirement today, a further investment in future-proofing

Automatic data deletion after cancellation

Art. 17 GDPR, the right to erasure (“right to be forgotten”), is one of the most frequently requested data protection measures. Erasure only becomes effective when the data is actually removed and not merely hidden.

At Nexoria, deletion is irreversible and complete. The process after cancellation follows a clearly defined two-phase model:

Phase 1: Export window (30 days)

• After cancellation, the customer has 30 days to export all of their data
• All features remain usable during this phase, and the platform is fully accessible
• The export includes: all documents in their original format, chat histories as structured data, tasks, calendar entries, definitions of Automations and audit logs

Phase 2: Irreversible deletion

After the 30 days have expired, the following are deleted automatically and irrevocably:

• All documents: Original files and processed versions are physically removed from the file system, not merely dereferenced in the database
• All vectors: The tenant's entire vector collection is deleted from the vector database. This makes it impossible to restore the semantic search or to reconstruct document content from vectors
• All chat histories: Chatbot conversations, VoiceBot transcripts, NexCompanion chat histories, feedback data
• All configurations: Chatbot settings, VoiceBot configurations, automation definitions, workspace structures, calendar entries, tasks
• All user accounts: Login credentials, profile information, MFA secrets, recovery codes, role settings
• All backups: The encrypted backup copies in the cross-server backup are also identified and deleted

A separate period applies to recordings and transcripts from Nexoria Meet: after the end of the contract, they remain stored for 180 days by default. This period can be adjusted individually. Separately from this, there is the 30-day period after the end of the contract during which customers can request the export of their data under the general terms.

When the relevant period expires, the tenant's database schema is completely removed. There is no “recycle bin”, no soft-delete phase after deletion and no technical means of recovery. Once the relevant period has expired, the data is permanently removed, and that is exactly the intention. Before then, the 30-day export window is available to you for exporting your data.

This thorough deletion fulfils Art. 17(1) GDPR not only formally but in its spirit: the right to erasure means erasure, not making data invisible.

Roles and permissions

Art. 25(2) GDPR requires that, by default, only the data necessary for the specific purpose is processed. The principle of least privilege is the technical implementation of this principle: every user receives exactly the rights they need for their task, no more.

Nexoria implements a two-tier role model, which separates organisation-wide permissions from area-specific access rights:

Tier 1: Tenant roles (organisation-wide)

• Super Admin: Full access to all tenant settings, user management, billing data, audit logs, chatbot and VoiceBot configuration. Typically the head of IT or the managing director. Can appoint other admins and reset MFA
• Admin: Can invite and manage users, create workspaces, configure chatbots. No access to billing data or global tenant settings
• Member: Standard role for regular employees. Access to assigned workspaces, the AI assistant, their own tasks and calendar. No access to user management or configuration
• Guest: Restricted access to explicitly shared content. No access to configuration, administration or other workspaces. Ideal for external partners or temporary project staff

Tier 2: Workspace roles (area-specific)

• Workspace Admin: Can invite members to the workspace, create and configure knowledge bases, change workspace settings
• Workspace Member: Can upload and search documents, use the AI assistant, create and edit tasks
• Workspace Viewer: Read-only access. Can view documents and use the AI assistant for questions, but cannot change, upload or delete data

Combining both tiers enables fine-grained access control: an employee can be an admin in their own team workspace but have only viewer rights in the finance workspace. The HR department can access HR documents but not the engineering department's technical documentation, and vice versa.

What matters is what a user is not able to see. The user interface shows only the functions and data the user is authorised to access. From their perspective, nothing else exists. The permission check takes place in the backend middleware, not in the frontend. Even if someone calls the API directly and tries to access resources that are not theirs, the request is rejected on the server side.

This model is in line with the recommendations of BSI IT-Grundschutz (module ORP.4: Identity and Access Management), which explicitly calls for role-based access control with the principle of least privilege and regular review of permissions.