| Bezeichnung | Demo-Anwendung „Preisoptimierung" |
|---|---|
| Verantwortlicher | Studienteam FOM (siehe Impressum) |
| Zweck | Studienprojekt; Preissimulation mit KI-gestütztem Vorschlag |
| Rechtsgrundlage | Art. 6 Abs. 1 lit. f DSGVO |
| Kategorien betroffener Personen | Teammitglieder, Demo-Nutzer (keine Endkunden) |
| Kategorien personenbezogener Daten | Username, Passwort-Hash, Rolle, Session-Cookie, Rate-Limit-Zähler |
| Kategorien von Empfängern | Google Ireland Ltd. (LLM-API) – nur Produktdaten, keine Personendaten |
| Drittlandtransfer | USA (Google LLC); Grundlage: Standardvertragsklauseln (Art. 46 DSGVO) |
| Löschfristen | Nutzerkonten + Historie: Projektabschluss; Rate-Limit: tgl. Reset; Preis-Suggestions: TTL 15 min |
| TOMs | siehe Abschnitt 4 |
Compliance & Governance
Interner Bereich: Verzeichnis von Verarbeitungstätigkeiten, DPIA- Kurzprüfung, TOMs, AVV-Bewertung, NIS-2-Prüfung und KI-Governance. Diese Seite ist nach Login erreichbar und dokumentiert die regulatorische Einordnung des Demo-Projekts.
Geprüft wurde, ob eine vollständige DSFA erforderlich ist. Ergebnis: nicht zwingend, mit dokumentierter Begründung.
- Profiling / automatisierte Einzelentscheidungen: liegen nicht vor. Jeder KI-Vorschlag wird vom Admin bestätigt (Human-in-the-Loop).
- Umfangreiche besondere Kategorien: keine (Art. 9 DSGVO nicht einschlägig).
- Systematische Überwachung öffentlicher Bereiche: nein.
- Innovative Technologie-Risiken: LLM-Einsatz als neuer Risikofaktor ist berücksichtigt; durch Zweckbindung (keine Kundendaten im Prompt) und Transparenz (Kennzeichnung KI-Vorschlag) mitigiert.
Dieser Abschnitt dokumentiert die Prüfung nach Art. 35 Abs. 1 DSGVO. Im Produktivbetrieb mit Echtkundendaten wäre eine vollständige DSFA nachzuziehen.
Die Nutzung der Gemini API erfolgt auf Basis der Google Cloud Terms of Service und der dazugehörigen Data Processing Addendum (DPA). Google fungiert in Bezug auf Input/Output-Daten grundsätzlich als Auftragsverarbeiter. Für den Prototyp-Betrieb werden ausschließlich nicht-personenbezogene Produktdaten übermittelt; eine vertragliche Dokumentation wurde nicht separat abgeschlossen, weil das Studienprojekt keinen Produktiv-Betrieb darstellt.
Produktivempfehlung: separates, unterzeichnetes AVV mit Google Cloud abschließen, zuzüglich Verfahrensverzeichnis pro Prompt.
| Schutzziel | Maßnahme |
|---|---|
| Vertraulichkeit | Argon2id-Passwort-Hashing; signierte HttpOnly-Session-Cookies; Rollen-Trennung admin/viewer; Rate-Limit pro Nutzer pro Tag; Admin-only Zugriff auf HTTPS-/User-/Rate-Limit-Settings |
| Integrität | Alembic-Migrationen versioniert; Preis-Historie mit Benutzerbezug und KI-Flag; Backend-validierter Formel- Evaluator ohne `eval` / Funktionsaufrufe außer Whitelist |
| Verfügbarkeit | systemd-Service; nginx-Reverse-Proxy mit Let's-Encrypt- Zertifikat (via Settings aktivierbar); idempotenter Installer; tägliches DB-Backup empfohlen (TODO produktiv) |
| Belastbarkeit | Rate Limiting bremst Missbrauch; strikte Input-Validierung (Pydantic + Regex für Formeln und Domains); subprocess-Aufrufe nur als argv-Array, nie Shell |
| Transport | TLS via Let's Encrypt (certbot-nginx); HTTP→HTTPS-Redirect automatisch konfiguriert |
| Zugriff | Backend-Service-User „preisopt" ohne allgemeine Sudo-Rechte; nur ein einziger privilegierter Helper-Befehl (HTTPS-Enable) via sudoers.d freigegeben |
| Weisungsbindung Dritter | LLM-Aufrufe sind strikt zweckgebunden auf Produktdaten; der Prompt wird in der UI vollständig als „Frage an die KI" angezeigt und damit überprüfbar gemacht |
Die NIS-2-Richtlinie (Umsetzung DE: NIS2UmsuCG) adressiert „wesentliche" und „wichtige" Einrichtungen in kritischer Infrastruktur (Energie, Gesundheit, digitale Infrastruktur etc.) ab festgelegten Schwellenwerten.
Ergebnis der Prüfung: nicht im Anwendungsbereich. Das Studienprojekt erbringt keine kritische Dienstleistung, betreibt keine kritische Infrastruktur und unterschreitet jeden relevanten Mitarbeiter- oder Umsatzschwellenwert. Dennoch wurden die in der Richtlinie geforderten Mindestmaßnahmen (Art. 21 NIS-2) im Rahmen der TOMs orientierungshalber umgesetzt: Risikomanagement via Rate Limit, Zugriffsbeschränkung über Rollen, Incident-Nachvollzug über die Preis-Historie, Lieferkettensicherheit dokumentiert durch die AVV-Bewertung in Abschnitt 3.
Einstufung
Das LLM-gestützte Preisvorschlag-Feature ist ein „KI-System mit begrenztem Risiko" nach Art. 50 EU AI Act (Verordnung 2024/1689). Einstufungsgründe:
- Interaktion Mensch-KI (Generativer Text, strukturierte Antwort).
- Keine Aufnahme in Annex III (Hochrisiko) – keine Entscheidungen über Bildungszugang, Beschäftigung, Bonität, Strafverfolgung, Migration oder biometrische Identifikation.
- Verbrauchernahe Nutzung nicht gegeben (B2B-Demo, kein Endkundenkontakt).
Transparenzpflicht (Art. 50 AI Act)
Wird erfüllt durch:
- Badge „KI-Vorschlag" an jedem LLM-generierten Preis in der Tabelle und in der Preis-Historie.
- Vollständige Anzeige des an die KI geschickten Prompts in der UI vor der Antwort.
- Anzeige der Begründung, die die KI zurückgeliefert hat.
Menschliche Aufsicht (Art. 14 AI Act, sinngemäß)
Der Shop-Betreiber (Admin) bestätigt jede KI-Empfehlung manuell, bevor sie als Strategie übernommen oder in die Preis-Historie geschrieben wird. Es gibt keinen Auto-Apply-Pfad.
KI-Kompetenz (Art. 4 AI Act)
Art. 4 AI Act verpflichtet Betreiber zur Sicherstellung ausreichender KI-Kompetenz beim eingesetzten Personal. Das Team besteht aus vier FOM-Studierenden im Studiengang Anwendungsentwicklung, die im Rahmen der Modul- Anforderungen KI-Technologien, deren Risiken, Grenzen und regulatorische Einordnung behandelt haben:
- Daniel Brunthaler – Entwicklung / Backend
- Kayathiri Raveendran – Entwicklung / Datenbank
- Okan Baykal – Entwicklung / Frontend
- Sven Schlickewei – Entwicklung / Deployment & Compliance-Doku
Alle vier sind eingetragen und authentifizierbar im System (Benutzerverwaltung → Team-Accounts).
Der gesamte Inhalt der Anwendung – Produkte, Preise, Nachfrage, Wettbewerbsdaten, Historien – ist Mock-Daten. Das System trifft keine geschäftlichen Entscheidungen, steuert keine realen Shopsysteme und gibt keine für den Markt verbindlichen Empfehlungen ab. Jeder Praxiseinsatz würde eine vollständige DSFA, einen signierten AVV mit Google Cloud sowie erweiterte TOMs (u. a. Backup, Monitoring, Incident-Response-Plan) erfordern.