When AI governance lands on privacy's desk

Many privacy professionals are being asked to help lead artificial intelligence governance before their organizations have answered a more basic question: What part of AI governance actually belongs to privacy?

Some of the work is familiar. Anyone studying for the AI Governance Professional certification, sitting through AI governance training or reviewing a vendor's responsible AI framework may recognize much of the underlying operating model. Risk assessment, data use analysis, vendor oversight, transparency, documentation, accountability, human review, escalation and evidence have long been part of privacy work.

The vocabulary is different. The acronyms are different. The technical context may be more complex. But the operational shape is not entirely new.

The harder issue is not whether privacy professionals have relevant knowledge. They do. The harder issue is knowing how to sort the work when AI governance arrives as one large, undifferentiated assignment.

In practice, the work tends to fall into four categories: what privacy professionals already know how to do, what privacy professionals need to learn, what belongs with another function, and what should be procured or supported externally. 

When those categories are blurred together, AI governance can feel bigger, newer and more intimidating than it needs to be. That is often when privacy professionals start questioning their footing and reaching for another credential, another framework or another tool before recognizing the judgment they have already developed.

The practical frame I have come to use is what I call the "working partition: keep, learn, redirect, buy." It is not meant to be fixed or universal. It is a way to locate the work before deciding how to approach it.

I tested an earlier version of this framing in a recent conversation on the "Let's Talk Privacy" podcast with Aakash Suri. The response from privacy practitioners suggested it helped name something many people are already experiencing. AI governance is not one job; it is a set of responsibilities that need to be sorted before they can be managed.

Keep

The first quadrant is the operational judgment work that has been part of the privacy profession's daily practice for decades. One reason current AI governance frameworks feel familiar is that many of the underlying concepts are familiar. 

Long before AI governance became a common topic in corporate training, the privacy community was already working through purpose limitation, secondary use analysis, identifiability assessments, accountability documentation, harm-mitigation reviews, redress methods, disparate impact assessments and fairness reviews.

These are not merely adjacent to AI governance. In many organizations, they form part of its substance.

More than 15 years ago, the Centre for Information Policy Leadership was developing the accountability frameworks that now inform many AI governance approaches. Its 2024 report, "Building Accountable AI Programs," maps CIPL's seven-element privacy accountability framework directly onto AI systems.

The same is true of the operational research. Nymity's Privacy Management Accountability Framework was released in 2012 and mapped to more than 800 privacy laws, regulations and guidelines; it was built to bridge privacy and data protection laws and principles to demonstrable operational compliance. That is the same gap AI governance now asks privacy teams to close. 

The 2019 submission I co-authored with Terry McQuay to the U.S. National Institute of Standards and Technology's Privacy Framework request for information sets out the underlying research, treating accountability as a menu of organizational measures rather than a checklist.

Civil society organizations and privacy think tanks were also early to the substance, even if the vocabulary was different. The Future of Privacy Forum was documenting and categorizing the harms of automated decision-making by 2017. The Center for Democracy and Technology launched its Digital Decisions project in 2015, convening industry, researchers, government officials and civil rights advocates to develop principles for fair algorithmic decision-making. 

The Electronic Privacy Information Center has long advocated for algorithmic transparency in scoring and screening systems, as well as for algorithmic impact assessments. Much of this work was not called AI governance at the time, but it is directly relevant to what AI governance programs are now expected to address.

The U.S. Federal Trade Commission's 2016 "Big data: A Tool for Inclusion or Exclusion? Understanding the issues" report applied disparate impact analysis to algorithmic decisions under existing civil rights law years before current state AI legislation made that analysis a compliance requirement. Consumer scoring harms, automated decision-making risks and the need for impact analysis were being named by privacy advocates well before they became mainstream regulatory vocabulary.

The IAPP Salary and Jobs Report 2025-26 finds that 68% of privacy professionals have taken on AI governance responsibilities. That reflects something the profession already knew: Much of the work AI governance now requires builds on work privacy professionals have been doing for years.

The first quadrant is not something to learn from scratch; it is something to identify, claim and adapt. The practical step is to inventory what your privacy program already does so existing processes can be reused and extended rather than rebuilt under new vocabulary. That is why the older accountability work matters: It shows that privacy is not entering AI governance as a newcomer but applying an established body of operational practice to a new generation of systems and legal requirements.

Learn

The second quadrant is where many privacy professionals are understandably anxious. While automated decision-making and advanced analytics have long been part of privacy work, current use cases and legal requirements are evolving faster than most organizational structures. The technical issues that affect how AI work are scoped, contracted, monitored and audited have real substance.

Privacy professionals do not need to become machine learning engineers, but they do need enough fluency to ask questions that a standard privacy intake form may not capture.

