Daten, offene Modelle und digitale Souveränität

Dasselbe Modell kann ganz verschiedene Abhängigkeiten schaffen

Du lässt 4.000 interne Rechnungen von einem Sprachmodell zusammenfassen. Dafür kannst du dieselben Modellgewichte auf einem Rechner im eigenen Gebäude ausführen. Du kannst sie auch in einer abgeschirmten Cloud-Umgebung deines Unternehmens betreiben. Oder du schickst die Rechnungen an einen fertigen Dienst des Modellentwicklers.

Das Modell kann in allen drei Fällen identisch sein. Deine Abhängigkeiten sind es nicht.

Beim lokalen Betrieb liegen Gewichte und Laufzeit auf deiner eigenen Hardware. Eine private Cloud ist eine Umgebung, die für deine Organisation reserviert ist. Wer sie betreibt, wer zugreifen darf und welche Kontrolle deine Organisation hat, wird technisch und vertraglich festgelegt. Bei einem gehosteten Dienst betreibt ein Anbieter Modell und Anwendung für dich. Du greifst über eine Oberfläche oder eine Programmierschnittstelle darauf zu. Eine Programmierschnittstelle, kurz API, lässt deine eigene Software Anfragen senden und Antworten empfangen.

Damit ändern sich die Wege deiner Daten. Es ändern sich aber auch Zuständigkeiten, Kosten, Updates und Ausstiegsmöglichkeiten. Ein lokales Modell kann ohne Internet laufen. Dafür musst du Betrieb, Sicherheit und Qualität selbst tragen. Ein gehosteter Dienst nimmt dir viel davon ab. Dafür brauchst du belastbare Zusagen des Anbieters.

Auf der Landkarte aus Kapitel 3 liegt dieses Kapitel deshalb um das Modell herum. Wir betrachten Daten, Anwendung, Laufzeit, Infrastruktur und Vertrag als ein System. Erst dieses System bestimmt, wer tatsächlich worüber verfügen kann.

Der Name eines Modells sagt wenig über deine Kontrolle. Der Betriebsweg sagt deutlich mehr.

Trainingsdaten, Betriebsdaten, Prompts, Protokolle und Ausgaben

Stell dir einen Assistenten für den Kundendienst vor. Eine Mitarbeiterin fügt eine Reklamation ein. Das System sucht die Bestellung, ruft die Lieferbedingungen ab und entwirft eine Antwort. In diesem kurzen Vorgang tauchen fünf verschiedene Datenarten auf.

Trainingsdaten sind die Texte, Bilder, Audiodateien oder anderen Beispiele, aus denen ein Modell vor und nach dem eigentlichen Vortraining gelernt hat. Sie wurden meist lange vor deiner Anfrage verarbeitet. Ein fertiges Modell enthält diese Dateien nicht als geordnetes Archiv. Trotzdem können einzelne Inhalte in seinen Gewichten Spuren hinterlassen.

Betriebsdaten sind Informationen, die deine Anwendung während der Nutzung aus eigenen Systemen holt. Dazu gehören im Beispiel Bestellung, Kundennummer und Lieferbedingung. Auch Dokumente für eine Suche mit RAG sind Betriebsdaten. RAG haben wir in Kapitel 13 als Abruf passender Quellen vor der Antwort kennengelernt.

Ein Prompt ist die aktuelle Eingabe an das Modell. Dazu zählen nicht nur die sichtbaren Worte der Mitarbeiterin. Verborgene Systemanweisungen, abgerufene Dokumente und Ergebnisse aufgerufener Werkzeuge können ebenfalls im Modellkontext landen.

Protokolle halten Vorgänge fest. Oft heißen sie Logs. Sie können Zeit, Nutzerkonto, Fehlermeldung, Prompt, Antwort, Werkzeugaufruf und technische Kennzahlen enthalten. Ein knappes Sicherheitsprotokoll ist etwas anderes als ein vollständiger Gesprächsmitschnitt.

Ausgaben sind die erzeugten Texte, Bilder, Entscheidungen oder Werkzeugbefehle. Sie können neue Geschäftsunterlagen werden. Dann brauchen auch sie eine Datenklasse, Aufbewahrungsfrist und verantwortliche Person.

Abbildung 14: Ein Cloud-Modell verarbeitet Eingaben außerhalb des eigenen Systems. Ein lokales Modell hält den direkten Datenweg im eigenen Netz. Werkzeuge, Aktualisierungen und Telemetrie können trotzdem weitere Verbindungen öffnen.

