Azure OpenAI: Zero Data Retention und Abuse Monitoring

Eine Kanzlei, die Mandantenschriftsätze über Azure OpenAI zusammenfassen lässt. Eine Klinik, die Arztbriefe mit einem eigenen Deployment vorstrukturiert. Eine Steuerberatung, die Belege per Prompt auswerten lässt. In allen drei Fällen stellt sich früher oder später dieselbe Frage: Kann jemand bei Microsoft mitlesen, was da an Inhalten durch die Leitung geht? Die ehrliche Antwort lautet: standardmäßig ja, zumindest potenziell und zeitweise - Azure OpenAI betreibt ein automatisiertes Abuse Monitoring, das Prompts und Antworten inhaltlich prüft und in bestimmten Fällen für eine menschliche Prüfung durch Microsoft-Mitarbeitende speichert.

Für die meisten Anwendungsfälle ist das unproblematisch und sogar sinnvoll - es schützt vor Missbrauch des Dienstes. Für Berufsgeheimnisträger und andere Organisationen mit besonders hohen Vertraulichkeitsanforderungen ist es dagegen ein Thema, das vor dem produktiven Einsatz geklärt sein sollte. Microsoft bietet dafür einen Weg an, diese menschliche Prüfung abzuschalten: Modified Abuse Monitoring - im Netz häufig auch als „Azure OpenAI Zero Data Retention” gesucht, auch wenn dieser Begriff, wie sich unten zeigt, nicht aus Microsofts eigener Dokumentation stammt. Kein Schalter im Portal, sondern ein Antragsprozess mit Formular, Prüfung und Voraussetzungen. Dieser Artikel ordnet ein, was Azure OpenAI standardmäßig speichert, was der Antrag konkret abschaltet - und was er ausdrücklich nicht abschaltet - , wie der Prozess abläuft und für wen er sich lohnt.

Was Azure OpenAI standardmäßig speichert

Microsoft trennt in der eigenen Dokumentation klar zwischen zwei Systemen, die beide unter dem Begriff „Responsible AI“ laufen, aber unterschiedliche Dinge tun: Guardrails (früher Content Filter) prüfen Inhalte synchron während der Verarbeitung und blockieren oder markieren sie nach Schweregrad - dabei werden laut Microsoft keine Prompts oder generierten Inhalte in den Klassifizierungsmodellen gespeichert. Das Abuse Monitoring ist ein separates System und genau der Mechanismus, um den es hier geht.

Abuse Monitoring hat laut der offiziellen Beschreibung mehrere Komponenten: eine Content-Klassifizierung, die Schweregrade erkennt, eine Mustererkennung, die wiederkehrendes oder eskalierendes Verhalten über mehrere Anfragen hinweg bewertet, und einen anschließenden Review-Schritt. Dieser Review läuft standardmäßig zweistufig: Zunächst prüft ein automatisiertes System - laut Microsoft ausdrücklich „automated means including AI models such as LLMs“ - die als auffällig markierten Prompts und Antworten, um die Einschätzung zu bestätigen. Reicht diese automatisierte Prüfung nicht aus, etwa weil die Konfidenz zu niedrig ist oder ein komplexer Kontext vorliegt, kann eine menschliche Prüfung folgen.

Für diese menschliche Prüfung legt Microsoft einen eigenen Datenspeicher an: pro Kundenressource logisch getrennt, in derselben Azure-Geografie wie die Foundry-Ressource des Kunden, innerhalb der Servicegrenze von Azure OpenAI. Zugriff erhalten laut Microsoft ausschließlich autorisierte Microsoft-Mitarbeitende, über Secure Access Workstations und mit Just-in-Time-Freigabe durch Teamverantwortliche - und nur auf Datensätze, die das System bereits als potenziell auffällig markiert hat. Für Deployments im Europäischen Wirtschaftsraum sitzen diese Mitarbeitenden laut Microsoft ebenfalls im EWR.

Wichtig für die Einordnung: Bei der automatisierten Prüfung werden die geprüften Prompts und Antworten laut Microsoft nicht gespeichert und nicht zum Training verwendet. Gespeichert wird ausschließlich das, was für eine mögliche menschliche Prüfung vorgehalten wird - und auch das nur, wenn es zuvor als potenziell auffällig eingestuft wurde. Die Modelle selbst sind laut Microsoft zustandslos: Es werden keine Prompts oder Antworten im Modell gespeichert, unabhängig vom Abuse Monitoring.

