Hvordan velge leverandør for AI-implementering: sjekkliste med 20 spørsmål og avtalepunkter (AI Act, GDPR, IP, akseptkriterier)

Forskjellen mellom en AI-implementering som gir målbar effekt og et prosjekt som stopper ved en presentasjon, ligger sjelden i teknologien. Den ligger i hvordan partneren behandler data, hvordan resultatet måles, og hva dere faktisk skriver inn i avtalen. Denne teksten er en liste med spørsmål til de første møtene med leverandøren – og en liste med punkter som bør inn i avtalen før prosjektet starter.

Dette er ikke juridisk rådgivning; avtalebestemmelser bør vurderes av advokat, særlig for systemer med høy risiko etter AI Act.

Viktigste konklusjoner

• Start med problemet, ikke modellen. En god partner spør først om prosess, data og forventet resultat – og først deretter om teknologistakken.
• Data avgjør resultatet. Spør om datarevisjon, tilgang, rettigheter og hvor dataene vil bli behandlet.
• En AI-avtale er ikke en vanlig programvareavtale. Den må dekke roller etter AI Act, databehandleravtale etter GDPR, eierskap til kode, prompter, konfigurasjoner og modellvekter, akseptansekriterier basert på metrikker og kostnader for bruk av modeller.
• Akseptanse er statistikk, ikke en knapp. Kriterier defineres på et testsett, med kvalitetsgrenser, svartid og kostnad per forespørsel.
• Planlegg exit. Dokumentasjon, overlevering og byttbarhet av modell er punkter som beskytter selskapet etter at samarbeidet avsluttes.

Hva en AI-implementering i en bedrift er

En AI-implementering er å bygge og drifte et system som bruker maskinlæringsmodeller eller språkmodeller (LLM) i en forretningsprosess: en assistent for ansatte eller kunder, en agent som utfører oppgaver i systemene, en RAG-kunnskapsbase, en prediktiv modell. I de fleste forretningsprosjekter bygger man ikke egne modeller fra bunnen; man bruker ferdige modeller via API eller open-weight-modeller og kobler dem med virksomhetens data og systemer. Derfor teller partnerens kompetanse først og fremst i integrasjoner, data, sikkerhet og effektmåling.

Tre pilarer for å vurdere en partner

Teknologi og data

Før du spør om pris, sjekk hvordan selskapet jobber med data: om de gjør revisjon av kilder, hvordan de rydder i data, hvordan de overfører tilgangsrettigheter fra kildesystemer til AI, hvordan de velger modell (kostnad, kvalitet, behandlingssted) og om de kan bytte den uten ombygging. En partner som straks foreslår å trene en egen modell, bør kunne begrunne hvorfor en ferdig modell med RAG ikke er nok.

Forretning og måling

En implementering uten discovery-fase (hva måler vi, hva er dagens nivå, hva regnes som suksess) ender i funksjoner ingen bruker. En god partner foreslår en pilot på én prosess og reelle data, med måling før og etter.

Jus og sikkerhet

AI Act gjelder trinnvis fra 2024 (forbud og AI-kompetanse fra februar 2025, åpenhet fra august 2026, høyrisikosystemer fra desember 2027). GDPR gjelder fullt ut. Partneren bør vite hvilken rolle den har (leverandør eller iverksetter etter AI Act, databehandler etter GDPR) og hva det betyr for avtalen.

Varselsignaler og beste praksis

Sjekkliste: 20 spørsmål til selskapet som implementerer AI

Erfaring

1. Kan dere vise et AI-system som kjører i produksjon hos en kunde – med tall? Se etter casestudier med metrikker (tid, kostnad, inntekt), ikke beskrivelser.
2. Hvilke problemer oppsto i tidligere implementeringer, og hvordan løste dere dem? Svaret viser om partneren snakker om risiko før den inntreffer.
3. Har dere erfaring fra vår bransje? Data i fintech, helse eller produksjon har ulike krav til sikkerhet og compliance.
4. Har dere overtatt systemer etter andre leverandører og integrert AI med legacy-systemer? De fleste selskaper bygger ikke fra scratch.

Data og arkitektur

1. Hvordan ser datarevisjonen ut før implementering? Kilder, kvalitet, hull, rettigheter.
2. Hvordan velger dere modell, og tillater arkitekturen å bytte den ut? Spørsmål om avhengighet til én leverandør.
3. Hvordan begrenser dere hallucinations? RAG på verifiserte kilder, sitering av kilder, kvalitetstester av svar, avslag på å svare ved manglende data.
4. Hvordan overfører dere tilgangsrettigheter fra kildesystemer til AI? Brukeren skal kun se det vedkommende har tilgang til.
5. Hvordan tester dere et system der svarene er ikke-deterministiske? Testsett, metrikker, regresjonstester etter hver endring av modell eller prompt.
6. Hvem og hvordan overvåker kvaliteten etter produksjonssetting? Logger, metrikker, varsler, plan for finjustering eller modellbytte.

