EU:s AI-förordning trädde i kraft i augusti 2024, med bestämmelser som fasas in över en två till tre år lång period [1][2]. De flesta företagsdiskussioner om efterlevnad har hittills fokuserat på om en arbetsflöde överhuvudtaget faller inom kategorin "hög risk". I mitten av 2026 skiftar samtalet till en mer praktisk fråga: givet att arbetsflödet är inom tillämpningsområdet, vilka distributionsarkitekturer låter dig faktiskt uppfylla distributörens skyldigheter, och vilka gör det tyst utan?

Den andra frågan är där on-prem-distribution slutar vara en stilistisk preferens och börjar vara en strukturell lösning.

Vad lagen kräver av distributörer av hög-risk-AI

Lagen skiljer mellan leverantören av ett AI-system och distributören av det [1]. En bank som använder en tredje parts LLM-API för att bedöma låneansökningar är distributören, inte leverantören. Distributörer av hög-risk-system har skyldigheter som inkluderar: att säkerställa mänsklig övervakning, övervaka systemets funktion, behålla loggar under en lämplig period, avbryta användning om systemet utgör en risk för grundläggande rättigheter, och att på begäran visa dessa möjligheter.

Flera av dessa skyldigheter är enkla när distributören kontrollerar körmiljön. Skyldigheten att "behålla loggar under en lämplig period" är mekaniskt enkel om inferensen sker på en server som distributören äger och loggarna hamnar i distributörens SIEM. Skyldigheten att "avbryta användning" är likaledes trivial om distributören kan stänga ner modellen på sin egen infrastruktur.

Samma skyldigheter blir svårare när inferensen körs på en molnbaserad LLM-API som distributören inte driver. De loggar distributören kan producera är begränsade till vad leverantören exponerar. Att avbryta användning kräver leverantörens samarbete. Att samtidigt visa vilken data som flödat genom systemet kräver förtroende för leverantörens pipeline.

Var molnbaserade LLM-API:er placeras i regleringen

Inget av detta gör molnbaserade LLM-API:er icke-kompatibla. Artikel för artikel kan leverantörer och användare av molnhostad AI uppfylla lagens skyldigheter. Friktionen är operativ, inte juridisk: användaren måste sammanställa, granska och visa efterlevnad över en leverantörsgräns, ofta för arbetsflöden som kör tusentals inferenser per dag.

Stanford HAI:s longitudinella AI Index har följt motsvarande skifte i företagsutgifter [3]: den brantaste tillväxten under 2023–2025 var inte inom generativ AI för allmänt bruk, utan i stödverktygen — observabilitet, styrning, prompt-loggning, innehållsklassificering, jailbreak-detektion. Majoriteten av dessa utgifter finns för att överbrygga gapet mellan vad molnbaserade LLM-API:er exponerar nativt och vad en användare behöver visa i en regulatorisk kontext.

Det gapet är den strukturella fördelen med att köra inferens på hårdvara som användaren äger. Varje "hände detta?"-fråga reduceras till en fråga som användaren kan besvara från sina egna loggar.

Vad on-prem inte ger dig gratis

Tre användarskyldigheter enligt AI-lagen är inte automatiskt uppfyllda av en on-prem-installation, och det är värt att nämna dem uttryckligen:

  • Mänsklig övervakning. Lagen kräver meningsfull övervakning av högrisk-AI, där människor kan tolka resultat och ingripa. Att köra modellen lokalt sätter inte en människa i loopen; det gör arbetsflödesdesignen.
  • Övervakning av drift och osäkert beteende. Användaren måste kontinuerligt övervaka systemet. On-prem-installation gör infrastrukturen enkel (datan är lokal), men policyn ("hur ser drift ut för detta arbetsflöde?") måste fortfarande definieras.
  • Leverantörsskyldigheter vidarebefordras. När on-prem-installationen bygger på en tredjepartsmodell (t.ex. en öppen vikt-modell under en icke-kommersiell licens, eller en leverantörsmodell levererad som binärfil) måste användaren fortfarande visa leverantörens obligatoriska upplysningar.

Den strukturella fördelen med on-prem ligger i datahantering och möjligheten att visa efterlevnad, inte i policyn. Policyn måste skrivas och upprätthållas oavsett var GPU:n finns.

Hur detta samspelar med USA, Storbritannien och andra jurisdiktioner

EU:s AI-lag är den mest detaljerade av de stora regelverken. USA:s NIST AI RMF [4] har en frivillig, ramverksbaserad ansats, och OECD AI Policy Observatory [5] följer hur nationella regeringar utanför EU närmar sig i stort sett liknande principer (riskbaserad övervakning, transparensskyldigheter, regler för datahantering).

För en multinationell användare är den praktiska effekten att den striktaste jurisdiktionen sätter arkitekturen. Om ett arbetsflöde måste uppfylla EU:s AI-lag för europeiska användare, kommer samma arbetsflöde inte att bryta mot USA:s, Storbritanniens, Japans eller Singapores skyldigheter om det är designat efter EU:s krav. Att designa installationen efter den striktaste nivån — inklusive användarens förmåga att visa datahantering per förfrågan — är vad som gör on-prem till det strukturellt enklare standardvalet för företags-AI 2026.

Hur en on-prem AI-installation redo för 2026 års efterlevnad ser ut

Den form vi levererar — och den form som efterlevnadsgranskare vi samarbetar med efterfrågar — är:

  • Inferens lokalt hos kunden. Antingen på användarens enhet eller på en kunddriven server. Inga prompts lämnar perimetern.
  • Innehållsfria revisionsloggar. Varje administrativ åtgärd loggas med tidsstämpel + aktör; inga prompts eller svar visas i revisionsraden. Revisionsraden är beviset; innehållet är den som distribuerarens att behålla enligt sin egen lagringspolicy.
  • Identitet via kundens IdP. OIDC mot Microsoft Entra ID eller Google Workspace, med distribuerarens befintliga åtkomstkontroller oförändrade.
  • Ingen leverantörsdriven inferenstjänst. Software Tailor driver inte modellkörningen eller tar emot prompts, svar eller kunddokument via denna väg. Organisationsidentitet, licensiering, policy, serverstatus, aggregerad användning, revisions- och supportloggar kan fortfarande använda en leverantörsstyrd kontrollplan och måste bedömas som ett separat beroende.

Den sista egenskapen för inferens är den som molnbaserade LLM-API:er strukturellt inte kan replikera. Det gör inte en on-premises-produkt automatiskt kompatibel eller tar bort behovet att bedöma dess kontrollplan, supportvägar, modellsupplykedja och kundens driftansvar.

Bakgrund om hur vi byggde kring detta från början finns i Varför vi levererar AI som installerbara binärer, inte moln-SaaS. Funktionerna som implementerar revision, identitet och policy finns i AI Admin Console.

Referenser

  1. Europeiska kommissionen. "AI Act — Regleringsramverk för AI." https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai. Hämtad 2026-06-15.
  2. Europeiska kommissionen. "AI Act träder i kraft." https://digital-strategy.ec.europa.eu/. Hämtad 2026-06-15.
  3. Stanford HAI. "AI Index Report." https://aiindex.stanford.edu/. Hämtad 2026-06-15.
  4. NIST. "AI Risk Management Framework (AI RMF 1.0)." https://www.nist.gov/itl/ai-risk-management-framework. Hämtad 2026-06-15.
  5. OECD AI Policy Observatory. "National AI policies." https://oecd.ai/. Hämtad 2026-06-15.