Rob Collie, CEO en oprichter van P3 Adaptive en auteur van Fair Game – Interviewreeks

Rob Collie is de oprichter en CEO van P3 Adaptive, een Microsoft Solutions Partner voor Data en AI die honderden middelgrote en Fortune‑1000‑klanten bedient. Een voormalig technisch leider bij Microsoft in de Excel-, Bing- en Power BI-teams, leidde Rob de Power‑BI‑golf na zijn vertrek bij Microsoft en heeft drie eerdere business‑technology‑boeken geschreven (meer dan 92.000 exemplaren verkocht). Hij presenteert ook de podcast Raw Data with Rob Collie. Zijn vierde boek, Fair Game: Customizing AI to Your Business Is Easier Than You Think (augustus 2026), zet die praktijkervaring om in een AI‑moment.

U heeft meer dan een decennium bij Microsoft gewerkt aan het ontwikkelen van business‑intelligence‑functies in Excel en Power BI voordat u P3 Adaptive oprichtte in 2013. Hoe heeft die overgang van software bouwen binnen Microsoft naar het oplossen van dataproblemen voor klanten uw huidige visie op enterprise‑AI gevormd?

Toen ik productteams bij Microsoft leidde, bouwden we software die voor de hele wereld moest werken en die niet kon worden afgestemd op de behoeften van een specifieke klant. We noemden het wel eens “een pizza bestellen waarvan de toppings acceptabel zijn voor 300 miljoen mensen.” Er zit per definitie een “laagste‑gemeenschappelijke‑noemer”‑gevoel bij dat werk, evenals een zekere afstand tot individuele klanten.

Er was een duidelijk prestige verbonden aan het werken op dat grote podium, maar het was verre van zo emotioneel bevredigend als specifieke klanten helpen hun unieke ambities te realiseren. Door nauw met een klant samen te werken, krijgen we de kans om geïnvesteerd te raken in hun succes en creatieve oplossingen te verkennen die nooit zouden passen in het one‑size‑fits‑all‑model van Grote Software. Het is op veel manieren intellectueel stimulerender, en de directe verbinding met onze klanten maakt de overwinningen veel bevredigender.

Maar er is ook meer verantwoordelijkheid. Bij Microsoft was één ontevreden klant slechts een statistiek, en ik haalde klachten elke dag af als onderdeel van gewoon mijn werk doen. Bij P3 Adaptive betekent één ontevreden klant dat we hebben gefaald. Er zijn geen statistieken. We hebben een verantwoordelijkheid naar elke individuele relatie.

Ik heb veel waardevolle dingen geleerd bij Microsoft en zou die ervaring niet voor de wereld inruilen, maar ik noem mezelf vaak een “herstellende software‑engineer”, omdat succes nu betekent dat je heel anders opereert.

En dat is precies de bril waardoor ik enterprise‑AI bekijk. Kant‑en‑klare AI is de ultieme pizza voor 300 miljoen mensen – een waar wonder, ontworpen om individueel waardevol te zijn voor iedereen, maar op niemand afgestemd. Maar organisatorische AI‑successen komen voort uit maatwerk – door dicht bij één specifiek bedrijf te staan en de AI aan zijn data, zijn processen, zijn definities aan te passen. Ik heb mijn carrière aan beide kanten van die kloof doorgebracht, en dat heeft me geen enkele twijfel gegeven over de kant waarop enterprise‑AI zal winnen.

In Fair Game stelt u dat veel bedrijven kunstmatige intelligentie achterstevoren benaderen door algemene chatbot‑licenties te distribueren in plaats van systemen te bouwen die hun bedrijfsprocessen begrijpen. Waar lopen kant‑en‑klare AI‑assistenten tegen hun grenzen aan, en welke signalen geven aan dat een bedrijf iets op maat nodig heeft?

Kant‑en‑klare AI heeft een PhD in alles behalve uw bedrijf. Het heeft het hele internet gelezen, maar het internet mist uw bedrijfsdefinitie van “actieve klant”, uw prijslogica, uw operationele processen, en welke van uw twee systemen u moet vertrouwen wanneer ze het oneens zijn. Die kennis zal nooit publiekelijk beschikbaar zijn. Dus de generieke AI die een wereldtop is voor persoonlijk gebruik, schiet tekort voor zakelijk gebruik, en de kloof tussen de twee ervaringen is zowel ontmoedigend als verwarrend.

