The Five Personas of Private AI: Platform Owner, Model Owner, Data Owner, Security Owner, and Business Owner

Private AI will not fail in most enterprises because the model cannot run.

It will fail because nobody can answer a simple question clearly:

Who owns this thing?

That question sounds basic until the first production AI use case crosses infrastructure, GPUs, model runtime, vector data, business logic, identity, audit logging, security policy, and operational support. In a traditional application stack, ownership is usually split across application teams, infrastructure teams, data teams, and security teams. Private AI compresses all of those concerns into one delivery path and then adds model behavior, prompt inputs, retrieval data, inference cost, and governance evidence on top.

That is where many enterprise AI programs get stuck. The platform team can deploy the environment. The data science team can test a model. The security team can review access. The business can fund the use case.

But if those groups do not share an ownership model, private AI becomes a collection of technically functional components with no accountable operating system.

This article frames private AI through five personas:

1. Platform Owner
2. Model Owner
3. Data Owner
4. Security Owner
5. Business Owner

The point is not to create another governance committee. The point is to make ownership explicit before private AI becomes production infrastructure.

Broadcom’s recent VMware Cloud Foundation positioning around private AI makes this operating-model discussion more important, not less important. A private cloud platform can give you a place to run AI workloads. It does not automatically decide who owns the model, the data, the policy, the cost, or the business risk.

TL;DR

Private AI needs an ownership model before it needs another tool.

The mental model is simple:

• Platform Owner owns the private AI substrate.
• Model Owner owns the model lifecycle and behavior.
• Data Owner owns the data sources, permissions, retention, and lineage.
• Security Owner owns the control framework, identity boundaries, audit, and response model.
• Business Owner owns the use case, funding, value, risk acceptance, and outcome.

These are personas, not necessarily job titles. One team may fill more than one role in a smaller environment. A larger enterprise may split each persona across multiple teams. The important part is that every production AI service has a named accountable owner for each lane.

The Ownership Model at a Glance

The diagram below is intentionally simple. Notice that the platform is the foundation, but it is not the owner of everything above it. Security cuts across every layer. The business owner sits at the top because private AI is only worth running when it serves a real business outcome.

This is the first guardrail: do not let the platform owner become the owner of last resort for the entire AI system.

That is the easiest failure mode in private AI. The platform team builds the environment, deploys the runtime, exposes the endpoint, and suddenly gets treated as accountable for model selection, data quality, prompt logging, user permissions, business accuracy, and compliance evidence.

That is not an operating model. That is organizational debt.

Scenario: The “Simple” Private AI Assistant

Assume a business unit wants a private AI assistant for internal policy search. The request sounds straightforward:

“We want employees to ask questions against our internal policy documents without sending data to a public AI service.”

Technically, this may look achievable. A private AI stack can host a model, expose a runtime endpoint, index internal content, and provide a retrieval-augmented generation workflow. In a VCF-style private cloud environment, the platform team may already have tenancy, lifecycle, network segmentation, monitoring, and capacity processes.

But the real questions start quickly:

Who decides which policy documents are allowed in the index?

Who approves the model?

Who owns the prompt template?

Who validates that answers are accurate enough?

Who defines whether user prompts are logged?

Who decides whether confidential documents can be retrieved?

Who responds if the assistant exposes restricted content?

Who pays for GPU capacity?

Who decides when the service is retired?

Private AI is not just an inference endpoint. It is a production service with infrastructure, model behavior, data rights, security controls, and business accountability.

Scope and Terminology Guardrails

For this article, private AI means an enterprise-controlled AI capability running on private infrastructure or a private cloud operating model. It may include self-hosted models, vendor-provided models, model runtimes, retrieval pipelines, AI services, internal assistants, or agentic workflows.

This article does not assume:

• every model is trained internally;
• every private AI environment is air-gapped;
• every workload requires GPUs;
• every organization has a dedicated AI platform team;
• VCF alone solves AI governance;
• ownership must map one-to-one to job titles.

The VCF lens matters because VCF already forces infrastructure teams to think in terms of domains, shared services, lifecycle, tenancy, identity boundaries, and operating models. Private AI adds another layer to that same discipline.

The model can run.

The question is whether the enterprise can operate it.

Assumptions

This mental model assumes the private AI service is moving beyond a lab or proof of concept. Once a service becomes production-facing, even internally, the ownership bar changes.

The assumptions are:

• The AI service has users, business impact, or operational dependency.
• The platform team provides a standardized private cloud or private AI landing zone.
• The model may change over time.
• The data sources may change over time.
• Access, logging, retention, and audit requirements matter.
• The service needs lifecycle management, not just deployment.
• Risk acceptance belongs to the business, not only to IT.

