For years, information security programs were built around a fairly stable set of assumptions. Users authenticated into systems. Applications processed data. Vendors connected through defined integrations. Logs could be retained, access could be reviewed, data could be classified, and controls could be tested against known frameworks. Risk could be documented in a register and mapped to policies, standards, and audit requirements.

That model still matters. But it is no longer sufficient.

Artificial intelligence has introduced a new operating layer across the enterprise, embedded into productivity suites, security platforms, software development workflows, service desks, data analytics environments, customer support tools, vendor products, and business decision processes. It is not arriving as one system with one owner and one control set. It is arriving everywhere at once, faster than most governance structures were designed to absorb.

That is why AI governance cannot be bolted onto a legacy security program. An AI system does not behave like a conventional application, vendor, user, or data system. It acts across all of them simultaneously, retrieving data, synthesizing information, influencing decisions, automating actions, and inheriting access. The risks are different. The control points are different. The evidence requirements are different. The accountability model is different. Organizations that treat AI as just another application risk will eventually discover they have governed the wrapper and missed the system entirely.

AI Is Already Inside the Security Operating Model

The integration of AI into information security is no longer theoretical. Microsoft has expanded Security Copilot into AI agents designed to assist with phishing investigation, data security, and identity management, framing agentic AI as a necessary response to the speed and complexity of modern attacks. CrowdStrike has built its Charlotte AI capability around human-agent collaboration, investigation guidance, and analyst workflow acceleration. Google’s Big Sleep agent discovered CVE-2025-6965, an SQLite vulnerability assessed to be known only to threat actors and at risk of active exploitation before disclosure.

These are meaningful advances. But they sharpen the governance question considerably. If an AI agent summarizes an incident, what evidence supports its conclusion? If an AI tool recommends disabling an account, who validates that recommendation and under what standard? If a model analyzes sensitive data to detect exposure, what did it access and under what authority? If an AI-enabled vendor becomes part of the control environment, how is that vendor assessed, monitored, and audited over time?

These are not abstract concerns. They are the new control questions, and most existing security programs do not have answers to them.

Traditional Security Controls Were Not Designed for AI Behavior

Most security programs are built around concrete objects: systems, users, roles, applications, devices, databases, networks, vendors, APIs, tickets, policies, and audit artifacts. AI systems are harder to govern because they blur those categories in ways that legacy control architectures were never designed to handle.

An AI assistant may function simultaneously as a user interface, an analytics layer, an automation engine, a data processor, a decision-support tool, and a vendor dependency. It may retrieve information from multiple systems, generate new content, summarize regulated data, influence employee decisions, or recommend security actions, all within a single workflow. The old control language becomes insufficient against that behavioral profile.

It is no longer enough to ask whether the application is patched or the vendor is certified. Security leaders now need to ask what data the AI can access, what decisions it can influence, what actions it can initiate, what human review is required at each stage, what prompts and outputs are logged and under whose authority, what data is retained or reused by the model or vendor, and what evidence demonstrates that the system is operating within approved boundaries.

A legacy control catalog may carry the same names as before: access review, change management, vendor assessment, data classification, logging, incident response. But AI changes how each of those controls must be designed, implemented, and tested. The control may have the same name. The risk is not the same.

Data Exposure Is the First AI Governance Problem

The first serious AI governance problem for most enterprises is not model ethics or algorithmic fairness. It is data exposure, and the scale at which AI can create it.

Most organizations believe their information management programs are effective. Far fewer have actually implemented data classification systems that operate at the level of rigor the claim implies. That gap is not a documentation problem. It is a control problem, and AI makes it catastrophic. An LLM integrated into a corporate environment will synthesize, surface, and distribute information at machine speed across the entire data estate. If your classification framework is aspirational rather than operational, you do not have a data governance program. You have a policy document attached to an exposure engine.

The Samsung incident illustrates how quickly this plays out in practice. In April 2023, engineers at Samsung Semiconductor leaked proprietary source code, test sequences, and internal meeting notes into ChatGPT on at least three separate occasions, all within roughly three weeks of the company lifting its internal ban on the tool. The engineers were not bad actors. They were competent professionals solving real work problems with the tools available to them. Because ChatGPT at the time used input data for model training, Samsung’s proprietary information became part of its knowledge base, available in principle to any of its then-100 million monthly active users. The data was gone before the security team knew it had moved.

