KI Dateninfrastruktur Assessment: Sind Ihre Daten bereit?

Ein KI Dateninfrastruktur Assessment ist eine strukturierte Prüfung, ob Ihre Daten das KI-System tragen können, das Sie bauen wollen. Es beantwortet fünf Fragen: Existieren die richtigen Daten, dürfen Sie sie für diesen Zweck rechtlich nutzen, kann ein Modell sie in der Form und mit der Geschwindigkeit erreichen, die das System braucht, sind sie genau und konsistent genug, um daraus zu lernen, und kann irgendjemand sagen, woher sie stammen. Es dauert Tage statt Monate und ist der günstigste Weg herauszufinden, dass ein vielversprechendes KI-Projekt noch nicht baubar ist.

Was Teams überrascht, ist selten, dass Daten fehlen. Es ist, dass die Daten in sieben Systemen liegen, in vier Formaten, mit drei unvereinbaren Definitionen von "Kunde", und niemand ist für die Abstimmung zuständig. Das Modell war nie der schwierige Teil. Eine saubere, gelabelte, rechtlich nutzbare und zuverlässig aktualisierte Tabelle davorzustellen, ist der schwierige Teil, und dort landet der Großteil des tatsächlichen Aufwands eines KI-Projekts.

Was ist ein KI Dateninfrastruktur Assessment?

Es ist ein diagnostischer Durchgang durch die Datenschicht unter einem geplanten Use Case: Quellen, Pipelines, Speicherung, Qualität, Verantwortlichkeiten und Rechtsgrundlage. Das Ergebnis ist keine Plattformempfehlung. Es ist ein Urteil pro Use Case (bereit, bereit nach konkret benannter Vorarbeit, oder auf der aktuellen Datenlage nicht tragfähig) plus eine bezifferte Liste dessen, was das Schließen der Lücken erfordern würde.

Es ist enger gefasst als ein vollständiges AI Readiness Audit, das zusätzlich Machbarkeit, ROI, regulatorische Exposition und die Frage bewertet, ob die Organisation das System überhaupt aufnehmen kann. Datenreife ist eine Dimension dieses Audits, aber es ist die Dimension, die am häufigsten über die Antwort entscheidet, und deshalb lohnt es sich, sie für sich zu betrachten. Wenn Sie zwischen beiden wählen: Das breitere Audit ist das richtige Instrument, wenn mehrere Kandidaten priorisiert werden müssen; ein fokussiertes Data Assessment passt, wenn der Use Case feststeht und nur offen ist, ob die Daten ihn tragen.

Zwei Dinge ist es nicht. Es ist kein Datenqualitätsprojekt: Es misst Qualität, es behebt sie nicht. Und es ist kein Modernisierungsprogramm. Viele KI-Use-Cases laufen problemlos auf einer zehn Jahre alten Datenbank mit einem nächtlichen Export, und einem Kunden zu sagen, er brauche erst ein Lakehouse, bevor er Support-Tickets klassifizieren kann, verkauft Infrastruktur statt eine Lösung.

Warum entscheidet Datenreife darüber, ob ein KI-Projekt live geht?

Weil Datenprobleme spät entdeckt und früh kalkuliert werden. Die Schätzung für einen KI-Build entsteht auf Basis der Daten, von denen alle glauben, dass es sie gibt. Gearbeitet wird dann mit den Daten, die es tatsächlich gibt, und die Differenz zwischen beiden schluckt der Zeitplan.

Das Muster ist vorhersehbar. Ein Pilot läuft auf einem handbereinigten Extrakt, den jemand einmal manuell in eine Tabelle gezogen hat. Die Ergebnisse sind gut. Das Projekt wird auf Basis dieser Ergebnisse freigegeben. Dann braucht die Produktion dieselben Daten automatisch, täglich, aus dem Quellsystem, und es stellt sich heraus, dass der Extrakt vier manuelle Joins enthielt, eine Ermessensentscheidung darüber, welcher Duplikatsatz bleibt, und eine Spalte, die eine Kollegin im Betrieb privat pflegt. Der Pilot hat nicht bewiesen, dass das System funktioniert. Er hat bewiesen, dass es auf Daten funktioniert, die derzeit keine Pipeline erzeugt.

