Du har allerede viden din AI-agent har brug for

I en virksomhed, der er underlagt regulering, findes der allerede sådanne retningslinjer, ofte i form af god praksis indenfor dokumentstyring. Hvad kendetegner en record? Hvor længe må den opbevares? Hvem må godkende hvad? Hvad betyder ordene på tagsne? 

De fleste virksomheder, der implementerer agenter i produktionen, det vil sige AI, der udfører handlinger frem for at besvare spørgsmål, genopbygger dele af de eksisterende retningslinjer fra bunden under et nyt mærkat frem for at genbruge etablerede styringspraksisser.   

Gartner forudser, at mere end 40% af agentiske AI projekter vil blive aflyst inden udgangen af 2027 på grund af forøgende omkostninger, uklar forretningsværdi og utilstrækkelige risikostyringsforanstaltninger. Omkostninger og forretningsværdi er ikke altid lette at styre, men det er risikostyring derimod. Den sidstnævnte kan være – og ofte er i et reguleret branche – en afgørende factor for, om et pilotprojekt overhovedet får lov til at komme i nærheden af den egentlige drift. 

Problemet er handlingen og de påfølgende konsekvenser af handlingen

I dag omhandler de fleste diskussioner om AI-risici hallucinationer: chatbotten, der opfinder en retssag eller en klausul i en kontrakt. Hallucinationerne er et reelt problem, men det er det forkerte problem at fokusere på i første omgang. En chatbot, der siger noget forkert har produceret en sætning. En agent, der handler på baggrund af noget forkert, har skabt en konsekvens.  

Frank Coyle fra UC Berkley fremhævede dette punkt i et foredrag udgivet af AI Engineer den 23. juli 2026. Han gør sit publikum opmærksom på, at en sprogmodel ikke kan røre ved noget andet end sit eget. Den genererer de mest sandsynlige næste ord, og når den konkluderer, at en opgave skal fuldføres, skriver den ned, hvad den ønsker der skal gøres, og beder den omkringliggende software om at udføre det.  

Der er et afbræk i denne overdragelse: Softwaren har hentet det, som modellen bad om, og der er endnu ikke skrevet noget. Det er i dette afbræk, du griber ind, og det værktøj, du bruger til at gribe ind med, bør ikke være endnu mere AI. Nøglen til overdragelsen er en skriftlig redegørelse for, hvad der gælder i din virksomhed.  

F.eks.: 

• En agent udsteder endnu en refusion på en ordre, der allerede er blevet refunderet, eller sender en udbetaling til kundeservicemedarbejderen i stedet for kunden. 

• En agent rapporterer en ordre som »sandsynligvis afsendt«. Denne præcise status findes dog ikke i jeres retningslinjer. 

De overstående forespørgsler er korrekt formuleret, men de er alligevel forkerte i denne sammenhæng. Ved at tilføje en simpel regel til din AI kan du fange alle disse fejl: »en ordre har højst én refusion«, »en kunde og en kundeservicemedarbejder er ikke det samme« og »en status skal stamme fra en fast liste«. 

To kontroller er nøglen, ikke kun en

Frank Coyle beskriver to kontroller. Den første undersøger, om en anmodning er korrekt udfyldt, på samme vis som et skema er kontrolleret; denne findes ved indgangen. Den anden undersøger om det er sandt; denne findes i hovedbogen, hvor regnskabet føres. I hans tekniske jargon: »Pydantic ved indgangen, ontologi i hovedbogen.« (AI Engineer, 23 July 2026). De første controller er rutine I softwareudvikling. Den anden skal skrives i beskrivelsen af din virksomhed, og det er dén de fleste AI-projekter springer over eller overser.  

Hvordan der ser ud i dine egne dokumenter

• Ét dokument, to destruktionsdatoer
  En agent, der arbejder sig igennem et migreringsbacklog, anvender en opbevaringsregel på et dokument, der allerede har en, uden at systemet går ned. Dokumentet indeholder nu to datoer, hvor det skal destrueres, og ingen kan bevise, hvilken af dem var gældende, så dokumentationen for dets bortskaffelse er ubrugeligt. Ved den næste inspektion betragtes dette ikke som en oprydning, men som en fejl, og fejlen omfatter hele den batch dokumentet tilhører. Én regel, skrevet én gang, fanger alle tilfælde af denne fejl. 

• En godkendelse fra en person, der ikke har bemyndigelse til at give den 
  En agent, der behandler en anmodning om sletning, sender godkendelsen til den person, der senest har redigeret filen, i stedet for til den person, der er angivet som dokumentets ejer. Den regulerede version ugyldiggør sletningsprotokollen for alt, der er godkendt på den måde, og man opdager det først den dag, hvor nogen beder en om at bevise, at sletningen var autoriseret. 

• En status, der ikke findes
  I et kvalitetssystem befinder et dokument sig i en tilstand fra en fastlagt liste: udkast, under gennemgang, godkendt, gældende, erstattet, forældet. En agent der rapporterer et dokument som »afventer endelig godkendelse« har skrevet en fuldstændig rimelig formulering, samt en brudt revisionsspor, fordi den tilstand ikke findes på listen, og ingen i de efterfølgende led ved, hvordan de skal håndteres.  

• To dokumenter der fungerer godt hver for sig – men ikke sammen
  Hvert dokument er godkendt til AI-behandling for sig. Tilsammen identificerer de en person, der skulle have forblevet anonym, eller rekonstruerer en formulering, som ingen af dokumenterne afslører hver for sig. Ingen kontrol, der gennemgår dokumenterne ét ad gangen, vil nogensinde opdage dette. Det an kun en kontrol, der forstår, hvordan dokumenterne hænger sammen. 

Hvad de overnævnte fire tilfælde har til fælles

I hvert tilfælde manglede agenten en oplysning om din virksomhed, som den ikke kunne have kendt til, medmindre nogen havde skrevet den ned. F.eks. hvor mange opbevaringsregler et dokument må indeholde, hvem der regnes som ejer, hvilke tilstande der findes, og hvilke dokumenter der ikke må interagere. De samme fire mønstre dukker op i en banks klagesager og i et forsyningsselskabs hændelse rapporter. To klokkeslæt i én fil, en godkendelse fra den person der skrev den, en tilstand, som ingen har defineret, to dokumenter, der er harmløse hver for sig, men ikke sammen.

Dette er et problem inden for dokumenthåndtering, og dokumenthåndtering er en profession 

AI-branchen har et udtryk for den skriftlige beskrivelse af din virksomhed og hvordan den hænger sammen: en ontologi. Det er en beskrivelse af de enheder, roller, relationer og begrænsninger, der findes inden for en organisation. Charles Cutter udgav i 1876 reglerne for, hvordan et bibliotekskatalog skulle struktureres, og disse regler kan stadig genkendes i de klassifikationssystemer, der anvendes i dag. Reglen om, at én konkret ting får nøjagtigt ét officielt navn, hvor alle stavningsvarianter henviser til netop denne, er blevet overholdt af bibliotekarer siden da.  

Det fremgår allerede af standarderne: ISO 25964, den internationale standard, der regulerer, hvordan ordforråd opbygges og sammenkædes, opregner de typer ordforråd, den dækker, og omfatter klassifikationssystemer til dokumenthåndtering og ontologier. Standarden bag dit arkiveringssystem har formelt placeret AI-branchens nye værktøj i samme familie som dette system. Meget af det, som AI-teams udvikler for første gang, er altså denne professions arbejde under et nyt navn. Det er vigtigt, fordi professionen ikke er svær at finde, og det samme gælder det arbejde, der skal udføres i din egen organisation. 

Hvorfor mere AI ikke kan kontrollere AI’en 

Den naturlige indvending er, at en god prompt eller en model, der er stor nok, udligner denne forskel. Det gør den ikke, og årsagen er strukturel. En AI genererer et svar med en tilknyttet sandsynlighed. En regel er enten sand eller falsk. Uanset hvor sikker modellen bliver, kan man ikke udlede det andet ud fra det første, fordi en kontrol skal være uafhængig af det, den kontrollerer – ellers er det ikke en kontrol. Det er f.eks. derfor, at kvalitetssystemet adskiller den person, der udfører arbejdet, fra den person, der godkender det, og hvorfor korrekturlæseren underskriver på en anden linje. Ingen ville acceptere en batchprotokol, hvor operatøren også har kontrasigneret som kontrollør. Den samme logik gælder for en model, der gennemgår sit eget output, og for en anden model, der gennemgår den første. 

Fem slags regler der udgør hovedparten af arbejdet 

Hvad retningslinjerne tilføjer er en håndfuld relevante regeltyper.  

Kort sagt: Når reglerne er formelt nedskrevet, kan en maskine anvende dem på enhver handling, som en agent foreslår, hver eneste gang. Og når den siger nej, begrunder den hvorfor. 

Et afslag du kan anføre I en afvigelsesrapport 

Den sidste del er vigtigere, end det måske lyder. Når kontrollen afviser en handling, lyder begrundelsen således: »approved-by kræver en person med en godkendelsesrolle, og dette er en systemkonto.« Du kan anføre denne sætning i en afvigelsesrapport, men du kan ikke anføre »modellen havde en sikkerhed på 62 %« i en afvigelsesrapport. 

Hvad retningslinjer ikke kan gøre 

Retningslinjer har naturligvis sine begrænsninger; de omfatter kun det, som nogen har skrevet ned, og de kan ikke vurdere, om et resumé er godt, eller om en oversættelse er tro mod originalen. De håndhæver en forkert regel lige så trofast som en rigtig, og det er netop derfor, den har brug for både en gennemgang og en ansvarlig person, og hvorfor den går i forfald uden nogen af delene. Men det er de samme begrænsninger, som dit kvalitetssystem har, og du har jo haft et sådant i årevis. 

Det meste af din retningslinje findes allerede i dit dokumentsystem og det er uoverskueligt

Gartners beskrivelse af kløften er kontant: Frem til 2026 vil organisationer opgive 60 % af de AI-projekter, der ikke understøttes af AI-klar data, og i sin undersøgelse fra 2024 blandt 248 ledere havde 63 % enten ikke de datapraksisser, som AI kræver, eller vidste ikke, om de havde dem. Hvis dine dokumenter ligger i SharePoint og Microsoft 365, starter du ikke fra bunden; du har en styringsbog, der som regel er halvvejs udarbejdet og sjældent er blevet gennemgået. Brikkerne er der. Dit termregister er listen over ord, som din organisation må arkivere ting under, med tilhørende synonymer og oversættelser. Dine indholdstyper angiver, hvilken type dokument der er tale om, og hvad der skal registreres om det. Dine opbevaringsmærker og følsomhedsmærker knytter politikker til denne klassificering, og når et dokument erklæres for en journalpost, ændrer det fra det øjeblik, hvem der må redigere det, og hvornår det må destrueres. Kort sagt har hver eneste strukturelle del af retningslinjerne sin plads i de fleste Microsoft 365-installationer. 

