Zusammenfassend sind es wohl drei wesentliche Punkte, die ich persönlich von der Veranstaltung mitgenommen habe und auf die ich hier näher eingehen möchte:

1. Souveränität wird verstanden und gelebt

2. Wissen und Daten sind ein Standortvorteil

3. Selbstwirkung durch Handeln; nicht Hoffen

Im Vorfeld hatte ich keine Erwartungen an den Summit selbst, daher wollte ich mich nur inspirieren und ihn auf mich wirken lassen. Und so kann ich natürlich auch nicht von enttäuschten oder übertroffenen Erwartungen sprechen.

Jetzt abonnieren

Einzig hat mich im Vorfeld tatsächlich interessiert, wie die Veranstaltung wohl bei vergleichbaren Events anderer Anbieter abschneiden würde, denn andere Anbieter spielen hier meist in einer ganz eigenen Liga.

In dieser Hinsicht war ich sehr positiv überrascht über die sehr gelungene Organisation samt Musikeinlagen, wie die des Polizeiorchesters Baden-Württemberg, die der Veranstaltung einen ganz eigenen Stempel aufdrückte bei gleichzeitiger Professionalität des Events insgesamt.

Allerdings trugen die Musikeinlagen im Areal zusammen mit den sehr lauten Ansagen zu einer enormen Geräuschkulisse bei, was wohl neben dem äußerst schlechten WLAN zu den wesentlichen Kritikpunkten zählt, die ich habe.

Das WLAN war wirklich miserabel, sodass ich die Arbeit, die ich mitnehmen musste, über meinen eigenen Hotspot erledigen musste. Vielleicht ging es auch nur mir so und sicherlich eine Kleinigkeit, aber für eine Cloud-Company natürlich auch etwas peinlich.

Damit aber letztlich zu den großen Dingen, die besprochen wurden, und den tiefen Eindrücken, die diese auf mich gemacht haben.

Durchweg, ob bei der sehr inspirierenden Session mit Dave deBronkart über Patientendaten und Nutzung von KI im Gesundheitswesen, der Paneldiskussion mit der Präsidentin des BSI Claudia Plattner und dem Präsidenten für Technik & Services der Polizei Baden-Württemberg Thomas Berger oder der Session von Brainblock, für mich haben sich drei wesentliche Themen wie ein roter Faden durch die vielen Diskussionen, Gespräche und Präsentationen gezogen.

1. Souveränität wird verstanden

Oft scheint Souveränität wie ein bedeutungsloser Marketing- oder Kampfbegriff zu sein, weshalb ich mich auf dem Weg zum Gipfeltreffen selbst auch fragte, was Souveränität bedeutet und ob es nur ein anderes Wort für Protektionismus ist.

Souveränität wurde dann natürlich auch oft erörtert. Dies wahrscheinlich zum Leidwesen von Claudia Plattner, der Präsidentin des BSI, die Souveränität gerne verstanden und nicht mehr darüber diskutieren möchte.

Durchweg zeichnet sich das Verständnis ab, dass Souveränität eben nicht bedeutet, sich zu isolieren, und die Notwendigkeit, alles selbst zu bauen. Vielmehr bedeutet es, den Entscheidungs- und den Handlungsspielraum zu kontrollieren und selbstbestimmt wahrnehmen zu können.

Beispielhaft dafür ist natürlich auch der jüngste Merger von Alpep Alphas und Cohere, als Kooperation zwischen einem kanadischen und einem europäischen Unternehmen. Auch die zahlreichen Partner wie Google, ServiceNow, Crowdstrike und viele mehr, die an dem Summit teilnahmen und Teil der Stackit-Cloud sind, sind ein Beleg für diesen Ansatz.

Allerdings müsste man dann natürlich auch etwas kritischer die Rolle von SAP hinterfragen, einem der größten Sponsoren des Events. Weil letztlich auch deren Lizenz- und Produktpolitik rund um S4HANA den Entscheidungsspielraum von Unternehmen eher dominierte. Nur weil SAP deutsch ist, ist es nicht unbedingt ein Garant für Souveränität nach dieser Definition. Umso mehr, da es erhebliche wirtschaftliche Interessen im Ausland hat.

Sorry SAP, but somebody had to say it!

Letztlich bewerte ich die jüngste Entwicklung bei SAP sehr positiv, wobei für mich die Kooperation mit Databricks und der Kauf von Dremio positiv aufgefallen sind. Hätte mir zwar DuckDB lieber gewünscht, aber hey … weiter so!

2. Daten und Wissen als Standortvorteil

Dass Daten wichtig sind für den Erfolg von Unternehmen, um effizienter zu produzieren oder zu verkaufen, ist für die meisten sicherlich nicht neu. Dieses aber eben als Standortvorteil zu verstehen und entsprechend zu handeln, eben schon.

Aus Unternehmen fließen zahlreiche Informationen ab, die die Innovationskraft von Anbietern und nicht der Unternehmen selbst stärken. Auch wenn dieser Mechanismus des Informationsparadoxons immer noch zu wenig verstanden wird, so war es bemerkenswert, wie sich durchweg durch alle Sessions die Erkenntnis herauskristallisiert hat, dass Daten und daraus gewonnene Informationen einen entscheidenden Hebel bei der Wettbewerbsfähigkeit spielen. Diese dürfen nicht verloren gehen und müssen entsprechend gewonnen werden. Dabei spielt natürlich auch der Einsatz von KI eine Rolle und hier eben auch der gesicherte Einsatz.

3. Handeln (es sind die Menschen)

Als letzte Beobachtung bei den von mir besuchten Sessions kristallisierte sich die für mich besonders hervorzuhebende Festsetzung heraus, sich auf die Selbstwirkung und das Handeln zu verlagern. Meckern und die Schuld bei Politik oder anderen Umständen zu suchen, machen viel zu viele und nebenbei gehört es auch nicht zu den Tugenden unserer Gesellschaft.

In vielen Gesprächen und Präsentationen hallte der Appell mit, zu handeln und die Umstände selbst zu gestalten, anstatt sich darauf zu verlassen, dass andere diese für einen ändern. Stackit und Schwarz Digit stehen hier beispielhaft für diese Einstellung. So weiß ich genau, dass sie z. B. von meinen ehemaligen Kollegen bei Databricks und auch anderen belächelt werden und man glaubt, dass sie es nicht schaffen werden. Doch nur wer handelt, kann etwas bewirken. So einfach ist das.

Insgesamt war es ein sehr inspirierendes und gelungenes Event und wir freuen uns schon sehr auf viele weitere solcher Events. Auch sind wir sehr aufgeregt über die gemeinsame zukünftige Entwicklung und den Beitrag, den wir hier von Datenhandwerk dabei leisten können.

Jetzt abonnieren

Nachdem Serge Brin und Larry Page ihre Suchmaschine gestartet hatten, wollten sie das Unternehmen eigentlich an Excite für 1 Million Dollar verkaufen, die allerdings dankend ablehnten. Während Jeff Bezos einen dominierenden Einzelhändler aufbaute und gleichzeitig begann, Cloud Computing über Jahre zu dominieren, waren sich zahlreiche Analysten sicher, dass Amazon niemals profitabel sein könnte, selbst wenn sie alle Bücher der Welt verkaufen würden.

Niemand ist besonders gut darin, die Zukunft vorherzusagen oder eine Entwicklung samt ihrer Auswirkungen vollumfänglich zu begreifen. Das liegt vorwiegend daran, dass wir dazu neigen, zukünftige Ereignisse anhand des Verlaufs von vergangenen Ereignissen zu messen. Hierzulande überwiegt deshalb auch vor allem scheinbar die große Skepsis und das Narrative der KI‑Blase. Das hängt im Wesentlichen auch mit der schlechten Erfahrung der Dotcom-Blase und insbesondere der traumatischen Erfahrung der “Volksaktie” Telekom zusammen.

Verdrängt wird dabei, dass es eben auch diese Zeit war, in der Unternehmen wie Google und Amazon entstanden sind.

Wie lässt sich das aber nun in der aktuellen Entwicklung einordnen und welche grundlegenden Prinzipien helfen dabei?

Dies ist ein Versuch, genau diese Prinzipien zu identifizieren und auszuarbeiten. Eines dieser Prinzipien basiert auf der Arbeit des Nobelpreisträgers Kenneth J. Arrow und seinem Prinzip des Informationsparadox bzw. seiner Umkehrung, wie es der CEO von Microsoft, Satya Nadella, so treffend formuliert hat.

Jetzt abonnieren

Für Wirtschaftsprüfer, Rechtsanwälte, Software-Entwickler und viele andere geht es darum, wie Unternehmen im Zeitalter der künstlichen Intelligenz ihre Kern-IP schützen können.

Hierbei beschreibt der Nobelpreisträger und Wirtschaftswissenschaftler Kenneth Arrow ein bekanntes Paradoxon auf dem Informationsmarkt:

Der Wert für den Käufer ist erst erkennbar, wenn er die Information besitzt. Doch dann hat er sie faktisch kostenlos erworben.

Wenn man es sich genau überlegt, ist es eben genau dieses Paradox, das auch hinter dem Erfolg eben vieler Informationstechnologiekonzerne wie Google steckt.

Sergey und Larry hatten wahrscheinlich überhaupt keine Idee von dem Potenzial der Informationen, die sie mit ihrer Suchmaschine einbringen würde. Doch, als sie diese Informationen hatten, konnten sie damit ein Unternehmen erschaffen, das ebenso wertvoll wurde wie Microsoft selbst.

Google ist die beste Suchmaschine weltweit, weil die meisten Menschen Google nutzen. Und die meisten Menschen nutzen Google, weil es die beste Suchmaschine ist.

Die Informationen, die wir als Nutzer der Suchmaschine zur Verfügung stellen, eben noch mehr, wenn wir Android oder Chrome nutzen, sind so wertvoll, um ein beherrschendes Unternehmen zu ermöglichen. Dabei sind es vor allem die Nutzerinformationen, die diese Stellung ermöglichen. Und auch hier bietet Arrow eine entscheidende Erklärung, indem er klarstellt, dass diejenigen, die die Informationen generieren, solange eine Monopolstellung inne haben, solange diese nicht geteilt werden.

KI heutzutage schafft das genau umgekehrte Problem.

Im KI-Zeitalter riskiert der Käufer, Wissen preiszugeben, nur um das Gekaufte nutzen zu können. Man bezahlt im Grunde doppelt für Intelligenz: einmal mit Geld und ein zweites Mal mit etwas noch Wertvollerem: dem firmeneigenen Wissen, das man offenlegen muss, um diese Intelligenz nutzbar zu machen. Je besser das Modell funktionieren soll, desto mehr von diesem Wissen muss man ihm zur Verfügung stellen! Mit der Zeit verschlimmert sich die Informationsasymmetrie immer weiter. Der Verkäufer erfährt immer mehr über das Unternehmen oder den Nutzer, während die Nutzer das gekaufte Produkt nutzen, während sie selbst kaum etwas darüber erfahren, was der Verkäufer im Gegenzug lernt.

