KI-Sicherheit Unternehmen: 30-Tage-Plan für Startups 2026

Inhalt dieses Artikels

Wenn ihr KI produktiv einsetzt, wird KI-Sicherheit im Unternehmen schnell zur Frage der Organisation und nicht der Technik. Gerade in Startups entstehen KI-Workflows dezentral: Texte im Marketing, Code-Vorschläge in der Entwicklung, Support-Antworten, interne Wissenssuche oder Agenten mit Zugriff auf eure Tools. Was dabei oft fehlt, sind klare Verantwortlichkeiten und Grenzen.

Die Lage lässt sich nüchtern einordnen. Laut KI-Sicherheitsstudie 2026 prüfen 67 % der Unternehmen kritische KI-Ergebnisse menschlich, 52 % testen vor dem Einsatz und 40 % protokollieren oder überwachen die KI-Nutzung. Das ist ein brauchbarer Maßstab für eure eigenen Minimalstandards. Bei KI-Agenten sorgen sich 84 % um falsche Entscheidungen und 78 % um Daten- oder Geheimnisabfluss. Dieser Artikel übersetzt genau diese Risiken in eine umsetzbare Reihenfolge für die ersten 30 Tage.

Quellen: KI-Sicherheitsstudie 2026 (BSI und TÜV-Verband)

Inhaltsverzeichnis

• Was geschützt werden muss und was davon zu trennen ist
• Die Risiken mit der größten Relevanz für kleine Teams
• Der 30-Minuten-Start vor jedem neuen Workflow
• Der 30-Tage-Plan: Überblick, Kontrolle, Test
• Fünf Alltagsszenarien und die passende Kontrolle
• Harte Grenzen für autonome Aktionen
• Wenn fremde Inhalte die KI steuern sollen
• Vier Kennzahlen für den monatlichen Check
• Fazit

1. Was geschützt werden muss und was davon zu trennen ist

KI-Sicherheit umfasst alle Maßnahmen, die verhindern oder begrenzen, dass KI-Systeme Daten offenlegen, manipulierte Inhalte übernehmen, falsche Ergebnisse ungeprüft in Geschäftsprozesse bringen oder mit zu vielen Rechten schädliche Aktionen ausführen. Das ist mehr als Datenschutz und mehr als ein sicherer Login.

Thema	Kernfrage	Beispiel	Warum es allein nicht genügt
AI Literacy	Verstehen Mitarbeitende Grenzen und typische Fehler?	Team erkennt Halluzinationen und meldet Auffälligkeiten	Schulung ohne technische Begrenzung verhindert keinen Datenabfluss
KI-Richtlinie	Welche Tools und Daten sind erlaubt?	Keine privaten KI-Konten für Arbeitsdaten	Eine Richtlinie ohne Alltagstest wird umgangen
IT-Sicherheit	Sind Konten, Geräte, APIs und Zugänge geschützt?	MFA und zentrale Verwaltung von API-Schlüsseln	Ein sicheres Konto verhindert keine falsche KI-Antwort
Datenschutz	Dürfen personenbezogene Daten so verarbeitet werden?	Zweck, Rechtsgrundlage und Anbieterprüfung klären	Rechtliche Zulässigkeit ersetzt keine Qualitätsprüfung

Die vier Bereiche greifen ineinander. Die EU-KI-Verordnung verlangt zudem ausreichende KI-Kompetenz bei Mitarbeitenden und beauftragten Personen. Für kleine Teams heißt das mindestens eine risikobezogene Unterweisung zu erlaubten Daten, Prüfpflichten und Meldewegen.

Quellen: EU-KI-Verordnung (Verordnung 2024/1689)

2. Die Risiken mit der größten Relevanz für kleine Teams

Statt einer langen Bedrohungsliste helfen fünf realistische Fälle:

• Datenabfluss: Kundendaten, Finanzzahlen, Roadmaps, Quellcode oder HR-Informationen landen in einem nicht freigegebenen Tool.
• Qualitätsfehler: Plausible, aber falsche Aussagen, unsicherer Code oder falsche Support-Zusagen werden übernommen.
• Berechtigungsfehler: Ein Agent kann mehr lesen, ändern oder versenden, als seine Aufgabe verlangt.
• Manipulierte Eingaben: Externe Inhalte beeinflussen das Verhalten eines angeschlossenen Modells.
• Schatten-KI: Mitarbeitende nutzen private Accounts oder ungeprüfte Browser-Erweiterungen außerhalb der Regeln.

