KI kann Softwareprojekte schneller machen. Gleichzeitig bringt sie Risiken mit, die klassische Entwicklungsprozesse nicht immer abdecken. Wer KI unkontrolliert in Code, Support, Dokumentation oder Geschäftsprozesse integriert, kann Datenschutzprobleme, Sicherheitslücken und schwer nachvollziehbare Entscheidungen erzeugen.
Das Ziel ist nicht, KI zu vermeiden. Das Ziel ist, KI professionell zu kontrollieren. Genau wie Cloud, Open Source oder Zahlungsanbieter braucht auch KI klare Regeln, Verantwortlichkeiten und technische Schutzmaßnahmen.
Die wichtigsten Risikokategorien
1. Datenschutz und sensible Informationen
Viele KI-Risiken beginnen mit Daten. Entwickler kopieren Logs, Kundendaten, Datenbankschemas oder interne Dokumente in Tools, ohne zu prüfen, ob das erlaubt ist. Auch scheinbar harmlose Prompts können sensible Informationen enthalten.
Unternehmen brauchen deshalb klare Regeln:
- Welche Daten dürfen in externe Tools?
- Welche Daten müssen anonymisiert werden?
- Welche Systeme brauchen lokale oder EU-basierte Verarbeitung?
- Wer darf Modellanbieter konfigurieren?
- Wie werden Prompts und Outputs protokolliert?
Bei sensiblen Daten kann eine lokale oder private KI-Architektur sinnvoll sein, besonders wenn Kundendaten, Vertragsinhalte oder interne Wissensbestände verarbeitet werden.
2. Halluzinationen und falsche Annahmen
KI-Systeme können plausibel klingende, aber falsche Antworten erzeugen. In Softwareprojekten zeigt sich das durch erfundene APIs, falsche Library-Versionen, unvollständige Migrationsschritte oder scheinbar logische Architekturentscheidungen, die nicht zur Codebasis passen.
Gegenmaßnahmen sind:
- Quellen und Dateien explizit referenzieren
- Tests für relevante Pfade verlangen
- Ergebnisse mit Dokumentation abgleichen
- kritische Entscheidungen menschlich freigeben
- keine unverified Outputs in Produktion übernehmen
3. Unsicherer oder schwer wartbarer Code
KI kann Code erzeugen, der funktioniert, aber langfristig problematisch ist: zu breite Berechtigungen, fehlende Fehlerbehandlung, doppelte Logik, schwache Typen oder unklare Zuständigkeiten.
Der Review muss deshalb nicht nur fragen: "Läuft es?" Sondern auch:
- Passt es zur Architektur?
- Gibt es unnötige Abhängigkeiten?
- Werden Secrets geschützt?
- Sind Fehlerzustände sauber behandelt?
- Gibt es Tests für Berechtigungen und Randfälle?
4. Prompt Injection und Tool-Missbrauch
Sobald KI-Systeme externe Inhalte lesen oder Tools nutzen, entsteht ein neues Angriffsmodell. Ein Dokument, eine Website oder eine Nutzeranfrage kann Anweisungen enthalten, die das System zu unerwünschtem Verhalten bringen sollen.
Die OWASP Top 10 for LLM Applications beschreibt solche Risiken als zentrale Kategorie moderner KI-Anwendungen. Für Unternehmen bedeutet das: KI-Agenten brauchen harte Tool-Grenzen, Freigaben und Filter. Ein Modell darf nicht automatisch alles tun, nur weil ein Dokument es behauptet.
5. Fehlende Nachvollziehbarkeit
Wenn niemand weiß, welche Eingaben ein KI-System gesehen hat und warum ein Ergebnis entstanden ist, wird Betrieb schwierig. Das betrifft Support, Compliance und Produktqualität.
Ein produktives KI-System braucht:
- Audit-Logs
- Versionierung von Prompts
- Modell- und Anbieterinformationen
- Nutzer- und Rechtekontext
- Freigabehistorie
- Monitoring für Fehler und Drift
Governance: Was Unternehmen konkret brauchen
KI-Governance muss nicht bürokratisch sein. Sie muss praktikabel sein. Ein guter Start besteht aus fünf Bausteinen.
| Baustein | Zweck |
|---|---|
| KI-Richtlinie | Definiert erlaubte Tools, Datenklassen und Freigaben |
| Use-Case-Bewertung | Bewertet Nutzen, Risiko und Datenlage vor Umsetzung |
| Technische Leitplanken | Rollen, Rechte, Logging, Tool-Grenzen |
| Qualitätssicherung | Tests, Evaluationssets, menschliche Reviews |
| Betrieb | Monitoring, Fehleranalyse, Updates, Verantwortliche |
EU AI Act: Nicht jedes System ist gleich riskant
Der EU AI Act folgt einem risikobasierten Ansatz. Nicht jede KI-Anwendung hat dieselben Pflichten. Ein internes Tool zur Code-Zusammenfassung ist anders zu bewerten als ein System, das Bewerbungen filtert, Kreditentscheidungen vorbereitet oder medizinische Empfehlungen gibt.
Für Unternehmen ist deshalb eine frühe Einordnung wichtig:
- Welchen Zweck hat das System?
- Wer ist betroffen?
- Werden Entscheidungen automatisiert?
- Gibt es menschliche Freigabe?
- Welche Daten werden verarbeitet?
- Kann ein Fehler Menschen rechtlich, finanziell oder gesundheitlich schaden?
Diese Fragen gehören an den Anfang, nicht kurz vor dem Launch.
Sicherheitsarchitektur für KI-Projekte
Eine belastbare KI-Integration sollte wie jedes andere produktive System entworfen werden.
Praktische Maßnahmen:
- keine Secrets in Prompts
- serverseitige Tool-Ausführung mit Rechteprüfung
- getrennte Umgebungen für Entwicklung und Produktion
- Eingabe- und Ausgabevalidierung
- Rate Limits und Kostenlimits
- Logging ohne unnötige personenbezogene Daten
- Freigabe für irreversible Aktionen
- Tests gegen Prompt Injection und unerlaubte Tool-Nutzung
Wann lokale KI sinnvoll ist
Lokale KI oder private Modelle sind nicht für jedes Projekt nötig. Sie können aber sinnvoll sein, wenn Daten das Unternehmen nicht verlassen sollen, geringe Latenz relevant ist oder branchenspezifische Compliance Anforderungen stellt.
Typische Kandidaten:
- interne Wissenssuche
- Vertrags- und Dokumentenanalyse
- Support-Vorbereitung
- sensible Produktdaten
- Forschung und Entwicklung
- regulierte Branchen
In solchen Fällen sollte früh geprüft werden, ob lokale Modelle, private Deployments oder strikt isolierte Hosting-Modelle die passenden technischen Rahmenbedingungen bieten.
Fazit: Risiko kontrollieren statt Innovation blockieren
KI-Risiken sind real. Aber sie sind kein Grund, KI pauschal zu vermeiden. Sie sind ein Grund, KI professionell zu integrieren.
Bei hafencity.dev betrachten wir KI-Projekte als Softwareprojekte mit besonderen Anforderungen: Datenflüsse, Rechte, Audit-Logs, Tests, Evaluation und Betrieb. So entstehen KI-Integrationen, die im Alltag funktionieren und nicht nur in einer Demo überzeugen.