The NIST AI Risk Management Framework is useful here because it frames AI risk management around governance, mapping, measurement, and management activities. That maps well to the practical problem: private AI needs named owners for governance, context, measurement, and operational response.

Decision Criteria: Where Ownership Must Be Explicit

Before assigning personas, ask five questions for every private AI service:

If those questions do not have clear answers, the service is not ready for production.

Persona 1: The Platform Owner

The Platform Owner owns the substrate that private AI runs on.

In a VCF-aligned environment, this usually means the private cloud team, platform engineering team, virtualization team, or infrastructure services team. They own the landing zone, tenant boundaries, compute pools, GPU capacity, storage policies, network integration, lifecycle processes, and operational monitoring for the platform layer.

The Platform Owner should be accountable for:

• platform availability;
• capacity and quota models;
• GPU and CPU resource pools;
• cluster or domain lifecycle;
• platform patching and upgrades;
• tenancy boundaries;
• runtime hosting patterns;
• service catalog exposure;
• infrastructure observability;
• backup, recovery, and continuity patterns for the platform components.

The Platform Owner should not be the default owner of:

• model accuracy;
• data permission;
• business acceptance;
• prompt quality;
• answer correctness;
• regulatory interpretation;
• end-user process adoption.

This distinction matters. In many enterprises, the platform team is the first group asked to “make private AI available.” That is reasonable. The problem starts when “make it available” becomes “own every risk created by every AI workload that runs on it.”

A better operating model is to treat the Platform Owner as the provider of a governed private AI landing zone, not the owner of every AI outcome.

Persona 2: The Model Owner

The Model Owner owns the model lifecycle.

This persona may sit in an AI platform team, data science team, ML engineering group, application team, or a centralized model governance function. The Model Owner is accountable for which model is used, how it is evaluated, how it is versioned, and what behavior is considered acceptable.

The Model Owner should be accountable for:

• model selection;
• model version approval;
• evaluation criteria;
• performance baselines;
• model cards or equivalent documentation;
• known limitations;
• prompt template ownership where applicable;
• inference configuration defaults;
• rollback strategy;
• retirement or replacement decisions.

The Model Owner does not own the private cloud. They should not need to know every detail of storage policy, cluster lifecycle, or network routing. But they must own enough of the model behavior to answer practical questions:

Is this model approved for this use case?

What changed between model versions?

What evaluation results justify promotion?

What failure modes are known?

What is the rollback plan?

A private AI service without a Model Owner is just a runtime waiting for someone else’s assumptions.

Persona 3: The Data Owner

The Data Owner owns what information the AI system may use.

This is especially important for retrieval-augmented generation, document search, internal assistants, decision support, analytics copilots, and agentic workflows that interact with enterprise systems. In many private AI conversations, the model gets most of the attention. In production, the data often creates the most operational risk.

The Data Owner should be accountable for:

• approved data sources;
• data classification;
• source-system authorization;
• data lineage;
• retention requirements;
• freshness expectations;
• vector index lifecycle;
• document removal workflows;
• sensitive data handling;
• prompt and response logging rules related to data exposure.

The Data Owner is the persona who should be able to say:

This content is approved for retrieval.

This content is restricted.

This data source cannot be used for this use case.

This index must be rebuilt every day.

This source must be removed from the AI service.

This class of user cannot query that class of data.

Without a Data Owner, private AI can accidentally convert “stored somewhere internally” into “available everywhere through natural language.”

That is not a model problem. That is an ownership problem.

Persona 4: The Security Owner

The Security Owner owns the control framework around private AI.

This is broader than firewall rules or identity groups. The Security Owner is responsible for the policy model that surrounds the AI service: identity, segmentation, secrets, logging, audit, guardrails, threat modeling, incident response, and evidence.

The Security Owner should be accountable for:

• identity and access control requirements;
• privileged access boundaries;
• network segmentation;
• endpoint exposure rules;
• secrets management;
• audit logging requirements;
• prompt and response logging policy;
• threat modeling;
• abuse scenarios;
• incident response workflow;
• security control validation;
• compliance evidence requirements.

The Security Owner should not be expected to define the business value of the use case. They also should not be the only team deciding whether the AI service is worth the risk. Their role is to define and validate the control environment, then make risk visible enough for the Business Owner to accept, reject, or change the use case.

The security problem in private AI is rarely that security teams do not care. It is that they get pulled in too late, after the platform is built, the model is chosen, the data is indexed, and the demo already exists.

By then, security becomes a blocker.

In a better operating model, security is a design owner from the beginning.

Persona 5: The Business Owner

The Business Owner owns the reason the AI service exists.

