Dennis van Remortel
Dennis van Remortel Portfolio Architect Public Cloud
21 augustus 2026

AI inrichten zonder spijt: zes architectuurkeuzes voor dag één

Een succesvolle AI-pilot is nog geen beheersbare dienst. Deze architectuurprincipes helpen organisaties om vanaf dag één snelheid te combineren met veiligheid, controle en schaalbaarheid.

De verleiding van snelheid

Vrijwel elke organisatie onderzoekt momenteel hoe AI ingezet kan worden. De druk komt van boven, van opzij en soms van buiten. En dus wordt er gehandeld: een pilot hier, een tool daar. Voor je het weet draait er ergens een Large Language Model in een omgeving die ooit voor iets heel anders is ontworpen.

Ik begrijp die snelheid, maar kijk vanuit mijn rol als Portfolio Architect Public Cloud verder dan het model of de eerste toepassing. Ik kijk vooral naar het fundament eromheen: identiteit, data, netwerk, logging, compliance, kosten en beheer. Juist daar wordt bepaald of een AI-oplossing kan doorgroeien van een interessant experiment naar een betrouwbare clouddienst.

Daarom stel ik bij iedere nieuwe AI-use case vanaf dag één een paar eenvoudige vragen. Wie is eigenaar van deze dienst? Kunnen we het gebruik, de risico’s en de kosten over twee jaar nog beheersen? En kunnen we een model of leverancier vervangen zonder de hele oplossing opnieuw te bouwen?

De antwoorden bepalen of een AI-omgeving blijvend waarde levert of langzaam verandert in een operationeel, financieel of compliance-risico.

AI zonder eigenaarschap wordt snel onbeheersbaar

Een AI-implementatie is geen project met een vaste eindoplevering, maar een levende dienst. Modellen worden bijgewerkt of uitgefaseerd, wijzigingen in prompts en databronnen beïnvloeden het gedrag en groeiend gebruik vergroot de afhankelijkheid.

Toch kom ik organisaties tegen die een generatieve AI-oplossing inrichten zonder duidelijk antwoord op vragen als: wie is verantwoordelijk als het model plotseling anders reageert? Wie bewaakt de kwaliteit van de output? Wie bepaalt welke data mag worden gebruikt? En wie besluit wanneer een model moet worden vervangen?

Dat zijn governancevragen die je architecturaal moet verankeren en niet pas moet oplossen wanneer er iets misgaat.

Leg daarom niet alleen vast wie ‘eigenaar van AI’ is, maar ook wie verantwoordelijk is voor de use case, de data, het platform en de risico’s en richt vóór de eerste productiegebruiker een beheerkader in voor monitoring, wijzigingen, incidenten en lifecycle.

Security voeg je niet achteraf toe​

De tweede valkuil is bekender, maar wordt nog steeds te vaak onderschat: security als nagedachte. Bij AI is dat extra riskant, omdat de aanvalsoppervlakte anders is dan bij traditionele software.

Niet alleen de infrastructuur vormt een risico. Ook de input van gebruikers, de data die aan het model wordt aangeboden, de koppelingen met andere systemen en de output van het model zijn potentiële risicovectoren. Denk aan prompt injection, ongewenste toegang tot databronnen, het blootleggen van vertrouwelijke informatie en onjuist gebruik van gegenereerde resultaten.

Security-by-design betekent bij AI daarom meer dan netwerksegmentatie en toegangsbeheer, hoe belangrijk die basismaatregelen ook zijn. Het ontwerp moet vooraf antwoord geven op concrete vragen over data, toegang, verwerking, modeltraining, logging en menselijke controle.

  • Welke data mag het model gebruiken?
  • Welke gebruikers en systemen krijgen toegang?
  • Waar wordt de data verwerkt?
  • Mag een leverancier de data voor modeltraining gebruiken?
  • Welke modelinteracties moeten worden vastgelegd?
  • Hoe wordt gevoelige informatie in logging afgeschermd?
  • Wanneer is menselijke controle verplicht?

