Gute KI-Beratung beginnt mit einer belastbaren Systemaufnahme

Wer zu früh Lösungen präsentiert, berät häufig ein angenommenes Unternehmen. Eine belastbare KI-Beratung macht zuerst sichtbar, wie Arbeit, Daten, Systeme, Entscheidungen und Verantwortung tatsächlich zusammenhängen.

Ein erstes Beratungsgespräch über KI produziert schnell eine Wunschliste: Wissensassistent, automatisierter Support, Dokumentenanalyse, Agententeam, Prognosen, Content-Produktion. Schon nach einer Stunde scheint eine Roadmap greifbar. Das Problem: Die Liste beschreibt Möglichkeiten, aber noch kein belastbares System. Prozessvarianten, Datenqualität, informelle Freigaben, Altsoftware, Mitbestimmung, Sicherheitsgrenzen und tatsächliche Entscheidungsmacht bleiben unsichtbar.

Gute Discovery bremst Innovation nicht. Sie verhindert, dass Geschwindigkeit in die falsche Richtung entsteht. Ihr Ergebnis ist weder eine Transkriptsammlung noch eine bunte Reifegradfolie, sondern ein überprüfbares Bild des Ist-Zustands und eine begründete Entscheidung darüber, welcher Use Case unter welchen Bedingungen weiterverfolgt wird.

Beratung beginnt mit einer Hypothese, nicht mit einer Antwort

Zu Beginn darf eine Beratung Hypothesen formulieren: „Die Suche nach gültigen Arbeitsanweisungen verursacht viel Nacharbeit" oder „Der Übergang zwischen Kundenanfrage und Fachprüfung könnte teilautomatisiert werden." Eine Hypothese ist nützlich, solange sie als vorläufig markiert bleibt.

Sie wird anschließend gegen mehrere Evidenzarten geprüft: Interviews, Prozessbeobachtung, Systemkonfiguration, Datenstichprobe, Richtlinien, Logs, Fehlertickets und bestehende Kontrollen. Keine einzelne Quelle besitzt automatisch Vorrang. Ein dokumentierter Sollprozess kann der Praxis widersprechen; ein Interview kann Ausnahmen vergessen; ein Log zeigt Verhalten, aber nicht immer den fachlichen Grund.

Die Beratungsakte trennt deshalb Behauptung, Beleg und Bewertung. Aus „Alle prüfen die Ausgabe" wird erst dann eine belastbare Aussage, wenn Rolle, Zeitpunkt, Kriterien, dokumentierte Abweichungen und technische Eingriffsmöglichkeit sichtbar sind. Wo Evidenz fehlt, steht nicht „erfüllt", sondern „ungeklärt".

Drei Karten beschreiben dasselbe Unternehmen

Eine gute Systemaufnahme baut mindestens drei miteinander verknüpfte Karten.

Die Arbeitskarte zeigt Auslöser, Schritte, Rollen, Wartezeiten, Ausnahmen und Entscheidungen. Sie beantwortet: Wie entsteht heute ein Ergebnis? Die System- und Datenkarte zeigt Anwendungen, Schnittstellen, Speicherorte, Quellen, Transformationen, Identitäten und Datenflüsse. Sie beantwortet: Welche technische Realität trägt den Prozess? Die Governance-Karte zeigt Eigentümer, Freigaben, Richtlinien, Risiken, Kontrollnachweise, Betroffene und Eskalationswege. Sie beantwortet: Wer darf entscheiden, wer trägt Verantwortung und wie wird Wirkung kontrolliert?

Getrennt bleiben diese Karten unvollständig. Ein Prozessschritt ohne Systembezug verschleiert Schatten-IT. Eine Datenbank ohne Arbeitskontext erklärt nicht, welche Entscheidung sie beeinflusst. Eine Richtlinie ohne technische Durchsetzung kann reine Absichtserklärung sein. Gemeinsame IDs verbinden Prozess, System, Datensatz, Use Case, Risiko und Kontrolle.

