INFORM DataLab Community Summit 2026: Was wir aus den Vorträgen mitnehmen

Daten, KI und viele gute Gespräche

Zwei Tage, ein neuer Ort und ziemlich viele Gespräche, die erst nach dem offiziellen Programm so richtig losgingen: Der Community Summit war dieses Jahr zum ersten Mal in Köln, und er ist ganz schön gewachsen. Schon am Vorabend in der Monkey Bar haben sich alte Bekannte wiedergetroffen, neue Gesichter dazugestellt und Fragen geklärt, für die in keiner Präsentation Platz gewesen wäre. Dieser Abend hat den Ton für den nächsten Tag gesetzt.

In der Wolkenburg ging es dann ohne Umwege ans Eingemachte. Bosch Digital, die apoBank, die Stadtwerke Bonn Verkehrs-GmbH, Intersnack, Techem und viele weitere haben erzählt, was bei ihnen wirklich läuft, inklusive der Stolpersteine. Dazu gab es Masterclasses, ein Panel ohne Verkaufsfolien und einen Open Space für alles, was sonst liegen geblieben wäre.

Mit dabei waren auch unsere Partner und Sponsoren Qlik, Snowflake, insightsoftware, Fivetran + dbt Labs und SAP. Sie standen nicht nur vor Ort für den direkten Austausch bereit, sondern haben das Programm mit eigenen Beiträgen mitgestaltet. Das macht den Summit für uns aus: Hersteller, Kunden und wir reden miteinander statt übereinander. Schluss mit Konzepten, die nur in PowerPoint funktionieren. Hier ist, was wir mitgenommen haben.

Datenintegration im Konzernmaßstab: Bosch Digital

Die Keynote von Bosch Digital hat uns direkt gezeigt, in welcher Liga manche Datenlandschaften spielen. Bosch Digital, der zentrale IT-Service-Provider der Bosch-Gruppe, betreibt eine der komplexesten Datenlandschaften Europas. Der interne Data Lake bindet über 280 Quellsysteme an, verarbeitet rund 900 Terabyte Daten und etwa 1,5 Milliarden Datensätze pro Tag. Das Ganze läuft hybrid: Der Großteil der Daten liegt noch on-premise, immer mehr zieht in die Cloud. Dazu kommen weitere Data Lakes aus den Geschäftsbereichen, die eigene Wege gehen dürfen.

Damit das nicht im Chaos endet, hat Bosch Digital ein eigenes Framework entwickelt. Ein Herzstück ist der Unified Provisioning Layer zwischen Quellsystemen und Workspaces. Die Idee: Daten werden maximal einmal extrahiert und dann mehrfach genutzt. Das spart Doppelarbeit und macht alles schneller.

Spannend wurde es beim Architektur-Assessment, das wir gemeinsam mit Bosch Digital durchgeführt haben. Es hat Pain Points sichtbar gemacht, die im Alltag nicht mehr auffallen. Rund 45 Tools im Portfolio, allein in der Datenbereitstellung vier verschiedene für Realtime, Batch und Replikation. Daraus sind Workstreams entstanden, zum Beispiel ein Nachfolger für SAP SLT, das SAP bis 2030 abkündigt, eine einheitliche Transformationsschicht im Lakehouse, weniger Integrationsmuster und eine zentrale Orchestrierung.

Beim Thema KI lautete die Botschaft: raus aus dem Hype, rein in messbaren Geschäftswert, und lieber mit drei priorisierten Use Cases starten als mit zehn gleichzeitig.

Data Self-Service braucht Spielregeln: apoBank

Auch die apoBank hat uns gezeigt, wie Data Self-Service in einem streng regulierten Umfeld funktioniert. Nach der Einführung des neuen Kernbankensystems 2020 stand die Frage im Raum, wie es mit dem Data Warehouse weitergeht. Die Eigenentwicklung auf Oracle hat die regulatorischen Anforderungen (BCBS 239) erfüllt, stieß aber bei Skalierung und Backlog an ihre Grenzen. Nach einem Marktvergleich fiel die Wahl auf Snowflake, vor allem weil es sofort als Software-as-a-Service nutzbar war.