Det, der mangler, er disciplin

Nogen opretter et begreb til et projekt. Projektet afsluttes, men begrebet forbliver. Senere findes der fire synonymer for den samme forretningsfunktion, og der er ingen regel for, hvilket der skal bruges. Dokumentkategorier oprettes i en bestemt afdelings hjørne og kan ikke bruges andre steder. Etiketter tildeles af den, der lige har husket det. Et menneske læser metadataene, forstår sammenhængen og retter dem diskret. Hvis en agent læser dem og handler ud fra dem, vil vedkommende – fordi agenten ikke har nogen anelse om, hvilket af de fire synonymer der er det rigtige – vælge det, der giver det bedste resultat. 

Hold grundlaget opdateret 

Hjælp AI-agenten ved at lægge grundlaget: fastlæg, hvad der findes, hvad det hedder, og hvilke sammenhænge der er. Skriv reglerne ned. Sørg derefter for at holde dem ajour, i takt med at virksomheden ændrer sig – det er den samme vedligeholdelse, som et bibliotekskatalog altid har haft brug for. Ingen version af agentbaseret AI fjerner dette arbejde. Der er kun valget mellem at gøre det bevidst og senere finde ud af, hvad agenten antog, når det ikke blev gjort. 

Tilsynsmyndigheden har allerede bedt om det 

EU’s AI-lov set fra en operatørs synspunkt 

EU’s AI-lov kræver, at højrisikable AI-systemer forbliver nøjagtige, robuste og sikre gennem hele deres levetid, under effektivt menneskeligt tilsyn og med styring af de data, de anvender (forordning (EU) 2024/1689, artikel 10, 14 og 15). I artikel 75 præciseres det, hvad robusthed betyder i praksis, og der nævnes fejlsikre planer: mekanismer, der gør det muligt for systemet at stoppe sikkert, når der opstår uregelmæssigheder, eller når driften bevæger sig uden for forudbestemte grænser. En fejlsikker plan for en agent er en kontrol, der afviser handlingen. De forudbestemte grænser er dine regler. Loven bruger ikke ordet ontologi, men den kræver, at du viser, at systemet holder sig inden for de grænser, du har fastsat på forhånd, og en probabilistisk komponent kan ikke selv påvise dette. Ikke alle dokumentagenter vil blive betragtet som et højrisikosystem i henhold til loven. Det, som loven betragter som bevis for kontrol, er stadig en nyttig beskrivelse af, hvad en inspektør vil ønske at se. 

Kvalitetssystemet, et niveau længere ned 

Inden for life science kræver principperne for dataintegritet, kendt som »ALCOA«, at en registrering skal være nøjagtig og konsistent. Inden for finans og energi er betegnelserne forskellige, men alle tilsynsmyndigheders regler stiller de samme spørgsmål om en registrering: Er den nøjagtig, og stemmer den overens med det, der faktisk skete? En agent, der angiver en livscyklusstatus, der ikke findes på den godkendte liste, opfylder ingen af disse krav – præcis på den måde, som en inspektør er uddannet til at holde øje med. ISO 15489, standarden for dokumenthåndtering, definerer, hvad en registrering er, og hvilke regler der gælder for den. Du bliver ikke bedt om at opfinde en compliance-model for agenter. Du bliver bedt om at koble agenten til den model, du allerede anvender. 

Hvor skal man begynde 

1. Vælg en agenthandling med konsekvenser. Ikke en chatbot. Noget, der skriver, tildeler en etiket, opretter en post, videresender en godkendelse, sletter. 
2. Skriv ned, hvad der skal være opfyldt, for at handlingen er gyldig. Én opbevaringsregel pr. dokument. Godkenderen har en godkendelsesrolle. Status er en af disse seks. 
3. Find ud af, hvor disse oplysninger allerede findes. Termdatabasen, indholdstyperne, opbevaringspolitikken, kvalitetsmanualen. Oplysningerne findes som regel allerede, men stemmer ofte ikke overens med hinanden. At løse denne uoverensstemmelse udgør størstedelen af værdien, og det er umagen værd, uanset om agenten nogensinde kommer til at udføre en handling. 
4. Foretag kontrollen mellem det, agenten har fundet ud af, og det, den er ved at skrive. Ikke bagefter. En agent, der allerede har slettet filen, er ikke blevet underlagt reglerne.  
5. Sørg for, at der ved hvert afslag angives en begrundelse, og før en logbog. Denne logbog er dit bevismateriale, dit spor til fejlfinding og dit svar på AI-loven – alt samlet ét sted. 
6. Sørg for, at regelbogen har en ansvarlig og en dato for gennemgang. Et ordforråd uden en ansvarlig forfalder. Det er den ældste erkendelse inden for arkiv- og dokumenthåndteringsfaget.

Det kedelige svar er det rigtige 

Branchens nuværende svar på upålidelige agenter er mere AI: en kritiker-model, en dommer-model, et udvalg af modeller. Men at bede et sandsynlighedsbaseret system om at certificere et andet sandsynlighedsbaseret system flytter blot problemet i stedet for at løse det. Det svar, der virker, er at få din »regelbog« på plads. Beslut, hvad der er sandt i din virksomhed, og skriv det ned. Tjek det mod regelbogen, før du handler, og giv nogen opgaven med at holde den opdateret. Hvis det lyder som biblioteksarbejde, er det fordi det er biblioteksarbejde. 

De organisationer, der først får agenter i reguleret produktion, vil ikke være dem med de bedste prompter. Det vil være dem, der allerede behandler deres information som noget, man klassificerer, snarere end noget, man søger i, og som har en person, hvis profession netop er det. 

AI har ikke skabt et nyt styringsproblem, men snarere afsløret et gammelt. Alle organisationer er allerede afhængige af definitioner, klassifikationer, ansvarsområder og regler, der bestemmer, hvilke handlinger der er legitime. De organisationer, der får succes med agenter, vil ikke være dem, der automatiserer hurtigst. Det vil være dem, der omsætter den eksisterende viden til en form, som maskinen kan kontrollere, før den handler. 

The post Sådan gør du din AI-agent mere kontrolleret og kvalitativ appeared first on Strator.

Indledning: Hvad går NIS 2 overordnet ud på? 

Og hvorfor kan du, som arbejder med virksomhedens data, dokumenter og information, bidrage? 

NIS står for Network and Information Systems. NIS 2 er EU’s andet direktiv om cybersikkerhed i net- og informationssystemer. 

Formålet med NIS 2 er grundlæggende at sikre, at virksomheder og organisationer, som samfundet er afhængigt af, er tilstrækkeligt robuste over for cyberangreb, systemnedbrud og andre digitale hændelser. Det omfatter en række sektorer, blandt andet energi, transport, sundhed, finansiel markedsinfrastruktur og digital infrastruktur. 

NIS 2 stiller blandt andet krav til, hvordan de omfattede virksomheder og organisationer skal styre cybersikkerhedsrisici, forebygge og håndtere hændelser, sikre driftskontinuitet og rapportere væsentlige hændelser. Kravene omfatter både tekniske, operationelle og organisatoriske foranstaltninger. 

Hvad siger reglerne – direkte og indirekte – om data? 

I NIS 2-loven defineres et net- og informationssystem. Definitionen består af tre dele: 

a) et elektronisk kommunikationsnet, 

b) anordninger, der ved hjælp af software behandler digitale data, og 

c) de digitale data, der lagres, behandles, fremfindes eller overføres af disse elementer. 

Lovens ordlyd i litra c er: 

“Digitale data, som lagres, behandles, fremfindes eller overføres af elementer i litra a og b med henblik på deres drift, brug, beskyttelse og vedligeholdelse.” 
(Kilde: NIS 2-loven, § 3, nr. 21, litra c – NIS2-loven= LOV nr 434 af 06/05/2025). 

Om net- og informationssystemerne siger NIS 2-loven, at de omfattede virksomheder og organisationer skal træffe passende og forholdsmæssige tekniske, operationelle og organisatoriske foranstaltninger for at styre risiciene for deres sikkerhed. Det omfatter blandt andet håndtering af hændelser, driftskontinuitet, backup og genetablering, leverandørsikkerhed, adgangskontrol og forvaltning af aktiver. 

Og hvad betyder sikkerhed så, når vi ser specifikt på dataene? Her er loven meget direkte. I definitionen af sikkerhed i net- og informationssystemer står der, at systemerne skal kunne modstå begivenheder, der kan være: 

“[…]  til skade for tilgængeligheden, autenticiteten, integriteten eller fortroligheden af lagrede, overførte eller behandlede data […]” 
(Kilde: NIS 2-loven, § 3, nr. 28). 

Det vil sige, at beskyttelsen af data ikke blot er noget, vi udleder af reglerne. Tilgængelighed, autenticitet, integritet og fortrolighed af data er eksplicit en del af det sikkerhedsbegreb, NIS 2 bygger på. 

Så der ligger en klar opgave inden for det informationsfaglige område: at bidrage til at identificere og beskytte de data, der indgår i systemernes drift, brug, beskyttelse og vedligeholdelse. 

Men der er også en mindre direkte – og mindst lige så vigtig – informationsopgave. 

NIS 2 stiller blandt andet krav om håndtering af hændelser, driftskontinuitet, backup og genetablering, krisestyring, leverandørsikkerhed, adgangskontrol og forvaltning af aktiver. For at kunne udføre de opgaver i praksis er virksomheden afhængig af information, hvis betydning ikke nødvendigvis skyldes, at den behandles direkte i de systemer, der understøtter driften, men at den er nødvendig for at kunne drive, beskytte, håndtere hændelser omkring eller genetablere systemerne og de tjenester, de understøtter. 

Det kan fx være drifts- og beredskabsprocedurer, planer for nøddrift og genetablering, oplysninger om system- og leverandørafhængigheder, kontakt- og eskalationslister, oversigter over kritiske aktiver, recovery-prioriteter, konfigurationsoplysninger eller den dokumentation, der fortæller medarbejderne, hvad de skal gøre, når den normale drift ikke længere fungerer. 

Her er det derfor ikke tilstrækkeligt kun at se ned i systemerne og spørge, hvilke data de indeholder. Vi er også nødt til at se rundt om systemerne: på de arbejdsgange, mennesker, leverandører og informationer, der er nødvendige for at holde driften i gang eller bringe den tilbage efter en hændelse. 

