Data processing
Data processing, explained for DPOs.
Where data is processed, who is responsible for what, and which safeguards are available. Compute currently runs in Georgia, outside the European Economic Area — this page explains what that means and how we support you.
Designed to support GDPR-conscious deployments.
Where data is processed
Compute in Georgia. Operations from Germany / Europe.
All inference and model storage currently run in a single compute region. Commercial relationships, contracts and support are handled from Europe.
- Infrastructure region
- Georgia
- Outside the EEA. All compute and model storage currently run here.
- Commercial operations
- Germany / Europe
- Sales, contracts, onboarding and customer communication.
- International data transfer
- Safeguards available
- For workloads involving EEA personal data, appropriate contractual and technical safeguards may be required.
Roles
You control your data. We process it on your instructions.
The typical allocation of roles. The definitive allocation for your deployment is set out in the DPA.
Customer — controller
You decide which data is sent to the models, for which purposes, and on which legal basis. You remain responsible for determining the appropriate legal basis for your workloads and for informing data subjects.
Lirux — processor
We process prompt and response content and request metadata only to provide the service, on your documented instructions, under a Data Processing Agreement. For our own account and billing data we act as controller — see the privacy policy.
What we process
Three categories of data.
Lirux does not train models on customer prompts, responses or files.
Prompt and response content
ProcessorThe text, audio or documents you send to a model and the output it returns. Processed in memory to produce the response. Whether content is stored at all, and for how long, is configurable on dedicated deployments and set out in your agreement.
Request metadata
ProcessorTimestamp, API key identifier, model, token counts, status code and source IP. Used for billing, rate limiting, security, abuse prevention and operations.
Account and billing data
ControllerNames, business email addresses and invoicing details of your administrators and contacts. Used to run the contract, support and billing.
Retention
Retention is configurable on dedicated deployments; defaults are defined in the DPA. Content logging can be switched off on Private AI Node deployments. Operational metadata needed for security, billing and abuse prevention is still recorded. If you need a specific retention period, tell us before deployment.
International transfers
Georgia is outside the EEA. Here is what that means.
Georgia is not a member of the European Economic Area. At the time of writing there is no EU adequacy decision for Georgia. Sending personal data from the EEA to our compute region is therefore an international transfer under Chapter V GDPR.
Such a transfer requires a transfer mechanism — typically Standard Contractual Clauses (SCCs) — together with a transfer impact assessment that considers the law and practice of the destination country and any supplementary measures.
We support DPA and SCC processes where applicable, provide the information you need for your transfer impact assessment, and describe our technical and organisational measures. The applicable SCC module depends on the contracting setup and is confirmed in the DPA.
Customers remain responsible for determining the appropriate legal basis for their workloads. Speak with us about your data classification before deployment.
Can a European company use this?
Yes. European businesses may use infrastructure outside the EEA. Workloads that involve no personal data can usually run without transfer-specific steps. Workloads involving personal data may require appropriate international-transfer safeguards — such as a DPA, Standard Contractual Clauses and a transfer impact assessment — and internal legal review. Contractual and technical safeguards are available for European customers.
Whether a particular workload is appropriate is a decision for you and your data protection officer. We help by being specific about where and how data is processed.
Data classification guide
Match the deployment to the data.
A starting point for the conversation with your DPO — not a substitute for your own assessment.
- Non-personal data
- Examples
- Public documentation, product catalogues, source code and technical content without personal data.
- Recommended deployment
- Managed AI API or Private AI Node.
- Steps before deployment
- Standard terms of service
- No GDPR transfer mechanism needed where no personal data is processed
- Pseudonymised data
- Examples
- Records where direct identifiers are replaced by keys you hold, e.g. ticket text with customer IDs.
- Recommended deployment
- Private AI Node, content logging off.
- Steps before deployment
- Pseudonymised data is still personal data under the GDPR
- DPA; SCCs and a transfer impact assessment where applicable
- Keep re-identification keys on your side
- Personal data
- Examples
- Customer emails, support conversations, call transcripts, CVs, contracts naming individuals.
- Recommended deployment
- Private AI Node, content logging off, IP allowlisting or VPN.
- Steps before deployment
- DPA and SCCs where applicable
- Transfer impact assessment
- Internal legal / DPO review
- Agreed retention settings
- Special categories (Art. 9 GDPR)
- Examples
- Health, biometric, genetic data, or data revealing political opinions, religious beliefs or trade-union membership.
- Recommended deployment
- Case by case — speak with us before sending any data.
- Steps before deployment
- Individual assessment before deployment
- A data protection impact assessment is often required
- We will tell you if the current region is not a suitable fit
Safeguards available
- Data Processing Agreement under Art. 28 GDPR
- Standard Contractual Clauses where applicable
- Encryption in transit (TLS) on all API traffic
- Access controls: named engineers, key-based access, logging
- Private networking: dedicated nodes, IP allowlisting, VPN on eligible plans
- Configurable content logging and retention on dedicated deployments
- Customer-controlled API authentication: issue, rotate and revoke keys
See Security for how each control works.
Sub-processors
A list of sub-processors is provided with the DPA. The DPA also describes how we inform you of intended changes and how you can object.
EU region
An EU-based region is not currently available. We are evaluating one and will be transparent about timing. If EU data residency is a requirement, tell us — it directly informs our roadmap.
Regions
Georgia
Georgia· Best value- Country
- Georgia
- Inside the EEA
- No
- Status
- Available — production compute region
Current production compute region. Outside the EEA — see Data Processing for transfer safeguards.
EU region
EU region· Not yet available- Country
- Germany (planned)
- Inside the EEA
- Yes
- Status
- Not currently available
An EU-based region is being evaluated. Not currently available — contact sales to register interest.
FAQ
Questions DPOs ask us.
Can European companies use the service?
Yes. European businesses may use infrastructure outside the EEA. Workloads involving personal data may require appropriate international-transfer safeguards and internal legal review. We support contractual and technical measures such as a Data Processing Agreement and Standard Contractual Clauses where applicable. Speak with us about your data classification before deployment.
How does GDPR work?
When you send personal data to Lirux, you are typically the controller and we act as processor under a Data Processing Agreement. Because compute currently runs in Georgia (outside the EEA), a transfer mechanism such as Standard Contractual Clauses and a transfer impact assessment may be required. Our services are designed to support GDPR-conscious deployments, but customers remain responsible for determining the appropriate legal basis for their workloads. This is not legal advice.
Is my data used for model training?
No. Lirux does not train models on customer prompts, responses or files. We serve open-weight models; we do not build our own foundation models from customer data.
What happens to prompts and responses?
Requests are processed in memory to produce a response. Request metadata (timestamp, model, token counts, status code) is logged for billing, rate limiting and operations. Whether prompt and response content is stored at all — and for how long — is configurable on dedicated deployments and defined in your agreement.
Can logs be disabled?
Content logging can be disabled on Private AI Node deployments. Operational metadata needed for security, billing and abuse prevention is still recorded. For the shared API, the default logging behaviour is documented in the DPA. [Configurable per deployment]
How long is data retained?
Retention is configurable for dedicated deployments and agreed in writing. Default retention periods for the shared API are set out in the Data Processing Agreement. Contact us if you need a specific retention period.
Can I get an EU region?
An EU-based region is not available today. We are evaluating one. If EU data residency is a requirement for you, tell us — demand from customers directly informs our roadmap — and we will be transparent about timing.
Not legal advice
Speak with us about your data classification before deployment.
Tell us what kind of data your workload touches. We will walk your DPO through the processing, the safeguards and the DPA.