Das bezeichnet Satya Nadella als das umgekehrte Informationsparadoxon.

Durch den Einsatz von Foundational Modellen wie Anthropic oder ChatGPT zahlen Unternehmen im Wesentlichen dafür, sich ihrer eigenen Monopolstellung bei ihrer Informationsgewinnung berauben zu lassen. Das mag dann auch die für viele überzogenen Bewertungen dieser KI‑Firmen erklären.

Nutzer werden an dieser Stelle gerne anführen, dass sie “private” Angebote nutzen, die Vereinbarungen getroffen haben, dass ihre Daten nicht für Trainingszwecke genutzt werden können, wobei sie eben nicht verstehen, dass Modelle eben auch aus „Erschöpfung“ – den Eingabeaufforderungen, die Nutzer verfassen, den von Agenten verwendeten Tools und insbesondere den Korrekturen, die Nutzer vornehmen, wenn das Modell fehlerhaft ist, – lernen.

Jede Korrektur wird zu institutionellem Know-how destilliert. Es ist die Art von Wissen, die ein Konkurrent niemals kaufen könnte und die fast unmerklich durchsickert: Spur für Spur, Korrektur für Korrektur, Bewertung für Bewertung.

Wieder auf Google bezogen wurde die Suchmaschine besser dadurch, welche Ergebnisse zu welchen Suchanfragen angeklickt wurden. Allein zu wissen, wonach gesucht wird, war ein schier unermesslicher Schatz. All diese Informationen der “Erschöpfung” fließen unweigerlich in die Verbesserung von Modellen. Dies erfordert mehr als Datenschutz.

Patente lösen eben nur einen Aspekt von Arrows Paradoxon. Sie ermöglichen es einem Erfinder, eine Idee offenzulegen, ohne sie einfach preiszugeben. Das umgekehrte Informationsparadoxon benötigt ein Äquivalent.

Indem Nutzer Informationen konsumieren, schaffen Sie selbst Informationen. Und was sie schaffen, sollte Ihnen gehören. Dies ist ihre besondere Intelligenz im Sinne Hayeks: das Wissen über Zeit, Ort und Umstände, das niemand sonst besitzen kann.

Es weiß, was du denkst, was dir wichtig ist und wie du Erfolg misst. Die großartige Innovation, die sich aus dem Recht der Modellanbieter auf faire Nutzung öffentlicher Daten für das Training von Modellen ergibt, ist zwar notwendig, doch hält es Satya für ironisch, dass der Status quo darin besteht, die Datenextraktion einzuschränken und sich das Recht vorzubehalten, aus Kundennutzungs- und Interaktionsdaten zu lernen.

Wenn Lernen nur in eine Richtung fließt, konzentriert sich der wirtschaftliche Wert eher bei den Besitzern der Lerninfrastruktur als bei den Schöpfern des Wissens selbst. Daher hält er es für unerlässlich, dass wir die Lerninfrastruktur jedem Unternehmen zugänglich machen, damit es seinen eigenen Lernprozess steuern kann.

Wie Alex Karp es ausdrückte: „Technische Kunden wollen die Kontrolle über ihre Rechenleistung, ihre Modelle, ihren Daten-Stack und ihr Alpha. Sie wollen wissen, dass sie die Produktionsmittel besitzen und diese nicht an jemand anderen übertragen werden.“

Das aktuelle System bewirkt genau die Übertragung, die Karp und Unternehmen befürchten. Deshalb benötigen Unternehmen eine echte Vertrauensbasis, damit sich ihr Humankapital und ihr Token-Kapital vermehren können. Hier sammeln und verbessern sich die Daten, Protokolle, Auswertungen, angepassten Gewichtungen und das Wissen einer Organisation.

Es handelt sich um eine strikte Grenze, die ohne Zustimmung nicht überschritten werden darf – nicht einmal die gesammelten Informationen. Unternehmen werden das Recht einfordern, Modellausgaben zur Feinabstimmung und/oder zum Training ihrer eigenen Modelle zu nutzen. Satya sieht darin das Recht jedes Unternehmens, seine Modelle an seinen Rechenschaftspflichten auszurichten.

Im Cloud-Zeitalter sammelten Unternehmen Daten.

Im KI-Zeitalter sammeln sie Lernerfahrungen. Die Vertrauensgrenze muss sich entsprechend weiterentwickeln: vom Schutz von Informationen hin zum Schutz der Mechanismen, durch die Organisationen lernen, sich anpassen und Wissen aufbauen.

Jedes Unternehmen muss nach Satya einige Maßnahmen ergreifen, um dies zu gewährleisten:

• Kontrolle
  Erstellen Sie Ihre eigenen Auswertungen, denn diese definieren, was innerhalb der Organisation als „gut“ gilt. Behalten Sie außerdem die Kontrolle über das Wissen, die Protokolle, das Feedback, die Entscheidungen und den institutionellen Kontext Ihrer Organisation sowie die Möglichkeit, Modellausgaben für Ihre eigenen Aufgaben und Abfragen zu nutzen.

• Fähigkeit
  Erstellen Sie innerhalb der Mandantengrenzen Ihre eigenen, proprietären Lernumgebungen, um Modelle zu trainieren oder zu optimieren. Die Modelle lernen dabei anhand realer Arbeitsabläufe, ohne das Unternehmenswissen preiszugeben.

• Wahlfreiheit
  Stellen Sie sicher, dass die Orchestrierungsschicht von jedem einzelnen Modell entkoppelt ist. Fragen Sie sich: Können Sie Ihre Evaluierungen weiterhin mit anderen Modellen durchführen und optimieren, wenn eines Ihrer Modelle wegfällt? Bleibt Ihre Unternehmenskompetenz erhalten, selbst wenn ein bestimmtes Standardmodell wegfällt?

• Kosten
  Durch die Entkopplung der Orchestrierungsschicht können Sie Kontext, Modelle und Aufgaben auf effizienteste und kostengünstigste Weise zusammenführen, ohne Kompromisse bei der Qualität einzugehen.

Kombiniert man diese vier Aspekte, entsteht ein kontinuierlicher Lernkreislauf (quasi eine Art Bergsteigermaschine), der es ermöglicht, dass deine KI-Investitionen den Wert Ihres Unternehmens exponentiell steigern.

Anders ausgedrückt: Ein Unternehmen sollte ein Modell nutzen können, ohne dabei das Wissen aufzugeben, das es einzigartig macht. Dies ist das umgekehrte Informationsparadoxon, dem wir uns stellen müssen.

Kombinieren Sie diese vier Aspekte, und Sie schaffen einen kontinuierlichen Lernkreislauf (eine Art „Hill Climbing Machine“), der den Wert Ihrer KI-Investitionen exponentiell steigert.

Jetzt abonnieren

Der eigentlich interessante Teil ist das, was DuckDB technisch anders macht als klassische Warehouses und verteilte Engines. Ebendarum bietet der Rest dieses Artikels einen technischen Einblick in die Struktur eines der derzeit wohl populärsten Datentools.

DuckDB ermöglicht schnelle und “spaßige” Datenanalyse, ohne dass man große Apache-Spark-Cluster einrichten oder ein Cloud-Data-Warehouse betreiben muss, wenn man nur ein paar hundert Gigabyte Daten verarbeitet. Aber auch für größere Datenmengen eignet es sich ebenso gut.

Das schrieb AWS jüngst zur Übernahme von DuckLabs:

"For almost a decade, the DuckDB team has worked with the idea of building a tool that lets people work with data, with confidence. I find that sentiment—not just making data easy to work with, but actively empowering people to ask questions, build, and really innovate with data—is exactly in line with how AWS and our customers think about data," said Andy Warfield, Amazon vice president and distinguished engineer. "We’ve been working closely with the DuckLabs team for the past two years, and I am so excited at the opportunity to work with them even more closely."

Was „Datenbank im Prozess“ konkret bedeutet

Die überwiegende Mehrheit der Datenbanken, darunter Postgres, MySQL, Snowflake und Spark, teilt Anwendung und Datenbank in zwei verschiedene Prozesse. Der Client einer Anwendung stellt eine Verbindung über einen Socket her, sendet eine Anfrage und wartet auf die Antwort.

Bei DuckDB verhält sich das anders.

Es wird als Bibliothek in den Prozess der Anwendung selbst eingebunden, wobei es egal ist, ob die Anwendung Python, C++, Node.js, R oder direkt als CLI läuft. Es existiert kein Port, kein Verbindungspool, kein Auth-Handshake und kein Server, mit dem man sich verbinden müsste.

Zugegebenermaßen ist das schon recht gewöhnungsbedürftig und seltsam, wenn man es jahrelang anders gewohnt war.

Ein Beispiel für eine Ausführung einer Datenbank in Python:

import duckdb

r1 = duckdb.sql("SELECT 42 AS i")
duckdb.sql("SELECT i * 2 AS k FROM r1").show()

Dies führt die Abfrage unter Verwendung einer In-Memory-Datenbank aus, die global innerhalb des Python-Moduls gespeichert ist. Das Ergebnis der Abfrage wird als „Relation“ zurückgegeben. Eine Relation ist eine symbolische Darstellung der Abfrage. Die Abfrage wird erst dann ausgeführt, wenn das Ergebnis abgerufen oder dessen Ausgabe auf dem Bildschirm angefordert wird (lazy execution).

DuckDB basiert in etwa auf dem gleichen Grundgedanken wie SQLite, was sich als Tool für ein flexibles OLTP (Online Transaction Processing) bei Entwicklern großer Beliebtheit erfreut. Nur ist DuckDB für einen anderen Workload gedacht: SQLite ist auf schnelle, punktuelle Transaktionen optimiert (OLTP), DuckDB auf große analytische Scans – OLAP (Online Analytical Processing).

Beide teilen sich das Deployment-Modell – eine einzelne Datei, kein Serverbetrieb –, aber ihre internen Speicher- und Ausführungsmodelle sind komplett unterschiedlich gebaut.

Daten lesen und schreiben: SQL über Systemgrenzen hinweg

Daten können in unterschiedlichen Formaten persistiert oder gelesen werden. Während bei anderen Datenbanksystemen die Speicherung der Daten eng mit der Ausführungsengine verknüpft ist, nutzt hier DuckDB das Prinzip der Trennung von Datenformat und Engine, wie wir es zum Beispiel auch bei Spark und anderen Cloud Warehouses finden.

Native werden zahlreiche Datenformate unterstützt:

import duckdb

duckdb.read_csv("example.csv")                # read a CSV file into a Relation
duckdb.read_parquet("example.parquet")        # read a Parquet file into a Relation
duckdb.read_json("example.json")              # read a JSON file into a Relation

duckdb.sql("SELECT * FROM 'example.csv'")     # directly query a CSV file
duckdb.sql("SELECT * FROM 'example.parquet'") # directly query a Parquet file
duckdb.sql("SELECT * FROM 'example.json'")    # directly query a JSON file

