Wat is een AI-solution-architect?

Een AI-solution-architect ontwerpt de technische blauwdruk van een AI-systeem voordat de bouw begint: welk model het werk doet en hoe vervangbaar dat is, waar de data vandaan komt en hoe die actueel blijft, hoe het systeem zich authenticeert in het landschap dat u al draait, wat het wegschrijft naar het audittrail, waar een mens kan ingrijpen, en wat het per transactie kost bij volle belasting. In een organisatie van een paar honderd tot een paar duizend medewerkers gaat die rol zelden over een nieuwe stack bedenken. Hij gaat over de vraag hoe één nieuw, niet-deterministisch onderdeel mag landen in een landschap dat al werkt en al aan regels moet voldoen.

De titel overlapt met vier rollen die de meeste IT-organisaties al hebben: de enterprise-architect, de solution architect, de MLOps- of platform-engineer, en degene die uw ICT-partner als lead architect levert. Het verschil zit niet in senioriteit. Het zit in wie van hen waarvan eigenaar is, en welke van die beslissingen duur worden om terug te draaien zodra het eerste systeem live staat.

Wat levert een AI-solution-architect eigenlijk op?

Het resultaat is een document dat u aan een bouwer én aan een auditor kunt geven, geen plaatje. Zes onderdelen komen bijna altijd terug.

• Een systeemcontext. Uit welke bestaande systemen de AI leest en waarnaar hij schrijft, met naam en toenaam in plaats van generiek: het ERP, het CRM, het WMS of TMS, het documentarchief, de identityprovider. Elke stroom heeft een richting en een eigenaar.
• Een dataontwerp. Waar de data voor retrieval of training vandaan komt, wie er eigenaar van is, hoe vaak die ververst, en wat er met een record gebeurt als het in het bronsysteem wordt gecorrigeerd of verwijderd. De meeste retrieval-problemen in productie zitten hier, niet in het model.
• Een koppelingsontwerp. De interfaces, het gedrag van elke interface bij storing, en wat de organisatie doet zolang een koppeling plat ligt. Een AI-functie die tijdens een storing stilletjes verouderde antwoorden geeft, is erger dan één die weigert.
• Een beheersingsontwerp. Identiteit en autorisatie voor de handelingen die de AI op eigen titel verricht, de gebeurtenissen die hij logt, de punten waar een mens goedkeurt, en de drempels waarboven een zaak naar een mens gaat.
• Een evaluatieontwerp. Wat werkend in cijfers betekent, gemeten tegen een testset die iemand anders beheert dan degene die het heeft gebouwd.
• Een kosten- en capaciteitsmodel. Kosten per transactie bij de verwachte belasting en bij drie keer die belasting, en welk onderdeel u als eerste zou vervangen als een leverancier zijn prijzen wijzigt.

Een bruikbare toets: noemt het document uw systemen niet bij naam, dan is het een sjabloon.

Hoe verschilt een AI-solution-architect van uw enterprise-architect?

De rollen verschillen in eigenaarschap, niet in rang.

• Enterprise-architect. Is eigenaar van het doellandschap en van de standaarden waaraan een nieuw systeem moet voldoen. Beantwoordt of dit hier überhaupt thuishoort, en tegen welke principes.
• Solution architect. Is eigenaar van het ontwerp van één systeem binnen die standaarden. De meesten zijn uitstekend in deterministische systemen. AI brengt faalvormen mee waarvoor de klassieke solution-architectuur niet is gemaakt: een onderdeel dat meestal gelijk heeft, geruisloos achteruitgaat in plaats van stuk te gaan, en zich niet op dezelfde manier laat testen.
• AI-solution-architect. Is eigenaar van precies dat verschil. Niet-determinisme, actualiteit van data, evaluatie, vervangbaarheid van het model, en de beheersmaatregelen die een probabilistisch onderdeel controleerbaar maken.
• MLOps- of platform-engineer. Is eigenaar van de runtime zodra het ontwerp er is: pipelines, uitrol, monitoring, drift.
• De lead architect van uw ICT-partner. Is eigenaar van het landschap waarin het systeem landt: netwerk, identiteit, endpoints en de servicedesk die de meldingen krijgt.

In een organisatie van 250 tot 5.000 fte bestaan de eerste twee meestal wel en de derde meestal niet. De vraag is dus zelden of u een architect nodig hebt. De vraag is wie eigenaar is van het deel dat echt nieuw is.

Waar zit een AI-architect naast uw ICT-partner?

