Ihre Branche

Keine Branche ist wirklich „wie alle anderen“

Auf den ersten Blick ähneln sich viele betriebliche Aufgaben.

Unternehmen:

• beantworten Anfragen,
• erstellen Angebote,
• prüfen Dokumente,
• verwalten Wissen,
• koordinieren Freigaben,
• produzieren Inhalte,
• bearbeiten Vorgänge,
• und dokumentieren Entscheidungen.

Deshalb wirken generische KI-Lösungen zunächst attraktiv.

Ein allgemeines System kann schließlich:

• Texte lesen,
• Inhalte zusammenfassen,
• Informationen klassifizieren,
• Fragen beantworten,
• Formulierungen erzeugen,
• und Daten zwischen Anwendungen übertragen.

Doch bereits beim zweiten Blick beginnen die Unterschiede.

Eine „Freigabe“ bedeutet in einer Kreativagentur etwas anderes als in einer Kommunalverwaltung.

Ein „Fall“ besitzt in einem technischen Service eine andere Struktur als in einer Beratung.

Eine „Abweichung“ kann im Qualitätsmanagement ein messbares Prüfergebnis, in der Finanzprüfung eine Buchungsdifferenz und in einer redaktionellen Organisation einen Verstoß gegen eine Inhaltsregel bezeichnen.

Auch scheinbar einfache Wörter sind nicht neutral:

• Auftrag
• Kunde
• Leistung
• Produkt
• Quelle
• Prüfung
• Risiko
• Status
• Freigabe
• Abschluss

Jede Branche und häufig sogar jedes Unternehmen verbindet damit eigene Regeln und Erwartungen.

Ein KI-System versteht eine Domäne nicht dadurch, dass es ihre Begriffe wiederholen kann. Es versteht sie erst dann ausreichend, wenn es weiß, welche Bedeutung, Verantwortung und Handlung mit diesen Begriffen verbunden ist.

Das Problem allgemeiner KI-Lösungen ist nicht ihre Allgemeinheit

Generische Technologie ist grundsätzlich wertvoll.

Viele technische Fähigkeiten werden in unterschiedlichen Branchen benötigt:

• Dokumente einlesen,
• Textpassagen finden,
• Daten extrahieren,
• E-Mails verarbeiten,
• Systeme verbinden,
• Aufgaben anlegen,
• Ergebnisse protokollieren,
• Versionen verwalten,
• und Sprachmodelle ansprechen.

Es wäre unwirtschaftlich, diese Funktionen für jede Branche neu zu entwickeln.

Das Problem entsteht erst, wenn aus einer allgemeinen technischen Fähigkeit automatisch eine fachlich passende Lösung werden soll.

Ein allgemeines Modell kann beispielsweise aus einem Dokument eine Zusammenfassung erzeugen.

Es weiß dadurch noch nicht:

• welche Abschnitte verbindlich sind,
• ob eine ältere Version verwendet werden darf,
• welche Aussagen besonders kritisch sind,
• wer das Ergebnis sehen darf,
• welche Fachbegriffe unverändert bleiben müssen,
• ob eine fehlende Angabe nur unvollständig oder tatsächlich unzulässig ist,
• und wann eine menschliche Entscheidung zwingend erforderlich wird.

Die technische Fähigkeit ist generisch.

Die fachliche Einordnung ist domänenspezifisch.

Eine belastbare Plattform trennt diese beiden Ebenen voneinander.

Zwischen Standardsoftware und Sonderentwicklung liegt ein dritter Weg

Unternehmen stehen bei spezialisierten Anforderungen häufig vor zwei scheinbaren Alternativen.

Alternative 1: Standardsoftware

Die Organisation übernimmt:

• vordefinierte Datenmodelle,
• feste Prozessschritte,
• allgemeine Rollen,
• standardisierte Oberflächen,
• und die Logik des Anbieters.

Das kann schnell funktionieren.

Problematisch wird es, wenn das Unternehmen seine Arbeit dauerhaft an das Werkzeug anpassen muss.

Typische Folgen sind:

• zusätzliche Tabellen,
• manuelle Nebenprozesse,
• unpassende Statuswerte,
• fehlende Fachlogik,
• und Umgehungslösungen außerhalb des Systems.

Alternative 2: individuelle Sonderentwicklung

Die Lösung wird exakt für einen bestimmten Prozess aufgebaut.

Sie bildet:

• Fachbegriffe,
• Rollen,
• Regeln,
• Daten,
• Oberflächen,
• und Abläufe

sehr genau ab.

Das kann im ersten Anwendungsfall gut funktionieren.

Bei jeder Erweiterung entstehen jedoch neue individuelle Komponenten.

Mit der Zeit wächst eine schwer wartbare Landschaft aus:

• Sonderfällen,
• individuellen Schnittstellen,
• duplizierter Logik,
• hart codierten Regeln,
• und voneinander abweichenden Anwendungen.

Der dritte Weg: generische Fähigkeiten, domänenspezifische Konfiguration

Die technische Plattform bleibt modular und wiederverwendbar.

Die Fachlichkeit wird in konfigurierbaren Schichten beschrieben:

• Domänen,
• Begriffe,
• Entitäten,
• Quellen,
• Rollen,
• Regeln,
• Prüfungen,
• Workflows,
• und Qualitätskriterien.

Dadurch muss eine neue Branche nicht in eine vorhandene Schablone gezwungen werden.

Gleichzeitig muss nicht für jede Besonderheit eine neue technische Einzellösung entstehen.

Die Plattform folgt dem Wissen der Domäne

Der zentrale Gestaltungsgrundsatz lautet:

Nicht die Fachlichkeit wird an die Plattform angepasst. Die Plattform wird so konfiguriert, dass sie die Fachlichkeit abbilden kann.

Das bedeutet nicht, jede bestehende Gewohnheit unverändert zu digitalisieren.

Auch branchenspezifische Abläufe können:

• unnötig kompliziert,
• historisch gewachsen,
• widersprüchlich,
• oder schlecht dokumentiert

sein.

Die Domäne wird deshalb nicht einfach kopiert.

Sie wird gemeinsam mit Fachleuten analysiert und modelliert.

Dabei werden Fragen beantwortet wie:

• Welche Objekte und Vorgänge sind zentral?
• Welche Begriffe besitzen eine eindeutige fachliche Bedeutung?
• Welche Quellen gelten als verbindlich?
• Welche Entscheidungen werden getroffen?
• Welche Informationen werden dafür benötigt?
• Welche Regeln sind eindeutig?
• Wo gibt es Interpretationsspielraum?
• Welche Risiken entstehen bei einem Fehler?
• Wer darf welche Handlung ausführen?
• Wie wird ein Ergebnis überprüft?
• Welche Ausnahmen gehören zum normalen Betrieb?

Aus diesen Antworten entsteht keine technische Kopie der Organisation.

Es entsteht ein strukturiertes Modell ihrer relevanten Fachlogik.

Was eine Domäne im System ausmacht

Eine Domäne ist mehr als ein Themenordner.

Sie beschreibt einen zusammenhängenden fachlichen Raum.

Dazu gehören mehrere Ebenen.

1. Fachbegriffe

Die Domäne besitzt ein eigenes Vokabular.

Dieses enthält:

• bevorzugte Bezeichnungen,
• Abkürzungen,
• Synonyme,
• veraltete Begriffe,
• mehrdeutige Wörter,
• und Begriffe, die nicht austauschbar verwendet werden dürfen.

Ein Beispiel:

In einem Unternehmen können „Anfrage“, „Lead“, „Opportunity“ und „Projektchance“ unterschiedliche Reifestufen bezeichnen.

Ein allgemeines Sprachmodell könnte diese Wörter ähnlich behandeln.

Der Fachprozess darf sie möglicherweise nicht verwechseln.

Das Domänenmodell hält deshalb fest:

• welche Bedeutung ein Begriff besitzt,
• zu welchem Objekt er gehört,
• welche Synonyme zulässig sind,
• und welche Abgrenzung zu ähnlichen Begriffen gilt.

2. Fachobjekte

Jede Domäne arbeitet mit bestimmten Objekten.

Das können beispielsweise sein:

• Antrag,
• Maschine,
• Produkt,
• Kampagne,
• Vertrag,
• Rechnung,
• Servicefall,
• Mandat,
• Prüfung,
• Veranstaltung,
• Tierbestand,
• Bauvorhaben,
• Immobilie,
• oder Forschungsprojekt.

Für jedes Objekt wird beschrieben:

• welche Merkmale es besitzt,
• welche Beziehungen bestehen,
• welche Zustände möglich sind,
• und welche Aktionen zulässig sind.

3. Ereignisse

Ein Prozess verändert sich durch Ereignisse.

Beispiele:

• Dokument eingegangen
• Messwert überschritten
• Kunde hat geantwortet
• Frist erreicht
• Freigabe erteilt
• Zahlung verbucht
• Quelle aktualisiert
• Termin abgesagt
• Prüfung fehlgeschlagen
• Asset veröffentlicht

Ereignisse lösen:

• Prüfungen,
• Aufgaben,
• Benachrichtigungen,
• Statusänderungen,
• oder Eskalationen

aus.

4. Entscheidungen

Nicht jede Veränderung ist automatisch.

Eine Domäne enthält Entscheidungspunkte:

• Ist die Anfrage ausreichend qualifiziert?
• Darf das Dokument veröffentlicht werden?
• Muss eine Abweichung eskaliert werden?
• Ist ein Antrag vollständig?
• Kann ein Angebot freigegeben werden?
• Benötigt eine Maschine eine sofortige Prüfung?
• Ist eine Aussage durch eine Quelle ausreichend belegt?

Das Modell beschreibt:

• wer entscheidet,
• welche Informationen benötigt werden,
• welche Regeln gelten,
• und wie die Entscheidung dokumentiert wird.

5. Ergebnisse

Ein Prozess produziert nicht nur Dateien.

Er erzeugt fachlich bewertete Ergebnisse.

Beispiele:

• qualifizierter Vorgang,
• freigegebenes Angebot,
• beantwortete Fachfrage,
• geprüfte Rechnung,
• Wartungsempfehlung,
• veröffentlichter Inhalt,
• oder dokumentierte Entscheidung.

Das System muss wissen, wann ein Ergebnis als:

• Entwurf,
• geprüft,
• freigegeben,
• abgelehnt,
• veraltet,
• oder abgeschlossen

gilt.

Fachsprache ist ein Teil der Prozesslogik

Sprache wird in KI-Projekten häufig als reine Oberfläche behandelt.

Ein System soll freundlicher, einfacher oder markentypischer formulieren.

In spezialisierten Domänen reicht das nicht aus.

Fachbegriffe können konkrete Folgen besitzen.

Ein Beispiel:

Die Formulierungen:

• „nicht nachgewiesen“
• „nicht vorhanden“
• „nicht geprüft“
• „nicht erforderlich“

können vollkommen unterschiedliche Zustände beschreiben.

Ein System darf daraus nicht denselben Status ableiten.

Ebenso kann der Unterschied zwischen:

• Empfehlung,
• Hinweis,
• Feststellung,
• Freigabe,
• Anweisung,
• und Entscheidung

fachlich entscheidend sein.

Deshalb wird Sprache im Domänenmodell mit Regeln verbunden.

Es wird festgelegt:

• welche Begriffe verbindlich sind,
• welche Formulierungen eine bestimmte Bedeutung besitzen,
• welche Aussagen gekennzeichnet werden müssen,
• welche Unsicherheit sichtbar bleiben muss,
• und welche Wörter nur nach fachlicher Prüfung verwendet werden dürfen.

KI darf Sprache flexibel verarbeiten.

Der Fachkontext setzt Grenzen für ihre Interpretation.

Ein Glossar allein genügt nicht

Ein Glossar erklärt Begriffe.

Ein produktives Domänenmodell muss zusätzlich Beziehungen verstehen.

Beispiel:

Kunde
→ besitzt Vertrag
→ Vertrag enthält Leistung
→ Leistung wird in Projekt erbracht
→ Projekt erzeugt Deliverable
→ Deliverable benötigt Freigabe

Oder:

Maschine
→ produziert Auftrag
→ Auftrag verwendet Materialcharge
→ Prozess erzeugt Messwerte
→ Messwerte gehören zu Prüfung
→ Prüfung kann Abweichung auslösen

Oder:

Antrag
→ gehört zu Leistung
→ benötigt Nachweise
→ wird durch Rolle geprüft
→ kann Rückfrage auslösen
→ endet in Entscheidung

Erst diese Beziehungen machen Informationen für Prozesse nutzbar.

Ein Sprachmodell kann in einem Text erkennen, dass ein Begriff erwähnt wird.

Das Domänenmodell zeigt, welche Bedeutung diese Erwähnung für den Vorgang besitzt.

Quellen besitzen in jeder Domäne einen anderen Stellenwert

Nicht jede Information ist gleich verbindlich.

Eine Domäne kann unterschiedliche Quellentypen enthalten:

• gesetzliche oder normative Grundlage,
• interne Richtlinie,
• freigegebene Arbeitsanweisung,
• technisches Handbuch,
• Vertrag,
• Produktdatenblatt,
• Forschungsquelle,
• Projektentscheidung,
• Erfahrungsbericht,
• Kundenkommentar,
• oder informelle Notiz.

Das System muss unterscheiden können:

• Welche Quelle definiert eine verbindliche Regel?
• Welche Quelle liefert nur Hintergrundwissen?
• Welche Information ist historisch?
• Welche Aussage wurde fachlich freigegeben?
• Welche Quelle gilt nur für einen Standort oder Kunden?
• Welche Quelle darf öffentlich verwendet werden?
• Welche Information ist vertraulich?
• Welche Aussage widerspricht einer neueren Fassung?

Ein allgemeiner Wissensassistent, der alle Dokumente gleich behandelt, kann überzeugende, aber fachlich falsche Antworten erzeugen.

Eine domänenfähige Wissensbasis benötigt deshalb eine Quellenhierarchie.

Quellenhierarchien verhindern zufällige Wahrheit

Angenommen, das System findet zu einer Frage drei passende Textstellen:

1. eine aktuelle freigegebene Arbeitsanweisung,
2. eine ältere Präsentation,
3. eine persönliche Projektnotiz.

Semantisch können alle drei ähnlich relevant wirken.

Fachlich besitzen sie jedoch nicht denselben Stellenwert.

Das Domänenmodell kann festlegen:

Freigegebene Richtlinie
> gültige Arbeitsanweisung
> freigegebene Fachinformation
> Projektdokumentation
> Erfahrungsnotiz
> ungeprüfter Entwurf

Diese Rangfolge ist nicht universell.

Eine andere Domäne kann eine andere Quellenlogik benötigen.

Wichtig ist, dass sie nicht dem Zufall des Suchergebnisses überlassen bleibt.

Das System sollte bei widersprüchlichen Quellen nicht eigenständig die angenehmste Antwort auswählen.

Es muss den Konflikt sichtbar machen.

Qualitätsmaßstäbe sind domänenspezifisch

Ein gutes Ergebnis sieht je nach Fachgebiet vollkommen unterschiedlich aus.

Bei einer Produktbeschreibung kann Qualität bedeuten:

• Fakten korrekt,
• Nutzen verständlich,
• Markenstimme konsistent,
• Kanalvorgaben eingehalten,
• Claims belegt.

Bei einer Wartungsempfehlung kann Qualität bedeuten:

• richtige Anlage zugeordnet,
• Sicherheitsanweisung berücksichtigt,
• aktuelle Messwerte einbezogen,
• mögliche Ursache nicht als Gewissheit dargestellt,
• fachliche Prüfung vorgesehen.

Bei einer Verwaltungsinformation kann Qualität bedeuten:

• zuständige Leistung gefunden,
• Quelle aktuell,
• verständliche Sprache,
• klare Abgrenzung zur Einzelfallentscheidung,
• barrierearmer Zugang.

Bei einem kreativen Konzept kann Qualität bedeuten:

• Briefing getroffen,
• eigenständige Perspektive,
• Markenpassung,
• medienübergreifende Tragfähigkeit,
• Rechte geklärt.

Ein universeller Qualitätsscore wäre dafür ungeeignet.

Jede Domäne benötigt eigene Prüfkriterien.

Qualität muss in prüfbare Fragen übersetzt werden

Abstrakte Anforderungen wie „hochwertig“, „korrekt“ oder „professionell“ helfen einem produktiven System nur begrenzt.

Sie müssen konkretisiert werden.

Beispiel für einen Fachartikel:

• Sind alle zentralen Aussagen durch freigegebene Quellen gestützt?
• Werden Annahmen sichtbar gekennzeichnet?
• Ist die Zielgruppe eindeutig adressiert?
• Wurde die definierte Markensprache eingehalten?
• Enthält der Text ausgeschlossene Behauptungen?
• Sind Quellen und Zitate nachvollziehbar?
• Ist die aktuelle Themenversion verwendet worden?

Beispiel für einen Servicefall:

• Ist der Kunde eindeutig zugeordnet?
• Wurde das betroffene Produkt erkannt?
• Sind Bestell- und Vertragsinformationen vorhanden?
• Wurde die Anfrage korrekt klassifiziert?
• Ist eine manuelle Eskalation notwendig?
• Darf die vorgeschlagene Antwort versendet werden?
• Welche Entscheidung ist noch offen?

