Der Weg des Geschäftsführers — Wissen

Ein Playbook vom Nichtverstehen zum kontrollierten Betrieb

Management-Zusammenfassung

Dieses Dokument ist der praktische Gegenpol zu den drei vorangehenden. Es beantwortet eine einzige Frage: Wie kommt ein Geschäftsführer, der KI heute nicht versteht, Schritt für Schritt dorthin, wo er sie kontrolliert einsetzt oder selbst baut — ohne sich rechtlich, finanziell oder operativ zu ruinieren?

Der Weg besteht aus sechs Etappen, die aufeinander aufbauen: verstehen (0), Kompetenz und Rollen aufbauen (1), Governance einführen (2), kaufen-oder-bauen entscheiden (3), ein erstes Projekt sicher starten (4), verantwortlich betreiben (5). Die Reihenfolge ist kein Zufall: Wer bei Etappe 4 (erstes Projekt) beginnt, ohne Etappe 2 (Governance) gelegt zu haben, baut auf Sand — und landet bei den Haftungsproblemen aus Dokument 1.

Drei Leitgedanken tragen das ganze Playbook:

Klein und reversibel schlagen groß und endgültig. Der sichere Einstieg ist ein eng umrissener, umkehrbarer Pilot mit klarer Vorher-Messung — nicht der große Wurf. Das gilt technisch, finanziell und rechtlich (Verzahnung mit Dokument 2: Reversibilität als Sicherheitsprinzip).

Der Geschäftsführer muss nicht rechnen lernen, sondern führen lernen. Er braucht kein Data-Science-Wissen, aber genug Verständnis, um gute von schlechten Vorschlägen zu unterscheiden, seine Dienstleister zu prüfen und Governance-Entscheidungen zu treffen. Genau dieses „Führungswissen ohne Technikstudium" ist das Ziel der Etappe 0.

Kontrolle wird eingebaut, nicht nachträglich aufgesetzt. Governance, Dokumentation und Freigaben sind keine Bürokratie, die man sich später leistet, sondern die Voraussetzung dafür, überhaupt sicher zu starten. Etablierte Rahmenwerke — der NIST AI Risk Management Framework und die Managementnorm ISO/IEC 42001 — liefern dafür fertige Strukturen, die man nicht neu erfinden muss.

Das Playbook endet mit konkreten Do/Don't-Regeln, Warnsignalen und Meilensteinen, an denen der GF ablesen kann, ob er auf Kurs ist.

Kernaussagen mit Einzelquellen

These 1 — Für KI-Governance gibt es fertige, anerkannte Rahmenwerke; niemand muss bei null anfangen. Der NIST AI RMF strukturiert Risikomanagement (Govern, Map, Measure, Manage); ISO/IEC 42001 ist die erste zertifizierbare Managementnorm für KI. Quellen: NIST, „AI Risk Management Framework (AI RMF 1.0)", Januar 2023, https://www.nist.gov/itl/ai-risk-management-framework (abgerufen 08/2026); ISO/IEC 42001:2023, „Information technology — Artificial intelligence — Management system", https://www.iso.org/standard/42001 (abgerufen 08/2026).

These 2 — Zwei KI-Act-Pflichten gelten bereits und gehören in jede erste Etappe: KI-Kompetenz der Mitarbeitenden (Art. 4, seit 02.02.2025) und das Verbot bestimmter Praktiken (Art. 5). Quelle: Art. 4, 5 und Umsetzungszeitplan VO (EU) 2024/1689, https://artificialintelligenceact.eu/implementation-timeline/ (abgerufen 08/2026).

These 3 — Für Betreiber von Hochrisiko-Systemen sind menschliche Aufsicht, Monitoring, Log-Aufbewahrung und Beschäftigten-Information konkret vorgeschrieben. Quelle: Art. 26 VO (EU) 2024/1689, https://artificialintelligenceact.eu/article/26/ (abgerufen 08/2026).

