Sammendraget på én linje #

fremforge lar aldri kundens kode bli behandlet av en amerikansk AI-leverandør som underleverandør på standardveien. Kunden tar med sin egen nøkkel fra AI-leverandøren (BYOK) og velger leverandør selv. Leverandøren er kundens egen databehandler under kundens egen avtale, ikke fremverks underleverandør etter databehandleravtalen (DPA).

Dette er fastsatt i DPA vedlegg B §B.8.

Hva «AI-integrasjoner» omfatter #

fremforge leverer fire AI-funksjoner på serversiden som bruker kundens konfigurerte AI-leverandør. Hver av dem er slått av til kunden legger inn en nøkkel:

AI-gjennomgang av PR-er – når en pull request åpnes eller oppdateres, sender fremforge diffen + PR-metadata til den konfigurerte leverandøren og publiserer en strukturert gjennomgangskommentar med en commit-status pending → success / warning.
Forklaringer av Renovates avhengighetsoppdateringer – PR-er laget av Renovate får en mer fokusert prompt om utbedring av CVE-er og risikoen for endringer som ikke er bakoverkompatible.
Gateway som kunden kaller selv – POST /api/v1/orgs/<slug>/ai/complete med en PAT som har scopet ai:invoke. Kundens egne workflower og skript kaller dette endepunktet i stedet for å bygge inn leverandørens SDK-er.
AI-rettelse for SAST-funn – slått av som standard også når en nøkkel er konfigurert; en eier av organisasjonen slår den på. Når noen klikker på AI-rettelse på et funn fra en av noen få utvalgte SAST-regler, sender fremforge regelens beskrivelse og høyst 60 linjer av den berørte filen til den konfigurerte leverandøren, kontrollerer diffen som kommer tilbake og skanner den på nytt, og åpner så en pull request som aldri merges automatisk. Prompten, koden og diffen lagres ikke av fremforge. Se AutoFix.

Det finnes en egen vei for AI-verktøy på utviklersiden (Claude Code, Cursor, Continue, JetBrains AI som snakker med fremforge gjennom det vanlige REST-API-et + PAT). Den veien går ikke gjennom noen AI-leverandør via fremverks infrastruktur; se docs.frem.sh/nb/get-started/ai-in-your-ide/.

Leverandører som støttes (fase 1, BYOK) #

fremforge støtter tre typer adaptere som dekker alle de store leverandørene i dag:

Adapter	Eksempler på leverandører
`openai-compatible`	OpenAI, Azure OpenAI, Mistral, Together, Fireworks, OpenRouter, T-Cloud AIFS, en hvilken som helst egen OpenAI-kompatibel URL
`anthropic`	Anthropics eget API
`vertex-gemini`	Google Vertex Gemini

Kunden limer inn leverandørens API-nøkkel i administrasjonsgrensesnittet under /<org>/_admin/ai-integrations. Nøkkelen krypteres i hvile med AES-256-GCM gjennom T Cloud Public DEW KMS med AAD-binding per rad (slik at en nøkkel som er hentet ut av en databasebackup, ikke kan dekrypteres uten at også den tilhørende rad-ID-en hentes ut).

Dataveien #

For hvert AI-kall (PR-gjennomgang, Renovate-forklaring eller /ai/complete kalt fra en workflow):

Kundens repository, en webhook-nyttelast eller et workflow-steg setter i gang forespørselen.
api-poden i fremforge setter sammen prompten: difftekst + PR-metadata + systemprompt + meldinger kunden leverer.
api-poden i fremforge sender en HTTPS-forespørsel til URL-en kunden har konfigurert for leverandøren, med nøkkelen kunden har konfigurert. Forespørselen går bare ut gjennom en begrenset utgående proxy, og bare til leverandørverten som ble kontrollert og låst da leverandøren ble lagret: en https-adresse med et DNS-navn, aldri en IP-adresse eller en privat, intern eller link-local-adresse. Omdirigeringer følges ikke. En forespørsel til en hvilken som helst annen vert avvises, slår av funksjonen og registreres i revisjonsloggen. Proxyen ser bare vert og port for den krypterte tilkoblingen, aldri prompten eller svaret.
Leverandørens svar registreres: antall tokener, latens, modellnavn, svartekst.
fremforge publiserer en Forgejo-kommentar (PR-gjennomgang) ELLER returnerer svaret til workflowen (/ai/complete).
En rad i ai_usage_events registrerer kallet: organisasjon, leverandør, modell, inngående tokener, utgående tokener, latens. Innholdet i prompten og svaret lagres ikke lenger enn forespørselen varer.