Noget af denne information kan vise sig først at være virkelig kritisk, når den normale situation bryder sammen. En beredskabsprocedure, som næsten aldrig bruges i dagligdagen, kan fx være helt afgørende under en hændelse. Det samme kan en opdateret kontaktliste eller dokumentationen for, hvordan en kritisk tjeneste drives manuelt, indtil de normale systemer igen er tilgængelige. 

NIS 2 siger ikke direkte, at virksomheden skal oprette en bestemt kategori, der hedder kritiske data. Men når kravene skal omsættes til praksis, bliver et grundlæggende spørgsmål svært at komme uden om: 

Hvilke data og informationer er virksomheden afhængig af for at kunne opretholde sine kritiske processer og tjenester – både i normal drift og når noget går galt? 

Det er dem, vi i det følgende kalder kritiske data. 

Hvilke informationsspørgsmål rejser NIS 2? 

Når vi oversætter kravene til den praktiske håndtering af data, er der en række spørgsmål, som bliver relevante. Det er ikke en juridisk tjekliste, men en informationsfaglig måde at bryde problemstillingen ned på: 

Kritikalitet: Hvilke data er virksomhedens kritiske processer og tjenester afhængige af – både i normal drift og under en hændelse? 

Afhængigheder og tilgængelighed: Hvor befinder de kritiske data sig, hvilke systemer og leverandører er vi afhængige af for at få adgang til dem, og kan de rette mennesker få fat i dem, når der er brug for dem? 

Fortrolighed, integritet og autenticitet: Er data beskyttet mod uvedkommende adgang og ændringer, og kan vi stole på, at de er komplette, ægte og kommer fra den kilde, vi tror? 

Genetablering: Hvis data eller systemer bliver utilgængelige, kan informationen så genetableres på en måde, så den fortsat kan forstås og anvendes? 

Ansvar, kontrol og dokumentation: Er det klart, hvem der har ansvaret, hvilke krav der gælder for håndteringen af data, og kan virksomheden dokumentere, at de nødvendige kontroller faktisk fungerer? 

I denne første artikel begynder vi med det første spørgsmål: Hvilke data er kritiske – og hvordan finder vi dem? 

Hvordan finder vi de kritiske data? 

Udgangspunktet er virksomhedens drift. Før vi kan identificere de kritiske data, skal vi vide, hvilke processer og tjenester virksomheden er afhængig af at kunne opretholde. 

Her kan vi tage udgangspunkt i de landskaber og analyser, virksomheden forhåbentlig allerede arbejder med. Der kan fx være et proceslandskab, som beskriver de væsentlige forretningsprocesser, og et systemlandskab, som viser, hvilke IT-systemer der understøtter dem. 

Det centrale for vores videre arbejde er, at de kritiske processer og tjenester er identificeret. 

Og her skal vi huske pointen fra før: Det handler ikke kun om de processer, der understøttes af de kritiske systemer. Det handler også om de arbejdsgange, der ligger rundt om systemerne og er nødvendige for at holde driften i gang, beskytte den eller opretholde en nøddrift, hvis de normale systemer ikke fungerer. 

Når de kritiske processer er udpeget – med forretningen som helt central part – kan vi begynde at se på dem med informationsbriller. 

For hver proces kan vi spørge: Hvilke data, dokumenter og øvrige informationer skal være til rådighed, for at processen kan fungere? Og tilsvarende: Hvilken information skal være til rådighed, hvis processen skal gå i nøddrift? 

Det kan man afdække gennem arbejdsgangsanalyser. Man følger den enkelte proces og ser på, hvilken information der kommer ind, hvilken information der anvendes undervejs, hvad der produceres, og hvilke informationer medarbejderne er afhængige af for at kunne udføre arbejdet. 

Resultatet er et billede af de informations- og datagrupper, som virksomhedens kritiske processer og tjenester er afhængige af. Det er disse data, der er virksomhedens kritiske data. 

Hvor befinder de kritiske data sig? 

Når vi har identificeret de informations- og datagrupper, som de kritiske processer er afhængige af, er næste spørgsmål: Hvor befinder de sig? 

Her er virksomhedens IT- eller systemlandskab et oplagt udgangspunkt. Det viser typisk, hvilke systemer virksomheden anvender, hvordan de hænger sammen, og hvilke forretningsområder eller processer de understøtter. 

Set med informationsbriller mangler der imidlertid ofte et lag. Et systemlandskab kan fortælle os, at virksomheden anvender fx SharePoint, et ERP-system, et vedligeholdelsessystem og en række fagsystemer. Det fortæller ikke nødvendigvis, hvilke informationsgrupper der konkret befinder sig i de enkelte systemer. 

Derfor kan man gennemgå systemlandskabet system for system og beskrive, hvilke typer information der opbevares i dem. Under SharePoint står der fx ikke kun SharePoint, men også informationsgrupper som driftsdokumentation, beredskabsplaner, kundeaftaler eller tekniske instruktioner. Det samme gøres for de øvrige systemer og informationsmiljøer. 

Når det er gjort, har vi et informationslandskab: et samlet overblik over virksomhedens informationsgrupper og hvor de befinder sig. 

Først derefter kan vi koble det tilbage til arbejdsgangsanalysen. 

Her har vi allerede identificeret, hvilke data de kritiske processer og tjenester er afhængige af. Nu kan vi bruge informationslandskabet til at finde ud af, hvor disse kritiske data faktisk bor. 

Nu ved vi, hvad der skal beskyttes 

På den måde får vi både identificeret de data, virksomheden er afhængig af, og placeret dem i det landskab, hvor de skal beskyttes, tilgås og eventuelt genetableres. 

Kortlægningen kan samtidig synliggøre afhængigheder, som ellers er lette at overse. Kritiske data kan fx være fordelt på flere systemer, ligge hos en ekstern leverandør eller være afhængige af bestemte integrationer for overhovedet at kunne anvendes. 

Dermed har vi i princippet svaret på, hvad der er kritisk i den NIS 2-sammenhæng, vi undersøger her. 

Men der er en vigtig afgrænsning. En virksomhed kan have anden information, som er forretningskritisk af andre årsager – fx fordi tab af den på længere sigt kan få alvorlige juridiske eller økonomiske konsekvenser. Den bliver ikke nødvendigvis identificeret gennem den analyse, vi foretager her. Vores blik er rettet mod de data, virksomheden er afhængig af for at kunne drive, beskytte og genetablere de processer, systemer og tjenester, der er relevante i NIS 2-sammenhæng. 

Med den afgræsning, har vi skabt et grundlag for at gå videre fra at finde de kritiske data til at beslutte, hvordan de skal håndteres og beskyttes. I næste artikel ser vi på, hvordan vi kan beskrive de kritiske data mere præcist og bruge klassifikation til at omsætte vores viden om dem til konkrete krav til håndtering. 

Vibeke Bugge Kristiansen
Direktør

Tine Weirsøe
Direktør Scandinavian Information Audit

The post NIS 2: Hvilke data skal beskyttes?  appeared first on Strator.

Skal alle dokumenter med over i et nyt system? Ikke nødvendigvis. Denne artikel viser, hvorfor migrering af dokumentation kræver langt mere arbejde end arkivering, og hvordan en fagligt funderet opdeling kan øge kvaliteten, spare ressourcer og skabe mere luft frem mod go-live. 

Vi kan tage udgangspunkt i en case, vi har haft hos Strator; I forbindelse med udskiftningen af et dokumentstyringssystem skulle vi håndtere flere millioner dokumenter i et stærkt reguleret miljø. Omkring 10 procent af dokumentationen skulle videre til aktiv anvendelse i det nye system. Resten skulle fortsat bevares, men ikke bruges i det daglige arbejde, og blev derfor placeret i et arkiv. 

Fordelingen af arbejdsindsatsen var påfaldende. Migreringen af de cirka 10 procent krævede omkring 90 procent af arbejdsindsatsen. Arkiveringen af de resterende 90 procent – cirka tre millioner dokumenter – krævede de sidste 10 procent, og det selv om dokumenterne i arkivprocessen skulle tilføres udvalgte metadata samt retentionstid og organiseres i virtuelle arkivbokse. 

Det var ikke udtryk for, at arkiveringen blev taget let. Forskellen skyldtes, at dokumentation, der skal bruges aktivt i et nyt system, skal tilpasses en ny sammenhæng. Dokumenterne skal passe ind i systemets struktur, metadata skal mappes og eventuelt beriges, og resultatet skal kontrolleres. Information, der fortsat skal bevares, men ikke længere indgå i den daglige anvendelse, kan håndteres langt enklere, fordi den ikke skal tilpasses alle de strukturer og arbejdsgange, som gælder for den aktive dokumentation. 

Eksemplet peger på en central beslutning i en større migrering: Det er ikke nødvendigvis al information, der bør tages med ind i det nye system. Organisationen bør i stedet tage stilling til, hvilken fremtid informationen skal have. Noget skal migreres til fortsat anvendelse, noget skal arkiveres, og noget kan efter en kontrolleret vurdering kasseres. 

Det dyre er at gøre dokumentationen anvendelig i en ny sammenhæng 

De cirka 10 procent af dokumentationen, der skulle ind i det nye system, blev først udvalgt, og derefter skulle de forberedes til en ny måde at blive anvendt på. 

Formålet med at indføre det nye system var at understøtte automatisering af dele af en proces, som ikke tidligere havde været automatiseret. Det krævede flere og uddybende data om de produkter, som dokumenterne omhandlede. Centrale produktoplysninger fandtes allerede i organisationens ERP-system. Opgaven var derfor at skabe en logisk forbindelse mellem dokumenterne og de relevante oplysninger og berige dem under migreringen. 

En del af dokumentationen kunne automatisk matches med oplysningerne fra ERP-systemet. Datakvaliteten og registreringspraksis i det gamle dokumentstyringssystem betød imidlertid, at sammenhængen ikke kunne etableres automatisk for alle dokumenter. Nogle dokumenter krævede derfor en manuel forberedelse, før berigelsen kunne gennemføres kontrolleret under selve migreringen. 

Det var med andre ord ikke alene en øvelse i at flytte eller tilpasse eksisterende metadata fra et felt til et andet. Dokumentationen skulle forbindes med oplysninger fra et andet forretningssystem og bringes op til et niveau, hvor den kunne indgå i nye, automatiserede arbejdsgange. 

De 10 procent var ikke én ensartet dokumentmængde. De bestod af flere grupper af dokumenter, som hver havde deres egne karakteristika, særheder og behov for berigelse. Reglerne for udvælgelse, matching og tilpasning måtte derfor fastlægges særskilt for de forskellige grupper. 

