Private AI vs. Public Cloud: welche KI-Architektur passt zum Unternehmen?

„Cloud oder On-Premise?“ klingt wie eine Infrastrukturfrage. Bei Unternehmens-KI ist es eine Architekturentscheidung über Kontrolle, Betrieb, Integrationen, Capacity und Exit.

Die falsche Vereinfachung lautet:

Public Cloud ist bequem, Private AI ist sicher.

Beides kann in einem konkreten Setup stimmen – muss aber nicht. Mehr technische Kontrolle verschiebt Verantwortung für Plattform, Updates, Skalierung, Observability, Recovery und Incident Handling ins eigene Unternehmen. Managed Services reduzieren diese Verantwortung, schaffen dafür aber bewusste Abhängigkeiten vom Provider.

Die bessere Frage lautet:

Welche Betriebsarchitektur passt zu diesem konkreten AI-Workload – und welche Verantwortung soll bewusst beim Provider, beim Plattformteam oder im eigenen Unternehmen liegen?

Die Entscheidungseinheit ist der Workload, nicht das Unternehmen

Ein Unternehmen muss nicht einmalig „Cloud“ oder „Private AI“ wählen. Es kann parallel betreiben:

• allgemeine Assistenz als zentral verwaltetes SaaS,
• eine interne Fachanwendung in einer Private Cloud,
• sensible oder lokale Inferenz On-Premise,
• elastische Batch- oder Evaluation-Workloads auf einer Public-Cloud-Plattform.

Diese Verteilung ist kein Übergangszustand. Sie kann das richtige Zielmodell sein, wenn Workloads unterschiedliche Integrationsnähe, Latenz, Capacity oder Kontrollgrenzen haben. Architektur wird pro Workload platziert, nicht einmal pro Organisation entschieden.

Ein Standardprodukt kann dafür bewusst die kleinste Lösung sein. Wenn die Frage zuerst lautet, ob ChatGPT, Copilot, eine kontrollierte Erweiterung oder eine eigene Anwendung passt, hilft ChatGPT & Copilot im Unternehmen bei dieser vorgelagerten Produktentscheidung.

Welche Kontrollgrenze braucht der Workflow?

Eine Kontrollgrenze ist hier keine juristische Formel, sondern eine technische Entscheidung: Welche Komponenten, Daten- und Aktionspfade müssen innerhalb einer kontrollierten Umgebung bleiben – und welche dürfen bewusst an einen Provider delegiert werden?

Vor der Plattformwahl sollte für den Workload klar sein:

• Welche Daten, APIs und Fachsysteme muss er wirklich erreichen?
• Welche Systeme dürfen von außerhalb der eigenen Umgebung erreichbar sein?
• Wo muss Identity inklusive Rollen und Berechtigungen durchgängig gelten?
• Welche Aktionen, Logs oder Datenpfade dürfen diese Grenze nicht überschreiten?
• Welche Komponenten müssen das Unternehmen selbst kontrollieren, obwohl Modellzugang oder Infrastruktur managed bleiben können?

Wenn Datenflüsse, Transfers und rechtliche Anforderungen selbst der Auslöser der Entscheidung sind, gehört diese Prüfung in den Deep Dive DSGVO-konforme KI für Unternehmen. Diese Seite entscheidet anschließend das technische Betriebs- und Ownership-Modell.

Deployment Model = Operating Model

Die Frage ist nicht nur „Wo läuft das Modell?“, sondern: Wer ist Montagmorgen verantwortlich, wenn es nicht läuft?

Ein Deployment Model verteilt Ownership. Bei einem Managed Service verantwortet der Provider typischerweise Infrastrukturverfügbarkeit, Teile der Plattform, Capacity und Patches. Das Unternehmen bleibt dennoch für Workload, Datenzugriff, Identity, sichere Integration, fachliche Qualität und die gewählten Abhängigkeiten verantwortlich. In Private Cloud oder eigenem Betrieb wandern zusätzlich Runtime, Plattform, Updates, Capacity und Recovery stärker in die eigene Verantwortung.

Betriebsmodell als Ownership-Verteilung

• Infrastruktur & Capacity

  Netzwerk, Compute, GPU-Kapazität, Hardware-Lifecycle und Skalierungsreserven: managed beim Provider oder bewusst im eigenen Betrieb.

  Provider oder eigenes Plattformteam

• Plattform & Model Runtime

  Runtime, Modellbereitstellung, Versionen, Patches und sichere Konfiguration: beim Provider, auf einer Private Platform oder selbst betrieben.

  Geteilte Verantwortung

• Daten & Integrationen

  Datenzugriff, Connectoren, fachliche Systemgrenzen und erlaubte Datenpfade bleiben eine Architekturentscheidung des Unternehmens.

  Eigene Verantwortung

