Google Clouds echter KI-Test: der regierte Workflow nach der Demo

Zusammenfassung

• Das KI-Angebot von Google Cloud für Unternehmen ist nicht mehr nur ein Aufruf des Gemini-Modells. Es handelt sich um eine operative Oberfläche, die Gemini Enterprise Agent Platform, das Vertex AI-Erbe, BigQuery, Agent Search, IAM, Cloud Audit Logs, Cloud Run, Workflows und Kapazitätssteuerungen zu einem regierten Workflow zusammenführt.
• Der akzeptierte Output ist der maßgebliche Nenner. Eine Modellantwort ist nur ein Schritt; die Produktionszuverlässigkeit hängt von der Datenaktualität, den Werkzeugberechtigungen, den Evaluierungssets, der Audit-Protokollierung, dem Quotendesign, den Kostenkontrollen, der Ausnahmebehandlung und der Rückrollbarkeit ab.
• Öffentliche Belege stützen die Kontrolltiefe und Nachfrage von Google Cloud, aber nicht universelle Kundenergebnisse. Die Berichte von Alphabet zeigen ein starkes Wachstum von Google Cloud und Investitionen in die Infrastruktur, während Statusvorfälle und die Dokumentation zeigen, warum Kunden weiterhin eine lokale Überwachung und ein Wiederherstellungsdesign benötigen.

Der entscheidende Output ist der akzeptierte Workflow, nicht die beeindruckende Antwort

Die stärkste Demo von Google Cloud AI beantwortet eine Frage mit einem großen Kontextfenster, einer datengestützten Zusammenfassung, einem Agenten, der ein Werkzeug aufruft, oder einem Entwickler, der schnell von einer natürlichsprachlichen Anfrage zu deploytem Code übergeht. Diese Demo ist wichtig, aber nicht die Produktionseinheit, für die ein Unternehmenskunde letztlich zahlt.

Die entscheidende Einheit ist der akzeptierte, regierte Workflow: eine modellgestützte Antwort, Entscheidung, Codeänderung, ein Datenergebnis, eine Kundenantwort, eine Sicherheitsempfehlung oder eine interne Aktion, die ein Unternehmen bereit ist zu behalten, zu prüfen und zu wiederholen.

Dieser Nenner verändert die Bewertung. Ein Modell kann in Sekunden eine flüssige Antwort erzeugen und dennoch den Workflow nicht bestehen, wenn es veraltete Unternehmensdaten zitiert, unter einer falschen Identität handelt, ein Kontingent überschreitet, nach einer Modellmigration stillschweigend das Verhalten ändert, keinen nützlichen Prüfpfad hinterlässt oder eine Nebenwirkung erzeugt, die ein Team nicht rückgängig machen kann.

Der akzeptierte Output umfasst jede Arbeit, die nötig ist, um von der Anfrage zu einem verwendbaren Ergebnis zu gelangen: Datenaufbereitung, Zugriffsdesign, Retrieval-Tuning, Evaluierung, menschliche Überprüfung, Ausnahmebehandlung, Überwachung, Kostenzuordnung, Vorfallsbehandlung und Migrationsplanung.

Google Cloud ist für diesen Test gut gerüstet, gerade weil sein öffentliches Angebot inzwischen breiter ist als ein Modell-Endpunkt. Im Jahresbericht 2025 von Alphabet wird Google Cloud als Anbieter von Infrastruktur-, Plattform-, Anwendungs- und anderen Cloud-Diensten beschrieben, mit KI-Angeboten wie Enterprise AI Infrastructure, Vertex AI und Gemini Enterprise sowie Cybersicherheit und Datenanalyse.

derselbe Bericht weist einen Umsatz von 58,705 Milliarden US-Dollar für Google Cloud im Jahr 2025 aus, während das Q1-2026-Formular 10-Q einen Google Cloud-Umsatz von 20,028 Milliarden US-Dollar im Quartal zeigt, ein Anstieg von 63 % im Jahresvergleich. Das ist keine Nischen-Entwickler-API. Es ist ein großes Cloud-Unternehmensgeschäft, das Kunden auffordert, wiederkehrende Arbeiten auf seine Infrastruktur zu verlagern.

Die Größenordnung erhöht den Standard. Wenn Google Cloud das System sein will, in dem Mitarbeiter, Entwickler, Datenteams und Betriebsgruppen KI-gestützte Arbeit akzeptieren, sollten Kunden es nach gewöhnlichen, wiederholten Aufgaben beurteilen, nicht nach Grenzmomenten. Kann ein Analyst eine fundierte Frage zur internen Richtlinie stellen und eine Antwort erhalten, die aktuell, berechtigungskorrekt und überprüfbar ist? Kann ein Entwickleragent Code vorschlagen und dabei Quellcodeverwaltung, Testbelege und Rückrollbarkeit bewahren?

Kann ein Kunden-Support- oder Sicherheitsworkflow eine Empfehlung an die richtige Person weiterleiten, mit genügend Kontext, um sie anzunehmen oder abzulehnen? Kann ein Datenteam wissen, welcher Datensatz, welche Modellversion und welche Benutzeranfrage die Antwort erzeugt haben? Das sind Produktionsfragen. Sie werden nicht allein durch Modellfähigkeit beantwortet.

Die rechtliche und markenbezogene Grenze ist nicht kosmetisch

Das Unternehmen im Fokus ist Google Cloud, das Cloud-Geschäft von Google für Infrastruktur-, Daten-, Sicherheits-, Kollaborations- und Enterprise-KI-Dienste. Es sollte nicht mit Google Search, der privaten Gemini-Nutzung, DeepMind-Forschungsankündigungen, YouTube, Android oder jedem Partner- und Kundenergebnis, das zufällig ein Google-Modell nutzt, gleichgesetzt werden. Die Segmentierung von Alphabet selbst ist hier wichtig: Google Cloud umfasst Google Cloud Platform und Google Workspace, und GCP-Dienste umfassen Infrastruktur, Plattform, Enterprise AI Infrastructure, Vertex AI, Gemini Enterprise, Cybersicherheit und Datenanalyse.

Das ist die operative Grenze für diesen Artikel.

