Daten & Integration

KI ist nur so belastbar wie ihr Datenfundament

Wenn eine KI-Anwendung eine überzeugende Antwort formuliert, wirkt es schnell so, als läge die eigentliche Intelligenz im Modell.

Im betrieblichen Alltag hängt die Qualität jedoch von vielen anderen Fragen ab:

• Ist der verwendete Kundenstatus aktuell?
• Wurde die richtige Produktvariante geladen?
• Gilt die herangezogene Richtlinie noch?
• Ist das Dokument freigegeben?
• Darf die anfragende Person diese Information sehen?
• Wurde der Vorgang bereits bearbeitet?
• Welche Version des Angebots ist verbindlich?
• Wurde das Ergebnis menschlich geprüft?
• Welches System darf eine Änderung speichern?
• Was geschieht, wenn zwei Systeme unterschiedliche Werte enthalten?

Ein Sprachmodell kann diese Fragen nicht allein beantworten.

Es benötigt eine Architektur, die festlegt:

• welche Daten existieren,
• wo sie gespeichert sind,
• wer für sie verantwortlich ist,
• wie sie aktualisiert werden,
• welche Beziehungen zwischen ihnen bestehen,
• und welche Aktionen daraus folgen dürfen.

Ein KI-Modell kann Informationen interpretieren. Es kann nicht eigenständig festlegen, welches System im Unternehmen die Wahrheit führt.

Deshalb beginnt eine belastbare KI-Plattform nicht mit einem Chatfenster.

Sie beginnt mit Datenverantwortung und Systemgrenzen.

Das Modell ist nicht das System

Ein Sprachmodell verarbeitet einen bereitgestellten Kontext und erzeugt daraus ein Ergebnis.

Es ist besonders leistungsfähig bei:

• Sprache,
• Zusammenfassung,
• Klassifikation,
• semantischer Einordnung,
• Strukturierung,
• und Formulierung.

Es ist dagegen nicht dafür gedacht, dauerhaft und verbindlich zu speichern:

• ob ein Kunde aktiv ist,
• welcher Preis freigegeben wurde,
• welcher Status aktuell gilt,
• welche Rechnung bereits bezahlt wurde,
• welche Version eines Dokuments gültig ist,
• oder wer eine Entscheidung bestätigt hat.

Solche Informationen benötigen:

• strukturierte Datensätze,
• eindeutige IDs,
• definierte Zustände,
• Transaktionen,
• Berechtigungen,
• Zeitstempel,
• und nachvollziehbare Änderungen.

Das Sprachmodell kann beispielsweise vorschlagen:

{
  "customer_id": "cus_481",
  "suggested_status": "qualified",
  "missing_information": [
    "budget",
    "target_date"
  ],
  "requires_review": true
}

Ob der Kundenstatus tatsächlich geändert wird, entscheidet nicht das Modell allein.

Die Plattform prüft:

• Ist der Kunde eindeutig?
• Darf die anfragende Rolle den Status verändern?
• Sind die notwendigen Regeln erfüllt?
• Ist eine Freigabe erforderlich?
• Welches System führt den Kundenstatus?
• Wurde die Änderung erfolgreich bestätigt?

Erst danach wird der Zustand verbindlich gespeichert.

Das System of Record beantwortet die Frage: Was gilt?

Für jede relevante Information sollte ein führendes System benannt sein.

Dieses wird häufig als System of Record bezeichnet.

Es beantwortet:

Welches System enthält den verbindlichen Stand dieser Information?

Beispiele können sein:

|Information|Führendes System| |---|---| |Kundenstammdaten|CRM| |Artikelnummer und Preis|ERP| |Lagerbestand|Warenwirtschaft oder WMS| |Aufgabenstatus|Projektmanagement| |Originaldokument|Dokumentenmanagement| |Rechnungsbuchung|Finanzsystem| |Freigegebener Content|Content-Plattform oder CMS| |Jobstatus|Automatisierungsplattform| |Rollen und Identitäten|Identity Provider| |Produktbeschreibung|PIM| |Veröffentlichungsstatus|Publishing-System|

Diese Zuordnung kann je nach Unternehmen anders aussehen.

Entscheidend ist nicht, welches Produkt verwendet wird.

Entscheidend ist, dass die Verantwortung eindeutig bleibt.

Ohne diese Klarheit entstehen typische Konflikte:

• CRM und ERP enthalten unterschiedliche Kundennamen.
• Der Shop zeigt einen anderen Preis als die Warenwirtschaft.
• Ein PDF enthält eine neuere Information als die Datenbank.
• Zwei Plattformen führen unterschiedliche Statuswerte.
• Eine KI-Antwort basiert auf einer historischen Dokumentversion.
• Eine manuelle Korrektur wird beim nächsten Import überschrieben.

Eine Integration darf solche Konflikte nicht verdecken.

Sie muss sie sichtbar und bearbeitbar machen.

Eine einzige „Single Source of Truth“ ist häufig unrealistisch

Der Wunsch nach einer einzigen zentralen Wahrheit klingt attraktiv.

In der Praxis besitzt ein Unternehmen jedoch mehrere spezialisierte Wahrheiten.

Das ERP weiß:

• welcher Auftrag besteht,
• welcher Preis gebucht wurde,
• welcher Artikel verwendet wird.

Das CRM weiß:

• wer der Ansprechpartner ist,
• welche Kommunikation stattgefunden hat,
• welche Vertriebschance offen ist.

Das Dokumentenmanagement weiß:

• welches Originaldokument abgelegt wurde,
• welche Dateiversion existiert,
• welche Aufbewahrungsregeln gelten.

Die Content-Plattform weiß:

• welcher Entwurf freigegeben wurde,
• aus welchen Quellen er entstand,
• welche Kanalvarianten dazugehören.

Die Frage lautet deshalb nicht:

Wie bringen wir alle Informationen in ein einziges System?

Sondern:

Wie verbinden wir mehrere führende Systeme, ohne ihre Zuständigkeiten zu vermischen?

Eine gute Architektur besitzt mehrere Systeme of Record und eine klare Integrationslogik zwischen ihnen.

PostgreSQL als belastbares Rückgrat

Für die zentrale Plattform eignet sich eine relationale Datenbank wie PostgreSQL besonders gut.

Sie bietet:

• strukturierte Tabellen,
• Beziehungen,
• Transaktionen,
• eindeutige Schlüssel,
• Constraints,
• Indizes,
• Rollen,
• Views,
• Trigger,
• JSON-Felder,
• Volltextsuche,
• und Erweiterbarkeit.

PostgreSQL kann gleichzeitig stark strukturiert und flexibel arbeiten.

Das ist wichtig, weil KI-Prozesse unterschiedliche Datenarten verbinden:

• Kunden,
• Vorgänge,
• Quellen,
• Dokumente,
• Jobs,
• Prompts,
• Modelle,
• Ergebnisse,
• Freigaben,
• Kosten,
• und Veröffentlichungen.

Ein relationales Modell sorgt dafür, dass diese Objekte nicht nur als lose Dateien oder Chatverläufe existieren.

Sie erhalten definierte Beziehungen.

Beispiel:

Kunde
→ besitzt Anfrage
→ Anfrage erzeugt Job
→ Job verwendet Promptversion
→ Job nutzt Quellen
→ Job erzeugt Ergebnis
→ Ergebnis erhält Review
→ Review führt zu Freigabe
→ Freigabe ermöglicht Veröffentlichung

Diese Kette lässt sich später:

• durchsuchen,
• prüfen,
• auswerten,
• und vollständig nachvollziehen.

Supabase ergänzt PostgreSQL um Plattformfunktionen

Supabase baut auf PostgreSQL auf und ergänzt die Datenbank um Funktionen, die für moderne Anwendungen hilfreich sein können.

Dazu gehören beispielsweise:

• Authentifizierung,
• APIs,
• Dateispeicherung,
• Echtzeitereignisse,
• serverseitige Funktionen,
• und Row Level Security.

Dadurch kann eine Plattform schneller auf einer belastbaren Datenbasis aufgebaut werden.

Wichtig bleibt:

Supabase ersetzt kein sauberes Datenmodell.

Eine automatisch erzeugte API ist nur so sinnvoll wie die dahinterliegende Struktur.

Vor der technischen Umsetzung müssen deshalb Fragen geklärt werden:

• Welche Entitäten existieren?
• Welche Beziehungen gelten?
• Welche Informationen sind Pflicht?
• Welche Zustände sind zulässig?
• Welche Rollen dürfen lesen oder schreiben?
• Welche Daten sind abgeleitet?
• Welche Werte müssen historisiert werden?
• Welche Änderungen benötigen einen Audit Trail?

Die Datenbank ist nicht nur ein Speicher.

Sie bildet die fachliche Struktur des Systems ab.

Datenobjekte statt unverbundener Dateien

Viele frühe KI-Prototypen arbeiten überwiegend mit Dateien:

• PDF hochladen,
• Text extrahieren,
• Modell aufrufen,
• Antwort anzeigen.

Für einen einzelnen Test kann das genügen.

