Wie Sie mit der Git-Historie von Overleaf unberechtigte KI-Verdachtsmomente entkräften

Ja. Prüfungsausschüsse und Ethikkommissionen verlangen einen lückenlosen Herkunftsnachweis (Provenance) – also einen nachprüfbaren Entstehungsprozess, der belegt, dass ein Dokument über einen längeren Zeitraum schrittweise verfasst wurde. Turnitin, iThenticate und GPTZero bewerten lediglich das finale, statische PDF. Sie vergeben eine Wahrscheinlichkeitsbewertung anhand von Perplexität und Burstiness, können jedoch nicht nachvollziehen, wie das Dokument tatsächlich entstanden ist.

Overleaf hingegen dokumentiert den gesamten Entstehungsprozess. Da wissenschaftliche und mathematische Texte auf eine präzise, passive und formale Sprache angewiesen sind, schlagen KI-Detektoren bei Arbeiten aus dem MINT-Bereich besonders häufig fälschlicherweise an. Ein KI-Detektor behauptet damit im Grunde, Ihr Text sei schlagartig durch einen generativen Prompt entstanden. Eine nachvollziehbare Overleaf-Historie beweist genau das Gegenteil: Hunderte schrittweise Änderungen, Syntaxkorrekturen, umbenannte Variablen und verfeinerte Theoreme, die sich über Wochen oder Monate erstrecken.

Wenn Sie ein kryptografisch gesichertes Protokoll Ihres Schreibprozesses vorlegen, ersetzen Sie bloße algorithmische Wahrscheinlichkeiten durch handfeste Beweise. Ein Prüfungsausschuss kann einen Vorwurf des Fehlverhaltens kaum aufrechterhalten, wenn ihm überprüfbare, mit verlässlichen Zeitstempeln versehene Revisionsdaten vorliegen.

Overleaf bietet zwei grundlegend verschiedene Tracking-Mechanismen. Den Unterschied zu kennen ist entscheidend dafür, wie Sie Ihre Beweise extrahieren und aufbereiten:

1. Der Web-Revisionsverlauf (History-Tab):

Der Web-Editor fasst einzelne Tastaturanschläge zu zusammenhängenden Bearbeitungssitzungen zusammen und stellt Änderungen im direkten visuellen Vergleich dar. Sie sehen genau, welcher Autor welche Passagen geändert hat, und können frühere Stände wiederherstellen. Allerdings sind die Exportmöglichkeiten der Weboberfläche eingeschränkt. Bei kostenlosen Konten beschränkt Overleaf die Ansicht zudem auf kürzliche Bearbeitungen (in der Regel die letzten 24 Stunden), wenngleich der vollständige Verlauf im Hintergrund gespeichert bleibt und nach einem Upgrade des Projekts sofort wieder einsehbar ist.

1. Die zugrunde liegende Git-Bridge und GitHub-Synchronisierung:

Jedes Overleaf-Projekt basiert im Hintergrund auf einem regulären Git-Repository. Über den direkten Zugang per Git-Bridge (`git.overleaf.com`) bei Premium- oder Campus-Lizenzen sowie über die native GitHub- bzw. GitLab-Integration können Sie mit Ihrem Projekt wie mit jedem gewöhnlichen Versionskontrollsystem arbeiten.

Während die Weboberfläche für den persönlichen Überblick genügt, erfordert ein formelles Widerspruchsverfahren übertragbare und manipulationssichere Nachweise. Durch den Export des zugrunde liegenden Git-Verzeichnisbaums erhalten Sie exakte Commit-Hashes, Autoren-Metadaten, doppelte Zeitstempel (Author-Date gegenüber Commit-Date) sowie maschinenlesbare Diff-Dateien, die jedes Kommissionsmitglied aus der Informatik oder den Ingenieurwissenschaften unabhängig überprüfen kann.

Um Ihren Bearbeitungsverlauf vor dem Prüfungsausschuss vorzulegen, klonen Sie das rohe Git-Repository auf Ihren lokalen Rechner und erstellen ein sauberes Prüfprotokoll.

1. Projekt-Repository klonen: Wenn Ihre Hochschule Overleaf Professional bereitstellt oder Sie einen Premium-Tarif nutzen, klonen Sie das Projekt direkt über die Overleaf-Git-Bridge mit `git clone https://git.overleaf.com/[project-id] thesis-appeal-repo`. Ist Ihr Projekt mit GitHub oder GitLab synchronisiert, klonen Sie stattdessen das entsprechende Remote-Repository mit `git clone https://github.com/[username]/[repository-name].git thesis-appeal-repo`.