Consider data subject deletion requests. A privacy team may already know how to assess where personal data is held, which vendors process it and whether deletion is required. The additional question is whether the personal data was used to train a model and what deletion means in that context.

If personal data has been used to train a model, removal may require retraining, specialized unlearning techniques or other controls many vendors have not implemented at scale. A system that ingested personal data in a training run two years ago may not be able to honor a deletion request in an operationally meaningful way, even if the contract uses familiar deletion language.

The privacy professional's role is not necessarily to design the technical control. It is to know enough to ask: What does deletion mean for this system and how can the answer be demonstrated?

The same "keep" and "learn" logic applies across the program. Privacy teams may keep their privacy-by-design process but learn how to integrate AI-specific review points. They may keep their vendor due diligence process but learn which additional questions matter for the AI system in scope. They may keep their incident response policy but learn how to incorporate serious AI incidents and related obligations under emerging law.

The same pattern applies to purpose limitation when a foundation model is used across multiple downstream applications to training data provenance and to model update cadence. The underlying privacy question may be familiar. The artifact, evidence and technical context may be different enough to matter.

Redirect

The third quadrant is where privacy professionals are often absorbing work that does not belong to them, largely because no one else has clearly claimed it and leadership is looking to the privacy function for an answer.

Privacy is well positioned to identify gaps, translate obligations into practical requirements and help define the governance structure. But identifying the required policy, process, procedure or control is not the same as owning the implementation.

For example, privacy may require high-risk AI systems undergo bias testing before deployment and ongoing monitoring after release. 

The data science team should own the testing procedures, metrics and technical execution. Privacy may help define a requirement that AI systems be monitored for alignment with applicable law. Engineering, machine learning or platform teams should define the methods.

This reflects the same accountability principle that Nymity's research described more than a decade ago: Privacy can help define what must happen, but accountability for execution often needs to sit with the business function closest to the work.

The challenge is that, in many organizations, the receiving functions for genuinely new technical work are underdeveloped or do not yet exist. Machine learning engineering may consist of a small, overloaded group. AI security may be unstaffed. Platform governance may be immature. In that environment, the default response is often to absorb the work into privacy.

That may solve the immediate problem, but it can dilute the privacy function over time.

Adversarial threat testing for prompt injection, model extraction and data poisoning belongs with security. The OWASP Top 10 for LLM Applications 2025 guide is written for security teams. Model lineage instrumentation through AI bills of materials and model cards belongs with machine learning, engineering or equivalent technical teams. 

Architecture controls for agentic systems belong with platform or engineering teams. For high-risk systems, the threat surface may be sophisticated enough to require third-party support, including external red teaming, independent audits of bias testing or assurance reviews of monitoring tools.

Redirecting work is not the same as refusing to help. It means identifying the right owner, documenting the handoff and ensuring the governance structure reflects how the work will actually be performed. Where partnerships exist, they should be written into governance documents because verbal delegation rarely survives personnel changes, reorganizations or regulatory scrutiny.

Buy

The fourth quadrant is where tooling enters the picture. AI governance may require capabilities such as AI bill of materials tracking, model behavior monitoring, evaluation pipelines, AI risk assessment platforms, workflow tools or independent assurance support.

Most privacy teams cannot build these capabilities themselves on the timelines AI adoption is demanding. Procurement decisions may sit with the business or legal, security, IT, or engineering teams. The privacy function's contribution is to help define the requirements and assess whether vendor answers are credible.

That requires the "learn" quadrant because privacy professionals need enough fluency to know what to ask. It also requires the "redirect" quadrant because the decision about what to buy depends on knowing who will own, operate and maintain the capability after procurement.

This is where the four parts of the "working partition" connect. "Keep" identifies what can be reused. "Learn" identifies what must be understood. "Redirect" identifies who should own the work. "Buy" identifies where external support or tooling is needed.

The most important step is locating the work in the right quadrant before deciding how to approach it.

A working frame, not a checklist

Each quadrant contains more than can be addressed here. The lines will also shift depending on the organization's structure, maturity of the privacy program, strength of relationships with security and engineering and pace of AI adoption across the business.

That is why this is a working frame rather than a checklist.

For privacy professionals, the goal is not to claim all of AI governance, nor is it to step away from it because some parts are technical, new or uncomfortable. The goal is to separate the work into categories that can be managed with greater confidence.

Some of the work should stay with privacy.

Some of it requires new learning.

Some of it needs to be redirected to the right function.

Some of it needs to be bought, supported or independently assured.

The value of the partition is that it turns an overwhelming assignment into a set of decisions. For privacy professionals now being asked to help lead AI governance, that distinction matters.

Special thanks to Alexys Carlton for her practical feedback on this early framing, grounded in her expertise in privacy and AI governance operations.