Deshalb wiegen Datenlücken schwerer als fast jedes andere Risiko. Ein Machbarkeitsproblem lässt sich mit einer Literaturrecherche beantworten. Ein Akzeptanzproblem lässt sich mit den betroffenen Menschen bearbeiten. Eine Datenlücke muss gebaut werden, und dieser Build ist häufig größer als das KI-Projekt, das er stützen sollte. Etliche der häufigsten Fehler bei der KI-Integration sind Datenprobleme im Kostüm eines Engineering-Problems.

Was heißt "AI ready" bei Daten konkret?

Reife ist kein einzelner Wert. Es sind sechs voneinander unabhängige Eigenschaften, und ein Use Case kann an einer einzigen scheitern, während er auf den anderen fünf gesund aussieht.

1. Zugriff

Kann ein System die Daten programmatisch lesen, nach Zeitplan, ohne Menschen dazwischen? Das klingt trivial und ist es oft nicht. Daten, die in einem SaaS-Produkt ohne Export-API eingeschlossen sind, eine SPS in der Fertigung mit proprietärem Protokoll, ein Reporting-Tool, das Zahlen darstellt, aber nicht herausgibt, oder eine Datenbank, die der Betrieb während der Geschäftszeiten von nichts anderem abfragen lässt: Jeder dieser Fälle ist ein Zugriffsproblem, und jeder macht aus einer zweiwöchigen Integration eine Verhandlung.

Achten Sie auch auf die unspektakulären Blocker. Wem gehören die Zugangsdaten. Ob eine Read Replica existiert oder jede Abfrage auf die Produktion geht. Ob der Export, der "nächtlich läuft", seit einem Monat still fehlschlägt, weil niemand hinsieht.

2. Abdeckung und Repräsentativität

Enthalten die Daten die Situationen, denen das System begegnen wird, ungefähr in den Anteilen, in denen es ihnen begegnen wird? Ein Fehlerklassifikator, der auf fotografierten Defekten trainiert wurde, übersieht die, die niemand fotografiert hat. Ein Bedarfsmodell auf Basis von 2024 und 2025 muss die Frage beantworten, ob diese Jahre normal waren. Ein Betrugsmodell, das auf entdecktem Betrug trainiert wurde, lernt genau den Betrug zu erkennen, den Ihre bestehenden Kontrollen ohnehin fangen.

Worauf es ankommt, ist systematische Abwesenheit: eine Fallklasse, die nicht zufällig fehlt, sondern wegen der Art der Datenerhebung. Zufällige Lücken verschlechtern ein Modell sanft. Systematische Lücken erzeugen ein Modell, das genau in den relevanten Situationen selbstbewusst falsch liegt.

3. Qualität und Konsistenz

Qualität ist messbar, und die Messung dauert Stunden statt Wochen. Vollständigkeit pro Spalte, Duplikatrate, Plausibilität der Zeitstempel, Wertebereiche außerhalb des physikalisch Möglichen und der Anteil der Sätze, die eine Geschäftsregel verletzen, von der alle annahmen, sie sei erzwungen.

Konsistenz ist die schwierigere Hälfte. Es geht darum, ob dasselbe Feld über Systeme und über die Zeit hinweg dasselbe bedeutet. Ein Statuscode, der 2023 umgewidmet wurde. Eine "Region", die Finance und Sales unterschiedlich definieren. Eine Maßeinheit, die sich mit einem Lieferantenwechsel geändert hat. Modelle nehmen solche Inkonsistenzen als Signal auf und erzeugen Verhalten, das später niemand erklären kann.

4. Labels und Ground Truth

Supervised Learning braucht Beispiele der richtigen Antwort, und die meisten Organisationen haben weniger davon als gedacht. Die Frage ist nicht, ob Ergebnisse irgendwo erfasst sind, sondern ob sie so erfasst sind, dass sie sich mit zeitlich korrektem Bezug auf den Input zurückführen lassen.

Zwei Fehlermuster wiederholen sich. Das erste ist Label Leakage: ein Feld, das erst befüllt wird, nachdem das Ergebnis bekannt ist. Das Modell sieht im Test hervorragend aus und ist in der Produktion nutzlos, weil dieses Feld zum Zeitpunkt der Vorhersage leer ist. Das zweite ist Uneinigkeit: Zwei Fachleute labeln denselben Fall unterschiedlich, was die erreichbare Modellgenauigkeit auf das Niveau menschlicher Übereinstimmung deckelt, unabhängig von der Architektur. Wer die Übereinstimmung zwischen Beurteilenden nie gemessen hat, kennt sein realistisches Genauigkeitsziel noch nicht.