• Identity & Security

  Identity Policy, Rollen, Berechtigungsmodell und Integrationsgrenzen bleiben beim Unternehmen; technische Security Controls werden je Deployment-Modell geteilt.

  Geteilte Verantwortung mit eigener Policy-Hoheit

• Observability & Operations

  Monitoring, Kosten- und Qualitätsbeobachtung, Backup/Restore, Recovery, Runbooks und Incident Response brauchen einen klar benannten Owner.

  Bewusst zu organisieren

Die Verteilung darf bewusst asymmetrisch sein: Ein Provider kann Infrastruktur und Modellruntime betreiben, während das Unternehmen Integrationsgrenzen, Identity, Evals, Incident-Eskalation und Exit behält. Entscheidend ist nicht, möglichst viele Layer selbst zu besitzen, sondern die verantworteten Layer zuverlässig betreiben zu können.

Integration, Locality und Latenz verändern die Platzierung

Die Nähe zu DMS, ERP, CRM, Fachsystemen und Identity ist ein echter Architekturparameter. Sie entscheidet, wie viele Datenbewegungen, Netzwerkgrenzen, Berechtigungsprüfungen und Failure Paths ein Workload durchläuft.

Relevant sind insbesondere:

• ob SSO und Rollen über den gesamten Abfrage- und Aktionspfad gelten,
• ob Daten vor der Inferenz unnötig kopiert oder transformiert werden,
• welche Bandbreite und Antwortzeit der Prozess verträgt,
• ob ein lokaler, Edge- oder isolierter Betrieb tatsächlich nötig ist,
• wie Audit Logs, Tracing und Fehleranalyse über Systemgrenzen hinweg zusammenlaufen.

Eine tiefe interne Integration rechtfertigt nicht automatisch Private AI. Public Cloud kann technisch sinnvoll bleiben, wenn Datenpfade, Identity, Latenz und Betriebsgrenzen bewusst gestaltet sind. Umgekehrt löst ein lokaler Runtime-Standort keine schlechten Schnittstellen, fehlenden Berechtigungsvollzug oder unklare Logs.

Bei einem RAG-System kommt die Frage hinzu, welche Schichten das Unternehmen selbst besitzen oder austauschbar halten muss. Das behandelt Enterprise RAG: kaufen, bauen oder hybrid? auf Ebene von Retrieval, Rechten, Evaluation und Connectoren.

Capacity und Kosten: Bei welchem Nutzungsprofil kippt die Logik?

Die Kostenfrage lautet nicht „Cloud teuer oder GPU kaufen?“. Sie lautet: Welches Nutzungsprofil muss diese Architektur wirtschaftlich und zuverlässig tragen?

Maßgeblich sind:

• durchschnittliche Auslastung, Peak Load und Concurrency,
• Context Size, Modellgröße und tatsächlicher Inference-Bedarf,
• benötigte Elasticity gegenüber ungenutzter Idle Capacity,
• Managed Premium gegenüber Plattform- und Operationskosten,
• Capacity-Reserven, Hardware Lifecycle und Wiederherstellbarkeit,
• Migrations- und Exit-Kosten, wenn eine Entscheidung später revidiert wird.

Variable Cloud-Kosten können wirtschaftlich sinnvoller sein, wenn Last stark schwankt oder interne Capacity überwiegend ungenutzt bliebe. Fixe Infrastruktur lohnt sich nicht allein deshalb, weil Cloud teuer wirkt. Sie wird erst plausibel, wenn Auslastung, Kontrollbedarf und Betriebsfähigkeit zusammenpassen.

Die KI-Architektur-Checkliste für Unternehmen prüft nach dieser Grundentscheidung, ob Limits, Backpressure, Degradation, Kostenbeobachtung und Recovery für den tatsächlichen Produktionsbetrieb belastbar sind.

Team Capability begrenzt sinnvolle Architekturentscheidungen

Die technisch kontrollierbarste Architektur ist nicht automatisch die betrieblich sicherste, wenn das Team sie nicht zuverlässig betreiben kann.

Das ist kein HR-Thema, sondern eine Betriebsgrenze. Vor Private Cloud oder Self-hosting sollte geklärt sein, wer Plattform- und Ops-Know-how, Security-Kompetenz, Monitoring, Backup/Restore, Patch-Management, Runtime- und GPU-Betrieb sowie Incident Response tatsächlich verantwortet.

Ein schlanker managed Ansatz kann deshalb sicherer und wirtschaftlicher sein als eine formal stärker kontrollierte Plattform ohne benannten Owner, Runbooks oder Recovery-Fähigkeit. Umgekehrt kann ein erfahrenes Plattformteam eigene Verantwortung gezielt übernehmen, wenn die Kontrolle für einen kritischen Workload echten Nutzen stiftet.

