9 Anbefalinger og tiltak

Forstørr bilde

For å svare opp til ekspertgruppens mandat og gjøre problemstillingene knyttet til datadeling så konkrete som mulig, har ekspertgruppen som tidligere vist definert et sett med scenarier, som kan illustrere noen typiske situasjoner og problemstillinger. Scenariene gjør det også mulig å skissere hvordan de aktuelle problemstillingene kan håndteres og løses. Få av spørsmålene lar seg løse med fasiter, men scenariene gjør det mulig å konkretisere spørsmål og temaer det er nyttig å tenkegjennom i ulike situasjoner og for ulike virksomheter.

Som beskrevet i kapittel 6 er det gruppens generelle anbefaling at deling av data reguleres gjennom avtaler. Det er også vanlig praksis. Form og innhold av slike avtaler varierer ganske mye, fra enkle avtaler til lange og kompliserte avtaleverk. Deling av data til tjenesteleverandører som tilbyr tjenester på nett, reguleres ofte gjennom standardavtalene til tjenesteleverandørene. Kjøper av tjenesten må akseptere vilkårene for å få tilgang til tjenesten. For små virksomheter – som for forbrukere – kan det være vanskelig å komme i en situasjon der det er mulig å forhandle om slike vilkår. Bransjenormer eller Codes of Conduct kan spille en viktig rolle for å få til mer balanserte avtalevilkår for små virksomheter. Anbefalingene i det følgende baserer seg på forutsetningen om at det er mulig å forhandle om vilkårene. Felles anbefalinger for alle scenariene er tatt opp under pkt. 9.1, mens spesielle forhold for de enkelte scenariene diskuteres under hvert scenario.

9.1 Felles anbefalinger

Som en del av forberedelsen til å bli en dataleverandør eller -mottaker, anbefales det at man gjør en evaluering av sin egen virksomhet for å finne nåsituasjon på modenhet i virksomheten rundt behandling av data. En slik vurdering bør være bred nok til at virksomheten får oversikt over behovet for og fordelene med å dele eller motta data, samt kostnadene og risiko forbundet med deling. Kostnader kan være både relatert til innhenting, prosessering, standardisering med mer, i tillegg til operasjonell risiko, som datasikkerhet og dataenes betydning for drift eller produksjon. Dette kan gjøres av virksomheten selv eller en kan få bistand av profesjonelle leverandører på dette området.

Digitaliseringsdirektoratet har lansert en veileder for hvordan man kan gå frem for å skaffe seg oversikt over hvilke data man besitter, og hvilke grep som kan tas for å få “orden i eget hus”.33 Avhengig av organisasjonens modenhet, kan det iverksettes tiltak på organisatorisk nivå parallelt med utvikling av data- eller tjenesteleveranser. Flere aktører tilbyr også ulike konsulent- eller rådgivningstjenester for slik selv-evaluering.34

Samtidig anbefales det å gjøre en risikovurdering av hvert datasett man ønsker å tilgjengeliggjøre, bruke og dele. Basert på erfaringene fra utvalgets medlemmer, har gruppen satt opp en liste med overordnete sjekkpunkter som vil pense inn på de mest sentrale juridiske parameterne ved deling av data.

1. Persondata – Data som direkte eller indirekte inneholder personopplysninger kan i utgangspunktet ikke deles uten samtykke fra den det gjelder. Alle persondata må behandles etter reglene i personopplysningsloven og overtredelse av reglene sanksjoneres.
2. Eksportkontroll og sanksjoner – Datadeling kan skje i sammenheng med en kontrakt om levering av tjenester eller utstyr som er omfattet av eksport/importrestriksjoner eller spesielle sanksjoner mot bestemte land.
3. Immaterialrettigheter – Data kan være beskyttet av immaterialrettigheter, som databaserettigheter eller at dataene utgjør forretningshemmeligheter. Virksomheten bør være oppmerksom både på egne rettigheter og at data som kommer fra en tredjepart kan være beskyttet av immaterialrettigheter som legger begrensninger på muligheten for deling.
4. Innsideinformasjon – Data er også informasjon, og såkalt markedssensitiv informasjon kan ikke deles i strid med reglene om innsideinformasjon og markedsmisbruk i verdipapirhandelloven kapittel 3 og Markedsmisbruksforordningen (MAR) (EU) nr. 597/2014.
5. Data underlagt særlig lovregulering – Enkelte virksomhetstyper og særlige typer data kan være underlagt spesielle regler om taushetsplikt eller forbud mot deling, samt særlige rapporteringskrav til myndigheter. Eksempler kan være data som er underlagt sikkerhetsloven. Deling av data må altså skje innenfor gjeldende lovregulering av virksomheten.
6. Konkurranserettslige forhold – Deling av konkurransesensitiv informasjon kan komme i konflikt med forbudet mot konkurransebegrensende samarbeid, og det å ikke dele kan etter omstendighetene utgjøre et misbruk av en dominerende markedsstilling.
7. Tredjeparts rettigheter – kontraktuelle begrensninger – Data som stammer fra tredjeparter kan være underlagt delingsbegrensninger i kontrakt. Virksomheten må sjekke av at videre deling av data skjer i henhold til de betingelsene som er satt i lisens til dataene.