Sikkerhet og jus

1. Hvor vil dataene våre fysisk behandles, og av hvilke aktører? Modellleverandørens sky, kundens sky, kundens infrastruktur; liste over underbehandlere.
2. Kan virksomhetens data brukes til å trene leverandørens modeller? Forventet svar: nei, basert på kommersiell avtale med modellleverandøren.
3. Hvordan sikrer dere etterlevelse av GDPR? Databehandleravtale, dataminimering, vurdering av personvernkonsekvenser (DPIA) ved behov, retten til sletting.
4. Hvilken rolle har dere og vi etter AI Act? Leverandør av system eller iverksetter; risikokategori; hva det betyr for dokumentasjon og tilsyn.
5. Hvilke sikringstiltak bruker dere på data i prompter og svar? Filtre for sensitive data, logging, tilgangskontroll, sikkerhetstester (inkludert prompt injection).

Samarbeid og kostnader

1. Hvordan definerer dere en pilot, og hva blir resultatet? Omfang, data, metrikker, beslutning om skalering.
2. Hvordan bryter dere ned prisen? Bygging, bruk av modeller (ved estimert antall forespørsler), drift og videreutvikling. Én sum uten oppdeling er et varselsignal.
3. Hvilke forretningsmetrikker skal vi følge opp? Tidsbesparelse, kostnad per sak, konvertering, inntekt; målt før og etter.
4. Hvem konkret skal jobbe i prosjektet og i hvilken arbeidsmodell? Dedikert team, utvidelse av vårt team, prosjekt med fast omfang; tilgang til arkitekt.
5. Hva får vi til slutt, og hvordan ser overleveringen ut? Kode, dokumentasjon, prompter, konfigurasjoner, testsett; mulighet for drift hos et annet team.

Elementer i en avtale om AI-implementering

1. Roller og ansvar etter AI Act

• Avklar hvem som er leverandør av systemet (utvikler og bringer det i omsetning), og hvem som er iverksetter (bruker det i egen virksomhet). Hvis systemet utvikles på bestilling under kundens merke, kan kunden være leverandør; avtalen bør si det eksplisitt.
• Klassifisering av systemets risiko i avtalen eller vedlegg; ved høy risiko: hvem som har ansvar for teknisk dokumentasjon, logging, menneskelig tilsyn og samsvarsvurdering.
• Åpenhet: systemet informerer brukeren om at vedkommende kommuniserer med AI; generert innhold merkes, i tråd med art. 50.
• AI-kompetanse (art. 4): opplæring av kundens team som del av leveransen – ikke et tillegg.
• Varsling av hendelser: prosedyre og frister for å informere kunden om systemfeil og sikkerhetshendelser.

2. GDPR og data

• Databehandleravtale (art. 28 GDPR) med partneren og liste over underbehandlere (inkludert modellleverandører) med rett til å protestere mot endringer.
• Behandlingssted og regioner (EU/EØS), regler for overføring utenfor EØS.
• Forbud mot å trene leverandørens modeller på kundens data, bekreftet i kommersiell avtale med modellleverandøren.
• Minimering og anonymisering av data før sending til modellen; filtre for sensitive data.
• Sletting av data: arkitekturen (RAG i stedet for trening på personopplysninger) skal gjøre det mulig å slette en persons data uten å bygge om modellen; loggretensjon (for høyrisikosystemer minst 6 måneder etter AI Act).
• Vurdering av personvernkonsekvenser (DPIA) og, ved høy risiko for bestemte iverksettere, vurdering av konsekvenser for grunnleggende rettigheter (art. 27 AI Act): hvem som utarbeider den.

3. Immaterielle rettigheter

• Overføring av økonomiske opphavsrettigheter (ikke lisens) til kode, datascript, dokumentasjon, prompter, konfigurasjoner, test- og evalueringssett – på alle utnyttelsesområder – ved betaling for milepælen.
• Modellvekter: hvis partneren finjusterer (fine-tuner) en modell, går rettighetene til vektene og treningsdataene over til kunden i den grad basismodellens lisens tillater. Eksterne leverandørers modeller (OpenAI, Anthropic, Google) kan ikke «kjøpes»; avtalen bør skille dette tydelig.
• Open-source-komponenter og open-weight-modeller: liste med lisenser og bekreftelse på samsvar med kommersiell bruk.
• Innhold generert av AI: opphavsrett verner menneskeskapte verk; avtalen bør regulere rettigheter til resultater og ansvar for bruken, uten å love vern som loven ikke gir.
• Partnerens knowhow: hvis partneren bringer inn egne komponenter eller produkter (f.eks. en ferdig kunnskapsbase), lisens på disse med rett til videre bruk etter avtalens slutt.

