Künstliche Intelligenz mit klarer Kontrolle über Ihre Daten

Bevor ein Unternehmen einem KI-Projekt zustimmt, steht fast immer dieselbe Frage im Raum. Nicht: „Was kann das Modell?", sondern: „Wo landen unsere Daten?" Das ist die richtige Frage, und sie verdient eine klare, projektspezifische Antwort: Welche Daten fließen wohin, zu welchem Anbieter, unter welchen Verträgen und mit welchen Kontrollen?

Dieser Text erklärt, wie wir diese Entscheidungen bei einem neuen System früh treffen und wie wir sie in bereits laufenden Systemen gezielt stärken. Gut zu beginnen ist wichtig. Ebenso wichtig ist es, Bestehendes verantwortungsvoll weiterzuentwickeln.

Die falsche Wahl

Leistungsfähigkeit oder Kontrolle - angeblich

KI-Architektur wird oft auf die Wahl eines Anbieters reduziert. Tatsächlich kann ein Modell lokal, in einer europäischen Region oder auf einer freigegebenen globalen Plattform laufen. Jeder Weg hat eigene Stärken bei Leistungsfähigkeit, Latenz, Verfügbarkeit, Kosten und Governance.

Modellleistung und Daten-Governance sind zwei Entscheidungen, die wir gemeinsam mit Ihnen treffen. Richtig ist der Weg, der zur Datenklasse, zum Geschäftsziel, zu Ihren bestehenden Standards und zu den Menschen passt, die das System später betreiben.

Das Fundament

Sicher ab Zeile eins

Neue Anwendungen können auf einem erprobten Sicherheitsfundament starten, das wir an Risikoprofil, Regulierung und bestehende Architektur anpassen. Bestehende Systeme stärken wir in priorisierten, testbaren Schritten. Je nach Projekt kann dieses Fundament enthalten:

• Mandantentrennung per Row-Level Security - die Datenbank setzt Mandantenregeln als zusätzliche Grenze unterhalb der Anwendung durch. Getestete Datenbankregeln schützen auch dann, wenn Anwendungscode einen Fehler macht.
• Zweckgerechte, nachvollziehbare Audit-Protokolle - relevante Änderungen halten fest, wer was wann geändert hat, in einer Tiefe, die zu Risiko und Compliance-Anforderungen des Projekts passt.
• Mehrfaktor-Authentifizierung, sichere Sitzungen und Rate Limiting - starke Passwort-Hashes, bewusst gewählte Token-Verfahren und Schutz vor wiederholten Anmeldeversuchen an sensiblen Zugangspunkten.
• Bewusst gewählte Browser-Integrationen - wo es Mehrwert schafft, hosten wir Assets selbst. Externe Dienste werden gezielt ausgewählt, dokumentiert und datenschutzgerecht konfiguriert.

Die Mandantentrennung ist dabei mehr als ein Haken auf einer Liste, deshalb hier als Bild. Entscheidend ist eine Grenze auf mehreren Ebenen: Prüfungen in der Anwendung bleiben wichtig; Row-Level Security ergänzt sie um eine Datenbankregel, die ein vergessener Filter nicht einfach aufhebt.

Und weil eine Liste von Schutzmaßnahmen nur so viel wert ist wie ihre Prüfung, testen wir aktiv auf Schwachstellen wie Timing-Angriffe bei der Anmeldung, SQL-Injection, mandantenübergreifende Lecks und unsichere Datei-Uploads. Behobene Fehler werden zu Regressionstests, damit sie bei einer erneuten Einführung möglichst früh auffallen. Das lässt Risiken nicht verschwinden, macht den Schutz aber wiederholbar und sichtbar.

Schutzmaßnahmen nachzurüsten ist meist aufwendiger und weniger planbar, als Sicherheit früh in den Entwurf einzubeziehen.

Die KI

Wo das Modell rechnet und wo nicht

Damit zurück zur Eingangsfrage. Für Entwicklung und besonders sensible Aufgaben können Modelle lokal oder in isolierten Umgebungen laufen. Im Produktivbetrieb wählen wir Anbieter, Region und Betriebsmodell anhand von Datenklasse, Ergebnisqualität, Verfügbarkeit, Budget und bestehenden Kundenvorgaben. Entscheidend sind dokumentierte Datenflüsse, passende Verträge sowie klare Aufbewahrungs-, Trainings- und Zugriffskontrollen. Vertrauliche Produktionsdaten gehören nicht in ungeprüfte Consumer-Dienste.

Das kann ein europäischer Anbieter sein, die EU-Region eines globalen Cloud-Dienstes wie Google Cloud oder eine bewusst integrierte Plattform wie Cloudflare - jeweils mit den Kontrollen, die der Anwendungsfall verlangt.

Dazu kommt eine Vorsichtsmaßnahme, die im Alltag leicht vergessen wird: Nutzungsgrenzen, Budgets und Warnungen pro Mandant, so nah am Anfragepfad durchgesetzt, wie die Plattform es zulässt. Eine KI-Rechnung, die über Nacht aus dem Ruder läuft, ist auch ein Betriebs- und Sicherheitsrisiko - wir behandeln sie als solches.

Der blinde Fleck

Der Prompt ist auch eine Eingabe

Eine Sache, die in vielen KI-Projekten übersehen wird: Alles, was in ein Modell hineingeht, ist eine Eingabe - und von außen beeinflussbare Eingaben behandeln wir als nicht vertrauenswürdig. Wer einen manipulierten Text in einem Datenbankeintrag platziert, kann versuchen, das Modell damit zu unerwünschtem Verhalten zu bewegen (Prompt-Injection). Wir trennen Anweisungen von Daten, begrenzen Werkzeuge und Berechtigungen und validieren sicherheitsrelevante Ausgaben. Bereinigung kann helfen, ist allein aber keine Sicherheitsgarantie.

Warum früh beginnen

Starkes Fundament, messbare Verbesserungen

Warum so viel Aufwand, bevor die erste sichtbare Funktion steht? Weil Datenschutz und Sicherheit wirtschaftlicher sind, wenn sie die Architektur früh prägen. Doch Brownfield ist nicht hoffnungslos: Ein bestehendes System lässt sich prüfen, Risiken lassen sich priorisieren und Kontrollen in messbaren Schritten verbessern, ohne so zu tun, als müsse alles neu gebaut werden.

Wir beginnen am liebsten früh. Unsere Verantwortung ist es, Ihr Projekt dort abzuholen, wo es heute steht.

Ehrlich bleiben

Was wir versprechen, und was nicht

Ein ehrliches Wort zum Schluss, denn Vertrauen entsteht nicht durch Superlative. Kein Fundament macht ein System für immer sicher, und keine Architektur ersetzt die kontinuierliche Sorgfalt, die Sicherheit erfordert. Wir verkaufen keine Plakette und kein Siegel. Wir bieten eine Disziplin und ein Fundament, auf dem Datenschutz die Voreinstellung ist und nicht der Sonderfall - und die Ehrlichkeit, den Unterschied zu benennen.