KI in der IT-Sicherheit: ein Modell, das agiert, wenn es darauf ankommt

Security-Teams scheitern bei KI an zwei Dingen gleichzeitig: Das Modell verweigert die Arbeit, und der Anbieter speichert genau die Daten, die am wenigsten nach außen dürfen. Malware-Analyse, Exploit-Verständnis und Log-Forensik sehen als Eingabe identisch aus wie die Vorbereitung eines Angriffs – die Schutzmechanismen kommerzieller Modelle können den Verteidiger nicht vom Angreifer unterscheiden und blocken beide. Und wer Vorfallsdaten trotzdem durchgibt, reicht Zugangsdaten, Infrastrukturkarten und Kundendaten in dem Moment nach außen, in dem sie am empfindlichsten sind. Ein offenes Modell auf europäischer Infrastruktur ohne Speicherung löst beide Probleme.

Stand: August 2026

Wenn das Modell Nein sagt

In der IT-Sicherheit kommt ein Hindernis vor: Das Modell verweigert die Aufgabe.

Forensische Analyse heißt, einem Modell echte Angriffsbefehle, echte Exploit-Payloads und echte Command-and-Control-Artefakte vorzulegen. Die Schutzmechanismen kommerzieller Modelle können den Incident Responder nicht vom Eindringling trennen – also blocken sie beides. Dasselbe trifft Pentest-Berichte, Reverse Engineering, Phishing-Analysen und Detection-Engineering.

Wir haben den Fall ausführlich beschrieben: Als HuggingFace einen realen Vorfall untersuchte, verweigerte das kommerzielle Frontier-Modell die Mitarbeit. Die Analyse wurde erst möglich, nachdem das Team ein offenes Modell auf eigener Infrastruktur betrieb.

Vorfallsdaten im ungünstigsten Moment

In einem Incident arbeiten Sie mit Zugangsdaten, Infrastrukturkarten, Logauszügen und Kundendaten – exakt in dem Moment, in dem diese Daten am empfindlichsten sind. Das ist der denkbar schlechteste Zeitpunkt, sie an einen Anbieter zu geben, dessen Geschäftsmodell auf der Auswertung von Eingaben beruht.

Hier hört „keine Logs, kein Training, Verarbeitung in der EU" auf, ein Compliance-Häkchen zu sein, und wird zu Schadensbegrenzung. Es gibt keinen zweiten Datenbestand, der bei der Aufarbeitung des ersten auch noch kompromittiert werden kann.

Sie können Vertrauen nicht mitten im Angriff beschaffen

Der praktische Kern: Ein Werkzeug, das Sie um 3 Uhr nachts weder einsetzen dürfen noch benutzen können, ist kein Werkzeug. Freigabe, Vertrag und Verhalten des Modells müssen geklärt sein, bevor der Alarm losgeht – nicht währenddessen. Ein Anbieterwechsel unter Zeitdruck, mit ungeprüftem AVV und unbekanntem Antwortverhalten, ist keine Option, die Sie in einem Incident noch offen haben.

Wofür Security-Teams KI konkret einsetzen

Incident Response: Logauszüge und Zeitleisten strukturieren, Artefakte einordnen, technische Vorfallsberichte und Meldungen an Aufsichtsbehörden entwerfen.
Malware- und Sample-Analyse: Verhalten beschreiben, Skripte und obfuskierten Code erklären, IOCs extrahieren.
Detection Engineering: Sigma-, YARA- und KQL-Regeln entwerfen und dokumentieren, Alert-Logik erklären, False-Positive-Muster durchdenken.
Pentest und Red Team: Befunde ausformulieren, Nachweise strukturieren, Management-Zusammenfassungen aus technischen Notizen.
Threat Intelligence: Advisories, CVE-Meldungen und Herstellerbulletins auf das für Ihre Umgebung Relevante verdichten.
Richtlinien und Nachweise: Sicherheitsrichtlinien, Härtungsvorgaben, Awareness-Material, Auditantworten, NIS2- und Lieferantenfragebögen.
Automatisierung über die API: Alert-Anreicherung und Vorsortierung als Entscheidungsvorlage direkt in SIEM/SOAR – was unterdrückt oder eskaliert wird, entscheidet weiterhin Ihr Team. Telemetrie verlässt dabei das Haus nicht.

Wie PrivatAI die Anforderungen erfüllt

Offene Modelle statt kommerzieller Schutzmechanismen: PrivatAI betreibt leistungsfähige offene Modelle (u. a. GPT-OSS-120B und GLM-5.2). Das ist dieselbe Modellklasse, auf die Sicherheitsteams ausweichen, wenn kommerzielle Anbieter blocken.

