Kann man KI vertrauen? Wie man überprüfbare KI entwickelt

Warum das Vertrauen in KI fragil ist

GenAI wurde von allen, von Schülern über Anwälte bis hin zu Vertriebsmitarbeitern, in bemerkenswerter Geschwindigkeit angenommen und genutzt, um ihre Arbeit effizienter zu gestalten. Doch die Lehren folgten rasch: Neben den Effizienzgewinnen stellten sich ein allgemeines Gefühl der Unsicherheit und ein Mangel an Vertrauen ein.

Die Gründe dafür liegen auf der Hand. Dasselbe Tool, das in Sekundenschnelle einen Vertrag 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. Der Assistent, der einem Kunden antwortet, wird vielleicht unbemerkt mit dem Gespräch trainiert. Nichts davon war anfangs offensichtlich, da das Ergebnis in jedem Fall gleich aussah: flüssig, schnell, überzeugend. Das Risiko lag nie nur in dem, was die KI sagte. Es lag darin, wohin die Daten flossen, wer sie sehen konnte und ob im Nachhinein jemand rekonstruieren konnte, was geschehen war.

Das ist es, was das Vertrauen in KI so fragil macht. Es liegt nicht daran, dass die Technologie lautstark versagt, sondern daran, dass sie wunderbar funktioniert, während sie im Stillen Dinge tut, die man nicht sehen kann. Ein System, das Sie nicht überprüfen können, verlangt von Ihnen, darauf zu vertrauen, dass es sicher ist – und Vertrauen übersteht weder die Prüfung einer Aufsichtsbehörde, den Due-Diligence-Fragebogen eines Kunden noch eine Benachrichtigung über eine Datenschutzverletzung. „Wir gehen davon aus, dass alles in Ordnung ist“ ist keine Position, die regulierte Unternehmen verteidigen können.

Die Frage ist also nicht, ob KI nützlich ist. Das steht bereits fest. Die Frage ist, ob man ihr dort vertrauen kann, wo Vertrauen nicht optional ist. Und um das zu beantworten, muss man sich ansehen, was tatsächlich schiefgehen kann.

Die realen Bedrohungen

Datensicherheit

Datenpannen und durchgesickerte 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 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 von der KI gelesen wird. Das System befolgt diese heimlich anstelle Ihrer Anweisungen, ä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. 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: ein kostenloser Tarif, ein niedriger Preis pro Token, eine Demo, die fast nichts kostet. Dann steigt die Nutzung. Abonnements werden gekauft, aktualisiert, gestapelt, und eine Abrechnung pro Anfrage, die bei einem 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 verbrauchsbasierte Preise sind genau für diesen Moment konzipiert.

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 beweisen können. Vertrauenswürdige KI ist kein Feature, das man einfach einschaltet. Es ist eine Reihe von Architekturentscheidungen, die getroffen werden müssen, bevor der erste Prompt überhaupt gesendet wird. Fünf davon sind am wichtigsten.

Auf eigener oder kontrollierter Infrastruktur betreiben

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

Open-Source-Modelle verwenden, die überprüfbar sind

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 telefoniert werden. Überprüfbarkeit ist hier keine ideologische Vorliebe, sondern das, was es einem Sicherheits- oder Compliance-Team ermöglicht, eine Freigabe mit Beweisen statt mit bloßen Zusicherungen zu erteilen. Es löst auch die Hälfte des Problems mit den Bildrechten: Wenn Sie das Modell selbst wählen, können Sie eines mit dokumentierten Trainingsdaten und einer Lizenz wählen, die Ihre Nutzung erlaubt, anstatt das zu übernehmen, was ein Anbieter willkürlich zusammengestellt hat.

Rechenleistung auf eigener Hardware behalten

Datenpannen, Prompt-Injections und stiller Datenabfluss setzen alle dasselbe voraus: dass Ihre Inferenz irgendwo läuft, wo sie von außen erreichbar ist. Fällt diese Annahme weg, verschwindet auch der Großteil der Angriffsfläche. Wenn das Modell auf Ihrer eigenen Hardware innerhalb Ihres eigenen Netzwerks läuft, gibt es keinen externen Endpunkt, der gehackt werden kann, keine gemeinsam genutzte Umgebung (Multi-Tenancy), 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 zu Gesicht bekommen. Eine Prompt-Injection, die versucht, Daten abzuziehen, hat keinen Ort, an den sie diese senden könnte, weil es keinen Ausgangspfad gibt, den sie missbrauchen könnte. Das meinen wir mit „souverän durch Architektur“, nicht durch Verträge. Das bedeutet in der Praxis, dass Ihre Daten nicht deshalb im Haus bleiben, weil ein Anbieter es versprochen hat, sondern weil es physisch keinen anderen Ort gibt, an den sie fließen könnten.

