PMO, EA og AI governance: Tre discipliner
Indsigt/PMO, EA og AI governance: Tre discipliner
Strategi🇩🇰 Dansk

PMO, EA og AI governance: Tre discipliner

August 2026·8 min læsning·Brian P.N. Tofft

De fleste virksomheder opbygger projektledelse, arkitekturstyring og AI governance som tre separate funktioner. Hver med sin leder, sine processer og sit sprog. Det virker logisk på papiret, men i praksis skaber det blindzoner, dobbeltarbejde og beslutninger, der modarbejder hinanden. Denne artikel beskriver, hvordan de tre discipliner hænger sammen, og hvordan en integreret tilgang giver bedre projekter, stærkere arkitektur og reel kontrol over AI.

Tre funktioner, ét formål

Et Project Management Office (PMO) sikrer, at projekter gennemføres struktureret og leverer det forventede resultat. Enterprise Architecture (EA) sikrer, at teknologiske valg understøtter forretningsstrategien og passer ind i det samlede systemlandskab. AI governance sikrer, at brugen af kunstig intelligens sker ansvarligt, lovligt og med dokumenteret risikostyring. Alle tre funktioner eksisterer for at beskytte virksomheden mod dårlige beslutninger og spildte ressourcer. Alligevel opererer de i mange organisationer i siloer, hvor PMO rapporterer til en CIO eller COO, EA sidder i en teknikafdeling, og AI governance er placeret hos jura. Resultatet er, at et projekt kan blive godkendt af PMO uden at EA har vurderet den arkitekturmæssige konsekvens, eller at en AI-løsning implementeres uden at nogen har klassificeret den efter EU AI Act.

Stage Gate-modellen som fælles ramme

En Stage Gate-model opdeler et IT-projekt i faser med klare gates, beslutningspunkter, hvor projektet vurderes inden det rykker videre. Typiske faser er idé og screening, foranalyse, planlægning, eksekvering, test og lancering. Ved hver gate stilles konkrete spørgsmål: er business casen stadig valid? Er risici identificeret og håndteret? Er de nødvendige ressourcer på plads? Denne model er PMO's styringsværktøj. Men den bliver langt stærkere, når EA og AI governance integreres direkte i faserne. I stedet for at arkitekturvurderinger og compliancetjek sker som isolerede sideprocesser, indlejres de som obligatoriske elementer ved de relevante gates.

EA i projektmodellen: arkitektur som kvalitetskontrol

I en integreret model deltager Enterprise Architecture aktivt ved mindst tre gates. Ved foranalysen vurderer EA, om den foreslåede løsning passer ind i det eksisterende systemlandskab, eller om den skaber teknisk gæld. Ved planlægningsfasen definerer EA de arkitekturprincipper og guardrails, som projektet skal overholde. Og ved testfasen verificerer EA, at den leverede løsning faktisk overholder de fastsatte principper. Det kræver et Architecture Board, et tværfagligt organ med mandat til at godkende eller afvise arkitekturbeslutninger. Uden et Architecture Board ender arkitekturvurderinger som anbefalinger, som projektledere frit kan ignorere, når tidsplanen presser. Et Architecture Board med reelt mandat er forskellen på EA som governance og EA som dokumentation.

AI governance i projektmodellen: compliance fra dag ét

EU AI Act trådte for alvor i kraft den 2. august 2026 for højrisikosystemer og transparenskrav. Det betyder, at ethvert projekt, der involverer AI, skal risikoklassificeres tidligt i forløbet. I en integreret Stage Gate-model sker denne klassificering allerede ved foranalysen. Spørgsmålene er konkrete: anvender projektet AI til beslutninger, der påvirker mennesker? Bruger det persondata til træning? Er systemet omfattet af Annex III i EU AI Act? Hvis svaret er ja, aktiveres en governance-track parallelt med projektplanen. Denne track omfatter dokumentation af datasæt, risikovurdering, test for bias og plan for menneskelig kontrol. Ved at integrere dette i projektmodellen undgår virksomheden den klassiske fejl: at bygge løsningen først og forsøge at gøre den compliant bagefter. Compliance bagefter er altid dyrere og ofte umulig uden grundlæggende ændringer.

Guidelines og guardrails: EA som ramme for AI

Enterprise Architecture leverer de guidelines og guardrails, som AI governance bygger på. Guidelines beskriver den foretrukne tilgang: hvilke dataplatforme bruger vi? Hvilke standarder for datamodellering følger vi? Hvordan dokumenterer vi integrationer? Guardrails er de hårde grænser: ingen AI-model må trænes på data, der ikke er klassificeret. Ingen ny integration må oprettes uden at EA har godkendt den. Ingen tredjeparts-AI-tjeneste må tages i brug uden risikovurdering. Forskellen mellem guidelines og guardrails er afgørende. Guidelines kan fraviges med en begrundelse. Guardrails kan ikke. Når AI governance opererer inden for EA's guardrails, bliver det en del af den daglige drift frem for et separat complianceprojekt, der lever sit eget liv ved siden af organisationen.

