Kann man KI vertrauen?

Warum das Vertrauen in KI so fragil ist

GenAI wurde in bemerkenswertem Tempo von allen angenommen – von Schülern über Anwälte bis hin zu Vertriebsmitarbeitern –, die alle damit ihre Arbeit effizienter gestalteten. Doch die Erkenntnisse ließen nicht lange auf sich warten: Neben den Effizienzgewinnen stellte sich rasch ein allgemeines Gefühl der Unsicherheit und ein Mangel an Vertrauen ein.

Die Gründe dafür liegen auf der Hand. Dasselbe Tool, das einen Vertrag in Sekundenschnelle entwirft, sendet diesen Vertrag auch an einen Server, der Ihnen nicht gehört, in einem Land, dessen Gesetze Sie nicht gewählt haben. Das Modell, das Patientennotizen zusammenfasst, behält diese möglicherweise im Speicher. Der Assistent, der einem Kunden antwortet, wird vielleicht unbemerkt mit diesem Gespräch trainiert. Nichts davon war anfangs offensichtlich, da das Ergebnis in beiden Fällen gleich aussah: flüssig, schnell, überzeugend. Das Risiko lag nie nur in dem, was die KI sagte. Es lag darin, wohin die Daten gingen, wer sie sehen konnte und ob im Nachhinein überhaupt jemand rekonstruieren konnte, was geschehen war.

Das ist es, was das Vertrauen in die KI so fragil macht. Es ist nicht so, dass die Technologie lautstark versagt, sondern dass sie hervorragend funktioniert, während sie im Hintergrund unbemerkt Dinge tut, die Sie nicht sehen können. Ein System, das Sie nicht überprüfen können, verlangt von Ihnen, auf seine Sicherheit zu vertrauen – und Vertrauen übersteht weder das Audit einer Regulierungsbehörde, noch den Due-Diligence-Fragebogen eines Kunden oder eine Datenschutzverletzungsmeldung. „Wir nehmen an, es ist in Ordnung“ ist keine Position, die regulierte Unternehmen verteidigen können.

Die Frage ist also nicht, ob KI nützlich ist. Das ist bereits geklärt. Die Frage ist, ob man ihr dort vertrauen kann, wo Vertrauen keine Option, sondern Pflicht ist. Und um das zu beantworten, muss man sich ansehen, was tatsächlich schiefgehen kann.

Die realen Bedrohungen

Datensicherheit

Datenpannen und geleakte Informationen machen fast wöchentlich Schlagzeilen, und dennoch füttern wir Tools weiterhin mit sensiblen Daten, ohne zu wissen, wohin sie fließen. Jeder Prompt landet in einer Blackbox. Wenn Sicherheits- und Berechtigungsrichtlinien nicht ernst genommen werden, wird aus Vertrauen ganz schnell ein Sicherheitsrisiko.

Prompt-Injections

Eine Bedrohung, die weit weniger Menschen kennen, ist die Prompt-Injection: bösartige Anweisungen, die in einer Website, einem Dokument oder einer E-Mail versteckt sind, die die KI liest. Das System befolgt diese heimlich an Ihrer Stelle, ändert sein Verhalten oder gibt Informationen preis, die niemals nach außen dringen sollten.

Bildrechte

Einige KI-Tools verwenden Bilder ohne die Zustimmung der ursprünglichen Urheber, sowohl für das Training von Modellen als auch für die Generierung neuer Inhalte. Die am besten sichtbaren Fälle betreffen gefälschte Bilder von Personen des öffentlichen Lebens, aber dieselben Techniken funktionieren bei jedem: einem Mitarbeiter, einer Führungskraft, Ihnen selbst. Und für Unternehmen besteht das Risiko in beide Richtungen: Die von Ihrer KI generierten Inhalte verletzen möglicherweise die geschützten Werke anderer, und die Haftung dafür ist selten klar geregelt.

Kosten

Es fängt immer günstig an: eine kostenlose Basisversion, ein niedriger Preis pro Token, eine Demo, die fast nichts kostet. Dann wächst die Nutzung. Abonnements werden gekauft, aktualisiert, gestapelt, und eine Preisgestaltung pro Anfrage, die beim Pilotprojekt noch harmlos aussah, skaliert mit jedem weiteren Benutzer. Das Tool ist nicht teurer geworden, Sie haben nur angefangen, es tatsächlich zu nutzen. Und eine nutzungsabhängige Preisgestaltung ist genau auf diesen Moment ausgelegt.

Wie man vertrauenswürdige KI aufbaut