Interviews zeigen Wissen – und blinde Flecken

Interviews sind unverzichtbar, aber nicht neutral. Führungskräfte beschreiben häufig den Sollprozess, Fachkräfte die Ausnahmefälle und IT die offiziell betreuten Systeme. Beschäftigte können Workarounds normal finden und deshalb gar nicht erwähnen. Beraterinnen und Berater wiederum hören leichter das, was zu ihrer bevorzugten Lösung passt.

Deshalb werden Fragen rollenbezogen gestellt. Die Prozessverantwortung erklärt Ziel und Akzeptanzkriterien. Fachanwender zeigen reale Fälle. IT und Security erklären Integrationen, Identitäten und Grenzen. Datenschutz, Recht, Compliance und Interessenvertretung benennen Prüfpfade. Betroffene oder kundennahe Rollen machen Folgen sichtbar.

Gute Fragen verlangen Beispiele: „Zeigen Sie den letzten Fall, bei dem der Standardweg nicht funktionierte." „Welche Eingabe würde das Ergebnis unbrauchbar machen?" „Wann wurde eine Empfehlung zuletzt überstimmt?" „Welche Datei gilt als verbindlich, und woran erkennt ein System ihre aktuelle Version?" Solche Fragen erzeugen prüfbare Objekte statt abstrakter Zustimmung.

Datenfluss ist mehr als eine Pfeilgrafik

Ein Datenflussdiagramm wird wertvoll, wenn jeder Pfeil Bedeutung trägt. Woher kommen Daten? Wer kontrolliert ihre Qualität? In welcher Region und bei welchem Dienst werden sie verarbeitet? Welche Transformation findet statt? Was wird protokolliert? Welche Aufbewahrung gilt? Wohin fließt die Ausgabe, und welche Aktion löst sie aus?

Für generative und agentische Systeme kommen weitere Ebenen hinzu: Systemprompt, Retrieval-Quellen, Embeddings, Vektorspeicher, Toolparameter, Modellanbieter, Cache, Telemetrie und menschliche Rückmeldung. Ein Datenfeld kann im Frontend verborgen sein und trotzdem in Logs, Traces oder Backups landen.

Die Aufnahme dokumentiert nicht blind jedes Byte. Sie priorisiert Daten, die Zweck, Entscheidung, Sicherheit oder Rechte beeinflussen. Für sensible oder geschäftskritische Pfade werden Herkunft, Berechtigung, Version, Übertragung, Speicherung, Löschung und mögliche Offenlegung nachvollziehbar.

Der tatsächliche Entscheidungspfad ist entscheidend

Organisationen beschreiben KI gern als Assistenz. Das Wort sagt wenig über die reale Wirkung. Ein Vorschlag kann faktisch bindend sein, wenn Zeitdruck, Oberfläche, Kennzahlen oder Führungserwartung Abweichungen verhindern. Umgekehrt kann ein automatisierter Schritt geringes Risiko tragen, wenn er reversibel ist, keine Personen wesentlich betrifft und zuverlässig kontrolliert wird.

Die Systemaufnahme markiert deshalb jede Stelle, an der Output Priorität, Zugang, Preis, Leistung, Auswahl, Sicherheit oder Kommunikation verändert. Für jeden Punkt werden Entscheidungseigentümer, menschliche Autorität, erforderliche Information, mögliche Verzerrung, Rücknahmeweg und Beschwerdekanal erfasst.

„Human-in-the-Loop" wird nicht als Kontrollhäkchen akzeptiert. Geprüft wird, ob die Person Zeit, Kompetenz, Information, Unabhängigkeit und technische Befugnis besitzt, die Ausgabe sinnvoll zu hinterfragen und zu stoppen.

Reifegrad ohne Theater

Reifegradmodelle können Gespräche strukturieren, erzeugen aber leicht Scheingenauigkeit. Eine Organisation ist nicht pauschal „Stufe 3". Daten-Governance kann stark, Modellerprobung schwach und Vorfallmanagement nicht vorhanden sein. Ein Durchschnittswert verdeckt genau die Lücke, die ein Pilot zum Scheitern bringt.

