On-premise AI vs cloud: welke AI-compute past bij je MKB?

Zodra een MKB-directeur AI serieus neemt, valt bijna altijd dezelfde vraag: "moeten we dit in de cloud doen, of een eigen server neerzetten?" Het klinkt als een principiele keuze, alsof je een kamp kiest. Dat is het niet. On-premise tegenover cloud is geen geloofskwestie maar een laag-keuze die je per werkproces maakt. Sommige werklasten horen lokaal, de meeste horen in de cloud of bij een managed partij, en de kunst zit in het trekken van die scheidslijn. Wie de vraag als of-of behandelt, kiest vrijwel altijd verkeerd.

Dit artikel is de keuze-verdieping onder het dossier AI capaciteit en compute voor Nederlandse bedrijven. De pillar legt de drie lagen van capaciteit uit; hier zoomen we in op de ene beslissing die de meeste MKB'ers verkeerd framen. En let op wat we hier bewust niet doen: er staat geen euro-prijzentabel in. Prijs is niet de eerste beslis-as, en de bedragen staan uitgewerkt in de kosten-spoke over GPU-prijzen. Wat hier wel staat, zijn de vier assen die de keuze echt sturen.

/ 01De keuze

De keuze is geen of-of

Het beeld dat AI-infrastructuur een binaire keuze is, komt van de partijen die de vergelijking publiceren. Hardware-leveranciers schrijven over een "cloud-exodus" en eigen infra als bevrijding; GPU-marktplaatsen en cloud-vendors schrijven precies andersom. Bijna elke bron verkoopt een kant. Wat ontbreekt, is het perspectief van een bedrijf dat allebei live draait en per werkproces beslist waar het thuishoort.

Want zo werkt het in de praktijk. Een klantenservice-mailtriage, een offerte-voorbereiding, een documentzoeker met bronverwijzing: die draaien prima op cloud- of API-compute. Een dossier met patientgegevens dat het netwerk niet uit mag, of een model dat je bewust op een vaste versie wilt vastzetten: dat kan een argument voor lokaal zijn. Dezelfde organisatie heeft dus vaak allebei. De vraag is niet "wij of zij", maar "welke laag waar".

/ 02Vier assen

Vier assen, niet een prijs

De meeste vergelijkingen beginnen bij het kostenplaatje. Dat is de verkeerde ingang, want prijs is een gevolg, geen oorzaak: hij volgt uit hoeveel uur je hardware echt draait. Begin daarom bij de vier assen die de keuze werkelijk bepalen. In volgorde van hoe vaak ze de doorslag geven:

1. Datasoevereiniteit. Waar mag en moet je data fysiek staan, en van welke jurisdictie wil je wegblijven?
2. Latency. Hoe snel moet het eerste antwoord komen, en moet het ook werken zonder internet?
3. Controle over versies. Wie bepaalt wanneer het model verandert: jij, of een vendor die het gedrag zomaar kan aanpassen?
4. Beheerlast. Wie houdt de machine draaiend, patcht, monitort en staat op als het om 23:00 stilvalt?

Prijs staat bewust niet in dit rijtje. Niet omdat kosten er niet toe doen, maar omdat het kostenverschil pas betekenis krijgt nadat je de vier assen hebt gewogen, en omdat de bedragen in de kosten-spoke thuishoren. Hieronder eerst de assen naast elkaar, per infra-model.

/ 03Soevereiniteit

As 1: datasoevereiniteit, waar mag je data staan

Dit is de as die het vaakst de doorslag geeft, en de enige waar regelgeving je keuze kan afdwingen. De kernvraag: welke data mag je netwerk niet uit, en welke jurisdictie wil je vermijden? De AVG stelt eisen aan waar en hoe je persoonsgegevens verwerkt, en de EU AI-Act legt daar vanaf 2026 gefaseerd verplichtingen bovenop.¹ Voor de meeste MKB'ers is de praktische vraag simpeler: staat mijn data in de EU, en kan een buitenlandse overheid er theoretisch bij?