Ekspertgruppen vil fremheve at deling av data skjer i mange ulike settinger og sammenhenger, og at mange kontraktstyper som har som hovedformål å regulere en annen ytelse eller tjeneste også vil regulere data. Et eksempel på en slik situasjon er der det inngås avtale om kjøp eller salg av utstyr eller tjenester som inkluderer datagenerering, for eksempel sensordata fra teknisk utstyr. Det er viktig at avtalen også regulerer hvorvidt og hvordan data skal være tilgjengelig for virksomheten og hva som skal skje med historiske data for utstyret ved eventuelt eierskifte. Dette kan eksemplifiseres ved at et skip skifter eier; skal den nye eieren ha tilgang til historiske data om skipet eller ikke, hvordan skal eventuell data overføres og vil det ha en kostnad.

Deling av data når dette skjer uten sammenheng med en tjeneste eller kjøp av utstyr, reguleres ofte i en lisensavtale. En lisensavtale er en kontrakt, men ordet “lisens” brukes gjerne for å signalisere at det som overføres er en rett til å bruke data eller informasjon, slik at den virksomheten som deler dataene fortsatt har rett til dem selv, i motsetning til et “kjøp” der alle rettigheter til det som kjøpes går over til kjøper.

I det følgende peker gruppen på visse emner som kan være relevante å vurdere eller ta med når deling av data skal reguleres i en kontrakt (lisensavtale). I mange sammenhenger vil tilsvarende bestemmelser eller punkter inngå i kontrakter om kjøp av utstyr eller tjenester for å regulere elementet av datadeling i det avtaleforholdet. Det er ikke avgjørende for innholdet av avtalen hva den kalles, og gruppen fokuserer her på de punktene som generelt kan være relevante når data deles – i utgangspunktet uavhengig av sammenhengen. Ikke alle punktene vil være like sentrale i alle avtaleforhold, så fremstillingen her bør behandles som et utgangspunkt eller en sjekkliste. I enkelte punkter ligger også mulige formuleringer basert på gruppens medlemmers erfaringer. Disse må betraktes som eksempler på hvordan et punkt kan utformes i en avtale, og det må vurderes konkret om de passer i et konkret avtaleforhold. Gruppens mål er å peke på forhold som virksomhetene bør vurdere om de skal regulere i sin avtale.

Ekspertgruppens vurderinger er relatert til norsk lov, og har det som utgangspunkt og bakgrunn for diskusjonen videre. Her behandles også kun de punktene i en avtale som har særlig betydning for deling av data, og ikke punkter som det generelt kan være relevant å regulere i alle avtaleforhold.

For at man skal kunne ha varig nytte og utvidet bruk av data i industrien kan det være nyttig for en virksomhet å rendyrke og organisere data på samme måte som andre aktiva i en virksomhet, for eksempel en motor eller annet type utstyr som trenger vedlikehold og oppfølging. Det kan også være nyttig å være tydelig på at konsumenten av et datasett håndteres som en «kunde» der man som leverandør har forpliktelser og forventninger til denne kunden og vice versa. Derfor er betegnelsene «Tjenesteleverandør» og «Kunde» benyttet videre i eksemplene slik at tjenesteleverandøren er den part som deler data og kunden er den som mottar data.