Die Grenze schützt die Analyse auch vor einem einfachen Fehler. Google verfügt über erstklassige Modellforschung, aber ein Kunde, der Google Cloud kauft, erhält keine direkte Garantie, dass jeder Modell-Durchbruch zu einem stabilen akzeptierten Workflow wird. Der Forschungsfortschritt kann die Rohantwort verbessern. Der regierte Workflow hängt immer noch von der Cloud-Produktoberfläche ab: IAM-Rollen, regionale Verfügbarkeit, Protokollierungsstandards, Datenkonnektoren, Kontingente, Hinweise zum Modelllebenszyklus, Supportvereinbarungen, SLAs, Abrechnung und Änderungsmanagement.

Ein DeepMind-Modellergebnis und ein Google Cloud-Produktionsergebnis sind verwandt, aber sie sind nicht die gleiche Evidenz.

Die Grenze wirkt auch in die andere Richtung. Wenn eine Kundenstory besagt, dass Replit Claude auf Vertex AI betreibt oder Fifth Dimension Gemini- und Claude-Inferenzen innerhalb von Vertex AI zentralisiert, ist der Beleg teilweise auf Google Cloud als verwaltete Multi-Modell-Kontrollebene ausgerichtet, nicht nur auf Gemini. Diese Unterscheidung ist kommerziell wichtig. Kunden können Google Cloud wählen, weil es ihnen ermöglicht, Google-Modelle, Partnermodelle, BigQuery, Cloud Run und Cloud-Sicherheitskontrollen in einer Architektur zu kombinieren.

Sie können auch mit Wechselkosten konfrontiert sein, weil dieselben Kontrollen Teil ihres Prozesses für akzeptierte Outputs werden.

Die Produktfrage lautet also nicht "Ist Gemini gut?", sondern "Kann Google Cloud modellgestützte Arbeit so regierbar machen, dass ein Unternehmen den Output nach Berücksichtigung der Gesamtkosten wiederholt akzeptiert?" Die Gemini-Qualität ist eine Eingabe. Die Cloud-Kontrolloberfläche ist das Produkt.

Google Cloud verkauft eine Kontrolloberfläche

Die aktuelle Dokumentation von Google beschreibtGemini Enterprise Agent Platformals einheitliche Plattform zum Erstellen, Bereitstellen, Regieren und Optimieren von unternehmenstauglichen agentischen Systemen und modellbasierten Lösungen. DieLifecycle-Übersichtunterteilt den Lebenszyklus in Erstellen, Skalieren, Regieren und Optimieren. Sie nennt Low-Code Studio, ein codeorientiertes Agent Development Kit, Model Garden-Zugriff, verwaltete Laufzeit, Sitzungsverwaltung, Memory Bank, eineindeutige Agentenidentität, Agent Registry, Agent Gateway, Gen AI-Evaluierung, Cloud Observability und Topology.

Diese Liste ist aufschlussreich. Sie zeigt, dass Google Cloud weiß, dass Unternehmens-KI nicht nur Inferenz ist. Dieselbe Plattform, die ein Modell hostet, muss auch beantworten, wer oder was handelt, welches Werkzeug genehmigt ist, welche Daten im Spiel sind, ob eine Antwort evaluiert wurde, ob die Aktion beobachtbar ist und wie eine Laufzeitumgebung bereitgestellt wird.

Der sinnvolle Vergleich ist daher nicht nur mit OpenAI, Anthropic, Microsoft, AWS oder einem Open-Source-Modell, sondern mit dem bestehenden Workflow des Kunden: einem manuellen Analystenprozess, einem etablierten SaaS-Workflow, einem Data Warehouse und BI-Stack, einer Ticket-Warteschlange, einem selbstgebauten Agenten-Framework oder einer risikoärmeren Entscheidung, weniger zu automatisieren.

Die öffentlichen Plattformkomponenten entsprechen natürlichen Produktionsfragen.Agent Registryzentralisiert genehmigte KI-Komponenten, MCP-Server und Endpunkte, sodass der Werkzeugzugriff nicht über unzusammenhängende Experimente verstreut ist.Agent Gatewaynutzt Registry-Metadaten, Agentenidentität und Richtlinienkontrollen und erzeugt gleichzeitig Beobachtbarkeits-Telemetrie für Interaktionen.Agent Identityverleiht einem Agenten eine stark bezeugbare Identität auf Basis von SPIFFE, wobei die Dokumentation besagt, dass Identitäten standardmäßig nicht von mehreren Workloads gemeinsam genutzt werden und keine langlebigen Dienstkontoschlüssel erzeugen können.

Diese Kontrollen sind wichtig, weil agentische Systeme anders scheitern als Chatbots. Ein Chatbot kann im Text falsch liegen. Ein Agent kann falsch liegen und gleichzeitig Daten lesen, ein Werkzeug aufrufen, ein Ticket aktualisieren, Code schreiben, eine Bereitstellung auslösen oder eine Anweisung an einen anderen Dienst weitergeben. Die Kontrolloberfläche muss den Unterschied zwischen einem Vorschlag und einer Aktion bewahren. Sie muss auch eine dauerhafte Spur dessen hinterlassen, was passiert, wenn eine fehlerhafte Prämisse von der Sprache in den Produktionszustand übergeht.

Der Vorteil von Google Cloud liegt darin, dass viele der umgebenden Komponenten bereits in seiner Cloud-Infrastruktur vorhanden sind. IAM, Cloud Audit Logs, BigQuery, Cloud Run, Workflows, Cloud Monitoring, VPC Service Controls und die Abrechnung sind keine Add-ons aus einem separaten Hobbyprojekt. Es sind etablierte Cloud-Primitive, die in den KI-Workflow eingebracht werden können. Die Schwäche ist dieselbe: Sobald ein Kunde den integrierten Weg beschreitet, erbt die Kette der akzeptierten Outputs die Komplexität, das Kostenmodell und die Fehlermodi einer Cloud-Plattform.

Datenverankerung ist das erste Zuverlässigkeitsproblem

Die meiste KI-Arbeit im Unternehmen scheitert, bevor sie das Modell erreicht. Die Daten sind unvollständig, veraltet, überberechtigt, schlecht beschrieben, dupliziert, regional eingeschränkt oder über SaaS-Systeme und Data Warehouses verstreut. Ein Modell, das isoliert stark ist, kann immer noch eine inakzeptable Antwort erzeugen, wenn das Retrieval-System die gestrige Richtlinie, einen veralteten Kundendatensatz, eine Datei, die der Benutzer nicht sehen sollte, oder eine Tabelle liefert, deren Bedeutung sich ohne Nachverfolgbarkeit geändert hat.

