Eine lokale KI ist noch lange keine sichere KI

Eine lokale KI klingt zunächst nach einer ziemlich einfachen Antwort auf viele Fragen, die Unternehmen aktuell beschäftigen.

Das Sprachmodell läuft auf eigener Hardware. Die Daten verlassen das Unternehmen nicht. Keine externen APIs, keine fremde Cloud, keine unkontrollierbare Datenübertragung.

Technisch ist das heute vergleichsweise einfach umzusetzen. Mit Projekten wie Ollama lassen sich moderne Sprachmodelle innerhalb weniger Minuten lokal betreiben.

Aber damit ist eine entscheidende Frage noch nicht beantwortet:

Was darf diese KI eigentlich?

Genau diese Frage wird meiner Meinung nach in vielen Diskussionen über lokale KI bisher zu wenig betrachtet.

Denn sobald aus einem Sprachmodell mehr als ein Chatbot wird und es tatsächlich mit Unternehmensdaten und Unternehmenssystemen arbeiten soll, geht es nicht mehr nur um das richtige Modell. Es geht um Identitäten, Berechtigungen und kontrollierte Aktionen.

Das Problem beginnt mit dem ersten Zugriff

Nehmen wir ein einfaches Beispiel.

Ein Unternehmen betreibt eine lokale KI auf einem Linux-Server. Die KI soll interne Dokumente durchsuchen können.

Technisch könnte man dem entsprechenden Prozess einfach Zugriff auf einen Ordner geben:

/data/knowledge

Die Dokumente werden indexiert, in einer Vektordatenbank abgelegt und können anschließend über einen RAG-Ansatz durchsucht werden. Genau so entsteht in der Praxis oft der Einstieg in eine KI-Wissensdatenbank.

Das funktioniert.

Interessant wird es, sobald die KI zusätzlich auf andere Daten zugreifen oder Aktionen ausführen soll.

Vielleicht auf:

• /data/knowledge
• /data/projects
• /data/templates
• /data/crm

Vielleicht soll sie Dokumente erstellen dürfen, aber keine bestehenden Dokumente überschreiben.

Vielleicht darf sie bestimmte Daten nur lesen.

Vielleicht soll sie später sogar Aktionen in einem ERP-System durchführen können.

Spätestens dann reicht die Aussage „Die KI läuft lokal“ nicht mehr aus.

Lokales Sprachmodell

Ollama, vLLM oder vergleichbare Inference

/data/knowledge
Dokumente

/data/projects
Projekte

/data/templates
Vorlagen

/data/crm
CRM-Daten

ERP
Aktionen

Ohne klare Rechte sieht die KI potenziell alles, an das der Prozess technisch angebunden ist.

Eine KI sollte nicht automatisch alles sehen dürfen

Ein naheliegender Ansatz ist, die KI unter einem eigenen technischen Benutzer laufen zu lassen.

Auf Linux könnte beispielsweise ein dedizierter Service-Account verwendet werden:

user: ai-reader

Dieser Benutzer bekommt ausschließlich die Rechte, die für seine Aufgabe notwendig sind.

Zum Beispiel:

Pfad	Recht
/data/knowledge	read
/data/drafts	read/write
/data/finance	no access
/etc	no access
/home	no access

Die Idee dahinter ist nicht neu. Sie entspricht einem Grundprinzip klassischer IT-Sicherheit: Least Privilege.

Ein Dienst bekommt nur die Berechtigungen, die er tatsächlich benötigt.

Für eine lokale KI ist dieses Prinzip besonders relevant. Denn ein lokal laufendes Modell kann genauso mit zu weitreichenden Berechtigungen ausgestattet werden wie jeder andere Prozess.

Aber der Service-Account allein reicht nicht

Bisher haben wir nur eine Frage beantwortet:

Was darf dieser KI-Dienst grundsätzlich?

In einer Unternehmensumgebung gibt es aber eine zweite Dimension:

Was darf der konkrete Mitarbeiter?

Nehmen wir zwei Mitarbeiter.

Mitarbeiter A arbeitet im Vertrieb.

Mitarbeiter B arbeitet in der Personalabteilung.

Beide verwenden dieselbe interne KI.

