It’s tempting to treat “AI governance” as something that happens in a policy document,
owned by legal or compliance, arriving as a set of requirements a developer implements
and moves on from. That model breaks down fast with AI features, because the actual
governance-relevant decisions get made inside the code, not around it. Whether an
ability’s output_schema includes a customer’s phone number, whether a prompt sent to a
third-party model includes a user’s full name and address, whether an AI-moderation
feature was tested against more than one kind of input, none of that shows up in a policy
document. It shows up in a pull request. This lesson makes the case, concretely, for why
that puts real governance responsibility on the developer, not instead of legal and
privacy teams, but alongside them.
Course 1’s understanding of abilities and output_schema, and Course 4’s data
minimization and audit-logging lessons. This course builds directly on both.
Step 1: Governance decisions already live in your codebase
Course 4 covered data minimization as a security practice: a narrow output_schema
protects against leaking data through an ability. The same design choice is also, from a
different angle, a data protection decision. If an ability returns a customer’s billing
address to an AI agent, that’s not only a bigger attack surface, it’s also personal data
now flowing to wherever that agent’s response ends up, potentially a third-party AI
provider’s servers, a chat transcript, a log file outside your control. The security
lesson and the governance lesson point at the same line of code.
Step 2: Why legal and privacy teams can’t see this on their own
A privacy team can write “don’t send unnecessary personal data to third parties” as a
requirement. They generally cannot read execute_callback and confirm whether that
requirement is actually met, and they usually don’t have visibility into what a given
ability’s output_schema declares versus what the function underneath it actually
returns when called. That’s not a criticism of privacy teams, it’s a description of where
the information actually lives. The person who wrote the ability, or who’s reviewing the
pull request that adds one, is the person positioned to notice a full customer object
being passed through instead of a narrow, deliberate array.
Recognizing that governance-relevant decisions happen in your code doesn’t mean you’re now responsible for deciding what the law requires. It means you’re responsible for surfacing the technical facts, what data moves where, under what conditions, so that whoever does own the compliance decision can actually make an informed one.
Step 3: Security controls and governance are related, not identical
Course 4 built real security controls: permission_callback gates, Application
Password scoped access, rate limiting, an audit log. Those controls answer “can this
actor do this thing.” Governance asks a related but different question: “should this
data move this way at all, and can we show that decision was deliberate.” A perfectly
permission-gated ability can still be a governance problem if it exposes more personal
data than its purpose requires, or if nothing records that it ran. This course treats the
security work from Course 4 as a prerequisite, not a substitute, for the governance work
here.
| Course 4 control | Governance question it doesn’t fully answer |
|---|---|
permission_callback | Even a correctly-permitted caller might receive more data than the stated purpose needs. |
Narrow output_schema | Narrow for whom, and was that narrowing reviewed against an actual privacy requirement? |
| Custom audit log (Course 4, Lesson 8) | Logs the ability and user. Does it capture what a compliance review needs, purpose and data sent? Lesson 7 of this course extends it. |
Step 4: A first mental model for where your judgment ends
A rough, practical line: ordinary engineering judgment covers “does this feature do what it’s supposed to, safely and minimally.” It stops being purely an engineering call the moment a decision depends on facts about the law, which jurisdictions apply, what counts as a legally adequate consent mechanism, whether a specific AI use case falls into a regulated risk category. When you hit that kind of question, the right move is not to guess and ship, it’s to flag it explicitly to whoever owns legal risk for the organization, with the technical facts laid out clearly enough that they can actually decide.
Nothing in this course, including this lesson, is telling you what a specific law requires for your specific site. It’s teaching you to recognize when a technical decision has crossed into territory where a non-technical, qualified person needs to be involved. That distinction matters throughout the rest of the course.
Apply it: map one existing AI feature
Pick one AI feature you’ve already built, or one from an earlier course in this track. Answer three questions about it in writing:
- What personal data, if any, does it send to an AI provider, and is that obvious from reading the code, or does it take digging?
- Is that data flow logged anywhere a compliance reviewer could find it later?
- Would you know who to ask if someone requested that this feature stop processing their personal data?
If any answer is “I’m not sure,” that’s the gap the rest of this course closes.
Recap
AI governance isn’t a separate track that runs parallel to development, its consequences are decided inside the code you already write: what an ability returns, what a prompt contains, whether an action leaves a record. Security controls from Course 4 are a necessary foundation, but they answer a different question than governance does. The right instinct isn’t to become your organization’s legal expert, it’s to recognize governance-relevant decisions when you’re making them and surface the technical facts to whoever does own that call.
Resources & further reading
- Abilities API reference, developer.wordpress.org
- Privacy guide for plugin developers, developer.wordpress.org
- WordPress MCP Security & Authentication, this track, Course 4