Abstract

AI systems are only as trustworthy as the data governance underneath them, and most organizations have not done the foundational work of inventory, classification, and access control before connecting AI tools to their environments. This gap is driving a measurable rise in shadow AI incidents and breach costs, and it now extends into overlooked risk areas such as AI notetakers recording board meetings. This article argues that organizations must govern the data itself, treating AI agents as privileged identities and fixing excessive access before AI inherits it, rather than relying on AI specific policy alone. Drawing on recent breach data and firsthand GRC and IAM governance experience, it outlines four practical principles for closing this gap.

Every organization racing to deploy AI is making a quiet bet: that the data those systems will touch is well understood, properly classified, and appropriately access-controlled. In my work reviewing vulnerability assessments, IAM environments, and third-party risk programs across financial services and technology clients, I can tell you that for most organizations, that bet is wrong, and most leaders do not find out until an incident forces the conversation. The gap is rarely a lack of intent. Security and compliance teams generally know classification matters, know lineage matters, and know access reviews matter. What they lack is the operational discipline to keep that foundation current while the business keeps generating new data, new systems, and now, new AI tools that consume all of it at once.

AI does not create data security problems from nothing. It finds every weakness that was already there: the shared drive nobody has cleaned up since 2019, the “temporary” admin access nobody revoked, the customer database with no owner of record, and it moves through them faster than any human ever could. I have seen this pattern play out directly in vulnerability assessment work, where classification gaps that sat quietly for years suddenly became urgent the moment a client wanted to connect an AI copilot to the same environment. The underlying weakness was not new. What changed was the speed and reach of the tool now sitting on top of it, and that is the shift most organizations are still not prepared for.

The Problem isn’t AI. It’s What AI is Standing On

Most enterprise data environments were never built with AI in mind. They were built incrementally, department by department, system by system, with data inventory and classification treated as a compliance checkbox rather than a living discipline. The result, in a large number of organizations, is a foundation with three familiar cracks:

• No current data inventory. Nobody has a reliable answer to “what data do we have, where does it live, and who owns it.”
• Broken or missing lineage. Data moves between systems, gets copied, transformed, and reused, with no record of where it came from or what it’s allowed to be used for.
• Inconsistent classification. Sensitive data, including PII, financial records, credentials, and source code, often sits unlabeled next to genuinely public material, in the same folders, the same databases, and the same permission groups.

When AI tools are layered onto that foundation, they do not fix it. They index it, summarize it, and surface it, often to people, prompts, and third-party services that were never meant to see it. In practice, that means a chatbot trained to “help employees find information faster” ends up surfacing a compensation spreadsheet, an unredacted contract, or a regulator’s findings letter to whoever happens to ask the right question.

Shadow AI: Governance Losing Ground as Usage Grows

“Shadow AI,” meaning employees and business units using AI tools without security or IT approval, has gone from a side issue to a headline risk in a single year. According to IBM’s 2026 Cost of a Data Breach Report, shadow AI now shows up in 43% of breaches investigated, more than double the 20% recorded a year earlier, and those incidents run notably more expensive, averaging $5.39 million compared with $4.63 million previously. Roughly one in five of these cases also carried a regulatory fine (Kiteworks, 2026a; ComplexDiscovery, 2026).

What makes this trend more alarming is the direction of travel on governance itself. Over that same period, fewer organizations required IT sign-off before an AI tool could be deployed, a requirement that dropped from 45% down to 38% even as unauthorized use climbed. More than two-thirds of the breached organizations in the study had no AI governance policy in place at all, and coordination between governance and security functions was rare: only about one in five reported the two teams actually working together (ComplexDiscovery, 2026).

Access control tells the same story. IBM’s researchers point to identity and access management as one of the strongest levers organizations have for reducing breach costs, yet fewer than half of the organizations studied, just 40%, had actually applied access controls to their AI models and the data behind them. The tooling to close that gap exists. What is missing is the discipline to apply it consistently, and that gap between what is possible and what is actually enforced is where most of these incidents originate (ComplexDiscovery, 2026).

The downstream impact of ungoverned AI use is concrete, not theoretical. Close to half of the shadow AI incidents IBM tracked led directly to data loss or compromise, roughly four in ten disrupted business operations, and about a third left organizations dealing with reputational fallout (ComplexDiscovery, 2026).

When “Checking a Script” Becomes a Data Leak

The clearest illustration of how shadow AI turns a data classification gap into an actual incident is Samsung’s 2023 experience with ChatGPT, which is still cited constantly because it captures the pattern so cleanly. Samsung lifted an internal ban on the tool in 2023, and within about three weeks, three separate incidents had occurred. An engineer ran proprietary semiconductor source code through the tool looking for bugs. Another employee submitted defect-detection code in search of optimization tips. A third turned an internal meeting recording into a written transcript and handed that transcript to the chatbot as well (The Daily Brief, 2026).

None of those three employees set out to leak anything. Each was doing what looked like a reasonable productivity shortcut. What made it a breach was the absence of anything standing between “sensitive data” and “external AI service,” meaning no classification flag, no data loss prevention control, and no policy anyone had internalized.

