Enterprise AI Strategy: Data Governance and Vendor Agnosticism

Everything so far in this course has been architecture and code. This lesson is different: it’s the conversation you’ll actually have with a CTO, a data protection officer, or a procurement team before an enterprise signs off on WordPress AI integrations at scale. Two concerns dominate that conversation, and they’re related but distinct: vendor lock-in (are we permanently dependent on one AI provider’s pricing and availability) and data governance (what data actually leaves our infrastructure, to whom, and under what terms, every time an ability gets called by an external agent).

Step 1: Vendor lock-in is a real, quantifiable risk, not paranoia

Every time your code hardcodes a call to one AI provider, you’ve coupled your product’s availability and cost structure to that vendor’s pricing changes, rate limits, and uptime. The PHP AI Client SDK’s using_model_preference() exists specifically to break that coupling:

// File: my-plugin.php
$response = wp_ai_client_prompt( $prompt_text )
	->using_model_preference( 'claude-sonnet-4-5', 'gemini-3-pro-preview', 'gpt-5.1' )
	->generate_text();

For an enterprise, this isn’t a nice-to-have, it’s the difference between “we can switch providers in a config change if pricing or terms shift” and “our entire AI feature set depends on one company’s roadmap.” Frame this explicitly when talking to stakeholders: provider preference lists are the WordPress-native equivalent of a multi-cloud strategy, applied to LLM vendors instead of infrastructure vendors.

Step 2: Trace exactly what leaves your site, and when

There are two entirely separate data flows in this stack, and enterprises need both explained clearly, in plain language, because they carry different risk:

Both directions need a governance answer. For the first, the question is “which abilities are marked meta.mcp.public => true, and does every one of them return data this specific external client is allowed to see.” For the second, it’s “does the prompt text we’re sending to a third-party model contain PII, customer records, or anything covered by a data processing agreement we haven’t actually signed with that provider.”

Step 3: Concrete governance questions, not vague compliance language

When an enterprise asks “is this compliant,” the useful answer is a checklist, not a reassurance. For every ability marked publicly exposed via MCP:

• Does its output_schema return any field that’s personally identifiable, financial, or otherwise regulated data?
• Is the calling client (identified via Application Password or session) restricted to a specific role with a real audit trail (Course 4’s patterns), or can any authenticated user reach it?
• If this ability’s result is later fed into an external AI model by the calling client (not your code, theirs), do you have any contractual visibility into that at all? Usually the honest answer is no, and that’s worth stating plainly rather than implying otherwise.

For every call your own code makes via wp_ai_client_prompt():

• Which provider’s data processing terms actually apply to this specific prompt, determined by the runtime preference resolution, not just the first item on your list?
• Is there a way to redact or exclude specific fields before they’re interpolated into a prompt string, and is that redaction actually implemented, not just assumed?
• Does the provider retain prompt data for model training by default, and did you configure the account-level setting (most providers have one) to opt out, where required?

Step 4: meta.mcp.public is a governance control, not just a switch

Course 1 introduced meta.mcp.public as the technical gate on whether the MCP Adapter exposes an ability at all. In an enterprise context, reframe this the same way you’d reframe a database column-level permission: it’s the single enforcement point where a data governance decision becomes a code-level fact, checked on every request, not a policy document nobody re-reads after the initial sign-off.

'meta' => array(
	'mcp' => array( 'public' => false ), // Default: not exposed until a governance review approves it
),

Treat flipping this value to true as requiring the same review as opening a new external API integration, because functionally, that’s exactly what it is.

Test it

Audit an existing site: list every ability currently marked publicly exposed, and for each one, write down in one sentence what data it returns and who’s allowed to call it.

wp-env run cli wp eval '
foreach ( wp_get_abilities() as $ability ) {
	$meta = $ability->get_meta();
	if ( ! empty( $meta["mcp"]["public"] ) ) {
		echo $ability->get_name() . "\n";
	}
}
'

If you can’t immediately answer “what does this return, and who can call it” for every name in that list, that’s the governance gap to close before the next review.

Recap

Vendor agnosticism through using_model_preference() protects an enterprise from pricing, outage, and policy risk tied to a single AI provider, and should be treated as a reviewable policy decision, not just a coding default. Data governance means tracing both directions of data flow, agents calling your exposed abilities, and your own code calling out to AI providers, and answering concrete, specific questions about each one. meta.mcp.public is where that governance decision actually gets enforced in code.

Resources & further reading

• PHP AI Client SDK repository, GitHub
• Abilities API reference, developer.wordpress.org
• MCP Adapter announcement: from abilities to AI agents, developer.wordpress.org