These 4 — Ob ein Unternehmen KI kaufen oder bauen sollte, ist selten „bauen": Für die meisten Fälle ist Konfigurieren geprüfter Standardlösungen der risikoärmere Weg. (Synthese; begründet in Kapitel 6.)

Die inhaltlichen Grundlagen zu Haftung (Dokument 1) und Autonomie (Dokument 2) werden hier vorausgesetzt und nur noch angewandt.

Etappe 0 — Verstehen ohne Technikstudium

Ziel dieser Etappe ist nicht Technikkompetenz, sondern Urteilskompetenz. Der Geschäftsführer muss so viel verstehen, dass er gute von schlechten Vorschlägen unterscheiden, einen Dienstleister prüfen und Risiken einordnen kann. Konkret genügt ein Verständnis von vier Dingen (Synthese):

Was heutige KI im Kern tut und was nicht: Sprachmodelle erzeugen plausible

Fortsetzungen auf Basis von Mustern; sie „wissen" nichts und können sicher klingen und falsch liegen (das Entzaubern der Reihe). Wer das verinnerlicht, versteht sofort, warum Kontrolle und Prüfung nötig sind.

Wo die Risiken sitzen: bei den Daten (Datenschutz, Vertraulichkeit), bei der

Verlässlichkeit der Ausgabe (Fehler, Erfindungen), bei der Autonomie (Dokument 2) und bei der Rechtslage (Dokument 1).

Was ein guter Anwendungsfall ist: wiederkehrend, gut beschreibbar, mit

überschaubarem Schaden bei Fehlern, mit messbarem Nutzen.

Woran man Substanz von Hype trennt: konkrete Zahlen statt Versprechen, Grenzen

offen benannt, überprüfbare Referenzen.