That pattern has not gone away; it has scaled. More recent research puts the typical organization at roughly 223 AI-related policy violations every month, with source code making up a large chunk of them, and finds that nearly half of employees using generative AI, 47%, are doing so through personal accounts that sit completely outside what security teams can see or control (Kiteworks, 2026b).

Who’s Actually in The Room? Board Meetings and AI Notetakers

One version of this risk deserves its own attention because it is showing up in boardrooms right now, often introduced with the best of intentions. Board secretaries and executive assistants, under real pressure to produce accurate minutes quickly, have started routing board meetings and executive sessions through AI notetakers such as Otter.ai, Fireflies.ai, Read.ai, and similar tools built into Zoom, Teams, and Google Meet. It is an understandable shortcut. It is also one of the highest risk data governance decisions an organization can make without realizing it, since board conversations are frequently the single most sensitive, most privileged, and most regulator relevant content an organization produces.

The risk is no longer hypothetical. A security flaw disclosed in the AI meeting assistant tl;dv in August 2026 meant that being signed in was, on its own, enough to browse meeting records that belonged to other customers. Most of what leaked was metadata, but a portion of accounts had full transcripts and attendee email addresses sitting fully exposed, and the researcher who found the flaw was able to join live sessions hosted by a government ministry and by students at a US university. At any given moment, close to a thousand meetings could be seen actively recording through the exposed system, turning a productivity tool into something closer to an open window into other organizations’ private conversations (Happy Scribe, 2026; Dark Reading, 2026).

Separately, a nationwide class action filed against Otter.ai in 2025 is still working its way through the courts. The complaint describes the company’s meeting assistant entering calls on its own, capturing and transcribing what was said without getting permission from every participant, and holding onto that data indefinitely, including using it to further train the underlying AI models. Picture that same tool sitting in a board meeting where outside directors, auditors, or legal counsel are on the call. The moment even one attendee outside the organization was never asked for consent, that gap alone can be enough to trigger a personal data breach notification obligation under a regime like the GDPR (Babst Calland, 2026).

There is a second layer of exposure that is specific to boards: privilege and discovery risk. Corporate counsel writing on this trend have singled out board meetings, executive strategy sessions, and legal consultations as the settings most likely to hand an opposing party an argument that attorney-client privilege was given up the moment an AI notetaker, and by extension the vendor behind it, had a seat at the table. Courts are already testing that theory. In United States v. Heppner (2026), a federal court in the Southern District of New York refused to treat materials a defendant had produced using a consumer AI platform as privileged, an early signal of where this line may end up being drawn (Mayer Brown, 2026).

The lesson for board secretaries and governance professionals is not “never use these tools.” It is that board content needs the same classification and access discipline as any other regulated data asset before a notetaker is ever turned on: confirm the tool is approved and covered by a data processing agreement, confirm where transcripts are stored and for how long, and treat “record the board meeting” as a decision that belongs in the data governance program, not as a convenience setting an assistant enables on their own.

Govern the Data, not Just the AI

The instinct in a lot of boardrooms right now is to buy an “AI governance” tool, publish an AI acceptable use policy, and consider the problem addressed. That is necessary, but it treats the symptom. The underlying exposure is a data governance problem that predates AI and will outlast whatever policy gets written this quarter. A few principles matter more than any specific tool, and they line up closely with the access governance work I do with clients day to day.

1. Data inventory and classification come first, not alongside.

You cannot govern access to data you cannot describe. Before any AI system, whether a copilot, an agent, or an internal model, gets connected to a data source, that source needs a known owner, a classification level, and a documented lineage of where the data originated and where it flows.

2. Treat AI agents like privileged identities, because that’s what they are.

An AI agent with a service account and broad read access to a file share or database is not a tool; it is a non-human privileged identity, often with more reach than most human employees ever get. It should go through the same lifecycle as any privileged account: least privilege provisioning, periodic access review, session logging, and de-provisioning when the use case ends. This is not an abstract recommendation. In one recent IAM governance engagement, I consolidated over 340 individual identities across a hybrid Entra ID and on premises Active Directory environment into federated SSO with zero standing privileged accounts sustained for twelve consecutive months. That is exactly the discipline an AI agent’s access needs applied to it before it ever touches production data, not after.

3. Fix excessive access before AI inherits it.

This is the step most organizations skip. AI tools are typically deployed against existing permission structures, which means every over-provisioned folder, every stale access grant, and every “just in case” admin role becomes something the AI can now surface, summarize, and act on at scale. An access review that was low priority before AI becomes urgent the moment an AI agent is connected. Excessive access does not get less dangerous because an AI system is now the one using it; it gets more dangerous, because the AI can retrieve and act on it faster and more broadly than any single employee could.

4. Lineage and monitoring are not optional extras.

Knowing what data an AI model was trained on, what data it retrieves at inference time, and where its outputs go is what makes an incident containable instead of catastrophic. Without lineage, a data exposure investigation starts from zero.