Im Produktivsystem muss jedoch geklärt werden, was diese Datei bedeutet.

Ein Dokument kann gehören zu:

• einem Kunden,
• einem Projekt,
• einer Rechnung,
• einer Quelle,
• einem Angebot,
• einer Maschine,
• einer Kampagne,
• oder einem Prüfprozess.

Zusätzlich besitzt es Eigenschaften wie:

• Dokumenttyp,
• Status,
• Version,
• Sprache,
• Gültigkeit,
• Vertraulichkeit,
• Herkunft,
• und verantwortliche Rolle.

Ein mögliches Datenobjekt könnte enthalten:

{
  "document_id": "doc_8712",
  "document_type": "service_manual",
  "title": "Wartungshandbuch Linie 3",
  "version": "4.2",
  "status": "approved",
  "valid_from": "2026-01-01",
  "valid_until": null,
  "domain_id": "maintenance",
  "access_level": "internal",
  "source_file_id": "file_9921"
}

Die Datei bleibt das Original.

Das Dokumentobjekt macht sie für Prozesse und Rechte nutzbar.

Originaldaten und abgeleitete Daten müssen getrennt bleiben

Ein häufiges Risiko besteht darin, automatisch extrahierte Informationen wie gesicherte Originaldaten zu behandeln.

Beispiel:

Aus einer Rechnung erkennt ein Modell:

• Rechnungsnummer,
• Datum,
• Nettobetrag,
• Bankverbindung,
• Bestellnummer.

Diese Werte können korrekt sein.

Sie können aber auch:

• falsch erkannt,
• unvollständig,
• vertauscht,
• oder mehrdeutig

sein.

Deshalb sollte das System unterscheiden zwischen:

Original

Die hochgeladene Datei oder der empfangene Datensatz.

Extraktion

Automatisch erkannte Informationen.

Validierung

Technisch oder fachlich geprüfte Werte.

Freigabe

Von einer verantwortlichen Rolle bestätigte Information.

Übernahme

Verbindlich in ein führendes System geschriebener Wert.

Ein möglicher Ablauf:

Originalrechnung
→ automatische Extraktion
→ Plausibilitätsprüfung
→ Abgleich mit ERP
→ menschliche Prüfung bei Abweichung
→ freigegebener Buchungsvorschlag

Das Original wird niemals durch die Modellinterpretation ersetzt.

Datenherkunft muss sichtbar bleiben

Wenn ein Ergebnis aus mehreren Quellen und Verarbeitungsschritten entsteht, sollte seine Herkunft nachvollziehbar sein.

Diese Herkunft wird häufig als Data Lineage oder Lineage bezeichnet.

Beispiel:

Lieferanten-PDF
→ Text extrahiert
→ Produktattribute erkannt
→ Attribute fachlich bestätigt
→ Produktkern erzeugt
→ Shoptext abgeleitet
→ Social-Media-Fassung erzeugt
→ redaktionell freigegeben

Für einen erzeugten Text sollte sichtbar sein:

• welche Quellen verwendet wurden,
• welche Datenfelder eingeflossen sind,
• welcher Prompt genutzt wurde,
• welches Modell beteiligt war,
• welche Person Änderungen vorgenommen hat,
• und welche Version veröffentlicht wurde.

Lineage beantwortet:

• Woher stammt diese Aussage?
• Welche Quelle muss aktualisiert werden?
• Welche Inhalte sind von einer Änderung betroffen?
• Kann das Ergebnis reproduziert werden?
• Welche Schritte waren automatisch?
• Wo hat ein Mensch entschieden?

Lineage ist mehr als ein Quellenverzeichnis

Ein Quellenverzeichnis sagt:

Dieser Text verwendet Dokument A und Dokument B.

Lineage beschreibt zusätzlich die Verarbeitungskette.

Beispiel:

Quelle A, Version 3.1
+ Produktdatensatz 481, Stand 14.07.2026
+ Markenregelwerk, Version 2.4
→ Prompt „Product Story“, Version 5.2
→ Modelllauf 17
→ Entwurf 1
→ redaktionelle Korrektur
→ Freigabe durch Produktmanagement
→ Veröffentlichung im Shop

Dadurch lässt sich später nachvollziehen, ob eine Änderung erforderlich ist.

Wenn sich beispielsweise der Lieferumfang eines Produkts ändert, können alle abhängigen Inhalte ermittelt werden.

Ohne Lineage müsste das Unternehmen manuell suchen:

• Welche Texte erwähnen den alten Lieferumfang?
• Welche Social Posts sind betroffen?
• Welche Übersetzungen müssen angepasst werden?
• Welche bereits geplanten Veröffentlichungen enthalten die Aussage?

Mit einer verknüpften Herkunftskette wird diese Auswirkung sichtbar.

Strukturierte Beziehungen bilden den Geschäftskontext

Eine reine Dokumentensuche kennt Texte.

Eine Datenplattform kennt zusätzlich Beziehungen.

Beispiel:

Kunde
→ besitzt Anlage
→ Anlage besitzt Servicevertrag
→ Servicevertrag definiert Reaktionszeit
→ Servicefall betrifft Anlage
→ Servicefall verwendet Dokumentation
→ Servicefall erzeugt Wartungsauftrag

Oder:

Produkt
→ besitzt Variante
→ Variante besitzt Attribute
→ Attribute stammen aus Quellen
→ Produktkern erzeugt Kanaltexte
→ Kanaltexte gehören zu Kampagne
→ Kampagne wird veröffentlicht

Diese Beziehungen ermöglichen präzisere KI-Unterstützung.

Eine Serviceanfrage kann nicht nur sprachlich ausgewertet werden.

Das System kann zusätzlich laden:

• betroffene Anlage,
• Wartungshistorie,
• gültigen Vertrag,
• frühere Störungen,
• und zuständige Rolle.

Die KI arbeitet dann nicht mit einem allgemeinen Textkontext.

Sie arbeitet mit einem strukturierten Geschäftskontext.

IDs sind wichtiger als Namen

Namen und Bezeichnungen können sich ändern.

Eindeutige IDs sollten deshalb die technische Verbindung bilden.

Beispiel:

Nicht ausreichend:

Kunde: Müller GmbH

Besser:

customer_id: cus_481
display_name: Müller GmbH

Dasselbe gilt für:

• Produkte,
• Projekte,
• Dokumente,
• Benutzer,
• Maschinen,
• Kampagnen,
• Jobs,
• und Freigaben.

Eindeutige IDs verhindern Probleme durch:

• Schreibvarianten,
• Umbenennungen,
• Mehrdeutigkeiten,
• Übersetzungen,
• und doppelte Einträge.

Ein Sprachmodell kann Namen zur Einordnung verwenden.

Der Prozess sollte verbindliche Aktionen auf IDs stützen.

Fachliche Schlüssel und technische Schlüssel erfüllen unterschiedliche Zwecke

Ein Datensatz kann mehrere Identifikatoren besitzen.

Beispiel:

Interne Datenbank-ID: 91f0...
Kundennummer: K-10482
ERP-ID: 471182
CRM-ID: crm_88192
Externe Referenz: EXT-2026-184

Die Plattform sollte diese Referenzen miteinander verbinden.

Dadurch kann ein Vorgang über mehrere Systeme hinweg verfolgt werden.

Wichtig ist, die Bedeutungen nicht zu vermischen.

Eine ERP-ID ist nicht automatisch dieselbe Identität wie eine CRM-ID.

Die Plattform benötigt eine explizite Zuordnung.

APIs definieren kontrollierte Systemgrenzen

Eine API beschreibt, wie ein System Daten oder Funktionen bereitstellt.

Sie ist mehr als eine technische URL.

Eine gute API definiert:

• welche Funktion angeboten wird,
• welche Eingaben benötigt werden,
• welche Antwort entsteht,
• welche Fehler möglich sind,
• welche Rolle zugreifen darf,
• und welche Version gilt.

Beispiel:

GET /api/customers/cus_481

Antwort:

{
  "customer_id": "cus_481",
  "name": "Müller GmbH",
  "status": "active",
  "crm_reference": "crm_88192"
}

Oder:

POST /api/content-items/item_912/reviews

{
  "decision": "request_changes",
  "comment": "Technische Aussage zur Kompatibilität prüfen."
}

Die API macht die Systemgrenze sichtbar.

Sie verhindert, dass jede Anwendung direkt und unkontrolliert auf interne Tabellen zugreift.

API-first bedeutet nicht API-only

Eine API-first-Architektur entwickelt Funktionen so, dass sie über definierte Schnittstellen nutzbar sind.

Dadurch können dieselben Fähigkeiten verwendet werden durch:

• Webanwendung,
• interne Oberfläche,
• n8n-Workflow,
• mobiles Frontend,
• Partnerintegration,
• oder automatisierten Agenten.

Beispiel:

Die Funktion „Review anfordern“ existiert als Plattformfähigkeit.

Sie wird nicht separat eingebaut in:

• Content-Editor,
• Angebotsprozess,
• Rechnungsworkflow,
• und Dokumentenanwendung.