Voor organisaties in de overheid, financiële dienstverlening en zorg zijn dit geen nice-to-haves. Het zijn architectuureisen die bepalend zijn voor de keuze van het model, het platform en de leverancier.

Voorkom dat iedere pilot een eigen eiland wordt

Een belangrijk risico is dat iedere AI-use case zijn eigen infrastructuur, beveiliging en beheerproces krijgt. Dat lijkt in het begin snel, maar leidt uiteindelijk tot versnippering, dubbel werk en moeilijk beheersbare afhankelijkheden.

Een herbruikbaar cloudfundament voorkomt dat teams bij iedere pilot opnieuw identity- en accessmanagement, netwerktoegang, secrets, logging, beleidsregels en kostenbeheer moeten ontwerpen. Teams kunnen dan sneller experimenteren binnen vooraf vastgestelde kaders.

Daarmee is governance geen rem op innovatie. Goede guardrails maken juist gecontroleerde snelheid mogelijk.

De keuze voor een AI-oplossing is bovendien breder dan alleen public of private cloud. Afhankelijk van de use case kan een organisatie kiezen voor AI-SaaS, een managed modeldienst in de Public Cloud, een zelf beheerd model of een hybride oplossing. De juiste keuze volgt uit de dataclassificatie, regelgeving, gewenste controle, kosten en het operationele vermogen van de organisatie en niet uit een principiële voorkeur voor één technologiemodel.

De zes principes die ik altijd meeneem

Op basis van wat ik in de praktijk tegenkom, zijn dit de zes principes die voor mij het meeste verschil maken.

1. Begin bij de use case, het risico en de data

Bepaal vóór de technische inrichting welk doel de AI-oplossing dient, welke besluiten ermee worden ondersteund en welk risico de organisatie accepteert.

Classificeer vervolgens de gebruikte data en leg vast welke bronnen het model mag raadplegen. Borg die grenzen technisch met passende toegangsrechten, beleidsregels en logische scheiding. Volledige isolatie per use case is niet altijd nodig of wenselijk, maar gecontroleerde scheiding is dat wel.

De classificatie van de use case en de data moet de architectuur bepalen, niet andersom.

2. Leg eigenaarschap en lifecycle vast

Leg expliciet vast wie eigenaar is van de use case, de data en het platform, en wie de kwaliteit van de resultaten bewaakt en risico’s accepteert.

Leg ook vast hoe modellen en prompts worden beoordeeld, gewijzigd, vervangen en uiteindelijk uitgefaseerd. Modellen veranderen, prijzen stijgen en diensten kunnen verdwijnen. Zonder lifecyclemanagement wordt die afhankelijkheid pas zichtbaar wanneer verandering onvermijdelijk is.

3. Bouw voor productie en beheer

Een pilot is nog geen architectuur. Ontwerp vanaf het begin met productie en beheer in gedachten.

Gebruik waar mogelijk een gestandaardiseerd cloudfundament met voorzieningen voor identiteit, netwerk, secrets, logging, beleidsregels en kostenbeheer. Stel jezelf daarbij de vraag of je de werking en gemaakte keuzes over achttien maanden nog kunt uitleggen aan een auditor, toezichthouder of nieuwe beheerder.

Beheerbaarheid gaat ook over verbruik. Richt daarom budgetten, quota, kostenallocatie en monitoring van token- en infrastructuurgebruik in. Een technisch succesvolle AI-dienst die financieel onvoorspelbaar is, is nog geen volwassen dienst.

4. Veranker security en privacy in het ontwerp

Gebruik security niet als checklist achteraf, maar als randvoorwaarde die ontwerpkeuzes stuurt. Dat geldt voor de keuze van het model en de leverancier, maar ook voor de locatie van dataverwerking, netwerktoegang en koppelingen met bedrijfsdata.

Maak modelinteracties controleerbaar met doelgerichte logging. Scherm gevoelige inhoud af, pas passende bewaartermijnen toe en beperk de toegang tot auditdata. Onbeperkt alle prompts en antwoorden opslaan kan namelijk zelf een nieuw beveiligings- en privacyrisico veroorzaken.

