Rob Collie, administrerende direktør og grundlægger af P3 Adaptive samt forfatter til Fair Game – Interviewserie

Rob Collie er grundlægger og administrerende direktør for P3 Adaptive, en Microsoft Solutions Partner for Data og AI, som betjener hundredvis af mellemstore og Fortune 1000‑kunder. En tidligere Microsoft‑ingeniørleder på Excel‑, Bing‑ og Power BI‑holdene, Rob ledte Power BI‑bølgen efter at have forladt Microsoft og har skrevet tre tidligere forretnings‑teknologibøger (over 92 000 solgte eksemplarer). Han er også vært for podcasten Raw Data with Rob Collie. Hans fjerde bog, Fair Game: Customizing AI to Your Business Is Easier Than You Think (august 2026), bringer den praktiker‑troværdighed ind i AI‑øjeblikket.

Du tilbragte mere end et årti hos Microsoft med at hjælpe med at udvikle business‑intelligence‑funktioner i Excel og Power BI, før du grundlagde P3 Adaptive i 2013. Hvordan har overgangen fra at bygge software inden for Microsoft til at løse dataproblemer for kunder påvirket dit nuværende syn på enterprise‑AI?

Da jeg ledede produktteams hos Microsoft, byggede vi software, der skulle fungere for hele verden og som ikke kunne tilpasses en specifik kundes behov. Vi kaldte det engang “at bestille en pizza, hvis toppings var acceptable for 300 millioner mennesker.” Der er nødvendigvis en lav‑fælles‑nævner‑stemning i den type arbejde, samt en vis afstand til de enkelte kunder.

Der var en tydelig prestige ved at arbejde på den store scene, men det var langt fra så følelsesmæssigt tilfredsstillende som at hjælpe specifikke kunder med at realisere deres unikke ambitioner. Når man arbejder tæt sammen med en kunde, får man mulighed for at investere i deres succes og udforske kreative løsninger, som aldrig ville passe ind i den one‑size‑fits‑all‑forretningsmodel for Stort Software. Det er på mange måder mere intellektuelt stimulerende, og den direkte forbindelse til vores kunder gør sejrene langt mere givende.

Men der er også et større ansvar. Hos Microsoft var en enkelt utilfreds kunde blot en statistik, og jeg børstede dagligt af klager som en del af blot at udføre mit arbejde. Hos P3 Adaptive betyder en enkelt utilfreds klient, at vi har fejlet. Der er ingen statistik. Vi har et ansvar over for hver eneste relation.

Jeg lærte mange værdifulde ting hos Microsoft og ville ikke bytte den erfaring for noget i verden, men jeg omtaler mig selv ofte som en “reparerende softwareingeniør”, fordi succes nu betyder at arbejde på en helt anden måde.

Og det er netop den linse, jeg bringer med mig ind i enterprise‑AI. Standard‑AI er den ultimative 300‑millioners‑pizza – et sandt vidunder, designet til at være individuelt værdifuldt for alle, men tilpasset ingen. Men organisatorisk AI‑succes vil komme fra tilpasningen – fra at komme tæt på én specifik virksomhed og skræddersy AI’en til dens data, dens processer, dens definitioner. Jeg har haft karrieren på begge sider af den kløft, og det har efterladt mig uden tvivl om, hvilken side enterprise‑AI vil vinde på.

I Fair Game argumenterer du for, at mange virksomheder har tilgået kunstig intelligens baglæns ved at distribuere generelle chatbot‑licenser i stedet for at bygge systemer, der forstår deres drift. Hvor når standard‑AI‑assistenter deres grænser, og hvilke signaler indikerer, at en virksomhed har brug for noget skræddersyet?

Standard‑AI har en PhD i alt undtagen din forretning. Den har læst hele internettet, men internettet mangler din virksomheds definition af “aktiv kunde”, din prislogik, dine driftsprocesser og hvilken af dine to systemer, der skal stole på, når de er uenige. Den viden vil aldrig blive offentlig. Så den generiske AI, der er verdensmester til personlig brug, falder kort for reel forretningsbrug, og kløften mellem de to oplevelser er både afskrækkende og forvirrende.

