Amazon und Unternehmens-KI: Wie Modelle, Verantwortlichkeiten und Support zwischen Bedrock, Nova, SageMaker und integrierten Diensten verteilt sind

Die richtige Frage: Was bedeutet es, KI „von Amazon“ einzuführen?

Wenn eine Organisation erklärt, sie werde KI „von Amazon“ einsetzen, fasst sie eine Entscheidung zu stark zusammen, die verschiedene Produkte umfassen kann. Gemeint sein kann, ein Modell der Amazon-Nova-Familie über eine verwaltete Schnittstelle aufzurufen, über Amazon Bedrock auf ein von einem anderen Unternehmen entwickeltes Modell zuzugreifen, mit Amazon SageMaker AI ein Modell anzupassen, zu trainieren oder bereitzustellen oder eine in einem anderen AWS-Dienst integrierte KI-Funktion zu aktivieren. Jede dieser Optionen verändert, was vertraglich bezogen, konfiguriert und protokolliert wird und wer eine Änderung oder einen Vorfall untersuchen muss.

Die Marke der Plattform beseitigt nicht die Notwendigkeit, das konkrete Modell, seine Version, die Region, das AWS-Konto, den Aufrufmodus und die geltenden Bedingungen zu identifizieren. In Bedrock wird ein Modell eines Drittanbieters zudem vertraglich als Drittanbieterinhalt behandelt. Dass ein Aufruf über eine AWS-API läuft, erlaubt daher nicht den Schluss, dass Nutzungsbedingungen, Beschränkungen oder Zusagen des Modellanbieters denen eines von Amazon entwickelten Modells entsprechen.

Für Technologieeinkauf, Architektur und Risikofunktionen ist nicht der Name des Cloud-Anbieters die nützliche Analyseeinheit. Sie ist eine überprüfbare Kombination aus Anwendungsfall, Zugangsdienst, genauem Modell oder genauer Funktion, Sicherheitskonfiguration, verarbeiteten Daten, Region und intern verantwortlicher Stelle. Mit einem solchen Inventar lassen sich dokumentierte Fakten von Annahmen über Qualität, künftige Verfügbarkeit oder regulatorische Konformität trennen.

Diese Unterscheidung vermeidet auch zwei häufige Fehler. Der erste besteht darin, einen verwalteten Dienst mit der vollständigen Übertragung des Betriebs gleichzusetzen: AWS kann die zugrunde liegende Infrastruktur betreiben, während der Kunde Entscheidungen zu Identitäten, Berechtigungen, Datenklassifizierung, Protokollzielen und der Konfiguration von Schutzmechanismen behält. Der zweite besteht darin, anzunehmen, ein Modellkatalog sei bereits eine technische oder rechtliche Empfehlung für einen bestimmten Fall. Verfügbarkeit ist eine Zugangsvoraussetzung; sie belegt für sich allein weder Leistung noch Eignung, Datenresidenz oder vertragliche Zulässigkeit.

Schichtenkarte: Nova, Bedrock, SageMaker AI und integrierte Funktionen

Amazon Nova bezeichnet eine Modellfamilie von Amazon. Die Service Card für Amazon Nova 2 Lite verortet die Nutzung in Amazon Bedrock und beschreibt Kontrollen sowie Einschränkungen des Modells aus der Perspektive verantwortungsvoller KI. Diese Herkunft ist relevant: Wird ein Nova-Modell über Bedrock aufgerufen, muss das Team sowohl die Bedingungen und Kontrollen von Bedrock als auch die spezifische Dokumentation des ausgewählten Modells bewerten.

Amazon Bedrock ist eine Dienstschicht, um mit Basismodellen über verwaltete Schnittstellen zu arbeiten. Sein Katalog kann Modelle von Amazon und von Drittanbietern enthalten. Der Dienst macht nicht alle diese Modelle zu von Amazon entwickelten Produkten und vereinheitlicht auch nicht automatisch die Pflichten, die mit jedem Anbieter verbunden sind. Die Vertragsdokumentation von AWS stellt ausdrücklich fest, dass Drittanbietermodelle in Bedrock Drittanbieterinhalt sind, und verweist auf zusätzliche spezifische Bedingungen.

