Was sich sicherheitlich ändert, wenn ein Modell Dokumente liest und auf Systeme zugreift – sachlich erklärt, ohne Panik und ohne Verharmlosung.
Kostenlose KI-Erstberatung anfragen →
Zufriedene Kunden der Suchhelden GmbH
Hinweis zum Inhalt: Diese Seite beschreibt Risiken und Schutzmaßnahmen auf konzeptioneller Ebene. Sie enthält bewusst keine Anleitungen, mit denen sich Systeme angreifen lassen. Wir erklären, was passiert und was hilft – nicht, wie man es auslöst.
Sobald ein Sprachmodell im Unternehmen mitarbeitet, verschiebt sich die Sicherheitslage. Nicht dramatisch, aber spürbar. Ein neues System kommt dazu. Es liest Dokumente, beantwortet Fragen und greift manchmal auf andere Systeme zu. Damit entstehen Fragen, die es vorher so nicht gab.
Sobald im Haus über KI Sicherheit gesprochen wird, verläuft die Diskussion meist in zwei Lagern. Das eine sieht kein neues Risiko, weil ja nur ein Chatfenster dazugekommen sei. Das andere blockiert alles, weil Sicherheit nicht abschließend beweisbar ist. Beide Haltungen führen zum selben Ergebnis: Es passiert nichts Geordnetes. Und in der Zwischenzeit arbeiten Mitarbeitende längst mit privaten Zugängen.
„Du kannst um die Welt fliegen um international Business zu machen – wir bringen Dein Business zum Fliegen. Wir bewegen uns durch datenbasierte Customer Journeys, setzen auf transparente Zusammenarbeit und positionieren Dein Business an die Spitze. Ein Business braucht keine Superkräfte, aber es braucht Helden – Suchhelden. Denn nicht alle Helden tragen Capes.“
KI-Sicherheit im Unternehmen: Welche Risiken der Einsatz von Sprachmodellen mitbringt
Diese Seite sortiert die Lage. Wir beschreiben, welche Sicherheitsrisiken beim Einsatz von Sprachmodellen wirklich entstehen. Wir erklären Prompt Injection, also den Versuch, ein Modell über manipulierte Inhalte zu Handlungen zu bewegen. Und wir zeigen, welche Schutzmaßnahmen auf Ebene von Architektur, Rechten und Zuständigkeit tatsächlich greifen.
Ein Punkt vorweg, weil er sonst untergeht. Ein selbst betriebenes Modell löst den Datenweg. Inhalte verlassen Deine Umgebung nicht mehr. Das ist viel wert. Es löst aber nicht die Risiken, die aus der Arbeitsweise von Sprachmodellen selbst folgen. Prompt Injection gibt es auf eigener Hardware genauso. Falsche Antworten auch.
KI und Sicherheit ist deshalb kein Thema, das man einmal abhakt. Es ist eine Reihe von Festlegungen: Wer darf was sehen? Was darf das Modell auslösen? Wer prüft die Ergebnisse? Und wer ist zuständig, wenn etwas auffällt? Diese vier Fragen entscheiden mehr über die Sicherheit als jede Produktauswahl.
Rechte, Grenzen und Absicherung sind Teil von Schritt 4 und 5 – nicht ein Nachtrag nach dem Start.
So setzen wir das mit Euch um: Ziele verstehen → Stack und Modelle wählen → Ihr mietet den Server nach unserer Vorgabe → wir richten ihn ein und betreuen ihn → wir führen die KI bei Euch ein → wir trainieren sie, bis Eure Ziele erreicht sind. Den Ablauf im Detail ansehen
Jetzt anfragen →Lass uns gemeinsam herausfinden, wo Künstliche Intelligenz in Deinem Unternehmen den größten Nutzen stiftet – ehrlich, unverbindlich und auf Augenhöhe. Wenn sich ein Projekt für Dich nicht rechnet, sagen wir Dir das genauso klar.
Der erste Fall wirkt harmlos. Ein Assistent soll eingehende Dokumente zusammenfassen. Angebote, Bewerbungen, Rechnungen, Prüfberichte. Diese Inhalte stammen nicht aus dem eigenen Haus. Sie kommen von Menschen und Systemen außerhalb Eurer Kontrolle.
Ein Sprachmodell unterscheidet nicht von allein zwischen Auftrag und Inhalt. Beides erreicht es als Text. Steht in einem Dokument etwas, das wie eine Anweisung klingt, kann das Modell darauf reagieren. Genau das ist der Kern von Prompt Injection.
Solange das Modell nur zusammenfasst, bleibt der Schaden begrenzt. Kritisch wird es, sobald es Zugriff auf Systeme hat. Dann kann aus einer manipulierten Passage in einem Dokument eine ungewollte Aktion werden. Die Frage ist also nicht nur, was das Modell liest. Sondern was es anschließend tun darf.
Der zweite Fall ist der häufigste und der unauffälligste. Mitarbeitende nutzen ein KI-Werkzeug und fügen ein, woran sie gerade arbeiten. Einen Vertragsentwurf. Eine Kundenliste. Ein Protokoll aus der Geschäftsführung.
Das geschieht selten in böser Absicht. Ein Eingabefeld wirkt wie ein Notizzettel, nicht wie ein Upload. Wer denselben Inhalt per E-Mail nach außen schicken sollte, würde zweimal nachdenken.
Bei einem öffentlichen Dienst verlassen diese Inhalte das Haus. Bei einem eigenen Modell bleiben sie drin. Ganz erledigt ist die Frage trotzdem nicht: Auch intern gehört nicht jeder Inhalt in jedes System.
Der dritte Fall entsteht fast immer beim Anbinden des Firmenwissens. Damit ein Assistent nützlich ist, bekommt er Zugriff auf Laufwerke, Wikis und Ablagen. Im Eifer des Aufbaus wird dieser Zugriff großzügig vergeben. Schließlich soll das System ja alles finden.
Damit wird das Modell zur Abkürzung an der Rechteverwaltung vorbei. Eine Person ohne Zugriff auf Personalunterlagen fragt den Assistenten. Und bekommt eine Antwort, die auf genau diesen Unterlagen beruht. Technisch war nichts kaputt. Organisatorisch ist es ein Vorfall.
Solche Fälle fallen spät auf, weil niemand danach sucht. Die Antwort sieht normal aus. Genau deshalb gehört die Rechtefrage an den Anfang eines Projekts.
Die mittlere Spalte ist die unbequeme. Sie beschreibt den Zustand vieler Unternehmen, die das Thema schon angepackt haben. Der Server steht, das Modell läuft, die Daten bleiben im Haus. Gefühlt ist die Sache erledigt. Tatsächlich ist eine von mehreren Fragen beantwortet.
Der Sprung zur rechten Spalte ist deshalb der eigentliche Gewinn. Er kostet keine zusätzliche Hardware. Er besteht aus Festlegungen: Wer darf welche Quelle nutzen? Was darf das Modell auslösen? Was wird protokolliert? Und wer schaut hin? Für den technischen Unterbau bieten wir betreutes Hosting auf eigener Infrastruktur an – die Festlegungen treffen wir gemeinsam mit Euch.
Am Anfang steht eine nüchterne Bestandsaufnahme. Welche Aufgaben soll das Modell übernehmen? Welche Datenarten berührt es dabei? Und welche Systeme sollen angebunden werden? Aus diesen drei Antworten ergibt sich das Risikoprofil, nicht aus einer allgemeinen Checkliste.
Dazu gehört ein unangenehmer Punkt: Was läuft heute schon, ohne dass es freigegeben ist? Private Zugänge, Browser-Erweiterungen, kleine Testaufbauten auf Einzelrechnern. Wer diese Frage überspringt, sichert ein System ab, während das eigentliche Risiko daneben weiterläuft.
Der zweite Schritt ist der wichtigste. Hier wird entschieden, was das Modell sehen und was es tun darf. Die Grundregel lautet: Rechte werden aus den Quellsystemen übernommen, nicht neu erfunden. Wer ein Dokument ohne KI nicht öffnen darf, bekommt es auch über den Assistenten nicht zu sehen.
Ebenso wichtig ist die Trennung zwischen Lesen und Handeln. Lesender Zugriff ist vergleichsweise harmlos. Schreibender Zugriff verändert etwas in Euren Systemen. Für schreibende Vorgänge legen wir deshalb Bestätigungsschritte fest. Ein Mensch sieht, was passieren soll, und gibt es frei. Das klingt altmodisch und ist die wirksamste einzelne Maßnahme in diesem Feld.
Jetzt geht es um das System selbst. Ein Modellserver ist ein Server wie jeder andere und braucht dieselbe Sorgfalt. Abgeschottetes Netz, saubere Benutzerverwaltung über Euer bestehendes Verzeichnis, ein festgelegter Update-Weg, Protokollierung, Backups. Nichts davon ist KI-spezifisch. Vergessen wird es trotzdem regelmäßig.
Ein Baustein verdient besondere Erwähnung: die Ausgangs-Firewall. Damit lässt sich technisch erzwingen, dass der Dienst keine Verbindung nach außen aufbaut. Eine vertragliche Zusage ist schwächer, weil sie sich nicht messen lässt. Wie weit sich das treiben lässt, beschreiben wir auf unserer Seite zum Betrieb ohne Internetverbindung. Auch die passende Server-Ausstattung gehört in diesen Schritt.
KI-Sicherheit testen heißt vor allem, die Rechtegrenzen zu prüfen. Dieser Schritt wird am häufigsten übersprungen. Bevor alle Zugriff bekommen, wird nachgemessen, ob die Festlegungen halten. Eine Person mit eingeschränkten Rechten arbeitet mit dem System und schaut, ob sie an Inhalte kommt, die sie sonst nicht sehen darf. Dasselbe gilt für die angebundenen Werkzeuge: Was darf ausgelöst werden, und was nicht?
Diese Prüfung braucht zwei Dinge. Erstens eine benannte zuständige Person, die das Ergebnis bewertet. Zweitens einen festen Turnus, denn Rechte und Quellen verändern sich im Betrieb. Sinnvoll ist außerdem eine kleine Testgruppe echter Nutzer:innen an echten Aufgaben. Was dabei auffällt, fließt zurück in Rechte, Quellen und Vorlagen.
Diese vier Schritte sind kein eigenes Projekt neben der Einführung. Sie stecken in unserem Ablauf drin. Die technische Absicherung gehört zu Schritt 4: Wir richten den Server ein und betreuen ihn über die gesamte Laufzeit. Dazu zählen abgeschottetes Netz, Ausgangs-Firewall, Anmeldung über Euer Benutzerverzeichnis, Protokollierung und Backups.
Rechte und Grenzen entstehen in Schritt 5, wenn wir die KI einrichten und im Unternehmen einführen. Dort übernehmen wir die bestehenden Zugriffsrechte aus Euren Quellsystemen. Dort legen wir auch fest, was das Modell auslösen darf und wo ein Mensch bestätigt. Geprüft wird vor dem breiten Start, mit einer kleinen Testgruppe an echten Aufgaben. Danach hört das nicht auf: Die Prüfung der Grenzen läuft in Schritt 6 weiter, und die Betreuung des Servers bleibt Teil von Schritt 4.
Gemeinsam schauen wir, wo KI Deine Prozesse sinnvoll verbessern, Dein Team entlasten oder neue Möglichkeiten schaffen kann. Konkret, praxisnah und immer mit Blick darauf, was für Dein Unternehmen wirklich Mehrwert bringt.
Prompt Injection bezeichnet den Versuch, ein Sprachmodell über manipulierte Inhalte zu Handlungen zu bewegen, die niemand beauftragt hat. Die Manipulation steckt dabei nicht im System, sondern im Text, den das Modell verarbeitet: in einem Dokument, einer E-Mail oder einer Webseite. Das Modell behandelt diesen Text wie jede andere Eingabe.
Der Grund liegt in der Arbeitsweise von Sprachmodellen. Für sie ist alles Text. Auftrag, Systemregeln und Dokumentinhalt erreichen das Modell im selben Kanal. Eine harte technische Trennung zwischen „Anweisung" und „Material" gibt es nicht.
Ein klassischer Angriff nutzt einen Fehler in der Software aus und lässt sich mit einem Update beheben. Prompt Injection nutzt keine Lücke, sondern eine Eigenschaft. Genau das macht sie für Sicherheitsverantwortliche ungewohnt.
Daraus folgt die Schutzlogik. Man begrenzt nicht, was das Modell liest. Man begrenzt, was es anschließend kann. Ein Modell ohne Systemzugriff richtet durch manipulierten Text wenig an. Ein Modell mit weitreichenden Rechten sehr viel.
Diese drei Begriffe werden oft vermischt, meinen aber Unterschiedliches. Informationssicherheit ist der Oberbegriff. Sie fragt, ob Systeme und Informationen verfügbar, unversehrt und vertraulich bleiben. Sie gilt für jedes System im Haus, mit und ohne KI.
KI-Sicherheit ist der Ausschnitt daraus, der sich mit den Besonderheiten von Sprachmodellen befasst. Dazu gehören Prompt Injection, unklare Rechtegrenzen bei angebundenem Wissen, schreibende Zugriffe und überzeugend falsche Antworten. Der Begriff LLM-Sicherheit meint dasselbe, nur enger auf Sprachmodelle bezogen.
Datenschutz fragt etwas anderes: Werden personenbezogene Daten rechtmäßig verarbeitet? Ein System kann gut abgesichert und trotzdem datenschutzrechtlich fragwürdig sein. Und umgekehrt. Beide Themen gehören an denselben Tisch, sind aber nicht dasselbe. Zur rechtlichen Sicht haben wir eine eigene Seite zum Datenschutz bei eigener KI.
Daraus folgt eine entlastende Nachricht. Wenn Ihr über KI IT-Sicherheit sprecht, sprecht Ihr zum größten Teil über Dinge, die Ihr schon geregelt habt. Ein Sprachmodell ist zunächst ein System wie jedes andere. Netz, Zugänge, Rechte, Updates, Protokollierung und Backups gelten unverändert. Neu sind allein die KI-typischen Risiken obendrauf. Wer eine funktionierende IT-Sicherheit hat, fängt also nicht bei null an, sondern ergänzt sie um wenige Punkte.
Ein vierter Begriff taucht zunehmend auf: Prompt Security. Gemeint ist der Umgang mit allem, was in ein Modell hineingeht und aus ihm herauskommt. Also mit Eingaben, angebundenen Inhalten und Ausgaben. Der Begriff ist neu, die dahinterliegenden Fragen sind es nicht.
Der Markt wartet nicht – belegte Zahlen
stufen generative KI als geschäftskritisch ein.
KPMG 2025der Mittelständler haben noch keine konkrete KI-Strategie.
KI-Index Mittelstand, H-KAjährliches Produktivitätspotenzial generativer KI weltweit.
McKinsey Global InstituteIm Folgenden beschreiben wir, was in jedem Feld passiert und was dagegen hilft – auf der Ebene von Architektur, Rechten und Zuständigkeit.
Das Grundmuster ist immer gleich. Ein Inhalt aus fremder Hand enthält Text, der wie eine Anweisung wirkt. Das Modell verarbeitet ihn zusammen mit dem eigentlichen Auftrag. Ob daraus ein Schaden entsteht, hängt allein daran, was das Modell anschließend tun darf.
Wirksam ist deshalb Zurückhaltung bei den Fähigkeiten. Ein Assistent, der Dokumente zusammenfasst, braucht keinen Schreibzugriff auf das Ticketsystem. Jede Kombination aus „liest Fremdinhalte" und „darf handeln" gehört bewusst entschieden.
Dazu kommen Bestätigungsschritte an kritischen Stellen und eine sichtbare Kennzeichnung der Herkunft. Vollständig ausschließen lässt sich das Risiko nicht. Eingrenzen sehr wohl.
Hier geht es nicht um Angriffe, sondern um Alltag. Mitarbeitende fügen Inhalte ein, weil es praktisch ist. Der Vorgang fühlt sich nicht wie eine Weitergabe an, ist aber eine.
Eigener Betrieb entschärft das Feld deutlich. Die Inhalte bleiben in Eurer Umgebung. Übrig bleibt die interne Frage, welche Inhalte in welches System gehören und wer die Verläufe einsehen kann.
Der wirksamste Hebel ist aber nicht technisch. Es ist ein gutes internes Werkzeug. Solange das freigegebene System schlechter ist als der private Zugang, entscheiden Mitarbeitende sich für den privaten Zugang. Verbote allein ändern daran wenig.
Sobald Firmenwissen angebunden wird, entscheidet die Rechtefrage über alles. Die Regel ist einfach: Das Modell zeigt einer Person nur, was diese Person ohnehin sehen dürfte. Technisch heißt das, die Rechte aus den Quellsystemen zu übernehmen und bei jeder Anfrage anzuwenden.
Der Fehler passiert meist aus Bequemlichkeit. Eine Sammelberechtigung ist schneller eingerichtet als eine saubere Übernahme. Sie funktioniert im Test hervorragend und fällt im Betrieb irgendwann auf. Wie die Anbindung des Firmenwissens sauber aufgebaut wird, beschreiben wir auf unserer Seite dazu.
Dazu kommt die Pflege. Rechte ändern sich, Menschen wechseln Abteilungen, Ablagen werden umgebaut. Eine Rechteübernahme, die nie geprüft wird, altert still.
Ein Modell kann heute mehr als reden. Über standardisierte Werkzeug-Anbindungen greift es auf CRM, Ticketsystem, Ablagen oder Datenbanken zu. Damit steigt der Nutzen deutlich. Und mit ihm das Risiko.
Die wichtigste Unterscheidung lautet: lesen oder handeln. Lesende Zugriffe sind überschaubar. Schreibende verändern Euren Datenbestand oder lösen Vorgänge aus.
Praktisch heißt das: enge Freigaben je Werkzeug, keine Sammelrechte, und ein Bestätigungsschritt vor allem, was nach außen wirkt oder schwer rückgängig zu machen ist. Außerdem gehört protokolliert, welches Werkzeug wann durch wen ausgelöst wurde. Wer diese Punkte klärt, kann die Anbindung anschließend ruhig ausbauen.
Ein Modell ist eine Datei, die von irgendwo kommt. Bei frei verfügbaren Modellen lohnt deshalb der Blick auf die Herkunft. Wer veröffentlicht es? Ist die Quelle die offizielle? Welche Lizenz gilt, und was ist über das Training bekannt?
Das gilt genauso für die Werkzeuge drumherum. Laufzeitumgebungen, Oberflächen und Erweiterungen sind Software wie jede andere. Sie gehören aus nachvollziehbaren Quellen bezogen und aktuell gehalten. Welche Werkzeuge in Frage kommen, ordnen wir in unserem Ratgeber zu den Werkzeugen für den Eigenbetrieb ein.
Der Vorteil des Eigenbetriebs ist hier die Kontrolle über den Zeitpunkt. Ein Update passiert, wenn Ihr es wollt, und nicht über Nacht. Das setzt voraus, dass sich jemand die Änderungen anschaut.
Das unterschätzteste Risiko ist keines von außen. Ein Sprachmodell kann überzeugend danebenliegen. Die Antwort klingt sicher, ist gut formuliert und inhaltlich falsch. Genau die Kombination macht sie gefährlich.
Kritisch wird das dort, wo Antworten ungeprüft weitergereicht werden. Der Fehler wandert dann weiter und wird unterwegs glaubwürdiger.
Dagegen hilft ein Dreiklang. Quellenangaben, damit jede Aussage nachschlagbar ist. Eine klare Prüfpflicht dort, wo Ergebnisse das Haus verlassen. Und eine Einweisung, die deutlich macht, wofür das Werkzeug gedacht ist und wofür nicht. Wer nur schult, wie man Prompts schreibt, hat die Hälfte ausgelassen.
Ohne Protokolle gibt es keine Aufklärung. Wenn jemand fragt, wer wann worauf zugegriffen hat, braucht es eine Antwort. Das gilt für Anfragen an das Modell, für genutzte Wissensquellen und für ausgelöste Werkzeuge.
Eine zentrale Stelle ist dabei viel wert. Läuft alles über eine gemeinsame Vermittlungsschicht, entsteht die Übersicht an einem Ort statt verstreut über viele Anwendungen. Das erleichtert Auswertung und Prüfung erheblich.
Und ein Punkt, der gern übersehen wird: Diese Protokolle sind selbst schützenswert. In ihnen stehen Fragen, Inhalte und Namen. Wer sie einsehen darf, gehört genauso festgelegt wie alles andere. Auch für Aufbewahrung und Löschung braucht es eine Regel.
Warum KI-Helden
Keine lange Vertragsbindung. Volle Flexibilität, volle Kostenkontrolle.
Statt sechsstelliger Projektkosten: flexibles Monatsmodell.
Modellunabhängig und immer am neuesten Stand — keine Bindung an ein LLM.
Persönlicher Ansprechpartner, Jour-Fixe-Calls und dediziertes Umsetzungsteam.
Die folgenden Situationen begegnen uns am häufigsten. Such Dir die, die Eurer Lage am nächsten kommt.
Bewerbungen, Angebote, Rechnungen, Prüfberichte: Diese Inhalte kommen von außen und sind ungeprüft. Hier gilt die strengste Trennung zwischen Lesen und Handeln. Das System darf zusammenfassen, einordnen und vorschlagen. Auslösen darf es nichts ohne menschliche Bestätigung. Zusätzlich hilft eine sichtbare Kennzeichnung, dass der Inhalt aus fremder Quelle stammt.
Schatten-KI entsteht nicht aus Trotz, sondern aus Bedarf. Wo kein freigegebenes Werkzeug existiert, nutzen Mitarbeitende ihr privates. Damit liegen Firmeninhalte in Umgebungen, die niemand überblickt. Ein Verbot allein verschiebt das Problem nur in die Unsichtbarkeit. Wirksam ist ein internes Werkzeug, das im Alltag besser ist als der Umweg – plus eine klare, verständliche Regel dazu.
Beim Anbinden des Firmenwissens wird der Zugriff oft großzügig vergeben, damit das System etwas findet. Damit sieht das Modell mehr als die fragende Person. Richtig ist der umgekehrte Weg: Rechte aus den Quellsystemen übernehmen und bei jeder Anfrage anwenden. Das kostet Aufwand im Aufbau und erspart einen Vorfall im Betrieb.
Sobald ein Assistent Vorgänge anlegt, Status ändert oder Nachrichten verschickt, ändert sich die Risikolage. Jede Werkzeug-Anbindung bekommt eigene, enge Grenzen. Schreibende Vorgänge brauchen einen Bestätigungsschritt. Und alles, was ausgelöst wird, gehört protokolliert. Der Nutzen solcher Anbindungen ist groß – deshalb lohnt es, sie sauber aufzusetzen, statt sie zu vermeiden.
Eine Modellantwort landet in einem Angebot, einer Kundenauskunft oder einer fachlichen Bewertung. Niemand hat sie geprüft, weil sie überzeugend klang. Hier hilft keine Technik, sondern ein Prozessschritt: Was das Haus verlässt, wird von einem Menschen freigegeben. Quellenangaben machen diese Prüfung überhaupt erst praktikabel, weil sie den Weg zur Originalstelle zeigen.
Irgendwo läuft eine Installation, die jemand vor längerer Zeit aufgesetzt hat. Sie steht in keinem Inventar und in keinem Update-Plan. Solche Systeme altern still: Aktualisierungen bleiben aus, Rechte veralten, Protokolle fehlen. Das ist kein KI-Problem, sondern ein Zuständigkeitsproblem. Die Lösung: erfassen, zuordnen, betreuen oder abschalten.
Der wichtigste Satz dieser Seite ist auch der unbequemste. Ein selbst betriebenes Modell löst den Datenweg – und sonst nichts automatisch. Die Inhalte bleiben im Haus, der Serverstandort ist geklärt, es gibt keinen Drittanbieter in der Kette. Das ist viel wert. Es ist aber nur eine von mehreren Fragen.
Prompt Injection funktioniert auf eigener Hardware genauso. Die Ursache liegt in der Arbeitsweise des Modells und nicht im Betriebsort. Ebenso können Antworten auf einem eigenen Server überzeugend falsch sein. Wer glaubt, mit dem Umzug ins eigene Rechenzentrum sei KI Sicherheit erledigt, hat die Frage falsch gestellt.
Dazu kommt: Eigener Betrieb verschiebt Verantwortung zu Euch. Updates, Protokolle, Rechte und Zuständigkeiten liegen jetzt im Haus. Das ist genau der Vorteil – es ist aber auch Arbeit. Wer sie weder selbst leisten noch abgeben will, ist mit einem fertigen Dienst ehrlicher bedient.
Und eine letzte Einschränkung betrifft die rechtliche Seite. Ein technisch sauber abgesichertes System ist eine gute Ausgangslage, mehr aber auch nicht. Eine vollständige Rechtsberatung können wir nicht leisten – für die datenschutzrechtliche Bewertung zieh bitte spezialisierte Datenschutzberater:innen oder Deine:n Datenschutzbeauftragte:n hinzu.
Lass uns gemeinsam klären, welche Risiken in Eurem Aufbau wirklich stecken – und welche Festlegungen es braucht, bevor das System für alle geöffnet wird. Kostenlos und unverbindlich.
KI-Helden ist die KI-Abteilung der Suchhelden GmbH aus Osnabrück. Seit über einem Jahrzehnt arbeiten wir mit Unternehmen an digitalen Projekten. Vom Start-up bis zum internationalen Konzern, branchenunabhängig. Über 4.000 realisierte Projekte, ein Team aus über 140 Held:innen.
Für das Thema KI Sicherheit heißt das vor allem eines: Wir reden nicht über Bedrohungen im Allgemeinen, sondern über Euren konkreten Aufbau. Welche Quellen sind angebunden? Wer nutzt das System? Was darf es auslösen? Aus diesen Antworten wird ein Konzept, das im Alltag trägt – und nicht ein Dokument, das niemand liest.
Prompt Injection ist der Versuch, ein Sprachmodell über manipulierte Inhalte zu Handlungen zu bewegen, die niemand beauftragt hat. Die Manipulation steckt im Material, das das Modell verarbeitet: in einem Dokument, einer E-Mail oder einer Webseite. Für das Modell ist alles Text, Auftrag und Inhalt kommen im selben Kanal an. Kritisch wird das vor allem dann, wenn das Modell Zugriff auf andere Systeme hat.
Nein. Prompt Injection folgt aus der Arbeitsweise von Sprachmodellen und nicht aus dem Betriebsort. Sie funktioniert auf eigener Hardware genauso wie bei einem öffentlichen Dienst. Eigener Betrieb löst den Datenweg, also die Frage, wohin Inhalte gehen. Die KI-typischen Risiken bleiben. Eingrenzen lässt sich Prompt Injection dadurch, dass ein Modell nur wenige, bewusst vergebene Fähigkeiten bekommt und schreibende Vorgänge bestätigt werden müssen.
KI-Sicherheit fragt, ob ein System gegen Missbrauch und Fehlverhalten abgesichert ist. Datenschutz fragt, ob personenbezogene Daten rechtmäßig verarbeitet werden. Beides hängt zusammen, ist aber nicht dasselbe. Ein System kann technisch gut abgesichert und datenschutzrechtlich trotzdem fragwürdig sein. Umgekehrt genauso. Wir empfehlen, beide Themen früh an denselben Tisch zu holen – und für die rechtliche Bewertung fachkundige Beratung hinzuzuziehen.
Indem Ihr die Rechtegrenzen nachmesst, bevor alle Zugriff bekommen. Eine Person mit eingeschränkten Rechten arbeitet mit dem System und prüft, ob sie an Inhalte kommt, die sie sonst nicht sehen darf. Dasselbe gilt für angebundene Werkzeuge: Was darf ausgelöst werden, was nicht? Dazu kommt eine kleine Testgruppe echter Nutzer:innen an echten Aufgaben. Das Ergebnis bewertet eine benannte zuständige Person und veranlasst die Änderungen.
Zurückhaltend bei den Fähigkeiten, nicht beim Lesen. Bewerbungen, Angebote oder Prüfberichte sind ungeprüftes Material aus fremder Hand. Das System darf sie zusammenfassen, einordnen und Vorschläge machen. Auslösen sollte es nichts ohne menschliche Bestätigung. Hilfreich ist außerdem eine sichtbare Kennzeichnung der Herkunft, damit Nutzer:innen eine Aussage richtig einordnen. Der Schutz liegt also nicht darin, was das Modell liest, sondern in dem, was es danach darf.
Am wirksamsten durch ein internes Werkzeug, das besser ist als der private Umweg. Solange kein freigegebenes System existiert, nutzen Menschen ihr eigenes – und Firmeninhalte landen in Umgebungen, die niemand überblickt. Dazu kommen eine verständliche Regel und eine kurze Einweisung, die erklärt, warum es sie gibt. Bei eigenem Betrieb bleiben die Inhalte ohnehin in Eurer Umgebung, was den kritischsten Teil entschärft.
Nein, und das ist die wichtigste Regel überhaupt. Ein Assistent zeigt nur, was die fragende Person auch ohne KI sehen dürfte. Technisch bedeutet das, die Rechte aus den Quellsystemen zu übernehmen und bei jeder Anfrage anzuwenden – statt eine eigene Berechtigungswelt aufzubauen. Sammelberechtigungen sind bequem im Aufbau und der häufigste Grund für spätere Vorfälle. Dieser Punkt gehört an den Anfang eines Projekts.
Deutlich kritischer als lesende, weil sie etwas verändern oder auslösen. Ein Modell, das nur liest, kann im schlechtesten Fall Falsches erzählen. Ein Modell, das schreibt, verändert Euren Datenbestand oder verschickt etwas nach außen. Deshalb bekommt jede Werkzeug-Anbindung eigene, enge Grenzen. Vorgänge, die schwer rückgängig zu machen sind, brauchen einen Bestätigungsschritt durch einen Menschen. Und alles Ausgelöste gehört protokolliert.
Schatten-KI meint die Nutzung privater KI-Zugänge für berufliche Aufgaben, ohne Freigabe und ohne Überblick. Sie entsteht nicht aus Trotz, sondern aus Bedarf. Ein Verbot verschiebt das Problem nur in die Unsichtbarkeit. Wirksam ist ein offizielles Werkzeug, das im Alltag schneller und besser ist als der Umweg. Dazu eine klare Regel, was hineindarf. In der Bestandsaufnahme schauen wir zuerst, was heute schon läuft.
Über die Herkunft. Wer veröffentlicht das Modell, ist die Quelle die offizielle, welche Lizenz gilt und was ist über das Training bekannt? Dasselbe gilt für die Werkzeuge drumherum: Sie gehören aus nachvollziehbaren Quellen bezogen, versioniert und aktuell gehalten. Der Vorteil des Eigenbetriebs ist die Kontrolle über den Zeitpunkt. Du entscheidest, welche Version läuft und wann sie wechselt.
Damit rechnen und den Prozess darauf auslegen. Ein Sprachmodell kann überzeugend danebenliegen, auf eigener Hardware genauso wie in der Cloud. Drei Dinge helfen: Quellenangaben, damit jede Aussage nachschlagbar ist. Eine klare Prüfpflicht überall dort, wo Ergebnisse das Haus verlassen. Und eine Einweisung, die sagt, wofür das Werkzeug gedacht ist und wofür nicht. Die Verantwortung für das Ergebnis bleibt beim Menschen.
Für Nachvollziehbarkeit ist es sehr sinnvoll, und für Aufklärung meist unverzichtbar. Protokolliert gehören Anfragen, genutzte Wissensquellen und ausgelöste Werkzeuge. Läuft alles über eine gemeinsame Vermittlungsschicht, entsteht die Übersicht an einer Stelle. Wichtig ist der zweite Teil: Diese Protokolle sind selbst schützenswert, weil darin Inhalte und Namen stehen. Wer sie einsehen darf und wie lange sie aufbewahrt werden, gehört festgelegt.
Es ist die richtige Grundlage, deckt aber nicht alles ab. Netz, Konten, Updates und Backups gelten für einen Modellserver genauso wie für jedes andere System. Neu sind die Punkte, die aus der Arbeitsweise des Modells folgen: Rechtegrenzen bei angebundenem Wissen, schreibende Zugriffe, Umgang mit Fremdinhalten und die Prüfung von Ergebnissen. KI und IT-Sicherheit gehören in dasselbe Konzept: Wir ergänzen die Punkte dort, statt ein zweites danebenzustellen.
Wie jedes andere wichtige System, mit einer Ergänzung. Abgeschottetes Netz, Anmeldung über Euer bestehendes Benutzerverzeichnis, ein festgelegter Update-Weg, Protokollierung, Backups und eine benannte Zuständigkeit. Die Ergänzung ist die Ausgangs-Firewall: Damit lässt sich technisch erzwingen und nachweisen, dass der Dienst keine Verbindung nach außen aufbaut. Eine vertragliche Zusage ist schwächer, weil sie sich nicht messen lässt.
Prompt Security bezeichnet den Umgang mit allem, was in ein Sprachmodell hineingeht und aus ihm herauskommt. Also mit den Eingaben der Nutzer:innen, mit angebundenen Inhalten und mit den Ausgaben. Dazu gehören Fragen wie: Welche Inhalte dürfen verarbeitet werden? Wie wird mit Material aus fremder Hand umgegangen? Und wer prüft die Ergebnisse? Der Begriff ist neu, die dahinterliegenden Fragen sind es nicht.
Das muss festgelegt werden, sonst ist es niemand. In der Praxis bewährt sich eine benannte Rolle mit Vertretung, meist in der IT oder der Informationssicherheit, eng abgestimmt mit dem Datenschutz. Diese Rolle verantwortet Rechte, Updates, Protokolle und die regelmäßige Prüfung. Ohne Zuständigkeit altern Systeme still: Aktualisierungen bleiben aus, Rechte veralten, und niemand merkt es. Das ist der häufigste stille Fehler in diesem Feld.
In einem Punkt eindeutig ja: Die Inhalte verlassen Deine Umgebung nicht, und Du bestimmst, was läuft. In allen anderen Punkten hängt es davon ab, wie sauber gearbeitet wird. Ein eigener Server ohne Rechtekonzept und ohne Zuständigkeit kann unsicherer sein als ein gepflegter Dienst. Der Vorteil des Eigenbetriebs ist Kontrolle. Kontrolle wirkt aber nur, wenn sie jemand ausübt.
Regelmäßig und zusätzlich bei jeder Änderung. Neue Wissensquelle, neue Werkzeug-Anbindung, neues Modell, größerer Nutzerkreis: Jeder dieser Punkte verschiebt die Rechtelage. Wir empfehlen einen festen Turnus für die Prüfung der Rechtegrenzen und eine kurze Bewertung bei jeder Erweiterung. Beides braucht eine benannte Person, sonst verschiebt es sich. Einen festen Zeitrahmen nennen wir bewusst nicht – er hängt an Eurer Änderungsgeschwindigkeit.
