Denne ydelse handler om den AI, der allerede bruges i jeres virksomhed, godkendt eller ej, og hvad der skal til for at få den under kontrol og i ordentlig drift: først indskrænkning, derefter modelvalg, integration, sikkerhed, business case og til sidst godkendelsen.

Noget af den AI er aldrig blevet godkendt: en browserudvidelse, en privat konto, en agent, som ingen har sat grænser for. Den skal indskrænkes først, med klare grænser og godkendte værktøjer, før der bygges noget nyt ovenpå. De fem kompetencer nedenfor er det, der skal til bagefter, uanset om I rydder op i det, der allerede er der, eller starter forfra.

De fleste virksomheder er forbi demoen. Nogen har bygget noget, der så godt ud på et møde, og så kommer de rigtige spørgsmål: Må det bruge produktionsdata? Kan vi stole på det over for en kunde? Hvad koster det, når alle bruger det? Hvem godkender det, og hvad sker der, når det tager fejl? Det er ikke et problem med modellen. Det er et arkitekturproblem, og det er her, de fleste AI-projekter går i stå.

En AI-arkitekt skal få projektet over den forhindring. Rollen bygger på fem kompetencer, og kun én af dem handler om AI. De fire andre afgør, om der overhovedet bliver leveret noget.

Hvad en AI-arkitekt skal kunne

1. Selve AI’en

Valg af model er en afvejning, ikke en smagssag: kapacitet mod pris, svartid, kontrol og hvor data lovligt må ligge. Retrieval-augmented generation (RAG) får modellen til at svare ud fra jeres egne dokumenter i stedet for internettets gennemsnit. Model Context Protocol (MCP) giver den adgang til de systemer, hvor arbejdet faktisk foregår, så den ikke bare sidder i et chatvindue ved siden af.

Så kommer det, de fleste pilotprojekter springer over. En model, der imponerer til demoen og tager fejl en gang om måneden i produktion, er en risiko. Den skal testes før lancering og overvåges bagefter, både for at kvaliteten falder over tid, og for de svar, der lyder sikre, men er forkerte. AI-sikkerhed er et fag for sig: prompt injection gør jeres egne dokumenter til instruktioner, og retrieval gør et skjult rettighedsproblem søgbart. Begge dele skal løses i designet, før de bliver til hændelser.

Og intet af det virker på dårlige data. Data lakes, data warehouses og databaser skal være i orden, før der er noget at hente. Det er den mindst spændende del af arbejdet og den vigtigste.

• Modelvalg ud fra pris, svartid, kontrol og hvor data ligger
• Retrieval over jeres egne dokumenter, så svarene kan spores tilbage til kilden
• Integration med værktøjer og workflows, bl.a. via Model Context Protocol
• Test og løbende overvågning af kvalitet og hallucinationer
• Prompt injection, datalæk og trusselsmodellering for AI
• Datakvalitet på tværs af data lakes, data warehouses og databaser
• Retningslinjer for brug og etik, skrevet så folk rent faktisk kan følge dem

2. Platformen under AI’en

AI kører på almindelig infrastruktur og fejler af helt almindelige grunde. Cloud eller on-premises. En færdig model som service eller en åben model, I selv hoster. Hvordan netværket klarer belastning, hvad en API-aftale reelt lover, og hvornår compute og storage begynder at koste rigtige penge. Det er de valg, der afgør, om løsningen kan skalere, er stabil og holder sig inden for rammer, I kan forklare en auditor.

Tyve års erfaring med løsnings- og sikkerhedsarkitektur er ikke en sidegevinst her. Det er selve kvalifikationen. AI-laget er nyt, men alt det, der bærer det, er det ikke.

3. Mødet, hvor det skal godkendes

AI-projekter dør sjældent på grund af modellen. De dør i styregruppen. Økonomidirektøren vil have et tal. Sikkerhedschefen vil have klare grænser. Juristerne vil vide, hvor data havner, og hvem der har ansvaret, når det går galt. Og det team, der skal arbejde anderledes hver dag, vil vide, om løsningen skal hjælpe dem eller erstatte dem. Det spørgsmål stiller ingen højt, men alle handler ud fra det.

At få alle fire til at sige ja uden at have direkte ledelsesansvar for nogen af dem er en kompetence i sig selv. Det samme gælder forandringsledelsen bagefter. Et workflow, som medarbejderne i stilhed lader være med at bruge, giver samme resultat som et projekt, der aldrig fik penge.

4. Business casen

En business case, der holder hos økonomiafdelingen, er ikke et slide med en procentsats. Den har en tilbagebetalingstid med antagelser, som man må udfordre, en leverandørsammenligning, hvor vinderen ikke var givet på forhånd, og en ærlig afvejning af tempo mod governance i stedet for et løfte om begge dele.

Den svarer også på det, de fleste AI-forslag springer over: Hvad gør forretningen den morgen, hvor modellen, API’et eller leverandøren er nede? Og hvilke processer er efterhånden blevet afhængige af noget, der har en statusside? Beredskabsplaner for AI er kun nye i den forstand, at meget få endnu har lavet en.

5. Oversættelsen

Arkitekturarbejdet skal munde ud i noget, folk kan handle på: et kapabilitetskort, et løsningsdesign og en roadmap, der er ordnet efter afhængigheder og ikke efter begejstring. Før alt det skal man spørge sig frem til behovet bag ønsket. Nogen beder om en chatbot. Det, de reelt har brug for, er, at tre teams holder op med at besvare det samme spørgsmål manuelt, elleve gange om dagen, efter hukommelsen.

Beskrevet på den sidste måde får det penge og bliver brugt. Beskrevet på den første måde ender det som et pilotprojekt og et skuldertræk. Det er aldrig værktøjet, der er historien. Det er problemet.

Sådan kommer vi i gang

• En vurdering. Kort og afgrænset. Hvor I står, hvad der er sikkert at gøre nu, og hvad der skal rettes først. God, når der allerede er et pilotprojekt, og folk er uenige om det.
• Et løsningsdesign. Arkitektur, roadmap og business case samlet i én leverance, skrevet til både bestyrelsen og dem, der skal bygge det.
• En arkitekt i teamet. Pr. uge eller pr. sprint. Jeg designer løsningen og hjælper derefter med at bygge den, så I slipper for omarbejde, børnesygdomme og et skredet budget.

Skal vi tage en snak?

30 minutter, gratis og uforpligtende. Har I et pilotprojekt, ingen vil godkende, en business case, der bliver ved med at komme retur, eller en bestyrelse, der vil have en plan inden næste kvartal eller andre problemstillinger så lad os tale om dem til mødet.

I kan også sende en besked i stedet.