Das Zonenmodell erklärt: Welcher Code an ein Modell darf

Welcher Code darf an ein KI-Modell?

Das Zonenmodell ist eine Regel, die festlegt, welcher Code an ein KI-Modell darf: Zone B geht mit, Zone A bleibt im Haus. An ein Modell geht also nur der Teil eures Quellcodes, den euer Team vorher dafür freigegeben hat. Die Regel steht fest, bevor Agenten an euren Tickets arbeiten.

Die Frage stellt sich, sobald Agenten in eurer eigenen Codebasis arbeiten. In Teams mit 3–15 Entwicklern kennt fast jeder die sensiblen Stellen im Code. Das Zonenmodell schreibt dieses Wissen auf, damit es auch für Agenten gilt.

Ein Agent braucht Kontext, um brauchbaren Code zu schreiben. Er liest Dateien, erfasst eure Architektur und schickt Teile davon als Anfrage an ein Modell.

Ohne Regel entscheidet jeder Entwickler selbst, was dabei mitgeht. Der eine ist vorsichtig, der andere kopiert eine ganze Konfigurationsdatei in den Chat. Das Zonenmodell ersetzt diese Einzelentscheidungen durch eine gemeinsame Regel für das ganze Team.

Zusammen mit zwei weiteren Regeln bildet es den Rahmen für die Arbeit mit Agenten:

• Zonen: Welche Dateien an ein Modell gehen dürfen und welche nicht.
• Firmenzugänge: Gearbeitet wird nur über Zugänge des Unternehmens, keine privaten Accounts.
• Zero-Retention: Die Firmenzugänge werden so eingerichtet, dass der Anbieter laut seinen Vertragsbedingungen euren Code nicht für Training verwendet und Anfragen nicht aufbewahrt.

Zone A und Zone B: So teilt ihr eure Codebasis ein

Das Zonenmodell teilt eure Codebasis in zwei Bereiche: Zone B darf als Kontext an ein Modell gehen, Zone A bleibt im Haus. Welche Datei in welche Zone gehört, legt ihr fest. Das Werkzeug entscheidet das nicht.

Ein Beispiel macht das greifbar. Für ein Ticket zum CSV-Export gehen die Dateien src/export/csv.ts und src/ui/table.tsx mit, also Exportlogik und Tabellenansicht. Die Dateien auth/keys.ts und customers.csv bleiben gesperrt. Schlüssel und Kundendaten gehören in Zone A.

Bei der Einteilung helfen ein paar einfache Fragen:

• Enthält die Datei Zugangsdaten, Schlüssel oder Tokens? Dann gehört sie in Zone A.
• Enthält sie Daten von Kunden oder Mitarbeitenden, etwa Exporte, Datenbank-Dumps oder echte Datensätze in Tests? Dann gehört sie in Zone A.
• Gehört sie zu einem Bereich, den ihr aus vertraglichen Gründen oder als Betriebsgeheimnis besonders schützen wollt? Dann gehört sie in Zone A.
• Ist es gewöhnlicher Anwendungscode, eine Oberfläche oder ein Test ohne solche Inhalte? Dann kommt die Datei für Zone B in Frage.

Das Zonenmodell ist eine organisatorische Regel für euer Team. Im Zweifel bleibt eine Datei in Zone A, bis jemand sie bewusst freigibt.

Firmenzugänge statt privater Accounts

Gearbeitet wird ausschließlich über Firmenzugänge, damit euer Unternehmen weiß, über welche Zugänge euer Code an ein Modell geht. Private Accounts und Consumer-Accounts fallen weg.

Ein verbreiteter Einwand lautet: „Ich weiß nicht, wo unser Code überall landet.“ Dahinter steckt oft Schatten-KI. Einzelne Entwickler nutzen KI-Werkzeuge in privaten Accounts, jeder für sich, und niemand hat den Überblick.

Im Selbsttest auf unserer Startseite fragen wir genau das: Laufen die Zugänge bei euch über private Accounts, gemischt oder nur über Firmenzugänge? Erst mit der dritten Antwort lässt sich ein Zonenmodell im Alltag durchsetzen. Eine Regel, die nur für einen Teil der Zugänge gilt, hat Lücken.

Firmenzugänge haben einen zweiten Vorteil. Die Lizenzen laufen direkt bei euch, ihr bleibt unabhängig von uns. Ihr vergebt Zugänge an neue Entwickler und entzieht sie wieder, wenn jemand das Team verlässt. Ob ein Team mit Codex oder Claude arbeitet, die Regel ist dieselbe.

Für die Geschäftsführung beantwortet das die Frage aus dem Einwand. Euer Code geht über Zugänge, die eurem Unternehmen gehören, und nach Regeln, die für alle im Team gelten.

Was Zero-Retention bedeutet

Zero-Retention bedeutet hier: Die Firmenzugänge werden so ausgewählt und eingerichtet, dass der Anbieter laut seinen Vertragsbedingungen eure Anfragen nicht aufbewahrt und euren Code nicht für Training verwendet. Diese Bedingungen liegen euch selbst vor, weil die Lizenzen bei euch laufen.

