6 Ein Stack für mandantenfähige KI-Infrastruktur muss fünf Dinge gleichzeitig leisten. Er muss die Daten, Identitäten und Audit-Trails jedes Mandanten getrennt halten. Er muss verhindern, dass die Trainingsspitze eines Mandanten das Inferencing-SLA eines anderen aushungert. Er muss den Verbrauch so fein messen, dass die Rechnung zum Vertrag passt. Er muss Sicherheitsgrenzen durchsetzen, die einem Audit standhalten. Und er muss all das auf gemeinsam genutzter physischer Hardware leisten – denn genau das ist der Grund, überhaupt eine mandantenfähige Plattform zu betreiben. Dieser Leitfaden richtet sich an Infrastrukturverantwortliche, die eine solche Plattform entwerfen – in einem Unternehmen, das KI für mehrere Geschäftsbereiche betreibt, bei einem Service Provider, der KI an viele Kunden verkauft, oder bei einem Betreiber einer Sovereign Cloud, der regulierte KI-Kapazität für Mandanten aus dem öffentlichen Sektor bereitstellt. Die folgenden Designentscheidungen sind keine optionalen Funktionen. Sie bilden das Minimum, das ein Angebot für mandantenfähige KI-Infrastruktur abdecken muss, damit es vor Vertrag, Audit und Wachstum Bestand hat. Was ist mandantenfähige KI-Infrastruktur? Mandantenfähige KI-Infrastruktur ist die Gesamtheit aus Compute-, Speicher-, Netzwerk-, Identitäts- und Betriebskontrollen, mit der eine einzige Plattform viele Mandanten – interne Geschäftsbereiche oder externe Kunden – bedient, die KI-Workloads auf gemeinsam genutzten physischen Ressourcen ausführen, bei starker Isolation zwischen den Mandanten und mandantenbezogener Verantwortlichkeit für Verbrauch, Leistung und Sicherheitsniveau. Der Begriff „mandantenfähig“ bedeutet mehr als mehrere Kunden auf einer Plattform. Schwierig ist der Rest: Isolation, die unter Last nicht bricht, Identitäten, die zwischen Mandanten nicht verschwimmen, Kontingente, die auch bei Lastspitzen halten, Audit-Logs, die belegen, was jeder Mandant getan hat – und nur das –, sowie eine Abrechnungsebene, die sich rechtfertigen kann, wenn der Kunde fragt, wie eine Zahl zustande kam. Eine Plattform, die mehreren Mandanten Rechenzeit liefert, deren Speicher aber nicht pro Bucket und pro Ebene messen kann, ist nicht mandantenfähig in dem Sinne, den ein KI-Service-Provider braucht. Mandantenfähige KI-Infrastruktur unterscheidet sich zudem von KI-Infrastruktur, die nur für ein Unternehmen gedacht ist. Ein Unternehmen baut für einen Mandanten: sich selbst. Ein mandantenfähiger Betreiber baut für viele Mandanten gleichzeitig – ohne privilegierten Mandanten, ohne gemeinsame Root-Identität und ohne implizites Vertrauen zwischen Workloads. Diese eine Vorgabe verändert die gesamte Architektur. Die fünf Designsäulen Säule Was sie umfasst Warum sie wichtig ist Mandantenisolation Grenzen für Daten, Identität, Leistung, Lebenszyklus und Betrieb zwischen Mandanten Verhindert Datenlecks, Noisy-Neighbor-Effekte und mandantenübergreifende Schadensausbreitung Namespace-Trennung Logische Namespaces pro Mandant – Buckets, Konten, IAM, Audit-Logs Gibt jedem Mandanten eine saubere API-Schnittstelle, die nicht auf die Daten anderer zugreifen kann Kontingente pro Mandant Pro Mandant durchgesetzte Grenzen für Kapazität, Durchsatz, Anfragerate und Parallelität Verhindert, dass ein Mandant die Ressourcen verbraucht, für die ein anderer bezahlt hat Abrechnung und Messung Messung pro Mandant, pro Ebene und pro Operation, abgestimmt auf den Vertrag Entscheidet, ob das mandantenfähige Geschäft profitabel ist Sicherheitsgrenzen Kontrollen für Identität, Verschlüsselung, Audit, Datenresidenz und betrieblichen Zugriff pro Mandant Entscheidet, ob die Plattform Audits, behördliche Prüfungen oder die Aufarbeitung von Sicherheitsvorfällen übersteht Jede Säule stärkt die nächste. Starke Isolation mit schwacher Messung kostet trotzdem Marge. Starke Messung mit schwachen Sicherheitsgrenzen kostet trotzdem den Kunden. Die fünf Säulen müssen gemeinsam und in derselben Betriebsebene entworfen werden – sonst werden sie später nachgerüstet, und die Plattform wird innerhalb von zwei Jahren neu gebaut. Mandantenisolation: die grundlegende Eigenschaft Mandantenisolation ist die Eigenschaft, die mandantenfähige KI-Infrastruktur überhaupt erst möglich macht. Vier Grenzen müssen gleichzeitig halten. Datenisolation. Die Daten jedes Mandanten liegen in einem eigenen logischen Namespace und können von der Identität eines anderen Mandanten weder adressiert noch aufgelistet oder abgerufen werden. Das ist nicht dasselbe wie Verschlüsselung im Ruhezustand – Verschlüsselung schützt Daten vor einer gestohlenen Festplatte, Isolation schützt sie vor einem anderen Mandanten auf derselben Plattform. Leistungsisolation. Die Trainingsspitze, der große Checkpoint-Schreibvorgang oder der Anstieg von Inferencing-Anfragen eines Mandanten darf Durchsatz oder Latenzbudget eines anderen Mandanten nicht beeinträchtigen. Kontingente, Ratenbegrenzungen und Quality-of-Service-Kontrollen müssen auf der Speicher- und Netzwerkebene wirken, nicht nur in der Anwendungsschicht. Isolation von Lebenszyklus und Richtlinien. Mandanten haben unterschiedliche Aufbewahrungsfristen, unterschiedliche Compliance-Vorgaben und ein unterschiedliches Schutzniveau. Ein Mandant benötigt vielleicht sieben Jahre Aufbewahrung mit Object-Lock-Unveränderlichkeit für regulierte Trainingsdaten, der nächste 90 Tage Aufbewahrung ohne Unveränderlichkeit. Beides muss auf derselben physischen Plattform ohne Eingriff des Betreibers laufen. Betriebliche Isolation. Wartung, Kapazitätsausgleich und Knotentausch dürfen aus Sicht jedes Mandanten keine spürbaren Ereignisse sein. Ein plattformweites Upgrade, das alle Mandanten gleichzeitig unterbricht, ist kein Managed Service – es ist ein geplanter Ausfall mit angehängter Mandantenliste. Die Referenz zur Speicherisolation bei Mandantenfähigkeit beschreibt die Mechanik auf Speicherebene ausführlicher. Für KI-Workloads lautet der Test, ob dasselbe Isolationsmodell für Trainingsdatensätze im Multi-Petabyte-Bereich, für Inferencing-Cache mit Latenz im Submillisekundenbereich und für Langzeitaufbewahrung auf kalten Medien gilt – alles auf derselben Plattform. Lautet die Antwort Nein, betreibt der Anbieter am Ende drei Plattformen mit drei Mandantenmodellen, und die Wirtschaftlichkeit leidet. Namespace-Trennung und die API für Mandanten Die Namespace-Trennung ist der Mechanismus, der Isolation zu etwas macht, das Mandanten tatsächlich nutzen können. Die S3-Objekt-API hat sich als De-facto-Standard für die Namespace-Grenze in mandantenfähiger KI-Infrastruktur etabliert – aus guten Gründen. Die KI-Tools jedes Mandanten – Trainings-Frameworks, Inferencing-Server, Vektordatenbanken, MLOps-Pipelines, Backup-Integrationen – sprechen bereits S3. Wird S3 als API für Mandanten genutzt, müssen diese keine proprietäre Schnittstelle lernen, und der Betreiber muss keine eigenen Client-SDKs pflegen. Die Namespace-Hierarchie aus Konten, Buckets und Objekten lässt sich sauber auf Mandantengrenzen abbilden: ein Konto pro Mandant, IAM-Identitäten mit festgelegtem Geltungsbereich unter jedem Konto, Audit-Logs und Lifecycle-Richtlinien, die vom Konto geerbt werden. Für KI-Workloads müssen drei Eigenschaften des Namespace erfüllt sein. Benennung und Identität pro Mandant. Bucket-Namen, IAM-Benutzer, Zugriffsschlüssel und Audit-Kennungen gehören zum Konto des Mandanten und können nicht mit anderen Mandanten kollidieren. Eine Kollision von Bucket-Namen zwischen Mandanten ist ein Fehler in der Mandantentrennung, kein Bedienungsproblem. Richtlinien pro Namespace. Aufbewahrung, Replikation, Verschlüsselungsschlüssel, Object Lock und Zugriffsprotokollierung werden pro Namespace konfiguriert. Der Betreiber setzt keine globale Regel nach dem Motto „alle Buckets erhalten X“ ein und nennt sie Mandantenrichtlinie. Prüfbare Auflistung. Ein Mandant kann alles innerhalb seines Namespace auflisten und nichts außerhalb davon. Das klingt selbstverständlich – und ist doch die Eigenschaft, die als Erstes bricht, wenn ein Betreiber einen gemeinsam genutzten Objektspeicher als „mandantenfähige“ Plattform verkabelt, ohne die nötige Arbeit zu leisten. Ist die Namespace-Grenze zugleich die API-Grenze, kann der Betreiber Kontingente, Ratenbegrenzungen und Audit-Hooks an einem einzigen Kontrollpunkt platzieren, statt sie über Anwendungsteams zu verteilen. Kontingente, Leistung und Noisy-Neighbor-Kontrolle Mit Kontingenten pro Mandant macht die Plattform aus gemeinsam genutzter physischer Kapazität vertraglich zugesicherte Mandantenkapazität. Ohne Kontingente wird jedes SLA auf der Plattform zum Best-Effort-Versprechen. Im KI-Maßstab zählen vier Arten von Kontingenten. Kapazitätskontingente begrenzen, wie viel Speicher ein Mandant auf jeder Ebene belegen darf – GPU-Direct-Flash, heiß, warm, kalt. Mit Kapazitätskontingenten kann der Betreiber Kapazität auch mit gutem Gewissen im Voraus verkaufen: Die Rechnung geht auf, weil die Plattform keinem Mandanten erlaubt, seine Zuteilung zu überschreiten. Durchsatzkontingente begrenzen, wie viel Bandbreite ein Mandant auf Lese- und Schreibpfaden nutzen darf, typischerweise als Dauerrate plus Burst-Budget. Für das Training sind Durchsatzkontingente die wichtigste Quality-of-Service-Kontrolle, denn sobald die GPUs ausgelastet sind, sind nicht sie der Engpass, sondern die Speicherebene. Anfragerate-Kontingente begrenzen, wie viele Objektoperationen pro Sekunde ein Mandant auslösen darf. Bei Inferencing- und Retrieval-Augmented-Generation-Workloads zählt die Anfragerate oft mehr als die reine Bandbreite. Parallelitätskontingente begrenzen, wie viele gleichzeitige Verbindungen oder laufende Operationen ein Mandant halten darf. Sie verhindern, dass die Erschöpfung des Verbindungspools durch einen Mandanten die Steuerungsebene für alle lahmlegt. Kontingente müssen auf Plattformebene durchgesetzt werden – in der Speicher- und Netzwerkschicht –, nicht nur in der Anwendungsschicht. Ein Kontingent in der Anwendungsschicht ist eine höfliche Bitte. Ein Kontingent auf Plattformebene ist ein Vertrag. Abrechnung, Messung und interne Leistungsverrechnung Bei der Abrechnung entscheidet sich, ob das Geschäftsmodell mandantenfähiger KI-Infrastruktur aufgeht. Die erforderliche Messgenauigkeit ist feiner als das, was die meisten Universal-Objektspeicher von Haus aus liefern. Die abrechenbaren Einheiten, die bei mandantenfähigen KI-Workloads zählen: Kapazität auf jeder Speicherebene – GPU-Direct-Flash, heiß, warm, kalt –, gemessen pro Mandant, pro Bucket und pro Zeitfenster Durchsatz während Trainingsläufen und beim Inferencing mit hoher Parallelität, oft gemessen pro gelesenem Gigabyte oder pro Objektanfrage Schutzstatus – Anzahl unveränderlicher Kopien, geografischer Replikate und Archivkopien –, weil jede Schutzeinstellung Grenzkosten verursacht, die der Betreiber decken muss Betriebsereignisse – Wiederherstellungen aus dem Archiv, regionsübergreifende Replikationsläufe, Lifecycle-Übergänge –, die Infrastruktur über die Grundlast hinaus beanspruchen Ohne Messung pro Mandant, pro Ebene und pro Operation mittelt der Betreiber am Ende die Kosten über alle Mandanten und berechnet effizienten Mandanten zu viel oder subventioniert ineffiziente. Beides schadet den Vertragsverlängerungen. Auch die interne Leistungsverrechnung ist wichtig. Unternehmen, die mandantenfähige KI-Infrastruktur für viele Geschäftsbereiche betreiben, müssen die KI-Kosten auf die einzelnen Bereiche umlegen. Eine Plattform, die Berichte pro Namespace, pro Ebene und pro Schutzstatus liefert, gibt dem zentralen Plattformteam eine Verrechnungsgrundlage, die der Geschäftsbereich direkt nutzen kann – an sich schon ein Vorteil gegenüber einer pauschalen internen Umlage. Der Beitrag zum Thema SLA (Service Level Agreement) zeigt, wie sich die Messung mit vertraglichen Zusagen in Einklang bringen lässt. Ergebnisbasierte Vertragsmodelle – Preise, die sich an Verfügbarkeit, Durchsatz, Schutzniveau und Servicegarantien orientieren statt an reinen Hardwarespezifikationen – werden bei KI-Serviceangeboten zunehmend zur Norm. Der Betreiber verpflichtet sich zu einem Ergebnis, die Messebene belegt, dass das Ergebnis geliefert wurde, und die Rechnung entspricht dem Vertrag. Kann die Messebene diesen Nachweis nicht erbringen, ist der Vertrag nicht zu verteidigen. Sicherheitsgrenzen, die einem Audit standhalten Sicherheitsgrenzen in mandantenfähiger KI-Infrastruktur umfassen mehr als Verschlüsselung und Zugriffskontrolle. Fünf Teilgrenzen müssen pro Mandant definiert und auf Plattformebene durchgesetzt werden. Identitätsgrenze. Jeder Mandant hat sein eigenes Konto, seinen eigenen IAM-Bereich und seinen eigenen Lebenszyklus für Zugangsdaten. Es gibt keine gemeinsame Root-Identität, die mandantenübergreifend übernommen werden kann. Mandantenübergreifender Zugriff ist konstruktionsbedingt ausgeschlossen, nicht nur per Richtlinie. Kryptografische Grenze. Verschlüsselungsschlüssel pro Mandant, deren Rotation und Widerruf – soweit der Vertrag es zulässt – unter der Kontrolle des Mandanten liegen. Eine Plattform, die die Daten aller Mandanten mit einem einzigen Schlüssel verschlüsselt, hat keine kryptografische Grenze, sondern nur eine kryptografische Illusion. Audit-Grenze. Audit-Logs pro Mandant, die der Mandant lesen und der Betreiber nicht unbemerkt verändern kann. Manipulationssichere Audit-Trails sind für regulierte Workloads heute eine Grunderwartung, keine Premiumfunktion. Residenzgrenze. Residenzrichtlinie pro Mandant – in welchen Regionen, an welchen Standorten und unter welchen Rechtsordnungen die Daten liegen dürfen. Die Datenresidenz wird in der Platzierungsebene durchgesetzt, nicht nur im Vertrag versprochen. Die Referenz zu Speicherebenen im Rechenzentrum beschreibt das Platzierungsdesign über Ebenen und Standorte hinweg. Grenze für betrieblichen Zugriff. Der Zugriff von Personal auf die Daten eines Mandanten ist prüfbar, einschränkbar und bei Bedarf auf bestimmte Staatsangehörigkeiten oder Sicherheitsfreigaben beschränkt. Souveräne Mandanten verlangen das ausdrücklich, regulierte Mandanten implizit über Compliance-Frameworks. Das Modell CORE5 für Cyber-Resilienz – Unveränderlichkeit, Ausfallsicherheit durch Erasure Coding, Metadatenschutz, standortübergreifende Replikation und richtliniengesteuerter Lebenszyklus – macht aus jeder dieser Grenzen eine Eigenschaft der Plattform statt einer Konfigurationsoption. Für mandantenfähige Betreiber ist genau dieser Unterschied das Erste, wonach Audit-Teams fragen. Warum das auf eine autonome Dateninfrastruktur hinausläuft Jede der oben genannten Säulen – Isolation, Namespace-Trennung, Kontingente, Abrechnung, Sicherheitsgrenzen – weist auf dieselbe architektonische Lücke hin. Klassischer Speicher wurde für einen Mandanten pro Plattform, eine Ebene pro Workload und einen Refresh-Zyklus pro Architektur entworfen. Mandantenfähige KI-Workloads widerlegen alle drei Annahmen auf einmal. Eine mandantenfähige KI-Plattform braucht eine Infrastruktur, die vielfältige Workload-Anforderungen – Training, Inferencing, Retrieval, Archiv – unterstützt, ohne den Betreiber zu zwingen, für jede ein eigenes System zu betreiben. Sie braucht richtliniengesteuerten Betrieb, damit das Betriebsteam unterproportional zur Zahl der Mandanten wächst. Sie braucht Cyber-Resilienz, die in die Architektur eingebaut ist, statt mit einem Backup-Produkt nachgerüstet zu werden. Sie muss ihren eigenen Zustand pro Mandant prüfen, belegen und berichten können – für SLAs ebenso wie für Audits. Und sie muss all das auf einer Plattform liefern, die der Betreiber auf einer Ebene erweitern kann, ohne die Preise aller anderen Ebenen neu zu kalkulieren. Genau für diese Lücke wurde Scality ADI (Autonomous Data Infrastructure) entwickelt. Wie Scality ADI mandantenfähige KI-Infrastruktur unterstützt Scality ADI ist eine Dateninfrastruktur für Enterprise-KI, Cyber-Resilienz und souveräne Kontrolle, die autonom und nachhaltig die passenden Speichermedien im Maßstab von mehreren Petabyte bis Exabyte zuordnet. Für Betreiber einer Plattform für mandantenfähige KI-Infrastruktur zählen vier Eigenschaften am meisten. Mandantenfähiges S3 im großen Maßstab. Scality ADI stellt S3-kompatiblen Objektspeicher als API für Mandanten bereit – mit isolierten Namespaces, IAM pro Mandant, Kontingenten, Audit-Grenzen und Lifecycle-Richtlinien. Mandanten erhalten die API, die ihre Tools bereits verstehen; der Betreiber erhält einen einzigen Kontrollpunkt auf Plattformebene, um Isolation durchzusetzen, Verbrauch zu messen und Audit-Nachweise zu erbringen. Temperaturübergreifendes Design mit vier Ebenen in einem Betriebsmodell. GPU-Direct-Flash mit S3 over RDMA, die heiße Ebene mit QLC und NL-SSD, die warme Ebene mit HDD sowie die kalte Ebene mit Band und Cloud-naher Archivierung liegen alle im selben Betriebsmodell. Der Betreiber kann Mandanten gestaffelten KI-Speicher anbieten – Premium-Kapazität mit GPU-Direct für das Training, heiß für den Inferencing-Cache, warm für Embeddings, kalt für die Aufbewahrung –, ohne hinter den Kulissen vier getrennte Systeme zu betreiben. Die Referenz zu Tiered Storage für KI beschreibt das Designmuster. Autonomer Betrieb mit richtliniengesteuerter Ausführung. Guardian-Agenten liefern Erkenntnisse und Empfehlungen innerhalb betreiberdefinierter Richtlinien: Kapazitätserweiterung, Selbstheilung, Rebalancing, Übergänge zwischen Ebenen, Upgrade-Validierung. Das Betriebsteam entscheidet, worauf es reagiert, oder lässt freigegebene KI-Tools über MCP (Model Context Protocol) innerhalb der Richtlinien handeln. Die Personaldecke muss nicht linear mit der Zahl der Mandanten wachsen – und genau diese Eigenschaft entscheidet, ob die Wirtschaftlichkeit bei fünfzig wie bei fünfhundert Mandanten aufgeht. CORE5-Cyber-Resilienz by Design. Unveränderlichkeit, Ausfallsicherheit durch Erasure Coding, Metadatenschutz, standortübergreifende Replikation und richtliniengesteuerter Lebenszyklus sind Eigenschaften der Plattform statt Funktionen, die der Betreiber selbst zusammenstellen muss. Pro Mandant kann der Betreiber Ausfallsicherheit, Unveränderlichkeitsstatus und Wiederherstellungsbereitschaft als Audit-Nachweis berichten – nicht als Marketingversprechen. Scality ADI wird als Open-Code-Software bereitgestellt – als Software-Appliance oder als Managed Service. Für einen mandantenfähigen Betreiber bedeutet das: Die Plattform lässt sich im eigenen Rechenzentrum bereitstellen, als eigener Service vermarkten und sowohl vom Betreiber als auch von seinen Mandanten prüfen, wenn Residenz- oder Audit-Anforderungen das verlangen. Scality bietet Unternehmen und souveränen Organisationen einen Weg zu KI-Leistung im großen Maßstab, ohne auf Kontrolle, Resilienz oder langfristige wirtschaftliche Disziplin zu verzichten – und dieselbe Eigenschaft erlaubt es einem mandantenfähigen Betreiber, diese Ergebnisse zu einem belastbaren kommerziellen Angebot zu bündeln. Das MultiScale-Design – Kapazität, Durchsatz und Operationen skalieren unabhängig voneinander – sorgt dafür, dass die Wirtschaftlichkeit pro Mandant über einen ganzen Refresh-Horizont aufgeht. Ein Betreiber, der einen Mandanten mit Foundation-Modellen aufnimmt, kann die GPU-Direct-Ebene erweitern, ohne die Preise des kalten Archivs neu zu kalkulieren. Ein Sovereign-Cloud-Betreiber, der seinen Mandantenstamm ausbaut, kann auf einer Ebene Kapazität hinzufügen und den Betriebsaufwand konstant halten. So unterstützt Scality ADI mandantenfähige KI-Infrastruktur im großen Maßstab Häufig gestellte Fragen Was ist mandantenfähige KI-Infrastruktur? Mandantenfähige KI-Infrastruktur ist die Gesamtheit aus Compute-, Speicher-, Netzwerk-, Identitäts- und Betriebskontrollen, mit der eine einzige Plattform viele Mandanten bedient, die KI-Workloads – Training, Fine-Tuning, Inferencing, Retrieval und Aufbewahrung – auf gemeinsam genutzten physischen Ressourcen ausführen, bei starker Isolation zwischen den Mandanten und mandantenbezogener Verantwortlichkeit für Verbrauch, Leistung und Sicherheitsniveau. Das Minimum umfasst Mandantenisolation, Namespace-Trennung, Kontingente pro Mandant, Abrechnung und Messung sowie Sicherheitsgrenzen. Worin unterscheidet sich mandantenfähige von nicht mandantenfähiger KI-Infrastruktur? Eine KI-Plattform für einen einzigen Mandanten wird für einen Kunden gebaut: das Unternehmen, das sie betreibt. Eine mandantenfähige Plattform wird für viele Mandanten auf gemeinsamer Infrastruktur gebaut und muss sie hinsichtlich Daten, Leistung, Lebenszyklus, Betrieb, Identität, Verschlüsselung, Audit und Datenresidenz voneinander isolieren. Mandantenfähige Betreiber brauchen zudem eine Messung pro Mandant für die Abrechnung, SLA-Berichte pro Mandant und Sicherheitsgrenzen pro Mandant – nichts davon muss eine Plattform für einen einzigen Mandanten typischerweise liefern. Was erfordert Mandantenisolation konkret? Mandantenisolation erfordert vier Grenzen, die gleichzeitig halten: Datenisolation, damit ein Mandant nicht auf den Namespace eines anderen zugreifen kann; Leistungsisolation, damit die Lastspitze eines Mandanten das SLA eines anderen nicht beeinträchtigt; Isolation von Lebenszyklus und Richtlinien, damit Mandanten auf derselben Plattform unterschiedliche Aufbewahrungs- und Schutzregeln nutzen können; und betriebliche Isolation, damit Wartungsereignisse aus Sicht jedes Mandanten unbemerkt bleiben. Jede Grenze muss auf Plattformebene statt in der Anwendungsschicht durchgesetzt werden. Wie werden Kontingente in mandantenfähiger KI-Infrastruktur durchgesetzt? Kontingente pro Mandant müssen auf der Speicher- und Netzwerkebene durchgesetzt werden, nicht nur in der Anwendungsschicht. Die vier Arten von Kontingenten, die für KI-Workloads zählen, sind Kapazität auf jeder Ebene (GPU-Direct, heiß, warm, kalt), Durchsatz (Dauerrate plus Burst-Budget), Anfragerate (Operationen pro Sekunde) und Parallelität (gleichzeitig laufende Operationen). Ein Kontingent in der Anwendungsschicht ist eine höfliche Bitte; ein Kontingent auf Plattformebene ist ein Vertrag. Welche Sicherheitsgrenzen braucht eine mandantenfähige KI-Plattform? Pro Mandant müssen fünf Grenzen halten: eine Identitätsgrenze, damit es keine mandantenübergreifende Root-Identität gibt, eine kryptografische Grenze mit Schlüsseln pro Mandant, eine Audit-Grenze mit manipulationssicheren Logs pro Mandant, eine in der Platzierungsebene durchgesetzte Residenzgrenze und eine Grenze für betrieblichen Zugriff mit prüfbarem und einschränkbarem Personalzugriff. Jede Grenze muss eine Eigenschaft der Plattform sein und keine Konfigurationsoption, die der Betreiber selbst zusammenstellen muss. Weiterführende Artikel Speicherisolation bei Mandantenfähigkeit SLA (Service Level Agreement) Speicherebenen im Rechenzentrum Tiered Storage für KI: skalierbare Leistung und Kostenkontrolle Souveräner Cloud-Speicher Datensouveränität in der Cloud CORE5-Lösung für Cyber-Resilienz (auf Englisch) KI-Datenpipelines: Architektur, Phasen und Best Practices