Ernaast, niet in plaats van. Crux Digits is een AI-leverancier en geen ICT-partner: wij verkopen geen systeembeheer, infrastructuur, hosting of servicedesk, en wij gaan ervan uit dat u die al hebt, intern of bij een leverancier met wie u al jaren werkt. Juist die aanname is het punt van deze paragraaf.

Het raakvlak tussen beide is de plek waar AI-projecten in het middensegment daadwerkelijk vastlopen, en het komt neer op drie beslissingen die niemand toewijst:

• Wie geeft de AI zijn credentials uit, en wie roteert ze. Een agent die op eigen titel handelt heeft een eigen identiteit nodig in Entra ID of uw equivalent, met eigen rechten en een eigen vervaldatum. Een gedeeld serviceaccount dat van een ontwikkelaar is geleend, is de meest gemaakte kortere weg en degene die in de volgende audit naar boven komt.
• Wiens monitoring ziet hem als eerste falen. Uw ICT-partner bewaakt beschikbaarheid. Een AI-systeem kan volledig beschikbaar zijn en toch fout. Iemand moet eigenaar zijn van het tweede signaal, en de blauwdruk moet vastleggen wie dat is en op welk alarm.
• Wie belt de gebruiker als het antwoord fout is maar het systeem draait. Is die route niet ontworpen, dan komt hij vanzelf bij de servicedesk terecht, die hem niet kan oplossen, en wordt de functie stilletjes niet meer gebruikt.

Leg die drie vóór de bouw schriftelijk vast, en de leveranciersverhouding loopt daarna meestal vanzelf.

Wat moet de architectuur goed doen wat een pilot nooit toetst?

Een pilot draait op een schone export, met een welwillende gebruiker, bij lage volumes, op data van vorige maand. Zes dingen komen pas daarna boven, en alle zes zijn architectuur en geen modelkeuze.

• Identiteit en rechten. In de pilot had het account van de bouwer toegang tot alles. In productie mag de AI precies zien wat de vragende gebruiker mag zien, en dat is een ontwerpbeslissing over hoe het verzoek zijn context meedraagt.
• Actualiteit van de data. De pilotindex is één keer gebouwd. Productie heeft een vastgelegde verversing nodig, en een vastgelegd antwoord voor records die in het bronsysteem zijn gecorrigeerd of verwijderd.
• Gelijktijdigheid en kosten bij belasting. Kosten per transactie die bij twintig per dag verwaarloosbaar zijn, zijn bij tweeduizend per dag een begrotingspost.
• Het volume aan uitzonderingen. De gevallen die de pilot oversloeg, bepalen of medewerkers het blijven gebruiken.
• Het audittrail. Welke invoer welke uitvoer opleverde, onder wiens bevoegdheid, en hoe lang bewaard.
• Vervangbaarheid van het model. Leveranciers stoppen modellen en wijzigen prijzen. Betekent wisselen een herbouw, dan is dat een ontwerpfout en geen pech.

Welke verplichtingen uit de AI-verordening landen op de architectuur en niet op het beleid?

De AI-verordening, Verordening (EU) 2024/1689, trad op 1 augustus 2024 in werking en geldt in fasen. De verboden van artikel 5 en de AI-geletterdheidsplicht van artikel 4 gelden sinds 2 februari 2025, de verplichtingen voor AI-modellen voor algemene doeleinden sinds 2 augustus 2025, en de transparantieplichten van artikel 50 sinds 2 augustus 2026. De Digital Omnibus on AI, Verordening (EU) 2026/1744, aangenomen op 8 juli 2026 en van kracht sinds 27 juli, verschoof de hoogrisicoverplichtingen uit hoofdstuk III, afdeling 2 naar 2 december 2027 voor zelfstandige systemen uit bijlage III en 2 augustus 2028 voor AI die is ingebouwd in gereguleerde producten uit bijlage I. De data zijn verschoven. De verplichtingen niet.

Vier van de artikelen 9 tot en met 15 zijn ontwerpbeslissingen en geen beleidsteksten, en daarom horen ze in de blauwdruk en niet in een compliancebijlage die later wordt geschreven. Artikel 10 stelt eisen aan databeheer voor trainings-, validatie- en testdata. Artikel 12 vraagt om automatische registratie van gebeurtenissen gedurende de levensduur van het systeem. Artikel 14 vraagt dat het systeem zo is gebouwd dat een mens toezicht kan houden en kan ingrijpen. Artikel 15 gaat over nauwkeurigheid, robuustheid en cyberbeveiliging, met nauwkeurigheidsniveaus die in de gebruiksaanwijzing staan.

