Zum Inhalt
PlagiatScanner.de
Hochschulpraxis · Handlung · HSP-10

Plagiatssoftware datenschutzseitig prüfen

Direktantwort: Inventarisiere zuerst Dokumenttypen, betroffene Personen und tatsächliche Datenwege. Ordne jedem Zweck eine belastbare Rechtsgrundlage, Rolle, Empfängergruppe, Speicherfrist und Löschprüfung zu. Kläre gesondert, ob Einreichungen nur analysiert, in eine Vergleichsdatenbank aufgenommen oder für weitere Zwecke verwendet werden. Anbieterangaben und Vertragstext reichen nicht allein: Die Hochschule braucht technische und organisatorische Nachweise sowie einen geprüften Betriebsprozess.

Datenfluss-Auftrag-Löschung-Datenbank-RasterFachstand 11. September 2026

Den konkreten Hochschulprozess statt nur das Produkt prüfen

Erfasse Bachelor- und Masterarbeiten, Hausarbeiten, Prüfungsentwürfe, veröffentlichte Texte und freiwillige Vorabprüfungen getrennt. In Dokumenten können Namen, Matrikelnummern, Gesundheitsdaten, Interviewaussagen, unveröffentlichte Forschung, Betriebsgeheimnisse oder Daten Dritter stehen. Auch Dateiname, Nutzerkonto, IP-Adresse, Protokoll und Prüfbericht sind mögliche personenbezogene Daten.

Zeichne den Weg vom Upload über Verarbeitung und Ergebnisbereitstellung bis Archivierung und Löschung. Berücksichtige Lernplattform, Identitätsdienst, Support, Subunternehmen, Backups und Vergleichsdatenbank. Ein Serverstandort beantwortet nicht automatisch, wer Zugriff hat, welche Transfermechanismen gelten oder ob Daten zu eigenen Anbieterzwecken verarbeitet werden.

Authority Asset: Datenfluss-Auftrag-Löschung-Datenbank-Raster

Prüffelder mit erforderlichem Nachweis
FeldKernfrageNachweisStoppsignal
DatenflussWelche Daten gehen wohin?Aktuelles Flussdiagramm, Schnittstellen, EmpfängerUnbekannte Subprozessoren
Zweck/RechtsgrundlageWarum wird jeder Datentyp verarbeitet?Zweckzuordnung und institutionelle PrüfungPauschale Einwilligung als Ersatz
Auftrag/RollenWer entscheidet, wer verarbeitet?Vertrag, Weisungen, VerantwortungsmatrixRollenwiderspruch
LöschungWann verschwinden Datei, Bericht, Logs, Backups?Fristen, Löschjob, Protokoll und StichprobeNur unverbindliche Zusage
DatenbankWird die Arbeit künftig verglichen?Opt-in/out-Regel, Zweck und ZugriffsmodellUnklare dauerhafte Aufnahme
SicherheitWie werden Zugriff und Übertragung geschützt?Berechtigungen, Verschlüsselung, VorfallprozessGeteilte Konten oder öffentliche Links
BetroffenenrechteWie werden Anfragen bearbeitet?Kontakt, Identifikation, Frist- und FallprozessAnbieter und Hochschule verweisen aufeinander

Verantwortung, Auftrag und Anbieterzwecke abgrenzen

Prüfe, ob der Anbieter ausschließlich dokumentierte Weisungen ausführt oder eigene Zwecke verfolgt. Produktverbesserung, Missbrauchsanalyse, Support und Aufbau einer Vergleichsdatenbank können unterschiedliche Rollen und Rechtsfragen auslösen. Der Vertragsname „Auftragsverarbeitung“ entscheidet nicht allein; tatsächliche Funktionen, Einstellungen und Datenverwendung müssen dazu passen.

Inventarisiere Unterauftragnehmer, Leistungsorte und Änderungsmechanismen. Kläre, wie die Hochschule über neue Empfänger informiert wird und widersprechen kann. Für Übermittlungen außerhalb des Europäischen Wirtschaftsraums braucht es eine gesonderte, aktuelle Prüfung der einschlägigen Grundlage und Risiken. Behaupte keine DSGVO-Konformität nur aufgrund eines Logos oder Anbieterlabels.

Lege intern fest, wer Uploads starten, Berichte lesen, Supportfälle eröffnen, Datenbankaufnahmen steuern und Löschungen kontrollieren darf. Rollenbasierte Konten und Protokolle sind überprüfbarer als geteilte Zugangsdaten. Ein Supportticket darf nicht automatisch den kompletten Studierendentext enthalten.

Analyse und dauerhafte Vergleichsnutzung getrennt entscheiden

Eine einmalige Ähnlichkeitsprüfung und die Aufnahme in einen künftigen Vergleichsbestand sind verschiedene Zwecke. Dokumentiere, ob Speicherung standardmäßig erfolgt, welche Organisationen später Treffer sehen, ob nur Fingerprints oder vollständige Texte verbleiben und wie ein Ausschluss technisch wirkt. Prüfe auch Versionen, Entwürfe und versehentlich hochgeladene Dateien.

