Databricks plus GPT-5.5 macht Agent-Standort zur Datengravitations-Frage

Databricks hat GPT-5.5 direkt in Enterprise-Agent-Workflows eingebettet, und GPT-5.5 hält aktuell den State-of-the-Art auf dem OfficeQA Pro Benchmark. Für die meisten CTOs klingt das nach einem Model-Upgrade. Ist es nicht — es ist ein Forcing Function dafür, wo deine Agents relativ zu deinen Daten laufen. Und das Fenster, diese Entscheidung günstig zu treffen, schließt sich gerade.

Was sich geändert hat

OpenAI und Databricks haben angekündigt, dass GPT-5.5 jetzt nativ in Databricks' Enterprise-Agent-Workflows verfügbar ist. Die Integration bedeutet: Teams, die bereits auf dem Databricks Lakehouse arbeiten, können GPT-5.5 direkt auf ihre bestehenden Catalogs, Governance-Regeln und Compute-Ressourcen richten — ohne Daten in eine separate Agent-Plattform zu exportieren. GPT-5.5 hat die Spitzenposition auf dem OfficeQA Pro Benchmark erreicht, einem Test, der die dokumentenintensive, mehrstufige Reasoning-Arbeit abbildet, die Enterprise-Back-Office-Agents kennzeichnet — Vertragsüberprüfung, Finanzanalyse, systemübergreifende Lookups.

Das praktische Ergebnis: Ein Databricks-Kunde kann jetzt ein Reasoning-Grade-Modell innerhalb desselben Security-Perimeters wie seine Delta Tables und Unity Catalog-Policies betreiben. Bisher bedeutete die Anbindung eines leistungsfähigen Frontier-Modells an Enterprise-Daten entweder Data-Egress zu einer externen API oder den Aufbau erheblicher Middleware, um Governance an der Grenze durchzusetzen. Diese Middleware-Kosten — in Engineering-Zeit, Latency und Audit-Oberfläche — waren oft das versteckte Argument gegen Enterprise-Agent-Adoption.

Das hier ist kein Research-Preview. Databricks hat eine große Installed Base bei Unternehmen mit 200 bis 2.000 FTE, und diese Unternehmen haben typischerweise bereits strukturierte und semi-strukturierte Daten auf der Plattform. GPT-5.5's Benchmark-Performance bedeutet, dass das Modell die Reasoning-Komplexität dieser Use Cases tatsächlich bewältigen kann — nicht nur simples Retrieval.

Warum das die Build-vs-Buy-Entscheidung für deinen Stack neu rahmt

Die klassische Enterprise-Agent-Architekturdebatte hat drei Positionen: einen Custom-Agent-Stack auf rohen APIs bauen, ein vertikales SaaS-Agent-Tool kaufen, oder ein allgemeines Orchestrierungs-Framework wie LangChain oder CrewAI vor die eigene Infrastruktur setzen. All das setzt voraus, dass die Agent-Schicht von der Datenschicht getrennt ist — verbunden durch Retrieval-Pipelines, die du selbst betreibst und pflegst.

Die Databricks/GPT-5.5-Integration bricht diese Annahme. Wenn deine Daten bereits in Databricks leben, eliminiert das native Ausführen von Agents in dieser Umgebung eine Retrieval-Pipeline, eine Governance-Enforcement-Schicht und eine separate Compute-Rechnung. Der architektonische Gewinn liegt nicht allein in der Modellqualität — er liegt darin, dass das Modell dort läuft, wo die Daten sind. Das beseitigt die Latency- und Compliance-Overhead, die Enterprise-Agent-Projekte in der Produktion töten. Datengravitation — das Prinzip, dass Compute sich zu den Daten bewegt, nicht umgekehrt — gilt jetzt direkt für Agent-Orchestrierung.

Das Risiko ist symmetrisch. Wenn du einen Agent-Stack außerhalb von Databricks gebaut hast oder gerade baust, während dein Data Warehouse darin sitzt, hast du jetzt einen schwieriger zu gewinnenden Vergleich vor dir. Der Standalone-Stack muss für deinen spezifischen Use Case deutlich besser sein, günstiger at Scale, oder flexibler auf eine Art, die du konkret benennen kannst. "Wir besitzen die Architektur" ist keine ausreichende Begründung, wenn die Kosten dieses Besitzes kontinuierlichen ETL-Overhead und eine Governance-Lücke umfassen. CTOs, die diese Entscheidung vor 18 Monaten getroffen haben — bevor ein Modell dieser Reasoning-Güte nativ auf der Plattform verfügbar war — sollten die Rechnung neu aufmachen.