Kosten zu einer kontrollierbaren Eigenschaft machen, statt einen Zähler zu überwachen

Die vierte Bedrohung, die Kostenexplosion, wird meist unterschätzt, weil die Preise pro Token in der Demophase günstig aussehen. Das ändert sich in dem Moment, in dem die Nutzung real wird. Angemietete KI ist für unregelmäßige Arbeitslasten bei einer Auslastung von etwa 15 Prozent kalkuliert. Aber eine KI-Funktion, die von Menschen tatsächlich genutzt wird, insbesondere ständig aktive Agenten, läuft eher bei einer Auslastung von 80–90 Prozent – und auf diesem Niveau steht der Zähler niemals still. Wir nennen dies die Auslastungsinversion: Unterhalb einer bestimmten Nutzungsschwelle ist die Cloud günstiger, darüber gewinnt die eigene Inferenz-Infrastruktur. Bei hoher Auslastung spart man etwa 80 Prozent im Vergleich zur entsprechenden Cloud-Kapazität. Der Besitz der Hardware verwandelt eine variable, unvorhersehbare Rechnung in fixe Kosten, die Sie bereits bezahlt haben. Es gibt keine bösen Überraschungen auf der Rechnung nach einem arbeitsreichen Quartal und keinen Grund, die Nutzung zu rationieren, um das Budget einzuhalten.

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

Die drei oben genannten Entscheidungen schließen die Lücken. Diese letzte Entscheidung ermöglicht es Ihnen, einem Auditor, einer Aufsichtsbehörde oder Ihrem eigenen Vorstand zu beweisen, dass sie geschlossen sind. Vertrauen, das nicht nachgewiesen werden kann, ist nur eine andere Form der bloßen Zusicherung. 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 zu einer Eigenschaft, auf die Sie in einem Netzwerkdiagramm und einem Audit-Trail verweisen können, nicht zu einer Vertragsklausel, von der Sie hoffen, dass sie rechtlich standhält. Für ein Unternehmen mit sensiblen Daten ist „Wir können es beweisen“ der Unterschied zwischen einem Pilotprojekt und dem produktiven Einsatz.

Dasselbe Protokoll ist Ihre Antwort auf die andere Hälfte der Frage der Bildrechte. 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, eine Reklamation zu untersuchen, den Inhalt zu entfernen und zu zeigen, dass Sie verantwortungsvoll gehandelt haben. Eine Haftungsfreistellung durch den Anbieter greift erst, wenn der Schaden bereits entstanden ist. Durch Nachweisbarkeit können Sie ihn abfangen, bevor er veröffentlicht wird.

Die Checkliste für Anbieter

Bevor Sie einen Vertrag mit einem KI-Anbieter unterzeichnen, stellen Sie diese sieben Fragen. 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 unseres eigenen Netzwerks ohne externen Datenabfluss betreiben?

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

4. Protokollieren Sie jede Anfrage und jedes Token in einem Protokoll, das wir einem Auditor übergeben können?

5. Werden unsere Daten jemals für das Training, das 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 beim Demovolumen?

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

Ein Anbieter, dessen Lösung auf den fünf oben genannten Entscheidungen basiert, kann alle sieben Fragen mit Beweisen beantworten. Jeder andere wird mit einem Vertrag antworten.

Fazit

Das Vertrauen in KI ist fragil, weil die meisten Systeme dieses Vertrauen auf bloßen Glauben hin einfordern. Die Alternative besteht nicht darin, noch stärker zu vertrauen, sondern auf einer Architektur aufzubauen, bei der Glaube überflüssig ist: eine Infrastruktur, die Sie kontrollieren, Modelle, die Sie überprüfen können, Kosten, die Sie selbst bestimmen, und Protokolle, die dies belegen. Wenn ein Anbieter die sieben obigen Fragen 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.