Die fünf Arten dürfen unterschiedliche Regeln haben. Ein öffentlicher Produkttext kann als Prompt erlaubt sein, eine vollständige Personalakte nicht. Ein Ausgabeentwurf kann 30 Tage aufbewahrt werden, ein technisches Fehlerprotokoll nur sieben. Ohne diese Trennung bleibt „Wir schützen die Daten“ eine hübsche, aber nutzlose Aussage.

Herkunft sowie rechtliche und vertragliche Grenzen

Nehmen wir an, dein Unternehmen besitzt 20.000 technische Handbücher. Einige stammen aus eigener Arbeit. Andere wurden von Lieferanten lizenziert. Wieder andere enthalten Namen von Kunden. Alle Dateien liegen im selben Ordner. Für ein Training sind sie trotzdem nicht dieselbe Sache.

Die dokumentierte Herkunft eines Datensatzes heißt Datenprovenienz. Sie beantwortet: Woher kam eine Datei, wann wurde sie übernommen, unter welchen Bedingungen, wie wurde sie verändert und wer hat das geprüft? Eine URL allein reicht nicht. Du brauchst auch Lizenz, Erhebungszweck, Auswahl, Filterung, Dubletten, Löschungen und bekannte Lücken.

Bei personenbezogenen Daten gilt in der Europäischen Union die Datenschutz-Grundverordnung. Entscheidend sind Zweck, Rechtsgrundlage und Rollen. Verarbeitet ein Anbieter personenbezogene Daten in deinem Auftrag, gehört ein Vertrag nach Artikel 28 DSGVO zur Prüfung. Bei Übermittlungen außerhalb des Europäischen Wirtschaftsraums kommen die Regeln aus Kapitel V hinzu. Ein Serverstandort in Frankfurt beantwortet noch nicht, welche Unterauftragnehmer oder Fernzugriffe beteiligt sind.

Beim Urheberrecht musst du Training und Ausgabe trennen. § 44b des deutschen Urheberrechtsgesetzes erlaubt Text und Data Mining an rechtmäßig zugänglichen Werken unter Bedingungen. Die Kopien sind zu löschen, wenn sie nicht mehr gebraucht werden. Rechteinhaber können sich die Nutzung bei online zugänglichen Werken maschinenlesbar vorbehalten. Daraus folgt keine pauschale Erlaubnis für jeden Datensatz und jeden Rechtsraum.

Für Ausgaben gilt wieder eine eigene Prüfung. Nach deutschem Recht schützt das Urheberrecht persönliche geistige Schöpfungen. Ob ein Mensch genug eigene schöpferische Entscheidungen getroffen hat, hängt vom Einzelfall ab. Der Bericht des U.S. Copyright Office vom Januar 2025 kommt für die Vereinigten Staaten ebenfalls zu einer fallbezogenen Prüfung. Diese Aussage lässt sich nicht einfach auf Deutschland übertragen.

Der europäische AI Act ergänzt seit 2024 weitere Pflichten nach Rolle und Risiko. Einzelne Teile gelten seit unterschiedlichen Daten. Am 5. August 2026 waren die allgemeinen Regeln sowie Transparenzpflichten weitgehend anwendbar, während für bestimmte Hochrisikobereiche besondere Übergänge galten. Für ein echtes Projekt zählt deshalb der aktuelle Rechtstext. Ein Buch ersetzt keine Rechtsberatung.

Vertrag und Technik müssen zusammenpassen. Prüfe Trainingsnutzung, Speicherfristen, Löschung, Verarbeitungsorte, Unterauftragnehmer, menschliche Einsicht, Sicherheitsvorfälle und Rückgabe deiner Daten. Ein Schalter in einer Oberfläche ersetzt diese Zusagen nicht.

Open Source, Open Weights und proprietäre Dienste

Du findest ein Modell zum Herunterladen. Ist es damit Open Source? Nein. Erst einmal kannst du nur sagen, dass Gewichte verfügbar sind.

Die Begriffe beschreiben verschiedene Dinge:

Begriff	Was tatsächlich zugänglich ist	Was daraus nicht folgt
Open Source AI	Nutzungs-, Prüf-, Änderungs- und Weitergabefreiheiten sowie die nötige Form zur Veränderung	Keine automatische Aussage über Qualität oder Sicherheit
Open Weights	Trainierte Parameter können bezogen werden	Keine vollständigen Trainingsdaten, kein Trainingscode und keine beliebige Nutzung
Offengelegte Architektur	Aufbau und Rechenverfahren sind beschrieben	Keine ausführbaren Gewichte und kein Recht zum Betrieb
Zugängliche API	Anfragen sind über eine Schnittstelle möglich	Kein Besitz an Gewichten, Laufzeit oder Dienst
Proprietärer Dienst	Anbieter betreibt ein geschlossenes Produkt	Keine einheitliche Regel für Datenschutz oder Verträge

Die Open Source Initiative, kurz OSI, veröffentlichte am 28. Oktober 2024 die Open Source AI Definition 1.0. Sie war bei der Prüfung am 5. August 2026 weiterhin die aktuelle stabile Fassung. Danach gehören zu Open Source AI die Freiheiten zur Nutzung, Prüfung, Veränderung und Weitergabe. Nötig sind außerdem ausreichend genaue Angaben zu den Trainingsdaten, der Code für Training und Ausführung sowie die Parameter unter passenden Bedingungen. Nicht jede Rohdatei muss veröffentlicht werden. Die Herkunft und Beschaffenheit der Daten müssen aber so genau beschrieben sein, dass Fachleute ein weitgehend vergleichbares System bauen können.

Die Lizenz entscheidet über Rechte und Pflichten. Ein Modell mit verfügbaren Gewichten kann Forschung und eigenen Betrieb erlauben und zugleich Bedingungen für große kommerzielle Dienste enthalten. „Herunterladbar“ bedeutet also weder „OSI-konformes Open Source“ noch „uneingeschränkt nutzbar“. Aktuelle Beispiele und ihre Lizenzstände stehen im datierten Begleiter zur Modelllandschaft 2026.

Offenheit ist kein einzelner Schalter. Prüfe Bestandteile, Lizenz und tatsächlichen Zugang getrennt.

Was Gewichte erlauben und was sie nicht verraten

Modellgewichte sind lange Sammlungen gelernter Zahlen. Mit Architektur, Laufzeit und passender Hardware kannst du daraus Antworten berechnen. Wenn die Lizenz es erlaubt, kannst du ein Modell lokal ausführen, untersuchen, anpassen oder in ein anderes Zahlenformat umwandeln.

Der grobe Speicherbedarf der reinen Gewichte lässt sich einfach abschätzen:

Parameterzahl x Bits pro Gewicht / 8 = Bytes für die Gewichte

Sieben Milliarden Gewichte mit 4 Bit brauchen rechnerisch etwa 3,5 Gigabyte. In der Praxis kommen Verwaltungsdaten, Zwischenspeicher und Laufzeit hinzu. Quantisierung nennt sich die Speicherung mit weniger Bits. Vier Bit brauchen für dieselbe Zahl an Gewichten nur ein Viertel des Platzes von 16 Bit. Wie stark sich die Qualität ändert, hängt von Modell, Verfahren und Aufgabe ab. Eine allgemeine Zusage wie „99 Prozent bleiben erhalten“ hat keine saubere gemeinsame Messgröße.

Aus einer Gewichtsdatei kannst du den vollständigen Trainingsbestand nicht ablesen. Du siehst weder die ursprünglichen Dateien noch ihre Lizenzen, Löschfristen oder Auswahlgründe. Auch Trainingscode, Filter und menschliche Entscheidungen fehlen, sofern sie nicht zusätzlich veröffentlicht wurden.

Trotzdem sind Gewichte kein sicherer Tresor. Modelle können seltene oder häufig wiederholte Passagen speichern. Bei einer Mitgliedschaftsanalyse versucht ein Angreifer festzustellen, ob ein bestimmter Datensatz wahrscheinlich zum Training gehörte. Bei einer Extraktion versucht er, gelernte Inhalte möglichst genau zurückzugewinnen. Forschende haben beide Angriffsklassen gezeigt. Ihr Erfolg hängt stark von Modell, Daten, Zugriff und Schutzmaßnahmen ab.

Vertrauliche Dokumente gehören deshalb nicht unverändert in ein Fine-Tuning, nur weil die Gewichte später im eigenen Netz liegen. Fine-Tuning passt Gewichte mit zusätzlichen Beispielen an. RAG hält Dokumente getrennt und erlaubt feinere Zugriffsregeln. Die abgerufenen Stellen landen während einer Anfrage trotzdem im Prompt und vielleicht im Protokoll.