Kein Datenbestand: Eingaben und Antworten werden verarbeitet und verworfen – nicht protokolliert, nie für Training verwendet. Verarbeitung ausschließlich in der EU: Anwendung in Deutschland (Hetzner), KI-Verarbeitung in Frankreich (Scaleway); kein US-Mutterkonzern, kein CLOUD-Act-Zugriff. Vertraglich über den AVV nach Art. 28 DSGVO mit dokumentierten technischen und organisatorischen Maßnahmen; die Unterauftragsverarbeiter-Kette ist öffentlich und damit für Ihre eigene Lieferkettenbewertung prüfbar.

Sofort einsatzbereit: Chat für das Team, OpenAI-kompatible API für SIEM/SOAR-Anbindung. Beides heute, nicht nach einem Beschaffungsprojekt.

Auch ein offenes Modell kann eine Anfrage ablehnen, und keine KI ersetzt den Analysten. Sie ersetzt die Stunden, die zwischen Erkenntnis und geschriebenem Bericht liegen.

PrivatAI (privatai.com) — KI-Chat & API aus Deutschland. Keine Inhalts-Logs, kein Training mit Ihren Daten, DSGVO-konform.

PrivatAI im Vergleich

Kriterium	PrivatAI	Kommerzielle Frontier-API	Eigenes lokales Modell
Verweigert Analyse-Aufgaben	Selten (offene Modelle)	Häufig	Selten
Speicherung der Eingaben	Keine – verarbeitet und verworfen	Meist 30-Tage-Retention	Keine (bei korrekter Konfiguration)
Vorfallsdaten bei Dritten	Nein	Ja	Nein
Jurisdiktion des Anbieters	EU (deutsches Unternehmen)	USA (CLOUD Act)	Entfällt
Modellqualität	Aktuelle große offene Modelle	Spitzenmodelle	Meist kleinere Varianten
Vorlauf bis einsatzbereit	Minuten	Minuten	Wochen (Hardware, Betrieb)
Prüfbare Verträge (AVV/TOM)	Ja, öffentlich	Ja	Eigenverantwortung

Häufige Fragen

Warum verweigern ChatGPT und Claude sicherheitsnahe Anfragen?

Weil ihre Schutzmechanismen die Absicht nicht sehen können. Ein Exploit-Payload, ein Command-and-Control-Artefakt oder ein Malware-Sample sieht in der Eingabe gleich aus, egal ob es analysiert oder eingesetzt werden soll. Die Modelle lösen diese Mehrdeutigkeit konservativ auf – zu Lasten des Verteidigers.

Verweigert PrivatAI diese Arbeit auch?

PrivatAI setzt offene Modelle ein (u. a. GPT-OSS-120B und GLM-5.2), die für Analyse-Aufgaben deutlich weniger restriktiv sind. Eine Garantie, dass jede beliebige Anfrage beantwortet wird, ist das nicht – aber es ist die Modellklasse, auf die Sicherheitsteams ausweichen, wenn die kommerziellen Anbieter blocken.

Was passiert mit unseren Vorfallsdaten?

Verarbeitet, beantwortet, verworfen. Keine Inhalts-Logs, kein Training, kein Datenbestand. In einem Incident ist genau das der Punkt: Ihre Breach-Artefakte werden nicht zu den Logs eines anderen Unternehmens.

Können wir PrivatAI in SIEM oder SOAR einbinden?

Ja, über die OpenAI-kompatible API. Alles, was heute gegen die OpenAI-Schnittstelle läuft – Anreicherung von Alerts, Triage-Unterstützung, Report-Generierung – lässt sich durch Austausch von Endpunkt und Schlüssel umstellen.

Hilft das bei NIS2?

Mittelbar. NIS2 verlangt Risikomanagement, Meldeprozesse und die Bewertung von Lieferkettenrisiken. PrivatAI beschleunigt die Dokumentationsarbeit und ist als Dienstleister selbst prüfbar – AVV, TOM und Unterauftragsverarbeiter sind öffentlich. Die Pflichten selbst erfüllen Sie, nicht das Werkzeug.

Was kostet PrivatAI?

PrivatAI kostet 30 €/Monat (Essential) oder 60 €/Monat (Professional), jeweils inkl. MwSt.; beide enthalten den Chat und die OpenAI-kompatible API. Für Anforderungen an den Verarbeitungsort gibt es ein Enterprise-Setup mit KI-Inferenz in Deutschland (ab 9.000 €/Monat, zzgl. USt.). Aktuelle Tarife: privatai.com/#preise.

IT-Sicherheit mit PrivatAI – ohne dass Daten die EU verlassen.

Kostenlos starten Kontakt aufnehmen