Der Vertriebsmitarbeiter darf auf Angebote, Kundendaten und Vertriebsdokumente zugreifen. Die Personalabteilung darf auf Personalunterlagen zugreifen.

Die KI sollte deshalb nicht einfach sagen: „Ich bin lokal installiert und darf alles lesen.“

Sie muss den Kontext des Benutzers berücksichtigen.

Damit entstehen zwei getrennte Berechtigungsebenen.

Mensch

Mitarbeiteridentität

Active Directory, Entra ID oder LDAP. Vertrieb darf CRM sehen, Personal darf Personalakten sehen.

KI

Technische Identität

ai-reader, ai-editor, ai-crm, ai-erp. Jeder Agent hat nur die Rechte für seine Aufgabe.

Benutzerberechtigung + Agentenberechtigung = effektive Berechtigung

Mensch und KI brauchen unterschiedliche Identitäten

Der menschliche Benutzer besitzt eine Identität, zum Beispiel über Active Directory, Entra ID oder LDAP.

Die KI beziehungsweise ein einzelner KI-Agent besitzt ebenfalls eine technische Identität.

Zum Beispiel:

• ai-reader
• ai-editor
• ai-crm
• ai-erp

Diese technischen Identitäten können jeweils unterschiedliche Rechte und Fähigkeiten besitzen.

Damit lässt sich ein relativ einfaches Grundmodell formulieren:

Der Mitarbeiter bringt seine Berechtigungen mit. Der KI-Agent bringt seine eigenen Fähigkeiten und Einschränkungen mit. Eine konkrete Aktion sollte nur möglich sein, wenn beide Ebenen sie zulassen.

Vereinfacht:

Benutzerberechtigung
+
Agentenberechtigung
=
effektive Berechtigung

Das ist bewusst vereinfacht. In einer realen Umgebung können zusätzlich Faktoren wie Datenklassifizierung, konkrete Ressource, Zweck, Freigaben oder das Risiko der Aktion eine Rolle spielen.

Genau deshalb wird aus der Frage nach einem Service-Account zunehmend eine Frage nach einer eigenen Zugriffsschicht.

Die KI sollte nicht direkt mit dem Dateisystem arbeiten

Noch einen Schritt weiter gedacht würde ich dem Sprachmodell selbst möglichst wenig direkte Rechte geben.

Das Modell sollte nicht einfach Shell-Befehle ausführen oder beliebige Dateien verändern können.

Stattdessen sollte es klar definierte Werkzeuge verwenden.

Zum Beispiel:

• search_documents()
• create_draft()
• read_customer()
• create_offer()
• create_ticket()

Das Modell kann damit nicht beliebige Aktionen ausführen. Es kann lediglich eine definierte Aktion anfordern.

Eine weitere Schicht entscheidet anschließend, ob diese Aktion erlaubt ist.

1. Mitarbeiter stellt eine Anfrage
2. KI-Agent fordert eine Aktion an, zum Beispiel create_offer
3. Policy Engine prüft Benutzer, Agent, Daten, Aktion, Freigabe und Protokollierung
4. Tool führt die Aktion nur bei Freigabe aus
5. CRM, ERP oder Dateisystem bleibt die eigentliche Quelle der Daten und ihrer Berechtigungen

Das könnte beispielsweise so aussehen:

Mitarbeiter
    ↓
KI-Agent
    ↓
"create_offer"
    ↓
Policy Engine
    ↓
Ist dieser Benutzer dazu berechtigt?
Ist dieser Agent dazu berechtigt?
Sind die benötigten Daten freigegeben?
Ist eine menschliche Bestätigung erforderlich?
    ↓
Tool
    ↓
CRM / ERP / Dateisystem

Damit wird das Sprachmodell selbst zu einem relativ kleinen Teil des Systems.

Die eigentliche Kontrolle liegt außerhalb des Modells.

Und plötzlich wird aus einem Chatbot ein Berechtigungsproblem

Genau an diesem Punkt verändert sich meiner Meinung nach die Perspektive auf Unternehmens-KI.

Solange eine KI lediglich Fragen beantwortet, ist das Berechtigungsproblem vergleichsweise überschaubar.

