Så väljer du rätt leverantör för AI-implementering: checklista med 20 frågor och avtalsvillkor (AI-förordningen, GDPR, IP, acceptanskriterier)

Skillnaden mellan en AI‑implementering som ger mätbar effekt och ett projekt som stannar vid en presentation ligger sällan i tekniken. Den ligger i hur partnern hanterar data, hur resultat mäts och vad ni skriver under i avtalet. Den här texten är en lista med frågor för de första mötena med leverantören och en lista med klausuler som bör finnas i avtalet innan projektet startar.

Detta är inte juridisk rådgivning; avtalsvillkor bör granskas av jurist, särskilt för system med hög risk enligt AI Act.

Viktigaste slutsatserna

• Börja med problemet, inte med modellen. En bra partner frågar först om process, data och förväntat resultat och först därefter om teknikstacken.
• Data avgör resultatet. Fråga om datarevision, åtkomst, behörigheter och var data kommer att behandlas.
• Ett AI‑avtal skiljer sig från ett mjukvaruavtal. Det måste omfatta roller enligt AI Act, biträdesavtal enligt GDPR, äganderätt till kod, prompts, konfigurationer och modellvikter, acceptanskriterier baserade på metrik samt kostnader för modellernas användning.
• Godkännande handlar om statistik, inte om en knapp. Acceptanskriterier definieras på ett testset, med trösklar för kvalitet, svarstid och kostnad per fråga.
• Planera för exit. Dokumentation, överlämning och utbytbarhet av modellen skyddar bolaget efter att samarbetet avslutats.

Vad är en AI‑implementering i ett företag

En AI‑implementering är att bygga och driftsätta ett system som använder maskininlärningsmodeller eller språkmodeller (LLM) i företagets processer: en assistent för medarbetare eller kunder, en agent som utför uppgifter i systemen, en RAG‑kunskapsbas, en prediktionsmodell. I de flesta affärsprojekt bygger man inte egna modeller från noll; man använder färdiga modeller via API eller open‑weight‑modeller och kopplar dem till företagets data och system. Därför är partnerns kompetens i integration, data, säkerhet och effektmätning det som räknas mest.

Tre pelare för att utvärdera en partner

Teknologi och data

Innan du frågar om pris, kontrollera hur företaget arbetar med data: gör de en granskning av källor, hur städar de data, hur för de över behörigheter från källsystem till AI, hur väljer de modell (kostnad, kvalitet, plats för behandling) och kan de byta modell utan ombyggnad. En partner som direkt föreslår att träna en egen modell bör kunna motivera varför en färdig modell med RAG inte räcker.

Affär och mätning

En implementering utan discovery‑fas (vad mäter vi, nuläge, vad räknas som framgång) slutar i funktioner som ingen använder. En bra partner föreslår en pilot för en process och verkliga data, med mätning före och efter.

Juridik och säkerhet

AI Act gäller stegvis från 2024 (förbud och AI‑kompetens från februari 2025, transparens från augusti 2026, system med hög risk från december 2027). GDPR gäller fullt ut. Partnern ska veta i vilken roll den uppträder (leverantör eller införande part enligt AI Act, personuppgiftsbiträde enligt GDPR) och vad det innebär för avtalet.

Varningssignaler och god praxis

Checklista: 20 frågor till företaget som implementerar AI

Erfarenhet

1. Kan ni visa ett AI‑system som kör i produktion hos kund, med siffror? Sök case studies med metrik (tid, kostnad, intäkt), inte beskrivningar.
2. Vilka problem uppstod i tidigare implementationer och hur löste ni dem? Svaret visar om partnern tar upp risker innan de inträffar.
3. Har ni erfarenhet i vår bransch? Data i fintech, hälso‑ och sjukvård eller tillverkning har olika krav på säkerhet och regelefterlevnad.
4. Har ni tagit över system efter andra leverantörer och integrerat AI med legacy‑system? De flesta företag bygger inte från noll.

Data och arkitektur

1. Hur ser er datarevision ut före implementation? Källor, kvalitet, luckor, behörigheter.
2. Hur väljer ni modell och tillåter arkitekturen att byta den? Fråga om beroende av en enda leverantör.
3. Hur begränsar ni hallucinationer? RAG på verifierade källor, citat av källor, tester av svarskvalitet, vägran att svara vid databrist.
4. Hur för ni över behörigheter från källsystem till AI? Användaren ska bara se det den har åtkomst till.
5. Hur testar ni ett system vars svar är icke‑deterministiska? Testset, metrik, regressionstester efter varje ändring av modell eller prompt.
6. Vem och hur övervakar kvaliteten efter driftsättning? Loggar, metrik, larm, plan för fin‑tuning eller modellbyte.