Generelle vilkår og beskrivelse av tjenesten

Statisk eller dynamisk datasett: I hovedsak kan man tenke seg to typer datadeling; Statisk og dynamisk.  Et statisk datasett kan være uttrekk av definerte data for en gitt tidsperiode som er tatt ut med en gitt frekvens. Typisk kan dette være målinger fra 10 forskjellige sensorer fra et gitt utstyr en gang per sekund fra og med 01.01.2021 til og med 31.12.2021. Siden disse dataene er statiske kan de sendes (og kopieres) til mottaker som en engangsjobb.  For eksempel kan visse typer utslippsmålinger til myndigheter basere seg på årlige aggregeringer av denne typen data som oversendes på sluttes av året.

For mer operasjonelle formål kan det være behov for samme data, men kontinuerlig samlet inn og tilgjengeliggjort. Et slikt dynamisk datasett er en kontinuerlig strøm av data som ofte krever et større apparat hos dataleverandør. Eksempelvis kan dette være målinger fra 10 forskjellige sensorer fra en gitt maskin der dataene blir målt en gang per sekund så lenge maskinen er i drift. 

For begge typer tjenester bør man være spesifikk og si noe om hvilke datapunkter som er tilgjengelige i tjenesten, metadata om disse samt hvor ofte dataene måles. For dynamiske datasett (datastrømmer) bør man i tillegg si noe om hvilke forpliktelser leverandøren av datatjenesten har. Typiske forpliktelser kan være:

Oppetid: Hvor mange % oppetid tilbys? Er det spesifikke krav til oppetid i kritiske perioder? Pass på at dette står i forhold til kritikalitet på datastrømmen

Support: Er det inkludert support på datatjenesten, og hvordan arter den seg? Vil det være tilgjengelig 24/4 eller i vanlig arbeidstid? Har man en organisasjon som kan håndtere dette?

Om det dreier seg om data til mindre kritiske operasjoner eller forskning så kan ofte kravene settes lavere og «Best effort» kan også være en aktuell formulering her.

Datakvalitet: Datakvalitet er avgjørende for at virksomheter skal kunne stole på datadrevet beslutningsstøtte. For sensordata er typiske kvalitetshendelser drifting av sensorer som krever kalibrering, kobling til utstyr faller ned slik at data ikke sendes, usynkroniserte tidsstempel og så videre. Hvordan datakvalitetshendelser skal håndteres bør beskrives i kontrakten. Eksempler på emner å dekke er: hvordan håndteres feil i data? gjøres det noen form for datavasking? Hvordan vises datakvalitetsmålinger?

Tilbake-kompatibilitet: Det anbefales å beskrive hvordan man som dataleverandør håndterer endringer og nye versjoner av tjenesten. 

Sikkerhet: Dersom datasettet krever autentisering/autorisasjon bør mekanismen som er i bruk beskrives, samt hvordan dette administreres. For noen industrier kan det være egne krav til sikkerhet i overføringsmekanismer fra utstyr til sky og lagring for å forhindre at dataene forandres eller lyttes på av andre.

Pris:Dersom dynamiske datasettet skal selges til en pris er det i hovedsak tre prismekanismer som er mest utbredt; Betaling per kall til datatjenesten eller fast pris for fast mengde data, med eller uten mulighet for utvidelse. I tillegg finnes avtaler om fastpris med ubegrensede kall eller mengder data, samt avtaler uten prising, for eksempel i tilfeller der to parter utveksler data med hverandre.

Prøveperiode: Det vil alltid være en læringskurve for hvordan nyttiggjøre seg av datasett fra andre aktører, enten det for forskning eller for kommersielle formål. For å gi kunden en mulighet til å forstå verdi før man forplikter seg til å kjøpe/bruke et datasett kan man vurdere en gratis utforskningsperiode (free trial) for kunden for å gi mulighet til å verifisere at datasettet faktisk gir den forventede verdi inn i videre arbeid.

Avtalens varighet:Dersom hensikten med datadeling er utforskende virksomhet og forretningsmodellen i begge ender ikke er helt klar, anbefales det å vurdere en tidsavgrenset avtale, for eksempel for ett år av gangen. Dette vil gjøre det mulig for begge parter å oppdatere innhold etter hvert som man opparbeider seg mer erfaring rundt bruk og innhold i datadelingen før man inngår mer langsiktige avtaler

