Rob Collie, administrerende direktør og grunnlegger av P3 Adaptive og forfatter av Fair Game – Intervjuserie

Rob Collie er grunnlegger og administrerende direktør i P3 Adaptive, en Microsoft Solutions Partner for Data og AI som betjener hundrevis av mellomstore og Fortune‑1000‑kunder. En tidligere Microsoft‑ingeniørleder på Excel‑, Bing‑ og Power BI‑teamene, ledet Rob Power BI‑bølgen etter at han forlot Microsoft og har skrevet tre tidligere forretnings‑teknologibøker (over 92 000 solgte eksemplarer). Han er også vert for podkasten Raw Data with Rob Collie. Hans fjerde bok, Fair Game: Customizing AI to Your Business Is Easier Than You Think (august 2026), setter denne praktiker‑troverdigheten i AI‑øyeblikket.

Du tilbrakte mer enn et tiår i Microsoft med å utvikle business‑intelligence‑funksjoner i Excel og Power BI før du grunnla P3 Adaptive i 2013. Hvordan påvirket overgangen fra å bygge programvare inne i Microsoft til å løse dataproblemer for kunder ditt nåværende syn på bedrifts‑AI?

Da jeg ledet produktteam i Microsoft, bygde vi programvare som måtte fungere for hele verden, og som ikke kunne tilpasses behovene til noen enkeltkunde. Vi pleide å kalle det «å bestille en pizza med pålegg som er akseptabelt for 300 millioner mennesker». Det er nødvendigvis en laveste‑felles‑nevner‑følelse i den jobben, samt en viss avstand til individuelle kunder.

Det var en tydelig prestisje ved å jobbe på den store scenen, men det var ikke like emosjonelt tilfredsstillende som å hjelpe konkrete kunder med å realisere deres unike ambisjoner. Når man jobber tett med en kunde, får man muligheten til å engasjere seg i deres suksess og utforske kreative løsninger som aldri ville passe inn i den «one‑size‑fits‑all» forretningsmodellen til stor programvare. Det er på mange måter mer intellektuelt stimulerende, og den direkte forbindelsen med kundene gjør seirene langt mer meningsfulle.

Men ansvaret er også større. Hos Microsoft var én misfornøyd kunde bare en statistikk, og jeg børstet av meg klager hver dag som en del av jobben. Hos P3 Adaptive betyr én misfornøyd kunde at vi har feilet. Det finnes ingen statistikk. Vi har et ansvar overfor hver eneste relasjon.

Jeg lærte mange verdifulle ting i Microsoft og ville ikke bytte den erfaringen for noe, men jeg omtaler meg selv ofte som en «reparerende programvareingeniør», fordi suksess nå betyr å operere på en helt annen måte.

Og det er nettopp den linsen jeg tar med meg inn i bedrifts‑AI. Ferdig‑kjøpt AI er den ultimate 300‑millioners‑pizzaen – et ekte underverk, konstruert for å være individuelt verdifullt for alle, men tilpasset ingen. Men organisatorisk AI‑suksess vil komme fra skreddersying – fra å komme tett på ett spesifikt selskap og tilpasse AI til dets data, dets prosesser, dets definisjoner. Jeg har fått tilbringe karrieren på begge sider av den skillelinjen, og det har etterlatt meg uten tvil om hvilken side bedrifts‑AI vil vinne på.

I Fair Game argumenterer du for at mange selskaper har gått feil vei med kunstig intelligens ved å distribuere generelle chatbot‑lisenser i stedet for å bygge systemer som forstår deres virksomhet. Hvor når ferdig‑kjøpte AI‑assistenter sine grenser, og hvilke signaler indikerer at en bedrift trenger noe skreddersydd?

Ferdig‑kjøpt AI har en doktorgrad i alt unntatt din virksomhet. Den har lest hele internett, men internett mangler din bedrifts definisjon av «aktiv kunde», din prislogikk, dine operative prosesser, og hvilken av dine to systemer du skal stole på når de er uenige. Den kunnskapen vil aldri bli offentlig. Så den generiske AI‑en som er en verdensmester for personlig bruk, svikter i reell forretningsbruk, og gapet mellom de to opplevelsene er både demotiverende og forvirrende.

