Frans van 't Hof

Frans van 't Hof

Director Consulting Expert - Enterprise & Solution Architect

Remco Gommers

Remco Gommers

Principal Architect

In onze vorige blog, Door de mist van AI, hebben we aangegeven dat het gebruik van AI wat ons betreft start met een aanpak voor AI-adoptie zodat het gebruik van AI ook echt leidt tot een succesvolle en behapbare inzet ervan. Daaruit bleek dat er veel overeenkomsten zijn tussen een AI-adoptieaanpak en reguliere IT. De door ons voorgestelde aanpak gebaseerd op de stappen “Strategie & Planning”, “Transformatie” en “Operatie & Verbeteren” werkt ook voor niet-AI-gebaseerde IT-uitdagingen.

Echter, er zijn ook specifieke aspecten aan AI die de realisatie en inzet ervan fundamenteel anders maken dan de meer reguliere IT. In dit blog gaan we dieper in op wat de verschillen zijn bij de realisatie en het gebruik van een AI-gebaseerde oplossing in vergelijking met reguliere IT, en waarom je je hiervan als organisatie goed bewust moet zijn. Zoals de titel al zegt: “AI toch ook wél anders”

‘Reguliere’ IT

Wat een AI-gebaseerde oplossing anders maakt dan ‘reguliere’ IT is de manier waarop beide gerealiseerd en gebruikt worden. De eerste vraag die opkomt is: wat is ‘reguliere’ IT? De beste omschrijving in deze context is dat reguliere IT bestaat uit expliciet geprogrammeerde code die een computer vertelt wat deze moet uitvoeren. Daarmee is het deterministisch van aard; er is een causaal verband tussen dat wat is geprogrammeerd en het resultaat. De programmacode is een integraal en cruciaal onderdeel van de oplossing. Het is ook inherent transparant over hoe het intern werkt en tot een oplossing komt. Deze werking kan vanzelfsprekend complex zijn, maar indien noodzakelijk kan de interne verwerking inzichtelijk gemaakt worden, zodat duidelijk is hoe tot het resultaat is gekomen.

AI en Machine Learning

Voor dit blog leggen we de focus op de meest populaire variant van AI op dit moment, Machine Learning (ML). Een ML-oplossing komt niet tot stand door expliciet geprogrammeerde code, maar door algoritmes te trainen op datasets waardoor een model ontstaat dat nieuwe patronen (voorspellende inzichten) kan vinden in data en/of nieuwe data (tekst, afbeelding, video) kan genereren gebaseerd op de ontwaarde patronen vanuit de bestaande datasets. Voorbeelden hiervan zijn generatieve AI (Gen AI) zoals ChatGPT, Google Gemini, DALL-E of Midjourney.

Bruikbaarheid wordt achteraf bepaald door het model zodanig te trainen dat het resultaat de gewenste uitkomst oplevert. Door de manier waarop het model tot stand komt niet expliciet herleidbaar is, maar meer emergent is, maakt dat een ML-oplossing meer stochastisch van aard is. Het kent een zekere mate van onvoorspelbaarheid; er is sprake van kansberekening hoe een resultaat tot stand komt. Daarmee is het ook niet inherent transparant zoals bij reguliere IT; hoe het resultaat intern bepaald wordt, is veelal een black-box proces.

Design time vs build time vs run time

Het realiseren van een ML-oplossing vergt een ander traject dan bij reguliere IT. Bij reguliere IT wordt tijdens design time vooral bepaald hoe de oplossing wordt vormgegeven. Dit is voornamelijk een deterministisch ontwerpproces voor het bepalen van expliciete instructies in programmacode. Tijdens build time wordt voornamelijk door een programmeur de code geschreven die eerder tijdens de design time is ontworpen. 

Bij een ML-oplossing verschuift het ontwerpen van de oplossing van design time veel meer naar build time. De oplossing wordt vormgegeven door algoritmes te trainen op een relevante dataset zodanig dat het model de gewenste resultaten oplevert op het moment dat een gebruiker er mee werkt. Dit is een fundamenteel verschil met een reguliere IT-oplossing. De ML-oplossing ‘schrijft’ zijn eigen expliciete instructies doordat het patronen afleidt in de dataset. Er is geen programmeur die expliciet code schrijft. 

Voor beide oplossingen geldt dat de uiteindelijke inzet is gedurende run-time. Maar de interactie met gebruikers is verschillend. Bij reguliere IT levert de oplossing resultaten door de programmacode uit te voeren met de input van de gebruiker. Deze input is vaak programma-specifiek en vereist een gebruiker bekend met de werking van de oplossing. Bij een ML-oplossing, met name bij generatieve AI, is de input niet programma-specifiek maar kan de gebruiker in natuurlijke taal vragen stellen en/of opdrachten geven en geeft de oplossing het resultaat in natuurlijke taal of in de gevraagde vorm (video, audio, afbeelding). De gebruiker heeft geen directe kennis nodig van hoe de oplossing werkt.