4. Akseptansekriterier

• Testsett avtalt før oppstart (representative forespørsler og forventede svar) som akseptansen måles på.
• Kvalitetsgrenser tilpasset oppgaven: for en kunnskapsbaseassistent f.eks. andel korrekte svar basert på kilder, andel avslag ved manglende data; for klassifisering: presisjon og recall; for ekstraksjon: felt-nøyaktighet.
• Svartid (f.eks. 95-persentilen) og kostnad per forespørsel ved antatt volum.
• Sikkerhet: tester for prompt injection og datalekkasje, tilgangskontroll.
• Menneskelig tilsyn: hvor menneske godkjenner resultat før det går til kunde eller system.
• Realismen: AI har en feilmargin; akseptanse definerer et akseptabelt nivå – ikke 100 %.

5. Kostnader, drift og exit

• Pris delt opp i bygging, bruk av modeller (med mekanisme for prisendringer hos leverandører) og drift.
• SLA for tilgjengelighet og responstid; kvalitetsmonitorering som en tjeneste – ikke et løfte.
• Byttbarhet av modell som arkitekturkrav nedfelt i avtalen.
• Exit-klausul: overlevering av kode, dokumentasjon, data og konfigurasjoner i avtalt format, overgangsperiode, støtte til nytt team.
• Konfidensialitet og revisjon: kundens rett til sikkerhets- og compliance-revisjon hos partner og underbehandlere.

Hvilken type partner du ser etter

Valget avhenger av startpunktet: én partner passer for å legge AI til eksisterende systemer (software house spesialisert på AI), en annen for et transformasjonsprogram i en stor virksomhet (stor integrator), en tredje for å rydde i data (analyseselskap). En oversikt over selskaper som implementerer AI i Polen gruppert etter partnertype finner du i vår TOP 10-rangering av selskaper som implementerer AI i Polen.

Startup House bygger AI-assistenter, agenter og RAG-kunnskapsbaser for mellomstore og store selskaper, også i regulerte bransjer (fintech, helse, cybersikkerhet). Løsningene kjører på verifiserte kundedata, i kundens sky, integrert med tilgangspolitikker; kundedata trener ikke offentlige modeller. I samsvar med ISO 27001. Eksempel: en kundeportal med innebygd AI for en cybersikkerhetsplattform med Fortune 500-kunder reduserte onboarding med 95 %, og overtakelse og modernisering av et logistikksystem for Omnipack senket utviklingskostnadene med 40 %.

Se også: AI Act: hva en implementerende virksomhet må gjøre · Casestudier fra Startup House

FAQ

Eget AI-team eller software house?

Rekruttering av et AI-team tar måneder, og den første implementeringen krever erfaring med integrasjoner og sikkerhet. For de fleste virksomheter fungerer modellen: start med en partner, bygg intern kompetanse parallelt (opplæring, produktansvarlig på innsiden), og ta gradvis over driften.

Hva koster en AI-implementering?

Avhenger av omfang. En pilot av en assistent på én prosess med ferdige modeller er et prosjekt på noen uker; implementering i flere avdelinger med integrasjoner er et prosjekt på måneder. Prisen bør deles i bygging, bruk av modeller og drift.

Gjør AI Act implementering vanskeligere?

For de fleste forretningsimplementeringer (minimal risiko) handler pliktene om ansattes kompetanse og åpenhet overfor brukere. Høyrisikosystemer (rekruttering, kredittscoring, biometri) krever dokumentasjon, logging og menneskelig tilsyn – med frist fra desember 2027. En partner som forstår dette, designer systemet for å møte kravene fra starten.

Hva er de største risikoene ved AI-implementering?

Data av lav kvalitet, manglende måling av nåsituasjon, manglende aksept i teamet, avhengighet av én modellleverandør – og en avtale som ikke regulerer eierskap til kode, prompter og data.

Hvor lenge varer en implementering?

En pilot på én prosess med reelle data kan bygges på noen uker. Produksjonssetting med integrasjoner og sikkerhet tar lenger tid og avhenger av antall systemer og datakvalitet.

Kan jeg bytte modellleverandør under eller etter prosjektet?