Sobald die KI aber handeln darf, verändert sich die Situation. Genau dort beginnt KI-Automatisierung: nicht beim Chat, sondern bei definierten Aktionen in bestehenden Systemen.

Eine KI soll vielleicht:

• Dokumente lesen.
• Dokumente erstellen.
• E-Mails vorbereiten.
• Tickets anlegen.
• CRM-Daten aktualisieren.
• Angebote erstellen.
• Informationen aus einem ERP-System abrufen.
• Oder irgendwann sogar administrative Aufgaben durchführen.

Jede dieser Aktionen besitzt ein eigenes Risiko und benötigt eigene Berechtigungen.

Eine KI, die ein Dokument zusammenfassen darf, braucht nicht automatisch das Recht, dieses Dokument zu löschen.

Eine KI, die einen Entwurf für ein Angebot erstellen darf, muss nicht automatisch Angebote versenden dürfen.

Eine KI, die Server-Logs lesen darf, sollte nicht automatisch Serverkonfigurationen verändern können.

Bei klassischen Softwareanwendungen bauen wir solche Grenzen seit Jahren. Bei KI-Agenten müssen wir anfangen, dieselben Prinzipien konsequent anzuwenden.

Bevor ein Agent solche Aktionen ausführen soll, lohnt sich deshalb zuerst die Frage, ob KI für den Prozess überhaupt der richtige Weg ist. Dafür gibt es den KI-Check.

Das Betriebssystem liefert bereits einen Teil der Lösung

Interessant ist dabei, dass wir nicht bei null anfangen müssen.

Linux besitzt seit Jahrzehnten ein ausgefeiltes Berechtigungsmodell.

Benutzer, Gruppen, Dateirechte, ACLs, Container, systemd, AppArmor oder SELinux können genutzt werden, um Prozesse voneinander zu isolieren und Zugriffe einzuschränken.

Unter Windows gibt es mit Active Directory, Service-Accounts und NTFS-ACLs ebenfalls mächtige Möglichkeiten.

Auch macOS bringt mit Unix-Berechtigungen, ACLs, Sandboxing und weiteren Sicherheitsmechanismen entsprechende Bausteine mit.

Die konkrete technische Umsetzung unterscheidet sich je nach Betriebssystem.

Das Grundprinzip bleibt aber gleich:

Die KI bekommt nicht pauschal Zugriff auf die Unternehmensumgebung. Sie bekommt genau definierte Fähigkeiten.

Aber was passiert mit Unternehmenssystemen?

Hier endet das klassische Dateirechtemodell.

Ein ERP-System funktioniert nicht wie ein Ordner auf einem Linux-Server.

Ein CRM-System funktioniert nicht wie ein lokales Dateisystem.

Und eine SaaS-Anwendung lässt sich nicht einfach über einen Service-Account und eine NTFS-ACL absichern.

Deshalb braucht eine solche Architektur zusätzlich eine Ebene oberhalb des Betriebssystems. Eine Art Policy- oder Access-Layer.

Diese Schicht könnte für jede Aktion prüfen:

• Wer ist der Benutzer?
• Welcher Agent möchte handeln?
• Welche Daten werden benötigt?
• Welche Aktion soll ausgeführt werden?
• Ist diese Aktion erlaubt?
• Ist eine Freigabe notwendig?
• Welche technische Identität führt die Aktion aus?
• Was muss protokolliert werden?

Damit entsteht eine Übersetzungsschicht zwischen der Sprache der KI und der Sprache der Unternehmens-IT.

Vielleicht brauchen wir für KI ein neues Berechtigungsmodell

Ich finde genau diese Frage momentan spannender als die Frage, welches lokale Sprachmodell man einsetzen sollte.

Denn Modelle werden austauschbarer.

Heute läuft vielleicht ein Modell von Meta, Alibaba, Mistral oder einem anderen Anbieter. Morgen ist ein anderes Modell besser.

Die grundsätzliche Frage bleibt jedoch:

Welche Fähigkeiten darf ein KI-Agent innerhalb eines Unternehmens besitzen?

Das erinnert an klassische Betriebssystemberechtigungen, geht aber darüber hinaus.

Ein KI-Agent besitzt nicht nur Zugriff auf Ressourcen. Er kann Entscheidungen treffen und daraus Aktionen ableiten.

