Die Kluft, die niemand gern betritt
Es gibt einen Satz, der in der KI-Welt viel zu leichtfertig fällt: „Läuft bei mir." Eine Demo funktioniert, ein Prototyp beeindruckt, ein Video macht die Runde. Und dann wird so getan, als sei der Rest nur noch Fleißarbeit.
Der Rest ist nicht Fleißarbeit. Zwischen „läuft bei mir" und „ein Unternehmen vertraut ihm seine vertraulichsten Daten an" liegt eine Kluft, die viele Projekte unterschätzen — und in die ich im April 2026 bewusst hineingegangen bin, bevor ZenAI ernsthaft an reale Organisationen gehen durfte.
Das ist die unglamouröseste Phase unserer ganzen Entwicklungsgeschichte. Sie taucht in keinem Demo-Video auf. Und sie ist vielleicht die wichtigste. Dieser Beitrag ist das Kapitel, das ich in der Geschichte unseres Labors angekündigt habe: der Härtetest.
Warum Sicherheit bei uns kein Feature ist
Ich glaube, der teuerste Denkfehler bei der Unternehmens-KI ist, Sicherheit und Datenschutz als nachgelagerte Schicht zu behandeln — als etwas, das man am Ende „noch drüberlegt". Compliance war für uns nie ein Anstrich. Sie war ein Tor, durch das das Produkt erst durchmusste.
Der Grund ist einfach: Die eigentliche Knappheit im KI-Markt ist nicht Rechenleistung und nicht Talent. Es ist Vertrauen. Ein System, das die Wissensarbeit eines Unternehmens trägt, sieht alles — Verträge, Finanzen, Personal, Strategie. Wer so etwas einführt, kauft nicht ein Feature. Er geht ein Vertrauensverhältnis ein. Und Vertrauen entsteht nicht durch ein Sicherheits-Siegel im Footer, sondern durch Architektur, die man prüfen kann.
Deshalb fuhr ich vor dem ersten ernsthaften Einsatz eine zusammenhängende Serie von zehn Härtungs-Sprints, Rücken an Rücken. Nicht als Reaktion auf einen Vorfall, sondern als Voraussetzung.
Die zehn Sprints
Jeder Sprint schloss eine konkrete Klasse von Risiken. Im Überblick:
1. Verschlüsselung und Schlüsselrotation. Sensible Felder werden auf Feldebene verschlüsselt, mit einem dokumentierten Verfahren zur Schlüsselrotation. Verschlüsselung, die man nie rotieren kann, ist nur die halbe Miete.
2. Mandantentrennung auf Datenebene. Strikte Zugriffstrennung pro Kontext, direkt in der Datenbank verankert (Row-Level Security), nicht nur in der Anwendungslogik. Daten des einen Mandanten dürfen die des anderen unter keinen Umständen sehen — und das soll die Datenbank selbst garantieren, nicht nur der gut gemeinte Code darüber.
3. Netzwerk-Härtung. Schutz gegen serverseitige Anfragefälschung (SSRF) und DNS-Rebinding — die Klasse von Angriffen, mit der ein System dazu gebracht wird, gegen interne Adressen zu telefonieren.
4. KI-spezifische Leitplanken. Schutz gegen Prompt-Injection und Leitplanken für Ausgaben, dazu eine dreistufige Inhaltsmoderation. Ein System mit Werkzeugen und Gedächtnis braucht Grenzen, die ein reiner Chatbot nicht braucht.
5. Betroffenenrechte, eingebaut. Ein Einwilligungszentrum mit Auskunft (DSAR) und vollständiger Kontolöschung. Datenschutzrechte sind keine E-Mail an den Support, sondern eine Funktion.
6. Transparenzpflichten. Kennzeichnung KI-erzeugter Ausgaben nach Artikel 50 des EU AI Act, sobald sie an Menschen gehen — und Kürzung von IP-Adressen nach DSGVO-Maßstab. Die Kennzeichnung ist nicht nachgelagert, sondern Teil der Ausgabe-Pipeline.
7. Integrität der Zahlungswege. Absicherung der Zahlungs-Webhooks gegen Doppelverarbeitung und Replay-Angriffe.
8. Nachvollziehbarkeit. Ein Audit-Trail und eine Weiterleitung sicherheitsrelevanter Ereignisse an die Systeme des Kunden (SIEM), pro Organisation getrennt. Wer Vertrauen will, muss prüfbar sein.
9. Der Angriff auf uns selbst. Ein eigener Penetrationstest-Durchlauf — das System bewusst aus der Angreiferperspektive unter Druck setzen, statt zu hoffen.
10. Berechtigungen im Token. Der Leistungsumfang eines Nutzers wird kryptografisch im Sitzungs-Token getragen, statt bei jeder Anfrage nachgeschlagen zu werden — weniger Angriffsfläche, klarere Grenzen.
Hinter dieser Liste stehen rund dreihundert zusätzliche automatisierte Tests. Sicherheit, die man nicht kontinuierlich nachprüft, verfällt mit dem nächsten Commit.
Was das kostet — und warum es sich lohnt
Diese Wochen haben kein einziges sichtbares Feature hervorgebracht. Kein Nutzer hat danach einen neuen Knopf gesehen. Aus Produktsicht ist das teure, unsichtbare Arbeit.
Und trotzdem würde ich sie jederzeit wieder so machen. Denn am Ende stand eine Querschnittsprüfung über alle Sprints — und sie fand tatsächlich noch eine Lücke (eine fehlende Zugriffsregel auf einer einzelnen Tabelle), die sofort geschlossen wurde. Genau das ist der Punkt: Nicht das Ziel ist „null Fehler", sondern ein Prozess, der Fehler findet und schließt, bevor jemand anderes sie findet. Ein ehrliches Sicherheitsversprechen lautet nicht „uns kann nichts passieren". Es lautet „wir suchen systematisch, und wir reparieren, was wir finden".
Dazu kommt die architektonische Grundentscheidung, die all das erst sinnvoll macht: Datensouveränität. ZenAI lässt sich vollständig auf eigener Infrastruktur betreiben, ohne dass Daten abfließen — auf Wunsch komplett lokal. DSGVO und EU AI Act sind in diesem Bild keine Last, die man trägt, sondern eine Form, in der man baut.
Vertrauen ist die eigentliche Knappheit
Ich habe lange in Organisationen gearbeitet und gesehen, wie KI-Initiativen scheitern. Selten an der Technik. Oft an einem leisen, berechtigten Misstrauen: „Wo landen unsere Daten eigentlich?"
Diese Frage verdient eine bessere Antwort als eine Broschüre. Sie verdient eine Architektur, die man aufmachen und prüfen kann. Der Härtetest war unser Weg, diese Antwort zu geben, bevor uns jemand danach fragen musste. Es war die Phase, in der aus einem beeindruckenden Prototyp ein System wurde, dem man etwas anvertrauen kann.
Dies ist ein Kapitel unserer Entwicklungsgeschichte. Im nächsten Beitrag der Reihe geht es um unseren grundsätzlichen Umgang mit KI — wo wir dem Menschen das letzte Wort lassen und warum. Wie wir KI überhaupt in einem Betrieb einführen, steht im Beitrag vom ersten Prozess zum Betriebssystem.