Säkerhet och juridik

1. Var kommer våra data fysiskt att behandlas och av vilka parter? Moln hos modellleverantören, kundens moln, kundens infrastruktur; lista över underbiträden.
2. Kan företagets data användas för att träna leverantörens modeller? Förväntat svar: nej, baserat på ett affärsavtal med modellleverantören.
3. Hur säkerställer ni efterlevnad av GDPR? Biträdesavtal, dataminimering, konsekvensbedömning (DPIA) vid behov, rätt att radera data.
4. I vilken roll enligt AI Act är ni, och i vilken är vi? Systemleverantör eller införande part; riskkategori; vad det betyder för dokumentation och tillsyn.
5. Vilka skydd tillämpar ni för data i prompts och svar? Filter för känsliga data, loggning, åtkomstkontroll, säkerhetstester (inklusive prompt injection).

Samarbete och kostnader

1. Hur definierar ni en pilot och vad blir dess resultat? Omfattning, data, metrik, beslut om skala.
2. Hur bryter ni ner prissättningen? Bygge, modellanvändning (vid uppskattat antal frågor), drift och utveckling. En klumpsumma utan uppdelning är en varningssignal.
3. Vilka affärsmetrik följer vi? Tidsbesparing, supportkostnad, konvertering, intäkt; mätt före och efter.
4. Vem arbetar konkret i projektet och i vilken modell? Dedikerat team, utökning av vårt team, fast scope‑projekt; tillgång till arkitekt.
5. Vad får vi vid avslut och hur ser överlämningen ut? Kod, dokumentation, prompts, konfigurationer, testset; möjlighet till förvaltning av ett annat team.

Avtalets delar för en AI‑implementering

1. Roller och ansvar enligt AI Act

• Definiera vem som är systemleverantör (utvecklar och släpper på marknaden) och vem som är införande part (använder i sin verksamhet). Om systemet byggs på uppdrag under kundens varumärke kan kunden vara leverantör; avtalet ska säga det uttryckligen.
• Riskklassning av systemet i avtalet eller bilaga; vid hög risk: vem ansvarar för teknisk dokumentation, loggning, mänsklig övervakning, överensstämmelsebedömning.
• Transparens: systemet informerar användaren om att hen interagerar med AI, genererat innehåll märks, i enlighet med art. 50.
• AI‑kompetens (art. 4): utbildning av kundens team som en del av leveransen, inte ett tillägg.
• Incidentrapportering: process och tidsfrister för att informera kunden om systemfel och säkerhetsincidenter.

2. GDPR och data

• Biträdesavtal (art. 28 GDPR) med partnern och lista över underbiträden (inklusive modellleverantörer) med rätt att invända mot ändringar.
• Behandlingsplats och regioner (EU/EES), regler för överföring utanför EES.
• Förbud mot att träna leverantörens modeller på kundens data, bekräftat i affärsavtal med modellleverantören.
• Minimering och anonymisering av data före sändning till modellen; filter för känsliga data.
• Radering av data: arkitekturen (RAG i stället för träning på personuppgifter) ska möjliggöra radering av en persons data utan att bygga om modellen; loggretention (för system med hög risk minst 6 månader enligt AI Act).
• Konsekvensbedömning (DPIA) och, vid hög risk för vissa införande parter, bedömning av konsekvenser för grundläggande rättigheter (art. 27 AI Act): vem tar fram den.

3. Immaterialrätt

• Överlåtelse av ekonomiska upphovsrätter (inte licens) till kod, dataskript, dokumentation, prompts, konfigurationer, test‑ och evalueringsdataset, på alla användningsområden, vid betalning för etappen.
• Modellvikter: om partnern fin‑tunar modellen (fine‑tuning) övergår rättigheterna till vikter och träningsdata till kunden i den utsträckning basmodellens licens medger. Externa leverantörsmodeller (OpenAI, Anthropic, Google) kan inte ”köpas”; avtalet ska klargöra detta.
• Open‑source‑komponenter och open‑weight‑modeller: lista med licenser och bekräftelse på förenlighet med kommersiell användning.
• AI‑genererat innehåll: upphovsrätt skyddar mänskliga verk; avtalet bör reglera rätt till resultat och ansvar för användningen, utan att utlova skydd som lagen inte ger.
• Partnerns know‑how: om partnern tillför egna komponenter eller produkter (t.ex. en färdig kunskapsbas), licens för dessa med rätt till fortsatt användning efter avtalets slut.

