Most first AI projects in gaming die between pilot and production. Usually the outcome is decided on day one, when the team picks what to build. Choose a project whose hard parts nobody has found yet, and the money runs out before you find them. Choose one with plenty of past examples, such as 40,000 answered support tickets a month, and 90 days is enough to produce a saving finance can check.
Why your first AI project should probably be the boring one
Operators with nothing in production usually want to start with the model that recommends games. It demos well internally and it is the hardest item on the list to get right cold: it needs behavioural depth per player, an experiment framework capable of proving lift, and a merchandising surface an algorithm can actually change.
A better first project is support deflection, answering the twenty or so questions that make up most of your ticket volume: where is my withdrawal, why was my bonus not credited, why does verification want another document. Four things make it the safer bet.
- Ground truth already exists: ticket history is a labelled set of questions and the answers agents gave.
- The metric is unambiguous, and finance already tracks cost per contact.
- Failure is contained. A weak answer produces an escalation; a mispriced market or a licensing incident is off the table.
- The team fits in one room: product owner, engineer, support lead.
Suppose, with numbers chosen for illustration, that a mid-size operator handles 40,000 support contacts a month at a fully loaded cost of EUR 3.20 each, roughly EUR 128,000 monthly. Deflect 22% cleanly and you save about EUR 28,000 a month before licence and engineering costs. Whether 22% is achievable on your traffic is precisely what a first deployment exists to find out.
The twenty questions are not random. In gaming, support tickets follow the money and the friction around it. A withdrawal is held for review. A bonus did not arrive because a wagering condition was still open. Verification asks for a document the player is sure they already sent. These questions repeat because the processes behind them repeat. That is why a knowledge base can answer them.
There is a catch: the easy questions run out. The first wave of savings is cheap. The tickets left after that are longer, angrier and more specific. A rate that looks healthy in week two can drop once the system reaches the harder cases. Plan for that.
Commercial teams will push back. Every helpdesk vendor already sells support bots, so a competitor can buy the same thing next quarter. A game recommender that lifts deposits per player keeps paying off and stays yours. They are right in one situation. The operator already has one ID per player across all systems, a working way to run A/B tests and a lobby an algorithm can reorder. Then the hard parts of personalisation are already paid for, and starting with support wastes a quarter. Without those three things, the recommender spends half a year rebuilding data plumbing with nothing to show. The support project builds the same plumbing and pays for itself on the way.
The plumbing you need before anyone writes a prompt
Stalled AI projects in gaming are rarely model problems. They are integration problems discovered in month four.
One player identity. If the same person appears under different keys in the wallet, the sportsbook, the CRM and the helpdesk, every prediction describes a fragment of a person. Reconciling identity often takes longer than the modelling.
Event history with honest timestamps. Deposits, stakes, session boundaries, bonus grants, verification status, contact records. Six months is a workable minimum, and you need to know which columns were backfilled or changed meaning during a platform migration.
Written label definitions. "Churned" is a decision you make (no real-money session in 30 days, or 60), and the warehouse will not make it for you.
A residency map. Which tables may leave the jurisdiction, which a sub-processor may see, what must be deleted on request, and how that deletion reaches training sets and vector stores.
| Readiness signal | Why it decides the project | Warning sign |
|---|---|---|
| Unified player ID | Every feature depends on it | Tickets will not join to wallet history |
| 6+ months of events | Bonus cycles distort short windows | Only the current platform's data survived |
| Documented labels | Nothing to train or test against without them | Churn differs in CRM and BI |
| Residency map | Decides if a hosted model is usable at all | Nobody knows where inference happens |
The teams that stall rarely picked the wrong model. More often they assumed identity, history and labels were already solved because a dashboard existed. A dashboard hides the joins that quietly drop the rows that do not match, so the numbers on screen look complete while the data underneath is not. Before trusting any of it, pull ten real players and trace them by hand across wallet, sportsbook, CRM and helpdesk. If you cannot reconstruct one person's month from the raw tables, nothing built on top of them will describe that person either.
Ninety days, shaped around evidence gates
The deployment exists to produce one number that finance and compliance both believe, so each stage of the quarter ends with a piece of evidence instead of a delivery date.
Weeks 1 to 3: measure the baseline by hand. Categorise 300 to 500 recent tickets and record handling time and first-time resolution. Tedious, and the only thing that makes the later comparison meaningful. Write the intent taxonomy from what you find; a vendor template will describe someone else's players.
Weeks 4 to 7: build against retrieval. Ground answers in your current terms, bonus rules and payment timelines rather than model recall, and keep the document set versioned so that when a promotion changes, the answer changes with it.
Weeks 8 to 10: agent-assist before customer-facing. Let the system draft and let agents approve or reject: an accuracy signal from real staff at zero player risk, and the rejections are your best training data.
Weeks 11 to 13: limited live release with a holdout. One or two languages, one or two intents, 10 to 20% of eligible traffic, and a control group that never touches the system. Without it, seasonality takes the credit or the blame.
The control group only helps if it is big enough to tell a real change from noise. When the effect is a few points, a control of a couple of hundred contacts a week will not settle anything within the quarter. Size it for the effect you expect.
Here is the arithmetic. Say you want to tell a re-contact rate of 12% from one of 15%. With the usual settings (80% power, 5% significance), a standard rule of thumb is 16 × p(1-p) / d². That gives 16 × 0.13 × 0.87 / 0.0009, or about 2,000 contacts in each group. At 40,000 contacts a month, a 10% control collects that in about two weeks. At 4,000 a month it takes five months, longer than the pilot.
Do not shrink or drop the control because the early numbers look good. Without it, you cannot prove the project paid for itself, and that proof is why the pilot got funded.
Decide early what triggers handover to a human and what the system must never attempt. Self-exclusion, affordability, complaints and account closure belong in the second list from day one.
What the first year actually costs
Most of the money goes somewhere other than the vendor invoice. Vendor pricing is quoted per message or per thousand tokens, usually the smallest line in the budget. Planning figures for the same hypothetical operator, EUR, twelve months:
| Line | Illustrative annual cost | Note |
|---|---|---|
| Model or platform usage | 25,000 | Often under a fifth of the total |
| Engineering time | 90,000 | Integration, retrieval, monitoring |
| Knowledge-base upkeep | 30,000 | Someone owns the answers permanently |
| Compliance and legal review | 20,000 | Impact assessment, per-market checks |
| Evaluation and QA | 25,000 | Sampling, red-teaming, regression sets |
Against roughly EUR 190,000 of cost, the deflection example returns about EUR 336,000 a year at full scale, but only after ramp, and only if quality holds once the easy questions are exhausted. Model a partial year and a low case too. Spread over twelve months, the EUR 190,000 is about EUR 15,800 a month, and against EUR 128,000 of monthly contact cost that means the project breaks even at roughly 12.4% clean deflection. At 12% it loses a little money; at 22% it returns about EUR 146,000 a year net.
Ramp changes the first year more than the rate does. If deflection climbs evenly from zero to 22% over six months and then holds, the first half averages about 11% and saves roughly EUR 84,000, the second half saves about EUR 169,000, and year one ends around EUR 63,000 ahead. Stretch the ramp to nine months and most of that margin disappears. If the case only works at the optimistic rate and the fast ramp, treat it as a bet.
Compliance is a design input, not a sign-off at the end
Responsible-gambling signals should flow one way. A model that can see markers of harm must not also feed marketing selection, and that separation belongs in the data layer, where a policy memo cannot reach.
This rule sounds like a policy line, but it breaks easily in practice. The usual cause is a shared store of player data. A churn or value model reads the same behaviour numbers that the safer-gambling model uses to flag risk. Suddenly the group chosen for a comeback bonus overlaps with the group showing signs of harm. Nobody chose that. The data setup did. So the split has to be built where the data lives, with separate sources for each model. Otherwise it breaks again every time someone reuses a handy column.
Regulators already expect this split. A model that learns to target players showing signs of harm is the clearest example of exploiting vulnerable people. For the protection side there is a reference too. The European standard on markers of harm, EN 18144, published in May 2026, lists nine signals to watch. A list like that is easier to defend to a regulator than one the team made up. Once those signals exist, the rest of the compliance work is about what the system may do with a player and how you prove later what it did.
The strictest licences go further. They expect harm signals to be flagged quickly and fed into automated processes. They expect marketing and new bonus offers to stop for players with strong signs of harm. For a first AI project, this turns the one-way flow into a licence condition. A support bot that spots distress must pass it to the safer-gambling team. Any comeback-bonus model must check the block flag before it picks a single player.
Automated decisions affecting a player (refusing a payout, restricting an account, denying a bonus) generally need a documented human review path and an explanation the player can understand. Plan for the player who contests one: someone has to review it, and the logs have to show what the model saw.
Everything must be reconstructible: model version, retrieved documents, prompt, output, timestamp, and who saw it. Auditors ask what the system told a named player on a given date, and "we have since updated the model" is not an answer.
A bot that improvises is speaking for the company. If it paraphrases a bonus term wrongly, the player will hold the operator to the paraphrase, and a complaint about a misquoted wagering condition costs more to defend than the bonus was worth.
Generated marketing copy takes the same approval route as human copy, and bonus terms must be verified against the source system before a model repeats them. Any conversational surface needs hard-coded behaviour for self-exclusion mentions, distress signals and complaint language: stop, hand over, log.
How to tell a real result from a dashboard illusion
Deflection measured as "chats with no agent involved" counts everyone who gave up and left. Pair it with re-contact within 72 hours and complaint volume: if re-contact rises alongside deflection, you moved cost and left the work where it was.
The 72-hour window matters because a player who gave up and a player who got an answer look the same when the chat closes. Only the next few days tell them apart. If deflection rises while re-contacts and complaints stay flat, you really removed work. If all three rise together, you taught players to give up. That is cheaper this month and expensive next quarter, when they charge back, complain to a regulator or stop depositing. One deflection number cannot show the difference, so never report it alone.
The same illusion waits in the project most teams want to do next. A retention model targeting the highest churn probability often spends bonus money on players who were staying anyway. What you want is uplift, the difference the intervention makes, which needs a randomised control inside the targeted segment.
Write the failure condition before launch: if deflection is under 8% or re-contact rises more than two points by week 10, the project stops or is rescoped. Pilots without a stopping rule survive on narrative.
What to leave until the second or third project
Some use cases have no business in a first project at all. Real-time pricing needs latency guarantees, market-data quality and a risk framework most first-time teams lack. Autonomous campaign spend removes the approval step exactly where advertising rules bite. Individually generated bonus offers create terms legal never reviewed. Systems that can freeze, refund or close accounts should wait until logging and rollback are mature.
Harm-detection models are the partial exception: build them early if you can, but as decision support routing a case to a trained human, never as a gate acting alone.
If a trade show is where you shortlist vendors
At a trade show you see many vendors in a few days, and every demo shows the part this guide says matters least: a model answering a question smoothly. The questions that separate vendors are dull, and each one links back to a step above.
- Where does the model run, and can you keep it in one region? Without a clear answer, your data map stays incomplete, and a hosted model may be unusable in some markets.
- Can we take the knowledge base and the test set with us if we leave? These two things are what the ninety days actually produce. If the vendor keeps them, you pay for the same learning twice.
- What do your logs record? When an auditor asks what the system told a named player on a given date, the answer comes from those logs or not at all.
A vendor who answers each of these with a slide about accuracy has already told you what you needed to know.
Questions operators ask before their first deployment
Do we need a data scientist to start? Not for a retrieval-based support project: an engineer comfortable with APIs and evaluation, plus a support lead with authority over the answer base. Churn and fraud scoring do need modelling skills.
Build or buy? Buy the first one. The purpose is learning whether the use case pays, and a vendor gets you there in weeks.
How much data is enough? For support, a few thousand resolved tickets and current documentation. For churn, six to twelve months of behaviour and a written label. If the answer is "we will collect it as we go", fix the pipeline first.
Will regulators object to AI in player-facing channels? Objections concentrate on unexplained automated decisions, weak audit trails, and marketing that reaches players showing harm markers. Grounded answers, logged outputs and a handover path address most of it. Confirm the position for each licence.
What sinks these projects most often? No baseline. Without hand-measured before-numbers every later result is arguable, and arguable results are not funded twice.