Amazon SageMaker AI steht für eine andere Art von Entscheidung. Seine Dokumentation zum Datenschutz wendet das Modell der geteilten Verantwortung an: AWS schützt die Infrastruktur, die den Dienst betreibt, und der Kunde behält Verantwortung für Konfiguration, Daten, Identitäten und die sichere Nutzung der bereitgestellten Ressourcen. In einer Architektur mit SageMaker AI kann der Kunde mehr Kontrolle über den operativen Zyklus von Training, Anpassung oder Endpunkt haben; diese Kontrolle erweitert jedoch auch den Umfang der Entscheidungen, die er steuern muss.

Schließlich enthalten einige AWS-Dienste KI-Funktionen, die als Teil des jeweiligen Dienstes genutzt werden. Sie sollten nicht automatisch mit einem direkten Modellaufruf in Bedrock oder einem vom Kunden verwalteten Endpunkt in SageMaker AI gleichgesetzt werden. Die Bewertung muss mit der Dokumentation des konkreten Dienstes beginnen: welche Daten die Funktion annimmt, wo sie verarbeitet wird, welche Protokolle sie bereitstellt und welche Sicherheitskonfigurationen sie unterstützt.

Zugangskanäle und operative Kontrolle

Eine verwaltete API verringert die Notwendigkeit, Inferenzinfrastruktur selbst zu betreiben, hebt aber Anwendungsentscheidungen nicht auf. In Bedrock wählt der Kunde weiterhin das freigeschaltete Modell, die Konfiguration der Anfragen, die zum Aufruf berechtigten Identitäten und die Mechanismen zur Beobachtbarkeit. Bei einem Drittanbietermodell müssen außerdem die Bedingungen dieses Dritten in die Freigabeunterlagen aufgenommen werden. Diese Prüfung ist nicht bloß administrativ: Sie kann erlaubte Nutzungen, Beschränkungen und Compliance-Pflichten beeinflussen.

Die Anpassung oder Bereitstellung eines eigenen Endpunkts in SageMaker AI verschiebt den operativen Schwerpunkt. Die Organisation erhält einen Rahmen, um mehr Elemente der Workload zu steuern, muss jedoch die für ihre Architektur erforderliche Zugriffs-, Netzwerk-, Verschlüsselungs-, Überwachungs- und Lebenszykluskonfiguration entwerfen und betreiben. Geteilte Verantwortung ist keine feste Kontrollliste; sie hängt von den tatsächlich genutzten Ressourcen und Optionen ab.

Vorgefertigte KI-Funktionen bieten eine noch stärkere Abstraktion, doch stärkere Abstraktion ist nicht gleichbedeutend mit geringerem Risiko. Das Team muss prüfen, welche Eingaben der Dienst erzeugt, welche Ausgaben anschließend ein anderes System nutzt, welche Berechtigungen Aktionen erlauben und ob ein nützliches Protokoll zur Überprüfung der Ergebnisse vorhanden ist. Dieselbe Geschäftsaufgabe – etwa die Extraktion von Informationen aus Dokumenten – kann unterschiedliche operative Profile haben, je nachdem, ob sie mit einer integrierten Funktion, einem Bedrock-Workflow oder einem SageMaker-AI-Endpunkt gelöst wird.

Die Wahl sollte nicht allein nach Integrationsgeschwindigkeit erfolgen. Sie muss auch die Umkehrbarkeit berücksichtigen. Ein Team muss wissen, wie ein Modell ersetzt wird, wie ein Ersatz getestet werden kann, wie stark die Abhängigkeit von einer API oder einem Eingabeformat ist und wer Änderungen freigibt. Das ist besonders relevant, wenn die Ausgabe Entscheidungen, externe Kommunikation oder automatisierte Handlungen speist.

Geteilte Verantwortung für Daten, Prompts und Aktionen

Die Bedrock-Dokumentation zum Datenschutz erläutert das Modell der geteilten Verantwortung und beschreibt Maßnahmen wie Verschlüsselung, TLS, Integration mit AWS CloudTrail sowie Optionen für private Konnektivität über VPC und AWS PrivateLink. Diese Fähigkeiten sind Nachweise für verfügbare oder vom Dienst bereitgestellte Kontrollen; sie beweisen nicht, dass sie aktiviert sind oder dass eine konkrete Implementierung für bestimmte Daten oder regulatorische Anforderungen geeignet ist.

