Bygga eget system med AI? Läs det finstilta först.

Med AI-verktyg som Lovable bygger du en app på en helg. Men verktygets egna villkor säger nej till hälsouppgifter, och lagens krav på ett system för patientdata följer inte med.

Det går fort nu. En kväll beskriver du för en AI vad du vill ha: en bokningssida, ett formulär för hälsodeklarationen, en lista över dagens patienter. På morgonen finns en app med inloggning och databas. Ingen programmerare, ingen offert, ingen väntan.

Vi förstår lockelsen. Vi använder själva AI varje dag, och verktygen är imponerande på riktigt.

Men en app som fungerar är inte samma sak som en app som får användas för patientuppgifter. Skillnaden syns inte på skärmen. Den står i avtalen, i lagen och i vad som händer den dag något går fel.

Det finstilta som ingen läser

Lovable är ett av de mest använda verktygen för att bygga appar med AI, och bolaget är svenskt. Vi tar det som exempel, men samma frågor gäller Bolt, Replit och liknande verktyg. Så här står det i Lovables egna villkor:

Det är inget fel på Lovable. Villkoren är ärligt skrivna och säger precis vad tjänsten är till för. Men i tandvården är nästan allt hälsouppgifter: vem som är patient, vilka besök hen har haft, vad som har gjorts i munnen. Och personnumret är ett identitetsnummer.

Verktyget säger själv att det inte är gjort för patientuppgifter. Den som ändå lägger dem där har tagit på sig hela ansvaret, utan ett avtal som täcker det.

Avtalet är ingen formalitet. När någon annan behandlar personuppgifter åt kliniken kräver GDPR ett personuppgiftsbiträdesavtal som täcker behandlingen (artikel 28). Ett avtal som förbjuder just de uppgifterna täcker dem inte. Då saknar kliniken det avtal lagen kräver, och det är kliniken som bär ansvaret.

Var hamnar uppgifterna?

Databasen i Lovable kan placeras i Europa. Men har ingen valt något annat bestämmer verktyget själv, utifrån var du råkar befinna dig när databasen skapas.

Det väljer den region som ligger närmast, och efteråt går databasen inte att flytta. Ber du verktyget lägga till inloggning en kväll på semester i Thailand kan databasen alltså hamna i Asien. Och där blir den kvar.

Databasen är dessutom bara en del. Som standard får verktygets AI-agent läsa, ändra och radera innehållet i databasen utan att fråga först. Det agenten läser skickas vidare till AI-modeller, och var de körs lovar villkoren inget om. Bara på företagsabonnemanget Enterprise går det att låsa AI-anropen till EU.

Det är skillnaden mellan att kunna välja och att ha valt. I ett system byggt för vården ska svaret på frågan ”var finns uppgifterna?” stå i avtalet. Det ska inte bero på var någon satt med datorn.

En app som skriver om sig själv

Med ett AI-verktyg ändras appen varje gång någon skriver en ny instruktion. Det är därför det går så fort. Och det är därför det är riskabelt.

Socialstyrelsens föreskrifter säger att ett system för patientuppgifter ska testas innan det tas i drift. Testerna bör göras åtskilt från den skarpa miljön och utan riktiga personuppgifter, och ändringar bör planeras, bedömas och godkännas innan de går ut (HSLF-FS 2016:40, 3 kap. 10 §). Det är motsatsen till att be en AI ”fixa det där” en sen kväll.

Sommaren 2025 byggde en amerikansk investerare en app med AI-verktyget Replit. Trots uttryckliga instruktioner om att inte röra något raderade AI-agenten hela den skarpa databasen, med uppgifter om över tusen chefer och företag. Sedan påstod den att databasen inte gick att återställa. Det gick, som tur var. Först efteråt började Replit skilja på databaser för utveckling och drift.

Byt ut kontaktlistan mot en patientlista, så förstår du varför reglerna finns.

Det som inte syns förrän det är för sent

AI skriver kod som fungerar, men inte alltid kod som är säker. I en studie från säkerhetsföretaget Veracode 2025 innehöll AI-skriven kod en känd säkerhetsbrist i 45 procent av fallen.

Våren 2025 gick två utvecklare igenom drygt 1 600 publicerade appar byggda med Lovable. Var tionde, 170 appar, lät vem som helst läsa uppgifter som borde ha varit skyddade, bland annat namn och e-postadresser. Bristen fick ett officiellt säkerhetsnummer (CVE-2025-48757). Lovable invände att varje kund själv ansvarar för att skydda uppgifterna i sin app.

