Die Kernidee lässt sich in einem Satz zusammenfassen: Hex macht den Weg von der ersten Datenfrage bis zur teilbaren, nachvollziehbaren Antwort durchgängig. In vielen Unternehmen zerfällt dieser Weg heute in unverbundene Etappen. Analysten explorieren Daten in einem lokalen Notebook, kopieren Zwischenergebnisse in eine Tabellenkalkulation, bauen daraus eine Präsentation und schicken diese per E-Mail herum. Sobald jemand die Zahlen hinterfragt, ist unklar, wie sie zustande kamen. Hex verankert die Analyse, den Code, die Daten und die Darstellung an einem Ort – nachvollziehbar, versionierbar und im Team teilbar.
Drei Eigenschaften definieren Hex:
Um Hex richtig einzuordnen, hilft ein Blick auf den typischen Weg der Daten. Rohdaten aus Quellsystemen – ERP, CRM, Online-Shop, Marketing-Werkzeuge – werden in ein zentrales Data Warehouse geladen und dort in saubere, geschäftlich sinnvolle Tabellen transformiert. Hex greift auf diese aufbereiteten Daten zu und ist die Schicht, in der aus den Daten Erkenntnisse werden: durch Exploration, Modellierung, Visualisierung und die anschließende Aufbereitung für ein Publikum. Hex ersetzt also weder das Warehouse noch die Transformationsschicht, sondern setzt darauf auf.
Diese Positionierung ist wichtig, weil sie erklärt, wofür Hex nicht gedacht ist. Hex ist keine Ladeschicht, es zieht keine Daten dauerhaft aus Quellsystemen, und es ist kein Speicherort für Ihre Unternehmensdaten. Es ist die Arbeitsfläche, auf der Analystinnen und Analysten mit den bereits vorhandenen, vertrauenswürdigen Daten arbeiten. Am wirkungsvollsten ist Hex daher in einer Umgebung, in der ein modernes Cloud Data Warehouse und eine saubere Transformationsschicht bereits existieren oder gemeinsam eingeführt werden.
Hex gehört zu einer neuen Kategorie von Werkzeugen, die die klassische Trennung zwischen dem Code-orientierten Daten-Notebook und der Klick-orientierten BI-Plattform auflöst. Notebooks sind extrem flexibel, aber schwer zu teilen und für Nicht-Techniker kaum bedienbar. Klassische BI-Werkzeuge sind gut teilbar und bedienbar, aber in der freien, tiefen Analyse begrenzt. Hex versucht, das Beste aus beiden zu vereinen: die analytische Tiefe des Notebooks und die Teilbarkeit der BI-Plattform.
Für den Mittelstand ist dieses Zwischenformat interessant, weil es einer typischen Realität entspricht. Oft gibt es eine kleine Gruppe datenaffiner Menschen, die tiefe Analysen benötigen, und einen größeren Kreis von Führungskräften und Fachbereichen, die verständliche Ergebnisse konsumieren wollen. Hex bedient beide Gruppen in einem Werkzeug: die Analysten in der Notebook-Ansicht, die Konsumenten in der aufbereiteten App- oder Dashboard-Ansicht. Genau diese Doppelrolle unterscheidet Hex von reinen Notebooks und von reinen Dashboard-Werkzeugen.
Hex versteht sich als Plattform, die den gesamten Ablauf datenanalytischer Arbeit abdeckt – von der Exploration über die Zusammenarbeit bis zur Veröffentlichung. Der Anbieter wendet sich damit primär an Datenteams: an Analysten, Data Scientists und Analytics Engineers, die anspruchsvolle Fragestellungen bearbeiten und deren Ergebnisse einem breiteren Publikum verständlich machen wollen. Das unterscheidet Hex von reinen Self-Service-BI-Werkzeugen, die vor allem Fachanwender ohne Code-Kenntnisse ansprechen.
Die Positionierung ist bewusst darauf ausgelegt, sich in einen modernen Data Stack einzufügen, nicht ihn zu ersetzen. Hex setzt auf ein vorhandenes Data Warehouse auf, arbeitet mit einer bestehenden Transformationsschicht zusammen und ordnet sich damit klar oberhalb der Datenaufbereitung, aber vor dem Endkonsum ein. Für Unternehmen, die diesen modernen Stack bereits verfolgen, ist Hex ein natürlicher Baustein; für Unternehmen, die noch mit einer isolierten Tabellenkalkulation oder einem einzelnen Berichtswerkzeug arbeiten, ist Hex oft ein größerer Schritt, der Vorarbeit an der Datenbasis voraussetzt.
Bei einer Plattform wie Hex staffeln sich die Pläne in der Regel entlang einiger wiederkehrender Achsen. Dazu zählen die Anzahl und Art der Nutzer (Bearbeiter versus reine Betrachter), der Umfang der Zusammenarbeits- und Governance-Funktionen (etwa Rechteverwaltung, Freigabeprozesse, Versionskontrolle), die Sicherheits- und Verwaltungsmerkmale (SSO, Prüfprotokolle, Datenschutzoptionen) sowie – auf der obersten Ebene – besondere Betriebsmodelle wie eine dediziert bereitgestellte, single-tenant betriebene Umgebung. Da Hersteller Namen, Grenzen und Preise regelmäßig anpassen, sollten Sie die für Sie relevanten Details immer aktuell beim Anbieter erfragen. Wir bewerten in unseren Projekten nicht die Marketing-Bezeichnung eines Plans, sondern gleichen die konkret enthaltenen Funktionen mit Ihrem tatsächlichen Bedarf ab.
Das Herzstück von Hex ist das hybride Notebook. Anders als in einem reinen SQL-Editor oder einem klassischen Python-Notebook lassen sich hier beide Sprachen frei mischen. Eine SQL-Zelle fragt Daten direkt aus dem Warehouse ab und liefert eine Tabelle. Diese Tabelle steht der nächsten Zelle unmittelbar als Datenobjekt zur Verfügung – etwa einer Python-Zelle, die eine statistische Auswertung, eine komplexe Umformung oder eine Visualisierung durchführt. Das Ergebnis kann wiederum von einer weiteren SQL-Abfrage genutzt werden. Für den Alltag bedeutet das: Man wählt für jeden Schritt das Werkzeug, das am besten passt, statt sich global zwischen SQL und Python entscheiden zu müssen.
Für den Mittelstand ist das ein pragmatischer Vorteil. Viele datenaffine Mitarbeiter beherrschen SQL solide, aber nur teilweise Python. In Hex können sie den Großteil einer Analyse in vertrautem SQL erledigen und Python gezielt dort einsetzen, wo es klare Vorteile bietet – etwa bei einer Berechnung, die in reinem SQL umständlich wäre. Das senkt die Einstiegshürde und erlaubt es, Python-Kompetenz schrittweise aufzubauen, statt sie von Beginn an vorauszusetzen.
Eine der wichtigsten Eigenschaften von Hex ist die reaktive Ausführung. Klassische Notebooks haben ein bekanntes Problem: Zellen können in beliebiger Reihenfolge ausgeführt werden, und wenn man eine frühe Zelle ändert, aber die nachgelagerten vergisst neu auszuführen, entstehen still und leise falsche Ergebnisse. Hex begegnet dem, indem es die Abhängigkeiten zwischen den Zellen versteht und als Graph verwaltet. Ändert man eine Eingabe, erkennt Hex automatisch, welche Zellen davon betroffen sind, und führt sie in der korrekten Reihenfolge neu aus.
Praktisch bedeutet das zweierlei. Erstens werden Analysen verlässlicher, weil der Zustand des Notebooks immer konsistent ist – ein oft unterschätzter Gewinn an Vertrauenswürdigkeit. Zweitens ist diese Reaktivität die technische Grundlage für interaktive Data Apps: Ändert ein Betrachter einen Filter oder eine Eingabe, rechnet Hex die abhängigen Schritte automatisch neu, und die Anwendung reagiert unmittelbar. Reaktivität ist damit nicht nur ein Komfortmerkmal, sondern das Fundament, auf dem die Interaktivität der veröffentlichten Ergebnisse ruht.
Der zweite große Baustein ist die Verwandlung derselben Arbeit in ein teilbares Ergebnis. Aus einem Notebook lässt sich per Anordnung der Elemente eine Data App zusammenstellen: eine interaktive Oberfläche mit Eingabefeldern, Filtern, Auswahllisten und Schaltflächen, hinter der die volle Analyse-Logik weiterläuft. Fachanwender sehen nur die aufgeräumte, bedienbare Oberfläche – nicht den Code. Wählt jemand einen anderen Zeitraum oder ein anderes Produkt, aktualisieren sich die Ergebnisse dank der reaktiven Ausführung automatisch. Alternativ lassen sich Kennzahlen und Visualisierungen als Dashboard anordnen, wenn ein kompakter, wiederkehrender Überblick gefragt ist.
Der entscheidende Punkt ist, dass es keinen Medienbruch gibt. In der traditionellen Welt wird eine Analyse in einem Werkzeug erstellt und dann mühsam in ein anderes für die Präsentation übertragen – mit dem Risiko, dass beide auseinanderlaufen. In Hex sind Analyse und Präsentation zwei Ansichten derselben Sache. Ändert sich die zugrunde liegende Logik, ändert sich auch die veröffentlichte App. Das erhält die Nachvollziehbarkeit und beseitigt eine der häufigsten Fehlerquellen im Berichtswesen.
Der KI-Assistent setzt an mehreren Stellen des Analyse-Alltags an. Aus einer in natürlicher Sprache formulierten Frage kann er einen Vorschlag für eine SQL-Abfrage oder eine Python-Zelle erzeugen, den der Nutzer prüft und übernimmt oder anpasst. Er kann bestehenden Code erklären, was besonders neuen Teammitgliedern hilft, sich in fremde Analysen einzuarbeiten. Und er kann bei Fehlern unterstützen, indem er die wahrscheinliche Ursache benennt und einen Lösungsweg vorschlägt. Das Grundprinzip ist, dass die KI im Werkzeug mitarbeitet, statt in einem separaten Chatfenster zu leben.
Der praktische Nutzen zeigt sich vor allem in drei Situationen. Beim Einstieg in eine neue Fragestellung hilft der Assistent, schneller zu einer ersten, lauffähigen Abfrage zu kommen, statt bei einem leeren Editor zu beginnen. Beim Überwinden von Wissenslücken – etwa wenn jemand SQL beherrscht, aber bei einer Python-Umformung unsicher ist – kann die KI einen Vorschlag liefern, der als Ausgangspunkt dient. Und bei der Fehlersuche spart die Erklärung einer Fehlermeldung oft mühsames Suchen. In Summe verschiebt sich die Arbeit von reiner Syntax hin zur fachlichen Fragestellung – was gerade weniger technischen Analysten zugutekommt.
Ebenso wichtig ist, die Grenzen klar zu sehen. KI-Assistenten arbeiten auf Basis von Wahrscheinlichkeiten und können plausibel klingende, aber falsche Ergebnisse liefern. Eine von der KI erzeugte SQL-Abfrage kann syntaktisch korrekt sein und trotzdem die falsche Geschäftslogik abbilden. Der entscheidende Punkt bleibt daher die menschliche Prüfung: Jedes KI-Ergebnis muss verstanden und auf Plausibilität kontrolliert werden, bevor es in eine Entscheidung einfließt. Der Assistent ist ein Beschleuniger, kein Ersatz für Fachverstand.
Neben der KI-Unterstützung bei der Erstellung bietet Hex Funktionen, um Analysen zu automatisieren. Ein Projekt kann nach Zeitplan automatisch aktualisiert werden, sodass ein Dashboard oder eine Data App stets aktuelle Zahlen zeigt, ohne dass jemand sie von Hand neu berechnet. Ergebnisse lassen sich planmäßig erzeugen und – je nach Ausstattung – an definierte Empfänger verteilen. So wird aus einer einmaligen Analyse ein verlässlich wiederkehrendes Datenprodukt, das Routineberichte ohne manuellen Aufwand liefert.
Für den Mittelstand liegt hier ein oft übersehener Wert. Viele wiederkehrende Auswertungen – der wöchentliche Umsatzbericht, das monatliche Marketing-Reporting – werden heute manuell erstellt und binden wertvolle Zeit. Automatisiert man diese in Hex, wird nicht nur Zeit frei, sondern auch eine Fehlerquelle beseitigt: Der Bericht basiert immer auf derselben, geprüften Logik, statt bei jeder Wiederholung neu und potenziell abweichend zusammengebaut zu werden.
Die wichtigste Verbindung ist die zum Data Warehouse. Hex verbindet sich mit den führenden Cloud-Plattformen – darunter Snowflake, Google BigQuery und Databricks – und führt SQL-Abfragen direkt dort aus. Das ist eine wichtige architektonische Eigenschaft: Die eigentliche Rechenarbeit findet im Warehouse statt, nicht in Hex. Hex holt sich die Ergebnisse und arbeitet damit weiter, aber die schwere Verarbeitung großer Datenmengen bleibt bei der Plattform, die dafür ausgelegt ist. Für die Leistung bei großen Datenbeständen ist das entscheidend, und für die Datenhoheit ist es relevant, weil die Daten primär im Warehouse liegen.
Diese Warehouse-Nähe erklärt auch, warum Hex am besten in einer Umgebung funktioniert, in der ein solches Warehouse bereits existiert. Unternehmen, die Snowflake, BigQuery oder Databricks betreiben oder einführen, können Hex als natürliche Analyseschicht darauf setzen. Wer dagegen seine Daten noch in verstreuten Tabellenkalkulationen oder einzelnen Datenbanken hält, sollte den Aufbau einer sauberen, zentralen Datenbasis als Voraussetzung einplanen – Hex ersetzt diesen Schritt nicht.
Ein besonders wertvoller Baustein ist das Zusammenspiel mit dbt, der verbreiteten Transformationsschicht des modernen Data Stack. In einer sauberen Architektur transformiert dbt die Rohdaten im Warehouse in verlässliche, getestete und dokumentierte Analysetabellen. Hex greift dann auf genau diese veredelten Tabellen zu. Die Arbeitsteilung ist klar: dbt sorgt für vertrauenswürdige, konsistente Daten – die eine Quelle der Wahrheit –, Hex sorgt für die Analyse und Darstellung darauf. Wo Hex zusätzlich Metadaten und Definitionen aus dbt nutzen kann, profitieren Analysten davon, dass sie mit denselben, verbindlich definierten Kennzahlen arbeiten, statt sie in jeder Analyse neu und potenziell abweichend zu berechnen.
Dieses Zusammenspiel ist aus unserer Sicht ein Musterbeispiel für den modernen, modularen Datenaufbau: spezialisierte Werkzeuge, die jeweils eine Aufgabe gut erledigen und über klare Schnittstellen zusammenwirken. Für den Mittelstand bedeutet das Wahlfreiheit und geringere Abhängigkeit – man kann einzelne Bausteine austauschen, ohne die ganze Landschaft neu zu bauen.
Hex nutzt Git für die Versionierung von Projekten. Damit werden Analysen mit derselben Sorgfalt behandelt wie Software: Jede Änderung ist nachvollziehbar, Versionsstände lassen sich vergleichen, und im Zweifel kann man zu einem früheren Stand zurückkehren. Für Teams, die bereits mit Git arbeiten, fügt sich Hex nahtlos in vorhandene Entwicklungsprozesse ein. Darüber hinaus bietet Hex Anbindungen an Identitätsdienste für die Anmeldung (SSO) sowie – je nach Ausstattung – Verbindungen zu weiteren Datenquellen und Diensten. Den genauen, aktuellen Umfang der verfügbaren Integrationen sollten Sie stets beim Anbieter prüfen, da sich das Ökosystem laufend erweitert.
Am nächsten steht Hex Werkzeugen aus derselben Kategorie: kollaborativen Analyse- und Notebook-Plattformen wie Mode oder Deepnote. Alle verfolgen die Grundidee, SQL- und teils Python-basierte Analyse mit Zusammenarbeit und Teilbarkeit zu verbinden. Die Unterschiede liegen weniger im Grundkonzept als in Schwerpunkten und Reifegraden einzelner Fähigkeiten – etwa wie stark die reaktive Ausführung ausgeprägt ist, wie ausgefeilt die Verwandlung in interaktive Anwendungen gelingt, wie tief die KI-Unterstützung integriert ist und wie gut sich die jeweilige Plattform in den vorhandenen Data Stack einfügt.
Aus Beratungssicht ist ein Vergleich innerhalb dieser Kategorie deshalb kein Duell um Punkte, sondern eine Frage der Passung: Welche Plattform harmoniert am besten mit dem vorhandenen Warehouse, mit den Kenntnissen des Teams (mehr SQL oder mehr Python) und mit der Art, wie Ergebnisse geteilt werden sollen? Da sich diese Werkzeuge schnell weiterentwickeln, empfehlen wir, die Auswahl anhand eines konkreten, eigenen Anwendungsfalls in einer Testphase zu treffen, statt sich auf allgemeine Merkmalslisten zu verlassen.
Deutlicher ist die Abgrenzung zu klassischen BI-Plattformen wie Tableau oder Power BI. Diese sind stark darin, standardisierte, weit verbreitete Dashboards und Berichte per Klick zu erstellen und großen Nutzerkreisen zugänglich zu machen. Ihr Schwerpunkt liegt auf der visuellen Selbstbedienung für Fachanwender, die keinen Code schreiben. Ihre Grenze zeigt sich, sobald eine Analyse tiefer geht als das, was die Oberfläche vorsieht – wenn also freie, code-gestützte Exploration, statistische Verfahren oder ungewöhnliche Umformungen gefragt sind.
Hex setzt genau umgekehrt an. Es ist stark in der tiefen, flexiblen Analyse mit SQL und Python und in der Nachvollziehbarkeit des Wegs zum Ergebnis, während es Fachanwender eher über veröffentlichte Data Apps als über freie Klick-Selbstbedienung erreicht. Die beiden Werkzeugwelten schließen sich nicht aus – in vielen Unternehmen existieren sie nebeneinander. Eine sinnvolle Aufteilung, die wir häufig sehen: klassische BI für die breit gestreuten Standardberichte, Hex für die anspruchsvollen, explorativen und maßgeschneiderten Analysen des Datenteams.
Der Regelfall ist der Betrieb als Cloud-SaaS: Hex läuft in der Infrastruktur des Anbieters, es ist keine eigene Installation nötig, Aktualisierungen erfolgen automatisch, und ein Team kann in kurzer Zeit produktiv werden. Für den Mittelstand ist das attraktiv, weil kein eigener Betriebsaufwand entsteht und keine spezialisierte IT-Mannschaft für den Unterhalt der Plattform vorgehalten werden muss. Der Preis dieser Bequemlichkeit ist, dass Betrieb und ein Teil der Datenverarbeitung außer Haus liegen – bei einem US-amerikanischen Anbieter. Das ist keine Ausschlussbedingung, aber ein Punkt, der eine bewusste datenschutzrechtliche Betrachtung erfordert, die wir in Kapitel 09 vertiefen.
Für Organisationen mit erhöhten Anforderungen an Sicherheit, Isolation oder Datenhoheit gibt es je nach Angebot besondere Betriebsoptionen. Dazu zählt insbesondere ein single-tenant betriebener Dienst: eine dediziert für einen Kunden bereitgestellte Umgebung, die von anderen Kunden getrennt ist. Solche Optionen sind typischerweise Teil der Enterprise-Ebene, können mit zusätzlichen Kosten verbunden sein und unterscheiden sich im Detail vom Standard-SaaS. Ob und in welcher Form eine solche Option verfügbar ist – und welche Region und welche vertraglichen Zusicherungen damit einhergehen –, sollten Sie konkret beim Anbieter erfragen, da dies für die Datenschutzbewertung entscheidend sein kann.
In unseren Projekten wägen wir hier nüchtern ab. Für viele mittelständische Anwendungsfälle mit unkritischen Daten ist der Standard-Cloud-Betrieb ausreichend und wirtschaftlich sinnvoll. Sobald jedoch besonders sensible Daten im Spiel sind oder eine Branche strenge Vorgaben macht, verschiebt sich die Abwägung – dann rücken besondere Betriebsoptionen, die Frage der Region und die vertraglichen Grundlagen in den Vordergrund.
Besonders wertvoll ist Hex, wenn im Unternehmen bereits eine kleine Gruppe von Menschen mit SQL – und idealerweise Python – arbeitet und über einfache Standard-Dashboards hinaus tiefere Analysen benötigt. Das können maßgeschneiderte Auswertungen sein, die kein Standardbericht abbildet: eine differenzierte Kundenanalyse, eine Untersuchung von Abwanderung, eine Prognose auf Basis historischer Daten oder eine explorative Suche nach Mustern in Betriebsdaten. In all diesen Fällen spielt Hex seine Stärke aus, weil es die Tiefe eines Notebooks mit der Teilbarkeit einer Anwendung verbindet.
Ein zweites, sehr praktisches Szenario ist das Ablösen manueller, wiederkehrender Auswertungen. In vielen mittelständischen Unternehmen werden wichtige Berichte in Tabellenkalkulationen von Hand zusammengebaut – Woche für Woche, Monat für Monat. Hex kann solche Auswertungen als automatisierte, verlässliche Data App abbilden. Das spart Zeit, reduziert Fehler und schafft eine nachvollziehbare, geteilte Version, die nicht mehr in verstreuten Dateiständen existiert.
So nützlich Hex sein kann – es ist kein Werkzeug für jedes Unternehmen und jeden Zweck. Die wichtigste Voraussetzung ist datenaffines Personal. Wer keine Mitarbeiter hat, die mit SQL umgehen, wird die Stärken von Hex kaum ausschöpfen; für diesen Fall sind klassische, klickbasierte BI-Werkzeuge oft der bessere Einstieg. Ebenso setzt Hex eine saubere Datenbasis voraus. Ohne ein zentrales, aufbereitetes Datenfundament bleibt auch das beste Analysewerkzeug wirkungslos – dann ist der Aufbau dieser Basis der eigentliche erste Schritt, nicht die Einführung von Hex.
Schließlich sollte der Zweck passen. Geht es primär darum, standardisierte Berichte an einen großen Empfängerkreis zu verteilen, ist eine klassische BI-Plattform meist die naheliegendere Wahl. Geht es dagegen um tiefe, flexible, teilbare Analysen eines datenaffinen Teams, spielt Hex seine besondere Stärke aus. In unseren Projekten empfehlen wir, diese Frage vor der Werkzeugwahl ehrlich zu klären – nicht selten ist die Antwort ein sinnvolles Nebeneinander mehrerer Werkzeuge, nicht ein einzelnes Alleskönner-Tool.
Die Kosten für Hex bestehen typischerweise aus einem nutzerbasierten Abonnement, das nach der Zahl und Art der Nutzer gestaffelt ist – häufig mit Unterscheidung zwischen Bearbeitern und reinen Betrachtern. Da Anbieter Preise und Plangrenzen regelmäßig ändern, nennen wir hier bewusst keine konkreten Beträge; verbindliche Zahlen erhalten Sie direkt beim Anbieter. Wichtig ist, bei der Kostenbetrachtung nicht nur den Listenpreis des Abonnements zu sehen, sondern das Gesamtbild: Hex verursacht zusätzlich Rechenkosten im Data Warehouse, weil die Abfragen dort ausgeführt werden. Wer die Wirtschaftlichkeit realistisch einschätzen will, muss beide Seiten – Lizenz und Warehouse-Verbrauch – zusammen betrachten.
Für den Mittelstand empfiehlt sich daher eine Hochrechnung auf Basis der realistisch erwarteten Nutzung: Wie viele Bearbeiter, wie viele Betrachter, wie viele und wie rechenintensive Analysen? Aus dieser ehrlichen Schätzung ergibt sich ein belastbares Bild der Gesamtkosten – deutlich verlässlicher als ein isolierter Blick auf den Abo-Preis.
Der Kern der Datenschutzfrage bei einem US-Cloud-Anbieter ist der Ort der Verarbeitung und der damit verbundene Datentransfer. Zu klären ist erstens, ob der Anbieter eine EU-Region anbietet und ob die Verarbeitung dort tatsächlich stattfindet. Zweitens, auf welcher Rechtsgrundlage ein etwaiger Transfer personenbezogener Daten in die USA erfolgt und welche Schutzmaßnahmen – etwa Standardvertragsklauseln – vereinbart sind. Drittens, ob ein belastbarer Auftragsverarbeitungsvertrag vorliegt und was er im Detail regelt. Diese Punkte sind nicht theoretisch, sondern die konkreten Fragen, die Sie dem Anbieter vor einer Einführung stellen sollten.
Ein oft entlastender Aspekt: In der Architektur des modernen Data Stack liegen die eigentlichen Geschäftsdaten primär im Data Warehouse, dessen Region Sie steuern können. Hex arbeitet mit Ausschnitten und Ergebnissen dieser Daten. Wie stark personenbezogene Daten tatsächlich in Hex gelangen, hängt daher stark von der konkreten Nutzung ab – und ist ein zentraler Punkt der Bewertung. Wer personenbezogene Daten weitgehend im Warehouse hält und in Hex mit aggregierten oder anonymisierten Ergebnissen arbeitet, reduziert die Angriffsfläche der Datenschutzfrage erheblich. Auch dies sollte Teil der Prüfung sein.
