Een interne AI-hub opzetten die blijft bestaan
Het probleem van gefragmenteerde AI-initiatieven
In middelgrote en grote organisaties ontstaat bij de opkomst van generatieve AI en taalmodellen vrijwel altijd hetzelfde patroon. Verschillende afdelingen — van marketing en klantenservice tot IT en legal — starten onafhankelijk van elkaar eigen experimenten. Een team bouwt een prototype met een externe leverancier, een andere afdeling sluit een los abonnement af op een SaaS-oplossing, en een individuele ontwikkelaar zet in een weekend een lokale Retrieval-Augmented Generation (RAG) oplossing in elkaar.
Aanvankelijk lijkt deze dynamiek positief: er is initiatief en de organisatie leert snel. Na zes tot twaalf maanden worden echter de schaduwzijden van deze versnippering zichtbaar. Teams doen ongeweten exact hetzelfde werk, maken dezelfde kostbare fouten op het gebied van privacy en gegevensbeveiliging, en bouwen op oplossingen die niet schaalbaar zijn. Belangrijker nog: zodra een sleutelfiguur vertrekt of een projectbudget afloopt, verdwijnt alle opgebouwde kennis spoorloos.
Het opzetten van een interne AI-hub wordt vaak gezien als de oplossing om regie te herpakken. Echter, veel van deze hubs verdwijnen binnen twee jaar even snel als ze zijn opgericht. Ze lopen vast in bureaucratie, worden omzeild door de business, of worden bij de eerste budgetronde wegbezuinigd omdat hun toegevoegde waarde niet helder is. Een AI-hub die blijft bestaan vraagt om een doordachte organisatorische inrichting, een helder mandaat en een duidelijke strategie voor kennisoverdracht.
Drie verschijningsvormen van een AI-hub en hun valkuilen
In de praktijk laten interne AI-hubs zich verdelen in drie primaire organisatiemodellen. Elk model kent een eigen dynamiek, specifieke voordelen en duidelijke afbreukrisico's.
1. Het autonome centrale bouwteam
In dit model fungeert de hub als een afgeschermd softwareteam dat alle AI-toepassingen voor de gehele organisatie ontwikkelt. Afdelingen leveren hun verzoeken in als opdrachten, waarna het team de gewenste functionaliteit oplevert.
De valkuil: Dit model verandert het team binnen korte tijd in een organisatorische bottleneck. Omdat het team de diepe domeinkennis van de operationele afdelingen mist, sluiten de gebouwde toepassingen vaak niet aan op de dagelijkse werkpraktijk. Bovendien raakt de hub overbelast met het beheer en onderhoud van maatwerkapplicaties, waardoor er geen tijd meer overblijft voor innovatie of strategische ondersteuning.
2. De strategische stuurgroep
Dit betreft een overlegstructuur waarin vertegenwoordigers uit de business, IT, juridische zaken en HR periodiek samenkomen. De stuurgroep stelt beleid op, beoordeelt aanvragen en adviseert de directie over AI-investeringen.
De valkuil: Zonder eigen technische capaciteit of uitvoeringskracht verandert een stuurgroep snel in een bureaucratische praatclub. Het orgaan produceert beleidsdocumenten en richtlijnen, maar mist de middelen om teams in de praktijk te helpen. De business ervaart de stuurgroep voornamelijk als een vertragende factor en zoekt wegen om het proces te omzeilen.
3. Het enabler-kenniscentrum
In de derde vorm treedt de hub op als een facilitator. Een klein, multidisciplinair kernteam bouwt centrale infrastructuur, stelt goedgekeurde bouwstenen beschikbaar en begeleidt afdelingen om zélf AI-oplossingen te ontwikkelen en te beheren.
De valkuil en uitdaging: Dit model is organisatorisch het meest effectief op lange termijn, maar tegelijkertijd het lastigst te verkopen aan het bestuur. Een enabler-hub levert immers zelden direct zichtbare eindproducten op die glimmen in een demonstratie. Het team bouwt de onderliggende fundering en verhoogt de zelfredzaamheid van anderen. Als de directie stuurt op directe, zichtbare applicaties, staat dit model continu onder druk.
| Model | Primaire focus | Grootste voordeel | Kritische valkuil |
|---|---|---|---|
| Centraal bouwteam | Zelf applicaties bouwen voor afdelingen | Hoge technische kwaliteit van code | Wordt een bottleneck; gebrek aan domeinkennis |
| Strategische stuurgroep | Beleid vaststellen en aanvragen toetsen | Directe betrokkenheid van governance | Mist uitvoeringskracht; wordt als vertragend ervaren |
| Enabler-kenniscentrum | Afdelingen in staat stellen zelf te bouwen | Hoge schaalbaarheid en kennisborging | Lastig te verkopen; levert geen directe 'showcases' |
Wat een goed functionerende hub nalaat
Een succesvolle AI-hub bewijst zijn waarde niet door het aantal beheerde projecten, maar door het fundament dat achterblijft in de organisatie. Als de hub goed werkt, levert dit concrete organisatorische bezittingen op:
- Gedeelde bouwstenen en architectuurpatronen: In plaats van dat elke afdeling opnieuw uitzoekt hoe een vector-database wordt ingericht of hoe een Large Language Model (LLM) veilig aan een interne database wordt gekoppeld, stelt de hub gestandaardiseerde koppelvlakken (API's), prompt-templates en RAG-pijplijnen beschikbaar.
- Een gestroomlijnde beoordelingsroute: Een helder, vooraf gedefinieerd proces voor het toetsen van ideeën op het gebied van gegevensbescherming, auteursrecht, ethiek en IT-beveiliging. Dit voorkomt dat elke pilot maandenlang stilstaat bij de juridische afdeling.
- Een centraal register van initiatieven: Een actueel en transparant overzicht van alle lopende experimenten, beproefde modellen en actieve integraties binnen de gehele organisatie. Dit voorkomt dubbel werk en stimuleert samenwerking tussen afdelingen.
- Vastgelegde lessen uit mislukte pogingen: Een gestructureerde documentatie van projecten die stopgezet zijn en de redenen daarachter. Analyseren waarom een initiatief niet werkte (bijvoorbeeld door gebrekkige datakwaliteit of een verkeerde modelkeuze) voorkomt dat andere teams later exact dezelfde valkuil instappen. Voor meer inzicht hierin verwijzen we naar het artikel over lessen uit mislukte AI-projecten.
Kernprincipe: Een AI-hub is succesvol wanneer een nieuw projectteam in week één kan starten met reeds beproefde bouwstenen en goedgekeurde kaders, in plaats van drie maanden te moeten vergaderen over infrastructurele en juridische randvoorwaarden.
Starten bij vraagstukken, niet bij gereedschap
Een veelvoorkomende strategie bij de oprichting van een hub is de aanschaf van een centraal AI-platform of het selecteren van een specifieke verzameling softwaretools. Dit is een verkeerde volgorde. Het selecteren van gereedschap zonder concrete toepassingscontext leidt tot investeringen in functionaliteiten die in de praktijk niet nodig blijken te zijn.
Een duurzame hub begint bij twee of drie concrete, operationele vraagstukken uit de organisatie die een duidelijke businesswaarde vertegenwoordigen. Door intensief samen te werken met de betrokken afdelingen om deze specifieke vraagstukken op te lossen, ontdekt het kernteam vanzelf welke technische architectuur, governance-kaders en vaardigheden daadwerkelijk vereist zijn. Pas tijdens de uitvoering van deze eerste projecten worden de herbruikbare componenten voor de rest van de organisatie gedefinieerd en gebouwd.
Het gestructureerd selecteren en inschatten van de haalbaarheid van deze initiële vraagstukken is hierbij cruciaal. Lees voor een methodische aanpak het overzicht over het prioriteren van AI-use-cases.
Bemensing en het vereiste mandaat
Een AI-hub heeft een multidisciplinaire samenstelling nodig om de brug te slaan tussen techniek, strategie en bedrijfsvoering. De minimale bezetting van een effectieve hub omvat de volgende rollen:
- De AI-architect: Verantwoordelijk voor de technische kaders, de integratie met de bestaande IT-infrastructuur en de selectie van geschikte modelarchitecturen en platforms.
- De Data & Compliance Officer: Waarborgt dat oplossingen voldoen aan wet- en regelgeving (zoals de Algemene Verordening Gegevensbescherming en de Europese AI Act) en bewaakt het databeheer.
- De Business Facilitator / Product Owner: Haalt vraagstukken op uit de organisatie, vertaalt operationele problemen naar technische specificaties en bewaakt de toegevoegde waarde voor de business.
- De Adoptiespecialist: Richt zich op change management, training en het verhogen van de digitale vaardigheden bij de eindgebruikers op de werkvloer.
Wanneer je besluit deze rollen in te vullen, is de keuze voor interne doorstroom of externe aantrekking essentieel. Bekijk hiervoor het overzicht over een effectief AI-team samenstellen.
Naast de juiste vaardigheden valt of staat de hub met zijn formele positie in de organisatie. Een hub zonder mandaat van de directie verandert onherroepelijk in een vrijblijvend adviesorgaan. De hub moet de bevoegdheid hebben om initiatieven stop te zetten die niet voldoen aan de gestelde veiligheidsnormen of die haaks staan op de centrale architectuur. Zonder deze formele doorzettingsmacht wordt de hub genegeerd zodra een afdeling snel een eigen oplossing wil doordrukken.
De verhouding tot bestaande afdelingen
Een van de grootste risico's bij de inrichting van een hub is dat het orgaan zich positioneert als een geïsoleerd eiland naast de bestaande IT-, security- en privacy-afdelingen. Wanneer de hub besluiten neemt buiten deze gevestigde afdelingen om, ontstaat er instinctieve weerstand. De IT-afdeling weigert de opgebouwde toepassingen in beheer te nemen, Security blokkeert netwerktoegangen en Privacy keurt gegevensstromen achteraf af.
Een effectieve hub werkt niet naast de bestaande afdelingen, maar beweegt zich door de bestaande overlegstructuren heen. Dat betekent concretiseerbaar:
- Security- en privacy-experts worden niet achteraf gevraagd om een stempel te zetten, maar zijn vanaf het allereerste concept betrokken bij het ontwerpen van de beoordelingsroutes.
- IT-architecten bepalen mede de infrastructurele kaders, zodat de bouwstenen van de hub naadloos aansluiten op het centrale datalake en het identiteitsbeheer (IAM).
- De business blijft de inhoudelijke eigenaar van het vraagstuk en levert de nodige domeinexperts voor het testen en valideren van de uitkomsten.
De hub fungeert hierbij als het verbindende element dat de taal van de business vertaalt naar de randvoorwaarden van IT en governance, en vice versa.
Financiering en de valkuil van het projectbudget
De manier waarop een AI-hub wordt gefinancierd bepaalt in grote mate het gedrag van het team. Een veelgemaakte fout is het hanteren van een intern declaratiemodel, waarbij de hub per uur of per project wordt betaald door de afdeling die de aanvraag doet.
Dit financieringsmodel leidt vrijwel direct tot de afbraak van de hub als kenniscentrum. Een afdeling die betaalt voor een specifiek project, wil namelijk uitsluitend een oplossing voor het eigen, unieke probleem. De afdeling heeft er geen belang bij dat de hub extra tijd investeert in het herbruikbaar maken van de code, het documenteren van de architectuur of het bouwen van een generieke API waar ook andere teams van kunnen profiteren.
Om herbruikbaarheid en organisatiebrede waarde te borgen, dient de basisinfrastructuur en de personele kern bezetting van de hub te worden gefinancierd uit een centraal innovatie- of transformatiebudget. Projectbudgetten van afdelingen worden alleen ingezet voor de specifieke domein-aanpassingen en de implementatie op de werkvloer. Voor een gedetailleerde afweging tussen de inzet van een eigen hub en externe ondersteuning kun je de analyse lezen over een intern team of externe AI-consultancy.
Meten of de hub werkt zonder schijnwerkelijkheid
Om het bestaansrecht van de hub aan te tonen, is sturing op meetbare resultaten noodzakelijk. Hierbij moet gewaakt worden voor het sturen op oppervlakkige indicatoren (vanity metrics), zoals het aantal georganiseerde inspiratiesessies, het totale aantal verwerkte prompts of het aantal getrainde medewerkers. Deze cijfers zeggen niets over de feitelijke organisatorische impact.
Stuur in plaats daarvan op indicatoren die de efficiëntie, schaalbaarheid en kwaliteit van de AI-adoptie inzichtelijk maken:
Doorlooptijd van idee naar pilot
Meet de tijd die verstrijkt tussen het eerste conceptuele idee van een afdeling en de oplevering van een geteste pilot in een veilige omgeving. Een goed functionerende hub verkort deze periode drastisch omdat de infrastructuur en de beoordelingskaders al gereedstaan.
Hergebruik van componenten
Houd bij hoe vaak centraal ontwikkelde bouwstenen (zoals authenticatie-modules, RAG-pijplijnen en compliance-checklists) worden toegepast in nieuwe projecten. Een stijgend hergebruik toont aan dat de hub erin slaagt om wildgroei te voorkomen en efficiëntie te verhogen.
Aantal bewust gestopte initiatieven
Het vroegtijdig beëindigen van kansarme, onveilige of niet-rendabele projecten is een belangrijk succesverschijnsel. Een hub die durft te adviseren een initiatief te staken vóórdat er grote investeringen zijn gedaan, bespaart de organisatie aanzienlijke middelen.
Groei in de organisatiebrede AI-volwassenheid
Evalueer periodiek in welke mate afdelingen zelfstandiger worden in het identificeren en beheren van geschikte toepassingen. Met behulp van een gestructureerde AI-volwassenheidsscan kan deze voortgang objectief in kaart worden gebracht.
De levensduur: een hub die zichzelf overbodig maakt
Een fundamenteel verschil tussen een klassieke IT-afdeling en een effectieve AI-hub is het perspectief op de eigen levensduur. Een AI-hub dient zo te zijn ontworpen dat hij zichzelf op termijn grotendeels overbodig maakt.
In de beginfase van technologische verandering is een gecentraliseerde hub noodzakelijk om expertise op te bouwen, kaders te stellen en initiatieven aan te jagen. Naarmate de technologie volwassener wordt en de vaardigheden binnen de afdelingen toenoemen, moet de hub taken geleidelijk overdragen aan de reguliere organisatie:
- Het beheer en onderhoud van operationele applicaties verhuist naar de standaard IT-beheerorganisatie.
- Privacy- en security-toetsingen worden geïntegreerd in de reguliere risicobeoordelingsprocessen van de Compliance-afdeling.
- Het identificeren en specificeren van nieuwe toepassingen wordt een standaard taak van de business analisten binnen de lijnorganisatie.
Wanneer deze overdracht niet vanaf de oprichting als doel wordt gesteld, ontstaat het risico dat de hub een permanente bureaucratische laag wordt die innovatie juist afremt. Door bij de start af te spreken hoe en wanneer taken worden overgedragen aan de staande organisatie, blijft het kernteam wendbaar en gericht op de volgende golf van technologische vernieuwing.