Aus solchen Fragen entsteht ein domänenspezifisches Review-System.

Ein Teil lässt sich automatisiert prüfen.

Ein Teil benötigt menschliches Urteil.

Regeln müssen außerhalb des Sprachmodells bleiben

Ein Prompt kann einem Sprachmodell Vorgaben machen.

Er ist jedoch kein geeigneter alleiniger Speicherort für verbindliche Fachlogik.

Kritische Regeln sollten:

• strukturiert,
• versioniert,
• testbar,
• nachvollziehbar,
• und fachlich freigegeben

sein.

Dazu gehören beispielsweise:

• Freigabegrenzen,
• Pflichtfelder,
• Rollenrechte,
• Statusübergänge,
• Ausschlusskriterien,
• Quellenprioritäten,
• Fristen,
• und Eskalationsbedingungen.

Ein vereinfachtes Regelmodell könnte so aussehen:

regel:
  name: "Zusätzliche kaufmännische Freigabe"
  gilt_fuer: "Angebot"
  bedingung:
    gesamtwert: "> 50000"
  erforderliche_rolle:
    - "Vertriebsleitung"
    - "Kaufmännische Leitung"
  automatische_entscheidung: false
  protokollierung: true

Oder:

regel:
  name: "Quelle für öffentliche Antwort"
  gilt_fuer: "Bürgerinformation"
  erlaubte_quellstatus:
    - "öffentlich_freigegeben"
    - "gültig"
  ausgeschlossene_quellstatus:
    - "Entwurf"
    - "historisch"
    - "intern"
  bei_fehlender_quelle:
    aktion: "Fachstelle übergeben"

Das Sprachmodell kann diese Regeln bei der Formulierung berücksichtigen.

Die Regel selbst bleibt aber unabhängig vom Modell verständlich und überprüfbar.

Rollen sind mehr als Benutzerkonten

In einer Domäne existieren unterschiedliche Verantwortlichkeiten.

Eine Rolle kann bestimmen:

• welche Informationen sichtbar sind,
• welche Entwürfe bearbeitet werden dürfen,
• welche Prüfung durchgeführt wird,
• welche Entscheidung möglich ist,
• und welche Aktion ausgelöst werden darf.

Mögliche Rollen sind beispielsweise:

• Sachbearbeitung
• Fachprüfung
• Redaktion
• Vertrieb
• Projektleitung
• Qualitätsmanagement
• Instandhaltung
• Datenschutz
• Rechtsprüfung
• Veröffentlichung
• externe Partner
• Kunde

Ein System darf nicht nur fragen:

Ist die Person angemeldet?

Es muss fragen:

Darf diese Person diese Information in diesem Kontext für diese Handlung verwenden?

Das betrifft auch automatisch erzeugte Ergebnisse.

Wer eine Quelle nicht lesen darf, darf keine Zusammenfassung daraus erhalten.

Wer keinen Preis freigeben darf, darf nicht über einen KI-Umweg eine verbindliche Preisentscheidung auslösen.

Rollenmodelle müssen Entscheidung und Ausführung trennen

Eine Person kann einen Entwurf erstellen, ohne ihn veröffentlichen zu dürfen.

Eine andere Person kann eine fachliche Prüfung durchführen, aber keine Zahlung auslösen.

Eine dritte Person kann einen Vorgang freigeben, ohne seine technischen Regeln verändern zu dürfen.

Deshalb sollte unterschieden werden zwischen:

• lesen,
• erstellen,
• bearbeiten,
• kommentieren,
• fachlich bestätigen,
• freigeben,
• veröffentlichen,
• ausführen,
• und administrieren.

Diese Trennung verhindert, dass eine komfortable KI-Oberfläche bestehende Kontrollmechanismen unbeabsichtigt zusammenzieht.

Risiken unterscheiden sich von Domäne zu Domäne

Ein falscher Social-Media-Entwurf hat andere Folgen als:

• eine fehlerhafte Zahlungsfreigabe,
• eine falsche Wartungsanweisung,
• eine unzulässige Gesundheitsbehauptung,
• eine fehlerhafte Verwaltungsinformation,
• oder eine falsche Vertragsauslegung.

Deshalb benötigt jede Domäne ein eigenes Risikomodell.

Eine einfache Einteilung kann mehrere Dimensionen betrachten:

Auswirkung

Welche Folgen hätte ein Fehler?

• gering
• begrenzt
• erheblich
• kritisch

Reversibilität

Kann die Handlung leicht korrigiert werden?

• Entwurf kann verworfen werden
• Veröffentlichung kann zurückgezogen werden
• Vorgang kann korrigiert werden
• Entscheidung besitzt schwer umkehrbare Folgen

Betroffene Personen oder Werte

Sind betroffen:

• interne Effizienz,
• Kundenbeziehung,
• finanzielle Mittel,
• personenbezogene Daten,
• Sicherheit,
• Rechte,
• oder öffentliche Vertrauenswürdigkeit?

Automatisierungsgrad

Darf das System:

• nur informieren,
• einen Vorschlag erzeugen,
• nach Bestätigung ausführen,
• oder einen eindeutig regelbasierten Schritt selbstständig ausführen?

Aus diesen Faktoren ergibt sich die notwendige Kontrolltiefe.

Nicht jede Domäne benötigt dieselbe KI

Ein häufiges Missverständnis lautet:

Wir wählen ein leistungsfähiges Modell und nutzen es anschließend für alle Aufgaben.

In der Praxis benötigen verschiedene Aufgaben unterschiedliche technische Verfahren.

Klassische Regeln

Geeignet für:

• eindeutige Prüfungen,
• Grenzwerte,
• Pflichtfelder,
• Statuslogik,
• und Rechte.

Suche

Geeignet für:

• Dokumente,
• Datensätze,
• Fakten,
• und bereits bekannte Informationen.

Semantische Suche

Geeignet für:

• inhaltlich ähnliche Passagen,
• unterschiedliche Formulierungen,
• und umfangreiche Wissensbestände.

Kleine Sprachmodelle

Geeignet für:

• Klassifikation,
• Extraktion,
• kurze Zusammenfassungen,
• und standardisierte Textaufgaben.

Leistungsfähigere Sprachmodelle

Geeignet für:

• komplexe Analyse,
• strukturierte Synthese,
• umfangreiche Kontextverarbeitung,
• und anspruchsvolle Textentwürfe.

Spezialisierte Modelle

Geeignet für:

• Bilder,
• Sprache,
• Dokumentlayouts,
• Zeitreihen,
• oder andere besondere Datentypen.

Menschen

Unverzichtbar für:

• Verantwortung,
• Werturteil,
• Ausnahmen,
• Konflikte,
• und verbindliche Entscheidungen.

Die Domäne bestimmt, welche Kombination angemessen ist.

Nicht jedes Problem wird durch ein größeres Sprachmodell besser gelöst.

Eine Domäne wird als Konfiguration beschreibbar

Wenn Fachlichkeit sauber modelliert ist, kann sie in konfigurierbaren Bausteinen dargestellt werden.

Ein vereinfachtes Domänenpaket könnte enthalten:

domaene:
  name: "Technischer Kundendienst"
  version: "1.2"

begriffe:
  - name: "Servicefall"
    synonyme:
      - "Störung"
      - "Ticket"
    abgrenzung:
      - "Wartungsauftrag"

objekte:
  - name: "Servicefall"
    pflichtfelder:
      - "Kunde"
      - "Anlage"
      - "Fehlerbeschreibung"
      - "Priorität"

quellen:
  erlaubte_typen:
    - "Servicehandbuch"
    - "Freigegebener Wartungsbericht"
    - "Technische Mitteilung"

rollen:
  - name: "Serviceannahme"
    darf:
      - "Fall anlegen"
      - "Zuordnung bestätigen"
  - name: "Technischer Spezialist"
    darf:
      - "Diagnose prüfen"
      - "Maßnahme freigeben"

regeln:
  - name: "Sicherheitskritische Meldung"
    bedingung: "sicherheitsklasse >= 3"
    aktion: "sofortige menschliche Eskalation"

qualitaet:
  - "Quelle sichtbar"
  - "Anlage eindeutig"
  - "Keine automatische Sicherheitsfreigabe"

Dieses Beispiel ist bewusst vereinfacht.

Es zeigt jedoch den Grundgedanken:

Die Fachlogik ist nicht als unübersichtlicher Sondercode versteckt.

Sie wird als nachvollziehbare Konfiguration geführt.

Konfiguration bedeutet nicht Beliebigkeit

Eine Plattform, die alles konfigurieren kann, kann schnell unübersichtlich werden.

Deshalb benötigt auch die Konfiguration klare Grenzen.

