KI im Unternehmen: AWS, Azure oder eigener Server?

Beide großen Anbieter stellen Sprachmodelle als verwalteten Dienst bereit — AWS über Bedrock, Microsoft über Azure OpenAI Service. Der entscheidende Unterschied zur direkten Nutzung eines Anbieter-Zugangs: Man kann die Region festlegen, in der die Verarbeitung stattfindet, und bekommt einen Auftragsverarbeitungsvertrag, der zu einem europäischen Betrieb passt.

Was dafür spricht: Die Anbindung an bestehende Systeme ist meist schon da. Wer ohnehin Microsoft 365 oder eine AWS-Landschaft betreibt, hat Identitäten, Rechte und Netzwerkgrenzen bereits geregelt — und genau daran scheitern Projekte sonst.

Was dagegen spricht: Die Abhängigkeit ist real. Preise, Modellauswahl und Bedingungen legt der Anbieter fest, und ein Wechsel ist Arbeit. Wer das vermeiden will, sollte die Anwendung von Anfang an so bauen, dass das Modell austauschbar bleibt.

Die Region legt fest, wo die Verarbeitung läuft. Sie sagt nichts darüber, wer von wo aus zugreifen darf — und genau daran hängt die rechtliche Bewertung. Jede Offenlegung gegenüber einem Empfänger im Drittland ist eine Übermittlung nach Kapitel V der DSGVO.

Für eine solche Übermittlung braucht es eine Grundlage: einen Angemessenheitsbeschluss, Standardvertragsklauseln oder ein anderes Instrument aus Artikel 46 DSGVO. Der Europäische Gerichtshof hat in der Rechtssache C-311/18 entschieden: Klauseln allein genügen nicht, wenn das Recht des Empfängerlands sie aushebelt.

Was ein Anbieter unter europäischer Region versteht, steht in seiner eigenen Dokumentation. Microsoft beschreibt die EU Data Boundary samt der Ausnahmen für Unterstützung und Bedrohungsanalyse. Wer das nicht liest, hält eine Einstellung für eine Zusage.

Dieselbe Dokumentation beantwortet die zweite Frage: ob Eingaben zum Training verwendet werden, wie lange sie gespeichert bleiben und wer sie im Missbrauchsfall sehen darf. Microsoft und AWS halten das schriftlich fest — nachlesen muss es trotzdem jemand.

Vorher steht die Rollenfrage. Ein Anbieter, der die Daten für eigene Zwecke nutzt, ist kein Auftragsverarbeiter nach Artikel 4 Nummer 8 DSGVO. Dann trägt dieser Vertragstyp die Sache nicht.

Der Europäische Datenschutzausschuss hat für die Modellebene eine eigene Stellungnahme vorgelegt. Sie behandelt, wann ein Modell selbst als anonym gilt und was unrechtmäßig verarbeitete Trainingsdaten für den späteren Einsatz bedeuten.

Wer nachprüfen will, ob ein verwalteter Dienst den Vertrag auch einhält, fragt nach einem Testat. Der Kriterienkatalog C5 des Bundesamts für Sicherheit in der Informationstechnik ist der Rahmen — danach fragt in Deutschland ein Prüfer.

Artikel 28 Absatz 3 DSGVO zählt auf, was der Vertrag mindestens regeln muss. Die Liste ist kurz genug, um sie beim Lesen eines Anbietervertrags abzuhaken:

Offene Modelle lassen sich auf eigener Hardware betreiben. Damit verlassen die Daten das Haus nicht — das stärkste Argument in Bereichen, in denen das schlicht Voraussetzung ist: Gesundheitswesen, Verteidigung, Teile der öffentlichen Verwaltung.

Der Preis dafür ist Betrieb. Grafikkarten, Überwachung, Aktualisierungen, jemand, der nachts erreichbar ist. Diese Kosten fallen an, ob das System genutzt wird oder nicht, während man beim Hyperscaler nach Verbrauch zahlt.

Die ehrliche Faustregel: Eigener Betrieb lohnt sich, wenn die Nutzung hoch und gleichmäßig ist — oder wenn eine Vorschrift keine Wahl lässt. Für den ersten Anwendungsfall ist er fast immer der teurere Weg.

Betrieb ist keine einmalige Einrichtung, sondern eine Liste, die nie leer wird. Ein Beispiel dafür: Ein öffentlich erreichbarer Container lief monatelang auf Node 20.

Diese Version ist im April 2026 aus der Wartung gefallen und bekommt seither keine Sicherheitsaktualisierungen mehr. Aufgefallen ist das bei einer Durchsicht, nicht im laufenden Betrieb — eine Laufzeit ohne Wartung meldet sich nicht von selbst.

Der Nachfolger Node 22 steht bis April 2027 in Wartung. Der Wechsel selbst war eine Zeile im Dockerfile. Die Arbeit steckte davor: Jemand muss hinsehen, und dieser Jemand muss wissen, wonach.

Dazu kommt, was fertig ist und trotzdem nicht laufen darf. Ein selbst betriebener Anmeldedienst bleibt abgeschaltet, solange er kein Zertifikat für seine Domain hat.

