Wie das zentrale Athletia Company Brain konkret entsteht: 12 Schritte in 4 Phasen, jeder mit Owner und Ergebnis. Kein Big Bang, jede Phase liefert etwas Nutzbares, und am Ende jeder Phase kann man ehrlich entscheiden, ob es weitergeht.
Die Reihenfolge ist der Kern dieses Plans. Das Company Brain wird zuerst rein intern gebaut und genutzt (null Kundenrisiko), erst dann fließen Ergebnisse kontrolliert Richtung Kunde. Und: PeakDiver liefert schon heute ein sauberes Datenmodell je Post (Brand, Club, Wettbewerb, Plattform, Format, owned/earned, Mediawert). Wir erfinden keine Datenwelt, wir machen die vorhandene abfragbar und generierfähig.
Die ersten Nutzer des Brains sind Athletia-Mitarbeiter, nicht Kunden. Interner Copilot und Entwurfs-Agenten dürfen Fehler machen, ein Mensch prüft alles, bevor es je einen Kunden erreicht.
Alle PeakDiver-Daten in einem zentralen Datenraum (nur Athletia-intern). Kundenspezifisches (CI, Historie) liegt getrennt je Kunde. Nach außen fließen nur anonymisierte Aggregate.
Nach jeder Phase ein Ausstiegstor mit Messung. Weitergebaut wird, weil die Zahlen es tragen, nicht weil der Plan es vorsieht.
Ein Tag mit Lukas, Johannes, Flo und dem Dev. Ergebnis: Zielbild bestätigt, Pilot-Kunde gewählt, Erfolgsmaße festgelegt (Zeit pro Report und Deck vorher/nachher, Stückzahl, Qualitätsurteil des Teams). Die Frageliste unten ist die Agenda.
HIL moderiertAthletia entscheidet
Ergebnis: beschlossener Scope auf einer Seite.
Wo liegen die PeakDiver-Daten physisch (Datenbank, Hosting, gibt es eine interne API)? Wie groß ist der Pool, wie oft aktualisiert er sich, wer kann einen Read-only-Zugang bereitstellen? Eine halbe Stunde mit dem Dev klärt, wie der Connector in Schritt 5 gebaut wird.
Athletia-DevHIL fragt strukturiert ab
Ergebnis: Zugangsweg + Datenvolumen schwarz auf weiß.
Drei Fragen an Datenschutzbeauftragten bzw. Kanzlei: (a) Was darf zentral gepoolt werden, was sagen die Bestandsverträge? (b) Stecken personenbezogene Daten in den Posts (Kommentare, Nutzernamen) und wie gehen wir damit um? (c) AVV und Zero-Retention mit dem Modell-Anbieter. Läuft parallel, blockiert Phase 1 nicht, muss aber vor Phase 3 grün sein.
Athletia + DSB/KanzleiHIL liefert die Fragenliste
Ergebnis: Ampel je Datenkategorie, To-do-Liste für Vertragsklauseln.
Postgres in der EU (Start: Neon oder RDS Frankfurt), ein Schema für den zentralen Pool (Posts, Kanäle, Marken, KPIs, Zeitreihen), pgvector für Embeddings im selben Haus, Objekt-Storage (S3/R2) für Assets und spätere Exporte. Alles als Code (Infrastruktur reproduzierbar), Zugriff nur über Service-Accounts mit Audit-Log.
HIL bautAthletia-Dev baut mit
Ergebnis: leerer, sauber strukturierter Datenraum in der EU.
Ein täglicher Sync-Job (read-only) aus der PeakDiver-Quelle in den Pool, gekapselt als MCP-Server: eine Schnittstelle, die später jeder Agent als Werkzeug nutzt. Erster Testlauf mit dem Showcase-Datensatz (192k Posts), dann der echte Pool. PeakDiver selbst wird nicht angefasst.
HIL bautAthletia-Dev gibt Zugang + Review
Ergebnis: der Pool füllt sich automatisch, täglich.
Ein einziger Dienst vor allen LLM-Aufrufen: EU-Verarbeitung mit AVV und Zero-Retention, Modellwahl je Aufgabe (großes Modell für Argumentation, kleines für Klassifikation), Kosten-Limits und Logging pro Anwendungsfall. Kein Agent ruft je ein Modell direkt auf.
HIL baut
Ergebnis: kontrollierter, bezahlbarer, auditierbarer Modell-Zugang.
Was das Brain außer Zahlen wissen muss: Athletia-Playbooks und Prozesswissen, Report- und Deck-Vorlagen, CI-Assets je Kunde (Logos, Farben, Tonalität), die Best-Case-Datenbank (~3.700 kuratierte Posts) als durchsuchbare Inspirationsquelle. Eingelesen, verschlagwortet, embedded.
HIL baut PipelineAthletia liefert Material
Ergebnis: das Brain kennt Zahlen UND Kontext.
Chat auf dem Pool, nur für Athletia-Mitarbeiter: "Wie hat Adidas über alle Kanäle in der Rückrunde performt?" oder "Top-10-Reels nach Engagement-Rate für Kunde X". Antworten immer mit Datenbeleg. Das ist der PeakDiver Copilot aus Flos Liste, bewusst zuerst intern: hier darf er reifen, ohne Kundenvertrauen zu riskieren.
HIL bautAthletia-Team testet täglich
Ergebnis: Datenabfragen in Sekunden statt Filter-Klickstrecken.
Erzeugt die Monats-Insights für den Pilot-Kunden als fertigen Entwurf im Kunden-CI: Kennzahlen, Write-up, Auffälligkeiten, Empfehlungen. Das Team, das die Mail heute in ~2 Stunden von Hand baut, wird zur QA-Instanz und misst: Wie lange dauert es jetzt, wie gut ist es?
HIL bautReport-Team prüft jede Ausgabe
Ergebnis: der erste messbare Vorher-nachher-Beweis.
Sponsoring-Argumentation auf Knopfdruck: Brand-Reichweiten aus der Logo-Erkennung, Zielgruppen-Fit, Forecast (andockend an die bestehende Campaign Calculation), als Deck-Entwurf im CI (HTML zu PDF/PPTX). Dazu das harte Tor für alles Kundengerichtete: nichts verlässt das Haus ohne menschliche Freigabe, jede Ausgabe im Audit-Log.
HIL bautPartner-Sales gibt frei
Ergebnis: Sponsoring-Unterlagen in Stunden statt Tagen.
Ein versionierter Metrik-Katalog legt fest, welche Kennzahlen aggregiert werden dürfen (Engagement-Raten, Reichweiten-Bänder, Format-Muster). Nächtlicher Job rechnet Kohorten-Werte, k-Anonymität ab mindestens 5 vergleichbaren Kunden, Ergebnis landet in einem separaten Benchmark-Store (read-only). Geht erst live, wenn der Rechtscheck aus Schritt 3 grün ist. Bis dahin: Vergleiche nur gegen die eigene Historie des Kunden.
HIL bautDSB nimmt ab
Ergebnis: Netzwerk-Intelligenz, die niemanden verrät.
Für den Pilot-Kunden entsteht der eigene, getrennte Datenraum: seine PeakDiver-Sicht, sein CI, seine Report- und Sponsoring-Historie, plus Benchmark-Zugriff (nur Aggregate). Report- und Deck-Agent arbeiten ab jetzt hierüber. Dann: 4 Wochen Alltagsbetrieb, Messung gegen die Erfolgsmaße aus Schritt 1, ehrliche Entscheidung am Ausstiegstor über Welle 2 (weitere Use Cases, weitere Kunden).
HIL baut + übergibtAthletia betreibt zunehmend selbst
Ergebnis: das Muster, das sich auf ~80 Kunden kopieren lässt.