Nicht jede Einstellung sollte frei veränderbar sein.

Zu unterscheiden sind:

Technische Kernfunktionen

Beispielsweise:

• Authentifizierung,
• Protokollierung,
• Jobsteuerung,
• Fehlerbehandlung,
• Versionierung,
• Modellzugriff,
• und Basissicherheit.

Diese bleiben plattformweit konsistent.

Domänenkonfiguration

Beispielsweise:

• Begriffe,
• Objekte,
• Quellenarten,
• Rollen,
• Qualitätskriterien,
• und fachliche Regeln.

Diese werden pro Domäne angepasst.

Prozesskonfiguration

Beispielsweise:

• Eingangskanäle,
• Bearbeitungsschritte,
• Freigaben,
• Übergaben,
• und Zielsysteme.

Diese können je Use Case variieren.

Benutzerkonfiguration

Beispielsweise:

• persönliche Ansichten,
• Filter,
• Benachrichtigungen,
• und bevorzugte Arbeitsoberflächen.

Diese Trennung verhindert, dass jede Anpassung die technische Stabilität gefährdet.

Fachliche Besonderheit darf nicht zu technischer Schuld werden

Technische Schuld entsteht, wenn kurzfristige Lösungen den späteren Betrieb erschweren.

Bei domänenspezifischen Systemen geschieht das häufig durch:

• hart codierte Fachbegriffe,
• fest eingebaute Statuswerte,
• individuelle Rollenprüfungen,
• duplizierte Schnittstellen,
• Sonderlogik in Benutzeroberflächen,
• und manuell gepflegte Ausnahmen.

Ein Beispiel:

Für einen ersten Kunden wird der Status „Fachlich geprüft“ direkt in mehreren Programmteilen eingebaut.

Beim nächsten Fachgebiet werden andere Status benötigt.

Daraufhin entstehen zusätzliche Sonderfälle.

Später weiß niemand mehr:

• welche Logik allgemein gilt,
• welche nur für einen Kunden,
• und welche Komponente bei einer Änderung angepasst werden muss.

Eine konfigurierbare Plattform vermeidet dies, indem sie Status, Regeln und Rollen als Daten behandelt.

Die Anwendung liest die jeweilige Domänenkonfiguration.

Sie muss nicht für jede neue Bezeichnung neu programmiert werden.

Fachliche Besonderheit ist wertvoll. Technische Sonderbehandlung ist es nur selten.

Wiederverwendbarkeit entsteht nicht durch Kopieren

Wenn ein Pilot funktioniert, liegt es nahe, ihn für den nächsten Bereich zu kopieren.

Aus einem Projektordner entsteht ein zweiter.

Aus einem Workflow werden mehrere fast identische Varianten.

Kurzfristig ist das schnell.

Langfristig entstehen:

• voneinander abweichende Versionen,
• doppelte Fehlerbehebung,
• uneinheitliche Sicherheitsregeln,
• und unklare Zuständigkeiten.

Besser ist es, nach einem Pilot zu unterscheiden:

Was ist allgemeine Fähigkeit?

Beispiele:

• E-Mail erfassen
• Dokument klassifizieren
• Quelle durchsuchen
• Freigabe einholen
• Aufgabe anlegen
• Ergebnis protokollieren

Was ist domänenspezifische Konfiguration?

Beispiele:

• Dokumenttypen
• Fachbegriffe
• Prüfkriterien
• Rollen
• Eskalationsregeln
• zulässige Quellen

Was ist use-case-spezifischer Ablauf?

Beispiele:

• Reihenfolge der Schritte
• benötigte Systeme
• konkrete Oberfläche
• Benachrichtigungen
• und Zielaktionen

Nur die wiederverwendbaren Teile werden in die gemeinsame Plattform übernommen.

Der nächste Use Case kombiniert sie neu.

Aus erfolgreichen Piloten entsteht eine Fähigkeitsbibliothek

Mit jedem umgesetzten Prozess können wiederverwendbare Bausteine entstehen.

Beispiele:

Eingang und Erfassung

• E-Mail-Import
• Formularannahme
• Datei-Upload
• API-Eingang
• Ereignisverarbeitung

Dokumentverarbeitung

• Dokumenttyp erkennen
• Text extrahieren
• Tabellen erfassen
• Metadaten ergänzen
• Dokumente vergleichen

Wissen

• Quellen indexieren
• semantisch suchen
• Antworten mit Quellen erstellen
• Widersprüche markieren
• Versionen berücksichtigen

Entscheidungen

• Regeln prüfen
• Freigaben einholen
• Ausnahmen eskalieren
• Entscheidungsgrundlage zusammenstellen
• Entscheidung dokumentieren

Kommunikation

• Antwortentwurf
• Mehrsprachigkeit
• kanalbezogene Formatierung
• Statusinformation
• Benachrichtigung

Betrieb

• Monitoring
• Fehlerwarteschlange
• Wiederholung fehlgeschlagener Schritte
• Audit-Trail
• Kostenmessung

Diese Bausteine bilden eine Fähigkeitsbibliothek.

Neue Branchenlösungen werden daraus zusammengesetzt und durch ihre Domänenkonfiguration spezialisiert.

Die Benutzeroberfläche folgt der Aufgabe, nicht der Plattform

Eine modulare technische Basis bedeutet nicht, dass alle Nutzer dieselbe Oberfläche erhalten müssen.

Ein Produktionsleiter benötigt andere Informationen als:

• eine Redakteurin,
• ein Servicetechniker,
• eine Sachbearbeiterin,
• ein Vertriebsmitarbeiter,
• oder eine Qualitätsprüferin.

Die Oberfläche sollte deshalb aus der jeweiligen Entscheidungssituation entwickelt werden.

Eine Arbeitsliste kann zeigen

• offene Vorgänge,
• Priorität,
• Status,
• verantwortliche Rolle,
• und nächste notwendige Entscheidung.

Eine Detailansicht kann zeigen

• Zusammenfassung,
• Quellen,
• Daten,
• Verlauf,
• Risiken,
• Vorschläge,
• und Aktionen.

Ein Review-Bereich kann zeigen

• Unterschiede zwischen Versionen,
• erfüllte und offene Prüfkriterien,
• Kommentare,
• und Freigabestatus.

Eine operative Ansicht kann zeigen

• aktuelles Ereignis,
• betroffene Objekte,
• Dringlichkeit,
• und mögliche nächste Schritte.

Die technische Plattform bleibt gemeinsam.

Die Interaktion wird an Domäne und Rolle angepasst.

Fachleute müssen das System mitgestalten können

Wenn jede Änderung einen Softwareentwickler benötigt, bleibt die Domäne technisch abhängig.

Deshalb sollten bestimmte fachliche Anpassungen durch autorisierte Personen möglich sein.

Dazu können gehören:

• Begriff ergänzen,
• Quelle freigeben,
• Qualitätskriterium ändern,
• Antwortbaustein aktualisieren,
• Rolle anpassen,
• Regelversion vorbereiten,
• oder neuen Dokumenttyp definieren.

Nicht jede Änderung darf sofort produktiv wirksam werden.

Ein geeigneter Governance-Prozess kann lauten:

Fachliche Änderung vorschlagen
→ Auswirkungen prüfen
→ Testfälle ausführen
→ verantwortliche Rolle bestätigt
→ neue Version veröffentlichen
→ Änderung protokollieren

So bleibt Fachlichkeit veränderbar, ohne den Betrieb unkontrolliert zu verändern.

Domänen verändern sich

Eine Fachdomäne ist kein statisches Modell.

Es ändern sich:

• Begriffe,
• Produkte,
• Vorschriften,
• Rollen,
• Quellen,
• technische Systeme,
• Qualitätsmaßstäbe,
• und Erwartungen der Nutzer.

Ein gutes Domänenmodell besitzt deshalb Versionen.

Eine neue Version kann beispielsweise enthalten:

• zusätzliche Dokumenttypen,
• geänderte Freigabegrenze,
• neue Zuständigkeit,
• aktualisierte Quelle,
• neue Marktsprache,
• oder angepasste Risikokategorie.

Dabei muss nachvollziehbar bleiben:

• Welche Version war zu welchem Zeitpunkt gültig?
• Welche Vorgänge wurden damit bearbeitet?
• Welche Regel wurde angewendet?
• Welche Ergebnisse müssen möglicherweise neu geprüft werden?
• Wer hat die Änderung freigegeben?

Versionierung ist nicht nur eine technische Funktion.

Sie ist ein Teil fachlicher Nachvollziehbarkeit.

Testfälle machen Fachlogik überprüfbar

Software wird getestet.

Fachkonfiguration sollte ebenfalls getestet werden.

Dafür werden reale oder realistische Fälle definiert.