Die Reihenfolge ist dabei nicht beliebig. Der Aussteller steckt in jedem ausgegebenen Token — ein Domainwechsel nach der ersten echten Anmeldung entwertet alle bestehenden Sitzungen.

Verbrauchsabrechnung heißt, dass ein Programmierfehler eine Rechnung ist. Eine Schleife über zweitausend Suchbegriffe ist in einer Minute geschrieben und in derselben Minute teuer.

Deshalb steht vor jedem bezahlten Aufruf ein Zähler, der die tatsächlichen Kosten aus der Antwort mitschreibt und bei einem gesetzten Betrag abbricht. Der Haken steckt im Wort Prozess: Der Zähler lebt im Programmlauf, nicht im Kalendertag.

Zehn Starts hintereinander zählen zehnmal von vorn. Ein echtes Tageslimit gehört deshalb in das Konto beim Anbieter — die Bremse im Programm ersetzt es nicht.

Der zweite Fehler ist die Höhe. Steht die Bremse über dem Guthaben, greift sie erst, wenn das Konto schon leer ist.

Wie weit eine Schätzung danebenliegt, zeigt eine Messung: Ein Trockenlauf über acht Kandidatenthemen kostete 17,8 Cent. Veranschlagt waren 13 Cent — und zwar für den ganzen Durchgang, nicht für dessen ersten Schritt.

Fixkosten kennt man vorher. Verbrauchskosten entstehen beim Benutzen — und wer sie nicht misst, kennt sie erst auf der Rechnung.

An zwei Stellen, und keine davon ist die Schnittstelle. Die erste ist die Adresse des Dienstes: Steht sie fest im Quelltext, ist ein Umzug ein Eingriff in die Anwendung. Steht sie in einer Umgebungsvariablen, ist er eine Zeile Konfiguration.

In derselben Kette liegen beide Fassungen nebeneinander. Zwei Zugänge lesen ihre Basisadresse aus einer Umgebungsvariablen. Ein dritter trägt sie fest verdrahtet — dort kostet derselbe Umzug einen Eingriff.

Die zweite Stelle sind die Parameter. Modelle, die gestern noch einen Regler für die Streuung annahmen, antworten heute mit HTTP 400 auf genau diesen Wert.

Der übliche Rat lautet, die Bindung durch eine eigene Schicht kleinzuhalten. Der Rat stimmt, und er ist nicht umsonst: Wer kein fertiges Anbieterpaket einbindet, pflegt Modellkennungen, Parameternamen und Beta-Kennzeichen selbst.

Die Schicht macht den Wechsel also nicht billiger. Sie verschiebt die Arbeit — von einem großen Umbau später auf laufende Pflege jetzt.

Der Vertrag regelt, was der Anbieter darf — nicht, wohin die eigene Anwendung nebenbei funkt. Diese zweite Frage lässt sich technisch beantworten statt vertraglich.

Eine Content-Security-Policy ist eine Positivliste erlaubter Gegenstellen, die der Browser durchsetzt. Wer eine neue externe Verbindung einbaut und sie dort nicht einträgt, bekommt keine Fehlermeldung, sondern eine stillschweigend blockierte Anfrage.

Denselben Weg gibt es rückwärts. Zwei fremde Ziele standen in dieser Liste, weil der Browser des Besuchers direkt dorthin meldete. Das läuft heute serverseitig, und die Liste ist wieder kürzer.

Eine Ebene tiefer entscheidet ein Namenspräfix. Bei Next.js wandert jede Variable mit dem Präfix NEXT_PUBLIC_ in das ausgelieferte Bündel — ein Schlüssel darin steht im Quelltext jeder Seite.

Das gilt für den verwalteten Dienst und für den eigenen Server gleichermaßen. Der Ort der Verarbeitung ändert nichts daran, wer den Schlüssel lesen kann.

Die Wahl fällt selten am Modell, sondern an vier nüchternen Fragen:

Manche Pflichten wirken unmittelbar auf den Betrieb. Artikel 12 der KI-Verordnung verlangt für Hochrisiko-Systeme eine automatische Aufzeichnung von Ereignissen. Wer solche Protokolle führen muss, entscheidet über Speicherort und Aufbewahrung nicht mehr frei.

Der zweite Weg läuft über Verträge. Die NIS2-Richtlinie verpflichtet betroffene Einrichtungen in Artikel 21 Absatz 2 zur Sicherheit ihrer Lieferkette. Diese Anforderungen erreichen dann Zulieferer, die selbst nicht unter die Richtlinie fallen — über den Vertrag mit dem Kunden.

In den meisten Betrieben führt der Weg über einen verwalteten Dienst in europäischer Region, mit sauber gezogenen Grenzen: welche Daten hineindürfen, welche nicht, und einer Anwendungsschicht dazwischen, die den Anbieter austauschbar hält.

Der eigene Server kommt dann später, wenn die Nutzung es rechtfertigt oder eine Vorschrift es verlangt. Diese Reihenfolge kostet weniger und macht früher etwas nutzbar — und sie verbaut nichts.

Sie hält auch den ersten Fehler klein — wer die Reihenfolge umdreht, kauft Hardware für eine Last, die noch niemand gemessen hat.