KI-Sicherheit entscheidet sich in der KI-Infrastruktur

KI-Infrastruktur ist mehr als ein Stapel GPU-Server

Wer über KI-Infrastruktur spricht, meint oft nur die Rechenkapazität. Tatsächlich sind es fünf Schichten, und jede davon kann ein Vorhaben aufhalten.

• Rechenkapazität. GPU- oder spezialisierte Beschleunigerhardware, dimensioniert auf Modellgröße, erwartete Last und Latenzanforderung. Ob gemietet, im eigenen Rechenzentrum oder in einer souveränen Cloud, ist eine Folgeentscheidung, keine Vorentscheidung.
• Speicher. Modellgewichte, Referenzmaterialien, Protokolle. Modelle sind groß, und sie werden mehrfach vorgehalten, wenn mehrere Versionen parallel laufen sollen.
• Netz. Durchsatz und Latenz zwischen Anwendung, Inferenz und Datenquellen. Mandantentrennung beginnt hier und nicht erst in der Anwendung.
• Plattform. Die Orchestrierung, die Modelle startet, skaliert, verteilt und Zugriffe steuert. In der Regel eine Container-Plattform, weil sich GPU-Kapazität darüber planbar zuteilen lässt.
• Betrieb. Monitoring, Patch- und Update-Management, Wiederanlauf, Rufbereitschaft. Die Schicht, die im Pilotprojekt fehlt und im Regelbetrieb den Unterschied macht.

Technisch lässt sich das in drei Bausteine schneiden, die bewusst austauschbar bleiben sollten: eine Hosting-Schicht für offene oder lizenzierte Modelle, eine Inferenz-Laufzeitumgebung auf der Beschleunigerhardware und eine Orchestrierungsschicht für Skalierung, Lastverteilung und Zugriffssteuerung. Sind diese drei Bausteine sauber getrennt, kosten eine neue Modellversion, ein anderes Hardware-Backend oder ein Wechsel der Hosting-Umgebung keine Neuentwicklung.

Zwei Dinge gehören ausdrücklich nicht in diese Aufzählung. Das Training von Modellen ist eine eigene Disziplin mit anderem Lastprofil als die Inferenz, also die Nutzung eines fertigen Modells für Anfragen. Und die Datenschicht, also Datenintegration, Vektor-Datenbanken und die Pipelines für Retrieval, ist ein eigenes Vorhaben mit eigenen Zuständigkeiten. Wer beides mit der Inferenz-Plattform in ein Projekt packt, plant drei Projekte als eines.

KI-Sicherheit ist keine Eigenschaft des Modells

In Sicherheitsdiskussionen zu KI geht es meist um das Modell: Halluzinationen, Jailbreaks, Filter. Das sind reale Themen, aber sie beschreiben das Verhalten eines Systems, nicht seine Angriffsfläche. Die Angriffsfläche liegt in der Infrastruktur, und sie hat vier Seiten.

Daten. Bei externen Modell-APIs verlässt jede Anfrage samt der Daten im Prompt die eigene Umgebung. Das ist unkritisch, solange nur öffentliche Informationen mitgehen, und heikel, sobald Personenbezug, Geschäftsgeheimnisse oder regulierte Inhalte im Spiel sind. In der Praxis ist selten dokumentiert, welche Inhalte tatsächlich mitgehen, weil Prompts aus Vorlagen, Kontextfenstern und angehängten Dokumenten zusammengesetzt werden.

Zugriff. Wer darf welches Modell mit welchen Daten anfragen? Eine Inferenz-Umgebung ohne Zugriffssteuerung und ohne Mandantentrennung ist eine gemeinsame Datenbank mit natürlichsprachlicher Schnittstelle. Mehrere Anwendungen auf derselben GPU brauchen dieselbe Trennung wie mehrere Anwendungen auf demselben Datenbankserver.

Modelle. Wer keine Kontrolle über Modellversionen hat, bekommt Verhaltensänderungen ungefragt. Ein Anbieter-Update kann Antworten verändern, die in einem Prozess bereits abgenommen waren. Für geprüfte Abläufe ist eine feste, nachvollziehbare Modellversion eine Sicherheitsanforderung und keine Komfortfrage.

Prompts und Ergebnisse. Prompts, hochgeladene Referenzmaterialien und generierte Ergebnisse sind selbst schützenswerte Daten. Standard-Nutzungsbedingungen externer Anbieter erlauben es häufig, sie zur Modellverbesserung weiterzuverwenden. Gegenüber eigenen Auftraggebern lässt sich das Gegenteil nur belegen, wenn es technisch erzwungen ist.

