Mikromobilitet Byvekstområdet utenfor Trondheim

Databehandler-/kontraktsvilkår for mikromobilitetsordning «Mikromobilitet Byvekstområde utenfor Trondheim» (Melhus, Malvik, Skaun, Stjørdal, Orkland). Operatør skal levere pseudonymiserte datasett månedlig (turdata, kjøretøytilgjengelighet, brukerundersøkelser via RiderSurvey API/alternativ), integrere GBFS/Entur Mobility API for sanntidsvisning i AtB-appen, samt oppfylle minimumskrav til drift, trafikksikkerhet, materiell og rapportering. Databehandleravtalen regulerer GDPR art. 28/29-behandling: instrukshåndtering, konfidensialitet, sikkerhetstiltak, bruk av underleverandører (forhåndsgodkjenning), bistand ved brudd/DPIA, tredjelandsoverføring (i praksis kun EØS), sletting/returnering, og revisjons-/inspeksjonsrettigheter.

• Operatør skal være registrert i et foretaksregister, faglig register eller handelsregister i den staten Tilbyderen er etablert.

  Dokumentasjon: Firmaattest

  Kilde: v6_00 Prosedyrebeskrivelse, punkt 3.4.1 Registrering/autorisasjon
• Operatør skal ha ordnede forhold med hensyn til betaling av skatt, arbeidsgiveravgift og merverdiavgift (skatteattest).

  Dokumentasjon: Skatteattest (ikke eldre enn 6 måneder regnet fra fristen for å levere forespørsel om å delta)

  Kilde: v6_00 Prosedyrebeskrivelse, punkt 3.4.2 Skatteattest

• Operatør må fylle ut registrerings-/svarskjema og bekrefte at obligatorisk dokumentasjon er levert.Kilde: Vedlegg 1 Registreringsskjema, avkrysningsbokser for obligatorisk dokumentasjon
• Operatør skal bekrefte om krav i bilag 2.1 Kravmatrise er oppfylt (Ja/Nei) og ved Nei redegjøre hvilke minimumskrav som ikke oppfylles.Kilde: Vedlegg 1 Registreringsskjema (del om bilag 2.1 Kravmatrise)
• Operatør skal angi antall kjøretøy per kommune ved oppstart (bindende opplysninger): El-sykler og El-sparkesykler for Malvik, Stjørdal, Melhus, Orkland, Skaun.Kilde: Vedlegg 1 Registreringsskjema (tabell «Kommune»/kjøretøyantall)
• Komplett registreringsdokumentasjon skal leveres i tråd med prosedyrebeskrivelsens krav; ikke send inn mer enn etterspurt.Kilde: v6_00 Prosedyrebeskrivelse, punkt 3.3 og 3.4
• Når operatør er godkjent: sende signert kontrakt og utfylt Vedlegg 3 Databehandleravtale.Kilde: v6_00 Prosedyrebeskrivelse, punkt 5 Tilbakemelding om opptak

Innleveringsvilkår fra kunngjøringen

Frist for forespørsel/tilbud

29.10.2027

Språk

norsk

Elektronisk katalog

Ikke tillatt

