Waarom AI projecten stilvallen zodra de infrastructuur niet meegroeit

De aandacht bij AI implementaties gaat bijna altijd naar het model, de use case of de tooling. Welk taalmodel past het best, hoe trainen we het op onze eigen data, en welke processen automatiseren we als eerste. Dat zijn logische vragen.

Maar ze gaan voorbij aan een factor die in de praktijk vaker bepalend is voor succes of mislukking: de infrastructuur waarop het hele systeem draait. Zodra een AI pilot overgaat naar productie, veranderen de eisen aan rekenkracht, dataverwerking en beschikbaarheid fundamenteel. En daar ontstaat het probleem.

Een taalmodel dat intern documenten analyseert of een chatbot die klantverzoeken afhandelt, vraagt in de testfase relatief weinig van de onderliggende systemen. Het aantal gebruikers is beperkt, de dataset is overzichtelijk en de responstijd is geen harde eis. Bij opschaling verandert dat beeld volledig.

Realtime verwerking van honderden gelijktijdige verzoeken, koppelingen met CRM of ERP systemen, en continue beschikbaarheid worden dan randvoorwaarden in plaats van wensen. Organisaties die hun AI stack op een generieke cloudoplossing draaien zonder specifieke afstemming op AI workloads, merken op dat moment dat latency oploopt, kosten onvoorspelbaar stijgen en het beheer complexer wordt dan de interne IT afdeling aankan.

Het verschil tussen reguliere cloudtoepassingen en AI workloads zit in de aard van de berekeningen. Waar een webapplicatie voornamelijk leunt op CPU capaciteit en standaard opslag, vereisen Large Language Models GPU acceleratie, hoge geheugenbandbreedte en snelle dataverbindingen tussen de verschillende componenten. Proserve biedt als managed service provider vanuit Nederlandse datacenters een infrastructuur die specifiek is ingericht voor dit type belasting, inclusief schaalbare rekenkracht en volledige ondersteuning voor zowel open source als commerciele modellen.

Die specialisatie maakt verschil, omdat een generiek cloudplatform niet automatisch geoptimaliseerd is voor de parallelle verwerkingspatronen die kenmerkend zijn voor AI. Training van modellen op eigen data vraagt andere resources dan het draaien van inferentie in productie. Organisaties die beide fasen op dezelfde infrastructuur willen uitvoeren, hebben baat bij een omgeving die per fase anders kan worden geconfigureerd zonder dat het hele platform opnieuw moet worden ingericht.

Een tweede factor die bij AI projecten vaak te laat op tafel komt, is de locatie en het beheer van data. De AVG en NIS2 richtlijn stellen concrete eisen aan waar persoonsgegevens en bedrijfskritieke data worden verwerkt en opgeslagen. Bij gebruik van Amerikaanse cloudplatformen via standaard API koppelingen is niet altijd transparant waar de data zich fysiek bevindt en welke partijen er toegang toe hebben. Voor organisaties in sectoren als zorg, financiele dienstverlening of overheid kan dat een juridisch en operationeel risico vormen. Europese datacenters met volledige controle over de datastroom bieden in dat opzicht meer zekerheid, zeker wanneer AI modellen worden gevoed met vertrouwelijke bedrijfsinformatie of klantdata.

De meeste organisaties die nu met AI werken, bevinden zich ergens tussen experiment en eerste productietoepassing. Die fase is kritiek, omdat de keuzes die nu worden gemaakt rond infrastructuur bepalen hoe snel en hoe ver de organisatie kan opschalen. Een modulaire opzet waarin model, data en infrastructuur los van elkaar kunnen worden aangepast, voorkomt dat een succesvolle pilot vastloopt op technische beperkingen. Het verschil tussen een AI project dat waarde levert en een project dat na twaalf maanden wordt teruggeschaald, zit zelden in het model zelf. Het zit in de vraag of de omgeving waarop het draait is ontworpen om mee te groeien met toenemende complexiteit, datavolumes en gebruikersaantallen. Wie die basis goed neerzet, hoeft later niet opnieuw te beginnen.