One Platform, Five Stakeholders: Designing AI Infrastructure That Serves Data Scientists, Engineers, MLOps, Security, and Leadership

Every AI platform initiative starts with optimism and ends with politics. The data scientists want Jupyter notebooks with unlimited GPU access. The data engineers want governed pipelines with schema enforcement. MLOps wants reproducible model deployments with canary rollouts. Security wants least-privilege access with audit trails. And leadership wants a dashboard showing ROI per AI initiative.

These aren't conflicting requirements — they're complementary layers of the same platform. The reason most enterprise AI platforms fail isn't technical. It's that they're designed for one stakeholder and imposed on the rest. The data science team builds a platform that works for notebooks but has no deployment story. The infrastructure team builds a platform that's secure but unusable. The MLOps team builds automation that the data scientists can't interact with.

This article maps the five key stakeholders, their actual needs, their pain points, and the platform architecture that serves all of them without serving none.

Stakeholder 1: Data Scientists

What They Actually Need

• Experimentation speed: Go from idea to running experiment in minutes, not days. Jupyter notebooks, VS Code, or their preferred IDE — connected to GPUs
• GPU access: On-demand access to appropriate GPU resources. H100 for large model fine-tuning, T4/L4 for experimentation and small inference tests
• Data access: Self-service access to datasets without filing tickets. They need to explore data before they know what they need
• Library freedom: Install PyTorch, TensorFlow, HuggingFace, or whatever the latest library is without IT approval for each package
• Reproducibility: Share experiments with colleagues. "It works on my laptop" is the enemy of collaboration

What Frustrates Them

• Waiting 2 weeks for a GPU instance to be provisioned
• Filing a Jira ticket to access a dataset they need for exploration
• Having their notebook environment rebuilt from scratch every time they log in
• Being told they can't use a library because IT hasn't approved it
• Having no path from "this experiment works" to "this model is in production"

Platform Response

Data Scientist experience on the AI Platform

Stakeholder 2: Data Engineers

What They Actually Need

• Pipeline orchestration: Reliable, scheduled data pipelines that transform raw data into features and training datasets. Airflow, Dagster, or Prefect
• Data quality: Schema enforcement, data validation, and anomaly detection. Bad data in means bad model out
• Data governance: Cataloguing, lineage tracking, and access control. Know where data came from, who transformed it, and who can access it
• Feature store: Consistent features between training and inference. The #1 source of training-serving skew is feature computation differences
• Scalable compute: Spark, Dask, or Ray clusters for large-scale data processing. Auto-scaling, not manual provisioning

What Frustrates Them

• Data scientists creating "shadow ETL" in notebooks that breaks when data schema changes
• No data catalogue — spending hours figuring out which table has the data they need
• Manual infrastructure management instead of focusing on data pipelines
• Being responsible for data quality but having no tools to enforce it
• Feature engineering happening in notebooks (not reproducible) instead of managed pipelines

Platform Response

• Data catalogue: Amundsen or DataHub integrated into the platform. Every dataset has an owner, description, schema, lineage, and quality score
• Pipeline templates: Pre-built Airflow/Dagster DAG templates for common patterns (incremental ingestion, feature computation, data validation)
• Feature store: Feast integrated with both the training environment (batch features) and the inference environment (online features). One definition, consistent everywhere
• Self-service Spark/Ray: On-demand compute clusters that auto-scale and auto-terminate. No ticket to provision, no orphaned clusters burning money
• Schema registry: Schema enforcement at ingestion. Data that violates the schema is rejected or quarantined, not silently loaded

Stakeholder 3: MLOps / Platform Engineers

What They Actually Need

• Model deployment pipeline: Take a model from the registry to production with versioning, canary rollout, and rollback
• Model registry: Versioned models with metadata, performance metrics, lineage, and deployment history
• Monitoring: Model performance monitoring in production — accuracy drift, data drift, latency, throughput
• Reproducibility: Given a model version, reproduce the exact training run. Code version, data version, hyperparameters, environment
• Automation: Automated retraining triggers when model performance degrades. Automated validation before promotion

What Frustrates Them

• Data scientists handing over a pickle file and saying "deploy this"
• No standard model format — every team uses a different serialisation (pickle, ONNX, SafeTensors, custom)
• Manual deployment processes that take days instead of minutes
• No monitoring — finding out a model is producing garbage outputs from customer complaints, not metrics
• Being the bottleneck between data science and production because there's no self-service deployment path

Platform Response

• Standardised model packaging: Models registered in MLflow with standard format (ONNX or SafeTensors), model card (accuracy, bias, training data lineage), and containerised serving configuration
• GitOps deployment: Model deployment via Git PR — change the model version in the deployment config, ArgoCD handles the rollout. Integrated security+feature pipeline
• Canary with safety metrics: Argo Rollouts with model-specific analysis (accuracy, latency, safety metrics) — automatic rollback on degradation
• Drift detection: Automated monitoring for data drift (input distribution changes) and concept drift (output quality degradation). Alerts and automated retraining triggers
• Experiment-to-production path: Data scientist clicks "promote" in MLflow UI. Model is validated, packaged, and a deployment PR is created. MLOps reviews and approves. No manual handover

Stakeholder 4: Security and Compliance

