Your AI Platform Is Not a Product. It Is a Contract Stack.

Why CISOs must stop approving “AI platforms” and start governing models, tools, data flows and legal boundaries.

TokenBy Eckhart Mehler for CISOsCISO — a perspective on cybersecurity leadership, governance and the decisions that determine whether organizations retain control.

Most organizations still ask the wrong question when they introduce an enterprise AI platform.

They ask:

Is this platform secure?
Is it GDPR compliant?
Can we approve it for business use?

Those questions are understandable. They are also dangerously incomplete.

Modern AI platforms are rarely single products in the traditional sense. They are composable environments: a model catalog, inference services, retrieval components, search tools, storage accounts, agent frameworks, telemetry, identity integrations, external APIs and sometimes third-party marketplaces—all held together by a cloud portal that makes the experience look deceptively uniform.

The interface may be one platform.

The contractual reality is not.

That distinction matters because security, privacy, sovereignty and accountability do not follow the user interface. They follow the actual data path.

A model deployed directly by the cloud provider may sit under one contractual regime. A partner model may be subject to separate provider terms. A web-grounding feature may route data to a service outside the core cloud compliance boundary. A preview capability may operate under reduced protections. An agent connected to email, calendars or document repositories may create a completely different risk profile from a simple internal chat assistant.

The result is uncomfortable but clear:

There is no such thing as a blanket approval for an AI platform.

There are only approvals for specific combinations of models, data, tools, identities, regions and actions.

And that is where many organizations are currently losing control.

The Interface Creates a Dangerous Illusion

Cloud AI platforms are designed to make complexity feel simple.

A user opens a portal, selects a model, enables a search connector, uploads documents, activates an agent tool and deploys a chatbot. From a business perspective, it appears as one integrated service.

From a governance perspective, it may be five or six distinct services with different legal, technical and operational characteristics.

That is not a criticism of the technology. It is the architecture of modern AI.

A single enterprise deployment can include:

• a foundation model,
• a model host,
• vector embeddings,
• a search index,
• document storage,
• telemetry and application monitoring,
• content safety functions,
• web search grounding,
• external APIs,
• identity services,
• workflow automation,
• marketplace components,
• partner-provided models.

Each of these components can create its own data flow. Each can introduce different retention rules, support access paths, sub-processors, data residency commitments, contractual limitations and security controls.

The problem begins when governance teams approve the visible layer while ignoring the hidden stack beneath it.

A statement such as “the application runs in Azure” may be technically true while still being operationally meaningless.

It does not answer:

• Which model is being used?
• Is the model operated directly by the cloud provider or by a partner?
• Where is inference actually performed?
• Are prompts retained for abuse monitoring?
• Are any tools sending queries to external services?
• Are retrieval sources copied, indexed or embedded elsewhere?
• Which logs contain user prompts, document fragments or agent actions?
• Can the agent access business systems?
• Can the agent write, delete, approve or communicate externally?
• Which terms apply to each component?

Without those answers, an approval is not governance.

It is hope documented in a ticket.

The Model Is Not Just a Technical Choice

Many organizations still treat model selection as a performance decision.

Which model writes better summaries?
Which model produces better code?
Which model is cheaper?
Which model has the largest context window?

These are important questions. But they are not the first questions a CISO should ask.

The first question is:

Under which contractual and operational regime is this model being consumed?

Microsoft Foundry, for example, distinguishes between models sold directly by Azure and models provided by partners or the wider model community. Microsoft explicitly classifies many non-Microsoft models as “Non-Microsoft Products” under the Product Terms, subject to the additional terms attached to those models. (Microsoft Learn⁠)

That distinction changes the assessment immediately.

A model can appear in the same catalog, be deployed from the same portal and be billed through the same cloud account—yet still involve a different contractual chain, different data handling, different provider obligations and different geographic processing model.

This is especially important where organizations assume that a cloud region automatically determines where all data is processed.

It often does not.

Microsoft’s documentation for Claude models in Foundry states that, depending on the selected hosting option, prompts and outputs may be processed anywhere in the world for operational purposes such as performance and capacity management. (Microsoft Learn⁠)

That does not make the service unusable.

But it makes a blanket “EU region” assurance insufficient.

The right conclusion is not that third-party models should never be used. The right conclusion is that each model must be governed as its own service.

Every approved model should have a documented profile covering:

• provider and contractual status,
• hosting and inference location,
• applicable processing terms,
• data retention and monitoring,
• permitted data classifications,
• use of prompts and outputs,
• possible third-country transfers,
• security controls,
• output restrictions,
• ownership and accountability.

A model catalog without a governance catalog is simply a procurement mechanism for unmanaged risk.

“Not Used for Training” Is Not the Same as “Not Processed”

One of the most common misunderstandings in enterprise AI is the phrase:

Your prompts are not used to train the model.

That statement can be important. It can also be incomplete.

For Azure Direct Models, Microsoft states that customer prompts, outputs, embeddings and training data are not used to improve Microsoft, model-provider or third-party models without permission. (Microsoft Learn⁠)