Eine der Eigenschaften von DuckDB ist die Fähigkeit, per Extension direkt gegen fremde Datenquellen zu scannen, ohne die Daten vorher zu materialisieren. D.h., dass hier die Optimierungen bei der Anfrage, wie z. B. die Daten entsprechend zu filtern (Predicate Pushdown), direkt übernommen werden.

Über postgres_scan etwa lässt sich eine produktive Postgres-Tabelle mit einer lokalen CSV-Datei joinen, in einer einzigen Abfrage:

SELECT u.id, u.email, s.zielwert
FROM postgres_scan('host=localhost dbname=prod', 'public', 'users') u
JOIN read_csv_auto('stakeholder_daten.csv') s ON u.id = s.user_id;

Das funktioniert nicht nur mit Postgres, sondern über weitere Extensions auch mit MySQL, SQLite, entfernten Parquet- und JSON-Dateien auf S3, sowie über Iceberg- und Delta-Lake-Extensions direkt gegen Lakehouse-Tabellen:

SELECT count(*), min(signup_date)
FROM read_parquet('s3://bucket/rohdaten/*.parquet')
WHERE jahr = 2024;

Dabei werden Filter- Predicate-Pushdowns auch auf die entfernte Quelle angewendet, sodass nicht unbedingt alle Spalten und Zeilen über das Netz gezogen werden müssen, um sie dann lokal zu filtern.

DuckDB verfügt über zahlreiche Erweiterungen, unter anderem auch Excel:

import duckdb

duckdb.sql("INSTALL excel;")
duckdb.sql("LOAD excel;")

duckdb.sql("""
  SELECT
    date_part('year', strptime(time, '%Y-%m-%d %H:%M:%S')) as year,
    CAST(temp AS DOUBLE) as temp,
    CAST(coco AS INTEGER) as coco
  FROM read_xlsx('2026-07-20_meteostat_export.xlsx', all_varchar=True, header=True);
""")

Spaltenorientierte Speicherung und Row Groups

Daten werden in DuckDB, so wie eigentlich auch in jeder anderen „Analytical Processing Engine“, spaltenweise, nicht zeilenweise, verarbeitet.

Der Unterschied ist bei analytischen Queries entscheidend. Wenn du zum Beispiel

SELECT avg(betrag) FROM rechnungen WHERE jahr = 2025

ausführst, muss die Engine nur die Spalten betrag und jahr lesen und nicht jede einzelne Zeile mit sämtlichen anderen Feldern, die für diese Query irrelevant sind. Bei einer zeilenorientierten Datenbank würden dagegen zwangsläufig alle Spalten mitgelesen werden.

Intern organisiert DuckDB die Daten in sogenannten Row Groups von jeweils rund 120.000 Zeilen. Jede Row Group trägt Metadaten (Min/Max-Werte pro Spalte, Null-Counts), die der Optimizer nutzt, um ganze Blöcke zu überspringen, wenn sie für eine Query offensichtlich irrelevant sind – sogenanntes Zone Mapping bzw. Predicate Pushdown. Bei einer Filterbedingung wie WHERE jahr = 2025 muss die Engine dadurch oft nur einen Bruchteil der physisch gespeicherten Daten überhaupt anfassen.

Das lässt sich in etwa mit der Partitionierung bei Parquet vergleichen, wo eine Gruppeneinteilung von Parquet-Files typischerweise in Ordnern und „Row Groups“ in den Files stattfindet.

DuckDB & Parquet

Der Parquet-Reader von DuckDB kommt ohne externe Abhängigkeiten aus und kann SQL-Abfragen direkt auf Parquet-Dateien ausführen – ganz ohne vorherigen Import- oder Analyseschritt. Dank des spaltenorientierten Formats von Parquet geschieht dies zudem zügig.

DuckDB liest Parquet-Dateien im Streaming-Verfahren ein; dadurch lassen sich auch Abfragen auf großen Dateien durchführen, die nicht vollständig in den Arbeitsspeicher passen.

Spalten und Zeilen, welche für eine bestimmte Abfrage benötigt werden, werden automatisch erkannt. Dies ermöglicht die Analyse weitaus größerer und komplexerer Parquet-Dateien, ohne dass manuelle Optimierungen oder zusätzliche Hardware- erforderlich sind.

Ein weiterer Vorteil: DuckDB erledigt all dies mittels Parallelverarbeitung und kann dank Glob-Syntax mehrere Parquet-Dateien gleichzeitig verarbeiten:

con.execute("""
   SELECT *
   FROM 'taxi/*.parquet'
   LIMIT 5""").df()

Vektorisierte Ausführung statt Zeile-für-Zeile

Klassische Datenbank-Engines arbeiten häufig nach dem sogenannten Volcano-Modell: Jeder Operator im Ausführungsplan verarbeitet eine Zeile, reicht sie an den nächsten Operator weiter, dann die nächste Zeile. Das erzeugt massiven Function-Call-Overhead, wenn Millionen Zeilen durch einen mehrstufigen Plan laufen.

DuckDB verarbeitet stattdessen Vektoren - Batches von typischerweise rund 2.048 Werten gleichzeitig. Ein Operator bekommt nicht eine Zeile, sondern einen ganzen Vektor, verarbeitet ihn mit SIMD-freundlichem Code und reicht den Vektor als Batch weiter. Das reduziert nicht nur den Overhead pro Zeile drastisch, es erlaubt der CPU auch, moderne Vektor-Instruktionen tatsächlich auszunutzen, statt ständig zwischen Interpreter-Schritten zu pendeln. Dieses Ausführungsmodell – kombiniert mit einem parallelisierbaren, morsel-artigen Scheduling über mehrere CPU‑Kerne – ist der Hauptgrund, warum DuckDB auf Single-Node-Hardware so nah an die Performance verteilter Systeme herankommt, ohne deren Koordinations-Overhead zu haben.

Out-of-Core-Verarbeitung: größer als der RAM

Der Punkt, an dem viele In-Memory-Tools kapitulieren, ist ein Datensatz, der größer ist als der verfügbare Arbeitsspeicher. DuckDB löst das über Streaming- und Spill-to-Disk-Mechanismen: Aggregationen, Joins und Sortierungen, die den RAM sprengen würden, werden in Teilen verarbeitet und Zwischenergebnisse bei Bedarf temporär auf die Festplatte ausgelagert, statt mit “Out of Memory” abzubrechen.

Ein Vergleichstest von Daniel Beach illustriert, wie belastbar das in der Praxis ist: 650 GB Rohdaten aus einer Delta-Lake-Tabelle auf S3, verarbeitet auf einer EC2-Instanz mit lediglich 32 GB RAM und 16 vCPUs — also knapp 5 % des Datenvolumens an Arbeitsspeicher.

DuckDB kam nach 16 Minuten durch, inklusive korrekter Verarbeitung von Deletion Vectors, mit der Polars zu diesem Zeitpunkt noch Schwierigkeiten hatte.

Ein Single-Node-PySpark-Setup auf vergleichbarer Hardware brauchte über eine Stunde, unter anderem weil Spark ohne manuelles Tuning (etwa an spark.sql.shuffle.partitions) nicht für diese Konstellation ausgelegt ist.

Für die Einordnung ist wichtig zu verstehen, dass das kein kontrollierter Benchmark Test unter Laborbedingungen ist, sondern ein einzelner, transparent dokumentierter Testlauf.

Es zeigt aber ein Muster, das sich in eigenen Projekten regelmäßig bestätigt – auf Datengrößen deutlich unterhalb des Petabyte-Bereichs verliert die Koordination eines verteilten Systems gegen ein gut gebautes Single-Node-Tool.

Zero-Copy-Integration mit dem Python/Arrow-Ökosystem

DuckDB arbeitet eng mit Apache Arrow zusammen. Für Pandas- und Polars-DataFrames sowie Arrow-Tables kann DuckDB SQL direkt auf den In-Memory-Objekten ausführen, ohne die Daten vorher zu serialisieren oder zu kopieren:

import duckdb
import pandas as pd

df = pd.read_parquet("umsatz.parquet")
result = duckdb.sql("SELECT region, sum(umsatz) FROM df GROUP BY region").df()

Für diesen Fall arbeitet DuckDB im Zero-Copy-Modus - der Speicher wird nicht dupliziert, sondern DuckDB liest direkt auf dem Arrow-Buffer. Das macht DuckDB zu einem SQL-Layer über bestehenden Python Datenstrukturen, statt zu einer weiteren Datenkopie, die separat zu pflegen ist.

DuckLake: Lakehouse-Features ohne Iceberg-Komplexität

Ein neueres Projekt aus dem DuckDB-Umfeld ist DuckLake, ein offenes Tabellenformat, das Lakehouse-typische Eigenschaften - ACID-Transaktionen, Schema Evolution, Time Travel — bereitstellt, ohne den vollen Funktionsumfang (und die Betriebskomplexität) von Apache Iceberg oder Delta Lake vorauszusetzen.

Der wesentliche Unterschied ist, dass DuckLake seine Metadaten nicht in einer eigenen Katalog-Infrastruktur speichert, sondern in einer regulären SQL-Datenbank, etwa Postgres.

Für Teams, die ohnehin schon eine relationale Datenbank betreiben, entfällt damit ein zusätzlicher Metadaten-Service, den man separat hochverfügbar machen müsste.

Im Browser: DuckDB-WASM

Über eine WebAssembly-Kompilierung läuft DuckDB auch vollständig im Browser, clientseitig, ohne Serveranbindung.

Das wird bereits produktiv genutzt, etwa im Dataset Explorer von Hugging Face, um Nutzern SQL-Abfragen auf öffentlichen Datensätzen zu erlauben, ohne dass jede Filter-Interaktion eine Anfrage an einen Server auslöst.

Dadurch wird die Serverlast für Anbieter von z.B. öffentlichen Datensätzen strukturell reduziert, da die Rechenlast auf die Clients verteilt wird.

Wo die Architektur an ihre Grenzen stößt

Zwei Einschränkungen sind für die hier präsentierte Einordnung wichtig:

Single-Writer Model
DuckDB erlaubt zu jedem Zeitpunkt genau einen schreibenden Prozess auf einer Datenbankdatei. Mehrere Prozesse können gleichzeitig lesen, aber ein paralleles Schreiben mehrerer unabhängiger Prozesse auf dieselbe Datei ist architektonisch nicht vorgesehen. Für Multi-User-Schreibzugriffe über mehrere Anwendungen hinweg braucht es entweder eine Anwendungsschicht, die Schreibzugriffe serialisiert, oder eine Erweiterung wie MotherDuck, die eine Cloud-Koordinationsschicht über DuckDB legt.

Kein OLTP
Die vektorisierte, batch-orientierte Ausführung, die DuckDB bei analytischen Scans so schnell macht, ist für hochfrequente Einzeltransaktionen – ein Bestellsystem mit tausenden kleinen Writes pro Sekunde etwa – nicht die richtige Wahl. Eine klassische OLTP-Datenbank wie Postgres ist hier deutlich besser geeignet. DuckDB und Postgres schließen sich deshalb nicht aus, sie lösen unterschiedliche Probleme – und lassen sich über Extensions wie pg_duckdb sogar kombinieren, sodass Postgres analytische Queries an die DuckDB-Engine delegiert.