• Databehandler skal behandle personopplysninger på vegne av Behandlingsansvarlig kun etter dokumenterte instrukser (spesifisert i Vedlegg A og C).Kilde: Vedlegg 3 Databehandleravtale, punkt 4 Databehandleren handler etter instrukser
• Konfidensialitet: tilgang kun for autoriserte personer med taushetsplikt; tilgangsliste skal gjennomgås og kontrolleres i henhold til intervall i Vedlegg C.Kilde: Vedlegg 3 Databehandleravtale, punkt 5 Konfidensialitet (og Vedlegg C.2)
• Sikkerhetstiltak minimum: pseudonymisering/kv- og kryptering (TLS 1.2+ for overføring), tilgangskontroll, gjennomgang av tilgang minst hver 12. måned, regelmessig testing årlig, ikke offentlig URL uten tilgangskontroll, sikker filoverføring/API med TLS, sky-leverandør minst ISO 27001 eller tilsvarende, logging av overføringer (≥6 mnd).Kilde: Vedlegg 3 Databehandleravtale, punkt 6 Sikkerhet ved behandlingen; konkretisering i Vedlegg C.2
• Underleverandører: kun forhåndsgodkjente skriftlig; innhente godkjenning minst 30 dager før; samme forpliktelser i underleverandøravtaler; kopi av underleverandøravtale ved anmodning; databehandleravtale må sikre at oppdragsgiver kan tre inn ved konkurs.Kilde: Vedlegg 3 Databehandleravtale, punkt 7 Bruk av underleverandør
• Overføring til tredjeland: kan kun skje etter dokumentert instruks og i samsvar med kapittel V; i denne avtalen gis ikke instruks om tredjeland/IMO og all behandling skal skje innenfor EØS.Kilde: Vedlegg 3 Databehandleravtale, punkt 8 Overføring til tredjeland; Vedlegg C.6
• Bistand ved registrertes henvendelser: bistand med identifisering/sletting av aktuelle pseudonymiserte opplysninger ved forespørsel innen 5 virkedager.Kilde: Vedlegg 3 Databehandleravtale, punkt 9 Bistand; Vedlegg C.3 a
• Varsling ved brudd: underrette behandlingsansvarlig uten ugrunnet opphold, om mulig innen 24 timer; bistå med å fremskaffe informasjon til melding til Datatilsynet.Kilde: Vedlegg 3 Databehandleravtale, punkt 10 Underretning om brudd; Vedlegg C.3 b og Vedlegg C.2 (logger)
• Sletting/returnering: ved opphør levere tilbake alle personopplysninger og slette kopier med mindre lovpålagt oppbevaring; pseudonymiserte data slettes etter oppbevaringsperiode.Kilde: Vedlegg 3 Databehandleravtale, punkt 11 Sletting og returnering; Vedlegg C.4
• Revisjon/inspeksjon: databehandler skal stille nødvendig info; tillate revisjoner/inspeksjoner; tilgang til lokaler ved legitimasjon; behandlingsansvarlig har inspeksjonsrett med 14 dagers varsel for berørte systemer og prosesser.Kilde: Vedlegg 3 Databehandleravtale, punkt 12 Revisjon; Vedlegg C.7
• Månedlig rapportering (3 datasett) via sikker filoverføring til dedikert mappe innenfor tilgangsinformasjon; turdata, kjøretøytilgjengelighet og brukerundersøkelsesdata.Kilde: v4_01 Kontrakt, punkt 1.5 Data om bruk; Vedlegg 2 (tidsfrist første 7 kalenderdager i påfølgende måned)
• Sanntidsvisning i AtB-appen: operatør skal levere GBFS-data til Entur Mobility API iht. spesifikasjoner (operatør dekker integrasjonskostnader).Kilde: v4_01 Kontrakt, punkt 1.4 Integrasjon; Vedlegg Bilag 2.1 krav 19
• RiderSurvey: operatør skal bruke RiderSurveyAPI for å samle inn svar i app (alternativ løsning aksepteres hvis funksjonelt tilsvarende utsending av spørreundersøkelse etter sluttført tur).Kilde: Vedlegg 2 (RiderSurveyAPI); Bilag 2.1 krav 29; v4_01 Kontrakt (alternativ løsning)
• Personopplysninger skal behandles i samsvar med GDPR (minstekrav).Kilde: Bilag 2.1 Kravmatrise, krav 27; v4_01 Kontrakt punkt 2.1.
• Operatør må følge kommunal regulering om plassering og parkering, samt akseptere at geo-fence soner kan endres av kommunene i avtaleperioden.Kilde: Bilag 2.1 Kravmatrise, krav 1-2
• Trafikksikker drift: rutiner for å hindre bruk i påvirket tilstand (promillekjøring), regelmessig kontroll/vedlikehold, rask respons ved ulykker/hendelser.Kilde: Bilag 2.1 Kravmatrise, krav 4-6
• Deling av sanntids- og historiske data med AtB, Impact Market og aktuelle kommuner i henhold til regelverk; samt støykrav og fjerning av kjøretøy som er utenfor tillatte plasser/hindrer fremkommelighet mv.Kilde: Bilag 2.1 Kravmatrise, krav 7-9
• Materiell/klima: fast automatisk lysanlegg, mulighet for å stå oppreist, merking med firmanavn/kontakt og unik ID (lesbar manuelt/digitalt), tåle norske klimaforhold, utslippsfrie kjøretøy.Kilde: Bilag 2.1 Kravmatrise, krav 10-14
• Utplassering/merke: synliggjøre at tilbudet er støttet av Oppdragsgiver ved diskret ikke-påtrengende merking med Oppdragsgivers logo (klistremerke).Kilde: Bilag 2.1 Kravmatrise, krav 15
• Digital funksjonalitet: lås/avlås via mobilapplikasjon; GPS med mulighet for regulering via geofencing; oppdatere apper/systemer med AtB/kommunereguleringer; sanntidsvisning i AtB-appen via GBFS.Kilde: Bilag 2.1 Kravmatrise, krav 16-19
• Brukergrensesnitt: samlet brukergrensesnitt (én app), rask start og nærliggende kjøretøy, se dedikerte parkeringsplasser og tilgjengelighet, supportfunksjon, samtykke i app.Kilde: Bilag 2.1 Kravmatrise, krav 20-26
• Minimum spris: operatør skal ta betalt for alle reiser; enkeltreiser minimum 10 NOK og maksimum som ikke overstiger operatørens gjennomsnittlige markedspris i andre byer; ved medlemskap må medlemskapet ikke gi lavere pris enn minimumspris i andre byer.Kilde: Bilag 2.1 Kravmatrise, krav 30

