SIW Executive Q&A: AI Governance Starts with Data Governance

Artificial intelligence is rapidly reshaping enterprise operations, from copilots and generative AI platforms to automated analytics and cloud-based workflows. Yet as organizations race to deploy AI capabilities, many security leaders are discovering that the greatest risks often have less to do with the AI tools themselves and more to do with the data that powers them.

As information moves through increasingly interconnected ecosystems of cloud applications, APIs, vector databases, third-party providers, and AI models, questions surrounding visibility, accountability, retention, and governance are becoming central concerns for security and risk management teams.

In this Executive Q&A, Shane Tierney, Senior Program Manager, Governance, Risk, and Compliance (GRC) at Drata, discusses why traditional security approaches focused on access controls and application governance are no longer sufficient in the AI era. Drawing on more than 15 years of experience building governance, privacy, compliance, and risk programs across multiple industries, Tierney argues that organizations must shift toward a data-centric governance model that emphasizes accountability throughout the entire data lifecycle.

He also explains why AI is transforming cybersecurity into what he calls a "data supply chain" challenge and why boards, regulators, and customers are increasingly demanding greater transparency in how organizations manage and protect information in AI-enabled environments.

SIW: Many organizations are focused on governing AI tools themselves. Why do you believe that approach is incomplete?

Tierney: Many organizations still approach AI governance primarily through the lens of the tools they use. They focus on identifying approved AI platforms, evaluating vendor security controls, and restricting access to authorized users. Those are all important steps, but they only address a portion of the overall risk.

The larger challenge lies in the data moving through those systems. AI technologies are increasingly connected to customer communications, support tickets, internal documentation, meeting transcripts, source code repositories, and operational data. Once information begins flowing through copilots, summarization engines, vector databases, and third-party AI features, the conversation extends well beyond determining which tools are approved.

At that point, organizations face a data accountability issue. Security leaders must be able to explain what information enters AI-enabled workflows, where it travels, how long it remains available, and whether it is used for training, indexing, or other secondary purposes. Without that visibility, even strong identity management and monitoring controls may fail to prevent sensitive information from appearing in places where the organization never intended it to reside.

That's why organizations need to move beyond a tool-centric mindset and adopt a workflow- and data-centric approach to governance. The greatest risks are rarely tied to a single AI platform. They emerge from the way data is handled across interconnected systems, vendors, and models.

SIW: You describe AI risk as a "data supply chain" problem. What does that mean in practice?

Tierney: Traditionally, cybersecurity programs have focused on protecting infrastructure, endpoints, applications, and identities. AI introduces an additional layer that cuts across all of those domains: the data pipelines that feed and surround AI systems.

Today, information often moves through highly complex chains involving APIs, cloud platforms, copilots, embeddings, indexes, and external model providers. A single AI-enabled workflow may simultaneously interact with internal repositories, third-party SaaS applications, and downstream analytics systems.

Regulators and boards are increasingly asking those same questions. They want to know where sensitive data could surface within AI systems, which vendors or subprocessors may interact with that information, and whether the organization can clearly explain how retention, deletion, and data isolation mechanisms actually function. Those are fundamentally questions about data lineage and accountability rather than application security alone.

SIW: Why are traditional controls such as IAM, DLP, and tool whitelisting no longer sufficient on their own?

Tierney: Those controls remain essential, but they were largely designed around the assumption that access to information is temporary and transactional. AI changes that assumption significantly.

In traditional environments, removing access typically ends exposure. AI workflows can be different. Information may persist within vector databases, embeddings, logs, evaluation datasets, or fine-tuned models long after the original access path has been removed. Once data enters those environments, organizations need stronger governance over how information is retained, reused, and constrained over time.

As a result, security leaders can no longer focus solely on who has access to a particular application. They also need clear policies governing what types of information can be ingested into AI systems, whether that data contributes to training or indexing activities, how long derived artifacts remain available, and what deletion and isolation actually mean in operational terms.

The vendor component is equally important. Traditional third-party reviews often concentrate on encryption, uptime, and access controls. AI requires organizations to look much deeper into how vendors handle customer information. Security teams need visibility regarding whether customer data is used for training, how prompts and outputs are retained, which subprocessors are involved, and how tenant separation is enforced.

Without those answers, organizations are relying on trust where they should be relying on verifiable controls, contractual protections, and operational transparency. The governance challenge ultimately becomes much broader than application security. It becomes a question of managing the full lifecycle of organizational data within AI-enabled ecosystems.

SIW: What should "data accountability" mean for security leaders?

Tierney: Data accountability is a term that gets used frequently, but it often lacks operational definition.

For security leaders, data accountability should mean having the ability to describe, control, and demonstrate how specific categories of information move through AI-enabled workflows over time, both internally and across third-party providers.

Organizations should be able to identify sensitive data, trace its movement, explain why it is being used, and demonstrate the controls governing retention, reuse, and isolation.

Access management remains an important component of governance, but accountability is the broader outcome organizations must be prepared to demonstrate to regulators, auditors, customers, and boards.

The most mature organizations are embedding AI governance into existing business processes rather than creating entirely separate governance structures. They are incorporating AI considerations into architecture reviews, vendor risk assessments, incident response planning, and change management activities. That integration is important because AI is no longer an isolated initiative. It is becoming embedded in everyday business operations, which means governance must also become part of the organization's normal operating rhythm.

Another important priority is reducing shadow AI activity by providing employees with secure and sanctioned alternatives. Simply blocking tools is rarely effective over the long term. Organizations must make approved AI solutions easier, faster, and more useful than unsanctioned options.

SIW: What are boards and executive leadership teams expecting from security leaders when it comes to AI risk?

Tierney: The conversation has evolved dramatically over the past year.

Early board discussions often focused on competitiveness, innovation, and whether organizations were adopting AI quickly enough. Today, those conversations are much more operational and governance-oriented.

Boards increasingly want to understand how AI intersects with regulated or sensitive information, how third-party providers handle organizational data, and whether the company can defend its governance framework if regulators, customers, or business partners begin asking more detailed questions.

Importantly, boards do not expect security leaders to eliminate AI risk altogether. That's neither practical nor realistic. What they do expect is evidence that AI-related risks are being managed like any other material business risk—identified, measured, monitored, and continuously improved over time.

The larger shift is that security leadership is increasingly becoming data leadership. Organizations that treat AI governance as a temporary compliance exercise or a collection of tool restrictions will struggle because the technology ecosystem is evolving too quickly and becoming too interconnected.

The organizations that will be most successful are those that build accountability directly into the data itself through clear lineage, well-defined controls, strong vendor expectations, and explicit operational ownership. Ultimately, the differentiator will not be how quickly organizations adopted AI. It will be whether they can demonstrate that AI operates on top of a secure, transparent, and well-governed data foundation.

Because in the end, you cannot govern AI unless you can govern the data it touches.