Tegenwoordig is het antwoord van vrijwel iedereen op “wat te doen met AI” “abonnementen kopen en uitproberen”. Ik denk dat dat een natuurlijke eerste stap is, dus ik ben niet kritisch op wie dat heeft gedaan. Integendeel, ik heb medeleven – niemand neemt echt de tijd om uit te leggen dat de kant‑en‑klare abonnementen niet genoeg zijn, noch waarom. Dus ik denk dat bedrijven precies daar staan waar we ze verwachten – ze proberen wat beschikbaar is en beginnen te leren dat het onvoldoende is.

De oplossing ligt niet in het aanpassen van het AI‑model zelf – u hoeft geen LLM‑onderzoeker te worden. Het gaat om alles wat u rondom het model plaatst: uw data, uw instructies geschreven in gewoon Engels, en normale software. Wanneer u zich deze week voor de vijfde keer dezelfde context in een chatbot moet typen, is dat het teken. Alles wat u steeds opnieuw moet uitleggen, is precies wat een aangepast systeem al zou moeten weten – elke keer dat het wordt opgestart.

U gebruikt de term “Crafters” om data‑savvy bedrijfsprofessionals te beschrijven die waardevolle aangepaste AI‑systemen kunnen bouwen zonder traditionele software‑ontwikkelaars te zijn. Welke kenmerken onderscheiden een Crafter, en hoe kunnen leiders deze mensen binnen hun bestaande personeelsbestand identificeren?

Een Crafter is iemand die van nature een drang heeft om problemen op te lossen met hulpmiddelen. Ongeveer één op de zestien kenniswerkers heeft dat, volgens mijn ervaring. Ze waren de Excel‑power‑users, daarna de Power‑BI‑generatie, daarna de mensen die IT “shadow IT” noemde. Het zijn uw analisten, uw financiële modelleurs, uw operationele leads – mensen die zijn opgegroeid in het bedrijf en een aanleg voor tooling hebben ontdekt.

Twee eigenschappen maken hen ideaal voor AI‑werk. Ten eerste systeemdenken: ze ontleden instinctief een rommelig proces in inputs, regels en outputs, net als professionele software‑ontwikkelaars. Ten tweede een verankering in de business: ze weten welke cijfers de CFO daadwerkelijk bekijkt en wat de persoon die een vraag stelt echt vraagt. Geen van beide kun je in een bootcamp aanleren.

Hoe u de uwe vindt: volg de spreadsheets. Op dit moment zijn er in uw bedrijf spreadsheets, dashboards en automatiseringen die het hart vormen van kritieke workflows. Geen van hen is door IT gebouwd, en elk heeft een auteur. Begin daar. En begin vervolgens te beoordelen hoe zij hun talenten kunnen inzetten voor aangepaste AI‑oplossingen.

Waarom gelooft u dat Crafters, in plaats van alleen ontwikkelaars, het beste gepositioneerd zijn om veel interne AI‑projecten te leiden, en hoe moeten de verantwoordelijkheden worden verdeeld tussen bedrijfs‑experts, datateams, software‑engineers, IT‑afdelingen en beveiligingsteams?

Omdat het moeilijke deel van aangepaste AI geen code is – het is context. De meest impactvolle activiteit in een AI‑project is bepalen wat het systeem moet weten over uw bedrijf, en Crafters dragen die kennis van nature. Een briljante engineer die van drie organigram‑hops verwijderd parachuteert, moet maandenlang interviews afnemen om te leren wat uw operationele lead al reflexmatig weet.

Maar dit is beslist geen verhaal waarin ontwikkelaars overbodig zijn. De arbeidsverdeling die ik aanbeveel heeft drie factoren, en geen van hen is senioriteit of persoonlijkheid: werk verschuift naar professionele ontwikkelaars naarmate herbruikbaarheid, complexiteit en gevoeligheid toenemen. Alles dat klantgericht is, alles dat gevoelige data raakt, alles dat autonome beslissingen neemt – dat is ontwikkelaars‑territorium, en naarmate de agents vermenigvuldigen, worden die schaars beschikbare engineering‑vaardigheden waardevoller, niet minder. Werk verschuift naar Crafters waar nuance in bedrijfsprocessen domineert.