Priorisiert diese Fälle über drei Fragen: Wie hoch ist der mögliche Schaden? Wie wahrscheinlich ist der Fehler? Lässt er sich rückgängig machen? Ein falscher Entwurf für einen Social-Post ist anders zu bewerten als eine falsche CRM-Änderung oder eine versendete Vertragszusage. Das BSI zählt Datenabfluss, unzuverlässige Ausgaben und Prompt Injections zu den zentralen Risiken generativer KI und empfiehlt, Ein- und Ausgaben zu prüfen sowie Folgeaktionen vor der Ausführung kontrollierbar zu machen.

Quellen: BSI: Generative KI-Modelle, Chancen und Risiken

3. Der 30-Minuten-Start vor jedem neuen Workflow

Die KI-Risikoanalyse vor jeder Tool-Freigabe ist kein Compliance-Projekt, sondern eine kurze Pflicht. Fünf Fragen reichen:

1. Welche Daten gehen in das System: öffentlich, intern, vertraulich oder besonders sensibel?
2. Erzeugt die KI nur einen Vorschlag oder löst sie eine echte Aktion aus?
3. Welche Systeme, Dateien, E-Mails oder APIs darf sie lesen oder verändern?
4. Wer prüft Ergebnis und Folgeaktion, und zu welchem Zeitpunkt?
5. Was ist der Fallback, wenn das Ergebnis falsch, manipuliert oder nicht verfügbar ist?

Daraus folgt eine dreistufige Entscheidung. Grün steht für unkritische, öffentliche Inhalte ohne externe Aktion, hier genügt eine Stichprobenkontrolle. Gelb umfasst interne Informationen oder vorbereitende Vorschläge mit verpflichtender Prüfung vor der Nutzung. Rot betrifft personenbezogene, vertrauliche oder finanzielle Informationen sowie irreversible Aktionen, erlaubt nur mit klarer Verantwortlichkeit, enger Berechtigung und dokumentierter Freigabe.

Das Ergebnis ist ein zentrales KI-Inventar mit Tool oder Workflow, Zweck, verantwortlicher Person, Datenklasse, verbundenen Systemen, Risikostufe und Freigabestatus. Diese eine Tabelle ersetzt später viele Diskussionen.

4. Der 30-Tage-Plan: Erst Überblick, dann Kontrolle, dann Test

Tage 1 bis 5: Bestand und Verantwortliche festlegen

Erfasst alle genutzten KI-Tools: Web-Tools, APIs, Browser-Erweiterungen, Copilots, Bots und Agenten. Benennt pro Eintrag einen Owner. Ohne Owner gibt es keine produktive Nutzung. Setzt ausschließlich geschäftliche, freigegebene Konten ein, private Logins sind für Arbeitsdaten tabu. Haltet eine Minimalregel schriftlich fest: keine Zugangsdaten, geheimen Schlüssel, unveröffentlichten Kundendaten, Personaldaten oder Vertragsinhalte in nicht freigegebene Tools.

Tage 6 bis 10: Daten und Anbieter prüfen

Führt vier Datenklassen ein: öffentlich, intern, vertraulich, besonders sensibel. Für den Vendor-Check klärt ihr: Wo werden Daten verarbeitet und gespeichert? Werden Eingaben oder Ausgaben für Training verwendet, und lässt sich das vertraglich oder technisch deaktivieren? Welche Subprozessoren wirken mit? Welche Lösch-, Export- und Zugriffsmöglichkeiten bestehen? Ist bei personenbezogenen Daten eine passende vertragliche und datenschutzrechtliche Grundlage nötig?

Wichtig: Das Entfernen von Namen macht Daten nicht automatisch anonym, auch Kontextdaten können Personen identifizierbar machen. Bei individuellen Datenschutz- oder Vertragsfragen holt ihr euch fachkundige Beratung.

Quellen: DSK-Orientierungshilfe KI und Datenschutz

Tage 11 bis 15: Zugriffe klein halten

Least Privilege heißt: Menschen und Agenten erhalten nur die Rechte, die für eine klar definierte Aufgabe nötig sind. Verwaltet API-Schlüssel zentral und hinterlegt sie nicht in Prompts, Code-Repositories oder geteilten Dokumenten. Passt Zugänge bei Rollenwechsel und Austritt sofort an. Trennt Testumgebungen von Produktivdaten und Live-Systemen. Agenten bekommen zunächst nur lesenden Zugriff, Schreibrechte erst nach dokumentiertem Test und mit klarer Begrenzung.

Tage 16 bis 20: Nachvollziehbarkeit und Human Review einführen

Logs sind nachvollziehbare Protokolle von Toolzugriffen, relevanten Eingaben, Tool-Aufrufen, Aktionen, Fehlermeldungen, Eskalationen und menschlichen Freigaben. Human Review ist die verbindliche menschliche Prüfung, bevor ein risikoreiches Ergebnis veröffentlicht, versendet oder umgesetzt wird. Nutzt dieselben Stufen wie in der Risikoanalyse: Grün gleich Stichprobe, Gelb gleich Prüfung vor Nutzung, Rot gleich Zwei-Augen-Freigabe. Entscheidend ist, dass die Prüfung fachlich sinnvoll ist. Wer freigibt, braucht Kontext, Zugriff auf die Quelle und die Befugnis, den Vorgang zu stoppen.