Wo Labels fehlen, sollte das Assessment ihre Erzeugung beziffern, denn dieser Aufwand ist real und meist der größte Einzelposten im Projekt.

5. Lineage und Governance

Lineage ist die Fähigkeit zu beantworten, woher eine Zahl kommt, wer sie transformiert hat und auf welcher Rechtsgrundlage Sie sie halten. Das ist geschäftlich relevant, weil einem Modell, dessen Herkunft niemand nachvollziehen kann, niemand eine folgenreiche Entscheidung anvertraut. Und es ist rechtlich relevant, weil sowohl GDPR als auch der EU AI Act Fragen stellen, die nur Lineage beantwortet.

Praktische Prüfpunkte: Gibt es pro Quelle eine benannte verantwortliche Person, sind personenbezogene Daten identifiziert und ihre Rechtsgrundlage dokumentiert, sind Aufbewahrungsfristen definiert und werden sie auch angewandt, und existiert ein Nachweis über Einwilligung oder vertragliche Grundlage für die Nutzung dieser Daten zum Modelltraining, was oft ein anderer Zweck ist als der Erhebungszweck. Genau dieser letzte Punkt wird unterschätzt. Daten, die rechtmäßig zur Leistungserbringung erhoben wurden, dürfen nicht automatisch als Trainingsdaten dienen, und die Überschneidung von GDPR und EU AI Act ist der Ort, an dem diese Frage entschieden wird.

6. Der Serving-Pfad

Trainingsdaten und Produktionsdaten sind verschiedene Probleme. Ein Modell, das auf einer Warehouse-Tabelle trainiert wurde, muss zur Inferenzzeit auf Daten laufen, die über einen Live-Pfad mit eigener Latenz, Verfügbarkeit und eigenen Ausfallmodi ankommen. Bewerten Sie diesen Pfad explizit: Wie frisch muss der Input sein, damit die Vorhersage nützlich ist, was passiert, wenn eine Quelle verspätet oder ausgefallen ist, und gilt dieselbe Transformationslogik an beiden Stellen.

Wenn Training und Serving unterschiedliche Transformationen anwenden, entsteht Training-Serving-Skew, eine Fehlerklasse, die ein offline gut bewertetes Modell in der Produktion monatelang still unterperformen lässt, bevor jemand die Ursache findet.

Wie prüft man Datenqualität schnell?

Durch gezielte Stichproben statt durch Vollerhebung. Ein vollständiger Datenkatalog dauert Monate und beantwortet Fragen, die Sie nicht gestellt haben. Eine gezielte Prüfung dauert Tage und beantwortet die entscheidende: Lässt sich dieser konkrete Use Case auf diesen konkreten Daten bauen.

Die Reihenfolge, die funktioniert:

• Von der Entscheidung ausgehen, nicht von den Daten. Schreiben Sie auf, welche Vorhersage das System treffen muss, zu welchem Zeitpunkt, und welche Informationen ein Mensch zu diesem Zeitpunkt hätte. Das definiert den Feature-Satz und schließt sofort jedes Feld aus, das zum Vorhersagezeitpunkt nicht existiert.
• Eine echte Stichprobe ziehen, Ende zu Ende. Kein kuratierter Extrakt. Zwölf Monate Produktionsdaten über genau den Zugriffspfad, den Sie nutzen würden, damit die Reibung beim Extrahieren im Assessment sichtbar wird und nicht erst im dritten Monat.
• Maschinell profilieren. Null-Raten, Kardinalität, Duplikate, Verteilungen, Kontinuität der Zeitreihen. Achten Sie besonders auf Sprünge in einer Verteilung, die meist eine Systemmigration oder Definitionsänderung markieren und kein reales Ereignis.
• Gegen eine bekannte Wahrheit abgleichen. Nehmen Sie eine Kennzahl, der das Unternehmen bereits vertraut, etwa Monatsausbringung, Umsatz oder Fehlerzahlen, und bauen Sie sie aus den Rohdaten nach. Wenn sich eine monatlich berichtete Zahl nicht reproduzieren lässt, haben Sie die Lücke vor dem Modell gefunden.
• Die Labels testen. Lassen Sie zwei Fachleute unabhängig dieselben fünfzig Fälle labeln und messen Sie, wie oft sie übereinstimmen. Diese eine Übung setzt die realistische Genauigkeitsobergrenze für das gesamte Projekt.
• Eine schwache Baseline versuchen. Fitten Sie bewusst etwas Einfaches, eine logistische Regression oder einen Gradient-Boosted-Tree auf naheliegenden Features. Findet ein schwaches Modell überhaupt kein Signal, rettet eine anspruchsvollere Architektur die Sache selten. Schneidet ein schwaches Modell verdächtig gut ab, suchen Sie nach Leakage.

