Mikromobilitet Byvekstområdet utenfor Trondheim

Vedleggene regulerer personopplysninger og datarapportering knyttet til mikromobilitetstjeneste/åpen ordning. Databehandleravtalen (inkl. vedlegg A-C) beskriver roller, instruksbasert behandling, sikkerhetstiltak, bistand ved henvendelser og brudd, underleverandører, eventuelle tredjelandsoverføringer, revisjon/inspeksjon og slette/tilbakeføring. I tillegg angir kravmatrisen minimumskrav til operatøren for ytelser, inkludert trafikksikkerhet, materialkrav, digital løsning/geo-fence, brukergrensesnitt, GDPR etterlevelse og rapportering av bruksdata (turdata, tilgjengelighetsdata og brukerundersøkelser via RiderSurvey API).

• Operatøren skal behandle personopplysninger i samsvar med gjeldende GDPR-regelverk.

  Dokumentasjon: Angis som Ja/nei i kravmatrise. Dokumentasjon uttrykkes ikke nærmere i teksten.

  Kilde: V3_2.1 Bilag 2.1 Kravmatrise, krav nr. 27

• Innen de første 7 kalenderdagene i påfølgende måned: levere Turdata via sikker filoverføring til dedikert mappe (i henhold til tilgangsinformasjon).Kilde: Vedlegg 2 Krav til rapportering av data fra operatør (Turdata, punkt 1)
• Innen de første 7 kalenderdagene i påfølgende måned: levere data for tilgjengelighet av kjøretøy via sikker filoverføring til dedikert mappe (antall elsykler per kommune og tilgjengelige kl. 12:00 hver dag).Kilde: Vedlegg 2 Krav til rapportering av data fra operatør (Kjøretøytilgjengelighet, punkt 2)
• Bruke RiderSurveyAPI for å samle inn brukerundersøkelsesdata i operatørens app (undersøkelse vises etter utvalgte turer).Kilde: Vedlegg 2 Krav til rapportering av data fra operatør (Brukerundersøkelsesdata, punkt 3) og RiderSurveyAPI-beskrivelsen

Innleveringsvilkår fra kunngjøringen

Frist for forespørsel/tilbud

29.10.2027

Språk

norsk

Elektronisk katalog

Ikke tillatt