Technisch gehörten eine Azure Landing Zone für privaten Traffic, eigenes Key Management sowie Datenschutz-, Exit- und Security-Konzepte dazu. Inhaltlich hat die Bank ein eigenes Medaillenmodell gebaut, das sich an der Reichweite orientiert. Je größer der Kreis, desto strenger werden Governance, Tests, Dokumentation und Code Review. Wer ein Datenprodukt baut, ist gleichzeitig Owner, und ein Governance-Team wirkt als Schiedsrichter.

Unser Lieblingsmoment: Das Data-Mesh-Rollenmodell mit elf Rollen war dem Lenkungskreis zu groß und wurde kurzerhand auf bestehende Strukturen heruntergebrochen. Gute Konzepte kommen eben nicht fertig aus der Schublade. Das Fazit der apoBank: Self-Service entsteht nicht durch die Plattform allein, sondern durch ein kontrolliertes Zusammenspiel aus Plattform, Datenverantwortung und Lieferprozess.

Kontext schlägt Modell

Wenn es einen Satz gab, den wir an diesem Tag gefühlt in jedem zweiten Vortrag gehört haben, dann diesen: Das Modell ist nicht das Problem. Philipp Ziemer, Head of Data Management bei INFORM DataLab, hat das mit Studien belegt: Bei Text-to-SQL sind rund 80 Prozent der Fehler inhaltlich falsch, nicht technisch. Der Code läuft, die Tabelle sieht gut aus, aber die Zahlen stimmen trotzdem nicht. Sein Rezept ist ein Lakehouse als Fundament und eine semantische Schicht, die ein LLM vorschlagen darf, ein Mensch aber prüfen und versionieren muss. MCP allein reicht nicht, weil es den Zugriff regelt, nicht die Bedeutung. Ob „Umsatz“ Innen- oder Außenumsatz meint, kann nur die Semantik klären.

Mehr als ein Semantic Layer: die Kontextschicht

Marc an Voort, Solutions Architect Enterprise bei Fivetran + dbt Labs, hat es mit einer Anekdote auf den Punkt gebracht: In einem Workshop haben Agenten bei Tabellen mit guten Beschreibungen richtig geantwortet, bei leeren oder schlechten Beschreibungen haben sie geraten. Er plädiert für eine Kontextschicht, die über das klassische Semantic Layer hinausgeht, damit Agenten nicht nur fragen können, was passiert ist, sondern auch warum.

Datenprodukte bei SAP

SAP hat mit der Business Data Cloud gezeigt, wie sich das umsetzen lässt: Datenprodukte bringen Beschreibung, Semantik und Eindeutigkeit gleich mit und werden in einem Katalog auffindbar. Über BDC Connect lassen sie sich mit Databricks, Snowflake, Fabric oder BigQuery austauschen, ohne Daten zu kopieren. Und auch Snowflake hat bestätigt: Vor zwölf Monaten war die Modellfrage noch die erste, heute spielt sie kaum noch eine Rolle.

Erst die Strategie, dann die Technik

Dr. Jens Linden, Head of Data Strategy bei INFORM DataLab, hat in seinem Vortrag zur AI Roadmap eine These aufgestellt, die sich gewaschen hat: Die meisten AI Roadmaps führen in die Mittelmäßigkeit, weil sie sich an Benchmarks und Reifegradmodellen orientieren und damit nur nachbauen, was andere schon machen.

Sein Gegenvorschlag ist der KI-Kompass. Jeder Use Case wird mit zwei Fragen eingeordnet:

1.  Liefert er etwas, das Wettbewerber weder nachbauen können noch wollen? Dann ist er eine Kür, so wie John Deeres „See & Spray“, das Unkraut auf dem Feld erkennt und gezielt bekämpft.
2. Wäre es offensichtlich dumm, ihn nicht umzusetzen? Dann ist er Pflicht, zum Beispiel der Abgleich von Rechnungen und Bestellungen. Alles andere landet im Verzicht, auch wenn sich der Use Case rechnen würde, denn Ressourcen sind begrenzt.

