Auditing a Vendor's "GDPR Compliant" Claim: A Technical Checklist for Devs

If your team is evaluating a third-party AI tool — chatbot, avatar widget, whatever — and the vendor's site just says "GDPR compliant" with no elaboration, that's not enough to sign off on from an engineering risk standpoint. Here's a concrete, testable checklist for what to actually verify before integrating, using the kind of embeddable AI avatar tools (e.g. nemynai.com.ua) as a reference case for the category.

Why "Compliant" as a Single Claim Is Insufficient

GDPR compliance decomposes into distinct, independently verifiable mechanisms. A vendor can have solid consent capture and a completely unenforced retention policy. Treating "compliant" as binary hides exactly the gaps you need to know about before integrating their widget into your stack.

Checklist Item 1: DPA Availability and Sub-Processor List
Request: "Can you provide your DPA and a list of sub-processors
(LLM provider, TTS provider, hosting, CRM backend)?"

Good signal: Named providers, specific data flows documented
Red flag: Generic response, no named sub-processors,
"we'll get back to you" with no follow-up

Sub-processors matter technically because each one is a place your data actually goes. If a vendor uses a third-party LLM API and TTS provider, your users' conversation data transits through those systems too — this needs to be in the DPA, not just implied.

Checklist Item 2: Test the Actual DSAR Process

Don't just ask if a data subject access/deletion process exists — test it if possible during a trial:

1. Create a test lead/conversation with a known test email
2. Submit a deletion request through whatever channel they document
3. Time how long it takes and verify data is actually gone
4. Check: does deletion cascade to backups, or just the primary DB?

A vendor with a working, fast DSAR process demonstrates it more convincingly than any policy document could.

Checklist Item 3: Retention Enforcement, Not Just Policy
Ask directly: "Is retention deletion an automated scheduled job,
or a manual process someone runs periodically?"

This is a meaningfully different engineering answer. "We delete data after 90 days" as a written policy with no automated enforcement is a claim, not a system behavior. Ask if they can describe (even at a high level) how retention is technically enforced.

Checklist Item 4: PII Minimization in Third-Party API Calls
Ask: "When a conversation is sent to your LLM provider,
is the visitor's name/email/phone included in that payload,
or only the conversational content needed to generate a response?"

This is a good technical litmus test — a team that's thought carefully about data minimization will have a clear, specific answer. A team that hasn't considered this will often not understand the question or give a vague response.

Checklist Item 5: Cross-Border Transfer Mechanism
Ask: "Where is conversation/lead data physically stored/processed,
and if outside the EU, what transfer mechanism applies
(SCCs, adequacy decision, etc.)?"

For any non-EU vendor handling EU personal data — relevant for a lot of regionally-built tools, including e.g. Ukrainian platforms like NemynAI serving EU-based business customers — this needs a specific answer, not a general "we take privacy seriously" statement.

Scoring the Responses
python
def compliance_signal_score(vendor_responses):
score = 0
if vendor_responses.get("dpa_available"): score += 1
if vendor_responses.get("named_subprocessors"): score += 1
if vendor_responses.get("dsar_process_documented"): score += 1
if vendor_responses.get("retention_automated"): score += 1
if vendor_responses.get("pii_minimization_confirmed"): score += 1
if vendor_responses.get("transfer_mechanism_named"): score += 1
return score # 6 = strong signal, 0-2 = needs real scrutiny before integrating

This isn't a formal audit framework — just a practical way to convert vague reassurance into something your team can actually compare across vendors.

Why This Is an Engineering Concern, Not Just Legal

If your team integrates a vendor's widget and it turns out their compliance claims don't hold up under a specific question, your application inherits that risk — you're the one who put the script tag on your site. Pushing for specifics before integration is a reasonable, low-cost step compared to the cost of unwinding a bad vendor relationship after a data subject complaint or an audit.

Takeaway

"GDPR compliant" on a landing page is marketing copy until it's backed by verifiable specifics: a real DPA, named sub-processors, an automated retention job, minimized PII in third-party calls, and a documented transfer mechanism. For any vendor your team is considering integrating — from major platforms down to smaller regional tools — asking these five questions directly, and actually testing the DSAR process during a trial period, tells you more than any compliance badge on their homepage.