Die laatste zorg, de Amerikaanse Cloud Act die US-providers kan verplichten data af te geven ook als die in Europa staat, verdient een eigen behandeling. We stippen hem hier alleen aan; de volledige uitleg staat in de spoke Microsoft Copilot of eigen AI: de Cloud Act-vraag. Voor de infra-keuze telt het als een gewicht op de soevereiniteit-as, niet als de hele beslissing.

Concreet: als modelgewichten of brondocumenten je perimeter niet mogen verlaten, is dat een sterk argument voor lokaal of voor een private tenant. Sectoren met harde eisen, denk aan zorg, juridisch, overheid en financieel, komen hier sneller uit op een lokale of afgeschermde laag. Maar let op de nuance: een cloud met EU-region en een scheidbare, private tenant dekt heel veel gevallen af. Dat is geen belofte van 100 procent, wel een AVG-bewuste opzet die voor het merendeel van het MKB volstaat.

/ 04Latency & controle

As 2 en 3: latency en controle over versies

Lokale inference schrapt de netwerk-round-trip naar een datacenter. Het verschil is meetbaar: een time-to-first-token van grofweg 50 tot 200 milliseconden lokaal tegen 200 tot 800 milliseconden via een cloud-API.² Klinkt groot, maar zet het in context. Voor een offerte die je binnen 30 seconden terugkrijgt of een documentvraag die een halve seconde later begint te typen, merkt niemand het. Latency wordt pas een echt argument bij real-time interactie, bij spraak, of als het systeem ook moet werken als de internetverbinding wegvalt.

De derde as, controle over versies, wordt vaak vergeten en is toch belangrijk. Bij een cloud-API bepaalt de vendor wanneer een model wijzigt. Een versie kan worden uitgefaseerd, of het gedrag verandert stilletjes na een update, en dan werkt je zorgvuldig afgestelde prompt opeens net anders. Op eigen hardware bepaal jij dat: je zet een modelversie vast en die blijft draaien tot jij besluit te wisselen. Voor werkprocessen waar reproduceerbaarheid telt, bijvoorbeeld een gestandaardiseerde offerte-uitvoer of een gecontroleerde documentanalyse, is dat een reeel voordeel van lokaal.

/ 05Beheerlast

As 4: de beheerlast die niemand meerekent

Dit is de verzwegen kostenpost en meteen de reden dat de meeste MKB-bedrijven beter af zijn zonder eigen AI-server. Een GPU-machine is niet iets wat je neerzet en vergeet. Er komen OS-patches, GPU-drivers die op het verkeerde moment breken, koeling, stroom, monitoring, back-ups en, als het om 23:00 stilvalt tijdens een batch, iemand die opstaat om het op te lossen. Een MKB zonder IT-afdeling onderschat die uren structureel.

Het gevaar zit in de rekensom vooraf. Wie de business-case maakt op alleen de hardware-afschrijving, vergelijkt appels met een halve peer. De echte vergelijking is: hardware plus stroom plus koeling plus beheer-uren tegen een maandbedrag bij een managed partij waar dat allemaal in zit. Reken de uren mee, ook de uren die je niet op de factuur ziet.

En er is een Nederlandse extra: stroom en netaansluiting. Een zware GPU-server trekt fors vermogen, en sinds 1 juli 2026 staat ook het MKB op de wachtlijst voor een zwaardere netaansluiting. Die realiteit werken we uit in de spoke over AI-capaciteit zonder eigen datacenter, en het is een concreet obstakel dat in de internationale vergelijkingen vrijwel altijd ontbreekt.

/ 06Kosten over tijd

Kosten over tijd: de break-even van bezetting

Nu pas komt geld in beeld, en dan niet als prijs per uur maar als vorm van de kostencurve over drie jaar. Geen bedragen hier; die staan in de kosten-spoke. Wel de mechaniek. Cloud rekent naar gebruik: betaal je alleen als het draait. Eigen hardware is een investering vooraf die je hoe dan ook afschrijft, of de kaart nu 20 of 90 procent van de tijd werkt.

Daaruit volgt de break-even. Onder circa 70 procent GPU-bezetting wint cloud of managed doorgaans op total cost of ownership: je betaalt niet voor idle-tijd. Pas bij 80 procent en meer voorspelbare, doorlopende bezetting kan eigen hardware over een horizon van drie jaar goedkoper uitpakken.³ De break-even zelf ligt tussen enkele maanden bij een klein model en enkele jaren bij een zware configuratie. De kernvraag is dus niet "wat kost een uur", maar "hoeveel uur draait dit werkelijk".