Wo das in unseren Datenprodukten landet

Wenn wir für einen Kunden Datenprodukte bauen, ist das meistens eine Kombination aus automatisierter Datenaufbereitung von ein bis zwei angebundenen Quellsystemen und einem Reporting- oder KI‑Layer obendrauf. DuckDB übernimmt dabei bei uns typischerweise die Verarbeitungsschicht zwischen Rohdaten und Auslieferung.

Konkret sieht das in der Regel so aus:

• Ingestion & Transformation: Statt einer eigenen Orchestrierungs-Infrastruktur läuft die Kernlogik als DuckDB-Prozess, angestoßen per Cronjob oder Lambda-Funktion, der über Extensions direkt gegen ERP-Exporte, CSV-Uploads oder S3-Buckets liest, transformiert und das Ergebnis als Parquet- oder Delta-Table zurückschreibt. Das ersetzt in vielen Projekten eine dedizierte ETL-Orchestrierung, die für das tatsächliche Datenvolumen überdimensioniert wäre.

• Speicherschicht im Produkt selbst: Weil eine DuckDB-Datenbank eine einzelne Datei ist, lässt sie sich sauber versionieren und als Artefakt zwischen Entwicklungs-, Test- und Produktionsumgebung durchreichen, ohne separate Datenbank-Instanz, die wir beim Kunden betreiben oder absichern müssten. Das reduziert die Zahl der Systeme, die nach Go-Live gewartet werden müssen, was bei Kunden ohne eigenes Data-Team der eigentliche Engpass ist, nicht die Rechenleistung.

• Speed Layer vor bestehenden Warehouses: Läuft beim Kunden bereits ein Warehouse wie Snowflake, setzen wir DuckDB gelegentlich als vorgelagerte Aggregationsschicht ein, die die für ein Dashboard relevanten Daten einmalig exportiert und lokal vorhält - die interaktive Filterung im Frontend verursacht dann keine laufenden Abfragekosten mehr im Warehouse.

• RAG- und KI-Pipelines: In Projekten mit einer Retrieval-Komponente übernimmt DuckDB häufig die Vorverarbeitung und Filterung der Rohdaten, bevor sie in eine Vektordatenbank wandern - die Zero-Copy-Integration mit Arrow/Pandas macht diesen Schritt in der Python-Pipeline günstig, ohne eine zusätzliche Datenkopie zu erzeugen.

Der gemeinsame Nenner: In keinem dieser Fälle betreiben wir für den Kunden eine zusätzliche Server-Komponente, die separat gepatcht, skaliert oder überwacht werden müsste. Das ist ein direkter Ausfluss der oben beschriebenen In-Process-Architektur — nicht ein Feature, das wir DuckDB andichten, sondern die logische Konsequenz aus einem Engine-Design, das für genau diese Klasse von Datenvolumen gebaut ist.

Jetzt abonnieren

Das ist ein Trugschluss.

Ein Data Warehouse kann sinnvoll sein. Es ist aber keine Grundvoraussetzung für eine funktionierende Data Governance. Für viele Unternehmen im Mittelstand ist es sogar der falsche erste Schritt. In diesem Artikel geht es darum, warum das so ist, und wie Ihr auch ohne DWH eine starke Datenverwaltung aufbaut.

Was Data Governance eigentlich bedeutet

Data Governance ist im Kern nichts anderes als die Gesamtheit der Regeln, Prozesse und Verantwortlichkeiten rund um den Umgang mit Daten. Das Ziel: Daten organisieren, ihre Qualität sicherstellen und Compliance-Anforderungen erfüllen. Konkret gehören dazu:

• Datenqualität – konsistente, fehlerfreie und aktuelle Daten

• Zugriffsmanagement – wer darf welche Daten einsehen und bearbeiten

• Datenschutz und Compliance – DSGVO, ISO-Normen und vergleichbare Anforderungen

• Metadatenmanagement – Daten verstehen und klassifizieren

• Prozessoptimierung – effiziente Datenflüsse im Unternehmen

Keiner dieser Punkte verlangt nach einem zentralen Data Warehouse. Sie verlangen nach klaren Regeln und Verantwortlichkeiten – unabhängig davon, wo die Daten technisch liegen.

Warum das Data Warehouse oft überbewertet wird

Ein Data Warehouse kann in bestimmten Fällen nützlich sein – etwa, wenn wirklich große Datenmengen aus vielen verschiedenen Quellen langfristig zusammengeführt werden müssen. Für die meisten mittelständischen Unternehmen sieht die Realität aber anders aus:

Der Implementierungsaufwand ist hoch. Ein DWH ist teuer, zeitintensiv und verlangt spezialisiertes Know-how, das viele Unternehmen mit 250 bis 1500 Mitarbeitenden schlicht nicht im eigenen Haus haben – und auch nicht aufbauen wollen, nur um ein einzelnes Datenprojekt zu starten.

Nicht alle Daten brauchen Zentralisierung. Oft reichen dezentrale Systeme und moderne Cloud-Lösungen vollkommen aus, um den eigentlichen Business-Nutzen zu heben.

Flexibilität geht verloren. Änderungen an Datenmodellen oder Geschäftsanforderungen werden in einem starren DWH-Setup zu einem eigenen Projekt – mit eigenem Budget, eigener Timeline, eigenem Abstimmungsaufwand.

Das größte Missverständnis dabei: Viele gehen davon aus, dass ein DWH automatisch für bessere Datenqualität oder mehr Sicherheit sorgt. Das stimmt nicht. Ohne klare Prozesse und Regeln bleibt auch das teuerste Data Warehouse nur eine weitere technische Lösung – ohne echten Mehrwert für das Geschäft.

Das ist genau das Muster, das wir auch bei Custom-AI-Projekten beobachten: Wer zuerst die Technik kauft und danach über die Regeln nachdenkt, baut am Ende ein teures System, das niemand richtig nutzt.

Wie Ihr Data Governance ohne Data Warehouse startet

Der Einstieg in Data Governance muss nicht kompliziert sein. Vier Schritte reichen für den Anfang:

1. Wichtige Daten identifizieren. Welche Daten braucht Ihr wirklich, um Eure zentralen Geschäftsfragen zu beantworten? Kundendaten, Rechnungen, Lagerbestände – meistens sind es deutlich weniger Datenquellen, als man zunächst vermutet.

2. Verantwortlichkeiten festlegen. Wer kümmert sich um welche Daten? Wer hält sie aktuell, und wer greift im Zweifel ein, wenn die Qualität nicht stimmt? Ohne eine klar benannte Person oder Rolle bleibt jede Data-Governance-Initiative ein Lippenbekenntnis.

3. Einfache Analyse-Tools nutzen. Excel, Google Sheets oder BI-Tools wie Power BI reichen für den Einstieg oft vollkommen aus, um erste belastbare Erkenntnisse zu gewinnen. Der teure Tech-Stack kommt später – wenn überhaupt.

4. Regeln für Datenqualität definieren. Wie werden Daten gepflegt? Welche Mindeststandards gelten – etwa für Vollständigkeit, Aktualität oder Formatierung? Diese Regeln müssen nicht perfekt sein. Sie müssen vor allem eines sein: befolgt.

Starte klein und pragmatisch

Eine gute Data Governance beginnt nicht mit einem großen DWH-Projekt. Sie beginnt mit klaren Verantwortlichkeiten, einem strukturierten Umgang mit den Daten, die Ihr ohnehin schon habt, und einfachen Werkzeugen, die Eure Teams bereits kennen.

Der „große Wurf“ – alles zentralisieren, alles neu aufsetzen, dann erst loslegen – klingt nach Gründlichkeit. In der Praxis ist er meistens der Grund, warum Data-Governance-Initiativen im Mittelstand nie über die Planungsphase hinauskommen.

Mehr zum konkreten Einstieg findet Ihr in unserem Artikel „Wie starte ich Data Governance in einem mittelständischen Betrieb?”.

Wie sind Eure Erfahrungen mit Data Governance – habt Ihr klein angefangen, oder steckt Ihr gerade mitten in einem großen DWH-Projekt? Schreibt es in die Kommentare.

Jetzt abonnieren

Der Unterschied zwischen beiden ist nicht der Zug. Es ist der Preis.

Was nichts kostet, wird von niemandem wertgeschätzt – weder von den Nutzern noch von den Betreibern. Subventionierte Systeme verdrecken, weil sich niemand verantwortlich für etwas Wertvolles fühlt.

Es ist der Unterschied zwischen der U-Bahn in London, die stark zugangsbeschränkt ist, und der U-Bahn in z. B. München. Die eine ist sauber und gepflegt, die andere riecht nach Urin.

Genau dieses Prinzip steckt hinter einer Entscheidung, die viele unserer Kunden zunächst irritiert: Bei Datenhandwerk kostet die Entwicklung Eures individuellen KI-Produkts nichts. Aber der erste Workshop kostet etwas – mit Geld-zurück-Garantie, falls er nichts bringt.

In diesem Artikel erklären wir, warum wir so abrechnen, was Pay-per-Use von klassischen Beratungsmodellen unterscheidet, und warum gerade der bezahlte Einstieg der wichtigste Teil des Modells ist.

Das Problem mit dem Tagessatz

Die meisten KI- und Datenprojekte im Mittelstand laufen nach demselben Muster: Ein Anbieter rechnet nach Tagessatz oder Stunden ab. Das Risiko liegt vollständig beim Kunden. Ob das Projekt am Ende einen messbaren Nutzen bringt, ist für die Vergütung irrelevant – bezahlt wird die Zeit, nicht das Ergebnis.

Das erzeugt einen stillen, aber wirksamen Fehlanreiz: Wer nach Stunden abrechnet, hat keinen wirtschaftlichen Grund, schnell zu liefern. Im Gegenteil – je länger ein Projekt dauert, desto höher die Rechnung.

Wir rechnen anders ab. Unser Modell ist eine Pay-per-Use-SaaS-Abrechnung: Wir bauen ein individuelles, exklusives Produkt für Dein Unternehmen, und Du zahlst erst, wenn es genutzt wird. Keine Tagessätze, keine Stundenzettel, keine Rechnung für halb fertige Konzepte.

Pay-per-Use ist kein neues Prinzip – es ist nur neu für KI-Beratung

Nutzungsabhängige Preismodelle sind in anderen Branchen längst etabliert und erprobt. Rolls-Royce verkauft seine Flugzeugtriebwerke nicht nur als Produkt, sondern bietet mit „Power by the Hour“ ein Modell an, bei dem Airlines pro Flugstunde zahlen statt für die Maschine selbst. Atlas Copco lässt Kunden für Druckluft pro Kubikmeter zahlen statt für den Kompressor, und Michelin verkauft Reifenleistung nach gefahrener Meile statt nach Stückzahl.