Aus der Verteilung der Use Cases ergibt sich, welche Rolle KI im Unternehmen spielt: kein Hebel, operatives Muss, Differenzierer oder ganz neues Geschäftsfeld. Davon hängen Budget, Verantwortung und Erfolgsmaßstab ab. Pflichtfälle laufen unter einer Kostenobergrenze, Kür-Fälle brauchen ein Erkundungsbudget und gehören auf die Agenda der Geschäftsführung. Ohne diesen Schritt behandelt man alles als operatives Muss, und eine Kür scheitert an der klassischen ROI-Rechnung.

Was ist dein Use Case wert? Der Business-Case-Workshop

Dass Data- und KI-Vorhaben oft aus Überzeugung starten statt aus einer belastbaren Rechnung, kennt wohl jedes Data-Team. Anne Schmitz, Data Strategy & Sustainability Consultant bei INFORM DataLab, hat deshalb mit den Teilnehmenden in Kleingruppen an einem Beispiel-Case gearbeitet. Bewertet wurde dabei nicht nur, was sich in Euro rechnen lässt, sondern auch der nicht monetäre Nutzen, und zwar bevor etwas umgesetzt wird. Mit nach Hause nahmen die Teilnehmenden Canvas-Templates und ein Cheat Sheet, mit denen sie direkt an den eigenen Use Cases weiterarbeiten können.

Vom Herzensprojekt zur Datenorganisation: Stadtwerke Bonn Verkehrs-GmbH

Wie es sich anfühlt, wenn aus einem Herzensprojekt eine echte Datenorganisation wird, hat uns die Stadtwerke Bonn Verkehrs-GmbH erzählt. Bei der SWBV ist die Datenlandschaft seit 2020 organisch gewachsen: über 40 aktive Use Cases, rund zehn Quellsysteme, getragen von Herzblut und ein paar engagierten Köpfen. Das Problem: Alles hing an wenigen Personen. Anfragen kamen auf Zuruf, und welcher Use Case zuerst dran war, wurde allein entschieden, ohne zu wissen, wie er auf die Unternehmensstrategie einzahlt.

Gemeinsam mit uns haben sie das geändert: mit einer Datenstrategie, einem Data Operating Model mit klaren Rollen, einem Business-Case-Modell und einem Assessment von Compliance und Architektur. Dabei haben wir uns als kritischer Freund verstanden: Wir haben nachgefragt, hinterfragt und Annahmen auch mal infrage gestellt.

Struktur und Kultur gemeinsam denken

Mindestens genauso wichtig war die Kultur, denn Struktur und Kultur lassen sich nur gemeinsam denken. Weil die Datenlandschaft von unten gewachsen ist, ist die Akzeptanz hoch: Die Kolleginnen und Kollegen haben selbst erlebt, dass ihnen Daten die Arbeit erleichtern. Was gefehlt hat, war das Commitment von oben. Das ist inzwischen da, und das Management fragt von sich aus nach Zahlen, Daten und Fakten. Den Betriebsrat hat die SWBV früh ins Boot geholt, und für alle im Unternehmen entsteht ein Lernpfad, auch für das Fahrpersonal. Das ist kein Nice-to-have, denn wer nach einem Unfall die Daten aufnimmt, bestimmt mit, wie gut sie später sind. Oder, wie es im Vortrag hieß: Die Fachbereichsgrenze ist keine Unternehmensgrenze.

Wie das konkret aussieht, zeigt die Mängelstatistik für die Busflotte. Sie führt Störmeldungen und Wetterdaten zusammen und soll später Predictive Maintenance ermöglichen, damit Busse nicht mehr nach starrem Zyklus, sondern nach Bedarf in die Werkstatt kommen. Dafür muss auch die Datenqualität weiter steigen, und genau dabei helfen Kultur und klare Schnittstellen.

KI im Alltag: Was in der Praxis funktioniert

Klein starten, Vertrauen aufbauen