What They Actually Need

• Access control: Who can access which data, which models, which compute resources? Least-privilege, time-bounded, auditable
• Data governance: Classification, residency, and access logging. Regulated data (PII, financial, health) must be tracked and controlled
• Supply chain security: SBOM for every container and model dependency. Vulnerability scanning. Image signing
• Audit trails: Every action traceable — data access, model training, deployment, inference. Required by DORA, NIS2, AI Act
• Policy enforcement: Technical controls that prevent policy violations, not policies that rely on human compliance

What Frustrates Them

• Data scientists downloading models from the internet without any security review
• No visibility into what data is being used for training (GDPR nightmare)
• Production AI systems with no audit trail (regulatory nightmare)
• Being the "department of no" because they can only block, not enable
• Finding out about AI deployments after they're in production

Platform Response

• RBAC + namespace isolation: Per-team namespaces with appropriate RBAC. Data scientists can access their team's data and compute but not other teams'. Security doesn't need to review every access request — the platform enforces boundaries
• Data classification integration: The data catalogue includes classification labels (public, internal, confidential, regulated). Access policies are enforced based on classification. Regulated data cannot be sent to external AI APIs — enforced at the AI gateway level
• Model supply chain: Internal model registry with scanning. Models from external sources (HuggingFace) go through a quarantine process — scanned for backdoors, validated, and then made available internally. No direct internet access from training/inference pods
• Continuous compliance evidence: Every training run, every deployment, every inference logged with full context. Compliance evidence generated automatically, not manually
• Admission control: Kyverno policies prevent non-compliant deployments. Security team defines policies; the platform enforces them. Security enables by defining guardrails, not by reviewing every deployment

Stakeholder 5: Leadership / Finance

What They Actually Need

• Cost visibility: How much are we spending on AI compute? Which teams? Which projects? What's the trend?
• ROI measurement: Which AI initiatives are delivering business value? What's the cost per model served? What's the business impact?
• Risk visibility: What AI systems are in production? What's their compliance status? What's our exposure?
• Capacity planning: Do we need more GPUs? When? How much will it cost? What's the lead time?
• Benchmarking: How does our AI maturity compare to industry? Are we investing appropriately?

What Frustrates Them

• Approving GPU budgets with no visibility into utilisation (are we wasting money?)
• AI teams unable to articulate business impact in financial terms
• Surprise compliance issues (we didn't know we had an AI system in scope for the AI Act)
• No single view of AI initiatives across the organisation
• Being asked to approve infrastructure spend with no cost-per-outcome metrics

Platform Response

• Chargeback dashboard: GPU-hours, storage, and API costs attributed to teams/projects. Monthly trend reports. Budget vs. actual. Automatically generated, not manually compiled
• AI initiative registry: Every AI system registered in the platform with: business owner, status (development/staging/production), compliance classification (AI Act risk level), cost, and business metrics
• Utilisation metrics: GPU utilisation, model inference volume, and idle resource identification. "These 3 GPU nodes have been at 8% utilisation for 30 days — reclaim or reassign"
• Compliance status: Per-system compliance posture: SBOM present, vulnerability scan current, audit logging active, AI Act risk classification assigned, human oversight implemented
• Capacity forecast: Based on current growth trends and planned initiatives, "you'll need 4 more H100 GPUs in Q3 — procurement lead time is 12 weeks, order by Q2"

The Architecture: One Platform, Five Views

The underlying infrastructure is shared. The experience is personalised:

Unified AI Platform Architecture

Each stakeholder sees the same platform through a different lens. The data scientist sees notebooks and GPUs. The security engineer sees policies and audit logs. Leadership sees costs and compliance. But underneath, it's one integrated system — not five disconnected tools.

Implementation Priority

You can't build everything at once. Priority order based on value and dependency:

1. Month 1-2: Foundation. Kubernetes platform with GPU scheduling, namespace isolation, RBAC. Data scientists get notebooks. Security gets audit logs. Everyone has a starting point
2. Month 3-4: Self-service. Data catalogue, model registry, self-service GPU provisioning. Reduces ticket volume by 70%. Data engineers and MLOps get their core tools
3. Month 5-6: Automation. GitOps deployment pipeline, admission control, automated scanning. Features and security deploy together. MLOps and security are no longer bottlenecks
4. Month 7-8: Governance. Cost attribution, AI initiative registry, compliance dashboards. Leadership gets visibility. Budget conversations become data-driven
5. Ongoing: Iteration. Add feature store, expand golden paths, improve developer experience based on quarterly surveys

What Open Empower Delivers

We design and implement multi-stakeholder AI platforms for regulated enterprises:

• Stakeholder mapping: Workshops with data science, engineering, MLOps, security, and leadership to define requirements and priorities
• Platform architecture: Kubernetes-based unified platform with role-based views and self-service capabilities
• Data science experience: JupyterHub, GPU scheduling, experiment tracking, and promotion-to-production workflows
• MLOps automation: Model registry, GitOps deployment, canary rollouts, and drift monitoring
• Security integration: RBAC, admission control, data classification, supply chain security, and compliance evidence
• Leadership visibility: Cost dashboards, AI initiative registry, and compliance status reporting

Five stakeholders. One platform. No compromises. Let's design yours.