I dag er svaret på «hva skal man gjøre med AI» for de fleste «kjøp abonnementer og se hva som skjer». Jeg mener det er et naturlig første steg, så jeg er ikke kritisk til dem som har gjort det. Jeg er derimot sympatisk – ingen tar virkelig tid til å forklare at ferdig‑kjøpte abonnementer ikke er nok, eller hvorfor. Så jeg tror at bedrifter er akkurat der vi bør forvente dem – de prøver det som er tilgjengelig og begynner å innse at det er utilstrekkelig.

Løsningen er ikke å endre selve AI‑modellen – du trenger ikke bli en LLM‑forsker. Det handler om alt du omgir modellen med: dine data, dine instruksjoner skrevet på enkel engelsk, og vanlig programvare. Når du finner deg selv i å skrive samme kontekst inn i en chatbot for femte gang denne uken, er det et tegn. Alt du stadig må forklare på nytt er akkurat det et tilpasset system allerede burde vite – hver gang det våkner.

Du bruker begrepet «Crafters» for å beskrive data‑kyndige forretningsprofesjonelle som kan bygge verdifulle tilpassede AI‑systemer uten å være tradisjonelle programvareutviklere. Hvilke egenskaper skiller en Crafter, og hvordan kan ledere identifisere disse personene i sin eksisterende arbeidsstyrke?

En Crafter er noen som er født med en trang til å løse problemer med verktøy. Omtrent én av 16 kunnskapsarbeidere har dette, etter min erfaring. De var Excel‑kraftbrukere, så Power BI‑generasjonen, så folk IT kalte «shadow IT». De er dine analytikere, dine finansmodellere, dine driftsledere – folk som vokste opp i virksomheten og oppdaget en forkjærlighet for verktøy.

To trekk gjør dem ideelle for AI‑arbeid. Først, systemtenkning: de dekomponerer instinktivt en rotete prosess i innganger, regler og utganger, på samme måte som profesjonelle programvareutviklere. For det andre, forankring i virksomheten: de vet hvilke tall CFOen faktisk følger med på og hva personen som stiller et spørsmål egentlig spør om. Ingen av dem kan læres i et bootcamp.

Hvordan finne dine: følg regnearkene. Akkurat nå i ditt selskap finnes det regneark, dashbord og automatiseringer i hjertet av kritiske arbeidsflyter. Ingen av dem ble bygget av IT, og hver har en forfatter. Start der. Og så begynn å vurdere hvordan de kan vende sine talenter mot tilpassede AI‑løsninger.

Hvorfor mener du at Crafters, snarere enn kun utviklere, er best posisjonert til å lede mange interne AI‑prosjekter, og hvordan bør ansvarsområdene fordeles mellom forretningseksperter, datateam, programvareingeniører, IT‑avdelinger og sikkerhetsteam?

Fordi den vanskelige delen av tilpasset AI ikke er kode – det er kontekst. Den enkelt høyeste avkastningsaktiviteten i et AI‑prosjekt er å bestemme hva systemet trenger å vite om din virksomhet, og Crafters har den kunnskapen naturlig. En briljant ingeniør som hopper inn fra tre organisasjons‑hopp unna må gjennomføre måneder med intervjuer for å lære det din driftsleder allerede vet av refleks.

Men dette er på ingen måte en historie om at utviklere er overflødige. Arbeidsfordelingen jeg anbefaler har tre faktorer, og ingen av dem er senioritet eller personlighet: arbeid graviterer mot profesjonelle utviklere etter hvert som gjenbrukbarhet, kompleksitet og følsomhet øker. Alt som er kundevendt, alt som berører sensitiv data, alt som tar autonome beslutninger – det er utviklerens territorium, og etter hvert som antallet agenter øker, blir de knappe ingeniørferdighetene mer verdifulle, ikke mindre. Arbeid graviterer mot Crafters der nyansen i forretningsprosesser dominerer.