The instinct to frame this as a user awareness problem misidentifies the failure. The organization’s existing DLP controls were built to monitor file transfers, email, and endpoint behavior. They were not designed to inspect natural language prompts. The acceptable use policy almost certainly predated the category of risk it now needed to govern. And the vendor risk questionnaire was built to evaluate SaaS applications with discrete, auditable data flows, not model APIs that ingest whatever users type into a prompt field.

AI governance begins with identity and data governance. Before an organization enables broad AI use, it must understand its access model, data classification, retention rules, sensitive repositories, privileged roles, and the exception process for each. The control question is not simply whether the AI tool is approved. The better question is what that tool can reach, and who decided that was acceptable.

Access Management Assumptions Collapse Under AI

The Microsoft Copilot situation has given the industry a sustained and instructive demonstration of what happens when an AI layer is placed on top of an unresolved access hygiene problem. Copilot can access everything a user can within Microsoft 365. When significant percentages of business-critical data are overshared across an organization, an AI system deployed into that environment does not inherit a permissions problem in some marginal or theoretical sense. It inherits it comprehensively and then surfaces that problem to every user, at scale, in natural language.

At Black Hat 2024, security researcher Michael Bargury demonstrated how Copilot Studio bots could exfiltrate sensitive enterprise data by circumventing existing controls, describing data leakage as probable rather than merely possible given the combination of insecure defaults, over-permissive plugins, and optimistic design assumptions baked into the platform. The US House of Representatives subsequently banned staff from using Microsoft Copilot over concerns that sensitive congressional data might be transmitted or stored outside authorized government networks. That reaction reflects a genuine recognition that the access control problem in AI deployments is not a configuration issue to be patched after go-live. It is a pre-deployment governance requirement demanding meaningful preparatory remediation before the first user activates the tool.

Traditional IAM frameworks were built on role-based access, periodic review cycles, and joiner-mover-leaver processes. None of those constructs adequately accounts for an AI agent that can traverse an entire data estate and synthesize findings in response to a single prompt. Least-privilege enforcement in an AI-enabled environment requires a fundamentally different control architecture, one that accounts not only for what the user can access directly, but for what the model can infer, surface, and redistribute from the permissions it inherits.

The principle is straightforward even if the execution is demanding: the more an AI system can see or do, the stronger the governance must be. That includes role-based access, least privilege, approval workflows, usage logging, periodic review, sensitive-data restrictions, monitoring for abuse, and rapid revocation when the risk profile changes.

Model Use Requires Policy, Not Slogans

Many organizations have responded to AI adoption with broad guidance: do not paste confidential data into public tools, do not use AI for regulated decisions without approval, do not rely on AI outputs without human review. That is a start. It is not governance.

There is a material difference between using AI to draft a meeting summary and using AI to generate production code, analyze security logs, process client data, evaluate vendors, recommend access changes, or automate response actions. Each of those use cases carries a different risk profile, a different evidence requirement, and a different standard of human oversight. A single policy that does not distinguish between them will be either too restrictive to be usable or too permissive to be protective.

Real AI governance requires a formal model-use framework that maps each category of AI activity to a risk tier, a control requirement, and an approval path. Low-risk productivity support may require disclosure and basic data-handling rules. Security investigation support may require logging, source validation, and mandatory human review of outputs before action. AI-assisted access decisions may require stronger segregation of duties and auditability requirements. AI used in customer-facing or regulated workflows may require legal, compliance, privacy, and security review before any deployment.

This is the discipline most organizations are missing. They are trying to govern AI as a tool category when they need to govern it as a set of distinct use cases, each with its own control requirements.

Vendor Risk Management Was Not Built for This

Traditional vendor assessments focus on security certifications, encryption standards, access controls, incident response capability, business continuity, subcontractor relationships, data residency, and privacy obligations. Those remain important. But AI-enabled vendors introduce questions that fall entirely outside that evaluation framework.