Zero-Retention und Zonenmodell ergänzen sich. Das Zonenmodell entscheidet, was überhaupt an ein Modell geht. Zero-Retention regelt, was laut den Bedingungen des Anbieters mit diesem Teil danach passiert. Erst beides zusammen beantwortet die Frage, wo euer Code landet.

Zero-Retention hängt deshalb eng an den Firmenzugängen. Die Bedingungen gelten für den Zugang, über den gearbeitet wird. Bei privaten Accounts entscheidet jeder Entwickler selbst, unter welchen Bedingungen er arbeitet. Mit Firmenzugängen gelten für das ganze Team dieselben.

Davon getrennt ist der vertragliche Rahmen zwischen euch und uns. NDA und AVV, also ein Vertrag zur Auftragsverarbeitung, regeln das Verhältnis zu MakeNative. Der Vertrag mit dem KI-Anbieter läuft über eure eigenen Firmenzugänge. NDA und AVV werden vor der Analysewoche unterschrieben, also bevor wir eine Zeile eures Codes lesen.

Wie die Regeln im Alltag eingehalten werden

Die Regeln werden in der Einrichtung verankert und an jeder Änderung geprüft. Ein Dokument, das niemand liest, schützt keinen Code.

Konkret greifen vier Stellen ineinander:

• Einrichtung: Wir richten die Agenten mit euren Standards, eurer Architektur und eurem Zonenmodell ein.
• Quality Gate: Bevor eine Änderung ins Review geht, prüft ein Quality Gate unter anderem, dass keine Zugangsdaten und keine Zone-A-Dateien im Diff stehen.
• Review: Der Product Engineer prüft jede Ausgabe, bevor sie in euren Code geht. Die Verantwortung bleibt in eurem Team.
• Datensicherheits-Tools: Wir richten sie ein. Im Team- und im Multiplikatoren-Programm laufen sie nach dem Programm weiter.

Die Stellen haben unterschiedliche Aufgaben. Was an ein Modell geht, regeln die Einrichtung der Agenten, die Firmenzugänge und die Regeln des Zonenmodells. Der Diff-Check im Quality Gate prüft dagegen die fertige Änderung, bevor sie ins Review geht.

Der Gedanke dahinter ist einfach. Eine Regel wirkt nur, wenn ein Ablauf sie bei jeder Änderung wieder abfragt. Deshalb ist das Zonenmodell kein einmaliger Workshop-Beschluss, sondern Teil der täglichen Arbeit mit Agenten.

Die Einteilung bleibt dabei veränderbar. Kommt ein neues Modul mit sensiblen Daten dazu, ordnet ihr es Zone A zu. Wird ein Bereich bereinigt, kann er nach eurer Freigabe in Zone B wechseln.

Was das Zonenmodell nicht ersetzt

Das Zonenmodell ersetzt keine rechtliche Bewertung, die bleibt in eurem Haus bei euch. Wir liefern Konzept und Einrichtung und benennen Chancen wie Risiken offen.

Für die Abstimmung im Unternehmen heißt das: Bindet eure Datenschutzverantwortlichen früh ein. Die Einbindung des Betriebsrats, wo vorhanden, liegt ebenfalls bei euch. Die Einteilung in Zone A und Zone B ist dafür eine gute Gesprächsgrundlage, weil sie zeigt, welche Dateien überhaupt an ein Modell gehen.

Im Programm entstehen auch Ergebnisse je Entwickler: die Einstufung je Entwickler, die Abschlussprüfung und der belegte Titel Product Engineer. So gehen wir mit diesen Daten um:

• Jeder Entwickler erfährt seine Ergebnisse zuerst.
• An die Geschäftsführung wird als Teamdurchschnitt berichtet.
• Berichte werden nie für Personalentscheidungen verwendet.

Die Unterlagen für das Gespräch mit eurem Betriebsrat liefern wir.

Wann das Zonenmodell festgelegt wird

Das Zonenmodell wird im Programm in Woche 1 festgelegt, am Mittwoch, bevor am Donnerstag die ersten Tickets laufen. Davor liegt die kostenlose Analysewoche, in der nichts verändert wird.

Der Weg dorthin sieht so aus:

• Erstgespräch: 30 Minuten, unverbindlich, kein Pitch.
• Vertraglicher Rahmen: Vor der Analysewoche unterschreiben wir NDA und AVV mit euch.
• Analysewoche: Wir lesen Codebasis, Tickets und Pipeline. Lesezugriff genügt, nichts wird verändert. Euer Aufwand: Kickoff und Lesezugriff.
• Programm, Woche 1: Arbeitsplätze einrichten, Zonenmodell festlegen, erste Tickets.

Die Analysewoche zeigt euch, wo euer Team heute steht und was in ihm steckt. Das Ergebnisdokument gehört euch, unabhängig davon, wie ihr euch entscheidet. Wenn ihr wissen wollt, wie Agenten in eurer Codebasis arbeiten können, während Zone A nicht an ein Modell geht, ist sie der erste Schritt.