That is a meaningful control.

But it is not the end of the analysis.

Data can still be processed to deliver the service. It can be subject to abuse monitoring. It can appear in diagnostic telemetry. It can be stored in application logs. It can be included in support cases. It can be sent to retrieval components. It can be transmitted to an external tool. It can be retained temporarily as part of a safety mechanism.

Microsoft documents abuse monitoring for models sold by Azure, including processes intended to detect recurring content or behavior that violates applicable product terms. (Microsoft Learn⁠)

Again, that does not mean the platform is unsafe.

It means organizations must stop using simplistic assurances as substitutes for control design.

The correct governance question is not:

Are prompts used for training?

It is:

For which purposes, under which conditions, for how long, by which service components, and under whose access control can prompts, outputs and derived data be processed?

That question is more difficult.

It is also the question that actually matters.

Web Grounding Is a Boundary Crossing, Not a Feature Toggle

The most revealing example is web grounding.

To a business user, web grounding looks harmless. It gives the model access to fresh information. It helps answer current questions. It reduces hallucinations by connecting the model to public sources.

From a security and privacy perspective, it is an external data transfer mechanism.

Microsoft states that when Grounding with Bing Search is used, customer data is transferred outside the Azure compliance boundary to the Bing grounding service. Microsoft further notes that the service is not subject to the same data processing terms, location commitments or compliance standards as the Foundry Agent Service. (Microsoft Learn⁠)

That changes the control model completely.

The search query itself may reveal:

• a confidential project,
• an internal investigation,
• a customer relationship,
• a security incident,
• a strategic business decision,
• a sensitive country context,
• a personnel matter,
• a legal or compliance concern.

The query may look short. The context behind it may not be.

A CISO should therefore never view web grounding as a harmless convenience feature. It is a controlled external interface.

For sensitive environments, the default should be simple:

Web grounding is disabled unless explicitly approved for a defined use case.

Where it is permitted, the organization should define:

• approved data classifications,
• prohibited query types,
• approved users and applications,
• logging and review requirements,
• user disclosure requirements,
• external recipient assessment,
• kill-switch capability,
• exception approval process.

Cloud providers document technical options to disable Bing grounding and related web knowledge capabilities. The existence of those controls is itself a reminder that web grounding should be governed as an external data channel, not treated as a standard feature. (Microsoft Learn⁠)

The Real Risk Begins When the AI Starts Acting

A chat assistant creates one kind of risk.

An agent creates another.

The difference is not semantic. It is architectural.

A chatbot responds.

An agent can retrieve, decide, trigger, write, send, update, create, approve, escalate, delete or communicate.

Once an AI system gains access to calendars, mailboxes, document repositories, ticketing platforms, workflow engines or business applications, the risk profile changes from content generation to delegated action.

That introduces new questions:

• Which identity does the agent use?
• Does it inherit user permissions?
• Does it have a separate service identity?
• Can it access all content the user can access?
• Can it act without user confirmation?
• Can it write to systems of record?
• Can it send external emails?
• Can it trigger workflows or approvals?
• Can it create financial, contractual or HR consequences?
• Are all actions logged and attributable?
• Can the agent be stopped immediately?

This is where organizations often underestimate the risk.

They focus on hallucinations, bias and prompt quality while ignoring the more immediate issue:

An agent with broad access and weak guardrails is a privileged automation account with an unpredictable interface.

The security model for AI agents should therefore resemble the security model for privileged access—not the security model for a consumer chatbot.

Every productive agent should have:

• a defined business owner,
• a defined technical owner,
• a dedicated identity,
• least-privilege permissions,
• time-bound access where possible,
• restricted tool scopes,
• approval gates for high-impact actions,
• complete action logging,
• anomaly monitoring,
• emergency disablement,
• periodic access review.

Where an agent can write, send, delete, approve or trigger external effects, a human approval step should be the default—not the exception.

Retrieval-Augmented Generation Creates New Data Stores

Organizations often believe they are simply “connecting documents to a model.”

They are usually creating a new information processing architecture.

Retrieval-augmented generation can involve:

• document ingestion,
• text extraction,
• chunking,
• embeddings,
• vector storage,
• metadata enrichment,
• indexing,
• search ranking,
• retrieval logs,
• query traces,
• evaluation data,
• cache layers,
• backup and retention mechanisms.

The model may not permanently retain the document.

But the surrounding architecture may still create multiple copies, representations and traces of the content.

Microsoft’s own guidance for Azure AI Search emphasizes that customers remain responsible for managing whether data flows outside organizational compliance and geographic boundaries. (Microsoft Learn⁠)

That responsibility cannot be delegated to the model provider.

A proper review of an AI knowledge system must therefore assess not only the model but also:

• the source repository,
• ingestion method,
• document classification,
• access control inheritance,
• index security,
• embedding storage,
• retention and deletion,
• backup scope,
• logging,
• search result filtering,
• prompt injection exposure,
• cross-tenant and cross-project separation.

In many cases, the greatest risk is not the model.