Terminering av kontrakten:Det anbefales å legge inn en tydelig beskrivelse av hendelsesforløp og forventninger til hva som skal skje med allerede delte data dersom kontrakten termineres. Om du er en tjenesteleverandør, vurder krav om at immaterialrettigheter, fraskrivelse av garanti, begrensning av forpliktelser, skadeserstatning og konfidensialitet og lignende fortsatt gjelder etter at tjenesten er terminert for data konsumert i tjenesten

Som eksempler kan terminering dekkes på følgende måte.

Upon termination of the Service Terms, (i) the license granted hereunder will immediately terminate; (ii) all rights of Customer to access and use the Service shall immediately cease; and (iii) Tjenesteleverandør may delete all of the Customer Content in the Service.

Provisions in these Service Terms which by their nature are intended to have effect also after the expiry or termination of these Service Terms, including but not limited to Intellectual Property Rights, No Warranties, Liability and Indemnity, and Confidentiality, shall survive expiry or termination.

9.2 Scenario 0: Intern deling i egen virksomhet

Forstørr bilde

En virksomhet ønsker å lagre data som man genererer selv (kun intern deling)

Relevante tema og utfordringer for scenario 0

• Hva er formålet med innsamling og lagring av data?
• Har virksomheten rett til å lagre data? (i forhold til datakildene)
• Hvilke lovverk er relevante med tanke på lagring av data (feks. GDPR)?
• Hvor og hvordan skal data lagres (teknisk)?
• Hvem har tilgang til data internt i virksomheten?
• Hvem skal man dele data med internt i virksomheten og hvorfor? 
• Bør dataene beskyttes med konfidensialitetsforpliktelser? (konkurransesensitive data, forretningshemmeligheter)
• Hvem har ansvar for at data er korrekt over tid (vedlikehold)?
• Hvor lenge skal data lagres?

Disse temaene vil også være relevante for scenariene 1-3 som blir utdypet grundigere nedenfor. Vi anbefaler at virksomhetene har gode og gjennomtenkte svar på disse sentrale spørsmål før man begynner å dele data med eksterne parter. Basert på ekspertgruppens erfaring vil grundig arbeid med å svare på disse spørsmålene internt i virksomheten gjøre det enklere når man begynner å samarbeide med andre rundt datadeling.

I et internt scenario anbefales det å regulere omgangen med data i interne retningslinjer eller instrukser som sikrer beste praksis for datahåndteringen. Det innebærer for eksempel at innsamling og lagring skjer planmessig og strukturert, at det foreligger sjekklister for å avklare tredjeparts rettigheter, spørsmål rundt personopplysninger eller lignende i forbindelse med datalagring, og at det foreligger rutiner som gjør de ansatte oppmerksomme på sjekkpunktene til rett tid. Det er viktig å forankre ansvaret for datahåndtering hos en funksjon internt i virksomheten.

9.3 Scenario 1: Enveis en-til-en deling

Forstørr bilde

Relevante tema og utfordringer for scenario 1

• Hva er formålet med deling av data?
• Har virksomheten rett til å dele data med en annen virksomhet?
• Hvilke lovverk er relevante ift. deling av data med en annen part?
• Skal det legges begrensninger for hvordan data brukes hos kunden?
• Skal kunden ha adgang til å dele data videre med tredjeparter?
• Hvem har ansvaret for hvordan data brukes?
• Hvilke avtaler trenger man?
• Hvordan skal data deles (teknisk)?
• Hvordan skal den kommersielle modellen/avtalen se ut?
• Hvem har ansvar for at data er korrekt over tid (vedlikehold)?
• Hvem har tilgang til data?
• Hvor lenge skal data lagres?

