The standard advice when legal and engineering keep missing each other is to communicate better: more meetings, a shared glossary, a compliance person in both rooms. Corné Potgieter argues the opposite on Towards Data Science: the unstructured handoff is the failure, so encode legal intent into machine-readable contracts and let systems check them. He calls it observable compliance. I buy it, and privacy governance on a WordPress site can start this week, without a data platform or a two-hundred-entry catalogue.
The reason this stops being theoretical now is agents. WooCommerce ships MCP abilities, store owners wire up assistants that read order data, and nothing in that stack asks what purpose a query serves. It just pulls the rows. Stores hit this before enterprises do, because a store’s data fits in one head until it doesn’t.
Why another meeting never fixes it
Law is written as narrative on purpose. It leaves room for interpretation, context and mitigation, and lawyers are trained to work in that room. Systems don’t have that room. The article puts it in one line:
When legal says, “It depends,” IT thinks, “I cannot build this.”
The format of the handoff is what breaks, and goodwill won’t fix a format problem. The article cites a study that checked 110 data access requests against privacy policies automatically. It caught every issue a human expert flagged, and raised 3.6 times more warnings, 80 percent of which the experts later agreed were valid. Humans kept the final call on every flag. That is the split I would copy.
WordPress already ships half a privacy governance layer
Since 4.9.6, core has a privacy toolkit: personal data exporters and erasers registered through wp_privacy_personal_data_exporters, wp_privacy_anonymize_data() for consistent masking, export files that expire on their own. The Consent API has been a feature plugin since 2020, and in December 2024 the core privacy team pushed again for adoption. It’s still a plugin you have to install, and few plugins declare support.
What none of that gives you is purpose. Exporters answer what you hold on a person, not whether a feed may be used for model training. The distance between your privacy policy PDF and those hooks is the data-contract gap the article describes. On our stack the contract does not need to be YAML in Git, though it can be: a signed-off option holding purposes, retention and a masking flag is a contract code can read and refuse. I wrote about core’s remaining privacy gap separately if you want the longer version.
The five answers legal owes you
Before writing any gate, get binary answers to the article’s own questions, once per dataset you ship somewhere:
- Is this field personal data?
- Can this dataset be used for model training?
- What retention period gets enforced?
- Should this attribute be masked or removed?
- What exactly counts as anonymisation here?
Legal can then answer yes, no, or permitted under recorded conditions, and each condition becomes a column in your option. Anything that cannot be answered in binary goes back to a person rather than into code.
What I’d build on a WooCommerce store
One function and one option. The option holds the purposes legal signed off on, and whether each export may carry identifiable fields. The function refuses everything else, and it belongs in front of anything with a model behind it, including the AI features people enable without reading the settings.
<?php
/**
* Purposes legal signed off on, and whether the
* export may carry identifiable fields. Written at
* activation, versioned in Git.
*/
function bbioon_orders_feed( string $purpose ): array|WP_Error {
$approved = get_option( 'bbioon_export_purposes', array() );
if ( ! isset( $approved[ $purpose ] ) ) {
return new WP_Error(
'bbioon_unapproved_purpose',
sprintf( 'Purpose "%s" has no recorded sign-off.', $purpose )
);
}
$identifiable = (bool) $approved[ $purpose ]['identifiable'];
$orders = wc_get_orders( array( 'limit' => 20 ) );
return array_map(
static function ( WC_Order $order ) use ( $identifiable ): array {
$email = $order->get_billing_email();
return array(
'id' => $order->get_id(),
'total' => $order->get_total(),
'billing' => $identifiable ? $email : wp_privacy_anonymize_data( $email, 'email' ),
);
},
$orders
);
}wp_privacy_anonymize_data( $email, ’email’ ) is core’s own anonymiser, so masked exports match what core produces elsewhere. A missing purpose returns a WP_Error instead of quietly filtered data. Silent fallbacks are how gates die, because nobody notices when one is shut.
Where this stops working
The other side has a point. Legal prose is vague because edge cases are real, and a hard gate built on a careless yes is worse than nothing, since it looks enforced. Keep an escape hatch for the ambiguous cases and review the purpose list when guidance moves, not on a schedule you invented.
The article’s own warning applies here: when a process gets this clean, reviewers start checking the shape of the output instead of its substance, and consent flags nobody verifies become decoration. I’m not sure a purpose list survives first contact with a marketing team asking for one more segment, so treat every addition like a deployment, dated and attributed.
If your store feeds AI features and nobody can answer those five questions in writing, that is the work I do: sit with your legal contact, pin the purposes down, and wire the gate into the exports that matter.
Don’t turn blocking on in week one. Run the check in log-only mode for a month and read what it catches. If the flags look wrong, the allowlist is wrong. And if legal will not commit to the vocabulary at all, skip the code, because a gate nobody owns moves the liability onto whoever wrote it.