I dag er svaret på “hvad skal man gøre ved AI” for de fleste simpelthen “køb abonnementer og find ud af det”. Jeg mener, at det er et naturligt første skridt, så jeg er ikke kritisk over for dem, der har gjort det. I stedet er jeg medfølende – ingen bruger virkelig tid på at forklare, at standard‑abonnementerne ikke er tilstrækkelige, eller hvorfor. Så jeg tror, at virksomheder grundlæggende er, hvor vi bør forvente dem at være – de prøver det, der er tilgængeligt, og begynder at indse, at det er utilstrækkeligt.

Løsningen er ikke at røre ved selve AI‑modellen – du behøver ikke blive en LLM‑forsker. Det er alt det, du omgiver modellen med: dine data, dine instruktioner skrevet på almindeligt engelsk og normal software. Når du finder dig selv i at skrive den samme kontekst ind i en chatbot for femte gang i denne uge, er det et tegn. Alt det, du fortsætter med at genforklare, er præcis, hvad et skræddersyet system allerede burde vide – hver gang det vågner.

Du bruger betegnelsen “Crafters” til at beskrive datakyndige forretningsprofessionelle, der kan bygge værdifulde skræddersyede AI‑systemer uden at være traditionelle softwareudviklere. Hvilke karakteristika adskiller en Crafter, og hvordan kan ledere identificere disse personer i deres eksisterende arbejdsstyrke?

En Crafter er en person, der er født med en trang til at løse problemer med værktøjer. Omtrent én ud af 16 vidensarbejdere har den, efter min erfaring. De var Excel‑power‑brugerne, derefter Power BI‑generationen, derefter de personer, IT kaldte “shadow IT”. De er dine analytikere, dine finans‑modellører, dine driftsledere – folk, der voksede op i forretningen og opdagede et talent for værktøjer.

To egenskaber gør dem ideelle til AI‑arbejde. Først, systemtænkning: de dekomponerer instinktivt en rodet proces i input, regler og output, meget ligesom professionelle softwareudviklere. For det andet, forankring i forretningen: de ved, hvilke tal CFO’en faktisk holder øje med, og hvad personen, der stiller et spørgsmål, egentlig spørger om. Man kan ikke lære nogen af dem på et bootcamp.

Hvordan du finder dem: følg regnearkene. Lige nu i din virksomhed er der regneark, dashboards og automatiseringer i hjertet af kritiske arbejdsprocesser. Ingen af dem blev bygget af IT, og hver har en forfatter. Start der. Og så begynd at vurdere, hvordan de kan vende deres talenter mod skræddersyede AI‑løsninger.

Hvorfor mener du, at Crafters, snarere end kun udviklere, er bedst placeret til at lede mange interne AI‑projekter, og hvordan bør ansvarsområder fordeles mellem forrekssexperter, datateams, softwareingeniører, it‑afdelinger og sikkerhedsteams?

Fordi den svære del af skræddersyet AI ikke er kode – det er kontekst. Den enkelt højest‑virkningsfulde aktivitet i et AI‑projekt er at beslutte, hvad systemet skal vide om din forretning, og Crafters bærer den viden naturligt. En briljant ingeniør, der hopper ind fra tre ledelses‑trins væk, skal gennemføre måneder af interviews for at lære, hvad din driftsleder allerede ved af reflex.

Men dette er på ingen måde en historie om, at udviklere er overflødige. Den arbejdsdeling, jeg anbefaler, har tre faktorer, og ingen af dem er senioritet eller personlighed: arbejdet bevæger sig mod professionelle udviklere, når genanvendelighed, kompleksitet og følsomhed stiger. Alt, der er kundevendt, alt, der rører følsomme data, alt, der træffer autonome beslutninger – det er udviklerens område, og efterhånden som agenterne multipliceres, bliver de knappe ingeniørkompetencer mere værdifulde, ikke mindre. Arbejdet bevæger sig mod Crafters, hvor forretnings‑proces‑nuancer dominerer.