Synergien i praksis: et konkret eksempel

En virksomhed ønsker at implementere en AI-baseret løsning til automatiseret kundeservice. I en siloopdelt organisation ville projektet blive startet af forretningen, godkendt af PMO på baggrund af en business case og overleveret til IT til implementering. EA ville måske blive spurgt til råds undervejs, og compliance ville blive kontaktet tæt på lancering. I en integreret model ser forløbet anderledes ud. Ved idéfasen vurderer EA, om løsningen passer ind i det eksisterende systemlandskab, og AI governance klassificerer systemet efter EU AI Act (i dette tilfælde sandsynligvis begrænset risiko med transparenskrav). Ved foranalysen definerer EA datakravene, og governance-teamet verificerer, at de planlagte datasæt kan bruges lovligt. Ved planlægningen fastlægger PMO tidsplan og ressourcer med input fra EA om arkitekturkrav og fra governance om dokumentationskrav. Ved test verificerer alle tre funktioner: PMO at leverancen er komplet, EA at arkitekturprincipperne er overholdt, og governance at dokumentationen er på plads til en eventuel myndighedshenvendelse. Forskellen er ikke flere møder. Forskellen er, at de rigtige spørgsmål stilles på det rigtige tidspunkt, i stedet for at de stilles for sent.

Dataplatformen som fundament

Ingen af de tre discipliner fungerer uden pålidelige data. PMO har brug for data til statusrapportering og ressourcestyring. EA har brug for data til at kortlægge systemlandskabet. AI governance har brug for data til risikovurdering og lineage. En struktureret dataplatform med klar master data, tiered datastruktur og data governance er derfor ikke et separat initiativ. Det er fundamentet, som PMO, EA og AI governance alle hviler på. Uden entydige datakilder kan PMO ikke rapportere retvisende, EA kan ikke vurdere afhængigheder, og AI governance kan ikke dokumentere, hvilke data en model er trænet på.

Organisatorisk placering: hvem ejer hvad?

Den hyppigste fejl er at placere AI governance hos jura alene. Jura kan vurdere lovkrav, men kan ikke vurdere, hvilke data et system trækker på, eller hvilke andre systemer det er koblet til. Det er arkitekturviden. Den bedste AI governance, vi har set, sidder hos Enterprise Architecture med jura som rådgiver. PMO bør ligeledes have en tæt kobling til EA, så projektmodellens gates afspejler arkitekturkrav. Konkret anbefaler vi, at Architecture Board inkluderer en fast repræsentant fra PMO, og at PMO's gate-kriterier inkluderer EA- og governance-godkendelser. Det skaber en integreret styringskæde, hvor ingen beslutning tages i isolation.

Fem trin til at komme i gang

Start med en kortlægning af, hvordan de tre funktioner opererer i dag. Hvor sidder de organisatorisk? Hvem rapporterer til hvem? Hvor er der overlap, og hvor er der huller? Dernæst: etabler en fælles projektmodel med Stage Gates, der inkluderer EA-vurdering og AI-klassificering som obligatoriske elementer. Tredje trin er at oprette eller styrke et Architecture Board med reelt mandat til at sige nej. Fjerde trin er at definere klare guardrails for AI, som er forankret i EA's eksisterende principper. Femte og sidste trin er at sikre, at dataplatformen understøtter alle tre funktioner med entydige kilder og klar lineage. Ingen af trinene kræver et stort program. De kræver, at nogen sætter sig for bordenden og beslutter, at disse discipliner ikke længere opererer i siloer.

Hvornår bør man søge ekstern hjælp?

Mange virksomheder har kompetencerne internt, men mangler kapacitet eller mandat til at drive forandringen. En ekstern rådgiver tilføjer to ting: et blik udefra, der ser de blindzoner, organisationen selv er for tæt på til at opdage, og en uafhængighed, der gør det lettere at stille de ubehagelige spørgsmål. Hos We Lead Projects har vi opbygget PMO-funktioner, etableret Architecture Boards og designet AI governance-rammer for virksomheder i alt fra retail til den offentlige sektor. Vores erfaring er, at den største gevinst ikke ligger i de enkelte funktioner, men i integrationen mellem dem.

Brian P.N. Tofft

Brian P.N. Tofft

Managing Partner, We Lead Projects

Brian har mere end 30 års erfaring med projektledelse og IT-transformationer på tværs af brancher.

Klar til at komme i gang?

Kontakt os og hør hvordan vi kan hjælpe med dit næste projekt.

Kontakt os