Ein Löschknopf in der Oberfläche ist noch kein Nachweis vollständiger Löschung. Erfasse Primärspeicher, Suchindex, Bericht, Protokolle, Supportkopien und Backups. Teste den vorgesehenen Löschprozess mit freigegebenen synthetischen Daten und dokumentiere, was tatsächlich bestätigt wird. Leite daraus keine Aussage über nicht sichtbare Systeme ab.

Informiere Studierende verständlich über Verantwortliche, Zweck, Datenkategorien, Empfänger, Speicherung, Rechte und Kontakt. Verstecke die Datenbankaufnahme nicht in einer langen Werkzeuganleitung. Wo eine Wahl vorgesehen ist, muss sie technisch und organisatorisch tatsächlich umgesetzt werden.

Beschaffung, Pilot und laufende Kontrolle verbinden

Fordere vor Vertragsschluss überprüfbare Antworten, Konfigurationsdokumentation, aktuelle Unterauftragnehmerliste, Sicherheitsnachweise, Löschkonzept und Vorfallweg. Datenschutz ist kein einmaliger Fragebogen. Produktupdates, neue KI-Funktionen oder geänderte Datenbanken können die Bewertung verändern. Definiere Änderungsprüfung und Ausstieg einschließlich Datenrückgabe und Löschung.

Ein Pilot verwendet synthetische oder ausdrücklich freigegebene Dokumente. Prüfe Berechtigungen, Ergebniszugang, Support, Löschung und Protokollierung. Ein erfolgreicher Upload beweist weder korrekte Löschung noch die rechtliche Zulässigkeit des späteren Regelbetriebs. Betriebsfreigabe und technische Funktionsprüfung bleiben getrennte Tore.

Der Hub Hochschulpraxis bündelt weitere institutionelle Prüfungen. Die Beschaffungsmatrix für KI-Detektoren ergänzt Qualitäts- und Governancefragen. Genau eine Grundlagenseite ist verlinkt: Wissenschaftlich arbeiten.

Freigabecheck für den tatsächlichen Betrieb

  • Datenarten und Wege sind vollständig inventarisiert.
  • Jeder Zweck besitzt geprüfte Grundlage und verantwortliche Rolle.
  • Analyse und Vergleichsdatenbank sind getrennt beschrieben.
  • Unterauftragnehmer und Transfers sind aktuell geprüft.
  • Löschung umfasst alle benannten Speicherarten und wird kontrolliert.
  • Betroffeneninformation entspricht der echten Konfiguration.
  • Änderungen lösen eine erneute institutionelle Prüfung aus.

Dokumentierte Rückfragen und Antworten des Anbieters gehören ebenfalls in das Evidenzregister, damit spätere Verantwortliche die Bewertungsgrundlage ohne Vermutungen nachvollziehen können.

Nachweise für Betrieb und Änderungen pflegen

Die Prüfung endet nicht mit der Beschaffungsentscheidung. Für den Betrieb braucht die Hochschule ein kleines Evidenzregister: geprüfte Produktversion, aktivierte Funktionen, Empfängerkategorien, vereinbarte Löschwege, Datum des letzten Tests und verantwortliche Stelle. Eine Testlöschung sollte nicht nur im Administrationsfenster bestätigt werden. Soweit technisch und vertraglich prüfbar, ist festzuhalten, ob Arbeitskopien, Protokolle, Sicherungen und Vergleichsspeicher von derselben Regel erfasst werden oder eigene Fristen besitzen. Bleibt ein Teil nicht verifizierbar, gehört genau diese Lücke in die Freigabeentscheidung.

Bei neuen Schnittstellen, geänderten Speicherorten, zusätzlichen Analysefunktionen oder einem Wechsel von Unterauftragnehmern wird das Raster erneut geprüft. Auch ein Störungsfall lässt sich als Tischübung durchspielen: Wer stoppt Übermittlungen, wer informiert Datenschutz und Informationssicherheit, und welche Fallakte erlaubt eine spätere Rekonstruktion? Das Ergebnis ist kein allgemeines Gütesiegel für die Software. Es belegt nur, welche konkrete Konfiguration die Hochschule zu einem bestimmten Zeitpunkt anhand welcher Unterlagen und Tests bewertet hat.

Offizielle Grundlagen

  1. Europäische Union: Datenschutz-Grundverordnung – Grundsätze, Rollen, Rechte und Sicherheit.
  2. Europäischer Datenschutzausschuss: Guidelines 07/2020 on controller and processor – funktionale Rollenabgrenzung.
  3. BfDI: Datenschutz-Folgenabschätzungen – offizielle Orientierung für risikobezogene Prüfung.

Quellenstand: 4. September 2026. Die konkrete Rechtsprüfung bleibt den zuständigen Stellen vorbehalten.