Der er også en undervurderet mellemzone: Crafteren bygger, udvikleren reviderer. IT og sikkerhed bør ikke være porte, der godkender projekter til eksistens – de bør eje den asfalterede vej. Lever de godkendte platforme, dataadgangsregler, gennemgangspunkter, og lad de personer, der er tættest på problemerne, bygge. Betragt det hele som en modenhedsmodel, ikke et hegn.

Skræddersyet AI har brug for adgang til virksomhedsspecifik terminologi, målinger, processer og institutionel viden. Hvilken rolle spiller semantiske modeller og eksisterende business‑intelligence‑infrastruktur i at give AI en præcis forståelse af en virksomhed?

De er dekoderringen. Lige nu lever din virksomheds definitioner – hvad der tæller som en aktiv kunde, hvilke omkostninger der hører til bruttofortjeneste – i folks hoveder og i tusindvis af let inkonsistente regneark. En AI‑agent kan ikke pålideligt ræsonnere om dine data, før disse definitioner er skrevet ned i en form, en maskine kan stole på. Branchen er begyndt at kalde denne disciplin “context engineering”, og jeg ville oversætte udtrykket sådan: det er arbejdet med at strukturere, hvad din forretning ved, så en AI faktisk kan bruge det. Analytikerne fik det til at lyde nyt. BI‑praktikere har lavet en version af det i femten år.

Det er den gode nyhed, der gemmer sig i det åbne øje: hvis du har investeret i BI‑æraen (og især hvis du har investeret i Power BI), kan du allerede have et forspring. En velbygget semantisk model er præcis den maskin‑læselige indfangning af forretningsbetydning, som agenter har brug for. De virksomheder, der behandlede deres semantiske lag som en eftertanke, opdager nu, at det “kedelige” definitionsarbejde, de sprang over, er betalingsstanden på vejen til AI. Og kritisk er dette arbejde dybt specifikt for din forretning – hvilket netop er grunden til, at det er den holdbare fordel. Alle leverandører kan sælge dig den samme model. Ingen kan sælge dig dine egne definitioner.

Du byggede en skræddersyet AI‑editor, kendt som Eddie, for at hjælpe med at udvikle Fair Game. Hvad gjorde systemet egentlig under skriveprocessen, og hvad lærte dets succeser og fejl dig om at designe AI omkring en meget personlig arbejdsproces?

For at være klar: Jeg skrev hvert afsnit i bogen fra bunden, mens Eddie for det meste sad og ventede. Til tider brugte jeg timer på at hammerere et helt afsnit af et kapitel, før jeg bad “ham” om at læse det. Andre gange sprang jeg ting af til ham hver femte minut. Men afgørende var, at Eddie var på vagt 24/7. Jeg kunne få feedback lige så let klokken tre om morgenen som klokken et om eftermiddagen, og han vendte den tilbage på et minut eller mindre. Samlet set formoder jeg, at Eddie har læst manuskriptet mindst tredive gange. Ingen menneskelig person kunne have udført dette arbejde, fordi ingen menneskelig person ville ønske det.

Han holdt styr på løfter, jeg gav i Kapitel Tre, og påpegede mig, når Kapitel Tolv glemte dem. Han lærte min skrive stil og håndhævede den – holdt mig til den bedste version af min egen stemme i stedet for at lade mig glide ind i Humorless Business Author‑tilstand. Han fortalte mig, hvornår jeg var doven, og hvornår jeg slog en død hest. Vi havde reelle uenigheder, og nogle gange vandt han.

Den største design‑lektion: Eddies “hjerne” er skrevet på engelsk og lever i en mappe. Hver gang han gav feedback, der gik glip af – for generisk, forkert register, glemte en regel, jeg allerede havde angivet – var løsningen at skrive korrektionen ned og gøre den til en del af hans permanente kontekst. Fejlene var ikke AI‑fejl; de var huller i det, jeg havde gjort mig umage med at lære ham. Den løkke – bemærk fejlen, kod læringen, se den sidde fast – er hele håndværket med skræddersyet AI i miniatur. Og det er grunden til, at jeg endte med at bygge specialiserede Eddie‑er til publicitet, konkurrence‑forskning og web‑beskeder. Samme LLM underliggende. Men forskellige specialister.