Google Cloud hat glaubwürdiges Rohmaterial für dieses Problem.Grounding with Agent Searchermöglicht es Gemini, über Agent Search eine Verbindung zu Website- oder Dokumentendaten herzustellen. Die Seite beschreibt Voraussetzungen wie IAM-Berechtigungen, Aktivierung von AI Applications und die Erstellung eines Datenspeichers und sagt, dass die Verankerung von Kundendaten bis zu 10 Agent Search-Datenquellen nutzen kann. Die separateAgent Search-Produktseitepositioniert den Dienst als verwaltetes RAG-System für Unternehmensdaten und beschreibt Zitate, Links, Datenquellensteuerung und Konnektoren.

Das reduziert den Erstellungsaufwand erheblich. Ein Team kann vermeiden, jede Komponente für Erfassung, OCR, Chunking, Einbettung, Indexierung, Retrieval und Zitierung manuell zusammenzubauen. Aber verwaltetes Grounding beseitigt nicht die Arbeit, zu entscheiden, wogegen die akzeptierte Antwort verankert werden soll. Eine maximale Anzahl von Datenquellen ist eine Grenze, um die herum man entwerfen muss. Ein Konnektor, der Jira, SharePoint, Salesforce oder einen Dokumentenspeicher liest, hängt immer noch von der Aktualität, den Berechtigungen und der Semantik dieser Systeme ab.

Wenn sowohl die offizielle Richtlinie als auch der Entwurf im Speicher liegen, weiß das Modell möglicherweise nicht, welche maßgeblich ist, es sei denn, die Retrieval- und Instruktionsschicht trägt diese Governance.

BigQuery fügt eine zweite Ebene hinzu. DieDaten-Governance-Dokumentationbeschreibt Knowledge Catalog, Metadaten-Discovery, Datenqualität, Datenprofilierung, Datenherkunft, IAM, Zugriffskontrollen auf Zeilen- und Spaltenebene, VPC Service Controls, Audit-Protokolle, Maskierung, Verschlüsselung, Freigabesteuerungen, Clean Rooms und Nutzungsmetriken. Das sind die Arten von Kontrollen, die ein Datenteam benötigt, bevor es ein modellgestütztes Ergebnis aus einem Warehouse-Kontext akzeptieren kann. Sie erfordern auch Arbeit. Jemand muss Glossarbegriffe, Eigentümer, Qualitätsregeln, Maskierungsrichtlinien, Zugriffsberechtigungen, Herkunftsaufnahme und Nutzungsüberwachung definieren. Diese Arbeit mag billiger sein, als einen privaten Daten-Governance-Stack von Grund auf aufzubauen, aber sie ist nicht kostenlos.

Daten-Governance ist auch der Punkt, an dem der Gesamtkostenvergleich konkret wird. Ein menschlicher Analyst kann Stunden damit verbringen, Dokumente zu finden, weiß aber, welche Quelle maßgeblich ist. Ein Cloud-gestützter Agent kann in Sekunden antworten, erfordert aber wochenlange Berechtigungsbereinigung und die Abstimmung des Datenspeichers, bevor die Antwort sicher genug ist, um akzeptiert zu werden. Die Frage ist nicht, ob Google Cloud Daten abrufen kann. Sie lautet, ob der Kunde seine Retrieval-Oberfläche genau und berechtigungskorrekt halten kann, und zwar mit der Geschwindigkeit normaler geschäftlicher Änderungen.

Datenschutzzusagen helfen, aber Aufbewahrung und Geografie erfordern dennoch Gestaltung

Die öffentlichen Zusagen von Google Cloud geben Unternehmenskäufern eine stärkere Ausgangsbasis als die Nutzung von Consumer-KI. DieService Specific Termsvon Google Cloud besagen, dass Google Kundendaten nicht ohne Erlaubnis oder Anweisung des Kunden zum Trainieren oder Feinabstimmen von KI/ML-Modellen verwendet. DieAgent Search-Daten-Governance-Seitesagt ebenfalls, dass Kundendaten, die in Agent Search verwendet werden, nicht zum Trainieren von Foundation-Modellen verwendet werden und dass Foundation-Modelle eingefroren sind und Eingaben verarbeiten, um Ausgaben für den Dienst zu liefern.

Das ist wichtig. Es adressiert eine der ersten Fragen auf Vorstandsebene: ob die eigenen Eingabeanfragen, abgerufenen Dokumente und Ausgaben zu Trainingsdaten für das Modell eines Anderen werden. Es hilft auch, die Unternehmens-KI von Google Cloud von einer weniger kontrollierten Consumer-Nutzung zu unterscheiden.

Aber der Datenschutzsatz ist nicht das gesamte Governance-Design. Die Dokumentation zuZero Data Retentionbesagt, dass Google Kundendaten nicht ohne Erlaubnis zum Trainieren oder Feinabstimmen von verwalteten Modellen verwendet, beschreibt aber auch Szenarien wie Missbrauchsüberwachung und Grounding-Modi, in denen das Aufbewahrungsverhalten variieren kann und Kunden möglicherweise Ausnahmen beantragen oder separate Bedingungen verstehen müssen. Das Grounding mit Google Search und Maps besitzt eine eigene Aufbewahrungssprache. Das macht die Plattform nicht unsicher. Es bedeutet, dass ein Kunde jedes aktivierte Feature der Datenklasse, die er preisgeben möchte, und der Region, in der es verarbeitet werden darf, zuordnen muss.

Die regionale Frage ist ähnlich. Die Grounding-Dokumentation besagt, dass AI Applications in den Multi-Regionen "Global", "EU" und "US" verfügbar sind. Ein Unternehmen, das unter Datenlokalitätsvorschriften arbeitet, kann nicht davon ausgehen, dass jedes KI-Feature, jedes Modell, jeder Konnektor, jedes Protokoll und jeder Support-Pfad dieselbe Geografie hat. Datensouveränität ist selten ein einzelner Schalter. Sie ist eine Kette aus Modellstandort, Datenspeicherort, Protokollen, Support-Zugriff, Backup, Überwachung, Nutzung von Drittanbietermodellen und Mitarbeiterzugriff.

Diese Kette verändert die Beschaffung. Ein Unternehmen, das zwischen Google Cloud, einem anderen Cloud-Anbieter, einem etablierten SaaS-KI-Feature, einem Open-Source-Modell in seiner eigenen Umgebung oder weniger Automatisierung wählt, sollte die Datenpfad-Beweise vergleichen, nicht die Slogans. Google Cloud verfügt über viele der richtigen Kontroll-Primitive. Der Käufer muss immer noch nachweisen, dass der gewählte Feature-Satz seinen Lokalitäts-, Aufbewahrungs- und Prüfpflichten entspricht.