Tage 21 bis 25: Vorfall und Ausfall planen

Definiert Incident Response als festen Ablauf: Vorfall melden, Workflow oder Zugriff stoppen, relevante Logs und Belege sichern, Schaden bewerten, betroffene Personen intern informieren, Ursache beheben, Regeln aktualisieren. Dazu gehört ein niedrigschwelliger Meldekanal, etwa ein eindeutiger Chat-Kanal oder ein kurzes Formular. Ergänzt einen Fallback-Prozess: den manuellen oder alternativen Weg, wenn der KI-Workflow ausfällt, fragwürdige Ergebnisse liefert oder gestoppt wird.

Tage 26 bis 30: Testen und nachschärfen

Führt einen kurzen Testfall durch. Zum Beispiel: Ein Support-Bot erhält eine manipulierte Anfrage, oder ein Agent schlägt eine falsche CRM-Änderung vor. Prüft anschließend: Wurde der Fehler erkannt? Konnte niemand ohne Freigabe handeln? Waren die Logs auffindbar? Funktionierte der Fallback? Das BSI empfiehlt Tests vor der Einführung sowie risikobasierte Red-Teaming-Übungen, um Schwachstellen vor dem Produktiveinsatz sichtbar zu machen.

Quellen: BSI: Generative KI-Modelle, Chancen und Risiken

5. Fünf Alltagsszenarien und die passende Kontrolle

Einsatz	Sinnvoller Rahmen	Pflichtkontrolle
ChatGPT im Marketing	Ideen, Gliederungen, Varianten für öffentliche Inhalte	Keine unveröffentlichten Kunden- oder Vertragsdaten, fachliche Endprüfung vor Veröffentlichung
Copilot im Code	Boilerplate, Tests, Doku, Refactoring-Vorschläge	Code Review, Tests und Secret-Scan, keine Zugangsdaten in Prompts oder Repos
Support-Bot	Standardfragen und Vorsortierung	Begrenzter Antwortumfang, Eskalation bei Preis-, Vertrags- und Datenschutzfragen, kritische Gespräche protokollieren
Interner Wissensassistent	Suche in freigegebenen Richtlinien und Prozessdokumenten	Ursprungsrechte übernehmen, Quellen sichtbar machen, kein pauschaler Zugriff auf HR-, Rechts- oder Finanzdokumente
KI-Agent mit externen Tools	Mehrstufige Aufgaben mit Tool-Aufrufen	Testumgebung, zuerst Leserechte, Aktionslimits, Freigabe vor externer Wirkung

Bei der KI-Agenten Sicherheit gilt: Das Risiko steigt nicht durch das Wort Agent, sondern durch die Kombination aus unzuverlässiger Ausgabe, externen Inhalten, Tool-Zugriffen und weitreichenden Berechtigungen. Ein Agent, der nur lesen und vorschlagen darf, ist überschaubar. Ein Agent mit Schreibrechten in CRM, Postfach und Zahlungssystem ist eine Betriebsentscheidung, die ihr bewusst treffen solltet.

6. Harte Grenzen für autonome Aktionen

Ohne ausdrückliche menschliche Freigabe darf eine KI:

• keine Zahlungen, Rückerstattungen oder Bankdatenänderungen auslösen
• keine Löschungen in Produktivsystemen durchführen
• keine CRM-Änderungen mit Vertrags-, Preis-, Eigentums- oder Kundenstatuswirkung vornehmen
• keine rechtsverbindlichen Angebote, Kündigungen oder Vertragszusagen versenden
• keine sensible HR-, Gesundheits- oder Rechtskommunikation versenden
• keine Admin-Rechte, API-Zugänge oder externen Freigaben vergeben

Auch unterhalb dieser Schwelle helfen Empfängerlisten, Ausgabenlimits, erlaubte Aktionsarten und Eskalationsschwellen. OWASP beschreibt das Risiko Excessive Agency: Schaden entsteht vor allem durch zu viele Funktionen, zu breite Berechtigungen oder zu viel Autonomie. Folgenreiche Aktionen brauchen eine unabhängige Bestätigung.

Quellen: OWASP: Excessive Agency (LLM06:2025)

7. Wenn fremde Inhalte die KI steuern sollen