Damit müssen wir neben der Frage „Darf dieser Prozess diese Datei lesen?“ zunehmend auch fragen:

„Darf dieser Agent diese Aktion im Namen dieses Benutzers durchführen?“

Das ist der Punkt, an dem sich klassische Berechtigungsmodelle und KI-Agenten überschneiden. Der Agent benötigt nicht nur Zugriff auf Daten, sondern klar definierte Fähigkeiten und Grenzen.

Ein möglicher Aufbau

Eine solche Architektur könnte vereinfacht aus fünf Ebenen bestehen.

Mensch

↓

Identität

↓

Policy Layer

↓

AI-Agent
Reader

AI-Agent
Editor

↓

Tools / APIs / Services

↓

Files

CRM

ERP

Mail

Der Mensch bringt seine Identität und seine Unternehmensberechtigungen mit.

Der KI-Agent bringt seine eigenen Fähigkeiten und Einschränkungen mit.

Die Policy-Schicht entscheidet, ob eine konkrete Aktion unter den gegebenen Bedingungen erlaubt ist.

Die Tools führen die Aktion aus.

Die Unternehmenssysteme bleiben die eigentliche Quelle der Daten und ihrer Berechtigungen.

Das Sprachmodell selbst bleibt möglichst weit von direkten Systemrechten entfernt.

Lokale KI ist deshalb nur ein Teil der Geschichte

Für besonders sensible Anwendungen kann es sinnvoll sein, das Sprachmodell vollständig innerhalb der eigenen Infrastruktur zu betreiben.

Das kann beispielsweise mit Ollama, vLLM oder anderen lokalen Inference-Lösungen geschehen. Mehr zur Einordnung steht auf der Seite Lokale KI für Unternehmen.

Das reduziert die Abhängigkeit von externen KI-APIs und kann für bestimmte Datenklassen sinnvoll sein.

Aber „lokal“ sollte nicht mit „sicher“ gleichgesetzt werden.

Ein Modell, das lokal läuft und Zugriff auf sämtliche Unternehmensdaten besitzt, ist nicht automatisch besser abgesichert als ein Cloud-Modell.

Sicherheit entsteht durch die Kombination aus Infrastruktur, Identitäten, Berechtigungen, Isolation, Policies und nachvollziehbaren Aktionen.

Die lokale Ausführung ist dabei nur ein Baustein.

Vielleicht ist genau das der interessante Teil

Ich glaube nicht, dass jedes Unternehmen zwingend eine eigene KI-Plattform benötigt.

Und ich glaube auch nicht, dass man für jeden Kunden zwanghaft einen KI-Anwendungsfall erfinden sollte.

Interessanter ist die umgekehrte Frage:

Welche Prozesse würden Unternehmen heute gerne mit KI unterstützen, wenn sie der KI dabei vertrauen könnten?

Vielleicht ist es die interne Wissenssuche.

Vielleicht ist es die Bearbeitung von E-Mails.

Vielleicht ist es die Erstellung von Angeboten.

Vielleicht ist es die Analyse von Produktionsdaten.

Vielleicht ist es etwas völlig anderes.

Der konkrete Use Case kann sich verändern.

Die Anforderungen an Identität, Berechtigungen, Isolation und Kontrolle bleiben dagegen bestehen.

Genau deshalb könnte eine solche Sicherheits- und Zugriffsschicht langfristig interessanter sein als ein weiterer spezialisierter KI-Chatbot.

Denn die Modelle werden besser.

Die Unternehmensdaten bleiben.

Die Prozesse bleiben.

Und die Frage, was eine KI innerhalb dieser Umgebung tatsächlich darf, wird mit jedem neuen Agenten wichtiger.

Vielleicht brauchen wir also nicht mehr KI in Unternehmen. Vielleicht brauchen wir zuerst eine bessere Art, KI sicher in Unternehmen arbeiten zu lassen.

Wenn Sie prüfen möchten, welche Daten, Identitäten und Freigaben ein KI-Agent in Ihrer Umgebung tatsächlich bekommen sollte, kläre ich das in 15 Minuten unverbindlich. Zum Erstgespräch.