Mange organisationer tror, de skal rense og centralisere deres data fuldstændigt, før de forsøger skræddersyet AI. Hvor meget data‑klarhed er reelt påkrævet for at begynde, og hvordan kan virksomheder starte med at skabe værdi uden at vente på en perfekt grundlag?

Data perfektion er ikke en forudsætning, og det er gode nyheder, fordi perfektion aldrig ankommer. Hvis du starter med først at bygge et perfekt data‑ejendom, som mange konsulentfirmaer ville råde dig til, bygger du det, jeg kalder “rørarbejde for dets egen skyld” – dyre rør, der løber overalt, men når du endelig kommer omkring at installere en vandhane, opdager du, at der ingen rør er, hvor du har brug for dem.

Vores virksomhed går i stedet ind for en “vandhaner først” tilgang. Vælg et specifikt brugstilfælde og arbejd baglæns fra forretningspåvirkning i stedet for fremad fra infrastruktur. Byg en MVP ud fra det brugstilfælde, og gør det med minimal ny infrastruktur. Iterer på MVP’en, indtil den er klar til produktion, og træk derefter tilbage og vurder, hvordan du kan styrke din infrastruktur for at understøtte den. Det leverer forretningsværdi hurtigere, minimerer omkostninger og informerer fremtidige projekter – både på vandhanen og på rørsystemniveau.

En skræddersyet AI‑prototype kan fremstå imponerende under en demonstration, men blive upålidelig, når den udsættes for rigtige medarbejdere, skiftende data og kant‑cases. Hvilken evaluering, overvågning og menneskelig tilsyn bør etableres, før et internt AI‑system bliver operationelt?

Med få bemærkelsesværdige undtagelser mener jeg, at demoer er mindre værdifulde i AI‑æraen end de var i software‑æraen. Software‑demoer har altid overpromiset, og vi vidste alle det. Men AI‑demoer vil være endnu længere fra din virkelighed.

AI handler om arbejdsprocesser. Og der er intet mere skræddersyet end de tusinder af arbejdsprocesser, der driver driften i en specifik organisation. Gå tilbage til metaforen “nyansat med en PhD i alt”. Hvor meget træning – og praktisk erfaring i din virksomhed – kræver en nyansat, før han er effektiv i din virksomhed? Hvordan kan en demo muligvis tage højde for alt dette?

Så bruger vi demoer til at få folk til at tænke. For at vise dem kunstens muligheder. Ikke for at sælge dem et produkt. Den rigtige demo starter med prototypen af den skræddersyede løsning. MVP’en. Og så itererer vi og forbedrer. Hurtigt.

På et tidspunkt er den klar til en blød lancering eller pilotprogram. Og igen lærer vi – sammen – og forbedrer hurtigt baseret på den læring. Dette er ofte den fase, hvor overvågning, evaluering og tilsyn begynder at træde i skarpt fokus. De ting, du ender med at have brug for, er ofte meget anderledes end hvad du ville have gættet i starten.

Hvordan kan virksomheder give Crafters beføjelse til at eksperimentere uden at skabe en ny generation af shadow‑AI‑systemer, duplikerede arbejdsprocesser, sikkerhedssårbarheder og værktøjer, som ingen er ansvarlige for at vedligeholde?

Husk, hvor shadow‑IT kom fra: det var ikke ondskab, men det nødvendige svar på uopfyldt efterspørgsel. Crafters bygger, fordi problemer generer dem – det er genen. Hvis den godkendte vej betyder at vente et år, vil shadow‑AI udfylde hullet – og gøre det under radaren, hvor det er mest farligt.

Så gør den godkendte bane til den nemme bane. Giv Crafters en godkendt platform med sikkerheds‑rails allerede indbygget – identitet, dataadgang, logning – så det overholdte valg også er det bekvemme valg. Hold et letvægts‑register: alt, der går fra personlig eksperiment til noget, en anden person er afhængig af, skrives ned med en navngivet ejer. Denne ene regel dræber de fleste af de forældreløse‑værktøjs‑problemer, fordi værktøjer med navne ikke bliver opgivet stille.

