The MLOps toolchain landscape was built for organisations with large dedicated ML platform teams and hundreds of models in production. A 250-person manufacturer deploying its first three AI workflows does not need Kubeflow, a feature store, a model registry, an experiment tracker, a drift-detection platform, and a standing platform team to run alongside them. Yet that is precisely the stack most vendor maturity models will steer them toward — because the maturity model is selling the destination, not the route.
The honest position is unglamorous: most DACH Mittelstand companies are nowhere near needing real MLOps, and acquiring it early is a way to spend money and headcount on machinery that has nothing to operate. The discipline you actually need is the discipline of matching operational weight to operational reality. That is what this piece is about.
The three-tier framework
MLOps requirements scale with how you consume AI, not with how ambitious your roadmap sounds. The useful question is not "how mature is our MLOps?" but "what are we actually running, and what is the smallest reliable way to run it?" Three tiers cover almost every mid-market situation, and the centre of gravity sits firmly in the first two.
Tier 1: API-first, where no MLOps is required. You consume AI through managed APIs — OpenAI, Anthropic, Azure OpenAI, Mistral, or similar. Your "deployment" is an API key and an integration layer inside an application you already operate. What you need here is prompt and configuration version control, which Git already gives you; cost monitoring, which the provider dashboards plus a monthly review already give you; output-quality monitoring through sampled human review; and a deliberate error-handling and fallback strategy for when the model is slow, wrong, or unavailable. This is not a watered-down MLOps. It is the correct operational posture for a company running a handful of AI-assisted workflows through managed APIs, and bolting infrastructure onto it adds cost and surface area without adding control.
Tier 2: Managed inference, where light MLOps earns its place. You fine-tune or self-select open-weight models and serve them on managed infrastructure — Azure Machine Learning, AWS SageMaker, Google Vertex AI, or a dedicated inference provider. Now you genuinely need to know which model version is in production and what changed, you need latency and error-rate monitoring alongside quality sampling, you need deployment you can trigger without hand-editing anything in production, and you need a rollback you have actually tested. MLflow covers the versioning and tracking core of this tier and is the most widely adopted open-source option for it, now governed under the Linux Foundation rather than any single vendor — which matters when you are choosing infrastructure you intend to depend on for years. Paired with your cloud provider's native deployment and serving tools, this handles the large majority of Tier 2 needs without a separate platform purchase.
Tier 3: Self-hosted lifecycle, where real MLOps becomes unavoidable. You operate your own GPU infrastructure, run training or continuous fine-tuning pipelines, manage many concurrent model versions, and own the full path from data preparation to production serving. Here you need everything from Tier 2 plus pipeline orchestration, feature management, automated drift detection, controlled A/B or shadow deployment, and real resource scheduling — and, just as importantly, the engineers to keep it running. The economics are the decisive factor: a credible Tier 3 platform means dedicated ML and platform engineering headcount plus GPU capacity, an annual commitment that lands well into six figures before it returns anything. For the overwhelming majority of Mittelstand companies, that case does not close, and pretending it does is how AI budgets quietly evaporate.
The vendor complexity trap
The platform landscape in 2026 is genuinely strong — Databricks, SageMaker, Azure Machine Learning, Vertex AI, Weights & Biases, Comet, and others are excellent at what they do. The trap is not that any of them is bad. The trap is adopting Tier 3 tooling to solve Tier 1 problems, because the vendor's reference architecture assumes a Tier 3 buyer.
The pattern repeats across sectors. A manufacturer that needs to classify and route incoming quality complaints does not need a feature store. A financial-services firm running an API-based assistant for internal compliance queries does not need a training-pipeline orchestrator. A logistics operator triaging customer requests through a managed LLM does not need shadow-deployment A/B infrastructure. In each case the work is real and worth doing — and in each case the operational layer that fits is closer to a disciplined Tier 1 than to anything on a platform sales deck.
For a mid-market buyer the evaluation criteria that matter are integration into the stack you already run, pricing that grows only when usage does, and short time-to-first-value. Feature completeness is a distraction. A platform that does the five things you need beats a platform that does fifty things you will never switch on — and that you will still pay for, patch, and staff.
Where compliance actually changes the picture
The one force that can legitimately push a Mittelstand company up the tiers is not ambition — it is regulation, and the obligations here are real and dated, not hypothetical. Under the EU AI Act, governance rules and obligations for general-purpose AI models have applied since 2 August 2025, and the bulk of the regulation became applicable on 2 August 2026; the heavier obligations for high-risk AI systems phase in later, with the regulated-product and listed high-risk categories reaching their deadlines on 2 August 2027 and 2 August 2028. If your AI touches a high-risk use case — biometrics, critical infrastructure, employment decisions, access to essential services — you will owe documentation, logging, and traceability that an undisciplined Tier 1 setup cannot produce on demand. That is a real reason to formalise versioning and monitoring, but it is a reason to do Tier 2 properly, not to leap to Tier 3.
Security obligations point the same way. Germany's NIS2 implementation amends the BSI-Gesetz and entered into force in December 2025, bringing essential and important entities under risk-management, supply-chain-security, and incident-reporting duties — including reporting significant incidents to the BSI within 24 hours. For an AI workflow, that means your operational stack has to be able to answer, quickly and credibly, what model was running, what it produced, and what changed. None of this demands a hyperscaler-grade platform. It demands that the modest stack you do run is auditable — versioned prompts and configs, retained logs, sampled-output records, and a rollback you can describe to a regulator without improvising.
The practical starting point
For a Mittelstand company starting in earnest, the minimum viable operational stack is deliberately small. Version control lives in the Git your engineering team already uses, covering prompts, configurations, and deployment scripts. Monitoring extends the observability stack you already run — Datadog, Grafana, or equivalent — with AI-specific signals: latency, error rate, token usage, and cost per task, so AI sits on the same operational footing as everything else you operate. Cost tracking is a monthly review of spend against business value delivered, and a spreadsheet genuinely suffices until spend is large enough to warrant more. Quality control is human review of a fixed weekly sample of outputs, which catches degradation earlier and cheaper than most automated drift dashboards will, while building the audit trail that compliance now expects.
Everything beyond that should be pulled in by a specific operational problem you can name — a latency target you keep missing, a model-version incident you could not reconstruct, an audit you could not satisfy — and never pushed in by a maturity model that profits from your discomfort. Build the operational layer your AI actually has, and add weight only when the work in production demands it.
A Fit Call pins down the right MLOps tier for your real AI workloads — and the EU AI Act and NIS2 obligations attached to them — before you commit budget to infrastructure you do not need.
References: European Commission, "AI Act — Regulatory framework for AI" (digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai); European Commission, "Guidelines for providers of general-purpose AI models," July 2025; BSI / openKRITIS, "NIS2 implementation in Germany (NIS2UmsuCG, amended BSI-Gesetz)" (openkritis.de/eu/eu-nis-2-germany.html); MLflow, Linux Foundation project (mlflow.org).