Wie lange wird gespeichert - und was sagt die aktuelle Doku wirklich dazu?

Hier lohnt sich Vorsicht, weil im Netz kursierende Angaben und der aktuelle Stand der offiziellen Dokumentation auseinanderlaufen. In mehreren Community-Diskussionen auf Microsoft Q&A wird eine frühere Formulierung zitiert, wonach abuse-monitoring-relevante Daten „up to 30 days“ gespeichert werden konnten. Diese konkrete Zahl taucht in der aktuellen Fassung der einschlägigen Microsoft-Learn-Seiten zu Abuse Monitoring und zu Data, Privacy and Security (Stand: August 2026, Abruf 20.08.2026) nicht mehr auf. Die aktuelle Formulierung beschreibt lediglich, dass Daten für eine mögliche menschliche Prüfung vorgehalten werden, ohne eine exakte Aufbewahrungsdauer in Tagen zu nennen.

Für die Praxis heißt das: Wer intern oder gegenüber Mandanten dokumentieren muss, „wie lange“ Prompts potenziell einsehbar bleiben, sollte sich nicht auf eine im Netz kursierende Zahl verlassen, sondern die aktuelle Formulierung der Microsoft-Learn-Seite zitieren - oder eben den in den nächsten Abschnitten beschriebenen Antrag stellen, der die Frage für den eigenen Anwendungsfall entschärft, statt sie zu beantworten.

Was Modified Abuse Monitoring abschaltet - und was nicht

Das ist der Punkt, an dem viele Erwartungen zu hoch ansetzen, und deshalb der wichtigste Absatz dieses Artikels: Modified Abuse Monitoring schaltet die menschliche Prüfung ab. Es schaltet nicht das gesamte Abuse Monitoring ab.

Microsoft formuliert das in der Dokumentation zur Modified-Abuse-Monitoring-Registrierung so: Wenn ein Kunde für Modified Abuse Monitoring freigegeben wurde, findet der oben beschriebene Prozess aus Datenspeicherung und menschlicher Prüfung nicht statt. Automatisierte Prüfung - inklusive KI-Modellen, die Prompts und Antworten zum Zeitpunkt ihrer Verarbeitung bewerten - kann aber weiterhin stattfinden. Erkennt diese automatisierte Prüfung Hinweise auf schwerwiegenden oder wiederkehrenden Missbrauch, kann der Kunde weiterhin Einschränkungen unterliegen, bis hin zu Drosselung oder Sperrung gemäß den Product Terms for Responsible Use of Microsoft AI Services. Zusätzlich kann Microsoft einen Kunden nach einer erkannten Auffälligkeit bitten, der menschlichen Prüfung wieder zuzustimmen, um das Risiko künftiger Zugriffsbeschränkungen zu senken.

Drei Punkte, die für eine korrekte Erwartungshaltung wichtig sind:

Kein Zero-Data-Retention im Sinne von „gar keine Speicherung“. Der Begriff „Zero Data Retention“, unter dem dieses Thema häufig gesucht wird, ist Microsofts eigene Dokumentation nicht die Quelle - er beschreibt umgangssprachlich das Ergebnis (keine Speicherung für menschliche Prüfung mehr), nicht einen offiziellen Produktnamen mit exakt dieser Bedeutung. Automatisierte, algorithmische Prüfung bleibt aktiv.
Guardrails und Abuse Monitoring sind zwei getrennte Anträge. Wer zusätzlich die Content-Filter-Schwellenwerte ändern oder abschalten möchte, braucht ein eigenes Formular („Modified Guardrails“) - nicht dasselbe wie das Abuse-Monitoring-Formular.
Fortgeschrittene Modelle können strengere Kriterien haben. Microsoft weist ausdrücklich darauf hin, dass „some advanced Models sold by Azure“ strengere Voraussetzungen für das Abschalten des Abuse Monitoring haben können als der Standardfall.

Wer überhaupt einen Antrag stellen kann

Modified Abuse Monitoring ist eine sogenannte Limited-Access-Funktion. Microsofts offizielle FAQ dazu ist eindeutig: Limited-Access-Funktionen stehen ausschließlich Kundinnen und Kunden offen, die von Microsoft „managed“ werden - also mit einem Microsoft-Account-Team zusammenarbeiten. Wer nicht sicher ist, ob das eigene Unternehmen ein solcher „managed customer“ ist, soll laut Microsoft trotzdem das Formular ausfüllen; Microsoft prüft die Zugehörigkeit dann selbst und verweist bei fehlender Berechtigung auf mögliche Eligibility-Programme.