Det forklarer, hvorfor en relativt lille del af den samlede dokumentmængde kunne kræve hovedparten af arbejdsindsatsen. Dokumenterne skulle ikke blot nå frem. De skulle fungere rigtigt i den nye sammenhæng og understøtte det formål, som det nye system var etableret for.  

Det er ét konkret eksempel, men kombinationen er velkendt fra vores arbejde med migreringer: Det nye system skal understøtte en ny eller ændret praksis, data i det eksisterende materiale er ikke nødvendigvis tilstrækkelig til den nye anvendelse, og kun en del af dokumentationen skal fortsat bruges aktivt. 

Faglig indsigt med en høj ”timeløn” 

I denne case er værd at give lidt opmærksomhed til kunden; Anja, en ansat hos vores kunde, sad sammen med os og brugte sin dybe faglige indsigt til at hjælpe os med at være i stand til at skelne mellem den dokumentation, der fortsat skulle anvendes aktivt, og den dokumentation, der alene skulle bevares. 

Tænk, hvor meget hendes timer sparede organisationen af konsulenthonorar til os. Organisationen undgik at bruge ressourcer på at tilpasse, berige, migrere og kontrollere dokumenter, som ikke skulle bruges i det nye system. Hendes reelle “timeløn” i projektet var derfor ganske høj. 

En teknisk analyse kan vise, hvilke dokumenter der findes, hvor store de er, og hvilke metadata de har. Vi eksterne specialister kan handle ud fra den indsigt og forståelse, vi kan tilvejebringe. Men den dybe forretningsforståelse af, hvad dokumenterne bruges til, hvilken dokumentationsværdi de har, og om de fortsat skal indgå i aktive processer, må komme fra dygtige mennesker med faglig indsigt i materialet. 

I denne case havde den indsigt en meget synlig økonomisk værdi. Samtidig gjorde den det muligt at bruge hovedparten af kræfterne på netop den dokumentation, der skulle fungere godt i det nye system. 

Det hele skal håndteres – men ikke på samme måde 

I den konkrete case var der to destinationer for dokumentationen. Den del, der fortsat skulle anvendes aktivt, blev migreret til det nye system. Resten blev arkiveret. Lige i dette eksempel, var der ikke blandt materialet dele, der skulle kasseres. 

I andre sammenhænge kan kontrolleret kassation være en tredje mulighed. Det ændrer ikke ved det grundlæggende princip: Hele informationsmængden skal håndteres, men den behøver ikke at blive håndteret på samme måde. 

Dokumentation, der fortsat skal bruges aktivt, skal fungere i det nye systems struktur og arbejdsprocesser. Den skal kunne findes, forstås og anvendes, og den skal rumme de data, som de nye processer kræver. Derfor kan migreringen indebære både udvælgelse, oprydning, transformation og berigelse. 

Dokumentation, der fortsat skal bevares, men ikke bruges i den daglige drift, har et andet formål. Den skal fortsat kunne genfindes og forstås, og den skal opbevares efter de regler, der gælder for den. Den behøver imidlertid ikke at blive tilpasset alle de funktioner og arbejdsgange, som gælder i det aktive system, så derfor er det som oftest mindre arbejdskrævende. 

Information, der hverken har fortsat anvendelsesværdi eller skal bevares som dokumentation, kan efter en kontrolleret vurdering kasseres. Det kræver stadig en beslutning og en dokumenteret proces. Men det kræver ikke, at informationen først gøres klar til et nyt system. 

Opdelingen er således ikke et valg mellem at tage informationen med eller lade den sejle sin egen sø. Den er en måde at sikre, at hver del af informationsmængden får den behandling, der svarer til dens fremtidige funktion. 

En mindre mængde kan behandles bedre 

Hvis alle de flere millioner dokumenter skulle have været behandlet med samme ambition som den aktive dokumentation, ville opgaven have fået et helt andet omfang. Inden for et fast budget og en fast tidsramme kunne alternativet have været at reducere kvaliteten af behandlingen for at få hele mængden igennem. 

Ved først at skelne mellem den dokumentation, der skulle bruges aktivt, og den dokumentation, der alene skulle bevares, kunne kræfterne koncentreres om den aktive del. Her kunne der arbejdes grundigt med udvælgelse, datakvalitet, berigelse og kontrol, så dokumentationen faktisk kunne understøtte de nye arbejdsgange. 

Adskillelsen efter fremtidig funktion reducerede derfor ikke blot omfanget af migreringen. Den gjorde det realistisk at behandle den vigtigste dokumentation med høj kvalitet og dermed få mere værdi af det nye system. 

Adskillelsen kan også skabe luft frem mod go-live 

Adskillelsen gav rent faktisk samtidigt lidt mere fleksibilitet i projektets tidsplan. 

Projekter kan være under et betydeligt tidspres frem mod go-live, og således også i dette tilfælde. Fordi informationsmængden var adskilt, kunne kræfterne koncentreres om den dokumentation, der skulle være klar til aktiv anvendelse i det nye system fra første dag. 

Arkivering og eventuel kontrolleret kassation af den øvrige information kan i mange tilfælde – som her - gennemføres i et efterfølgende forløb som en del af den planlagte udfasning af det gamle system. Det giver mulighed for at arbejde roligt med den resterende informationsmængde, uden at den belaster den mest kritiske del af projektets tidsplan. 

”Efterfølgende” må dog ikke komme til at betyde ”ubestemt” eller ”aldrig”. Udfasningen skal være planlagt, og der skal være ansvar, ressourcer og en afslutning på arbejdet. Ellers kan det gamle system ende som et spøgelse, der fortsat skal drives og koster, selv om det nye system er taget i brug. 

Det rigtige resultat er ikke nødvendigvis at flytte mest muligt 

Et godt resultat af en migrering er altså ikke nødvendigvis, at så stor en del af det gamle systems indhold som muligt er blevet flyttet ind i det nye. 

Det gode resultat er, at den information, der skal bruges videre, fungerer i sin nye sammenhæng. Den historiske dokumentation, der fortsat skal bevares, er arkiveret forsvarligt. Og information, som der ikke længere er grundlag for at opbevare, bliver håndteret gennem en kontrolleret beslutning. 

Det kræver, at organisationen ser på informationen før migreringen og tager stilling til dens fremtid. Den faglige vurdering koster tid, men casen viser også, hvor meget den kan spare - og hvor stor betydning den kan have for kvaliteten af det nye system. 

Så skal alt virkelig med over i det nye system? Nej. Men det hele skal have en kontrolleret fremtid. 

Vibeke Bugge Kristiansen
Direktør

The post Skal alle dokumenter virkelig med over i det nye system? Hvornår skal dokumenter arkiveres eller migreres? appeared first on Strator.

Regeloperatoren memberOf i Microsoft Entra ID stopper med at blive evalueret efter den 3. november 2026, og fejltilstanden er tavshed. Dynamiske medlemskabsgrupper, dynamiske administrative enheder og automatiske tildelingspolitikker i Entitlement Management, der bruger den, vil hverken give en fejl eller forsvinde. De vil ganske enkelt fastholde deres medlemskab, som det så ud den 3. november, for altid. Det betyder, at medarbejdere, der forlader organisationen, beholder deres adgang, mens nye medarbejdere aldrig får den.

Et nedbrud bliver opdaget på få minutter. En fastfrosset adgangsmodel bliver først opdaget ved en audit.

Her er, hvad du bør gøre inden den 3. november.

Hvad gjorde memberOf egentlig?

Preview-funktionen gjorde det muligt for en dynamisk gruppe at hente medlemmerne fra andre grupper:

user.memberOf -any (group.objectId -in ['<groupObjectId1>', '<groupObjectId2>'])

Det var det tætteste, Entra ID kom på indlejrede grupper, som downstream-tjenester kunne læse. Organisationer brugte funktionen til at flade et gruppehierarki ud til en struktur, som SharePoint, Teams, Conditional Access og gruppebaseret licensering kunne bruge, fordi indlejrede grupper aldrig har fungeret problemfrit med disse tjenester.

Microsofts angivne årsag til at udfase funktionen er skala. Under previewen blev det observeret, at memberOf kunne forsinke behandlingen af dynamisk medlemskab i en hel tenant – ikke kun for de grupper, der brugte funktionen.

Der kan være en alternativ løsning under udvikling, men der er endnu ikke noget nyt på vej ud.

Hvad går i stykker, og hvor mærker du det først?

Det fastfrosne medlemskab forplanter sig til alt det, der afhænger af gruppen:

• Adgang til SharePoint og Teams. Medarbejdere, der forlader organisationen, beholder adgangen til sites og kanaler. Nye medarbejdere får den aldrig.

• Targeting i Conditional Access. Nye medarbejdere falder uden for en politik, som de burde være omfattet af. Din MFA- eller enhedsoverholdelsespolitik holder dermed stille og roligt op med at dække dem.

• Gruppebaseret licensering. Nye medarbejdere får ikke tildelt licenser. Medarbejdere, der forlader organisationen, fortsætter med at optage licenser, som du betaler for.

• Access packages. Automatiske tildelingspolitikker holder op med både at tildele og fjerne adgange, så en tidsbegrænset adgang i stilhed bliver permanent.

• Dynamiske administrative enheder. Det delegerede administrationsscope begynder at afvige fra organisationsstrukturen.

For regulerede organisationer er der et yderligere problem. Hvis jeres procedure for adgangskontrol siger, at medlemskab vedligeholdes automatisk af en attributbaseret regel, og den regel i stilhed er holdt op med at blive evalueret, er der ikke længere overensstemmelse mellem den dokumenterede proces og systemets faktiske tilstand.

Det er en audit finding, og den kan være svær at afgrænse bagefter. I skal kunne dokumentere, hvem der havde adgang til hvad – og hvor længe.

Hvilke dele af din tenant glemmer folk at kontrollere?

Næsten alle kontrollerer dynamiske grupper. Der er to andre steder, hvor memberOf-regler kan gemme sig, og som næsten ingen kontrollerer:

• Dynamiske administrative enheder. De bliver konfigureret én gang af en person på identity-teamet og derefter aldrig rørt igen. De er heller ikke synlige under et almindeligt adgangseftersyn. Når en sådan enhed fryser fast, holder det delegerede administrationsscope op med at følge organisationsstrukturen.

• Automatiske tildelingspolitikker i Entitlement Management. Reglen ligger i politikkens konfiguration af tilladte mål i stedet for på selve gruppeobjektet. Derfor vil en eksport, der kun fokuserer på grupper, overse den fuldstændigt.