I denne settingen for datadeling deler en virksomhet data med andre, for eksempel gjennom tilgang til APIer. Utvekslingen av data bør fortrinnsvis skje i tråd med etablerte standarder og (meta)datamodeller, men er opp til avtalen mellom virksomhetene. Sikkerheten ivaretas her ved å følge etablert praksis for API-utvikling, som innebærer for eksempel kryptering av data som sendes, begrensning av datamengder som kan overføres, og begrensninger på tilganger for å unngå «brute-force»-angrep for inntrenging. Fordelen med slike løsninger er at både avtaler og teknologiske løsninger tillater en forholdsvis hurtig implementering, samtidig som den egner seg mest for datautveksling mellom et fåtall aktører eller for enveis, åpen tilgjengeliggjøring. Dette fordi kompleksiteten (både teknisk og når det gjelder avtaler) øker eksponentielt med antall virksomheter som deltar i datadelingen.

Partene bør reflektere over formålet med delingen for at vilkårene i avtalen blir best mulig tilpasset og legger til rette for at formålet realiseres så enkelt og friksjonsfritt som mulig. Den som vil dele data, må forsikre seg om at tredjeparts rettigheter ikke er til hinder for det. Er det tale om persondata, kan disse bare deles i henhold til personopplysningsloven. Også data fra egen virksomhet kan etter omstendighetene inneholde persondata om virksomhetens ansatte. Andre data kan også være underlagt restriksjoner, for eksempel etter sikkerhetsloven. Data som er innhentet fra tredjepart kan være underlagt begrensninger enten i lov (for eksempel forretningshemmelighetsloven) eller i avtale.

Dersom kunden bare skal bruke dataene til bestemte formål eller på bestemte måter, bør det presiseres i avtalen. Det samme gjelder dersom det skal legges begrensninger på hvordan kunden kan bruke tjenesten eksternt mot sine kunder, altså dele dataene videre med tredjeparter. Slike nyanser er det viktig å beskrive i avtalen. Begrensninger på bruken av dataene henger typisk sammen med behov hos den virksomheten som deler data for å sikre seg at eventuelle rettigheter beholdes, for eksempel forretningshemmeligheter eller databaserettigheter. Et relativt vanlig scenario vil være at en kunde ønsker å bruke data fra tjenesteleverandøren internt som delmengde av et større datagrunnlag for å utføre en analyse, men vil ikke kunne videreformidle/selge dataene videre til andre. Et eksempel på tekst som begrenser videre deling fra en kontrakt er:

«Service or any information derived from the Service may not be reproduced, transmitted, copied (in any form or by any means), distributed further or modified for commercial purposes.»

Det bør også reguleres i avtalen hva som skal være konsekvensene av at avtalens krav ikke overholdes. Den alminnelige kontraktsretten har regler om konsekvenser av avtalebrudd, som mulighet for retting, prisavslag, erstatning og til slutt heving, altså at avtalen bringes til opphør. Det kan være grunn til å tenke gjennom hvordan partene vil at sanksjonene skal gjelde i eget avtaleforhold, for eksempel at det settes klare frister for å rette opp forhold, og å presisere om visse forpliktelser er så sentrale at brudd på dem skal medføre rett til å heve avtalen.

9.4 Scenario 2: Virksomhet vil levere tjenester basert på data fra andre

Forstørr bilde

I tillegg til spørsmålene i foregående scenario, reiser dette scenariet ofte spørsmål om håndtering av immaterialrettigheter og om dataportabilitet. I tillegg til håndtering av databaserettigheter eller forretningshemmeligheter hos dataleverandør, bør tjenesteleverandør sin bruk av dataene håndteres. Dersom dataene skal kunne brukes til å lage nye verdiskapende datasett eller tjenester for videresalg, vil rettighetene til disse (opphavsrett til datamaskinprogrammer, nye databaserettigheter eller forretningshemmeligheter) oppstå hos kunden, altså tjenesteleverandøren, med mindre noe annet følger av avtalen. Det er mulig å legge til at dataleverandørene skal krediteres i en ny tjeneste. Det kan også bli satt krav fra dataleverandør om at tjenesteleverandørs tjeneste ikke skal kunne reverse engineeres tilbake til dataleverandøren sine datasett. Et eksempel tekst som dekker dette i en kontrakt er:

«Include in all materials containing the DATA PROVIDER Data a credit identifying DATA PROVIDER as the source as follows:» Copyright © DATA PROVIDER Global Limited [current year] All Rights Reserved.

Customer can create Derivative Works using the data from the provided that the original data form the service cannot be reverse engineered to its raw format or obtained from the Derivative Works. The Derivative Works cannot directly compete with DATA PROVIDER's products.»

