Farewell, Dr. No: How Data Security Enables AI Innovation

The Essential Role of Security and Governance

Data security and governance, risk, and compliance (GRC) are essential functions in large organizations. For the professionals in charge of security and GRC, the watchword has always been “control”. Control where data is stored, when it can be moved, who has access to it, and how it can be used for business purposes.

The key performance indicators are clear: no data breaches, no violations of governance guidelines, minimal risk. Failure to achieve these goals can result in massive financial penalties (potentially in the hundreds of millions), as well as loss of reputation and customer confidence.

Security and GRC teams have historically taken a conservative approach. They often deny requests for access to information, prevent data transfer across borders, and ask business teams to proceed slowly on new initiatives that involve use of protected information.

As a result, data-security and GRC teams are frequently derided as the “Department of No” – a moniker that reflects the frustration business teams feel when they encounter multiple review cycles, extensive audits, and repeated requests for more detail.

AI Turns Everything Upside Down

Never easy, the job of data security and GRC teams has become more complicated with the arrival of agentic AI. It has fundamentally changed the volume and variety of data being requested, as well as the speed with which answers are expected. More users and business units are seeking greater amounts of data for AI projects that stretch the boundaries of security and governance practices. And this expands the surface area of risk.

Case in point: The CISO of one major entertainment company I interviewed said his department has been hit with “an avalanche” of requests for data related to AI projects. Another CISO, at a large healthcare organization, described AI as creating “a mess” in his department: “Identity inheritance, prompt injection, DLP consistency, inference, and malicious proxy detection all become harder to manage once multiple agents, protocols, and model layers are involved.”

The flood of AI projects has heightened tensions between business units that want to use more data, and security/governance teams that scramble to protect it. When faced with “no” or long approval cycles, business teams are often motivated to seek workarounds, including shadow AI.

Senior leaders now give top priority to moving AI projects from POC into production. And this puts security and governance teams on the hot seat to keep pace and do everything they can to enable AI-fueled projects. As one CISO put it, “we’re all here to support the business.” But he also acknowledged that “AI adoption is accelerating faster than governance processes can scale, especially as every SaaS platform adds AI features and the business pushes for greater productivity.”

Another CISO I spoke with summarized user attitudes like this: “Our teams are passionate about what they do and are driven to succeed. They don’t like to hear ‘no’. So, the cybersecurity team has to produce evidence and justification when blocking a request, which increases the manual burden on us even more.”

It’s now politically and competitively difficult for security/GRC to say ‘no.’ The question for them now is whether the answer always must be ‘yes’.

The Only Constant is Change

This isn’t the first time IT management has faced the need to adapt to new technologies.

The move to DevOps challenged traditional views of roles and responsibilities, and raised concerns about stability, security, and control. There were cultural and organizational implications when enterprises made the move from centralized database administration to relational databases and SQL.Not to mention the impact of the rapid transition from mainframes to minis, to desktops, to laptops, to mobile devices.

In all instances, departments that initially said “no” adapted and evolved. Data security and GRC must do the same. Accountability hasn’t changed, but expectations have.

A New Approach to Security and Governance

Here’s our perspective on how security governance and AI initiatives can take a leap forward.

The most fundamental change is approach. Instead of being the “Department of No,” security and compliance teams can now become the “Department of Know” How? By applying their experience, expertise, and perspective to enable business units to safely populate their AI models with contextualized and protected data that meets the highest standards of security and governance.

Their default answer to requests for data access is no longer “No.” Instead, it becomes “Yes, and here’s how we can help.”

The Case for New Best Practices

Here are six best practices that can help security and governance teams meet business needs for successful AI projects without compromising security and GRC requirements.

1. Address security and governance from the very start with the data itself

Legacy approaches to data security have employed a “locked gates and high walls” approach to preventing data breaches. These perimeter measures attempt to prevent bad actors from reaching critical data which might provide them something of value. That’s how some companies end up paying millions in restitution and regulatory fines even with security and governance measures in place.

What if, instead, security techniques (like masking, tokenization, and anonymization) were embedded in the data layer itself – such that even if a bad actor were to reach the data, it would have no value to them?

With this approach, data is protected and governance is assured – at rest, in transit, and during analysis. Protection becomes a one-time activity that doesn’t need to be repeated every time an authorized party requests access. The same holds true for governance measures like data sovereignty and compliance audits.

2. Explore the context of requests instead of making predetermined decisions

One of the ways security and governance teams can apply their expertise is to engage with the business units to understand the goals of their AI projects. At an early stage, they can suggest the best options for accessing useable and protected data.

Data security experts can help design queries that reduce risk and avoid compliance issues. For example, instead of using highly sensitive data like dates of birth, they can query by age ranges, or by ZIP code rather than individual addresses. This is what we mean by saying “Yes, and here’s how we can help.”

3. Create or join multi-disciplinary teams to collaborate on security/compliance issues

As mentioned, I conducted in-depth interviews with CISOs at almost twenty large organizations from different industries. One of the takeaways was the extent to which data security and governance are owned by multiple departments, not just security or IT groups.

The CISO of a large consulting firm noted that his security organization collaborates with business units around the globe, as well as central IT and legal affairs. Many companies told us that buying decisions for security-related products and services are now made by cross-functional committees representing as many as seven corporate functions.

I spoke with someone at a large advertising company. The deputy CISO explained the impact of a highly decentralized operation: “We have nine lines of business and historically each line has had its own IT and security teams. We’ve been trying to bring these together.”

Cross-functional teamwork can have many benefits. It can reduce the number of steps and the time needed for approval of requests for data access. It’s also an opportunity for all affected parties to learn what AI projects are expected to achieve for the business and what risks they may pose to data security and governance.

4. Simplify the process for requests

Virtually everything these days is automated and digitized, so security/governance procedures are no different. The process of reviewing and acting on requests for data could be streamlined and accelerated by:

• a standardized list of the most common types of requests;
• self-service forms for submitting requests and checking status;
• guidelines for what types of requests are and aren’t normally approved; and
• a list of pre-approved third-party tools and vendors that can be used without engaging in shadow AI.

The idea here is to replace toll booths that slow access to data with maps that help guide business users toward their desired destination.

5. Set an expectation of approval so long as established procedures are followed

This means clearly defining in advance what those procedures are. Requests can’t go into a black box that produces decisions based on opaque reasoning. Corporate data and governance rules should promise predictable response times.

6. Measure success differently

Finally, data-security and GRC teams can measure success and progress well beyond a reduction or halt in breaches or violations. For example, average time to approve requests, percentage of requests approved; and percentage of requests approved automatically.

The Impact: Reduced Data Friction

Moving from “No” to “Know” isn’t just a change in attitude. It can have positive impacts on employee morale, efficiency, competitive advantage, and even revenue.

When business units and AI architects have easier access to data, they can complete their work faster and more efficiently, potentially accelerating the deployment of new applications, products, and services.

And when teams have easier access to data, job satisfaction rises and there’s less incentive to engage in shadow AI.

The Protegrity Advantage

Security and governance teams are being asked to do two hard things at once: move faster and lower risk. That is where Protegrity helps. By protecting the data itself, Protegrity makes it easier for approved users to get the data they need for AI without losing control of sensitive information. That is the shift from the Department of No to the Department of Know: helping the business move faster with data that is safe, useful, and ready for AI. The answer is not access without control, or control without access. It has to be both.