13 „Autonom“ tauchte in diesem Jahr auf den Funktionslisten vieler Technologieanbieter auf, und Speicher war keine Ausnahme. Der Grund liegt auf der Hand: KI hat Infrastrukturteams in ein Terrain gedrängt, für das ihre Werkzeuge nie gebaut wurden: mehr Daten, mehr Workloads, mehr Dringlichkeit und bei Weitem nicht genug Personal, um alles von Hand zu betreiben. „Autonom“ ist zur Kurzformel für „Problem gelöst“ geworden. Doch das Wort trägt einen Mythos in sich, den es gleich zu Beginn zu entkräften gilt, und nach ihm ist dieser Beitrag benannt: die Annahme, dass ein Mensch „in the Loop“ bedeutet, dass eine Person jede Aktion in Echtzeit genehmigt. Hält man beide Gedanken nebeneinander – autonom, aber ein Mensch zeichnet alles ab –, heben sie sich gegenseitig auf. Entweder wartet das System auf eine Person und ist nicht autonom, oder es handelt selbstständig, und der Mensch hat nicht wirklich die Kontrolle. Dieser scheinbare Widerspruch ist der Grund, warum „Human in the Loop“ als Marketing-Floskel abgetan wird. Die Auflösung besteht darin, das Modell als zwei Ebenen zu sehen, nicht als eine Abfolge. Die erste ist eine stehende Richtlinie: Menschen legen die Autorisierungsgrenzen im Voraus fest und verantworten sie. Die zweite ist die Laufzeitschleife, und sie ist schnell: Eine Erkenntnis taucht auf, die Plattform prüft sie gegen diese stehende Richtlinie und führt die Aktion automatisch aus, wenn sie innerhalb der Grenze liegt, und eskaliert an eine Person, wenn nicht oder wenn so viel auf dem Spiel steht, dass ein Mensch im Moment selbst entscheiden sollte. Die Kontrolle bleibt beim Menschen. Was sich ändert, ist, wann er sie ausübt: Er wechselt auf die Richtlinienebene, wo die eigentlichen Entscheidungen fallen. Diese Unterscheidung ist wichtig, weil „autonom“ bei jedem Anbieter etwas anderes bedeutet. Der eine meldet ein Problem und wartet auf eine Person; der andere handelt einfach, ganz ohne Genehmigung. Käufer müssen raten, was sie tatsächlich kaufen, und dieses Raten wird teuer, wenn die Daten in den Exabyte-Bereich gehen und ein Fehler nicht klein bleibt. An dieser Definition von „autonom“ sollten Sie Ihren Anbieter messen: Menschen legen die Richtlinie im Voraus fest; ein KI-Agent bringt eine Empfehlung ein; die Plattform prüft sie gegen diese Richtlinie und führt mit Maschinengeschwindigkeit nur aus, was bereits freigegeben ist, protokolliert jeden Schritt und fragt bei allem, was die Richtlinie nicht abdeckt, eine Person. Autonomie entfernt den Menschen nicht, sie verlagert ihn nach vorn Niemand, der für ein Exabyte an Produktivdaten verantwortlich ist, will ein System, das außerhalb der gesetzten Grenzen handelt, und niemand will einen Prüfbericht unterschreiben, in dem steht: „Die Plattform hat entschieden.“ Wenn die Sprache eines Anbieters also nahelegt, dass Ihre Betriebsteams nun optional sind, stellen Sie die direkte Frage: Was macht diese Plattform mit unseren Daten, wenn niemand hinsieht, und kann sie es hinterher belegen? Hier richtet der Mythos seinen Schaden an. Weil „Human in the Loop“ mit Echtzeitgenehmigung gleichgesetzt wird, schließen Teams, sie müssten zwischen Kontrolle und Maschinengeschwindigkeit wählen, und Anbieter grenzenloser Automatisierung lassen sie das gern glauben. Doch die eigentliche Aufgabe des Menschen ist eine andere: im Voraus zu entscheiden, welche Aktionen unter welchen Bedingungen freigegeben sind, und diese Richtlinie zu verantworten. Der Mensch schreibt die Richtlinie; die Plattform handelt innerhalb ihrer Grenzen. Vieles, was als autonomer Speicher vermarktet wird, ist gewöhnliche oder grenzenlose Automatisierung im Gewand selbstfahrender Sprache. Begriffe wie selbstheilend, selbstoptimierend, Zero Touch oder „die KI kümmert sich darum“ überspringen die einzigen Fragen, die zählen: Welche Aktionen kann das System selbstständig ausführen, wer hat das entschieden, und was geschieht mit allem, was die Richtlinie nicht abdeckt? Den Menschen zu entfernen, war nie das Ziel. Ziel war es, die Triage von Warnmeldungen, die Archäologie in Dashboards und das Rätselraten um drei Uhr morgens loszuwerden, und nichts davon sollte damit enden, einer Aufsichtsbehörde erklären zu müssen, warum Ihre Speicherplattform eigenmächtig etwas gelöscht hat. Schafft ein Mensch in der Schleife nicht einfach den Engpass neu? Sehen Sie sich die Uhr an, gegen die ein Angreifer läuft. Die durchschnittliche Breakout Time, vom Erstzugriff bis zur schädlichen Aktivität, sank 2025 auf 29 Minuten – 65 % schneller als im Vorjahr, mit einem Rekordwert von 27 Sekunden (CrowdStrike 2026 Global Threat Report). Bei 27 Sekunden gewinnt kein Workflow, der im Moment auf eine menschliche Entscheidung wartet, dieses Rennen. Genau deshalb muss die Entscheidung fallen, bevor das Rennen beginnt. Ein autonomes Modell, dessen Antwort auf Dringlichkeit lautet „jemanden anpiepen und hoffen, dass er wach ist“, ist kein ernsthaftes Design. Das heißt nicht, dass Speicher versuchen sollte, Angriffe in der Geschwindigkeit des Angreifers zu erkennen. Das ist kein Versprechen einer Speicherplattform, und jeder Anbieter, der Ihnen das verkauft, betreibt wieder Autonomie-Washing. In einem agentischen Workflow ist die entscheidende Frage, ob die Aktion vor dem dringlichen Moment bereits per Richtlinie autorisiert wurde. Schafft ein Mensch in der Schleife also einen neuen Engpass? Nur wenn man annimmt, dass er in Echtzeit genehmigen muss. Vorab-Autorisierung ändert diese Annahme: Sie legen im Voraus fest, welche Aktionen bereits freigegeben sind, beginnend mit umkehrbaren Arbeiten, während alles, was Daten oder Kapazität vernichtet, weiterhin eine menschliche Entscheidung im Moment erfordert, zumindest bis die Umkehrung selbst getestet und als sicher erwiesen ist. Und wo keine Richtlinie die Situation abdeckt, fällt der Workflow darauf zurück, eine Person zu fragen. Dieser Rückfall ist gewollt; im Exabyte-Maßstab ist er die einzig sichere Voreinstellung. Wo die Autorisierungsgrenze liegt: Scality ADI (Autonomous Data Infrastructure) unterstützt beide Modelle. Guardian, die integrierte KI-Betriebsfunktion, arbeitet nur lesend: Sie empfiehlt Aktionen, und jede über Guardian angestoßene Aktion erfordert eine menschliche Genehmigung. Kunden, die ADI über ihren eigenen agentischen Harness per MCP betreiben, können stattdessen in diesem Harness Autorisierungsrichtlinien definieren, sodass Aktionen, die diese Richtlinien bereits freigeben, ohne neue menschliche Entscheidung im Moment ausgeführt werden. (auf Englisch) Im kundenbetriebenen Modell verlagert sich diese Funktionstrennung aus Guardian heraus: Der Harness verantwortet die Autorisierungsgrenze, und der KI-Stack kann die über MCP bereitgestellten operativen Aktionen mit den ihm zugewiesenen Berechtigungen aufrufen. Das sollte man nicht kleinreden: Die Zugangsdaten, die Sie Ihrem KI-Stack übergeben, sind privilegierter Zugriff und sollten auch so behandelt werden: mit schriftlicher Richtlinie, festgelegtem Umfang und Protokoll. Es lohnt sich auch, präzise zu sein, was eine „Empfehlung“ ist, denn sie als bessere Warnmeldung zu behandeln, ist ein Fehler: Eine Warnmeldung verlangt Ihre Aufmerksamkeit. Eine Empfehlung verlangt Ihre Entscheidung. Eine Entscheidung bringt Haftung mit sich. Das ist die Falle bei begrenzter Autonomie: Eine lange Liste von Empfehlungen, die auf Echtzeitgenehmigung warten, führt zu Genehmigungsmüdigkeit, und aus Prüfungen werden Abnickvorgänge. Im Voraus festzulegen, welche Aktionen Ihre Richtlinie freigibt und welche nie, macht es überhaupt erst sicher, Autonomie einzuschalten. Das eigentliche Produkt ist die Grenze, nicht die Intelligenz Gute Empfehlungen werden leicht, daher liegt die interessante Ingenieursarbeit nicht mehr dort. Das Schwierige ist die Grenze: eine Richtlinienebene, die dem Kunden gehört, von der Plattform durchgesetzt wird und aufzeichnet, was vorgeschlagen wurde, wer es autorisiert hat, was ausgeführt wurde und was sich geändert hat. In Scality ADI werden Richtlinien von Betriebsteams definiert und genehmigt, nicht von undurchsichtiger Automatisierung, und der Kunde behält den Audit-Trail. Dieses Eigentum ist wichtig, denn im Exabyte-Maßstab bleibt eine schlechte Entscheidung nicht klein. ADI bietet vier Stufen in einem einzigen S3-Namespace: GPU-Direct (TLC-Flash, S3 über RDMA) Hot (QLC und NL-SSD) Warm (NL-SSD und HDD) Cold (Band und Cloud) Im Exabyte-Maßstab kann eine falsch autorisierte Operation eine enorme Datenmenge betreffen, bevor ein Mensch eingreifen kann. Deshalb müssen hier mehr als irgendwo sonst die Grenze und das Protokoll halten. Die Bedrohungslage ist genau der Grund, warum das Protokoll ebenso wichtig ist wie die Grenze. Bei Ransomware-Vorfällen wurden 34 % der Backup-Repositories verändert oder gelöscht (Veeam 2025 Ransomware Trends). Wenn Sie nicht feststellen können, ob eine Aktion autorisiert war, haben Sie zum denkbar schlechtesten Zeitpunkt ein Ermittlungsproblem geschaffen. Teams müssen rekonstruieren, was geschehen ist, klären, ob die Aktivität legitim war, und eine prüfbare Verantwortungskette wiederherstellen. Bis Sie das ausschließen können, bearbeiten Sie einen Vorfall. Die Objektversionierung zeigt, was sich geändert hat; nur das Protokoll zeigt, wer es freigegeben hat. In Scality ADI werden Aktionen der Betriebsteams im Supervisor und seiner API in Logs geschrieben, die Sie an Ihr eigenes SIEM weiterleiten können. Und ein Protokoll ist nur so gut wie die Verantwortlichkeit dahinter; fragen Sie daher, wofür ein Anbieter vertraglich einsteht, nicht nur, was seine Architektur zulässt. Eine Checkliste für alle, die Ihnen „Autonomie“ verkaufen Autonomie, die sich nicht prüfen lässt, ist ein unbegrenztes Haftungsrisiko mit besserem Marketing. Vertrauen Sie ihr nicht. Diese Fragen sollen die Grenzen, Kontrollen und Verantwortlichkeiten hinter jedem Autonomieversprechen offenlegen. Fragen Sie im ersten Termin: Was kann es tun, ohne mich zu fragen? Kann der Anbieter diese Aktionen nicht aufzählen, gibt es keine Grenze. Können Sie das Protokoll vorlegen, und kann ich beweisen, dass es nicht verändert wurde? Fragen Sie nach Manipulationsnachweis, Aufbewahrung, Export in Ihre eigenen Werkzeuge und danach, wofür der Anbieter vertraglich haftet, wenn das Protokoll falsch ist. Ein Protokoll, das nur der Anbieter vorlegen kann, ist sein Wort auf seinem Briefpapier. Wessen Richtlinie gilt, und wie fein lässt sie sich eingrenzen? Lautet die Antwort „unsere Standardeinstellungen“, ist die Richtlinie nicht Ihre, und das Risiko auch nicht. Grenzen Sie nach Aktion, Stufe, Bucket, Rate und Kapazitätsanteil ein. Ein grober Umfang ist nur ein größerer Explosionsradius. Nehmen Sie diese Fragen mit in das Architektur-Review: Wie wird verhindert, dass die empfehlende Komponente selbst ausführt? Kann dieselbe Komponente vorschlagen und handeln, sollte der Anbieter das offen sagen. Wenn nicht, fragen Sie, ob der Nur-Lese-Zugriff durch separate Zugangsdaten und eine separate API-Oberfläche durchgesetzt oder nur in der Konfiguration behauptet wird. Eine Designabsicht ist keine Kontrolle. Kann ich es beobachten, bevor ich ihm vertraue? Verlangen Sie einen Probelauf oder eine Ansicht der vorgeschlagenen Änderungen. Autonomie, die sich nicht proben lässt, testen Sie im Produktivbetrieb. Lässt sich eine genehmigte Aktion rückgängig machen? Fragen Sie, welches Rollback es gibt, mit welcher Granularität und in welchem Zeitfenster. „Aus dem Backup wiederherstellen“ ist kein Rückgängigmachen. Was passiert, wenn die Schleife unterbrochen wird? Ist der genehmigende Stack nicht erreichbar oder schlägt die Richtlinienprüfung fehl, hält die Plattform an, stellt die Aktion in eine Warteschlange oder führt sie nach der letzten Anweisung aus? Fail-open ist eine Entscheidung, die jemand für Sie getroffen hat. Und wie stoppen Sie eine laufende Aktion: sofortiger Stopp oder Entzug der Zugangsdaten, und wer darf diesen Hebel ziehen? Wer ist verantwortlich, wenn die Richtlinie falsch war? Die Antwort sollte einen klar verantwortlichen Eigentümer benennen und nicht mit „das System hat entschieden“ enden. Legen Sie diese Fragen Ihrem bestehenden Anbieter und jedem Herausforderer vor, den Sie bewerten, und vergleichen Sie die Antworten nebeneinander. Stellen Sie Scality dieselben Fragen. Wenn wir sie nicht beantworten können, haben auch wir uns das Wort „autonom“ nicht verdient. Einige unserer Antworten sind bereits dokumentiert. Beim AI Field Day 8 (auf Englisch) haben wir Guardian und die operative MCP-Ebene vor unabhängigen Delegierten vorgeführt, die eigens gekommen waren, um kritisch nachzuhaken und die schwierigen Fragen zu stellen. Zuerst die Richtlinie. Dann Erkenntnis, Prüfung, Ausführung. „Autonom“ wird im Speichermarketing weiter auftauchen. Das Wort selbst beweist nichts; entscheidend ist, ob ein Anbieter Ihnen eine im Voraus von Menschen verfasste Richtlinie zeigen kann, gefolgt von Erkenntnis, Richtlinienprüfung und Ausführung, mit einem Protokoll als Beleg. Alles andere ist eine Vermutung, die sich als Funktion verkleidet. So sieht es aus, wenn man sich das Wort verdient: Autonomer Speicher bezieht Sie weiterhin ein, nur früher, als Sie erwarten. Sie legen die Grenzen vorab in der Richtlinie fest; ein Agent zeigt, was geschieht; und die Plattform führt mit Maschinengeschwindigkeit nur aus, was diese Regeln bereits freigeben, protokolliert jeden Schritt und fragt eine Person, wann immer die Regeln eine Entscheidung nicht abdecken.