4. Acceptanskriterier

• Ett överenskommet testset före start (representativa frågor och förväntade svar) som acceptans mäts på.
• Kvalitetsnivåer anpassade till uppgiften: för en kunskapsbaserad assistent t.ex. andel korrekta och källunderbyggda svar, andel vägranden vid databristsituationer; för klassificering: precision och recall; för extraktion: fältnoggrannhet.
• Svarstid (t.ex. 95:e percentilen) och kostnad per fråga vid antagen volym.
• Säkerhet: tester av prompt injection och datainläckage, åtkomstkontroll.
• Mänsklig övervakning: var en människa godkänner resultatet innan det når kund eller system.
• Realism: AI har felmarginal; acceptans definierar en acceptabel nivå, inte 100 %.

5. Kostnader, drift och exit

• Prisuppdelning i bygge, modellanvändning (med mekanism för leverantörers prisändringar) och drift.
• SLA för tillgänglighet och responstid; kvalitetsövervakning som tjänst, inte ett löfte.
• Utbytbarhet av modellen som arkitekturkrav inskrivet i avtalet.
• Exit‑klausul: överlämning av kod, dokumentation, data och konfigurationer i överenskommet format, övergångsperiod, stöd till nästa team.
• Konfidentialitet och revision: kundens rätt att revidera säkerhet och regelefterlevnad hos partner och underbiträden.

Vilken typ av partner passar dig

Valet beror på startläget: en partner passar för att lägga till AI i befintliga system (software house specialiserat på AI), en annan för ett transformationsprogram i en koncern (stor integratör), en tredje för att få ordning på data (analysföretag). En sammanställning av företag som implementerar AI i Polen, grupperad efter partnertyp, finns i vår ranking TOP 10 företag som implementerar AI i Polen.

Startup House bygger AI‑assistenter, agenter och RAG‑kunskapsbaser för medelstora och stora företag, inklusive reglerade branscher (fintech, healthcare, cybersäkerhet). Lösningarna körs på verifierad kunddata, i kundens moln, integrerade med åtkomstpolicyer; kunddata tränar inte publika modeller. ISO 27001 compliant. Exempel: en kundportal med inbyggd AI för en cybersäkerhetsplattform som betjänar Fortune 500‑kunder kortade onboarding med 95 %, och övertagande och modernisering av ett logistiskt system för Omnipack sänkte utvecklingskostnaderna med 40 %.

Se även: AI Act: vad en implementerande part måste göra · Case studies Startup House

FAQ

Eget AI‑team eller software house?

Att rekrytera ett AI‑team tar månader, och den första implementeringen kräver erfarenhet av integrationer och säkerhet. För de flesta företag fungerar modellen: starta med en partner, bygg parallellt intern kompetens (utbildning, produktägare på företagets sida), ta successivt över förvaltningen.

Vad kostar en AI‑implementering?

Det beror på omfattningen. En pilot av en assistent för en process och färdiga modeller är ett projekt på några veckor; en implementering i flera avdelningar med integrationer är ett projekt på månader. Priset ska dela upp kostnaden för bygge, modellanvändning och drift.

Försvårar AI Act implementeringar?

För de flesta affärsimplementationer (minimal risk) handlar skyldigheterna om personalens kompetens och transparens mot användare. System med hög risk (rekrytering, kreditscoring, biometrik) kräver dokumentation, loggning och mänsklig övervakning, med start från december 2027. En partner som förstår detta designar systemet för att uppfylla kraven från början.

Vilka är de största riskerna med en AI‑implementering?

Låg datakvalitet, ingen mätning av nuläge, bristande acceptans i teamet, beroende av en modellleverantör och ett avtal som inte reglerar äganderätt till kod, prompts och data.

Hur länge tar implementeringen?

En pilot för en process och verkliga data kan byggas på några veckor. Produktionssättning med integrationer och säkerhet tar längre tid och beror på antalet system och datakvaliteten.

Kan jag byta modellleverantör under eller efter projektet?

Ja, om arkitekturen förutsätter det och avtalet kräver det. Modeller förändras var tredje till sjätte månad; ett system där modellen är en utbytbar komponent kräver ingen ombyggnad vid leverantörsbyte.