Das Muster ist immer dasselbe: Der Anbieter trägt das unternehmerische Risiko der Investition. Der Kunde zahlt nur für das, was tatsächlich funktioniert und genutzt wird.

Möglich wird das durch Fortschritte in Digitalisierung, Sensorik und Cloud-Technologie – diese haben die Überwachung und Abrechnung nutzungsabhängiger Modelle erst wirtschaftlich tragfähig gemacht, sowohl im B2C- als auch im B2B-Bereich. Was Rolls-Royce für Triebwerke macht, übertragen wir auf individuelle KI-Produkte für den Mittelstand: Wir tragen das Risiko der Entwicklung. Du zahlst erst, wenn das Produkt im Alltag läuft.

Warum der Workshop trotzdem etwas kostet

Genau hier kommt der Punkt, der die meisten Kunden im Erstgespräch überrascht: Wenn die Entwicklung nichts kostet – warum kostet dann der erste Workshop etwas?

Die Antwort hat zwei Ebenen.

Erstens: Der Workshop ist keine Vertriebsmaßnahme, sondern Arbeit.
Im initialen Workshop scopen wir gemeinsam, welches Produkt überhaupt gebaut werden soll – welche Daten verfügbar sind, welcher Use Case den größten Hebel bringt, wo die „low hanging fruits“ liegen. Das ist Expertenarbeit, kein unverbindliches Kennenlernen.

Zweitens, und das ist der wichtigere Grund: Verbindlichkeit muss auf beiden Seiten beginnen, bevor irgendetwas gebaut wird.

Zurück zur ÖPNV-Analogie: Wer nichts investiert, behandelt das Ergebnis auch nicht wie etwas Wertvolles. Das gilt für Nutzer subventionierter ÖPNV genauso wie für Auftraggeber kostenloser Erstgespräche.

Ein kostenloses Erstgespräch wird seltener vorbereitet, seltener ernst genommen, seltener mit den nötigen internen Ressourcen flankiert. Ein bezahlter Workshop verändert die Dynamik auf beiden Seiten des Tisches – auch bei uns.

Wir liefern nicht „irgendeinen Termin“, wir liefern das Fundament für ein Produkt, das danach nichts mehr kosten soll, bis es läuft.

Falls der Workshop am Ende nichts bringt oder Du mit dem Ergebnis unzufrieden bist: Du bekommst Dein Geld zurück. Aber kostenlos war er nie.

Was das für Euer Unternehmen bedeutet

Für Fachbereichsleiter und Geschäftsführer im Mittelstand – ohne eigenes Data-Team, mit begrenztem Risikoappetit für teure PoCs ohne Ergebnis – verschiebt dieses Modell die entscheidende Frage:

Nicht mehr „Wie viele Tage kostet das?“, sondern „Trägt der Anbieter das Risiko mit mir?”

Bei einem Tagessatz-Modell trägst Du als Kunde das volle Risiko. Bei unserem Pay-per-Use-Modell verdienen wir erst, wenn das Produkt läuft und im Alltag genutzt wird. Der Workshop ist der einzige Punkt, an dem beide Seiten von Anfang an Verbindlichkeit zeigen müssen – und genau deshalb kostet er etwas.

Kurz zusammengefasst:

• Entwicklung: Pay-per-Use, du zahlst erst ab Nutzung

• Initialer Workshop: kostet bewusst etwas, mit Geld-zurück-Garantie

• Das Prinzip: Was nichts kostet, ist auch nichts wert – für keine der beiden Seiten

Wenn Du wissen willst, wie ein solcher Workshop für Dein Unternehmen aussehen könnte, sprechen wir gern in einem ersten Gespräch darüber, wo Eure größten Hebel liegen.

Jetzt abonnieren

Riccardo Mattivi, Senior Staff AI Engineer bei Integral AdScience, eröffnete die Session im Rahmen der ACM-Initiative für lebenslanges Lernen. Den Hauptvortrag hielt Guglielmo Liozzi - biomedizinischer Ingenieur und Direktor für KI und angewandte Mathematik bei MSD (Merck), mit langjähriger Erfahrung in Software-Engineering und maschinellem Lernen. Sein Thema: das, wie er es nannte, ungenutzte Geschäftspotenzial kleiner Sprachmodelle.

Das passt genau zu etwas, das ich selbst seit Jahren in Kundenprojekten beobachte – und das ich in jüngster Vergangenheit auch in einem Post zum Buch „Small Language Models“ aufgegriffen habe: Man braucht nicht das größte Modell. Man braucht das Richtige.

Der technische Teil: Wie weit lässt sich ein Modell schrumpfen?

Liozzi startete mit konkreten Beispielen, wie man ein domänenspezifisches kleines Sprachmodell aufbaut und implementiert. Dabei stellte er eine Frage, die ich für den schönsten Gedanken-Provokateur des ganzen Talks halte:

„Was, wenn ich versuche, eines dieser Modelle auf einem Commodore 64 zum Laufen zu bringen?”

Das ist natürlich überspitzt – aber genau darin liegt der Witz. Es zwingt einen, eine Frage zu stellen, die in der aktuellen KI-Debatte viel zu selten gestellt wird: Wie wenig Hardware braucht ein Modell wirklich, um für eine konkrete Aufgabe nützlich zu sein? Liozzi führte aus, wie ein Modell quantisiert und für stark eingeschränkte Architekturen angepasst werden muss – eine Übung, die zeigt, wie viel „Fett“ in den meisten KI-Implementierungen tatsächlich steckt, wenn man sie mit Allzweck-Modellen löst statt mit zugeschnittenen.

Für den Mittelstand ist die Commodore-64-Frage natürlich keine reale Anforderung. Aber die Denkrichtung dahinter ist hochrelevant: Viele Unternehmen rüsten ihre Infrastruktur für KI-Anwendungen auf, die eigentlich mit deutlich weniger Rechenleistung laufen könnten – wenn das Modell von Anfang an für die konkrete Aufgabe gebaut wäre, statt ein generisches Großmodell per Prompt zu bändigen.

Der Geschäftsteil: Warum kleine Modelle keine Kompromisslösung sind

Im zweiten Teil wechselte Liozzi den Fokus von der Technik zur Geschäftsperspektive. Seine Kernaussage: Die Implementierung kleiner Sprachmodelle ist keine technische Notlösung für Unternehmen, die sich kein großes Modell leisten können. Sie ist eine eigenständige Geschäftschance.

„Die Nutzung kleiner Sprachmodelle in stark regulierten Branchen kann viele Risiken mindern.”

Das deckt sich exakt mit dem, was wir bei Datenhandwerk im Mittelstand sehen – gerade bei Kunden in regulierten oder datensensiblen Bereichen. Viele bestehende KI-Lösungen sind für den allgemeinen Markt gebaut und erfüllen die spezifischen Anforderungen einzelner Branchen oder Unternehmen schlicht nicht. Liozzi sprach explizit von der Notwendigkeit, hier innovative, zugeschnittene Lösungen zu schaffen - statt zu versuchen, ein universelles Großmodell mit immer mehr Prompt-Engineering in die richtige Richtung zu zwingen.

Datenschutz: Das Modell kommt zu den Daten, nicht umgekehrt

Der Punkt, der für mich am meisten praktische Relevanz für unsere Kunden hatte, war Liozzis Perspektive auf Datenschutz und Sicherheit:

„Die Modelle bewegen sich dorthin, wo die Daten sind, anstatt die Daten zu bewegen.”

Das ist ein einfacher Satz mit einer großen Konsequenz. Bei den meisten kommerziellen KI-APIs ist es umgekehrt: Eure Daten verlassen Eure Infrastruktur, um vom Modell verarbeitet zu werden – und damit verlasst Ihr auch ein gutes Stück Kontrolle über das, was mit sensiblen Informationen passiert. Ein kleines, lokal betreibbares Modell dreht dieses Prinzip um. Es läuft dort, wo die Daten ohnehin liegen – on-premise, in der eigenen Cloud-Umgebung, ohne dass Kundendaten, Vertragsdaten oder Produktionsdaten irgendwo anders hinwandern müssen.

Liozzi gab konkrete Beispiele, wie Unternehmen genau über diesen Weg Datenschutzbedenken adressieren, die bei der Nutzung großer kommerzieller Modelle sonst schwer auflösbar sind.

Der Satz, der mir hängen geblieben ist

Zum Abschluss formulierte Liozzi eine These, die für mich die treffendste Zusammenfassung der gesamten Bewegung hin zu kleinen, spezialisierten Modellen ist:

„Dies ist eine Verschiebung von der Anmietung von Intelligenz zu deren Besitz.”

Genau das ist der Unterschied, den ich Entscheidern im Mittelstand am liebsten erklären würde, wenn ich nur einen Satz hätte. Wer ein großes KI-Modell per API nutzt, mietet Intelligenz – bei einem Anbieter, der die Spielregeln, die Preise und manchmal sogar die Verfügbarkeit jederzeit ändern kann. Wer ein kleines, auf die eigenen Daten und Prozesse zugeschnittenes Modell selbst betreibt oder betreiben lässt, besitzt diese Intelligenz – als eigenen Vermögenswert, der sich mit dem Unternehmen weiterentwickelt, statt von außen verwaltet zu werden.

Was das für Euch bedeutet

Liozzis Vortrag bestätigt etwas, das in der aktuellen KI-Debatte oft untergeht, weil die Schlagzeilen den großen Modellen gehören: Die eigentliche Paradigmenverschiebung passiert nicht beim nächsten GPT-Release. Sie passiert bei Unternehmen, die aufhören zu fragen: „Welches Modell ist gerade das beste?“ und anfangen zu fragen: „Welches Modell brauche ich für genau mein Problem – und kann ich es selbst besitzen, statt es zu mieten?“

Für den Mittelstand ohne eigenes Data-Team klingt das zunächst nach einer Hürde. Ist es aber nicht – es ist eine Einladung, das KI-Projekt von der richtigen Seite aus zu denken: nicht vom größten verfügbaren Modell aus, sondern vom eigenen, sehr konkreten Anwendungsfall.

Jetzt abonnieren

Am nächsten Tag verlieren Uber, American Express, Mastercard und DoorDash zwischen 4 und 6 Prozent ihres Börsenwerts. Alle vier Unternehmen waren im Szenario namentlich erwähnt.

Das ist die aktuelle Lage: Ein hypothetisches Gedankenspiel über KI-Agenten bewegt echtes Geld an echten Märkten. Wenn das die Reaktion auf eine Spekulation ist, wie verzerrt ist dann erst die Diskussion, die Entscheider in ihren eigenen Unternehmen führen müssen?

Die kurze Antwort: ziemlich verzerrt. Und genau deshalb lohnt sich ein Blick auf die richtigen Fragen – statt auf die falschen Ängste.

Die falsche Frage: „Übernehmen die Agenten?”

