AI-RACI: waarom ik eerst uw IT-organisatie spreek

Een AI-RACI is de matrix die voor elk onderdeel van een AI-systeem vastlegt wie het werk doet, wie eindverantwoordelijk is, wie wordt geraadpleegd en wie wordt geïnformeerd. De AI-leverancier tekent de bruikbare versie niet in zijn eentje. Ik teken hem in een eerste overleg met uw IT-organisatie en uw ICT-partner, voordat er één regel code is geschreven. Vrijwel elke vertraging die ik in een AI-project bij een middelgrote organisatie heb gezien, kwam namelijk uit het landschap rond het model.

Dit stuk is geschreven voor de IT-manager, IT-directeur, informatiemanager of CIO van een organisatie met 250 tot 5.000 medewerkers, die al een ICT-partner of een eigen IT-afdeling heeft en op het punt staat een gespecialiseerde AI-leverancier binnen te halen. Ik leid zo'n gespecialiseerd bedrijf. Wij beheren uw infrastructuur, uw servicedesk en uw netwerk niet, en dat willen we ook niet. Juist daarom vraag ik het eerste overleg niet aan met uw directie, maar met de mensen die dat wel doen.

Waarom lopen AI-projecten vertraging op bij IT en niet bij het model?

In eerste gesprekken maken opdrachtgevers zich zorgen over het model: welk model, hoe nauwkeurig, of het dingen gaat verzinnen. Dat zijn terechte vragen, en ze zijn binnen een week of twee te toetsen aan uw eigen casussen. Projecten die uitlopen, lopen meestal ergens anders uit, en dat patroon is opvallend voorspelbaar.

• Een app-registratie of serviceaccount dat via een wachtrij moet worden aangevraagd, door een leverancier die niet op de lijst staat van wie zoiets mag aanvragen.
• Een egress-proxy die het endpoint van de modelaanbieder blokkeert, ontdekt op de dag dat de eerste integratietest draait.
• Een changewindow dat eens per twee weken opengaat, tegenover een bouwplanning die ervan uitging dat we konden uitrollen zodra iets klaar was.
• Logs die in de SIEM van de ICT-partner terecht moeten komen, in een formaat waarover niemand afspraken heeft gemaakt.
• Een cloudabonnement dat eigendom is van de ICT-partner, zodat voor elke nieuwe resource zijn mensen nodig zijn, terwijl er voor zijn uren nooit budget is vrijgemaakt.

Niets hiervan is moeilijk. Elk punt is het werk van iemand anders, in het proces van iemand anders, in het tempo van iemand anders. Een specialist die ze in week zes ontdekt, moet wachten. Een specialist die ze in week nul ontdekt, kan eromheen ontwerpen of de aanvraag op de eerste dag in de wachtrij zetten. Het verschil tussen een project dat op tijd landt en een project dat maanden uitloopt, zit vaak alleen in het moment waarop deze vragen zijn gesteld.

Er is ook een minder zichtbare reden. Een ICT-partner die een AI-systeem pas bij de overdracht voor het eerst ziet, wordt gevraagd iets te ondersteunen waarover hij niets te zeggen had. Zijn verstandigste reactie is dan: vertragen, om documentatie vragen en voorwaarden stellen. In zijn plaats zou ik precies hetzelfde doen.

Wat leerde de Nederlandse bouw van het vroeg betrekken van de aannemer?

De Nederlandse bouwsector heeft een woord voor de oplossing: het bouwteam. In een bouwteam werken de opdrachtgever, zijn adviseurs en een aannemer samen aan het ontwerp, zodat de partij die het straks echt bouwt haar kennis van uitvoering, planning en kosten inbrengt zolang de tekening nog kan veranderen. Bouwend Nederland beschrijft het in die termen. Het alternatief is de traditionele route, waarin de opdrachtgever een ontwerp en een bestek laat maken en aannemers een prijs afgeven voor wat hun wordt aangereikt.

Wat mij opviel bij het lezen over de modelovereenkomsten, is hoe ze zijn veranderd. Bijna dertig jaar lang werden bouwteams meestal vastgelegd in het VGBouw-model uit 1992, geschreven voor een tijd waarin de aannemer vooral aanschoof om te adviseren over uitvoerbaarheid en kosten. Op 14 mei 2020 lanceerde Duurzaam Gebouwd de Modelovereenkomst Bouwteam DG 2020, en in 2021 volgde Bouwend Nederland met een opvolger van het model uit 1992. Het DG 2020-model kreeg een apart artikel over houding en gedrag: hoe de partijen met elkaar horen om te gaan, vastgelegd in het contract. Drie decennia praktijk hadden de sector geleerd dat een rolbeschrijving op zich niet genoeg is.