Begge dele kræver Microsoft Graph for at kunne enumereres korrekt. Ingen af dem dukker op, hvis du kun søger under Groups i administrationscenteret.

Den detalje, næsten alle overser: Nogle af dine medlemskaber er allerede frosset fast

Her er den opdagelse, der ændrer, hvordan du bør prioritere arbejdet – og den kommer direkte fra de dokumenterede begrænsninger ved preview-funktionen.

memberOf fjernede aldrig medlemmer, når en kildegruppe blev slettet, eller når et medlem blev fjernet fra en kildegruppe. Dokumentationen siger det direkte: Berørte brugere forbliver medlemmer af memberOf-gruppen, indtil reglen ændres.

Hold det op mod udfasningen. Det betyder, at fastfrysningen den 3. november ikke er starten på jeres drift. Hvis en kildegruppe, der refereres til i en af jeres regler, er blevet slettet eller har fået fjernet medlemmer, er noget af jeres adgang allerede forældet i dag – og har været det, lige så længe kildegruppen har været væk eller medlemmet har været fjernet.

Det er derfor, en memberOf-gennemgang bør identificere hvert eneste kildegruppe-ID i hver regel og kontrollere, om gruppen stadig findes.

Et kildegruppe-ID, der ikke kan opløses, er ikke bare et irriterende datakvalitetsproblem. Det er et tegn på adgang, der på et tidspunkt er holdt op med at afspejle virkeligheden.

Og det er præcis den slags, du helst selv vil opdage, frem for at få det påpeget under en audit.

Hvordan beslutter du, hvad du skal gøre med hver regel?

Der er tre ærlige udfald – og et fjerde, som folk helst undgår at sætte navn på.

Omskriv reglen ved hjælp af understøttede operatorer. Hvis kildegrupperne svarer til en reel attribut, såsom afdeling, stillingsbetegnelse, virksomhedsnavn eller en extension attribute, kan du udtrykke reglen direkte ud fra denne attribut.

Det kan være det bedste udfald, og det tvinger ofte organisationen til endelig at tage den samtale om kvaliteten af HR-data, som burde have været taget for længe siden.

Konverter til tildelt medlemskab. Fastfrys medlemskabet bevidst, og administrer det gennem jeres joiner/mover/leaver-proces. Det er kedeligt, auditerbart og ærligt omkring, hvem der ejer listen.

Slet reglen. En betydelig del af grupperne fra preview-perioden viser sig ikke at blive brugt til noget.

Accepter, at nogle grupper har brug for et dynamisk medlemskab. Det er den løsning, folk ofte springer over. Hvis en gruppes medlemskab udelukkende består af alle medlemmerne fra andre grupper, findes der ingen attribut, der kan udtrykke det. Hvis medlemskabet samtidig skal holdes løbende opdateret, er tildelt medlemskab ikke en migration.

Hvordan tester du en omskrivning, før du implementerer den?

Du ønsker både coverage og precision på 100 %, men de fleste migrationsplaner holder kun øje med coverage.

Coverage er andelen af de nuværende medlemmer, som den foreslåede regel stadig inkluderer. Coverage under 100 % betyder, at nogle personer mister adgang, når ændringen implementeres. Det hører du om samme morgen.

Precision er andelen af den population, som den foreslåede regel inkluderer, og som faktisk er medlem i dag. Precision under 100 % betyder, at nogle personer får adgang, når ændringen implementeres.

Ingen rapporterer om det. Og det er præcis derfor, det er den farlige af de to.

En regel med 100 % coverage og 80 % precision ser ud som en problemfri migration på dagen – men bliver til en stille over-tildeling af adgang, som fortsætter for altid.

Da vi udviklede vores eget analyseværktøj, gjorde vi precision til den blokerende tærskel i stedet for coverage. Værktøjet vil ikke foreslå en omskrivning, der udvider adgangen, men det foreslår gerne en, der efterlader dig med en navngiven liste på otte personer, som manuelt skal tilføjes igen.

En kort manuel opgave er bedre end en usynlig udvidelse af rettigheder.

Uanset hvordan du beregner værdierne, bør du validere den foreslåede regel i Entra-portalen, før du implementerer den, og sammenligne medlemskabet før og efter.

En tilgang i 3 trin

Trin 1: Find alle anvendelser.

Eksportér dynamiske grupper, og søg efter memberOf i reglerne. Gør det samme for dynamiske administrative enheder og automatiske tildelingspolitikker i Entitlement Management via Graph.

For hvert fund skal du registrere, hvad der bruger gruppen: sites, teams, Conditional Access-politikker, licenstildelinger, access packages osv.

Migrationsrisikoen ligger i de systemer og funktioner, der bruger gruppen – ikke i selve gruppeobjektet.

Hvis du vil være sikker på, at du får det hele med, og har brug for hjælp, så kontakt os for en gratis vurdering.

Trin 2: Beslut dig for hver gruppe.

Husk den begrænsning, der oprindeligt fik folk til at bruge memberOf: Funktionen kunne ikke kombineres med andre regler eller operatorer.

En omskrivning er derfor sjældent en direkte oversættelse én til én. Det er en mulighed for at udtrykke den oprindelige intention korrekt.

Trin 3: Validér og dokumentér.

Sammenlign medlemskabet før og efter, bekræft, at de downstream-systemer og -funktioner, der bruger grupperne, stadig fungerer korrekt, og dokumentér ændringen.

Under GxP, NIS2 eller DORA er dokumentationen af valideringen selve leverancen.

Læg en buffer ind inden den 3. november. Du ønsker ikke, at den sidste gruppe bliver migreret på den sidste dag.

Arbejder du med memberOf-grupper i et reguleret miljø?

Vi gennemfører en read-only-vurdering af din tenant og giver dig et register, en anbefaling for hver gruppe samt en valideringsplan.

Kontakt os for at høre mere.

Ulrich Bojko
Udviklingschef

 

The post Udfasningen af memberOf i Entra: Dine grupper går ikke i stykker – de fryser fast appeared first on Strator.

Jeg studerede datamatiker, som er lidt ligesom en schweizerkniv inden for IT-branchen. Som en del af mit studie, lærte jeg det grundlæggende inden for næsten alle områder af IT, lige fra programmering til arkitektur til analyse. Jeg besluttede at træde ind på arbejdsmarkedet med dette solide, alsidige grundlag. Jeg startede hos Strator i en rolle, der var en blanding af forretningskonsulent, analytisk konsulent og teknisk konsulent. Med tiden bevægede jeg mig mere over mod den tekniske side. 

Nu får jeg hovedsageligt tekniske opgaver, hvilket jeg er rigtig glad for! Mit første længerevarende projekt var en stor datamigrering, hvor vi skulle udtrække metadataene og tilpasse dem til den organisatoriske omstrukturering, som kunden var i gang med. Vi skulle omorganisere og omdøbe dokumenter, gennemføre migreringen og udarbejde en samlet rapport for at sikre, at alt forløb som planlagt. 

Jeg nød virkelig at lære den virksomhed at kende, som vi arbejdede sammen med. Normalt undersøger vi dataene, deres struktur, den aktuelle situation osv. Vi forsøger at finde ud af, hvad virksomheden har brug for, og hvorfor. Vi får lov til at lave en masse nørdede analyser af dataene og kombinere dem med forretningsudvikling for at danne os et overblik over situationen. Derefter kommer det tekniske aspekt, hvor man udvikler processer, applikationer eller software. Det er rigtig sjovt, fordi man får lov til at være teknisk og nørdet. 

Efter cirka et år var projektet afsluttet, og det var tid til noget nyt. Ulrich besluttede at tage mig under sine vinger og lærte mig alverdens om SharePoint. Jeg brugte næsten hele 2025 på at lære alt, hvad der er at vide om SharePoint, fra en erfaren ekspert på området. Det gav mig nye færdigheder og værktøjer, som jeg kan bruge i mit arbejde som teknisk konsulent 

Det er dejligt at høre, at du har lært så meget af din kollega. Er der meget støtte mellem kollegerne? 

De sjældne gange, hvor vi har en rolig dag, finder vi altid noget andet at lave ved at hjælpe vores kolleger. Det er sådan, vi arbejder proaktivt. Derudover synes jeg også, at vi er gode til at tage hensyn til alles behov og forskelle. Vi er gode til at tage imod folk og imødekomme dem. Hvis nogen har lidt for lidt at lave, har vi heller ingen problemer med at bede dem om at hjælpe til med forskellige ting. Det er bare sådan, vi gør tingene. 

På den måde får vi også et ret klart overblik over de forskellige medarbejderes styrker. Det giver os mulighed for virkelig at udnytte deres kompetencer fuldt ud, hvilket igen øger antallet af tjenester, som Strator kan tilbyde en kunde. Dinah er et godt eksempel på dette. Hun besidder en række specifikke kompetencer og viden om, hvordan man klassificerer data og filer, og hun gør det med en særlig indsigt, som hun har med sig fra sin baggrund. Det førte til udviklingen af Strategic Information Management – Lite som en del af vores Summer Clean-Up-kampagne. Især lige nu kunne folk virkelig have brug for Dinahs specifikke kompetencer. Det bliver mere og mere vigtigt for hver dag, der går, at sikre, at ens datalandskab er ryddeligt og velordnet. 

Oplever I ofte sådanne problemer med uordnede datamiljøer i praksis? 

Det er et af de tilbagevendende problemer, vi støder på i vores arbejde. Vi påtager os ofte datamigrationsprojekter, hvor projektlederen naturligvis ønsker at udnytte den tildelte tid mest effektivt. Men ofte ser vi, at kunderne ønsker at spare tid på migrationen ved at springe den indledende oprydning over. Vi kommer ind i projektet og får til opgave at overføre store datamængder fra A til B, men vi kan ikke gennemføre vores indledende analyse, som den bør, fordi dataene ikke er strukturerede, ikke er klassificerede eller er klassificeret på en inkonsekvent måde. Tidspresset får kunderne til at bede os om at fortsætte med migreringen alligevel, men så mister vi i stedet mere tid på den anden side af migreringen. 

Efter migreringen skal vi sikre os, at alle data er blevet overført korrekt, men hvis det oprindelige datasæt er i fuldstændig uorden, tager det meget længere tid at krydstjekke det hele. Udover tiden bruger det også langt mere af din datakvote, hvis du ikke rydder op i dine data på forhånd. Når vi rydder op, leder vi efter gamle, ubrugte, tomme og/eller beskadigede filer, der optager unødvendig plads. Det er fuldstændig meningsløst at migrere dem, og det er endda til skade for kunden. Når dataene er migreret, ser de måske pæne ud, fordi de ligger i en ny UI, men det er stadig det samme rod. Ved at klassificere dine data kan du faktisk opnå større effektivitet og udnytte nye teknologier til at videreudvikle din arbejdsgang. 