Prompt Injection bedeutet: Bösartige Anweisungen in einer Eingabe bringen das Modell dazu, seine eigentliche Aufgabe oder seine Regeln zu ignorieren. Das relevante Startup-Szenario ist alltäglich. Ein Agent liest eine E-Mail, eine Webseite oder ein Dokument. Darin steht sichtbar oder versteckt die Anweisung, Daten weiterzugeben oder ein Tool auszuführen. Weil der Agent externe Inhalte verarbeitet und zugleich Zugriff auf Postfach, Dateien oder andere Tools hat, kann daraus eine reale Folgeaktion entstehen.

Die Schutzregeln sind überschaubar:

• Externe Inhalte grundsätzlich als nicht vertrauenswürdig behandeln.
• Anweisungen, externe Inhalte und Zugangsdaten beziehungsweise Tokens so weit wie möglich trennen.
• Geheimnisse nicht in den Kontext laden, wenn sie für die Aufgabe nicht nötig sind.
• Nur eng begrenzte Tool-Aufrufe erlauben und kritische Aktionen bestätigen lassen.
• Manipulationsversuche im Test gezielt simulieren.

Ein System-Prompt allein ist keine belastbare Sicherheitsgrenze. Das BSI warnt ausdrücklich vor indirekten Prompt Injections, sobald Sprachmodelle an Dokumente, Webseiten, Programmierumgebungen oder E-Mail-Postfächer angebunden werden.

Quellen: BSI-Cybersicherheitswarnung zu indirekten Prompt Injections

8. Vier Kennzahlen für den monatlichen 30-Minuten-Check

Plant einen kurzen monatlichen Review ein, zusätzlich einen Check vor dem Go-live eines neuen Agenten oder vor jeder Berechtigungserweiterung. Vier Messgrößen genügen:

• Review-Quote: Anteil der als Gelb oder Rot eingestuften KI-Ergebnisse, die vor Nutzung dokumentiert geprüft wurden.
• Vorfallkategorien: Anzahl und Art gemeldeter Daten-, Qualitäts-, Rechte-, Manipulations- und Verfügbarkeitsvorfälle.
• Time-to-Detect: Zeit vom Auftreten bis zur Entdeckung eines Vorfalls.
• Fallback-Nutzung: Wie oft ein Team auf den manuellen oder alternativen Prozess wechseln musste.

Optional kommt eine fünfte Kennzahl dazu: der Anteil inventarisierter und freigegebener KI-Tools gegenüber allen tatsächlich genutzten Tools. Sie zeigt euch, wie groß eure Schatten-KI wirklich ist.

FAQ

Was bedeutet KI-Sicherheit im Unternehmen konkret?

Es geht darum, Daten, Zugriffe, KI-Ausgaben und daraus folgende Aktionen kontrollierbar zu halten. Praktisch heißt das: Inventar mit Owner, Datenklassen, minimale Rechte, Logs, menschliche Prüfung bei kritischen Ergebnissen und ein getesteter Notfallweg.

Braucht ein kleines Startup wirklich eine KI-Richtlinie?

Ja, aber sie muss nicht lang sein. Eine Seite mit erlaubten Tools, verbotenen Datenarten, Freigaberegeln und Meldeweg reicht für den Start. Wichtig ist, dass sie im Alltag funktioniert und nicht umgangen wird.

Wie sicher sind KI-Agenten mit Tool-Zugriff?

Das hängt an den Berechtigungen. Lesender Zugriff mit menschlicher Freigabe vor jeder externen Wirkung ist gut beherrschbar. Breite Schreibrechte in Produktivsystemen sind das eigentliche Risiko, nicht der Agent selbst.

Was tun wir bei einem KI-Vorfall?

Workflow oder Zugriff stoppen, Logs und Belege sichern, Schaden bewerten, intern informieren, Ursache beheben und die Regeln anpassen. Legt vorher fest, wer den Stopp auslösen darf.

Fazit

Euer Mindeststandard passt auf eine Checkliste: Tool mit Owner, Datenklasse, Vendor-Check, minimale Rechte, Logs, Human Review, Incident-Meldung, Fallback und begrenzte Agentenautonomie. Gute KI-Sicherheit im Unternehmen bremst euch nicht. Sie macht den KI-Einsatz belastbar genug, um Marketing, Support, Produkt und interne Abläufe schrittweise zu erweitern.

Pro-Tipp: Legt das KI-Inventar als einfache Tabelle an und koppelt jede Berechtigungserweiterung an einen kurzen Testfall. Erst wenn ein Team Fehler erkennen, stoppen und rückgängig machen kann, ist ein KI-Workflow wirklich produktionsreif.

Transparenzhinweis: Dieser Beitrag wurde unter Zuhilfenahme künstlicher Intelligenz erstellt und vor der Veröffentlichung redaktionell geprüft. Alle Zahlen und Angaben wurden gegen die im Text verlinkten Primärquellen abgeglichen.