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

[5]

ISO/IEC 23894

AI-specifik risikostyring

Integrerer AI-risici i organisatoriske aktiviteter og funktioner

Siger mindre om daglig arbejdsorganisering og medarbejderpraksis

[6]

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

[7]

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

[8]

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

[9]

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

[10]

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

[11]

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

[12]

PMI’s AI Essentials

Projektfaglig oversættelse

Kobler AI til projektledelsespraksis

Giver ikke en samlet organisationsmodel

[13]

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

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/

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

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

Populære opslag fra denne blog

McKinsey As a Prompt

En tidligere OpenAI-medarbejder taler ud (positivt, men meget interessant)

Valg af den rigtige AI og den rigtige AI-model (Ethan Mulllicks seneste opslag)