Exclusive Interview with Hass Peymani: Head of iGaming at CreateFuture
At iGaming News, we caught up with Hass Peymani, Head of iGaming at CreateFuture, to discuss how the industry is approaching the shift towards “AI-native” thinking and what it really means in practice for operators navigating legacy systems, regulatory pressure and rapid technological change. From live client hackathons to AI orchestration platforms, testing to AI Native SDLC, and AI prototypes built in a single day, Hass shares his perspective on where the technology is genuinely adding value, where the risks sit and what needs to happen for AI to move from experimentation to real-world deployment across iGaming.
To start, tell us a bit about yourself and your role at CreateFuture. How did you first get into iGaming, and what has your journey looked like from there to where you are now?
I got into poker in the late 90s — badly. Genuinely terrible at it, but completely hooked on the world around it. A few of my friends happened to be some of the best online players around, and when they started travelling to live events, I tagged along. One thing led to another in the way these things do, and I ended up building a digital production company that makes multilingual video, webcast, and radio content for operators and major brands across the industry. It was a strange road to end up on, but it dropped me right in the middle of the poker boom at exactly the right time — and gave me a front row seat working with players, operators and everyone in between across betting and gaming in the US, UK and Asia.
My role within CreateFuture covers the commercial health of the division, our GTM Strategy, and partnerships across the industry with operators, vendors and hyperscalers.
Everyone in iGaming is talking about being “AI-native”. What does that actually mean to you in practice, and why should an operator genuinely care?
Honestly, most people use "AI-native" to mean "we've shipped something with AI in it". That isn't what we mean. AI-native is about AI being in how you work and what you build, from the first sprint, not bolted on at the end. Two things shift when you actually do it. Your engineering teams move faster, with smaller squads delivering more code, properly tested.
And the product itself starts doing things that matter commercially: personalising onboarding, surfacing safer gambling signals before they become compliance events, automating trading workflows. Operators should care because the gap between those who've embedded it and those who haven't is widening.
You recently took a real client problem into an AWS hackathon in London. Can you walk us through what your team built and why that specific problem was worth solving?
We took a live client problem to an AWS-hosted iGaming hackathon in London earlier this year. Five of our team, working on AWS Bedrock, built a fully working agentic pipeline in one day. The problem we picked was reducing editorial overhead. When something changes mid-event, a weather shift at a horse race, a player dropping out of a lineup, the editorial team has to research and rewrite commentary in real time. It's slow, expensive and it doesn't scale. We picked it because a current client of ours lives with that pain every day. The bit worth noticing is the way the team worked. Spec-first, AI in the room from the first minute, compressing weeks of effort into a single day. That's what AI-native delivery looks like when it's real.
Building a working agentic system in a single day is a bold claim. How close is that prototype to something a client could realistically run in production?
Much of the hard work in making these AI systems production-ready involves testing against real data, tweaking the prompts, evaluating the outputs, and verifying that the system produces the intended results. These systems are useless if they’re built correctly but don’t have the correct impact. And unlike traditional deterministic systems, it’s not simply about writing the rules properly. It’s about testing them against real-world inputs and evaluating the outputs.
The use case you explored involved AI-generated editorial content. In a UKGC-licensed environment, how do you see governance working in practice — who signs off output before it reaches customers, and who ultimately carries responsibility if something goes wrong?
The accountability question is the easy one. It would rest with the licence holder. Under the UKGC framework, a personal management licence holder at the operator is accountable regardless of who built the system or how clever the AI is. That doesn't change.
What does change is what good governance looks like in the workflow. In the pipeline we built, the agent doesn't publish anything. Output goes into a queue, a human reviewer at the operator signs it off, and only then does it reach a customer. The audit trail captures the input, the prompt, the model version, what the agent did, the output, who reviewed it, when, and what they decided. That's the SOP that turns an AI feature into something a compliance team will actually sign off on. None of that is optional in a UKGC-licensed environment.
Your team has built an internal methodology hub based on live client delivery. What’s in that hub that you wouldn’t typically find in a standard internal wiki?
The thing that makes it different is where the content comes from. A normal wiki is people writing what they think should be true. Ours is people writing what actually worked on a live project last week. Real examples. Real runbooks. Video demos of how a team solved a particular problem. It's structured around the software development lifecycle, not by team or tool, so when an engineer needs to know how we approach AI-assisted testing or spec generation, they go to that part of the SDLC and find what other teams have already done. The other thing that's different is that it's living. People contribute back. Someone solves a problem on a client engagement, drops it into the hub, the next team picks it up and builds on it. That's the bit a static wiki never quite manages.
Many established operators are still carrying years of platform debt. In your view, who is actually ready to layer agentic AI on top of legacy systems — and who is underestimating the challenge?
The readiness question is mostly cultural, not technical. The operators who can layer agentic AI on top of legacy systems are the ones who have engineering, product and compliance working as peers. Where the engineers care what the regulator will ask for, and the compliance team understands what a model card is. That combination is rarer than people think. Operators underestimating the challenge tend to treat AI as a tooling decision. They roll out Copilot, expect velocity to jump, and are surprised when nothing changes. Tools don't replace ways of working. The deeper issue is that agentic AI tests seams in your organisation that have been hidden for years. The handoffs between product and engineering. The escalation paths into compliance. The bits where decisions are made on email rather than in the system. Legacy debt is technical. The harder debt is organisational. Tailored AI enablement across the workforce is what sets the tone, the benchmark and the strategic ambition for the company.
Where would you advise clients not to use agentic AI? For example, should there be hard limits around areas like AML, responsible gambling, or others?
The approach should be anywhere the final decision carries personal regulatory liability or directly affects a player's ability to play or their money. The AML decision is the clearest example. An agent can detect patterns and prepare the case, but whether to file a Suspicious Activity Report sits with the MLRO. That doesn't move. Responsible gambling intervention is the same. An agent can surface risk signals; whether to limit, restrict or exclude a customer is a regulated human decision. KYC approvals, sanctions screening, vulnerability calls, account closures: same pattern across all of them. Agentic AI works well for detection, summarisation, content generation, workflow compression. Where it doesn't belong is the final decision step in any regulated process. What you need there is a human, a clear SOP, and an audit trail the UKGC will recognise. That's an SDLC discipline, designed from day one.
The architecture you used sits on AWS Bedrock. What would you say to operators who are cautious about becoming too dependent on a single cloud provider?
In the betting and gaming industry, a large part of the technical ecosystem is built on AWS infrastructure, and our partnership there runs deep. It gives us access to funding, technical resources, solutions and relationships that we pass through to clients. Multi-cloud strategy is ultimately a decision that sits with the operator and their technical leadership, and we work just as closely with clients running across other hyperscalers, multi-cloud, or on-prem environments, bringing the same rigour regardless of the stack.
The recent hackathon pipeline ran on Bedrock because we were at an AWS event solving a problem with AWS tooling, and Bedrock itself provides multi-model access within that environment. The broader architecture, ingestion, queueing, infrastructure-as-code, is portable across cloud providers, and we design with that flexibility and resilience in mind from the outset.
At the hackathon, your product manager was writing code while your engineer was shaping the spec. Do you think operators need to rethink how they structure product and engineering teams in an AI-native world?
Yes, but with a strong caveat. Good engineering still means good engineering, and that doesn't change. If anything, it matters more, because without engineering discipline AI just produces slop at higher speed. What changes is the rigidity of the roles. At the hackathon, the product manager could contribute to code because the AI lowered the friction; the engineer could shape the spec because product thinking was already on the table. That works when you have senior, disciplined people who understand both sides. It doesn't work when you have an organisation where the PM has never seen a code review and the engineer doesn't understand the customer outcome. The best AI-enabled teams understand the problem and the solution, and there's no substitute for that. The day was so productive precisely because everyone in the room had both. So the structural shift is real, but it's a shift toward T-shaped capability across the team, not a shift toward role abolition. Operators that try to use AI to dilute engineering rigour will produce worse software, faster.
New AI-first operators are entering the market without legacy constraints. How much of a competitive threat are they to established brands today?
A real threat in some places, an overrated one in others. The AI-first operators don't have 20 years of platform debt to drag around, and they can architect agentic systems from day one. That's a genuine advantage for shipping speed. Where I'd push back is on the assumption that AI removes the need for deep engineering experience. Running a tier-one iGaming platform at peak load, through regulatory inspections, against real fraud, is something you only know how to do if you've done it. There are still humans in the loop in every regulated decision, and you still need engineers who have actually built a platform, not just generated one. So the threat is real for incumbents who keep treating modernisation as optional. It's smaller than the headlines suggest for incumbents who are seriously embedding AI on top of platforms their teams understand cold.
Tell me about the team you’ve built at CreateFuture. What kinds of skills and mindsets tend to succeed in this kind of environment?
We've built the team carefully. Around 600 iGaming specialists, and roughly 80% of our teams have worked across operator accounts like FanDuel, Flutter, Fanatics, evoke and tombola, giving us real domain knowledge, because of this, we onboard our teams quickly and start helping at pace. That matters because they walk into a room understanding the constraints already. They engage product, engineering and compliance leadership as peers. The mindsets are what I'd lead with, though. Curiosity. The people who thrive here are the ones who genuinely want to learn what their client is actually wrestling with, not the ones who arrive with a fixed answer. Empathy. We work with a "badges at the door" approach because client teams have been burned before by partners who don't listen. And a willingness to share. Our methodology hub only works because people contribute back what they've learned. That culture is what makes the work durable. It's also what makes it enjoyable.
