Anlage zur Betriebsvereinbarung: CodeLotse &ZeroWidthSpace;

Status: Template — to be reviewed by the controller's DPO / counsel. Draft of 2026-10-13; not reviewed yet. Entwurf; ersetzt keine Rechtsberatung und keine Verhandlung mit dem Betriebsrat.

English summary at the end of this document.

Diese Anlage beschreibt das System CodeLotse für eine Betriebsvereinbarung nach § 87 Abs. 1 Nr. 6 BetrVG. Arbeitgeber und Betriebsrat passen sie an den Betrieb an. Platzhalter stehen in spitzen Klammern (<…>). Hersteller (Anbieter) des Systems ist die Quavon UG (haftungsbeschränkt); in der gehosteten Edition ist sie zusätzlich Auftragsverarbeiter des Arbeitgebers.

1. Gegenstand &ZeroWidthSpace;

1.1 Gegenstand ist die Einführung und Anwendung von CodeLotse <Version, selbst betrieben / gehostet> im Betrieb <Betrieb / Unternehmen>. 1.2 CodeLotse unterstützt die Softwareentwicklung in den angebundenen Repositories <Liste oder „alle Repositories der Organisation …“> des Git-Hosts <z. B. GitHub>.

2. Systembeschreibung &ZeroWidthSpace;

Funktion	Beschreibung	Im Betrieb aktiviert
Code-Review	Ein Sprachmodell prüft Änderungen (Pull Requests) und schreibt Hinweise zum Code	`<ja/nein>`
Issue-Triage	Vorschläge für Labels und mögliche Duplikate	`<ja/nein>`
Antworten und Chat	Antworten auf Fragen in Issues und Kommentaren	`<ja/nein>`
Korrekturvorschläge	Entwurfs-Pull-Requests für Issues, erstellt in einer abgeschotteten Umgebung	`<ja/nein>`
Akzeptanzkriterien	Abgleich eines Pull Requests mit den Kriterien des Issues	`<ja/nein>`
Zuweisungsvorschläge	Vorschläge für Reviewer und Bearbeiter (siehe Nr. 7)	`<aus / Vorschlag / automatisch>`
Team-Auswertungen	Kennzahlen auf Team-Ebene (siehe Nr. 6)	`<ja/nein>`

Das Sprachmodell wird über <Anbieter, Dienst, Region> aufgerufen. Andere Anbieter erhalten keine Daten.

3. Zwecke &ZeroWidthSpace;

3.1 Zulässige Zwecke sind ausschließlich: a) Verbesserung der Codequalität und -sicherheit, b) Unterstützung bei der Bearbeitung von Issues, c) Verteilung von Reviews und Aufgaben an Personen, die den betroffenen Code kennen, und Verbreitung von Wissen im Team (nur wenn Zuweisungsvorschläge aktiviert sind), d) Auswertungen des Entwicklungsprozesses auf Team-Ebene und Kostenkontrolle.

4. Ausschluss der Leistungs- und Verhaltenskontrolle &ZeroWidthSpace;

4.1 Das System und seine Daten werden nicht zur Leistungs- oder Verhaltenskontrolle einzelner Beschäftigter verwendet. 4.2 Insbesondere ist unzulässig, Daten aus CodeLotse zu verwenden für a) Leistungsbeurteilungen, Zielvereinbarungen, Vergütung, Beförderung, Versetzung, Abmahnung oder Kündigung, b) Rankings, Ranglisten oder Vergleiche zwischen Personen, c) Auswertungen von Arbeitszeiten, Anwesenheit oder Arbeitstempo einzelner Personen. 4.3 Erkenntnisse, die entgegen Nr. 4.1 und 4.2 gewonnen werden, dürfen nicht verwertet werden; darauf gestützte personelle Maßnahmen sind unwirksam <Formulierung durch die Betriebsparteien>.

5. Datenkategorien &ZeroWidthSpace;