Ein belastbares Assessment bewertet deshalb einzelne Fähigkeiten mit beobachtbaren Kriterien: Gibt es ein vollständiges Systemregister? Sind Eigentümer benannt? Werden Datenquellen versioniert? Existieren Akzeptanztests? Können Nutzer Fehler melden? Werden Änderungen neu bewertet? Ist ein Stop technisch möglich? Gibt es Nachweise aus echten Fällen?

Jede Bewertung enthält Evidenz, Geltungsbereich und Vertrauen. „Teilweise" wird erklärt. Unklarheit bleibt sichtbar. Der Zweck ist nicht, eine attraktive Punktzahl zu verkaufen, sondern Entscheidungen über Investitionen und Kontrollen vorzubereiten.

Use Cases werden nicht nur nach Nutzen sortiert

Ein guter Use-Case-Katalog unterscheidet Problem, Zielgruppe, erwarteten Nutzen, Entscheidungseinfluss, Datenreife, technische Machbarkeit, Integrationsaufwand, Risiko, Reversibilität und Evidenzbedarf. Begeisterung oder Modellneuheit sind keine Priorisierungskriterien.

Hoher Wert bei niedriger Datenreife ist kein schneller Gewinn. Niedriges Risiko bei fehlendem Eigentümer ist kein Pilot. Ein scheinbar kleiner Assistent kann teuer werden, wenn er zehn Systeme anbinden muss. Ein technisch anspruchsvoller Use Case kann dennoch geeignet sein, wenn er in einem engen, reversiblen und gut messbaren Rahmen getestet wird.

Priorisierung ist eine Portfolioentscheidung. Einige Ideen werden verworfen, einige benötigen Vorarbeiten, wenige erhalten einen Pilot. Zu jedem Kandidaten gehört ein „Warum jetzt?", ein „Warum nicht?" und ein Stop-Kriterium.

Vom Assessment zum kontrollierten Pilot

Ein Pilot ist keine verkleinerte Produktion. Er ist ein Experiment mit Entscheidungswert. Er prüft definierte Hypothesen unter begrenztem Scope und produziert Evidenz für Fortsetzung, Änderung oder Abbruch.

Vor dem Start werden Baseline, Testfälle, Qualitätsmetriken, Risikoschwellen, Nutzergruppe, Datenumfang, Laufzeit, Budget und Verantwortliche festgelegt. Neben Durchschnittsqualität zählen kritische Fehler, Gruppenunterschiede, falsche Sicherheit, Bedienverhalten und Aufwand der menschlichen Kontrolle. Ein Demoerfolg mit ausgewählten Beispielen genügt nicht.

Go-live ist ein eigenes Gate. Erst wenn Architektur, Datenschutz, Security, Betrieb, Schulung, Support, Überwachung und Rücknahme geklärt sind, wird aus dem Pilot ein Dienst. Die Entscheidung wird dokumentiert; Restunsicherheit verschwindet nicht hinter einer grünen Ampel.

KI-Kompetenz ist kontextbezogen

Artikel 4 des AI Act verlangt Maßnahmen für ein ausreichendes Maß an KI-Kompetenz unter Berücksichtigung von Wissen, Erfahrung, Einsatzkontext und betroffenen Personen. Eine allgemeine Einführung für alle erfüllt nicht automatisch jeden Bedarf.

Rollen brauchen unterschiedliche Fähigkeiten. Anwender müssen Grenzen, Datenregeln und Eskalation verstehen. Prozessverantwortliche benötigen Bewertungs- und Kontrollkompetenz. Entwickler brauchen Test-, Sicherheits- und Dokumentationspraxis. Führungskräfte müssen Risikoakzeptanz, Ressourcen und Verantwortlichkeit steuern. Kontrollfunktionen brauchen Zugriff auf technische Evidenz.