Voor het overgrote deel van het MKB blijft de bezetting bursty en wisselend: een mailbatch in de ochtend, wat offertes door de dag, een documentvraag tussendoor. Die profielen zitten ruim onder de 70 procent en horen dus in de cloud. Alleen continue, zware werklasten, denk aan doorlopende beeldgeneratie of grote transcriptie-stromen, komen in de buurt van de drempel waar eigen hardware begint te lonen.

/ 07Beslisboom

De beslisboom: cloud, on-premise of hybride

Vier assen zijn mooi, maar je wilt een uitkomst. Loop de volgende vier vragen langs, in deze volgorde, en je hebt in een paar minuten de laag te pakken:

1. Moet de data je netwerk uit mogen? Nee, bij een harde regelgevende of contractuele eis, dan gaat die specifieke werklast lokaal of naar een private tenant. Dit is de enige vraag die de keuze kan afdwingen.
2. Is de belasting continu en hoog, richting 80 procent of meer? Ja, en dan pas is on-premise financieel de moeite van het overwegen waard. Weeg dan wel de beheerlast eerlijk mee.
3. Is de belasting bursty, wisselend of relatief bescheiden? Dan is cloud of managed vrijwel altijd het antwoord: je betaalt naar gebruik en hebt geen beheer.
4. Is een deel gevoelig en een deel niet? Dan is het antwoord hybride: de gevoelige of vaste laag lokaal, de rest in de cloud. Dit is voor de meeste bedrijven de eindbestemming.

De vuistregel die eronder ligt: ongeveer vier op de vijf MKB-werklasten passen vandaag prima op managed of API-compute.³ Hybride is daarbij geen compromis maar de nuchtere default, waarbij je per laag beslist in plaats van je in een loopgraaf in te graven. Wie de vraag als of-of blijft stellen, betaalt te veel of neemt te veel beheer op zich.

/ 08Wat wij draaien

Waar wij de lijn trekken: lokaal en cloud

Wij hebben makkelijk praten, want we draaien allebei. Concreet: 57 agents over 5 servers, lokaal en cloud, volledig automatisch, voor onze eigen drie bedrijven, een webshop in zonne-energie, een installatiebedrijf voor zon en warmtepompen, en een engineering-bureau voor netcongestie en batterijen. Precies daarom hebben we geen belang bij het verkopen van een kant: we gebruiken zelf de laag die per werkproces past.

Waar trekken we de lijn? De gevoelige of reproduceerbaarheid-kritische laag draait lokaal: documenten die de perimeter niet uit hoeven, en modellen die we bewust op een vaste versie zetten. De piek-generatie en de zware, incidentele modellen draaien via managed cloud, zodat we alleen voor pieken betalen en niet permanent een dure kaart in de kast hebben staan. Die verdeling is niet ideologisch, ze volgt uit de vier assen, precies zoals we ze hierboven beschreven.

Wil je zien hoe wij die laag-per-laag-keuze naar een concrete opzet vertalen, kijk dan op de AI Capaciteit-pagina. Daar staat hoe we capaciteit leveren zonder je in een eigen datacenter of een dichtgetimmerd cloud-contract te duwen: de laag die past, per werkproces.

/ 09Volgende stap

Drie volgende stappen

Je kent nu de vier assen, de beslisboom en de reden dat hybride meestal wint. Drie concrete stappen, van breed naar specifiek:

1. Lees het volledige capaciteit-plaatje. De pillar AI capaciteit en compute voor Nederlandse bedrijven zet de drie lagen neer waarin deze keuze past.
2. Reken je bezetting door. De kosten-spoke over GPU-prijzen vertaalt de bezettingsvraag uit dit artikel naar concrete maandbedragen, zodat je de break-even voor jouw geval kunt zien.
3. Plan een intake. Bekijk hoe wij capaciteit leveren en bepaal samen per werkproces de laag. Reactie binnen 24 uur na het intake-formulier.