Dieselbe Dokumentation unterscheidet den Betrieb von Bedrock von den Modellanbietern. Eine ernsthafte Prüfung trennt daher drei Ebenen: die Verantwortlichkeiten von AWS als Dienstbetreiber, die Bedingungen und Beschränkungen des Anbieters bei einem Drittanbietermodell sowie die Pflichten des Kunden, der den Ablauf gestaltet. Zu Letzteren gehören typischerweise die Vergabe von Berechtigungen, die Auswahl der gesendeten Daten, die Definition der Aufbewahrung an gewählten Protokollzielen und die Aufsicht über Systeme, die auf eine Ausgabe reagieren.

Die Service Card zu Amazon Nova 2 Lite erklärt, dass AWS die über Bedrock verarbeiteten Eingabe- und Ausgabedaten nicht zum Trainieren der Bedrock-Modelle, einschließlich Nova 2 Lite, verwendet. Das ist eine relevante Aussage für die von AWS beschriebene Verarbeitung, darf jedoch nicht ohne Prüfung auf sämtliche Produkte, Konfigurationen, Anbieter oder unterstützenden Ziele einer Architektur erweitert werden. Beispielsweise bilden vom Kunden aktivierte Protokolle einen eigenen Datenfluss und erfordern eine separate Entscheidung zu Speicherung und Zugriff.

Wenn eine Anwendung die Modellantwort zur Ausführung externer Aktionen verwendet, erstreckt sich die Verantwortung auf das Autorisierungsdesign. Das Modell darf nicht als Zugriffsinstanz angesehen werden. Die Anwendung sollte Berechtigungen prüfen, zulässige Operationen begrenzen, empfangene Anweisungen als nicht vertrauenswürdige Daten behandeln und ausreichende Nachweise zur Untersuchung einer Aktion aufbewahren. Dies sind empfehlenswerte Designmaßnahmen; die vorliegenden Quellen erlauben nicht die Aussage, dass eine bestimmte Konfiguration sie standardmäßig umsetzt.

Lebenszyklus, Regionen, Kontingente und Ersatz

Der Lebenszyklus eines Modells ist eine operative Anforderung und keine beiläufige Katalognotiz. Die Bedrock-Dokumentation definiert die Zustände Active, Legacy und End-of-Life und stellt das Feld modelLifecycle zur Statusabfrage bereit. Ein Modell kann während eines Übergangs weiterhin sichtbar sein, ohne dass es für eine neue Implementierung ausgewählt werden sollte. Teams müssen diese Zustände in ihrem Inventar erkennen und den Produktionsabläufen zuordnen, die vom Modell abhängen.

Die Dokumentation zum Lebenszyklus beschreibt Hinweise und Prozesse im Zusammenhang mit Rücknahme oder Ersatz. Ein interner Plan sollte sich dennoch nicht darauf verlassen, dass ein Hinweis für eine rechtzeitige Reaktion genügt. Es muss einen Weg geben, betroffene Aufrufe zu ermitteln, eine Alternative zu erproben, Ergebnisse zu vergleichen und Anwendungskonfigurationen zu aktualisieren. Bei Anwendungen mit hoher Auswirkung verlangt ein solcher Ersatz auch eine erneute Risiko- und Kontrollbewertung, nicht nur einen Verbindungstest.

Auch die Region ist Teil der Entscheidung. Die Konfiguration der Bedrock-Aufrufprotokollierung wird je Konto und Region verwaltet. Modellverfügbarkeit, Kontingente und Zugangsarten können ebenfalls variieren; sie dürfen daher nicht aus einer anderen Region oder einer Erfahrung in der Konsole abgeleitet werden. Vor der Produktionsaufnahme muss die Organisation die aktuelle Verfügbarkeit in der Zielregion prüfen und den Nachweis dieser Prüfung dokumentieren.

Kontingente bestimmen die reale Kapazität eines Designs, dürfen aber nicht mit Leistungszusagen für einen Geschäftsfall verwechselt werden. Die technischen Unterlagen müssen die relevanten Grenzen, die Strategie bei Fehlern oder Ratenbegrenzung und das sichere Verhalten erfassen, wenn das Modell oder der Dienst nicht antwortet. Die vorliegenden Quellen stützen die Notwendigkeit, diese Variablen zu prüfen, erlauben aber keine Aussage über universelle Kontingent- oder Verfügbarkeitswerte für alle Modelle.