Beispiele:

Standardfall

Alle Angaben sind vollständig und eindeutig.

Unvollständiger Fall

Ein notwendiges Dokument oder Feld fehlt.

Widerspruch

Zwei Quellen oder Angaben passen nicht zusammen.

Berechtigungsfall

Eine Person darf bestimmte Informationen nicht verwenden.

Ausnahme

Der Vorgang folgt nicht dem üblichen Ablauf.

Risikofall

Eine falsche Entscheidung hätte erhebliche Folgen.

Für jeden Fall wird festgelegt:

• erwartete Klassifikation,
• anwendbare Regeln,
• erlaubte Quellen,
• notwendige Rolle,
• erwarteter Systemzustand,
• und mögliche Aktion.

Wenn eine Domänenkonfiguration geändert wird, können diese Fälle erneut ausgeführt werden.

Dadurch wird sichtbar, ob eine vermeintlich kleine Anpassung unerwartete Folgen besitzt.

Fachliche Qualität braucht ein eigenes Monitoring

Technisches Monitoring zeigt:

• System erreichbar,
• Schnittstelle funktioniert,
• Verarbeitung erfolgreich,
• Speicher verfügbar,
• Fehlerquote.

Das reicht für domänenspezifische Anwendungen nicht aus.

Zusätzlich benötigt werden können:

• Anteil falsch klassifizierter Vorgänge,
• Antworten ohne gültige Quelle,
• häufige menschliche Korrekturen,
• abgelehnte Vorschläge,
• übersehene Eskalationen,
• veraltete Inhalte,
• Regelkonflikte,
• und ungewöhnliche Ergebnisveränderungen.

Ein System kann technisch fehlerfrei laufen und fachlich zunehmend schlechter werden.

Beispielsweise weil:

• sich die Eingangsdaten verändert haben,
• neue Begriffe verwendet werden,
• eine Quelle nicht aktualisiert wurde,
• oder ein Modellwechsel andere Ergebnisse erzeugt.

Fachliches Monitoring macht diese Veränderungen sichtbar.

Feedback verbessert nicht nur das Modell

Wenn ein Nutzer einen Vorschlag korrigiert, kann die Ursache an verschiedenen Stellen liegen.

Mögliche Gründe:

• Begriff nicht erkannt,
• Quelle fehlte,
• Rolle falsch zugeordnet,
• Regel unvollständig,
• Eingabedaten fehlerhaft,
• Prozess unklar,
• oder Modellergebnis ungeeignet.

Deshalb sollte Feedback nicht pauschal als „KI lag falsch“ gespeichert werden.

Es kann strukturiert werden als:

• falsche Klassifikation,
• fehlender Kontext,
• Quelle veraltet,
• Regel unvollständig,
• unpassende Formulierung,
• falsche Priorität,
• notwendige Ausnahme,
• oder technischer Fehler.

Dadurch kann gezielt entschieden werden:

• Modell anpassen,
• Prompt ändern,
• Quelle ergänzen,
• Regel korrigieren,
• Domänenmodell erweitern,
• oder Prozess neu gestalten.

Ein Pilot prüft mehr als die technische Machbarkeit

Ein erfolgreicher Pilot beantwortet nicht nur:

Kann ein Modell diese Aufgabe grundsätzlich ausführen?

Er muss mehrere Ebenen prüfen.

Fachlichkeit

• Sind Begriffe und Objekte korrekt modelliert?
• Werden die richtigen Quellen verwendet?
• Sind Regeln vollständig?
• Sind Ergebnisse fachlich hilfreich?

Daten

• Sind die benötigten Informationen verfügbar?
• Können Objekte eindeutig zugeordnet werden?
• Welche Datenlücken treten auf?
• Welche Qualität ist für den Betrieb erforderlich?

Prozess

• Passt die Unterstützung zum tatsächlichen Arbeitsablauf?
• Wo entstehen neue Übergaben?
• Welche Ausnahmen fehlen?
• Wer übernimmt offene Fälle?

Menschen

• Verstehen Nutzer die Vorschläge?
• Können sie Fehler erkennen und korrigieren?
• Wird die Verantwortung eindeutig wahrgenommen?
• Entsteht tatsächliche Entlastung?

Technologie

• Sind Schnittstellen stabil?
• Wie reagiert das System auf Ausfälle?
• Sind Modelle und Komponenten austauschbar?
• Wie hoch sind Laufzeit und Kosten?

Organisation

• Wer pflegt die Domäne?
• Wer verantwortet Regeln?
• Wer betreibt die Lösung?
• Wie werden Änderungen freigegeben?

Erst wenn diese Ebenen zusammenpassen, ist der Pilot übertragbar.

Der Pilot sollte einen vollständigen Vorgang abbilden

Ein häufiges Demonstrationsmuster besteht darin, nur den beeindruckenden KI-Schritt zu zeigen.

Beispiel:

• Dokument hochladen,
• Zusammenfassung erzeugen,
• Ergebnis anzeigen.

Im realen Prozess fehlen dann jedoch:

• Zugriffskontrolle,
• Zuordnung zum Vorgang,
• Quellenstatus,
• Fachprüfung,
• Korrektur,
• Freigabe,
• Speicherung,
• und Fehlerbehandlung.

Ein aussagekräftiger Pilot bildet deshalb einen vollständigen, wenn auch begrenzten Ablauf ab.

Beispiel:

Anfrage geht ein
→ Domäne und Vorgangstyp erkennen
→ vorhandenen Kontext laden
→ Informationen strukturieren
→ Regeln prüfen
→ Entwurf erzeugen
→ Fachperson prüft
→ Ergebnis freigeben
→ Zielsystem aktualisieren
→ Verlauf protokollieren

Der Umfang kann klein sein.

Die Prozesskette sollte vollständig genug sein, um den späteren Betrieb realistisch zu beurteilen.

Die richtige Pilotfrage ist konkret

Nicht:

Kann KI unsere Branche unterstützen?

Sondern beispielsweise:

• Können technische Anfragen einer Produktfamilie zuverlässig strukturiert und zugeordnet werden?
• Können freigegebene Fachquellen für eine definierte Nutzergruppe nachvollziehbar durchsucht werden?
• Können wiederkehrende Dokumente vor einer menschlichen Prüfung auf Vollständigkeit vorbereitet werden?
• Können Inhalte aus einem freigegebenen Wissenskern in drei definierte Formate übertragen werden?
• Können Abweichungen in einem begrenzten Prozess früher sichtbar gemacht werden?
• Können häufige Anfragen schneller an die zuständige Rolle gelangen?

Eine konkrete Frage ermöglicht:

• klare Testfälle,
• messbare Wirkung,
• bekannte Risiken,
• und eine nachvollziehbare Entscheidung über die Fortsetzung.

Nach dem Pilot beginnt die eigentliche Modellierung

Während eines Piloten entstehen zahlreiche Erkenntnisse:

• Begriffe sind anders als angenommen.
• Eine Regel besitzt mehr Ausnahmen.
• Eine Quelle ist nicht verlässlich gepflegt.
• Rollen überschneiden sich.
• Nutzer benötigen andere Informationen.
• Bestimmte Schritte sollten nicht automatisiert werden.
• Eine bestehende Schnittstelle reicht nicht aus.
• Ein scheinbar seltener Sonderfall tritt häufig auf.

Diese Erkenntnisse sind kein Zeichen des Scheiterns.

Sie sind der wichtigste Ertrag des Piloten.

Nach der Testphase wird deshalb geprüft:

Welche Fähigkeiten sind allgemein wiederverwendbar?

Welche Konfiguration gehört zur Domäne?

Welche Prozessdetails bleiben spezifisch?

Welche Annahmen waren falsch?

Welche Verantwortung muss organisatorisch geklärt werden?

Welche Bestandteile sind stabil genug für den Produktivbetrieb?

Erst daraus entsteht ein belastbarer Baustein.

Skalierung bedeutet nicht, alles sofort auszurollen

Ein erfolgreicher Pilot kann auf unterschiedliche Weise erweitert werden.

Horizontal

Derselbe Prozess wird auf weitere:

• Produktgruppen,
• Standorte,
• Teams,
• oder Kundenbereiche

übertragen.

Vertikal

Der bestehende Prozess erhält zusätzliche Schritte.

Beispielsweise:

• von Klassifikation zu Antwortentwurf,
• von Antwortentwurf zu Freigabe,
• von Freigabe zu kontrollierter Ausführung.

Fachlich

Weitere Objekte, Regeln oder Quellentypen werden ergänzt.

Technisch

Zusätzliche Systeme oder Kanäle werden angebunden.

Organisatorisch

Weitere Rollen und Verantwortlichkeiten werden integriert.