Exit und Reversibility

Lock-in ist nicht moralisch falsch. Er kann für Time-to-Value, Modellqualität oder geringe Betriebsarbeit rational sein. Riskant wird er, wenn das Unternehmen den Wechselaufwand nicht kennt oder wichtige Artefakte den Anbieter nicht verlassen können.

Für jeden Workload sollte deshalb klar sein:

• Können Originaldaten, Metadaten und relevante Logs exportiert werden?
• Können Modelle oder Provider gewechselt werden, ohne die Anwendung neu zu erfinden?
• Wo binden proprietäre APIs, Runtimes, Vector Stores oder Agent-Runtimes?
• Sind Konfiguration, Prompts, Infrastructure as Code und Evaluationsfälle versioniert?
• Lassen sich abgeleitete Daten und kritische Zustände reproduzierbar rebuilden?
• Welche Preis-, Qualitäts-, Verfügbarkeits- oder Strategiewechsel lösen eine Neubewertung aus?

Ein Exit-Pfad muss keinen sofortigen Wechsel erlauben. Er muss nur als realistische Option beschrieben sein, bevor die Abhängigkeit teuer wird.

Fünf realistische Operating Models

Die Modelle sind keine Rangfolge. Sie sind unterschiedliche Verteilungen von Ownership, Elasticity, Integrationsnähe, Operationslast und Exit-Komplexität.

EU- oder Regional Hosting ist kein eigenes Operating Model. Es beschreibt eine zusätzliche Betriebs- beziehungsweise Residency-Grenze: Public SaaS, Managed Cloud oder Private Cloud können jeweils regional oder EU-gehostet sein.

Hybrid ist kein Kompromiss zwischen zwei Ideologien. Es ist ein bewusstes Zielmodell, wenn sensible oder lokal gebundene Workloads privat bleiben sollen, während unkritische, elastische oder modellintensive Aufgaben gezielt managed laufen. Seine Mehrkosten entstehen nicht primär durch zwei Orte, sondern durch die zusätzliche Integrations-, Routing-, Identity- und Observability-Komplexität.

Entscheidungs-Memo für die Architekturentscheidung

Das Ergebnis sollte keine Scorecard sein, in der On-Premise gegen Cloud „gewinnt“. Für jeden priorisierten Workload genügt ein kurzes, überprüfbares Memo:

• Workload: Welche Aufgabe, Nutzer und Systeme umfasst er?
• Kontrollgrenze: Welche Daten-, Aktions- und Betriebsgrenzen sind technisch erforderlich?
• Integrationsnähe: Welche Identity-, Daten- und Fachsysteme müssen durchgängig funktionieren?
• Lastprofil: Welche Auslastung, Peaks, Latenz und Capacity-Annahmen gelten?
• Team Capability: Wer kann Plattform, Security, Monitoring, Recovery und Incidents tatsächlich tragen?
• Operations Owner: Wer besitzt Runbook, Eskalation, Patch- und Change-Verantwortung?
• Akzeptierter Lock-in: Welche Abhängigkeit wird bewusst für welchen Nutzen akzeptiert?
• Exit Trigger: Bei welchem Preis-, Qualitäts-, Verfügbarkeits- oder Strategiewechsel wird die Entscheidung neu bewertet?
• Gewähltes Betriebsmodell: Welches Zielmodell ist für diesen Workload aktuell die kleinste tragfähige Lösung?
• Wichtigste offene Annahme: Welche Annahme muss vor Build oder Go-live noch belegt werden?

So bleibt die Architekturentscheidung nachvollziehbar, wenn Modell, Provider, Last oder Integrationen später wechseln.

Architektur statt Ideologie

Es gibt keinen technischen Preis dafür, „maximal on-prem“ zu sein. Genauso ist „Cloud first“ kein Qualitätsmerkmal.

Die richtige Entscheidung minimiert die Gesamtkosten aus Risiko, Betrieb, Komplexität und Abhängigkeit für den konkreten Workload. Souveränität bedeutet dabei nicht, alles selbst zu hosten. Sie bedeutet, die entscheidenden technischen und organisatorischen Abhängigkeiten bewusst zu wählen und im Betrieb kontrollieren zu können.

Wenn Zielarchitektur, Plattformwahl, Runtime- oder Hybrid-Design noch offen sind, ist KI-Beratung & AI Solution Architecture der passende Einstieg. Wenn Schutzbedarf, bestehende Datenflüsse und die gewünschte Kontrollgrenze der konkrete Auslöser sind, passt Souveräne KI & Private AI.

Sie wollen Betriebsmodell, Ownership und Exit für einen konkreten AI-Workload entscheiden? → Architekturgespräch anfragen