On-Premise AI Compute for Malta’s Regulated iGaming and Finance Operators

The cloud is the right home for a great deal of AI work. It is not automatically the right home for regulated data, and at steady utilisation it is not automatically the cheaper one either.

If you run an iGaming operation, a fintech or a bank in Malta, you are being asked the same question from two directions at once. The business wants to put AI to work, on fraud and anti-money-laundering scoring, player or customer risk, churn, support automation, and increasingly on running models in-house rather than sending data to a third party. At the same time your compliance and risk functions are asking where that data physically sits, who can reach it, and what happens to continuity if a supplier has a bad day. Those two pressures meet at a single infrastructure decision: do the AI workloads and the sensitive data behind them run in someone else’s cloud, or on hardware you control. This article is about when the honest answer is on-premise, what that infrastructure actually looks like, and where the cloud still wins. Sirap has supplied, installed and supported Supermicro servers across Maltese operators for years, in DataCore software-defined storage roles, as storage servers, and for on-prem AI inference and training, so this is written from building these systems, not from a brochure.

Why would a regulated operator keep AI on-premise at all?

Because for regulated data the question is not only “what performs best”, it is “what can we prove and control”. Three things push a Maltese iGaming or financial operator towards on-premise or in-country infrastructure, and none of them is a fashion.

The first is data residency and control. Player data, payment data and the models trained on them carry obligations under the EU’s Digital Operational Resilience Act (DORA) for financial entities, the NIS2 directive, and the expectations of the MGA and the MFSA. Keeping the data and the inference that runs against it on hardware you own, in a known location, makes residency and access something you can demonstrate rather than something you have to take a supplier’s word for. For MGA licensees there is also a specific, separate obligation: a real-time replicated copy of regulatory data on an inspectable server in Malta, which we cover in our guide to the iGaming replication server requirement. The second is operational resilience. DORA in particular is built around the risk that a critical third party fails or is breached; infrastructure you run yourself, with your own continuity design, is one way to reduce concentration risk rather than add to it. The third is cost behaviour. Cloud GPU capacity is priced for flexibility, and that flexibility is worth paying for when your demand is spiky. When you are running inference more or less continuously, the meter never stops, and at steady high utilisation an owned cluster usually crosses below the cloud bill within its service life.

The distinction most buyers get wrong: training is not the workload that lives with you

It is easy to assume “AI infrastructure” means a giant training cluster, decide that is too much, and stop there. For most regulated operators the workload that actually needs to sit close to your data is not training, it is inference: the model running in production, scoring a transaction for fraud, flagging an account, answering a support query, every second of every day. Training a model is occasional, bursty and often fine to do in the cloud or on a smaller in-house box; inference against live regulated data is constant and latency-sensitive, and that is the part there is a real argument for keeping on-premise. Getting this distinction right changes the hardware conversation completely, because a steady inference workload is served by a sensible GPU server or two and fast storage, not by a hyperscale rack. It is the difference between a proportionate on-prem deployment and an overbuilt one.

What does the on-premise stack actually look like?

It comes down to three tiers, and a regulated operator rarely needs all of them at full scale. We build them on Supermicro because the platform range spans all three cleanly, from a 65W edge box to an eight-GPU server, on the same management and support footing.

1. GPU servers, to run the models

This is the compute that runs inference and, where you do it in-house, training. Supermicro’s GPU systems run from a 4U Universal GPU server that takes a flexible mix of accelerators, up to the X14 5U NVIDIA GPU server for heavier work. The point is to size the accelerator count to the inference load you actually have, with headroom, rather than to a benchmark. A pair of well-specified GPU servers covers a lot of real-world fraud, AML and risk inference.

2. Storage that keeps the GPUs fed, often software-defined

A GPU that is waiting on storage is the most expensive idle component in the building, so the storage tier matters as much as the compute. Here is the distinction worth drawing: a traditional SAN is not the only way to get resilient, high-performance shared storage. DataCore software-defined storage pools standard Supermicro servers and their NVMe into a redundant, high-availability block store, with synchronous mirroring between two nodes so a whole server can fail without taking storage down. For an operator that wants resilience and performance without being locked to a single proprietary array, running DataCore on Supermicro is a genuinely different shape of answer, and it is one of the configurations we run most. Where the requirement is pure capacity rather than block performance, the X13 4U storage server provides dense, economical bulk storage.

3. Edge systems, for branch and satellite sites

Not every workload sits in the main rack. Retail-facing arms, branch offices, regional sites and on-location operations often need a small, quiet, secure box that does local inference or acts as a secure gateway, without a data-centre around it. Supermicro’s April 2026 family of compact AMD EPYC 4005 systems is built precisely for this: the mini AS-E300-14GR in a 2.5-litre enclosure, the short-depth 1U AS-1116R-FN4 for branch back-end consolidation, and the slim-tower AS-3015TR-i4 that takes a single GPU for sites that need local acceleration. They draw as little as 65W, and they carry the security features that matter for distributed regulated kit: a TPM 2.0 hardware root of trust and AMD’s Secure Encrypted Virtualization, plus out-of-band management so you can run them in places with no IT staff.