AI integrations — data path and sovereignty

Effective: 2026-05-24 — fremforge Phase 1 AI integrations

The one-line summary #

fremforge never sub-processes customer code through a US AI vendor on the default path. The customer brings their own AI vendor key (BYOK) and chooses their own vendor. The vendor is the customer’s own processor under the customer’s own contract, not fremverk’s sub-processor under the Data Processing Agreement.

This is codified at DPA Annex B §B.8.

What “AI integrations” covers #

fremforge ships three server-side AI features that use the customer’s configured AI vendor:

1. AI PR review — when a pull request opens or syncs, fremforge sends the diff + PR metadata to the configured vendor and posts a structured review comment with a pending → success / warning commit-status.
2. Renovate dep-bump explanations — Renovate-authored PRs get a tighter prompt focused on CVE remediation and breaking-change risk.
3. Customer-callable gateway — POST /api/v1/orgs/<slug>/ai/complete with a PAT carrying the ai:invoke scope. Customers’ own workflows + scripts call this endpoint instead of embedding vendor SDKs.

A separate path exists for dev-side AI tooling (Claude Code, Cursor, Continue, JetBrains AI talking to fremforge via the standard REST API + PAT). That path doesn’t transit any AI vendor through fremverk’s infrastructure; see docs.frem.sh/get-started/ai-in-your-ide/.

Supported vendors (Phase 1, BYOK) #

fremforge supports three adapter shapes that cover every current major vendor:

The customer pastes a vendor API key in the admin UI at /<org>/_admin/ai-integrations. The key is encrypted at rest with AES-256-GCM using T Cloud DEW KMS with a per-row AAD binding (so a key extracted from a database backup cannot be decrypted without also extracting the matching row id).

The data path #

For each AI call (PR review, Renovate explanation, or workflow-callable /ai/complete):

1. The customer’s repo, a webhook payload, or a workflow step originates the request.
2. fremforge’s api pod assembles the prompt: diff text + PR metadata + system prompt + customer-supplied messages.
3. fremforge’s api pod sends an HTTPS request to the customer-configured vendor’s URL with the customer-configured key.
4. The vendor’s response is captured: token counts, latency, model name, response text.
5. fremforge posts a Forgejo comment (PR review) OR returns the response to the workflow (/ai/complete).
6. An ai_usage_events row records the call: tenant, provider, model, tokens-in, tokens-out, latency. The prompt and the response body are not retained beyond the request lifecycle.

The prompt + response transit fremforge’s api pod once. They do not transit any third-party log aggregator, observability service, or backup. Per-call audit emits the metadata (which feature, which provider, token counts) but not the body.

Why “not a sub-processor” #

Article 28 GDPR makes someone a sub-processor when the controller appoints them, contracts with them, and instructs them to process the data on the controller’s behalf. None of those apply here:

• The customer chooses the AI vendor. fremverk does not appoint or recommend one. The dropdown in the admin UI lists adapter shapes, not endorsements.
• The customer contracts with the AI vendor directly. fremverk has no commercial relationship with the AI vendor for this purpose. The customer pays the vendor; fremverk does not mark up vendor token costs.
• The customer can remove the AI vendor at any time without notifying fremverk. That’s not how a fremverk sub-processor relationship works.
• fremverk’s own no-US-parent sub-processor commitment in DPA §11.3 is unchanged. A customer choosing a US-incorporated AI vendor (OpenAI, Anthropic, Google Vertex) is exposing themselves to that vendor’s jurisdiction — not fremverk’s.

This is the same legal posture as customer-chosen identity providers (Microsoft Entra, Okta, Google Workspace, JumpCloud, Authentik) federated into fremforge via OIDC. They appear in the Annex B header note for the same reason.

The Phase 2 “turnkey” trajectory #

When AIFS (T-Cloud AI Foundation Services) ships a code-tuned model good enough for PR review — currently expected 6–18 months out — fremverk plans to offer a turnkey AI plan tier where fremverk holds an AIFS-Germany account and bills per-seat for tokens. That option would constitute a new fremverk sub-processor and would be added to the Annex B register subject to the 30-day §10.2 notice.

The BYOK path stays available even after turnkey ships — customers can always bring their own vendor key.

Audit visibility #

Every AI call emits an audit event:

• tenant.ai_integration.provider_added / _disabled / _tested — provider config changes
• tenant.ai_integration.feature_default_changed — which provider handles which feature
• tenant.ai_integration.repo_override_changed / _removed — per-repo overrides
• ai.complete.ok / ai.complete.failed — every customer-callable /ai/complete request

Customers see token-spend per month and per-(provider, model) 👍/👎 satisfaction scores in the admin UI; the underlying ai_usage_events and ai_review_comments tables drive both. Customer audit logs (DPA §9, 13-month retention) include all tenant.ai_integration.* events.

Soft-fail UX #

AI features never block a PR. If the configured vendor returns an error, hits a rate-limit, exceeds the customer’s spend cap, or has an invalid key, the PR review comment is skipped and a warning commit-status renders (“AI review unavailable: retry on next push or fix the key”). The customer’s CI is unaffected; only the AI-generated comment is missing.

Questions, audit requests #

For compliance reviewers: this page is the deep-linkable trust artefact. The contractual carrier is DPA Annex B §B.8. Questions to compliance@frem.sh.