• Instruksbasert behandling: Databehandler skal bare behandle personopplysninger etter dokumenterte instrukser fra behandlingsansvarlig (vedlegg A og C), og instruksene skal være dokumenterte og oppbevares skriftlig.Kilde: 3. Vedlegg 3 Databehandleravtale, punkt 4 «Databehandleren handler etter instrukser»
• Konfidensialitet: Databehandler skal kun gi tilgang til autoriserte personer underlagt konfidensialitet/taushetsplikt, og tilganger skal kontrolleres iht. intervall i vedlegg C.Kilde: 3. Vedlegg 3 Databehandleravtale, punkt 5 «Konfidensialitet»
• Sikkerhetstiltak minimum: pseudonymisering og kryptering ved overføring (TLS 1.2 eller høyere), tilgangskontroll med individuelle kontoer, gjennomgang av tilgang minst hver 12. måned, mulighet for gjenoppretting, årlig sikkerhetsgjennomgang, ikke offentlig URL uten tilgangskontroll, sikker filoverføring/API, ikke ukryptert e-post, loggføring (min. 6 måneder).Kilde: Vedlegg C Instruks for behandling, punkt C.2 «Informasjonssikkerhet»
• Underleverandør: Databehandler kan kun bruke underleverandører som behandlingsansvarlig har forhåndsgodkjent skriftlig; innhent godkjenning minst 30 dager før engasjering.Kilde: 3. Vedlegg 3 Databehandleravtale, punkt 7 «Bruk av underleverandør» og Vedlegg B «Underleverandører»
• Overføring utenfor EØS: kan kun skje etter dokumentert instruks; i dette oppsettet er all behandling på vegne av oppdragsgiver innen EØS, og overføring til tredjeland krever gyldig overføringsgrunnlag og varsling i forkant.Kilde: 3. Vedlegg 3 Databehandleravtale, punkt 8 «Overføring til tredjeland...»; Vedlegg C «C.6 Instruks for overføring...»
• Bistand ved registrertes henvendelser: Databehandler skal bistå med å identifisere og om nødvendig slette relevante pseudonymiserte opplysninger ved henvendelser berørt data (innen 5 virkedager).Kilde: Vedlegg C «C.3 Bistand til den Behandlingsansvarlige», punkt a
• Varsling og bistand ved brudd: Databehandler skal varsle behandlingsansvarlig innen 24 timer etter kjennskap og bistå med informasjon for melding til Datatilsynet.Kilde: 3. Vedlegg 3 Databehandleravtale, punkt 10 «Underretning om brudd...»; Vedlegg C C.3 b
• Sletting/tilbakeføring: Ved opphør skal databehandler levere tilbake alle personopplysninger og slette kopier, med mindre lov krever oppbevaring.Kilde: 3. Vedlegg 3 Databehandleravtale, punkt 11 «Sletting og returnering av opplysninger»
• Oppbevaringsperiode/sletteprosedyrer for pseudonymiserte data oversendt: oppbevares i kontraktsperioden + 12 måneder for revisjons/verifikasjon, deretter slettes; skriftlig bekreftelse ved avslutning.Kilde: Vedlegg C «C.4 Oppbevaringsperiode/sletteprosedyrer»
• Revisjon/inspeksjon: Databehandler skal stille nødvendig informasjon til rådighet for etterlevelse og muliggjøre revisjoner/inspeksjoner; tilsynsmyndigheter kan gis adgang til lokaler ved legitimasjon.Kilde: 3. Vedlegg 3 Databehandleravtale, punkt 12 «Revisjon»; Vedlegg C C.7
• Operatøren skal følge kommunal regulering om plassering og parkering, inkludert dedikerte parkeringsplasser og forbudssoner.Kilde: V3_2.1 Bilag 2.1 Kravmatrise, krav nr. 1
• Operatøren skal forholde seg til oppdaterte geofence-reguleringer (endringer/varslinger) fra AtB med frist minst neste arbeidsdag med mindre annet fremgår.Kilde: V3_2.1 Bilag 2.1 Kravmatrise, krav nr. 2-3
• Operatøren skal ha løsning for lade- og parkeringsinfrastruktur i Stjørdal: enten bruke eksisterende infrastruktur eller tilby alternativ løsning med tilsvarende funksjonalitet/kapasitet/dekning; ved bruk av eksisterende infrastruktur dekker operatør kostnader til nødvendig kjøretøytilpasning.Kilde: V3_2.1 Bilag 2.1 Kravmatrise, krav nr. 4
• Trafikksikker drift: tiltak for å hindre bruk i påvirket tilstand, regelmessig kontroll/reparasjon/vedlikehold, rutiner/utstyr/teknologi for rask respons ved ulykker/hendelser, ikke sjenerende lyd (alarmvarsling automatisk deaktivert 22.00–09.00 natt til lørdager/søndager/helligdager).Kilde: V3_2.1 Bilag 2.1 Kravmatrise, krav nr. 4-6 og 8
• Fortløpende fjerne/flytte kjøretøy på eget initiativ: utenfor tillatte plasser, til hinder for fremkommelighet, veltet/ødelagt/forsøpling, eller når må fjernes ved kommunal drift/vinterdrift/rengjøring/veiarbeid eller nødsituasjoner (brann/vannlekkasje).Kilde: V3_2.1 Bilag 2.1 Kravmatrise, krav nr. 9
• Materiellkrav: fast automatisk lysanlegg, funksjonalitet for å stå oppreist (f.eks. støtte), tydelig merking med firmanavn/kontakt og unik ID (manuelt og digitalt) i samsvar med kommunal forskrift, tåle norske klimaforhold, utslippsfrie kjøretøy, og diskré merking med oppdragsgivers logo (klistremerke).Kilde: V3_2.1 Bilag 2.1 Kravmatrise, krav nr. 10-15
• Digital løsning/geo-fence: opplåsing via mobilapplikasjon, GPS med mulighet for regulering av fart/parkering/bruksområde via geofencing, oppdatering av egne apper/systemer med fastsatte reguleringer fra AtB og kommuner.Kilde: V3_2.1 Bilag 2.1 Kravmatrise, krav nr. 16-18
• Sanntidsvisning i AtB-app: operatøren skal levere GBFS-data til Enturs Mobility API iht. gjeldende spesifikasjoner.Kilde: V3_2.1 Bilag 2.1 Kravmatrise, krav nr. 19
• Brukergrensesnitt: én app for alle kjøretøy, rask registrering/app-laste og oppstart, start av tur innen få sekunder med nærliggende kjøretøy, visning av dedikerte parkeringsplasser og tilgjengelige kjøretøy, supportfunksjon (chat e.l.), og samtykke i appen via egenerklæring.Kilde: V3_2.1 Bilag 2.1 Kravmatrise, krav nr. 20-26
• Rapportering av bruksdata: dele nødvendige datasett for turbaserte utbetalinger med Oppdragsgiver og Impact Market iht. Vedlegg 2 (turdata og kjøretøytilgjengelighet).Kilde: V3_2.1 Bilag 2.1 Kravmatrise, krav nr. 28
• Rapportering for sosial avkastning: dele nødvendige datasett for brukerundersøkelsesdata med Oppdragsgiver og Impact Market iht. Vedlegg 2 punkt 3; funksjonalitet skal være klar innen juli; alternativ løsning til Rider Survey-API aksepteres hvis funksjonelt tilsvarer utsending av spørreundersøkelse til brukere ved sluttført tur.Kilde: V3_2.1 Bilag 2.1 Kravmatrise, krav nr. 29
• Pris: operatøren skal ta betalt for alle reiser; minimumspris minst 10 NOK og maksimumpris ikke over operatørens gjennomsnittlige markedspris i andre byer; dersom medlemskap brukes, skal medlemskapet ikke selges til lavere pris enn minimumspris i andre byer.Kilde: V3_2.1 Bilag 2.1 Kravmatrise, krav nr. 30