1. Vollständige Commit-Metadaten mit Zeitstempeln exportieren: Führen Sie `git log` mit dem Flag `--pretty=fuller` aus: `git log --pretty=fuller --stat > commit_timeline_summary.txt`. Dadurch werden sowohl das `AuthorDate` (wann die Bearbeitung vorgenommen wurde) als auch das `CommitDate` (wann der Commit auf dem Remote-Server eingegangen ist) ausgegeben. Da Server-Zeitstempel nicht durch Manipulation der lokalen Systemzeit verändert werden können, dienen sie als verlässlicher, extern beglaubigter Zeitnachweis.

1. Zeilenweise Diffs für beanstandete Abschnitte erstellen: Um nachzuweisen, dass Sie ein bestimmtes Kapitel oder einen Abschnitt manuell verfasst haben, exportieren Sie den vollständigen historischen Diff dieser Datei mit `git log -p -w --reverse -- main.tex > main_tex_evolution.diff`. Alternativ können Sie Commits isolieren, die ein bestimmtes Theorem betreffen: `git log -S "theorem:convergence" -p -- sections/methodology.tex > convergence_proof_steps.diff`. Diese Ausgabe dokumentiert jede Hinzufügung und Löschung im standardisierten Unified-Diff-Format und belegt die zeitliche Abfolge Ihres Entwurfs.

Während geisteswissenschaftliche Arbeiten vor allem auf Umformulierungen auf Wortebene beruhen, weisen MINT-Arbeiten unverwechselbare technische Merkmale auf, die große Sprachmodelle bei der einmaligen Textgenerierung nicht erzeugen.

1. Schrittweise mathematische Herleitungen: KI-Modelle erzeugen vollständige LaTeX-Gleichungen in einem einzigen Durchlauf. Menschliche Forscher hingegen machen Notationsfehler, passen Indizes an, korrigieren Vorzeichen und teilen lange Ausdrücke über mehrere Kompilierungsversuche hinweg auf mehrzeilige Umgebungen auf. In einem authentischen Repository erfasst ein früher Commit etwa eine grundlegende Verlustfunktion (`\mathcal{L}(\theta) = \sum \log P - \lambda \sum \|\mathbf{w}_k\|_2^2`), während nachfolgende Commits Regularisierungsterme verfeinern (`-\frac{\lambda}{2} \sum \|\mathbf{w}_{k, t}^{(j)}\|_2^2`) und Dimensionsindizes vereinheitlichen. Diese schrittweise Anpassung der mathematischen Notation liefert den empirischen Beweis einer echten gedanklichen Ausarbeitung.

1. Fehlerbehebungszyklen beim Kompilieren in LaTeX: Wer manuell in LaTeX schreibt, stößt immer wieder auf Kompilierungsfehler: nicht geschlossene Klammern, nicht maskierte Sonderzeichen, fehlende Pakete oder fehlerhafte Querverweise. Ihr Git-Log enthält Zwischen-Commits, die ganz konkrete Compiler-Fehler beheben (etwa das Schließen eines offenen `\left(` mit einem `\right)` oder das Ersetzen eines ungültigen `\cite`-Schlüssels). Solche kleinteiligen Fehlerbehebungs-Commits existieren bei rein KI-generierten Texten nicht.

1. Asynchrone BibTeX-Einträge: Generative Modelle erfinden häufig Quellenangaben oder fügen Zitate gesammelt auf einen Schlag ein. In einem echten Forschungs-Repository wachsen `.bib`-Dateien hingegen kontinuierlich über die Zeit. Die Commits belegen, dass einzelne BibTeX-Einträge an unterschiedlichen Tagen hinzukamen – passend zum tatsächlichen Verlauf Ihrer Literaturrecherche:

Prüfungsausschüsse setzen sich oft sowohl aus Fachgutachtern als auch aus nicht-technischen Verwaltungsmitgliedern zusammen. Reichen Sie keinesfalls Hunderte Seiten unstrukturierte Terminalausgaben ein. Gliedern Sie Ihre Unterlagen stattdessen in ein formelles, professionelles Dossier:

1. Executive Summary (1 Seite): Nennen Sie Lehrveranstaltung, Titel der Arbeit, Dozenten sowie den beanstandeten KI-Prozentsatz von Turnitin oder iThenticate. Fassen Sie die Kennzahlen des Projekts zusammen: gesamte Bearbeitungsdauer (z. B. 47 Tage), Gesamtzahl der Commits (z. B. 114 Commits), Repository-URL und Overleaf-Projekt-ID. Formulieren Sie unmissverständlich: "The attached technical record establishes an uninterrupted drafting timeline that refutes the claim of automated text generation." (Das beigefügte technische Protokoll belegt einen lückenlosen Entstehungsverlauf, der den Vorwurf einer automatisierten Textgenerierung widerlegt.)

1. Chronologische Meilensteintabelle: Erstellen Sie eine übersichtliche Tabelle, die wichtige Meilensteine der Arbeit den entsprechenden Git-Commit-Hashes zuordnet:

