Hvordan bruger man AI i organisationer: Fra projekter til opgaver med AI (Deep Research)
Jeg indtalte en længere prompt (derfor er der nogle stavefejl) for at få et bud på anvendelse af AI i praksis i organisationer. Et kort oplæg fra mig i en klumme i Computerworld havde fået en læser til at putte mine skriverier ind i Perplexity, og jeg har så taget både mit og Perplixity's materiale og kørt en Deep Research på det. Her er min prompt:
"jeg og andre går i disse tider og tænker meget over modeller for anvendelse af kunstig intelligens i organisationer og i projekter og for individer i organisationerne. Jeg forsøgte i min klumme i fredags at komme med et bud på en tre steps metode og en af mine læsere var så smart at han puttede det ind i en kunstig intelligens nemlig Percy og bad den om at kommentere på det jeg havde skrevet. Lige om lidt får du både mine forslag og tid men jeg vil også lige sætte scenen for hvad jeg gerne vil have til jeg vil gerne have at du undersøger om der rent faktisk er nogen der har tænkt over disse ting og lave metoder eller måske endda standarder for anvendelse eller indførelse af gunstig intelligens i organisation og projekter og så videre og hvis ikke så Overvej nøje de COMPLEXITY har skrevet plus de andre har skrevet om tilsvarende ting og foreslå en gennemarbejdetmodeller for henholdsvis anvendelse af det bredt i organisationer til speed PROSA og andre ting og til at få måske projekter til at gå hurtigere blive bedre billigere og alle de andre fordele vi kender vi. Her kommer det materiale som jeg lovede dig nemlig mit første rå forslag og derefter perpleks iz reaktion på det . Gennemfør en kritisk analyse og kom med forbedringsforslag til flg:"
Fra projekter til opgaver med AI
Hovedkonklusion
Ja, der er allerede tænkt meget over dette felt, og der findes både
standarder, playbooks, offentlige vejledninger og forskningsbaserede modeller
for ansvarlig og effektiv anvendelse af AI i organisationer. Men der findes
ikke én enkelt, færdig “mastermodel”, som på én gang løser tre niveauer: bred
organisatorisk indførelse, hurtigere og bedre projekter samt den enkelte
medarbejders daglige brug. Det, der findes, er snarere et modulært landskab:
styringsstandarder til organisationen, risikomodeller til anvendelsen,
livscyklusmodeller til løsningerne og kompetencekrav til medarbejderne. Derfor
er det rigtige næste skridt ikke at opfinde alt fra bunden, men at samle disse
tråde i en mere operationel model. [1]
Din intuition om at flytte fokus “fra projekter til opgaver” er i den
forstand meget stærk. Den ligger tæt op ad den task-baserede tænkning i både
arbejdsmarkedsforskning og nyere AI-forskning: arbejde bør forstås som bundter
af opgaver, og AI’s værdi afhænger af, hvilke opgaver der kan understøttes,
hvor godt de kan kædes sammen, og hvor meget verifikation og koordinering der
stadig kræves. Men forskningen peger også på, at gevinsten sjældent kommer af
at automatisere enkeltopgaver isoleret; den kommer oftere af at redesigne hele
workflows, så AI-kompatible opgaver samles, handoffs reduceres, og
kontrolpunkter placeres rigtigt. Med andre ord: den rigtige bevægelse er ikke
bare fra projekter til opgaver, men fra projekter til opgaver og fra opgaver
til sammenhængende opgavekæder. [2]
Min samlede vurdering er derfor, at din model er rigtig i sin diagnose,
men utilstrækkelig i sin styringslogik. Perplexitys kritik rammer flere vigtige
mangler, især klassifikation, tidlig governance og konkretisering af AI, men
den svarer stadig primært med procesforbedring. Det, der mangler, er en
egentlig operativ model med tydelige baner, roller, proportional governance,
læringssløjfer og en særskilt model for medarbejdernes daglige AI-brug. Det er
den model, jeg foreslår nedenfor. [3]
Hvad
der allerede findes
Det er forkert at sige, at området er metodemæssigt tomt. Tværtimod
findes der allerede en ret solid “stabel” af internationale og offentlige
rammer, men de adresserer forskellige lag af problemet. ISO/IEC 42001 er en
ledelsesstandard for et AI management system på organisationsniveau og
beskriver, hvordan man etablerer, implementerer, vedligeholder og løbende
forbedrer AI-styring i organisationen. ISO/IEC 23894 giver vejledning i
AI-specifik risikostyring. ISO/IEC 38507 flytter spørgsmålet op i bestyrelses-
og direktionens styringsrum. ISO/IEC 5338 beskriver AI-systemers
livscyklusprocesser og kan bruges i både organisationer og projekter. NIST AI
RMF giver en frivillig, men meget anvendt risikostruktur med de fire
kernefunktioner govern, map, measure og manage, og OECD’s AI-principper og
due-diligence-vejledning kobler AI til ansvarlig virksomhedsadfærd og løbende
due diligence. For den offentlige sektor findes der ovenikøbet et særskilt
G7/OECD/UNESCO-toolkit, og i Danmark findes både Digitaliseringsstyrelsens,
Datatilsynets, KL’s og den Digitale Taskforces vejledninger og principper. PMI
har desuden lavet særskilt materiale til projektprofessionelle. [4]
|
Ramme |
Hvad den bidrager med |
Hvor den er stærk |
Hvor den ikke er nok alene |
Kilder |
|
ISO/IEC 42001 |
Et formelt AI-ledelsessystem med løbende forbedring |
Organisationsstyring, ansvarlig brug, sporbarhed, compliance |
Svarer ikke i sig selv på, hvornår noget er en opgave, et projekt
eller blot personlig produktivitet |
|
|
ISO/IEC 23894 |
AI-specifik risikostyring |
Integrerer AI-risici i organisatoriske aktiviteter og funktioner |
Siger mindre om daglig arbejdsorganisering og medarbejderpraksis |
|
|
ISO/IEC 38507 |
Governance for ledelse og bestyrelse |
Gør AI til et topledelsesansvar |
Er for højniveau til at styre konkrete opgavelanes og leverancerytmer |
|
|
ISO/IEC 5338 |
Livscyklusprocesser for AI-systemer |
God til udvikling, anskaffelse og forbedring af AI-løsninger i
projekter |
Er ikke en model for medarbejdernes daglige brug af generativ AI |
|
|
NIST AI RMF |
Govern, map, measure, manage |
Operativ risikologik på tværs af hele livscyklussen |
Frivillig ramme; kræver oversættelse til lokal drift og roller |
|
|
OECD AI Principles og Due Diligence Guidance |
Værdier og seks due-diligence-trin |
God til at forbinde AI med ansvarlig virksomhedsadfærd,
stakeholderhensyn og dokumentation |
Ikke en hurtig beslutningsmodel for opgave vs. projekt |
|
|
G7 Toolkit for Public Sector AI |
Praktisk offentlig-sektor-rejse fra principper til anvendelse |
Offentlige use cases, governance, implementeringsudfordringer og
rejsen fra framing til scaling |
Ikke en dansk lokal driftsmodel i sig selv |
|
|
Danske vejledninger |
Lokal operationalisering i dansk kontekst |
AI-færdigheder, data, jura, transparens, ansvar, sikkerhed og
praktiske retningslinjer |
Ikke en samlet portefølje- og triagemodel |
|
|
PMI’s AI Essentials |
Projektfaglig oversættelse |
Kobler AI til projektledelsespraksis |
Giver ikke en samlet organisationsmodel |
Det vigtigste forskningsmæssige modsvar til idéen om et tomt felt er,
at task-begrebet allerede er centralt i AI- og arbejdsmarkedsforskning.
OpenAI’s “GPTs are GPTs” vurderer job ud fra opgaveeksponering, og Alan Turing
Institutes analyse af offentligt arbejde bygger eksplicit på den task-baserede
tilgang fra arbejdslivsøkonomien og estimerer, at omkring 41 % af den
offentlige arbejdstid i Storbritannien ligger i aktiviteter, som generativ AI
kan understøtte. Det betyder ikke, at 41 % kan automatiseres væk; det betyder,
at en meget stor del af arbejdet giver mening at tænke i opgaver, eksponering,
error tolerance og støtte frem for i store abstrakte transformationsprojekter. [14]
Hvad forskningen siger om opgaver, workflow og produktivitet
Forskningen peger i retning af tre ting på én gang. For det første kan
AI faktisk skabe konkrete produktivitetsgevinster. I et stort feltstudie af
kundeservice øgede generativ AI produktiviteten med omkring 14 %, med særligt
store gevinster for mindre erfarne medarbejdere. Stanford-versionen af samme
forskning understreger desuden, at AI ofte indsnævrer gabet mellem lav- og
højtperformende medarbejdere. I softwareudvikling viste et kontrolleret
eksperiment fra Microsoft Research, at udviklere med GitHub Copilot løste
opgaven 55,8 % hurtigere, og GitHubs egne undersøgelser viser, at brugerne
oplever mere flow og mindre kognitiv belastning ved repetitive opgaver. I den
britiske centraladministration viste en stor Copilot-afprøvning et
gennemsnitligt tidsbesparelsesniveau på 26 minutter om dagen, samtidig med at
over 70 % oplevede mindre tid brugt på informationssøgning og rutinearbejde. [15]
For det andet er gevinsten ikke jævnt fordelt. Harvard/BCG-studiet om
den “jagged technological frontier” viser, at AI markant forbedrer hastighed og
kvalitet på opgaver inden for modellens styrkeområde, men at teknologien ikke
er stabilt god på alle tilsyneladende lignende opgaver. Det er en meget vigtig
korrektion til enhver for simpel AI-optimisme. Den praktiske lære er, at
organisationer ikke skal spørge “kan AI hjælpe os?”, men “på hvilke opgaver,
under hvilke betingelser, med hvilken verifikationsbyrde og med hvilke failure
modes?”. Derfor er en moden model nødt til at indeholde frontier-vurdering,
testregimer og en eksplicit beslutning om, hvornår AI kun må foreslå, og
hvornår den må producere noget, der går videre i processen. [16]
For det tredje kommer den store gevinst ofte fra workflow-redesign,
ikke fra punktvis værktøjsbrug. MIT Sloan fremhæver ny forskning, der viser, at
AI’s største effekt ligger i, hvordan opgaver sekventeres, grupperes og
overdrages mellem mennesker og maskiner. Når AI-venlige opgaver kædes sammen,
falder koordinationsomkostningen. Når hver lille delopgave i stedet sendes frem
og tilbage mellem mennesker, værktøjer og kontrolinstanser, bliver AI mest et
ekstra lag. McKinseys 2025-survey peger i samme retning: omdesign af workflows
er den faktor, der korrelerer stærkest med bundlinjeeffekt, og CEO-overblik
over AI-governance hænger også sammen med bedre effekt. Det er meget tæt på det
problem, du peger på: mange organisationer forsøger at “lægge AI oven på” den
eksisterende projektmaskine i stedet for at ændre selve arbejdsformen. [17]
Der findes også en vigtig offentlig-sektor-konsekvens af dette. Dansk
og international offentlig vejledning anbefaler ikke at starte med de mest
spektakulære use cases, men med de kedelige og gentagne interne processer, hvor
der er høj volumen, lavere ekstern skade ved fejl og et tydeligt
læringspotentiale. Digitaliseringsstyrelsen anbefaler eksplicit at starte dér,
hvor det er nemmest, gerne med simple ikke-borgervendte processer med mange
gentagelser, og samtidig at få jura og dataforudsætninger afklaret tidligt. Den
Digitale Taskforce har i den danske storskalasatsning fra 2026 koncentreret
indsatsen om automatiseret dokumentation, assistenter og beslutningsstøtte til
medarbejdere samt digitale assistenter til borgere og virksomheder. Det er i
praksis en offentlig porteføljemodel, ikke bare en værktøjspolitik. [18]
Kritisk analyse af din model og Perplexitys svar
Din model har en stærk kerne, fordi den angriber et reelt
organisatorisk problem: projectification. Forskningen om public sector
projectification beskriver netop projektspredning som en central tendens i den
offentlige sektor, og nyere managementlitteratur understreger, at
projectification også kan øge organisatorisk kompleksitet. Derfor er din
diagnose ikke bare polemisk; den ligger i forlængelse af en etableret
forskningsdiskussion. Din model har også stærk ledelsesmæssig energi: den
insisterer på at samle viden og beslutningskraft i samme rum, den tidsbokser,
og den forsøger at få værdien ud tidligt. Alt det er sundt. [19]
Problemet er, at modellen i sin nuværende form blander tre forskellige
spørgsmål sammen: arbejdsorganisering, risikostyring og teknologisk leverage.
Derfor bliver formuleringen “trin tre: alt det udenom” den svageste del. I
moderne AI-styring er governance ikke noget, der kommer efter løsningen;
governance er selve det, der afgør, om løsningen kan designes hurtigt, sikkert
og genbrugeligt. NIST beskriver govern som en tværgående funktion, der skal
gennemsyre de øvrige funktioner. OECD’s due diligence begynder med at indlejre
ansvarlig adfærd i politikker og ledelsessystemer. Datatilsynet siger direkte,
at databeskyttelsesreglerne skal tænkes ind helt fra start, og
Digitaliseringsstyrelsen anbefaler tidlig afklaring af både jura og data. Det
er ikke “udenom”; det er designforudsætninger. [20]
Det andet svage punkt er, at AI i din model mest er en antagelse og
ikke en arbejdsdeling. Der står, at AI gør det muligt at gøre ting anderledes,
men ikke hvordan. Her er Perplexitys kritik fair. Men Perplexitys eget svar
bliver også for generisk. Det mangler især tre ting. Dels skelner det ikke
mellem intern produktivitet, beslutningsstøtte og borger- eller kundevendte
anvendelser, selv om disse tre baner har meget forskellige risikoprofiler. Dels
gør det ikke nok ud af frontier-problemet: AI er ikke bare en hurtig
medhjælper, men et værktøj med ujævn kvalitet, hvilket kræver forskellige
verifikationsmønstre. Dels mangler det en ordentlig efterfase: monitorering,
læring, incident-håndtering, udfasning og opdatering af guardrails. På det
punkt er både NIST, OECD og COSO mere modne end Perplexitys forbedringsforslag.
[21]
Det tredje punkt er tidsboksen. “En halv dag” er god som provokation og
som kulturmarkør, men dårlig som generel styringsregel. Den bør ikke forstås
som “produktion på en halv dag”, men som “første verificérbare version på en
halv dag”, og kun i de lavrisikoopgaver, hvor data, værktøj, kompetencer og
beslutningsret allerede er på plads. Det er i tråd med forskningens pointe om,
at AI skaber værdi hurtigere, når opgaver er velafgrænsede, repetitive eller
inden for værktøjets frontier, og mindre sikkert, når opgaven er kompleks,
tværgående eller rettighedsfølsom. [22]
En gennemarbejdet model for organisationer
Hvis jeg skulle samle standarderne, forskningen og den danske
offentlige kontekst i én model, ville jeg foreslå en AI-operativ model
med fem faste lag: principper, portefølje, platform, praksis og læring. Pointen
er, at de lag skal være lette nok til ikke at kvæle tempoet, men faste nok til
at gøre tempo muligt uden kaos. Det svarer bedre til ISO 42001’s
ledelsessystemtænkning, NIST’s govern/map/measure/manage-logik og OECD’s due
diligence end en ren projektmodel gør. [23]
Principper er øverste lag. Her fastsætter
ledelsen ikke bare et etisk manifest, men en egentlig brugspolitik: hvad AI må
bruges til, hvilke dataklasser der må behandles i hvilke værktøjer, hvilke
anvendelser der kræver særskilt godkendelse, og hvilken risikotolerance
organisationen accepterer. Den Digitale Taskforces principper er et godt lokalt
udgangspunkt: værdiskabelse, omkostningseffektivitet, ansvarlighed, sikkerhed,
bæredygtighed og fremtidssikring. Ledelsen bør samtidig fastlægge en simpel
regel om, at kun godkendte værktøjer og godkendte integrationsmønstre må bruges
i produktion. [24]
Portefølje er næste lag. Her bør alle
AI-initiativer – også små – passere en let intake og triage. Ikke for at starte
et projekt, men for at afgøre, hvilken bane de tilhører: personlig
produktivitet, teamopgave, struktureret workflow-ændring eller formelt projekt/program.
Triage bør ske hurtigt, helst på 15-30 minutter, og vurdere fem forhold:
ekstern påvirkning, dataklasse, integrationsgrad, reversibilitet og
fejlkonsekvens. NIST’s profil-tænkning med current og target states er nyttig
her, fordi den gør det muligt at arbejde med proportionale krav i stedet for
enten fuld bureaukrati eller laissez-faire. [25]
Platform er tredje lag. Her skal
organisationen gøre det “kedelige” arbejde én gang og få tempo mange gange:
fælles kontraktvilkår, godkendte modeltjenester, logging, outputmærkning,
adgangsstyring, standardprompts, testpakker, dokumentationsskabeloner og eventuelt
en central videnbank over gode use cases og kendte failure modes.
Digitaliseringsstyrelsen anbefaler genbrug af eksisterende løsninger, og den
danske Taskforce lægger op til fællesoffentlige skaleringsmønstre frem for
lokal pionerromantik i hver enhed. Det er præcis den logik, der skalerer. [18]
Praksis er det fjerde lag. Her skal AI bruges
i konkrete arbejdssituationer gennem små ansvarlige enheder frem for store
møder. Standardopstillingen bør være en lille arbejds-celle med én
domæneekspert, én output- eller systemejer og én person, der kan bygge eller
konfigurere løsningen. AI skal have en eksplicit rolle i cellen: analysere
materiale, foreslå proces, generere første udkast, skabe testcases, udarbejde
dokumentation og hjælpe med overlevering. Menneskerne skal tilsvarende have
eksplicitte roller: afgrænse problemet, vurdere korrekthed, træffe valg,
acceptere risiko og stå på mål for resultatet. HBS-studiet peger på netop
forskellige samarbejdsmønstre mellem menneske og AI, og NIST samt OECD
understreger, at roller og ansvar skal være tydelige. [26]
Læring er femte lag. Her fejler mange
AI-initiativer i praksis, fordi de tror, idriftsættelse er slutpunktet.
Organisationen bør måle på mindst seks ting: gennemløbstid,
kvalitetsforbedring, genarbejde, faktisk brugeradoption, incidents/afvigelser
og dokumenteret frigjort tid. Hertil kommer et læringsløb, hvor
risikopolitikker, træning og standarder justeres på baggrund af det, der
faktisk sker. McKinsey peger på, at organisationer, der får værdi ud af AI,
ændrer workflows og governance, mens OECD og NIST begge gør løbende
monitorering og forbedring til en del af modellen. [27]
En gennemarbejdet model for projekter og opgaver
På projekt- og opgaveniveau ville jeg erstatte din tretrinsmodel med en
opgaveførst-model. Den bedste version af din tanke er ikke at afskaffe
projekter, men at indføre en hurtig opgavelane ved siden af projektmaskinen.
Det afgørende er, at små og reversible forbedringer ikke skal tvinges gennem
samme styring som tværgående, irreversible eller rettighedsfølsomme ændringer.
Samtidig må de heller ikke få lov at løbe uden sikkerhedsnet. [28]
En praktisk beslutningsregel kan se sådan ud:
|
Bane |
Typisk kendetegn |
AI’s rolle |
Governance-niveau |
Typisk tidshorisont |
|
Personlig produktivitet |
Ingen integration, ingen beslutningseffekt, lav datarisiko |
Udkast, opsummering, strukturering, oversættelse, idegenerering |
Godkendt værktøj, træning, basale regler |
Samme dag |
|
Teamopgave |
Få afhængigheder, lav til moderat risiko, reversibel ændring |
Prototype, analyse, test, dokumentation, intern assistent |
Let triage, standardguardrails, simple tests |
Dage til få uger |
|
Workflow-ændring |
Flere roller, procesændring, beslutningsstøtte, integrationer |
Delautomatisering, sagsstøtte, dokumentation, kvalitetssikring |
Udvidet review med jura, sikkerhed, arkitektur og ejerforankring |
Uger til få måneder |
|
Formelt projekt |
Tværgående systempåvirkning, høj compliance- eller rettighedsrisiko,
irreversibilitet |
Delkomponent i større design og levering |
Fuld projekt- eller programstyring |
Måneder+ |
Dette skel er ikke improviseret; det ligger i forlængelse af NIST’s
proportionalitets- og kontekstlogik, OECD’s risikobaserede due diligence,
Digitaliseringsstyrelsens anbefaling om at starte småt og Datatilsynets krav om
at tænke databeskyttelse ind fra starten. Samtidig passer det godt med den
danske Taskforces aktuelle portefølje, hvor dokumentation,
medarbejderassistenter og borgerassistenter eksplicit behandles som forskellige
skaleringsbaner. [29]
Selve arbejdsforløbet bør derefter være kort og iterativt. Først
afgrænses opgaven: ønsket effekt, bruger, data, risici og succesmål. Dernæst
bygges en første version hurtigt i cellen, gerne samme dag i de simple
tilfælde. Så kommer parallel validering: faglig test, teknisk test og de
relevante guardrails, som først aktiveres på det niveau, risikoen tilsiger.
Derefter kommer idriftsættelse med rollback-mulighed, ejerskab og opfølgning.
NIST kalder processen iterativ, ikke lineær, og MIT Sloan understreger, at
værdien afhænger af, hvordan opgaver kædes og håndoffs reduceres. Derfor bør
test, compliance og arkitektur ikke placeres som en sen “trin tre”-mur, men som
aktive og proportionale kontroller undervejs. [30]
Din formel “dem, der ved noget, og dem, der kan beslutte, sætter sig
sammen” bør bevares næsten ordret. Det er sandsynligvis det stærkeste i din
model. Men jeg ville supplere den med to skærpelser. Den første er, at mødet
skal ende med én af fire beslutninger: gør det nu, prøv af som prototype, løft
det til næste bane eller stop det helt. Den anden er, at “færdig” skal
defineres som verificeret og forankret, ikke blot bygget. Det er den vigtigste
praktiske forskel mellem hurtighed og forhastelse. [31]
En gennemarbejdet model for individet
For den enkelte medarbejder bør organisationen ikke nøjes med “du må
bruge Copilot/ChatGPT”, men indføre en AI-arbejdspraksis med fire faste
vaner: afgræns, anvend, verificér og dokumentér. Det matcher både EU’s AI
literacy-krav og KL’s danske vejledning, som lægger vægt på teknologiske,
praktiske og etiske færdigheder samt menneskelig bearbejdning og ansvar. [32]
Afgræns betyder, at medarbejderen hurtigt skal
kunne afgøre, om opgaven egner sig til AI. Gode kandidater er udkast,
omskrivning, strukturering, mødeforberedelse, opsummering, translationshjælp,
idégenerering, testcases og rutinepræget dokumentation. Dårlige kandidater er
endelige faglige vurderinger uden menneskelig kontrol, materiale med
personoplysninger eller forretningskritisk information i åbne værktøjer, og
opgaver hvor fejlen rammer borgerrettigheder eller sagsbehandling direkte. Både
KL og Digitaliseringsstyrelsen advarer mod at lægge personoplysninger og
forretningskritiske oplysninger i offentligt tilgængelige værktøjer, og
EU-kommissionens AI literacy-Q&A fremhæver hallucination som en konkret
risiko, medarbejdere skal informeres om. [33]
Anvend betyder, at medarbejderen arbejder med
AI som makker og ikke som auteur. AI bør bruges til første version, ikke til
sidste ansvar. I praksis betyder det, at medarbejderen beder modellen om at
strukturere et problem, foreslå alternativer, fremstille argumenter for og
imod, generere testspørgsmål eller sammenfatte komplekst stof i et
arbejdspapir, som efterfølgende behandles fagligt. Denne arbejdsdeling passer
godt med både HBS-studiets centaur/cyborg-begreber og med de dokumenterede
produktivitetsgevinster i tekst-, support- og kodearbejde. [34]
Verificér er den vigtigste vane. Medarbejderen
skal kende sit verifikationsmønster efter outputtype. Faktuelt og juridisk
indhold kræver kildecheck og faglig kontrol; analysenotater kræver kontrol af
antagelser og logik; kode kræver tests; borger- og kundevendt indhold kræver
både faglig og formmæssig godkendelse. Det er netop læren fra den jaggede
frontier: høj performance i nogle opgavetyper fritager ikke organisationen for
systematisk verifikation i andre. KL understreger, at output aldrig kan stå
alene og altid skal bearbejdes af fagpersoner. [35]
Dokumentér betyder ikke et stort bureaukrati,
men passende gennemsigtighed. Hvis AI har bidraget væsentligt til et notat, et
resume, et forslag eller en sagsforberedelse, bør det kunne forklares, hvordan
værktøjet er brugt, hvilke dele der er AI-genererede, og hvem der har valideret
resultatet. KL anbefaler åbenhed om brugen, og EU-Kommissionen siger, at der
ikke kræves certifikater for AI literacy, men at organisationer godt kan føre
interne registre over træning og vejledning. Det peger på en simpel praksis:
dokumentér vigtige anvendelser, ikke alt. [36]
Åbne spørgsmål og begrænsninger
Jeg har med vilje baseret denne analyse på de mest autoritative
offentlige kilder, standarder og forskningsresultater, men jeg har ikke
kortlagt Trafikstyrelsens interne retningslinjer, værktøjsportefølje eller
data-/arkitekturregler. Derfor er modellen her bedst forstået som en fagligt
underbygget referencemodel, der skal oversættes til jeres lokale dataklasser,
godkendte værktøjer, journaliseringskrav, leverandørstrategi og
myndighedsansvar, før den kan bruges som egentlig intern driftsmodel. [37]
Derudover var din reference til “COMPLEXITY” ikke entydig i de
offentligt tilgængelige kilder. Jeg har derfor ikke lagt vægt på et specifikt
Complexity-dokument, men i stedet bygget vurderingen på det bredere forsknings-
og standardlandskab, som reelt dækker det spørgsmål, du stiller. Hvis
“COMPLEXITY” henviser til en bestemt artikel, virksomhed eller intern tekst,
kan den være relevant som supplement, men den ændrer næppe hovedkonklusionen:
den mest holdbare model er en opgave- og workflowbaseret AI-arbejdsmodel med
tidlig governance, tydelige baner og stærk AI literacy. [38]
[1] [4] [5] [23] [37]
https://www.iso.org/standard/42001
https://www.iso.org/standard/42001
[2]
https://www.turing.ac.uk/sites/default/files/2025-05/ons_tus_final_report.pdf
https://www.turing.ac.uk/sites/default/files/2025-05/ons_tus_final_report.pdf
[3] [9] [20] [29] [30] [31] https://airc.nist.gov/airmf-resources/airmf/5-sec-core/
https://airc.nist.gov/airmf-resources/airmf/5-sec-core/
[6]
https://www.iso.org/standard/77304.html
https://www.iso.org/standard/77304.html
[7]
https://www.iso.org/standard/56641.html
https://www.iso.org/standard/56641.html
[8]
https://www.iso.org/standard/81118.html
https://www.iso.org/standard/81118.html
[10] https://www.oecd.org/en/topics/ai-principles.html
https://www.oecd.org/en/topics/ai-principles.html
[11]
https://www.oecd.org/en/publications/g7-toolkit-for-artificial-intelligence-in-the-public-sector_421c1244-en.html
[12]
https://digst.dk/kunstig-intelligens/guides-til-brug-af-kunstig-intelligens/
https://digst.dk/kunstig-intelligens/guides-til-brug-af-kunstig-intelligens/
[13] https://www.pmi.org/standards/ai-essentials-for-project-professionals
https://www.pmi.org/standards/ai-essentials-for-project-professionals
[14]
https://openai.com/index/gpts-are-gpts/
https://openai.com/index/gpts-are-gpts/
[15]
https://www.nber.org/papers/w31161
https://www.nber.org/papers/w31161
[16] [21] [26] [34] [35] https://d3.harvard.edu/navigating-the-jagged-technological-frontier/
https://d3.harvard.edu/navigating-the-jagged-technological-frontier/
[17] [38] https://mitsloan.mit.edu/ideas-made-to-matter/how-ai-reshaping-workflows-and-redefining-jobs
https://mitsloan.mit.edu/ideas-made-to-matter/how-ai-reshaping-workflows-and-redefining-jobs
[18]
https://digst.dk/kunstig-intelligens/casekatalog-ai-loesninger-med-dokumenteret-effekt/
https://digst.dk/kunstig-intelligens/casekatalog-ai-loesninger-med-dokumenteret-effekt/
[19]
https://publicera.kb.se/sjpa/article/view/10588
https://publicera.kb.se/sjpa/article/view/10588
[22]
https://www.microsoft.com/en-us/research/publication/the-impact-of-ai-on-developer-productivity-evidence-from-github-copilot/
[24]
https://www.digitaskforce.dk/taskforcens-indsatser/principper-for-anvendelse-af-kunstig-intelligens
https://www.digitaskforce.dk/taskforcens-indsatser/principper-for-anvendelse-af-kunstig-intelligens
[25] https://airc.nist.gov/airmf-resources/airmf/6-sec-profile/
https://airc.nist.gov/airmf-resources/airmf/6-sec-profile/
[27]
https://www.mckinsey.com/~/media/mckinsey/business%20functions/quantumblack/our%20insights/the%20state%20of%20ai/2025/the-state-of-ai-how-organizations-are-rewiring-to-capture-value_final.pdf?param1=competitive-matrix
[28] https://www.sciencedirect.com/science/article/pii/S0007681323001155
https://www.sciencedirect.com/science/article/pii/S0007681323001155
[32]
https://digital-strategy.ec.europa.eu/en/faqs/ai-literacy-questions-answers
https://digital-strategy.ec.europa.eu/en/faqs/ai-literacy-questions-answers
[33] [36]
https://videncenter.kl.dk/viden-og-vaerktoejer/ai/ai-inspirationskataloger/guide-om-generativ-ai
https://videncenter.kl.dk/viden-og-vaerktoejer/ai/ai-inspirationskataloger/guide-om-generativ-ai
Kommentarer
Send en kommentar