Berechtigungen entscheiden, ob ein Agent nützlich oder gefährlich ist

Der Schritt von der Antwort zur Aktion hängt von der Identität ab. Ein Modell, das nur zusammenfassen kann, ist durch seinen Text begrenzt. Ein modellgestützter Agent, der private Daten lesen, APIs aufrufen, Tickets schreiben, Code ändern, Kundendatensätze verändern, Workflows starten oder Bereitstellungen auslösen kann, benötigt ein Berechtigungsmodell, das enger ist als die Begeisterung der Demo.

Die Dokumentation von Google Cloud gibt Kunden mehrere nützliche Primitive an die Hand. DieAgent Platform IAM-Dokumentationbesagt, dass der Zugriff auf Projekt- oder Ressourcenebene verwaltet werden kann und dass benutzerdefinierte Rollen empfohlen werden, wenn Teams den Zugriff auf nur die erforderlichen Berechtigungen beschränken müssen.Agent Identitymacht den Agenten selbst zu einem Prinzipal, anstatt jede Aktion hinter einem einzigen gemeinsamen Dienstkonto zu verstecken.Agent Gatewayverwendet Identität und Registry-Metadaten für Autorisierungsentscheidungen und die Durchsetzung von Richtlinien.

Diese Kontrollen sind nur wertvoll, wenn der Kunde sie mit Disziplin einsetzt. Der Weg des geringsten Widerstands in jeder Plattform ist ein breiter Zugriff während des Piloten: ein Dienstkonto, eine freizügige Rolle, viele Werkzeuge und das Versprechen, es später enger zu fassen. Das mag für eine Sandbox akzeptabel sein. Für einen akzeptierten Workflow ist es das falsche Muster.

Ein regierter Workflow benötigt separate Identitäten für separate Aktionsklassen, Datenquellenberechtigungen, die dem Benutzer oder der Aufgabe folgen, Werkzeugumfänge, die dem maximal akzeptablen Schadensradius entsprechen, und Protokolle, die den Agenten, den Benutzer und das Ziel identifizieren.

Das Design sollte außerdem Lesen, Vorschlagen und Ausführen unterscheiden. Ein Agent, der eine Richtlinie liest und eine Antwort entwirft, sollte nicht automatisch die Berechtigung haben, die Antwort zu senden. Ein Agent, der eine Codeänderung vorschlägt, sollte sie nicht automatisch mergen. Ein Agent, der ein Kundenproblem klassifiziert, sollte nicht automatisch den Kontodatensatz verändern, es sei denn, die Aktion verfügt über eine Genehmigungsregel, eine Nachbedingungsprüfung und einen Wiederherstellungspfad.

Der Sinn der KI-Workflow-Zuverlässigkeit liegt nicht darin, jede maschinelle Aktion zu verhindern, sondern die Autorität jeder Aktion lesbar und begrenzt zu machen.

An dieser Stelle kann der integrierte Bestand von Google Cloud helfen. Cloud IAM, Dienstkonten, ressourcenbasierte Richtlinien, VPC Service Controls und Audit-Protokolle sind Cloud-Sicherheitsteams vertraut. Aber das Governance-Objekt hat sich verschoben. Der Prinzipal kann jetzt ein Agent sein, die Daten können ein Retrieval-Kontext anstelle einer direkten Datenbankabfrage sein, und der Output kann zu einer Geschäftsaktion werden. Sicherheitsteams sollten Agentenberechtigungen als Produktionsprivilegien behandeln und nicht als Einstellungen zum Schreiben von Anfragen.

Evaluierung ist ein Feature, kein Ersatz für Urteilsvermögen

Google Cloud gebührt Anerkennung dafür, die Evaluierung zu einem Teil der Plattformgeschichte zu machen. DieGen AI-Evaluierungsdienst-Übersichtbesagt, dass sie eine objektive, datengestützte Bewertung generativer KI-Modelle und Anwendungsfälle wie Modellmigration, Änderungen des Anfragewortlauts und Feinabstimmung unterstützt. Sie beschreibt adaptive Rubriken als maßgeschneiderte Bestanden/Nicht-bestanden-Tests für einzelne Anfragen, ähnlich wie Unit-Tests in der Softwareentwicklung. DieAgent Evaluierung-Dokumentationerweitert die Idee auf die Fähigkeit eines Agenten, Aufgaben und Ziele zu erfüllen.

Das ist die richtige Richtung. Unternehmen müssen aufhören, KI-Evaluierung als einmaligen Anbieterwettstreit zu behandeln. Ein regierter Workflow benötigt wiederkehrende Tests für den akzeptierten Output: Hat die Antwort die genehmigte Quelle verwendet, Rollengrenzen eingehalten, genügend Belege geliefert, bei fehlenden Daten abgelehnt, den Werkzeugaufruf abgeschlossen, eine unsichere Downstream-Formatierung vermieden, innerhalb der Latenz- und Kostenziele geblieben und einen Wiederherstellungsweg bewahrt?

Aber Evaluierungswerkzeuge schaffen keinen Wahrheitsbestand. Der Kunde muss immer noch definieren, was eine gute Antwort ausmacht, repräsentative Fälle sammeln, Grenzfälle kennzeichnen, Bestehens-/Nichtbestehensschwellen festlegen, Negativbeispiele einbeziehen, Instruction Injection testen, veraltete Daten testen, Berechtigungsfehlanpassungen testen und die Suite bei geschäftlichen Änderungen aktualisieren. Wenn ein Unternehmen nie niedergeschrieben hat, wie ein Mensch entscheidet, ob eine Zusammenfassung des Lieferantenrisikos akzeptabel ist, kann ein Modell-Evaluierungsdienst nicht die gesamte Richtlinie ableiten.

Er kann den Test operationalisieren, sobald die Organisation den Standard liefert.

Die Evaluierungskosten steigen mit dem Anspruch. Ein einfacher Zusammenfassungsvorgang benötigt vielleicht eine kleine Menge an Beispielen und manuelle Stichproben. Ein regierter Agent, der Code schreibt, ein Data Warehouse liest, einen Kunden kontaktiert oder eine Compliance-Aufzeichnung aktualisiert, benötigt tiefergehende Tests. Er benötigt aktionsspezifische Nachbedingungen, Regressionsprüfungen über Modellversionen hinweg, gegnerische Anweisungen, Kosten- und Latenzbudgets und eine menschliche Überprüfung bei unsicheren Fällen. Je wertvoller der Workflow, desto teurer die Akzeptanzbeweise.