Fra vores side gør et ryddeligt udgangspunkt det lettere at forsikre kunden om, at alt arbejdet rent faktisk er udført korrekt. Hvis vi kan vise kunden konkret, at migreringen er gennemført med en optimal struktur, er der et reelt bevis på, at alt er i orden, overholder kravene, og at intet er gået tabt. Det er ikke umuligt at gennemføre en ustruktureret migrering, men det kræver blot flere ressourcer, fordi alt er mindre strømlinet. Ni ud af ti gange koster det i sidste ende mere tid og penge at springe en oprydning af den gamle struktur over for at spare tid. 

Mit råd til enhver læser vil være: Ryd op i dine data, før du går i gang med en migrering, og hold dem rene også efter migreringen. Gør det selv, lad os gøre det, eller lad en anden gøre det, for dine data fylder hurtigt op, og at have et rent datalandskab sparer dig for en masse tid og penge i det store og hele, selv uden for en migrering. 

Til sidst: Er der noget, du ser frem til hos Strator? 

Jeg ser frem til at få mere erfaring som en del af salgsteamet hos Strator. Jeg glæder mig meget til at hjælpe virksomheden med at nå nye højder og udvide sig, så vi kan arbejde på større projekter i større skala. Jeg vil meget gerne på sigt hjælpe Strator med at ekspandere og lande større projekter fra store kunder. 

The post Strators schweizerkniv: mød Christian – salgs- og teknisk konsulent appeared first on Strator.

I løbet af sommeren 2026 gennemfører Microsoft en række ændringer i SharePoint, der, set hver for sig, ligner rutinemæssig administrativ vedligeholdelse: et nyt flag her, en udfaset godkendelsesmetode der, en justering af, hvordan klassificering interagerer med Copilot. Hver for sig vil ingen af dem skabe opsigt, men samlet set tegner de et billede af en samlet, bevidst ændring i, hvordan Microsoft forventer, at organisationer skal forvalte deres indholdsmiljø.

Skiftet består i, at lifecycle, tilladelser og klassificering bliver forudsætningerne for at kunne anvende kunstig intelligens, snarere end valgfri finjusteringer, der kan håndteres senere. For enhver organisation, der planlægger en implementering af Microsoft 365 Copilot i anden halvdel af året, er det vigtigt at vide, at de ændringer, vi vil gennemgå i denne artikel, ikke er underordnede detaljer, men derimod de nye grundregler. Disse ændringer peger alle i samme retning.

At grundlægge Copilot i pålidelige kilder

Den mest iøjnefaldende af de nye funktioner er Authoritative Sites. Den giver en administrator mulighed for at udpege bestemte SharePoint-websteder som pålidelige, så Microsoft 365 Copilot prioriterer indholdet herfra, når det besvarer spørgsmål i Copilot Chat og Copilot Search. Indstillingen gælder for hvert enkelt websted, kræver en Copilot-licens og er som standard deaktiveret.

Intentionen er god. I en stor tenant skal Copilot basere sine svar på noget, og ikke alt indhold fortjener samme vægt. Den politik, der blev offentliggjort i sidste uge, og det forkastede udkast fra for flere år siden bør ikke have samme autoritet, og Authoritative Sites giver en organisation mulighed for at foretrække de kilder, der har opnået tillid.

Det, som denne funktion ikke gør, er at opbygge tillid på dine vegne. At markere et site som autoritativt er kun en fordel, hvis webstedet rent faktisk er opdateret, præcist og velforvaltet. Hvis du leder Copilot hen til et websted fyldt med forældet, duplikeret eller forkert mærket materiale, vil det, som man kunne forvente, resultere i en assistent, der mangler pålidelige oplysninger. Det er en assistent, der gentager dit dårligste indhold med fornyet selvtillid, nu med dit eget autoritetsstempel. Funktionen forudsætter, at organisationen allerede ved, hvilke af dens websteder der er troværdige. Det gør de fleste ikke, og den antagelse er den røde tråd, der går igennem alt andet.

Ekstern deling bliver som standard underlagt styring

I årevis har deling af indhold med personer uden for organisationen været baseret på en engangskode, der blev sendt via e-mail. Denne mekanisme udfases nu. Fra juli 2026 begynder udfasningen af SharePoints autentificering med engangskoder, og ekstern deling

overgår fuldstændigt til Microsoft Entra B2B, hvilket forventes gennemført inden udgangen af august. Nye eksterne invitationer er allerede tidligere på året overgået til denne model.

I praksis bliver alle eksterne modtagere nu en administreret Entra B2B-gæst i stedet for indehaver af en midlertidig kode. Dette er en klar forbedring af styringen, da ekstern adgang dermed falder ind under de samme kontrolmekanismer som alt andet: betinget adgang, identitetsbeskyttelse og centraliseret gæstestyring. Det er også en deadline. Eksterne brugere, der har benyttet den gamle metode, kan miste adgangen til tidligere delt indhold, og den administrative indstilling, der tidligere styrede denne adfærd, fjernes.

Implikationen er enkel. Det gæsteområde, som mange organisationer aldrig formelt har revideret, er ved at blive et reguleret område, uanset om de er forberedte på det eller ej. Det er tid, der er godt brugt, at gennemgå, hvem der har ekstern adgang, inden overgangen er afsluttet.

Klassificering bliver en grænse, ikke et forslag

Tilladelser beskriver, hvad en bruger har lov til at åbne. De har aldrig i sig selv beskrevet, hvad et AI-system bør undlade at røre ved. Den skelnen trækkes nu.

Gennem Microsoft Purview kan sensitivity labels udelukke indhold fra Copilots grundlag, og håndhævelsen vil være fuldt implementeret inden udgangen af juli. Et dokument, der er klassificeret på et begrænset niveau, kan holdes uden for Copilots rækkevidde, selv for brugere, der har tilladelse til at åbne det direkte. Klassificering er ikke længere blot vejledende metadata, men bliver en håndhævelig grænse, der forhindrer Copilot i at få adgang blot fordi »brugeren havde adgang«, som det var den utilstrækkelige begrundelse før opdateringen.

For regulerede brancher er dette ikke blot en bekvemmelighed; det er forskellen mellem en Copilot-implementering, der kan forsvares, og en, der afslører kontrollerede oplysninger i et genereret svar, fordi tilladelserne tilfældigvis tillod det. Ligesom med autoritative websteder fungerer beskyttelsen kun, hvor mærkningerne allerede findes. En grænse opretholdes kun, hvor nogen har fastlagt den.

Governance bliver en disciplin, man kan se

Det mere underliggende tema bag disse ændringer er, at governance i sig selv behandles som en operationel disciplin snarere end en årlig oprydning. Microsoft samler aktiviteterne i forbindelse med gennemgang af websteder, inaktivitet, ejerskab og attestering i mere overskuelige grænseflader for de ansvarlige, og forbedrer rapporteringen, så administratorer kan identificere overdreven deling og risici ved tilladelser, så man ikke længere behøver at gætte sig frem.

Governance får sine egne arbejdsredskaber, hvilket betyder, at den kan måles, tildeles og håndteres som et løbende arbejde.

Den fælles forudsætning: Styring er adgangsbilletten

Ser man bort fra de enkelte funktioner, er den fælles forudsætning umulig at overse. Hver enkelt funktion læser oplysninger, som forventes allerede at findes på webstedet, og handler

ud fra dem. Autoritative websteder er afhængige af at vide, hvilke websteder der er troværdige. Purviews beskyttelse bygger på, at der er tildelt mærker. Kontrol af ejerskab og attestering forudsætter, at der findes en gyldig ejer, der kan kontaktes. Ingen af disse kontrolmekanismer skaber de underliggende oplysninger; de bruger dem alle sammen.

Hvilket rejser spørgsmålet: hvor kommer disse oplysninger fra?

Den side af life cycle, som ingen styrer

Microsoft styrer midten af et websteds Life cycle og dets afslutning. Registrering af inaktivitet, ejerskabsgennemgange, attestering og arkivering er alle kontroller, der finder sted under normal drift og ved udløb af levetiden. De forudsætter, at et websted allerede eksisterer, allerede har en ejer, allerede har en klassificering og en fornuftig tilladelsesmodel. De bygger på metadata, som nogen på et tidligere tidspunkt forventedes at have indført.

Der er næsten ingen styring af begyndelsen, og det er netop i begyndelsen, at resultatet afgøres. Et websted, der oprettes uden en klar ejer, efterlader attesteringspolitikken uden nogen at underrette. Et websted, der oprettes uden en følsomhedsmærkning, giver Purview-grænsen intet at håndhæve. Et websted, der oprettes med brede, arvede tilladelser, bliver præcis det, som rapporten om overdreven deling senere vil omtale. Den kostbare afhjælpning, der udgør hovedparten af de fleste styringsprogrammer, er næsten udelukkende den akkumulerede pris for websteder, der aldrig blev oprettet korrekt fra starten.Det er netop dette hul, som Strators eksperter er trænet til at lukke.

Microsofts værktøjer er kun så pålidelige som de oplysninger, der allerede er registreret på webstedet. Arbejdet med at sikre, at disse oplysninger findes fra første øjeblik, og at reparere dem, hvor de mangler, er en separat disciplin i forhold til de kontroller, der senere afhænger af dem.

To halvdele af den samme livscyklus

Strators tilgang og Microsofts native life cycle er ikke alternativer til hinanden. De regulerer forskellige halvdele af den samme livscyklus, og den del, der omhandler klargøring, er en forudsætning for, at den del, der omhandler stabil drift, kan fungere.

Forholdet er direkte på alle punkter. »Authoritative Sites« bliver troværdigt, når webstederne allerede er klassificeret efter niveau, fordi denne klassificering udgør den naturlige udvælgelse af kilder, der har opnået Copilot-prioritet. Purviews klassificeringsgrænse bliver legitim, når mærkater tildeles ved oprettelsen i stedet for at blive eftermonteret under pres.

Ejerskabs- og attestationsgennemgange bliver meningsfulde, når der fra starten findes gyldige ejere, så der ikke er nogen forsømte websteder, der kan forsinke gennemgangen. Og rapporter om overdreven deling har mindre at finde, når webstederne som standard tildeles adgang med mindst mulig privilegier. I alle fald arver den indbyggede kontrol et fundament, som den ikke selv har skullet opbygge.

Hvor en Copilot-implementering egentlig begynder