Var börjar man för att förbereda företaget för att införa artificiell intelligens?

Börja med att analysera affärsprocesser, tillgänglig data och medarbetarnas behov. Välj sedan områden där AI‑verktyg kan ge mätbara effekter, och utse en ansvarig för projektet. Nästa steg bör omfatta riskbedömning, pilot i kontrollerad miljö och gradvis utökning av användningen i det dagliga arbetet.

Vad är en AI‑policy och bör alla företag ta fram en?

En AI‑policy är ett internt dokument som fastställer regler för hur AI‑system används i organisationen. Den bör ange tillåtna AI‑verktyg, begränsningar för datainmatning, regler för verifiering av resultat samt ansvar för medarbetare och administratörer. Den kan också reglera hur leverantörer väljs, hur AI‑modeller uppdateras och hur incidenter rapporteras. En väl genomarbetad AI‑policy stödjer regelefterlevnad och ett säkert införande av AI‑lösningar.

Är ett register över AI‑system obligatoriskt i varje organisation?

Inte alla organisationer måste föra ett formellt register över alla AI‑system. Ett internt AI‑register är dock god riskhanteringspraxis. Det bör innehålla systemets namn, syfte, leverantör, använda data, riskkategori och ansvarig person. För vissa hög‑risk‑system föreskriver EU:s AI Act även registreringskrav. Omfattningen beror bland annat på organisationens roll och användningen av systemet.

Hur genomför man en riskbedömning före implementering av ett AI‑system?

Börja riskbedömningen med att fastställa systemets syfte, typ av data som behandlas och möjlig påverkan på fysiska personer och verksamheten. Analysen ska beakta informationssäkerhet, AI‑resultatens kvalitet, felaktiga beslut, mänsklig övervakning och potentiellt förbjudna praktiker. Fastställ också om användningen kan klassas som otillåten risk eller hög‑risk‑system enligt AI Act. Riskbedömningen är inte ett engångsdokument — den ska uppdateras i takt med att systemet förändras.

Kräver en AI‑implementering en konsekvensbedömning för dataskydd?

En konsekvensbedömning för dataskydd, dvs. DPIA, krävs enligt GDPR när en viss typ av behandling sannolikt leder till hög risk för fysiska personers rättigheter och friheter. Detta gäller särskilt vissa former av profilering och automatiserat beslutsfattande. Enbart användning av AI innebär inte automatiskt en skyldighet att ta fram en DPIA. Konsekvensbedömningen ersätter inte den riskanalys som krävs enligt AI Act, eftersom mekanismerna delvis avser olika risker.

Vad betyder AI literacy och vilka utbildningar bör medarbetare genomgå?

AI literacy innebär kompetens att använda AI‑system medvetet, säkert och ansvarsfullt. Utbildningar bör omfatta modellernas möjligheter och begränsningar, skydd av personuppgifter, verifiering av svar samt igenkänning av fel. Utbildningsmaterial ska anpassas till medarbetarnas roller och hur AI‑verktyg används i vardagen. Art. 4 AI Act förutsätter åtgärder som säkerställer en adekvat nivå av AI‑kompetens hos leverantörer och användare.

Vem är leverantör och vem är tillämpande part enligt AI Act?

Leverantör är den part som utvecklar ett AI‑system eller låter det utvecklas och släpper det på marknaden eller tar det i bruk under eget namn eller varumärke. Tillämpande part använder ett AI‑system inom sin verksamhet, utanför privat och icke‑professionell användning. Rollfördelningen är viktig för dokumentation, tillsyn, säkerhet och skyldigheter enligt EU‑rätten. I vissa situationer kan den implementerande organisationen ta över leverantörens skyldigheter.

Hur fungerar människa i loopen, det vill säga human in the loop?

Human in the loop är en modell där en människa deltar i bedömningen eller godkännandet av AI‑resultat. Personen kan granska rekommendationer, korrigera fel och fatta slutliga beslut i situationer som kräver extra kontroll. Detta är särskilt viktigt vid automatisering av processer som påverkar kunder, medarbetare eller fysiska personer. Övervakningen ska vara reell: medarbetaren måste förstå systemets begränsningar, kunna ifrågasätta resultatet och ha befogenhet att ingripa.

Texten är informativ och utgör inte juridisk rådgivning. Rättsläge: oktober 2026 (AI Act efter Digital Omnibus, förordning 2026/1744).