De vergelijking reikt verder dan ik had verwacht, en ik moet eerlijk zeggen waar ze ophoudt. Een aannemer in een bouwteam hoopt doorgaans daarna de uitvoering te mogen doen. Uw ICT-partner dingt niet mee naar de bouw van het AI-systeem, en ik ding niet mee naar het beheer van uw netwerk. Dat maakt de AI-versie eerder makkelijker dan moeilijker, want niemand aan tafel concurreert om het werk van de ander. Een kanttekening voor Vlaamse lezers: het bouwteam en de modelovereenkomsten die ik hier noem, zijn Nederlandse praktijk. De Belgische bouw kent eigen tradities, en ik zou er niet van uitgaan dat deze namen in Antwerpen iets betekenen.

De les die ik eruit haal is eenvoudig. Betrek de partij die straks met het systeem moet werken bij het ontwerp, zolang dat ontwerp nog kan veranderen. Voor een AI-systeem in een organisatie van uw omvang is dat uw IT-organisatie, samen met uw ICT-partner.

Welke rijen mist een standaard RACI-matrix voor een AI-systeem?

De meeste IT-organisaties hebben al een RACI-sjabloon, en veel cloudteams hebben het hunne uit een raamwerk overgenomen. Het Cloud Adoption Framework van Microsoft publiceert voorbeelden van RACI-matrices voor cloudteams, met kolommen als Levering van oplossingen, Wijzigingsbeheer, Oplossingsbewerkingen, Bestuur en Platformbewerkingen. Het is een prima pagina. Er staat alleen geen rij in voor wat een model zegt.

Een detail dat mij amuseert: de Nederlandse versie van die pagina is machinaal vertaald, en de beschrijving noemt de partijen verantwoordelijke, verantwoordelijke, geraadpleegde en geïnformeerde. Responsible en Accountable zijn allebei hetzelfde woord geworden. Daarmee zit het hele faalpatroon van een RACI in één woord. Als R en A samenvallen in één persoon, of in niemand, ziet de matrix er compleet uit en beslist hij niets. Teams die met de VERI-matrix werken, ondervangen dat met het woord eindverantwoordelijk, en ik zou erop staan dat dat woord in uw versie terugkomt.

Dit zijn de rijen die ik voor een AI-systeem toevoeg. Elke rij krijgt precies één eindverantwoordelijke.

• Identiteit: de app-registratie of service principal waaronder het systeem draait, wie die aanvraagt, wie de rechten goedkeurt en wie ze periodiek herziet.
• Netwerk: welke endpoints het systeem mag bereiken, dat van de modelaanbieder inbegrepen, en wie de egress-regels aanpast.
• Datatoegang: welke bronnen het systeem mag lezen, onder welke classificatie, en wie dat per bron aftekent.
• Model- en promptwijzigingen: wie een modelversie of prompt in productie mag wijzigen, en via welke changeroute.
• De evaluatieset: wie eigenaar is van de vragen die bepalen wat een goed antwoord is, en wie ze vóór elke wijziging uitvoert.

• Logging en bewaartermijn: waar prompts, antwoorden en opgehaalde context worden opgeslagen, hoe lang, en wie ze mag inzien.
• Kosten: wie de melding krijgt als de tokenrekening verdubbelt, en wie het systeem mag uitzetten.
• Uitfasering: wie de identiteit, de sleutels en de index opruimt als het systeem buiten gebruik wordt gesteld.

Wie er om twee uur 's nachts wordt gebeld als het systeem een verkeerd antwoord geeft, is ook een rij, en een belangrijke, maar die verdient een eigen gesprek. Ik schreef erover in wie er wordt gebeld als een AI-systeem faalt. De rijen hierboven bepalen of het systeem überhaupt gebouwd kan worden.

Wat vraagt u de ICT-partner voordat een AI-project begint?

Voor dat eerste overleg mik ik op negentig minuten. Niet ik zit het overleg voor, maar de IT-manager: het gaat om het eigen landschap en de eigen leveranciers. Ik neem een schets van één pagina mee: wat het systeem leest, wat het schrijft, waar het draait en wat het aanroept. Daarna stel ik vragen in plaats van te presenteren.

• Onder welk identiteitsmodel wilt u dit systeem laten draaien, en hoe lang duurt een nieuwe app-registratie van aanvraag tot goedkeuring?
• Loopt uitgaand verkeer via een proxy, en wat is ervoor nodig om een nieuw endpoint toe te staan?
• Wanneer zijn uw changewindows, en welke van onze wijzigingen wilt u daarin terugzien?
• Waar moeten de logs naartoe, en in welk formaat?
• Wie is eigenaar van het abonnement of de tenant waarin dit komt te draaien, en wilt u het binnen of buiten uw bestaande landing zone?
• Welke dataclassificatie geldt voor elke bron die we willen lezen, en wie in uw organisatie bepaalt dat?
• Wat zou voor u een reden zijn om dit systeem later niet te willen ondersteunen?

Die laatste vraag is de vraag die ertoe doet. Ze klinkt confronterend. In de praktijk is het de vraag die in het overleg de meeste opluchting geeft, omdat de ICT-partner zo een legitieme plek krijgt om vroeg nee te zeggen in plaats van een reden om later te vertragen. De antwoorden zijn bijna altijd redelijk: geen gedeelde beheeraccounts, geen geheimen in de code, niets buiten de landing zone, geen systeem dat de partner niet zelf kan uitzetten. Dat zijn uitvoerbaarheidseisen, precies het soort kennis dat een aannemer in een bouwteam inbrengt. Ik neem ze op in het ontwerp, en dan zijn het geen bezwaren meer.