Vertrauen war das meistgenannte Wort des Tages. Marc an Voort hat von einem Kundenworkshop erzählt, in dem jede KI-Antwort sofort im Power-BI-Dashboard gegengeprüft wurde. Vertrauen ist schwer aufzubauen und schnell zerstört. Sein Tipp klingt zunächst ungewöhnlich: einen Use Case wählen, dessen Antwort man schon kennt. Erst wenn der Prozess dieselbe Zahl liefert wie die bekannte Auswertung, lohnt sich der nächste Schritt.

Im Vendor-Panel mit insightsoftware, Fivetran + dbt Labs, Snowflake und Qlik zog sich dieser Gedanke durch. Für die nächsten 90 Tage empfehlen die Hersteller einen realistischen Use Case, C-Level-Sponsoring, einen echten Business Case und ein Modell, das zur Aufgabe passt. Für eine E-Mail braucht es nicht das größte Modell.

Agenten im Arbeitsalltag: Snowflake und SAP

Dr. Fabian Gampfer, Principal AI Specialist bei Snowflake, hat mit dem internen Projekt „Raven“ gezeigt, wie sich der Alltag verändert. Rund 6.000 Mitarbeitende fragen per Chat nach Pipeline, Kundenübersicht und Terminvorbereitung. Der Agent kombiniert dafür strukturierte Daten aus CRM und Support mit unstrukturierten Inhalten aus Präsentationen, Jira und Confluence. Interessant: Sobald das System lief, kamen sofort neue Ideen, und die Datenbasis musste verdoppelt werden, weil so viele zusätzliche Themen gefragt waren.

SAP hat gezeigt, wie Fachanwender in natürlicher Sprache mit Geschäftsdaten arbeiten. Im Hintergrund orchestrieren spezialisierte Agenten die Aufgaben, etwa eine Reisebuchung oder der Aufbau eines Planungsmodells samt Dashboard. SAP hat dabei betont, dass es kein Entweder-oder zwischen Dashboards und KI gibt. Beide Welten bleiben nebeneinander bestehen.

Masterclasses: Hype von Fortschritt trennen

Bei unserem Head of AI Nils Gerber stand die Frage im Mittelpunkt, die gerade alle beschäftigt: Was kann KI heute wirklich, und was ist nur neu verpackter Hype? In seiner Masterclass „Agenten bauen war gestern?“ ist er die Entwicklung von frühen Sprachmodellen über Reasoning-Modelle bis zur agentischen KI durchgegangen, hat Modellklassen sortiert und gezeigt, wann sich eigene Agenten noch lohnen. Und das nicht als Frontalvortrag: Per QR-Code ging es für alle ins „Human Benchmark“, ein Quiz, bei dem sich zeigte, wer KI-Hype von Realität unterscheiden kann. Am Ende hat ein Live-Ranking den „AI Champion“ ermittelt.

Dass KI heute schon viel Fleißarbeit selbst übernehmen kann, hat Peter Collienne in der Masterclass zu Qlik Cloud und MCP live gezeigt: Ein LLM baut über MCP Dashboards, legt Masterelemente samt Beschreibungen an und erstellt Glossare. Das nimmt Fleißarbeit ab und löst das Blank-Page-Problem. Kontrolle bleibt trotzdem nötig. Wer Masterelemente nutzt und dem Modell genau sagt, was es tun soll, spart Tokens und bekommt Ergebnisse, die sich validieren lassen.

Unser Fazit: Fundament zuerst, dann KI

Wenn wir den Tag in einem Satz zusammenfassen müssten: Erst kommt das Fundament, dann kommt die KI. Saubere Daten, gemeinsame Definitionen, klare Verantwortung und ein echter Business Case sind kein Bremsklotz, sondern die Voraussetzung dafür, dass KI Mehrwert liefert. Wer klein startet, einen Sponsor im Management hat und Technik und Organisation zusammen denkt, kommt weiter als mit dem großen Wurf.

Danke an alle, die dabei waren, mitdiskutiert und mitgelacht haben. Wir freuen uns schon auf das nächste Mal.