Sporttechnologie und Daten: Wer kontrolliert den Zugang

Die Sporttechnologie verkauft seit Jahren dasselbe Versprechen: mehr Daten, schnellere Antworten, klügere Entscheidungen. Die Marktforschungsschlagzeilen, die jede Woche auf den Tisch kommen, stützen sich auf Wachstumsraten und Abkürzungen. Die technische Realität ist unordentlicher. Zwei Dokumente im dieswöchigen Stapel sollte man zusammen lesen. Sie beschreiben gegensätzliche Wege, einem KI-Agenten die Zahlen zu füttern, auf denen Sportorganisationen zunehmend zu arbeiten behaupten.

Starburst veröffentlichte am 11. September eine Analyse zweier Architekturen für agentische Datenanalyse. Der Beitrag ist für Unternehmensdatenteams geschrieben, nicht für Vereine oder Ligen. Das verwendete Beispiel ist bewusst alltäglich: Ein Lebensmittelgeschäft fragt, ob die Eierwerbeaktion der letzten Woche profitabel war. Um das zu beantworten, muss man wissen, ob die Aktion Kunden brachte, die sonst nicht gekommen wären, ob neue Kunden wiederkamen, was sonst in derselben Transaktion gekauft wurde, wo diese Artikel im Laden stehen und wie profitabel sie sind. Das ist eine Kette von Folgefragen über mehr als einen Datensatz. Dieselbe Problemform hat eine Sportorganisation, wenn sie fragt, warum eine Sponsoringkampagne den Ticketverkauf bewegt hat.

Option 0: die Daten zum Modell schicken

Der erste Ansatz, von Starburst Option 0 genannt, besteht darin, die relevanten Tabellen zu extrahieren und die Rohdaten als Datei oder direkte Leitung an den Agenten zu senden, der dann selbst verarbeitet. Das Unternehmen ist deutlich bei den Abwägungen. Terabytes an einen Agenten zu senden, kann unbezahlbar teuer werden, wenn der Agent pro empfangener oder verarbeiteter Dateneinheit abrechnet. Starburst sagt, die Leistungsnachteile verringern die Praktikabilität dieser Option so stark, dass sie keine gute ist. Deshalb trägt sie die Bezeichnung Option 0 und nicht Option 1.

Für Sportteams ist die Rechnung ohnehin unattraktiv. Ein einzelnes Spiel erzeugt heute Trackingdaten, aus Videos abgeleitete Ereignisse, Ticketing-Datensätze, Merchandise-Transaktionen und App-Telemetrie. Die Zahl der Menschen, die Fragen dazu stellen, ist klein. Pro Zeile zu zahlen, um das in ein Modell zu bewegen, ist keine Budgetposition, die die meisten Analyseabteilungen verteidigen können.

Der zweite Ansatz ist der, den Starburst empfiehlt. Man gibt dem Agenten direkten Zugang zum Datenbanksystem und lässt ihn sein eigenes SQL schreiben, wobei er iteriert, während er seinen Fokus verfeinert. Die Datenbank-Engine tut, wofür sie gebaut ist, und verarbeitet lokale Daten mit optimierten Abfrageplänen. Der Agent überwacht und sendet aufeinanderfolgende oder parallele Anfragen, bis er etwas zurückgeben kann. Starburst räumt den bekannten Nachteil ein: Agenten können weit anspruchsvoller sein als Menschen und eine Datenbank mit spekulativen Abfragen überlasten, während sie arbeiten.

Die Datenbankbranche konzentriert sich künftig mit aller Kraft darauf, agentische Arbeitslasten zu unterstützen, und moderne Datenbanksysteme sind zunehmend in der Lage, diese Art skalierbarer Datenverarbeitung effizient zu bewältigen.

Das ist das Argument in einem Satz, und es ist ebenso ein Verkaufsargument wie ein technisches. Starburst verkauft Datenbanksysteme. Dennoch ist der Punkt, wo die Optimierung liegt, schwer zu bestreiten: Agenten werden besser, aber sie werden nicht so bald Terabytes strukturierter Daten so effizient verarbeiten wie Engines, die auf Jahrzehnten der Abfrageforschung aufbauen.