This persona may be a product owner, application owner, department leader, process owner, or executive sponsor. The Business Owner is accountable for the use case, the funding, the expected outcome, and the residual business risk.

The Business Owner should be accountable for:

• business objective;
• funding model;
• user population;
• success criteria;
• process impact;
• acceptable error tolerance;
• risk acceptance;
• go-live decision;
• adoption and training;
• service retirement decision.

This is the persona most often under-defined in private AI.

A business team may ask for AI, but then expect IT to own the consequences. That does not work in production. If the assistant gives a bad answer, if the workflow changes how employees make decisions, if the output affects a customer process, or if the AI service becomes part of daily operations, the business must own the outcome.

IT can own the platform.

AI teams can own the model.

Data teams can own the source permissions.

Security can own the controls.

Only the business can own whether the use case should exist.

RACI: Private AI Ownership Table

Use this as a starting point, not a universal standard. The value is not the letters themselves. The value is forcing the conversation before the service goes live.

Legend:

• R = Responsible for doing the work
• A = Accountable for the decision or outcome
• C = Consulted before decision
• I = Informed after decision or change

Decision or Activity	Platform Owner	Model Owner	Data Owner	Security Owner	Business Owner
Define business use case	I	C	C	C	A/R
Approve production use	C	C	C	C	A
Define success criteria	I	C	C	C	A/R
Provision private AI landing zone	A/R	C	I	C	I
Define tenant or namespace boundary	A/R	C	C	C	I
Allocate GPU or compute capacity	A/R	C	I	I	C
Select approved model	C	A/R	C	C	C
Define model evaluation criteria	I	A/R	C	C	C
Approve model promotion	I	A/R	C	C	C
Define prompt template ownership	I	A/R	C	C	C
Approve data sources	I	C	A/R	C	C
Define data classification rules	I	I	A/R	C	C
Build or refresh vector index	C	C	A/R	C	I
Define data retention requirements	I	I	A/R	C	C
Define identity and access controls	C	C	C	A/R	C
Define network segmentation	R	I	I	A	I
Define prompt and response logging policy	C	C	C	A/R	C
Validate audit evidence	C	C	C	A/R	I
Accept residual business risk	I	C	C	C	A/R
Respond to model behavior incident	C	A/R	C	C	C
Respond to data exposure incident	C	C	A/R	A/R	C
Respond to platform outage	A/R	I	I	C	I
Approve service retirement	C	C	C	C	A/R

The table should be customized per organization. In a regulated environment, legal, privacy, compliance, records management, and enterprise architecture may need explicit columns. In a smaller organization, one team may hold multiple roles. The important part is that the decision rights are visible.

The Minimum Viable Ownership Record

A RACI table is useful for the operating model. A service-level ownership record is useful for implementation.

This is the type of lightweight artifact that should exist before a private AI service goes live:

private_ai_service:
  name: internal-policy-assistant
  environment: production
  service_tier: internal-business-critical

  owners:
    business_owner: hr-operations
    platform_owner: private-cloud-platform-team
    model_owner: enterprise-ai-platform-team
    data_owner: corporate-policy-data-owner
    security_owner: cyber-architecture

  approved_use_case:
    description: "Answer employee questions using approved HR policy documents."
    approved_user_groups:
      - full-time-employees
      - hr-service-desk
    excluded_use:
      - legal_advice
      - payroll_dispute_resolution
      - employee_relations_case_decisions

  model_controls:
    approved_model: "enterprise-approved-llm"
    model_version: "documented-in-model-registry"
    evaluation_owner: enterprise-ai-platform-team
    rollback_required: true

  data_controls:
    approved_sources:
      - hr-policy-library
      - benefits-faq
    prohibited_sources:
      - employee-case-files
      - payroll-records
      - legal-hold-documents
    index_refresh: daily
    retention_policy: "follow-corporate-records-policy"

  security_controls:
    authentication: "enterprise-sso"
    authorization: "group-based-access"
    prompt_logging: "enabled-with-sensitive-data-review"
    response_logging: "enabled"
    network_exposure: "internal-only"
    incident_response_playbook: "ai-service-incident-response"

  review:
    business_review: quarterly
    model_review: monthly
    data_review: monthly
    security_review: quarterly

This is not meant to be a universal schema. It is a forcing function.

If the team cannot fill out this record, the service probably is not ready for production.

The vCF Angle: Private AI as an Operating Model

VCF is relevant here because private AI is not just a workload placement decision. It is an operating-model decision.

A VCF environment already has concepts that matter for private AI:

• management and workload boundaries;
• shared services;
• lifecycle domains;
• infrastructure capacity pools;
• tenancy and isolation;
• identity integration;
• network and security policy;
• operational monitoring;
• platform automation.

Private AI should build on that discipline rather than bypass it.