Stattdessen verwenden alle dieselbe Schnittstelle.

API-first bedeutet jedoch nicht, dass jede interne Kleinigkeit als öffentliche API bereitgestellt werden muss.

Die Schnittstelle sollte dort liegen, wo eine stabile Systemgrenze besteht.

APIs brauchen Versionierung

Schnittstellen verändern sich.

Ein Feld wird ergänzt.

Ein Status wird umbenannt.

Ein Rückgabeformat wird erweitert.

Ohne Versionierung können bestehende Integrationen unerwartet brechen.

Mögliche Ansätze sind:

/api/v1/jobs
/api/v2/jobs

oder versionierte Schemas innerhalb derselben Schnittstelle.

Entscheidend ist:

• Bestehende Verbraucher werden nicht unbemerkt beschädigt.
• Änderungen werden dokumentiert.
• Übergangsfristen sind definiert.
• Testumgebungen stehen bereit.
• Alte Versionen werden kontrolliert abgeschaltet.

Webhooks transportieren Ereignisse

APIs werden häufig aktiv aufgerufen:

Gib mir den aktuellen Kundenstatus.

Webhooks informieren dagegen über ein Ereignis:

Der Kundenstatus wurde verändert.

Typische Ereignisse sind:

• Bestellung eingegangen,
• Dokument hochgeladen,
• Freigabe erteilt,
• Rechnung bezahlt,
• Artikel veröffentlicht,
• Produkt geändert,
• oder Termin abgesagt.

Ein Ereignis kann beispielsweise enthalten:

{
  "event_id": "evt_77291",
  "event_type": "product.updated",
  "occurred_at": "2026-07-28T14:42:00Z",
  "source": "erp",
  "entity_id": "prd_481",
  "version": 17
}

Die Plattform kann daraus Folgeprozesse ableiten.

Beispiel:

Produkt aktualisiert
→ relevante Änderungen bestimmen
→ betroffene Inhalte finden
→ Aktualisierungsjobs erzeugen
→ Review anfordern

Ereignisse beschreiben Tatsachen, keine Befehle

Ein Ereignis sollte ausdrücken, was geschehen ist.

Beispiel:

invoice.received

Nicht:

process_invoice_now

Der Unterschied ist wichtig.

Ein Fakt kann von mehreren Systemen verarbeitet werden.

Die jeweilige Reaktion bleibt in ihrer Verantwortung.

Beispiel:

invoice.received
→ Dokumentenservice extrahiert Daten
→ Finanzplattform erzeugt Prüfjob
→ Monitoring aktualisiert Eingangszahlen

Dadurch werden Systeme weniger eng miteinander gekoppelt.

Synchrone und asynchrone Integration erfüllen unterschiedliche Aufgaben

Eine synchrone Integration wartet unmittelbar auf eine Antwort.

Beispiel:

Benutzer öffnet Kundenansicht
→ CRM-Daten werden abgerufen
→ Antwort erscheint

Geeignet für:

• schnelle Leseoperationen,
• direkte Validierungen,
• und interaktive Nutzeraktionen.

Eine asynchrone Integration startet einen Prozess und liefert zunächst nur einen Status.

Beispiel:

Benutzer startet Dokumentenanalyse
→ Job wird angelegt
→ Verarbeitung läuft im Hintergrund
→ Ergebnis wird später bereitgestellt

Geeignet für:

• lange Aufgaben,
• Modellaufrufe,
• Dateiverarbeitung,
• Generierung,
• komplexe Recherchen,
• und systemübergreifende Abläufe.

Ein häufiger Architekturfehler besteht darin, lange und fehleranfällige Prozesse synchron innerhalb einer Benutzeranfrage auszuführen.

Dann entstehen:

• Timeouts,
• unklare Zustände,
• schlechte Nutzererfahrung,
• und schwer beherrschbare Wiederholungen.

Integration benötigt einen klaren Verantwortungsfluss

Für jede Verbindung sollte beantwortet werden:

• Wer initiiert die Übertragung?
• Welches System ist Quelle?
• Welches System ist Ziel?
• Welche Daten werden übertragen?
• Wird gelesen oder geschrieben?
• Welche Version wird verwendet?
• Wie wird Erfolg bestätigt?
• Wie wird ein Fehler behandelt?
• Wie werden Dubletten verhindert?
• Was passiert bei einem Konflikt?

Beispiel:

|Frage|Antwort| |---|---| |Quelle|ERP| |Ziel|PIM| |Objekt|Produkt| |Auslöser|product.updated| |Richtung|ERP → PIM| |Verbindliche Felder|Artikelnummer, Material, Maße| |Nicht verbindliche Felder|Marketingtext| |Konfliktregel|ERP gewinnt bei technischen Attributen| |Fehlerbehandlung|Job Queue und manueller Review| |Idempotenz|Produkt-ID + Versionsnummer|

Diese Klarheit ist wichtiger als die Wahl des Integrationstools.

Direkter Datenbankzugriff ist selten die beste Integration

Es kann technisch einfach sein, einer Anwendung direkten Zugriff auf Tabellen eines anderen Systems zu geben.

Langfristig entstehen jedoch Risiken:

• interne Tabellen ändern sich,
• Geschäftsregeln werden umgangen,
• Rechte sind zu weit,
• Änderungen bleiben unprotokolliert,
• und Datenabhängigkeiten werden unsichtbar.

Besser sind:

• dokumentierte APIs,
• Views,
• kontrollierte Datenexporte,
• oder Ereignisschnittstellen.

Direkter Datenbankzugriff kann in bestimmten internen Szenarien sinnvoll sein.

Er sollte aber bewusst und mit klaren Grenzen eingesetzt werden.

Datenreplikation ist nicht gleich Datenverantwortung

Eine Plattform kann Daten aus einem führenden System zwischenspeichern.

Beispiel:

• CRM-Kunden werden für schnelle Suche repliziert.
• Produktdaten werden für Content-Produktion gespiegelt.
• Dokumentmetadaten werden für Wissenssuche übernommen.

Diese Kopie wird häufig als Cache, Projektion oder Replikat bezeichnet.

Sie ist nicht automatisch die neue Wahrheit.

Das System muss wissen:

• Woher stammt der Wert?
• Wann wurde er zuletzt synchronisiert?
• Darf er lokal verändert werden?
• Was geschieht bei Abweichungen?
• Wann wird er als veraltet betrachtet?

Ein replizierter Datensatz kann beispielsweise enthalten:

{
  "customer_id": "cus_481",
  "source_system": "crm",
  "source_version": "178",
  "synced_at": "2026-07-28T15:03:00Z",
  "local_edit_allowed": false
}

Datenkonflikte müssen bewusst gelöst werden

Angenommen:

• Das CRM enthält die E-Mail-Adresse A.
• Das ERP enthält die E-Mail-Adresse B.
• Eine eingehende Anfrage kommt von Adresse C.

Welche Adresse ist richtig?

Die Integration darf nicht zufällig den zuletzt übertragenen Wert übernehmen.

Mögliche Konfliktstrategien sind:

Führendes System gewinnt

Für ein definiertes Feld gilt immer eine bestimmte Quelle.

Neueste bestätigte Änderung gewinnt

Nur möglich, wenn Zeitstempel und Änderungsrechte belastbar sind.

Zusammenführung

Mehrere Werte werden als getrennte Informationen gespeichert.

Menschliche Prüfung

Bei kritischen Widersprüchen wird kein automatischer Wert gewählt.

Feldbezogene Verantwortung

Beispiel:

• Rechnungsadresse aus ERP
• Ansprechpartner aus CRM
• Login-E-Mail aus Identity Provider

Konfliktregeln sollten pro Datentyp definiert werden.

Das Datenmodell sollte fachliche Zustände ausdrücken

Ein Statusfeld wie:

status = 3

ist technisch kompakt, aber fachlich schwer verständlich.

Besser sind lesbare Zustände:

draft
in_review
approved
published
archived

Zusätzlich sollten erlaubte Übergänge definiert werden.

Beispiel:

draft
→ in_review
→ approved
→ published

Nicht erlaubt:

draft
→ published

Solche Regeln können auf Datenbank- oder Anwendungsebene abgesichert werden.

Dadurch wird verhindert, dass einzelne Integrationen wichtige Prozessschritte umgehen.

Status ist nicht dasselbe wie Ergebnis

Ein Job kann technisch erfolgreich sein.

Das fachliche Ergebnis kann trotzdem noch ungeprüft sein.

Beispiel:

Jobstatus: succeeded
Contentstatus: draft
Reviewstatus: pending
Publishingstatus: not_scheduled

Diese Ebenen sollten getrennt bleiben.

Sonst kann aus:

Generierung erfolgreich

versehentlich werden:

Inhalt freigegeben.

Ein technischer Erfolg bedeutet lediglich, dass die Aufgabe ausgeführt wurde.

Nicht, dass das Ergebnis fachlich akzeptiert oder veröffentlicht werden darf.

Datenbank-Constraints verhindern ungültige Zustände