Waarom aarzelt de ICT-partner, en wat maakt het makkelijker?

Als u de lezer bent voor wie dit stuk bedoeld is, weet u dit waarschijnlijk al, maar het is goed om het hardop te zeggen. De angst van een ICT-partner is eigenaar worden van iets wat hij niet kan ondersteunen. Zijn contract, zijn mensen en zijn monitoring zijn ingericht op infrastructuur en applicaties die zich voorspelbaar gedragen. Een AI-systeem doet dat niet, en de partner weet het.

Uit ervaring weet ik dat drie dingen helpen.

• Zwart op wit wat niet van hem is. De ICT-partner is geen eigenaar van de kwaliteit van de antwoorden, van de evaluatieset of van promptwijzigingen. Die horen bij u, zoals ik betoogde in wat IT zelf moet houden bij een AI-leverancier. Dat hardop uitspreken neemt het grootste deel van de weerstand weg.
• Een veto waar dat terecht is. Voor identiteit, netwerk en de landing zone gelden zijn eisen als bindend, en dat zeg ik voordat hij erom hoeft te vragen.
• Zijn uren in het budget, en dat verdient een eigen paragraaf.

Wat niet helpt, is om de partner heen werken. Een specialist die in een apart abonnement bouwt om de wachtrij te ontlopen, wint een paar weken en levert een systeem op dat niemand bij IT in beheer wil nemen. Als dat gebeurt, eindigt het meestal in een herbouw binnen de eigen omgeving, of wordt het systeem stilletjes uitgezet, en beide kosten meer dan de wachtrij had gekost.

Wie betaalt de uren van de ICT-partner in een AI-project?

Dit is de vraag die niemand stelt, en ze levert meer wrijving op dan welke technische vraag ook. De tijd die de ICT-partner in de ontwerpfase besteedt, is echt werk: een schets beoordelen, een identiteit aanmaken, een route openzetten, een logbron toevoegen. Onder veel beheercontracten valt dat buiten de vaste vergoeding en wordt het per uur gefactureerd, of het concurreert met tickets uit de rest van uw organisatie.

Als niemand het begroot, gebeurt het werk toch, alleen trager en met enige wrevel. Mijn advies is weinig spannend. Vraag de ICT-partner in het eerste overleg om een schatting van zijn uren, zet die als eigen regel in de projectbegroting en behandel die uren als onderdeel van wat het AI-systeem kost, niet als overhead.

Ook hier is het bouwteam leerzaam. Bouwend Nederland merkt op dat de aannemer als beloning voor zijn werk in de ontwerpfase traditioneel het vooruitzicht kreeg dat hij als eerste en enige een prijsaanbieding voor de uitvoering mocht doen. Uw ICT-partner krijgt zo'n vooruitzicht niet bij een AI-traject. Betaal dus de uren, en u zult zien dat de wachtrij gaat lopen.

Wanneer is het overleg met drie partijen overdreven?

Niet elke AI-wijziging heeft het nodig. Als het werk volledig plaatsvindt binnen een platform dat uw ICT-partner al beheert, zoals bij een Copilot Studio-agent die uw eigen mensen in uw eigen tenant bouwen, dekt de bestaande RACI het meestal af. Als de AI-leverancier alles als dienst host en single sign-on het enige raakvlak is, volstaat een kort gesprek over identiteit en gegevensverwerking.

Het overleg is zijn negentig minuten waard wanneer drie voorwaarden samenkomen: een gespecialiseerde leverancier bouwt, het systeem leest uit of schrijft naar systemen die uw ICT-partner beheert, en het gaat binnen uw eigen omgeving draaien. Dat beschrijft het meeste werk dat wij doen voor organisaties van uw omvang, en daarom vraag ik er standaard om.

Wat ik in uw volgende kick-off zou veranderen

Staat u op het punt een AI-project met een gespecialiseerde leverancier te starten, haal dan één overleg naar voren. Zet de ICT-partner aan tafel voordat het ontwerp vastligt. Vraag wat voor hem een reden zou zijn om te weigeren. Teken de RACI met de AI-rijen hierboven en één eindverantwoordelijke per rij. Begroot zijn uren als aparte regel.

Niets hiervan is slim bedacht. Het is wat de Nederlandse bouw in haar contracten heeft vastgelegd, nadat ze het dertig jaar lang met vallen en opstaan had geleerd. Onze pagina over AI-implementatie in Nederland beschrijft hoe wij een bouwtraject rond dat overleg inrichten, en toegepaste AI voor middelgrote bedrijven laat zien waar het past in een groter programma. Zit u nog eerder in het proces, en twijfelt u of het project überhaupt moet starten, lees dan liever hoe ik weet dat een project gaat mislukken voordat het begint.

Veelgestelde vragen