Das Wichtigste in einem Satz #

fremforge lässt Kundencode auf dem Standardpfad nie durch einen US-KI-Anbieter als Unterauftragsverarbeiter verarbeiten. Der Kunde bringt seinen eigenen Schlüssel für einen KI-Anbieter mit (BYOK) und wählt den Anbieter selbst. Dieser Anbieter ist der eigene Auftragsverarbeiter des Kunden unter dessen eigenem Vertrag – nicht ein Unterauftragsverarbeiter von fremverk im Sinne des Auftragsverarbeitungsvertrags.

Festgeschrieben ist das in AVV Anhang B §B.8.

Was „KI-Integrationen“ umfasst #

fremforge bietet vier serverseitige KI-Funktionen, die den vom Kunden eingerichteten KI-Anbieter nutzen. Jede bleibt aus, bis der Kunde einen Anbieterschlüssel hinterlegt:

KI-Review von PRs – wenn ein Pull Request geöffnet oder aktualisiert wird, sendet fremforge den Diff und die PR-Metadaten an den eingerichteten Anbieter und veröffentlicht einen strukturierten Review-Kommentar mit einem Commit-Status pending → success / warning.
Erklärungen zu Renovate-Updates – PRs von Renovate bekommen einen enger gefassten Prompt, der auf die Behebung von CVEs und das Risiko inkompatibler Änderungen ausgerichtet ist.
Gateway für eigene Aufrufe – POST /api/v1/orgs/<slug>/ai/complete mit einem PAT, der den Scope ai:invoke trägt. Eigene Workflows und Skripte des Kunden rufen diesen Endpunkt auf, statt SDKs der Anbieter einzubetten.
KI-Fix für SAST-Funde – auch bei eingerichtetem Schlüssel standardmäßig aus; ein Owner der Organisation schaltet ihn ein. Klickt eine Person bei einem Fund zu einer von wenigen ausgewählten SAST-Regeln auf AI fix, sendet fremforge die Beschreibung der Regel und höchstens 60 Zeilen der betroffenen Datei an den eingerichteten Anbieter, prüft den zurückgegebenen Diff, scannt ihn erneut und öffnet einen Pull Request, der nie automatisch gemergt wird. Prompt, Code und Diff speichert fremforge nicht. Siehe AutoFix.

Für KI-Werkzeuge auf Entwicklerseite gibt es einen separaten Pfad (Claude Code, Cursor, Continue, JetBrains AI, die über die normale REST-API und einen PAT mit fremforge sprechen). Auf diesem Pfad läuft kein KI-Anbieter über die Infrastruktur von fremverk; siehe docs.frem.sh/get-started/ai-in-your-ide/.

Unterstützte Anbieter (Phase 1, BYOK) #

fremforge unterstützt drei Adaptertypen, die alle großen aktuellen Anbieter abdecken:

Adapter	Beispiele für Anbieter
`openai-compatible`	OpenAI, Azure OpenAI, Mistral, Together, Fireworks, OpenRouter, T-Cloud AIFS, jede eigene OpenAI-kompatible URL
`anthropic`	Native API von Anthropic
`vertex-gemini`	Google Vertex Gemini

Der Kunde fügt den API-Schlüssel des Anbieters in der Admin-UI unter /<org>/_admin/ai-integrations ein. Der Schlüssel wird im Ruhezustand mit AES-256-GCM über T Cloud Public DEW KMS verschlüsselt, mit einer AAD-Bindung pro Zeile (ein aus einem Datenbank-Backup extrahierter Schlüssel lässt sich also nicht entschlüsseln, ohne auch die passende Zeilen-ID zu extrahieren).

Der Datenpfad #

Für jeden KI-Aufruf (PR-Review, Renovate-Erklärung oder /ai/complete aus einem Workflow):

Das Repository des Kunden, eine Webhook-Payload oder ein Workflow-Schritt löst die Anfrage aus.
Der api-Pod von fremforge setzt den Prompt zusammen: Diff-Text + PR-Metadaten + System-Prompt + vom Kunden gelieferte Nachrichten.
Der api-Pod von fremforge sendet eine HTTPS-Anfrage an die URL des vom Kunden eingerichteten Anbieters, mit dem vom Kunden eingerichteten Schlüssel.
Die Antwort des Anbieters wird erfasst: Token-Zahlen, Latenz, Modellname, Antworttext.
fremforge veröffentlicht einen Forgejo-Kommentar (PR-Review) ODER gibt die Antwort an den Workflow zurück (/ai/complete).
Eine Zeile in ai_usage_events protokolliert den Aufruf: Mandant, Anbieter, Modell, Eingabe-Tokens, Ausgabe-Tokens, Latenz. Prompt und Antworttext werden nicht über die Dauer der Anfrage hinaus aufbewahrt.

