Wem gehören die Daten in einem Unternehmen? Die naheliegende Antwort: dem Team, das die Datenbank betreibt. Wer die Infrastruktur kontrolliert, kontrolliert auch die Daten – so die verbreitete Annahme. Ein Beitrag aus einer englischsprachigen Lernreihe zu Daten und KI dreht das um. Datenverantwortung hat mit Besitz wenig zu tun. Diese Verwechslung sorgt in vielen Organisationen für ungeklärte Zuständigkeiten.
Der Beitrag beginnt mit einem einfachen Szenario: eine Kundendatenbank, und die Frage, wem diese Daten gehören. Die Antworten kommen prompt und widersprechen sich – Datenbankteam, Anwendungsteam, Datenteam, Vertrieb, Finanzabteilung. Aus einer trivialen Frage wird ein Zuständigkeitsproblem. Daraus folgt die Unterscheidung, die den restlichen Text trägt: Wo Daten liegen, sagt nichts darüber aus, wer für sie einsteht.
Warum Speicherort und Verantwortung zwei verschiedene Dinge sind
Datenverantwortung heißt nicht, eine Datenbank physisch zu besitzen. Gemeint ist Rechenschaft: für die Bedeutung eines Datenbestands, für die wichtigsten Geschäftsregeln, für Qualitätserwartungen und für die Entscheidungen rund um diese Daten. Wer diese Rechenschaft trägt, muss nicht die Festplatten betreiben. Besitz beschreibt Zugriff, Verantwortung beschreibt Zuständigkeit.
Ein Beispiel: Personaldaten. Die Personalabteilung verantwortet die fachliche Bedeutung eines Mitarbeiterdatensatzes, die IT speichert ihn, das Datenbankteam wartet die Datenbank, das Security-Team regelt die Zugriffe. Alles notwendig. Trotzdem bleiben Fragen offen. Was bedeutet „aktiver Mitarbeiter“ genau, welche Felder sind Pflicht, was macht einen Datensatz gültig, wer darf ihn ändern, und was passiert, wenn zwei Systeme widersprechende Werte liefern? Das sind Verantwortungsfragen, keine Speicherfragen.
Owner, Steward, Custodian: drei Rollen mit drei unterschiedlichen Aufgaben
Drei Begriffe tauchen in der Data-Governance-Praxis oft gemeinsam auf, meinen aber nicht dasselbe. Der Owner ist die Person oder Fachfunktion, die für die Daten und die wesentlichen Entscheidungen darüber verantwortlich ist. Der Steward kümmert sich um die praktische Pflege: fachliche Definitionen, Datenqualität, Metadaten, Geschäftsregeln, Problemklärung und die Abstimmung zwischen Teams. Der Custodian übernimmt den technischen Betrieb und den Schutz – Speicherung, Datenbanken, Backups, Pipelines, technische Zugriffe, Verfügbarkeit, Sicherheitskontrollen.
Die Merkhilfe: Der Owner entscheidet, der Steward verwaltet, der Custodian betreibt. IBM und Microsoft beschreiben ähnliche Verantwortlichkeiten, doch Bezeichnungen und Grenzen unterscheiden sich von Organisation zu Organisation. Entscheidend ist nicht der Titel auf der Visitenkarte, sondern dass die Zuständigkeiten geklärt sind. Wo Rollen nur auf dem Papier existieren, entsteht keine Verantwortung, sondern eine weitere Dokumentationsleiche.
Ein Kundendatensatz, drei Zuständigkeiten und ein Streit über Zahlen
Konkret wird es an einem einzelnen Datensatz: Kundin Priya, Status aktiv, Kreditlimit ₹5,00,000 – in indischer Schreibweise, also fünf Lakh Rupien. Der Owner entscheidet, was „aktiver Kunde“ inhaltlich bedeutet. Der Steward sorgt dafür, dass diese Definition verstanden und überall gleich angewendet wird. Der Custodian stellt sicher, dass der Datensatz sicher gespeichert und technisch verfügbar ist. Ein Datensatz, drei Verantwortlichkeiten – keine davon lässt sich sinnvoll an eine andere abwälzen.
Dann der Konflikt: Die Finanzabteilung meldet 125.000 aktive Kunden, der Vertrieb 131.000, das CRM 128.500. Die technischen Teams prüfen die Pipelines, und alles ist grün. Die Datenbank läuft, die Pipelines arbeiten, die Dashboards laden. Vielleicht verwenden die Systeme unterschiedliche Definitionen, vielleicht zählt eines kürzlich inaktive Kunden mit, vielleicht fehlt eine organisationsweit verbindliche Festlegung. Die eigentliche Frage lautet dann nicht mehr, welches System defekt ist, sondern: Wer hat die Autorität, diese Definition zu entscheiden?
Was ein Data Owner nicht persönlich tun muss
Hier räumt der Beitrag mit einem Missverständnis auf, an dem viele Ownership-Modelle früh scheitern. Ein Data Owner muss nicht selbst Pipelines bauen, Datenbanken reparieren, SQL schreiben, Infrastruktur überwachen, jeden Datensatz bereinigen oder jede Zugriffsanfrage bearbeiten. Das wäre nicht zu leisten. Verantwortung heißt Rechenschaft, nicht die persönliche Ausführung jeder Aufgabe.
Die Analogie, die sich durch den Text zieht: ein Haus. Der Eigentümer repariert nicht zwingend die Rohre, verlegt keinen Strom, putzt keine Fenster, deckt kein Dach. Trotzdem bleibt er verantwortlich. Diese Verantwortung verschwindet nicht, weil spezialisierte Handwerker die Arbeit machen. Bei Daten ist es ähnlich: Verschiedene Teams erledigen verschiedene Arbeiten, die Zuständigkeit bleibt trotzdem zuordenbar.
Datenqualität und Lineage brauchen eine klare Zuständigkeit
Ein weiteres Beispiel: Das Alter eines Kunden steht als minus sieben im System. Das System hat den Wert akzeptiert, die Pipeline hat ihn weitergegeben, das Dashboard zeigt ihn an. Jemand muss jetzt entscheiden, ob dieser Wert gültig ist, welche Validierungsregel künftig gilt, wo der Fehler behoben wird, ob nachgelagerte Systeme ihn ablehnen sollen und wie schnell reagiert werden muss. Ohne klare Zuständigkeit wird daraus ein Problem für alle Beteiligten.
Und damit für niemanden. Der Beitrag verknüpft das mit zwei früheren Kapiteln: Kapitel 3 fragte, ob man den Daten trauen kann. Kapitel 4 folgte einem Wert vom Dashboard über die Metrik und den Datensatz bis zur Quelle. Das ist Lineage, und sie beantwortet die Frage, woher etwas kommt. Ist aber eine Quelle falsch, hilft Lineage beim Auffinden – nicht bei der Entscheidung, wer für die Definition oder die Geschäftsregel einsteht. Vertrauen, Herkunft und Verantwortung greifen ineinander. Ohne den dritten Baustein bleiben die ersten beiden unvollständig.
Wem gehören die Daten im Unternehmen? Sieben Fragen als Prüfschema
Für die Praxis gibt es eine kurze Fragenliste, die sich auf jeden wichtigen Datenbestand anwenden lässt. Wer besitzt beziehungsweise verantwortet diesen Datensatz? Was bedeutet er inhaltlich? Wer pflegt die fachlichen Definitionen? Wer verantwortet seine Qualität? Wer genehmigt Zugriffe? Wer löst Widersprüche zwischen Systemen auf? Und wer entscheidet abschließend, wenn etwas schiefgeht?
Lauten mehrere dieser Antworten „weiß nicht“, ist das nicht nur ein Datenverantwortungsproblem, sondern ein Rechenschaftsproblem. Der Beitrag empfiehlt, einen wichtigen Datensatz auszuwählen – Kunden, Umsatz, Mitarbeiter, Produkt, Finanzen oder Risiko – und die sieben Fragen ehrlich durchzugehen. Das Muster der Lücken sagt mehr über das tatsächliche Datenbetriebsmodell eines Unternehmens aus als jedes Organigramm.
Das Fazit in einem Satz: Wenn alle die Daten nutzen, aber niemand sie verantwortet, werden die Daten zur Verantwortung aller und zur Rechenschaft von niemandem. Dazwischen liegt die eigentliche Arbeit der Data Governance: nicht Werkzeuge beschaffen, sondern Zuständigkeiten benennen und Entscheidungsrechte festlegen.
Was das für den Alltag bedeutet
Daten wandern durch CRM, Datenbank, Pipeline, Warehouse, Dashboard und inzwischen auch durch KI-Anwendungen. Die Technologie wechselt auf diesem Weg mehrfach, die Zuständigkeit darf dabei nicht verschwinden. Wer in seinem Unternehmen auf die Frage nach dem Eigentum an Kundendaten fünf verschiedene Antworten bekommt, hat kein technisches Problem, sondern eine offene Entscheidung. Diese Entscheidung lässt sich nachholen. Sie erfordert aber eine bewusste Setzung und keine weitere Datenplattform.
Datenverantwortung ist also keine Frage des Besitzes, sondern der Rechenschaft. Und wie beim Haus repariert sich nichts von selbst, nur weil technisch alles läuft.
Quelle: fromdata2ai.substack.com