Es gibt legitime Gründe, off-platform zu bleiben: Multi-Cloud-Neutralitätsanforderungen, Use Cases, die mehrere Datenspeicher umspannen, die nicht in Databricks konsolidiert sind, oder Agent-Komplexität, die Orchestrierungs-Primitives erfordert, die Databricks noch nicht exponieret. Aber diese Gründe müssen explizit in deinen Architektur-Docs stehen — nicht implizit bleiben.

Was du am Montagmorgen tun solltest

Der Entscheidungsbaum hier hat fünf Inputs. Arbeite sie durch, bevor dein nächstes Infrastruktur-Review ansteht.

• Datenlage: Wie viel Prozent der Daten, die deine Agents brauchen, liegen bereits in Databricks? Wenn es über 70 % sind, verdient der native Weg eine formale Evaluation — keine beiläufige Ablehnung.
• Bestehende Databricks-Ausgaben: Zahlst du bereits für einen Databricks-Tier, der Agent-Tooling einschließt? Wenn ja, können die Grenzkosten des nativen Wegs niedriger sein als die kombinierten API- und Infrastrukturkosten deines aktuellen Standalone-Stacks.
• Governance-Posture: Verlangt dein Security- oder Compliance-Team, dass Model-Inference innerhalb einer bestimmten Datengrenze bleibt? Native-in-Platform ist oft der kürzeste Weg, diese Anforderung zu erfüllen.
• Agent-Komplexität: Betreiben deine Agents mehrstufiges Reasoning über strukturierte Enterprise-Daten, oder einfaches RAG auf Dokumenten? GPT-5.5's OfficeQA Pro-Performance ist vor allem für ersteres relevant.
• Team-Ownership: Wer besitzt aktuell deinen Agent-Stack? Wenn es ein kleines Data-Engineering-Team ist, das bereits Databricks betreibt, reduziert Konsolidierung deren operationale Oberfläche. Wenn es ein Product-Team ist, das differenzierte Logik baut, braucht es womöglich die Flexibilität eines Standalone-Orchestrierungs-Layers.

Wenn deine Antworten Richtung Konsolidierung zeigen, mach einen 2-Wochen-Proof-of-Concept auf einem bestehenden Agent-Use-Case — nimm etwas aus der Produktion mit messbaren Latency- und Cost-Baselines. Du brauchst echte Zahlen, keine Benchmark-Extrapolationen, bevor du dich auf eine Migration festlegst.

Was es kostet und was es einspart

Die Kosten des nativen Wegs sind Plattformabhängigkeit. Databricks ist keine neutrale Infrastruktur-Schicht — die Plattform hat Pricing Power, und das Konsolidieren deines Agent-Compute dort erhöht deine Exponierung gegenüber zukünftigen Preisänderungen. Du akzeptierst auch die Orchestrierungs-Primitives der Plattform, die bei Features wie komplexer Multi-Agent-Koordination hinter Open-Source-Frameworks zurückliegen können. Für Teams, die erhebliches internes Tooling auf LangGraph oder Ähnlichem aufgebaut haben, ist der Migrationskost echter Engineering-Aufwand — wahrscheinlich 4 bis 8 Wochen für eine nicht-triviale Agent-Oberfläche.

Das Einsparpotenzial ist weniger abstrakt. Das Entfernen einer Retrieval-Pipeline zwischen Agent-Schicht und Datenschicht reduziert typischerweise die p95-Latency messbar bei datenintensiven Queries. Governance-Enforcement auf der Daten-Schicht statt an der API-Grenze verkleinert die Audit-Oberfläche, die dein Security-Team pflegen muss. Und wenn du aktuell einen separaten Vector Store und eine Embedding-Pipeline für Enterprise-Retrieval betreibst, kann der native Lakehouse-Ansatz diese Infrastruktur vollständig kollabieren lassen. Für ein Unternehmen mit 3 oder 4 aktiven Agent-Workflows und einem moderaten Databricks-Footprint können die jährlichen Infrastruktur-Einsparungen die Migrationskosten innerhalb eines einzigen Quartals rechtfertigen — aber diese Rechnung hängt vollständig von den tatsächlichen Kosten deines aktuellen Stacks ab, die die meisten Teams noch nicht vollständig erfasst haben.