• Dokumentteksten for «Databehandleravtale.docx» inneholder utfylte felter for Databehandler (MACROBUTTON [NAVN]/[ORGANISASJONSNUMMER]/[ADRESSE] osv.), men selve operatør-/databehandleridentiteten er ikke konkret i utdraget.
• Krav om oppdrags-/leverandørrolle i kontrakt: om operatør alltid er «Databehandler» og AtB/Impact Market rollene ellers er klart avgrenset i teksten, men eksakt rollefordeling mellom operatør og Impact Market utover at Impact Market fungerer som databehandler fremgår ikke fullt ut i utdrag.
• Flere detaljer om revisjonsprosedyrer og inventar (f.eks. Vedlegg C punkt C.7/C.8 referanser) er delvis beskrevet, men eksakt omfang i henhold til alle delpunkter er ikke fullt gjengitt i teksten.

Punkter der konkurransedokumentene åpner for tolkning, og der en presisering fra oppdragsgiver kan ha betydning for prising og risiko. Spørsmål kan stilles innen fristene som er angitt i konkurransegrunnlaget.

1. I Kontrakten punkt 1.5 og i Vedlegg 2 punkt 1–3 beskrives månedlig oversendelse av turdata, tilgjengelighetsdata og brukerundersøkelsesdata, samt at AtB «på et senere tidspunkt» kan kreve daglig deling via API/SQL. Kan dere bekrefte (i) hvilke datasett som kan kreves daglig, (ii) forventet leveranseformat (CSV vs API/SQL), og (iii) rimelig frist/varsel dere vil gi før daglig deling iverksettes?

   Hvorfor det er verdt å spørre: For å kunne prise og planlegge drift og integrasjoner (kost-/arbeidsomfang) trengs avklaring av hva som kan bli «daglig» og hvordan det teknisk skal leveres samt hvilket varsel som gis.

   Kilde: Kontrakt 1.5 og Vedlegg 2 punkt 1–3

2. I Kontrakten punkt 1.4 står det at operatør skal levere GBFS-data til Enturs Mobility-API «i tråd med gjeldende spesifikasjoner». Hvilken GBFS-versjon/spesifikasjon (inkl. endringslogg/standard) legger AtB til grunn, og hvem dekker eventuelle kostnader ved endringer i Enturs/GBFS-krav (utover «operatør må selv dekke kostnader tilknyttet integrasjon»)?

   Hvorfor det er verdt å spørre: Dette påvirker løpende utviklings- og vedlikeholdskostnader for integrasjon mot Entur/GBFS, som igjen påvirker prising og risikovurdering.

   Kilde: Kontrakt 1.4

3. I Vedlegg 2 punkt 1 (turdata) fremgår det at det skal sendes inn user_ID for å håndheve «maksimalt 4 turer per unik bruker per dag», og at feltene ellers er MDS. Kan dere presisere hvordan user_ID skal håndteres for å støtte kontrollen (f.eks. skal det være anonymisert/pseudonymisert allerede i operatørens system, eller leveres en intern identifikator som dere senere pseudonymiserer)?

   Hvorfor det er verdt å spørre: Feil forståelse av hvordan bruker-identifikasjon skal overleveres kan gi avvisning av datagrunnlag eller feil insentivberegning; det påvirker også personvern-/DPIA-arbeidet.

   Kilde: Vedlegg 2 Appendiks 1 (turdata)

4. I Kontrakten punkt 2.1 beskrives fakturering: Impact Market beregner insentiver innen 10 kalenderdager og sender spesifikasjon til operatør, operatør skal sende etterskuddsfaktura innen en uke, og faktura sendes til Oppdragsgiver (kopi til Impact Market). Kan dere bekrefte hvem som er betalingsmottaker i praksis for insentivene (AtB som oppdragsgiver) og hva operatør skal legge inn i fakturaspesifikasjonen (minimum hvilke linjer/underlag), herunder hvordan dere håndterer avvik/reklamasjon på grunnlag av datasett?

   Hvorfor det er verdt å spørre: Operatøren trenger klarhet i fakturaprosess, spesifikasjonskrav og håndtering av datadifferanser for å kunne etablere finansrutiner og unngå tvister.

   Kilde: Kontrakt 2.1