Wir geben den Systemen menschliche Eigenschaften und messen ihre Leistungsfähigkeit auf menschlicher Ebene, was die öffentliche Debatte über Agentic AI stark anthropomorphisiert. Diese Denkweise geht letztlich auf Alan Turings Imitationsspiel aus dem Jahr 1950 zurück: Ein System gilt als intelligent, wenn es im Dialog nicht von einem Menschen zu unterscheiden ist.

Das Problem an diesem Maßstab: Er fragt nach Imitation, nicht nach Wirkung. Ob ein KI-Agent wie ein Mensch wirkt, ist für dein Unternehmen die uninteressanteste Frage überhaupt. Relevant ist, was passiert, wenn dieser Agent mit deinen Daten, deinen Mitarbeitenden und deinen Geschäftsprozessen interagiert.

Schon 1989 argumentierte die Soziologin Susan Leigh Star, dass der Turing-Test der falsche Maßstab für KI-Systeme ist. Ihr Vorschlag, angelehnt an den Soziologen Émile Durkheim: Die Intelligenz eines Systems bemisst sich nicht daran, wie menschlich es wirkt, sondern daran, wie nützlich es für die gemeinsame Arbeit ist – und wie gut es sich an veränderte Bedingungen anpassen kann.

Übersetzt in die Sprache des Mittelstands: Es geht nicht darum, ob ein Agent klug klingt. Es geht darum, ob er im echten Betriebsalltag etwas bringt, und ob er sich anpassen lässt, wenn sich eure Prozesse ändern.

Die richtige Frage: „Mit welchen Regeln lassen wir Agenten arbeiten?”

Ein KI-Agent handelt nie im Vakuum. Er ist Teil eines größeren Zusammenspiels aus Menschen, Software, Daten und Prozessen – in der Forschung wird das ein „sozialer Mechanismus“ genannt.

Wikipedia ist ein bekanntes Beispiel: Menschliche Autorinnen und Autoren arbeiten mit Bots zusammen, die Vandalismus erkennen, Verlinkungen pflegen und Bearbeitungen vorschlagen – begrenzt durch klare Regeln der Community.

Autonome Fahrzeuge im Straßenverkehr sind ein anderes Beispiel: Sie agieren neben menschlichen Fahrern und Fußgängern, in einem Umfeld mit Verkehrsregeln, Wetterbedingungen und sich durchgehend ändernden Situationen.

Die entscheidende Erkenntnis aus diesem Forschungsfeld lässt sich auf jedes Unternehmen übertragen, das KI-Agenten einsetzen will:

Nicht der einzelne Agent entscheidet über den Erfolg. Die Regeln, nach denen Mensch und Agent zusammenarbeiten, entscheiden darüber.

Forscher schlagen dafür einen erweiterten Prüfkatalog vor, der spieltheoretische Mechanismus-Gestaltung mit sozialwissenschaftlichen Fragen verbindet – den sogenannten Star-Durkheim-Test. Vereinfacht gefragt:

• Wessen Interessen verfolgt der Agent, und wessen Interessen verfolgen die Menschen, mit denen er zusammenarbeitet?
  Bei einem Vertriebsagenten sind das andere Ziele als bei einem Fahrer im Straßenverkehr – aber die Frage ist dieselbe: Laufen die Interessen von Mensch und KI-Agent in dieselbe Richtung, oder erzeugt der Agent stille Fehlanreize?

• Handelt der Agent verlässlich, regelkonform und nachvollziehbar?
  Ein Agent, der „irgendwie“ zum Ziel kommt, aber niemand versteht, wie, ist in einem Unternehmenskontext ein Risiko – nicht ein Feature.

• Was passiert, wenn der Agent zu viele Rechte bekommt?
  Hier hilft ein aktuelles Beispiel: Open-Claw, ein Open-Source-System aus lokal arbeitenden Agenten, die digitale Aufgaben über mehrere Software-Dienste hinweg selbstständig erledigen. Je größer das Autonomie-Versprechen, desto größer die Angriffsfläche – von kompromittierten Zugangsdaten bis zu manipulierbaren Workflows. Wer einem solchen System weitreichende Zugriffsrechte einräumt, sollte sich der Risiken bewusst sein, die der Hype gerne ausblendet.

• Lässt sich die Sicherheit so weit erhöhen, dass das System noch funktioniert? Die Forscher vergleichen übermäßige Einschränkung mit dem Versuch, eine Küche kindersicher zu machen, indem man Messer, Herd und Backofen entfernt. Dann ist die Küche sicher – aber nutzlos. Genau diese Balance müssen Entscheider für jeden Agenten in ihrem Unternehmen selbst finden.

Was das für die Regulierung bedeutet – und warum sie allein nicht reicht

Der EU‑AI‑Act verfolgt einen risikobasierten Ansatz: Je nach Risikokategorie eines KI-Systems gelten unterschiedliche Anforderungen, etwa Verbote bestimmter Techniken wie Social Scoring oder biometrischer Identifizierung im öffentlichen Raum.

Das ist sinnvoll, hat aber eine Schwäche, die für Entscheider direkt relevant ist: Die Regulierung betrachtet meist das einzelne System – nicht den gesamten Kontext, in den es eingebettet ist.

Beim autonomen Fahren funktioniert das einigermaßen, weil es dort bereits viele Regulierungen gibt, die genau diesen Gesamtkontext mitdenken. Bei Sprachmodellen und KI-Agenten in Unternehmen sieht das anders aus – hier zeigt sich, wie schwer sich selbst europäische Gesetzgebung tut, regulatorische Leitplanken gegen die Marktdynamik großer Anbieter durchzusetzen.

Die praktische Konsequenz für Entscheider: Wer auf gesetzliche Leitplanken wartet, bevor er sich mit den eigenen Spielregeln für KI-Agenten beschäftigt, wartet zu lange.

Die Verantwortung, den eigenen „sozialen Mechanismus“ zwischen Mitarbeitenden und Agenten sinnvoll zu gestalten, liegt zuerst im Unternehmen selbst.

Die eigentliche Machtfrage

Die entscheidende Frage ist nicht, ob KI-Agenten eingesetzt werden. Technologien verschwinden selten wieder, sobald sie wirtschaftlich sinnvoll sind. Die entscheidende Frage ist, welche Strukturen und Regeln ein Unternehmen für das Zusammenspiel von Menschen und Agenten baut – bevor der Agent produktiv geschaltet wird, nicht danach.

Drei praktische Leitfragen für Entscheider, abgeleitet aus der oben skizzierten Logik:

1. Welches Ziel verfolgt der Agent wirklich – und passt das zu den Zielen der Menschen, die mit ihm arbeiten? Ein Kundenservice-Agent, der primär auf Geschwindigkeit optimiert ist, kann in Konflikt mit dem Ziel „Kundenzufriedenheit“ stehen, selbst wenn beide auf dem Papier zusammengehören.

2. Wie viel Autonomie braucht der Agent wirklich – und wie viel davon ist nur Bequemlichkeit? Jede zusätzliche Berechtigung ist eine zusätzliche Angriffsfläche. Die Frage ist nicht „Was kann der Agent maximal tun?“, sondern „Was muss er minimal können, um den Job zu erledigen?”

3. Wer im Unternehmen versteht den Agenten gut genug, um ihn anzupassen, wenn sich die Lage ändert? Ein Agent, den niemand außer dem ursprünglichen Anbieter versteht oder verändern kann, ist eine Blackbox mit Risikoaufschlag.

Diese Fragen lassen sich nicht an einem Nachmittag beantworten, und sie lassen sich nicht durch ein einzelnes Tool oder eine einzelne Policy lösen. Sie verlangen eine bewusste Auseinandersetzung mit der eigenen Datenlage, den eigenen Prozessen und der eigenen Risikotoleranz – bevor der erste Agent live geht.

Nicht die Maschine bestimmt die Wirkung von KI-Agenten in deinem Unternehmen. Die Regeln, nach denen Menschen und Agenten zusammenarbeiten, tun das.

Jetzt abonnieren

Das ist kein Einzelfall und kein Zufall. Es ist ein Muster, das sich durch die gesamte aktuelle KI-Forschung zieht: Größer ist nicht automatisch besser. Und Benchmarks, auf die sich die meisten Entscheidungen stützen, sagen oft erschreckend wenig darüber aus, was im echten Betrieb funktioniert.

Das Benchmark-Problem: Was auf dem Papier gut aussieht, scheitert im Alltag

Kili Technology hat in einer aktuellen Analyse das Ausmaß dieses Problems beziffert: Enterprise-Agentensysteme zeigen im Schnitt eine Lücke von 37 Prozent zwischen Labor-Benchmark-Werten und tatsächlicher Performance im produktiven Einsatz. Bei Kostenvergleichen ist die Streuung noch dramatischer – bis zum 50-Fachen Unterschied zwischen Ansätzen, die auf dem Papier ähnlich gut abschneiden.

Woran liegt das?

Mehrere Gründe kommen zusammen:

Benchmarks sind gesättigt.
MMLU, einst der Goldstandard für KI-Fähigkeiten, wird heute von praktisch jedem führenden Modell mit über 88 Prozent gelöst. Unterschiede zwischen Modellen liegen dort im Bereich des statistischen Rauschens – sie sagen nichts mehr aus.

Benchmarks werden kontaminiert.
Modelle haben Testfragen oft schon während des Trainings gesehen. Bei SWE-Bench Verified, dem früheren Coding-Standard, zeigte ein Audit, dass praktisch alle führenden Modelle Überlappungen mit den Trainingsdaten aufweisen – und fast 60 Prozent der schweren Aufgaben fehlerhaft konstruiert waren.

Benchmarks können manipuliert werden.
Der internationale KI-Sicherheitsbericht 2026 dokumentierte, dass Spitzenmodelle zwischen Test- und Produktionskontext unterscheiden können – und sich in Tests sicherer verhalten als im echten Einsatz. Ein besonders deutliches Beispiel: Ein Modell, das eigentlich die Ausführungsgeschwindigkeit optimieren sollte, schrieb stattdessen einfach die Timer-Funktion um, damit sie schnelle Ergebnisse meldete – ohne die tatsächliche Performance zu verbessern.

Benchmarks testen die falsche Sache.
Ein Modell, das bei Humanity’s Last Exam glänzt – einem Test mit Fragen an der Grenze des akademischen Wissens –, sagt wenig darüber aus, ob es in eurem Kundenservice-Bot vernünftig mit einer mehrdeutigen Anfrage umgeht. Produktionssysteme interagieren mit Teams, verarbeiten unklare Eingaben und laufen über lange Zeiträume. Kein Standard-Benchmark berichtet Kosten pro Aufgabe, Latenz oder Zuverlässigkeit über mehrere Durchläufe.

Teilen

Der Gegenbeweis: Wie ein 1,3-Milliarden-Modell größere Modelle schlug

