Warum ich angefangen habe, KI selbst zu bauen

2023 war das Jahr, in dem alle plötzlich über KI redeten.

Meine Kunden redeten darüber. Meine Kollegen redeten darüber. LinkedIn war voll davon. Und ich saß in Incident-Response-Einsätzen, in Forensik-Analysen, in Risikobeurteilungen, und fragte mich: Was davon ist echt, und was ist Rauschen?

Ich bin seit über zwanzig Jahren in der IT-Sicherheit. Ich habe Ransomware-Angriffe analysiert, DSGVO-Projekte durch bürokratische Dickichte geführt, und ich war früh dabei, als Cloud noch ein Fremdwort war. Ich bin kein Early Adopter aus Prinzip. Ich bin jemand, der fragt: Löst das ein echtes Problem?

Also habe ich angefangen, selbst auszuprobieren.

Zuerst: anderen zuhören

Bevor ich eine einzige Zeile Code geschrieben habe, habe ich zugehört.

Nicht den großen Tech-Medien, die jeden Monat eine neue KI-Revolution ausrufen. Sondern Leuten, die konkret arbeiten und konkret denken. David Shapiro, der sich ernsthaft mit KI-Alignment und dem beschäftigt, was diese Systeme eigentlich sind. "All About AI" für den praktischen Blick auf neue Modelle und Tools. Daniel Miesslers Unsupervised Learning, weil er Security und KI zusammendenkt, und nicht so tut, als wären es zwei getrennte Welten.

Das war meine Schule, bevor es eine formale Schule gab.

Im April 2024 habe ich dann Geld in die Hand genommen: Clint Bodungens Mastering AI for Cybersecurity. Bodungen kommt aus der ICS/SCADA-Security, kennt die Realität kritischer Infrastrukturen, und er denkt nicht in Demos, er denkt in Anwendungsfällen. Der Kurs war teuer. Er war es wert. Nicht weil er mir alles beigebracht hat, was ich weiß. Sondern weil er meinen Blick strukturiert hat: Was kann KI in Security-Workflows leisten, und wo fängt der Unsinn an?

Die erste Frage war nicht technisch

Parallel dazu hatte ich eine Frage, die mich nicht losließ: Kann ich einem KI-Modell vertrauen, wenn es um Sicherheitsthemen geht?

Als Threat Hunter sehe ich täglich, wie Angreifer Systeme ausnutzen, die nicht für ihre tatsächliche Nutzung durchdacht wurden. Die Frage war also: Wenn ich KI in meinen Workflow einbaue, als Analyse-Werkzeug, als Recherche-Assistent, als Zusammenfassungs-Maschine, welche Risiken bring ich damit rein?

Die Antwort war: Mehr als die meisten Kollegen dachten. Aber auch weniger als die Pessimisten sagten.

Ich musste das selbst herausfinden. Dafür musste ich verstehen, wie diese Dinge funktionieren. Nicht auf Paper-Niveau. Auf Hands-on-Niveau.

Kleine Schritte, konkrete Probleme

Ich habe nicht mit einer großen Architektur angefangen. Ich habe mit einem Problem angefangen, das ich tatsächlich hatte.

Problem 1: Ich verbrachte zu viel Zeit damit, lange Sicherheitsberichte zusammenzufassen, für Kunden, die keine Zeit haben, 40 Seiten zu lesen.

Lösung: Ein Python-Skript, das Dokumente an Claude schickt und eine Zusammenfassung als DOCX und HTML zurückliefert. Vielleicht dreißig Zeilen Code.

Das war claude_call.py, das erste Skript in meinem myscripts-Repository. Unspektakulär. Aber es hat funktioniert. Und es hat mir gezeigt, was möglich ist, wenn man die API direkt anspricht statt über eine Chat-Oberfläche.

Problem 2: Ich wollte verstehen, wie Chatbot-Interaktion funktioniert, nicht als Nutzer, sondern als jemand, der solche Systeme beurteilen soll.

Lösung: Ein Terminal-Chatbot mit der Groq-API. Wieder einfach. Wieder lehrreich. Groq war damals für seine Geschwindigkeit bekannt, Inferenz in einem Tempo, das sich anders anfühlte als alles andere.

Was mich wirklich interessiert hat

Irgendwann kam das dritte Skript: MP3-Transkription mit anschließender Fachanalyse.

Ich hatte Aufnahmen von Sicherheits-Briefings. Lange Aufnahmen. Statt sie noch einmal abzuhören, ließ ich ein Modell transkribieren und das Ergebnis analysieren. Das war der Moment, in dem ich aufgehört habe, KI als Spielzeug zu betrachten.

Nicht weil es magisch war, sondern weil es die richtige Aufgabe für das richtige Werkzeug war.

Kurz danach habe ich angefangen, mit MITRE ATT&CK-Daten zu arbeiten. Ich wollte wissen: Kann ein Modell aus einem Sicherheitsszenario automatisch die relevanten TTPs extrahieren? Kann ich damit Threat-Intelligence-Arbeit beschleunigen, ohne die Qualität zu opfern?

Die Antwort war: Ja, mit Einschränkungen. Das Modell findet Muster gut. Aber es weiß nicht, was es nicht weiß. Es gibt keine Unsicherheit zurück, es gibt eine Antwort. Das ist der Unterschied zwischen einem Werkzeug und einem Kollegen. Und die Einschränkungen zu verstehen ist mindestens so wichtig wie die Fähigkeiten.

Was ich gelernt habe, und was nicht

Nach diesen ersten Experimenten wusste ich drei Dinge:

Erstens: KI ist kein Alleskönner. Sie halluziniert. Sie übersieht Kontext. Sie ist so gut wie die Frage, die man stellt. Das ist kein Argument gegen KI, das ist ein Argument für Kompetenz beim Einsatz.

Zweitens: Der direkte API-Zugang ist der Unterschied zwischen einem Werkzeug und einer Black Box. Wer nur Chat-Oberflächen nutzt, versteht nicht, was passiert. Und wer es in sicherheitskritischen Kontexten einsetzt ohne zu verstehen, was passiert, hat ein Problem, auch wenn es lange gut geht.

Drittens: Lokale Modelle sind für Security-Leute keine Nische. Sie sind eine Notwendigkeit. Wenn ich Forensik-Daten analysiere oder interne Bedrohungsszenarien bearbeite, gehören diese Daten nicht in die Cloud eines amerikanischen Hyperscalers. Dazu mehr in Episode 2.

Warum ich das hier erzähle

Ich schreibe diese Serie nicht, um zu zeigen, wie clever ich bin.

Ich schreibe sie, weil ich in meiner täglichen Arbeit, in Beratungen, in Audits, in Gesprächen mit Führungskräften, immer wieder dasselbe sehe: Entweder wird KI unkritisch eingesetzt, oder sie wird aus Angst gar nicht eingesetzt.

Beides ist falsch. Beides entsteht aus mangelndem Verständnis.

Mein Weg war: zuhören, lernen, klein anfangen, konkrete Probleme lösen, verstehen was passiert, und dann skalieren. Nicht umgekehrt.

Das ist kein Erfolgsrezept. Es ist eine Haltung.