Datenschutz- und Speicherkonzept

Generated artifact. Do not edit manually.

Generated by: scripts/build_compendia.py Regenerate with: python3 scripts/build_compendia.py --compendium security --web-and-tex Source of truth: docs/security/source/

Sprache / Language: Deutsch (DE) · English (EN) | PDF: Deutsches PDF · English PDF

Kompendium: §1 Datenschutz & Speicherung · §2 OpenAI-MCP-Clientbindung · §3 KI-Verordnung Compliance

1. Datenschutz- und Speicherkonzept

Technisches Datenfluss- und Speicherkonzept

Stand: aktualisiert am 13. September 2026 (mit Abgleich auf den neutralen OpenAI-Endpunkt-Cutover vom Oktober 2026) für die aktive Claude-first-Beta, den nachfolgenden ChatGPT-Integrationskandidaten samt Windows-Desktop-Git-Beta, die Freitextgrenze der Coach-Werkzeuge, freiwilliges Lernziel-Feedback sowie die Lösch- und Aufbewahrungsgrenze der SkillPilot-ID. Die bestehenden Angaben zur Lehreransicht und zum persönlichen Fachzeitplan gelten unverändert fort.

Dieses Dokument beschreibt Datenflüsse und Speicherung aus technischer Sicht. Es ersetzt weder die lernendenseitige SkillPilot-Datenschutzerklärung noch die Datenschutzbedingungen des KI-Anbieters oder eine rechtliche Prüfung vor einer öffentlichen Freigabe. Der öffentliche Datenschutztext wird in app/src/utils/privacyViewCopy.ts gepflegt. Die unten genannten Repository-Defaults sind kein Nachweis für die tatsächliche Konfiguration oder Aufbewahrungsdauer jedes produktiven Dienstes, Log-Abzugs oder Backups.

Die verbindliche Arbeitsreihenfolge lautet Claude-Beta → stabiler Kandidat → fokussierte ChatGPT-Integrationsabnahme → offizielle Einreichung. Die providerneutrale Coach-Grenze und das Claude-Runbook regeln die aktive Provider-Spur. Der getrennte OpenAI-MCP-Identitäts- und 24-Stunden-Session-Vertrag sowie 2 beschreiben den nachfolgenden OpenAI-Integrationskandidaten und die explizit autorisierte Desktop-Git-Beta, nicht ein abgenommenes öffentliches Verzeichnis-Release.

1.1. Grundprinzip: Privacy by Design

SkillPilot trennt strikt zwischen pseudonymer Lernenden-Identität, persistentem Lernstand, temporärem Provider-Zugriff und providerseitigem Gesprächsinhalt:

Das SkillPilot-Backend speichert Lernfortschritte unter einer zufälligen, pseudonymen SkillPilot-ID — ohne Namen, E-Mail-Adresse oder Passwort zu verlangen. Dies ist Pseudonymität, keine Anonymität: Die ID verknüpft eine Lernhistorie, und wer eine Zuordnung zwischen ID und Person besitzt, kann die Person identifizieren.
Der Browser bildet die Anmeldeoberfläche für SkillPilot. Er hält die dauerhafte SkillPilot-ID lokal vor und kann sie optional mit einem selbst gewählten Passwort verschlüsselt ablegen.
Die dauerhafte SkillPilot-ID verbleibt ausschließlich in First-Party-Oberflächen von SkillPilot und gelangt weder in den KI-Chat noch in OAuth-Principals, MCP-Tools oder providergehostete Widgets. Jeder explizite Start im WebGUI erzeugt eine separate, kurzlebige Lernsession-Referenz, die das Backend intern auf die ID auflöst.
Der KI-Anbieter verarbeitet Chatverlauf, Uploads, projizierten Lernkontext und Tool-Antworten unter dem jeweiligen Provider-Account und dessen Bedingungen.
SkillPilot erhält kein vollständiges Chat-Transkript des Providers, empfängt aber jeden explizit gesendeten API- oder MCP-Toolaufruf einschließlich der für das Lesen oder Ändern des Lernstands nötigen strukturierten Argumente.

