AI Center governance, audit trail & privacy in rConfig V8
AI Center governance, audit trail, and data privacy in rConfig V8
Section titled “AI Center governance, audit trail, and data privacy in rConfig V8”After reading this page, you can explain exactly what data each AI capability sends to your provider, what rConfig records about every AI interaction, what it never stores, and who’s able to configure AI settings.
Access control
Section titled “Access control”Two permissions govern the AI Center: aicenter.view (view providers, capabilities, audit history, MCP status and tokens) and aicenter.update (create, update, or delete providers; toggle capabilities; manage MCP tokens). Both are managed like any other rConfig permission. See Roles for how role-based permissions work generally.
On top of that, the AI Settings and AI Configuration tabs are visible only to users with the Admin role. Every other AI Center tab (Overview, MCP Server, Skills, Privacy, and API Docs) is reachable by any user with AI Center access.
Provider control
Section titled “Provider control”Only one AI provider is active at a time, and only an admin can add, test, or activate one. Every enabled capability uses whichever provider is currently active. See Set up an AI provider.
What data each capability sends
Section titled “What data each capability sends”| Capability | Data sent to your provider | Device config included? |
|---|---|---|
| Config Analysis & Explain | Your message, the device config (sent only on the first message of a conversation: in full when under roughly 100 KB, otherwise only the most relevant sections), and a config metadata fingerprint. Follow-up messages send only the new message. | Yes |
| Drift Detection & Narration | Device name, change trigger, severity, and the computed config diff. If no diff has been computed yet, the full previous and current configuration files are sent instead. | Partial |
| Policy & Compliance Narration (narration) | Device name, policy name, overall result (pass/fail), reason, and per-rule results. No configuration text. | No |
| Policy & Compliance Narration (AI rule generation) | Policy name and description, and optionally up to 8 KB of a device configuration you paste in. Output is shown in the editor only, and is written to the policy store solely when you click Save. | Optional |
| Optimization Assistant | Your message and conversation history only. | No |
Where your data goes
Section titled “Where your data goes”The AI Center classifies the active provider’s destination based on its configured endpoint, and reflects that classification on the Privacy tab:
- On-premises: the active provider’s endpoint resolves to a local or private network address
- Cloud provider: the active provider is a recognized cloud API (OpenAI, Anthropic, Gemini, or Azure)
- External API endpoint: a custom, non-local base URL that isn’t one of the recognized cloud providers
- Unknown: shown when no provider is currently active
Choosing Ollama or an OpenAI-compatible endpoint pointed at infrastructure you control is how you keep AI inference entirely on-premises. See Set up an AI provider for how to configure a local endpoint.
What rConfig does not store
Section titled “What rConfig does not store”- rConfig doesn’t host any AI models itself. Every inference request goes directly from your instance to your configured provider
- AI responses aren’t stored in the database; they’re transient to the conversation
- Configuration content sent during inference isn’t separately logged or retained by rConfig beyond the conversation itself
- The audit trail (below) records only metadata about each interaction, never the prompt or response text
Audit trail
Section titled “Audit trail”Every AI interaction is recorded automatically. Each entry captures:
- User
- Capability used
- Conversation ID
- Provider and model
- Prompt and completion token counts
- IP address
- Timestamp
Never recorded: the prompt text, the device configuration content, or the AI’s response text.
Audit history is available through the AI Center API (GET /api/ai/audit-logs), filterable by capability, user, and date range. See API Docs for how to generate a reference for the full API.