Praktisch heißt Etappe 0: selbst mit gängigen Werkzeugen an ungefährlichen, internen Aufgaben experimentieren (keine sensiblen Daten), zwei, drei kompakte, seriöse Quellen lesen, und die eigene KI-Kompetenz sowie die der Schlüsselpersonen aufbauen — Letzteres ist ohnehin Pflicht (Art. 4 AI Act). Der Fehler, den man hier vermeidet: Etappe 0 überspringen und gleich einen Dienstleister beauftragen, den man nicht beurteilen kann. (Empfehlung/Synthese; Rechtsgrundlage der Kompetenzpflicht: Art. 4 VO (EU) 2024/1689, https://artificialintelligenceact.eu/article/4/, abgerufen 08/2026.)

Etappe 1 — Kompetenz und Rollen aufbauen

KI ist kein reines IT-Thema und keine reine Chefsache — sie braucht benannte Zuständigkeiten. Auch im kleinen Betrieb sollten drei Rollen klar besetzt sein, notfalls in Personalunion oder extern (Synthese):

Verantwortung (der GF): trifft die Grundsatz- und Governance-Entscheidungen, gibt

Autonomiestufen frei, trägt die Haftung. Nicht delegierbar (Dokument 1, Kapitel 5).

Umsetzung (intern oder extern): wählt Werkzeuge aus, konfiguriert, betreut den

Betrieb. Kann an eine IT-Person oder einen Dienstleister gehen.

Kontrolle/Recht (Datenschutz, Justiziariat): prüft Rechtmäßigkeit, Datenschutz,

Verträge. Im kleinen Betrieb typischerweise extern (DSB, Kanzlei).

Intern vs. extern (Entscheidungshilfe, Synthese): Extern beginnen, wenn Wissen fehlt und der Bedarf noch unklar ist — das senkt das Risiko teurer Fehlgriffe. Intern aufbauen, sobald KI dauerhaft und breit genutzt wird — dann lohnt eigene Kompetenz, und die Abhängigkeit vom Dienstleister sinkt. Die häufigste Fehlentscheidung ist, dauerhaft kritisches KI-Wissen komplett auszulagern und dadurch dauerhaft urteilsunfähig zu bleiben.

Wichtig ist zudem, die Belegschaft früh mitzunehmen: Information, Schulung, klare Regeln, welche Werkzeuge erlaubt sind und welche Daten hineindürfen. Das erfüllt zugleich die Informationspflicht gegenüber Beschäftigten (Art. 26 AI Act) und die Beteiligungsrechte des Betriebsrats (Dokument 1, Kapitel 10) und verhindert die gefährlichste Grauzone: „Schatten-KI", bei der Mitarbeitende unkontrolliert private Tools mit Firmendaten füttern.

Etappe 2 — Governance einführen

Governance klingt nach Konzern, ist aber im Kern eine überschaubare Sammlung von Festlegungen, die auch ein Mittelständler leisten kann. Man muss sie nicht erfinden: Der NIST AI RMF (Funktionen Govern, Map, Measure, Manage) und die Norm ISO/IEC 42001 liefern die Struktur. (Quellen: NIST AI RMF 1.0, Januar 2023, https://www.nist.gov/itl/ai-risk-management-framework; ISO/IEC 42001:2023, https://www.iso.org/standard/42001; beide abgerufen 08/2026.)

Ein pragmatisches Minimalset für den Mittelstand (Synthese, an NIST/ISO angelehnt):

KI-Leitlinie: ein kurzes, verbindliches Dokument — welche Ziele, welche

Grundregeln, welche Werkzeuge erlaubt/verboten, welche Daten dürfen wohin, wer gibt frei.

Anwendungsregister: eine schlichte Liste aller KI-Anwendungen mit Zweck,

Datenarten, Rolle nach AI Act (Betreiber/Anbieter), Risikoklasse, Autonomiestufe, Verantwortlichem. Das ist die Grundlage für Überblick und Nachweis.

Risiko- und Freigabeprozess: vor Produktivstart eine kurze Prüfung (Datenschutz,

Recht, Sicherheit, Autonomiestufe) mit dokumentierter Freigabe (Dokument 1, Kapitel 6; Dokument 2, Kapitel 9).

Rollen und Eskalation: wer entscheidet, wer kontrolliert, wohin wird eskaliert,

wer wird bei Vorfällen informiert.

Kompetenz-/Schulungsnachweis: wer wurde wann geschult (Art. 4 AI Act).

Der entscheidende Punkt für den GF: Diese Governance ist die praktische Erfüllung seiner Organisationspflicht aus Dokument 1. Sie ist zugleich seine beste Verteidigung — und sie muss existieren, *bevor* das erste ernsthafte Projekt live geht, nicht danach.

Etappe 3 — Kaufen, Bauen oder Konfigurieren

Die Frage „kaufen oder bauen" ist meist falsch gestellt, weil sie eine dritte, oft beste Option unterschlägt: konfigurieren. Drei Wege stehen zur Wahl (Synthese):

Kaufen (Standardsoftware mit KI): fertige Lösung mit eingebauter KI (z. B. im

CRM, in der Buchhaltung, im Support-Tool). Geringstes technisches Risiko, schnellster Nutzen, aber wenig Differenzierung und Abhängigkeit vom Anbieter.

Konfigurieren (Standardmodell + eigene Daten/Regeln): ein geprüftes Basismodell

oder eine Plattform an den eigenen Bedarf anpassen, ohne selbst zu entwickeln. Für die meisten Mittelständler der beste Kompromiss aus Nutzen, Kontrolle und Risiko.

Bauen (Eigenentwicklung): lohnt nur, wenn KI zum Kern des Geschäftsmodells gehört,

ausreichend Kompetenz vorhanden ist und der Wettbewerbsvorteil die Kosten und Risiken (inkl. Anbieter-Rolle nach AI Act, Dokument 1, Kapitel 8.1) rechtfertigt.

Entscheidungsraster (Empfehlung): Standardproblem → kaufen. Standardproblem mit eigenem Zuschnitt und sensiblen Daten → konfigurieren. Kern-Differenzierung mit vorhandener Kompetenz → bauen. Im Zweifel die risikoärmere Stufe wählen und später hochskalieren. Eine oft übersehene Konsequenz: Wer baut oder ein System wesentlich verändert, kann selbst zum „Anbieter" mit strengeren Pflichten werden — das ist ein Kostenfaktor, kein Detail.

Bei jedem Weg gilt die Prüfung des Anbieters/der Lösung (Auswahlpflicht, Dokument 1, Kapitel 5): Wo werden Daten verarbeitet? Gibt es einen Auftragsverarbeitungsvertrag (Art. 28 DSGVO)? Wie sind Vertraulichkeit, Ausstieg und Datenrückgabe geregelt? Wie transparent ist der Anbieter über Grenzen und Risiken?

Etappe 4 — Das erste Projekt sicher starten

Jetzt wird gebaut oder eingeführt — aber klein, reversibel und gemessen. Ein bewährter Ablauf (Synthese):

Use-Case wählen: ein wiederkehrendes, klar umrissenes Problem mit überschaubarem

Schaden bei Fehlern und messbarem Nutzen. Nicht der spektakulärste Fall, sondern der sicherste Lern-Fall. Sensible Bereiche (Personal, Kredit, Gesundheit, Recht) meidet man im ersten Projekt.

Baseline messen: den Ist-Zustand ehrlich erfassen (Zeit, Kosten, Fehlerquote).

Ohne diese Vorher-Zahl lässt sich kein Erfolg belegen.

Rechtmäßigkeit klären und freigeben: Datenschutz, ggf. DSFA (Dokument 1,

Kapitel 7.3), Rolle/Risikoklasse nach AI Act, Vertraulichkeit, Mitbestimmung — dokumentiert freigeben.

Autonomiestufe festlegen: im Pilot bewusst niedrig (Vorschlag/Freigabe, Dokument

2), mit menschlicher Kontrolle und Not-Aus.

Pilot fahren, eng begrenzt: kleine Nutzergruppe, kurzer Zeitraum, enges Budget,

klare Abbruchkriterien.

Abnahme gegen die Baseline: hat es den erwarteten Nutzen gebracht, ohne

inakzeptable Risiken? Erst dann ausweiten — oder ehrlich beenden. Ein sauber beendeter Pilot, der sich nicht lohnt, ist ein Erfolg, kein Scheitern.

Der häufigste Fehler in dieser Etappe: den Pilot direkt in den Vollbetrieb kippen, ohne Abnahme, ohne Governance-Anschluss, ohne Skalierungs-Risikoprüfung (Dokument 2, Kapitel 8 — Häufigkeit mal Schaden).

Etappe 5 — Betrieb und Verantwortung

Ein produktives KI-System ist kein fertiges Projekt, sondern ein laufender Betrieb mit Pflichten (Synthese, gestützt auf Art. 26 AI Act):

Monitoring: Läuft das System noch im geprüften Rahmen? Verändert sich die

Qualität? Auffälligkeiten werden erkannt und behandelt.

Vorfallbehandlung: Es gibt einen Weg, Fehler/Schäden zu melden, zu stoppen

(Kill-Switch, Dokument 2) und zu korrigieren, und eine Meldung an Anbieter/Behörde, wo vorgeschrieben.

Nachweis: Logs und Dokumentation werden aufbewahrt (Art. 26 AI Act; Dokument 1,

Kapitel 6) — für Kontrolle, Fehleranalyse und den eigenen Haftungsschutz.

Pflege: Regeln, Freigaben und das Anwendungsregister werden aktuell gehalten;

neue Anwendungen durchlaufen denselben Prozess.

Review: in Abständen die Frage stellen, ob Nutzen, Risiko und Autonomiestufe noch

stimmen — und nachsteuern.

(Quelle zu den Betreiberpflichten: Art. 26 VO (EU) 2024/1689, https://artificialintelligenceact.eu/article/26/, abgerufen 08/2026.)

Do / Don't, Warnsignale, Meilensteine

Do (Synthese):

Klein, reversibel, gemessen starten; erst nach Abnahme ausweiten.
Governance und Dokumentation vor dem ersten ernsthaften Projekt aufsetzen.
Belegschaft und Betriebsrat früh einbinden; Schatten-KI durch klare, erlaubte

Alternativen verhindern.

Dienstleister und Lösungen aktiv prüfen (Daten, Verträge, Ausstieg, Grenzen).
Autonomie niedrig beginnen und nur bei Bewährung erhöhen.
Grenzen und Fehlversuche ehrlich dokumentieren — sie sind Lernkapital und

Haftungsschutz.

Don't (Synthese):

Nicht mit sensiblen Daten (Personal, Kunden, Gesundheit) im ersten Pilot starten.
Nicht kritisches KI-Wissen dauerhaft komplett auslagern.
Nicht ohne Baseline starten — sonst ist jeder ROI eine Behauptung.
Nicht die Rechtmäßigkeitsprüfung überspringen, weil „es ja nur ein Test ist".
Nicht menschliche Kontrolle behaupten, wo keine echte Eingriffsmacht besteht

(Scheinkontrolle, Dokument 2).

Nicht dem größten Versprechen folgen; dem überprüfbarsten folgen.

Warnsignale, dass es aus dem Ruder läuft (Synthese):

Niemand kann sagen, welche KI-Anwendungen im Haus laufen (kein Register).
Freigaben erfolgen in Sekunden und fast immer positiv (Scheinkontrolle).
Mitarbeitende nutzen private Tools mit Firmendaten.
Der Dienstleister kann Grenzen und Risiken seiner Lösung nicht klar benennen.
Es gibt keinen dokumentierten Weg, ein System zu stoppen.
Der Nutzen wird behauptet, aber nie gegen eine Baseline gemessen.

Meilensteine (Synthese):

GF und Schlüsselpersonen haben Grundverständnis und KI-Kompetenz (Etappe 0/1).
Rollen sind benannt; eine KI-Leitlinie existiert (Etappe 1/2).
Ein Anwendungsregister und ein Freigabeprozess laufen (Etappe 2).
Ein erster Pilot ist gegen eine Baseline sauber abgenommen (Etappe 4).
Mindestens ein System ist im kontrollierten, dokumentierten Regelbetrieb (Etappe 5).
Der Prozess wiederholt sich für neue Anwendungen — KI ist Routine, nicht Abenteuer.

Quellenliste und „schnell veraltend"

Quellen:

NIST, „AI Risk Management Framework (AI RMF 1.0)", Januar 2023 —

https://www.nist.gov/itl/ai-risk-management-framework (abgerufen 08/2026)

ISO/IEC 42001:2023, „Information technology — Artificial intelligence — Management

system" — https://www.iso.org/standard/42001 (abgerufen 08/2026)

VO (EU) 2024/1689 (AI Act): Art. 4 (KI-Kompetenz), Art. 5 (verbotene Praktiken),

Art. 26 (Betreiberpflichten), Umsetzungszeitplan — https://artificialintelligenceact.eu/implementation-timeline/ ; https://artificialintelligenceact.eu/article/4/ ; https://artificialintelligenceact.eu/article/26/ (abgerufen 08/2026); Verordnungstext EUR-Lex: https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32024R1689

Art. 28 DSGVO (Auftragsverarbeitung), VO (EU) 2016/679 —

https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32016R0679 (abgerufen 08/2026)

Querverweise: Dokument 1 (Rechts-Kompass) und Dokument 2 (Autonomie) dieser Serie.

Schnell veraltend (Refresh nötig):

Konkrete KI-Werkzeuge, Plattformen, Preise: mit „Stand MM/JJJJ" versehen, häufig prüfen.
AI-Act-Leitlinien und harmonisierte Normen nach dem 02.08.2026.
ISO/IEC-42001-Ökosystem: Zertifizierungspraxis, ergänzende Normen und Leitfäden

entstehen laufend.

NIST AI RMF: ergänzende Profile (u. a. generative KI) werden fortgeschrieben.
Marktübliche Kosten für Einführung/Betrieb: veralten schnell, nicht als feste Zahlen

im Buch zementieren.

*Ende Dokument 4.*