title: "Bygg AI-appar som inte lagrar dina användares data: Tillståndslösa LLM-API:er och GDPR" description: "Vad tillståndslös inferens innebär, varför det är viktigt för GDPR-efterlevnad, och hur du bygger en produktionsklar chattapplikation med full kontroll över datalagring." date: 2026-04-06 slug: stateless-llm-api-gdpr keywords: ["stateless llm api", "gdpr compliant llm", "zero data retention ai", "stateless inference gdpr", "llm no data retention"] category: guides schema_types: ["TechArticle", "FAQPage"]

Bygg AI-appar som inte lagrar dina användares data: Tillståndslösa LLM-API:er och GDPR

De flesta LLM-API:er är tillståndsfulla som standard. När du skickar en förfrågan till OpenAI sparas prompten och svaret — vanligtvis i 30 dagar — för missbruksövervakning, analys och driftloggning. Den lagrade datan skapar GDPR-skyldigheter: lagringsscheman, raderingsmekanismer, artikel 28-avtal och revisionsexponering.

Tillståndslös inferens vänder på detta. API:et behandlar din förfrågan i arbetsminnet, genererar ett svar och kasserar omedelbart allt. Inga loggar som innehåller ditt innehåll, inga träningsdata, inget att radera.

Den här guiden förklarar hur tillståndslös LLM-arkitektur fungerar, när det är relevant för GDPR-efterlevnad, och hur du bygger en produktionsklar chattapplikation med den. Alla exempel använder JuiceFactorys OpenAI-kompatibla API.

Skaffa din kostnadsfria API-nyckel: juicefactory.ai/api-key — inget kreditkort krävs.

Vad tillståndslös inferens faktiskt innebär

Tillståndslöshet i ett LLM-API betyder att leverantören inte upprätthåller något konversationstillstånd mellan förfrågningar. Varje förfrågan är oberoende. API:et tar emot de meddelanden du skickar, bearbetar dem, returnerar ett svar och frigör minnet. Inget kvarstår.

Det här skiljer sig från hur du kanske bygger en chattapplikation, där du lagrar konversationshistorik i din databas och skickar den med varje förfrågan. Tillståndsfullheten finns i ditt applikationslager — inte i inferenstjänsten. API:et vet aldrig om tidigare konversationer om du inte inkluderar dem i den aktuella förfrågan.

Den avgörande skillnaden ur ett efterlevnadsperspektiv:

# Tillståndsfullt mönster — leverantören behåller historik
# Din prompt skickas till deras server, loggas, lagras, sparas
response = openai.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "My patient ID is 12345..."}]
)
# Det patient-ID:t ligger nu i OpenAI:s loggar i 30 dagar

# Tillståndslöst mönster — leverantören kasserar allt
client = OpenAI(
    api_key="jf-...",
    base_url="https://api.juicefactory.ai/v1"
)
response = client.chat.completions.create(
    model="qwen3-vl",
    messages=[{"role": "user", "content": "My patient ID is 12345..."}]
)
# Förfrågan bearbetas i minnet, svar returneras, data kasseras

Koden ser nästan identisk ut. Konsekvenserna för efterlevnad är helt olika.

Varför detta är viktigt för GDPR

GDPR ställer specifika krav på hur personuppgifter hanteras. För LLM-applikationer är de mest relevanta:

Artikel 5(1)(c) — Uppgiftsminimering: Behandla bara det som är nödvändigt. Att behålla promptar i 30 dagar när du bara behövde svaret i 200 ms är svårt att motivera.

Artikel 5(1)(e) — Lagringsminimering: Data ska inte lagras längre än nödvändigt för sitt ändamål. Med tillståndsfulla API:er förlitar du dig på leverantörens lagringsschema, inte ditt eget.

Artikel 17 — Rätten till radering: Användare kan begära radering av sina personuppgifter. Med tillståndslös inferens finns det inget att radera — datan lagrades aldrig. Med tillståndsfulla leverantörer behöver du en mekanism för att samordna raderingsbegäranden över deras infrastruktur.

Artikel 28 — Personuppgiftsbiträdesavtal: Varje tjänst som behandlar personuppgifter för din räkning kräver ett DPA (Data Processing Agreement). Tillståndslösa leverantörer har enklare DPA:er eftersom behandlingens omfattning begränsas till den omedelbara förfrågan.

