IT-kontrakttvister og digitale beviser

En tvist om en IT-leverance er på mange måder en almindelig kontraktsag: Hvad var aftalt, hvad blev leveret, og hvem bærer ansvaret for forskellen? Det særlige er, at både aftalen, leverancen og forløbet ligger i systemer. Kravspecifikationen findes i flere versioner, fejlene er registreret i et ticketsystem, ændringsønskerne er aftalt i mails og møder, og selve løsningen kører måske stadig hos leverandøren.

Det giver gode muligheder for at dokumentere forløbet præcist, men også en risiko for, at de vigtigste data forsvinder eller ændres, mens tvisten udvikler sig. Denne side følger en IT-kontrakttvist fra de første problemer til hovedforhandlingen og peger på de artikler, der går i dybden.

De typiske IT-kontrakttvister

IT-tvister kommer i mange former, og bevistemaet afhænger af typen.

Udviklings- og implementeringsprojekter. Tvisten handler om mangler, forsinkelse og ændringer. Spørgsmålet er ofte, om fejlene skyldes leverandøren, kundens egne ændringsønsker eller uklare krav.

SaaS og drift. Her handler det om oppetid, svartider, servicemål og sikkerhed. De relevante data ligger typisk hos leverandøren, og kunden har kun adgang til det, leverandørens portal viser.

Licenser. Licensaudits og tvister om brug af software ud over aftalen bygger på installationsdata, brugerlister og leverandørens måleværktøjer. Ved open source handler det om, hvilke komponenter der indgår, og om licensvilkårene er overholdt.

Outsourcing og exit. Ved ophør skal data, dokumentation og viden overføres. Tvisten handler ofte om, hvad der skulle udleveres, i hvilket format og hvornår.

AI-leverancer. Ved leverancer med maskinlæring eller sprogmodeller kommer nye spørgsmål til: hvilken model, hvilke data og hvilke resultater blev lovet og leveret.

Databehandling. Når en databehandler har haft et sikkerhedsbrud eller ikke har fulgt instrukserne, er der tvist om ansvar og tab mellem dataansvarlig og databehandler.

Fase 1: Problemerne viser sig

I de fleste IT-projekter er der en periode, hvor problemerne vokser, uden at nogen endnu taler om tvist. Det er her, de vigtigste beviser skabes, og det er her, klienten bedst kan forbedre sin stilling: ved at reklamere skriftligt og præcist, ved at sikre at fejl registreres i det aftalte system og ved at undgå, at væsentlige aftaler kun træffes mundtligt.

Hvis klienten allerede er kommet til advokaten, skal tidspunkterne for reklamationer kunne dokumenteres, og det skal vurderes, om de kom frem til den rigtige modtager.

Reklamation i tide Bevis for, hvornår der blev klaget.
Hvornår er en mail kommet frem? Teknisk og juridisk tidspunkt for modtagelse.
Opsigelse på sms eller mail Gyldighed og bevis.
Kendskabstidspunkt og forældelse Digitale spor, der viser, hvornår klienten vidste besked.

Fase 2: Datakilderne kortlægges

Det første klientmøde i en IT-tvist bør give et kort over, hvor dokumentationen ligger. Typisk drejer det sig om kontrakten og bilagene i alle versioner, projektstyringsværktøjer, ticketsystemer, testmiljøer og testrapporter, versionsstyring af kode, driftslogs og overvågning, mødereferater og mails. Meget af det ligger hos leverandøren eller i fælles værktøjer, som den ene part kan lukke adgangen til.

Den konkrete tjekliste til IT-leverancesager er et godt udgangspunkt, og datakortet kan bruges til at holde styr på, hvem der ejer hvert system, og hvor længe data gemmes.

Tjekliste: IT-leverancesag De spørgsmål og datakilder, der typisk er i spil.
Skabelon: datakort Systemer, ejere og opbevaring på ét ark.
Ticketsystemer som bevis Jira, Zendesk og lignende.
Versionshistorik Hvem ændrede udkastet?
Kalenderen som bevis Møder og deltagere.
AI-mødereferater Transskriptioner og automatiske referater.

Fase 3: Sikring, før adgangen lukkes

IT-tvister har en særlig risiko: Når samarbejdet bryder sammen, lukker den ene part ofte adgangen til fælles systemer, eller abonnementer opsiges. Testmiljøer nedlægges, logs roterer ud efter en fast periode, og løsningen opdateres, så den tilstand, tvisten handler om, ikke længere findes.

Derfor bør sikringen ske tidligt. Det kan være eksport fra ticketsystemet, kopi af repository, skærmoptagelse af fejl i løsningen, sikring af driftslogs og en formel meddelelse til modparten om at bevare data.