Veröffentlichte Sicherheit, konfigurierbare Kontrollen und Nachvollziehbarkeit

Bedrock erlaubt die Konfiguration der Aufrufprotokollierung in Amazon CloudWatch Logs und Amazon S3. Die Dokumentation besagt, dass diese Protokollierung standardmäßig deaktiviert ist und ihre Konfiguration konten- und regionsspezifisch erfolgt. Sie kann Informationen über Eingaben und Ausgaben, Modell, Identität, Operation, Region und Fehler enthalten. Ihr Wert für Audits hängt davon ab, dass die Organisation sie aktiviert, geeignete Ziele festlegt und den Zugriff darauf kontrolliert.

Diese Funktion schafft eine operative Spannung, die ausdrücklich aufgelöst werden muss. Mehr Kontext zu protokollieren erleichtert die Untersuchung von Vorfällen, die Reproduktion von Ergebnissen und die Zuordnung von Aufrufen; zugleich können Prompts und Antworten sensible Daten oder Unternehmensinformationen enthalten. Die Entscheidung muss die Protokollrichtlinie mit Datenklassifizierung, Zugriffskontrollen, Verschlüsselung, Aufbewahrung und den in der Organisation geltenden Löschverfahren verbinden. Es genügt nicht festzustellen, dass Logging verfügbar ist.

CloudTrail, private Netzwerkoptionen und die für Bedrock beschriebenen Verschlüsselungsmechanismen können Bestandteile einer vertretbaren Architektur sein, ihre Wirksamkeit hängt jedoch von Konfiguration und Umfang des Ablaufs ab. Ebenso weist die Dokumentation von SageMaker AI dem Kunden Sicherheitsverantwortlichkeiten in der Cloud zu. Die Freigabe eines Anwendungsfalls sollte Konfigurationsnachweise verlangen und sich nicht auf eine Liste von Produktfunktionen beschränken.

Auch technische Nachweise und vertragliche Nachweise sind zu unterscheiden. Servicebedingungen können Beschränkungen für Drittanbietermodelle und automatisierte Mechanismen zur Missbrauchserkennung festlegen, während technische Dokumentation Verhalten und Dienstoptionen erläutert. Keine der beiden Formen ersetzt eine Bewertung spezifischer regulatorischer Anforderungen, die eine unabhängige rechtliche, datenschutzrechtliche und sicherheitliche Prüfung erfordern kann.

Entscheidungsmatrix nach Anwendungsfall

Es gibt keine automatische Zuordnung zwischen einem Geschäftsfall und einem Dienst. Die folgende Matrix empfiehlt kein konkretes Produkt; sie benennt Fragen, die vor einer Auswahl beantwortet werden müssen. Das Ergebnis kann eine verwaltete API, ein Design auf SageMaker AI, eine integrierte Funktion oder die Feststellung sein, dass für die Produktion noch keine ausreichenden Nachweise vorliegen.

Bei einem Prototyp mit nicht sensiblen Daten kann ein schneller Zugang Vorrang haben, doch es braucht weiterhin eine klare Trennung von Echtdaten und eine Prüfung der geltenden Bedingungen. In einem unternehmensweiten RAG-System sind häufig die Kontrolle über Dokumentenquellen, Abrufberechtigungen, Protokolle und die Behandlung von Ergebnissen entscheidend. Bei Automatisierung mit Aktionen verlagert sich der Schwerpunkt auf Autorisierung, Validierung und Nachvollziehbarkeit jeder externen Operation.

Eine Anforderung an Datenresidenz, Auditierbarkeit oder Aufbewahrung darf nicht durch eine Annahme aus dem Namen eines Dienstes erfüllt werden. Region, Protokollkonfiguration, Datenziele, ausgewähltes Modell und geltende Bedingungen müssen überprüft werden. Wenn einer dieser Nachweise fehlt, ist es die vorsichtige Entscheidung, die Anforderung als offen und nicht als erfüllt zu klassifizieren.

Checkliste vor der Bereitstellung

