NVIDIANVIDIA-Certified Professional: Agentic AI2026-109.2 Integrate compliance guardrails (privacy, enterprise policy).
Enforce topic scope and storage lifetimes
Completed by the knowledge check
Learning objective
Enforce enterprise policies with topic-control rails and data-retention rules.
Core idea
An enterprise policy governs both what an assistant may discuss and how long the delivery system may keep its data. These are different decisions with different enforcement mechanisms. A topic classifier judges a message against conversation rules; a storage retention mechanism removes retained data according to a lifecycle. Passing the classifier does not authorize indefinite storage.
NeMo Guardrails documents topic control through a dedicated model, an input flow, and a task-specific prompt. Its tracing documentation separately requires attention to backend access and retention when capturing content. Translate each policy clause into an executable setting, a test, and an owner. See 9.2.1 for PII redaction and 1.4.2 for user and tenant memory lifecycles; this lesson adds enterprise topic rules and operational retention enforcement.
How it works
Bind the topic rules to the checking model
The Guardrails topic-control configuration declares a model with type: topic_control, engine: nim, and parameters.base_url pointing to its serving endpoint. NVIDIA’s example uses parameters.model_name: llama-3.1-nemoguard-8b-topic-control. This model performs the topic check; distinguish it from the application’s answer-generating model.
Activate topic safety check input $model=topic_control under rails.input.flows. Then define a prompt whose task is topic_safety_check_input $model=topic_control. The model declaration, flow, and prompt must refer to the same checking role. General instructions provide prompt-level topical guidance; they do not configure this dedicated checking rail.
Define permitted subjects and exclusions. Distinguish “Explain the supplier-selection policy” from “Which supplier should I choose for my personal renovation?” Banning every supplier mention would block useful work.
The flow automatically adds TOPIC_SAFETY_OUTPUT_RESTRICTION, instructing the topic model to return on-topic or off-topic. Its topic_safety_check_input action interprets the result as a boolean topic decision. These labels belong to the checking protocol; they are not the final business answer. Preserve the distinction when measuring allowed and refused requests.
Turn enterprise wording into acceptance cases
Use the policy-based nemoguardrails eval workflow. Conventionally, policies.yaml contains policies with an id and natural-language description; interactions.yaml contains interaction sets with inputs and policy-linked expected_output, including type: refusal. These filenames are conventions: the top-level keys define the configuration. Add owner, version, and rationale in the team’s policy register.
Configure a model with type: llm-judge. Run cases with nemoguardrails eval run, assess policy compliance with nemoguardrails eval check-compliance, and inspect results with nemoguardrails eval ui. Review judge decisions against expected outcomes rather than treating the aggregate compliance rate as the business decision.
Measure mistaken refusals separately from admitted off-topic requests. Tightening a rule can improve one rate while damaging the other. Measure checking latency and inference capacity at the intended concurrency, including policy-prompt tokens.
The TopicControl flow checks input; an on-topic question does not ensure an on-topic answer. Choose among the documented topical-rail approaches:
| Approach | Mechanism | Cost and boundary |
|---|---|---|
| General instructions | Main-model instructions | Prompt tokens; relies on the generating model following guidance. |
| Input check | TopicControl flow or adapted self_check_input prompt | Classifier or self-check LLM call before generation. |
| Output check | Adapted self_check_output prompt | LLM call checking the generated response’s topic. |
| Dialog rails | Explicit Colang define user and define flow rules | Intent-processing calls plus flow authoring and maintenance; this tutorial uses Colang 1.0 syntax. |
Select checks for the consequence to prevent (see 7.1.1). Topic acceptance does not grant tool authorization (see 9.1.1).
Enforce the lifetime in the store
Register each retained data class, destination, lifetime, enforcing setting, deletion verification, and owner. Separate conversations, logs, traces, and derived stores. NVIDIA’s content-capture documentation treats tracing backends as user-content stores requiring retention limits.
Minimizing collection reduces the amount that needs expiry. Use tracing.enable_content_capture: false when metadata suffices; see 9.2.1 for the engine-specific capture controls. A retention policy still applies to whatever metadata and application logs you retain. Turning off content capture does not remove records already stored.
For a concrete diagnostic-log backend, Grafana Loki implements retention through its Compactor. Set compactor.retention_enabled: true and configure limits_config.retention_period for the global lifetime. limits_config.retention_stream adds label-selected stream policies; per-tenant runtime overrides support tenant-specific rules. These settings govern Loki logs, not the assistant’s other stores or its trace database.
Loki retention requires a 24h index period and configured compactor.delete_request_store. Each retention_stream rule’s period must be at least 24h; that minimum does not apply to retention_period. Index references disappear before asynchronous chunk deletion, delayed by compactor.retention_delete_delay. Verify both outcomes. Retention-period changes are not retroactive; address existing logs separately. Keep any object-store lifecycle longer than Loki retention.
Expire retrieved-corpus data separately. The NVIDIA RAG Blueprint ingestor exposes DELETE /documents with the target collection_name query parameter and a JSON array of document names to delete documents from the vectorstore. DELETE /collections accepts collection names for retiring whole vector-database collections. Schedule these calls from the corpus retention register, then verify that expired documents no longer support retrieval. Source-file retention remains a separate destination; vectorstore deletion does not establish deletion from the original repository. See 1.4.2 for memory stores.
Key distinctions and trade-offs
Assign each clause to the mechanism that can enforce it:
| Enterprise requirement | Mechanism | Trade-off and owner |
|---|---|---|
| Stay within approved subjects | topic safety check input $model=topic_control plus its task prompt | False refusals versus off-topic admissions; application and policy owners. |
| Avoid retaining conversation content in Guardrails spans | tracing.enable_content_capture: false | Less diagnostic detail; observability and privacy owners. |
| Expire diagnostic logs after the agreed window | Loki retention_enabled and retention_period | Less historical investigation data; storage owner. |
| Give selected log streams different lifetimes | Loki retention_stream with label selectors | More configuration and coverage testing; storage and tenant-policy owners. |
A policy prompt cannot schedule deletion, and a retention setting cannot decide whether a question is appropriate. Redaction reduces retained content but does not replace a required expiry. Regulatory interpretation belongs with the compliance owner; see 9.5.2 for that broader assessment.
Architecture / decision scenario
A manufacturing company deploys a procurement workflow assistant. Its hypothetical policy permits purchasing-process explanations, rejects personal purchasing advice, and keeps diagnostic logs for seven days. Application traces retain operational metadata without message content. The p95 target is 1.8 seconds.
One proposal adds policy wording to the main prompt and keeps 30 days of logs for easier incident investigation. It is inexpensive to implement, but fails the explicit seven-day lifetime and supplies no dedicated topic-check decision. The application owner instead wires the topic-control model, input flow, and task prompt, then tests policy boundaries.
Using those interaction files with nemoguardrails eval run and check-compliance, evaluate 500 synthetic allowed and 100 forbidden requests: suppose the initial prompt refuses 40 allowed requests and admits two forbidden ones. A revised prompt refuses ten allowed requests but admits 12 forbidden ones. The enterprise policy owner chooses or revises the policy using both rates; the lower refusal rate alone cannot justify the second version. The team also measures whether the extra checking call preserves the 1.8-second target.
The storage owner configures Loki retention to 168h, enables the Compactor, supplies the delete-request store, and verifies the required index period. Verify both query disappearance and asynchronous chunk deletion. Existing logs from the proposed 30-day setup require a separate cleanup decision because changing retention is not retroactive. The privacy owner approves separate retention-register entries:
| Data | Lifetime | Mechanism and owner |
|---|---|---|
| Diagnostic logs | Seven days | Loki retention_period: 168h; storage owner. |
| Retrieved procurement documents | Until their approved expiry date | Scheduled DELETE /documents with collection_name and document names; corpus owner, with a separate source-file deletion check. |
Common exam traps
- Relying on general instructions when policy requires an independent checking rail.
- Confusing
on-topicwith authorization or a compliant final answer. - Improving false refusals while ignoring off-topic admissions.
- Assuming enabled log ingestion implies enabled Loki retention.
- Applying the
24hstream-rule minimum to every retention field. - Treating index removal, physical deletion, and retroactive policy changes as one operation.
What to remember
Bind enterprise topic rules to the checking model, flow, and task prompt, then evaluate both sides of the boundary. Enforce retention in each actual store with named settings and owners. Verify deletion behavior and existing data separately from policy wording and query visibility.
Knowledge check
A procurement assistant’s policy requires a dedicated topic classifier, separate from the answering model, to judge every user message before generation. The team declares a model with type: topic_control and adds topic safety check input $model=topic_control under rails.input.flows. What else does the configuration need?
topic_safety_check_input $model=topic_controlself_check_output prompt listing the approved topicsdefine flow dialog rail for each approved purchasing topicA procurement assistant’s policy sets two limits for its topic rail: refuse at most 5% of allowed requests and admit at most 3% of forbidden ones. On 500 allowed and 100 forbidden synthetic requests, prompt A refuses 40 allowed and admits 2 forbidden; prompt B refuses 10 allowed and admits 12 forbidden. What should the team do?
Topic-control input checks admit only purchasing-process questions, yet some answers to those on-topic questions drift into personal product recommendations. Which addition checks each generated response before it is returned?
self_check_output prompt that checks the response’s topictopic safety check input flow on a larger modelself_check_output prompt checks the response itself, at the cost of another LLM call. A stricter or larger input check still sees only the question, and general instructions rely on the answering model following them rather than checking its result.The storage owner sets limits_config.retention_period: 168h for an assistant’s Grafana Loki logs, which use a 24h index period and have no tenant or stream overrides. The Compactor is running, but its retention settings remain at their defaults. Nine days after deployment, logs ingested after deployment are still returned by queries. Which configuration is required?
retention_stream rule with period: 168h for the assistant’s labelscompactor.retention_enabled: true with a configured delete_request_storecompactor.retention_delete_delay for chunks marked for deletionretention_enabled is set, and enabling retention also requires a delete-request store; a lifetime alone enforces nothing. A stream rule is another lifetime the Compactor would equally ignore, the delete delay governs chunk removal after index references are already gone, and these logs arrived after the change, so non-retroactivity does not explain them.A corpus retention register says each supplier contract expires on its end date. On expiry, a scheduled job calls the NVIDIA RAG Blueprint ingestor’s DELETE /documents with the name of the collection shared by all supplier contracts and the contract’s document name. What must the corpus owner still do?
DELETE /collectionsDELETE /documents removes the document from the vectorstore; the original file is a separate destination with its own deletion, and the outcome is verified by checking that retrieval no longer supports it. Retiring the whole collection removes contracts that have not expired, a topic rule decides what may be discussed rather than what is stored, and content capture governs traces, not the corpus.References
- NVIDIA, Topic Control
- NVIDIA, Capturing Prompt and Response Content
- Grafana Labs, Log retention
- NVIDIA, Evaluate Configuration
- NVIDIA, Topical Rails
- NVIDIA, RAG Blueprint ingestor server OpenAPI schema