Dieses letzte Paar ist die wertvollste Stunde im gesamten Assessment. Eine schwache Baseline ist zugleich Untergrenze und Alarmanlage.

Brauchen Sie ein Data Warehouse, bevor Sie mit KI anfangen?

Meistens nicht. Verlangt wird ein verlässlicher, wiederholbarer Weg von der Quelle zum Modell, und ein geplanter Export in Object Storage erfüllt das für einen großen Teil der ersten Projekte. Warehouses und Lakehouses rechnen sich, wenn viele Use Cases dieselben Daten teilen, wenn Governance zentralisiert werden muss oder wenn Analystinnen und Analysten Self-Service-Zugriff brauchen. Das sind gute Gründe. "Wir brauchen es, bevor wir KI machen können" gehört nicht dazu.

Das Sequenzierungsargument läuft sogar andersherum. Wer eine Plattform vor einem validierten Use Case baut, entwirft gegen Anforderungen, die er nur vermutet. Wer den ersten Use Case auf einer bescheidenen Pipeline baut, lernt, was die Plattform tatsächlich leisten muss, und die dafür geschriebene Pipeline ist selten verschwendet. Die Ausnahme: wenn das Assessment dieselbe Datenlücke bei drei oder vier Kandidaten gleichzeitig findet. Dann ist das gemeinsame Fundament der günstigere Weg und sollte bewusst gebaut werden statt als Nebenprodukt.

Hüten Sie sich auch vor dem umgekehrten Fehler. Ein Team, das achtzehn Monate in eine Plattform steckt und keine KI ausgeliefert hat, hat nichts entrisikiert. Es hat ein KI-Projekt in ein Infrastrukturprojekt verwandelt, und Infrastrukturprojekte werden an Lieferterminen gemessen, die Datenplattformen historisch schlecht einhalten.

Was verlangt der EU AI Act von Ihren Daten?

Für Hochrisikosysteme stellt der EU AI Act ausdrückliche Anforderungen an die Datenschicht. Trainings-, Validierungs- und Testdatensätze müssen relevant, hinreichend repräsentativ und so weit wie möglich fehlerfrei und vollständig im Hinblick auf die Zweckbestimmung sein. Anbieter müssen Daten-Governance-Praktiken anwenden, die Erhebungsprozesse, Datenherkunft, Aufbereitungsschritte, die Formulierung von Annahmen, die Bewertung von Verfügbarkeit und Eignung sowie die Prüfung auf Bias abdecken, der Gesundheit, Sicherheit oder Grundrechte beeinträchtigen könnte.

Als technische Anforderungen gelesen statt als Rechtstext übersetzen sich diese Pflichten in Dinge, die ein Data Assessment heute prüfen kann: dokumentierte Herkunft pro Quelle, eine schriftliche Aufzeichnung der Aufbereitungs- und Transformationsschritte, eine Bias-Prüfung gegenüber den betroffenen Gruppen und einen Nachweis, dass die Daten den Einsatzkontext abbilden. Die Logging-Pflichten aus Artikel 12 kommen hinzu: Das System muss aufzeichnen, was es getan hat, was eine Pipeline-Designentscheidung ist und sich schmerzhaft nachrüsten lässt.

Ob Ihr System hochriskant ist, hängt von seiner Zweckbestimmung ab, und das sollte früh geklärt sein, weil es die Datenarchitektur verändert. Die Klassifizierung Ihres KI-Systems im Risikorahmen beschreibt, wie diese Einordnung erfolgt, und die Aufbewahrungspflichten für KI-Systemdokumentation beschreiben, wie lange die entstehenden Nachweise überdauern müssen. In regulierten Bereichen wie dem Gesundheitswesen kommen MDR und IVDR obendrauf und heben die Nachweisschwelle weiter an. Das ist Readiness-Arbeit und keine Rechtsberatung, aber sie vor dem Einfrieren der Architektur zu leisten, ist der Unterschied zwischen Compliance by Design und einem späteren Umbau.