It is the newly created shadow knowledge base around it.

A Cloud Region Is Not a Sovereignty Strategy

“Hosted in Europe” is useful.

It is not enough.

Regional deployment addresses an important part of the problem: where certain workloads are stored and processed under normal operating conditions.

But sovereignty is broader.

It includes:

• who can access data,
• under which legal authority,
• who controls encryption keys,
• where support personnel operate,
• how incident response works,
• whether logs move across boundaries,
• whether external tools bypass the primary region,
• whether model providers receive data,
• whether the organization can leave,
• whether business operations can continue after a provider dispute, outage or legal restriction.

An organization can have data in a European data center and still remain dependent on:

• non-European legal jurisdictions,
• foreign support access,
• foreign model providers,
• external web services,
• proprietary APIs,
• opaque monitoring systems,
• provider-controlled keys,
• non-portable vector stores,
• undocumented service dependencies.

This is why cloud sovereignty cannot be reduced to data location.

It is a question of operational agency.

Can the organization understand where its data moves?

Can it constrain those flows?

Can it audit them?

Can it stop them?

Can it migrate?

Can it continue operating when a provider changes terms, architecture or availability?

Those are CISO questions because they determine whether the organization has retained control of its own digital operations.

The Contract Review Must Follow the Architecture

Traditional procurement often reviews one master agreement and one data processing agreement.

That approach is no longer sufficient for AI platforms.

The legal assessment must mirror the technical architecture.

For every productive AI use case, organizations should map at least:

This mapping should become a mandatory control artifact, not an optional technical diagram.

Because in AI systems, the architecture is the contract.

And the contract is part of the threat model.

Preview Is Not a Production Security Classification

There is a tendency to treat preview features as harmless innovation tools.

They are often the opposite.

Preview services may have changing functionality, incomplete certifications, evolving data handling, limited support commitments and different contractual terms. Microsoft explicitly cautions that preview capabilities can be subject to separate conditions and may not carry the same protections as generally available services. (Microsoft Learn⁠)

That should lead to a simple enterprise rule:

No sensitive, personal, confidential or security-relevant data in preview services.

Preview environments should be isolated by design:

• separate subscriptions,
• separate identities,
• synthetic or anonymized data,
• no production connectors,
• no productive email or calendar access,
• no broad network access,
• time-limited approval,
• documented exit criteria.

Innovation does not require recklessness.

It requires boundaries.

What a Mature AI Approval Model Looks Like

The solution is not to ban AI platforms.

The solution is to stop approving them as if they were static software packages.

A mature approval process works at the level of deployment patterns.

It approves combinations such as:

Approved: Azure Direct Model X, deployed in Region Y, without web grounding, with private networking, using internal documents classified up to Level B, with read-only retrieval, no external connectors and no autonomous write actions.

That is an approval.

This is not:

Approved: AI platform.

The difference may look bureaucratic.

It is actually the difference between governance and ambiguity.

A practical governance model should include five layers.

1. Model governance

Maintain an approved model register covering:

• provider,
• model version,
• contractual status,
• hosting model,
• permitted data classes,
• region,
• retention,
• monitoring,
• business owner,
• expiry date,
• review cycle.

2. Tool governance

Treat every external tool, search connector, API and plug-in as a separate outbound data interface.

No tool should be enabled by default simply because the platform supports it.

3. Agent governance

Classify agents by impact:

• informational agents,
• retrieval agents,
• internal workflow agents,
• external communication agents,
• transaction or approval agents,
• privileged administration agents.

The higher the impact, the stronger the approval, logging, segregation and human oversight.

4. Data governance

Define what may enter the system.

Not just in policy language, but through enforceable technical controls:

• data classification,
• DLP,
• access filtering,
• document labels,
• blocked data types,
• protected repositories,
• prompt guidance,
• monitoring,
• audit trails.

5. Contract governance

Maintain a living contract map for every model and service component.

Cloud AI terms change faster than most annual supplier reviews. Governance must therefore include ongoing review, not one-off legal sign-off.

The CISO’s New Question

The question is no longer:

Is this AI platform secure?

The better question is:

Which exact combination of model, tool, data source, identity, region and action are we allowing—and can we still explain, monitor and stop it?

That question may feel more demanding.

It is.

But it reflects reality.

AI platforms are not simply software products. They are dynamic ecosystems of services, providers, data paths and delegated capabilities.

The organizations that manage them well will not be the ones with the longest AI policy.

They will be the ones that can answer, at any moment:

• what models are in use,
• what data they receive,
• where that data goes,
• what they can access,
• what they can do,
• which contracts apply,
• who approved them,
• and how to turn them off.

That is not bureaucracy.

That is control.

And in the age of agentic AI, control is the foundation of trust.

Publication Note & Disclaimer
This article reflects my personal professional perspective and does not represent the official policy or position of my employer. Drafting and editorial refinement may have been supported by commercially available AI-assisted tools. The analysis, conclusions and final curation are entirely my own.

For information regarding image credits, copyrights, trademarks and other intellectual property rights, please refer to the Imprint.