Kategorie	Beispiele	Speicherdauer (Standard)
Konto- und Rollendaten	Kennung und Login beim Git-Host oder Identitätsanbieter, Rollen, Gruppen	Sitzungen höchstens 8 Stunden; Konten bis zur Entfernung
Inhalte	Pull Requests, Issues, Kommentare, Code-Ausschnitte	`<Aufbewahrungsfrist des Mandanten, Standard 90 Tage für abgeleitete Daten>`
Ergebnisse	Review-Hinweise, Triage-Ergebnisse, Antworten, Korrekturvorschläge	wie Inhalte
Zuweisungsdaten (nur wenn aktiviert)	Vorgeschlagene Personen mit Begründung, Code-Vertrautheit je Datei (ohne Gesamtwerte je Person), Anzahl offener Aufgaben, freiwillige Abwesenheitszeiträume (nur von/bis)	6 Monate; Abwesenheiten 30 Tage nach Ende; im Betriebsratsmodus die kürzeste zulässige Frist
Team-Kennzahlen	Tageswerte je Repository ohne Personenbezug	Aufbewahrungsfrist des Mandanten
Protokoll (Audit-Log)	Wer hat welche Einstellung geändert oder welche Ausgabe freigegeben, mit IP-Adresse	`<Frist nach Abstimmung mit der Rechtsberatung>`

Nicht verarbeitet werden: Kalenderinhalte (Titel, Teilnehmende, Gründe für Abwesenheit), Leistungs-, Geschwindigkeits- oder Qualitätswerte je Person, persönliche Merkmale.

6. Team-Auswertungen &ZeroWidthSpace;

6.1 Kennzahlen werden nur für Gruppen von mindestens k = <5 oder höher> Personen angezeigt. Werte für kleinere Gruppen werden unterdrückt; das gilt für jeden Zeitraum und jede Aufschlüsselung einzeln. 6.2 Es gibt keine Auswertung nach Personen. Mandanten- und Team-Auswertungen sehen nur <Rollen, z. B. Mandanten-Administratoren>. 6.3 Eine persönliche Ansicht („Meine Kennzahlen“) sieht nur die betroffene Person selbst, nur nach ihrer eigenen Einwilligung (Opt-in) und nur, wenn der Betriebsratsmodus aus ist. <Die Betriebsparteien vereinbaren, ob die persönliche Ansicht im Betrieb überhaupt zugelassen wird.> Vorgesetzte und Administratoren können die persönliche Ansicht anderer nicht aufrufen. 6.4 Kostenkennzahlen (Kosten der Modellaufrufe) beziehen sich auf Repositories und Funktionen, nie auf Personen.

7. Zuweisungsvorschläge &ZeroWidthSpace;

7.1 Betriebsart: <aus / nur Vorschlag / automatische Zuweisung>. Ohne diese Vereinbarung bleibt die Funktion im Betriebsratsmodus ausgeschaltet. 7.2 Eingangsdaten sind abschließend: CODEOWNERS-Einträge, zeitlich abklingende Commits, Blame- und Review-Historie zu den betroffenen Dateien, Bearbeitende ähnlicher Issues, aktuelle Zahl offener Aufgaben, freiwillige Abwesenheitszeiträume, Opt-out. Neue Eingangsdaten bedürfen einer Änderung dieser Vereinbarung. 7.3 Vorschläge enthalten nur Personen und sachliche Begründungen („Owner laut CODEOWNERS“, „hat N der betroffenen Dateien in den letzten D Tagen geändert“). Punktwerte, Rangfolgen und andere Kandidaten werden nicht angezeigt. 7.4 Jede Person kann der Berücksichtigung ohne Begründung widersprechen (Opt-out). Sie wird dann nie automatisch vorgeschlagen und bleibt manuell zuweisbar. Der Widerspruch ist für andere nicht sichtbar und hat keine Nachteile. 7.5 Jede Zuweisung kann von Menschen jederzeit geändert werden. Eine Änderung verschlechtert künftige Vorschläge für die betroffene Person nicht. 7.6 Eine automatische Zuweisung wird nur eingeschaltet, wenn diese Vereinbarung sie ausdrücklich erlaubt und die rechtliche Freigabe vorliegt.