Ja, hvis arkitekturen legger til rette for det og avtalen krever det. Modeller endrer seg hver få måneder; et system der modellen er en utskiftbar komponent, krever ikke ombygging ved leverandørbytte.

Hvor begynner jeg når selskapet skal forberedes på å ta i bruk kunstig intelligens?

Start med å analysere forretningsprosesser, tilgjengelige data og ansattes behov. Velg deretter områder der AI-verktøy kan gi målbare gevinster, og pek ut en ansvarlig for prosjektet. Videre steg bør omfatte risikovurdering, pilot i et kontrollert miljø og gradvis utrulling av ny teknologi i daglig drift.

Hva er en AI-policy, og bør alle virksomheter ha en?

En AI-policy er et internt dokument som fastsetter regler for bruk av systemer for kunstig intelligens i organisasjonen. Den bør angi tillatte AI-verktøy, begrensninger for datainntasting, regler for verifisering av resultater og ansvar hos ansatte og administratorer. Den kan også regulere valg av leverandører, oppdatering av AI-modeller og varsling av hendelser. En god AI-policy støtter etterlevelse av juridiske krav og trygg implementering av AI-løsninger.

Er et register over AI-systemer obligatorisk i alle organisasjoner?

Ikke alle organisasjoner må føre et formelt register over alle AI-systemer. Et internt AI-register er likevel god risikostyringspraksis. Det bør inneholde navn på systemet, formål, leverandør, brukte data, risikokategori og ansvarlig person. For bestemte høyrisikosystemer gir EUs AI Act også registreringsplikter. Omfanget avhenger blant annet av organisasjonens rolle og bruksområdet.

Hvordan gjennomføre en risikovurdering før implementering av et AI-system?

Start risikovurderingen med å fastsette systemets formål, typer data som behandles og mulig påvirkning på enkeltpersoner og virksomheten. Analysen bør dekke informasjonssikkerhet, kvalitet på AI-resultater, feilede beslutninger, menneskelig tilsyn og potensielt forbudte praksiser. Det må også avklares om bruken kan klassifiseres som uakseptabel risiko eller høyrisikosystem etter AI Act. Risikovurdering er ikke et engangsdokument – den bør oppdateres når systemet endres.

Krever AI-implementering en vurdering av personvernkonsekvenser?

Vurdering av personvernkonsekvenser (DPIA) kreves etter GDPR når en bestemt type behandling sannsynligvis medfører høy risiko for fysiske personers rettigheter og friheter. Dette gjelder særlig enkelte former for profilering og automatiserte beslutninger. Bruk av kunstig intelligens i seg selv utløser ikke automatisk plikt til DPIA. En DPIA erstatter ikke risikovurderingen som kreves etter AI Act – de dekker delvis ulike risikoer.

Hva betyr AI literacy, og hvilken opplæring bør ansatte få?

AI literacy er kompetansen som trengs for å bruke AI-systemer bevisst, sikkert og ansvarlig. Opplæringen bør omfatte muligheter og begrensninger ved AI-modeller, vern av personopplysninger, verifisering av svar og gjenkjenning av feil. Læringsmateriell bør tilpasses ansattes roller og hvordan AI-verktøy brukes i det daglige. Art. 4 i AI Act forutsetter tiltak som sikrer et tilstrekkelig nivå av AI-kompetanse hos leverandører og aktører som bruker systemene.

Hvem er leverandør og hvem er iverksetter av et AI-system etter AI Act?

Leverandør er den som utvikler et AI-system eller får det utviklet og bringer det i omsetning eller tar det i bruk under eget navn eller varemerke. Iverksetter bruker AI-systemet i sin virksomhet, utenom personlig og ikke-profesjonell bruk. Rollefordelingen har betydning for dokumentasjon, tilsyn, sikkerhet og plikter etter EUs regelverk. I bestemte situasjoner kan organisasjonen som implementerer løsningen, overta leverandørplikter.

Hvordan fungerer menneskelig tilsyn over AI, altså human in the loop?

Human in the loop er en modell der mennesket deltar i vurdering eller godkjenning av AI-resultater. Man kan kontrollere anbefalinger, rette feil og ta endelige beslutninger i situasjoner som krever ekstra kontroll. Dette er særlig viktig ved automatisering av prosesser som påvirker kunder, ansatte eller enkeltpersoner. Tilsynet må være reelt: medarbeideren må forstå systemets begrensninger, kunne bestride resultatet og ha nødvendige rettigheter til å gripe inn.

Teksten er informativ og utgjør ikke juridisk rådgivning. Rettslig status: oktober 2026 (AI Act etter Digital Omnibus, forordning 2026/1744).