Diese Erweiterungen sollten einzeln steuerbar bleiben.

Skalierung ist ein kontrollierter Ausbau.

Kein einmaliger Sprung vom Prototyp zur unternehmensweiten Vollautomatisierung.

Beispiel: Spezialisierter technischer Handel

Ein Unternehmen vertreibt erklärungsbedürftige Komponenten für unterschiedliche Anwendungsbereiche.

Die Produktdaten enthalten:

• technische Eigenschaften,
• Normen,
• Varianten,
• Kompatibilitäten,
• Ausschlüsse,
• und Einsatzbedingungen.

Allgemeine E-Commerce-Automatisierung reicht hier nicht aus.

Ein Domänenmodell könnte beschreiben:

• welche Attribute für welche Produktgruppe Pflicht sind,
• welche Kompatibilitäten zulässig sind,
• welche Aussagen nur mit Datenblatt belegt werden dürfen,
• welche Fragen eine technische Fachperson prüfen muss,
• und welche Produktvarianten nicht miteinander kombiniert werden dürfen.

Ein Pilot könnte einen begrenzten Produktbereich abbilden.

Das System:

1. prüft eingehende Lieferantendaten,
2. vereinheitlicht Fachbegriffe,
3. markiert fehlende Pflichtattribute,
4. erzeugt einen Produktkern aus freigegebenen Fakten,
5. bereitet Shop- und Vertriebsinhalte vor,
6. und übergibt technische Claims zur Fachprüfung.

Die technische Content-Funktion ist wiederverwendbar.

Die Produktlogik wird durch die Domänenkonfiguration bestimmt.

Beispiel: Verband oder Fachorganisation

Ein Verband verwaltet:

• Fachinformationen,
• Stellungnahmen,
• Veranstaltungen,
• Mitgliederfragen,
• Positionspapiere,
• und branchenspezifische Regeln.

Ein allgemeiner Wissensassistent könnte zwar Dokumente durchsuchen.

Für eine belastbare Lösung muss jedoch unterschieden werden zwischen:

• offizieller Verbandsposition,
• externem Fachbeitrag,
• historischem Beschluss,
• Arbeitsentwurf,
• Veranstaltungsunterlage,
• und persönlicher Einschätzung.

Das Domänenmodell legt fest:

• welche Quellen öffentlich verwendet werden dürfen,
• welche Rollen Stellungnahmen freigeben,
• welche Begriffe verbindlich sind,
• wie Aktualität geprüft wird,
• und wann eine Anfrage an ein Fachgremium übergeben werden muss.

Ein Pilot kann zunächst häufige Mitgliederfragen in einem klar abgegrenzten Themenbereich bearbeiten.

Beispiel: Immobilien- und Gebäudebetrieb

Ein Betreiber verwaltet Informationen zu:

• Gebäuden,
• Mietflächen,
• technischen Anlagen,
• Verträgen,
• Wartungen,
• Störungen,
• Dienstleistern,
• und Energieverbrauch.

Eine domänenfähige Plattform verbindet diese Objekte.

Eine eingehende Meldung wie:

Im dritten Obergeschoss ist es seit gestern ungewöhnlich kalt.

kann in Zusammenhang gebracht werden mit:

• Gebäude,
• Fläche,
• Heizungsanlage,
• aktueller Außentemperatur,
• bekannten Störungen,
• Wartungsvertrag,
• und zuständigem Dienstleister.

Die allgemeine Fähigkeit besteht in:

• Nachricht verstehen,
• Kontext suchen,
• Aufgabe erzeugen,
• und Status kommunizieren.

Die konkrete Gebäudelogik wird durch das Domänenmodell bereitgestellt.

Beispiel: Bildungs- und Weiterbildungsorganisation

Ein Bildungsanbieter arbeitet mit:

• Programmen,
• Modulen,
• Lernzielen,
• Zielgruppen,
• Referenten,
• Materialien,
• Prüfungen,
• Terminen,
• und Rückmeldungen.

Eine allgemeine Content-KI könnte aus vorhandenen Dokumenten Unterrichtsmaterial erzeugen.

Ein domänenspezifisches System berücksichtigt zusätzlich:

• Kompetenzniveau,
• didaktische Ziele,
• Prüfungsrelevanz,
• zulässige Quellen,
• Barrierefreiheit,
• Veranstaltungsformat,
• und fachliche Freigabe.

Aus einem geprüften Wissenskern können entstehen:

• Kursbeschreibung,
• Agenda,
• Trainerleitfaden,
• Teilnehmerunterlage,
• Übungsaufgabe,
• und Nachbereitung.

Alle Formate bleiben mit denselben Lernzielen verbunden.

Beispiel: Nischenbranche mit wenig Standardsoftware

Gerade kleine Fachgebiete werden von großen Softwareanbietern häufig nur unzureichend berücksichtigt.

Die Betriebe arbeiten dann mit:

• Tabellen,
• E-Mails,
• spezialisierten Einzelprogrammen,
• Papierformularen,
• und persönlichem Erfahrungswissen.

Eine vollständige Individualentwicklung wäre möglicherweise zu teuer.

Eine generische Plattform mit konfigurierbarem Domänenmodell kann hier einen Mittelweg bieten.

Ein Pilot konzentriert sich beispielsweise auf:

• eine wiederkehrende Anfrage,
• einen Prüfprozess,
• eine Wissenssuche,
• oder eine Dokumentation.

Die Fachbegriffe und Regeln werden gemeinsam modelliert.

Technische Grundfunktionen werden aus vorhandenen Bausteinen zusammengesetzt.

So erhält auch eine kleine Domäne eine passende Lösung, ohne eine vollständige Softwareplattform neu finanzieren zu müssen.

Branchenspezifische Compliance wird zu einer eigenen Regelschicht

Compliance ist nicht in jeder Domäne gleich.

Mögliche Anforderungen betreffen:

• Datenschutz,
• Vertraulichkeit,
• Dokumentationspflicht,
• Vier-Augen-Prinzip,
• Aufbewahrung,
• Barrierefreiheit,
• Kennzeichnung,
• Freigabe,
• Nachweisführung,
• oder sicherheitskritische Prozesse.

Eine Plattform sollte diese Anforderungen nicht nur in allgemeinen Vertragsdokumenten erwähnen.

Sie müssen im tatsächlichen Prozess wirksam werden.

Beispiele:

• Bestimmte Daten dürfen ein internes System nicht verlassen.
• Eine Veröffentlichung benötigt zwei getrennte Freigaben.
• Ein fachlicher Hinweis muss seine Quelle anzeigen.
• Eine technische Handlung darf nur durch eine autorisierte Rolle ausgelöst werden.
• Eine automatisch erzeugte Übersetzung wird als ungeprüft gekennzeichnet.
• Eine Entscheidung benötigt eine dokumentierte Begründung.
• Ein Asset darf nach Ablauf seiner Rechte nicht mehr ausgespielt werden.

Die Compliance-Regeln werden dadurch zu ausführbaren und überprüfbaren Prozessbestandteilen.

Konfigurierbare Compliance ersetzt keine rechtliche Prüfung

Eine Regelschicht kann Anforderungen technisch umsetzen.

Sie kann jedoch nicht selbst bestimmen, welche rechtlichen oder normativen Pflichten für eine Organisation gelten.

Dafür werden benötigt:

• Fachverantwortliche,
• Datenschutz,
• Informationssicherheit,
• Recht,
• Compliance,
• oder andere zuständige Rollen.

Diese Personen definieren:

• welche Regeln gelten,
• wie sie interpretiert werden,
• welche Nachweise erforderlich sind,
• und wann eine Ausnahme zulässig ist.

Die Plattform sorgt anschließend dafür, dass die freigegebenen Regeln:

• konsistent angewendet,
• protokolliert,
• versioniert,
• und bei Änderungen aktualisiert

werden können.

Offene Architektur verhindert die domänenspezifische Sackgasse

Eine Branchenlösung darf nicht dazu führen, dass das Unternehmen dauerhaft an:

• ein einzelnes Modell,
• einen proprietären Datenbestand,
• eine bestimmte Oberfläche,
• oder einen nicht exportierbaren Prozess

gebunden ist.

Eine offene Architektur trennt:

• Domänenmodell,
• Daten,
• Prozesslogik,
• KI-Modelle,
• Benutzeroberflächen,
• und Integrationen.

Dadurch kann beispielsweise:

• ein Sprachmodell ausgetauscht,
• eine Datenquelle ersetzt,
• eine neue Oberfläche ergänzt,
• ein Prozessschritt verändert,
• oder ein weiterer Fachbereich angebunden

werden, ohne das gesamte System neu aufzubauen.

Offen bedeutet dabei nicht zwingend, dass jede Komponente Open Source sein muss.

