Att kravställa en AI-lösning är att före avtal specificera inte bara vad lösningen ska göra, utan hur den hanterar er data, vem som bär vilket ansvar, vad som loggas och hur ni lämnar avtalet med er data.
Digg och IMY:s nationella riktlinjer för generativ AI från januari 2025 har en del om att köpa generativ AI enligt lagen om offentlig upphandling. Säljer ni till offentlig sektor är den läsningen relevant även för er. Privata företag omfattas däremot inte av LOU och köper AI genom vanliga avtal, utan ett regelverk som tvingar fram ordning. Den här guiden är skriven för det läget.
En bra AI-beställning ställer fyra frågor före avtal: vad gör lösningen med vår data, vem ansvarar för vad, vad kan vi granska och hur ser vägen ut ur avtalet?
Vilka funktionskrav är rimliga att ställa?
Funktionslistan är den lätta delen. Den blir mer värd om ni kravställer i verksamhetstermer, inte tekniktermer: ett krav som "systemet ska hantera våra 40 vanligaste ärendetyper med minst 95 procents korrekt sortering, mätt på våra egna historiska ärenden" ger er något att testa mot, medan "modern AI-funktionalitet" ger leverantören tolkningsföreträde. Kräv också att acceptanstestet körs på er data och inte på leverantörens demodata, eftersom demodata är utvalda för att fungera medan era ärenden innehåller undantagen. Varför piloten ska köras på verklig data beskrivs i AI-pilot för produktion.
Vad ska ni kräva kring data och DPA?
Här avgörs vad som händer med er information. Tre frågor ska ha skriftliga svar innan något signeras.
- Träning: används era prompter, dokument eller utdata för att träna leverantörens modeller? Kräv nej som utgångsläge. Hos flera stora leverantörer gäller det redan för företagstjänster, till exempel för Anthropics kommersiella tjänster och modellerna i Microsoft Foundry enligt deras dokumentation i oktober 2026, men tillägg och mindre aktörer varierar.
- Geografi och underbiträden: var behandlas data, och vilka underleverantörer ingår i kedjan? En AI-tjänst är ofta flera bolag i lager, och kedjan är det som räknas, inte logotypen överst. Varför lagring och behandling är två olika frågor beskrivs i EU AI Act och GDPR. Omfattas ni av cybersäkerhetslagen (2025:1506), som gäller sedan den 15 januari 2026, är säkerhet i leveranskedjan dessutom en av de säkerhetsåtgärder lagen kräver.
- Lagring och loggar: hur länge sparar leverantören era prompter och svar, och kan ni själva få ut loggarna vid en incident eller granskning?
Behandlar leverantören personuppgifter åt er, vilket den gör så fort namn eller e-postadresser finns i underlaget, ska ett personuppgiftsbiträdesavtal enligt GDPR artikel 28 täcka just detta. Vad avtalet minst ska innehålla står i FAQ:n nedan.
Vem bär ansvaret enligt AI-förordningen?
EU:s AI-förordning delar ut roller: leverantören som utvecklar systemet bär ett ansvar, ni som använder det i verksamheten bär ett annat. I den svenska lydelsen heter er roll tillhandahållare, på engelska deployer. Låter ni bygga en lösning som tas i drift under ert namn är ni normalt själva leverantör. Vitsen med att veta det vid kravställningen är att avtala om gränssnittet: vem informerar användarna enligt transparenskraven i artikel 50, som gäller sedan den 2 augusti 2026, vem dokumenterar vad, och vem agerar om systemet visar sig vara högrisk när kraven för högrisksystem i bilaga III börjar tillämpas den 2 december 2027 enligt ändringsförordningen (EU) 2026/1744? Vilken roll ni får i olika upplägg, och vad som följer av den, beskrivs i EU AI Act och GDPR.
Som startpunkt för avtalstexten finns EU:s modellklausuler. Den 5 mars 2025 publicerades på kommissionens plattform för offentliga köpare uppdaterade standardavtalsklausuler för AI-upphandling, MCC-AI, i en fullversion för högrisksystem, en lättare version för övrig AI och en kommentar, som också finns på svenska. De är skrivna för offentliga köpare och tänkta som bilaga till ett huvudavtal, eftersom de enligt kommentaren inte reglerar till exempel immateriella rättigheter, betalning eller ansvar. För ett SME utan egen jurist på AI-avtal är de ändå ett bra underlag att ge sitt ombud. Vid större avtal hör en jurist hemma i processen, och guiden ni läser ersätter inte den granskningen.
Hur bygger ni in exit från början?
Exitfrågan känns pessimistisk att ställa innan avtalet är signerat. Ställ den ändå, i fyra delar. I vilket format exporteras er data, era konfigurationer och er historik? Vad kostar uttaget, i pengar och i leverantörens medverkan? Hur länge finns data kvar hos leverantören efter avslut, och hur raderas den bevisligen? Och om lösningen bygger på en viss underliggande modell: vad händer den dag modellen byts eller pensioneras? Arkitekturen påverkar svaret mer än avtalsprosan. Lösningar där affärslogiken ligger i er miljö och modellen nås genom utbytbara standardgränssnitt åldras väl. Lösningar där allt av värde bor hos leverantören åldras som hyreskontrakt. Det är samma avvägning som i valet mellan att köpa, bygga i lågkod och skriva egen kod, som beskrivs i lågkod eller egen kod, fast i avtalsform. Tumregeln är enkel: ju svårare det är att beskriva en ordnad sorti, desto viktigare att förhandla den innan ni flyttar in, för efteråt är förhandlingsläget borta. Exit och driftstopp hör dessutom ihop, eftersom en plan för hur verksamheten klarar sig när leverantören inte svarar bygger på samma svar.
En sista praktisk punkt: kravställ förvaltningen samtidigt. Svarstider, vem som justerar när verksamheten ändras, vad som ingår i priset och vad som debiteras. De frågorna hör till driften efter lansering, men de avgörs i beställningen, och leverantörens svar på dem kan säga mer än demon. Läs också ansvarsbegränsningen. Det nya produktansvarsdirektivet, (EU) 2024/2853, räknar programvara som produkt och gäller produkter som släpps ut eller tas i bruk efter den 9 december 2026, men det ger ersättning till fysiska personer och undantar egendom och data som används yrkesmässigt. Ert företags egna förluster när en AI-lösning fallerar regleras alltså i första hand av avtalet.
Vad ändras när lösningen byggs åt er?
Kravlistan gäller oavsett om ni köper en färdig tjänst eller låter bygga en lösning. När Byron Calles bygger lösningen får ni dokumentation som gör att ni kan förvalta den själva, och frågorna om data, loggar och exit kan besvaras i designen i stället för i en förhandling i efterhand. Förstudien, AI-strategi, är första fasen i bygget och rätt tillfälle att ta fram kravlistan för ert flöde, och i utvecklingsfasen byggs och driftsätts lösningen. Boka ett samtal så går vi igenom vad ert flöde kräver.
Vanliga frågor
Vad ska ett DPA med en AI-leverantör innehålla?
Ett DPA, personuppgiftsbiträdesavtal, ska enligt GDPR artikel 28.3 ange vad behandlingen gäller, hur länge den pågår, dess art och ändamål, vilka typer av personuppgifter och registrerade som berörs och era rättigheter och skyldigheter. Avtalet ska också slå fast att leverantören bara behandlar uppgifterna enligt era dokumenterade instruktioner, även vid överföring till tredjeland, att personalen har tystnadsplikt, att säkerheten uppfyller artikel 32, att underbiträden bara anlitas med ert tillstånd och på samma villkor, att leverantören hjälper er med de registrerades begäranden, att uppgifterna raderas eller lämnas tillbaka när avtalet upphör och att ni får den information som behövs för granskning. En standardmall kan uppfylla allt detta utan att svara på frågorna om träning, geografi och loggar i checklistan.
Vem äger koden när en AI-lösning byggs på beställning?
Det avgörs av avtalet. Enligt 40 a § upphovsrättslagen övergår upphovsrätten till ett datorprogram till arbetsgivaren när en anställd skriver det i tjänsten, men regeln gäller arbetstagare och inte uppdragstagare. Skriver en konsult eller leverantör koden åt er stannar rätten hos dem, om avtalet inte säger något annat. Skriv därför in äganderätt eller en tydlig nyttjanderätt till kod, promptar, konfiguration, testdata och dokumentation, och lista vilka av leverantörens återanvända komponenter som följer med under egen licens. Språkmodellen i botten äger ni i regel inte, den används på licens från modelleverantören, vilket är ännu ett skäl att hålla den utbytbar.