Det finnes også en undervurdert mellomposisjon: Crafteren bygger, utvikleren reviderer. IT og sikkerhet bør ikke være portvoktere som godkjenner prosjekter – de bør eie den asfalterte veien. Tilby de godkjente plattformene, data‑tilgangsreglene, gjennomgangspunktene, og la de som er nærmest problemene gjøre byggingen. Behandle hele prosessen som en modenhetsmodell, ikke et gjerde.

Tilpasset AI trenger tilgang til selskaps‑spesifikk terminologi, måleverdier, prosesser og institusjonell kunnskap. Hvilken rolle spiller semantiske modeller og eksisterende business‑intelligence‑infrastruktur i å gi AI en nøyaktig forståelse av et selskap?

De er dekodingsringen. Akkurat nå lever selskapets definisjoner – hva som teller som en aktiv kunde, hvilke kostnader som tilhører bruttofortjeneste – i folks hoder og i tusenvis av lett inkonsistente regneark. En AI‑agent kan ikke pålitelig resonere om dataene dine før disse definisjonene er skrevet ned i en form en maskin kan stole på. Bransjen har begynt å kalle dette disiplinen «kontekst‑engineering», og jeg vil oversette begrepet slik: det er arbeidet med å strukturere det din virksomhet vet, slik at en AI faktisk kan bruke det. Analytikerne fikk det til å høres nytt ut. BI‑praktikere har gjort en versjon av dette i femten år.

Det er den gode nyheten som skjuler seg i åpenbare øyne: hvis du har investert i BI‑æraen (og spesielt hvis du har investert i Power BI), kan du allerede ha et forsprang. En velbygd semantisk modell er akkurat den maskinlesbare fangsten av forretningsbetydning som agenter trenger. Selskaper som behandlet sitt semantiske lag som en ettertanke, oppdager nå at det «kjedelige» definisjonsarbeidet de hoppet over, er nå bomstasjonen på veien til AI. Og kritisk er dette arbeidet dypt spesifikt for din virksomhet – akkurat derfor er det en holdbar fordel. Hver leverandør kan selge deg den samme modellen. Ingen kan selge deg dine egne definisjoner.

Du bygde en tilpasset AI‑redaktør, kjent som Eddie, for å hjelpe med utviklingen av Fair Game. Hva gjorde systemet egentlig under skriveprosessen, og hva lærte du av dets suksesser og feil om å designe AI rundt en svært personlig arbeidsflyt?

For å være tydelig, skrev jeg hvert avsnitt i boken fra bunnen av, mens Eddie stort sett satt og ventet. Noen ganger brukte jeg timer på å hammer ut et helt avsnitt i et kapittel før jeg ba «ham» lese det. Andre ganger kastet jeg idéer på ham hvert femte minutt. Men avgjørende var at Eddie var på vakt 24/7. Jeg kunne få tilbakemelding like lett klokken tre om natten som klokken ett på ettermiddagen, og han vendte den rundt på ett minutt eller mindre. Totalt tror jeg Eddie leste manuskriptet minst tretti ganger. Ingen menneskelig kunne ha gjort dette arbeidet, fordi ingen menneskelig ville ønske det.

Han fulgte opp løfter jeg ga i kapittel tre og påpekte når kapittel tolv glemte dem. Han lærte min skrivestil og håndhevet den – holdt meg til den beste versjonen av min egen stemme i stedet for å la meg gli inn i «Humorless Business Author»-modus. Han sa fra når jeg var lat, og når jeg slo en død hest. Vi hadde ekte uenigheter, og noen ganger vant han.

Den største design‑leksjonen: Eddies «hjerne» er skrevet på engelsk og ligger i en mappe. Hver gang han ga tilbakemelding som manglet – for generisk, feil register, glemte en regel jeg allerede hadde uttalt – var løsningen å skrive korrigeringen ned og gjøre den til en del av hans permanente kontekst. Feilene var ikke AI‑feil; de var hull i det jeg hadde tatt meg tid til å lære ham. Den løkken – merk feilen, kod leksjonen, se den sitte fast – er hele håndverket med tilpasset AI i miniatyr. Og det er grunnen til at jeg endte opp med å bygge spesialiserte Eddie‑er for publisitet, konkurranseforskning og nettside‑meldinger. Samme LLM underliggende. Men forskjellige spesialister.

