Samenvatting in één regel #

fremforge laat klantcode op het standaardpad nooit door een Amerikaanse AI-leverancier subverwerken. De klant brengt een eigen sleutel van een AI-leverancier mee (BYOK) en kiest zelf de leverancier. Die leverancier is de eigen verwerker van de klant, onder het eigen contract van de klant, en geen subverwerker van fremverk onder de verwerkersovereenkomst.

Dit is vastgelegd in DPA bijlage B §B.8.

Wat onder “AI-integraties” valt #

fremforge heeft vier server-side AI-functies die de AI-leverancier gebruiken die de klant heeft ingesteld. Elk ervan staat uit tot de klant een sleutel van een leverancier toevoegt:

AI-review van PR’s – als een pull request wordt geopend of bijgewerkt, stuurt fremforge de diff + PR-metadata naar de ingestelde leverancier en plaatst een gestructureerd reviewcommentaar met een commitstatus pending → success / warning.
Uitleg bij dependency-updates van Renovate – PR’s van Renovate krijgen een gerichtere prompt, toegespitst op het verhelpen van CVE’s en het risico op breaking changes.
Gateway die de klant zelf aanroept – POST /api/v1/orgs/<slug>/ai/complete met een PAT met de scope ai:invoke. De eigen workflows en scripts van klanten roepen dit endpoint aan, in plaats van SDK’s van leveranciers in te bouwen.
AI-fix voor SAST-bevindingen – staat standaard uit, ook als er een sleutel is ingesteld; een eigenaar van de organisatie zet het aan. Klikt iemand op AI fix bij een bevinding van een van een korte lijst SAST-regels, dan stuurt fremforge de beschrijving van de regel en maximaal 60 regels van het betreffende bestand naar de ingestelde leverancier, controleert de teruggegeven diff en scant die opnieuw, en opent een pull request die nooit automatisch wordt gemerged. De prompt, de code en de diff worden niet door fremforge opgeslagen. Zie AutoFix.

Daarnaast is er een apart pad voor AI-tools aan de kant van de ontwikkelaar (Claude Code, Cursor, Continue, JetBrains AI die via de gewone REST-API + PAT met fremforge praten). Dat pad loopt niet via de infrastructuur van fremverk naar een AI-leverancier; zie docs.frem.sh/get-started/ai-in-your-ide/.

Ondersteunde leveranciers (fase 1, BYOK) #

fremforge ondersteunt drie soorten adapters, die samen elke grote leverancier van dit moment dekken:

Adapter	Voorbeelden van leveranciers
`openai-compatible`	OpenAI, Azure OpenAI, Mistral, Together, Fireworks, OpenRouter, T-Cloud AIFS, elke eigen OpenAI-compatibele URL
`anthropic`	De eigen API van Anthropic
`vertex-gemini`	Google Vertex Gemini

De klant plakt een API-sleutel van de leverancier in de beheer-UI op /<org>/_admin/ai-integrations. De sleutel wordt in rust versleuteld met AES-256-GCM via T Cloud Public DEW KMS, met een AAD-binding per rij (zodat een sleutel die uit een databaseback-up is gehaald niet kan worden ontsleuteld zonder ook de bijbehorende rij-id te bemachtigen).

Het datapad #

Voor elke AI-aanroep (PR-review, uitleg bij Renovate, of /ai/complete vanuit een workflow):

Het verzoek komt uit de repository van de klant, een webhook-payload of een workflowstap.
De api-pod van fremforge stelt de prompt samen: difftekst + PR-metadata + systeemprompt + door de klant aangeleverde berichten.
De api-pod van fremforge stuurt een HTTPS-verzoek naar de URL van de door de klant ingestelde leverancier, met de door de klant ingestelde sleutel.
Het antwoord van de leverancier wordt vastgelegd: aantallen tokens, latentie, modelnaam, antwoordtekst.
fremforge plaatst een Forgejo-commentaar (PR-review) OF geeft het antwoord terug aan de workflow (/ai/complete).
Een rij in ai_usage_events registreert de aanroep: tenant, aanbieder, model, tokens in, tokens uit, latentie. De prompt en de inhoud van het antwoord worden niet bewaard na afloop van het verzoek.