Jede der oben genannten Bedrohungen hat dieselbe Ursache: Die KI läuft an einem Ort, den Sie nicht kontrollieren, auf einem Modell, das Sie nicht überprüfen können, und auf eine Weise, die Sie im Nachhinein nicht nachweisen können. Vertrauenswürdige KI ist kein Feature, das man einfach einschaltet. Es ist eine Reihe von Architekturentscheidungen, die getroffen werden müssen, noch bevor der erste Prompt gesendet wird. Fünf davon sind am wichtigsten.

Nutzung eigener oder kontrollierter Infrastruktur

Der effektivste Weg, eine Datenpanne zu verhindern, besteht darin, sicherzustellen, dass die Daten das Haus nie verlassen. Wenn die Auswertung (Inferenz) auf Hardware läuft, die Sie besitzen oder kontrollieren, gibt es keine API von Drittanbietern, die Ihre Prompts protokolliert, keinen externen Cache, der Ihre Eingaben speichert, und keinen unbemerkten Datenabfluss in die Trainingspipeline eines Anbieters. Die Frage „Wo landen unsere Daten eigentlich?“ ist dann keine Frage des Vertrauens mehr, sondern der Netzwerktopologie – etwas, das Ihr eigenes Team überprüfen kann.

Nutzung von Open-Source-, überprüfbaren Modellen

Ein geschlossenes Modell ist eine doppelte Blackbox: Sie können weder sehen, wie es trainiert wurde, noch, was es zur Laufzeit mit Ihren Daten macht. Open-Source-Modelle beseitigen die zweite Unbekannte vollständig. Sie können die Gewichte auslesen, das Modell isoliert ausführen, es durch ein anderes ersetzen und selbst überprüfen, dass keine Daten nach Hause gesendet werden. Überprüfbarkeit ist hier kein ideologisches Anliegen, sondern das, was es einem Sicherheits- oder Compliance-Team ermöglicht, Freigaben auf der Grundlage von Beweisen statt bloßer Zusicherungen zu erteilen. Zudem löst dies die Hälfte des Bildrechte-Problems: Wenn Sie das Modell selbst wählen, können Sie sich für eines mit dokumentierten Trainingsdaten und einer Lizenz entscheiden, die Ihre Nutzung erlaubt, anstatt das zu übernehmen, was ein Anbieter ungefragt aus dem Internet geladen hat.

Berechnung auf eigener Hardware belassen

Datenpannen, Prompt-Injections und unbemerkter Datenabfluss setzen alle dasselbe voraus: dass Ihre Auswertung irgendwo läuft, wo sie von außen erreichbar ist. Wenn Sie diese Annahme verwerfen, verschwindet der Großteil der Angriffsfläche. Wenn das Modell auf eigener Hardware innerhalb des eigenen Netzwerks läuft, gibt es keinen externen Endpunkt, der gehackt werden kann, keine Mandantenfähigkeit, aus der man ausbrechen könnte, und von vornherein keinen Weg nach draußen zu einem Dritten. Der Supercomputer steht in Ihrem Serverraum, nicht in einem Rechenzentrum, das Sie nie sehen werden. Eine Prompt-Injection, die versucht, Daten abzuschöpfen, hat kein Ziel, an das sie diese senden könnte, da es keinen Ausgangspfad gibt, den sie missbrauchen könnte. Das meinen wir mit „Souveränität durch Architektur, nicht durch Vertrag“ – in der Praxis bedeutet das, dass Ihre Daten nicht deshalb bleiben, weil ein Anbieter es versprochen hat, sondern weil es physisch keinen anderen Ort gibt, an den sie abfließen könnten.

Machen Sie Kosten zu einer Größe, die Sie kontrollieren, nicht zu einem Zähler, den Sie überwachen

Die vierte Bedrohung, die Kostenexplosion, wird oft unterschätzt, weil die Token-Preise in der Demophase günstig aussehen. Sie wirken nicht mehr billig, sobald die Nutzung im echten Betrieb ankommt. Gemietete KI ist für unregelmäßige Arbeitslasten bei einer Auslastung von etwa 15 Prozent kalkuliert. Aber eine KI-Funktion, die tatsächlich genutzt wird – insbesondere dauerhaft aktive Agenten –, läuft eher bei 80–90 % Auslastung, und auf diesem Niveau läuft der Zähler ununterbrochen. Wir nennen dies die Auslastungsumkehr (Utilization Inversion): Unterhalb einer bestimmten Nutzungsschwelle ist die Cloud günstiger, oberhalb dieser Schwelle gewinnt der Betrieb eigener Systeme. Bei hoher Auslastung spart der eigene Betrieb rund 80 Prozent im Vergleich zur entsprechenden Cloud-Kapazität. Die eigene Hardware verwandelt eine unvorhersehbare, variable Rechnung in fixe Kosten, die Sie bereits bezahlt haben. Es gibt keine überraschenden Rechnungen nach einem arbeitsreichen Quartal und keinen Grund, die Nutzung künstlich einzuschränken, um das Budget zu schonen.