Was sind die häufigsten Lücken in der Dateninfrastruktur?

Über Assessments hinweg wiederholen sich dieselben wenigen:

• Keine Ground Truth. Ergebnisse sind informell bekannt, aber nie zum verursachenden Fall erfasst. Häufig in der Instandhaltung, wo die Reparatur dokumentiert ist, der Fehlermodus aber nicht.
• Manuelle Schritte versteckt in der Pipeline. Eine Tabelle, ein Umbenennen, eine Person, die entscheidet, welches Duplikat bleibt. Im Piloten unsichtbar, in der Produktion blockierend.
• Keine historische Tiefe. Das System überschreibt statt anzuhängen, es gibt also einen aktuellen Zustand und keine Historie zum Lernen. Das in Woche eins zu entdecken ist eine gute Woche. In Monat vier nicht.
• Definitionsdrift. Ein Feld, dessen Bedeutung sich ohne Migration geändert hat, sodass zwei Epochen in einer Spalte liegen.
• Undokumentierte personenbezogene Daten. Freitextfelder mit Namen, Notizen oder Kennungen, die niemand klassifiziert hat und die im Compliance-Review auftauchen und den Launch aufhalten.
• Kein Monitoring. Pipelines, die still fehlschlagen. Wenn nichts alarmiert, sobald der gestrige Ladelauf ausblieb, liefert das Modell unbemerkt Vorhersagen auf veraltetem Input.
• Sensor- und Edge-Daten, die die Maschine nie verlassen. Häufig in der Fertigung, wo das Signal existiert, aber die Konnektivität zum Einsammeln fehlt und das Erfassungsprojekt das eigentliche erste Projekt ist. Predictive Maintenance steht und fällt genau damit.

Eine praktische Checkliste zur Datenreife

Bewerten Sie jeden Punkt für einen konkreten Use Case. Alles, was mit "nein" oder "unbekannt" beantwortet wird, ist ein Arbeitspaket mit Kosten, kein Detail für später.

• Die Vorhersage, ihr Zeitpunkt und die zu diesem Zeitpunkt verfügbaren Informationen sind aufgeschrieben.
• Jedes benötigte Feld ist über einen automatisierten Pfad mit benannter verantwortlicher Person erreichbar.
• Mindestens ein vollständiger Geschäftszyklus an Historie existiert, bekannte Lücken sind dokumentiert.
• Ground Truth existiert, ist mit dem Input-Datensatz verknüpft und war erst nach dem Vorhersagezeitpunkt verfügbar.
• Die Übereinstimmung zwischen Beurteilenden wurde gemessen, oder die Labels sind objektiv.
• Ein Profiling-Bericht existiert: Nullwerte, Duplikate, Wertebereiche, Verteilungsverschiebungen über die Zeit.
• Eine Geschäftskennzahl wurde aus Rohdaten nachgebaut und stimmt überein.
• Personenbezogene Daten sind identifiziert, mit Rechtsgrundlage für genau diesen Zweck und definierter Aufbewahrungsfrist.
• Der produktive Serving-Pfad ist beschrieben, inklusive Frischeanforderung und Verhalten im Fehlerfall.
• Training und Serving teilen sich eine Implementierung der Transformationen.
• Pipeline-Fehler lösen einen Alarm aus, den eine benannte Person erhält.
• Eine schwache Baseline wurde gefittet und ihr Ergebnis auf Signal und auf Leakage geprüft.

Zwölf Punkte, die meisten in ein bis zwei Tagen beantwortbar. Der Wert liegt nicht im Punktestand. Er liegt darin, dass jedes "unbekannt" sichtbar wird, bevor es zur Terminüberschreitung wird.

Was tun, wenn die Daten nicht bereit sind?

Nicht bereit ist ein Befund, kein Urteil. Meist stehen drei Antworten offen, und das Assessment sollte sagen, welche greift.