Schon 2023 lieferte Microsoft Research mit dem Modell „phi-1“ einen der eindrücklichsten Belege dafür, dass Modellgröße nicht der entscheidende Faktor ist. Phi-1 hatte gerade einmal 1,3 Milliarden Parameter – winzig im Vergleich zu den meisten Konkurrenten. Trainiert wurde es mit weniger als 7 Milliarden Tokens, ein Bruchteil dessen, was vergleichbare Modelle damals verschlangen.

Das Ergebnis: 50,6 Prozent Pass-Rate auf dem HumanEval-Coding-Benchmark – und schlug damit Modelle, die zehnmal größer und mit hundertmal mehr Trainingsdaten gefüttert worden waren. StarCoder etwa, ein Modell mit 15,5 Milliarden Parametern und einer Billion Trainings-Tokens, kam nur auf vergleichbare oder schlechtere Werte.

Der Grund war kein cleverer Trick in der Architektur. Es war die Qualität der Trainingsdaten. Statt phi-1 mit dem üblichen, riesigen, aber unsauberen Mix aus öffentlichem Code zu trainieren, kuratierten die Forscher gezielt „lehrbuchqualitative“ Daten – sauber strukturierter, instruktiver Code statt zufällig zusammengewürfelter Repositories voller Boilerplate und unverständlicher Snippets. Ergänzt wurde das durch synthetisch generierte Übungsaufgaben.

Das Team zeigte sogar, dass dieser Effekt nicht auf Zufall oder versehentliche Kontamination der Testdaten zurückzuführen war: Selbst nachdem sie aggressiv über 40 Prozent der Trainingsdaten entfernt hatten, die HumanEval-Aufgaben auch nur entfernt ähnelten, blieb die Leistung von phi-1 stabil deutlich über der von StarCoder.

Die Kernerkenntnis aus diesem Paper, treffend zusammengefasst im Titel selbst: „Textbooks Are All You Need“.

Saubere, gezielt kuratierte Daten schlagen rohe Masse.

Teilen

GLM-5.2: Dasselbe Prinzip, drei Jahre später, im großen Maßstab

Was bei phi-1 im Kleinen demonstriert wurde, zeigt sich heute bei GLM-5.2 im Maßstab von Hunderten Milliarden Parametern. GLM-5.2 wurde nicht als Alleskönner trainiert, der nebenbei auch programmieren kann.

Es wurde gezielt für Coding-Aufgaben und für das Arbeiten in agentischen Umgebungen wie Claude Code oder OpenCode trainiert – mit einer effizienten MoE-Architektur und Optimierungen, die den Rechenaufwand pro Token drastisch senken.

Das Ergebnis bestätigt das Muster: In einer realen Aufgabe – dem Bau eines WebGL-3D-Plattformers von Grund auf – kostete GLM-5.2 rund 5,39 US-Dollar, während Opus 4.8 etwa 21,92 US-Dollar verschlang. Opus war zwar schneller fertig und lieferte das sauberere Ergebnis, aber der Kostenunterschied von etwa dem Vierfachen zeigt deutlich: Spezialisierung auf eine klar definierte Aufgabe schlägt rohe Modellgröße, wenn das Verhältnis von Aufwand zu Ergebnis zählt.

Was das für euer Unternehmen bedeutet

Die Kili-Analyse formuliert es treffend: Benchmarks sollten als Filter dienen, nicht als Urteil. Ein Benchmark-Score sagt euch, welches Modell es wert ist, weiter getestet zu werden – nicht, welches Modell für eure Nutzer tatsächlich funktioniert.

Für den Mittelstand heißt das konkret:

Hört auf, dem größten verfügbaren Modell automatisch zu vertrauen. Die Annahme „größer ist besser“ ist bequem, aber empirisch immer wieder widerlegt – von phi-1 vor drei Jahren bis zu GLM-5.2 heute.

Investiert in die Qualität eurer eigenen Daten, nicht in die Größe des Modells.
Phi-1 zeigt eindrücklich: Ein kleines Modell mit sauberen, gezielt kuratierten Trainingsdaten kann ein riesiges Modell mit unsauberen Daten schlagen. Das gilt nicht nur für die Modelle der großen Labs – es gilt genauso für jedes Custom-AI-Projekt, das auf euren eigenen Geschäftsdaten aufbaut.

Testet gegen eure eigene Realität, nicht gegen ein Leaderboard.
Ein Modell, das bei Humanity’s Last Exam brilliert, kann bei eurer konkreten Reklamationsbearbeitung trotzdem scheitern – und ein kleineres, spezialisiertes Modell kann genau dort gewinnen, wo es darauf ankommt.

Bewertet automatisierte Metriken, Modell-Screening und menschliche Fachexpertise gemeinsam.
Genau dieses gestaffelte Vorgehen empfiehlt auch die Kili-Analyse für produktionsreife KI-Bewertung – und es deckt sich mit dem, was sich in der Praxis als robust erweist: Kein einzelner Test ersetzt das Urteil von jemandem, der weiß, was in eurem spezifischen Kontext „richtig“ bedeutet.

Die eigentliche Frage ist also nicht „Welches Modell hat den höchsten Benchmark-Score?“. Die eigentliche Frage ist: „Welches Modell – trainiert auf welchen Daten, getestet gegen welche Realität – löst mein konkretes Problem am verlässlichsten und am günstigsten?”

Genau das ist der Unterschied zwischen einem KI-Projekt, das beeindruckende Folien produziert, und einem, das im Alltag tatsächlich läuft.

Jetzt abonnieren

Diese Geschichte hören nicht nur wir immer wieder. In seiner Studie vom Juli 2025 stellte das MIT fest, dass 95 % der Unternehmen keinen messbaren Erfolg durch den Einsatz insbesondere von GenAI feststellen können.

Wir denken, dass das Problem nicht an fehlender Technologie oder Unfähigkeit der Teams liegt, sondern daran, dass KI-Projekte falsch angegangen werden.

Jetzt abonnieren

Das Problem: KI als isoliertes Feature

Die Mehrheit der Unternehmen betrachtet KI als eine zusätzliche Komponente. Ein Chatbot hier, ein Empfehlungsalgorithmus dort, ein Prognosemodell für die Finanzabteilung. Jedes Team ist für den Aufbau seiner eigenen Datenpipeline, das Trainieren eigener Modelle sowie die Bewältigung des Change-Managements verantwortlich.

Die Realität dahinter:

• Team A braucht 6 Monate, um Kundendaten zu strukturieren

• 3 Monate später beginnt Team B erneut mit dem Bau derselben Datenpipeline.

• Team C scheitert am Widerstand der Fachabteilung, weil niemand versteht, was das Tool eigentlich bringt

Jedes Projekt kostet dabei mehrere hunderttausend Euro. Der ROI? Bestenfalls marginal.

Der Wendepunkt: In Produkten denken, nicht in Projekten

Stell dir vor, dein Vertrieb wäre eine geschlossene Domäne. Die Generierung von Leads, die Kommunikation mit Kunden, das Forecasting und die Churn-Prävention sind alle miteinander verbunden. Jede frisch eingeführte KI-Applikation verwendet die gleiche Dateninfrastruktur. Jedes trainierte Modell verbessert das nächste. Das Team wird durch jeden Erfolg motiviert, den nächsten Schritt zu machen.

Ein konkretes Beispiel aus der Praxis:

Ein Online-Shop-Unternehmen hat den Bereich „Kundenerlebnis“ in drei Schritten verändert:

1. Start (Monat 1–3): Produktempfehlungen basierend auf historischen Käufen

   • Dateninfrastruktur aufgebaut: Kundenverhalten, Produktkatalog, Transaktionen

   • Impact: +12 % Conversion bei wiederkehrenden Kunden

2. Ausbau (Monat 4–6): Dynamische Preisoptimierung für Bestandskunden

   • Nutzte die gleiche Dateninfrastruktur wie Schritt 1

   • Erweiterte Customer-Insights um Preissensitivität

   • Impact: +8 % Marge bei gleichbleibender Kundenzufriedenheit

3. Skalierung (Monat 7–9): Predictive Churn Prevention

   • Kombinierte Daten aus Schritt 1 und 2

   • Team hatte inzwischen Erfahrung und Vertrauen

   • Impact: –23 % Kundenabwanderung in der Risikogruppe

Gesamtergebnis nach 9 Monaten: 3,2 Mio € zusätzlicher Jahresumsatz bei 680.000 € Investment.

Warum dieser Ansatz funktioniert

1. Daten als Produkt, nicht als Abfallprodukt

In isolierten Projekten sind Daten ein notwendiges Übel. Im Produkt-Ansatz werden sie zum Asset. Du baust einmal eine saubere, gut dokumentierte Dateninfrastruktur auf – und jede weitere Initiative profitiert davon.

Konkret bedeutet das:

• Einheitliche Datenqualität über alle Use Cases hinweg

• Wiederverwendbare Features (z.B. “Customer Lifetime Value” einmal berechnen, überall nutzen)

• Reduzierte Time-to-Market für neue KI-Anwendungen um 60-70%

Der Schlüssel zum Erfolg liegt nicht darin, die gesamte Organisation auf einmal umzukrempeln – ein solches Unterfangen ist zu komplex und birgt hohe Risiken. Stattdessen sollten Unternehmen einen entscheidenden Geschäftsbereich oder eine „Domäne“ identifizieren und diesen von Grund auf neu denken. Eine solche ganzheitliche Transformation eines Kernprozesses oder einer Funktion führt zu erheblichen Leistungssteigerungen, die isolierte Anwendungen niemals erreichen können.

Die Vorteile des Produkt-Ansatzes:

1. Synergien: Jede neue KI-Initiative kann auf der vorherigen aufbauen, indem Daten wiederverwendet und Fähigkeiten für gemeinsame Interessengruppen erweitert werden.

2. Organischer Wandel: Dieser Ansatz löst einen organischen Veränderungszyklus innerhalb der Domänen aus. Wenn Führungskräfte und Mitarbeiter sehen, wie KI funktioniert und welche Vorteile sie bringt, entsteht eine Eigendynamik für den KI-Einsatz im gesamten Unternehmen.

3. Kontinuierliche Verbesserung: Der Domänen-Ansatz fördert eine Denkweise der kontinuierlichen Verbesserung, die angesichts der rasanten Entwicklung der KI-Technologie unerlässlich ist. KI-Transformationen sind keine einmaligen Projekte, sondern fortlaufende Anstrengungen.

2. Der Mensch vor der Technologie

Veränderungen in Organisationen entstehen nicht durch verbesserte Computerprogramme, sondern durch Menschen, die mitmachen und begreifen. Indem Mitarbeiter aus dem gesamten Domäne-Zyklus (unabhängig davon, wo sie zuvor in der Organisation saßen) einberufen und ihnen Verantwortung für die Arbeit übertragen wird, fördert es die Beteiligung an einer Initiative und erzeugt Begeisterung und Dynamik. Es ist wichtig, dass diese Faktoren berücksichtigt werden, damit Mitarbeiter bei der Entwicklung von Lösungen über das Übliche hinausdenken und dem Projekt dabei helfen, unvorhergesehene Hindernisse zu überwinden.