Alles protokollieren, um es beweisen, nicht nur behaupten zu können

Die drei oben genannten Entscheidungen schließen die Sicherheitslücken. Diese letzte Entscheidung ermöglicht es Ihnen, einem Auditor, einer Regulierungsbehörde oder Ihrem eigenen Vorstand nachzuweisen, dass sie geschlossen sind. Vertrauen, das man nicht nachweisen kann, ist nur eine weitere Form von gutem Glauben. Auf der von Ihnen kontrollierten Infrastruktur können Sie jede Anfrage protokollieren, jedes Token verfolgen, genau sehen, welches Modell welchen Prompt verarbeitet hat, und diese Aufzeichnungen bei Bedarf vorlegen. Souveränität wird so zu einer Eigenschaft, die Sie in einem Netzwerkdiagramm und einem Audit-Trail aufzeigen können, statt zu einer Vertragsklausel, auf deren Gültigkeit Sie hoffen müssen. Für ein Unternehmen mit sensiblen Daten ist das Wissen „Wir können es beweisen“ der Unterschied zwischen einem Pilotprojekt und dem produktiven Einsatz.

Dieselbe Protokollierung ist Ihre Antwort auf die andere Hälfte der Bildrechte-Frage. Keine Architektur kann verhindern, dass ein Modell etwas generiert, das einem geschützten Werk zu ähnlich ist – das kann keine Infrastruktur. Aber ein vollständiges Protokoll darüber, welches Modell welche Ausgabe aus welchem Prompt erzeugt hat, ermöglicht es Ihnen, einer Beschwerde nachzugehen, den Inhalt zu entfernen und zu zeigen, dass Sie verantwortungsvoll gehandelt haben. Schadensersatzklauseln von Anbietern greifen erst, wenn der Schaden bereits entstanden ist. Durch Nachvollziehbarkeit können Sie ihn abfangen, bevor das Produkt veröffentlicht wird.

Die Checkliste für Anbieter

Bevor Sie einen Vertrag mit einem KI-Anbieter unterzeichnen, sollten Sie diese sieben Fragen stellen. Die Antworten trennen Architektur von bloßen Versprechungen.

1. Wohin fließen unsere Daten physisch, wenn wir einen Prompt senden, und können Sie uns das in einem Netzwerkdiagramm zeigen?

2. Können wir dies vollständig innerhalb unserer eigenen Netzwerkgrenzen ausführen, ohne jeden externen Datenabfluss?

3. Können wir die Modellgewichte auslesen und sie isoliert ausführen?

4. Protokollieren Sie jede Anfrage und jedes Token in einem Datensatz, den wir einem Prüfer vorlegen können?

5. Werden unsere Daten jemals für das Training, Caching oder die Speicherung verwendet, auch nur vorübergehend?

6. Wie verhält sich unsere Kostenkurve bei einer Auslastung von 80–90 %, und nicht nur bei Demo-Nutzung?

7. Wer haftet, wenn das Modell urheberrechtlich geschützte Inhalte reproduziert?

Ein Anbieter, der auf den fünf oben genannten Entscheidungen aufbaut, kann alle sieben Fragen mit Beweisen beantworten. Jeder andere wird mit einem Vertrag antworten.

Fazit

Vertrauen in KI ist fragil, weil die meisten Systeme auf blindes Vertrauen setzen. Die Alternative besteht nicht darin, noch stärker zu vertrauen, sondern auf einer Architektur aufzubauen, die Vertrauen überflüssig macht: eine Infrastruktur, die Sie kontrollieren, Modelle, die Sie überprüfen können, Kosten, die Sie selbst bestimmen, und Aufzeichnungen, die dies belegen. Wenn ein Anbieter die sieben Fragen oben mit Beweisen beantworten kann, haben Sie es mit einer solchen Architektur zu tun. Wenn nicht, wissen Sie jetzt, wonach Sie fragen müssen.

Dieser Leitfaden wurde gemeinsam von Tealstack und Xinity verfasst. Wenn einige dieser Fragen in Ihrem Unternehmen noch offen sind, vereinbaren Sie ein Gespräch mit uns.