• Databehandleravtalen inneholder plasserholdere for databehandlerens navn/org.nr./adresse/land som ikke er spesifisert i teksten (MACROBUTTON-felter).
• Kravmatrisens innhold er angitt som Ja/nei-minimumskrav, men det fremgår ikke hvilke konsekvenser som gir avvisning utover generell formulering (avvisning av registrering ved manglende oppfyllelse).
• Vedlegg C spesifiserer prosedyrer for tilgangskontroll (12-månedlig), men eksakt intervall for «tidsintervall» i konfidensialitetsdelen vises ikke eksplisitt der; antas dekket av vedlegg C.

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 Vedlegg 2 «Krav til rapportering av data fra operatører», punkt 1 (Turdata): Når dere beskriver regelen om «maksimalt 4 turer per unike bruker per dag som kvalifiserer for insentiver», ber vi dere bekrefte hvilke felt dere forventer at vi bruker for å identifisere «unik bruker» (f.eks. user_ID før pseudonymisering) og hvordan dag-avgrensingen skal tolkes (lokal tid/UTC, tidsone).

   Hvorfor det er verdt å spørre: Leverandøren må prise og designe korrekt datalogikk for kvalifisering til insentiver (telle-/avgrensingsregler).

   Kilde: Vedlegg 2, punkt 1 Turdata (regel om 4 turer per unik bruker per dag og anonymisert RiderID).

2. I Vedlegg 2, punkt 2 (Data for tilgjengelighet av kjøretøy) og Appendiks 2: Dere skriver at tidsstempel gjelder «mellom 12:00–13:00 CET» og at det leveres én rad per dag for foregående måned. Kan dere spesifisere nøyaktig hvilket tidsstempel/interval vi skal bruke i CSV (skal vi rapportere ett tidspunkt, f.eks. 12:00:00 CET, eller et intervall/regel for hvordan «kl. 12:00 hver dag» måles)?

   Hvorfor det er verdt å spørre: Avklarer konkret format og målelogikk som påvirker implementering og datakvalitet.

   Kilde: Vedlegg 2, punkt 2 Data for tilgjengelighet av kjøretøy; Appendiks 2 Datafelt for kjøretøytilgjengelighet.

3. I Vedlegg 2, punkt 3 (Brukerundersøkelsesdata) og Appendiks 3 (Rider Survey API): Dere skriver at «ImpactMarket kontrollerer sampling logic» og at sampling kan gi «mellom hver 10. og 100. tur» avhengig av segmenter. Ber dere om å beskrive hvilke «definerte incentive segments» (vehicle type, geografi, tidsvindu osv.) dere benytter, og hvordan vi som operatør kan forutsi forventet undersøkelsesvolum til budsjettering/kapasitetsplanlegging.

   Hvorfor det er verdt å spørre: Forutsigbarhet for hvor mange trip-end eventer som blir til faktiske undersøkelser påvirker drift, kost og kapasitet.

   Kilde: Appendiks 3, punkt 4.1 Sampling & Survey Decision og punkt 4.2/4.3 Sampling Control.