Diese Kosten sind oft die Zahlung wert. Manuelle Überprüfung ohne Evaluierung skaliert schlecht und übersieht Drift. Ein etabliertes SaaS-Tool kann sein eigenes Modellverhalten verbergen. Ein eigener Stack kann sogar noch mehr Evaluierungsaufwand verursachen, weil jede Komponente lokal zusammengebaut wird. Der Evaluierungsdienst von Google Cloud kann die Infrastrukturarbeit reduzieren. Er beseitigt nicht die organisatorische Arbeit, zu entscheiden, was akzeptabel ist.

Audit-Protokolle verwandeln eine Blackbox in eine Aufzeichnung, aber nur, wenn aktiviert und gelesen

Prüfbarkeit ist einer der klarsten Vorteile von Google Cloud gegenüber einem eigenständigen Modellaufruf. DieAgent Platform-Audit-Protokollierungbesagt, dass Google Cloud-Dienste Audit-Protokolle schreiben, um die Frage zu beantworten, wer was, wo und wann getan hat. Admin-Aktivitätsprotokolle können nicht deaktiviert werden. Systemereignisprotokolle identifizieren automatisierte Google Cloud-Aktionen, die Ressourcen ändern, und können ebenfalls nicht deaktiviert werden. Datenzugriffsprotokolle umfassen Lese- und Schreibzugriffe auf benutzerbereitgestellte Daten, aber die Dokumentation besagt, dass sie explizit aktiviert werden müssen.

Die separate Seite zumAktivieren von Datenzugriffs-Audit-Protokollenist leicht zu übersehen und äußerst wichtig. Sie besagt, dass Kunden diese Protokolle aktivieren müssen, um Audit-Protokolle über die Nutzung von Modell-Endpunkten zu erhalten, und dass die Anzeige desdata_access-Streams den Private Logs Viewer erfordert. Die allgemeineCloud Audit Logs-Übersichtfügt hinzu, dass Datenzugriffsprotokolle außerhalb von BigQuery standardmäßig deaktiviert sind, da sie groß sein können und Gebühren verursachen können.

Dies ist ein praktischer Governance-Kompromiss. Vollständige Protokollierung schafft Nachweise, verursacht aber auch Kosten, Aufbewahrungsfragen, Zugriffskontrollfragen und Prüfarbeit. Wenn ein Team nicht die richtigen Protokolle aktiviert, kann es möglicherweise nicht rekonstruieren, welche Anfrage, welcher Endpunkt, welche Datenquelle, welche Identität oder welcher Werkzeugaufruf zu einem akzeptierten Output geführt hat. Wenn es alles ohne Routing- und Aufbewahrungsdisziplin aktiviert, kann es große Mengen sensibler Protokolle erzeugen, die nur wenige inspizieren. Prüfbarkeit ist kein anzukreuzendes Kästchen. Es ist ein Datenprodukt.

Für einen akzeptierten KI-Workflow sollte die Mindestaufzeichnung den Benutzer oder Dienst, der die Arbeit angefordert hat, die Agentenidentität, das Modell und die Version, die Retrieval-Quellen, Werkzeugaufrufe, Berechtigungsentscheidungen, das Evaluierungsergebnis oder den Prüfschritt, den endgültigen akzeptierten Output und jede nachgelagerte Aktion umfassen. Google Cloud dokumentiert mehrere Teile dieser Kette, aber die durchgängige Aufzeichnung überschreitet Produktgrenzen.

Ein Kunde benötigt möglicherweise Cloud Logging, Anwendungsprotokolle, BigQuery-Job-Metadaten, Agent Gateway-Telemetrie, Quellcodeverwaltungsaufzeichnungen, Ticket-Historien und Audit-Trails von Geschäftssystemen.

Die kommerzielle Implikation ist einfach: Einsparungen, die die Prüfüberprüfung ignorieren, sind zu hoch angesetzt. Wenn ein Modell 20 Minuten Entwurfsarbeit einspart, aber 10 Minuten Beweisprüfung erfordert, beträgt die Ersparnis beim akzeptierten Output nicht 20 Minuten. Wenn die Protokollierung einen kostspieligen Fehler verhindert, kann die Wirtschaftlichkeit immer noch ausgezeichnet sein. Die Buchhaltung muss die Prüfarbeit beinhalten.

Versionsdrift ist ein Zuverlässigkeitskostenfaktor

KI-Systeme ändern sich häufiger als traditionelle Unternehmens-Workflows. Modelle werden eingestellt, Endpunkte werden als veraltet markiert, Sicherheitsfilter ändern sich, Kontextfenster wachsen, Latenzprofile verschieben sich, Preise ändern sich und Partnermodelle erscheinen oder verschwinden. DieSeite zu Modellversionen und -lebenszyklusvon Google Cloud existiert, weil dies ein echtes betriebliches Problem ist. Sie definiert Lebenszyklusbegriffe für Gemini- und Einbettungsmodelle, liefert Daten, empfiehlt Upgrades und verweist auf Migrationspfade. Die Versionshinweise dokumentieren Produktionsaktualisierungen, Funktionen, bekannte Probleme und veraltete Funktionalität.

Die operative Frage ist nicht, ob sich etwas ändert, sondern ob die Änderung sichtbar ist, bevor sie die akzeptierte Arbeit beeinträchtigt. Eine Modellmigration, die das allgemeine Denken verbessert, kann dennoch den Ton, das Ablehnungsverhalten, das Ausgabeschema, den Zitierstil, die Token-Kosten oder die Häufigkeit von Werkzeugaufrufen verändern. Eine Grounding-Änderung kann das Retrieval für ein Corpus verbessern und für ein anderes verschlechtern. Eine Aktualisierung eines Sicherheitsfilters kann eine legitime interne Sicherheitsaufgabe blockieren. Ein Deprecation-Hinweis kann eine Migration in einem arbeitsreichen Quartal erzwingen.

Google Cloud kann helfen, indem es Lebenszyklusinformationen und Evaluierungswerkzeuge veröffentlicht. Kunden benötigen dennoch eine Migrationsdisziplin. Jeder akzeptierte Workflow sollte wo möglich einen festgelegten oder deklarierten Modellpfad, eine Regressionssuite, einen repräsentativen Datensatz, ein Änderungsfenster, eine Rückfall- oder Ausweichoption und einen Verantwortlichen haben, der die Versionshinweise verfolgt. Wenn der Workflow ein Partnermodell über Vertex AI verwendet, ist der Kunde auch vom Modelllebenszyklus und den Bedingungen dieses Partners abhängig.