Die Systemaufnahme liefert dafür die Lernbedarfsanalyse. Schulung wird an reale Entscheidungen, Fehlermodi und Werkzeuge gebunden und durch Übungen überprüft – nicht nur durch Teilnahmebescheinigungen.

Die Grenze guter Beratung

KI-Beratung verbindet Technik, Organisation und Governance, darf aber fehlende Fachexpertise nicht simulieren. Sie kann Systeme und Datenflüsse dokumentieren, Pflichten-Schnittstellen markieren, Evidenz sammeln und Fragen für Rechts-, Datenschutz-, Security- oder Branchenexpertinnen vorbereiten. Die verbindliche Fachbeurteilung bleibt bei der zuständigen Rolle.

Diese Grenze erhöht den Wert der Beratung. Eine Rechtsprüfung wird schneller, wenn Zweck, Rollen, Daten, Entscheidungspunkte, Anbieterunterlagen und offene Fragen strukturiert vorliegen. Security kann konkrete Angriffsflächen statt abstrakte Produktnamen bewerten. Die Organisation erhält Entscheidungen statt widersprüchlicher Einzeldokumente.

Interessenkonflikte müssen ebenfalls sichtbar sein. Wer ein bestimmtes Tool verkauft, sollte dessen Auswahl nicht als neutrales Assessment darstellen. Annahmen, Bewertungsmethode, Einschränkungen und wirtschaftliche Beziehungen gehören in die Auftrags- und Ergebnisdokumentation.

Das Ergebnis ist ein Entscheidungs- und Umsetzungspaket

Eine belastbare Systemaufnahme endet mit einem zusammenhängenden Paket:

1. System- und Use-Case-Register mit Eigentümern und Status.

2. Verknüpfte Arbeits-, Daten- und Governance-Karten.

3. Evidenzregister mit Fakten, Quellen, Lücken und Vertrauen.

4. Risiko- und Kontrollregister mit Verantwortlichen.

5. Priorisiertes Use-Case-Portfolio mit Abbruchgründen.

6. Pilot-Charta mit Baseline, Tests, Grenzen und Gates.

7. Fachfragen und Übergabepakete für zuständige Prüfstellen.

8. Umsetzungsroadmap mit Abhängigkeiten und Review-Terminen.

Damit kann ein Unternehmen begründet entscheiden. Es weiß nicht nur, welche KI-Ideen attraktiv klingen, sondern welchen Zustand es besitzt, welche Evidenz fehlt, welche Kontrolle zuerst aufgebaut werden muss und welcher nächste Schritt reversibel ist.

Übungsblatt: Führe eine Mini-Systemaufnahme durch

Wähle einen realen oder geplanten KI-Use Case.

1. Formuliere drei Hypothesen über Problem, Nutzen und Risiko.

2. Benenne Interviewrollen und fordere je ein reales Beispiel an.

3. Zeichne Arbeits-, System-/Daten- und Governance-Karte.

4. Verknüpfe jeden wichtigen Claim mit Evidenz oder Lückenstatus.

5. Markiere Entscheidungspunkte und tatsächliche menschliche Autorität.

6. Bewerte Datenreife, Machbarkeit, Wirkung und Reversibilität getrennt.

7. Definiere Pilot-Baseline, Testfälle, Stop-Kriterien und Go-live-Gate.

8. Erstelle ein Übergabepaket für mindestens eine Fachstelle.

Alle Materialien zum Download – die Themenübersicht und das Übungsblatt:

Einordnung: Der Artikel beschreibt eine fachübergreifende Methode für Discovery, Systemaufnahme und Umsetzungsplanung. Sie ersetzt weder Rechtsberatung noch Datenschutz-, Informationssicherheits-, Mitbestimmungs- oder branchenspezifische Prüfungen. Standards und Frameworks werden als Orientierung genutzt; ihre Anwendung oder Zertifizierung ist nicht automatisch gesetzlich vorgeschrieben. Stand der redaktionellen Prüfung: 16. Juli 2026.