Die fünfte Seite ist die Verfügbarkeit. Sobald eine KI-Funktion in einem Kundenprozess hängt, ist ihr Ausfall ein Betriebsvorfall. Dann braucht sie Wiederanlauf, Rufbereitschaft und einen Zuständigen, nicht nur ein Dashboard.

DSGVO-konforme KI beginnt bei der Frage, wo die Inferenz läuft

Ob eine KI-Anwendung DSGVO-konform betrieben werden kann, entscheidet sich an drei infrastrukturnahen Punkten. Die rechtliche Bewertung gehört in Ihre Rechtsabteilung oder zu spezialisierten Kanzleien. Technisch vorbereiten lässt sie sich aber nur so.

Wo die Daten verarbeitet werden. Die Verarbeitung findet dort statt, wo die Inferenz läuft, nicht dort, wo Ihre Anwendung gehostet ist. Wenn eine Anwendung in Frankfurt läuft und ihre Anfragen an eine Modell-API in einer anderen Jurisdiktion schickt, ist der Verarbeitungsort die Modell-API. Eine Inferenz-Umgebung im eigenen Rechenzentrum oder in einem europäischen, souveränen Rechenzentrum verschiebt diesen Punkt zurück unter die eigene Kontrolle.

Wer als Auftragsverarbeiter auftritt. Jeder Dienst in der Kette ist zu benennen, vom Hosting über die Inferenz bis zu Protokollierung und Monitoring. Bei einer selbst betriebenen KI-Infrastruktur ist diese Kette kurz und dokumentierbar. Bei einer Kette aus SaaS-Werkzeug, Middleware und Modell-API ist sie oft länger, als in der Verarbeitungsübersicht steht.

Wer Zugriff hat. Zugriff meint nicht nur Ihre Mitarbeitenden, sondern auch Support- und Betriebszugänge auf der Anbieterseite sowie die Frage, ob Prompts und Ergebnisse für Trainingszwecke weiterverwendet werden dürfen. Das ist der Punkt, an dem sich Nutzungsbedingungen und Datenschutzerklärung unterscheiden können.

Daraus folgt kein Verbot externer Dienste. In der Praxis führt es zu einem hybriden Modell: Unkritische Anwendungsfälle laufen weiter über Standard-Werkzeuge, während sensible oder kundenbezogene Verarbeitung in einer kontrollierten Umgebung stattfindet. Voraussetzung ist eine bewusste Aufteilung. Ohne sie wird entweder der strengste Fall zum Maßstab für alles, was jede Nutzung blockiert, oder, häufiger, der lockerste.

Wie sich diese Fragen jenseits von KI für die gesamte Plattform beantworten lassen, steht im Artikel zur DSGVO-konformen Cloud.

Kostenloses Whitepaper · 8 Seiten

KI Engine

Von Andreas Hankel, CTO onehundred. Download gegen E-Mail-Adresse, ohne Vertriebsanruf.

Whitepaper laden

EU AI Act: Risikoklassen, Nachweispflichten und die verschobenen Fristen

Der EU AI Act ordnet KI-Systeme nach ihrem Risiko ein. Für die Infrastruktur ist vor allem eine dieser Risikoklassen interessant: Für Hochrisiko-Systeme fordert die Verordnung eine Konformitätsbewertung und eine Nachweisführung. Beides betrifft die Architektur direkt, denn wer nicht weiß und nicht protokolliert, wo seine Inferenz stattfindet, kann nichts davon belegen.

Bei den Fristen hat sich etwas bewegt. Nach der Einigung des Digital-Omnibus-Pakets im Juni 2026 gelten die Hochrisiko-Pflichten für eigenständige KI-Systeme ab dem 2. Dezember 2027, für in Produkte eingebettete Systeme ab August 2028. Wer seine Planung noch am ursprünglich vorgesehenen Termin August 2026 ausrichtet, arbeitet mit einem falschen Zeitbild und hat mehr Spielraum, als er annimmt.

Zwei Abgrenzungen sind uns wichtig, weil sie regelmäßig vermischt werden. Erstens: Ob Ihr konkretes System als Hochrisiko-System gilt, welche Rolle Sie in der Verordnung einnehmen und welche Schulungspflichten sich daraus ergeben, ist eine rechtliche Bewertung. Wir nehmen sie nicht vor, und Aussagen zur nationalen Umsetzung in Deutschland gehören ebenfalls in die rechtliche Beratung. Zweitens: Technische Nachweisfähigkeit lässt sich unabhängig davon herstellen, und sie ist die Voraussetzung dafür, dass eine rechtliche Bewertung überhaupt etwas zu bewerten hat.