Die Wahl mehrerer Modelle reduziert die Abhängigkeit von einem einzelnen Modell, kann aber den Testaufwand erhöhen.

Das ist ein Grund, warum der Nenner des akzeptierten Outputs nützlich ist. Ein einzelner Modellaufruf mag billig erscheinen. Ein regierter Workflow beinhaltet zukünftige Migrationen. Wenn der Kunde es sich nicht leisten kann, Modelländerungen zu testen, sollte er Arbeiten mit hoher Konsequenz nicht tiefgreifend automatisieren. Wenn der Workflow wertvoll genug ist, werden wiederkehrende Evaluierung und Migrationsplanung Teil der tatsächlichen Kosten des Produkts.

Kapazität und Vorfälle machen Zuverlässigkeit zu einer Designentscheidung

Google Cloud verfügt über die Infrastruktur-Größenordnung, um Unternehmens-KI zu bedienen, aber Kunden sollten Größe nicht mit unendlicher Kapazität verwechseln. Das Q1-2026-10-Q von Alphabet meldet 462,3 Milliarden US-Dollar an verbleibenden Leistungsverpflichtungen im Zusammenhang mit Google Cloud und erhebliche Investitionen in die technische Infrastruktur. Es heißt darin auch, dass die Investitionsausgaben im ersten Quartal 2026 35,7 Milliarden US-Dollar betrugen und dass Alphabet erwartete, die Investitionen in die technische Infrastruktur im Vergleich zu 2025 zu erhöhen. Diese Größenordnung signalisiert Nachfrage und Engagement.

Sie zeigt auch, dass KI-Kapazität kapitalintensiv ist.

Auf Produktebene stellt Google Cloud mehrere Verbrauchs- und Kapazitätskonzepte bereit. DieProvisioned Throughput-Übersichtbeschreibt ein Festpreis-Abonnement mit fester Laufzeit, das Durchsatz für unterstützte generative KI-Modelle nach Modell und Standort reserviert. Sie empfiehlt, die Option für Echtzeit-Produktionsanwendungen, durchgängig hochvolumige kritische Workloads, vorhersehbare Benutzererfahrung und deterministische Kosten in Betracht zu ziehen. DieQuotendokumentationlistet regionale und modellspezifische Limits, Kontingente der Agent Runtime, Evaluierungskontingente und das Batch-Verhalten auf. Sie erwähnt, dass die Gemini-Batch-Inferenz einen geteilten Pool nutzt und bei Kapazitätsdruck Arbeiten in die Warteschlange stellen kann.

Diese Details sind keine Beschaffungsnebensächlichkeiten. Sie bestimmen, ob ein Workflow zuverlässig ist. Ein Kundensupport-Agent, der von einigen internen Mitarbeitern genutzt wird, kann PayGo-Schwankungen leichter tolerieren als ein kundenorientiertes Schadensystem während der Spitzenlast. Ein nächtlicher Evaluierungsbatch kann in die Warteschlange gestellt werden, wenn das Ergebnis morgen benötigt wird, aber nicht, wenn es eine Bereitstellung innerhalb derselben Stunde verhindert. Ein Workflow mit strengem Latenzziel benötigt möglicherweise Provisioned Throughput oder einen Fallback-Pfad.

Deterministische Kosten können genauso wichtig sein wie deterministische Latenz, da modellgestützte Arbeit Token-, Retrieval-, Protokollierungs- und Prüfkosten verursachen kann, die während eines Piloten schwer vorherzusagen sind.

Statusvorfälle verdeutlichen denselben Punkt. Am 27. Februar 2026 meldete Google Cloud einenVertex AI Gemini API-Vorfall, der 1 Stunde und 58 Minuten dauerte und den globalen Endpunkt sowie US-Regionen betraf. Als Grundursache wurde eine Konfigurationsänderung an einem Sicherheitsfilterdienst gemeldet, der Gemini-Modelle unterstützt, was zu Überlastungsfehlern führte; die Behebung umfasste Rollback, hinzugefügte Kapazität, verstärkte Validierungs-Checkpoints und verbesserte Alarmierung. Am 18. Juli 2025 betraf einMulti-Produkt-Vorfall in us-east1Produkte wie Cloud Run, Cloud Workflows, BigQuery, IAM, Cloud Monitoring, Vertex AI Online Prediction und VPC nach einem Problem mit einem Hardware-Workflow/Control-Plane.

Diese Vorfälle beweisen nicht, dass Google Cloud ungewöhnlich unzuverlässig ist. Sie beweisen, dass regierte KI-Workflows von gemeinsam genutzten Diensten abhängen: Modell-APIs, Sicherheitsfilter, Regionen, Netzwerke, IAM, Überwachung, Orchestrierung und Datenplattformen. Ein belastbarer Workflow benötigt eine Regel für veraltete Daten, eine Wiederholungsregel, ein Fallback-Modell oder eine Warteschlange, eine Nachricht für den eingeschränkten Betrieb, einen manuellen Weg für dringende Arbeiten und eine Möglichkeit, Plattformausfälle von Modellausfällen zu unterscheiden.

Das Modell kann leistungsfähig sein, während der Endpunkt ratenbegrenzt ist. Die Daten können korrekt sein, während der Workflow-Runner ausfällt. Der Agent kann fehlerfrei sein, während IAM- oder Netzwerkpfade beeinträchtigt sind.

Zuverlässigkeit ist daher teilweise eine Produkteigenschaft und teilweise eine Architekturentscheidung. Google Cloud bietet SLAs und Kapazitätsoptionen. Der Kunde entscheidet immer noch, welche Aufgaben reservierten Durchsatz, Multi-Region-Design, manuelles Fallback oder geringere Automatisierung verdienen.

Rückrollen ist für Compute einfacher als für akzeptierte Geschäftszustände

Google Cloud verfügt über ausgereifte Bereitstellungskontrollen für die Software-Infrastruktur.Cloud Runermöglicht es Teams, Traffic aufzuteilen, eine Revision schrittweise auszurollen und auf eine vorherige Revision zurückzurollen. Die Dokumentation warnt auch, dass Traffic-Änderungen nicht sofort wirksam werden und laufende Anfragen während des Übergangs fortbestehen.Workflowsunterstützt try-, retry- und Ausnahmebehandlungsstrukturen.

