Three days in Lisbon are an audit, not a shopping trip
SBC Summit Lisbon 2026 runs 29 September – 1 October 2026 at Feira Internacional de Lisboa & MEO Arena. For an operator those three days are not a place to buy AI, but a place to test claims about it that cannot be tested over a video call.
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.
The conversation has moved from capability to accountability
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 Lisbon. Treat each as a hypothesis to check, not a forecast:
- 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 than it was last year; it makes the paperwork the product. Vendors who have absorbed that shift raise accountability before you do, because a supervisory authority already forced them to write it down. The ones who have not will treat every governance question as friction: a sign they have sold mostly to operators who never had to answer for the output. On the floor the tell is simple: ask who signs the decision when the model is wrong, and watch whether the answer is a role and a process or a shrug back toward the customer. The first is a product that has met a regulator; the second is one that has only met a sales target.
Five questions that separate a running system from a rehearsed demo
Ask them in the same order every time so answers stay comparable, and write them down at the stand, not that evening.
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, not the person who attended. The failure mode of conference procurement is a commercial lead signing for a system no engineer assessed.
Where the claims usually break
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.
There is a quieter failure that outlives the pilot: a model that works on the day you sign and slowly stops working as the market moves around it. Payment mixes change, a new bonus format arrives, a season shifts session behaviour, and a system nobody is retraining drifts out of calibration without ever throwing an error. Ask who owns that maintenance after go-live, on what cadence the model is re-evaluated, and what signal tells them it has degraded before your own numbers do. A vendor who monitors drift describes it unprompted; one who cannot is selling you a snapshot and calling it a system, and the bill for that arrives months later, when nobody remembers which stand it came from.
Structuring 29 September to 1 October 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. One note on the split between Feira Internacional de Lisboa and MEO Arena: moving between spaces costs time, so cluster each day by location rather than topic.
The fortnight after you land
- 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.
What a preview cannot tell you
This is a method, not a forecast. The agenda, exhibitor mix and balance of the conversation are only knowable on site, and anyone describing the specifics of a 2026 event in detail beforehand is guessing. Use the published agenda closer to the date for sessions and speakers.
The method has limits. A three-day audit is not a technical evaluation, and a strong score is evidence of a good conversation rather than a good system. Conferences also over-represent vendors with marketing budgets, which is not the same population as vendors with good products.
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. It compresses a twenty-minute pitch into five.
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.