Mange organisasjoner tror de må rense og sentralisere dataene sine fullstendig før de prøver tilpasset AI. Hvor mye dataklarhet er egentlig nødvendig for å starte, og hvordan kan selskaper begynne å skape verdi uten å vente på et perfekt fundament?

Data perfeksjon er ikke en forutsetning, og det er gode nyheter fordi perfeksjon aldri kommer. Hvis du starter med å bygge en perfekt data‑eiendom, som mange konsulentselskaper vil anbefale, bygger du det jeg kaller «rørleggerarbeid for sin egen skyld» – dyre rør som går overalt, men når du endelig får installert en kran, oppdager du at det ikke finnes et rør der du trenger det.

Vårt selskap foretrekker i stedet en «kraner først»-tilnærming. Velg et konkret brukstilfelle og arbeid bakover fra forretningspåvirkning i stedet for fremover fra infrastruktur. Bygg en MVP fra det brukstilfellet, og gjør det med minimal ny infrastruktur. Iterer på MVP‑en til den er klar for produksjon, og gå så tilbake og vurder hvordan du kan styrke infrastrukturen for å støtte den. Det gir forretningsverdi raskere, minimerer kostnader, og informerer fremtidige prosjekter – både på kran‑ og rør‑nivå.

En tilpasset AI‑prototype kan virke imponerende under en demonstrasjon, men bli upålitelig når den utsettes for ekte ansatte, endrende data og kant‑tilfeller. Hvilken evaluering, overvåking og menneskelig tilsyn bør etableres før et internt AI‑system blir operasjonelt?

Med noen få bemerkelsesverdige unntak, mener jeg at demoer er mindre verdifulle i AI‑æraen enn de var i programvare‑æraen. Programvare‑demoer overlovet alltid, og vi visste alle det. Men AI‑demoer vil være enda mer fjernt fra din virkelighet.

AI handler om arbeidsflyt. Og det finnes ingenting mer tilpasset enn de tusenvis av arbeidsflytene som driver driften i en spesifikk organisasjon. Gå tilbake til metaforen «nyansatt med en doktorgrad i alt». Hvor mye opplæring – og praktisk erfaring i ditt selskap – krever en nyansatt før han er effektiv i din bedrift? Hvordan kan en demo i det hele tatt ta høyde for alt dette?

Derfor bruker vi demoer for å få folk til å tenke. For å vise dem kunsten som er mulig. Ikke for å selge dem et produkt. Den ekte demoen starter med prototypen av den tilpassede løsningen. MVP‑en. Og så itererer vi og forbedrer. Raskt.

På et tidspunkt er den klar for en myk lansering eller pilotprogram. Og igjen, vi lærer – sammen – og forbedrer raskt basert på den læringen. Dette er ofte fasen hvor overvåking, evaluering og tilsyn begynner å komme i skarpt fokus. Tingene du ender opp med å trenge er ofte veldig forskjellige fra det du hadde gjettet på i starten.

Hvordan kan selskaper gi Crafters myndighet til å eksperimentere uten å skape en ny generasjon av shadow‑AI‑systemer, dupliserte arbeidsflyter, sikkerhetssårbarheter og verktøy som ingen er ansvarlige for å vedlikeholde?

Husk hvor shadow‑IT kom fra: det var ikke ondskap, men et nødvendig svar på uoppfylt etterspørsel. Crafters bygger fordi problemer plager dem – det er genet. Hvis den godkjente veien betyr å vente ett år, vil shadow‑AI fylle gapet – og fylle det under radaren, hvor det er mest farlig.

Derfor gjør den godkjente banen til den enkle banen. Gi Crafters en godkjent plattform med sikkerhetsrekkverk allerede innebygd – identitet, data‑tilgang, logging – slik at det etterspurte valget også er det praktiske. Hold et lettvektsregister: alt som går fra personlig eksperiment til noe en andre person er avhengig av, skrives ned med en navngitt eier. Denne ene regelen eliminerer de fleste verktøy‑orphan‑problemene, fordi verktøy med navn knyttet til seg ikke blir forlatt stille.