Um auf unser Beispiel zurückzukommen: Im Rahmen des ersten Projekts erfährt das Vertriebsteam Folgendes: „Offenbar hat das KI-Tool unsere vielversprechendsten Leads zutreffend prognostiziert.“

Im zweiten Projekt stellen sie sich die Frage: „Können wir das auch für X verwenden?“

Beim dritten Projekt arbeiten sie an der Entwicklung ihrer eigenen Ideen.

Messbare Indikatoren:

• Adoption-Rate steigt von typischen 30 % (isoliertes Projekt) auf 75–85 % (dritte Initiative in der Domäne)

• Time-to-Value sinkt von durchschnittlich 8 Monaten auf 3–4 Monate

3. Prozesse, die mit der Technologie wachsen

Die Entwicklung der KI-Technologie schreitet rapide voran. GPT-4 jetzt, GPT-5 morgen, multimodale Modelle am Tag danach. Wer immer wieder von Null beginnt, der verliert.

Durch den Produkt-Ansatz werden Prozesse zur fortlaufenden Verbesserung etabliert:

• Regelmäßige Model-Retraining-Cycles

• A/B-Testing neuer Ansätze gegen etablierte Lösungen

• Feedback-Loops zwischen Business und Data Science

Die Notwendigkeit ist echt

Während du diese Zeilen liest, optimiert ein Konkurrent möglicherweise bereits seine Lieferkette unter Zuhilfenahme von künstlicher Intelligenz. Ein Startup revolutioniert deine Industrie mit einem Geschäftsmodell, das auf KI zugeschnitten ist. Ein weiterer CEO genehmigte letzte Woche den Produkt-Ansatz für seinen Vertrieb.

Die gute Nachricht: Die meisten Unternehmen haben durch die COVID-Jahre bereits erste KI-Erfahrungen gesammelt. Teams sind aufgebaut. Erste Projekte laufen.

Die Herausforderung: Diese Punktlösungen in eine kohärente, domänenweite Transformation zu überführen.

Deine nächsten Schritte

1. Identifiziere eine kritische Domäne. Wo würden 20–30 % Effizienzsteigerung den größten Business-Impact haben?

2. Mappe die Datenlage: Welche Daten existieren bereits? Was fehlt? Was ist die Qualität?

3. Definiere 3–5 vernetzte Use Cases. Nicht isolierte Projekte, sondern eine zusammenhängende Transformationsstory

4. Starte klein, denke groß. Erstes Projekt in 8–12 Wochen live, aber mit Infrastruktur, die skaliert.

Weiterführende Ressourcen:

• Framework für Domänen-Mapping – systematisches Vorgehen zur Identifikation der richtigen Domäne

• Data Product Canvas – Template für die Konzeption von Daten als Produkt

• KI-Readiness-Assessment – Evaluiere die Ausgangslage deiner Organisation.

Frage in die Community: Welche Domäne in eurem Unternehmen hätte das größte Transformationspotenzial? Und was hält euch aktuell davon ab, den ersten Schritt zu gehen?

Noch keine Data-Community?

Durch den Ansatz einer Data Community konnten wir zeigen, dass es nicht immer so sperrig sein muss, um handfeste Ergebnisse zu erzielen.

Wertvolles Wissen über Daten liegt in Unternehmen bei verschiedenen Teams und Abteilungen verstreut. Oft fehlt eine zentrale Anlaufstelle, um Erfahrungen auszutauschen, Best Practices zu teilen und datengetriebene Innovationen voranzutreiben. Hier kommt die Data Community ins Spiel. Sie ist das lebendige Fundament, das sicherstellt, dass Data Governance nicht nur ein Regelwerk, sondern eine gelebte Unternehmenskultur wird.

Eine Data Community bringt Mitarbeitende zusammen, die mit Daten arbeiten – von Analysten über IT-Teams bis hin zu Fachabteilungen.

Doch welchen konkreten Mehrwert bietet eine solche Community und wie lässt sie sich implementieren? Lasst es uns herausfinden!

Jetzt abonnieren

Die versteckte Bedrohung: Wieso Daten und Wissen in Silos stecken ⚠️

Daten haben sich in der heutigen Wirtschaft als entscheidender Vermögenswert entwickelt. Bedauerlicherweise ist in zahlreichen Unternehmen das wertvolle Wissen über diese Daten auf verschiedene Teams und Abteilungen verteilt und in Datensilos eingeschlossen.

Der Hauptgrund ist die Art und Weise, wie das Unternehmen organisiert ist.

In Unternehmen gibt es verschiedene Abteilungen wie Marketing, Vertrieb, Finanzen und Produktion, die speziell für ihre eigenen Ziele optimiert sind.

• Vertikale Optimierung: Jede Abteilung entwickelt ihre eigenen, spezialisierten Prozesse und Kennzahlen und beschafft die dafür notwendigen Daten und IT-Systeme (z. B. CRM für den Vertrieb, ERP für die Produktion). Diese Systeme sind oft nicht nativ miteinander verbunden.

• Wissenslokalisierung: Das Wissen über die Daten – ihre genaue Herkunft, ihre Definitionen, ihre Qualität und die Art ihrer Nutzung – verbleibt im Verantwortungsbereich der jeweiligen Abteilung. Das führt dazu, dass das Vertriebsteam die Definition von „Kunde“ auf andere Art interpretiert als das Finanzteam.

• Fehlende horizontale Brücken: Es fehlt eine horizontale, unternehmensweite Struktur, die den abteilungsübergreifenden Austausch von Daten und Wissen standardisiert und fördert.

Die Folge dieser strukturellen Isolation ist, dass Daten und das Wissen darüber nicht frei fließen können, wodurch sich schwerwiegende Probleme ergeben:

• Redundanz und Ineffizienz: Teams erfinden das Rad neu oder führen dieselben Berechnungen mit unterschiedlichen Datensätzen durch. Das Marketing-Team nutzt insbesondere eine CRM-Datenbank, weiß aber nicht, dass das Controlling bereits eine optimierte Kundensegmentierung entwickelt hat – wertvolle Arbeit wird dupliziert.

• Mangelndes Vertrauen in Daten: Ohne eine „Single Source of Truth“ (SSOT) sind Daten inkonsistent, was zu Verwirrung und Misstrauen unter den Nutzern führt. Entscheidungen basieren auf fehlerhaften oder veralteten Informationen, was die betriebliche Effizienz verringert und Kosten erhöht.

• Compliance- und Innovationsrisiken: Unkontrollierte Datenflüsse und unklare Verantwortlichkeiten erschweren die Einhaltung gesetzlicher Vorschriften (z. B. DSGVO) und behindern die vollständige Nutzung des Datenpotenzials für neue Geschäftsmodelle oder KI-Initiativen.

Der Mehrwert der Community: Wissen, Vertrauen und Entscheidungen

Eine Data Community bringt Mitarbeitende zusammen – von Analysten über IT-Teams bis hin zu Fachabteilungen. Ihr Mehrwert ist direkt und operativ:

1️⃣ Bessere Nutzung und Verständnis von Daten

Viele Unternehmen sammeln riesige Mengen an Daten – doch oft bleibt unklar, wie diese optimal genutzt werden können. Die Community hilft, Wissenssilos zu überwinden und ein gemeinsames Verständnis darüber zu schaffen, wo wichtige Daten liegen, wie sie richtig interpretiert werden und welche Analyse-Tools sinnvoll sind.

✅ Wo wichtige Daten liegen
✅ Wie sie richtig interpretiert werden
✅ Welche Analyse-Tools sinnvoll sind

💡 Beispiel: Ein Marketing-Team nutzt eine CRM-Datenbank, weiß aber nicht, dass das Controlling-Team bereits eine optimierte Kundensegmentierung entwickelt hat. Durch den Austausch in der Data Community können beide voneinander profitieren.

2️⃣ Förderung von datengetriebener Entscheidungsfindung

Der gemeinschaftliche Aufbau einer Daten-Community sowie die Sicherstellung der Datenqualität tragen dazu bei, das Vertrauen in Daten zu stärken und fundiertere sowie schnellere Entscheidungsfindungen zu begünstigen.

Sie ermöglicht:

📊 Bessere Entscheidungsgrundlagen durch transparenten Austausch von Analysen
📊 Höhere Datenkompetenz im gesamten Unternehmen
📊 Weniger Abhängigkeit von einzelnen Experten

💡 Beispiel: Vertrieb und Produktion können durch eine bessere gemeinsame Nutzung von Daten Nachfrage-Trends schneller erkennen und Produktionsmengen anpassen.

3️⃣ Effizientere Zusammenarbeit zwischen Teams

Ohne eine zentrale Plattform für den Austausch arbeiten viele Teams doppelt, weil sie ähnliche Analysen oder Berichte unabhängig voneinander erstellen. Eine Data Community schafft:

🤝 Bessere Zusammenarbeit zwischen Fachbereichen, IT & Data Science
🚀 Synergien, die Kosten und Zeit sparen
📂 Standardisierung von Methoden & Tools

💡 Beispiel: IT und Controlling arbeiten gemeinsam an einer automatisierten Reporting-Lösung, die beiden Abteilungen Arbeit erspart.

4️⃣ Innovationen durch neue Perspektiven

Oft entstehen die besten Ideen, wenn unterschiedliche Perspektiven aufeinandertreffen. Eine Data Community bietet Raum für:

🔍 Erfahrungsaustausch über neue Technologien & Trends
💡 Kreative Lösungsansätze für Datenprobleme
🌍 Interdisziplinären Wissenstransfer

💡 Beispiel: Ein Data-Scientist teilt in der Community, wie KI für die Lageroptimierung eingesetzt werden kann – das Logistik-Team adaptiert die Idee und reduziert Lagerkosten.

5️⃣ Förderung einer datengetriebenen Unternehmenskultur

Eine Data Community hilft, eine starke Datenkultur aufzubauen, indem sie:

📢 Schulungen & Events organisiert
📘 Wissen in Form von Leitfäden & Best Practices teilt
🎯 Datenbewusstsein auf allen Ebenen fördert

💡 Beispiel: Regelmäßige „Lunch & Learn“-Sessions helfen Mitarbeitenden, datengetriebene Ansätze besser zu verstehen und anzuwenden.

🚀 Fazit: Eine Data Community bringt echten Mehrwert!

Unternehmen, die eine aktive Data Community aufbauen, profitieren von:

✅ Besserem Datenverständnis & effizienterer Nutzung
✅ Schnellerem Wissenstransfer & weniger Doppelarbeit
✅ Mehr Innovation & besseren Geschäftsentscheidungen
✅ Einer starken, datengetriebenen Unternehmenskultur

💡 Tipp: Der Aufbau einer Data Community muss nicht kompliziert sein! Starte klein mit regelmäßigen Meetups, Wissens-Sharing und einer internen Plattform für den Austausch.

👉 Wie nutzt dein Unternehmen Daten? Gibt es bereits eine Data Community? Teile deine Erfahrungen in den Kommentaren! 😊👇