By Chris Autrey, CTO
Every vendor deck has AI in it now.
Some of it is real. Some of it is a skin over a commodity model with a price markup. The difference matters more in our industry than in most, because the cost of getting it wrong isn’t just a bad quarter. It’s a compliance finding, a failed audit, or a regulator asking a question you can’t answer.
I’ve spent my career building software for regulated environments. The bar is different here. Systems get judged by how they behave when the stakes are real, not how they demo on a conference stage.
If you’re evaluating AI tools or AI-enabled software for your casino, here’s what I’d hold them to.
1. Know which of the three things you’re actually buying.
There are three categories on the market right now.
An existing product with AI features added. The product hasn’t changed. A capability was bolted on.
A product that exists because of AI. Computer vision on the table. Voice analytics in the call center. ML-driven kiosk routing.
A rules engine that was rebranded as AI last quarter.
The first two are legitimate. The third is marketing. The test is simple: ask the vendor to describe what model is doing what, trained on what, producing what output. If the answer is evasive, you have your answer.
2. AI doesn’t create regulatory exceptions.
Regulatory obligations don’t soften because a model generated the report. SOC 2 controls don’t pass because the vendor has an AI story. Gaming commission expectations don’t change because the feature is new.
If a model is involved in CTR or SAR workflows, even as a suggestion engine, the audit trail has to survive scrutiny. “The model recommended it” is not a defensible answer to a regulator.
Different jurisdictions are at different stages on AI-specific guidance. Before you roll anything out, confirm whether your regulator has a position.
3. Ask what data leaves your environment.
This is the question before the question.
When this product runs, what data goes where, and what happens to it there?
Get the answers in writing. Is patron data used to train the vendor’s models? Who are their sub-processors, including their AI provider? Where is inference happening geographically? What’s the retention policy on prompts and completions? Is there a documented process for deletion on request?
Most AI vendors are routing traffic through a frontier model provider as a sub-processor. That’s not automatically a problem. It is automatically a question.
4. Demand model provenance.
What model? What version? Who built it? How often it changes?
Vendors swap models without notice. That can change behavior in ways that matter for reproducibility, and reproducibility matters when an auditor asks why a decision was made six months ago.
If the vendor can’t tell you what’s under the hood today, they can’t tell you what was under the hood when the output you’re defending was produced.
5. Explainability scales with stakes.
Not every AI output needs to be fully explainable. A demand forecast informing a buyer’s decision is not the same as a model flagging a patron for enhanced due diligence.
The working test: if this output ends up in front of a regulator, an auditor, or in a legal proceeding, can you reconstruct how it was produced? Not the weights. The inputs, the version, the context, and the post-processing.
If you can’t reconstruct it, you either need explainability improvements or a human decision layer on top. Usually both.
6. Be specific about human-in-the-loop.
Every deck has the phrase. Most of the time it means very little.
There is a large gap between a human reviewing every output and a human having the theoretical ability to override an output that gets auto-approved 99% of the time.
Useful questions:
- What’s the default path when the model is confident?
- What triggers human review?
- What training do the reviewers have?
- What happens to their overrides?
For anything touching compliance, patron identification, or financial reporting, the default should be that the model assists and the human decides. For low-stakes operational optimizations, more automation is fine.
7. Measure it honestly or don’t run the pilot.
AI pilots die for the same reason most pilots die. No baseline. Vague success criteria. Scoped to prove the technology worked rather than prove the business case.
Before any AI pilot, write down what the current process costs in time, error rate, and customer impact. Write down what success looks like in numbers. Write down the criterion that kills it.
Revisit at the end honestly. A tool that doesn’t clear the bar isn’t a failure. It’s data. Treating it as production-bound because the technology is interesting is how budgets get wasted.
8. Get your internal policy in place first.
Before you roll any AI tool out to employees, three things need to exist.
An acceptable use policy. What data can go into a third-party AI tool, and what can’t.
A disclosure policy. When AI is used in producing customer-facing or regulator-facing output, how is that disclosed.
Basic training. So staff understand both the capabilities and the failure modes of the tools they’re using.
The most common AI incident at companies right now is an employee pasting sensitive data into a public AI tool because nobody told them not to. A one-page policy and a short training prevents most of it.
AI is moving into casino operations in a real way. Forecasting, cash management, audit workflows, player experience. The value is real. The risk is also real.
The executives who do this well won’t be the ones who adopt the fastest. They’ll be the ones who apply the same procurement rigor they already use for any other vendor decision, with an AI-specific layer on top.
The tools earn their place in the operation. Or they don’t.
