G2

Vikash K.

SWE

Insurance

Mid-Market (51-1000 emp.)

11/4/2026

"Catches PII leaks to Python logs and external AI sinks in CI, though custom insurance fields needed YAML rule tuning"

4/5

What do you like best about Privado AI?

Our insurance claims payloads mix sensitive policyholder PII, such as home addresses, policy numbers, and bank routing details for Actual Cash Value payouts, right alongside commercial property fields like item descriptions, pre-tax replacement prices, and depreciation rates. Putting Privado AI's static code scanner into our GitHub Actions pipeline gave us a reliable way to trace how personal data elements move through our Python and FastAPI microservices before code ever merges. The strongest part of their architecture is how the privado scan CLI uses AST data-flow analysis to map data sources to four distinct sink categories: console logs, databases, internal APIs, and third-party endpoints. Because the scanner runs locally inside our CI runner and only pushes the generated .privado/privado.json metadata graph to the Privado dashboard, our raw proprietary source code never leaves our infrastructure. Whenever a developer modifies a Pydantic model and accidentally passes a claimant identifier into an unmasked logger.info() call or an external LLM pricing payload, Privado flags the exact file and line number right on the pull request. Review collected by and hosted on G2.com.

What do you dislike about Privado AI?

Out of the box, Privado's default discovery rules easily caught standard identifiers like email addresses, phone numbers, and SSNs, but missed several insurance-specific attributes in our Pydantic schemas such as loss_location_address and payee_routing_number. At the same time, generic variable names on our commercial inventory sheets, like vendor_name or manufacturer_contact for retail suppliers, initially triggered false-positive personal data alerts. I had to spend time writing custom YAML classification rules under rules/sources so the scanner could distinguish commercial retailer metadata from actual policyholder PII. Additionally, because static AST scanning evaluates one repository at a time, it maps data lineage cleanly inside our main FastAPI api-server, but when a claim dictionary is written to our cache layer and picked up asynchronously by separate background worker repositories for categorization or depreciation, the scanner cannot stitch that cross-repo hop automatically without manual linking in the UI. Full repository scans also added a few minutes to our pull request checks until we configured incremental scanning. Review collected by and hosted on G2.com.

What problems is Privado AI solving and how is that benefiting you?

During fast-paced debugging on our claims pipeline, engineers occasionally logged full claim dictionaries using logger.error() to inspect failed rows, or passed raw intake objects directly into third-party search and pricing API requests. Catching those accidental PII leakages during manual peer review was hit-or-miss, and our engineering leads were constantly interrupted by legal and compliance teams asking us to manually fill out lengthy DPIA and RoPA spreadsheets for every microservice update. Privado AI solved both headaches. It blocks unmasked console log leaks and unauthorized external AI data sharing at the CI gate, while its Dynamic Data Maps keep a live visual inventory of which backend services touch personal data so we no longer maintain manual compliance spreadsheets. Review collected by and hosted on G2.com.