A casino does not need perfect data or a large technology program before testing an AI-supported workflow. It does need a defined problem, controlled source material, named owners, a review process, and a clear way to decide whether the pilot helped.
The preparation is mostly operational. Managers should be able to explain what happens today, where the process loses value, which record is authoritative, who may see the information, and who approves the final output. Choosing a model comes later.
Prepare a one-page problem statement
Begin with one workflow and describe it without using the word “AI.”
A useful statement contains:
- Current task: what the department prepares, checks, or decides.
- Current friction: wasted time, inconsistent fields, missing ownership, late reporting, repeated errors, or unclear follow-up.
- Operational consequence: what management cannot see or do reliably.
- Target output: the report, checklist, comparison, or draft the pilot should produce.
- Excluded decisions: what remains outside the pilot.
For example:
The current cage handover records open exceptions in free text. Management cannot consistently see amount, document status, owner, approval state, and next action. The pilot will prepare a structured exception summary from approved sample records. It will not decide shortage cause, responsibility, transaction approval, or regulatory reporting.
This statement is already more valuable than “we want a cage AI tool.”
Collect a representative source pack
Do not begin with one unusually clean example. A pilot should see the normal range of work.
A representative source pack may contain:
- three to five ordinary examples;
- at least one incomplete or late example;
- an example with a correction;
- an example containing an exception or dispute;
- the blank approved form or report template;
- the relevant procedure, field definitions, and status codes;
- the approved final output for comparison.
Use redacted, anonymized, synthetic, or previously approved material when possible. The pilot does not need unrestricted live data to prove that the workflow logic is useful.
Identify the system of record
Every material field should have an owner and an authoritative source. An email may explain a situation, but the approved incident record may remain authoritative. A dashboard may display a figure, but the CMS export or financial report may own the value. A generated summary is never the source merely because it is easier to read.
Create a simple source map:
| Information | Authoritative source | Owner | Allowed pilot use |
|---|---|---|---|
| Shift staffing | Approved roster and attendance record | Shift manager / HR-defined owner | Compare planned and actual coverage |
| Cage exception | Variance and supporting documents | Cage supervisor | Prepare open-item summary |
| Surveillance status | Authorized case or request system | Surveillance management | Show approved status only |
| Slot performance | Approved statistical report | Slots / finance-defined owner | Calculate and explain selected indicators |
If the source map cannot be agreed, the pilot is likely to reproduce existing confusion more quickly.
Classify the information before uploading anything
Managers should not assume that information is safe because it already appears in an internal report. A pilot may involve player identifiers, employee records, surveillance material, financial information, credentials, security procedures, health details, or legally protected information.
For each field, decide:
- whether the pilot needs it at all;
- whether it can be removed, masked, generalized, or replaced;
- where it may be processed;
- who may access the input and output;
- how long it will be retained;
- how corrections and deletion are handled;
- whether a third-party service receives it.
The [NIST Privacy Framework](https://www.nist.gov/privacy-framework) is a voluntary tool for identifying and managing privacy risk. It is not casino-specific legal advice, but it provides a useful reminder that privacy risk arises from data processing itself, not only from a cybersecurity breach.
Name six operating roles
Small pilots often fail because everyone supports the idea but no one owns the work. Assign these roles even when one person performs more than one of them:
- Business owner: accountable for the department problem and operational value.
- Source owner: confirms the authoritative records and field meanings.
- Reviewer: checks each pilot output against the source.
- Approver: decides whether the output may enter the official workflow.
- Technical owner: controls access, environment, integration, logging, and support.
- Risk adviser: covers compliance, privacy, legal, information security, HR, surveillance, finance, or another affected function as required.
“Management will review it” is not a role assignment. The preparation document should name the responsible position and the evidence that person checks.
Define allowed and prohibited actions
A clear permission table prevents gradual expansion during the pilot.
| The pilot may | The pilot may not |
|---|---|
| Extract defined fields from approved samples | Search unrestricted department files |
| Flag missing or contradictory information | Resolve the contradiction automatically |
| Draft a management summary | Publish it as an approved report |
| Suggest questions for a reviewer | Accuse a player or employee |
| Compare approved scenarios | Change a live schedule, limit, game, offer, or transaction |
The list should be specific to the workflow. Generic governance wording is not a substitute for operational permissions.
Prepare the benchmark answer
Before testing the tool, experienced staff should review the sample pack and record what a correct or useful output should contain. This is the benchmark.
For a shift report, the benchmark might identify the five material events, three open actions, two unresolved facts, and the correct executive summary. For an SOP review, it might list missing roles, unclear sequence, absent escalation, and inconsistent terminology.
Without a benchmark, reviewers tend to judge the output by writing quality. A confident paragraph can receive a high score even when it misses the most important exception.
Choose measurable acceptance criteria
A pilot should have a small set of measures tied to the operating problem.
Examples include:
- percentage of required fields captured correctly;
- percentage of material benchmark issues surfaced;
- unsupported statements per output;
- corrections required before approval;
- preparation and review time;
- percentage of open items with owner and next action;
- reviewer acceptance, rejection, and escalation rates.
Set the measures before seeing the results. Do not define success afterward as whatever the tool happened to do well.
Prepare failure and stop conditions
The pilot should stop or pause when:
- out-of-scope sensitive data enters the workflow;
- the source cannot be verified;
- the system presents a draft as an approved conclusion;
- reviewers cannot explain why an output is wrong;
- staff begin bypassing the official process;
- correction rates exceed the agreed threshold;
- the vendor or technical environment changes materially;
- logs, access controls, or retention rules fail.
A reversible pilot is safer because stopping it does not stop the department.
Questions for a vendor or internal technical team
Casino management should obtain clear answers to:
- Where are prompts, files, outputs, and logs stored?
- Are they used to train or improve any model?
- Which employees, subcontractors, or support teams can access them?
- What are the retention and deletion rules?
- Can the casino restrict regions, models, connectors, and file types?
- How are permissions separated by department and role?
- Can outputs be traced to input sources and model versions?
- What happens when the service is unavailable?
- How are incidents reported and investigated?
- Can the casino export its records and end the service cleanly?
The [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) provides a useful voluntary structure for governing AI use, mapping the context and affected parties, measuring performance and risk, and managing identified problems. It should be applied alongside the casino’s own approved controls and jurisdictional obligations.
A minimum pilot pack
Management should be able to hand the implementation team one folder containing:
- the one-page problem statement;
- representative, approved sample records;
- the blank form or expected output;
- field definitions and status codes;
- source and role map;
- data-classification decisions;
- allowed and prohibited actions;
- benchmark outputs;
- acceptance and stop criteria;
- approval and change log.
That pack is enough to begin a controlled discovery and prototype. It also exposes whether the department is ready. If the casino cannot locate the approved form, agree on the field meaning, or name the approver, the immediate improvement may be process clarification rather than technology.
Choose the workflow, then the tool
The [department AI plans](/en/department-ai-plans/) help managers identify appropriate workflows by operating area. The [CasinoOpsAI methodology](/en/methodology/) explains evidence classes, decision authority, and information boundaries. [ReportHub](/en/report-hub/) provides a concrete example of how source intake, review, approval, and management reporting can be separated.
The casino is ready for a first pilot when it can describe the work more clearly than the technology. That clarity protects the operation and gives the implementation team a fair chance to build something managers can actually use.