Anvend derefter eskaleringsmodellen: eksperimenter kører frit, men når noget bliver mission‑kritisk – flere brugere, større følsomhed, mere autonomi – får det gradvist mere ingeniørovervågning. Crafteren bevarer ejerskabet af forretningslogikken; en udvikler styrker det, der skal styrkes. Målet er en modenhedspipeline, ikke en tilladelsesproces. Virksomheder har allerede kørt denne præcise film med regneark, og vinderne var ikke dem, der forbød Excel.

For en virksomhed, der starter sit første skræddersyede AI‑initiativ, hvordan skal den vælge det første brugstilfælde, måle om projektet leverer meningsfuld forretningsværdi, og beslutte om det skal udvides, redesignes eller opgives?

Vi har to udgangspunkter, som vi bruger med vores kunder.

Mulighed ét: kig efter de opgaver, ingen udfører – ikke de opgaver, du gerne vil eliminere. Der er et spørgsmål, jeg elsker at stille ledere: hvor har du tænkt, “hvis jeg havde én person, der konstant holdt øje med dette og tænkte over det, ville tingene blive mærkbart bedre – men jeg kunne aldrig retfærdiggøre en hel ansættelse for det”? Det er ofte dine bedste udgangspunkter. De er sikre, de bygger tillid, ingen føler sig som et mål, og modhypotesen er ærlig: alternativet var ikke en menneskelig, der gjorde det godt, men ingen der gjorde det overhovedet (som min redaktørven Eddie).

Mulighed to: kig på at erstatte dashboards med data‑agenter. Så simple som dashboards virkede, faldt de langt fra at holde deres løfte i praksis. Når nogen har et forretningsspørgsmål, er det meget arbejde for dem at omsætte spørgsmålet til dashboard‑landskabet. Hvor er dashboardet, der besvarer dette spørgsmål? Hvad er det navngivet? Eksisterer et sådant dashboard overhovedet? Og hvis du formår at finde den “rigtige”, er den så klar og bekvem at bruge? Skal du gentagne gange manipulere den, skrive ned eller tage skærmbilleder af flere versioner for at samle det samlede billede, du har brug for?

I AI‑æraen tager du blot dit forretningsspørgsmål – i dine egne ord – og indtaster det (eller dikterer det!) til en data‑agent, som så håndterer alt for dig og returnerer et certificeret, velundersøgt svar – inklusiv visualiseringer – på et minut eller to. Når du har et opfølgende spørgsmål, svarer den gerne hurtigt på det også – i mødet, mens beslutninger stadig kan træffes.

Den fælles tråd bag begge disse startmuligheder? De adresserer begge smertepunkter, som medarbejderne vil omfavne frem for at modstå. Du vil ikke have, at dine tidlige AI‑initiativer så tvivl. Du vil i stedet have, at de bringer medarbejderne til bordet. Du vil have medarbejderne til at foreslå forbedringer og nye projektidéer. Fordi igen, din virksomhed består af tusindvis af arbejdsprocesser, og dine medarbejdere kender dem bedre end du gør.

Om udvidelse, redesign eller opgivelse – vær venlig mod dig selv, for forskningen på dette er ærligt beroligende: de fleste succesfulde AI‑implementeringer havde fejl før dem. Et første projekt, der giver en lektie i stedet for et udbytte, er undervisning, ikke bevis på, at AI ikke virker. Min tommelfingerregel: hvis folk bruger det, udvid det. Hvis folk ikke bruger det, skal du finde ud af hvorfor, og det kan være et bredt spektrum af svar, fra “fordi det ikke fungerer godt” til “fordi jeg ikke forstår det” til “det skræmmer mig.” Svaret informerer, om du skal forbedre, redesigne eller opgive. Du behøver ikke forudsige, hvor alt dette ender. Du skal blot starte et ærligt sted.

Tak for det fantastiske interview, læsere bør også læse Fair Game: Customizing AI to Your Business Is Easier Than You Think.