cesnimda
20 lines
1.5 KiB
Markdown
20 lines
1.5 KiB
Markdown
# AI privacy and external-processing policy
|
|
|
|
Updated: 2026-08-03
|
|
|
|
The default execution mode is local-only. External processing of `/cv/*` payloads requires all of:
|
|
|
|
1. `Ai:ExternalProcessingEnabled=true` on the backend;
|
|
2. `EXTERNAL_AI_ENABLED=true` on the AI sidecar;
|
|
3. a configured external `Ai:ExternalProvider` / `AI_PROVIDER` (`gemini` or `groq`);
|
|
4. a current Pro/Admin entitlement resolved from the database;
|
|
5. AI enabled in the user's server-side settings; and
|
|
6. the user's explicit `ExternalAiProcessingAllowed` opt-in.
|
|
|
|
The backend adds `X-Ai-External-Allowed: true` only after that live policy check. The sidecar otherwise routes `/cv/*` to Ollama even when an external provider is configured. `/summarize` always uses the local summarization model. Provider keys remain server-side and are never returned by the settings API.
|
|
|
|
`GET/PUT /api/ai/settings` owns the user settings. Disabling AI takes effect on the next protected request and is also rechecked by the current enrichment and queued-CV workers. Existing users migrate with AI enabled to preserve current behaviour; external consent always defaults to false.
|
|
|
|
This is the privacy admission foundation, not the final routing system. AI-001/AI-002 must carry an immutable policy snapshot into durable operations, recheck it at execution, record the actual provider/reason, add bounded local-first fallback triggers and minimize each external payload. Background CV work currently fails safe to local because it has no HTTP user context.
|
|
|