Ein Teil der Datenqualität sollte technisch abgesichert werden.

Beispiele:

• Eindeutige Rechnungsnummer pro Lieferant
• Pflichtbeziehung zwischen Job und Geschäftsvorgang
• Nur erlaubte Statuswerte
• Keine Veröffentlichung ohne Freigabe
• Keine negative Versionsnummer
• Keine doppelte Zuordnung derselben externen Ereignis-ID

Constraints verhindern Fehler unabhängig davon, ob sie entstehen durch:

• Benutzeroberfläche,
• API,
• Workflow,
• Import,
• oder KI-Agent.

Ein Modell kann eine Regel übersehen.

Die Datenbank sollte kritische Inkonsistenzen trotzdem ablehnen.

JSON-Felder sind nützlich, aber kein Ersatz für Modellierung

PostgreSQL erlaubt flexible JSON-Strukturen.

Das ist hilfreich für:

• wechselnde Modellantworten,
• Anbieterinformationen,
• Konfigurationen,
• oder technische Metadaten.

Problematisch wird es, wenn sämtliche Fachinformationen in unstrukturierten JSON-Feldern verschwinden.

Dann werden wichtige Werte:

• schwer validierbar,
• schlecht durchsuchbar,
• uneinheitlich benannt,
• und kaum referenzierbar.

Eine sinnvolle Trennung lautet:

Relationale Felder

Für:

• IDs,
• Status,
• Beziehungen,
• Zeitstempel,
• Rollen,
• Versionen,
• und häufig benötigte Fachwerte.

JSON-Felder

Für:

• flexible Zusatzinformationen,
• providerabhängige Details,
• seltene Attribute,
• und technische Rohantworten.

Schemaänderungen sind Teil des Produktbetriebs

Ein Datenmodell entwickelt sich weiter.

Neue Anforderungen entstehen:

• zusätzlicher Status,
• neues Objekt,
• weitere Beziehung,
• neue Zugriffsklasse,
• zusätzliche Versionierung,
• oder geänderte Pflichtfelder.

Solche Änderungen werden über Migrationen umgesetzt.

Eine Migration sollte:

• versioniert,
• getestet,
• rückverfolgbar,
• und in verschiedenen Umgebungen reproduzierbar

sein.

Nicht sinnvoll ist, Tabellen manuell im Produktivsystem zu verändern, ohne die Änderung im Projekt zu dokumentieren.

Migrationen müssen bestehende Daten berücksichtigen

Ein neues Pflichtfeld kann nicht einfach hinzugefügt werden, wenn ältere Datensätze keinen Wert besitzen.

Beispiel:

Neu erforderlich:

domain_id

Bestehende Jobs besitzen dieses Feld noch nicht.

Die Migration muss entscheiden:

• Wert aus Beziehung ableiten,
• Standarddomäne setzen,
• Datensätze zur Prüfung markieren,
• oder Feld zunächst optional einführen.

Schemaänderung und Datenmigration gehören zusammen.

Vektorsuche ist ein Zusatz, kein Ersatz für die Datenbank

Für semantische Suche werden Inhalte häufig als Vektoren gespeichert.

Das ermöglicht:

• ähnliche Textpassagen finden,
• Fragen mit anders formulierten Quellen verbinden,
• und große Wissensbestände semantisch durchsuchen.

Die Vektordatenbank beziehungsweise Vektorerweiterung sollte jedoch nicht zum einzigen Wissensspeicher werden.

Ein Vektor kennt Ähnlichkeit.

Er kennt nicht automatisch:

• Gültigkeit,
• Freigabestatus,
• Rolle,
• Version,
• Dokumenttyp,
• Mandant,
• oder fachliche Verbindlichkeit.

Deshalb bleibt die relationale Datenbasis entscheidend.

Ein Suchprozess kann beispielsweise lauten:

Anfrage
→ Mandant und Rolle bestimmen
→ erlaubte Dokumente relational filtern
→ nur gültige Versionen auswählen
→ Vektorsuche innerhalb dieses Bestands
→ Ergebnisse fachlich ranken
→ Passagen an Modell übergeben

Die Vektorsuche beantwortet:

Welche Passage ist semantisch ähnlich?

Die Datenbank beantwortet:

Darf diese Passage für diese Person und diesen Zweck verwendet werden?

Chunking beeinflusst die Wissensqualität

Dokumente werden für semantische Suche häufig in Abschnitte zerlegt.

Diese Abschnitte werden als Chunks bezeichnet.

Zu kleine Chunks verlieren Kontext.

Zu große Chunks enthalten zu viele Themen.

Ein sinnvoller Zuschnitt berücksichtigt:

• Überschriften,
• Absätze,
• Tabellen,
• Aufzählungen,
• Dokumenttyp,
• und fachliche Struktur.

Ein Vertrag benötigt möglicherweise andere Segmente als:

• Wartungshandbuch,
• Produktdatenblatt,
• Interview,
• oder Richtlinie.

Jeder Chunk sollte mit seinem Dokument verbunden bleiben.

Mögliche Metadaten:

{
  "chunk_id": "chunk_1128",
  "document_id": "doc_8712",
  "section": "4.2 Sicherheitsprüfung",
  "page": 18,
  "document_version": "4.2",
  "access_level": "internal"
}

Dokumentversionen dürfen nicht gemeinsam als gleich gültig gesucht werden

Ein Wissenssystem kann mehrere Versionen desselben Dokuments enthalten.

Beispiel:

• Version 2.0 – historisch
• Version 3.0 – abgelöst
• Version 4.2 – aktuell

Die semantische Suche könnte aus allen Versionen passende Passagen finden.

Ohne Statusfilter entstehen widersprüchliche Antworten.

Deshalb benötigt jedes Dokument:

• Versionsnummer,
• Gültigkeitszeitraum,
• Status,
• und Beziehung zur ersetzten Version.

Ein Suchprozess sollte standardmäßig nur gültige und freigegebene Inhalte verwenden.

Historische Quellen können für Analysezwecke verfügbar bleiben, müssen aber ausdrücklich als historisch behandelt werden.

Row Level Security schützt Daten auf Zeilenebene

In Plattformen mit mehreren:

• Kunden,
• Organisationen,
• Projekten,
• Domänen,
• oder Rollen

reicht eine allgemeine Anmeldung nicht aus.

Eine Person darf möglicherweise:

• Daten ihres eigenen Unternehmens,
• nur bestimmte Projekte,
• oder nur einen Teil der Domäne

sehen.

PostgreSQL beziehungsweise Supabase kann über Row Level Security Regeln auf einzelne Datensätze anwenden.

Beispiele:

• Nutzer sieht nur Datensätze seines Mandanten.
• Projektmitglied sieht nur zugeordnete Projekte.
• Reviewer sieht nur zur Prüfung freigegebene Inhalte.
• externer Kunde sieht nur explizit bereitgestellte Ergebnisse.
• Service-Mitarbeiter sieht Kundendaten, aber keine internen Finanzinformationen.

Diese Regeln wirken unabhängig davon, ob der Zugriff erfolgt über:

• Benutzeroberfläche,
• API,
• Workflow,
• oder KI-Assistent.

Berechtigungen müssen vor der KI-Verarbeitung greifen

Es reicht nicht, eine fertige Antwort anschließend zu filtern.

Geschützte Informationen dürfen gar nicht erst in den Modellkontext gelangen.

Der Ablauf sollte lauten:

Identität prüfen
→ Rolle bestimmen
→ erlaubte Datensätze filtern
→ Kontext zusammenstellen
→ Modell aufrufen

Nicht:

Alle Daten laden
→ Modell antwortet
→ versuchen, sensible Teile zu entfernen

Sobald geschützte Daten an ein Modell oder einen externen Dienst übergeben wurden, ist die Zugriffskontrolle bereits fehlgeschlagen.

Rollen, Berechtigungen und Fachverantwortung sind nicht dasselbe

Eine Person kann technisch lesen dürfen, ohne fachlich freigeben zu dürfen.

Beispiel:

Redakteur

• darf Quellen lesen,
• darf Entwürfe bearbeiten,
• darf Review anfordern.

Fachexperte

• darf Aussagen fachlich bestätigen,
• darf aber möglicherweise nicht veröffentlichen.

Publisher

• darf nur vollständig freigegebene Inhalte ausspielen.

Administrator

• darf Systeme konfigurieren,
• aber nicht automatisch fachliche Aussagen freigeben.

Das Rechtemodell sollte unterscheiden zwischen:

• lesen,
• erstellen,
• verändern,
• kommentieren,
• prüfen,
• freigeben,
• veröffentlichen,
• und administrieren.

Service Accounts benötigen minimale Rechte

Integrationen arbeiten häufig mit technischen Konten.

Ein Workflow benötigt beispielsweise Zugriff auf:

• CRM,
• ERP,
• Dateispeicher,
• oder E-Mail.

Der einfachste Weg wäre ein Administratorkonto.

Das ist jedoch riskant.

Besser sind aufgabenspezifische Service Accounts.

Beispiel:

