Vorlesung 31: Sicherheit — Grenzen der Künstlichen Intelligenz

Kursthema: KI | Block: Grenzen | Reihenfolge: 31 | Zielgruppe: interessierte Erwachsene

Gliederung: Teil 1 (20 Min) Einführung mit Analogien und Beispielen; Teil 2 (20 Min) Fachbegriffe und Techniken; Teil 3 (10 Min) Anwendungen, Grenzen und Denkaufgaben.

Teil 1 (ca. 20 Minuten) — Einführende Darstellung: Was bedeutet "Sicherheit" bei KI?

Wenn wir von Sicherheit bei KI-Systemen sprechen, meinen wir mehrere miteinander verknüpfte Aspekte: die Verlässlichkeit der Ergebnisse (Robustheit), den Schutz vor gezielter Manipulation (Angriffe auf Modelle oder Daten), den Schutz sensibler Daten (Privatsphäre) und die Verantwortlichkeit derjenigen, die Systeme entwickeln und betreiben. Eine hilfreiche Alltag-Analogie ist die eines Autos: ein Auto muss mechanisch robust sein, darf nicht von außen leicht manipuliert werden, soll die Privatsphäre der Insassen schützen und der Hersteller trägt Verantwortung für Design, Qualitätssicherung und Gebrauchsanweisungen. Entsprechend braucht auch KI eine „Fahrzeuginspektion“ (Testverfahren), „Schlösser und Sensoren“ (Sicherheitsmechanismen) und Regeln für Hersteller und Betreiber.

Praktische Beispiele machen die Probleme greifbar. Adversariale Beispiele sind künstlich veränderte Eingaben, die ein Modell zu falschen Schlüssen verleiten können, obwohl Menschen sie korrekt interpretieren. Datenvergiftung (data poisoning) bezeichnet gezielte Manipulation der Trainingsdaten, um ein spätes Modellverhalten zu beeinflussen. Mit „Model Extraction“ können Angreifer aus einer zugänglichen Schnittstelle (API) ein Modell nachbauen und damit Geschäftsgeheimnisse oder Sicherheitsfunktionen aushebeln. Für personenbezogene Daten besteht das Risiko, dass aus einem Modelleinsatz private Informationen rekonstruiert werden können. Diese Angriffsformen wurden in der Forschung nachgewiesen und dokumentiert; es besteht wissenschaftlicher Konsens, dass sie reale Risiken darstellen, für die technische Gegenmaßnahmen notwendig sind.

Gleichzeitig ist wichtig zu betonen, wo Unsicherheiten liegen: Manche Angriffe funktionieren nur unter bestimmten Annahmen (z. B. volle Kenntnis des Modells oder Zugriff auf Trainingsdaten), und die Wirksamkeit von Gegenmaßnahmen kann von Architektur, Datenqualität und Einsatzumgebung abhängen. Aktuelle Leitlinien wie der NIST AI Risk Management Framework fassen den Forschungsstand praktikabel zusammen und empfehlen Risikoanalysen und Prozessgestaltung als Kernaufgaben zur Minderung von Gefahren.

Teil 2 (ca. 20 Minuten) — Vertiefung: Fachbegriffe, Angriffsarten und Schutzmechanismen

Wichtige Angriffsarten

Adversariale Eingaben (adversarial examples) beschreiben gezielte, oft klein wirkende Modifikationen an Eingabedaten, die ein Modell fehlleiten, ohne für Menschen sichtbar anders zu wirken. Die Forschung hat mehrere Verfahren gezeigt, mit denen solche Beispiele konstruiert werden können, sowie Gegenmaßnahmen wie adversariales Training, das Modelle auf solche Manipulationen vorbereitet. Während adversariales Training die Robustheit in getesteten Szenarien verbessert, ist vollständige Immunität gegen alle möglichen Manipulationen bisher nicht erreicht.

Data Poisoning betrifft Manipulationen am Trainingsdatensatz. Solche Manipulationen können subtil sein (Backdoors/Trojaner: das Modell lernt ein ingrained Trigger-Verhalten) oder breit angelegt, um Performance zu verschlechtern. Poisoning ist besonders relevant, wenn Trainingsdaten aus unsicheren Quellen stammen oder wenn öffentliche/benutzergenerierte Daten ohne strenge Qualitätskontrolle genutzt werden.

Modell-Diebstahl (model extraction) nutzt oft eine öffentlich zugängliche Abfrage-Schnittstelle, um ein funktional ähnliches Modell zu rekonstruieren. Dadurch können proprietäre Modelle kopiert, Sicherheitsschranken umgangen oder zusätzliche Angriffe wie adversariale Beispiele leichter vorbereitet werden.

Angriffe gegen Datenschutz

Membership-Inference-Angriffe versuchen zu bestimmen, ob ein spezifischer Datensatz oder ein Individuum im Trainingssatz eines Modells enthalten war. Model-Inversion-Angriffe zielen darauf ab, aus einem Modell Rückschlüsse auf Trainingsdaten zu ziehen und damit sensible Informationen zu rekonstruieren. Beide Angriffstypen wurden in der Literatur praktisch demonstriert und zeigen, dass Modelle ohne Schutzmaßnahmen Privatsphäre verletzen können.

Abwehrstrategien und ihre Grenzen

