AI and the Enterprise Risk - Part 1

Part 1 of 3: The Decision to Trust

Artificial intelligence has moved rapidly from an experimental technology to an enterprise capability. Organizations now use large language models (LLMs) to summarize documents, analyze information, generate software, support research, interact with customers, and increasingly perform tasks through autonomous or semi-autonomous agents.

The technological question is no longer whether AI can perform useful enterprise functions. In many cases, it clearly can.

The more consequential question is what an enterprise must surrender—or potentially expose—in order to obtain that utility.

That question deserves consideration before an AI system is connected to enterprise systems, before an agent is granted credentials, and before proprietary information is placed into a model or its surrounding infrastructure. The decision to authorize AI access is itself an enterprise-risk decision.

NIST's AI Risk Management Framework emphasizes that AI risks should be considered across the lifecycle, including pre-design, design, development, deployment, use, and evaluation. Its Generative AI Profile specifically identifies risks involving information security, privacy, intellectual property, and third-party components.

For enterprises, however, risk management begins with a more fundamental question:

What exactly is being entrusted to the system?

The enterprise information problem

Not all corporate information has the same value.

A publicly available marketing document and an unreleased product design may both be stored on the same corporate network, but their risk profiles are fundamentally different. The same is true of an employee handbook compared with source code, customer records, proprietary algorithms, pricing models, acquisition plans, manufacturing processes, or research data.

An enterprise therefore should not approach AI access as a binary question of whether AI is "secure."

The relevant question is whether the specific information, system, and authority involved are appropriate for the particular AI architecture being considered.

This distinction is important because an organization can make a technically secure connection to an AI service and still make a strategically poor decision.

Consider a hypothetical pharmaceutical company. An AI system might be extremely effective at reviewing research documents. The productivity case could be compelling. But if the system requires access to unpublished research containing commercially significant discoveries, the decision is no longer simply about productivity. It becomes a decision about how much control the company is willing to relinquish over strategically valuable information.

The same issue appears in financial services, manufacturing, software, healthcare, defense, consulting, insurance, and virtually every industry where proprietary information creates competitive advantage.

Information has economic value before it becomes data

One weakness in many AI discussions is the tendency to treat information primarily as a cybersecurity classification.

Confidential information is not valuable merely because it is confidential.

It may represent years of research, substantial capital investment, accumulated organizational knowledge, customer relationships, or a competitive position that cannot easily be reconstructed.

Trade-secret protection illustrates the point. Information can derive economic value precisely because it is not generally known and because the organization takes reasonable measures to maintain its secrecy.

Introducing AI into that environment therefore raises a question that precedes technical security:

Does the proposed AI architecture preserve the enterprise's ability to control information that derives value from being controlled?

This is different from asking whether an AI vendor promises not to train a model on customer inputs. Contractual and technical protections are important, but they are only components of the larger question.

The enterprise must understand the entire information path.

Where is the information processed? Where is it temporarily stored? What logs exist? Which services receive it? Which employees or contractors may access it? What happens to derived information? What happens when an agent uses a tool? What happens when the AI retrieves information from another system?

These questions become increasingly important as AI systems move from simple conversational interfaces toward systems that can retrieve information and act upon it.

The distinction between AI assistance and AI delegation

There is a meaningful difference between asking an LLM to summarize a document and authorizing an AI agent to search an enterprise's document repository, determine which information is relevant, combine it with other sources, and take an action.

The first is primarily an information-processing relationship.

The second is a delegation relationship.

Delegation changes the risk calculation.

An agent may have access to email, customer-management systems, internal databases, source repositories, financial systems, cloud infrastructure, or business applications. Its value comes partly from being able to move information and perform actions across those boundaries.

That same capability creates a larger potential consequence when something goes wrong.

OWASP's current guidance identifies excessive agency, sensitive-information disclosure, prompt injection, supply-chain vulnerabilities, and model theft among significant risks associated with LLM and agentic applications. Its 2026 agentic-AI guidance specifically addresses systems capable of planning, acting, and making decisions across complex workflows.

The important point is not that agents are inherently unsafe.

It is that greater capability requires a correspondingly more deliberate authorization decision.

The public-model question

Once an enterprise identifies a potentially valuable AI application, the next question frequently becomes which model to use.

The easiest option is often a commercially available model accessed through an application or API.

That approach can provide sophisticated capabilities without requiring the enterprise to build and operate a foundation model. It may also provide rapid deployment and access to capabilities that would otherwise require substantial infrastructure and specialized expertise.

But convenience can obscure an important distinction.

The enterprise is not merely purchasing computation. It is introducing another organization, technology stack, contractual relationship, and supply chain into the processing of potentially sensitive information.

The question is therefore not simply:

"Is this AI model good enough?"

It is:

"Is this model, deployment architecture, provider relationship, and information flow appropriate for the information and authority we intend to provide?"

The answer may differ dramatically between use cases.

A marketing department analyzing publicly available material presents a very different risk profile from an engineering department providing unreleased source code. An internal HR assistant handling routine administrative information differs from an agent capable of querying customer databases.

A single enterprise-wide AI policy may therefore be insufficient.

The temptation to classify AI as another software application

Traditional enterprise technology governance has often been organized around applications.

An organization buys software, establishes access controls, evaluates the vendor, integrates the application, and manages it throughout its lifecycle.

LLMs complicate this model because the system does not merely execute predetermined software functions. It interprets language, generates outputs, interacts with information probabilistically, and may be embedded inside applications that subsequently give it access to additional systems.

The model is therefore only one component.

The actual risk surface may include the model, prompts, retrieval systems, embeddings, databases, tools, APIs, identity systems, orchestration software, logging systems, third-party services, and human users.

NIST's Generative AI Profile explicitly recommends connecting AI governance with existing model, data, software-development, IT, legal, compliance, and risk-management activities.

This is important because the decision cannot reasonably be delegated to a single technical department.

The enterprise's chief information officer, chief information security officer, data scientists, legal counsel, privacy professionals, business leaders, and risk managers may each see a different portion of the problem.

The decision before authorization

A mature enterprise AI decision should therefore begin before the model is selected.

The sequence might be conceptualized as:

Business objective → information required → information sensitivity → AI architecture → ownership/control → access authority → residual risk → authorization.

This sequence reverses a common tendency in technology adoption.

Instead of starting with, "What can this new model do for us?" the enterprise starts with, "What are we asking the model to know and do?"

That distinction matters.

If the proposed application requires access to information that the organization would be unwilling to disclose to a third party under any other circumstance, the burden of justification should be correspondingly high.

Similarly, if an agent requires authority to perform an action that would normally require a highly trusted employee, the enterprise should be able to explain why the AI system deserves comparable authority.

The goal is not to prevent AI adoption. The goal is to prevent the economic value of AI from being measured while the value of the information being exposed is ignored.

The emerging enterprise question

The next generation of AI adoption will increasingly force enterprises to distinguish between using intelligence and outsourcing control over intelligence.

That distinction becomes particularly important as organizations consider whether to rely on external models, privately deploy existing models, fine-tune models with proprietary information, retrieve proprietary information at inference time, or develop their own models.

Each architecture changes the distribution of control, cost, dependency, and risk.

Consequently, the question of whether an enterprise should trust AI cannot be answered independently of the question of what kind of AI relationship the enterprise is prepared to establish.

That is the subject of the next part of this series.

The central issue is no longer simply whether an enterprise should use AI.

It is how much ownership and control the enterprise should retain over the intelligence upon which it intends to depend.

Article published by icrunchdata
Image credit by Getty Images, Moment, Eugene Mymrin