Das sind nützliche Kontrollen für KI-Anwendungen. Ein Team kann einen neuen Agentendienst mit einem geringen Traffic-Anteil bereitstellen, Fehler überwachen und den Container zurückrollen, wenn er sich schlecht verhält. Es kann vorübergehende HTTP-Fehler abfangen, ausgewählte Aufrufe wiederholen und zu einem Ausnahmepfad verzweigen. Es kann einen fehlgeschlagenen Workflow in ein Ticket umleiten, anstatt so zu tun, als sei die Aktion abgeschlossen.

Aber das geschäftliche Rückrollen ist schwieriger als das Rückrollen der Infrastruktur. Wenn ein Agent eine Antwort entwirft und ein Mensch sie nicht gesendet hat, ist das Rollback einfach: den Entwurf verwerfen. Wenn ein Agent ein CRM-Feld aktualisiert, ein Compliance-Formular einreicht, eine Richtlinie ändert, eine Nachricht sendet, eine Rückerstattung genehmigt, einen Support-Fall eröffnet oder Code merged, lebt die Nebenwirkung außerhalb des Modell-Endpunkts. Das Zurückrollen einer Cloud Run-Revision sendet die Nachricht nicht zurück oder stellt das alte Kundenverständnis wieder her.

Eine Wiederholung kann einen vorübergehenden Fehler verschlimmern, wenn die nachgelagerte Aktion nicht idempotent ist.

Hier wird der Test des akzeptierten Outputs streng. Jede Aktionsklasse benötigt eine Nachbedingung und einen Wiederherstellungspfad. Ein Codeänderungs-Workflow benötigt Quellcodeverwaltungsnachweise, Tests, Bereitstellungs-Rollback und Problemverantwortlichkeit. Ein Datenergebnis-Workflow benötigt Abfrageherkunft, Datensatzversion, Datenqualitätsprüfungen und Korrekturverfahren. Ein Kundenaktions-Workflow benötigt Genehmigungsschwellen und eine Möglichkeit, den Kunden zu benachrichtigen, wenn sich eine akzeptierte Antwort später als falsch herausstellt.

Ein Sicherheits- oder Betriebs-Workflow benötigt eine menschliche Übersteuerung und einen Weg, eine falsche Blockierung zu entfernen.

Google Cloud kann viele Low-Level-Kontrollen bereitstellen, aber es kann nicht die geschäftliche Umkehrung des Kunden definieren. Eine Plattform kann es dem Kunden ermöglichen, die Wiederholung zu erstellen; sie kann nicht wissen, ob das Wiederholen der Aktion sicher ist. Eine Plattform kann die Anfrage protokollieren; sie kann nicht garantieren, dass das nachgelagerte System den beabsichtigten Zustand erreicht hat, es sei denn, der Workflow prüft das Ziel. Die Last verlagert sich auf das Design.

Kundenberichte zeigen Akzeptanz, aber keine universelle Antwort

Die Kundenberichte von Google Cloud sind nützliche Marktsignale, weil sie die Arten von Workflows zeigen, die Käufer versuchen. Sie sollten nicht als unabhängige Benchmarks gelesen werden.

FletcherTechberichtete, Gemini Enterprise in drei Wochen für Kerndaten implementiert zu haben, 31.778 Antworten an 222 Mitarbeiter über drei Monate geliefert und mehr als 2.500 Stunden eingespart zu haben. Die Geschichte nennt Datenkonnektoren, Jira, ServiceNow, SharePoint, benutzerdefinierte KI-Assistenten und ein dediziertes Google Cloud-Projekt für Ressourcen-, Zugriffs- und Kosten-Governance. Das ist nah am Thema des akzeptierten Outputs: Der Wert liegt nicht nur im Assistenten, sondern in der Integration in die täglichen Systeme und Kontrollen.

Fifth Dimensionberichtete, Vertex AI zu nutzen, um Gemini- und Claude-Inferenzen für dokumentenintensive gewerbliche Immobilien-Workflows zu zentralisieren, mit Cloud SQL, Cloud Storage, Cloud Run und BigQuery im Stack. Die Geschichte beschreibt lang laufende Workflows und ein berichtetes Zuverlässigkeitsziel von 99,9 %. Es ist ein nützliches Beispiel für Google Cloud als Multi-Modell-Workflow-Plattform und nicht als reine Gemini-Umgebung.

Replitberichtete, Claude auf Vertex AI, Gemini, Cloud Run, Compute Engine, Cloud SQL und BigQuery zu nutzen, um KI-unterstützte Softwareerstellung und -bereitstellung zu unterstützen. Die Geschichte besagt, dass Replit mehr als 35 Millionen Entwickler und mehr als 100.000 Anwendungen über Cloud Run unterstützt. Auch hier ist die Lehre architektonisch: Der Agent ist mit Bereitstellung, Daten und Infrastruktur verbunden.

Die Grenzen sind ebenso wichtig. Diese Geschichten geben keine vollständigen Ausnahmeraten, falsche akzeptierte Outputs, Minuten menschlicher Überprüfung, Rollback-Zeit, Migrationsarbeit, fehlgeschlagene Anfragen, Kosten für die Datenbereinigung oder das preis, was passierte, als ein Endpunkt degradierte. Sie sind nicht nutzlos, weil sie werblich sind; sie sind nützlich, wenn sie als Akzeptanzbelege gelesen werden. Sie zeigen, dass Kunden echte Arbeit auf KI-Oberflächen von Google Cloud verlagern. Sie beweisen nicht, dass jedes Unternehmen nach Berücksichtigung der Überwachungs- und Integrationskosten Geld spart.

Der kommerzielle Fall hängt von der Reduzierung der Gesamtarbeit ab

Der kommerzielle Fall von Google Cloud ist am stärksten, wenn die Aufgabe wiederholt wird, evidenzreich, berechtigungsbegrenzt und teuer genug ist, dass bessere Werkzeuge die manuelle Arbeit übertreffen. Gute Kandidaten sind interne Wissensantworten, die auf genehmigten Quellen basieren, Codeänderungen im ersten Entwurf mit Tests und Überprüfung, datenschwere Dokumentenextraktion, Support-Triage, Sicherheitsanreicherung, regierte Analytik und Workflow-Routing, bei dem ein akzeptierter Output überprüft werden kann, bevor er die Außenwelt verändert.

