Question 1

Hvorfor når de fleste AI-projekter aldrig i drift?

Accepted Answer

Fordi piloten blev bygget under forhold, produktionen ikke har.

En proof of concept kører på håndrenset data, på én maskine, uden integration til de systemer, forretningen faktisk bruger. Den har ingen fejlhåndtering, ingen overvågning, ingen logning og ingen rollebaseret adgangsstyring. Alt det skal tilføjes bagefter, og det er dér, projekterne går i stå.

Produktionsdata er inkonsistent. Svartider skal holdes under et sekund. Sikkerhed kræver færrest mulige rettigheder, så en medarbejder ikke kan prompte sig frem til en kollegas løn. Den underliggende fejl er at behandle det som et AI-problem og bygge nedad fra modellen i stedet for at behandle det som systemarkitektur og bygge opad fra infrastrukturen.

Cases

Question 2

Hvad blokerer reelt AI i danske virksomheder?

Accepted Answer

Manglende teknisk kompetence og dårlig datakvalitet. I den rækkefølge.

De fleste organisationer, der går i stå, mangler ikke strategi. Det, de mangler, er ingeniørarbejdet, der gør strategien til software, som virker - datapipelines, cloud-arkitektur, adgangsstyring og drift. Uden det ender det typisk i analyselammelse eller et hyldeprodukt, der ikke kan integreres med noget som helst.

Den anden blokering er datas tilstand. Information ligger spredt i aldrende ERP-systemer, CRM-databaser, lukkede fildrev og ustrukturerede PDF'er. Hvis det ikke kan samles, renses og gøres tilgængeligt gennem pålidelige pipelines, svarer modellen ud fra det, den tilfældigvis finder. Usikkerhed om compliance er en reel tredjeplads: frygt for GDPR-eksponering og EU's AI-forordning stopper projekter, før de overhovedet bliver defineret.

Question 3

Hvorfor fejler RAG-systemer i drift?

Accepted Answer

Fordi søgningen som regel er naiv, og modellen får skylden.

Retrieval-augmented generation lader en model svare ud fra jeres egne dokumenter. Konceptet er sundt. Fejlen ligger næsten altid i søgelaget, ikke i modellen. Ren vektorlighed forudsætter, at spørgsmålet og svaret indeholder de samme ord. I en rigtig virksomhed gør de sjældent det: nogen spørger, hvordan man eskalerer en P1-hændelse, og det dokument, der svarer på det, blev skrevet i 2019 og kalder det en severity-one.

Den anden fejl er chunking. Lange dokumenter skæres i lige store stykker, hvilket adskiller en konklusion fra de betingelser, den afhænger af. Det fundne afsnit er korrekt og ubrugeligt på samme tid. At rette begge dele kræver hybrid søgning - nøgleordssøgning ved siden af vektorer - reranking af resultaterne og chunking, der respekterer dokumentets struktur.

Question 4

Hvad kræver EU's AI-forordning lige nu?

Accepted Answer

Gennemsigtighedskravene gælder allerede. Højrisikokravene blev udskudt til december 2027.

Forordningen inddeler systemer efter risiko. Siden 2. august 2026 skal alt, der interagerer med mennesker, oplyse om det, og syntetisk output skal mærkes maskinlæsbart. Digital Omnibus fra 27. juli 2026 udskød til gengæld højrisikokravene til 2. december 2027, og til 2. august 2028 for AI indlejret i produkter under produktsikkerhedslovgivningen.

Den forpligtelse, de fleste virksomheder har overset, er AI-kompetencer: enhver organisation, der bruger AI-værktøjer, også helt almindelige som ChatGPT eller Copilot, skal understøtte, at medarbejderne kan bruge dem ansvarligt. Og udskudt er ikke aflyst: dokumentationen er billigere at bygge ind nu end at skrue på bagefter. Vi holder en fuld reference over, hvad forordningen kræver af et udviklingsteam, med kilde på hver dato.

AI-forordningen

Question 5

Hvordan håndterer I GDPR og persondata i generativ AI?

Accepted Answer

Et lovligt behandlingsgrundlag, en databehandleraftale, der forbyder træning på jeres data, og minimering, før noget sendes af sted.

GDPR gælder for AI præcis som for alt andet. Databehandleraftalen skal angive, hvor data opbevares, og udtrykkeligt forbyde leverandøren at bruge jeres data til at træne sine egne modeller. Alt indgribende kræver en konsekvensanalyse, før det går i luften - ikke bagefter.