Erfaringerne fra sommerens ændringer viser, at en Copilot-implementering ikke starter med en licens. Den starter i det underliggende indholdsmiljø, i den ikke særlig glamourøse disciplin omkring ejerskab, livscyklus og klassificering, som hver eneste af disse nye funktioner i al stilhed er afhængig af. De organisationer, der vil indføre Copilot med tillid, er dem, der først har udført dette arbejde og betragtet det som et fundament snarere end en oprydning.

Microsoft styrer midten og slutningen af et websteds levetid. Strator styrer begyndelsen. Og det er begyndelsen, der afgør, om man kan stole på alt det, der følger efter.

 

The post Først styring, så aktiverer man AI’en appeared first on Strator.

I denne nue serie af blogindlæg vil vi præsentere de mennesker, der gør Strator til det, det er. I dette første interview introducerer vi Ulrich Bojko, vores udviklingschef, og spørger ind til hans oplevelser hos Strator.  Her deler han sine tanker om betydningen af eksperter, afhængighed af AI og digital suvrænitet 

Siden 2025 har Ulrich været en central del af Strator. På trods af dette relativt unge samarbejde har Ulrich vist sig at være en værdifuld del af teamet som en mand med mange ideer, en grundig arbejdsmoral og masser af sjove vittigheder. Som SharePoint-ekspert og entusiast inden for forretningsudvikling, hjælper Ulrich Strator med at nå lidt længere hver dag ved at udvikle nye værktøjer, gennemføre omfattende migreringer og finde på nye måder, hvorpå Strator kan hjælpe virksomheder med at omdanne deres information til en konkurrencemæssig fordel. 

Hvordan startede du hos Strator 

Min karriere hos Strator begyndte som ekstern konsulent. Jeg er SharePoint-ekspert og har arbejdet med både SharePoint Online og on-premises siden 2008. Jeg plejer at fortælle folk, at jeg stort set kan få SharePoint til at gøre alt, hvad de ønsker. Jeg har udviklet en lang række forskellige løsninger, lige fra kontraktstyring og QMS systemer til extranetter og kundeportaler. Nogle af dem var fuldstændig skræddersyede, men på det seneste har de været baseret på SharePoint-funktionaliteter. 

Det endte i hvert fald med, at jeg begyndte som ekstern konsulent for Strator, fordi kunderne spurgte dem: »Nu hvor I har flyttet alle vores data over til SharePoint, kan I så hjælpe os med at udnytte denne SharePoint-platform til andre formål?« Det er selvfølgelig et helt andet speciale, og det var her, jeg kom ind i billedet, og jeg forelskede mig i Strator og de mennesker, der arbejder der. 

Da jeg første så Strator, slog det mig, at det nok var det mest kedelige firma, jeg nogensidne var blevet inviteret til. Forstå mig ret: disse bibliotekar-nørder, der snakkede om klassifikationsmodeller og V-modeller og validering, og alle disse vanvittige forkortelser som EQ, IQ, PQ, OQ og hvad ved jeg. Jeg tænkte: »Hvordan kan man ikke bare dø lidt indeni hver dag af at arbejde med det her? Det her er jo et helt nyt niveau af nørderi.« 

Men da jeg først for alvor satte mig ind i det, indså jeg, at det slet ikke var så kedeligt. I det øjeblik, hvor man skal flytte 3 eller 4 millioner filer uden at miste en eneste af dem, samtidig med at man har det hele under kontrol og kan bevise, at man har gjort alting korrekt, begynder det at blive sjovt. Jeg udvikler ikke kun tekniske løsninger, men jeg roder også rundt i de enorme datamængder. 

Du er i øjeblikket udviklingschef. Hvad indebærer det? 

Jeg har altid været glad for forretningsudvikling, selvom jeg var freelancer i 10–12 år. Hvis jeg så en mulighed, et problem eller et behov hos en virksomhed, som jeg ikke selv kunne løse, har jeg altid sat pris på at være den, der havde det rette netværk til at gøre noget ved det. Jeg elsker også at tale med mange forskellige virksomheder, ikke kun kunder. 

Når det gælder forretningsudvikling, elsker jeg at udvikle ideer til konkrete produkter eller tilbud, som en virksomhed kan levere ud fra teamets kompetencer. Jeg nyder simpelthen at se, hvordan vi kan pakke det sammen, sælge det og opbygge et netværk af kunder, leverandører og partnere. Det udgør omkring 50 % af mit arbejde, mens de resterende 50 % går med at løse kundernes SharePoint-problemer eller udvikle løsninger til SharePoint. 

Jeg følger også europæisk politik ret tæt som en del af mit arbejde med forretningsudvikling. Jeg kan godt lide at se muligheder i politikken og udpege dem til gavn for vores virksomhed eller vores kunder. 

Mange politikere taler for eksempel om digital suverænitet i øjeblikket, og det er noget, jeg har talt om i de sidste 20 år. Nu, med skiftet i det politiske klima i USA, er nødvedigheden for digital suvrænitet endelig kommet på folks radar. Hver eneste samtale mellem en leverandør og en institution i den offentlige sektor, en kommune, et ministerium, en regering eller hvad det nu måtte være, vil have digital suverænitet som det første punkt på dagsordenen. 

Det er heldigt, at jeg elsker at rådgive kunder om, hvordan de opnår digital suverænitet: ikke ved at købe en licens, men ved at tilpasse visse dueligheder. Især når der er så mange misforståelser om digital suverænitet forårsaget af det såkaldte »sovereignty washing«, hvor virksomheder markedsfører deres produkt som den magiske knap til at blive suveræn. Folk kan godt lide at føre kortet igennem I troen om at de bliver digitale suveræne fem minutter senere. Men pludselig når din nye suverænitetsløsning en vis grænse, hvor du bliver nødt til at købe en opgradering, eller prisen stiger simpelthen. Før du ved af det, sidder du fast i en leverandørbinding og er ikke længere digitalt suveræn. Det kan ske både med open source-løsninger og, som eksempel, en Microsoft-løsning. At sikre, at folk indser det, er også det, jeg ønsker at gøre ved at opbygge et netværk. 

Du ser virkelig ud til at nyde at vejlede og rådgive som en del af forretningsudviklingen. 

Jeg kan rigtig godt lide at have den rådgivende rolle. I disse tider medfører det dog sine egne udfordringer, da AI ofte bruges som en slags rådgiver. Det er ret risikabelt, fordi den er meget overbevisende i sin måde at lede alle hen imod den samme »one-stop-shop«-løsning, da de store modeller er baseret på amerikansk tankegang. Man kan godt få en europæisk AI, men uanset hvad vil den være baseret på en eller anden model, der styrer dens svar. Hvis folk ønsker reel viden, baseret på mange års erfaring, har de stadig brug for en person, der giver dem personlig rådgivning. Jeg elsker at gøre det, fordi rådgivning aldrig er en »one-size-fits-all«-situation. Jeg elsker at sætte mig ind i en virksomhed og forstå dens processer. Al den forretningsudvikling, både for Strator og for en kunde, er noget, jeg virkelig nyder. Det giver mig mulighed for at bruge min tekniske viden og mine kommunikationsevner. Det er virkelig der, hvor jeg føler mig mest hjemme – mellem teknologien og bestyrelseslokalet. 

Er denne overdrevne afhængighed af AI noget, du ofte støder på? 

Det og afhængigheden af licenser for at få alt på plads i stedet for at stole på faktisk kompetence eller bestemte strukturer. AI er et ekstremt kraftfuldt værktøj, men det er kun et værktøj. Det fungerer ikke uden de rette forberedelser. 

Folk vil ikke fokusere på de kedelige dele, som f.eks. først at få orden på deres data. Den manglende solide grundlag er grunden til, at statistikker viser, at mellem 70 og 95 % af AI-implementeringer eller AI-projekter faktisk ikke leverer den værdi, man havde forventet. Folk er holdt op med at stole på specialister og eksperter på grund af al den tomme markedsføringssnak, og fordi de ikke har tid til at gå i dybden. Derudover vil AI altid svare på den måde, den tror, at den, der stiller spørgsmålet, ønsker at få svaret, og det er derfor, den ikke kan have samme værdi som en ekspert. 

Det er også et råd, jeg gerne vil give læserne: Tænk langsomt. AI er også en boble, og det er vigtigt at være klar over, at den kan briste. Virksomheder kan gå konkurs, og priserne på AI-tjenester kan stige drastisk fra den ene dag til den anden. Hvis man bruger AI uden at tænke for meget over det, risikerer man i sidste ende at begynde at bruge AI i stedet for at tænke selv. Hvad gør man så, når boblen brister? 

Vær meget, meget forsigtig, når du erstatter mennesker med AI. Det er et praktisk værktøj, der ikke har nogen kritisk sans, det ser ikke ud over de parametre, du giver det, og det er måske ikke så pålideligt, som du tror. Det kan være den største trussel mod din digitale suverænitet, du kan have, for hvis det pludselig holder op med at fungere eller giver dig forkerte svar, mens din virksomhed er afhængig af det, hvad gør du så? 

Kort sagt: tænk langsomt, opbyg en arbejdsgang i stedet for udelukkende at stole på AI, og hold fast i de meget værdifulde menneskelige værdier og kompetencer i dit team i denne AI-alder. 

Til sidst: Er der et projekt i den (nærmeste) fremtid, som du ser frem til? 

Jo, vi har udviklet nogle små værktøjer til kunder, der skal styrke deres digitale suverænitet ved at hjælpe dem med at styre deres SharePoint-websteder. Jeg har kaldt dem vores »Blueprints«, og jeg glæder mig rigtig meget til at se dem blive en realitet. Jeg har arbejdet på en scanning, som vi vil bruge til vores Strategic Information Assessment – Lite, og jeg vil snart fortælle mere om noget, jeg har kaldt »Site Lifecycle Governance« som en del af disse Blueprints. Vi arbejder stadig på Blueprints, men vi vil offentliggøre flere nyheder om dem efterhånden som tiden går. 

The post Mellem teknikken og bestyrelseslokalet: Mød Ulrich Bojko – udviklingschef  appeared first on Strator.

Denne skelnen er vigtigere nu end nogensinde før, fordi de strategiske indsatser er reelle, og markedsføringen omkring dem er højlydt. To nylige og omfattende undersøgelser hjælper med at skære igennem støjen: Digitaliseringsstyrelsens rapport fra december 2025 om open source i den offentlige sektor og en international undersøgelse af seksten digitalt modne lande, som Digitaliseringsstyrelsen bestilte året før. Læst i sammenhæng peger de på den samme ubehagelige men nyttige konklusion. Digital suverænitet er en formåen, og formåen skal opbygges. 

Suverænitet er ikke et produkt du kan købe 

