Kravställa AI-lösning: avtal, DPA och exitstrategi

Historien kommer från ett verkligt uppdrag. Ett bolag hade köpt en AI-lösning för dokumenthantering: demon var imponerande, priset rimligt, avtalet tre sidor. Ett år senare ville de byta leverantör och upptäckte ordningen i den omvända änden: ingen rätt att exportera de konfigurationer och den historik som byggts upp, otydligt var datan fysiskt fanns, och ett personuppgiftsbiträdesavtal som visade sig vara leverantörens standardmall utan de svar deras revisor nu efterfrågade.

Inget av det var olagligt. Allt hade gått att undvika i beställningen.

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.

Det mesta som skrivs om AI-upphandling på svenska riktar sig till offentlig sektor, där Digg i sina nationella AI-riktlinjer från 2025 ger konkret vägledning kopplad till LOU. Säljer ni till offentlig sektor är den läsningen relevant även för er. Men de flesta SME köper AI som privata avtal, utan upphandlingsregler och därmed utan det ramverk som tvingar fram ordning. Den här guiden är för er. Handlar frågan snarare om vilken partner ni ska anlita än om avtalet finns våra sju frågor till AI-konsulten som komplement.

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, och den enda många hinner med. Två saker gör den mer värd. Kravställ i verksamhetstermer, inte tekniktermer: "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. Och kräv att acceptanstestet körs på er data, inte leverantörens demodata. Skillnaden mellan de två är ofta hela skillnaden, som vi konstaterat i varför piloter bör köras på verklig data.

Vad ska ni kräva kring data och DPA?

Här sitter de dyraste misstagen. 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 standard. Företagsplaner hos etablerade leverantörer ger detta, 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. Resonemanget känns igen från vår genomgång av datasuveränitet och AI.
• 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?

Behandlas personuppgifter, och det gör det i de flesta verkliga flöden, ska ett personuppgiftsbiträdesavtal finnas som täcker just detta. Se FAQ:n nedan för minimikraven.

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, förordningens "deployer", bär ett annat. Vitsen med att veta det vid kravställningen är att avtala om gränssnittet: vem informerar användare enligt transparenskraven som gäller sedan augusti 2026, vem dokumenterar vad, och vem agerar om systemet omklassas när högriskkraven börjar tillämpas i december 2027?

Det finns numera färdig hjälp. EU-kommissionen publicerade i mars 2025 uppdaterade modellavtalsklausuler för AI-upphandling, MCC-AI, i en fullversion för högrisksystem och en lättare för övrig AI. De är skrivna för offentliga köpare men uttryckligen tänkta att kunna anpassas klausul för klausul, och för ett SME utan jurist på AI-avtal är de en utmärkt startpunkt att ge sitt ombud. För det ska sägas: 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 är beställningens mest försummade, för den känns pessimistisk att ställa i förälskelsefasen. 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 bygga eller köpa-beslutet, fast i avtalsform. Vår tumregel är därfö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.

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 säger ofta mer än demon. En leverantör som svarar konkret på exit- och förvaltningsfrågor har varit med förut. En som viftar bort dem har inte det, eller hoppas att ni inte har det.

Vill ni ha hjälp att beställa rätt?

Vi sitter regelbundet på beställarsidan i AI-projekt och hjälper er med kravlista, leverantörsutvärdering och testupplägg, oavsett om lösningen sedan byggs av oss eller någon annan. En AI-strategi ger er dessutom prioriteringen av vad som över huvud taget är värt att köpa. Boka ett samtal innan nästa avtal ska signeras. Stockholm är basen för teamet, men engagemangen sträcker sig över hela Sverige.