Den Use Case verengen. Häufig tragen die Daten eine kleinere Fassung derselben Idee. Statt Ausfälle im ganzen Werk vorherzusagen, sagen Sie sie für die zwei Maschinentypen mit instrumentierter Historie vorher. Ein enges System, das live geht, schlägt ein breites, das wartet.

Zuerst eine Erfassungsphase fahren. Liegt die Lücke bei Labels oder Historie, wird das erste Projekt die saubere Erfassung, und der KI-Build folgt, sobald genug zusammengekommen ist. Diese unglamouröse Empfehlung rettet ganze Budgets, und der Zeitrahmen gehört ehrlich benannt: Wer ein Jahr saisonaler Daten braucht, braucht ein Jahr.

Den Ansatz ändern. Manche Lücken sind architektonisch statt absolut. Weak Supervision, Transfer Learning, synthetische Augmentierung oder ein regelbasiertes System mit Human-in-the-Loop können eine dünne Labellage überbrücken. Jedes hat Kosten, und jedes ist eine legitime Antwort, sofern es bewusst gewählt wird und nicht, um schlechte Nachrichten zu vermeiden.

Was keine der drei ist: trotzdem weitermachen und hoffen, dass die Daten besser werden. Das ist der Weg, den wie Sie das Scheitern von KI-Projekten vermeiden beschreibt, und er endet jedes Mal gleich.

Das ehrliche Fazit

Datenreife ist die Randbedingung, die bestimmt, welche KI Sie bauen können, und sie ist vorab erkennbar, für einen Bruchteil dessen, was ihre Entdeckung mitten im Build kostet. Das Assessment ist bewusst unspektakulär: die echten Daten über den echten Zugriffspfad ziehen, profilieren, gegen eine Zahl abgleichen, der das Unternehmen vertraut, messen, ob Ihre Fachleute untereinander übereinstimmen, etwas Einfaches fitten und aufschreiben, was fehlt.

Heraus kommt ein Use Case, der jetzt baubar ist, einer, der nach konkret bezifferter Vorarbeit baubar ist, oder die klare Aussage, dass die Daten die Idee noch nicht tragen. Alle drei Ergebnisse sind nützlich. Nur eines davon ist teuer, wenn man es spät erfährt.

Wenn Sie noch abwägen, ob KI überhaupt auf die Roadmap gehört, sind die frühen Signale für KI-Reife die günstigere erste Lektüre, und realistischer Machine-Learning-ROI setzt die Erwartung, was ein funktionierendes System einbringt. Ist die Datenfrage geklärt, verbringt die anschließende Integrationsarbeit ihr Budget mit echter Unsicherheit statt mit der Wiederentdeckung, dass die Zahlen nie zusammenpassten.

Häufige Fragen

Brauchen wir ein Data Warehouse, bevor wir mit KI starten?

Für ein erstes Projekt meist nicht. Ein Warehouse hilft der Analytik im großen Maßstab, aber eine einzelne gut verstandene Quelle genügt oft, um einen Anwendungsfall zu belegen. Zuerst ein Warehouse zu bauen verzögert die KI-Arbeit um Quartale und optimiert häufig für Reportingfragen statt für die des Modells.

Wie lange dauert eine Bewertung der Dateninfrastruktur?

Üblicherweise zwei bis vier Wochen, je nach Zahl der Systeme im Umfang und der Geschwindigkeit der Zugriffsfreigaben. Freigaben sind meist der längste Weg, nicht die Analyse, weshalb es wichtiger ist, den Datenverantwortlichen in Woche eins zu finden als irgendein technischer Schritt.

Was, wenn unsere Daten über Systeme verteilt sind, die nicht miteinander sprechen?

Das ist der Normalzustand und kein Ausschlusskriterium. Die Bewertung klärt, welche Verknüpfungen der Anwendungsfall wirklich braucht, statt anzunehmen, dass alles vereinheitlicht werden muss. Die meisten ersten Projekte brauchen zwei oder drei verbundene Quellen, kein unternehmensweites Integrationsprogramm.

Können wir die Reife bewerten, ohne einem externen Partner Zugriff auf Produktivdaten zu geben?

Ja. Schemata, Zeilenzahlen, Feldbeschreibungen und eine kleine anonymisierte oder synthetische Stichprobe beantworten die meisten Reifefragen. Voller Zugriff zählt erst beim Übergang vom Assessment zum Bauen, und dann ist der Umfang eng genug für eine ordentliche Datenvereinbarung.