Funktions- und Verarbeitungsmatrix

Diese Seite führt für jede Funktion der DQC Platform auf, welche Daten sie verarbeitet, über welche Schnittstelle und welches Protokoll, welche Berechtigung ein Benutzer dafür benötigt und ob dabei ein Sprachmodell zum Einsatz kommt.

In einer Private-Cloud- oder On-Premises-Installation laufen alle Komponenten innerhalb der von Ihnen kontrollierten Infrastruktur. Metadaten, Regeln und Ergebnisse verbleiben in Ihrem Mandanten; ausgehende Verbindungen bestehen nur dort, wo Sie sie selbst konfigurieren (LLM-Endpunkt, E-Mail, Webhooks, angebundene Quellen).

So lesen Sie die Matrix

Verarbeitete Daten - die Kategorien, die weiter unten unter "Datenkategorien" beschrieben sind.
Schnittstelle / Protokoll - auf welchem Weg die Daten zur Funktion gelangen. "HTTPS" bezeichnet die Weboberfläche bzw. die REST-API der Plattform selbst.
Erforderliche Berechtigung - entweder eine Tenant-Berechtigung (in Code-Schrift) oder ein Objektrecht am Konnektor, an der Tabelle oder am Regelsatz. Welche Rolle welche Berechtigung besitzt, ist unter Benutzerverwaltung und Zugriffsrechte dokumentiert.
KI-Nutzung - die Modellklasse, an die die Anfrage geroutet wird, oder "keine", wenn die Funktion ohne Sprachmodell arbeitet. Die Klassen und die dahinterliegenden Modelle sind unter Private Cloud & On-Premises Deployments beschrieben.

Matrix

Funktion	Verarbeitete Daten	Schnittstelle / Protokoll	Erforderliche Berechtigung	KI-Nutzung
Anmeldung und Sitzung	Identitätsdaten (Name, E-Mail, Passwort-Hash oder SSO-Subject), Sitzungscookie	HTTPS; OpenID Connect / OAuth 2.0 für SSO; TOTP oder WebAuthn für MFA	keine - jeder authentifizierte Benutzer	keine
Benutzer- und Rollenverwaltung	Identitätsdaten, Rollenzuweisungen	HTTPS (UI und REST-API)	`Benutzer einladen`, `Rollen ändern und Benutzer entfernen`	keine
Gruppenverwaltung	Gruppennamen, Mitgliedschaften	HTTPS	`Gruppen erstellen und verwalten`	keine
Datenquelle anbinden	Verbindungsparameter und Zugangsdaten des Quellsystems	Native Datenbankprotokolle (PostgreSQL, MS SQL Server, Oracle, SAP HANA, Snowflake, Databricks, BigQuery, Redshift, ClickHouse, Synapse, MotherDuck/DuckDB), OData über HTTPS, SharePoint, Object Storage (S3, Azure Blob, GCS)	`Datenquellen hinzufügen`	keine
Datei-Upload	Inhalte der hochgeladenen Datei (XLSX, CSV, JSON, Parquet)	HTTPS	Bearbeiten am Zielobjekt	keine
Profiling	Spaltenwerte der ausgewählten Tabelle und die daraus abgeleiteten Statistiken	Protokoll der angebundenen Quelle	Ansehen oder Bearbeiten an der Tabelle	keine
Regelausführung (Datenqualitätsprüfung)	Daten der angebundenen Quelle im Umfang des Regelsatzes; die entstehenden Findings	Protokoll der angebundenen Quelle	Bearbeiten am Regelsatz	keine
Regelvorschläge	Tabellen- und Spaltenmetadaten, vom Benutzer freigegebene Beispielwerte	HTTPS zum KI-Gateway (OpenAI-kompatibel)	Bearbeiten an der Tabelle	`STANDARD`
DQ-KI-Assistent (Chat)	Benutzereingabe, Tabellenmetadaten, freigegebene Beispielwerte	HTTPS zum KI-Gateway	Ansehen an der Tabelle	`FAST`
LLM-basierte Regeln (semantische Regeln)	Werte der von der Regel geprüften Spalten	HTTPS zum KI-Gateway	Bearbeiten am Regelsatz	`FAST`
Regelbeschreibungen, Benennung von Regelsätzen und Missionen	Regel- und Regelsatz-Metadaten	HTTPS zum KI-Gateway	Bearbeiten am Objekt	`NANO` (nutzt ersatzweise FAST)
Spaltenzuordnung beim Mapping von Systemtabellen	Spaltennamen und Datentypen	HTTPS zum KI-Gateway	`Datenquellen hinzufügen`	`COLUMN_RELATION` (nutzt ersatzweise FAST)
PDF-Konnektor	Inhalte der bereitgestellten PDF-Dokumente	HTTPS zum KI-Gateway	`Datenquellen hinzufügen`	`PDF_PROCESSING` (nutzt ersatzweise STANDARD)
Datenverbesserung: Adressen	Adressfelder der ausgewählten Datensätze	HTTPS zum KI-Gateway; optional ein Geocoding- oder Fetch-Proxy, sofern konfiguriert	Bearbeiten an der Tabelle	`STANDARD`
Dublettenauflösung	Datensätze der ausgewählten Tabelle	HTTPS zum KI-Gateway	Bearbeiten an der Tabelle	`STANDARD`
Issue-Bearbeitung und Export	Findings und die zugehörigen Datensätze	HTTPS; Export als XLSX, CSV, JSON, Parquet oder PDF	Ansehen an der Tabelle	keine
Missionen und Alarme	Empfängerdaten (Name, E-Mail), Zusammenfassungen von Findings	HTTPS; SMTP für E-Mail; konfigurierte Chat-Kanäle	`Missionen und Alarme verwalten`	keine
Webhooks	Ereignis-Payloads (Objekt-IDs, Ergebnisse von Läufen)	HTTPS, ausgehend, signiert	`Zugriff auf API-Token`	keine
REST-API	Je nach Endpunkt - dieselben Objekte wie in der Benutzeroberfläche	HTTPS/REST (JSON), authentifiziert per JWT oder API-Token	`Zugriff auf API-Token` zusätzlich die Objektrechte des Aufrufers	keine
BI-Verbindung	Aggregierte Ergebnisse und Findings	PostgreSQL-Protokoll, nur lesend	`Zugriff auf BI-Verbindung`	keine
Unternehmensregeln, Tags, Qualitätsdimensionen	Regel-Metadaten	HTTPS	`Unternehmensregeln verwalten`, `Tags verwalten`, `Qualitätsdimensionen verwalten`	keine
LLM-Einstellungen	Endpunkt-URL, API-Schlüssel, Modellnamen	HTTPS	`LLM-Einstellungen verwalten`	keine