Gewichte schaffen technische Möglichkeiten. Herkunft und Rechte musst du weiterhin dokumentieren.

Lokal, private Cloud oder gehosteter Betrieb

Nehmen wir einen Vertragsassistenten mit vertraulichen Anlagen. Drei Betriebsformen können sinnvoll sein. Ihre Grenzen liegen nur an verschiedenen Stellen.

Betriebsform	Kontrolle und Datenweg	Eigene Aufgaben	Typische Grenze
Lokal oder im eigenen Rechenzentrum	Gewichte, Laufzeit und Eingaben können im eigenen Netz bleiben	Hardware, Updates, Sicherheit, Tests und Bereitschaft	Kapazität und Fachwissen
Private Cloud	Reservierte Umgebung mit vertraglich festgelegtem Betreiber und Ort	Konfiguration, Identitäten, Schlüssel, Netz und Anbieterprüfung	Abhängigkeit von Cloud-Technik und Vertrag
Gehosteter Modellservice	Anbieter betreibt Modell, Skalierung und Aktualisierung	Datenregeln, Vertrag, Berechtigungen, Ausgaben und Kontrolle des Dienstes	Weniger Einblick und geringere technische Wechselkontrolle

Ein lokales Modell sendet von sich aus keine Datei ins Internet. Die Laufzeitsoftware kann aber Telemetrie, Aktualisierungen oder externe Werkzeuge aufrufen. Programme wie llama.cpp, Ollama oder LM Studio erleichtern den lokalen Betrieb. Ihre Einstellungen, Erweiterungen und Netzwerkverbindungen gehören trotzdem in die Prüfung.

Beim eigenen Betrieb übernimmst du die Arbeit des Anbieters. Du brauchst Modellupdates, Sicherheitskorrekturen, Backups, Zugriffsschutz, Überwachung und belastbare Tests. Ein kleines lokales Modell kann für Klassifikation oder interne Suche ausreichen. Schwierige Aufgaben können ein größeres gehostetes Modell benötigen. Das entscheidet dein Test aus Kapitel 16, nicht die Betriebsform.

Oft passt eine Mischung. Vertrauliche Standardfälle laufen lokal oder in einer privaten Cloud. Andere Aufgaben dürfen einen vertraglich geprüften Dienst nutzen. Entfernte Namen senken dabei manchmal das Risiko. Eine echte Anonymisierung ist mehr als das Ersetzen eines Namens. Der restliche Kontext kann eine Person weiterhin erkennbar machen.

Anbieterbindung, Portabilität und ein geplanter Ausstieg

Ein Team speichert 200 Systemanweisungen im Format eines Anbieters. Werkzeuge erwarten dessen Antwortschema. Die Suche nutzt einen eigenen Indexdienst. Evals liegen nur in der Oberfläche. Nach zwei Jahren soll alles wechseln. Die Modellanfrage ist dann der kleinste Teil der Arbeit.

Anbieterbindung bedeutet, dass ein Wechsel wegen technischer, vertraglicher oder organisatorischer Abhängigkeiten teuer wird. Portabilität beschreibt, wie gut du Daten, Anweisungen, Tests und Abläufe in eine andere Umgebung übertragen kannst. Eine API, die ähnlich aussieht, garantiert noch kein gleiches Verhalten.

Plane den Ausstieg vor dem Einstieg. Halte Prompts, Systemregeln und Werkzeugbeschreibungen in einem eigenen Versionssystem. Speichere Dokumente in üblichen Formaten. Trenne den Suchindex von seinen Quelldateien. Bewahre Testfälle und erwartete Ergebnisse außerhalb der Anbieteroberfläche auf. Dokumentiere Modelleinstellungen, Sicherheitsregeln und bekannte Abweichungen.

Der Vertrag braucht ebenfalls einen Ausgang. Welche Eingaben, Ausgaben, Protokolle, Anpassungen und Metadaten kannst du exportieren? In welchem Format? Wie lange dauert der Wechsel? Wann löscht der Anbieter Kopien und Sicherungen? Was passiert mit einem angepassten Modell oder Adapter?