Technische Nachweisfähigkeit heißt konkret: Es ist dokumentiert, welches Modell in welcher Version auf welcher Infrastruktur an welchem Ort antwortet. Es ist protokolliert, welche Systeme Anfragen stellen durften. Es ist nachvollziehbar, wann sich daran etwas geändert hat. Das ist in einer selbst betriebenen Inferenz-Umgebung eine Konfigurationsfrage. Bei einer externen API ist es eine Frage danach, was der Anbieter zusichert und was er offenlegt.

Für die Praxis heißt das: KI-Compliance ist zu einem großen Teil Infrastrukturarbeit, die vor der ersten produktiven Anwendung erledigt sein sollte und nicht nach dem ersten Audit.

Make or Buy: eigene GPU-Infrastruktur oder API ist eine Laufzeitrechnung

Die Frage wird meist zu früh mit einem Gefühl und zu spät mit Zahlen beantwortet. Belastbar wird sie über drei Größen.

1. Erwartetes Anfragevolumen. Wie viele Anfragen fallen über die nächsten zwölf Monate an? Nicht im besten Fall, sondern im wahrscheinlichen.
2. Laufzeit der Nutzung. Ist der Anwendungsfall dauerhaft oder eine Kampagne? Eigene Infrastruktur amortisiert sich über Zeit, nicht über einen Höhepunkt.
3. Gleichmäßigkeit der Auslastung. Konstante Last füllt eine eigene GPU aus. Last in Spitzen lässt sie die meiste Zeit leerlaufen und ist genau das Profil, für das eine API gebaut ist.

Dahinter steht eine simple Kostenstruktur: Eigene Inferenz-Infrastruktur hat hohe Grundkosten und niedrige Grenzkosten, externe Modell-APIs haben keine Grundkosten und rechnen pro Anfrage ab. Bei kleinen bis mittleren Volumina schlagen APIs eigene Infrastruktur deshalb häufig weiterhin. Das ist kein Argument gegen eigene KI-Infrastruktur, sondern eines dafür, die Rechnung ehrlich aufzumachen und auch das Ergebnis zuzulassen, dass die API günstiger bleibt.

In die Rechnung gehören außerdem drei Posten, die in Werkzeugvergleichen selten auftauchen: der Betriebsaufwand für die eigene Plattform, die Wartung der Modellversionen und das Risiko der Gegenseite. Preiserhöhungen, geänderte Rate Limits oder neue Nutzungsbedingungen eines API-Anbieters sind kein hypothetisches Szenario, sondern ein Kostenfaktor mit unbekanntem Vorzeichen. Wer LLM-Kosten über drei Jahre vergleicht, sollte auf beiden Seiten mit Bandbreiten arbeiten.

Und es gibt Fälle, in denen die Rechnung gar nicht entscheidet. Wenn ein Anwendungsfall Personenbezug, Geschäftsgeheimnisse oder regulierte Inhalte verarbeitet, die die eigene Umgebung nicht verlassen dürfen, überstimmt die Souveränitätsanforderung die Kostenrechnung. Dann lautet die Frage nicht mehr, ob eigene Inferenz billiger ist, sondern wie klein sie ausfallen kann.

LLM selbst hosten: Modell, Laufzeitumgebung, Sizing

Ein LLM selbst zu hosten ist technisch unspektakulärer, als es klingt, und betrieblich anspruchsvoller. Drei Entscheidungen fallen der Reihe nach.

Das Modell. Offene Modelle, etwa aus der Llama- oder der Mistral-Familie, lassen sich selbst betreiben und in der Version festhalten. Die Modellwahl ist dabei die am leichtesten revidierbare Entscheidung im ganzen Vorhaben, solange die Hosting-Schicht austauschbar gebaut ist. Für viele Aufgaben, etwa Klassifikation, Extraktion oder Zusammenfassung interner Dokumente, reicht ein kleineres Modell, das auf deutlich weniger Hardware antwortet.

Die Inferenz-Laufzeitumgebung. Sie lädt die Modellgewichte, hält sie im Speicher der Beschleunigerhardware und beantwortet Anfragen. Ihre Kennzahlen sind Latenz je Anfrage, parallel bedienbare Anfragen und Auslastung der Hardware. Über diese drei Zahlen wird später auch der Betrieb gesteuert.

Das Sizing. Es ergibt sich aus Modellgröße, erwarteter Last und Latenzanforderung, nicht aus einem Hardware-Datenblatt. Die belastbare Reihenfolge lautet: Anwendungsfall und Antwortzeiten festlegen, Modellgröße daraus ableiten, Speicherbedarf der Gewichte bestimmen, Parallelität einrechnen, erst dann Hardware auswählen. Wer umgekehrt anfängt und GPU-Server bestellt, bevor die Last bekannt ist, kauft entweder zu viel oder das Falsche.