Technische Gegenmaßnahmen existieren in mehreren Kategorien. Differential Privacy ist ein mathematisch definiertes Konzept, das die Wahrscheinlichkeit begrenzt, mit der Informationen über einzelne Trainingsbeispiele aus Modellausgaben rekonstruiert werden können; praktische Implementierungen für Deep Learning sind verfügbar, führen aber zu Abwägungen zwischen Privatsphäre und Modellleistung. Adversariales Training erhöht die Robustheit gegenüber bestimmten Arten von Manipulationen; seine Effektivität ist jedoch abhängig von dem Spektrum der während des Trainings simulierten Angriffe. Weitere Maßnahmen sind Input-Sanitization, Monitoring von Anfragen an Modelle (zur Erkennung von Extraktionsversuchen), und die Verwendung von Zugangskontrollen und Logging.

Ergänzend zu technischen Mitteln empfiehlt die Forschung Prozessmaßnahmen: systematische Risikoanalyse, dokumentierte Tests, Red-Teaming und kontinuierliches Monitoring in Produktion. Institutionelle Rahmenwerke wie das NIST AI Risk Management Framework empfehlen, Sicherheit nicht als Einmalaufgabe, sondern als iterativen, organisationsweiten Prozess zu behandeln.

Rolle von Governance und Normen

Neben technischen Lösungen bilden regulatorische und normative Vorgaben den dritten Pfeiler der Sicherheit. Internationale Prinzipien, wie die von der OECD formulierten AI-Prinzipien, und Gesetzesinitiativen, wie der Vorschlag der Europäischen Kommission zum „Artificial Intelligence Act“, zielen darauf ab, Mindestanforderungen, Transparenzpflichten und Verantwortlichkeiten festzulegen. Solche Regelwerke betreffen beispielsweise Klassifizierung risikoreicher Systeme, Reporting-Pflichten für Sicherheitsvorfälle und Anforderungen an Datenqualität und Dokumentation. Die konkrete Ausgestaltung und Wirkung dieser Regelungen ist Gegenstand laufender politischer und fachlicher Diskussionen; als Fakt lässt sich festhalten, dass solche Rahmenwerke derzeit in vielen Rechtsräumen entwickelt und umgesetzt werden.

Verantwortung der Entwickler und Betreiber

Entwickler und Organisationen tragen Verantwortung in mehreren Dimensionen: sie müssen Risiken identifizieren, adäquate Gegenmaßnahmen implementieren, ihre Modelle testen und dokumentieren sowie transparent über Grenzen und mögliche Fehlfunktionen informieren. Diese Verantwortung umfasst auch organisatorische Maßnahmen wie Security-by-Design, Data Governance und klare Prozesse für Updates und Incident-Response. Leitfäden und Frameworks der Forschung und Normungsorganisationen empfehlen, Verantwortlichkeiten klar zuzuordnen und Sicherheitsprüfungen entlang des gesamten Entwicklungszyklus durchzuführen.

Transparenz über Unsicherheiten

Viele Verteidigungsmaßnahmen bieten keinen absoluten Schutz, sondern reduzieren Wahrscheinlichkeiten oder begrenzen Schäden unter bestimmten Annahmen. Die Forschung ist aktiv: neue Angriffsszenarien und Verteidigungsansätze werden kontinuierlich publiziert. Es besteht daher eine wissenschaftliche Übereinstimmung, dass Sicherheit bei KI fortlaufende Überprüfung, Anpassung und externe Evaluation erfordert.

Teil 3 (ca. 10 Minuten) — Anwendungen, Grenzen und Denkaufgaben

Um die bisherigen Punkte zu verknüpfen, betrachten wir drei kurze Anwendungsbeispiele und die damit verbundenen Sicherheitsfragen. Erstens: ein medizinisches Assistenzsystem, das Diagnosen aus Röntgenbildern unterstützt. Hier sind Risiken adversarialer Manipulationen (falsch-positive/negativ-Fehldiagnosen) und Datenschutzverletzungen akut. Gegenmaßnahmen umfassen robustes Testen, Zugangsbeschränkungen, Differential Privacy bei Trainingsdaten und klare Dokumentation über die Systemgrenzen.

Zweitens: ein Chatbot, der Kundendaten verarbeitet und per API verfügbar ist. Relevante Gefahren sind Model Extraction, Prompt Injection (Eingaben, die das System zu unerwünschtem Verhalten bringen) und Leak von vertraulichen Informationen. Praktische Schutzmaßnahmen sind Ratenbegrenzung, Ausgabe-Filterung, Logging, stärker kontrollierte Kontexte für sensible Anfragen und gezieltes Red-Teaming.

Drittens: ein System zur Qualitätsprüfung in einer Fertigungsstraße. Hier steht Robustheit gegen ungewöhnliche Sensorwerte oder gezielte Störungen im Vordergrund. Strategien umfassen robuste Sensordatenfusion, Anomalieerkennung und regelmäßige Tests unter realistischen Störbedingungen.

Kleine Denkaufgaben zur Vertiefung: 1) Stellen Sie sich vor, Sie betreiben ein öffentliches Klassifikations-API. Welche Hinweise im Betrieb würden Ihnen signalisieren, dass ein model-extraction-Angriff stattfindet? 2) Sie sollen ein Modell mit sensiblen Patientendaten trainieren: welche Abwägungen führen Sie zwischen Modellqualität und Privacy-Parameter einer Differential-Privacy-Lösung durch? 3) Ihr Team entdeckt, dass ein Modell unter bestimmten Input-Varianten systematisch falsch reagiert: welche Schritte würden Sie zur Identifikation, Behebung und zur Kommunikation nach außen ergreifen?

Für jede dieser Aufgaben gilt: Man benötigt technische Maßnahmen, organisatorische Prozesse und transparente Kommunikation. Die Kombination reduziert Risiken, eliminiert sie aber nicht vollständig; deshalb müssen Verantwortlichkeiten, Monitoring und Notfallpläne Teil des Systems sein.