Dersom dataleverandørene ønsker mulighet til å få dataene de har levert “ut” av tjenesten, bør det reguleres i avtalen både hvordan det skal skje, og om det også skal omfatte historiske data. Problematikk omkring dataportabilitet oppstår typisk dersom den som samler inn data til en tjeneste også yter tjenesten til dataleverandørene. Et eksempel på dette kan være skytjenester i landbruk som samler data fra sensorer hos den enkelte bonde og sammenstiller med andre datasett for å levere en tjeneste som kan bestå av informasjon eller prediksjon til bonden.

9.5 Scenario 3: Virksomheter deler data på tvers i felles arkitektur

Forstørr bilde

Relevante tema og utfordringer for scenario 3

• Hvorfor ønsker man å dele og samle data (forretningsmessig verdi)?
• Hvordan skal data deles (teknisk løsning)?
• Har de som deler data rett til å gjøre dette?
• Hvordan skal data anonymiseres og hvem har ansvaret for dette? (den som vedlikeholder databasen eller den som sender dataene?)
• Hvem har ansvar for drift av felles arkitektur (styring av tilganger og kontroll med data)?
• Hvordan skal den kommersielle modellen se ut?
• Hva får man “igjen” av å dele data?
• Hvem skal få tilgang til dataene? (er det behov for begrensninger?)
• Hva skal dataene kunne brukes til?

Når det er mange aktører som ønsker å dele eller utveksle data, men ikke ønsker å bruke en felles dataplattform, kan føderert deling av data være en aktuell løsning. Eksempelvis, når bedrifter langs en verdikjede (underleverandører, logistikkpartnere, produsenter og distributører) ønsker å gjøre visse deler av produksjonsdata tilgjengelig for utvalgte partnere, men ikke vil gi alle aktørene den samme innsikten. I en slik føderert setting vil datadeling skje basert på forretningsmessige behov, men i motsetning til en distribuert arkitektur vil det være et felles rammeverk som definerer sikkerhet og autentisering (som oftest basert på digitale sertifikater som deles ut av en tredjepart som alle aktørene har tillit til), så vel som spilleregler for interoperabilitet og bruk av data som skal deles. En slik løsning vil kreve en investering av deltagerne i forkant, siden spesifikke (sikkerhets-sertifiserte) programvaremoduler må utvikles eller kjøpes for å koble seg mot infrastrukturen, men vil gjøre utvidelser av det digitale samarbeidet (flere datasett, flere aktører) enklere å håndtere.

I tillegg til det som i foregående scenarier, reiser dette scenariet særlig spørsmål knyttet til avtaleforhold med flere enn to parter. På den ene siden kan det være mindre ressurskrevende og mer effektivt å dele data i et samarbeid mellom flere parter. På den annen side er det en risiko for at delingen blir et minste felles multiplum fordi hensynet til like vilkår vil føre til at partene bare vil dele i henhold til vilkårene fra den mest restriktive av dem. Her forutsettes at samarbeidet er basert på en kontrakt og at det ikke er mer integrert, som i et felles selskap eller joint venture. I et flerpartssamarbeid bør det vurderes om alle parter skal eller bør være underlagt samme vilkår, eller om det er grunn til å differensiere mellom dem. Forutsetningene for deling av data kan være svært ulike for virksomhetene selv om det er forretningsmessig nyttig for dem å dele data. I så fall kan det tenkes en struktur med visse fellesbestemmelser, og så spesielle bestemmelser for ulike parter.

Det bør tas stilling til hvem som har ansvar for å følge opp tilganger og administrere den felles infrastrukturen eller plattformen. Det kan være en fordel å regulere ansvar for data i forhold til inngrep i tredjeparts rettigheter (hvem har ansvar for at bruk av delte data ikke gjør inngrep i tredjeparts forretningshemmeligheter eller personopplysninger?). Det anbefales også å regulere ansvar for datakvalitet, altså hvordan partene seg imellom vil sanksjonere det at delte data har feil eller dårligere kvalitet som medfører problemer for produksjon eller drift. Endelig anbefales å regulere uttreden av samarbeidet og håndtering av allerede delte data dersom en part vil eller må tre ut.