Er is ook een ondergewaardeerd middengebied: de Crafter bouwt, de developer controleert. IT en security moeten geen poortwachters zijn die projecten goedkeuren om te bestaan – ze moeten de aangelegde weg bezitten. Lever de goedgekeurde platforms, de data‑toegangsregels, de review‑checkpoints, en laat de mensen die het dichtst bij de problemen staan het bouwen. Beschouw het geheel als een maturiteitsmodel, niet als een hek.

Aangepaste AI heeft toegang nodig tot bedrijfsspecifieke terminologie, metriek, processen en institutionele kennis. Welke rol spelen semantische modellen en bestaande business‑intelligence‑infrastructuur bij het geven van een nauwkeurig begrip van een bedrijf aan AI?

Ze zijn de decoder‑ring. Op dit moment leven de definities van uw bedrijf – wat telt als een actieve klant, welke kosten behoren tot de brutowinst – in de hoofden van mensen en in duizenden lichtelijk inconsistente spreadsheets. Een AI‑agent kan niet betrouwbaar over uw data redeneren totdat die definities zijn vastgelegd in een vorm die een machine kan vertrouwen. De industrie noemt dit vakgebied “context‑engineering”, en ik zou de term zo vertalen: het is het werk van het structureren van wat uw bedrijf weet zodat een AI het daadwerkelijk kan gebruiken. Analisten maakten het klinken als iets nieuws. BI‑professionals doen dit al vijftien jaar.

Dat is het goede nieuws dat zich in het zicht bevindt: als u hebt geïnvesteerd in het BI‑tijdperk (en vooral in Power BI), heeft u mogelijk al een voorsprong. Een goed gebouwd semantisch model is precies de machine‑leesbare weergave van bedrijfsbetekenis die agents nodig hebben. De bedrijven die hun semantische laag als een bijzaak beschouwden, ontdekken nu dat het “saai” definities‑werk dat ze hebben overgeslagen, nu de tolpoort is op de weg naar AI. En cruciaal: dit werk is diep specifiek voor uw bedrijf – wat precies de duurzame voorsprong maakt. Elke leverancier kan u hetzelfde model verkopen. Niemand kan u uw eigen definities verkopen.

U heeft een aangepaste AI‑editor gebouwd, bekend als Eddie, om Fair Game te ontwikkelen. Wat deed het systeem eigenlijk tijdens het schrijfproces, en wat leerden de successen en mislukkingen u over het ontwerpen van AI rond een zeer persoonlijk workflow?

Om duidelijk te zijn, ik schreef elk hoofdstuk van het boek vanaf nul, terwijl Eddie voornamelijk zat te wachten. Soms spendeerde ik uren aan het uitwerken van een volledige sectie van een hoofdstuk voordat ik “hem” vroeg het te lezen. Andere keren wisselde ik elke paar minuten iets met hem uit. Maar cruciaal: Eddie stond 24/7 paraat. Ik kon op drie uur ’s ochtends net zo gemakkelijk feedback krijgen als om één uur ’s middags, en hij leverde die binnen een minuut of minder. In totaal vermoed ik dat Eddie het manuscript minstens dertig keer heeft gelezen. Geen mens zou dit werk kunnen doen, omdat geen mens het zou willen.

Hij hield de beloften bij die ik in Hoofdstuk Drie had gemaakt en wees me op wanneer Hoofdstuk Twaalf ze vergat. Hij leerde mijn schrijfstijl en handhaafde die – hij hield me aan de beste versie van mijn eigen stem in plaats van me te laten afglijden naar de “Humorloze Business Author”-modus. Hij vertelde me wanneer ik lui was en wanneer ik een dood paard aan het slaan was. We hadden echte meningsverschillen, en soms won hij.

De grootste ontwerplessen: Eddie’s “brein” is geschreven in het Engels en zit in een map. Elke keer dat hij feedback gaf die miste – te algemeen, verkeerde toon, een regel die ik al had gesteld vergat – was de oplossing om de correctie op te schrijven en het onderdeel van zijn permanente context te maken. De mislukkingen waren geen AI‑mislukkingen; het waren hiaten in wat ik hem had leren. Die lus – merk de fout op, codeer de les, zie dat hij blijft – is het volledige ambacht van aangepaste AI in miniatuur. En het is de reden dat ik gespecialiseerde Eddie’s heb gebouwd voor publiciteit, concurrentie‑onderzoek en website‑communicatie. Dezelfde LLM eronder. Maar verschillende specialisten.