In der Europäischen Union gilt der Data Act seit dem 12. September 2025. Er enthält Regeln zum Wechsel zwischen Datenverarbeitungsdiensten. Verträge müssen unter anderem Wechsel, exportierbare Daten, Fristen, Unterstützung und Löschung behandeln. Das hilft, ersetzt aber keinen technischen Test deines konkreten Systems.

Ein brauchbarer Exit ist kein PDF im Einkauf. Er ist ein einmal ausprobierter Weg.

Digitale Souveränität als konkrete Kontrolle

Nehmen wir an, ein deutsches Unternehmen nutzt ein Modell aus China auf Chips aus den Vereinigten Staaten in einem Rechenzentrum in Finnland. Ist das souverän? Die Länderliste allein beantwortet es nicht.

Digitale Souveränität bedeutet hier, dass eine Organisation begründete Entscheidungen treffen und nötige Änderungen selbst durchsetzen kann. Dafür braucht sie Kontrolle auf vier Ebenen.

Bei den Daten zählen Herkunft, Klassen, Zugriffsrechte, Schlüssel, Löschung und nachvollziehbare Wege. Beim Modell zählen Lizenz, verfügbare Gewichte, dokumentierte Grenzen, Evals und die Möglichkeit zum Wechsel. Bei der Infrastruktur zählen Betreiber, Standort, Netzwerk, Updates, Sicherungen und Wiederanlauf. Bei den Fähigkeiten zählt, ob das eigene Team das System prüfen, betreiben und im Notfall ersetzen kann.

Kontrolle muss nicht heißen, alles selbst zu bauen. Ein guter Vertrag mit einem spezialisierten Betreiber kann mehr tatsächliche Kontrolle bieten als ein ungepflegter Server im Keller. Ein offenes Modell hilft wenig, wenn nur eine Person es starten kann. Ein europäischer Anbieter hilft wenig, wenn Daten und Protokolle nicht exportierbar sind.

Schatten-KI zeigt die praktische Seite. Beschäftigte nutzen nicht freigegebene Dienste, wenn erlaubte Werkzeuge fehlen oder Regeln unverständlich sind. Ein bloßes Verbot löst das Bedürfnis nicht. Du brauchst Datenklassen mit Beispielen, passende freigegebene Werkzeuge, zentrale Einstellungen und einen schnellen Prüfweg für neue Fälle.

Souveränität ist damit kein Herkunftssiegel. Sie ist nachweisbare Handlungsfähigkeit.

Internationale Modellentwicklung ohne nationale Rangliste

DeepSeek veröffentlichte im Januar 2025 den technischen Bericht und die Gewichte von DeepSeek-R1. Der Bericht beschrieb Reinforcement Learning und Destillation für Reasoning-Modelle. Diese Veröffentlichung bleibt als datiertes Beispiel im Buch, weil sie einen technischen Bericht mit zugänglichen Gewichten verband.

Ein solches Beispiel belegt eine konkrete Veröffentlichung. Es beweist keine allgemeine Rangfolge von Ländern. Auch der Begriff „chinesisches Modell“ fasst Unternehmen, Forschungsteams, Rechenzentren, Datensätze, Chips und internationale Veröffentlichungen grob zusammen.

Mehrere technische Wege kommen zusammen. Mixture-of-Experts-Modelle aktivieren nur einen Teil ihrer Gewichte pro Token. Niedrigere Zahlenpräzision spart Speicher und Datenverkehr. Neue Attention-Varianten können bei langen Kontexten bestimmte Speicherlasten senken. Verbesserte Trainingsverfahren verändern zusätzlich, wie ein Team Daten und Rechenarbeit nutzt. Keiner dieser Wege gehört einem Land oder einem einzelnen Labor.

Auch Benchmarktabellen brauchen Grenzen. Anbieter wählen Modelleinstellungen, Werkzeuge, Reasoning-Budgets und Laufzeitumgebungen. Manche Werte stammen aus eigener Messung, andere aus fremden Ranglisten. Zwei gleiche Benchmarknamen können deshalb verschiedene Systeme vergleichen. Ein Ergebnis ist kein universelles Fähigkeitsurteil.

Exportkontrollen können in einem Land den Druck zu effizienterer Nutzung vorhandener Hardware erhöhen. Aus diesem nationalen Beispiel folgt aber keine allgemeine technische Ursache. Forschung, Kapital, Daten, Ingenieursarbeit, Infrastruktur und veröffentlichte Verfahren wirken zusammen. Ebenso wenig beweist ein Trainingsort allein Unabhängigkeit. Chips, Software und Datenquellen bleiben international verflochten.