Architekturinvariante für Coach-Werkzeuge: Antworten der Lernenden, Erklärungen, Gesprächszusammenfassungen und vom Coach formulierte Rückmeldungen verbleiben ausschließlich im Provider-Chat. Weder workFeedback, outcomeFeedback, Recall-Felder wie feedback/lastFeedback noch umbenannte Äquivalente gehören in akzeptierte Coach-Eingaben, gespeicherten Lernstand, Replay-Antworten oder Diagnosedaten. Der Coach trifft die pädagogische Einschätzung und formuliert seine Erfolgsmeldung selbst; SkillPilot nimmt ausschließlich die autorisierte strukturierte Entscheidung entgegen und gibt den bestätigten Zustand zurück (siehe providerneutrale Coach-Grenze). Das Bereinigungsprotokoll vom 12. September 2026 dokumentiert eine historische Produktionsbereinigung samt damaligen Rollout-Pflichten und ist kein Beleg für den Zustand späterer Deployments.

Der Status der Provider-Spuren bleibt explizit getrennt:

Claude V1 OAuth/MCP: die aktive Lern-Beta über den persönlichen Claude-Marketplace. Installation und Updates umgehen weder OAuth noch Session-Isolation oder fachliche Autorisierung.
Mehrsprachige OpenAI-V1-OAuth/MCP-App: der ChatGPT-Integrationskandidat (skillpilot-coach auf dem neutralen Zielendpunkt https://mcp-openai.skillpilot.com/mcp, flankiert von der explizit autorisierten Windows-Desktop-Git-Beta). Vollständige Host-Abnahmen über Desktop/Voice, Web und Mobile bleiben Voraussetzung einer Verzeichnis-Veröffentlichung; Quellcode, lokale Tests oder bestandene Claude-Tests belegen keine ChatGPT-Host-Abnahme.
Visible Session: ausschließlich historischer Custom-GPT-Rollback-Vertrag, keine beworbene Beta und kein aktueller MCP-Vertrag. Sein temporäres sps_...-Bearer-Token ist bewusst in Startnachricht und Status-Footer sichtbar.

Alle Provider-Spuren nutzen denselben fachlichen Kern, wahren jedoch strikt getrennte OAuth- und Session-Grenzen. Sprachunterstützung und Frontend-Integration sind releasegebunden; bloßes Vorhandensein im Quellcode begründet keine öffentliche Plattformzusage.

1.2. Datenpartitionierung

1.2. A. Lokaler Client (Browser / Local Storage)

Vertrauensgrenze: kontrolliert durch die lernende Person und ihre Browserumgebung. Der Browser kann folgende Daten halten:

die aktive SkillPilot-ID;
optionale benannte lokale Profile, in denen die SkillPilot-ID mit einem selbst gewählten Passwort verschlüsselt ist (das Passwort selbst wird nicht gespeichert);
eine browserlokale OpenAI-Teilnahmebestätigung, gebunden an das aktuelle pseudonyme SkillPilot-Profil für die Lebensdauer des Browser-Tabs;
das gewählte Curriculum sowie weitere UI-Einstellungen;
lokalen SRS-Wiederholungszustand vor oder zwischen Synchronisationen;
die frisch vorbereitete Provider-Start-URL bzw. Startnachricht mit einer kurzlebigen Lernsession-Referenz, jedoch niemals mit dauerhafter SkillPilot-ID, OAuth-Token oder Client-Secret.

Jeder V1-Coach-Start ruft mit der lokal aktiven dauerhaften SkillPilot-ID einen lernendenspezifischen UI-Endpunkt auf und erzeugt genau in diesem Moment eine frische Lernsession-Referenz. Der Claude-Start öffnet den vorbereiteten Chat direkt; die ChatGPT-Desktop-Beta zeigt die providerspezifische Startnachricht zum Einfügen in einen neuen Desktop-Chat an. Da eine Start-URL oder Startnachricht mit temporärer Referenz selbst schutzbedürftig ist und in der Browserchronik oder kopierten Links auftauchen kann, ist sie entsprechend vertraulich zu behandeln.

Im lehrkraftbegleiteten Einsatz kann der Browser der Lehrkraft bzw. ein institutionell kontrollierter Speicher zusätzlich lokale Klassennamen, Namen oder Aliase, dauerhafte SkillPilot-IDs und zwischengespeicherte Level-2-Personalisierungen halten; SkillPilot speichert diese Klassenzuordnung nicht zentral. Die Lehreransicht liest reguläre Profil- und Mastery-Endpunkte direkt über die bekannte dauerhafte ID. Bei der erstmaligen Planung eines Lernbereichs ermittelt ein zusätzlicher no-store-Lesezugriff alle atomaren Ziel-IDs der vollständigen Level-2-Personalisierung des gewählten Fachs samt offener Teilmenge (unabhängig vom veränderlichen Level-3-Fokus) und legt Ziel-IDs, Summenzähler und Erfassungszeitpunkt als unveränderliche lokale Planungs-Baseline ab — ohne SkillPilot-ID oder numerische Einzel-Masterywerte in der Baseline. Die reguläre Lehreransicht verändert keine lernendenseitig geplanten Ziele und erzeugt serverseitig weder Lehrkraft-, Klassen-, Berechtigungs- noch Mitgliedschaftsdatensätze.

Die Lehreransicht sperrt Lernstandsänderungen im Frontend, während der browserlokale Kursplan editierbare Arbeitsdaten der Lehrkraft bleibt. Eine explizit bestätigte Aktion kann Planbezeichnung, datierte Blöcke und clientseitig materialisierte atomare Ziel-IDs in einen getrennten persönlichen Fachzeitplan unter der bekannten dauerhaften SkillPilot-ID kopieren. Der Server prüft die IDs gegen den personalisierten Fachumfang: Neu hinzugefügte IDs werden nur akzeptiert, solange sie offen sind; bereits enthaltene IDs dürfen zur Wahrung der Plankontinuität erhalten bleiben. Es werden weder Klassen-ID, Alias, Durchführungsjournal, Bestätigungen, Masterywerte, Planungs-Baseline noch Planhistorie übertragen und keine Lehrkraft-Lernenden-Beziehung angelegt. Spätere lokale Planänderungen werden nicht synchronisiert; von der Lehrkraft eingegebene Titel werden unverändert kopiert und können personenbezogene Angaben enthalten.

Die bestätigte First-Party-Aktion Planung wirksam machen validiert sämtliche aktuellen Fachpläne vor dem Schreiben vollständig (alles oder nichts), aktiviert das plangesteuerte Lernen unter der bekannten SkillPilot-ID und wählt sofort das erste fällige Ziel mit erfüllten Voraussetzungen (jederzeit pausierbar). Die nachgeordnete Aktion Nur dieses Fach aktualisieren ersetzt lediglich die betreffende Fachkopie, ohne den Planmodus zu aktivieren oder ein Ziel zu wählen. Ein expliziter Fachwechsel parkt ein unvollendetes aktives Ziel ohne Mastery-Änderung und wählt ein fälliges zulässiges Ziel im gewählten Fach; nach bestätigtem Abschluss hat ein gültiger Plan mit dem abgeschlossenen Ziel Vorrang, andernfalls greift die deterministische Dringlichkeits- und Fachreihenfolge. Veraltete oder ungültige Pläne bleiben ungenutzt, ohne fälliges zulässiges Ziel wird kein Ersatz erfunden, der generische Autopilot bleibt während aktivem Planmodus unterdrückt, und reiner Kalenderfortschritt löst keinen Schreibvorgang aus. Planexporte lassen die abgeleitete Baseline weg, exportieren Freitexttitel jedoch unverändert.

Die dauerhafte SkillPilot-ID bleibt das Inhabergeheimnis und der Vollzugriffsschlüssel auf den Lernstand (das Löschen einer lokalen Klasse lässt die ID gültig und unverändert). Heruntergeladene lokale Klassenexporte werden daher im Browser zwingend mit einem von der Lehrkraft gewählten Passwort über versioniertes PBKDF2-SHA-256 und authentifiziertes AES-256-GCM verschlüsselt; SkillPilot speichert oder rekonstruiert das Passwort nicht. Ältere unverschlüsselte JSON-Klassenexporte bleiben zur Migration importierbar (im UI als ungeschützt markiert), neue Exporte werden niemals im Klartext geschrieben. Die Dateiverschlüsselung schützt die exportierte Datei im Ruhezustand, verschlüsselt aber weder den lokalen Browserspeicher noch ein entsperrtes Gerät und macht die ID nach dem Entschlüsseln nicht schreibgeschützt.

1.2. B. Persistenter Lernstand im SkillPilot-Backend

Vertrauensgrenze: pseudonyme, zentrale Datenhaltung im SkillPilot-Backend. Gespeichert werden insbesondere:

Learner: der dauerhafte pseudonyme Lernendenschlüssel;
providerspezifische aktive Lernsessions samt absolutem Ablaufzeitpunkt und direkter interner Zuordnung zum Lernenden;
Mastery: Lernziel-Mastery pro Lernendem und Ziel;
geplante Ziele und Lernkonfiguration (Curriculum, Personalisierung, Scope, aktives Ziel, Filter und synchronisierter Client-Zustand);
optionale persönliche Fachzeitpläne, deren Revisionen und materialisierte atomare Ziel-IDs sowie die Präferenz für plangesteuertes Lernen (standardmäßig deaktiviert bis zur bestätigten Aktivierung);
statische Curricula, Kompetenzdefinitionen, SRS-Decks, Ressourcen und Review-Metadaten.

Kein Modellanbieter benötigt die dauerhafte SkillPilot-ID für die aktive Claude-Integration oder den OpenAI-Kandidaten; sie dient ausschließlich serverintern als Verknüpfungsschlüssel von der temporären Session zum Lernstand. Der Betreiber hat bestätigt, dass der SkillPilot-Core in Deutschland gehostet wird; dies bedeutet nicht, dass gewählte KI-Anbieter, Supportdienste oder sämtliche Auftragsverarbeiter ausschließlich in Deutschland arbeiten — die providerseitige Verarbeitung folgt den offengelegten Bedingungen des jeweiligen Anbieters.

1.2. C. Historische Visible-Session-Daten — ausschließlich Rollback

Dieser beibehaltene Legacy-Pfad ist weder die aktive Claude-Beta noch ein aktueller ChatGPT-MCP-Vertrag. Das Backend speichert eine ChatSession mit HMAC-Hash des temporären Tokens, Lernendenzuordnung, Sprache, Start-/Ablauf-/Nutzungszeitstempeln und optionalen Widerrufsdaten; Klartext-sps_...-Tokens werden nur bei der Erzeugung ausgegeben und dürfen niemals geloggt werden. ChatGPT sieht das Token in Startnachricht und Pflicht-Footer, den projizierten Lernkontext, Auswahlnummern/-referenzen, öffentliche kanonische Lernziel-IDs sowie Recall-Karten-IDs und Fragen. Das Token ist ein kurzlebiges Berechtigungsmerkmal (absoluter Ablauf nach höchstens 24 Stunden ohne Verlängerung durch Nutzung), keine Anonymisierung des Gesprächs.

1.2. D. Daten des mehrsprachigen OpenAI-V1-OAuth/MCP-Kandidaten

Dieser Abschnitt beschreibt das implementierte Sicherheits- und Datenprofil der OpenAI-V1-Spur (skillpilot-coach, vorbereitet für den neutralen geschützten Endpunkt https://mcp-openai.skillpilot.com/mcp als Nachfolger von https://mcp-coach-v1.skillpilot.com/mcp; reale Host-Abnahme, Cutover-Rollout und Verzeichnis-Veröffentlichung bleiben getrennte Schritte). Das Backend hält diese Spur strikt getrennt von Visible-Session-Tabellen und Claude-Verbindungen.

Der geschützte /mcp-Endpunkt nutzt serverauthentifiziertes HTTPS, OpenAI-Connector-mTLS und ein gültiges OAuth-Access-Token; ein dedizierter Nginx-vHost leitet ausschließlich /mcp auf den Loopback-Handler /internal/openai/v1/mcp weiter (siehe 2). Für das gehostete ChatGPT-Verzeichnisprofil akzeptiert der Authorization Server genau den vorkonfigurierten vertraulichen OAuth-Client (client_secret_basic + PKCE S256 + exakte Prüfung von Client-ID, Redirect-URI, Resource, Audience und Scopes; Ablage des Client-Secrets nur in ChatGPT-Appkonfiguration und SkillPilot-Secret-Store); für die explizit autorisierte native Windows-Desktop-Route dient ein separates, exakt gepinntes öffentliches CIMD-Profil mit PKCE S256, das niemals als Fallback einer fehlgeschlagenen vertraulichen Authentisierung fungiert. Offene DCR, ungepinnte CIMD, none, private_key_jwt und implizite Profilwechsel sind ausgeschlossen. Der mTLS-Rand prüft OpenAIs veröffentlichte CA-Kette, clientAuth-EKU und den exakten Connector-SAN und speichert nur die feste Klassifikation (VERIFIED, temporär OBSERVE_NO_CERT oder Loopback LOCAL_OPERATOR), niemals das Zertifikat selbst (observe dient dem Integrationsnachweis; eine Verzeichnis-Veröffentlichung verlangt enforce).

Gespeichert werden die OAuth-Autorisierungs-, Consent-, Code-, opaken Access- und rotierenden Refresh-Token-Daten sowie je explizitem Lernen starten ein separater Lernsession-Datensatz mit ausschließlich HMAC-Hash der hochentropischen Referenz, Lernendenzuordnung, started_at, expires_at und Widerrufsmetadaten. OAuth authentisiert die App, die Session adressiert den Lernenden: Jeder fachliche MCP-Aufruf verlangt beides zugleich. Die Start-Intents sind eng begrenzt (aktuelle Lerneinheit, Verified Recall mit Ziel und Batchgröße sowie geprüfter Abi-2026-Prüfungseinstieg mit Ziel und Kursniveau); freie Browser-Prompts werden nicht als Startzustand persistiert.

Anlegen oder Laden der dauerhaften SkillPilot-ID, Bestätigen der Provider-Hinweise sowie die gesamte Level-2-Personalisierung erfolgen ausschließlich im First-Party-WebGUI. ChatGPT hält OAuth-Tokens als reine Transport-Credentials im Authorization-Header (unsichtbar für Nutzende und außerhalb von Modellprompts/Argumenten), während die temporäre learningSessionId automatisch in den Startprompt für fachliche Toolaufrufe eingesetzt wird, ohne die dauerhafte SkillPilot-ID preiszugeben. Über CoachStateProjection projiziert MCP nur den benötigten Workflow-Kontext; Prüfungslösungen und Bewertungsschemata erfordern den autorisierten Evaluationspfad, und Recall-Antworten werden erst nach dem Antwortschritt der Lernenden freigegeben.

1.2. E. Aktive Claude-V1-OAuth/MCP-Daten

Claude ist der aktive Lern-Beta-Provider: Der persönliche Marketplace liefert Plugin-Paket und Coach-Anweisungen, während fachliche Operationen die isolierte Claude-V1-MCP-Grenze über HTTPS und OAuth aufrufen. Das Claude-Autorisierungs-Principal ist eine generierte, lernendenunabhängige technische Verbindungsreferenz statt der dauerhaften SkillPilot-ID. Jeder explizite Start im First-Party-WebGUI erzeugt eine frische, exakt 24 Stunden gültige Lernsession-Referenz (gespeichert als Hash, Lernendenzuordnung, Erstellungs-/Ablaufzeitpunkt, Locale und Zustandsversion; weder Chataktivität noch OAuth-Refresh verlängern sie). Fachliche Aufrufe erfordern sowohl gültiges OAuth als auch die temporäre Lernsession.

Claudes Client-Authentisierungsprofile sind von OpenAI getrennt (unterstützt werden das eingeschränkte öffentliche Claude-CIMD-Profil sowie ein explizit konfiguriertes vertrauliches Profil mit PKCE und providerspezifischer Prüfung; OpenAI-Connector-mTLS gilt nicht für Claude, und eine öffentliche Client-ID ist kein Geheimnis). Projizierte Kontextdaten enthalten keinen dauerhaften Lernendenschlüssel, bleiben aber pseudonyme Lerndaten. Eingehende Operationen akzeptieren ausschließlich strukturierte Ziel-/Kartenreferenzen, Sprache, Nebenläufigkeits-/Idempotenzschlüssel, autorisierte Capability-Referenzen und eng begrenzte Entscheidungen (optionaler numerischer Prüfungsscore; boolesches passed je Recall-Karte); nicht unterstützte Ergebnisfelder werden vor Mutation und Replay-Speicherung abgewiesen, während Antworten, Fotos, Spracheingaben und Erklärungen im Claude-Chat bleiben (ClaudeV1AppAuthenticationFilter, ClaudeV1LearningSessionService, ClaudeV1McpContractAdapter, ClaudeV1CoachContextProjector).

1.2. F. Bewusst eingereichtes Lernziel-Feedback

Cockpit und Lernzielbuch öffnen dasselbe freiwillige öffentliche Feedback-Formular (credentials: 'omit', Übergabe nur des öffentlichen Ziel-/Buchkontexts ohne Lernenden-ID, kein automatischer Export aus Provider-Chats). Unter eigenem Hinweis und expliziten Bestätigungen erfasst es Kategorie, Beobachtung sowie optional Begründung/Beleg, Vorschlag, Quelle und Perspektive ohne Namens-, E-Mail- oder Anhangsfelder (Nutzende werden angewiesen, keine Chats, Zugangsdaten oder unnötigen Personendaten einzufügen, da Längen-/Feldprüfungen freie Personendaten nicht erkennen).

goal_feedback_submission speichert den Text mit zufälligen Feedback-/Einreichungs-IDs, Eingangszeitpunkt, öffentlicher Ziel-/Buch-/Seitenbindung samt Fingerprints, Hinweisversion/-sprache, Bestätigungen und technischen Digests ohne Lernenden-Fremdschlüssel (das Rate-Limiting hasht die Client-IP kurzlebig im Speicher, was keine Aussage über Infrastruktur-Logs trifft). Offene Einträge werden nach 30 Tagen zur Löschung fällig (tägliche Bereinigung plus Bereinigung bei Intake/Export, daher nennt das Formular höchstens 31 Tage im Online-Posteingang). Betreiber exportieren Batches lokal nach tmp/goal-feedback/inbox/<export-id> und quittieren den Digest erst nach verifizierter Speicherung, wodurch der Online-Inhalt gelöscht wird und nur ein inhaltsfreier Batch-Beleg verbleibt. Exportierte Texte dürfen für die offengelegte technisch unterstützte Prüfung genutzt werden; lokale Rohdateien und Codex-Protokolle bilden eigene Aufbewahrungsgrenzen mit manueller Löschpflicht nach Abschluss gemäß Feedback-Intake-Runbook (GoalFeedbackSubmissionService, GoalFeedbackRetentionService, GoalFeedbackExportService, GoalBookFeedbackPilotView.tsx). Widerrufs- oder Löschwünsche laufen über support@skillpilot.com (vorzugsweise mit Feedback-ID).

1.3. Datenfluss-Szenarien

Individuelle Anmeldung: Beim Öffnen von https://skillpilot.com erzeugt der Browser eine SkillPilot-ID, entsperrt ein gespeichertes Profil oder übernimmt eine vorhandene ID, speichert Curriculum und Konfiguration pseudonym im Backend und öffnet das Cockpit oder startet eine verfügbare Coach-Integration.
Claude-Beta-Verbindung und Lernstart: Nach Plugin-Installation und OAuth-Verbindung (getrennt vom Lernendenprofil) wählt die Person im SkillPilot-WebGUI ihren Kontext und startet über Lernen starten eine 24-stündige Claude-Lernsession; Claude nutzt OAuth + temporäre Referenz für MCP-Tools, bewertet Antworten im Chat und sendet nur strukturierte Ergebnisse an SkillPilot zurück.
Historische ChatGPT Visible Session (nur Rollback): POST /api/ui/learners/{skillpilotId}/visible-chat-start erzeugt ein maximal 24 Stunden gültiges sps_...-Token (serverseitig als HMAC-Hash) und öffnet den sprachspezifischen Custom GPT gegen /api/ai/{lang}/sessions/.../visible.
Kandidaten-Abnahme — OpenAI-V1-App-Verbindung: Nach browserlokaler Bestätigung der länderspezifischen Alters-/Erziehungsberechtigtenregeln (ohne Geburtsdatum und ohne Altersableitung aus Jahrgangsstufen) durchläuft ChatGPT OAuth Authorization Code + PKCE S256 gegen das gepinnte Clientprofil (client_secret_basic für die gehostete App bzw. separates gepinntes Desktop-CIMD-Profil) und erhält resource-/scope-gebundene Tokens ohne Lernendenauswahl.
Öffnen des MCP-Coaches ohne vorbereitete Session: Fehlt eine learningSessionId, ruft das Modell kein Tool auf, fragt weder dauerhafte noch temporäre IDs ab und verweist lokalisiert auf https://skillpilot.com/ und Lernen starten.
Kandidaten-Abnahme — OpenAI-Session mit Backend-Locale: Jeder Klick auf Lernen starten erzeugt eine frische 24-Stunden-Session (HMAC-Hash, Lernendenzuordnung, communicationLocale, started_at, expires_at, Widerrufsdaten; wiederholte Starts erzeugen getrennte Sessions ohne Verlängerung älterer) und fügt die Referenz automatisch in die Startnachricht ein; das Backend verlangt für jeden Fachaufruf gültiges OAuth und gültige Session ohne Fallback.
Widerruf der App-Autorisierung & Cockpit-Einsicht: Ein serverseitiger OAuth-Widerruf entwertet Autorisierung und Access-/Refresh-Tokens sofort, lässt getrennte Session-Datensätze ohne gültiges OAuth unbenutzbar und erhält den pseudonymen Lernfortschritt. Die Cockpit-Einsicht (GET /api/ui/learners/{skillpilotId}/state) findet ausschließlich zwischen Browser und SkillPilot-Backend statt.

1.4. Aufbewahrung und Löschung

Die Repository-Standardlaufzeiten für Zugangsdaten in Claude V1 und dem OpenAI-V1-Kandidaten betragen:

OAuth-Access-Token: 1 Stunde;
Rotierendes Refresh-Token: 30 Tage;
Claude-V1-Lernsession: feste 24 Stunden ab dem First-Party-Start;
OpenAI-V1-Lernsession: exakt 24 Stunden ab der bestätigten First-Party-Aktion Lernen starten.

Die Ablauffrist einer Lernsession wird weder durch MCP-Aufrufe noch durch Access-Token-Refresh, Browser-Reload, neuen Chat oder Kontextkompaktierung verlängert. Refresh-Token-Rotation kann die Token-Gültigkeit fortschreiben und darf nicht als automatische Löschung aller Verbindungsdaten nach 30 Tagen beschrieben werden; abgelaufene Session-Zeilen werden standardmäßig stündlich bereinigt. OAuth-Laufzeiten sind keine allgemeine Datenbank-Löschfrist für abgelaufene Autorisierungs-, Consent- oder Diagnosedatensätze, und das Löschen eines Lernenden entfernt nicht automatisch jede lernendenunabhängige technische Provider-Autorisierung. Historische Visible-Session-Tokens laufen nach höchstens 24 Stunden ab; Lernfortschritt wird niemals durch Ablauf oder Widerruf einer KI-Verbindung gelöscht.

Der aktive Lernstand unter einer SkillPilot-ID in der SkillPilot-Datenbank einschließlich zugehöriger SkillPilot-Lernsessions und lernendengebundener Verbindungen unterliegt einer gemeinsamen Löschgrenze:

die lernende Person kann ihn jederzeit manuell über die vorgesehene WebGUI-Funktion löschen; und
nach 365 aufeinanderfolgenden Tagen ohne erfolgreiche Aktivität wird er zur automatischen Löschung fällig und beim nächsten automatischen Löschlauf entfernt.

Als Aktivität zählen ausschließlich folgende erfolgreich abgeschlossene Vorgänge:

erfolgreiche Erstellung einer SkillPilot-ID;
das aktive Laden oder Fortsetzen des Lernstands in der SkillPilot-Weboberfläche;
ein vom Server abgeschlossener Import oder Export signierter Lerndaten;
eine serverseitig erfolgreich gespeicherte Änderung des Lernstands;
eine erfolgreich abgeschlossene SkillPilot-Sitzungs- oder KI-Anbieter-Verbindungsaktion; oder
ein gültiger Coach-/MCP-Aufruf, den SkillPilot mit einem fachlich erfolgreichen Ergebnis abschließt.

Hintergrund-GET-Anfragen, SSE-Verkehr, OAuth-Token-Aktualisierungen, das bloße Auswählen, Öffnen oder Lesen einer lokalen Datei sowie vom Server nicht abgeschlossene oder fachlich abgewiesene Aktionen zählen nicht und starten die 365-Tage-Frist nicht neu.

Nach der Löschung hat die dauerhafte SkillPilot-ID keinen Zugriff mehr auf diesen Lernstand, zugehörige Lernsessions und lernendengebundene Verbindungen sind unbenutzbar, und eine getrennt bestehende technische OAuth-Autorisierung kann den gelöschten Lernenden weder wiederherstellen noch auswählen. Mangels Klarnamenbindung erfordern Auskunfts- oder Löschwünsche zu einem Lernprofil einen verhältnismäßigen Zugriffsnachweis über einen vereinbarten sicheren Kanal (der Support darf dauerhafte IDs oder temporäre Credentials niemals per gewöhnlicher E-Mail anfordern; Feedback-Anfragen nutzen ihre Feedback-ID). Lokale Dateien und Provider-Chats sind von dieser Löschung unberührt. Bestehende Sicherungskopien gehören nicht zum aktiven Lernstand; weder manuelle Löschung noch der 365-Tage-Ablauf löschen sie unmittelbar einzeln.

Klartext-Sessionreferenzen, OAuth-Credentials/-Secrets, Request-Bodies, Antworten von Lernenden und Startgeheimnisse dürfen nicht in Anwendungs-, Reverse-Proxy-, Trace- oder Support-Logs gelangen. Der allgemeine RequestLoggingFilter überspringt geschützte MCP-, OAuth-, Feedback- und Coach-Ergebnisrouten vollständig, während die begrenzte OAuth/MCP-Telemetrie nur Operation, Ergebnis, Latenz, Korrelations-IDs und HMAC-abgeleitete Session-Fingerprints ohne freie Toolargumente erfasst. Andere API-Routen können auf DEBUG feldredigierte, größenbegrenzte Bodies protokollieren; optionales AI-Tracing (tmp/ai-trace.jsonl, standardmäßig aus) nutzt Feld-/Tokenmuster-Redaktion statt allgemeiner Personendatenerkennung und besitzt weder automatische TTL noch Kopplung an die Lernendenlöschung. Ebenso wird das Legacy-Feld ChatStartRequest.promptContext (auf 2.000 Zeichen gekürzt, nicht in der Session gespeichert) vom allgemeinen Debug-Logger nicht als Ganzes redigiert und darf nicht ohne Textprüfung beworben oder getraced werden.

1.5. Sicherung, Wiederherstellung und verbleibende Betriebsregeln

Lernende und Bildungseinrichtungen tragen selbst die Verantwortung für die Aufbewahrung ihrer Zugriffsschlüssel und externen Namenszuordnungen: Signierte Exporte/Importe übertragen Lernstände zwischen Browsern, passwortgeschützte ID-Dateien sichern die SkillPilot-ID verschlüsselt, lokale Klassenexporte verschlüsseln Lehrkraft-Listen (Passwortpflege und Altdatenlöschung liegen bei der Einrichtung), ein Logout leert nur die aktive Browsersitzung, und eine serverseitige Lernendenlöschung belässt lokale Exporte/ID-Dateien auf den Endgeräten.

scripts/backup_db.sh setzt restriktive Dateirechte, nutzt standardmäßig BACKUP_RETENTION_DAYS=30, erstellt SQL-Dumps ohne Feedback-Inhaltstabellen und entfernt überalterte Dateien nur bei erfolgreichen Sicherungsläufen (ohne eigene Dump-Verschlüsselung im Skript und ohne stundengenaue 30-Tage-Garantie). application.yml schreibt standardmäßig INFO-Logs nach logs/skillpilot.log mit 10-MB-Rotation und max-history: 7; die realen produktiven Fristen für Anwendungs-, Proxy-, Trace-, Snapshot-, WAL- und Offsite-Kopien sind gesondert betrieblich zu bestätigen und dürfen nicht stillschweigend mit aktiver Lernenden- oder Online-Feedback-Löschung gleichgesetzt werden.

Wesentliche Betriebsregeln und Restrisiken:

Zugangsdaten im Betrieb und Support: Aktive Lernsession-Referenzen (Claude, OpenAI oder historische sps_...-Tokens) sowie OAuth-Access-/Refresh-Tokens sind Inhaber-Credentials — unredigierte Chats, Screenshots, Browserchroniken, HAR-Dateien oder Logs dürfen niemals geteilt werden, während kanonische Lernziel- und Karten-IDs öffentliche technische Referenzen sind.
Reichweite von Dateiverschlüsselung und Provider-Chats: Die Verschlüsselung von Klassenexporten schützt die heruntergeladene Datei im Ruhezustand und erkennt Manipulationen, verschlüsselt aber weder den aktiven Browserspeicher skillpilot_classes noch ein entsperrtes Gerät. Lernende sind darauf hinzuweisen, keine sensiblen Personendaten in den KI-Chat einzugeben oder hochzuladen, da der Provider diese nach eigenen Bedingungen verarbeitet und eine SkillPilot-Löschung keinen Provider-Chat entfernt.
Wahrheitsgemäße Release-Gates: Visible Session bleibt reiner Rollback-Pfad, und weder OpenAI-Kandidatencode noch Claude-Verfügbarkeit belegen eine Host-Abnahme auf einem anderen Client. Vor jedem providerspezifischen Release oder Cutover sind Datenschutzhinweise, Provider-Angaben, reale Aufbewahrungs-/Logging-/OAuth-Profile, echtes Widerrufsverhalten und offene Auftragsverarbeiter-/Backup-Bestätigungen gegen das konkrete Release zu prüfen.