9.6 Scenario 4: Deling av data mellom flere virksomheter på en felles dataplattform

Forstørr bilde

Relevante tema og utfordringer for scenario 4

• Hvorfor ønsker man å dele og samle data? (Forretningsmessig verdi)
• Hvordan skal data deles (teknisk løsning)?
• Har man rett til å dele dataen videre fra virksomheten til en 3.part?
• Hvordan skal data anonymiseres og hvem har ansvaret for dette? (den som vedlikeholder databasen eller den som sender dataen?)
• Hvem har ansvaret for datavedlikehold og -kvalitet, og hvordan reguleres dette i avtalene?
• Hvordan skal avtalene se ut mellom de ulike aktørene

I en sentralisert arkitektur vil sikkerheten som regel ivaretas av leverandøren av dataplattformen som implementerer rutiner for både sikker overføring, lagring og manipulasjon av data, tilgangsstyring ved å innrette ulike nivåer for brukerrettigheter og så videre. Bruk av data reguleres ofte av plattformleverandørenes standardavtaler. Deling av data på slike plattformer har fordelen av at virksomheten som ønsker å dele data vil kunne kjøpe det som en tjeneste istedenfor å ta kostnaden av en egen teknisk implementering. Dette gjør slike felles dataplattformer interessant i settinger der mange aktører har de samme interessene som i sin helhet vil tjene på tilgang til hverandres datasett.

I tillegg til det som er diskutert for scenario 1 og 3, er det i dette scenariet også et særlig behov for å tenke igjennom organiseringen av den felles plattformen og hvordan partene skal forholde seg til den. Ved å opprette en felles plattform, samles de opplastede data i en database, som det etter omstendighetene kan oppstå databaserettigheter til. Etter åndsverkloven kan databaserettigheter innehas av flere parter i sameie. For å få god forutsigbarhet om rettighetene til en slik felles database, kan det være en fordel å regulere hvem som skal være sameiere og med hvor store andeler i databaserettighetene. Det bør også reguleres hvem som skal ha rett til å bruke databasen og om alle partene skal ha lik rett til å bruke alle data. Dette spørsmålet løses ikke uten videre av reglene om databaserettigheter. Når data samles i en felles plattform, blir det også mulig å dele dataene samlet med tredjeparter. Den felles avtalen bør regulere om det skal være mulig, for hvem og på hvilke vilkår.

Det er også viktig å regulere vedlikehold av dataene og datakvalitet og eventuelt ansvar (eller ikke ansvar) for at feil i dataene fører til skader eller ulemper i drift eller produksjon hos noen av partene eller hos tredjeparter.

9.7 Scenario 5: Deling av data på en felles dataplattform med datatjenester

Forstørr bilde

Moderne dataplattformer tilbyr som oftest verdiøkende tjenester for datasettene som deles, enten fra plattformeier eller andre leverandører. Dette kan for eksempel være transformasjon av data til formater som er i tråd med standarder eller andre avtalte datamodeller, integrasjon av data fra de ulike aktørene der dette ønskes, eller avanserte analysetjenester basert på maskinlæring.

Dette scenariet er en kombinasjon av scenario 2 og 4, og spesifikke anbefalinger for scenario 5 dekkes i stor grad av disse. Scenariet illustrerer hvordan data samles, kombineres med andre data, aggregeres og foredles, og slik inngår i en tjeneste som kan ha som output noe helt annet enn de opprinnelige dataene. Det bør imidlertid påpekes at det kan være svært vanskelig både å forutse og beregne noe adekvat vederlag for bruken av de opprinnelige dataene i den endelige tjenesten, særlig dersom denne tjenesten ikke ytes til dataprodusentene, men til helt andre kunder med helt andre behov. Problemet kan være at selv et helt minimalt vederlag til de enkelte dataprodusentene samlet sett blir en så stor utgift for tjenesteutvikler at det ikke vil lønne seg å utvikle og tilby tjenesten. Dette scenariet oppfattes derfor først og fremst aktuelt der partene til plattformen får andre fordeler av delingen enn at det utvikles en tjeneste. Det kan også tenkes at koblingen mot en tjenesteyter bidrar til å finansiere drift og vedlikehold av plattformen.