Governance and responsible operation

Use this guide to decide what data GPT-RAG may process, who owns each control, and what evidence an operator should preserve for security reviews and incident investigations.

Available in GPT-RAG v3.7.0

GPT-RAG v3.7.0 integrates orchestrator v3.8.0 and ingestion v2.5.0 with the correlated Audit Contract v1 (integration history: PR #573). Audit and provenance controls remain disabled by default until you complete the rollout steps below.

Why this matters

During a review or incident, an operator should be able to answer practical questions without searching unrelated logs:

What route or orchestration strategy handled the request?
Which grounding sources and tools were selected?
Did each tool call complete, fail, time out, or get cancelled?
Was an outcome produced or rejected?
What data classes could have entered telemetry?
Who configured access, retention, deletion, and export?

GPT-RAG already uses logs, traces, metrics, and source references. Those signals are useful, but they do not by themselves provide the versioned audit contract now implemented in GPT-RAG v3.7.0 (originally proposed in issue #571). The contract correlates operational metadata while leaving prompts, responses, source excerpts, tool arguments, and tool results out of the default event stream, and it stays off until an operator enables it.

flowchart LR
  Request[User request] --> Route[Route and source selection]
  Route --> Tools[Retrieval and tools]
  Tools --> Outcome[Outcome]
  Route -. audit events .-> Evidence[Correlated operational evidence]
  Tools -. audit events .-> Evidence
  Outcome -. audit events .-> Evidence

What GPT-RAG can and cannot establish

GPT-RAG cannot determine whether a deployment or use case is legally compliant. It does not certify a system, enforce an external governance framework, provide a complete legal crosswalk, or replace an adopter's legal, privacy, security, risk, records-management, or human-oversight processes.

Clear responsibilities, documented data practices, correlated audit events, configurable retention, and reviewable technical evidence can help adopters perform their own:

security and architecture reviews;
incident investigations;
privacy, risk, and audit assessments;
NIST AI Risk Management Framework activities; and
assessments involving the EU AI Act.

These are inputs to an adopter-led assessment, not proof of conformance or a legal conclusion. Applicability and evidence requirements depend on the deployment, data, users, jurisdiction, and intended use.

Intended use and limitations

The governance baseline is intended for teams that deploy GPT-RAG as a retrieval-augmented assistant and need a repeatable way to manage enterprise data and operational evidence.

Do not assume that:

a citation proves that an answer is correct or complete;
a recorded event proves that the producer behaved correctly;
missing telemetry proves that an action did not occur;
an opaque identifier is anonymous in every environment;
permission trimming replaces source-system authorization review;
a preview grounding capability is production-ready because it has audit events;
retention in Azure Monitor satisfies a records-management obligation; or
technical evidence establishes legal compliance.

The audit trail is best-effort telemetry. Sampling, exporter failures, process termination, asynchronous boundaries, disabled instrumentation, and upstream systems can create evidence gaps. Events are asserted by the producing GPT-RAG process. They are not independently attested, cryptographically signed, tamper-evident, or nonrepudiable.

Shared responsibility

One organization may perform more than one role. Assign each responsibility explicitly before production use.

Role	Responsibilities
GPT-RAG maintainers	Publish accurate behavior and limitations; provide privacy-conscious defaults; version the audit contract; test schema compatibility, redaction, and bounds; preserve compatibility or publish migration guidance.
Deployer or platform team	Select the deployment topology; configure identities, networking, Key Vault, Azure Monitor, retention, export, and backup; apply least-privilege RBAC; keep secrets out of configuration and telemetry; verify regional and service boundaries.
Runtime operator	Monitor health, cost, sampling, and evidence gaps; review access regularly; investigate incidents; validate deletion and export procedures; canary changes; roll back audit emission if it harms reliability.
Adopter, business owner, or data owner	Define the intended and prohibited uses; assert the right to use each data source; classify data; set minimization and retention policy; determine legal and regulatory obligations; define human oversight, risk acceptance, and user communication.

Govern ingested and connected data

Apply these controls to indexed content and to sources queried at request time. That includes Blob Storage, Azure AI Search, SharePoint, OneLake, specific Work IQ, Fabric IQ, Foundry IQ and web grounding integrations, and remote MCP servers.

Before connecting a source

Record provenance. Identify the system of record, data owner, ingestion or query path, refresh cadence, and applicable permission model.
Obtain a right-to-use assertion. The operator or data owner should record that the organization is authorized to process the source for the intended users and purpose. GPT-RAG cannot make this determination.
Classify the data. Apply the organization's classification for personal, confidential, regulated, export-controlled, or other sensitive content.
Minimize scope. Include only the sites, containers, indexes, tables, fields, date ranges, and tools required by the use case.
Define retention and deletion. Document how source data, indexes, conversation history, caches, and backups are removed. Test the process.
Review access. Use source-system permissions, managed identities, delegated access, and GPT-RAG retrieval controls as applicable. Test with representative allowed and denied users.
Review data movement. Confirm region, service, public internet, and cross-boundary behavior for every enabled source.

Sensitive content

Treat retrieved content as sensitive whenever its source classification says so. Grounding can copy excerpts into prompts, responses, conversation history, dependency telemetry, or troubleshooting logs. Permission trimming reduces unauthorized retrieval, but it does not replace classification, minimization, access review, or downstream handling controls.

For the concrete capabilities GPT-RAG integrates, see the Grounding sources overview. GPT-RAG integrates specific Work IQ, Fabric IQ, Foundry IQ, and web grounding capabilities. It does not claim complete Microsoft IQ support or provide a Microsoft IQ governance layer.

Govern generated telemetry

Data classes

Class	Examples	Required posture
Operational metadata	Event and correlation IDs, service and version, bounded status and reason codes, durations, tool names, source kinds, opaque source references	Permitted by the metadata-only contract. Classify and minimize it because identifiers and operational context can still be sensitive.
Sensitive content	Prompts, responses, source excerpts, system instructions, tool arguments, tool results	Off by default. Enable only after an explicit need, privacy review, access design, retention decision, and cost review.
Prohibited data	Access tokens, API keys, authorization headers, cookies, connection strings, credentials, and detected secrets	Never capture or export, including when sensitive-content capture is enabled. Redact before telemetry leaves the producing process and fail closed by omitting unsafe values.

Actor correlation is disabled by default. If AUDIT_ACTOR_PSEUDONYM_ENABLED=true, the producer records actor_id as hmac_ plus the first 32 hexadecimal characters of an HMAC-SHA256 digest. It never places the raw user name, email address, object ID, or token claim in that property. Store AUDIT_HMAC_KEY in Azure Key Vault, restrict it to the producing workload, and rotate it together with AUDIT_HMAC_KEY_ID. Rotation breaks direct pseudonym correlation across key versions.

Redaction metadata should say that redaction occurred and list omitted field names, never the omitted values. A successful redaction flag does not prove that all sensitive information was found, so producers must use allowlisted fields and bounded enums instead of trying to sanitize arbitrary objects.

Retention, access, and export

GPT-RAG's current AI Landing Zone template configures the Log Analytics workspace for 30 days of retention. A reused workspace or table-level override can differ, so inspect the deployed settings rather than assuming the template value applies.

Azure Monitor supports up to two years of analytics retention for Analytics tables and up to 12 years of total retention with long-term retention. Longer retention and additional ingestion can increase cost. The adopter must choose a period that matches incident, privacy, records-management, and legal needs.

Use this operational baseline:

Keep access least-privileged and review role assignments regularly.
Separate platform administration from routine telemetry reading where practical.
The audit implementation stores allowlisted prompt, response, source_excerpt, tool_arguments, and tool_result values in AppEvents.Properties, not AppGenAIContent. If audit sensitive capture is approved, restrict AppEvents, its query results, alerts, workbooks, and exports accordingly.
Other generative AI instrumentation can use AppGenAIContent. Follow the current Application Insights routing guidance and configure it as a protected table when that separate content capture is enabled.
Test retention changes and deletion procedures in a non-production environment.
Use Log Analytics data export when continuous export to Azure Storage or Event Hubs is required.
If an organization needs WORM retention, configure immutable Blob Storage on the export destination as an operator-owned control. GPT-RAG does not configure an immutable evidence store.

Sampling affects evidence. A 100 percent sampling configuration may reduce sampling gaps, but it increases ingestion and retention cost and still does not guarantee complete evidence. Verify the deployed OpenTelemetry and Azure Monitor sampling behavior, exporter health, and throttling before relying on telemetry for an investigation.

Roll out the audit feature

Use GPT-RAG umbrella v3.7.0 or later with orchestrator v3.8.0 and ingestion v2.5.0. Do not mix older component versions with this shared-contract rollout.

Upgrade with AUDIT_EVENTS_ENABLED=false, AUDIT_SENSITIVE_CONTENT_ENABLED=false, and INGESTION_PROVENANCE_ENABLED=false.
Run post-provisioning. Verify that AUDIT_HMAC_KEY is a Key Vault reference and that the existing Search index gained the optional provenance fields without being recreated.
Enable metadata-only audit events in a non-production environment.
Enable ingestion provenance separately if the deployment has reviewed the classification and right-to-use defaults.
Keep AUDIT_ACTOR_PSEUDONYM_ENABLED and AUDIT_SENSITIVE_CONTENT_ENABLED disabled.
If actor correlation is approved, enable pseudonymization only after reviewing access to the automatically provisioned Key Vault key.
Rotate the pseudonymization key on your schedule, or immediately after a suspected exposure: create a new version of the AUDIT-HMAC-KEY secret in Key Vault, advance AUDIT_HMAC_KEY_ID to a new value that marks the new pseudonymization epoch, then restart or redeploy the affected workloads so both changes take effect together. Do not edit AUDIT_HMAC_KEY itself; it is an unversioned Key Vault reference and always resolves to the secret's current version. Retain or remove prior secret versions according to your rollback and retention policy. See HMAC identifiers and rotation.
Canary a small production slice and reconstruct representative requests.
Monitor latency, exporter failures, ingestion volume, retention cost, and evidence-gap health signals.
Confirm that existing traces, logs, dashboards, alerts, indexed documents, and operator-added Search fields still work.
Roll back by setting AUDIT_EVENTS_ENABLED=false and INGESTION_PROVENANCE_ENABLED=false, then restart the components. Additive Search fields can remain. Do not enable sensitive content as a troubleshooting shortcut.

Audit emission should not make the user request fail. If event production or the synchronous logging path fails, the runtime continues the request and attempts an audit.emission.failed event, then a fixed warning if that also fails. The Azure Monitor batch exporter does not expose an application callback for later delivery failure. The implementation has no separate health event, rate limiter, or delivery acknowledgment, so operators must monitor expected volume and Azure Monitor ingestion health.