The wrong pattern is to treat AI as a special island:

"AI is different, so we built a separate stack."

That may work for a proof of concept. It usually becomes a problem when the service needs patching, backup, access review, chargeback, incident response, capacity planning, or audit evidence.

The better pattern is to treat private AI as a governed service on top of the private cloud operating model:

"AI is different enough to need new ownership,
 but not so different that it should escape platform discipline."

That distinction is the architectural center of the five-persona model.

Mapping the Five Personas to Govern, Map, Measure, and Manage

The NIST AI RMF functions provide a useful governance lens, but they still need operational owners. The personas make those functions executable.

AI RMF Function	Ownership Interpretation
Govern	Business and Security define policy, accountability, risk tolerance, and approval gates. Platform implements enforceable controls.
Map	Business, Data, and Model Owners define context: use case, users, data sources, impacts, model behavior, and dependencies.
Measure	Model, Data, Security, and Platform Owners produce evidence: evaluation metrics, data quality checks, control validation, utilization, and operational telemetry.
Manage	Each owner treats risk in their lane, while the Business Owner accepts or rejects residual business risk.

This is where private AI needs discipline. Governance cannot live only in a document. It must show up in deployment patterns, service catalogs, access workflows, model registries, data approvals, logging decisions, and incident response.

Operational Implications

The five-persona model changes how private AI should be delivered.

Service Catalogs Need Ownership Fields

A private AI service catalog should not only ask for CPU, GPU, memory, storage, and network requirements. It should also ask for named owners.

At minimum:

• business owner;
• platform owner;
• model owner;
• data owner;
• security owner;
• approved use case;
• approved data sources;
• expected users;
• logging requirements;
• review cadence.

No ownership record, no production service.

AI Incidents Need Multi-Persona Response

A private AI incident may not be a simple outage. It may be a bad answer, unauthorized data exposure, model drift, prompt abuse, endpoint compromise, capacity exhaustion, or a retrieval issue.

Different incident types require different accountable owners.

Platform outage? Platform Owner leads.

Unauthorized data exposure? Data Owner and Security Owner lead.

Unsafe model behavior? Model Owner leads with Security and Business consulted.

Business process harm? Business Owner leads risk response.

The incident model should reflect that before the first incident happens.

Cost Allocation Must Be Business-Aware

Private AI consumes real infrastructure. GPU capacity, storage, indexing pipelines, monitoring, and operations are not free just because they run on private infrastructure.

The Business Owner must be visible in cost allocation. Otherwise, platform teams will be asked to absorb AI demand without a demand-management mechanism.

Access Requests Need More Than IAM Approval

For a normal application, access approval may be mostly about user identity and role. For private AI, access also depends on what data the AI can retrieve, what actions the AI can perform, what prompts are logged, and what output the user can rely on.

The Security Owner may define the access control pattern, but the Data Owner and Business Owner must participate in deciding who should access what.

Model Changes Need Change Management

A model version change can alter system behavior even if the application code does not change.

That means model promotion should have a change path. It does not need to be heavyweight for every internal service, but it should be explicit:

• what changed;
• what was evaluated;
• what risk was accepted;
• who approved promotion;
• how rollback works.

A Practical Readiness Checklist

Before treating a private AI service as production-ready, ask:

Readiness Question	Required Owner
Is the use case approved and funded?	Business Owner
Is the private AI landing zone approved?	Platform Owner
Is the model approved for this use case?	Model Owner
Are the data sources approved for retrieval or inference?	Data Owner
Are identity, logging, segmentation, and audit controls defined?	Security Owner
Is residual business risk accepted?	Business Owner
Is there a rollback or disablement plan?	Platform, Model, Data, Security
Is there an incident response path?	Security Owner with all personas
Is there a review cadence?	Business Owner and relevant technical owners

This checklist is deliberately operational. It should be usable in an intake form, design review, architecture board, or private AI service onboarding workflow.

Conclusion: Private AI Needs Named Owners, Not Just Running Models

Private AI is attractive because it gives enterprises more control over data, infrastructure, model access, and operating boundaries. But control does not come from location alone. Running AI on private infrastructure does not automatically create governance.

The hard part is not always deploying the model.

The hard part is deciding who owns the consequences.

The five-persona model gives teams a practical way to separate responsibilities without fragmenting accountability:

• Platform owns the substrate.
• Model owns behavior.
• Data owns permissible context.
• Security owns controls.
• Business owns value and risk.

For VCF-oriented teams, this should feel familiar. It is the same operating-model discipline already required for private cloud, extended into AI. The difference is that AI makes unclear ownership visible faster.

A private AI platform can make the model available.

A clear ownership model makes it operable.

External Sources