Organizations That Are Closing the Gap

The picture is not uniformly bad. Where organizations have made real progress, the pattern is consistent: they extended existing data governance discipline into AI workflows instead of trying to bolt on something new, which mirrors how I approach AI risk governance work with my own clients.

One case study in recent governance literature describes a data leader who chose not to rebuild her organization’s data governance program from the ground up just because AI had entered the picture. She took what already existed, the metadata standards, the lineage tracking, the data quality rules, and stretched it to cover AI model development too, brought data stewards into the model build process itself, made sure someone was clearly accountable for both the AI systems and the data feeding them, and updated existing policy so it spoke to the NIST AI Risk Management Framework rather than sitting apart from it. Trust in the underlying data improved across departments, regulators got answers faster, and one-off compliance reviews became less frequent (Dataversity, 2026). It is roughly the same sequence I followed when I built an AI Risk Governance Framework for a managed services provider client: map the framework to NIST AI RMF and the EU AI Act’s risk tiers, build a shadow AI inventory before writing a single new control, and only then define the acceptable use rules everyone was waiting for.

The broader trend supports this approach. Gartner’s forecasting suggests that by this year, three times as many large enterprises will have data lineage tooling in place compared with where the market stood back in 2023, a jump that reflects lineage moving from a nice-to-have into a baseline expectation for any organization serious about AI (Quinnox, 2026). And on the identity side, IBM’s own breach data makes the financial case for closing the access control gap: organizations that lean heavily on security AI and automation cut their average breach cost by nearly two million dollars and shortened containment by more than two months, proof that AI pointed at strengthening governance, rather than left to outrun it, pays for itself (Kiteworks, 2026a).

The Bottom Line

AI does not introduce a new category of data risk so much as it puts an accelerant on the data risk your organization has been carrying for years. Poor inventory, broken lineage, inconsistent classification, and excessive access are old problems, and I still find them in nearly every environment I assess. What is new is the speed and scale at which AI can find and exploit them, and the fact that every AI agent connected to your environment, and every AI notetaker sitting quietly in your board meetings, is functionally a new privileged identity that inherits whatever access sloppiness already exists.

The organizations pulling ahead are not the ones with the most sophisticated AI governance policy on paper. They are the ones that did the unglamorous work first: know your data, classify it honestly, fix who and what can access it, and only then let AI anywhere near it.

References

Babst Calland. (2026, February 18). Who’s really in the room? Hidden risks of AI note-takers. https://www.babstcalland.com/news-article/whos-really-in-the-room-hidden-risks-of-ai-note-takers/

ComplexDiscovery. (2026, August 3). Policy without control: The AI governance gap in IBM’s 2026 Cost of a Data Breach Report. https://complexdiscovery.com/policy-without-control-the-ai-governance-gap-in-ibms-2026-cost-of-a-data-breach-report/

Dark Reading. (2026, August 4). AI notetaker exposes government, corporate video calls. https://www.darkreading.com/application-security/ai-notetaker-spy-government-corporate-video-calls

Dataversity. (2026, July 30). Data governance frameworks for AI compliance. https://www.dataversity.net/articles/data-governance-frameworks-ai-compliance/

Happy Scribe. (2026, August 5). tl;dv security breach: What it means for anyone using or building an AI notetaker. https://www.happyscribe.com/blog/tldv-security-breach

Kiteworks. (2026a, July 30). The IBM 2026 Cost of a Data Breach Report proves AI governance failure, not AI itself, is driving costs. https://www.kiteworks.com/cybersecurity-risk-management/ibm-2026-breach-report-ai-governance/

Kiteworks. (2026b, January 9). 2026 AI data security crisis: Shadow AI & data governance strategies. https://www.kiteworks.com/cybersecurity-risk-management/ai-data-security-crisis-shadow-ai-governance-strategies-2026/

Mayer Brown. (2026, June 3). AI notetakers: Productivity tool or emerging legal risk? https://www.mayerbrown.com/en/insights/publications/2026/06/ai-notetakers-productivity-tool-or-emerging-legal-risk

Quinnox. (2026, August 11). Data governance for AI in 2026: Challenges, best practices and solutions. https://www.quinnox.com/blogs/data-governance-for-ai/

The Daily Brief. (2026, August 2). Shadow AI costs enterprises $670K per breach in 2026. https://www.beri.net/article/shadow-ai-enterprise-governance-gap-2026

United States v. Heppner, No. 25 CR. 503 (JSR), 2026 WL 436479 (S.D.N.Y. Feb. 17, 2026).

About the author

Bola Mabawonku is a Senior GRC Manager and Cloud Security Architect with over five years of experience delivering cybersecurity programs across financial services, healthcare, and technology sectors. He holds the CISM, CRISC, CISSP, and CCSP certifications and has built and led enterprise security programs from the ground up. His work spans governance, risk, cloud security architecture, compliance automation, and detection engineering.

Portfolio: bolamabawonku.com  ·  LinkedIn: linkedin.com/in/bolarinwa-mabawonku