Datenkategorien

Kategorie	Beispiele	Wo sie gespeichert werden
Identitätsdaten	Name, E-Mail-Adresse, Rolle, Gruppenmitgliedschaften, Authentifizierungsfaktoren	Plattform-Datenbank (Identitäts-Schema von Ory Kratos)
Verbindungsmetadaten	Host, Port, Datenbank, Benutzer und die Zugangsdaten einer angebundenen Quelle	Plattform-Datenbank. Die Zugangsdaten des Deployments selbst (Plattform-Datenbank, LLM-Gateway, SSO) liegen als Kubernetes Secrets oder in einem externen Secret Store.
Strukturmetadaten	Tabellen- und Spaltennamen, Datentypen, Profiling-Statistiken, Regeln und Regelsätze	Plattform-Datenbank, im Schema des jeweiligen Mandanten
Beispieldaten	Einzelne Werte aus einer angebundenen Quelle, soweit eine Prüfung, ein Profiling-Lauf oder eine Assistenz-Anfrage sie benötigt	Plattform-Datenbank (Mandanten-Schema) und der konfigurierte Object Storage
Findings	Regelergebnisse, Issue-Datensätze, Quality Scores und deren Historie	Plattform-Datenbank, im Schema des jeweiligen Mandanten
Betriebsdaten	Container-Logs, Traces und Metriken, Lauf-Historie	Standardausgabe der Container, der konfigurierte OpenTelemetry-Endpunkt und die Plattform-Datenbank

Was das Sprachmodell erreicht

Sämtlicher LLM-Verkehr der Plattform läuft über ein einziges Gateway, das OpenAI-API-kompatibel ist. Es läuft entweder im eigenen Cluster (self-hosted) oder - wenn Sie sich dafür entscheiden - als DQC-gehostetes Gateway, das mit einem für Sie ausgestellten Virtual Key angesprochen wird.

Anfragen enthalten Strukturmetadaten und die Beispielwerte, die die jeweilige Funktion benötigt - keine Kopie der angebundenen Quelle.
Auf welches Modell eine Klasse geroutet wird, bestimmen Sie: Sie können jede Klasse auf Ihren eigenen Endpunkt richten, und ein Modell kann mehrere Klassen bedienen.
Die KI-Funktionen lassen sich abschalten. Ohne konfiguriertes Gateway startet die Plattform, und jede Funktion der Matrix mit dem Eintrag "keine" arbeitet weiter.
In abgeschotteten Netzen kann das Gateway über einen ausgehenden Proxy geführt und mit einem eigenen CA-Bundle versehen werden.