Det är just poängen. Ansvaret ligger hos den som byggde.

Ibland behövs inte ens en bugg. Apoteket och Apohem hade Metas spårningspixel på sina webbplatser. När bolagen slog på en ny delfunktion i pixeln skickades uppgifter till Meta om vad kunderna hade köpt, bland annat självtester och produkter mot specifika hälsobesvär. Integritetsskyddsmyndigheten (IMY) beslutade 2024 om sanktionsavgifter på 37 respektive 8 miljoner kronor. En egenbyggd bokningssida med en spårningspixel kan på samma sätt avslöja vem som bokat vad.

Vad lagen kräver av ett system för patientuppgifter

Kraven gäller oavsett om systemet är köpt eller hembyggt. Socialstyrelsen säger det rakt ut: vårdgivaren ska se till att kraven uppfylls vid upphandling eller egenutveckling av system för personuppgifter (HSLF-FS 2016:40, 3 kap. 9 §). Bygger du själv är det alltså du som ska kunna visa att allt det här finns:

Inget av det här blir till för att man ber en AI om det. Det måste byggas, provas och skötas, varje dag, år efter år.

Och föreslår verktyget diagnoser eller behandlingar kan det räknas som en medicinteknisk produkt. Då gäller EU:s förordning om medicintekniska produkter (MDR), med krav på bland annat riskhantering och dokumentation.

Lagen står inte still

Ett system för vården blir aldrig färdigt, eftersom reglerna runt det inte blir det. Tre exempel:

Varje ändring betyder att någon måste läsa, tolka, bygga om och testa, helst innan den börjar gälla. Hos en leverantör är det någons jobb. I ett hembygge är det ingens, tills IMY eller IVO frågar.

Räkna på hela kostnaden

Ett abonnemang på ett AI-verktyg kostar några hundralappar i månaden. Därför blir jämförelsen fel. Den verkliga kostnaden för ett eget system är allt runt omkring:

Den sista punkten underskattas mest. Ett hembygge är ofta en enda persons verk, och koden är skriven av en AI som ingen annan har följt. När den personen slutar försvinner kunskapen om hur systemet fungerar.

Och går något fel är det kliniken som får förklara sig, för IMY och för patienterna.

Det är klart att det känns smart att bygga själv när en AI gör jobbet på en kväll. Men en klinikägare ska lägga sin tid på patienterna, inte på att bevaka nya föreskrifter och hålla ett eget system lagligt år efter år. Att bygga går fort. Ansvaret för patienternas uppgifter tar aldrig slut.

Amir Ahmadi Head of Growth på Qliora

Därför köper man ett system

Att köpa ett system är inte att lämna ifrån sig ansvaret. Kliniken är fortfarande personuppgiftsansvarig. Men man köper det som inte går att bygga på en helg: ett system som är gjort för vårdens regler från början, ett avtal som täcker uppgifterna och ett team vars jobb är att hålla allt uppdaterat när reglerna ändras.

Så har vi byggt Qliora:

Bygg gärna. Men inte med patienternas uppgifter.

AI-verktygen är fantastiska för att testa en idé, göra en skiss eller bygga något som inte rör patienter. Använd dem. Men så fort patientuppgifter kommer in i bilden har frågan bytt karaktär. Då handlar det inte längre om vad som går att bygga, utan om vad du kan stå för när IMY, IVO eller en patient frågar.

Fem frågor att ställa till varje system som ska hantera patientuppgifter, köpt eller eget:

  1. Får vi enligt avtalet lägga in hälsouppgifter och personnummer här?

  2. I vilket land lagras uppgifterna, och i vilket land körs AI:n?

  3. Kan vi se vem som öppnade en viss patient, och när?

  4. Vem uppdaterar systemet när reglerna ändras?

  5. Vad händer med uppgifterna om leverantören, eller den som byggde, försvinner?

Kan ni inte svara på varje fråga, med ett ja eller ett namn, vet ni var arbetet börjar. Ställ gärna samma frågor till oss.

Vill du se hur Qliora hanterar patientuppgifter i praktiken? Läs mer på vår sida om säkerhet eller boka en kostnadsfri demo.

Källor

Uppgifterna om Lovable bygger på bolagets villkor och dokumentation som de såg ut i oktober 2026. Texten är en översikt, inte juridisk rådgivning.