Disclaimer: This article documents my personal exploration of AI governance frameworks and regulatory concepts. Nothing in this post constitutes legal advice, compliance certification, or a guarantee of regulatory conformance. AI governance requirements vary by jurisdiction, sector, and use case. Consult qualified legal and compliance professionals before making governance decisions. NosisTech LLC accepts no liability for outcomes arising from use of this content.
A privacy compliance agent is a system that reviews how data is collected, used, stored, and shared. In this build, I focused on a narrow version of that idea: a small agent that screens fictional business activities for possible GDPR and CCPA concerns. GDPR is the European Union’s General Data Protection Regulation. CCPA is the California Consumer Privacy Act. The goal was not to create a legal opinion machine. The goal was to show how an agent can turn messy business descriptions into structured compliance review questions.
What This Agent Does
This agent reads a fictional data processing activity and returns a structured privacy screening result.
It looks for possible GDPR flags, possible CCPA flags, review questions for a human, and a short cautious summary. I used fictional companies in the examples because this agent is about pattern recognition, not commentary on real businesses.
The three test cases were designed to create different outcomes:
- Basic newsletter: a lower-risk opt-in email collection scenario.
- Health analytics: a higher-risk scenario involving wearable health data from EU users.
- Ad sharing: a higher-risk California shopper tracking and advertising-sharing scenario.
The architecture: business activity in, privacy checklist applied, structured JSON out.
Why I Built This
I built this because most companies do not struggle with privacy law only at the policy level. They struggle at the translation layer.
A founder says, “We collect usage data for product analytics.” A lawyer hears lawful basis, retention, transfer mechanism, data subject rights, and vendor processing. A developer hears database fields and API logs. That translation gap is where risk hides.
I wanted a small agent that demonstrates the first layer of that translation. Not a final answer. Not legal advice. A screening layer that turns an ordinary business description into the right questions.
What Actually Happened
What actually happened: The two models agreed on the high-risk cases, but they treated the newsletter case differently.
What surprised me: DeepSeek rated the newsletter case LOW, while Gemini rated it MEDIUM. Gemini was more cautious because it wanted more information about rights processes, storage location, and CCPA applicability.
What I would change next: I would separate “risk level” from “missing information level” so a low-risk activity with incomplete documentation does not get blended with genuinely high-risk processing.
Why this matters: Real privacy reviews often start with incomplete information. The agent’s value is not that it gives a final answer. The value is that it exposes what a human reviewer needs to ask next.
The Architecture: How It Works
The agent has five moving parts.
First, it loads its model configuration from .env. That means the model name, API key, and LiteLLM-compatible endpoint are environment-specific values, not hardcoded into the Python file.
Second, it defines a compact privacy checklist. A checklist is a short set of review rules. In this build, the checklist focuses on common GDPR and CCPA screening concerns such as lawful basis, sensitive data, sale or sharing of personal information, opt-out paths, retention, transfer concerns, and rights processes.
Third, it sends fictional data activity descriptions to the model.
Fourth, it asks for JSON. JSON is a structured text format that software can read predictably.
Fifth, it prints the result so I can compare how two different model providers reason through the same cases.
The important architectural idea is not that the model knows privacy law perfectly. The important idea is that a business activity can be routed through a structured screening layer before a human reviewer spends time on it.
The Build: Step by Step
SYSTEM_PROMPT = """
You are reviewing a fictional data processing activity for educational GDPR and CCPA screening.
This is not legal advice and does not certify compliance.
Use this simplified checklist:
- GDPR: flag unclear lawful basis, special category data, unclear retention, high-risk profiling or automated decisions, cross-border transfer concerns, and missing data subject rights process.
- CCPA: flag unclear applicability, sale or sharing of personal information, missing opt-out path, sensitive personal information, and missing consumer rights process.
Return only JSON:
{
"risk_level": "LOW | MEDIUM | HIGH",
"gdpr_flags": ["short flag"],
"ccpa_flags": ["short flag"],
"review_questions": ["question a human reviewer should ask next"],
"summary": "short cautious summary"
}
"""
What This Code Is Actually Doing
This is the agent’s instruction card. It tells the model what kind of review to perform, which privacy concepts to watch for, and what shape the answer needs to have. The key decision here is the phrase “educational screening.” That keeps the output framed as a first-pass review, not a legal conclusion.
DEMOS = [
{
"label": "Basic newsletter",
"activity": "Fictional company Alder Books collects email addresses for a monthly newsletter. Users opt in through a form, can unsubscribe, and data is deleted after two years of inactivity.",
},
{
"label": "Health analytics",
"activity": "Fictional company ValeFit analyzes wearable heart rate data and sleep records from EU users to create wellness scores. The activity uses consent, stores data in another region, and has not completed a DPIA.",
},
{
"label": "Ad sharing",
"activity": "Fictional company BrightCart tracks California shoppers across its site and shares purchase behavior with advertising partners for retargeting. It has no opt-out link and no process for deletion requests.",
},
]
What This Code Is Actually Doing
These are the test cases. I used fictional companies so the model would focus on the supplied facts instead of using outside knowledge about real businesses. The three examples test different levels of concern: a basic newsletter, sensitive health analytics, and advertising data sharing.
def screen_activity(client, model, activity):
"""Ask the model to screen one data activity for GDPR and CCPA flags."""
result = client.chat.completions.create(
model=model,
messages=[
{"role": "system", "content": SYSTEM_PROMPT},
{"role": "user", "content": activity},
],
temperature=0,
)
return parse_json(result.choices[0].message.content)
What This Code Is Actually Doing
This function sends one activity description to the model. The system message contains the privacy screening rules, and the user message contains the fictional business activity. temperature=0 asks the model to behave more consistently, which helps when comparing outputs across providers.
def parse_json(text):
"""Parse JSON even when a model wraps it in extra formatting."""
cleaned = text.strip()
if cleaned.startswith("```"):
lines = cleaned.splitlines()
if lines[0].startswith("```"):
lines = lines[1:]
if lines and lines[-1].startswith("```"):
lines = lines[:-1]
cleaned = "\n".join(lines).strip()
start = cleaned.find("{")
end = cleaned.rfind("}")
if start != -1 and end != -1:
cleaned = cleaned[start : end + 1]
return json.loads(cleaned)
What This Code Is Actually Doing
This is the cleanup layer. Some models return JSON inside a formatted code block. This function strips that wrapper and extracts the JSON object so Python can read it. This became important after earlier builds showed that Gemini and DeepSeek can format structured output differently.
Test Results
I tested the same three fictional cases through gemini-flash and deepseek-v4-pro.
For the basic newsletter case, DeepSeek returned LOW risk. Gemini returned MEDIUM risk. That difference was useful. DeepSeek focused on the opt-in newsletter flow and deletion after inactivity. Gemini focused on missing information: data subject rights, storage location, and whether CCPA applies.
For the health analytics case, both models returned HIGH risk. That matched the expected behavior because the activity involved wearable health data, EU users, wellness scoring, cross-region storage, and no completed DPIA. DPIA means Data Protection Impact Assessment, a formal review often associated with higher-risk data processing.
For the ad sharing case, both models returned HIGH risk. That also matched the expected behavior because the fictional company shared California shopper behavior with advertising partners, had no opt-out link, and had no deletion request process.
The models did not use identical wording, and that is normal. The important result was that both providers separated the lower-risk newsletter activity from the higher-risk health data and advertising-sharing scenarios.
Errors I Hit During This Build
The issue was Gemini appearing to return nothing during one run. I added clearer case output and a provider failure message so the script would not fail silently if a provider request stopped unexpectedly.
Why This Matters
This build matters because privacy risk usually starts as ordinary business language.
A company does not say, “We are creating a cross-border special category data processing workflow with unclear retention.” It says, “We analyze wearable data to create wellness scores.” The agent translates that description into review flags and questions.
That translation layer has business value. It can help founders, operators, and compliance teams prepare better intake notes before legal review. It can help technical teams understand why privacy reviewers ask certain questions. It can also become the foundation for a more formal privacy impact assessment workflow, with human review kept in the loop.
This is where the leverage is. The agent does not replace judgment. It organizes the first layer of review so judgment can happen faster.
This build is an educational demonstration of an architecture pattern, not legal advice, compliance certification, or an implementation guide for any specific organization. Any real GDPR, CCPA, or privacy governance workflow should be designed around that organization’s jurisdiction, data flows, contracts, vendors, security controls, and legal obligations, then reviewed by qualified privacy, legal, and security professionals before use.
Tools Used
- LiteLLM (MIT): github.com/BerriAI/litellm
- OpenAI Python SDK (Apache 2.0): github.com/openai/openai-python
- python-dotenv (BSD-3-Clause): github.com/theskumar/python-dotenv
- NosisTech Agent Engineering (MIT): github.com/nosistech/agent-engineering
(c) 2026 NosisTech LLC. Licensed under CC BY 4.0. Use freely, just credit us.