Data & security brief

Where your players' data actually lives.

The precise version, not the reassuring one.

This is the first question every operator asks us, and most vendors answer it with a sentence designed to end the conversation. Below is the whole data path instead — what stays with you, what leaves, what is removed before it does, and how you verify any of it. Written to be forwarded to your DPO.

The short answer, in four sentences

PlayerDesk is installed inside your infrastructure. We operate no player database and hold no copy of your book.
Identifiers are tokenised before any request leaves your perimeter, and the mapping back to a real player never leaves you.
The language model runs in the EU under zero retention: requests are not stored after the response and are never used to train a model.
Every request is traceable — what was sent, what was redacted, which endpoint answered — in a log your DPO reads directly.

The rest of this page is each of those four in detail, including the parts that are uncomfortable.

1. What is deployed where

PlayerDesk runs in your environment — your cloud account, your VPC, or your own hardware. It is not a multi-tenant SaaS with your players in someone else's database.

Stays inside your perimeter

Player database. Event stream from your PAM. Conversation history. The token–identity mapping. Audit and reasoning logs. Your knowledge base. All of it, permanently.

Leaves your perimeter

One thing: the redacted text of the conversation currently being answered, plus the retrieved policy snippets needed to answer it — sent to a language model endpoint and discarded after the response.

Never exists at all

An Arctura-side copy of your players, your chats or your outcomes. There is no central database of operator data on our side to be breached, subpoenaed or sold.

Arctura engineers do not have standing access to your environment. Access for support or incident work is granted by you, limited to named individuals, time-boxed and logged — on your side, where you can revoke it without asking us.

2. The redaction pass — and its honest limits

Before any request leaves your environment, it goes through a redaction stage that runs inside your perimeter. It works in layers, because no single technique is sufficient:

Structured identifiers, deterministically. Player ID, account number, email address, phone number, IBAN and card numbers (validated by checksum), document and national ID numbers, physical addresses, transaction references. These follow known formats and are replaced with stable tokens — <PLAYER_7f3a> rather than a name — so the model can still reason about "the same player" without knowing who that is.
Free text, by named-entity recognition. Players write their own names, their relatives' names and their locations in the middle of sentences, where no pattern catches them. A local NER pass over the message flags person names, organisations and places for tokenisation before the request is assembled.
Attachments and structured payloads. PAM responses are mapped to the fields the answer actually needs. A KYC status check returns a status, not a document.

Where this stops being perfect — and what covers the gap

We will not tell you that redaction is airtight, because it is not, for us or for anyone else. A player can phrase something in a way that no pattern and no model catches. Free text is adversarial by nature.

So redaction is the first layer, not the only one. Underneath it sit three more: zero retention at the model provider, so anything that slips through is not stored; EU-only processing, so it never leaves the jurisdiction; and a contractual no-training guarantee, so it cannot end up in a model's weights. Any vendor who tells you their redaction alone makes the question moot is either not thinking about it or hoping you aren't.

If your regulator or your own risk appetite requires that nothing whatsoever leaves the perimeter, PlayerDesk runs on a self-hosted open-weights model inside your environment. It costs more in infrastructure and gives up some quality; we will tell you honestly which of your topics that trade-off affects.

3. The model providers, named

We do not hide behind "industry-leading AI providers". The language model behind your deployment is one of Anthropic, OpenAI or Azure OpenAI. Which one is fixed when your deployment is configured, written into your contract, and not changed without notifying you in advance.

EU region

Requests are served from EU-region endpoints. No transfer of conversation data outside the EU/EEA.

Zero retention

Endpoints are configured so that requests are not persisted after the response is returned.

No training on your data

Enterprise terms prohibit the use of your requests for model training or improvement. This is contractual, not a setting.

Named in your DPA

Every sub-processor is listed with its role and region, and any change is notified before it takes effect.

Supporting infrastructure that Arctura operates on its own side — nothing containing player data — is EU-hosted (Hetzner, Frankfurt). The contracting entity is Gazolin Production SRL, Baia Mare, Romania, trading as Arctura.

4. How you verify it rather than trust it

Every request PlayerDesk makes is recorded in your environment with a full trace: the original message, the redacted version that was actually transmitted, which fields were tokenised, which endpoint answered, the response, and the reasoning that led to the action taken. Your DPO reads the same log we do, in the same place, without asking us for an export.

That trace serves three audiences at once: your compliance team reviewing a specific player's case, your DPO answering a subject access request, and your regulator asking why an automated system said what it said. It is also what makes the quality-control layer possible — you cannot grade a decision you cannot reconstruct.

Deletion follows your retention policy, not ours. The logs live in your storage under your rules. There is nothing on our side to delete, which is a simpler answer than a deletion certificate.

5. Roles, agreements and the regulatory frame

GDPR roles. You are the Controller: the player relationship and the purpose are yours. Arctura acts as Processor, on your written instructions only. No re-use, no independent decision-making, no onward sharing beyond the named sub-processors.
DPA. Available on request and finalised per operator — your legal entity, your jurisdiction, and whatever clauses your counsel wants added. We deliberately do not post a generic PDF: an agreement that isn't specific to two named parties is a template, and stale templates linger in inboxes. Email hello@arctura.eu and ask for the PlayerDesk DPA.
Sub-processors. Named in the DPA with region and role. Changes notified in advance, with the right to object.
EU AI Act. An automated support agent interacting with consumers carries transparency obligations. Players are told they are talking to an automated system, human escalation is always reachable, and every decision carries a reasoning trace — which is also what an Article 86 explanation request needs.
Responsible gambling. RG language in a conversation is an unconditional escalation trigger. It is never handled automatically, in any jurisdiction, regardless of confidence.

What to ask us — and every other vendor

These are the questions that separate a real answer from a comfortable one. We publish them because we would rather be measured against them than against a brochure.

Is the system deployed in my environment, or is my data in your database? Say which, precisely.
What exactly leaves my perimeter on a single request? Show me one, redacted and unredacted.
Which model provider, in which region, under what retention and training terms? Name them.
What happens to data that your redaction misses? What is the second layer?
Can my DPO read the request log without asking you for it?
What is your answer if my regulator asks why the system said a specific thing to a specific player?

The full buyer's guide — 12 questions vendors hope you won't ask →