5. Krav 19 og 18 i Bilag 2.1 (Kravmatrise) samt Kontrakten punkt 4.5 om suspensjon ved bl.a. manipulering av turdata: kan dere beskrive hvilke konkrete valideringer/kontroller dere bruker for å avdekke «manipulering av turdata» (eksempelvis avvik i MDS-felt, tidsstempler, duplisering, geografisk mønster), og hva som typisk regnes som «retting» innen 5 virkedager?

   Hvorfor det er verdt å spørre: Operatøren må vite hvilke datakvalitetskrav som håndheves og hva som er praktisk mulig å rette raskt for å redusere risiko for umiddelbar suspensjon.

   Kilde: Kontrakt 4.5 og Bilag 2.1 krav 18–19

6. Bilag 2.1 krav 7 sier at operatøren skal dele «sanntidsdata og historiske data» med AtB, Impact Market og kommuner i henhold til gjeldende regelverk, mens Vedlegg 2 beskriver levering av tre datasett månedlig og Kontrakten 1.5 omtaler at AtB senere kan kreve daglig deling via API/SQL. Hvilke mottakere (AtB vs Impact Market vs kommuner) mottar hvilke datatyper (turdata/tilgjengelighet/undersøkelser), og skjer deling til kommuner kun gjennom AtB (eller direkte til kommunene)?

   Hvorfor det er verdt å spørre: Mottaker- og datatypespesifikk avklaring er viktig for både dataminimering, personvernansvar og teknisk/organisatorisk opplegg.

   Kilde: Bilag 2.1 krav 7, Kontrakt 1.5 og Vedlegg 2 punkt 1–3

7. I Bilag 2.1 krav 29 står «Funksjonaliteten skal være klar innen juli» for brukerundersøkelsesdata. Kan dere presisere (i) hvilken dato i juli som menes, (ii) hva som skal være «klar» (integrasjon i app, testmiljø, end-to-end flyt, eller oppstart av faktisk sampling), og (iii) om det forventes leveranse/rapportering i en overgangsperiode før ordentlig pilotoppstart 01.04.2026?

   Hvorfor det er verdt å spørre: Operatøren må planlegge app- og API-integrasjon og timeline; uklart «innen juli» kan gi uforutsette forsinkelser og risiko for manglende oppfyllelse av minimumskrav.

   Kilde: Bilag 2.1 krav 29

8. I Kontrakten punkt 1.6 og Prosedyrebeskrivelsen punkt 1.5/1.6 fremgår det begrensning «maksimum 4 leieturer per bruker per dag» og at utbetaling forutsetter turens varighet minimum 3 minutter og maksimalt 4 leieturer per bruker per dag kvalifiserer. Kan dere bekrefte hvordan «bruker per dag» avgrenses tidsmessig (lokal tid/UTC, og hvilken tidssone), og om dupliserte/avbrutte turer eller turer med manglende felter (f.eks. end_time) behandles som kvalifiserende?

   Hvorfor det er verdt å spørre: Dette påvirker både insentivgrunnlag og utvikling/feilhåndtering i datagrunnlaget; også viktig for å unngå avvisning eller underutbetaling.

   Kilde: Prosedyrebeskrivelsen 1.5–1.6 og Kontrakt 1.6

9. Bilag 2.1 krav 30 om pris: «minimumspris minst 10 NOK og maksimumspris som ikke overstiger operatørens gjennomsnittlige markedspris i andre byer». Kan dere presisere hvilken priskomponent som inngår i «minimumspris» og «markedspris» (grunnpris, per minutt, per km, abonnement, tilleggsavgifter), og hvordan dere vil kontrollere/ dokumentere dette i praksis dersom AtB spør?

   Hvorfor det er verdt å spørre: Prisreglene kan være krevende å dokumentere og kan påvirke produktdesign og inntektsmodell; leverandøren trenger kontrollmetode og avgrensninger for å kunne prise riktig.

   Kilde: Bilag 2.1 krav 30

10. I Kontrakten punkt 4.11 om plikter ved avslutning og Vedlegg 3 (Databehandleravtale) punkt C.4 om oppbevaringsperiode/sletting: kan dere bekrefte hvilke av operatørens egne data som (i) skal leveres/avleveres til AtB etter kontraktens opphør, og hvilke som (ii) kun skal slettes hos databehandler, samt frist for slik avlevering/slettebekreftelse?

    Hvorfor det er verdt å spørre: Dette påvirker avslutningsplan, kostnader og risiko for feil datohåndtering ved kontraktslutt; leverandøren trenger tydelig arbeidsdeling og tidsfrister.

    Kilde: Kontrakt 4.11 og Databehandleravtale vedlegg C punkt C.4