4. I Vedlegg 2, punkt 3 og Appendiks 3: API-et returnerer «show_survey = true/false». Kan dere bekrefte krav til feilhåndtering og responstider (f.eks. timeout, retry-policy) dersom RiderSurvey API ikke svarer, er utilgjengelig, eller returnerer feil?

   Hvorfor det er verdt å spørre: Operatøren trenger en tydelig integrasjons- og driftsprosess for å unngå tapte undersøkelser og uklar etterlevelse.

   Kilde: Appendiks 3, punkt 4.2 API & Technical Flow (samt formulering om responstidskrav).

5. I Vedlegg 2, punkt 1 og Appendiks 1 (Turdata): CSV skal inneholde «alle turer som er startet innenfor områdene som omfattes av open house-ordningen den siste måneden». Ber dere bekrefte hvordan «områdene» bestemmes teknisk (f.eks. ved koordinatgrenser/polygoner/geo-fence), og om vi skal bruke samme geofence som brukes for insentiv-kvalifisering.

   Hvorfor det er verdt å spørre: Korrekt avgrensning av datasett påvirker både rapportering og eventuell avviks-/avvisningsrisiko.

   Kilde: Vedlegg 2, punkt 1 Turdata (avgrensning av turer innen områdene) og Appendiks 1 Datafelt for turdata.

6. I Vedlegg 3 Databehandleravtale: Dere har en standardavtale med plasserholdere for databehandlerens navn/organisasjonsnummer/adresse/land (MACROBUTTON-felter). Hvilken utfylt versjon forventer dere at leverandøren signerer (skal leverandøren selv fylle inn alle plasserte felter), og finnes det en standard prosess for innsendelse av endelig signert databehandleravtale før/etter kontraktsinngåelse?

   Hvorfor det er verdt å spørre: Avklarer praktisk dokumenthåndtering og reduserer risiko for feil signering/forbehold.

   Kilde: Vedlegg 3 Databehandleravtale (partspunkter for Databehandler med MACROBUTTON-plasserholdere).

7. I Bilag 2.1 Kravmatrise (minimumskrav), krav nr. 29 (GBFS data til Enturs Mobility API i tråd med gjeldende spesifikasjoner): Hvilke konkrete «gjeldende spesifikasjoner» gjelder for denne konkurransen, og skal vi levere GBFS-data via Enturs Mobility API som del av leveransen uten ekstra lisens-/tilknytningskost for oss?

   Hvorfor det er verdt å spørre: Konkretiserer integrasjonskrav og kost/forutsetninger knyttet til Entur/GBFS.

   Kilde: Bilag 2.1 Kravmatrise, krav nr. 19 (sanntid i AtB-appen via GBFS til Enturs Mobility API).

8. I Bilag 2.1 Kravmatrise, krav nr. 29–30 og prisregler: Krav nr. 30 sier at enkeltturer skal ha minimumspris på minst 10 NOK og maksimumspris som ikke overstiger operatørens gjennomsnittlige markedspris i andre byer, og at medlemskap ikke kan selges til lavere pris enn minimumspris. Kan dere bekrefte (1) hvordan «gjennomsnittlig markedspris i andre byer» skal beregnes (periode, hvilke byer, vekting), og (2) om dette er ment som en etterprøvbar kontroll i kontraktsperioden eller kun et tilbudsprisgrunnlag?

   Hvorfor det er verdt å spørre: Uklar beregningsmetode for markedspris og medlemskapspriser påvirker kommersiell strategi og etterlevelsesrisiko.

   Kilde: Bilag 2.1 Kravmatrise, krav nr. 30 «Pris».

9. I Bilag 2.1 Kravmatrise, krav nr. 2 om geo-fence-soner: Dere skriver at kommunene kan innføre/endrer soner, og at sonene kan innebære forbud/annen regulering. Hvilke endringer forventes å kunne komme, og hvilke responstider skal vi legge til grunn for oppdatering av vår løsning (f.eks. kart-/geo-fence-oppdatering i app og/eller kjøretøy), gitt at kr. 3 sier «frist for iverksettelse vil være minst neste arbeidsdag» dersom ikke annet fremgår?

   Hvorfor det er verdt å spørre: Avklarer endringshåndtering og operasjonelle kostnader/servicenivå ved løpende regelverksendringer.

   Kilde: Bilag 2.1 Kravmatrise, krav nr. 2 (geo-fence-reguleringer) og krav nr. 3 (oppdateringer fra AtB).