Zusätzliche Punkte aus der offiziellen FAQ, die für die Antragsvorbereitung relevant sind:

Registrierungsformulare mit privaten E-Mail-Adressen werden abgelehnt - nur geschäftliche Adressen der eigenen Organisation zählen.
Der genutzte Anwendungsfall muss zu den auf dem Formular gelisteten Optionen passen; Microsoft bittet, nicht gelistete Anwendungsfälle über ein separates Feedback-Formular zu melden statt über den Registrierungsprozess.
Eine Freigabe gilt für den bei der Registrierung angegebenen Anwendungsfall - Microsoft kann diese Angabe erneut abfragen.

In mehreren Community-Threads auf Microsoft Q&A berichten Nutzerinnen und Nutzer zusätzlich, dass eine Freigabe faktisch an einen Enterprise Agreement (EA) oder Microsoft Customer Agreement (MCA) gebunden sei und reine Pay-as-you-go-Abonnements abgelehnt würden. Das ist eine plausible, aber keine von Microsoft in der offiziellen Dokumentation so formulierte Aussage - die offizielle FAQ spricht generisch von „customers managed by Microsoft“, ohne Vertragsart explizit zu benennen.

Antrag und Verifikation: Formular, Bearbeitungsdauer und ContentLogging

Der Antrag läuft nicht über das Azure-Portal, sondern über ein Web-Formular, das Microsoft direkt von der Limited-Access-Seite aus verlinkt. Der grobe Ablauf:

Formular ausfüllen. Microsoft verlinkt das Modified-Abuse-Monitoring-Formular direkt von der offiziellen Limited-Access-Seite für Azure OpenAI aus. Für die Abschaltung der Content-Filter existiert ein separates Formular („Modified Guardrails“) - bei Bedarf beide parallel einreichen, da es zwei unterschiedliche Anträge sind.
Bearbeitungszeit einplanen. Microsofts offizielle FAQ zu Limited-Access-Funktionen nennt hierfür konkret 5 bis 10 Werktage bis zur ersten Rückmeldung - mit dem ausdrücklichen Hinweis, dass einzelne Prüfungen länger dauern können. Eine Bestätigungs-E-Mail folgt in jedem Fall, sobald die Prüfung abgeschlossen ist.
Reaktion abwarten. Bei Ablehnung liefert Microsoft keinen pauschalen Support-Weg zur manuellen Beschleunigung oder Übersteuerung der Gating-Entscheidung - das bestätigen auch mehrere Microsoft-Moderatorinnen und -Moderatoren in den Support-Foren. Eine erneute Einreichung mit zusätzlichem Kontext zum Anwendungsfall ist möglich.
Freigabe verifizieren. Nach einer Freigabe lässt sich der Status direkt in Azure prüfen - nicht nur per E-Mail-Vertrauen. In der JSON-Ansicht der Foundry-Ressource im Azure-Portal oder per Azure CLI (az cognitiveservices account show) erscheint im Capabilities-Feld ein Eintrag ContentLogging mit dem Wert false, sobald die Datenspeicherung für Abuse Monitoring abgeschaltet ist. Ohne Freigabe taucht dieses Feld laut Microsoft gar nicht erst auf - sein bloßes Fehlen ist also kein Fehlerzustand, sondern der Normalfall.

Die Freigabe gilt pro Azure-Subscription-ID, die im Formular angegeben wird - und dann laut Nutzerberichten in den Microsoft-Foren für alle Foundry-Ressourcen innerhalb dieser Subscription, nicht nur für eine einzelne Ressource. Bei mehreren Subscriptions ist entsprechend mehrfach zu beantragen.

Azure OpenAI vs. Claude auf Microsoft Foundry: unterschiedliche Mechanik