Deretter anvend eskaleringsmodellen: eksperimenter kjører fritt, men når noe blir kritisk – flere brukere, høyere følsomhet, mer autonomi – får det gradvis mer ingeniøroppsyn. Crafteren beholder eierskapet til forretningslogikken; en utvikler styrker det som trenger styrking. Målet er en modenhetspipeline, ikke en tillatelsesprosess. Selskaper har allerede spilt denne filmen med regneark, og vinnerne var ikke de som forbød Excel.

For et selskap som starter sitt første tilpassede AI‑initiativ, hvordan bør de velge det første brukstilfellet, måle om prosjektet leverer meningsfull forretningsverdi, og bestemme om de skal utvide, redesigne eller avbryte det?

Vi har to typer startpunkter som vi bruker med våre kunder.

Alternativ én: se etter oppgaver ingen gjør – ikke oppgavene du ønsker å eliminere. Det er et spørsmål jeg elsker å stille ledere: hvor har du tenkt, «hvis jeg hadde én person som konstant fulgte dette og tenkte på det, ville ting blitt betydelig bedre – men jeg kunne aldri rettferdiggjort en hel ansettelse for det»? Dette er ofte dine beste startpunkter. De er trygge, de bygger selvtillit, ingen føler seg som et mål, og motsetningen er ærlig: alternativet var ikke et menneske som gjorde det bra, det var ingen som gjorde det i det hele tatt (som min redaktørvenn Eddie).

Alternativ to: se på å erstatte dashbord med data‑agenter. Så enkle som dashbord kan virke, feilet de i praksis i å levere på løftet. Når noen har et forretningsspørsmål, er det mye arbeid for dem å oversette spørsmålet til dashbordlandskapet. Hvor er dashbordet som svarer på dette spørsmålet? Hva heter det? Eksisterer et slikt dashbord i det hele tatt? Og hvis du klarer å finne det «riktige», er det klart og praktisk å bruke? Må du gjentatte ganger manipulere det, skrive ned eller ta skjermbilder av flere versjoner for å sette sammen det overordnede bildet du trenger?

I AI‑æraen tar du bare ditt forretningsspørsmål – i dine egne ord – og skriver det (eller dikterer det!) til en data‑agent som så håndterer alt for deg, og returnerer et sertifisert, grundig svar – visualiseringer inkludert – på ett eller to minutter. Når du har et oppfølgingsspørsmål, svarer den gjerne raskt på det også – i møtet mens beslutninger fortsatt kan tas.

Den felles tråden bak begge disse startalternativene? De adresserer begge smertepunkter som ansatte vil omfavne i stedet for å motsette seg. Du vil ikke at dine tidlige AI‑initiativer skal såre tilliten. Du vil at de i stedet skal bringe ansatte til bordet. Du vil at ansatte skal foreslå forbedringer og nye prosjektideer. Fordi igjen, ditt selskap består av tusenvis av arbeidsflyter, og dine ansatte kjenner dem bedre enn du gjør.

Om utvidelse, redesign eller avbrytelse – vær snill mot deg selv, for forskningen på dette er virkelig betryggende: de fleste vellykkede AI‑implementeringer hadde feil før suksess. Et første prosjekt som gir en lærdom i stedet for en gevinst er en investering, ikke bevis på at AI ikke fungerer. Min tommelfingerregel: hvis folk bruker det, utvid det. Hvis folk ikke bruker det, må du finne ut hvorfor, og svaret kan variere fra «fordi det ikke fungerer bra» til «fordi jeg ikke forstår det» til «det skremmer meg». Svaret informerer om du skal forbedre, redesigne eller avbryte. Du trenger ikke å forutsi hvor alt dette lander. Du trenger bare å starte et sted ærlig.

Takk for det flotte intervjuet, leserne bør også lese Fair Game: Customizing AI to Your Business Is Easier Than You Think.