I Built an AI That Reads Terms of Service So You Don't Have To Building PrivacyGuardian AI for HACKHAZARDS '26

Disha Maurya — Tue, 07 Jul 2026 05:37:28 +0000

The problem

Nobody reads Terms of Service or Privacy Policies. Not because we don't care about our data — because they're deliberately long, dense, and written in legal language designed to discourage exactly the kind of scrutiny that would make us think twice before clicking "I agree."

Existing tools that try to solve this, like ToS;DR, rely on human volunteers manually reviewing documents. That means they only cover a small number of major companies, and reviews take weeks. Everything else — the smaller apps, the niche services, the new startup you just signed up for — goes completely unreviewed.

I wanted to build something that could do this instantly, for any document, not just the top 50 companies.

What I built

PrivacyGuardian AI takes any Terms of Service, Privacy Policy, or EULA — pasted in or uploaded — and returns:

A Privacy Health Score (0-100) based on a documented, consistent scoring rubric
A plain-English breakdown of what data is collected and why
Flagged risky clauses (forced arbitration, perpetual content licenses, mandatory AI training, liability waivers) with a real-world explanation of what each one actually means for the user
A Compare Two Policies mode that puts two competing services side by side and tells you which one is actually more privacy-respecting
A grounded chat assistant so you can ask follow-up questions about the specific document you just analyzed
A downloadable PDF report

Tech stack

Google AI Studio + Gemini for the core analysis engine, using structured JSON output (via responseSchema) so results render reliably as UI components instead of unpredictable free text
React for the frontend, built and iterated inside AI Studio's Build feature
jsPDF for client-side PDF generation, so reports can be exported and shared without needing a backend document service

The part that actually mattered: the scoring rubric

Early versions of this project had a subtle but serious problem: the privacy score, the risk level badge, and the final recommendation were all being generated somewhat independently by the model. That meant I'd occasionally get a report where the score said "65" but the recommendation said "Not Recommended" — internally contradictory, and exactly the kind of inconsistency that destroys trust in a tool whose entire value proposition is trust.

The fix was to stop letting the model freely decide all three values separately. Instead, I defined an explicit five-tier rubric:

ScoreRisk LevelRecommendation85-100SafeSafe to Accept65-84LowSafe to Accept45-64MediumProceed with Caution25-44HighNot Recommended0-24CriticalNot Recommended

Then I built a single shared function that every part of the app — the score gauge, the badges, the exported PDF, the preset demo cards — pulls from. One source of truth, everywhere. The model only decides the score; everything else is derived deterministically. That one change eliminated an entire category of bugs at once.

Other real bugs I hit (and what they taught me)

Preset labels lying about real output. I had demo documents pre-labeled "Moderate Risk" that, when actually analyzed, returned Critical-level results. The label and the substance had drifted apart because I'd changed the badge text without re-verifying the actual document content still matched. Lesson: never trust a label — always re-run the real analysis after any change.

Silent JSON parsing failures. When I moved to lazy-loading detailed sections (to speed up Compare mode), two specific sections started throwing Unexpected token '<'... is not valid JSON — meaning the frontend was receiving an HTML error page instead of JSON from a broken endpoint. It's a good reminder that "the build succeeded" and "the feature actually works when clicked" are two very different claims, and only manual testing catches the gap.

Compare mode was too slow. Running two full document analyses sequentially, then a third synthesis call, added up fast. Switching to Promise.all so both documents analyze in parallel, plus trimming the initial payload to only what's needed for the comparison view, cut the wait meaningfully.

No real document should score a perfect 100. Even the best privacy policy has some standard legal boilerplate. Capping the maximum score at 98 was a small change, but it made the tool feel more honestly calibrated rather than defaulting to an unrealistic "perfect" score.

What I'd build next

A browser extension that offers to analyze whatever site's ToS you're currently on, rather than requiring you to remember to open the app
RAG-based retrieval over long documents instead of prompt-stuffing the whole text, for better accuracy on very long policies
A "what changed" diff feature — re-analyzing a policy you've seen before and highlighting what's new

Closing thought

The most useful part of this build wasn't the initial prompt-to-app generation — it was the second half: catching the places where the AI's own summary of "I fixed it" didn't match what actually rendered on screen. Building with AI tools moves fast, but verifying what they build is still very much a human job.

Built solo for HACKHAZARDS '26, organized by NAMESPACE. Track: Trust, Identity & Security.__

DEV Community: Disha Maurya

I Built an AI That Reads Terms of Service So You Don't Have To Building PrivacyGuardian AI for HACKHAZARDS '26