Ontwikkelcyclus

De softwareontwikkelingsmethodiek die voor reguliere IT gehanteerd wordt, voert nog steeds de boventoon voor hoe organisatie ook met AI-ontwikkeling omgaan. Vanwege hetgeen hierboven beschreven is, is dit echter onverstandig. Bij een klassiek ontwikkelproces is het uitgangspunt dat specificaties en uiteindelijk programmatuur elkaar stapsgewijs opvolgen. Het begint met bijvoorbeeld business process management of business rule management waarbij aanwezige processen en regels expliciet worden uitgeschreven. Dit op basis van wat we hiervan als mens begrijpen. De programmatuur die we gebruiken is dus gebaseerd op ons begrip over hoe dingen in elkaar moeten zitten.

Bij AI worden uitkomsten en modellen gemaakt waarvan we niet meteen snappen wat het ontwerp erachter is of waarom zaken zo zijn als ze zijn. De nadruk in de ontwikkeling moet dan ook verschuiven naar het werkelijk kunnen begrijpen van wat je voorgeschoteld krijgt. Of het nu gaat om de uitkomsten van een ChatBot voor een klant of een stukje inhoud dat je zelf wilt gebruiken om het werk beter of sneller te doen. Ooit is daarom ook Explainable AI als disciplines bedacht. In de kern een prima raamwerk, maar het geeft geen antwoord op hoe zaken echt georganiseerd of ingericht worden. Dit vraagt een veel fundamentelere benadering. Een benadering waarbij AI-systemen zo worden gemaakt dat zaken herleidbaar en begrijpelijk zijn. Of het nu om de data, het model of de uitkomsten gaat. Dit vergt een andere wijze van beheersing en aanpak. 

Verschuiving van code naar data

De verschuiving van code-centrisch naar data-centrisch zien we ook terug bij de inrichting van de IT-organisatie. Bij de ontwikkeling van reguliere IT is de IT-organisatie voornamelijk ingericht op programmeurs en ontwikkelaars die kennis moeten hebben van het ontwerpen en schrijven van programmacode. De gebruikte tooling is hierop aangepast voor wat betreft de ontwikkelplatformen, programmeer-talen en code repositories.

Bij de ontwikkeling van een ML-oplossing moet de IT-organisatie veel meer ingericht worden op rollen die toegespitst zijn op de dataset en de interactie met de oplossing. De gebruikte tooling is daarom meer geënt op datasetcuratie en -kwaliteit, natuurlijke taalinteractie, en model training efficiency.

Mogelijke nieuwe rollen kunnen zijn:

  • dataset curator: degene die verantwoordelijk is voor de acquisitie van datasets, en zorgt voor de datasetkwaliteit en datasetrelevantie,
  • prompt engineers: werken met ML-oplossingen, met name generatieve AI, is veel meer conversatie-gedreven, dus is er expertise nodig op het gebied van natuurlijke taalinteractie, semantische commando’s te geven; dit vereist nieuwe inzichten in interactie ontwerp
  • energy-processing-efficiency engineer: het trainen van een model is heel erg processing intensief, dit vraagt om expertise van energie-efficiënte processing, massive parallel processing, processing optimalisatie.

De IT in AI-modellen is de dataset

De adoptie van AI-gebaseerde oplossingen binnen organisaties gaat de komende tijd grote veranderingen brengen in hoe oplossingen gerealiseerd en gebruikt gaan worden. Dit verlangt een aanpassing van de IT-organisatie in hoe deze oplossingen gerealiseerd worden. Van een deterministisch code-centrisch proces naar een data-gedreven meer dialoog-gebaseerd proces.

De fundamentele en centrale rol die data speelt binnen de realisatie en gebruik van AI-gebaseerde oplossingen maakt ook dat de kwaliteit en relevantie ervan bepalend zijn voor het succes van de oplossing. Dat maakt dat zaken als transparantie van de oplossing, bias in data en ethiek bij het gebruik van data relevant worden bij het de realisatie en gebruik van AI-gebaseerde oplossingen. Dat is het onderwerp van het volgende blog over AI. 
 

Over deze auteurs

Frans van 't Hof

Frans van 't Hof

Director Consulting Expert - Enterprise & Solution Architect

Frans van ’t Hof werkt sinds het begin van deze eeuw als architect in de ICT. Hij heeft daarnaast een brede achtergrond en ervaring met organisatorische en bedrijfsmatige advisering. Vanuit detachering en projecten is hij werkzaam geweest bij overheden en de financiële sector. De laatste ...

Remco Gommers

Remco Gommers

Principal Architect

Remco Gommers werkt al meer dan 25 jaar binnen het ICT-vakgebied, waarvan de laatste 15 jaar als architect. Hij heeft een brede achtergrond en kennis over veel facetten van automatisering, van diepgaande techniek tot organisatorische inrichting van IT-landschappen. Zijn ervaring heeft hij opgedaan in o. ...