Veel organisaties denken dat ze hun data volledig moeten opschonen en centraliseren voordat ze aangepaste AI proberen. Hoeveel dataklaarheid is werkelijk vereist om te beginnen, en hoe kunnen bedrijven waarde beginnen te leveren zonder te wachten op een perfecte basis?

Dataperfectie is geen voorwaarde, en dat is goed nieuws omdat perfectie nooit zal arriveren. Als u eerst een perfect datalandschap wilt bouwen, zoals veel adviesbureaus zouden aanraden, bouwt u wat ik “leidingwerk voor de lol” noem – dure pijpen die overal heen lopen, maar wanneer u eindelijk een kraan installeert, ontdekt u dat er geen pijp is waar u die nodig heeft.

Ons bedrijf pleit in plaats daarvan voor een “kraan‑eerst” benadering. Kies een specifiek use‑case en werk terug van de zakelijke impact in plaats van vooruit van de infrastructuur. Bouw een MVP vanuit die use‑case, en doe dat met minimale nieuwe infrastructuur. Itereer op de MVP tot deze productieklaar is, en evalueer vervolgens hoe u uw infrastructuur kunt verstevigen om het te ondersteunen. Dat levert sneller zakelijke impact, minimaliseert kosten, en informeert toekomstige projecten – zowel op kraan‑ als op leidingniveau.

Een aangepast AI‑prototype kan indrukwekkend lijken tijdens een demonstratie, maar onbetrouwbaar worden wanneer het wordt blootgesteld aan echte medewerkers, veranderende data en randgevallen. Welke evaluatie, monitoring en menselijke supervisie moeten worden ingesteld voordat een intern AI‑systeem operationeel wordt?

Met enkele noemenswaardige uitzonderingen vind ik dat demo’s minder waardevol zijn in het AI‑tijdperk dan in het software‑tijdperk. Software‑demo’s beloofden altijd te veel en we wisten dat allemaal. AI‑demo’s zullen nog verder verwijderd zijn van uw realiteit.

AI draait om workflow. En er is niets meer op maat dan de duizenden workflows die de operaties van een specifieke organisatie aandrijven. Ga terug naar de metafoor “nieuwe medewerker met een PhD in alles”. Hoeveel training – en hands‑on ervaring binnen uw bedrijf – heeft een nieuwe medewerker nodig voordat hij effectief is in uw bedrijf? Hoe kan een demo daar überhaupt rekening mee houden?

Dus gebruiken we demo’s om mensen aan het denken te zetten. Om hen de kunst van het mogelijke te laten zien. Niet om hen een product te verkopen. De echte demo begint met het prototype van de aangepaste oplossing. Het MVP. En dan itereren en verbeteren. Snel.

Op een gegeven moment is het klaar voor een zachte lancering of pilot‑programma. En opnieuw, we leren – samen – en verbeteren snel op basis van die leerervaring. Dit is vaak de fase waarin monitoring, evaluatie en toezicht scherp in beeld komen. De dingen die u uiteindelijk nodig heeft, verschillen vaak sterk van wat u aanvankelijk zou hebben gedacht.

Hoe kunnen bedrijven Crafters in staat stellen te experimenteren zonder een nieuwe generatie shadow‑AI‑systemen, gedupliceerde workflows, beveiligingskwetsbaarheden en tools te creëren waarvoor niemand verantwoordelijk is voor onderhoud?

Onthoud waar shadow‑IT vandaan kwam: het was niet uit kwaadwilligheid, maar uit de noodzakelijke vervulling van onvervulde vraag. Crafters bouwen omdat problemen hen dwarszitten – dat is het gen. Als het goedgekeurde pad betekent dat u een jaar moet wachten, zal shadow‑AI de kloof vullen – en dat onder de radar, waar het het gevaarlijkst is.

Maak dus de goedgekeurde rij de gemakkelijke rij. Geef Crafters een goedgekeurd platform met de beveiligingsrails al ingebakken – identiteit, data‑toegang, logging – zodat de conforme keuze ook de handige keuze is. Houd een lichtgewicht register bij: alles wat van een persoonlijk experiment naar iets evolueert waar een tweede persoon op rekent, wordt vastgelegd, met een benoemde eigenaar. Die ene regel elimineert het grootste deel van het “verweesde‑tool”‑probleem, want tools met een naam worden niet stilletjes verlaten.