Prompten + svaret passerer api-poden i fremforge én gang. De går ikke gjennom noen logginnsamler, observabilitetstjeneste eller backup hos tredjepart. Revisjonen per kall registrerer metadata (hvilken funksjon, hvilken leverandør, antall tokener), men ikke innholdet.

Hvorfor «ikke en underleverandør» #

Etter artikkel 28 i GDPR blir noen en underleverandør når den behandlingsansvarlige utpeker dem, inngår avtale med dem og instruerer dem til å behandle opplysningene på vegne av den ansvarlige. Ingenting av dette gjelder her:

Kunden velger AI-leverandøren. fremverk utpeker eller anbefaler ingen. Nedtrekksmenyen i administrasjonsgrensesnittet lister opp typer adaptere, ikke anbefalinger.
Kunden inngår avtale direkte med AI-leverandøren. fremverk har ingen forretningsrelasjon med AI-leverandøren for dette formålet. Kunden betaler leverandøren; fremverk legger ikke noe påslag på leverandørens tokenkostnader.
Kunden kan når som helst fjerne AI-leverandøren uten å si fra til fremverk. Slik fungerer ikke en relasjon med en av fremverks underleverandører.
fremverks egen forpliktelse om underleverandører uten amerikansk morselskap i DPA §11.3 er uendret. En kunde som velger en AI-leverandør registrert i USA (OpenAI, Anthropic, Google Vertex), utsetter seg selv for den leverandørens jurisdiksjon – ikke fremverks.

Det er den samme rettslige posisjonen som for identitetsleverandører kunden selv velger (Microsoft Entra, Okta, Google Workspace, JumpCloud, Authentik) og føderer inn i fremforge gjennom OIDC. De er nevnt i innledningen til vedlegg B av samme grunn.

Veien mot en «nøkkelferdig» fase 2 #

Når AIFS (T-Cloud AI Foundation Services) lanserer en kodetilpasset modell som er god nok for PR-gjennomgang – i dag ventet om 6–18 måneder – planlegger fremverk å tilby en nøkkelferdig AI-plan der fremverk har en AIFS-konto i Tyskland og fakturerer tokener per bruker. Det alternativet vil innebære en ny underleverandør for fremverk og vil bli lagt til i registeret i vedlegg B, med det varselet på 30 dager som gjelder etter §10.2.

BYOK-veien blir værende også når det nøkkelferdige alternativet lanseres – kunder kan alltid ta med sin egen nøkkel.

Synlighet i revisjonsloggen #

Hvert AI-kall lager en revisjonshendelse:

tenant.ai_integration.provider_added / _disabled / _tested – endringer i leverandørkonfigurasjonen
tenant.ai_integration.feature_default_changed – hvilken leverandør som håndterer hvilken funksjon
tenant.ai_integration.repo_override_changed / _removed – overstyringer per repository
ai.complete.ok / ai.complete.failed – hver /ai/complete-forespørsel kunden kaller

Kundene ser tokenforbruk per måned og vurderinger 👍/👎 per (leverandør, modell) i administrasjonsgrensesnittet; tabellene ai_usage_events og ai_review_comments ligger bak begge. Kundenes revisjonslogger (DPA §9, oppbevaring i 13 måneder) inneholder alle tenant.ai_integration.*-hendelser.

Myke feil i grensesnittet #

AI-funksjonene blokkerer aldri en PR. Hvis den konfigurerte leverandøren returnerer en feil, når en grense for antall kall, overskrider kundens kostnadstak eller har en ugyldig nøkkel, hoppes gjennomgangskommentaren over, og en commit-status warning vises («AI-gjennomgang ikke tilgjengelig: prøv igjen ved neste push eller rett nøkkelen»). Kundens CI påvirkes ikke; det eneste som mangler, er den AI-genererte kommentaren.

Spørsmål og anmodninger om revisjon #

For deg som vurderer etterlevelse: denne siden er tillitsdokumentet du kan lenke direkte til. Det avtalemessige grunnlaget er DPA vedlegg B §B.8. Spørsmål sendes til compliance@frem.sh.