Prompt und Antwort durchlaufen den api-Pod von fremforge genau einmal. Sie durchlaufen keinen Log-Aggregator, keinen Observability-Dienst und kein Backup eines Dritten. Das Audit pro Aufruf erfasst die Metadaten (welche Funktion, welcher Anbieter, Token-Zahlen), aber nicht den Inhalt.

Warum „kein Unterauftragsverarbeiter“ #

Nach Artikel 28 DSGVO ist jemand Unterauftragsverarbeiter, wenn der Verantwortliche ihn beauftragt, mit ihm einen Vertrag schließt und ihn anweist, die Daten im Auftrag des Verantwortlichen zu verarbeiten. Nichts davon trifft hier zu:

Der Kunde wählt den KI-Anbieter. fremverk beauftragt oder empfiehlt keinen. Die Auswahlliste in der Admin-UI zeigt Adaptertypen, keine Empfehlungen.
Der Kunde schließt den Vertrag direkt mit dem KI-Anbieter. fremverk hat für diesen Zweck keine Geschäftsbeziehung mit dem KI-Anbieter. Der Kunde bezahlt den Anbieter; fremverk schlägt nichts auf die Token-Kosten des Anbieters auf.
Der Kunde kann den KI-Anbieter jederzeit entfernen, ohne fremverk Bescheid zu geben. So funktioniert eine Beziehung zu einem Unterauftragsverarbeiter von fremverk nicht.
Die eigene Zusage von fremverk, keine Unterauftragsverarbeiter mit US-Muttergesellschaft einzusetzen, in AVV §11.3 bleibt unverändert. Wählt ein Kunde einen in den USA eingetragenen KI-Anbieter (OpenAI, Anthropic, Google Vertex), unterwirft er sich der Rechtsordnung dieses Anbieters – nicht der von fremverk.

Das ist dieselbe rechtliche Position wie bei vom Kunden gewählten Identitätsanbietern (Microsoft Entra, Okta, Google Workspace, JumpCloud, Authentik), die per OIDC mit fremforge föderiert sind. Sie erscheinen aus demselben Grund im Vorbemerkungstext zu Anhang B.

Ausblick Phase 2: „Turnkey“ #

Sobald AIFS (T-Cloud AI Foundation Services) ein auf Code abgestimmtes Modell anbietet, das für PR-Reviews gut genug ist – derzeit in 6–18 Monaten erwartet –, plant fremverk einen schlüsselfertigen KI-Tarif, bei dem fremverk ein AIFS-Konto in Deutschland hält und Tokens pro Platz abrechnet. Diese Option würde einen neuen Unterauftragsverarbeiter von fremverk begründen und mit der 30-tägigen Mitteilung nach §10.2 in das Verzeichnis nach Anhang B aufgenommen.

Der BYOK-Pfad bleibt auch nach dem Start von Turnkey verfügbar – Kunden können immer ihren eigenen Anbieterschlüssel mitbringen.

Sichtbarkeit im Audit #

Jeder KI-Aufruf erzeugt ein Audit-Event:

tenant.ai_integration.provider_added / _disabled / _tested – Änderungen an der Anbieterkonfiguration
tenant.ai_integration.feature_default_changed – welcher Anbieter welche Funktion bedient
tenant.ai_integration.repo_override_changed / _removed – Überschreibungen pro Repository
ai.complete.ok / ai.complete.failed – jede Anfrage an /ai/complete aus Kundenaufrufen

Kunden sehen in der Admin-UI die Token-Ausgaben pro Monat und 👍/👎-Zufriedenheitswerte pro (Anbieter, Modell); beides speist sich aus den Tabellen ai_usage_events und ai_review_comments. Die Audit-Logs der Kunden (AVV §9, 13 Monate Aufbewahrung) enthalten alle tenant.ai_integration.*-Events.

Weiches Scheitern #

KI-Funktionen blockieren nie einen PR. Gibt der eingerichtete Anbieter einen Fehler zurück, greift ein Rate Limit, ist das Ausgabenlimit des Kunden überschritten oder der Schlüssel ungültig, entfällt der Review-Kommentar, und es erscheint ein Commit-Status warning („AI review unavailable: retry on next push or fix the key“). Die CI des Kunden ist nicht betroffen; nur der von der KI erzeugte Kommentar fehlt.

Fragen und Audit-Anfragen #

Für Compliance-Prüfer: Diese Seite ist das direkt verlinkbare Trust-Dokument. Vertragliche Grundlage ist AVV Anhang B §B.8. Fragen an compliance@frem.sh.