Wer sich mit dem Microsoft-Foundry-Portfolio beschäftigt, kennt inzwischen auch Claude als Modelloption dort - Microsoft hat Anthropics Claude-Modelle als Foundry-Angebot allgemein verfügbar gemacht. Für die Frage in diesem Artikel ist die Abgrenzung wichtig, um keine Verwechslung entstehen zu lassen: Der hier beschriebene Modified-Abuse-Monitoring-Mechanismus gilt für „Models sold by Azure“ - im Kern die klassischen Azure-OpenAI-Modelle. Für Claude-Modelle in Microsoft Foundry gilt laut Microsofts eigener Dokumentation zu Datenschutz und Sicherheit ein anderer Mechanismus.

Bei der Hosting-Option „Hosted on Azure“ verarbeitet zwar Azure-Infrastruktur die Prompts, aber automatische Schutzmechanismen markieren Inhalte, die an Anthropic Trust & Safety zur Prüfung weitergeleitet werden können - Anthropic-Personal prüft laut Microsoft „on an exceptions-only basis“, um potenzielle Sicherheitsverstöße zu untersuchen, nach Anthropics eigenen Bedingungen. Bei der Hosting-Option „Hosted on Anthropic Infrastructure“ verarbeitet Anthropic die Daten ohnehin auf eigener Infrastruktur, gegebenenfalls außerhalb der gewählten Azure-Region, gemäß Anthropics Data Processing Addendum.

Das bedeutet: Das in diesem Artikel beschriebene Formular und der Modified-Abuse-Monitoring-Prozess sind auf Azure-OpenAI-Modelle zugeschnitten. Für Claude auf Foundry ist die relevante Stellschraube das Zero-Data-Retention-Arrangement von Anthropic selbst, das wir an anderer Stelle ausführlich einordnen - ein eigenständiges Konzept mit eigenem Antragsweg über den Anthropic-Vertrieb, nicht über das hier beschriebene Microsoft-Formular. Wer beide Modellwelten im selben Tenant betreibt, sollte diese Unterscheidung in der eigenen Dokumentation sauber führen, um nicht versehentlich eine Zusage für die eine Modellfamilie auf die andere zu übertragen.

Für wen sich der Antrag lohnt: Berufsgeheimnisträger und § 203 StGB

Der naheliegendste Anlass für diesen Artikel ist eine Beobachtung aus öffentlich einsehbaren Microsoft-Q&A-Threads: Mehrere deutschsprachige Diskussionen dort beschäftigen sich ausdrücklich mit der Frage, wie Azure OpenAI mit Vertraulichkeitspflichten für Berufsgeheimnisträger - etwa Rechtsanwältinnen, Steuerberater oder Ärztinnen - zusammenpasst, und einige davon nennen dabei explizit § 203 StGB und eine von Microsoft angebotene „Professional Secrecy Amendment“ als Zusatzvereinbarung. Diese Häufung ist ein reales Nachfragesignal. Zu § 203 StGB und Cloud-KI im Allgemeinen gibt es durchaus deutschsprachige Fachbeiträge aus Kanzlei- und Beratungsperspektive - was dort fehlt, ist die konkrete Verzahnung mit Modified Abuse Monitoring als der technischen Gegenmaßnahme auf Microsoft-Seite. Genau diese Lücke füllt dieser Abschnitt.

Wichtig an dieser Stelle die Abgrenzung: Ob und wie § 203 StGB im Einzelfall auf die eigene Nutzung von Azure OpenAI zutrifft, welche technischen und organisatorischen Maßnahmen dafür ausreichen und ob eine Zusatzvereinbarung mit Microsoft die eigene strafrechtliche Verantwortung tatsächlich abdeckt, ist eine Rechtsfrage, die dieser Artikel nicht beantwortet und nicht beantworten sollte - dafür braucht es im Einzelfall juristische Beratung. Technisch lässt sich aber sauber einordnen: Wer in einer Branche mit erhöhten Vertraulichkeitsanforderungen an Mandanten-, Patienten- oder ähnlich sensible Daten arbeitet, hat mit der standardmäßigen menschlichen Prüfung im Abuse Monitoring einen zusätzlichen Prüfpunkt, der bei der eigenen Datenschutz- und Verschwiegenheitsbewertung mitgedacht werden muss - unabhängig davon, welche konkrete Rechtsnorm im eigenen Fall greift.