Det tekniske svar er dataminimering: fjern eller pseudonymiser persondata før inferens, så navne bliver til identifikatorer, og følsomme felter maskeres, inden prompten forlader jeres netværk. Modeller, der løbende træner på brugerinput, er en særlig risiko - persondata kan ende indlejret i vægtene, og så bliver retten til sletning umulig at honorere. Hosting inden for EU eller kørsel af åbne modeller på jeres egen infrastruktur fjerner det meste af problemet.

Question 6

Hvad er Shadow AI, og hvorfor er det en sikkerhedsrisiko?

Accepted Answer

Medarbejdere, der bruger ikke-godkendte AI-tjenester til rigtigt arbejde. Jeres data forlader huset, og ingen logger det.

Mens ledelsen diskuterer strategi, har størstedelen af medarbejderne allerede taget værktøjerne i brug. Nogen indsætter en kundeliste, et bestyrelsesreferat, kildekode eller et kontraktudkast i en gratis assistent for at spare en time. I det øjeblik har data forladt jeres sikkerhedsperimeter, og I har ingen registrering af, at det skete.

Generelle forbud gør det værre - de flytter praksissen over på private enheder, hvor intet er synligt. Det brugbare svar har to dele. Fastlæg regler for dataklassifikation, og bloker ikke-godkendte tjenester på maskinerne. Giv derefter folk et internt værktøj, der er godt nok til, at det ikke længere er fristende at ty til offentlige løsninger.

Ydelser

Question 7

Hvordan dokumenterer I ROI og de samlede ejeromkostninger?

Accepted Answer

Ved at indregne omkostningerne for hele systemet, ikke kun modellicensen.

Den typiske fejl er kun at budgettere med API-kald. De reelle ejeromkostninger omfatter hosting, lagring, overvågning, sikkerhedsopdateringer og den ingeniørtid, det tager at holde det hele kørende. Et projekt, der så billigt ud i pilotfasen, bliver dyrt præcis når det begynder at gøre gavn.

På afkastsiden er de gevinster, der holder, i videnarbejde: tid brugt på at lede efter information, samle data og formulere tekst. Hold det op imod de timer, der bruges i dag på det arbejde, AI ville overtage - ikke mod en forventet transformation. To ting sænker den økonomiske risiko strukturelt: en fast pris aftalt inden der skrives kode, og en tidsubegrænset brugsret til koden, så der ikke hænger en løbende betaling ved den.

AI Readiness Assessment

Question 8

Hvem ejer kildekoden og rettighederne?

Accepted Answer

I kan bruge, ændre og flytte alt, vi bygger. Brugsretten er tidsubegrænset, og vi beholder ophavsretten.

Dansk ophavsret lader rettighederne blive hos leverandøren, medmindre kontrakten siger andet, så det bliver skrevet eksplicit ind frem for at være underforstået. Vi bruger den samme konstruktion som det offentliges K-aftaler og IT-Branchens standardvilkår: I får brugsretten, vi beholder ophavsretten.

Det, I får

En tidsubegrænset og uindskrænket brugsret til alt, der er bygget til jer. Brug det, ændr det, byg videre på det - selv, med jeres egne udviklere eller med en anden leverandør. Ingen tidsmæssige eller geografiske begrænsninger, og den fortsætter, efter samarbejdet slutter.

Det, vi beholder

Ophavsretten, og retten til at genbruge den generelle viden, knowhow, værktøjer og komponenter fra vores arbejde. Jeres data, jeres indhold og fortrolige oplysninger er jeres og fjernes, før noget genbruges i andre sammenhænge.

Tredjepart

Open source- og tredjepartskomponenter beholder deres egne licenser. Vi lister hver eneste, vi bruger.

Den opdeling er en del af grunden til, at prisen ser ud, som den gør: fundamentet er der allerede. I kan tage driften hjem eller skifte til en anden partner når som helst, og I kan fremvise og revidere koden, når en myndighed eller en revisor beder om det. Brugsretten er jeres ved overtagelse, eller på betalingstidspunktet for det, der er betalt forud, og den fortsætter, efter samarbejdet slutter.

Ydelser

De spørgsmål, der er værd at stille, før I bygger

At få AI i drift

Sikkerhed, jura og data

Økonomi og ejerskab

Vil I have dem besvaret for jeres forretning?