Bevarelsespligt og litigation hold Hvornår pligten opstår.
Skabelon: meddelelse om bevarelse af data Meddelelsen til modparten.
Beslutningstræ: sikre nu eller vente Hvad haster, og hvad kan vente?
Beviser i cloud uden for EU Når data ligger hos en udenlandsk udbyder.
Edition af modpartens backup Når den tidligere tilstand kun findes i backup.

Fase 4: Bevistemaerne sagstype for sagstype

Mangler og forsinkelse

I en mangelsag skal det dokumenteres, hvad der var aftalt, hvordan løsningen faktisk fungerede, og hvorfor. Ticketsystemets historik viser fejlenes antal, alvor og behandling, mens versionsstyringen viser, hvad der blev ændret hvornår. Ændringsønsker og deres konsekvenser er ofte det, der afgør ansvaret for forsinkelsen.

Mangler ved IT-leverancer Dokumentation af fejl, forsinkelser og ændringsønsker.
Når klienten er IT-leverandøren Leverandørens egen dokumentation.
ERP-systemets ændringslog Ændringer i forretningssystemer.

SaaS, drift og servicemål

I SaaS-tvister er leverandørens egne målinger ofte det eneste grundlag for oppetidsberegninger, og kunden har sjældent adgang til rådata. Det er derfor værd at overveje kundens egne målinger og logs, og at være præcis med, hvordan servicemålet beregnes.

SaaS-tvister Oppetid, SLA og logdata.
Sådan læser du en logfil Grundbegreber.
Forsikringssager efter cyberangreb Når et nedbrud skyldes et angreb.

Licenser og open source

I licenssager er det centrale, hvad der faktisk er installeret og brugt, og hvordan det er målt. Leverandørens auditværktøjer kan tælle anderledes, end kunden forventer. Ved open source kan en softwarestykliste vise, hvilke komponenter løsningen indeholder.

Licensaudit Tvister om softwarelicenser.
Open source-licensbrud SBOM som bevis.
Ophavsret og software Når tvisten handler om kopiering af kode.

Outsourcing og exit

Exit-tvister drejer sig om leverandørens pligt til at udlevere data og bistå ved overgangen. Formater, fuldstændighed og tidspunkter er de typiske stridspunkter. Det er vigtigt at kunne dokumentere, hvad der faktisk blev modtaget, og om det kunne bruges.

Exit-bistand og dataudlevering Ved ophør af outsourcing.
Koncerner med fælles tenant Udskillelse af Microsoft 365-miljøer.
Tvangsfuldbyrdelse af udlevering af data Når udleveringen ikke sker frivilligt.

AI-leverancer og automatisering

Ved AI-leverancer skal det dokumenteres, hvilken model og hvilken version der blev leveret, hvilke data den er trænet eller tilpasset med, og hvordan resultaterne er målt. Output fra sprogmodeller varierer, så en enkelt test er sjældent nok. Chatbots, der giver kunder løfter, er en beslægtet problemstilling.

AI-leverancer Dokumentation af model, data og output.
Chatbotten lovede kunden noget Chatbotsvar som grundlag for krav.
Edition af AI-historik Modpartens ChatGPT- og Copilot-historik.

Databehandling og sikkerhedsbrud

Når et sikkerhedsbrud hos en databehandler fører til krav, handler sagen om, hvad der skete, hvilke sikkerhedsforanstaltninger der var aftalt og etableret, og hvilket tab der fulgte. Hændelsesrapporter, logs og databehandleraftalens instrukser er de centrale dokumenter.

Databehandlertvister Ansvar mellem dataansvarlig og databehandler.
Erstatning efter persondatabrud Hændelse, årsag og omfang.
Sager hos Datatilsynet Dokumentation fra IT-siden.
Fakturasvindel via hacket mail Når en kompromitteret mailkonto fører til tab.

Udbud, fakturering og overdragelse

IT-kontrakter indgås ofte efter udbud, faktureres via e-faktura og indgår i virksomhedsoverdragelser. Hver af disse situationer har egne datakilder.

Udbudssager Tilbud og kommunikation i udbudsportaler.
Fakturatvister E-fakturaer og regnskabssystemer.
Datarum og garantibrud Virksomhedsoverdragelse.
Digitale signaturer Elektroniske aftaler som bevis.

Fase 5: Forhandling, hastesager og valg af bevisvej

Mange IT-tvister løses ved forhandling, mægling eller voldgift, fordi parterne ønsker fortrolighed eller har brug for at fortsætte samarbejdet. Sikrede data styrker forhandlingspositionen, og en fælles IT-sagkyndig kan være en måde at nå en fælles forståelse af de tekniske fakta.

Er der brug for at stoppe en adfærd hurtigt, fx brug af kode eller data uden ret, kan forbud og påbud komme på tale, og så skal dokumentationen være klar på få dage.