U kunt geen audittrail toevoegen aan een systeem dat er nooit één heeft weggeschreven, en een menselijke controlestap inbouwen in een werkwijze die mensen al vertrouwen is een veranderproject en geen patch. De meeste AI in het middensegment is geen hoogrisico-AI uit bijlage III, en dat mag ook gewoon gezegd worden. Maar werving en kredietscoring staan wel op die lijst, en een organisatie van deze omvang draait er vaak één van. Dit is geen juridisch advies.

Wat verandert de Cyberbeveiligingswet voor een AI-systeem?

De Nederlandse uitwerking van NIS2, de Cyberbeveiligingswet, is op 15 augustus 2026 in werking getreden en stelt eisen aan de digitale weerbaarheid van ruim 8.000 organisaties die essentiële of belangrijke diensten leveren. Er hoort een registratieplicht in het entiteitenregister bij, een zorgplicht (een risicoanalyse en op grond daarvan passende en evenredige maatregelen om netwerk- en informatiesystemen te beveiligen) en een meldplicht: significante incidenten gaan zo snel mogelijk en in elk geval binnen 24 uur naar het CSIRT en de toezichthouder. Het bestuur keurt de maatregelen goed en houdt toezicht op de uitvoering.

Het gevolg voor de architectuur is beperkt en concreet. Een klok van 24 uur is alleen haalbaar als het systeem u vertelt dat er iets is gebeurd. Een AI-onderdeel dat een serviceaccount op uw ERP heeft, documenten van de fileshare leest en niets naar uw SIEM stuurt, is een blinde vlek in een landschap dat nu een wettelijke meldplicht draagt. Of een bepaald AI-systeem onder de wet valt, is een vraag voor uw CISO en uw jurist. Of het wegschrijft wat een incidentmelding nodig heeft, is een vraag voor de blauwdruk, en die is vóór de bouw veel minder duur te beantwoorden dan erna.

Neemt u een AI-solution-architect aan, huurt u er een in, of leent u er een?

Lees van boven naar beneden. Het eerste blok dat op u slaat, is meestal het juiste antwoord.

• Haal er een bij voor een afgebakende opdracht. Eén of twee systemen gepland, nog niets in productie. Wat u nodig hebt is een review van enkele weken, geen vacature. Crux Digits rekent advies, architectuurreviews en begeleiding van een intern team af tegen €150 per uur excl. btw; de AI Audit & Strategy van €2.500 is dezelfde werkzaamheid als vast pakket.
• Huur een interim in. Een programma met meerdere systemen over twaalf tot achttien maanden en geen interne kandidaat. Duurder per dag, geen aannamerisico, en kennisoverdracht kunt u in de opdracht vastleggen in plaats van erop hopen.
• Neem er een aan. Drie of meer AI-systemen live of gepland, en AI staat voor onbepaalde tijd op de roadmap. Als orde van grootte: de gemodelleerde cijfers van SalaryExpert komen voor een AI solutions architect in Nederland uit op ongeveer €119.500 per jaar gemiddeld en rond €132.400 op senior niveau. Gemodelleerde salarisdata is een orde van grootte, geen offerte.
• Doe voorlopig niets. Niets in productie, geen benoemd proces, geen interne eigenaar met uren in zijn week. Een architect zonder systeem om te ontwerpen schrijft een document dat niemand opent.

Waar past Crux Digits?

Wij ontwerpen en bouwen AI-systemen náást uw bestaande IT-organisatie en uw bestaande ICT-partner, vanuit Utrecht, met één benoemde expert die aan het werk verbonden blijft in plaats van een wisselend team.

Drie stappen, drie vaste prijzen, elk vooraf schriftelijk afgebakend: de AI Audit & Strategy voor €2.500 in één tot twee weken, een Production-ready MVP voor €20.000 in vier tot zes weken, en een Production Launch vanaf €50.000 vanaf acht tot twaalf weken, alles excl. btw. Advies, architectuurreviews en begeleiding van uw eigen team gaan per uur, tegen €150 excl. btw. Bouwwerk nooit.

Gaat u binnen 60 dagen door naar de MVP, dan wordt de €2.500 volledig verrekend. Alles wat wordt gemaakt is bij oplevering van u, de code inbegrepen. En is het eerlijke antwoord dat een instelling in software waarvoor u al betaalt het werk doet, dan zegt de audit dat en bespaart u de bouw.