Ein Content-Workflow darf:

• freigegebene Produktdaten lesen,
• Entwürfe speichern,
• Review-Aufgaben erstellen.

Er darf nicht:

• Preise verändern,
• Benutzer verwalten,
• Inhalte ohne Freigabe veröffentlichen,
• oder andere Mandanten lesen.

Auch technische Konten folgen dem Prinzip der minimalen Rechte.

Geheimnisse gehören in eine Secret-Verwaltung

Integrationen benötigen sensible Zugangsdaten:

• API-Schlüssel,
• Datenbankpasswörter,
• OAuth-Tokens,
• Zertifikate,
• und Signaturschlüssel.

Diese Informationen dürfen nicht gespeichert werden in:

• Prompts,
• Workflowtexten,
• Logs,
• Quellcode,
• Screenshots,
• oder Datenbankfeldern ohne Schutz.

Eine Secret-Verwaltung ermöglicht:

• verschlüsselte Speicherung,
• Zugriff nach Rolle,
• getrennte Werte pro Umgebung,
• Rotation,
• Ablauf,
• und Sperrung.

Das System sollte außerdem dokumentieren:

• welchem Dienst ein Secret gehört,
• wer verantwortlich ist,
• welche Rechte es besitzt,
• und wann es erneuert werden muss.

Audit Trails machen Veränderungen nachvollziehbar

Ein Audit Trail dokumentiert relevante Änderungen.

Beispiele:

• Status geändert,
• Daten korrigiert,
• Quelle freigegeben,
• Regel aktualisiert,
• Promptversion veröffentlicht,
• Review erteilt,
• Inhalt veröffentlicht,
• Zugriff auf sensible Daten erfolgt.

Ein Audit-Eintrag kann enthalten:

{
  "event_id": "audit_9812",
  "entity_type": "content_item",
  "entity_id": "item_441",
  "action": "approved",
  "actor_type": "user",
  "actor_id": "usr_72",
  "occurred_at": "2026-07-28T16:12:00Z",
  "metadata": {
    "version": 4,
    "review_type": "technical"
  }
}

Wichtig ist die Trennung zwischen:

• aktuellem Zustand,
• fachlicher Historie,
• und technischen Logs.

Der aktuelle Datensatz sagt:

Der Inhalt ist freigegeben.

Der Audit Trail sagt:

Wer hat welche Version wann und auf welcher Grundlage freigegeben?

Ein Audit Trail darf nicht alles grenzenlos speichern

Nachvollziehbarkeit bedeutet nicht, sämtliche Daten unbegrenzt zu vervielfältigen.

Zu berücksichtigen sind:

• Datenschutz,
• Vertraulichkeit,
• Aufbewahrungsfristen,
• Zweckbindung,
• und Speicherbedarf.

Nicht jeder vollständige Prompt oder Dokumentinhalt muss dauerhaft im Audit Trail liegen.

Häufig genügen:

• Referenzen,
• Hashes,
• IDs,
• Versionen,
• Entscheidung,
• und verantwortliche Rolle.

Sensible Inhalte verbleiben in ihrem dafür vorgesehenen System.

Mandantentrennung muss durch alle Schichten reichen

Eine Multi-Tenant-Plattform verarbeitet Daten mehrerer Organisationen oder Kunden.

Die Trennung darf nicht nur in der Benutzeroberfläche stattfinden.

Sie muss gelten für:

• Datenbankzeilen,
• Dateien,
• Vektorsuche,
• Jobs,
• Prompts,
• Modellkontexte,
• Logs,
• Caches,
• und externe Integrationen.

Ein Datensatz kann beispielsweise tragen:

tenant_id
domain_id
project_id

Jeder Zugriff muss diese Grenzen berücksichtigen.

Ein häufiger Fehler entsteht, wenn die relationale Datenbank sauber getrennt ist, die Vektorsuche aber Ergebnisse aus mehreren Mandanten gemeinsam durchsucht.

Oder wenn Dateien verschiedener Kunden im selben ungeschützten Speicherpfad liegen.

Mandantentrennung ist eine Ende-zu-Ende-Eigenschaft.

Domänen trennen nicht nur Daten, sondern auch Regeln

Zwei Fachgebiete können dieselbe technische Plattform nutzen und trotzdem unterschiedliche Logik besitzen.

Beispiel:

Content-Domäne

• Quellenstatus
• Markenregeln
• Review
• Publishing

Instandhaltungsdomäne

• Anlagen
• Sicherheitsregeln
• Störungen
• Wartungsfreigaben

Verwaltungsdomäne

• Leistungen
• Zuständigkeiten
• Nachweise
• Einzelfallprüfung

Die Plattform kann gemeinsame Fähigkeiten bereitstellen:

• Authentifizierung,
• Job Queue,
• Suche,
• Versionierung,
• Audit,
• und Integration.

Die fachlichen Regeln bleiben pro Domäne getrennt.

Self-Hosting ist eine Betriebsentscheidung, kein Selbstzweck

Ein Teil der Plattform kann selbst betrieben werden.

Mögliche Gründe:

• besondere Vertraulichkeit,
• technische Kontrolle,
• Datenresidenz,
• Anpassbarkeit,
• Kostenstruktur,
• oder Unabhängigkeit.

Self-Hosting bedeutet jedoch auch Verantwortung für:

• Updates,
• Sicherheit,
• Backups,
• Verfügbarkeit,
• Monitoring,
• Skalierung,
• und Wiederherstellung.

Eine Komponente ist nicht automatisch besser, nur weil sie im eigenen Rechenzentrum läuft.

Die Entscheidung sollte abhängig sein von:

• Schutzbedarf,
• interner Kompetenz,
• Betriebsaufwand,
• Integrationsanforderungen,
• und wirtschaftlicher Wirkung.

Hybride Architekturen verbinden Kontrolle und Flexibilität

Nicht jede Komponente muss im selben Betriebsmodell laufen.

Eine hybride Architektur kann beispielsweise kombinieren:

• selbst betriebene PostgreSQL-Datenbank,
• internes Dokumentenarchiv,
• externen Modellanbieter für allgemeine Texte,
• lokales Modell für vertrauliche Inhalte,
• Cloud-Speicher für freigegebene Medien,
• und SaaS-CRM als führendes Kundensystem.

Entscheidend ist, die Datenwege zu kennen.

Für jede Verarbeitung muss klar sein:

• Welche Information verlässt welche Grenze?
• Welcher Anbieter erhält welche Daten?
• In welchem Land oder Rechtsraum wird verarbeitet?
• Was wird gespeichert?
• Wie wird gelöscht?
• Welche Alternative besteht bei Ausfall oder Anbieterwechsel?

Datenklassifikation steuert die Architektur

Nicht alle Informationen besitzen denselben Schutzbedarf.

Eine Organisation kann Daten beispielsweise klassifizieren als:

• öffentlich,
• intern,
• vertraulich,
• besonders geschützt,
• oder reguliert.

Aus dieser Klassifikation ergeben sich Regeln:

|Klasse|Mögliche Verarbeitung| |---|---| |Öffentlich|externe Modelle grundsätzlich möglich| |Intern|nur freigegebene Anbieter| |Vertraulich|reduzierte oder pseudonymisierte Verarbeitung| |Besonders geschützt|lokale oder speziell kontrollierte Umgebung| |Reguliert|zusätzliche fachliche und rechtliche Prüfung|

Die Klassifikation sollte an:

• Dokumenten,
• Datenobjekten,
• Quellen,
• und Jobs

hinterlegt sein.

Dadurch kann die Plattform automatisch verhindern, dass ein ungeeigneter Dienst verwendet wird.

Modellanbieter sind austauschbare Komponenten

Die fachliche Plattform sollte nicht vollständig von einem einzelnen KI-Anbieter abhängen.

Modelle unterscheiden sich in:

• Qualität,
• Kosten,
• Geschwindigkeit,
• Kontextgröße,
• Datenschutz,
• Verfügbarkeit,
• und unterstützten Formaten.

Eine Modellabstraktion kann Aufgaben unabhängig vom konkreten Anbieter beschreiben.

Beispiel:

Aufgabe: Klassifikation
Erwartete Ausgabe: inquiry_classification_v2
Maximale Kostenklasse: niedrig
Schutzklasse: intern
Erforderliche Sprache: Deutsch

Die Plattform wählt ein dafür freigegebenes Modell.

Ein Modellwechsel bleibt trotzdem eine kontrollierte Änderung.

Er benötigt:

• Tests,
• Freigabe,
• Versionierung,
• und Monitoring.

Vendor Lock-in entsteht nicht nur durch Modelle

Abhängigkeit kann entstehen durch:

• proprietäre Datenformate,
• nicht exportierbare Workflows,
• geschlossene APIs,
• versteckte Geschäftslogik,
• Anbieter-spezifische Promptstrukturen,
• oder unzugängliche Auditdaten.

Eine offene Architektur reduziert dieses Risiko.

Wichtige Maßnahmen sind:

• PostgreSQL als portable Datenbasis,
• dokumentierte Schnittstellen,
• exportierbare Konfiguration,
• getrennte Geschäftsregeln,
• versionierte Prompts,
• und standardisierte Dateiformate.

Vollständige Unabhängigkeit ist selten möglich.

Das Ziel ist kontrollierbare Abhängigkeit.

Portabilität beginnt mit Besitz an den eigenen Daten

Eine Organisation sollte jederzeit beantworten können:

• Welche Daten besitzt die Plattform?
• In welchem Format können sie exportiert werden?
• Welche Beziehungen müssen erhalten bleiben?
• Welche Dateien gehören dazu?
• Welche Auditinformationen sind notwendig?
• Wie wird ein Wechsel durchgeführt?
• Was geschieht mit Anbieter-spezifischen IDs?

Ein reiner CSV-Export reicht für komplexe Plattformen häufig nicht aus.

Benötigt werden können:

• relationale Daten,
• Dateien,
• Vektoren,
• Konfigurationen,
• Promptversionen,
• Regeln,
• und Historien.

Die Exit-Strategie sollte nicht erst beim Anbieterwechsel entworfen werden.

Integration ist ein dauerhaftes Produkt

Schnittstellen verändern sich.

Anbieter ändern:

• Authentifizierung,
• Felder,
• Limits,
• Preise,
• Versionen,
• oder Verfügbarkeit.

Ein Integrationsprojekt ist deshalb nicht nach dem ersten erfolgreichen Datentransfer abgeschlossen.

Es benötigt:

• Eigentümer,
• Monitoring,
• Tests,
• Dokumentation,
• Versionspflege,
• Fehlerbearbeitung,
• und Kostenkontrolle.

Jede wichtige Integration sollte als eigenes Produkt betrachtet werden.

Dazu gehören:

• Zweck,
• Verantwortlichkeit,
• Service-Level,
• bekannte Grenzen,
• und Änderungsprozess.

Schnittstellenkatalog schafft Transparenz

Mit wachsender Plattform steigt die Zahl der Verbindungen.

Ein Schnittstellenkatalog kann dokumentieren:

• Quellsystem,
• Zielsystem,
• Datentyp,
• Richtung,
• Auslöser,
• Frequenz,
• Protokoll,
• verantwortliche Person,
• Schutzklasse,
• und Fehlerweg.

Beispiel:

|Integration|Quelle|Ziel|Modus|Eigentümer| |---|---|---|---|---| |Kundenstamm|CRM|Plattform|Webhook + API|Vertriebssysteme| |Produktdaten|ERP|PIM|Ereignisbasiert|Produktmanagement| |Freigegebener Content|Plattform|CMS|Publishing API|Redaktion| |Dokumente|DMS|Wissensindex|periodisch|Knowledge Management| |Rechnungsstatus|ERP|Plattform|API|Finanzen|

Ein solcher Katalog verhindert unsichtbare Abhängigkeiten.

Datenqualität ist eine gemeinsame Verantwortung

Technisch gültige Daten können fachlich falsch sein.

Beispiel:

Preis = 0

Das Feld ist numerisch korrekt.

Fachlich kann es bedeuten:

• kostenlos,
• noch nicht gepflegt,
• nicht verfügbar,
• oder Importfehler.

Datenqualität umfasst daher mehrere Ebenen.

Vollständigkeit

Sind notwendige Werte vorhanden?

Eindeutigkeit

Kann ein Objekt klar zugeordnet werden?

Aktualität

Ist der Wert noch gültig?

Konsistenz

Passen verwandte Informationen zusammen?

Plausibilität

Ist der Wert im Kontext sinnvoll?

Herkunft

Ist bekannt, woher die Information stammt?

Verantwortung

Wer darf den Wert korrigieren?

Datenqualitätsregeln gehören zum Datenmodell

Beispiele für prüfbare Regeln:

• Produkt benötigt eindeutige Artikelnummer.
• Freigegebener Inhalt benötigt mindestens eine Quelle.
• Rechnung benötigt Lieferant, Rechnungsnummer und Betrag.
• Veröffentlichung benötigt gültige Rechte.
• Job benötigt zugeordneten Mandanten.
• Dokument mit Status approved benötigt verantwortliche Rolle.
• Preis darf nicht aus einem Textmodell übernommen werden.

Solche Regeln sollten möglichst früh greifen.

Nicht erst, wenn ein fehlerhafter Wert bereits in mehrere Systeme übertragen wurde.

KI kann Datenqualität unterstützen, aber nicht definieren

Ein Modell kann helfen:

• Dubletten vorzuschlagen,
• ungewöhnliche Werte zu markieren,
• Begriffe zu vereinheitlichen,
• fehlende Attribute zu erkennen,
• und Widersprüche zusammenzufassen.

Es kann nicht allein festlegen:

• welcher Wert verbindlich ist,
• welche Ausnahme zulässig ist,
• oder welche Datenqualität für einen Prozess ausreicht.

Diese Entscheidungen benötigen Fachverantwortung.

Stammdaten und Bewegungsdaten erfüllen unterschiedliche Aufgaben

Stammdaten

Beschreiben relativ stabile Objekte:

• Kunde,
• Produkt,
• Lieferant,
• Maschine,
• Nutzer,
• Standort.

Bewegungsdaten

Beschreiben Vorgänge und Veränderungen:

• Bestellung,
• Rechnung,
• Servicefall,
• Messwert,
• Veröffentlichung,
• Zahlung,
• Freigabe.

Eine KI-Plattform benötigt häufig beide Ebenen.

Beispiel:

Kunde als Stammdatensatz
+ aktuelle Anfrage als Bewegungsdaten
+ frühere Kommunikation
+ gültiger Vertrag
→ vorbereitete Bearbeitung

Die Architektur sollte vermeiden, dass jede Anfrage neue unverbundene Kopien derselben Stammdaten erzeugt.

Zeit ist ein wichtiger Bestandteil von Daten

Viele Informationen gelten nur in einem bestimmten Zeitraum.

Beispiele:

• Preis,
• Vertrag,
• Zuständigkeit,
• Richtlinie,
• Nutzungsrecht,
• Rollenmitgliedschaft,
• Modellfreigabe,
• und Promptversion.

Ein Datensatz sollte daher nicht nur enthalten:

Wert

sondern gegebenenfalls:

gültig_von
gültig_bis
erstellt_am
aktualisiert_am
freigegeben_am

Dadurch lässt sich später beantworten:

Welche Information galt zum Zeitpunkt der Entscheidung?

Diese historische Sicht ist für Audit, Rekonstruktion und Fehleranalyse wesentlich.

Soft Delete schützt Historie

Datensätze werden häufig nicht sofort physisch gelöscht.

Stattdessen erhalten sie einen Zustand wie:

archived
deleted_at
inactive

Dadurch bleiben Beziehungen und Historien nachvollziehbar.

Das bedeutet nicht, dass Daten unbegrenzt gespeichert werden dürfen.

Lösch- und Aufbewahrungsregeln müssen trotzdem umgesetzt werden.

Soft Delete ist eine technische Methode für kontrollierte Zustandsänderung, kein Ersatz für Datenschutz.

Backups sind nur wertvoll, wenn Wiederherstellung getestet wird

Eine Plattform benötigt regelmäßige Sicherungen von:

• Datenbank,
• Dateien,
• Konfiguration,
• und gegebenenfalls Schlüsselmaterial.

Ein Backup allein garantiert jedoch keine Wiederherstellung.

Zu testen ist:

• Kann die Datenbank eingespielt werden?
• Sind Beziehungen vollständig?
• Sind Dateien weiterhin erreichbar?
• Sind Secrets und Konfigurationen rekonstruierbar?
• Wie lange dauert die Wiederherstellung?
• Welche Daten gehen zwischen zwei Sicherungen verloren?

Wichtige Kennzahlen können sein:

Recovery Point Objective

Wie viel Datenverlust ist maximal akzeptabel?

Recovery Time Objective

Wie schnell muss das System wieder verfügbar sein?

Hochverfügbarkeit ist use-case-abhängig

Nicht jede Plattform benötigt dieselbe Verfügbarkeit.

Ein interner Content-Workflow kann möglicherweise einige Stunden warten.

Ein kundenkritischer Serviceprozess benötigt unter Umständen schnellere Wiederherstellung.

Die Architektur sollte nach Wirkung gestaltet werden.

Fragen sind:

• Welche Prozesse sind geschäftskritisch?
• Welche Ausfallzeit ist tolerierbar?
• Gibt es einen manuellen Ersatzprozess?
• Welche Abhängigkeiten bestehen?
• Welche Komponenten benötigen Redundanz?
• Welche Kosten sind wirtschaftlich angemessen?

Observability verbindet Logs, Metriken und Traces

Ein verteiltes System kann nur betrieben werden, wenn sein Zustand sichtbar ist.

Logs

Beschreiben einzelne Ereignisse:

• API-Aufruf fehlgeschlagen
• Datensatz nicht gefunden
• Zugriff verweigert
• Modellantwort ungültig

Metriken

Zeigen Entwicklungen:

• Anzahl API-Fehler
• Synchronisationsdauer
• offene Jobs
• Datenbankauslastung
• Kosten pro Vorgang

Traces

Zeigen den Weg eines Vorgangs durch mehrere Systeme:

Formular
→ API
→ Datenbank
→ Workflow
→ Modell
→ Review
→ CRM

Diese drei Ebenen ergänzen einander.

Correlation IDs verbinden verteilte Vorgänge

Ein einziger Prozess kann unterschiedliche technische IDs erzeugen:

• API Request ID,
• Job ID,
• Workflow Execution ID,
• Modell Request ID,
• CRM ID,
• Publishing ID.

Eine gemeinsame Correlation ID verbindet diese Schritte.

Beispiel:

correlation_id: trace_98127

Bei einem Fehler lässt sich dadurch der gesamte Weg verfolgen.

Ohne gemeinsame Referenz wird die Analyse zu einer manuellen Suche über Zeitstempel und Inhalte.

Fachliches Monitoring ergänzt technische Überwachung

Ein System kann technisch fehlerfrei laufen und fachlich schlechte Ergebnisse erzeugen.

Deshalb sollten zusätzlich beobachtet werden:

• Antworten ohne gültige Quelle,
• hohe Korrekturquote,
• häufige Datenkonflikte,
• nicht zuordenbare Vorgänge,
• veraltete Inhalte,
• fehlerhafte Rollenentscheidungen,
• und ungewöhnlich viele manuelle Eskalationen.

Technischer Erfolg bedeutet:

Die API antwortet.

Fachlicher Erfolg bedeutet:

Die richtige Information wurde für die richtige Person im richtigen Prozess verwendet.

Kosten müssen Daten- und Integrationsschritten zugeordnet werden

Kosten entstehen nicht nur durch Sprachmodelle.

Auch folgende Komponenten können variable Kosten verursachen:

• Datenbank,
• Speicher,
• Netzwerk,
• API-Aufrufe,
• OCR,
• Vektorsuche,
• Modellnutzung,
• Bildgenerierung,
• Audioverarbeitung,
• und externe Publishing-Dienste.

Die Plattform sollte Kosten nach:

• Job,
• Prozess,
• Kunde,
• Domäne,
• Modell,
• und Anbieter

zuordnen können.

So wird sichtbar:

• welcher Use Case wirtschaftlich funktioniert,
• welche Integration besonders teuer ist,
• wo Wiederholungen Kosten verursachen,
• und ob ein lokaler oder externer Dienst sinnvoller ist.

Ein Praxisbeispiel: CRM, ERP und Angebotsplattform

Ein Unternehmen erstellt Angebote für Bestands- und Neukunden.

Die relevanten Informationen liegen in mehreren Systemen.

CRM

• Ansprechpartner
• Kommunikation
• Vertriebschance
• Kundenbeziehung

ERP

• Kundennummer
• Preise
• Produkte
• Zahlungsbedingungen

Plattform

• Anfrage
• Analyse
• Angebotsentwurf
• Quellen
• Review
• Freigabe

Ablauf

Anfrage eingegangen
→ Kunde im CRM suchen
→ ERP-Referenz zuordnen
→ freigegebene Produkt- und Leistungsdaten laden
→ Entwurf erzeugen
→ kaufmännische Werte aus ERP übernehmen
→ fachliches Review
→ freigegebenes Angebot speichern
→ CRM-Status aktualisieren

Wichtig:

• Die KI darf Preise nicht erfinden.
• Das CRM bleibt führend für den Vertriebsstatus.
• Das ERP bleibt führend für kaufmännische Daten.
• Die Plattform führt Entwurf, Quellen und Freigabe.
• Das finale Dokument erhält eine eindeutige Version.

Ein Praxisbeispiel: Wissensplattform mit Dokumentenrechten

Ein Unternehmen möchte einen internen Wissensassistenten aufbauen.

Die Quellen liegen in:

• Dokumentenmanagement,
• Projektordnern,
• Intranet,
• und Fachsystemen.

Architektur

1. Dokumentmetadaten werden übernommen.
2. Berechtigungen werden synchronisiert.
3. Inhalte werden extrahiert.
4. Dokumente werden in fachlich sinnvolle Abschnitte zerlegt.
5. Chunks erhalten Dokument-, Versions- und Rollenbezug.
6. Vektoren werden erzeugt.
7. Suchanfragen filtern zuerst nach Rechten und Gültigkeit.
8. Erst danach erfolgt die semantische Suche.
9. Die Antwort zeigt Quellen und Versionen.

Grenzen

Der Assistent darf nicht:

• historische Quellen als aktuell darstellen,
• interne Notizen als verbindliche Richtlinie behandeln,
• nicht erlaubte Dokumente indirekt zusammenfassen,
• oder fehlende Informationen erfinden.

Ein Praxisbeispiel: Produktdaten und Content-Ausgabe

Ein Händler möchte Produktdaten für mehrere Kanäle nutzen.

Führende Systeme

• ERP: Artikelnummer, Preis, Bestand
• PIM: Produktattribute und Medien
• Plattform: Produktkern, Content-Versionen und Reviews
• Shop: Veröffentlichung
• Marktplatz: kanalspezifische Darstellung

Datenfluss

ERP-Produkt geändert
→ Ereignis an Plattform
→ PIM-Daten ergänzen
→ geänderte Attribute bestimmen
→ betroffene Texte finden
→ Aktualisierungsentwürfe erzeugen
→ Produktreview
→ Kanalversionen aktualisieren

Lineage

Der Shoptext bleibt verbunden mit:

• Produktversion,
• Quellen,
• Prompt,
• Modell,
• redaktioneller Änderung,
• und Veröffentlichung.

Ändert sich ein technisches Attribut, kann das System betroffene Inhalte identifizieren.

Ein Praxisbeispiel: Rechnungsverarbeitung

Eine Rechnung trifft per E-Mail ein.

Originalsysteme

• E-Mail-System: Eingang
• Dokumentenspeicher: Originaldatei
• Plattform: Extraktion und Prüfstatus
• ERP: Bestellung und Lieferant
• Buchhaltung: Buchung und Zahlung

Ablauf

E-Mail empfangen
→ Datei speichern
→ Dokumentfingerprint prüfen
→ Rechnungsdaten extrahieren
→ Lieferant im ERP suchen
→ Bestellung abgleichen
→ Abweichungen speichern
→ menschliche Prüfung bei Risiko
→ Buchungsvorschlag übertragen
→ Bestätigung aus Finanzsystem speichern

Die Plattform führt nicht selbst die Buchhaltung.

Sie koordiniert und dokumentiert den Prüfprozess.

Ein Praxisbeispiel: Multi-Mandanten-Contentplattform

Eine Plattform produziert Inhalte für mehrere Marken.

Jede Marke besitzt:

• eigene Quellen,
• eigene Tonalität,
• eigene Promptbausteine,
• eigene Assets,
• eigene Freigaben,
• eigene Publishing-Kanäle.

Die gemeinsame Plattform bietet:

• Authentifizierung,
• Job Queue,
• Modellzugriff,
• Versionierung,
• Kostenmessung,
• Review,
• und Publishing-Schnittstellen.

Die Mandantentrennung gilt für:

• Datenbank,
• Dateispeicher,
• Vektorsuche,
• Prompts,
• Logs,
• und API-Schlüssel.

Ein Inhalt darf niemals versehentlich Quellen oder Markenregeln eines anderen Mandanten verwenden.

Der beste Einstieg ist eine konkrete Datenbewegung

Ein Daten- und Integrationsprojekt sollte nicht mit der abstrakten Forderung beginnen:

Wir müssen alle Systeme miteinander verbinden.

Sinnvoller ist ein klarer Geschäftsvorgang.

Beispiele:

• Kundenanfrage vom Postfach bis ins CRM
• Produktänderung vom ERP bis in den Shop
• Dokument vom Upload bis zur fachlichen Prüfung
• freigegebener Inhalt bis zur Veröffentlichung
• Rechnungsstatus vom ERP bis zur Übersicht
• Wartungsmeldung von der Maschine bis zum Auftrag

An diesem Vorgang wird sichtbar:

• welche Systeme beteiligt sind,
• welche Daten benötigt werden,
• welches System führt,
• welche Konflikte auftreten,
• und welche Integration tatsächlich Wert erzeugt.

Wie ein erstes Daten- und Integrationsprojekt abläuft

1. Geschäftsvorgang auswählen

Ein begrenzter, häufig auftretender Prozess wird festgelegt.

2. Systeme kartieren

Erfasst werden:

• Quellen,
• Ziele,
• Schnittstellen,
• Dateiformate,
• manuelle Übergaben,
• und bestehende Schattenprozesse.

3. System of Record definieren

Für jedes relevante Feld wird festgelegt:

• Wo gilt der verbindliche Wert?
• Wer ist verantwortlich?
• Wer darf ändern?
• Welche Kopien existieren?

4. Datenmodell entwickeln

Objekte, Beziehungen, Status, Versionen und IDs werden beschrieben.