Der Fall wird schwächer, wenn die Aufgabe selten, mehrdeutig, mit hoher Haftung, schlecht dokumentiert, über unzugängliche Systeme verstreut oder von implizitem menschlichem Urteilsvermögen abhängig ist. In diesen Fällen kann das Modell dennoch beim Entwerfen oder Recherchieren helfen, aber der akzeptierte Workflow bleibt möglicherweise größtenteils menschlich. Weniger Automatisierung zu betreiben kann rational sein. Ein Unternehmen benötigt keinen autonomen Agenten für eine Aufgabe, die zweimal im Monat anfällt und schwerwiegende Folgen hat, wenn sie falsch ausgeführt wird.

Die Alternativen sind breit gefächert. Manuelle Arbeit hat eine geringe Plattformabhängigkeit, aber hohe Arbeitskosten und inkonsistente Beweise. Etablierte SaaS-KI hat möglicherweise eine bessere Domänenintegration, aber eine schwächere systemübergreifende Governance oder Modellauswahl. Ein anderer Cloud-/Modellanbieter bietet möglicherweise eine bessere Modellleistung oder ein besseres Ökosystem, erfordert aber eine andere Daten- und Identitätsintegration. Open Source kann die Anbieterbindung verringern und die Kontrolle verbessern, erhöht aber gleichzeitig den Aufwand für Hosting, Sicherheit, Evaluierung und Betrieb.

Ein eigener Stack kann maßgeschneidert werden, erfordert aber knappes Plattform-Engineering. Das Angebot von Google Cloud lautet, dass die integrierte KI-, Daten-, Identitäts-, Bereitstellungs- und Protokollierungsoberfläche die Kosten des Mittelwegs senkt.

Wechselkosten sollten von Anfang an einkalkuliert werden. Wenn ein Kunde Datenspeicher, Evaluierungssuiten, IAM-Rollen, Cloud Run-Dienste, Workflows, BigQuery-Herkunft, Audit-Routen, Dashboards und Support-Prozesse rund um Google Cloud aufbaut, gewinnt er Kohärenz, verliert aber Portabilität. Ein Konkurrenzmodell kann über Vertex AI oder einen separaten Anbieter aufrufbar sein, aber das System des akzeptierten Outputs ist mehr als ein Modell. Es umfasst Protokolle, Berechtigungen, Evaluatoren, Datenverträge und Bereitstellungsmuster.

Das ist kein Grund, Google Cloud zu meiden. Es ist ein Grund, Ausstiegsspuren zu entwerfen. Speichern Sie Evaluierungsdatensätze in portablen Formaten. Halten Sie Geschäftsregeln nach Möglichkeit außerhalb von Freitext-Anweisungen. Trennen Sie Modelladapter von der Workflow-Logik. Verfolgen Sie Quelldokumente und Ausgabeschemata. Machen Sie Audit-Aufzeichnungen außerhalb einer einzelnen Konsole lesbar. Das beste Kundenergebnis ist nicht null Bindung, sondern genügend Modularität, damit Google Cloud die Arbeitslast verdient, indem es die Arbeit reduziert, nicht indem es den Prozess einsperrt.

Was ein ernsthafter Käufer fragen sollte

Die Kaufentscheidungsfrage sollte als Betriebstest formuliert werden. Für eine wiederholte Aufgabe: Was ist der akzeptierte Output, wer akzeptiert ihn, welche Beweise sind erforderlich, welche Daten dürfen verwendet werden, welche Aktion kann folgen und was passiert, wenn sie falsch ist? Diese Aussage sollte der Plattformentscheidung vorausgehen.

Speziell für Google Cloud sollte ein Käufer fragen, ob der Workflow die mitarbeiterorientierte Assistentenerfahrung von Gemini Enterprise, die Erstellungs- und Regierungsoberfläche der Agent Platform, das Grounding mit Agent Search, die BigQuery-Governance, die Bereitstellung mit Cloud Run, die Orchestrierung mit Workflows oder all dies benötigt. Alle Teile ohne eine Aufgabendefinition zu kaufen, schafft ein Plattformprogramm, keinen zuverlässigen Workflow. Zu wenig zu kaufen, schafft eine Modell-Demo, die nicht regiert werden kann.

Der Käufer sollte auch fragen, welche Datenzugriffsprotokolle aktiviert werden, wer sie einsehen kann, wo sie aufbewahrt werden und welcher Überprüfungsprozess Protokolle in Überwachung umwandelt. Es sollte entschieden werden, welche Aktionen eine menschliche Genehmigung erfordern, welche automatisch ausgeführt werden können und welche niemals delegiert werden sollten. Es sollte ein Modellmigrationsplan festgelegt werden, bevor sich die erste Modellversion ändert. Es sollten Quoten- und Durchsatzregeln definiert werden, bevor aus einem erfolgreichen Piloten ein stark genutztes Produkt wird.

Es sollte ein Fallback für Endpunktfehler und veraltete Retrieval-Ergebnisse geschrieben werden. Es sollte Instruction Injection und unsichere Ausgabebehandlung getestet werden, da die Liste der LLM-Risiken von OWASP für Systeme nicht theoretisch ist, die Modellausgaben an Werkzeuge weitergeben.

Schließlich sollte der Käufer den menschlichen Nenner sichtbar halten. Wie viele akzeptierte Outputs pro Woche werden erwartet? Wie viele werden abgelehnt? Wie lange dauert die Überprüfung? Wie oft bittet der Agent um Klärung? Wie viele Outputs müssen nach der Annahme korrigiert werden? Wie oft aktualisieren Datenbesitzer das Corpus? Wie viele Ingenieurstunden fließen in die Modellmigration und Protokollierung? Wenn diese Zahlen nicht erfasst werden, wird die Organisation Begeisterung anstelle von Produktivität messen.

Google Cloud bietet Unternehmen eine ernsthafte Kontrolloberfläche für regierte KI-Workflows. Es verfügt über die Modelle, den Datenbestand, die Identitätsmaschinerie, die Bereitstellungsschicht, die Protokolle, den Evaluierungsdienst und die kommerzielle Größenordnung. Der ungelöste Test ist, ob Kunden diese Teile nutzen können, um die Gesamtarbeit zu reduzieren, wenn die Überwachung eingerechnet wird. Der Gewinner ist nicht die Plattform, die in einer Demo am schnellsten antwortet, sondern diejenige, deren akzeptierte Outputs nach dem hundertsten gewöhnlichen Lauf nützlich, erklärbar, berechtigungskorrekt und wiederherstellbar bleiben.