Efterlevnadsvärdet är inte bara teoretiskt. I en sjukvårdsapplikation som hanterar patientfrågor, eller ett juridiskt verktyg som bearbetar ärendeanteckningar, vill du kunna säga till ditt dataskyddsombud: "Inferensleverantören behandlar data övergående och lagrar ingenting." Det är en ren berättelse. "De behåller våra promptar i 30 dagar, här är vårt DPA" är ett svårare samtal.

Arkitektur: var tillståndet lever

flowchart LR
    subgraph Your Infrastructure
        A[User] --> B[Your App]
        B --> C[(EU Database\nconversation history\nyour retention policy)]
    end
    subgraph JuiceFactory
        B -->|full context per request| D[Stateless API\nRAM only]
        D -->|response| B
        D --> E[Memory freed\nnothing stored]
    end

Du äger datan. Du bestämmer lagringstiden. Inferensleverantören är ett rent beräkningslager.

Bygg en tillståndslös chattapplikation

Det som kan vara lite kontraintuitivt: tillståndslös inferens betyder inte att du inte kan ha flerstegskonversationer. Det innebär att du hanterar konversationstillståndet, inte leverantören. Du lagrar historiken i din databas, skickar den med varje förfrågan och har full kontroll över vad som sparas och hur länge.

Så här sätter du upp det:

Grundläggande konfiguration

from openai import OpenAI

client = OpenAI(
    api_key="your-juicefactory-api-key",
    base_url="https://api.juicefactory.ai/v1"
)

Det är den enda konfigurationsändringen jämfört med en standard OpenAI-konfiguration. Allt annat — förfrågningsformat, svarshantering, streaming — är identiskt.

Hantering av konversationstillstånd

from openai import OpenAI
from typing import List

client = OpenAI(
    api_key="your-juicefactory-api-key",
    base_url="https://api.juicefactory.ai/v1"
)

def chat(history: List[dict], message: str) -> tuple[str, List[dict]]:
    """
    Send a message with conversation history to the stateless API.
    Returns the response and the updated history.

    History lives in your application — the API never sees it
    except as part of the current request.
    """
    history.append({"role": "user", "content": message})

    response = client.chat.completions.create(
        model="qwen3-vl",
        messages=history,
        max_tokens=500,
        temperature=0.7
    )

    assistant_message = response.choices[0].message.content
    history.append({"role": "assistant", "content": assistant_message})

    return assistant_message, history

# Example usage
conversation = []
reply, conversation = chat(conversation, "What is the GDPR right to erasure?")
print(reply)
reply, conversation = chat(conversation, "Does it apply to AI systems?")
print(reply)

API:et behandlar varje förfrågan från grunden. Du styr vilken historik du inkluderar — och hur länge du lagrar den i din egen databas.

Produktionsserver med FastAPI

En komplett tillståndslös chattserver med GDPR-kompatibel datahantering:

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
from typing import List, Dict
from openai import OpenAI
import uvicorn

client = OpenAI(
    api_key="your-juicefactory-api-key",
    base_url="https://api.juicefactory.ai/v1"
)

app = FastAPI()

class Message(BaseModel):
    user_id: str
    content: str

class Reply(BaseModel):
    content: str
    message_count: int

# ⚠️ DEMO ONLY — in-memory storage. In production, use an EU-hosted
# database (PostgreSQL, etc.) with encryption at rest and defined
# retention periods.
conversations: Dict[str, List[dict]] = {}

@app.post("/chat", response_model=Reply)
async def chat(message: Message):
    history = conversations.get(message.user_id, [])
    history.append({"role": "user", "content": message.content})

    response = client.chat.completions.create(
        model="qwen3-vl",
        messages=history,
        max_tokens=500,
        temperature=0.7
    )

    reply = response.choices[0].message.content
    history.append({"role": "assistant", "content": reply})
    conversations[message.user_id] = history

    return Reply(content=reply, message_count=len(history))

@app.delete("/conversations/{user_id}")
async def delete_conversation(user_id: str):
    """
    GDPR Article 17 — Right to Erasure.
    User requests deletion: remove their conversation history.
    Because the inference provider stores nothing, this is the only
    place their data exists.
    """
    if user_id in conversations:
        del conversations[user_id]
        return {"status": "deleted"}
    raise HTTPException(status_code=404, detail="No conversation found")