Offen bedeutet vor allem:

• dokumentierte Schnittstellen,
• exportierbare Informationen,
• sichtbare Regeln,
• und kontrollierbare Abhängigkeiten.

Das Domänenmodell gehört dem Unternehmen

Fachbegriffe, Regeln, Qualitätsmaßstäbe und Prozesswissen sind kein technisches Nebenprodukt.

Sie bilden einen wichtigen Teil der betrieblichen Kompetenz.

Deshalb sollte geklärt sein:

• Wo wird das Domänenmodell gespeichert?
• In welchem Format kann es exportiert werden?
• Wer darf es bearbeiten?
• Wie werden Versionen dokumentiert?
• Kann es unabhängig von einem einzelnen KI-Anbieter weiterverwendet werden?
• Welche Teile enthalten vertrauliches Unternehmenswissen?
• Wie werden externe Dienstleister eingebunden?

Eine Lösung sollte nicht dazu führen, dass die eigene Fachlogik nur innerhalb eines nicht nachvollziehbaren Anbietersystems existiert.

Betrieb beginnt mit klaren Eigentümern

Eine domänenfähige Plattform benötigt mehrere Arten von Verantwortung.

Plattformverantwortung

Zuständig für:

• technische Basis,
• Sicherheit,
• Verfügbarkeit,
• gemeinsame Komponenten,
• und Standards.

Domänenverantwortung

Zuständig für:

• Begriffe,
• Quellen,
• fachliche Regeln,
• Qualität,
• und Weiterentwicklung des Fachmodells.

Prozessverantwortung

Zuständig für:

• konkreten Ablauf,
• Rollen,
• Eskalationen,
• und Wirkung im Arbeitsalltag.

Datenverantwortung

Zuständig für:

• Datenquelle,
• Qualität,
• Zugriff,
• und Aktualität.

Modellverantwortung

Zuständig für:

• Auswahl und Bewertung eingesetzter KI-Modelle,
• Tests,
• Kosten,
• und Ergebnisveränderungen.

Betriebsverantwortung

Zuständig für:

• Monitoring,
• Fehler,
• Support,
• und Wiederherstellung.

Diese Rollen können je nach Größe des Unternehmens von denselben Personen übernommen werden.

Die Verantwortung selbst sollte trotzdem eindeutig benannt sein.

Wie ein neues Fachgebiet aufgenommen wird

Ein systematischer Einstieg in eine neue Domäne kann in mehreren Schritten erfolgen.

1. Fachlichen Zweck klären

Zunächst wird nicht die gesamte Branche modelliert.

Es wird festgelegt:

• Welcher Vorgang soll unterstützt werden?
• Welche Nutzergruppe arbeitet damit?
• Welche Entscheidung soll besser vorbereitet werden?
• Welcher Nutzen wird erwartet?
• Welche Risiken bestehen?

2. Domänensprache erfassen

Gesammelt werden:

• zentrale Begriffe,
• Synonyme,
• Abkürzungen,
• Statuswerte,
• und problematische Mehrdeutigkeiten.

3. Fachobjekte und Beziehungen modellieren

Es wird beschrieben:

• welche Objekte vorkommen,
• welche Merkmale sie besitzen,
• und wie sie miteinander verbunden sind.

4. Quellenlandschaft ordnen

Alle relevanten Quellen werden bewertet nach:

• Verbindlichkeit,
• Aktualität,
• Geltungsbereich,
• Vertraulichkeit,
• und Verantwortlichkeit.

5. Rollen und Entscheidungen aufnehmen

Für jeden Entscheidungspunkt wird geklärt:

• Wer entscheidet?
• Welche Informationen werden benötigt?
• Welche Regel gilt?
• Was darf vorbereitet werden?
• Was darf automatisiert ausgeführt werden?

6. Risiken bestimmen

Es wird bewertet:

• Welche Fehler sind tolerierbar?
• Welche benötigen zwingende menschliche Prüfung?
• Welche Aktionen dürfen niemals autonom erfolgen?
• Welche Daten benötigen besonderen Schutz?

7. Qualitätskriterien formulieren

Ein gutes Ergebnis wird in konkrete, prüfbare Anforderungen übersetzt.

8. Pilotprozess konfigurieren

Vorhandene technische Bausteine werden mit der Domänenkonfiguration zu einem vollständigen Ablauf verbunden.

9. Mit realen Fällen testen

Standardfälle, Ausnahmen, Fehler und kritische Situationen werden geprüft.

10. Lernen und stabilisieren

Erkenntnisse fließen zurück in:

• Begriffe,
• Regeln,
• Quellen,
• Rollen,
• Oberfläche,
• und Prozess.

Der Pilot muss die Organisation mitprüfen

Selbst eine technisch und fachlich gute Lösung kann scheitern, wenn organisatorische Fragen offenbleiben.

Beispiele:

• Niemand fühlt sich für Quellen verantwortlich.
• Fachregeln werden nur mündlich weitergegeben.
• Freigaben besitzen keine Vertretung.
• Ein System darf Daten nicht bereitstellen.
• Nutzer haben keine Zeit für Reviews.
• Fehlerfälle landen in einem unbeobachteten Postfach.
• Eine neue Rolle wurde nicht in der Organisation verankert.

Der Pilot sollte deshalb auch zeigen:

• Wer pflegt Inhalte?
• Wer beantwortet Eskalationen?
• Wer entscheidet bei Widersprüchen?
• Wer bewertet Feedback?
• Wer darf Regeln ändern?
• Wer finanziert den laufenden Betrieb?
• Wie werden neue Mitarbeitende eingearbeitet?

Die Plattform kann Fachlichkeit strukturieren.

Sie kann fehlende Verantwortung nicht selbst erzeugen.

Messbarer Nutzen bleibt use-case-spezifisch

Eine domänenfähige Plattform sollte nicht nur technische Kennzahlen sammeln.

Der betriebliche Nutzen hängt vom konkreten Vorgang ab.

Mögliche Zielgrößen sind:

Zeit

• geringere Suchzeit,
• schnellere Vorbereitung,
• kürzere Durchlaufzeit,
• weniger Wartezeit,
• und schnellere Reaktion.

Qualität

• weniger falsche Zuordnungen,
• vollständigere Datensätze,
• konsistentere Ergebnisse,
• aktuellere Quellen,
• und frühere Erkennung von Abweichungen.

Wissen

• geringere Abhängigkeit von Einzelpersonen,
• bessere Auffindbarkeit,
• nachvollziehbare Entscheidungen,
• und schnellere Einarbeitung.

Wirtschaftlichkeit

• geringerer manueller Aufwand,
• niedrigere Fehlerkosten,
• höhere Wiederverwendung,
• weniger Nacharbeit,
• und bessere Nutzung vorhandener Systeme.

Risiko

• weniger unzulässige Veröffentlichungen,
• klarere Freigaben,
• kontrolliertere Datenzugriffe,
• und bessere Protokollierung.

Akzeptanz

• tatsächliche Nutzung,
• weniger Umgehungsprozesse,
• weniger Korrekturen,
• und positives Feedback der Fachrollen.

Der gleiche technische Baustein kann in verschiedenen Domänen vollkommen unterschiedliche Wirkung erzeugen.

Typische Fehler bei branchenindividuellen KI-Lösungen

Die Branche nur über einige Prompts abbilden

Ein Prompt ersetzt kein Fachmodell aus Begriffen, Quellen, Rollen und Regeln.

Bestehende Abläufe unkritisch kopieren

Nicht jede historische Gewohnheit sollte digital erhalten bleiben.

Alles individuell programmieren

Sondercode für jede Fachanforderung erzeugt langfristig hohe technische Schuld.

Standardsoftware ohne ausreichende Anpassung einsetzen

Wenn Fachlichkeit nur in Tabellen und Nebenprozessen lebt, ist die Lösung nicht wirklich integriert.

Quellen ohne Hierarchie zusammenführen

Semantische Ähnlichkeit sagt nichts über fachliche Verbindlichkeit aus.

Fachbegriffe nur als Synonymliste behandeln

Entscheidend sind Bedeutung, Beziehungen und Prozessfolgen.

Regeln im Prompt verstecken

Verbindliche Logik muss testbar und versionierbar sein.

Rollen nur als Zugriffsgruppen abbilden

Entscheidung, Freigabe und Ausführung benötigen differenzierte Rechte.

Zu früh mehrere Domänen gleichzeitig modellieren

Ein belastbarer Pilot liefert mehr als eine breite, aber oberflächliche Plattformkonfiguration.

Den Pilot nach der Demonstration beenden

Die wichtigsten Erkenntnisse entstehen im realen Betrieb mit Ausnahmen und Fehlern.

Fachliche Konfiguration nicht versionieren

