Every AI feature that sends WordPress content to a third-party model, OpenAI, Anthropic, Google, or any other provider, is sending data somewhere outside your own infrastructure. If that content includes personal data, a customer’s name in a support message, a commenter’s email, a user’s uploaded document, you’ve made a data-sharing decision, and data protection law in many jurisdictions, GDPR most prominently for a track this broad, has things to say about data-sharing decisions. This lesson covers the general principles at a level useful for a developer making day-to-day decisions. It is deliberately not a legal opinion.
Course 1’s overview of the PHP AI Client SDK and Course 4’s data minimization lesson. This lesson assumes you understand that an AI feature typically sends a prompt to an external API.
This lesson describes general, publicly-documented principles behind data protection law, largely drawing on GDPR as the best-known framework, at a level intended to help a developer reason about design choices. It is not legal advice, it does not tell you whether your specific feature is compliant, and it cannot account for your organization’s actual data flows, user base, or jurisdiction. Any real compliance determination should involve your organization’s own legal counsel or data protection officer.
Step 1: Recognize when your AI feature is a data transfer
The general principle worth internalizing first: sending user data to a third-party AI provider’s API is, functionally, sharing personal data with an external processor, no different in kind from sending it to any other external service. It doesn’t matter that the “third party” is an AI model rather than, say, an email marketing platform, the underlying question is the same one you’d ask about any integration: what personal data is leaving our systems, who is it going to, and under what terms.
Step 2: The general idea of a “lawful basis”
GDPR-style frameworks generally require that any processing of personal data rest on one of a small set of recognized justifications, commonly described as a “lawful basis.” Consent is the one developers reach for reflexively, but it is typically just one option among several, others include that the processing is necessary to perform a contract with the person (fulfilling an order), a legal obligation, or a legitimate interest of the business that doesn’t override the individual’s rights. Which basis applies, if any, to a given AI feature is a legal and factual determination, not something this lesson can answer generically. The practical takeaway for a developer is narrower: know that “we’re processing this data because the feature needs it” is not, by itself, a sufficient answer, and that someone in your organization should be able to state which basis applies before a feature ships.
Whether consent, contract, legitimate interest, or another basis applies to a specific AI feature depends on facts this lesson cannot know: what the feature does, what data it touches, and which jurisdictions its users are in. Confirm the actual basis with whoever owns privacy compliance in your organization, don’t infer one from this lesson.
Step 3: Where consent is the right mechanism
Consent tends to be the appropriate mechanism when processing is optional, from the user’s perspective, and not something the core service depends on. A “summarize this page with AI” button a visitor can choose to click is a reasonable candidate for a consent-style pattern: clear, specific, and not bundled into unrelated terms. A general, GDPR-consistent shape for that kind of consent looks like this at a design level:
A practical, illustrative pattern: gating an AI feature behind a real settings toggle that a site owner (or, for a user-facing AI feature, the end user) controls, and checking that toggle before any data leaves your infrastructure.
// File: my-plugin.php
// Illustrative only: an explicit, checked opt-in before any AI call happens.
function my_plugin_ai_processing_allowed( int $user_id ): bool {
return (bool) get_user_meta( $user_id, 'my_plugin_ai_consent', true );
}
// Called before constructing any prompt that includes this user's content.
if ( ! my_plugin_ai_processing_allowed( get_current_user_id() ) ) {
return new WP_Error( 'consent_required', 'AI processing requires opt-in for this account.' );
}This is a pattern, not a compliance guarantee, whether it satisfies a legal requirement for your specific feature is exactly the kind of question to route to legal counsel.
Step 4: Practical habits, independent of the legal answer
Several habits are worth adopting regardless of exactly which lawful basis applies, because they reduce risk either way and are good engineering practice on their own terms:
Apply it: audit one AI feature’s data flow
For one AI feature you maintain, write down: what personal data (if any) reaches the prompt, which provider receives it, whether that provider’s terms cover training use, and whether a consent mechanism gates the feature today. If any of those are unclear, that’s the concrete action item to bring to your privacy or legal contact.
Recap
Sending content to a third-party AI provider is a data-sharing decision like any other integration, and GDPR-style frameworks generally expect a recognized lawful basis behind any processing of personal data, consent being one option among several, not the only one. The practical developer habits, minimizing data, reading provider terms, documenting data flows, reduce risk regardless of exactly which legal basis applies. None of this lesson is a substitute for confirming the actual compliance posture of a real feature with qualified legal counsel.
Resources & further reading
- GDPR.eu, general compliance guidance, gdpr.eu
- GDPR.eu, “What is GDPR?”, gdpr.eu
- Privacy guide for plugin developers, developer.wordpress.org