This lesson explains a real, meaningful architectural choice and its practical implications. It is not legal advice, and it is not a substitute for a qualified lawyer’s review of your specific site, jurisdiction, and data. Treat it as a starting point for that conversation, the same caveat Course 16 opens with.
Every piece built across this course, indexed content and its embeddings in Lesson 2’s custom table, session transcripts in Course 11’s transients, chat logs in Lesson 8’s table, leads in Lesson 7’s custom post type, lives in one place: your site’s own WordPress database. That wasn’t an accident of convenience. It’s a real, defensible architectural decision with actual consequences for data residency, and this closing lesson makes that decision explicit instead of leaving it implicit.
Every prior lesson in this course. This lesson is a synthesis, not new code.
Step 1: an honest accounting of what actually leaves your server
Nothing in this course is worth much without being precise about this, so here it is plainly:
Step 2: why this is a real advantage, not a marketing line
A third-party SaaS chatbot product typically stores your conversations, your indexed content, and your leads on that vendor’s infrastructure, under that vendor’s retention policy, subject to that vendor’s own subprocessors and data transfer arrangements. This course’s architecture is different in a way that has real, concrete consequences:
GDPR’s data protection by design principle isn’t a checkbox, it’s an architectural posture: build systems that minimize data movement and maximize the controller’s actual control over personal data, from the start, rather than retrofitting compliance onto a system that scattered data across third-party services by default. Storing chunks, transcripts, and leads in your own database from the first line of code this course wrote is a real, working instance of that principle, not a claim made after the fact.
Step 3: what this course did not solve, said plainly
Owning the database does not mean no data ever leaves your infrastructure. Every call to
AiClient::input()->generateEmbedding() and every call to wp_ai_client_prompt()
sends the relevant text to whichever AI provider your site is configured to use. That
provider’s own data handling, retention, and whether it trains on submitted data are
real questions this course’s architecture does not answer for you, they depend entirely
on which provider you’ve configured and what contractual terms govern that relationship.
Data residency for storage and genuine data minimization in what gets sent per call are
related but distinct problems, this lesson has only addressed the first.
A visitor’s chat message can contain personal data, an email address, an order number,
a name, without any special handling in this course’s code. Nothing built here scrubs
PII before it reaches wp_ai_client_prompt(). That’s a deliberate scope boundary, not an
oversight, Course 16’s PII-handling lesson covers detecting and redacting that kind of
content before it ever reaches a prompt, and is worth building on top of everything in
this course before a real production launch.
Step 4: where the fuller picture lives
This lesson is a recap of an architectural choice, not a compliance program. AI Governance, Compliance & Responsible AI for WordPress, Course 16, is where the legal and regulatory depth actually lives: consent for AI-processed data, the EU AI Act’s risk tiers as they apply to a support chatbot specifically, honest content disclosure, PII redaction before it reaches a prompt, and audit trails built for a compliance review rather than just debugging. Everything this course built, indexed content, embeddings, transcripts, leads, is exactly the kind of system Course 16 assumes you already have when it asks harder questions about consent and retention.
Test it: verify your own accounting
Before calling this course’s chatbot production-ready, confirm the same claims Step 1 made are actually true of your own build:
wp-env run cli wp eval '
global $wpdb;
echo "Chunks stored: " . $wpdb->get_var( "SELECT COUNT(*) FROM {$wpdb->prefix}ai_chunk_embeddings" ) . "\n";
echo "Chat log rows: " . $wpdb->get_var( "SELECT COUNT(*) FROM {$wpdb->prefix}ai_chat_log" ) . "\n";
echo "Leads stored: " . count( get_posts( array( "post_type" => "chat_lead", "posts_per_page" => -1 ) ) ) . "\n";
'Then check your AI provider’s own dashboard or API logs for the same period and confirm what was actually sent matches only the per-call text this lesson described, not entire transcripts or full indexed documents dumped wholesale on every request.
Recap
This course built a chatbot whose content, embeddings, conversations, and leads all live in your own WordPress database, a real and meaningful data-residency choice, not an incidental detail. That doesn’t eliminate every data-protection question, provider calls still leave your infrastructure by necessity, and PII handling in prompts remains a real, unsolved concern this course deliberately left to Course 16. What it does give you is control: over retention, over deletion, over backups, and over knowing precisely what leaves your server and what never does. That’s the foundation this entire course was built to hand you, a chatbot that answers accurately, hands off to a human cleanly, and keeps its data where you can actually account for it.