Privacy Policy Decoder
Privacy policies contain some of the most important information about how our data is collected and used, but they are often long, technical, and difficult to understand.
I built Privacy Policy Decoder to make that first-pass analysis easier.
The Problem
When someone signs up for a service, they are often expected to understand a privacy policy that may contain thousands of words covering data collection, third-party sharing, tracking, retention, user controls, AI/model use, and government disclosures.
The important information is there, but finding it and understanding how the pieces fit together can take a lot of time.
The goal of this project is not to replace the original privacy policy or provide legal advice. It is to help a user quickly understand what the policy actually says and identify the parts worth paying closer attention to.
What I Built
Privacy Policy Decoder is a web application where a user pastes a privacy policy and receives a structured privacy analysis.
The system looks at seven predefined dimensions:
- Data Collection
- Third-Party Sharing
- Tracking
- Retention
- User Control
- AI / Model Use
- Government Disclosure
For each dimension, the application provides an assessment, supporting evidence from the policy, and a confidence level.
The result also includes:
- a plain-English summary,
- key concerns,
- a score out of 42,
- and an A–F concern grade.
The Important Part: AI Does Not Decide the Grade
The main design decision behind the project was to separate evidence extraction from scoring.
Gemini is used to read the supplied policy text and extract structured findings.
The model is not asked to simply decide whether a policy is "good" or "bad."
Instead, the flow is:
Privacy Policy
↓
Gemini structured evidence extraction
↓
Output validation
↓
Deterministic scoring rubric
↓
Privacy Snapshot
↓
Evidence + Key Takeaways
The final score is calculated by application code using a predefined rubric.
This means that the AI answers:
What does the policy say?
while the application answers:
How does that finding map to our scoring framework?
The score is therefore transparent and reproducible from the extracted findings rather than being a free-form AI opinion.
Evidence First
Another important design principle is that the application should not ask users to blindly trust an AI-generated conclusion.
Each dimension displays the relevant evidence extracted from the policy.
For example, instead of simply reporting:
"Broad commercial sharing"
the interface also shows the policy language that supports that assessment.
This makes the analysis easier to inspect and understand.
The system also distinguishes "not stated" from an explicit "no." A policy that fails to mention a practice does not automatically mean that the practice does not exist.
How I Built It
The frontend is built with:
- HTML
- CSS
- Vanilla JavaScript
The backend runs through a Vercel serverless function.
Gemini is accessed through Google's @google/genai SDK and is used for structured evidence extraction.
The backend validates the model response before passing it to the scoring layer. The scoring rubric, validation rules, and application logic are implemented in code rather than delegated to the model.
The project is deployed on Vercel and the source code is available on GitHub.
Security Considerations
Because the application processes user-supplied policy text, that text is treated as untrusted input.
The Gemini prompt explicitly instructs the model to treat the policy contents as data rather than instructions, reducing the risk of policy text attempting to override the analysis instructions.
The frontend also renders returned content safely using DOM text nodes rather than injecting model-generated content as HTML.
API credentials remain server-side and are not exposed to the frontend.
Challenges
One of the biggest challenges was getting useful AI analysis without letting the model control the final interpretation.
A simple approach would have been to ask an AI model for an overall privacy rating, but that would make the result harder to verify and reproduce.
Instead, I had to design structured classifications, validation rules, evidence requirements, and a deterministic scoring layer around the model.
Another challenge was handling ambiguity correctly.
For example, "not stated" is not the same thing as "no," and a narrowly scoped statement about AI or model use should not automatically be interpreted as a global statement about all data.
I also tested the analysis pipeline against real privacy policies during development to refine the extraction behavior and evidence handling.
What I Learned
This project taught me that using AI in a product does not mean giving the model responsibility for everything.
A stronger architecture can come from giving the model a narrow, well-defined job and keeping important application decisions in deterministic code.
I also learned how important evidence and scope are when building tools that analyze natural-language documents. A concise answer is not necessarily a trustworthy answer unless the user can understand where it came from.
Limitations
Privacy Policy Decoder analyzes the policy text supplied by the user. It does not independently verify whether an organization's real-world practices match its published policy.
The A–F result is a project-defined scoring framework, not an industry-standard privacy score.
The application is also not legal advice and does not determine regulatory compliance.
Why I Built It
The goal is simple:
Make privacy policies easier to understand without pretending that an AI summary is a legal judgment.
Privacy Policy Decoder is an attempt to make the first step of understanding a privacy policy faster, clearer, and easier to verify.
Log in or sign up for Devpost to join the conversation.