Bevissikring uden retssag Forhandling, forlig og mediation.
Fælles IT-sagkyndig Aftale mellem parterne.
Forbud og påbud IT-beviser i hastesager.
Digitale beviser i voldgift Når parterne selv aftaler processen.
Voldgift: skønsmand udpeget af voldgiftsretten Skøn i voldgiftssager.
Beslutningstræ: bevisvej Erklæring, skøn, edition eller fogedretlig bevissikring.

Fase 6: Retssagen

IT-sager kan behandles ved Sø- og Handelsretten, og det tekniske indhold gør det ekstra vigtigt, at processkrifterne forklarer de tekniske argumenter klart og at bevistemaerne er formuleret, så de kan besvares.

Processkrifter og forberedelse

IT-sager i Sø- og Handelsretten Det særlige ved specialretten.
Stævningen Digitale beviser og bevistemaer.
Processkrifter med tekniske argumenter Teknik forklaret til retten.
Det forberedende retsmøde Planlægning af en IT-tung sag.
Retsafgift og omkostningsrisiko Det økonomiske overblik.

Edition

Den part, der har driftet løsningen, sidder typisk på logs, tickets og kode. Editionsbegæringen skal være konkret om systemer, perioder og formater.

Editionsbegæring set fra IT-siden Hvad begæringen skal indeholde.
Partsedition fra begæring til kendelse Forløbet trin for trin.
Skabelon: opfordring til fremlæggelse af data Opfordringen til modparten.
eDiscovery Når datamængden er stor.

Syn og skøn

Syn og skøn er ofte afgørende i IT-sager, fordi mangler og årsager kræver teknisk vurdering. Skønstemaet skal formuleres, så skønsmanden kan svare på det, og skønsmanden skal have adgang til de relevante systemer.

Syn og skøn i IT-sager Gode og dårlige spørgsmål.
Anmodning om syn og skøn Fra anmodning til udmeldelse.
Skabelon: skønstema Et skønstema i en IT-sag.
Skønsmandens adgang til systemer Adgang til data og miljøer.
Besigtigelsen Skønsforretningen i praksis.
Supplerende skøn og overskøn Når første erklæring ikke er nok.

Hovedforhandlingen

Tidslinjer som bevis Forløbet vist overskueligt.
Digitale beviser i retssalen Skærme og visualiseringer.
Vidneforklaring fra IT-medarbejdere Klientens egne teknikere som vidner.
Krydsforhør af en IT-sagkyndig Forberedelse og spørgsmål.
Afhjemling af en IT-skønserklæring Skønsmanden i retten.

Typiske faldgruber i IT-kontrakttvister

Nogle problemer går igen i IT-sager, uanset om klienten er kunde eller leverandør.

Tilstanden ændrer sig. En løsning, der er i drift, bliver løbende opdateret. Når skønsmanden kommer, er de fejl, sagen handler om, måske rettet, eller nye er kommet til. Det skal derfor dokumenteres, hvilken version der var i drift på de relevante tidspunkter, og om den version stadig kan genskabes, fx fra versionsstyring eller backup.

Data ligger hos modparten. Kunden har sjældent adgang til leverandørens driftslogs, overvågning og interne tickets. Leverandøren har på sin side sjældent adgang til kundens interne kommunikation om, hvordan løsningen blev brugt. Begge dele kan blive relevante, og begge parter bør regne med, at deres egne systemer kan blive omfattet af edition.

Uklare krav. Mange IT-tvister handler i virkeligheden om, hvad der var aftalt. Hvis kravspecifikationen er ændret mange gange, eller hvis vigtige afklaringer er sket i møder uden referat, bliver versionshistorik, mails og chats afgørende for at rekonstruere aftalen.

Store datamængder. Et ticketsystem eller et repository fra et flerårigt projekt kan indeholde meget store mængder data. Det er sjældent nødvendigt at fremlægge det hele. Afgrænsning efter perioder, moduler og søgeord gør materialet håndterbart for både retten og skønsmanden.

Fortrolighed. Kildekode, sikkerhedsopsætning og kundedata kan være følsomme. Udlevering til modparten eller skønsmanden bør ske under aftalte vilkår, og det kan være relevant at overveje lukkede døre.

Søgeord og afgrænsning Aftaler med modparten.
Stikprøver i store datamængder Når ikke alt kan gennemgås.
Sikker deling af store datamængder Med retten og modparten.
Lukkede døre og forretningshemmeligheder Beskyttelse af følsomme oplysninger.

Efter sagen

Når tvisten er afgjort, skal data ofte tilbageleveres eller slettes, og en eventuel overgang til ny leverandør skal gennemføres. Erfaringerne fra sagen kan bruges til at skrive bedre kontrakter om dokumentation, logning og exit næste gang.