Unterschätzt wird meist nicht die erste Inbetriebnahme, sondern alles danach: mehrere Modellversionen parallel, ein Wechsel ohne Ausfall, saubere Trennung mehrerer Anwendungen auf derselben Hardware und ein Wiederanlauf, der auch nachts funktioniert. Wie das als Angebot aussieht, steht auf der Seite zur KI-Infrastruktur.

Warum KI-Vorhaben am Betrieb scheitern

Die Zahlen sind unangenehm eindeutig. S&P Global berichtet in der Umfrage „2025 Voice of the Enterprise" eine Abbruchquote von 42 Prozent bei KI-Initiativen. IDC nennt gemeinsam mit Lenovo 88 Prozent nicht ausgerollte Proof-of-Concepts. Die RAND Corporation kommt auf über 80 Prozent gescheiterte KI-Projekte. Je nach Studie und Definition erreichen also zwischen 42 Prozent und über 80 Prozent der Initiativen den produktiven Betrieb nicht. Als Ursachen werden überwiegend die GPU-Kapazitätsplanung, die Datenpipelines und ein fehlendes Betriebsmodell genannt, nicht die Qualität der Modelle.

Das Muster dahinter ist immer dasselbe. Ein Pilot läuft auf einer Maschine mit einem Datenexport und beweist, dass der Anwendungsfall funktioniert. Der Regelbetrieb braucht aber Orchestrierung, Mandantentrennung, Monitoring und Wiederanlauf. Dieser Übergang wird selten als eigenes Projekt mit eigenem Budget geplant, und die Verantwortung endet oft mit dem Pilotprojekt.

Ein tragfähiges Betriebsmodell für KI-Workloads beantwortet vier Fragen:

• Wer wird gerufen? Rufbereitschaft, Eskalationsweg und definierte Verfügbarkeit, wie bei jedem anderen produktiven Dienst auch.
• Was wird gemessen? Neben Latenz und Auslastung auch die Kosten je Anfrage und die Qualität der Antworten, inklusive Drift, also dem langsamen Abweichen der Ergebnisse vom erwarteten Verhalten.
• Wie werden Modelle aktualisiert? Geplantes Update-Management mit Testlauf und Rückfallweg statt stiller Versionswechsel.
• Wie wird skaliert? Kapazitätssteuerung nach Last, mit einer Grenze, an der jemand entscheidet, statt einer Rechnung, die im Monatsabschluss auffällt.

Das ist der Kern dessen, was als MLOps beschrieben wird: nicht ein Werkzeug, sondern Zuständigkeit, Messung und ein wiederholbarer Weg von der neuen Modellversion in den Betrieb.

Anfangen sollten Sie mit einer Prüfung, nicht mit Hardware

Der belastbare Einstieg ist ein technisches Readiness-Assessment. Es beantwortet drei Fragen und ist bewusst eine reine Plattformfrage, keine Bewertung Ihrer Anwendungsfälle.

1. Dateninfrastruktur. Liegen die Daten, die der Anwendungsfall braucht, in einer Form vor, die eine produktive Anwendung nutzen kann, oder existiert bisher nur ein Export aus dem Pilotprojekt?
2. Rechenkapazität. Welche Kapazität ist vorhanden, welche wird gebraucht, und wird GPU-Kapazität bei Ihnen geplant oder fallweise beschafft?
3. Souveränität. Welche Anfragen dürfen die eigene Umgebung nicht verlassen, und woraus ergibt sich das: aus Verträgen, aus Regulierung oder aus Zusagen an Ihre Kunden?

Aus den Antworten folgt die Make-or-Buy-Rechnung und daraus das Zielbild: eigenes Rechenzentrum, europäisches souveränes Rechenzentrum, hybrides Modell oder vorerst weiter über die API. Erst danach werden Hardware und Plattform ausgewählt.

Zwei Hinweise aus der Praxis. Erstens ist die Frage nach dem Ort der Inferenz leichter zu beantworten, bevor Datenflüsse, Werkzeuge und Erwartungen gesetzt sind. Wird sie erst nach dem Pilotprojekt gestellt, wird Souveränität zur nachträglichen Korrektur, und die ist teurer als die Planung. Zweitens ist ein Anwendungsfall, bei dem ein Kunde die Frage „Wo laufen unsere Daten?" bereits gestellt hat, kein Warnsignal, sondern der Normalfall von morgen.

Wer diesen Weg gehen will, ohne die eigene Infrastruktur dafür aufzubauen, findet in einer Private Cloud die Umgebung, in der eine Inferenz-Plattform anschließend läuft. Und wer zuerst die Souveränitätsfrage für die gesamte IT klären will, beginnt besser bei der digitalen Souveränität.