The register: the founding artefact
Governance starts with an inventory question most operators cannot answer quickly: which models influence player outcomes or money movements right now? The register makes it answerable — one row per model, whether built, bought or embedded in a vendor product:
| Field | What it pins down |
|---|---|
| Purpose & decision | What the model influences — and whether it decides or proposes |
| Owners | Business owner (accountable for outcomes) and technical owner (accountable for behaviour) — named people |
| Inputs | Data classes consumed, with the protection-only boundary from the purpose register respected |
| Autonomy class | Decides alone / proposes to a human / informs only — the human-in-the-loop map, per model |
| Fallback | What runs when the model is wrong, degraded or down |
| Review state | Last reviewed, by whom, next due — the "last confirmed" discipline from the configuration matrix |
The register's honest side effect: filling it usually surfaces two or three models nobody remembered were in production — embedded vendor scoring being the classic find.
Decision rights: consequence draws the line
The workable autonomy rule is about consequence, not sophistication. Models rank and route; humans decide adverse actions. Restriction, withholding, exclusion, complaint outcomes — model input, human decision, logged rationale (the same split abuse detection already applies). Full automation is legitimate where decisions are reversible, low-harm and monitored: ranking a lobby, timing a send, ordering a queue. Two boundaries are absolute regardless of autonomy class: protection signals never feed marketing optimisation, and suppression lists bind every model-driven send exactly as they bind manual ones.
The audit trail
For every model-influenced decision that touches a player adversely, the log answers: which model version, which inputs, what it proposed, who decided, and why where the human diverged. This is the append-only event discipline applied to decisions — and it is what converts "the algorithm seemed fine" into a defensible case file. Model versions deploy like code because they are code: versioned, reviewed, rollback-able, with the register updated in the same change.
Where governance meets each function
- Compliance monitoring — the richest AI surface and the strictest decision-rights terrain: AI in AML, fraud and RG monitoring.
- CRM and personalisation — the highest volume of automated decisions, governed by suppression and consent gates: AI CRM automation.
- Model health — drift, bias and decay as an operational discipline: model risk.
- Vendors — the same governance applied through a contract: the vendor questions.
Starting from an ungoverned present
Most operators adopt governance after the models, not before. The pragmatic sequence: build the register first (two weeks of asking around), classify autonomy and fix the indefensible cases (models silently deciding adverse actions get a human gate immediately), wire decision logging into the highest-consequence models next, and put the review cadence in the calendar with an owner. Perfection is not the bar; being able to answer the five regulator questions without a war room is.
Continue reading: AI in compliance monitoring — the strictest terrain first. The Turbo Stars platform — where the AI layer ships with its governance surface.