Det er fristende at tro, at en bestemt type platform afgør spørgsmålet. Det gør den ikke. Man kan være reelt uafhængig på en proprietær platform, hvis man har en god styring, og fuldstændig fanget i open source, hvis man ikke har det. Mærket på emballagen betyder meget lidt. Organisationen bag den afgør næsten alt. 

De store udbydere er selv et godt eksempel på dette. I løbet af det seneste år har Microsoft færdiggjort sin EU Data Boundary og indført suverænitetsløsninger såsom krypteringsnøgler, der opbevares hos kunden, adgangskontrol baseret i Europa og lokal implementering af centrale arbejdsbelastninger – alt sammen med direkte fokus på suverænitetshensyn. Det er betydelige investeringer, og de gør det muligt at opnå digital suverænitet på en hyperscale-kommerciel cloud på en måde, der ikke var mulig for blot få år siden. Samtidig er der stadig uafklarede spørgsmål, såsom udenlandsk lovgivnings rækkevidde over data, der fysisk er lagret i Europa, hvilket ingen indkøbsbeslutning i sig selv fuldt ud kan fjerne. Læren er ikke, at én udbyder er sikker, og en anden ikke er det. Læren er, at uanset hvad man vælger, overgår ansvaret for at forstå, hvad man besidder, hvor det befinder sig, og hvordan man ville afhænde det, hvis det blev nødvendigt, ikke til leverandøren. Det forbliver hos dig. 

Så det egentlige spørgsmål er aldrig »hvilken platform giver os digital suverænitet«. Det er »forstår vi vores konfiguration, ejer vi vores data, kender vi vores kontrakter, og har vi en økonomisk bæredygtig måde at skifte kurs på«. Det er organisatoriske egenskaber, ikke produktegenskaber. 

Kontrol og ansvar er én og samme beslutning 

Digitaliseringsstyrelsens rapport fra 2025 taler klart om den handel, som ingen bryder sig om at nævne. Når du får større kontrol over din teknologi, påtager du dig også et større ansvar: licensbetingelser, sikkerhedsopdateringer, support, maintenance og ganske enkelt at vide, hvad du arbejder med. Kontrol er ikke en præmie, man modtager. Det er en arbejdsbyrde, man påtager sig. Rapporten undgår omhyggeligt at hævde, at mere åbenhed altid er bedre; den siger tværtimod det modsatte. Træf valg ud fra den værdi, de tilfører, og vær ærlig om, hvorvidt du kan gennemføre det, du har valgt. 

Danmark oprettede et særligt open source-kontor til sundhedssektoren. Selvom det var teknisk højt anset, gik det alligevel i opløsning. Ikke på grund af kodens kvalitet, men på grund af manglende organisatorisk og økonomisk opbakning. Teknisk ekspertise er ikke i sig selv nok til at sikre vedvarende operationel opbakning. Det gør finansiering, ejerskab og lederskab derimod. Især lederskab. Det samme mønster viser sig omvendt, hvor suverænitet lykkes. Den opretholdes af en organisation med et lederskab, der har besluttet at afsætte ressourcer til den, ikke af en licens, der tilfældigvis tillod det. 

Derfor kæmper de mindste organisationer mest, og hvorfor svaret sjældent er en heroisk genopbygning internt. Duelighed er krævende netop fordi det er rigtigt arbejde, og at lade som om en platform fjerner det arbejde er hvordan afhængighed stille og roligt hober sig op. 

Forudsætningerne er det sted, hvor suveræniteten egentlig opbygges 

Hvis digital suverænitet er en duelighed, bliver det praktiske spørgsmål, hvad denne duelighed består af. Digitaliseringsstyrelsens rapport, der bygger på erfaringer fra offentlige myndigheder i Danmark og i udlandet, opstiller en klar og fordelsagtigt neutral leverandørliste over forudsætninger. Disse forudsætninger gælder i lige så høj grad for proprietær software som for open source. 

Den første forudsætning er organisation og ledelse. Nogen skal stå bag beslutningen, formulere begrundelsen for den og investere i den kompetence, der skal til for at gennemføre den, uanset om denne kompetence opbygges internt eller købes. Den anden er en bevidst beslutning om support og maintenance. Der er behov for det, uanset om softwaren er open source eller ej. Al software har brug for support og maintenance, og det ville være en fejl at lade den stå uden ejerskab. Den tredje forudsætning er evnen til at vurdere sikkerhed og modenhed, til at bedømme, om der står et aktivt fællesskab eller en kompetent leverandør bag en komponent, i stedet for at antage, at en licens garanterer det. Den fjerde forudsætning er et reelt overblik over licenser, kontrakter og data; at vide, hvilke vilkår der binder dig, hvor dine oplysninger befinder sig, og hvad dine aftaler rent faktisk siger. Det femte punkt er open standards og integration, så systemerne kan kommunikere med hinanden, og – hvad der er afgørende – så man senere kan skifte leverandør uden at skulle afmontere det hele. Det sidste punkt er en honest lifetime economics, hvor man sammenligner en løsnings samlede omkostninger i stedet for den angivne pris, fordi værdien af at kunne skifte aldrig fremgår af en faktura. 

Ingen af disse forudsætninger er tekniske kneb. De er alle discipliner. Tilsammen udgør de det, som digital suverænitet reelt består af, og det opmuntrende er, at de kan udvikles bevidst. 

Organisationer behøver ikke at stå alene  

Organisationer behøver ikke at erhverve evnen til at udøve digital suverænitet på selvstændig vis, og de mest udviklede lande har indset dette. Det gennemgående mønster i den internationale undersøgelse er fremkomsten af fælles forvaltning: neutrale organisationer, der har denne formåen på vegne af mange. I Danmark giver OS2-fællesskabet kommunerne mulighed for at samle midler og kompetencer med fælles løsninger, ud fra princippet om, at de, der er afhængige af noget, bidrager til at opretholde det og bevarer muligheden for at skifte leverandør. Estland og Finland gik så langt som til at oprette en fælles institution med personale og et budget, udelukkende med det formål at forvalte den software, de deler. Italien har oprettet et statsligt kontor til at vejlede og støtte indførelsen af open source, Tyskland har etableret både et offentligt organ til at udvikle fælles løsninger og et agentur til at finansiere vedligeholdelsen af kritisk open source, og Den Europæiske Union er i færd med at sammensætte fælles byggesten, som flere lande kan trække på. 

Det afgørende er ikke, hvilken model der vinder, men, at hver enkelt af dem betragter duelighed som noget, der skal finansieres, bemandes og deles, snarere end noget, der tages for givet. Digital suverænitet i stor skala er lige så meget en kollektiv disciplin som en individuel. 

Digital suverænitet er en ledelsesmæssig holdning 

Alt dette fører tilbage til ét enkelt punkt, og det er et punkt, som CTO’en og CIO’en skal tage ansvaret for. Ledelsen, nærmere bestemt CIO’en og/eller CTO’en, er dem, der skal træffe beslutninger om digital suverænitet. Det er vigtigt, at de gør dette allerede under selve indkøbsprocessen. Datalokalisering, mulighed for at skifte leverandør, open standards og klarhed omkring kontrakter bør ikke være eftertanker, der først kommer frem, når en platform allerede er valgt. De hører som standard til kravene, der gælder for alle leverandører, uanset hvem de er. Behandlet på den måde bliver digital suverænitet beslutningen om at tage ansvar for sin egen infrastruktur, at vide, hvad man kører og hvorfor, samt bevidst at holde sine muligheder åbne. 

De mest holdbare eksempler er governed, ikke improviseret. Aarhus blev for eksempel ikke mere digitalt uafhængigt ved blot at skifte til et andet produkt. Byen fastlagde en retning over mange år – fra et krav om at overveje alternativer, over en handlingsplan og en digital strategi, til afsatte budgetmidler med henblik på at udvide udvalget af leverandører. Den røde tråd er ikke en teknologi. Det er vedvarende, værdidrevet governance og en afvisning af at lade andre bestemme tempoet som udgangspunkt. Det langvarige princip bag det er værd at huske: Vælg den bedste og mest økonomiske løsning uanset softwaretype. Disse løsninger skal vælges af en organisation, der forstår, hvad den vælger. 

Det er netop denne formåen, vi opbygger hos Strator. Platformen er jeres uanset om den er kommerciel eller open source, i skyen eller on-premises. Det egentlige spørgsmål er, om I kan styre den, og om I kan forlade den, hvis I nogensinde bliver nødt til det. Digital suverænitet er ikke blot en sætning i kontrakten; det er bevidstheden om, at organisationen kender sin situation og har evnen til at migrere, hvis den vælger det.  

The post Digital suverænitet er ikke en licens. Det er en formåen. appeared first on Strator.

The post Strators ekspertise inden for SMART-migration appeared first on Strator.

Planlægning slår held – gør klar til sommerens oprydning

Når sommeren nærmer sig, vil mange virksomheder opleve, at kontorerne tømmes, efterhånden som medarbejderne tager på ferie. Det gør sommeren til det perfekte tidspunkt til at rydde op i dit digitale informationsmiljø uden at bekymre dig om at forstyrre den normale arbejdsgang på dine SharePoint- eller FileShare-miljøer. Det er dog bedst ikke at foretage en sådan oprydning uden de rette forberedelser. Derfor har Strator besluttet at lancere en særlig servicepakke, der er skræddersyet til netop dette formål.

 

Med en Strategic Information Assessment Lite kan du tage et nemt første skridt mod at skabe grundlag for at forbedre datakvalitet og klassificering på en hurtig og nyttig måde. Klassificering af data understøtter fortrolighed, integritet og tilgængelighed. Samtidig skaber den et solidt fundament for organisationens informationsstruktur. For at klassificere effektivt er det dog nødvendigt først at forstå den nuværende situation.

Læs mere om strategiske informationsvurderinger

Hvad du får ud af Strategic Information Assessment Lite

• Et overblik over jeres informationslandskab
• En samlet vurdering af din datakvalitet
• Den aktuelle status for dine dokumenters overholdelse af reglerne
• Et første forslag til et klassificeringssystem til organisering af dine data
• Muligheder for at reducere dataaffald

Krav

• Platform: FileShare og SharePoint-websteder
• Omfang: Dokumentation fra op til 5 procesområder (HR, økonomi osv.) og op til 1 million filer
• Din deltagelse: 1 opstartsmøde, 1 afklaringsmøde, 1 afslutningsmøde

 

Pris: 50.000 DKK

Kontakt os for at få mere at vide – helt uforpligtende

Kontakt Os

The post Gør dig klar til sommerrengøringen appeared first on Strator.