Ein AI-Security-Team baust du nicht auf, indem du einen Prompt-Filter kaufst und einen Security Engineer zusätzlich auf KI ansetzt. Du brauchst eine kleine Kerngruppe mit klaren Rollen: jemanden, der Regulierung und Risiko steuert, jemanden, der Modelle, Daten und Agenten technisch absichert, und eine feste Verbindung zu Informationssicherheit, Datenschutz und Fachbereichen. Dieser Leitfaden zeigt dir, in welcher Reihenfolge du vorgehst, welche Rollen du zuerst besetzt, welche Kontrollen das Team etablieren muss und wo externe Unterstützung sinnvoll ist.
Kurz gesagt
- Erst Inventar, dann Team: Ohne Überblick über alle KI-Systeme, Agenten und Schatten-KI weißt du nicht, welche Kompetenzen du brauchst.
- Zwei Kernrollen zuerst: ein KI-Security- oder KI-Governance-Verantwortlicher für Regulierung und Risiko, dazu ein AI Security Engineer für Architektur, Tests und Betrieb.
- AI Security ist Teamarbeit: CIO, CTO und CISO setzen Leitplanken, ISB und KI-Beauftragter arbeiten eng abgestimmt, Fachbereiche bleiben eingebunden.
- Kontrollen laufen dauerhaft: Filter, Leitplanken für Agenten, minimale Berechtigungen, Logging und regelmäßiges Red Teaming statt einmaliger Abnahme.
- Gezielt extern ergänzen: Red Teaming oder eine Interim-Leitung kannst du zukaufen, Architekturwissen und Verantwortung gehören ins Haus.
Inhaltsverzeichnis
- Was AI Security abdeckt und warum klassische IT-Sicherheit nicht reicht
- Bestandsaufnahme: Was du schon hast und was fehlt
- Die Rollen im AI-Security-Team
- Zuständigkeiten: Wer mit wem arbeitet
- Kontrollen, die das Team etabliert
- In drei Phasen zum arbeitsfähigen Team
- Intern aufbauen oder extern ergänzen
- Unsere Sicht: Das Profil entscheidet, nicht der Titel
- AI-Security-Talente mit Polydigital finden
- Häufige Fragen zum AI-Security-Team
- Quellen
Was AI Security abdeckt und warum klassische IT-Sicherheit nicht reicht
AI Security schützt KI-Systeme vor Angriffen wie Data Poisoning und Prompt Injection und sichert vertrauliche Daten, Systemintegrität und die Verfügbarkeit von KI-Diensten. So beschreibt es Microsofts Überblick zur KI-Sicherheit. Der Rahmen ist breiter als bei klassischer Anwendungssicherheit: Er reicht über den gesamten KI-Lebenszyklus, von Modellen und Trainingsdaten über Schnittstellen bis zu den Anwendungen, die auf einem Modell aufsetzen.
Drei Punkte unterscheiden KI-Systeme von dem, was dein Security-Team bisher kennt:
- Die Angriffsfläche ist Sprache. Ein Angreifer braucht keinen Exploit, oft genügt ein präparierter Text in einer Mail, einem Dokument oder einer Webseite, den das Modell als Anweisung liest.
- Daten sind Teil des Systems. Wer Trainings- oder Retrieval-Daten manipuliert, verändert das Verhalten des Modells, ohne eine Zeile Code anzufassen.
- Agenten handeln selbst. KI-Agenten treffen eigenständig Entscheidungen und rufen externe Tools auf. Dadurch entstehen neue Angriffswege wie Memory Poisoning oder Tool-Missbrauch.
Hinzu kommt das Tempo. Viele Unternehmen führen KI schneller ein, als ihre Sicherheitsteams sie absichern können. CrowdStrike empfiehlt deshalb, Erkennung und Abwehr auch auf Prompt- und Agenteninteraktionen auszudehnen. Genau diese Lücke schließt ein eigenes AI-Security-Team.
Zur Abgrenzung: AI Safety fragt, ob ein Modell sich so verhält, wie es soll, auch ohne Angreifer. AI Security fragt, ob jemand das System absichtlich missbrauchen, manipulieren oder ausspähen kann. Dein Team braucht beide Perspektiven, sein Kernauftrag ist aber Security.
Bestandsaufnahme: Was du schon hast und was fehlt
Bevor du eine einzige Stelle ausschreibst, klärst du drei Fragen. Die Antworten bestimmen, welche Rollen du brauchst und in welcher Reihenfolge.
Welche KI-Systeme laufen im Unternehmen?
Erstelle ein KI-Inventar. Es umfasst eingekaufte Tools wie Copilots und Chat-Assistenten, selbst gebaute Anwendungen auf Basis großer Sprachmodelle, KI-Funktionen in bestehender Software, etwa im ERP oder CRM, und Agenten, die auf interne Systeme zugreifen. Vergiss die Schatten-KI nicht: Tools, die Teams ohne Freigabe nutzen. Wie du sie systematisch findest, beschreiben wir im Beitrag zu Shadow AI Governance mit Discovery zuerst.
Für jedes System hältst du fest:
- Wer ist fachlich verantwortlich?
- Welche Daten verarbeitet es, darunter personenbezogene oder geschäftskritische?
- Hat es Schreibrechte oder kann es Aktionen auslösen?
- Ist es extern erreichbar, etwa für Kunden?
Welche Risiken sind die dringendsten?
Priorisiere nach Wirkung, nicht nach Technik. Ein interner Assistent ohne Schreibrechte ist ein anderes Risiko als ein Agent, der Bestellungen auslöst oder auf das Kundenportal antwortet. Prüfe außerdem, welche Systeme unter die Risikoklassen des AI Act fallen könnten. Daraus ergibt sich, ob dein erster Engpass eher regulatorisch oder eher technisch ist.
Welche Kompetenzen hast du bereits?
Mach eine ehrliche Skill-Landkarte. Oft gibt es mehr als gedacht: Ein Cloud-Security-Spezialist kennt Identitäten und Netzwerke, ein ML Engineer kennt Modelle und Embeddings, die Datenschutzbeauftragte kennt die DSGVO. Selten vorhanden ist die Verbindung dieser Welten, also jemand, der versteht, wie ein Angriff über einen Prompt bis zu einer Berechtigung im Backend durchschlägt. Genau dort liegt meist die erste Besetzung.
Die Rollen im AI-Security-Team
Ein AI-Security-Team ist in den meisten Unternehmen keine große Abteilung, sondern eine Kerngruppe von zwei bis fünf Personen, die mit bestehenden Teams verzahnt ist. Diese Rollen bilden den Kern:
| Rolle | Schwerpunkt | Typischer Hintergrund | Wann besetzen |
|---|---|---|---|
| KI-Security Manager / AI Governance Officer | Anforderungen aus Gesetz, Normen und Verträgen, Risikobewertung, Richtlinien | Informationssicherheit, ISMS, Compliance | Phase 1 |
| AI Security Engineer | Sichere Architektur, Agenten-Leitplanken, Berechtigungen, Tests | ML Engineering, Plattform- oder Cloud-Security | Phase 1 bis 2 |
| AI Red Teamer | Angriffssimulation, Prompt Injection, Jailbreaks | Penetration Testing, Offensive Security | Phase 2, oft extern |
| MLOps Engineer mit Security-Fokus | Sichere Pipelines, Modell- und Datenversionierung, Monitoring | DevOps, Data Engineering | Phase 2 bis 3 |
| Head of AI Security / fractional Lead | Strategie, Budget, Abstimmung mit CISO und CIO | Security-Führung mit KI-Erfahrung | Bei großen Portfolios oder als Interim |
KI-Security Manager
Die Rolle identifiziert gesetzliche, regulatorische, normative und vertragliche Anforderungen, wirkt an KI-Strategie und Risikobewertung mit und plant und überwacht die KI-Sicherheitsmaßnahmen. So beschreibt es das Berufsbild KI-Security Manager der DGI, dessen Ausbildung KI-Grundlagen, Governance, Risikomanagement sowie AI Act und DSGVO abdeckt. Für dich heißt das: Diese Person braucht kein Machine-Learning-Studium, aber sie muss technische Risiken verstehen und in Entscheidungen übersetzen können.
AI Security Engineer
Der AI Security Engineer ist die technische Schlüsselrolle. Er kennt Modelle und Embeddings ebenso wie Identitäten, Netzwerke und Rechtekonzepte. Gute Kandidatinnen und Kandidaten kommen entweder aus der ML- und Datenentwicklung und haben sich Security angeeignet, oder aus der Plattform- und Cloud-Security und haben sich in KI-Architekturen eingearbeitet. Aufgaben, Skills und Gehaltsrahmen haben wir im Stellenprofil AI Security Engineer zusammengefasst.
Weitere Rollen
Red Teaming und MLOps-Security kommen in der zweiten Ausbaustufe dazu. Eine eigene Führungsrolle lohnt sich, wenn du viele KI-Systeme in mehreren Geschäftsbereichen betreibst. Vorher reicht oft eine erfahrene Führungskraft auf Interim- oder Fractional-Basis, die Struktur aufbaut und an das Stammteam übergibt. Wie sich die Rollen in einen Gesamtplan mit Budget einfügen, zeigt unser Stellenplan für dein AI-Team.
Zuständigkeiten: Wer mit wem arbeitet
Das häufigste Problem ist nicht fehlendes Wissen, sondern unklare Verantwortung. Ein AI-Security-Team, das neben ISB, Datenschutz und Fachbereichen herläuft, erzeugt Doppelarbeit oder Lücken. Regle die Schnittstellen deshalb von Anfang an schriftlich.
Führungsebene. CIO, CTO und CISO haben unterschiedliche Aufgaben: Der CIO sorgt für passende Richtlinien, der CTO verankert disziplinierte Entwicklungsprozesse, der CISO schützt die Betriebsumgebung nach dem Zero-Trust-Prinzip. Booz Allen beschreibt AI Security ausdrücklich als Teamleistung, in der spezialisierte AI Security Engineers ihre Expertise in jede Phase des Lebenszyklus einbringen.
ISB und KI-Beauftragter. Der Informationssicherheitsbeauftragte verantwortet weiter das ISMS. Der KI-Beauftragte oder KI-Security Manager ergänzt ihn für KI-spezifische Risiken, regulatorische Anforderungen und ethische Fragen. Beide sollten eng abgestimmt zusammenarbeiten, etwa mit gemeinsamen Risikoregistern statt zweier paralleler Listen.
Weitere Schnittstellen. KI-Sicherheitsmaßnahmen sind mit Informationssicherheit, Datenschutz, Business Continuity, IT-Compliance und IT-Betrieb abzustimmen. Das gehört laut DGI zum Kern der Rolle. Praktisch bewährt sich:
- Datenschutz: Mitzeichnung bei jedem System mit personenbezogenen Daten.
- Fachbereiche: ein benannter Owner pro KI-System, der fachliche Fehler erkennt und Freigaben verantwortet.
- Data- und AI-Team: Security-Review als fester Schritt im Entwicklungsprozess, nicht als Abnahme am Ende.
- Betriebsrat: frühe Einbindung, wenn Systeme Leistung oder Verhalten von Beschäftigten berühren. Welche Rollen du dafür zuerst brauchst, steht im Beitrag zur KI-Einführung mit dem Betriebsrat.
Eine einfache RACI-Matrix pro KI-System genügt am Anfang. Wichtig ist, dass jeder Agent einen Menschen hat, der für ihn einsteht.
Kontrollen, die das Team etabliert
Die Arbeit eines AI-Security-Teams zeigt sich in Kontrollen, die dauerhaft laufen. Microsoft nennt in seiner Anleitung zu sicheren agentischen KI-Systemen unter anderem Eingabe- und Ausgabefilter, Laufzeit-Leitplanken für Agenten, kontinuierliche Tests und Red Teaming, Protokollierung und Überwachung sowie eingeschränkte Berechtigungen. Entscheidungen, Agentenpläne und Toolaufrufe sollen nachvollziehbar dokumentiert sein.
Daraus ergibt sich ein Kontrollset, das du schrittweise aufbaust:
- Minimale Berechtigungen: Jeder Agent bekommt nur die Rechte, die er für seine Aufgabe braucht, mit eigener Identität statt geteilter Service-Accounts.
- Eingabe- und Ausgabefilter: Erkennen von Prompt Injection, Blockieren sensibler Daten in Antworten.
- Leitplanken zur Laufzeit: Freigabeschritte für kritische Aktionen, Limits für Toolaufrufe, Abbruch bei unerwartetem Verhalten.
- Logging und Monitoring: Prompts, Antworten, Toolaufrufe und Entscheidungen werden protokolliert und an das bestehende Security-Monitoring angebunden.
- Red Teaming: Gezielte Angriffe auf die eigenen Systeme. Solche Tests decken laut CrowdStrike Risiken wie Prompt Injection, Jailbreaks, Data Poisoning und übermäßige Befugnisse auf.
- Menschliche Aufsicht: Klare Regeln, wann ein Mensch prüft und eingreift. Was der AI Act dazu verlangt, erklären wir im Beitrag zu Human Oversight nach Art. 14 AI Act.
Zwei Grundsätze halten das System zusammen. Erstens „Secure by Design“: Die Leitlinien des britischen NCSC und internationaler Partner verlangen Sicherheit als Kernanforderung über den gesamten Lebenszyklus, von Design über Entwicklung und Bereitstellung bis zum Betrieb. Zweitens Kontinuität: Die Forschung zu KI-Sicherheit entwickelt sich schnell, deshalb rät der Bitkom-Leitfaden KI & Informationssicherheit zu regelmäßigen Sicherheitsbewertungen mit Angriffssimulationen statt einmaliger Tests.
In drei Phasen zum arbeitsfähigen Team
Ein realistischer Fahrplan orientiert sich an einem 90-Tage-Rhythmus, wie ihn auch Leitfäden zur KI-Governance vorschlagen: Inventar und Rollen zuerst, dann Risikoklassifikation und Freigabeprozess, schließlich ein Steuerungsgremium. Für das Security-Team sieht das so aus:
Phase 1: Fundament (ungefähr Tag 1 bis 30)
- KI-Inventar starten, Schatten-KI erfassen.
- Verantwortliche Person für KI-Security benennen, intern oder interim.
- Sofortmaßnahmen für die riskantesten Systeme: Rechte reduzieren, Logging einschalten.
- Schnittstellen zu ISB, Datenschutz und Fachbereichen festlegen.
Phase 2: Struktur (ungefähr Tag 31 bis 60)
- Risikoklassifikation aller Systeme, inklusive AI-Act-Einordnung.
- KI-Richtlinie und Freigabeprozess für neue KI-Anwendungen verabschieden.
- AI Security Engineer an Bord holen oder Suche starten.
- Erstes Red Teaming für die kritischsten Anwendungen beauftragen.
Phase 3: Betrieb (ungefähr Tag 61 bis 90)
- Governance Board einrichten, das Freigaben und Risiken regelmäßig bewertet.
- Security-Review fest in den Entwicklungsprozess integrieren.
- Rollenbasierte Schulungen für Entwicklerteams, Fachbereiche und Führungskräfte.
- Kennzahlen definieren, etwa Anteil der Systeme mit Owner, offene Findings aus Red Teaming, Zeit bis zur Freigabe.
Plane die Personalsuche parallel zu Phase 1, nicht danach. Spezialisierte KI-Rollen sind schwer zu besetzen. Welche Fristen realistisch sind und wo du ansetzt, findest du im Beitrag zur Besetzungsdauer von KI-Rollen.
Intern aufbauen oder extern ergänzen
Nicht jede Fähigkeit muss fest im Team sitzen. Entscheidend ist, was dauerhaft Wissen über deine Systeme braucht und was punktuell anfällt.
| Fähigkeit | Intern | Extern | Unsere Empfehlung |
|---|---|---|---|
| Verantwortung und Risikosteuerung | Pflicht | nur zur Überbrückung | Intern, bei Bedarf zunächst interim |
| Sichere Architektur und Agenten-Leitplanken | stark empfohlen | zum Start möglich | Intern, weil Wissen über eigene Systeme zählt |
| Red Teaming | ab großem Portfolio | gut geeignet | Extern, regelmäßig wiederholt |
| Regulatorische Spezialfragen | Grundwissen | für Einzelfragen | Intern Grundlagen, extern Rechtsberatung |
| Schulungen | Inhalte intern verankern | Konzeption möglich | Gemischt |
Die Faustregel: Verantwortung lässt sich nicht auslagern. Wer für einen Agenten einsteht, muss im Unternehmen sitzen oder als Interim-Lead klar beauftragt sein, mit einer Übergabe an das Stammteam. Dienstleister sind stark bei Tests und Spitzen, schwach beim täglichen Wissen über deine Datenflüsse.
Unsere Sicht: Das Profil entscheidet, nicht der Titel
Wir sehen in vielen Gesprächen mit IT-Leitungen dasselbe Muster: Die Stelle heißt „AI Security Engineer“, gesucht wird aber eigentlich ein klassischer Penetration Tester oder ein ML Engineer mit etwas Security-Interesse. Beides greift zu kurz. Die Rolle lebt davon, dass jemand zwischen Fachwissen und Technologie zu Hause ist: Er versteht, wie ein Modell Kontext verarbeitet, und zugleich, welche Berechtigung im Backend daraus folgt.
Darum prüfen wir bei jeder Besetzung drei Dinge, die in keinem Lebenslauf stehen. Setzt die Person KI souverän ein, auch im eigenen Arbeitsalltag? Kann sie die Ergebnisse von KI kritisch beurteilen, statt ihnen zu vertrauen? Und steht sie für das Resultat ein, auch wenn ein Agent nachts etwas Unerwartetes tut? Gerade in der Security entscheidet diese Haltung über die Qualität des Teams.
Unser Rat für den Start: Besetze lieber eine wirklich passende Person als drei halbe. Ein starker AI Security Engineer mit einer klaren Governance-Rolle an seiner Seite bringt mehr als ein großes Team ohne gemeinsame Verantwortung.
— Ingmar
AI-Security-Talente mit Polydigital finden
Wir besetzen AI Security Engineers, AI Governance Officers, MLOps Engineers und Führungsrollen wie Head of AI oder fractional CAIO, in Festanstellung, als Interim-Mandat oder fractional. Du bekommst wenige, gründlich geprüfte Profile. Jedes Talent interviewen wir persönlich, und in der Endauswahl durchläuft jede Kandidatin und jeder Kandidat eine EFPA-zertifizierte Eignungsdiagnostik, die ein zertifizierter Berater bei uns auswertet.
Wenn du vor der Suche klären willst, welche Rolle du zuerst brauchst, unterstützen wir dich auch mit Rollenberatung. → Data- und AI-Experten mit Polydigital finden
Häufige Fragen zum AI-Security-Team
Wie groß sollte ein AI-Security-Team am Anfang sein?
Für die meisten mittelständischen Unternehmen reichen zu Beginn zwei Kernrollen: eine verantwortliche Person für KI-Security und Governance sowie ein AI Security Engineer. Beide arbeiten eng mit ISB, Datenschutz und dem Data-Team zusammen. Ausbauen solltest du, wenn die Zahl der Agenten und externen KI-Anwendungen wächst.
Kann unser bestehendes IT-Security-Team AI Security mit übernehmen?
Teilweise. Identitäten, Netzwerke, Monitoring und Incident Response bleiben beim bestehenden Team. Prompt Injection, Data Poisoning und die Absicherung autonomer Agenten erfordern aber zusätzliches Wissen über Modelle und Datenflüsse, das du gezielt aufbauen oder einstellen musst.
Welche Rolle sollten wir zuerst besetzen?
Das hängt von deinem Engpass ab. Ist unklar, welche Systeme unter den AI Act fallen und wer verantwortlich ist, beginnst du mit der Governance-Rolle. Laufen bereits Agenten mit Schreibrechten in Produktion, hat der AI Security Engineer Vorrang.
Lohnt sich eine Interim-Besetzung für AI Security?
Ja, wenn du schnell handlungsfähig sein musst und die Festanstellung noch läuft. Eine Interim- oder Fractional-Führungskraft baut Inventar, Richtlinien und Prozesse auf und übergibt sie dann an das Stammteam. Wichtig ist eine klar geregelte Übergabe, damit das Wissen im Unternehmen bleibt.
Quellen
- Microsoft: Was ist KI-Sicherheit?
- Cloudflare: Was ist KI-Sicherheit?
- CrowdStrike: Sicherung von KI-Systemen, Leitfaden für Security-Verantwortliche
- DGI: KI-Security Manager
- Booz Allen: Securing AI
- NESEC: KI-Governance und KI-Riskmanagement
- Microsoft Learn: Sichere autonome agentische KI-Systeme
- NCSC: Guidelines for secure AI system development
- Bitkom: Leitfaden KI & Informationssicherheit