Wie die Werkzeuge tatsächlich aussehen

Zwei Open-Source-Projekte im dieswöchigen Stapel zeigen, wie die Leitungen am kleineren Ende zusammengesetzt werden. Adaca Analytics, am 8. September auf GitHub unter der MIT-Lizenz veröffentlicht, baut die alten Google-Analytics-Dashboards auf GA4-Daten nach. Tägliche Rollups aus der GA4 Data API oder einem BigQuery-Export landen in einer D1-Datenbank, die der Betreiber besitzt, während Echtzeitdaten live bei Google bleiben. Sechs Dashboards sind ab Werk dabei, jede Zahl öffnet eine Detailseite mit eigenem Trend und Aufschlüsselungen, und das Ganze läuft auf Cloudflare Workers hinter Cloudflare Access oder integrierter Basic Auth. Eine Anmeldung gibt es nicht.

Plainoldanalytics, am 13. September auf GitHub veröffentlicht, geht den umgekehrten Weg: aufgesetzte Webanalytik, eingebettet in eine Go-Anwendung. Es ist speicherunabhängig, sodass das Importieren des Kernpakets nie ein Backend mitzieht, und es gibt Adapter für gin und chi. Der Verkehr wird etwa einmal pro Sekunde auf die Festplatte geschrieben. Betreiber können Schlüssel- und Werteigenschaften pro Anfrage setzen, Routen von der Protokollierung ausschließen oder wörtliche Routenpfade statt Pfadparameter aufzeichnen.

Keines der Projekte ist ein Sportprodukt. Beide sind relevant, weil sie zeigen, wie sich die Standardannahme verschiebt: Die Daten bleiben dort, wo der Betreiber sie abgelegt hat, und die Analysesicht ist etwas, das man betreibt, statt etwas, das man mietet.

Die Datenschutzfrage, die niemand benchmarkt

DataZen, ein lokal-first Datenbankclient, am 29. August auf Hacker News veröffentlicht, benennt das Problem direkt: Wohin gehen meine Daten? Das Werkzeug erscheint unter GPLv3, verlangt kein Konto und unterstützt standardmäßig PostgreSQL, MySQL, SQLite und Redis, mit optionalen Treibern für MongoDB, ClickHouse, DuckDB und SQL Server. Es enthält einen integrierten MCP-Server, damit Agenten wie Claude, Cursor und Cline Datenbanken über das Model Context Protocol abfragen können, und es kann auch als MCP-Client fungieren. Anmeldedaten werden mit AES-256-GCM im Schlüsselbund des Betriebssystems verschlüsselt. Das Projekt sagt, dass nur Schema- und Abfragekontext mit dem vom Nutzer konfigurierten KI-Anbieter geteilt werden.

Diese letzte Unterscheidung ist die, nach der Sportorganisationen fragen sollten. Schema- und Abfragekontext ist nicht dasselbe wie Rohdaten, aber auch nicht nichts. Ein Schema verrät, was ein Verein misst: welche Fanattribute er speichert, wie er Ticketkäufer segmentiert, was er über die Belastung von Spielern erfasst. In einem Sport, in dem Verletzungsdaten und Vertragsverhandlungen im selben Bestand wie das Ticketing liegen, sind die Metadaten für sich genommen kommerziell sensibel.

Das Dossier sagt uns nicht, was ein Verein oder eine Liga tatsächlich eingesetzt hat. Das Verkaufsmaterial hinter den Marktprognosen ist kein Beleg für Akzeptanz. Was es zeigt, ist eine Spaltung. Ein Lager argumentiert, dass Agenten die Datenbank steuern sollten und moderne Engines die Last aufnehmen können. Das andere baut Werkzeuge, die die Daten lokal halten und nur Kontext nach außen senden. Die Sporttechnologie wird die Antwort erben, für die sich ihre Datenteams entscheiden. Die Entscheidung fällt jetzt, in Open-Source-Repositories statt in Pressemitteilungen.