if __name__ == "__main__":
    uvicorn.run(app, host="0.0.0.0", port=8000)

Raderingsendpointen enligt rätten till radering är trivial att implementera — eftersom du kontrollerar den enda kopian av datan. Med en tillståndsfull leverantör skulle du även behöva samordna med deras infrastruktur.

Vad noll datalagring täcker — och inte täcker

"Noll datalagring" från inferensleverantören innebär att de inte lagrar dina promptar eller svar. Det betyder inte att din applikation saknar lagring — det är ditt ansvar.

Vad JuiceFactory inte lagrar:

• Promptinnehåll
• Svarsinnehåll
• Härledd data från dina förfrågningar
• Träningsdata

Vad driftloggar innehåller (enbart metadata, inte innehåll):

• Tidsstämplar
• Förfrågnings-ID:n
• Antal tokens
• Latensmätningar
• Felstatuskoder

Dessa metadatafält innehåller inte personuppgifter. Det är vad vilken infrastrukturleverantör som helst loggar för fakturerings- och tillförlitlighetsändamål.

Ditt applikationslager är där GDPR-skyldigheterna lever:

• Lagra konversationshistorik i en EU-hostad databas
• Implementera konfigurerbara lagringsperioder
• Bygg raderingsendpoints (som exemplet ovan)
• Logga det du behöver för dina ändamål, enligt dina policyer

OpenAI kontra tillståndslösa EU-leverantörer: vad skiljer sig

OpenAI:s standard-API-beteende lagrar förfrågningsdata i 30 dagar. Enterprise-avtal kan konfigurera noll lagring, men det kräver ett minimiåtagande och explicit förhandling.

Även med noll lagring konfigurerat på OpenAI:s sida är den underliggande infrastrukturen USA-baserad, vilket skapar CLOUD Act-exponering — amerikanska myndigheter kan tvinga amerikanska företag att lämna ut data oavsett var servrarna finns.

JuiceFactory är ett svenskt företag, EU-registrerat, utan amerikanskt moderbolag. Datan lämnar aldrig EU:s jurisdiktion och det finns ingen CLOUD Act-vinkel.

För de flesta utvecklingsprojekt med icke-känslig data påverkar denna skillnad inte det dagliga arbetet. För applikationer som hanterar reglerad data — patientinformation, finansiella handlingar, juridiska dokument — är det ofta den avgörande faktorn.

Vanliga frågor

Betyder tillståndslöst att jag inte kan ha flerstegskonversationer? Nej. Du hanterar konversationshistoriken i din applikation och inkluderar den i varje förfrågan. API:et bearbetar hela historiken du skickar men lagrar ingenting efter att svaret har levererats.

Hur verifierar jag att leverantören faktiskt inte lagrar data? Granska deras personuppgiftsbiträdesavtal (tillgängligt i JuiceFactorys portal under Settings -> Legal). Det specificerar avtalsmässiga förbud mot datalagring som en GDPR artikel 28-skyldighet. Du kan även begära en teknisk revision.

Ersätter detta mitt behov av en GDPR-efterlevnadsgranskning? Nej. Tillståndslös inferens hanterar personuppgiftsbiträdessidan av skyldigheten. Du behöver fortfarande rättslig grund för behandling, transparens mot användare, infrastruktur för registrerades rättigheter och dokumentation som personuppgiftsansvarig.

Gäller det även embeddingar — är de också tillståndslösa? Ja. JuiceFactorys embedding-endpoint (Qwen3-Embed) har samma arkitektur med noll lagring. Dokument du bäddar in bearbetas övergående.

Är tillståndslös inferens långsammare? Nej. Det finns ingen märkbar prestandaskillnad. Tillståndslös bearbetning kräver ingen extra beräkning — om något är det marginellt snabbare eftersom det inte finns någon overhead för läsning/skrivning av tillstånd.

Redo att bygga? Skaffa din kostnadsfria JuiceFactory API-nyckel.

Relaterade guider: Migrera från OpenAI till EU API · EU LLM API-jämförelse 2026 · RAG i Python — GDPR-säker