How CasinoOS uses AI
Draft for review by counsel. This is not legal advice. Text in [square brackets] must be filled in or confirmed before publication. Check every statement against the code before each release.
Effective [date]. Version 0.1.
This statement is for operators, their regulators, auditors and test labs. It says what the AI in CasinoOS does, what it never does, where a person decides, and how each AI action can be checked afterwards.
1. Summary
- AI prepares work. People decide on every offer and every hold. Replies follow the operator's Approve all setting: when it is on, every reply needs approval by a member of staff with the right role. When it is off (the default), staff replies go out when the writer sends them, and the AI sends low-risk replies by itself.
- AI answers a player directly in the live chat widget, for general questions, and in the inbox for low-risk cases while Approve all is off. It cannot see or change any account. The widget says that it is an AI assistant.
- Messages about a crisis, self-exclusion, account closure, possible underage play or data-protection rights never get an AI answer. They get a fixed reply and go to a person.
- Before any model call, player ids are replaced with tokens and contact, payment and identity data are removed.
- Every AI action is recorded in a tamper-evident audit trail, with what the model saw and said (as hashes), the model and prompt version, and why the result was used or blocked.
2. Where AI is used
| Feature | What the AI does | Who decides |
|---|---|---|
| Inbox triage | Suggests intent, priority, sentiment and whether a case needs escalation. | Staff. Crisis and self-exclusion signals are also detected by fixed rules that do not depend on the model. |
| Inbox reply drafts | Writes a draft reply in the operator's tone. | Approve all on: a person edits it and a second staff account approves it before it is sent. Approve all off: the AI sends it only when fixed rules find the case low risk (server/autoreply.mjs); otherwise a person edits and sends it. Routed responsible gambling cases and handed-off cases always need approval. |
| Live chat widget | Answers general questions about how the site, games, deposits and safer gambling tools work. | Approve all off: sent at once, after the guardrails in section 4. Approve all on: held for a person, and the player is told a person will reply. Either way it cannot see accounts, promise outcomes, or offer, credit or refund anything. |
| Command bar | Opens the right screen with work prepared. | It never sends a message, grants a bonus or changes a setting. |
| Translation | Translates replies. | Machine-translated replies are marked for review and go through the same approval. |
Responsible gambling and AML scoring use fixed, documented rules (server/compliance/rg.mjs, aml.mjs), not a model. RG scores can trigger protective actions at once (stop marketing, withdraw offers, lower a limit), because those only reduce a player's exposure. AML scores lead only to a review by a person. A withdrawal hold or enhanced due diligence needs approval.
3. What the AI never does
- Send an inbox reply, offer or bonus without a person's approval.
- Answer a crisis, self-exclusion, closure, underage or data-rights message.
- Move money, change a balance, place a bet or change a game outcome.
- Raise a deposit limit, lift a self-exclusion, or close an account.
- Make a final KYC, AML or responsible gambling decision.
- See a player's name, contact details, payment details or player id.
4. Guardrails on AI output
- Fixed routes before the model. A message is checked for crisis, self-exclusion, underage and data-rights signals before any model call. A match gets a fixed reply and goes to a person.
- Output checks. Model output is checked for promises or guarantees of winnings, statements that money was credited, refunded or paid out, card-like numbers, and, in conversations with signs of gambling harm, offers. Look-alike characters and spacing tricks are normalised first. A reply that fails gets a rule-based reply instead.
- Market rules. An offer, or a support reply that contains one, is checked against the player's market rules before it can be approved.
- Routed cases. On a case routed to the responsible gambling team, a reply can be approved only by the compliance or owner role.
- Fallback. Without a model key, or when the model fails, the Service uses fixed rule-based replies.
5. Data sent to AI providers
| Sent | Not sent |
|---|---|
| The message text, with contact, payment and identity data removed | Player name, email, phone, postcode, player id |
| A keyed token in place of the player id | Card numbers, IBANs, account numbers |
| VIP tier, KYC status and a balance band | Exact balance, transaction history |
| The market's rules and helplines | Staff identities |
The provider is Anthropic (Claude). It is listed in annex 3 of the data processing agreement. It may not use the data to train its models under the API terms we use. [Confirm against Anthropic's current terms.]
6. Transparency to players
- The live chat widget is labelled "AI assistant" in its header, its typing indicator and its replies. Under Article 50(1) of the EU AI Act, people must be told they are talking to an AI system unless it is obvious. This applies from 2 August 2026.
- With Approve all on, inbox replies are written or approved by a person, who is responsible for them. With it off, low-risk inbox replies may be sent by the AI without review, so the operator should say so in its privacy notice. The player privacy notice template has wording for both.
7. Audit and accountability
Each AI action writes an audit entry with:
- the provider, model and prompt version (
PROMPTSinserver/server.mjs) - SHA-256 hashes of exactly what the model saw and said
- the source of the final text: model, rules, guardrail or fixed reply
- the reason it was used or blocked
- the market profile version
The log is append-only and hash chained. With an HMAC key set, someone who can edit the file but does not hold the key cannot rebuild the chain. Owner and compliance roles can verify the chain and export it for a regulator.
8. Known limits
We state these so operators can plan around them:
- The four-eyes rule covers replies only, and only while Approve all is on. Then a different staff account must approve a reply than the one that wrote it, in the hub, Slack and Teams, and there is no override. With Approve all off (the default), ordinary replies have no second check and low-risk ones are sent by the AI. Routed responsible gambling cases and handed-off cases always need a second account. Bonus offers are proposed by the AI and approved by one support agent, with no second approver; the operator's bonus limits apply to every proposal. Other actions that need a person, such as holds, are not yet approved through the server, so operators that need separation of duties for those must enforce it by process.
- There is no knowledge base. "Low risk" is decided by fixed rules on the case and the draft, not by matching against approved answers.
- The RG and AML thresholds are not validated models. They are documented starting points to be calibrated on the operator's data with its RG lead and MLRO.
- Guardrails reduce risk but cannot remove it. A model may still produce an inaccurate answer to a general question in live chat. The widget tells players that a person can help with anything about their account.
- Prompt injection. Player messages are untrusted. The guardrails act on the output whatever the input says, but this is an area of active testing.
9. Governance
Prompts are versioned, and changes are reviewed through pull requests. Evaluation records and the change log are described in the model governance policy (docs/compliance/policies/model-governance.md). Questions about this statement go to [AI governance contact].