8. Zugriffsrechte &ZeroWidthSpace;

Rolle	Zugriff
Beschäftigte mit Repository-Zugriff	Ergebnisse in ihren Repositories; Transparenzseite; eigene Einstellungen
Repository-Maintainer	Freigaben und Einstellungen ihrer Repositories
Mandanten-Administratoren `<Personen/Funktion>`	Einstellungen des Mandanten, Team-Auswertungen, Audit-Log des Mandanten
Instanz-Administratoren `<Personen/Funktion>`	Technischer Betrieb; Notfallzugang nur protokolliert
Betriebsrat	Einsicht nach Nr. 11

9. Speicherung und Löschung &ZeroWidthSpace;

9.1 Es gelten die Fristen aus Nr. 5. Abgelaufene Daten werden täglich automatisch gelöscht. 9.2 Auskunft und Löschung je Person erfolgen über die Funktion quavon dsar. Protokolleinträge werden nach Abstimmung mit der Rechtsberatung aufbewahrt oder pseudonymisiert.

10. Änderungen &ZeroWidthSpace;

Der Mitbestimmung unterliegen insbesondere: a) die Aktivierung weiterer Funktionen aus Nr. 2, b) neue Eingangsdaten oder Kennzahlen, c) die Absenkung von k, die Zulassung der persönlichen Ansicht oder das Abschalten des Betriebsratsmodus, d) der Wechsel von „Vorschlag“ zu „automatische Zuweisung“, e) längere Speicherfristen, f) neue Empfänger, insbesondere ein anderer Modellanbieter außerhalb der EU.

Versionswechsel ohne solche Änderungen teilt der Arbeitgeber dem Betriebsrat mit den Versionshinweisen mit.

11. Informationsrechte des Betriebsrats &ZeroWidthSpace;

11.1 Der Betriebsrat erhält vor der Einführung und bei jeder Änderung nach Nr. 10 diese Anlage, die Transparenzseite, die Datenschutz-Folgenabschätzung und die Liste der Unterauftragsverarbeiter (§ 80 Abs. 2, § 90 Abs. 1 Nr. 3 BetrVG). 11.2 Der Betriebsrat kann <z. B. halbjährlich> Einsicht in die Einstellungen (Betriebsarten, k, Fristen) und in das Audit-Log der Konfigurationsänderungen nehmen. 11.3 Der Betriebsrat kann einen Sachverständigen hinzuziehen; bei der Beurteilung von KI gilt die Hinzuziehung als erforderlich (§ 80 Abs. 3 Satz 2 BetrVG).

12. Schlussbestimmungen &ZeroWidthSpace;

<Inkrafttreten, Kündigung, Nachwirkung, Ansprechpersonen — durch die Betriebsparteien>

English summary &ZeroWidthSpace;

This is a German template annex for a works agreement (Betriebsvereinbarung) under § 87(1) No. 6 BetrVG covering CodeLotse. The employer and the works council adapt it.

Purposes: code quality and security, help with issues, routing reviews and tasks to people who know the code and spreading knowledge (only if assignment is enabled), team-level process metrics and cost control.
Exclusion: no performance or behaviour control of individuals; no use for appraisal, pay, promotion, warnings or dismissal; no rankings; no individual working-time or pace analysis; data obtained in breach may not be used.
Data: account and role data, repository content, results, assignment data (opt-in availability as from/to only), team metrics without personal reference, audit log. Not processed: calendar contents, per-person performance values, personal traits.
Analytics: team-level only with k ≥ 5 per point; no per-person dimension; a personal view only for the person, opt-in, and not in works-council mode; costs never per person.
Assignment: off until agreed; closed list of inputs; facts only, no scores or ranks; individual opt-out without disadvantage; humans can always change assignments; automatic assignment only if expressly permitted and legally signed off.
Access rights, retention and deletion, changes requiring co-determination (new features, inputs, lower k, self view, automatic assignment, longer retention, new recipients) and works-council information rights (§ 80(2), § 90(1) No. 3, expert under § 80(3) sentence 2).