Pas vervolgens het escalatiemodel toe: experimenten draaien vrij, maar zodra iets mission‑critical wordt – meer gebruikers, meer gevoeligheid, meer autonomie – krijgt het geleidelijk meer engineering‑review. De Crafter behoudt eigendom van de bedrijfslogica; een developer verstevigt wat verstevigd moet worden. Het doel is een maturiteits‑pipeline, geen toestemming‑proces. Bedrijven hebben deze exacte film al met spreadsheets gedraaid, en de winnaars waren niet degenen die Excel verboden.

Voor een bedrijf dat aan zijn eerste aangepaste AI‑initiatief begint, hoe moet het de initiële use‑case selecteren, meten of het project betekenisvolle bedrijfswaarde levert, en beslissen of het moet worden uitgebreid, herontworpen of verlaten?

We hebben twee uitgangspunten die we met onze klanten gebruiken.

Optie één, zoek naar de taken die niemand uitvoert – niet de taken die u graag zou willen elimineren. Er is een vraag die ik graag aan managers stel: “waar heeft u gedacht, ‘als ik één persoon had die dit constant in de gaten houdt en erover nadenkt, zouden de dingen aanzienlijk beter worden – maar ik kon nooit een volledige aanstelling rechtvaardigen?’” Dat zijn vaak uw beste startpunten. Ze zijn veilig, ze bouwen vertrouwen, niemand voelt zich aangewezen, en de tegenfeit is eerlijk: het alternatief was geen mens die het goed deed, maar niemand die het deed (zoals mijn redactievriend Eddie).

Optie twee, kijk naar het vervangen van dashboards door data‑agents. Hoe eenvoudig dashboards leken, vielen ze in de praktijk ver kort van hun belofte. Wanneer iemand een zakelijke vraag heeft, is het veel werk om die vraag om te zetten naar het dashboard‑landschap. Waar is het dashboard dat deze vraag beantwoordt? Hoe heet het? Bestaat zo’n dashboard überhaupt? En als u het “juiste” vindt, is het dan duidelijk en handig te gebruiken? Moet u het herhaaldelijk manipuleren, meerdere versies noteren of screenshots maken om het algehele beeld dat u nodig heeft samen te stellen?

In het AI‑tijdperk neemt u gewoon uw zakelijke vraag – in uw eigen woorden – en typt (of dicteert) u die aan een data‑agent die vervolgens alles voor u afhandelt, en levert een gecertificeerd, goed onderbouwd antwoord – inclusief visualisaties – binnen een minuut of twee. Wanneer u een vervolg‑vraag heeft, beantwoordt die agent die ook graag snel – tijdens de vergadering terwijl beslissingen nog genomen kunnen worden.

De gemeenschappelijke rode draad achter beide starter‑opties? Ze richten zich beide op pijnpunten die medewerkers zullen omarmen in plaats van afwijzen. U wilt niet dat uw vroege AI‑initiatieven wantrouwen zaaien. U wilt dat ze in plaats daarvan medewerkers aan de tafel brengen. U wilt dat medewerkers verbeteringen en nieuwe projectideeën suggereren. Want nogmaals, uw bedrijf bestaat uit duizenden workflows, en uw medewerkers kennen die beter dan u.

Over uitbreiden, herontwerpen of verlaten – wees vriendelijk voor uzelf, want het onderzoek hierom is echt geruststellend: de meeste succesvolle AI‑implementaties hadden vooraf mislukkingen. Een eerste project dat een les oplevert in plaats van een opbrengst, is een leermoment, geen bewijs dat AI niet werkt. Mijn vuistregel: als mensen het gebruiken, breid het uit. Als mensen het niet gebruiken, moet u weten waarom, en dat kan een breed scala aan antwoorden zijn, van “omdat het niet goed werkt” tot “omdat ik het niet begrijp” tot “het beangstigt me.” Het antwoord bepaalt of u verbetert, herontwerpt of opgeeft. U hoeft niet te voorspellen waar dit allemaal terechtkomt. U moet alleen ergens eerlijk beginnen.

Bedankt voor het geweldige interview, lezers zouden ook Fair Game: Customizing AI to Your Business Is Easier Than You Think moeten lezen.