Änderungen müssen später nachvollziehbar bleiben.

Wiederverwendung mit Kopieren verwechseln

Skalierung braucht gemeinsame Fähigkeiten und getrennte Konfigurationen.

Technische und fachliche Verantwortung vermischen

Beide Ebenen benötigen benannte Eigentümer.

Was eine gute domänenfähige Plattform auszeichnet

Eine belastbare Lösung ist:

Generisch im technischen Kern

Grundfunktionen werden nicht für jede Branche neu entwickelt.

Spezifisch in der Fachlichkeit

Begriffe, Quellen, Regeln, Rollen und Qualitätsmaßstäbe werden pro Domäne modelliert.

Modular

Fähigkeiten können zu unterschiedlichen Prozessen kombiniert werden.

Konfigurierbar

Fachliche Änderungen benötigen nicht automatisch neue Sonderprogrammierung.

Versionierbar

Regeln, Quellen und Modelle besitzen nachvollziehbare Entwicklungsstände.

Testbar

Fachlogik wird mit realistischen Fällen überprüft.

Rechtebasiert

Zugriff, Entscheidung und Ausführung bleiben kontrolliert.

Quellenbewusst

Informationen besitzen Herkunft, Gültigkeit und fachlichen Stellenwert.

Zurückhaltend

Bei fehlender Grundlage oder hohem Risiko wird gezielt an Menschen übergeben.

Integrierbar

Bestehende Systeme bleiben führend und werden über dokumentierte Schnittstellen verbunden.

Übertragbar

Erfolgreiche Fähigkeiten können auf weitere Bereiche ausgeweitet werden.

Betreibbar

Monitoring, Fehlerbehandlung, Pflege und Verantwortung sind dauerhaft organisiert.

Ihre Besonderheit ist kein Hindernis

Viele Organisationen glauben, für KI und Automatisierung entweder zu speziell oder noch nicht standardisiert genug zu sein.

Sie sagen beispielsweise:

• Unsere Prozesse sind anders.
• Unsere Fachsprache versteht kein allgemeines System.
• Wir haben zu viele Sonderfälle.
• Unsere Quellen sind zu unterschiedlich.
• Unsere Entscheidungen benötigen Erfahrung.
• Standardsoftware passt nicht zu uns.
• Eine Individualentwicklung wäre zu teuer.

Diese Einwände können berechtigt sein.

Sie sprechen jedoch nicht grundsätzlich gegen eine modulare Lösung.

Sie zeigen, welche Bestandteile modelliert werden müssen:

• Fachsprache,
• Objekte,
• Quellen,
• Regeln,
• Rollen,
• Risiken,
• und Ausnahmen.

Nicht jede Besonderheit erfordert neue Software.

Viele Besonderheiten lassen sich als kontrollierbare Fachkonfiguration ausdrücken.

Der Unterschied zwischen Sonderfall und Domäne

Ein Sonderfall wird häufig nachträglich behandelt.

Das System funktioniert grundsätzlich anders, aber für einen bestimmten Kunden wird eine Ausnahme eingebaut.

Eine Domäne wird dagegen bewusst modelliert.

Ihre Besonderheiten sind keine Abweichung vom „eigentlichen“ System.

Sie sind ein vorgesehener Teil der Architektur.

Das verändert die Perspektive.

Nicht:

Wie bringen wir diesen ungewöhnlichen Prozess irgendwie in unsere Plattform?

Sondern:

Welche allgemeine Fähigkeit wird benötigt, und welche fachliche Konfiguration macht sie für diese Domäne korrekt nutzbar?

So wird Spezialisierung nicht zum technischen Problem.

Sie wird zu einem strukturierten Gestaltungsgegenstand.

Von einer Fachlösung zu einer lernenden Plattform

Mit jedem neuen Use Case wächst nicht nur die Zahl der Anwendungen.

Es wächst auch das gemeinsame Verständnis darüber:

• welche technischen Fähigkeiten wiederkehren,
• welche Domänenmuster ähnlich sind,
• welche Regeln abstrahiert werden können,
• welche Risiken häufig auftreten,
• welche Oberflächen sich bewähren,
• und welche Betriebsmodelle funktionieren.

Ein Freigabeprozess kann beispielsweise in verschiedenen Domänen wiederkehren.

Die konkreten Rollen und Prüfkriterien unterscheiden sich.

Die grundlegende Fähigkeit bleibt ähnlich:

Entwurf
→ fachliche Prüfung
→ offene Punkte
→ Entscheidung
→ Freigabe
→ Ausführung
→ Protokollierung

Dasselbe gilt für:

• Dokumenteingang,
• Wissenssuche,
• Ausnahmesteuerung,
• Quellenprüfung,
• und Aufgabenübergabe.

Die Plattform lernt dadurch nicht nur über Modelle und Daten.

Auch ihre Architektur wird mit jedem Pilot reifer.

Wie aus einer Besonderheit ein wiederverwendbarer Baustein wird

Angenommen, ein Pilot benötigt eine besondere Quellenprüfung.

Zunächst scheint diese Anforderung sehr spezifisch.

Bei genauer Betrachtung enthält sie allgemeine Bestandteile:

• Quelle besitzt Typ,
• Quelle besitzt Status,
• Quelle besitzt Gültigkeit,
• Quelle besitzt Verantwortlichen,
• Quelle besitzt Zugriffsklasse,
• Quelle kann eine andere Quelle ersetzen.

Diese Struktur kann auch in anderen Domänen nützlich sein.

Die konkrete Konfiguration bleibt unterschiedlich:

• technische Norm,
• Verwaltungsrichtlinie,
• Produktdatenblatt,
• redaktionelle Quelle,
• oder Vertragsdokument.

Der Pilot liefert damit nicht nur eine Einzellösung.

Er erweitert die gemeinsame Quellenfähigkeit der Plattform.

Der sinnvolle Einstieg: eine Frage, ein Vorgang, eine Verantwortung

Der Aufbau einer domänenfähigen Plattform sollte nicht mit der vollständigen Modellierung einer Branche beginnen.

Ein praktikabler Einstieg ist kleiner.

Er konzentriert sich auf:

• eine konkrete Frage,
• einen wiederkehrenden Vorgang,
• eine klar benannte Nutzergruppe,
• eine verantwortliche Fachrolle,
• und einen messbaren Nutzen.

Beispiele:

• Welche eingehenden Anfragen gehören zu welchem Fachprozess?
• Welche Informationen fehlen vor einer Angebotserstellung?
• Welche freigegebenen Quellen beantworten eine wiederkehrende Fachfrage?
• Welche Dokumente benötigen vor der Prüfung besondere Aufmerksamkeit?
• Welche Abweichung muss durch welche Rolle bearbeitet werden?
• Welche Inhalte dürfen für welche Zielgruppe veröffentlicht werden?

An diesem kleinen Prozess wird die Domäne sichtbar.

Nicht vollständig, aber ausreichend, um eine belastbare erste Struktur zu entwickeln.

Passt dieser Ansatz zu Ihrer Organisation?

Eine domänenfähige Plattform ist besonders interessant, wenn:

• Standardsoftware Ihre Fachlogik nur unzureichend abbildet,
• mehrere spezialisierte Prozesse ähnliche technische Fähigkeiten benötigen,
• Wissen über viele Quellen verteilt ist,
• Entscheidungen klare Rollen und Freigaben benötigen,
• KI-Ergebnisse nachvollziehbar und kontrollierbar bleiben müssen,
• individuelle Sonderentwicklungen vermieden werden sollen,
• oder ein erster Pilot später auf weitere Bereiche übertragen werden soll.

Der Einstieg benötigt keine vollständig dokumentierte Organisation.

Er benötigt einen konkreten Vorgang und die Bereitschaft, dessen Fachlichkeit gemeinsam sichtbar zu machen.

Zu klären sind zunächst:

• Welche Aufgabe soll verbessert werden?
• Welche Begriffe und Objekte sind dafür zentral?
• Welche Quellen gelten?
• Welche Entscheidungen werden getroffen?
• Welche Regeln sind verbindlich?
• Welche Ausnahmen treten auf?
• Wer trägt Verantwortung?
• Welche technische Fähigkeit kann wiederverwendet werden?
• Und woran erkennen wir, dass der Pilot tatsächlich funktioniert?

Ihre Branche muss nicht in eine generische KI-Schablone passen. Die technische Plattform sollte so aufgebaut sein, dass Ihre Fachsprache, Ihre Qualitätsmaßstäbe, Ihre Rollen und Ihre Regeln kontrolliert abgebildet werden können. So wird aus einer individuellen Besonderheit keine proprietäre Sackgasse, sondern ein verständliches Domänenmodell, das mit Ihrem Unternehmen wachsen kann.