Über diese Berufsgruppen hinaus lohnt sich der Antrag grundsätzlich für jede Organisation, die mit hochsensiblen oder hochvertraulichen Daten arbeitet und aus eigener vertraglicher oder regulatorischer Verpflichtung heraus entweder nicht will oder nicht das Recht hat, Microsoft die Speicherung und menschliche Prüfung eigener Prompts und Antworten zu erlauben - so formuliert es die Microsoft-Dokumentation selbst als Zielgruppe für Modified Abuse Monitoring. Wer diese Voraussetzung nicht erfüllt, sollte den Antrag nicht vorschnell stellen: Weniger menschliche Prüfung bedeutet laut Microsoft auch weniger genaue Missbrauchserkennung - ein Kompromiss, der sich nur lohnt, wenn die Vertraulichkeitsanforderung tatsächlich höher wiegt als der Verlust an Erkennungsgenauigkeit.

Häufige Fragen zu Azure OpenAI Zero Data Retention und Modified Abuse Monitoring

Was ist der Unterschied zwischen Abuse Monitoring und Modified Abuse Monitoring?

Abuse Monitoring ist der Standardmechanismus: automatisierte Content-Klassifizierung und Mustererkennung, bei Bedarf ergänzt um automatisierte und in manchen Fällen menschliche Prüfung auffälliger Prompts und Antworten. Modified Abuse Monitoring ist der genehmigte Ausnahmezustand, in dem die menschliche Prüfung samt der dafür angelegten Datenspeicherung entfällt - automatisierte Prüfung bleibt laut Microsoft weiterhin möglich.

Deaktiviert Modified Abuse Monitoring die Datenspeicherung vollständig?

Es deaktiviert die Speicherung und menschliche Prüfung, die für den Human-Review-Prozess angelegt wird. Automatisierte, algorithmische Prüfung - laut Microsoft auch mithilfe von KI-Modellen - findet weiterhin statt, ohne dass die dafür geprüften Inhalte laut Dokumentation dauerhaft gespeichert werden.

Wer kann Modified Abuse Monitoring beantragen?

Laut Microsofts offizieller FAQ ausschließlich Kundinnen und Kunden, die von Microsoft „managed“ werden, also mit einem Account-Team zusammenarbeiten - mit geschäftlicher E-Mail-Adresse und einem zum Formular passenden Anwendungsfall. In Community-Berichten wird zusätzlich häufig ein Enterprise Agreement oder Microsoft Customer Agreement als faktische Voraussetzung genannt; das ist keine offiziell so dokumentierte Aussage und sollte vor einer Zusage direkt mit Microsoft abgeklärt werden.

Wie lange dauert die Bearbeitung des Antrags?

Microsofts offizielle FAQ zu Limited-Access-Funktionen nennt 5 bis 10 Werktage bis zur ersten Rückmeldung (Stand: August 2026), mit dem Hinweis, dass einzelne Prüfungen länger dauern können.

Gilt Modified Abuse Monitoring auch für Claude-Modelle in Microsoft Foundry?

Nein, jedenfalls nicht über denselben Mechanismus. Der beschriebene Prozess und das Formular gelten für „Models sold by Azure“, also im Kern Azure-OpenAI-Modelle. Claude-Modelle in Foundry folgen laut Microsofts eigener Dokumentation einem anderen Modell mit Anthropic Trust & Safety als prüfender Stelle beziehungsweise, je nach Hosting-Option, vollständiger Verarbeitung auf Anthropic-Infrastruktur.

Fazit

Azure OpenAI speichert standardmäßig keine Prompts im Modell selbst, legt aber für die automatisierte und gegebenenfalls menschliche Missbrauchsprüfung einen eigenen, ressourcenweise getrennten Datenspeicher an. Modified Abuse Monitoring schaltet genau diesen menschlichen Prüfschritt samt der dafür angelegten Speicherung ab - nicht die automatisierte Prüfung, und nicht die Möglichkeit, bei erkanntem schwerem Missbrauch weiterhin eingeschränkt zu werden. Der Weg dorthin ist kein Konfigurationsschalter, sondern ein Antrag, der Microsoft-Account-Team-Kundschaft vorbehalten ist, 5 bis 10 Werktage Bearbeitungszeit braucht und sich anschließend über das ContentLogging-Attribut technisch verifizieren lässt. Für Berufsgeheimnisträger und andere Organisationen mit hohen Vertraulichkeitsanforderungen ist das eine Frage, die vor dem Produktivbetrieb geklärt gehört - technisch, nicht juristisch, und mit realistischer Erwartung daran, was der Antrag tatsächlich verändert.

Quellen (Stand: August 2026, Abruf 20.08.2026):