<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Kaldryn: Blogg, forskning och EU-regelverk</title>
    <link>https://lemon-sea-08a033b03.7.azurestaticapps.net/</link>
    <atom:link href="https://lemon-sea-08a033b03.7.azurestaticapps.net/feed.xml" rel="self" type="application/rss+xml" />
    <description>Privat, självhostad AI från Sverige. Texter om suverän AI, lokal driftsättning och EU-efterlevnad.</description>
    <language>sv-SE</language>
    <lastBuildDate>Tue, 28 Jul 2026 17:48:31 GMT</lastBuildDate>
    <item>
      <title>Varför vi satte ett datacenter i ett skåp</title>
      <link>https://lemon-sea-08a033b03.7.azurestaticapps.net/blog/varfor-vi-satte-ett-datacenter-i-ett-skap/</link>
      <guid isPermaLink="true">https://lemon-sea-08a033b03.7.azurestaticapps.net/blog/varfor-vi-satte-ett-datacenter-i-ett-skap/</guid>
      <pubDate>Thu, 02 Jul 2026 09:00:00 GMT</pubDate>
      <category>Blogg</category>
      <category>Produkt</category>
      <description>Tanken bakom Kaldryn One, och varför framtidens företags-AI för de flesta är en tyst svart låda i hörnet av kontoret, inte en större molnräkning.</description>
      <content:encoded><![CDATA[<p>När vi visar Kaldryn One är den vanligaste reaktionen inte en fråga om tokens per sekund eller kontextfönster. Det är någon som pekar på lådan och säger: <em>”Är det här allt?”</em></p>
<p>Ja, det är allt. En svart apparat i storlek med ett skåp, tystare än kontorets kylskåp, inkopplad i ett vanligt vägguttag och er nätverksswitch. Inuti den finns hela ert företags AI-förmåga. Chatt över era egna dokument, över tvåhundra utvalda öppna modeller, ett OpenAI-kompatibelt API, och inte en enda byte som lämnar huset.</p>
<h2>Problemet med att ”bara använda molnet”</h2>
<p>För många team fungerar moln-AI alldeles utmärkt. Men varje samtal vi haft med sjukhus, advokatbyråer, banker och myndigheter i Norden följde samma mönster: folk fick verkligt värde ur konsumentverktygen, ledningen ville ha den förmågan på riktigt, och varenda väg dit gick genom någon annans infrastruktur, på någon annans villkor.</p>
<ul>
<li>Priset skalar med antalet anställda. En AI-licens per person är en skatt på att växa.</li>
<li>Datan lämnar huset. Hur bra avtalet än är, så lämnar en prompt som skrivs in i en molnassistent fysiskt era lokaler.</li>
<li>Beroendet växer. Modeller läggs ner, villkor skrivs om, priser ändras, och era arbetsflöden är byggda på alltihop.</li>
</ul>
<p>För reglerade verksamheter räcker ofta punkt två för att avsluta diskussionen. Vårt svar är inte ”lita på oss i stället”. Det är: skicka inte datan någonstans över huvud taget.</p>
<h2>Begränsningar skapar produkter</h2>
<p>Vi gav oss själva tre krav för apparaten, och de formade allt:</p>
<ol>
<li><strong>Den ska bo på ett kontor, inte i en serverhall.</strong> Det satte ljudramen (under 38 dB, tystare än ett vanligt samtal), effektramen (ett vanligt vägguttag, ingen trefas) och storleken (skåp, inte rack).</li>
<li><strong>En IT-avdelning på en person ska kunna sköta den.</strong> Två sladdar, ström och ethernet. Den kommer färdigkonfigurerad, indexerar era dokument lokalt och betjänar teamet samma dag.</li>
<li><strong>Den ska fortsätta fungera med internet urdraget.</strong> Inte som ett partytrick, utan som grundantagande. Uppdateringar är något ni väljer att installera, inte något som händer er.</li>
</ol>
<div data-callout><p>Testet vi hela tiden återvände till: om ni drar ut nätverkskabeln ur väggen, vad fungerar fortfarande? För Kaldryn One är svaret: allt. Det är skillnaden mellan att äga sin AI och att hyra den.</p></div>
<h2>Vad ”ett datacenter” egentligen betyder för en firma med 30 anställda</h2>
<p>Uttrycket låter storslaget, men titta på vad en liten organisation faktiskt behöver av AI-infrastruktur: en assistent som kan sina dokument, ett privat API för verktygen den bygger, och en styrning en jurist kan skriva under. Det är inte ett hyperskaleproblem. Det får plats i en låda, GPU:er, lagring, modeller, sökning, adminkonsol, revisionslogg, allt.</p>
<p>En låda för en firma med trettio anställda. Rader av dem för ett datacenter. Plattformen är densamma oavsett, och det är precis poängen. Suveränitet ska inte vara en lyx för storföretag.</p>
<h2>Vad som kommer härnäst</h2>
<p>Vi delar mer av tänkandet bakom plattformen här på bloggen, de tekniska avvägningarna, vad som fungerar bra på en enda låda 2026, och vad vi hör från den reglerade delen av marknaden. För det djupare tekniska materialet finns referensarkitekturen och white papers om regelefterlevnad i <a href="/research/">vårt research-nav</a>. Och om ni hellre bara vill se lådan: <a href="/kaldryn-one/">möt Kaldryn One</a>.</p>]]></content:encoded>
    </item>
    <item>
      <title>AI-förordningens deadlines flyttades: vad 2026 års Digital Omnibus ändrade</title>
      <link>https://lemon-sea-08a033b03.7.azurestaticapps.net/eu-regulations/ai-forordningens-deadlines-flyttades-2026/</link>
      <guid isPermaLink="true">https://lemon-sea-08a033b03.7.azurestaticapps.net/eu-regulations/ai-forordningens-deadlines-flyttades-2026/</guid>
      <pubDate>Thu, 02 Jul 2026 09:00:00 GMT</pubDate>
      <category>EU-regelverk</category>
      <category>EU:s AI-förordning</category>
      <description>I mitten av 2026 sköt EU fram AI-förordningens deadlines för hög risk. Här är vad som flyttades, vad som inte gjorde det, och vad ni som tillhandahåller eller använder AI faktiskt bör göra åt saken.</description>
      <content:encoded><![CDATA[<p>Om ni byggde en efterlevnadsplan för 2026 kring den ursprungliga kalendern för AI-förordningen är delar av den nu inaktuella. I slutet av juni 2026 gav rådet sitt <a href="https://www.consilium.europa.eu/en/press/press-releases/2026/06/29/artificial-intelligence-council-gives-final-green-light-to-simplify-and-streamline-rules/">slutliga klartecken</a> till ett paket som EU har kallat Digital Omnibus, och en av sakerna det gör är att skjuta fram de tuffaste deadlinesen i <a href="https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng">AI-förordningen</a>. Värt att veta exakt vad som förändrades innan ni skriver om något.</p>
<h2>Vad som flyttades</h2>
<p>De två deadlines som flyttades är de för system med hög risk, som alltid skulle bli det tyngsta lyftet.</p>
<ul>
<li>Reglerna för fristående system med hög risk som räknas upp i bilaga III (tänk biometri, kritisk infrastruktur, rekrytering, kreditbedömning, tillgång till samhällsviktiga tjänster) skulle ha börjat tillämpas den 2 augusti 2026. De tillämpas nu från och med den 2 december 2027.</li>
<li>Reglerna för AI med hög risk som är inbyggd i reglerade produkter enligt bilaga I (medicintekniska produkter, maskiner och liknande) flyttades från den 2 augusti 2027 till den 2 augusti 2028.</li>
</ul>
<p>Huvudskälet är prosaiskt. De harmoniserade tekniska standarder som företag behöver för att faktiskt kunna visa överensstämmelse var försenade hos CEN och CENELEC, de europeiska standardiseringsorganen. Man kan inte begära att företag ska nå upp till en ribba som ännu inte har dragits. Så medlagstiftarna flyttade i stället fram ribbans deadline i tiden. Europaparlamentets egen <a href="https://www.europarl.europa.eu/news/en/press-room/20260316IPR38219/meps-support-postponement-of-certain-rules-on-artificial-intelligence">redogörelse</a> för utskottsomröstningen i mars beskriver logiken.</p>
<h2>Vad som inte flyttades</h2>
<p>Det är den här delen folk missar. Stora delar av AI-förordningen gäller redan, och inget av det senarelades.</p>
<p>Förbudet mot otillåtna användningar har gällt sedan den 2 februari 2025. Skyldigheten om AI-kunnighet i artikel 4, som säger att personal som använder AI-system behöver en grundläggande förståelse för dem, har gällt sedan samma datum. Skyldigheterna för AI-modeller för allmänna ändamål (GPAI) trädde i kraft den 2 augusti 2025, tillsammans med ramverket för styrning och sanktioner. Och transparensskyldigheterna i artikel 50, de som säger att ni måste tala om för människor när de pratar med en maskin och märka AI-genererat innehåll, gäller fortfarande från och med den 2 augusti 2026. De rördes inte.</p>
<div data-callout><p>Så om er reaktion på förseningen är ”bra, då har vi mer tid”, kontrollera vilken kategori er användning faktiskt hamnar i. En intern assistent som skriver utkast och sammanfattar är oftast inget system med hög risk enligt bilaga III över huvud taget. Vilket betyder att de deadlines som flyttades aldrig var era deadlines. Skyldigheten om AI-kunnighet och transparensreglerna, som inte flyttades, är det förmodligen.</p></div>
<h2>Sanktionerna är oförändrade, och de är stora</h2>
<p>Inget av detta mildrade tillsynssidan. Artikel 99 sätter fortfarande böter på upp till 35 miljoner euro eller 7 procent av den globala årsomsättningen för otillåtna användningar, upp till 15 miljoner euro eller 3 procent för de flesta andra överträdelser, och upp till 7,5 miljoner euro eller 1 procent för att lämna felaktig information till myndigheter. Ni kan läsa de exakta nivåerna i <a href="https://artificialintelligenceact.eu/article/99/">AI Act Explorer</a>. För ett medelstort företag är det procentsatserna som biter.</p>
<h2>Vad ni som använder AI faktiskt bör göra</h2>
<p>Skala bort kalenderbruset så blir att-göra-listan kort. Ta reda på var AI redan används i hela organisationen, inklusive de verktyg som ingen officiellt köpte in. Sortera in varje användning i en kategori: förbjuden, hög risk, begränsad risk (vilket mestadels betyder transparensskyldigheter) eller minimal. Se till att utbildningen i AI-kunnighet blir klar, eftersom den redan är försenad och är en av de billigaste rutorna att bocka av. Och för allt som ens skulle kunna vara hög risk, utse en ansvarig nu, för december 2027 kommer snabbare än det låter när standarder, dokumentation och processer för mänsklig tillsyn alla ska vara på plats först.</p>
<p>En tystare poäng. En stor del av bördan för den som använder AI handlar om bevis: att spara loggar, att fästa exakt den modellversion ni bedömde, att kunna säga vad systemet gör med en indata. Allt det är lättare när modellen körs på infrastruktur ni kontrollerar snarare än bakom en leverantörs API som kan ändras under fötterna på er. Suveränitet och regelefterlevnad är inte samma sak, men de rimmar.</p>
<p>Detta är allmän information, inte juridisk rådgivning. Omnibustexten höll fortfarande på att färdigställas i Europeiska unionens officiella tidning när detta publicerades, så bekräfta det slutliga förordningsnumret och eventuell nationell vägledning med er jurist innan ni agerar på det.</p>]]></content:encoded>
    </item>
    <item>
      <title>Molnpolicyn 2026 och CLOUD Act: vad staten just sa om molnet</title>
      <link>https://lemon-sea-08a033b03.7.azurestaticapps.net/eu-regulations/molnpolicyn-2026-och-cloud-act/</link>
      <guid isPermaLink="true">https://lemon-sea-08a033b03.7.azurestaticapps.net/eu-regulations/molnpolicyn-2026-och-cloud-act/</guid>
      <pubDate>Tue, 30 Jun 2026 09:00:00 GMT</pubDate>
      <category>EU-regelverk</category>
      <category>Datasuveränitet</category>
      <description>Sveriges första nationella molnpolicy erkänner beroendet av leverantörer utanför EU. Vad det betyder för er data, och varför on premise löser frågan.</description>
      <content:encoded><![CDATA[<p>Den 28 maj 2026 hände något som borde ha fått fler att lyfta på ögonbrynen. Regeringen antog Sveriges första nationella molnpolicy för offentlig förvaltning. Det är inte en teknisk detalj för IT avdelningen. Det är staten som för första gången skriver ner, svart på vitt, att Sverige är <a href="https://www.regeringen.se/pressmeddelanden/2026/05/ny-molnpolicy-ska-bidra-till-okad-digital-suveranitet-i-offentlig-forvaltning/">starkt beroende av leverantörer utanför EU</a>. När regeringen erkänner ett beroende offentligt, då har frågan flyttat från konsultrapporter till politik.</p>

<p>För er som hanterar känslig information, oavsett om ni är en myndighet, en region eller ett privat bolag med patientdata, personuppgifter eller affärshemligheter, är detta värt att förstå ordentligt. Vi går igenom vad policyn faktiskt säger, hur den hänger ihop med amerikansk lag och offentlighetsprincipen, och varför just den kombinationen gör on premise till ett rakt svar snarare än en nostalgisk reflex.</p>

<h2>Vad molnpolicyn faktiskt säger</h2>

<p>Civilminister Erik Slottner presenterade policyn som ett steg mot ökad digital suveränitet. Det viktiga är att den inte förbjuder amerikanska moln. Den gör något mer nyanserat. Den kräver att offentliga verksamheter gör <a href="https://www.regeringen.se/pressmeddelanden/2026/05/ny-molnpolicy-ska-bidra-till-okad-digital-suveranitet-i-offentlig-forvaltning/">riskbedömningar, använder öppna standarder, skriver tydliga avtal och tar fram exitplaner</a> så att de kan byta leverantör om de behöver. Post och telestyrelsen, PTS, ska stödja arbetet med att införa den.</p>

<p>Läs det där en gång till. Kravet på exitplaner finns där av en anledning. Det är själva erkännandet av problemet. Om ni behöver en plan för att kunna lämna en leverantör, då har ni redan konstaterat att ni sitter fast. Inlåsning är inte en teoretisk risk längre. Den är förutsättningen som policyn utgår ifrån. Och den som någon gång försökt migrera flera petabyte data och hundratals integrationer bort från en molnplattform vet att en exitplan på papper och en genomförd flytt är två väldigt olika saker.</p>

<h2>Offentlighetsprincipen och den amerikanska räckvidden</h2>

<p>Här blir det juridiskt intressant, och för svensk offentlig sektor helt centralt. Offentlighetsprincipen möter molnet genom sekretesslagstiftningen, offentlighets och sekretesslagen. Den 1 juli 2023 trädde en sekretessbrytande bestämmelse i kraft, OSL 10 kap. 2 a paragrafen, som infördes delvis just för att göra utkontraktering möjlig. Att en sådan bestämmelse behövdes säger något om hur känslig frågan är.</p>

<p>Myndighetssamverkan eSam har gått längre i sin analys. Deras hållning är att en sekretessbelagd uppgift som görs <a href="https://www.esamverka.se/vad-vi-gor/molnfragan.html">tekniskt tillgänglig för en leverantör kan betraktas som röjd</a>, alltså som ett avslöjande i lagens mening, även om ingen människa faktiskt har läst den. I samma analys lyfter eSam den amerikanska CLOUD Act från 2018 och övervakningslagen FISA 702. Poängen är att ett amerikanskt bolag kan tvingas lämna ut data oavsett var i världen servrarna står, vilket krockar med svensk sekretess.</p>

<p>Det ska sägas rakt ut att eSam inte stiftar lag. Deras vägledning är inflytelserik men inte bindande, och tolkningen är omtvistad. Vissa jurister menar att den är för strikt. Andra menar att den är rimlig försiktighet. Men oavsett var man landar juridiskt kvarstår själva spänningen. Så länge en extern leverantör har teknisk åtkomst till den känsliga uppgiften, så länge finns frågan där, och den behöver hanteras, dokumenteras och försvaras.</p>

<div data-callout><p>Kärnan i hela debatten är teknisk åtkomst, inte serverns fysiska adress. Ett datacenter i Stockholm som drivs av ett bolag under amerikansk jurisdiktion löser inte CLOUD Act frågan. Det som avgör är vem som juridiskt kan tvingas öppna dörren till era data.</p></div>

<h2>Bryssel drar åt samma håll</h2>

<p>Sverige är inte ensamt om att göra den här bedömningen. Bara några dagar senare, den 3 juni 2026, föreslog EU kommissionen en Cloud and AI Development Act som en del av ett större paket för teknisk suveränitet. Kommissionen konstaterar att ett <a href="https://digital-strategy.ec.europa.eu/en/policies/cloud-and-ai-development-act">överdrivet beroende av molnleverantörer utanför EU är en risk för Europas digitala autonomi</a>.</p>

<p>Förslaget skisserar fyra nivåer av molnsuveränitet, från L1 till L4. På den högsta nivån, L4, utesluts kontroll från bolag i tredjeland helt. Det är en tydlig signal om vart lagstiftaren är på väg. När både den svenska regeringen och EU kommissionen inom loppet av en vecka pekar på samma beroende och samma risk, då är det inte en tillfällig politisk stämning. Det är en riktning, och riktningen håller i sig oavsett vilken regering som sitter.</p>

<h2>Varför on premise gör frågan enkel</h2>

<p>Nu till det praktiska. Allt ovanstående, riskbedömningarna, exitplanerna, den sekretessbrytande bestämmelsen, eSams röjandeanalys, de fyra suveränitetsnivåerna, allt handlar i grunden om samma sak. Vad händer när er känsliga information passerar genom, eller görs tillgänglig för, en extern leverantör.</p>

<p>Ta bort den leverantören ur den känsliga kedjan, och de flesta av frågorna faller bort av sig själva. Det är det som on premise gör. När er AI och er data körs på hårdvara ni själva kontrollerar, i era egna lokaler eller i ett datacenter under er egen rättsliga kontroll, då finns det ingen extern part i den känsliga vägen. CLOUD Act biter inte, eftersom det inte finns något amerikanskt bolag som kan föreläggas att lämna ut något. Exitproblemet försvinner, eftersom ni inte behöver planera en flytt från en leverantör ni aldrig blev beroende av. Röjandefrågan förenklas dramatiskt, eftersom uppgiften aldrig gjordes tekniskt tillgänglig för någon utanför er kontroll.</p>

<p>Det är värt att vara ärlig med att on premise inte är gratis och inte passar allt. Det ställer krav på egen kompetens, på drift och på investeringar i hårdvara. För en del arbetsbelastningar är molnet fortsatt rätt val, och policyn förbjuder det inte. Men för det som verkligen är känsligt, patientjournaler, förundersökningar, personuppgifter under stark sekretess, affärskritiska modeller, där byter on premise ut en lång rad juridiska och avtalsmässiga risker mot en fråga om teknik och drift. Många upplever att den bytesaffären är enkel att stå för.</p>

<p>Det är precis den positionen Kaldryn är byggt kring. Vi levererar AI som körs där ni bestämmer, på er egen infrastruktur, utan att era data behöver lämna er kontroll. När staten nu ber offentlig sektor att fundera på beroenden, exitplaner och suveränitet, är vårt svar okomplicerat. Den bästa exitplanen är att aldrig ha checkat in.</p>

<p><em>Detta är en översiktlig genomgång och inte juridisk rådgivning. Regelverken är nya, tolkningarna utvecklas och det egna ansvaret för bedömning kvarstår. Rådgör alltid med egen jurist för er specifika situation.</em></p>]]></content:encoded>
    </item>
    <item>
      <title>Därför flyttar svenska verksamheter AI:n hem</title>
      <link>https://lemon-sea-08a033b03.7.azurestaticapps.net/blog/darfor-flyttar-svenska-verksamheter-ai-hem/</link>
      <guid isPermaLink="true">https://lemon-sea-08a033b03.7.azurestaticapps.net/blog/darfor-flyttar-svenska-verksamheter-ai-hem/</guid>
      <pubDate>Sat, 20 Jun 2026 09:00:00 GMT</pubDate>
      <category>Blogg</category>
      <category>Fältanteckningar</category>
      <description>Advokatbyråer, banker, kommuner och vården landar i samma slutsats: känsliga data och den AI som läser dem hör hemma innanför era egna väggar.</description>
      <content:encoded><![CDATA[<p>Det finns ett mönster vi ser om och om igen när vi pratar med svenska verksamheter, och det är inte drivet av teknikentusiasm. Det är drivet av ansvar. En advokat, en compliancechef på en bank, en IT-strateg i en kommun och en verksamhetsutvecklare inom vården sitter på helt olika stolar, men de kommer fram till samma sak: den känsligaste informationen, och den AI som ska läsa den, bör ligga innanför de egna väggarna. Inte för att molnet är ondskefullt. Utan för att var och en av dem bär ett konkret, juridiskt förankrat ansvar som pekar åt samma håll.</p>

<p>Vi tänkte gå igenom yrke för yrke, för det är där resonemanget blir skarpt. Det här är inga abstrakta principer. Det är regler ni redan lever under.</p>

<h2>Advokaterna: tystnadsplikten gäller alltid</h2>

<p>Sveriges advokatsamfund kom under 2025 med vägledning om generativ AI i advokatverksamhet, och den är läsvärd just för att den inte fastnar i panik eller hype. Kärnprincipen är enkel att formulera och obekväm att leva upp till: <a href="https://www.advokaten.se/tidigare-nummer/2024/nr-6-2024-argang-90/samfundet-vagleder-om-ai/">tystnadsplikten gäller alltid</a>. En advokat måste granska villkoren för det AI-verktyg som används, och måste undvika verktyg som återanvänder det som matas in.</p>

<p>Läs den meningen en gång till. Ni ska granska villkoren. Ni ska undvika verktyg som tränar på er indata. Hur många av de populära molntjänsterna klarar egentligen det testet, när ni läser det finstilta och inte marknadsföringssidan? När ett klientärende innehåller uppgifter som omfattas av tystnadsplikt, så räcker det inte att leverantören lovar att vara snäll. Ni behöver kunna bevisa att materialet aldrig lämnade er kontroll. Det är en väldigt annorlunda utgångspunkt än att lita på en användarpolicy som kan ändras med ett mejl.</p>

<h2>Finansbranschen: molnet är tillåtet, men tillsynen får aldrig blockeras</h2>

<p>Här vill vi vara ärliga, för myten att Finansinspektionen skulle förbjuda molnet är just en myt. FI har ingen principiell invändning mot moln. Men de har ett krav som förändrar spelplanen: era avtal får inte begränsa myndighetens möjlighet att utöva tillsyn, alltså rätten att granska och komma åt. <a href="https://www.fi.se/sv/bank/utlagd-verksamhet/">FI tillämpar EBA:s riktlinjer om utläggning</a>, och sedan DORA trädde i kraft den 17 januari 2025 behandlas molnleverantören uttryckligen som en tredjepartsleverantör av IKT-tjänster.</p>

<p>Vad betyder det i praktiken? Att ett vackert SLA inte hjälper er om leverantören sitter i en jurisdiktion där svenska tillsynsmyndigheter inte når in, eller där granskningsrätten är teoretisk. Ni är fortfarande ansvariga. Utläggning av drift flyttar inte ansvaret, den lägger bara till en beroendekedja ni måste kunna redovisa. Ju fler av de leden ni håller på egen mark, desto enklare blir hela DORA-historien att faktiskt genomföra. Vi har skrivit mer om det regulatoriska landskapet i våra <a href="/eu-regulations/">EU-genomgångar</a>.</p>

<div data-callout><p>Det gemensamma draget är inte att molnet är förbjudet. Det är att ansvaret aldrig flyttar. Advokaten, banken, kommunen och kliniken sitter kvar med notan om något går fel, oavsett vem som driftar servern. När ansvaret ändå stannar hos er, blir frågan enkel: varför inte behålla kontrollen också?</p></div>

<h2>Offentlig sektor: offentlighetsprincipen och en ny molnpolicy</h2>

<p>Den svenska offentliga sektorn lever med något som är näst intill unikt i världen, offentlighetsprincipen, och den ställer krav som inte översätts rent till en generisk molntjänst byggd för en helt annan rättsordning. En allmän handling ska kunna lämnas ut, spåras och hanteras enligt svenska regler, inte enligt villkoren i ett standardavtal skrivet på andra sidan Atlanten.</p>

<p>Och nu har staten satt ned foten på allvar. Den 28 maj 2026 antog regeringen en <a href="https://www.regeringen.se/pressmeddelanden/2026/05/ny-molnpolicy-ska-bidra-till-okad-digital-suveranitet-i-offentlig-forvaltning/">nationell molnpolicy</a> som slår fast att landet är för beroende av leverantörer utanför EU, och som kräver att verksamheter tar fram exitplaner. Läs det som en signal, inte som en detalj. När regeringen skriftligen konstaterar att beroendet är för stort och begär utträdesplaner, då är riktningen utstakad för varje myndighet, region och kommun som ännu inte börjat tänka i de banorna.</p>

<h2>Vården: patientsekretessen tål inga genvägar</h2>

<p>Inom hälso- och sjukvården är logiken kanske allra mest självklar. Patientsekretessen är inte förhandlingsbar, och de data som en klinisk AI skulle vilja läsa hör till det mest integritetskänsliga som finns. Journaltext, provsvar, diagnoser. Att skicka den typen av material genom en tjänst där ni inte fullt ut kontrollerar vart det tar vägen är inte en teknisk risk, det är en förtroendefråga gentemot varje enskild patient. Här handlar det inte om att optimera, utan om att inte svika.</p>

<h2>Fyra yrken, en riktning</h2>

<p>Ser ni det? Advokatsekretess, FI-tillsyn, offentlighetsprincipen, patientsekretess. Fyra helt olika regelverk, fyra olika yrkesetiker, och ändå exakt samma slutsats: behåll den känsliga informationen, och den AI som läser den, innanför era egna väggar. Det är inte en slump. Det är vad som händer när juridiskt ansvar möter en teknik som är hungrig på just era mest skyddade data.</p>

<p>Och Sverige är inte ensamt. Det pågår en tydlig europeisk rörelse i samma riktning. Danmarks digitaliseringsministerium <a href="https://therecord.media/denmark-digital-agency-microsoft-digital-independence">lämnade Microsoft av suveränitetsskäl i juni 2025</a>. Den tyska delstaten Schleswig-Holstein flyttar <a href="https://www.theregister.com/2025/10/15/schleswig_holstein_open_source/">tiotusentals datorer till öppen källkod</a>. Bakgrunden är en siffra som borde få fler att lyfta på ögonbrynen: ungefär 90 procent av Europas digitala infrastruktur körs på leverantörer utanför Europa. Det är inte en självständig position att förhandla ifrån, det är ett beroende.</p>

<p>Vi ska vara raka med er om vad detta inte betyder. Det betyder inte att ni ska bygga allt själva, hyra in ett serverrum och anställa fem drifttekniker. Det vore att byta ett problem mot ett annat. Poängen är kontroll över rätt sak: att era mest skyddade data, och modellen som bearbetar dem, ligger på infrastruktur ni faktiskt bestämmer över, med tillsyn ni kan bevisa och utan träning på ert material. Det är precis den avvägningen vi byggt <a href="/kaldryn-one/">Kaldryn One</a> kring.</p>

<p>Om ni sitter på en av de här stolarna, advokat, compliance, offentlig förvaltning eller vård, så känner ni förmodligen redan igen argumentet. Ni har läst er egen branschs vägledning. Ni vet vad ansvaret väger. Frågan är inte längre om känslig AI hör hemma innanför väggarna. Den frågan är i praktiken redan besvarad, av era egna regelverk. Frågan är bara när ni flyttar in den.</p>]]></content:encoded>
    </item>
    <item>
      <title>Digital suveränitet i EU: en fältguide för 2026</title>
      <link>https://lemon-sea-08a033b03.7.azurestaticapps.net/research/digital-suveranitet-i-eu-2026/</link>
      <guid isPermaLink="true">https://lemon-sea-08a033b03.7.azurestaticapps.net/research/digital-suveranitet-i-eu-2026/</guid>
      <pubDate>Thu, 18 Jun 2026 09:00:00 GMT</pubDate>
      <category>Rapporter</category>
      <category>Suverän AI</category>
      <description>Under 2025 och 2026 vaknade Europa upp inför sitt beroende av ett fåtal utländska molnleverantörer. En fältguide till lagarna, pengarna och de faktiska besluten som följer.</description>
      <content:encoded><![CDATA[<p>Under större delen av det senaste decenniet var "digital suveränitet" mest en fras för paneldebatter på konferenser. Under 2025 och 2026 blev det i stället politik, budgetar och faktiska migreringar. Om ni säljer, köper eller driver teknik i Europa är det värt att förstå vad som förändrats, för marken har rört sig under en hel del antaganden om var data och beräkningar egentligen får finnas.</p>
<h2>Siffran som startade samtalet</h2>
<p>Uppskattningarna varierar, men bilden är genomgående och obekväm. Ungefär nittio procent av Europas digitala infrastruktur körs hos icke-europeiska, huvudsakligen amerikanska, leverantörer, och de tre stora amerikanska hyperskalarna håller runt två tredjedelar av den europeiska molnmarknaden. De europeiska leverantörernas andel har faktiskt sjunkit under de senaste åren. Analyser som <a href="https://www.bertelsmann-stiftung.de/en/our-projects/reframetech-algorithmen-fuers-gemeinwohl/project-news/eurostack-a-european-alternative-for-digital-sovereignty">EuroStack-arbetet från Bertelsmann Stiftung</a> kartlägger beroendet i detalj. När ni väl ser siffrorna framträder mycket av den europeiska politiken under de senaste två åren som en enda reaktion på just dem.</p>
<h2>Lagarna som kommer ikapp</h2>
<p>Flera juridiska trådar drar åt samma håll. <a href="https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng">EU:s dataförordning (Data Act)</a>, tillämplig sedan september 2025, monterar ned de avgifter och tekniska hinder som låser in kunder hos en molnleverantör, och den ålägger leverantörer att skydda icke-personuppgifter mot olaglig åtkomst från utländska myndigheter. GDPR:s regler om överföring, formade av Schrems II-domen, håller kvar risken med att skicka personuppgifter utomlands högst upp på bordet. Och i juni 2026 föreslog kommissionen ett <a href="https://digital-strategy.ec.europa.eu/en/policies/cloud-and-ai-development-act">regelverk för utveckling av moln och AI (Cloud and AI Development Act)</a>, som en del av ett bredare paket för teknisk suveränitet. Formuleringen är rakt på sak: ett överdrivet beroende av moln­leverantörer utanför EU är en betydande risk för Europas digitala självständighet. Förslaget talar om att tredubbla EU:s datacenterkapacitet och att definiera nivåer av molnsuveränitet, där den strängaste utesluter kontroll från bolag i tredjeland för de känsligaste offentliga arbetslasterna.</p>
<h2>Sverige sätter det på pränt</h2>
<p>Det här är inte bara en Brysselhistoria. Den 28 maj 2026 antog den svenska regeringen sin <a href="https://www.regeringen.se/pressmeddelanden/2026/05/ny-molnpolicy-ska-bidra-till-okad-digital-suveranitet-i-offentlig-forvaltning/">första nationella molnpolicy för offentlig förvaltning</a>, och konstaterar på ren svenska att landet är starkt beroende av leverantörer utanför EU. Civilminister Erik Slottner har varit tydlig med vart det pekar: förvaltningen ska kunna använda molntjänster utan att tappa kontrollen över sin information. Policyn förbjuder inte amerikanskt moln. Den kräver riskanalyser, öppna standarder, tydliga avtal och exitplaner, så att en offentlig verksamhet faktiskt kan lämna en leverantör när den behöver. Riktningen är omisskännlig även där språket är försiktigt.</p>
<div data-callout><p>Lägg märke till det återkommande ordet i allt det här: exit. Dataförordningen tar bort exitavgifterna. Den svenska molnpolicyn kräver exitplaner. EU:s suveränitetsnivåer handlar om att inte sitta fast. Tillsynsmyndigheter och lagstiftare har dragit slutsatsen att förmågan att lämna var det som saknades. Den renaste versionen av en exitplan är det upplägg ni aldrig behöver lämna, eftersom data låg i era egna lokaler hela tiden.</p></div>
<h2>Från policy till faktiska migreringar</h2>
<p>Den mest talande signalen är att organisationer slutade vänta på att lagarna skulle bli klara. I juni 2025 meddelade Danmarks digitaliseringsministerium en övergång från Microsofts programvara mot alternativ med öppen källkod, uttryckligen på suveränitetsgrund, enligt <a href="https://therecord.media/denmark-digital-agency-microsoft-digital-independence">rapporteringen vid tillfället</a>, där Köpenhamn pekade på en licenskostnad för Microsoft som hade stigit kraftigt på fem år. I Tyskland satte delstaten Schleswig-Holstein i gång med att flytta tiotusentals maskiner från Windows och Office till Linux och verktyg med öppen källkod, med prognoser om reella årliga besparingar, enligt <a href="https://www.theregister.com/2025/10/15/schleswig_holstein_open_source/">bevakningen i fackpressen</a>. Det här är inte uppstartsbolag som vill markera. Det är myndigheter som flyttar lönehantering och e-post.</p>
<h2>Var AI kommer in</h2>
<p>AI skärper varenda del av det här. En assistent som skickar prompter och dokument till ett moln under utländsk kontroll är exakt det beroende som suveränitetsdebatten handlar om, tillämpat på er känsligaste interna kunskap. Att köra modellen på er egen hårdvara är inte en smart gardering mot trenden. Det är trenden, uttryckt på nivån av en enda driftsättning. När beräkningen sker där data redan finns, finns det ingen leverantör att bli inlåst hos, ingen gräns att försvara och ingen utländsk lag som når fram till servern.</p>
<p>Inget av det här betyder att det amerikanska molnet försvinner, och den här guiden är ingen förutsägelse om att det borde. Den är en karta över ett verkligt skifte i vad europeiska institutioner anser klokt. För ett svenskt bolag som alltid har byggt AI för att köras innanför kundens egna väggar bekräftar kartan mest en satsning vi gjorde tidigt. Resten av kontinenten beskriver nu, i lag och i budgetar, precis det vi bygger.</p>]]></content:encoded>
    </item>
    <item>
      <title>IMY, GDPR och AI: vad tillsynen faktiskt tittar på</title>
      <link>https://lemon-sea-08a033b03.7.azurestaticapps.net/eu-regulations/imy-gdpr-och-ai-vad-tillsynen-gor/</link>
      <guid isPermaLink="true">https://lemon-sea-08a033b03.7.azurestaticapps.net/eu-regulations/imy-gdpr-och-ai-vad-tillsynen-gor/</guid>
      <pubDate>Fri, 05 Jun 2026 09:00:00 GMT</pubDate>
      <category>EU-regelverk</category>
      <category>GDPR</category>
      <description>Vad Integritetsskyddsmyndigheten granskar kring GDPR, moln och AI, och varför egen hårdvara krymper er exponering och kortar konsekvensbedömningen.</description>
      <content:encoded><![CDATA[<p>Det är lätt att läsa GDPR som en abstrakt textmassa och svårt att veta vad en svensk tillsynsmyndighet faktiskt reagerar på i praktiken. Integritetsskyddsmyndigheten, IMY, har de senaste åren fattat en rad beslut som säger mer om era risker än vad själva förordningstexten gör. Om ni läser dem sida vid sida framträder ett tydligt mönster: myndigheten återkommer gång på gång till två saker. Vart datan tar vägen, och om ni bedömde riskerna innan ni satte igång.</p>
<p>Den här genomgången handlar om vad IMY tittar på när moln och AI möter GDPR, och varför det mönstret spelar rakt in i frågan om var ni bör köra er AI.</p>
<h2>Google Analytics: överföringen som inte gick att rädda med avtal</h2>
<p>Den 3 juli 2023 avslutade IMY en granskning av fyra företag som använde Google Analytics. Granskningen inleddes efter klagomål från integritetsorganisationen noyb, och den handlade om samma fråga som legat olöst sedan Schrems II: kan personuppgifter om europeiska besökare skickas till ett amerikanskt bolag utan att amerikanska myndigheter kommer åt dem?</p>
<p>IMY:s svar var nej, inte i de granskade fallen. Företagen hade standardavtalsklausuler på plats och hade lagt till kompletterande skyddsåtgärder, precis som regelverket föreskriver. Myndigheten bedömde ändå att åtgärderna inte räckte för att hindra amerikansk åtkomst, och att överföringarna därmed var olagliga. Tele2 fick en sanktionsavgift på 12 miljoner kronor och CDON 300 000 kronor, medan övriga ålades att sluta använda verktyget. Ni kan läsa <a href="https://www.imy.se/en/news/four-companies-must-stop-using-google-analytics/">IMY:s egen sammanfattning av beslutet</a>.</p>
<p>Lägg märke till vad som fällde avgörandet. Det var inte slarv med avtalen. Företagen gjorde det pappersarbete som förväntades, och det räckte ändå inte, eftersom den underliggande överföringen till ett tredjeland var problemet i sig. När själva dataflödet lämnar EU går det inte alltid att avtala sig ur risken.</p>
<h2>Östersund: beslutet handlade om den uteblivna bedömningen</h2>
<p>Ett halvår senare, den 30 november 2023, kom ett beslut med en annan poäng. Östersunds kommun fick en sanktionsavgift på 300 000 kronor för att ha infört Google Workspace i 24 skolor, för ungefär 6 000 elever, utan att först ha gjort en konsekvensbedömning avseende dataskydd. IMY:s beslut går att läsa <a href="https://www.imy.se/nyheter/sanktionsavgift-mot-kommun-som-inte-bedomt-konsekvenser-innan-google-workspace-infordes/">i sin helhet på myndighetens webbplats</a>.</p>
<p>Det är värt att vara noggrann här, eftersom beslutet ofta återberättas fel. Avgiften handlade inte uttryckligen om CLOUD Act eller om att data flöt till USA. Den handlade om att kommunen behandlade personuppgifter om barn, i stor skala, i ett system med kända risker, utan att ha gjort den bedömning som artikel 35 i GDPR kräver innan man sätter igång. Felet var alltså inte enbart var datan hamnade. Felet var att ingen på förhand hade satt sig ner och skrivit ner riskerna.</p>
<div data-callout><p>Två beslut, två lärdomar som pekar åt samma håll. Google Analytics visar att en överföring till tredjeland kan vara olaglig även när avtalen är korrekta. Östersund visar att en storskalig molnutrullning kan straffa sig enbart för att ingen gjorde konsekvensbedömningen i tid. Det ena är en risk i dataflödet, det andra en risk i pappersarbetet, och en AI som körs på egen hårdvara krymper båda samtidigt.</p></div>
<h2>Känsliga uppgifter höjer ribban ytterligare</h2>
<p>För vissa verksamheter är insatserna högre än så. Vård och omsorg behandlar hälsouppgifter, som enligt artikel 9 i GDPR är en särskild kategori av personuppgifter med starkare skydd. Sådan behandling är i vårdsammanhang laglig via artikel 9.2 h, men bara i kombination med det tystnadspliktsvillkor som ställs i artikel 9.3. Ovanpå detta ligger den svenska <a href="https://www.riksdagen.se/sv/dokument-och-lagar/dokument/svensk-forfattningssamling/patientdatalag-2008355_sfs-2008-355/">patientdatalagen (2008:355)</a>, som reglerar hur vårdgivare får hantera journaluppgifter.</p>
<p>Innebörden är enkel att sammanfatta. När ni behandlar hälsodata måste ni kunna visa både att behandlingen har rätt rättslig grund och att uppgifterna omfattas av tystnadsplikt hela vägen genom kedjan. IMY publicerar löpande <a href="https://www.imy.se/">vägledning för vårdgivare</a> om just detta. Varje extra part i den kedjan, varje leverantör som teoretiskt kan nå uppgifterna, är en punkt ni måste kunna redogöra för. Ju fler händer datan passerar, desto längre blir listan över saker ni ska kunna försvara.</p>
<h2>AI gör inte problemet mindre, snarare tvärtom</h2>
<p>Det är frestande att tro att en AI-modell tvättar bort personuppgifterna. Man tränar en modell på data, och kvar blir vikter och siffror, inte namn och journaler. Så enkelt är det inte. I sitt yttrande 28/2024 från den 17 december 2024 slog Europeiska dataskyddsstyrelsen fast att en AI-modell som tränats på personuppgifter inte i samtliga fall kan anses vara anonym. Frågan måste bedömas från fall till fall. Yttrandet finns att läsa <a href="https://www.edpb.europa.eu/our-work-tools/our-documents/opinion-board-art-64/opinion-282024-certain-data-protection-aspects_en">hos Europeiska dataskyddsstyrelsen</a>.</p>
<p>För er del betyder det att en AI-satsning inte gör GDPR-frågan enklare. Den lägger till ett nytt led där personuppgifter kan finnas kvar, ofta på ett sätt som är svårt att granska i efterhand. Om den modellen dessutom körs som en molntjänst hos en leverantör i ett tredjeland, har ni på en gång återskapat exakt den situation som fällde företagen i Google Analytics-beslutet. Datan lämnar huset, och den gör det nu inbäddad i något ni inte fullt ut kan inspektera.</p>
<h2>Varför egen hårdvara krymper exponeringen</h2>
<p>Här knyts trådarna ihop. Det återkommande temat i IMY:s beslut är att data lämnar er till en tredje part, och att konsekvenserna inte bedömdes i tid. Bägge riskerna är knutna till att någon annan är inblandad i det känsliga flödet.</p>
<p>Om ni kör AI:n på egen hårdvara, i era egna lokaler, försvinner överföringen helt. Det finns inget tredjeland att avtala kring, ingen amerikansk myndighet som kan begära åtkomst till en server som aldrig rört en hyperskalig leverantör, och ingen extern part att redogöra för i journalkedjan. Konsekvensbedömningen blir samtidigt kortare, eftersom den svåraste delen, personuppgiftsbiträdet i ett tredjeland i det känsliga flödet, helt enkelt inte finns. Ni slipper inte konsekvensbedömningen, men ni slipper dess mest krävande kapitel.</p>
<p>Det är inte en magisk lösning på allt GDPR kräver. Ni har fortfarande rättslig grund, gallring, säkerhet och registrerades rättigheter att hantera, oavsett var maskinen står. Men de två frågor som IMY tydligast har visat att myndigheten straffar, den olagliga överföringen och den uteblivna bedömningen, blir båda betydligt lättare att svara på när datan aldrig lämnar er byggnad.</p>
<p>Det här är ingen juridisk rådgivning, och er dataskyddsjurist bör alltid göra den slutliga bedömningen för just er verksamhet. Men om ni läser IMY:s beslut som en vägvisare, snarare än som enskilda böter, pekar de ganska entydigt mot att den säkraste datan är den som aldrig behövde flytta.</p>]]></content:encoded>
    </item>
    <item>
      <title>Den verkliga kostnaden för lokal AI jämfört med molnassistenter per användare</title>
      <link>https://lemon-sea-08a033b03.7.azurestaticapps.net/research/lokal-ai-kostnad-jamfort-med-moln/</link>
      <guid isPermaLink="true">https://lemon-sea-08a033b03.7.azurestaticapps.net/research/lokal-ai-kostnad-jamfort-med-moln/</guid>
      <pubDate>Wed, 20 May 2026 09:00:00 GMT</pubDate>
      <category>Rapporter</category>
      <category>Ekonomi</category>
      <description>En saklig genomgång av när det lönar sig att köra öppna modeller på egen hårdvara i stället för att betala per användare eller per token, och när det inte gör det, med break-even-räkningen.</description>
      <content:encoded><![CDATA[<p>Varje affärscase för lokal AI stöter förr eller senare på samma fråga från ekonomiavdelningen: är det här faktiskt billigare än att bara betala en molnleverantör? Det ärliga svaret är att det beror på, och den som säger något annat har något att sälja. Så låt oss lägga fram den verkliga räkningen, inklusive de delar som inte talar till vår fördel.</p>
<h2>Så debiterar moln-AI er</h2>
<p>Det finns två mätare som tickar. Produkter per användare tar ut en fast månadsavgift för varje person. API:er per token tar betalt för texten som går in och, dyrare, för texten som kommer ut. I skrivande stund 2026 ligger en frontmodell i mellanskiktet någonstans runt två till tre dollar per miljon inmatade tokens och tio till femton dollar per miljon utmatade tokens, enligt de publicerade priserna från <a href="https://platform.claude.com/docs/en/about-claude/pricing">Anthropic</a>, <a href="https://developers.openai.com/api/docs/pricing">OpenAI</a> och <a href="https://ai.google.dev/gemini-api/docs/pricing">Google</a>. Det finns också betydligt billigare nivåer med små modeller, en del så lågt som tio till fyrtio cent per miljon tokens, och för lätta arbetsbelastningar är de ärligt talat svåra att slå.</p>
<p>Den sista poängen är viktig, så jag säger den rakt ut. Om en handfull personer använder AI då och då är molnet troligen billigare än att köpa en GPU, och då ska ni använda molnet. Ekonomin i lokal AI avgörs inte av det enkla fallet. Den avgörs av volym.</p>
<h2>Där mätaren börjar göra ont</h2>
<p>Kostnaderna slutar vara försumbara i tre situationer. Den första är samtidighet: många människor som använder assistenten på en gång, hela dagen. Den andra är sökning i långa dokument, där varje fråga drar en stor mängd kontext genom modellen och varje token debiteras. Den tredje är agentisk användning, där modellen anropar sig själv i loopar för att slutföra en uppgift och tyst multiplicerar antalet tokens med tio eller mer. En enda storanvändare som kör agentiska arbetsflöden kan bränna hundratusentals tokens om dagen. Multiplicera det med en hel avdelning och månadsfakturan slutar se ut som en avrundningspost.</p>
<p>Det är den här profilen som gör att ägd hårdvara ändrar bilden, och det råkar vara exakt profilen för ett företag som vill väva in AI i det dagliga arbetet i stället för att använda den som en nyhet.</p>
<h2>Break-even, ärligt talat</h2>
<p>Det finns en användbar studie om detta från 2025, <a href="https://arxiv.org/html/2509.18101v3">en kostnads- och nyttoanalys av lokal LLM-driftsättning</a>, och dess siffror är värda att citera eftersom de varken är hype eller avfärdande. En enda modern konsument-GPU kan betjäna en modell med 24 till 32 miljarder parametrar med ungefär 150 till 200 tokens per sekund. För en liten men jämn arbetsbelastning finner författarna att hårdvaran betalar sig mot kommersiella API-kostnader på månader, ibland på under en. För större driftsättningar på datacenter-GPU:er sträcker sig återbetalningen till några år, och den håller bara om ni faktiskt håller hårdvaran sysselsatt.</p>
<p>Den reservationen är hela spelet. En GPU som ni köpte och lät stå oanvänd är det dyraste sättet att köra AI som någonsin uppfunnits. Break-even förutsätter uthållig nyttjandegrad, och oberoende analyser placerar brytpunkten där egen drift slår molnet någonstans norr om femtio procents jämn användning. Under det betalar ni för kisel som tar tupplur.</p>
<div data-callout><p>Sammanfattningen på en rad inför ekonomimötet. Moln-AI är billigare för lätt eller ojämn användning. Ägd hårdvara är billigare för tung, förutsägbar användning, och den betalar sig på månader i stället för år så snart maskinen är genuint sysselsatt. Välj verktyget som matchar er faktiska användning, inte det med den snyggare bilden.</p></div>
<h2>Posten ingen budgeterar</h2>
<p>Här är det de flesta gör-det-själv-projekt för lokal drift tyst blöder pengar. Det är inte hårdvaran. Det är personen. Att köra sin egen inferensstack innebär att någon måste hålla modellerna uppdaterade, GPU:erna friska, drivrutinerna aktuella och säkerheten patchad. Analyser av total ägandekostnad för lokal drift finner gång på gång att en deltidsanställd infrastrukturingenjör, säg en halv heltidstjänst till sjuttiofem till hundratusen dollar om året, är den enskilt största posten över tre år, större än servrarna.</p>
<p>Detta är den ärliga svaga punkten i naiv egen drift, och det är också precis det problem en förvaltad box finns till för att lösa. När lådan anländer förkonfigurerad och någon annan sköter uppdateringar och övervakning försvinner den personalposten ur er budget. Skillnaden mellan att "köra egna modeller" och att "äga en box som kör era modeller" ligger mestadels i just den här posten.</p>
<h2>Värdet som inte står på fakturan</h2>
<p>Kostnadsjämförelser som stannar vid tokens missar själva anledningen till att de flesta av våra kunder är här från början. När modellen körs i er byggnad blir er data aldrig en överföring att bedöma, ett intrång som väntar på att rapporteras, eller ett beroende av en leverantör som kan ändra sina priser eller sina villkor. <a href="https://www.ibm.com/reports/data-breach">IBM:s intrångsforskning för 2025</a> anger den globala genomsnittskostnaden för ett dataintrång till 4,44 miljoner dollar, och pekar på ett verkligt påslag när osanktionerade AI-verktyg är inblandade. Inget av detta syns i en offert per token, men det är riktiga pengar och riktig risk.</p>
<h2>Så fattar ni beslutet på riktigt</h2>
<p>Hoppa över leverantörernas kalkylark och gör så här i stället. Uppskatta er stabila användning i tokens per månad, ärligt, inklusive de agentiska och långkontextbelastningar ni planerar att växa in i. Om den är liten och sannolikt förblir liten, använd molnet och njut av det. Om den är stor, eller växer snabbt, eller rör data ni inte kan skicka ut ur byggnaden, prissätt då det ägda alternativet ordentligt, inklusive den personal ni slipper med en förvaltad box, och jämför det med den molnräkning ni skulle skriva under på att betala varje månad, för alltid. För många reglerade, AI-hungriga organisationer är den jämförelsen inte jämn. För andra är den genuint det, och vi säger hellre det till er än vinner en affär ni kommer att ångra.</p>]]></content:encoded>
    </item>
    <item>
      <title>Vad vi menar när vi säger att er data aldrig lämnar huset</title>
      <link>https://lemon-sea-08a033b03.7.azurestaticapps.net/blog/vad-din-data-lamnar-aldrig-huset-betyder/</link>
      <guid isPermaLink="true">https://lemon-sea-08a033b03.7.azurestaticapps.net/blog/vad-din-data-lamnar-aldrig-huset-betyder/</guid>
      <pubDate>Tue, 24 Feb 2026 09:00:00 GMT</pubDate>
      <category>Blogg</category>
      <category>Produkt</category>
      <description>Det är en enkel mening att skriva på en webbplats. Här är den konkreta versionen: vad som faktiskt händer med en fråga, ett dokument och ett svar när AI:n körs lokalt.</description>
      <content:encoded><![CDATA[<p>"Er data lämnar aldrig huset" är en sådan där mening som låter bra men inte betyder någonting förrän någon förklarar den. Marknadssidor älskar den. Så låt oss göra det oglamorösa: beskriva vad den faktiskt innebär, steg för steg, för skillnaden mot moln-AI är konkret och den spelar roll.</p>
<h2>Följ en enda fråga</h2>
<p>Tänk er att en medarbetare ber assistenten sammanfatta ett avtal. Med ett molnverktyg ser resan ut så här. Avtalet och frågan lämnar datorn, färdas över det publika internet, landar i en leverantörs datacenter (ofta i ett annat land), bearbetas på maskiner som ingen på ert företag någonsin kommer att se, och svaret färdas tillbaka. Någonstans på den resan låg ert avtal på någon annans dator. Kanske sparades det ett tag. Kanske användes det för att förbättra en modell. Ni litar på ett avtal och en policy som säger att avtalet förblev privat.</p>
<p>Nu den lokala versionen. Medarbetaren ställer samma fråga. Avtalet och frågan går till en server som står i ert eget hus, på ert eget nät. Modellen körs där. Svaret kommer tillbaka. Ingenting korsade internet. Ingenting landade på en maskin ni inte äger. Det fanns ingen tredje part att lita på, för det fanns ingen tredje part. Det är hela skillnaden, och den är inte subtil.</p>
<h2>Vad "huset" egentligen syftar på</h2>
<p>Uttrycket är en aning bokstavligt. Det vi menar är er förtroendegräns: nätet och hårdvaran ni kontrollerar. För de flesta kunder är det en server på kontoret eller i ett eget datacenter. Den kan vara helt luftgapad, utan någon internetanslutning alls, för det allra känsligaste arbetet. Eller så kan den vara uppkopplad för bekvämlighets skull men konfigurerad så att själva AI-arbetet aldrig skickar ut data. Poängen är att ni bestämmer var gränsen går, och den känsliga bearbetningen sker innanför den.</p>
<div data-callout><p>Ett snabbt sätt att pröva vilket påstående om "privat AI" som helst, inklusive vårt. Ställ en enda fråga: när jag skickar in en fråga, färdas texten i den frågan någonsin till en dator som leverantören kontrollerar? Om svaret är ja, i någon form, av någon anledning, då lämnar data huset, oavsett vad broschyren säger. Om svaret är nej, be dem visa hur de skulle bevisa det.</p></div>
<h2>Varför det här är mer än en känsla</h2>
<p>Att hålla data lokalt är inte bara betryggande. Det tar bort verkliga, konkreta problem. Det finns ingen internationell dataöverföring att bedöma mot de skiftande regler som följde på <a href="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62018CJ0311">Schrems II-domen</a>. Det finns ingen utländsk lag som kan nå en server som aldrig höll er data. Det finns ingen leverantör som kunde logga era frågor eller ändra sin lagringspolicy nästa kvartal. När en tillsynsmyndighet, en revisor eller ert eget säkerhetsteam ställer den svåra frågan, vart tar datan vägen, kan ni ge det kortast tänkbara svaret. Den stannar här.</p>
<p>Vi förseglar nätverkets perimeter vid uppstart, för en oföränderlig logg över vad systemet gjort, och levererar verktygen för att visa att ingenting lämnade huset. Det är maskineriet bakom sloganen. Men sloganen i sig är enkel, och den är skälet till att många av våra kunder valde lokal AI från första början. Deras mest värdefulla data är precis den data de inte kan skicka i väg. Så vi byggde versionen där de slipper.</p>]]></content:encoded>
    </item>
    <item>
      <title>EU:s dataförordning i klartext: vad den förändrar för moln och AI</title>
      <link>https://lemon-sea-08a033b03.7.azurestaticapps.net/eu-regulations/eu-dataforordningen-forklarad/</link>
      <guid isPermaLink="true">https://lemon-sea-08a033b03.7.azurestaticapps.net/eu-regulations/eu-dataforordningen-forklarad/</guid>
      <pubDate>Wed, 18 Feb 2026 09:00:00 GMT</pubDate>
      <category>EU-regelverk</category>
      <category>EU:s dataförordning</category>
      <description>EU:s dataförordning gäller sedan september 2025. Här är vad den faktiskt förändrar för molnbyte, utträdesavgifter och utländsk åtkomst till era data.</description>
      <content:encoded><![CDATA[<p>De flesta som ansvarar för IT i Europa känner till GDPR och vid det här laget även AI-förordningen. Betydligt färre har läst <a href="https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng">EU:s dataförordning</a>, vilket är synd, för den skriver i tysthet om två saker som spelar stor roll när ni köper AI: hur enkelt ni kan lämna en molnleverantör, och vad som händer med era data när en utländsk myndighet kommer och frågar.</p>
<p>Dataförordningen, formellt förordning (EU) 2023/2854, gäller i hela unionen sedan den 12 september 2025. <a href="https://digital-strategy.ec.europa.eu/en/policies/data-act">Europeiska kommissionens egen sammanfattning</a> beskriver den som en lag om "rättvisa i dataekonomin". Det stämmer, men är lite abstrakt. Låt oss lyfta fram de delar som berör var och en som driver programvara.</p>
<h2>Att lämna en molnleverantör ska bli enklare, och billigare</h2>
<p>Om ni någon gång har försökt flytta ut några terabyte från en hyperskalig leverantör känner ni igen mönstret. Datan är lätt att lägga in och märkligt dyr att ta ut. Dessa utträdesavgifter handlade aldrig egentligen om vad bandbredden kostade. De var ett stängsel.</p>
<p>Kapitel VI i dataförordningen (artiklarna 23 till 31) går direkt på det stängslet. Leverantörer måste ta bort de kommersiella, tekniska och avtalsmässiga hinder som hindrar er från att byta till en annan leverantör, flytta till er egen infrastruktur på plats, eller använda flera leverantörer samtidigt. Och artikel 29 sätter en klocka på själva avgifterna: bytesavgifterna sänks under en övergångsperiod och måste vara helt borta från och med den 12 januari 2027, precis som juridiska analyser från byråer som <a href="https://www.gtlaw.com/en/insights/2025/9/cloud-switching-under-the-eu-data-act">Greenberg Traurig</a> beskriver i detalj. Efter det datumet ska det inte kosta er någonting att flytta ut era data.</p>
<p>Läs det en gång till med inköpsglasögonen på. EU har bestämt att inlåsning genom utträdesavgifter är ett problem värt att lagstifta bort. Om en tillsynsmyndighet anser att byteskostnaden är problemet, är det renaste svaret den lösning där det inte finns någon leverantör att byta bort från från första början.</p>
<h2>Delen om utländska myndigheter</h2>
<p>Artikel 32 är den som inte får tillräckligt med uppmärksamhet. Den kräver att leverantörer av moln- och edge-tjänster inför tekniska, rättsliga och organisatoriska åtgärder för att förhindra olaglig åtkomst från tredjeländers myndigheter till icke-personuppgifter som lagras i EU, där sådan åtkomst skulle strida mot unionsrätten eller en medlemsstats rätt.</p>
<p>Notera den noggranna formuleringen: icke-personuppgifter. Överföringar av personuppgifter styrs fortfarande av kapitel V i <a href="https://eur-lex.europa.eu/eli/reg/2016/679/oj">GDPR</a>, vilket är en annan diskussion. Men det faktum att EU ansåg sig behöva en särskild artikel om utländsk statlig åtkomst till vanliga affärsdata visar hur reell oron har blivit. Oron har ett namn i de flestas medvetande, den amerikanska CLOUD Act, och dataförordningen är unionens sätt att skriva in ett partiellt svar på den i lag.</p>
<div data-callout><p>Ett rakt sätt att uttrycka det. Dataförordningen lägger mycket bläck på att hjälpa er att fly en molnleverantör och på att skydda era data från utländsk rättslig räckvidd. Båda problemen försvinner om datan ligger på en maskin i er egen byggnad. Ni kan inte bli inlåsta i en infrastruktur ni äger, och inget utländskt domstolsbeslut når en server som aldrig rört en hyperskalig leverantör.</p></div>
<h2>Vad det betyder om ni inför AI</h2>
<p>Här blir det konkret för var och en som rullar ut en assistent eller ett dokumentsökverktyg. Varje prompt, varje uppladdad fil, varje hämtad textpassage är data som lämnar er kontroll i det ögonblick den träffar en molnmodells API. Dataförordningen förbjuder inte det. Den fortsätter bara att nöta bort antagandet att era data naturligt bor i någon annans datacenter.</p>
<p>Om ni kör modellen lokalt slutar hela frågan om byteskostnader, utträdesavgifter och tredjelands åtkomst att gälla för er AI-arbetsbelastning. Inte för att ni hittade en smart avtalsmässig kringgång, utan för att datan aldrig blev någon annans problem till att börja med.</p>
<p>Inget av detta är juridisk rådgivning, och dataförordningen samverkar med GDPR, <a href="https://digital-strategy.ec.europa.eu/en/policies/data-governance-act">dataförvaltningsförordningen</a> och sektorsregler på sätt som er juridiska rådgivare bör kartlägga för just er situation. Men färdriktningen är inte subtil. Europa lagstiftar för en värld där ni kan plocka upp era data och gå. Att köra AI på er egen hårdvara är helt enkelt den kortaste versionen av den promenaden.</p>]]></content:encoded>
    </item>
  </channel>
</rss>