1. Kommentierte Diff-Auszüge: Wählen Sie 3 bis 5 aussagekräftige Diffs aus, die Schritte der Formelherleitung, Anpassungen im Algorithmen-Pseudocode oder Überarbeitungen des Literaturteils zeigen. Fügen Sie kurze Erläuterungen hinzu, die menschliche Denk- und Entscheidungsprozesse verdeutlichen.

1. Vollständiger technischer Anhang: Fassen Sie die vollständige Ausgabe von `git log --stat` und die detaillierten Patch-Dateien in einem indexierten PDF-Anhang zusammen. Stellen Sie sicher, dass die Commit-Hashes exakt mit dem Live-Repository auf Overleaf oder GitHub übereinstimmen, damit der Ausschuss die Versionshistorie direkt nachvollziehen kann.

Wahren Sie während des gesamten Verfahrens einen sachlichen, professionellen Ton. Konzentrieren Sie sich auf die technischen Grenzen probabilistischer KI-Detektoren, anstatt die Absichten der prüfenden Personen infrage zu stellen.

Selbst wenn ein Prüfungsausschuss Ihr Git-Log als Nachweis eigenständiger Forschungsleistung anerkennt, kann die Hochschule verlangen, dass einzelne Absätze überarbeitet werden – etwa wenn für die Archivierung der Abschlussarbeit strikte Vorgaben bezüglich KI-Markierungen gelten. Bei technischen LaTeX-Dokumenten birgt das manuelle Umschreiben von Einleitungs- oder Literaturabschnitten jedoch die Gefahr, Zitationen, Querverweise (`\label{}` und `\ref{}`) oder mathematische Notationen zu beschädigen.

Importieren Sie den Turnitin- oder iThenticate-Bericht und überarbeiten Sie nur die darin markierten Passagen. Sie erhalten eine bearbeitbare Datei im selben Format zurück.

Indem Sie sich ausschließlich auf die beanstandeten Passagen konzentrieren, bleiben Ihre LaTeX-Struktur, mathematische Formeln und das Zitationsnetzwerk vollständig erhalten, während genau die Sätze entschärft werden, die von der Prüfsoftware der Hochschule markiert wurden.

Was kann ich tun, wenn ich Overleaf im kostenlosen Tarif ohne Git-Integration genutzt habe? Wenn Sie während des Schreibens weder GitHub verknüpft noch die Git-Bridge genutzt haben, steht Ihnen dennoch der History-Tab in der Weboberfläche zur Verfügung. Zeigt der kostenlose Tarif lediglich die letzten 24 Stunden an, schaltet ein Upgrade Ihres Kontos oder eine Campus-Lizenz den gesamten bisherigen Revisionsverlauf rückwirkend frei. Zudem können Sie Ihren Widerspruch durch lokal heruntergeladene Entwurfs-Archive (`.zip`), datierte PDF-Kompilate aus dem Browser-Cache sowie den Browserverlauf untermauern.

Können Git-Commit-Zeitstempel gefälscht werden, um einen Widerspruch zu konstruieren? Zwar lassen sich lokale Zeitangaben über die Umgebungsvariable `GIT_AUTHOR_DATE` manipulieren, die von Overleaf oder GitHub beim Push aufgezeichneten Server-Zeitstempel können Nutzer jedoch nicht verändern. Das `CommitDate` des Servers dokumentiert den exakten Eingangszeitpunkt im Netzwerk. Darüber hinaus ist es praktisch unmöglich, Dutzende stimmige, funktionsfähige Zwischenstände in LaTeX mit authentischen Syntaxfehlern und schrittweisen Formelanpassungen überzeugend automatisiert zu fälschen.

Prüfen Turnitin und iThenticate die Git-Historie von Overleaf automatisch? Nein. Turnitin und iThenticate analysieren ausschließlich das Dokument, das im Hochschulportal hochgeladen wurde (in der Regel eine PDF- oder Word-Datei). Sie verfügen über keinerlei Schnittstelle zu Overleaf, GitHub oder anderen Schreibumgebungen. Sie untersuchen rein statistische Textmuster nach der Einreichung – weshalb Studierende ihren Versionsverlauf selbstständig exportieren und vorlegen müssen.

Verstehen auch nicht-technische Ausschussmitglieder ein Git-Log? Viele Mitglieder aus Fachbereichen außerhalb der MINT-Fächer sind mit der Syntax von Git nicht vertraut. Genau deshalb sind Ihre einseitige Zusammenfassung und die übersichtlichen Diff-Tabellen so wichtig. Lehrende aus den MINT-Fächern oder technische Berater im Prüfungsausschuss verstehen Versionskontrollsysteme jedoch sofort – und kryptografisch nachvollziehbare Commit-Historien Dritter bieten eine objektive Grundlage für Ihre akademische Verteidigung.