Zorg daarnaast dat gevoelige informatie alleen binnen vooraf goedgekeurde trust boundaries, regio’s en verwerkingsafspraken wordt gebruikt.

5. Houd de mens in de loop en monitor gedrag

AI-assistentie is niet hetzelfde als AI-autonomie. Bepaal per use case waar menselijke validatie verplicht is en leg dat vast in het systeem, niet alleen in een beleidsdocument.

Monitor bovendien niet alleen beschikbaarheid en technische performance. Kijk ook naar de kwaliteit van de output, afwijkend modelgedrag, ongewenst gebruik, beveiligingsincidenten en kosten. Alleen dan kun je tijdig ingrijpen wanneer het systeem of het gebruik verandert.

De intensiteit van menselijke controle moet passen bij de mogelijke impact. Een AI-assistent die interne teksten samenvat, vraagt om andere maatregelen dan een toepassing die medewerkers ondersteunt bij beslissingen over burgers, patiënten of klanten.

6. Ontwerp voor verandering en investeer in AI-geletterdheid

Voorkom dat prompts, data-integraties en bedrijfslogica onnodig vastgroeien aan één model of leverancier. Volledige onafhankelijkheid is lang niet altijd haalbaar of verstandig, maar kies afhankelijkheden dan bewust.

Leg daarom vooraf vast wat er gebeurt wanneer een model wordt uitgefaseerd, prijzen sterk stijgen, voorwaarden veranderen of een leverancier niet langer aan de eisen voldoet. Een exitstrategie hoeft niet te betekenen dat je morgen kunt migreren, maar wel dat je weet wat daarvoor nodig is.

Techniek en architectuur zijn daarbij niet voldoende. Mensen moeten begrijpen wat een AI-systeem wel en niet kan, welke risico’s bij hun rol horen en wanneer menselijke beoordeling noodzakelijk is.

Sinds 2 februari 2025 vereist artikel 4 van de Europese AI-verordening dat aanbieders en organisaties die AI inzetten, zorgen voor een passend niveau van AI-geletterdheid bij de mensen die namens hen met AI-systemen werken. Het benodigde niveau hangt onder meer af van hun rol, kennis en de context waarin het systeem wordt gebruikt.

AI-geletterdheid is daarmee geen losse training die je achteraf toevoegt, maar een randvoorwaarde voor verantwoord gebruik. Zonder deskundige gebruikers en beheerders blijft zelfs de best ontworpen omgeving kwetsbaar.

Snelheid en degelijkheid sluiten elkaar niet uit

Dit is geen pleidooi voor vertraging. Ik zeg niet dat organisaties moeten wachten tot alles perfect is, want dat moment komt niet.

Blind doorrazen is echter evenmin verstandig: organisaties die zonder fundament starten, bouwen problemen die later duurder en moeilijker op te lossen zijn, zoals versnipperde omgevingen, onduidelijk eigenaarschap, onvoorspelbare kosten en afhankelijkheid van één model of leverancier.

De organisaties die ik zie slagen, behandelen AI daarom niet als een verzameling losse pilots, maar als een nieuwe categorie clouddiensten binnen hun portfolio. Ze combineren ambitie met discipline en maken bewuste keuzes over eigenaarschap, data, modellen, leveranciers en lifecycle.

Daardoor blijft de omgeving schaalbaar, beheersbaar en aantoonbaar veilig, ook wanneer het gebruik groeit, een model verandert of een toezichthouder vragen stelt.

Dat fundament begint op dag één.

Meer weten?

Benieuwd hoe zo’n fundament er in jouw organisatie uitziet? Solvinity helpt organisaties bij het ontwerpen en beheren van veilige AI-omgevingen in de cloud, van use-case- en risicoanalyse tot een gestandaardiseerd cloudfundament, governance, observability en operationeel beheer.

Mijn collega’s en ik gaan daar graag over in gesprek. Neem contact op via ons contactformulier.

Benieuwd wat Solvinity voor jou kan betekenen?​

Neem vandaag nog contact op en ontdek de mogelijkheden.

Lees ook

Meer berichten

Meer