What it takes to make AI useful in iGaming
Adam Mateja, Co-Founder and CEO of Blurify, explores what it takes to make AI useful within an operator’s business and how those principles are shaping the development of Openora.ai.
Almost any problem in iGaming can now be turned into an AI use case. That doesn’t necessarily make it a good one. For operators, the opportunity lies in creating an environment where AI can reliably help turn business requirements into working, tested software.
The harder question comes after the initial demonstration: can AI work effectively within the reality of the business? A tool might perform an individual task impressively, but its value depends on understanding the systems around it and the rules that determine what happens next.
At Blurify, we have spent years building software for iGaming businesses, and the challenge we encounter is rarely a shortage of ideas. Operators generally know what they want to change. The difficulty is turning that ambition into something that works within the technology they already have.
This has shaped how we think about AI at Blurify and, more recently, how we have approached the development of Openora.ai, our Open-Source AI-native Casino Platform Framework. We started by considering what the underlying technology needs to provide for AI to become genuinely useful within it.
Context changes what AI can do
Take software development. Coding agents can already produce and modify software, with their usefulness increasing when they understand the product they are working with and the consequences of the changes they make.
Imagine an operator wants to introduce a new payment provider. An AI coding agent can help build the integration, but it also needs to understand how the existing platform handles payments and where the new provider needs to connect. Give the agent this structured context and it can work within the existing architecture, including identifying which parts of the system need to change.
We have built this principle into Openora from the outset. The framework combines adapters and plugins with machine-readable information about how the platform is structured and how its components interact. This gives AI agents defined boundaries to work within and a clearer understanding of the wider system when making changes.
AI can then assist with development while engineers focus their time on decisions requiring deeper knowledge of the product and business.
For us, this is what makes Openora AI-native: the framework gives AI structured knowledge of the environment it is being asked to work in from the outset.
Start with the business problem
Deciding where AI belongs in an operator’s business starts with the problem being solved. A product change taking too long to deliver or an internal process consuming too much engineering time presents a problem to solve, with AI potentially forming part of the solution.
Openora grew from a broader challenge we repeatedly encountered. An operator may know exactly which market it wants to enter or which provider it wants to replace. The question is whether its technology can move as quickly as the business needs it to. Development priorities could be influenced by a provider’s roadmap, while changes to tightly connected systems often reached much further than originally expected.
This experience shaped the wider framework. Its modular structure allows operators to introduce new capabilities alongside existing technology and modernise individual parts of the platform over time. AI-assisted development supports engineering teams working within this model.
The business requirement determines what gets built. AI helps the team get there more effectively.
As AI takes on more complex tasks, its authority needs to be clearly defined. It can support decisions around areas such as player eligibility or payouts, with regulated decisions remaining subject to human approval.
Openora reflects this by giving AI defined boundaries within the framework. It can gather the relevant information and support the person making the decision, while responsibility for the outcome remains with the operator.
Building around operator needs
Openora is still developing, giving us an opportunity to make operator requirements part of how the framework evolves.
Conversations with operators can show us where existing technology is holding them back and which capabilities deserve priority. Requirements will naturally vary. An operator adding a capability to its current platform faces a different challenge from one gradually replacing legacy technology, and Openora’s modular structure is designed to accommodate both approaches.
Those conversations will also help determine where AI is most useful. Combined with a framework that can be changed in smaller parts, AI-assisted development can help engineering teams respond more quickly as operator needs evolve. For operators, the bigger gain is greater freedom to decide what gets built and when.
As AI become a normal part of how iGaming technology is built and operated, access to the technology itself will offer less differentiation. How effectively it can be applied within a particular business will matter far more.
Openora is our attempt to build these principles into the foundations of an iGaming platform framework. AI-assisted development has been considered from the beginning, while the framework continues to be shaped by the problems operators bring to us and the software they need to deliver.