Schritt 3: Azure-OpenAI-Resource erstellen (in der richtigen Region)

Sobald die Freischaltung da ist, kommt eine Mail von Microsoft. Jetzt der entscheidende Klick: die Region.

Azure OpenAI ist in vielen Regionen verfügbar – East US, West Europe, Sweden Central, Switzerland North, etc. Für deutsche KMU mit DSGVO-Anspruch:

Im Portal: Create a resource → Azure OpenAI → Sweden Central. Resource-Name vergeben (z.B. "kiba-prod-sweden"), Pricing Tier "Standard S0" wählen.

Vor dem letzten "Create" gibt es einen Tab "Networking". Wenn du ganz sauber sein willst, schränk hier ein, wer auf die Resource zugreifen darf – nur deine eigenen IPs oder ein Private Endpoint. Für den Anfang reicht "All networks" mit aktivierter Firewall, du kannst das später verschärfen.

Schritt 4: EU Data Boundary aktivieren

Das ist der Klick, der den Unterschied zwischen "DSGVO halbwegs" und "DSGVO sauber" macht.

Microsoft hat 2024 die EU Data Boundary eingeführt: eine Garantie, dass bestimmte Daten die EU nicht verlassen – auch nicht für temporäre Verarbeitung wie Inhaltssicherheits-Checks. Standardmäßig ist sie nicht aktiv. Du musst sie einschalten.

Im Azure Portal → deine OpenAI-Resource → Settings → Data Boundary. Häkchen bei "Enable EU Data Boundary". Speichern.

Was sich damit ändert: Auch die Sicherheits-Checks (Content Safety), die OpenAI normalerweise asynchron in den USA durchführt, laufen jetzt in der EU. Latenz steigt um ca. 50 ms. Datenschutz-Position deutlich besser.

Praxistipp: Screenshot der aktivierten Einstellung machen und in die DSFA-Doku legen. Das ist die Belegquelle.

Schritt 5: Modell-Deployment

Anders als bei OpenAI direkt: In Azure musst du jedes Modell, das du nutzen willst, einzeln "deployen". Das ist ein zweiter Schritt nach der Resource-Erstellung.

In der OpenAI-Resource: Resource Management → Model deployments → Manage deployments → Create new deployment.

Empfehlung für den Standardfall:

Bei "Deployment Type" wähl Standard für den Anfang. Provisioned ist für Hochlast-Use-Cases mit garantierter Kapazität – brauchst du nicht, wenn du nicht hunderte Requests pro Sekunde fährst.

Bei "Tokens per Minute Rate Limit" stell für jedes Deployment einen sinnvollen Wert ein. Default ist hoch. Reduzieren auf das, was du im Pilot brauchst – das schützt vor Überraschungen, wenn ein Skript fehlläuft.

Schritt 6: Erster API-Call

Jetzt der Smoke-Test. In der OpenAI-Resource: Resource Management → Keys and Endpoint. Du brauchst zwei Werte:

Endpoint – sieht aus wie https://kiba-prod-sweden.openai.azure.com/

Key 1 – langer hex-String

Test im Terminal:

curl https://kiba-prod-sweden.openai.azure.com/openai/deployments/gpt-4o-mini/chat/completions?api-version=2024-08-01-preview \
  -H "api-key: DEIN_KEY_HIER" \
  -H "Content-Type: application/json" \
  -d '{
    "messages": [
      {"role": "user", "content": "Antworte mit OK"}
    ]
  }'

Wenn du eine Antwort mit "OK" bekommst: Setup ist fertig. Wenn 401: Key falsch. Wenn 404: Deployment-Name oder Endpoint falsch (häufiger Fehler – Deployment-Name muss exakt stimmen). Wenn 429: Rate Limit zu niedrig gesetzt.

Was du in die DSFA-Doku schreibst

Drei häufige Stolpersteine

Falsche Region. Der häufigste Fehler: East US als Region, EU Data Boundary aktiviert, Datenschutzbeauftragter sagt trotzdem nein. EU Data Boundary greift nur mit EU-Region. Sweden Central ist Pflicht für deutsche Compliance.

API-Version-Hölle. Azure OpenAI hat Versionsstrings im URL ("?api-version=2024-08-01-preview"). Wenn du eine alte Version verwendest, fehlen dir neue Features. Wenn du eine zu neue verwendest, gibt's noch Bugs. Empfehlung: Schau auf die aktuelle Stable-Version in der Doku.

Quota-Fallen. Microsoft setzt initiale Quotas conservative. Wenn dein Pilot wächst, musst du Quota-Erhöhungen beantragen. Auch das ist ein Antragsprozess, dauert ein bis drei Tage. Plan ein.