What model powers the service, and is it proprietary, open-source, hosted, or embedded through a secondary provider? Is customer data used for training, tuning, evaluation, or product improvement, and can the customer opt out? What prompts, outputs, embeddings, metadata, and logs are retained, and for how long? Are there third-party AI providers involved in model inference or fine-tuning? How is model behavior tested for hallucination, unsafe output, prompt injection, and data leakage risk? How does the vendor notify clients of model changes? What evidence can the vendor actually produce to support its representations?

Security researchers discovered malicious machine learning models on Hugging Face in 2023 and early 2024, disguised as legitimate tools. These models appeared safe during inspection but contained code that executed upon deployment, with attackers in at least one scheme creating fake organization accounts and embedding command-and-control capability directly into models that employees unknowingly used. A standard vendor risk questionnaire has no mechanism for evaluating a model artifact. It was built to evaluate organizations, not objects.

Most organizations today have no systematic inventory of the AI tools their employees are connecting to corporate accounts and systems. Employees connect AI writing assistants, coding tools, meeting summarizers, and productivity applications to corporate environments as a matter of routine workflow, often without triggering any vendor intake review at all. In March 2026, the NSA and allied intelligence agencies issued joint guidance directing organizations buying or building AI to treat training data, models, software, and third-party services as supply-chain dependencies requiring the same rigor applied to any other critical infrastructure component. The procurement and vendor risk processes that exist in most organizations today are not positioned to execute against that standard without significant retooling.

Monitoring and Auditability Require Rearchitecting

Legacy monitoring was built to watch infrastructure, applications, endpoints, identities, network activity, and data movement. AI governance requires an additional layer: visibility into how AI systems are actually being used, not simply whether they are available.

That does not mean reading every employee prompt. It means creating appropriate, risk-calibrated telemetry to answer basic control questions: which AI tools are active and in which business processes, which data sources are connected, which users and roles have access, whether sensitive data types are appearing in prompts or outputs, whether outputs are influencing regulated or security-critical decisions, and whether there are signs of prompt injection, abnormal usage patterns, data exfiltration, or policy bypass. OWASP’s LLM application risk work identifies prompt injection as a primary attack vector, with manipulated inputs potentially leading to unauthorized access, data breaches, or compromised downstream decision-making. That is a current design requirement, not a future consideration.

Auditability sits alongside monitoring as a foundational requirement, and it is the one most often deferred in the name of speed to deployment. If an AI system supports material business processes, security operations, access decisions, customer workflows, software development, or regulatory obligations, auditability must be designed in from the beginning, not retrofitted after the organization discovers it cannot answer a regulator’s question or reconstruct a security event.

Deep learning models operate as black boxes even to their creators, and that lack of explainability conflicts directly with the auditability and accountability principles that underpin enterprise risk management. Many compliance programs account for file access and user actions but not for AI-generated outputs, which leaves organizations unable to demonstrate who accessed what data through what mechanism and with what downstream effect. Auditability in an AI governance context means the organization can reconstruct what system was used, which model version was involved, what data sources were available to it, who initiated the action, what output was generated, whether a human reviewed that output, and whether a subsequent decision was made on its basis. Without that record, the organization is not governing AI. It is hoping AI is behaving appropriately.

IBM’s Cost of a Data Breach Report 2025 found that two-thirds of organizations that experienced AI-related breaches did not perform regular audits to evaluate AI risk, and more than three-quarters had not conducted adversarial testing on their AI models. Adversarial testing is not optional hygiene. It is the mechanism by which an organization understands how its AI systems behave when inputs are manipulated, boundaries are probed, and controls are deliberately stressed.

The Regulatory Clock Is Running Faster Than the Governance Clock

The external governance environment has moved from advisory to mandatory with unusual speed. The EU AI Act entered into force on August 1, 2024, with broad applicability scheduled for August 2026 and earlier obligations already active for certain prohibited practices and AI literacy requirements. NIST released its Generative AI Profile, AI 600-1, in July 2024 as a companion to the AI Risk Management Framework, specifically designed to help organizations identify and manage risks unique to generative AI systems. ISO/IEC 42001:2023 established a formal AI management system standard applicable to organizations providing or using AI-based products and services.

