Governance
This domain tests your ability to apply security, safety, and compliance practices to GenAI systems built on Databricks. It covers guardrails for content filtering, PII protection, Unity Catalog access control for AI assets, legal/licensing considerations, and audit traceability. Governance accounts for 8% of the exam, meaning roughly 4–6 questions. These questions tend to be scenario-based, asking you to pick the right tool, permission level, or architectural pattern for a given compliance requirement.
Guardrails for Harmful or Off-Topic Content
Core Concepts
Guardrails are controls placed around LLM inputs and outputs to prevent harmful, off-topic, or policy-violating content from reaching users or being processed. On Databricks, guardrails are implemented at several layers: the AI Playground, Model Serving endpoints, and explicitly through Llama Guard and Databricks AI / MLflow evaluation frameworks.
Llama Guard is a Meta-trained classifier model available on Databricks Model Serving that evaluates prompts and responses against a set of safety categories (violence, hate speech, sexual content, dangerous advice, etc.). It can be deployed as a standalone endpoint or called inline within a chain.
Databricks Model Serving supports AI Gateway (also called MLflow AI Gateway or Databricks AI Gateway) — a proxy layer that sits in front of model endpoints and can enforce:
- Rate limiting (requests per minute/second)
- Content filtering (block or flag requests/responses)
- Guardrail policies attached to a route
Inference Tables capture raw request/response pairs at a serving endpoint for downstream analysis, including guardrail violations.
Input vs. Output Guardrails
| Guardrail Type | When Applied | Typical Use Case |
|---|---|---|
| Input guardrail | Before model inference | Block jailbreak attempts, off-topic queries |
| Output guardrail | After model inference | Filter harmful completions before delivery |
| Both (bidirectional) | Input + output | High-compliance environments (healthcare, finance) |
Implementing Guardrails in a Chain (LangChain / LlamaIndex on Databricks)
In a RAG chain, guardrails are placed as chain steps — a pre-retrieval input filter and a post-generation output filter. You call the Llama Guard endpoint via mlflow.deployments or directly via REST. If the classification returns UNSAFE, the chain short-circuits and returns a safe refusal message instead of the model's response.
Decision flow for content guardrail placement:
Diagram 1 – Guardrail placement decision tree in a RAG pipeline
Common Traps
- Confusing rate limiting with content filtering. Rate limiting controls frequency of requests; it does not block harmful content. Both are features of AI Gateway but serve different purposes.
- Assuming the base LLM has built-in safety. Fine-tuned or open-source models may have safety alignment removed. Always add explicit guardrail steps.
- Placing guardrails only on output. Jailbreak prompts must be caught at input; output-only guardrails miss adversarial inputs that still reach the model.
- Believing Llama Guard is the only option. Other classifiers (custom MLflow models, third-party APIs) can serve as guardrail endpoints — Llama Guard is the Databricks-recommended default.
Worked Scenario
Requirement: A healthcare company deploys a patient-facing chatbot. The chatbot must never respond with self-harm content and must reject questions about competitor services. Both categories must be blocked.
Reasoning: Two separate guardrails are needed. Llama Guard (deployed on Model Serving) handles the self-harm safety category at output. A custom topic classifier (deployed as a second Model Serving endpoint) checks at input for competitor mentions. The chain calls input guardrail → retrieval → LLM → output guardrail (Llama Guard). AI Gateway route-level filtering alone is insufficient because topic detection requires a custom model.
PII Handling and Masking in Prompts and Retrieval Data
Core Concepts
PII (Personally Identifiable Information) in GenAI pipelines can appear in: user prompts, retrieved documents, model responses, and logged inference data. Databricks provides tools at multiple stages to detect and mask PII.
Presidio (Microsoft open-source, runnable on Databricks) is the most commonly referenced PII detection and anonymization library. It identifies entities such as names, SSNs, phone numbers, credit card numbers, and email addresses, then replaces them with tokens or synthetic values.
Databricks' native approach uses:
- Delta Lake column masking (Unity Catalog feature) — applies a masking function at read time so downstream queries never see raw PII.
- Row-level security (RLS) in Unity Catalog to limit which principals can access rows containing PII.
ai_mask()andai_analyze_sentiment()SQL functions — built-in Databricks SQL AI functions that can detect and mask PII inline in SQL queries (available in DBR 13.3+).
PII Handling Stages in a RAG Pipeline
| Stage | Risk | Mitigation |
|---|---|---|
| User prompt ingestion | User submits SSN or name in query | Input PII masking before logging or retrieval |
| Document ingestion / chunking | Source docs contain PII | Pre-processing with Presidio before embedding |
| Vector index | Embedded chunks encode PII semantically | Mask/redact before embedding; restrict index access |
| Inference Table logging | Raw prompts logged to Delta | Column masking on inference table; restrict table ACLs |
| LLM response | Model regurgitates PII from context | Output PII scanning before delivery |
Unity Catalog Column Masking for PII
-- Define a masking function
CREATE FUNCTION mask_ssn(ssn STRING)
RETURNS STRING
RETURN CASE WHEN is_account_group_member('pii_readers')
THEN ssn
ELSE regexp_replace(ssn, '[0-9]', 'X')
END;
-- Apply to a table column
ALTER TABLE patient_records
ALTER COLUMN ssn SET MASK mask_ssn;
Non-privileged users querying patient_records will see XXX-XX-XXXX instead of the real SSN. This is enforced at the catalog/schema/table level in Unity Catalog and cannot be bypassed by direct Spark reads when Unity Catalog governance is enabled.
ai_mask() SQL Function
ai_mask(text, ['PERSON', 'PHONE_NUMBER', 'EMAIL']) — takes a string column and a list of entity types, returns the string with detected entities replaced by [PERSON], [PHONE_NUMBER], etc. This is a Databricks SQL AI Function, powered by a foundation model endpoint under the hood. It requires Serverless SQL or a cluster with DBR 13.3+ and Unity Catalog enabled.
Common Traps
- Assuming embedding removes PII. Embeddings encode semantic meaning; PII can often be reconstructed or retrieved via similarity search. Mask before embedding.
- Confusing
ai_mask()with Presidio.ai_mask()is a SQL function for inline use; Presidio is a Python library for batch pipeline processing. Both detect PII but in different contexts. - Logging raw prompts to inference tables without masking. Inference Tables log everything by default. You must apply column masking or a masking transform on the logged table.
- Row-level security vs. column masking confusion. RLS controls which rows a user can see. Column masking controls which values within a row a user can see. Both can be needed simultaneously.
Worked Scenario
Requirement: A legal firm indexes case documents that contain client names and SSNs into a Databricks Vector Search index. Associates should be able to query the index but must never see raw SSNs in retrieved chunks.
Reasoning: During document ingestion, run Presidio on the text chunks to replace SSNs with [SSN_REDACTED] before embedding and storing. Store the original (unmasked) documents in a separate Delta table with column masking applied, restricted to senior partners via Unity Catalog column mask policy. The vector index is built from the masked chunks, so retrieved context sent to the LLM also contains no raw SSNs.
Unlock with a paid plan
6 more sections (about 2,442 words) continue below. Every paid plan unlocks all Generative AI Engineer Associate study guides, the full question bank and mock exams, from $4.97/month.