Skip to main content

Ask five people to define "data governance" and you'll get five different answers. Tim Fisher, DPM's VP of AI, isn't surprised by that. "I don't know that there is a really established definition that every company [uses]," he says. "For some people it means the legal team telling them what they can and cannot do, and in other parts of the organization it means very different things."

For the purposes of this piece, we're using it the way Fisher does when pushed to define it precisely: the policy and legal layer of who can access data, under what consent, subject to what rules — not whether the data itself is accurate, current, or well-organized. That second question is real, and it's a different discipline with different fixes; we're covering it separately. This piece is about the policy question, and why it can't wait.

When Fisher narrows the definition down, he lands on a specific place inside an org chart. "I think of data governance more around the policies and the principles," he says — and in a larger company, he locates it precisely: "The sort of overlap in the Venn diagram between legal and data ops."

Create a Free Account to Read More

Unlock this piece and join a community of forward-thinking leaders discovering tools, playbooks, and insights for thriving in the age of AI.

This field is for validation purposes and should be left unchanged.
Name*
This field is hidden when viewing the form
This field is hidden when viewing the form
This field is hidden when viewing the form
This field is hidden when viewing the form
By submitting you agree to receive occasional emails and acknowledge our Privacy Policy. You can unsubscribe at any time.

I think of data governance more around the policies and the principles. The sort of overlap in the Venn diagram between legal and data ops.

Tim Fisher Headshot-69614

Tim Fisher

VP of AI at The Digital Project Manager

That overlap isn't abstract. Fisher points to a much older, very concrete reason companies build these structures in the first place: securities law. "In the US, the Securities and Exchange Commission sets very stringent rules around what can and cannot be said or shared for very obvious reasons, with insider trading and stuff like that," he says.

"So that's a reason for a company to have data governance." He ties this directly to the company growth stage — the move from private to public is often when governance stops being optional, as outside consultants get brought in specifically to build the structures a public company is legally required to have.

That's the part worth sitting with before anything else: governance existed as a hard legal requirement long before AI showed up. What's changed is the speed and surface area of the risk — which is where things get urgent for anyone running operations today.

Join the DPM community for access to exclusive content, practical templates, member-only events, and weekly leadership insights - it’s free to join.

This field is for validation purposes and should be left unchanged.
Name*
This field is hidden when viewing the form
This field is hidden when viewing the form
This field is hidden when viewing the form
By submitting you agree to receive occasional emails and acknowledge our Privacy Policy. You can unsubscribe at any time.

Why AI makes this a more urgent concern for ops leaders

Companies have always had data they weren't supposed to share carelessly. What's new is how easy it is now to share it without anyone deciding to. Fisher's clearest example is a setting most employees have walked past without noticing: "The little toggle that they've never seen, that’s buried five layers down in the settings page that gives OpenAI or Anthropic access to all this data to train their algorithms," he says. Nobody has to intend to leak anything. The default just has to go unchecked.

That's the mechanism behind most AI-era governance failures: teams "throwing" proprietary or HR information into LLMs "without understanding" what they've actually consented to, because nobody built the policy layer that would have flagged it before it happened. Fisher is blunt that this isn't a rare misstep — "we've all heard horror stories about source code being surfaced to the wrong people. It can happen."

The tension is structural, not a failure of caution. "You have this awkward place where you're growing," Fisher says. "You feel the need for some rules, but you don't want to handcuff your teams too much." Every ops leader balancing AI adoption against security is living in exactly that gap — and AI didn't create the underlying legal exposure, it just made it possible to trigger by accident, at scale, through a settings menu nobody read.

You have this awkward place where you’re growing. You feel the need for some rules, but you don’t want to handcuff your teams too much.

Tim Fisher Headshot-69614

Tim Fisher

VP of AI at The Digital Project Manager

Where operations leaders are actually exposed

The highest areas of consideration for ops leaders are:

  • Employee personal data. Staffing plans, HR records, and performance information that can end up inside an AI tool's context window without anyone actually consenting to it being there.
  • Financial and disclosure-sensitive information. Material nonpublic information, earnings data, and anything that would trigger SEC disclosure concerns if it leaked or reached the wrong person at the wrong time.
  • Proprietary and IP-sensitive information (including source code). A pure access-control and confidentiality risk — separate from securities regulation — but the same underlying mechanism as any other unmonitored AI default.
  • Client project data. Proprietary client information run through AI tools without contractual or consent clarity carries the same exposure, even without a specific breach on record yet.

Most companies don't have any of this

Despite the stakes, Fisher is blunt that many organizations are operating with no policy layer at all. "Lots of organizations have no data governance whatsoever," he says.

He's watched this play out from both ends. At a larger, more established company, he saw governance "taken very seriously over a long period of time," to the point that it became increasingly conservative — and increasingly hard to unwind. Smaller, faster-growing companies have the opposite problem: not too much caution, but none at all, layered on top of pressure to move fast.

The takeaway for delivery leaders

You don't need to build a full governance framework to take the first step. Start with something small and concrete: go check a settings menu. Fisher's toggle example is real and findable — find out whether your org's AI tools are set to train on your data by default, and who signed off on that. That's a conversation you can have this week, not a project.

Worth holding alongside that, though, is a genuine tension Fisher raises: gatekeeping isn't automatically the safe choice. "Even in organizations where data is readily available, it's often still seen as proprietary even when it doesn't need to be," he says — and locking things down by default can quietly cost a company as much as leaving them wide open, just less visibly. "You're not going to make inroads to changing if you don't change who has access to your data in your organization." Good governance isn't just fewer people touching data — it's the right people touching the right data, on purpose.

Even in organizations where data is readily available, it’s often still seen as proprietary even when it doesn’t need to be.

Tim Fisher Headshot-69614

Tim Fisher

VP of AI at The Digital Project Manager

In practice, that means a few concrete moves, not a policy binder:

  • Start the conversation now, before an incident forces it. Ask which teams are already using AI tools, and how — most ops leaders are behind on this simply because no one asked.
  • Check org-wide tools first. Whatever AI platforms are sanctioned company-wide, confirm the training-data default and who has visibility into what's flowing through them.
  • Don't ignore personal or unofficial tool use. The bigger risk is often the AI tool nobody approved — someone pasting client notes into a personal ChatGPT account because the sanctioned tool is slower. Surfacing that isn't about punishment, it's about knowing where your exposure actually is.
  • Build the access review into the same conversation, not a separate one. While you're checking defaults and AI tool use, ask who's gatekeeping data that doesn't need to be gatekept. Tightening one door while leaving another one wide open isn't governance — it's theater.
  • Train people to recognize sensitive data, not just follow rules. Most employees have never been asked to think about what counts as sensitive — client details, HR records, financial information — or what could go wrong if it ends up in an unregulated tool. A policy telling people what not to do matters less than people actually recognizing the risk in front of them.

None of this requires slowing teams down to get it right. It requires knowing where your data is going, who decided that, and whether the answer is still yes.

Want more insights like these? Sign up for a free DPM account to hear from more experts like these.

Kristen Kerr

Kristen is an editor at the Digital Project Manager and Certified ScrumMaster (CSM). Kristen lends her over 6 years of experience working primarily in tech startups to help guide other professionals managing strategic projects.