Federal agencies issued 59 new AI-related regulations in 2024 alone, more than double the prior year, and organizations that cannot track their AI usage now face immediate compliance exposure across GDPR, CCPA, and HIPAA. Recent research from the Cloud Security Alliance found that only roughly one quarter of organizations have comprehensive AI security governance in place, and that governance maturity has emerged as the single strongest differentiating factor between security teams that feel prepared and those that do not.

The message across these signals is consistent: AI governance is not an IT policy issue. It is becoming a structured management discipline with defined ownership, documented controls, evidence requirements, monitoring obligations, training mandates, and continuous improvement expectations. Security leaders should be building that structure now, before they are asked to audit its absence after the fact.

The New Control Model for AI

A mature AI governance program needs to address at least eight interconnected domains, and the absence of any one of them creates a gap that the others cannot compensate for.

The organization needs a living inventory of approved AI tools and AI-enabled business processes, because unknown AI use is ungoverned AI use. Every AI system must be mapped to the data it can access, the sensitivity of that data, and the roles authorized to use it. The models and vendors involved need to be understood in terms of how data is handled, what contractual protections exist, and how model changes are communicated and controlled. High-impact decisions influenced by AI must carry defined human oversight requirements, with approval, review, and accountability that does not get delegated to the model. AI usage, exceptions, sensitive-data events, and anomalous behavior need monitoring and logging infrastructure designed for the behavioral characteristics of AI systems, not repurposed from infrastructure monitoring. AI-enabled applications must go through security architecture and threat modeling that addresses prompt injection, insecure output handling, data leakage, model abuse, and supply-chain dependencies. The organization must be able to demonstrate, to regulators, auditors, and its own leadership, how AI is governed, who approved it, what controls apply, and whether those controls are operating as designed. And AI-related incidents, whether involving data exposure, unsafe output, model misuse, vendor breach, prompt injection, unauthorized automation, or policy violation, need defined response playbooks that do not assume the incident will look like a traditional breach.

That is the difference between having an AI policy and having an AI governance program.

The Culture Problem: Employees Will Use AI Before Governance Catches Up

There is also a human reality that security leaders must confront directly: employees will use AI because it makes them faster, and no policy written for auditors will change that behavior on its own. AI adoption has consistently outpaced security maturity, and security professionals should assume that a meaningful percentage of any organization’s workforce is already using unauthorized AI tools in their daily workflows.

Trying to prohibit all unsanctioned AI use is not a sustainable strategy for most organizations. The better approach is to create safe, approved, well-governed pathways that make secure behavior easier than insecure behavior. That requires clear policy, usable tools, practical training, data-handling guidance, clear escalation paths, and an environment where employees can ask questions without fear of punishment for the act of asking.

Employees should not have to guess whether a use case is acceptable. They should know where to go, what is approved, what requires review, and what data must never appear in a prompt. AI governance will fail if it is written only to satisfy auditors. It has to be legible and usable by the people it is meant to protect.

The Leadership Question Is Not Whether AI Will Be Used

AI will be used. It will be used by employees, vendors, security platforms, developers, service teams, analysts, and executives. It will be used in approved ways and, where governance is weak, in ways that are entirely unmonitored.

The real leadership question is whether the organization will govern AI intentionally or inherit AI risk accidentally. That means moving from legacy control assumptions to an AI-aware governance model, asking harder questions about data exposure, model use, vendor risk, access, monitoring, and auditability, and recognizing that AI is not simply another tool in the stack. It is a new layer of decision support, automation, and information synthesis that acts simultaneously as user, application, vendor, and data system, and it cuts across the boundaries that existing security programs were designed to protect.

The organizations that mature fastest will not slow the business down with vague prohibition. They will not wave AI through with blind optimism. They will build the control environment that allows the business to move with trust. That is where modern information security leadership is headed: not toward less AI, but toward better-governed AI.

Kimly Hong is a cybersecurity professional specializing in identity and access management, governance frameworks, and enterprise security program development. With hands-on experience implementing IAM solutions across complex regulated environments, Kimly works at the intersection of identity security, compliance, and business enablement.

Connect on LinkedIn or www.kimlyhong.com to continue the conversation