Die Produktionsfreigabe sollte Unterlagen hervorbringen, die für technische Teams und Kontrollfunktionen lesbar sind. Ihr Ziel ist nicht zu beweisen, dass jede Unsicherheit verschwunden ist, sondern klarzumachen, was geprüft wurde, was von einer Konfiguration abhängt und was offen bleibt. Die Liste muss überprüft werden, wenn sich Modell, Lebenszyklusstatus, Region, Anbieter, Daten oder freigeschaltete Aktionen ändern.

Zunächst ist der Zugangsvertrag zu bestimmen: AWS-Dienst, Modell, Modellanbieter, falls dieser nicht Amazon ist, und zusätzliche Bedingungen. Danach ist der technische Geltungsbereich zu dokumentieren: Konto, Region, Aufrufart oder Endpunkt, Identitäten, Berechtigungen und Grenzen. Drittens sind Datenflüsse getrennt zu beschreiben: Eingabe, abgerufener Kontext, Ausgabe, Protokolle und nachgelagerte Speicherung.

Anschließend sind die Kontrollen zu testen. Es ist zu bestätigen, dass Protokolle, sofern erforderlich, im passenden Konto und in der passenden Region aktiviert sind und dass ihre Ziele über den vorgesehenen Zugriff und die vorgesehene Aufbewahrung verfügen. Aufrufberechtigungen, gewählte Netzwerkpfade und Fehlerbehandlung sind zu überprüfen. Führt der Ablauf Aktionen aus, sollten Fehler, unerwartete Antworten und verweigerte Autorisierungen erprobt werden.

Abschließend ist ein Ersatzplan festzulegen. Er muss angeben, wie eine Änderung des Lebenszyklus erkannt wird, welche Alternative bewertet wird, welches Kriterium ihre Freigabe erlaubt und wer für die Migration verantwortlich ist. Diese Planung garantiert nicht, dass ein alternatives Modell gleichwertige Ergebnisse liefert; gerade deshalb sind Tests und eine ausdrückliche Entscheidung erforderlich.

Was sich aus dem Katalog nicht ableiten lässt

Der Bedrock-Katalog und die Existenz von Amazon-Nova-Modellen erlauben nicht den Schluss, dass ein Modell für eine bestimmte Aufgabe geeignet ist. Dokumentation zu Verfügbarkeit, Lebenszyklus oder Kontrollen beschreibt Fähigkeiten und Zustände, doch Qualität hängt vom Anwendungsfall, den Daten, dem Prompt-Design, den Bewertungen und den vom Kunden definierten Akzeptanzkriterien ab. Die Validierung muss mit repräsentativen Tests und mit Aufmerksamkeit für mögliche Ausgabefehler erfolgen.

Ebenso lässt sich daraus nicht ableiten, dass ein gehostetes Modell sämtliche Verantwortung auf AWS oder den Modellanbieter überträgt. Die Bedrock- und SageMaker-AI-Dokumentation belässt dem Kunden eine klare Rolle bei Konfiguration und Schutz seiner Umgebung. Die Bedingungen für Drittanbietermodelle fügen eine weitere Ebene hinzu, die nicht aus der Prüfung verschwinden darf, nur weil der technische Zugang zentralisiert ist.

Schließlich bedeutet mehr Kontrolle über Infrastruktur nicht, dass mehr Sicherheit nachgewiesen ist. Ein Endpunkt und seine Ressourcen können zusätzliche Gestaltungsoptionen bieten, erfordern jedoch auch zusätzliche Konfigurationen und Nachweise. Umgekehrt kann eine verwaltete API Infrastrukturaufgaben verringern, ohne die Data Governance, Zugriffskontrolle, Ergebnisbewertung oder Autorisierung von Aktionen eigenständig zu lösen.

Die operative Schlussfolgerung ist bewusst begrenzt: AWS stellt mehrere Schichten für die Einführung von KI bereit, und die geprüften Quellen erlauben die Unterscheidung einiger Verantwortlichkeiten, Kontrollen und Lebenszyklusmechanismen. Sie erlauben weder die Zertifizierung der Konformität eines konkreten Anwendungsfalls noch die Vorhersage der künftigen Verfügbarkeit eines Modells oder die Erklärung funktionaler Gleichwertigkeit zwischen Alternativen. Solche Schlussfolgerungen erfordern eine aktuelle Prüfung und Nachweise aus der tatsächlichen Bereitstellung.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.