5. Rechte und Schutzbedarf bestimmen

Für jede Datenart wird geklärt:

• Wer darf lesen?
• Wer darf schreiben?
• Welche Daten dürfen extern verarbeitet werden?
• Welche Mandanten- und Domänengrenzen gelten?

6. Integrationsmuster auswählen

Je Verbindung wird entschieden:

• synchrone API,
• Webhook,
• Ereignis,
• periodische Synchronisation,
• Dateiimport,
• oder manuelle Freigabe.

7. Konflikt- und Fehlerlogik definieren

Geprüft werden:

• Dubletten,
• Timeouts,
• widersprüchliche Werte,
• fehlende IDs,
• ungültige Daten,
• und nicht erreichbare Systeme.

8. Lineage und Audit modellieren

Es wird festgelegt:

• welche Herkunft gespeichert wird,
• welche Versionen gelten,
• und welche Änderungen nachvollziehbar sein müssen.

9. Pilot mit realen Fällen umsetzen

Standardfälle, Ausnahmen und technische Fehler werden getestet.

10. Monitoring etablieren

Beobachtet werden:

• technische Fehler,
• Datenkonflikte,
• Synchronisationsverzögerungen,
• fachliche Korrekturen,
• und Kosten.

11. Betrieb und Verantwortung übergeben

Für jede Integration werden Eigentümer, Runbooks und Änderungsprozesse benannt.

12. Architektur schrittweise erweitern

Weitere Systeme werden erst angebunden, wenn die bestehende Datenbewegung stabil und verständlich funktioniert.

Typische Fehler bei Daten- und Integrationsarchitekturen

Das Sprachmodell zum Datenspeicher machen

Chatverläufe und Modellkontexte ersetzen keine strukturierte Datenhaltung.

Kein führendes System benennen

Ohne Datenverantwortung entstehen widersprüchliche Werte und unkontrollierte Überschreibungen.

Alle Daten zentral kopieren

Mehr Kopien erhöhen nicht automatisch die Qualität.

Direkte Datenbankzugriffe überall erlauben

Dadurch werden Systemgrenzen, Rechte und Geschäftslogik umgangen.

Vektorsuche mit Wahrheit verwechseln

Semantische Ähnlichkeit sagt nichts über Gültigkeit und Berechtigung aus.

Dokumentversionen nicht unterscheiden

Historische und aktuelle Quellen dürfen nicht gleich behandelt werden.

Rollen erst in der Oberfläche prüfen

Berechtigungen müssen bereits beim Datenzugriff wirken.

Mandantentrennung nur in Tabellen umsetzen

Auch Dateien, Vektoren, Logs und Modellkontexte müssen getrennt bleiben.

APIs ohne klare Verträge bauen

Unklare Eingaben und Fehlerantworten machen Integrationen fragil.

Webhooks als garantiert einmalige Ereignisse behandeln

Ereignisse können mehrfach oder verzögert eintreffen.

Datenkonflikte mit „letzter Wert gewinnt“ lösen

Nicht jeder neuere Wert ist fachlich verbindlich.

JSON für alle Fachinformationen verwenden

Flexible Felder ersetzen kein verständliches Datenmodell.

Lineage erst bei Problemen nachrüsten

Herkunft muss während der Verarbeitung erfasst werden.

Self-Hosting mit Sicherheit gleichsetzen

Eigener Betrieb erzeugt zusätzliche Verantwortung.

Vendor Lock-in nur beim Modell betrachten

Auch Datenformate, Workflows und Regeln können Abhängigkeit erzeugen.

Backups nicht testen

Eine Sicherung ist wertlos, wenn sie nicht wiederhergestellt werden kann.

Was eine belastbare Daten- und Integrationsarchitektur auszeichnet

Eine gute Architektur ist:

Verantwortlich

Für jede Information ist ein führendes System benannt.

Strukturiert

Geschäftsobjekte, Beziehungen und Zustände sind klar modelliert.

Quellenbewusst

Original, Extraktion, Ableitung und Freigabe bleiben unterscheidbar.

Nachvollziehbar

Datenherkunft, Versionen und Entscheidungen sind dokumentiert.

API-first

Systemfähigkeiten werden über kontrollierte Schnittstellen bereitgestellt.

Ereignisfähig

Änderungen können asynchron und entkoppelt verarbeitet werden.

Rechtebasiert

Zugriff wird vor der Verarbeitung begrenzt.

Mandantenfähig

Daten, Dateien, Vektoren und Prozesse bleiben sauber getrennt.

Versioniert

Schema, Regeln, Quellen und Schnittstellen entwickeln sich kontrolliert weiter.

Modellunabhängig

KI-Anbieter können nach Tests ausgetauscht oder unterschiedlich eingesetzt werden.

Offen

Daten, Konfigurationen und Beziehungen bleiben exportierbar und dokumentiert.

Beobachtbar

Technische Fehler, fachliche Konflikte, Kosten und Verzögerungen werden sichtbar.

Betreibbar

Backups, Wiederherstellung, Monitoring, Runbooks und Verantwortlichkeiten sind organisiert.

Systemgrenzen schaffen keine Silos – sie schaffen Verantwortung

Der Begriff Systemgrenze klingt zunächst nach Trennung.

In einer guten Architektur verhindert sie jedoch nicht die Zusammenarbeit.

Sie macht sichtbar:

• welches System wofür zuständig ist,
• welche Daten es bereitstellt,
• welche Änderungen es akzeptiert,
• welche Rechte gelten,
• und was außerhalb seiner Verantwortung liegt.

Dadurch können Systeme gezielt verbunden werden, ohne zu einem unübersichtlichen Gesamtsystem zu verschmelzen.

Ein CRM muss kein Dokumentenmanagement werden.

Ein ERP muss keine Content-Plattform werden.

Ein Sprachmodell muss keine Datenbank werden.

Eine Workflow-Plattform muss kein System of Record werden.

Jede Komponente erfüllt eine klar definierte Aufgabe.

Die Integration sorgt dafür, dass daraus ein gemeinsamer Prozess entsteht.

Die Datenbank ist langfristig oft wichtiger als das Modell

Modelle verändern sich schnell.

Ein heute bevorzugtes Modell kann in einem Jahr ersetzt werden.

Die Datenbasis bleibt.

In ihr liegen:

• Kundenbeziehungen,
• Prozesszustände,
• Quellen,
• Ergebnisse,
• Freigaben,
• Historien,
• Rollen,
• und fachliche Zusammenhänge.

Wenn diese Informationen sauber strukturiert sind, kann ein Unternehmen:

• Modelle wechseln,
• neue Oberflächen entwickeln,
• zusätzliche Prozesse anbinden,
• und weitere Domänen erschließen.

Wenn die Geschäftslogik dagegen nur in Prompts, Workflow-Nodes oder Anbieterplattformen verborgen ist, wird jede Veränderung aufwendig.

Das Modell erzeugt den aktuellen Output. Das Datenfundament erhält die langfristige Handlungsfähigkeit.

Wo befindet sich in Ihrer Systemlandschaft heute die verbindliche Wahrheit?

Vielleicht wird derselbe Kundenstatus in CRM, Tabelle und Projektmanagement gepflegt.

Vielleicht erzeugt eine KI bereits Ergebnisse, ohne dass deren Quellen und Versionen gespeichert werden.

Vielleicht liegen Produktdaten in mehreren Systemen und widersprechen sich.

Vielleicht existieren n8n-Workflows, die direkt auf Datenbanken schreiben, ohne klaren Systembesitz.

Vielleicht werden Dokumente vektorisiert, ohne Berechtigungen und Gültigkeit ausreichend abzubilden.

Vielleicht ist nicht nachvollziehbar, welche Daten ein externer Modellanbieter erhält.

Dann sollte der nächste Schritt nicht darin bestehen, einfach weitere Systeme anzuschließen.

Sinnvoller ist eine klare Architekturentscheidung:

• Welches System führt welche Information?
• Welche Daten sind Original, welche nur abgeleitet?
• Welche IDs verbinden die Systeme?
• Welche Schnittstellen werden benötigt?
• Welche Ereignisse lösen Prozesse aus?
• Wie werden Konflikte behandelt?
• Welche Rollen dürfen lesen, verändern oder freigeben?
• Wie bleibt die Herkunft eines Ergebnisses sichtbar?
• Welche Komponenten müssen selbst betrieben werden?
• Welche Anbieter sollen austauschbar bleiben?
• Und welcher konkrete Datenfluss eignet sich für einen kontrollierten Pilot?

Belastbare KI entsteht nicht durch den größtmöglichen Datenzugriff. Sie entsteht durch die präzise Verbindung der richtigen Informationen innerhalb klarer Systemgrenzen. PostgreSQL beziehungsweise Supabase, dokumentierte APIs, nachvollziehbare Lineage und offene Integrationen schaffen dafür das Fundament – damit Modelle, Workflows und Anwendungen leistungsfähig bleiben, ohne Verantwortung, Datenhoheit und betriebliche Kontrolle zu verlieren.