Every vendor at a trade show sounds convincing until you ask the second question: who runs this in production, and what happens when it is wrong? Most AI pitches in iGaming are built to survive the first question and very little after it. With hundreds of exhibitors at a show like SBC Summit Lisbon (about 800 in 2026), the second question is the only filter that scales.
Treat the show floor as an audit
The method below was first written for SBC Summit Lisbon 2026, which ran from 29 September to 1 October 2026 at Feira Internacional de Lisboa & MEO Arena. It works unchanged for the next edition and for any other iGaming trade show of similar size. For an operator, the value of those three days lies in testing AI claims that cannot be tested over a video call. Buying can wait.
Every stand will describe a model that personalises, predicts, detects or protects, and none of that language is falsifiable from a website. A show floor lets you ask the same awkward question at eleven stands in a row and compare the answers. Those that converge on the same operational detail describe something that exists; those that pivot to vision describe a roadmap.
Picture the scale before you plan the days. The organiser's figures for the 2026 edition put it at roughly 40,000 delegates from more than 150 countries. Over 11,000 of them were operators. There were about 800 exhibitors and sponsors and more than 600 speakers. You cannot wander a floor that size and expect to remember it. The audit only works if you arrive with your questions already written. In 2026, AI also had its own hands-on Tech Academy. If your show has something similar, attend it before you hit the floor, if only to learn the words the stands will use back at you.
The conversation has moved from capability to accountability
The claim worth testing hardest has changed in the last few years. The question used to be whether AI worked in iGaming at all. That is largely settled in the boring direction: recommendation ranking, churn scoring, payment anomaly detection and safer-gambling flags all function somewhere. What is not settled is who owns the output when it is wrong.
Expect that shift to show up in three ways, each of them a hypothesis to check at the stands:
- Conversations that start with model architecture and end with audit logs, because a supervisory authority asked for one.
- Attention on the line between an automated decision and a human one, especially where it touches a player's money or account status.
- Sharper questions about training data provenance: whose players, which markets, and whether your data leaves your environment.
None of this makes the technology more dangerous. It makes the paperwork part of the product. Vendors who get this raise accountability before you do. Vendors who do not will treat every governance question as friction. That usually means they have sold mostly to operators who never had to answer for the output. On the floor the test is simple. Ask who signs off the decision when the model is wrong. A good answer names a role and a process. A bad one shrugs the question back to the customer. A role and a process usually means the product has already been through a regulator's review.
What that review looks like is fairly predictable. Where automated harm detection is expected, the operator still has to show a human checking what the automation did to each customer, and a route for the customer to contest an automated decision. A vendor selling safer-gambling detection into a regulated market should be able to show you that review screen and the contest route. If the demo shows a risk score and nothing about what a human does with it, the operator is left to build the half of the product the regulator cares about most.
The price of that missing half is on the public record. In March 2023 the William Hill group agreed a record £19.2m settlement with the Gambling Commission; among the failures cited, one customer spent £23,000 in 20 minutes without an interaction, and 331 self-excluded customers of its Mr Green brand could still gamble. Neither was a modelling problem. Both were about what happened, or did not happen, after the data said something.
Five questions that separate a running system from a rehearsed demo
The accountability question works best as part of a fixed set. Ask the five below in the same order every time so answers stay comparable, and write them down at the stand while the answer is fresh.
1. "How many operators run this in production today, and how long has the longest-running one been live?" A vendor with real deployments answers with a number and a duration without hesitating. Vagueness ("several", "a number of large brands") is the most reliable warning sign on a show floor.
2. "What happens on the day the model is wrong about a real player?" You want a review queue, an override path, who staffs it, and how long a reversal takes. If the answer is that the model is not wrong, it has not met enough players.
3. "Where does our data sit, and what leaves our environment?" Follow up on whether your data improves a model other operators benefit from. There is no universally correct answer (pooled learning genuinely helps fraud detection) but you need to know which arrangement you are buying and whether it is written down.
4. "What does integration require from my team, in engineer-weeks?" Ask separately about the first connection, the data mapping and ongoing maintenance. Vendors quote the first and omit the third.
5. "Which of your customers switched this off, and why?" Almost nobody asks. Those who answer honestly are worth a second meeting: they have survived a failure and can describe it.
Keep a sixth in reserve for safer gambling and payments: who signs off the decision logic when a regulator asks? If the answer is only the vendor, you have an outsourcing problem. If it is only you, you need documentation nobody has offered.
A scoring sheet you can fill in while standing up
Rate each stand out of 3 on the spot. A filled sheet from thirty conversations survives the flight home; impressions do not.
| Criterion | 0 points | 1-2 points | 3 points |
|---|---|---|---|
| Production evidence | No live customers counted | Live under six months | Several deployments, one over a year |
| Failure handling | "The model handles it" | Review exists, owner unclear | Named queue, override path, turnaround |
| Data arrangement | Cannot describe data flow | Verbal description only | Written terms on residency and training |
| Integration cost | None offered | Setup estimate only | Setup plus maintenance in engineer-weeks |
| Metric commitment | Talks about "efficiency" | Names a metric, no baseline | Metric, baseline and measurement window |
| Regulatory posture | Defers entirely to you | Logs on request | Explains decision logic and sign-off |
Under 9 out of 18 needs no follow-up call. Over 14 deserves a technical session with whoever would maintain it. The failure mode of conference procurement is a commercial lead signing for a system no engineer assessed.
The integration row hides the biggest number, so convert it to money before you compare stands. Take two stands, with figures invented for the arithmetic and an assumed loaded cost of EUR 2,500 per engineer-week. Stand A quotes four engineer-weeks to connect and half a week a month to maintain: 4 plus 6 is 10 weeks in year one, about EUR 25,000. Stand B quotes two weeks to connect, which sounds better on the floor, but admits to two weeks a month of mapping fixes as your event schema changes: 2 plus 24 is 26 weeks, about EUR 65,000. Stand B scored higher on the demo and costs 2.6 times as much to keep alive. A sheet that records only the setup estimate would have ranked them the other way.
A tie-breaker follows from that. When two stands score within two points of each other, pick the one with the lower year-one engineering total, whatever the demo looked like.
Where the claims usually break
Even a stand that scores well on the sheet tends to fail in the same three places, so probe each one before you shortlist it.
Latency and the moment of decision. A churn score computed overnight is a different product from one computed mid-session, yet both are sold with the same vocabulary. Ask when the score is produced relative to the action it should influence. If it is a batch job, the use cases narrow.
Cold start and market transfer. A model trained on one regulated market does not transfer automatically to another with different payment rails, bonus norms and session patterns. Ask what happens in the first eight weeks where the vendor has no history, and who pays for it.
The measurement problem. Uplift claims mean something only against a holdout group. If nobody can describe how the control group was built, the number is a before-and-after comparison wearing a lab coat, and seasonality may explain it.
None of these disqualify a product. They change what you pay and how long you pilot.
One quieter failure outlives the pilot. A model works on the day you sign and then slowly stops working as the market moves. Payment mixes change, a new bonus format arrives, the season changes how people play. A model nobody retrains drifts off target without ever throwing an error. Ask who looks after it after go-live, how often it is re-checked, and what warning tells them it has slipped before your own numbers do. A vendor who watches for this mentions it without being asked. One who cannot is selling a model frozen on signing day. The bill arrives months later, when nobody remembers which stand it came from.
Structuring three show days so the trip pays for itself
The common failure is treating all three days identically and coming home with collateral instead of decisions.
| Day | Purpose | What you leave with |
|---|---|---|
| Day one | Wide sweep: short conversations, five questions, scoring sheet | A shortlist of 6-10 stands |
| Day two | Depth: longer sessions with the shortlist, plus regulation content | Two or three candidates with integration estimates |
| Day three | Peers, not vendors: operators of similar size in similar markets | Honest accounts of what did not work |
Day three is the one people skip and the one that returns most: a vendor cannot tell you what it feels like to run their system through a bad month, and another operator will, more candidly than in any panel. At a split venue such as Lisbon's Feira Internacional and MEO Arena, moving between spaces costs time, so cluster each day by location rather than topic.
The fortnight after you land
Conference notes go stale fast, and a shortlist nobody outside the trip has seen rarely survives the next budget meeting.
- Within 72 hours, transcribe the scoring sheets into one shared document while you still remember which conversation was which. Anything not written down now is lost.
- Within a week, circulate the shortlist to the people who would operate the system and let them add questions you did not think to ask. Their objections are cheaper now than during implementation.
- Within two weeks, ask your two strongest candidates for a written pilot scope: one metric, one baseline, one time window, one named owner each side, and an agreed definition of failure. Vendors who resist that last item have told you something.
If no candidate survives, the trip still worked. A summit that stops you buying the wrong system pays for itself more cleanly than one that starts a project you abandon by spring.
The method is biased against young vendors, and sometimes that is wrong
The scoring sheet has a blind spot: it punishes young companies. A team that is twelve months old cannot have a deployment older than a year, so it loses three points before anyone looks at the model. Yet young teams often have the sharpest ideas. An operator that only buys from established vendors pays their prices for their thinking. Make an exception when a young vendor scores 3 on failure handling and on data terms despite having few customers. Those two rows show the team has thought about the day the model is wrong, which is what production experience is supposed to teach. Offer such a vendor a shadow pilot instead of a contract. For eight weeks the model scores your live players but changes nothing, and you compare its calls with what actually happened. If it would have beaten your current rules often enough, sign. If not, you have lost part of one engineer's time for eight weeks and nothing more.
The method has other limits. A three-day audit is not a technical evaluation, and a strong score is evidence of a good conversation; the system still has to prove itself. Conferences also over-represent vendors with marketing budgets, which is not the same population as vendors with good products. With about 800 exhibitors, the best fit for your market may simply not have a stand. The agenda and exhibitor mix also change with every edition, so plan from that year's published agenda rather than from this one.
Questions operators ask before booking the trip
Is it worth going with no AI budget this cycle? Yes, for the mapping rather than the buying. Knowing which categories have real deployments and which are still pre-production shapes next year's budget, and that is hard to learn remotely.
Who should we send? One person who owns a metric and one who would maintain the system. A commercial lead alone returns with enthusiasm and no estimates; an engineer alone returns with estimates and no sense of which problem is worth solving.
How do we avoid hearing the same pitch three times? Ask the five questions before letting the demo run. A stand that has to answer them first cannot run its standard script, so a twenty-minute pitch shrinks to five minutes of specifics.
What if our data is not ready for any of this? That is the most common honest position and a good reason to attend. Find out what data state each vendor requires (event granularity, history depth, identity resolution) and you leave with a data roadmap instead of a purchase.
How much of what we hear will still be true in a year? Less than it sounds. Treat roadmaps as intent rather than commitment and contract against what runs today. The parts most likely to hold are operational: review queues, data terms, integration cost.