Aktuelle Veröffentlichungen, Zugangsstände, Lizenzen und Vergleichszahlen stehen im datierten Begleiter zur Modelllandschaft 2026. Dort dürfen Versionsnamen altern. Das dauerhafte Prinzip bleibt: Vergleiche konkrete Artefakte und Bedingungen, keine Flaggen.

Erst Kontrollanforderungen wählen, dann den Anbieter

Du planst einen Assistenten für Personalfragen. Er soll öffentliche Stellenausschreibungen schreiben, interne Richtlinien durchsuchen und einzelne Personalakten erklären. Ein einziger pauschaler Haken „KI erlaubt“ würde drei verschiedene Daten- und Risikoklassen verdecken.

Lege zuerst die Kontrollanforderungen je Aufgabe fest:

1. Welche Daten dürfen hinein und welche bleiben ausgeschlossen?
2. Welche Systeme, Werkzeuge und Personen dürfen sie sehen?
3. Dürfen Prompts oder Ausgaben für Training und Produktverbesserung genutzt werden?
4. Wo werden Inhalte und Protokolle verarbeitet und wie lange bleiben sie dort?
5. Welche Lizenz erlaubt Betrieb, Anpassung und Weitergabe?
6. Welche Qualität und welches Sicherheitsverhalten muss dein Eval belegen?
7. Welche Daten, Regeln und Tests kannst du exportieren?
8. Wer kann den Betrieb übernehmen, stoppen und auf eine andere Lösung umstellen?

Erst danach vergleichst du Angebote. Für öffentliche Ausschreibungen kann ein gehosteter Dienst passen. Für interne Richtlinien reicht vielleicht eine private Cloud mit RAG. Personalakten verlangen möglicherweise einen lokalen Weg mit besonders engem Zugriff. Das sind keine allgemeinen Antworten. Es sind Beispiele dafür, wie Datenklasse und Aufgabe die Auswahl bestimmen.

Beziehe Einkauf, Datenschutz, Informationssicherheit, Fachbereich und Betrieb früh ein. Der Einkauf sieht Vertragsfristen. Der Fachbereich kennt die Daten. Der Betrieb kennt Abhängigkeiten. Die Sicherheit kennt Zugriffswege. Eine Person allein sieht selten das ganze System.

Prüfe die Exit-Route in einem kleinen Versuch. Exportiere Testfälle, ersetze das Modell und miss erneut. Wenn das nur mit monatelanger Sonderarbeit möglich ist, weißt du wenigstens vor dem großen Vertrag davon.

Der Anbieter ist eine Antwort. Deine Kontrollanforderungen sind die Frage davor.

Kontrolle zeigt sich im Ausstieg

Fünf kurze Fälle prüfen das Modell im Kopf:

1. Gewichte liegen auf deinem Server. Sind die Trainingsdaten damit bekannt? Nein. Dafür brauchst du gesonderte Angaben zu Herkunft, Auswahl und Verarbeitung.
2. Ein Modell ist herunterladbar. Darfst du es uneingeschränkt kommerziell anbieten? Nicht automatisch. Die Lizenz entscheidet.
3. Ein Anbieter verarbeitet in der EU. Sind damit alle Datenschutzfragen geklärt? Nein. Rollen, Zweck, Vertrag, Unterauftragnehmer, Fernzugriffe und Löschung fehlen.
4. Ein lokales Modell nutzt eine Websuche. Bleibt jeder Prompt im eigenen Netz? Nein. Der Werkzeugaufruf öffnet einen weiteren Datenweg.
5. Ein Modell gewinnt einen Benchmark. Ist es für deinen Prozess besser? Erst dein Eval unter vergleichbaren Bedingungen kann das zeigen.

Du kannst die Entscheidung jetzt als Kette lesen: Datenart, Herkunft, Rechte, Betriebsweg, Kontrolle, Test und Exit. Fehlt ein Glied, bleibt eine Abhängigkeit unsichtbar.

Kapitel 21 betrachtet, was solche Systeme für Arbeit, Bildung und öffentliche Information verändern. Dort wird die Datenfrage noch einmal praktisch. Wer darf mit welchen Quellen arbeiten, wer prüft die Ausgabe und wie bleibt eine Behauptung nachvollziehbar?

Weiter geht es mit Kapitel 21.