De prompt + het antwoord gaan één keer door de api-pod van fremforge. Ze gaan niet door een logaggregator, observability-dienst of back-up van derden. De audit per aanroep legt de metadata vast (welke functie, welke aanbieder, aantallen tokens), maar niet de inhoud.

Waarom “geen subverwerker” #

Volgens artikel 28 AVG is iemand subverwerker als de verantwoordelijke hem aanstelt, een contract met hem sluit en hem opdraagt de gegevens namens de verantwoordelijke te verwerken. Niets daarvan is hier van toepassing:

De klant kiest de AI-leverancier. fremverk stelt er geen aan en beveelt er geen aan. De keuzelijst in de beheer-UI toont soorten adapters, geen aanbevelingen.
De klant sluit zelf een contract met de AI-leverancier. fremverk heeft hiervoor geen commerciële relatie met de AI-leverancier. De klant betaalt de leverancier; fremverk zet geen marge op de tokenkosten van de leverancier.
De klant kan de AI-leverancier op elk moment verwijderen, zonder fremverk in te lichten. Zo werkt een relatie met een subverwerker van fremverk niet.
De eigen toezegging van fremverk in DPA §11.3 – geen subverwerkers met een Amerikaanse moedermaatschappij – blijft ongewijzigd. Een klant die kiest voor een in de VS opgerichte AI-leverancier (OpenAI, Anthropic, Google Vertex) stelt zichzelf bloot aan de jurisdictie van die leverancier – niet aan die van fremverk.

Dit is dezelfde juridische positie als bij identiteitsproviders die de klant kiest (Microsoft Entra, Okta, Google Workspace, JumpCloud, Authentik) en die via OIDC aan fremforge worden gekoppeld. Om dezelfde reden staan ze in de toelichting bovenaan bijlage B.

Het “turnkey”-traject van fase 2 #

Zodra AIFS (T-Cloud AI Foundation Services) een op code afgestemd model levert dat goed genoeg is voor PR-review – naar verwachting over 6–18 maanden – wil fremverk een turnkey AI-abonnement aanbieden, waarbij fremverk een AIFS-account in Duitsland aanhoudt en tokens per plaats factureert. Die optie zou een nieuwe subverwerker van fremverk betekenen en zou aan het register in bijlage B worden toegevoegd, met inachtneming van de kennisgeving van 30 dagen volgens §10.2.

Het BYOK-pad blijft beschikbaar, ook als turnkey er is – klanten kunnen altijd hun eigen sleutel van een leverancier meebrengen.

Zichtbaarheid in de audit #

Elke AI-aanroep levert een audit-event op:

tenant.ai_integration.provider_added / _disabled / _tested – wijzigingen in de configuratie van aanbieders
tenant.ai_integration.feature_default_changed – welke aanbieder welke functie afhandelt
tenant.ai_integration.repo_override_changed / _removed – uitzonderingen per repository
ai.complete.ok / ai.complete.failed – elk /ai/complete-verzoek van de klant

Klanten zien in de beheer-UI de tokenkosten per maand en de 👍/👎-tevredenheidsscores per (aanbieder, model); beide zijn gebaseerd op de onderliggende tabellen ai_usage_events en ai_review_comments. De auditlogs van klanten (DPA §9, bewaartermijn 13 maanden) bevatten alle tenant.ai_integration.*-events.

Zacht falen #

AI-functies blokkeren nooit een PR. Geeft de ingestelde leverancier een fout, loopt hij tegen een rate limit aan, wordt het bestedingsplafond van de klant overschreden of is de sleutel ongeldig, dan wordt het reviewcommentaar overgeslagen en verschijnt er een commitstatus warning (“AI review unavailable: retry on next push or fix the key”). De CI van de klant merkt er niets van; alleen het door AI gegenereerde commentaar ontbreekt.

Vragen en auditverzoeken #

Voor compliance-reviewers: deze pagina is het trustdocument waar je direct naar kunt linken. De contractuele basis is DPA bijlage B §B.8. Vragen kun je sturen naar compliance@frem.sh.