Wenn KI-Entscheidungen Abteilungsgrenzen überschreiten

In einem mittelständischen Unternehmen, gewachsen und ordentlich geführt, dürfen mehrere Teams ausprobieren, was KI im Arbeitsalltag taugt. Ein Team aus dem Betrieb lässt aus einer Sammlung von Notizen den ersten Entwurf des Wochenberichts schreiben. Jemand mit Sachverstand liest den Text weiterhin gegen, aber eine langweilige Pflicht kostet weniger Zeit und das Ergebnis sieht jede Woche gleich aus. Eine kleine Verbesserung, stabil genug, um den Reiz des Neuen zu überleben, und vermutlich alles, was dieses Team braucht.

Das Unternehmen hat daraus kein Programm gemacht und die Anwendung nirgends sonst ausgerollt. Das ist kein Mangel an Ehrgeiz. Nutzen an einer Stelle bleibt Nutzen, auch wenn er dort bleibt. Anders wird es, sobald KI Bereiche, Abläufe oder Systeme verbindet und die Entscheidungen darunter voneinander abhängen.

Nehmen wir an, ein anderes Team sieht das Ergebnis und möchte etwas Ähnliches. Was in einer Ecke des Hauses funktioniert hat, berührt nun gemeinsame Daten, gemeinsame Technik und einen Prozess, der jemand anderem gehört. Das ursprüngliche Team kann erklären, was es gebaut hat. Es kann und soll aber nicht für das ganze Unternehmen entscheiden, was daraus wird.

Interesse von außen macht aus einem lokalen Erfolg noch keinen Auftrag für das Gesamtunternehmen. Es bringt allerdings eine andere Frage in den Raum. Soll das Ergebnis seinen ursprünglichen Ort verlassen, was müsste mitreisen, und wer darf das entscheiden. Die Antwort kann sein, alles so zu lassen, wie es ist. Eine kleine Anwendung darf nützlich sein, ohne einen Lenkungskreis und eine Dreijahresplanung zu erben.

Das Experiment war nie dafür gedacht, diese Frage zu klären. Wenn der Versuch funktioniert hat, wer entscheidet dann, was daraus werden soll?

Die Entscheidung nach dem Experiment

Sobald ein Versuch funktioniert, kommt die Begeisterung meist vor der Klärung. Ein weiteres Team will Zugang. Die IT sieht einen Baustein, der sich wiederverwenden ließe. Das Risikomanagement fragt, ob die Kontrollen mitwandern. Das Controlling überlegt, wie ein größerer Business Case aussehen könnte. Nichts davon ist Bürokratie. Es ist die Organisation, die merkt, dass aus einem nützlichen Werkzeug etwas anderes werden könnte.

Es gibt mehrere gute Ausgänge. Die Anwendung bleibt beim Team, das sie gebaut hat. Ein Teil davon wird geteilt, etwa der Datenzugang oder das technische Fundament, während die Arbeit drumherum lokal bleibt. Ein breiterer Anwendungsfall rechtfertigt Investition und Skalierung. Der Versuch kann auch enden. Ein guter Test verdient sein Geld schon dann, wenn er zeigt, dass Wirtschaftlichkeit, Verlässlichkeit oder Aufwand keine zweite Runde tragen. Kein Unternehmen schuldet jedem klugen Prototyp eine Karriere.

Das Experiment selbst kann zwischen diesen Zukünften nicht wählen, und technischer Erfolg entscheidet die Sache ebenso wenig. Manchmal ist die Grenze wirklich technisch, und dann sollte man sie auch so behandeln. Das Modell ist für die Aufgabe nicht zuverlässig genug. Die nötigen Daten fehlen oder taugen wenig. Die Anbindung ist mühsam, die Kosten übersteigen den Nutzen, und das passende Können gibt es im Haus noch nicht. Keine noch so saubere Entscheidungslogik räumt solche Hindernisse weg.

Bessere Technik kann die Antwort verändern. Sie kann trotzdem nicht bestimmen, welche Arbeit sich ändern soll, wer für das Ergebnis geradesteht und welcher Nachweis eine weitere Investition rechtfertigt. Das bleiben organisatorische Entscheidungen, auch wenn der Gegenstand hochtechnisch ist.

Hier hilft die bekannte Unterscheidung zwischen Aktivität und Fähigkeit, solange man sie nicht überlädt. Ein gelungener Pilot zeigt, dass etwas in einer bestimmten Umgebung funktioniert. Betriebsfähigkeit verlangt mehr. Die Organisation muss sie besitzen, steuern, mit echter Arbeit verbinden, die Einführung begleiten und sie anpassen, wenn sich die Bedingungen ändern. Das kann der richtige Anspruch sein. Es ist nicht das Pflichtziel jedes Versuchs.

Die nächste Entscheidung beginnt deshalb beim Wert und der Relevanz des Problems, nicht beim Charme des Prototyps. Sie braucht eine Vorstellung von tragbarem Risiko, eine vernünftige Grenze für weitere Tests und Belege, die einen lokalen Erfolg von etwas Übertragbarem unterscheiden. Und sie braucht jemanden, der dieses Urteil fällen darf und für die Folgen einsteht.

Richtige Antworten auf verschiedene Fragen

Ein Unternehmen, das solche Entscheidungen öfter treffen will, reagiert sinnvoll. Es gibt der KI eine Richtung, wählt eine freigegebene Plattform, schreibt Regeln, baut eigenes Können auf und holt Partner dazu, wo Umsetzungskapazität fehlt. In einem regulierten Umfeld macht diese Grundarbeit das Handeln überhaupt erst möglich. Governance ist nicht die Abteilung, die den Spaß verdirbt. Sie schafft die Basis dafür, dass man weitergehen kann, ohne jedes Mal dieselbe Diskussion über Sicherheit, Daten und Haftung von vorn zu führen.

Diese Maßnahmen zeigen ernsthafte Absicht. Eine Strategie lenkt Aufmerksamkeit auf Probleme, die dem Geschäft wirklich etwas bringen. Gemeinsame Technik macht sicheren Zugang und Wiederverwendung leichter. Regeln geben Teams einen Rahmen, in dem sie arbeiten können, und Fachrollen wie erfahrene Partner machen aus Absicht etwas Baubares. Richtung, Leitplanken, Können und Umsetzung haben alle ihren Platz.

Nehmen wir ein reguliertes mittelständisches Unternehmen, dessen Kundenservice einen KI-Assistenten für die Bearbeitung von Anfragen vorschlägt. Die Idee passt zur Strategie. Die freigegebene Plattform trägt sie, die geltende Richtlinie deckt die Nutzung von Kundendaten ab, und ein Umsetzungspartner weiß, wie man so etwas baut. Auf den ersten Blick fehlt nichts.

Sobald der Vorschlag Richtung Betrieb wandert, wird es unübersichtlicher. Der Kundenservice erwartet schnellere Antworten und mehr Einheitlichkeit. Das Risikomanagement will sicher sein, dass heikle Fälle erkannt und geprüft werden. Die IT hätte lieber eine Anbindung, die andere Teams mitnutzen können, als eine weitere lokale Schnittstelle zum Pflegen. Das Controlling möchte wissen, welche Verbesserung die Investition trägt. Ein zentrales KI-Team kann all das koordinieren, aber der Serviceprozess und seine Wirtschaftlichkeit gehören ihm nicht.

Jede dieser Positionen ist vernünftig, und jede beantwortet einen anderen Teil der Frage. Die Strategie hat geholfen, ein aussichtsreiches Feld zu wählen, klärt aber nicht den Handel zwischen Tempo, Kontrolle und Investition. Die Plattform macht eine Lösung technisch verfügbar, ohne zu bestimmen, wie sich die Arbeit drumherum ändert. Governance legt fest, was erlaubt ist, und Erlaubnis ist weder Priorität noch Wert. Ein Partner kann die Anwendung liefern und trotzdem der Falsche sein, um festzulegen, wer im Haus für das Ergebnis verantwortlich bleibt.

Manche Organisationen verbinden solche Urteile längst über ihre Portfolio-, Governance- und Betriebsroutinen. Wo das trägt, fehlt kein Baustein. Der eigentliche Test lautet, ob diese Routinen die Perspektiven genau dann zusammenbringen, wenn entschieden werden muss, und ob dabei genug Klarheit über Eigentümerschaft und Belege entsteht, dass die Folgen im Alltag ankommen.

Das Unternehmen in diesem Beispiel hat vieles getan, was verantwortliche Führung nahelegt. Seine Schwierigkeit, falls eine auftaucht, liegt zwischen den Maßnahmen und nicht in einer von ihnen. Bevor eine weitere Richtlinie, Rolle oder Plattform dazukommt, lohnt es sich, einen einzigen Anwendungsfall durch alle Entscheidungen zu verfolgen, die zwischen einer erlaubten Möglichkeit und einem echten Nutzen liegen.

Zwischen Pilot und Wirkung

Diese Verfolgung legt offen, was als Vorschlag verborgen blieb. Der Kundenservice muss seinen Anspruch zuerst schärfen. Ein Assistent, der den Service verbessert, ist für eine Investitionsentscheidung zu vage. Antworten auf Standardanfragen entwerfen und heikle Fälle an erfahrene Mitarbeitende weiterleiten, das lässt sich prüfen.

Damit wird der Handel sichtbar. Der Wert liegt in kürzeren Bearbeitungszeiten und gleichmäßigeren Antworten. Das Risiko liegt dort, wo das System eine Anfrage falsch versteht, die falschen Kundendaten heranzieht oder souverän klingt, obwohl es nachfragen müsste. Der Versuch bekommt eine Grenze aus bestimmten Anfragetypen, menschlicher Prüfung und einer vereinbarten Qualitätsschwelle. Ein Test für eine Entscheidung, keine hübsche Vorführung.

Diese Belege müssen irgendwo auf das Portfolio treffen. Ein Pilot, der gemeinsame Kundendaten, eine wiederverwendbare Anbindung und dauerhafte Betreuung braucht, greift auf Geld, Aufmerksamkeit und Infrastruktur zu, die andere Vorhaben ebenfalls benötigen. Die Frage ist nicht mehr, ob die Idee zur KI-Strategie passt, sondern ob diese Variante die Mittel verdient, gemessen an erwartetem Nutzen, Risiken und Alternativen.

Wenn das Unternehmen weitergeht, reicht technische Eigentümerschaft nicht. Jemand im Kundenservice muss die Arbeit besitzen, sobald die Anwendung darin auftaucht. Mitarbeitende prüfen Antwortvorschläge, verwerfen sie, wenn nötig, und übernehmen die Fälle, die das System nicht kann. Jemand muss außerdem für Qualitätskontrolle und Prozessänderungen zuständig sein, wenn sich Kundenverhalten, Regeln oder Technik verschieben. Der Umsetzungspartner kann das Produkt betreuen, doch Verantwortung für den Kundenservice geht nicht per Vertrag auf ihn über.

Die scheinbar technische Frage nach dem Kontext wird nun sehr praktisch. Eine Antwort ist nur so verlässlich wie die Produktregeln, die Kundenhistorie und die Serviceleitlinien, auf die sie zugreift. Diese Quellen müssen erreichbar, aktuell und so gut verstanden sein, dass jemand für sie einstehen kann. Das ist oft erhebliche Arbeit. Wissen ist deshalb nicht die geheime Ursache jeder KI-Schwierigkeit. Das Modell kann trotzdem ungeeignet, die Anbindung zu fragil und der Preis zu hoch sein. Der Test führt allerdings in die Irre, wenn gepflegtes Material wenig mit den Informationen zu tun hat, mit denen im Alltag gearbeitet wird.

Auch Governance verändert an dieser Stelle ihren Charakter. Eine Richtlinie erlaubt den Anwendungsfall, doch der Betrieb verlangt genauere Urteile. Welche Anfragen brauchen menschliche Prüfung. Welche Fehlerquote ist in einem Entwurf tragbar, den eine Person freigibt. Wann geht Vorsicht vor Tempo. Solche Festlegungen machen aus einer allgemeinen Leitplanke die Arbeitsbedingungen, unter denen weitergelernt werden kann.

Dann kommt die Einführung, mit all der unaufgeräumten Wirklichkeit, die dieses Wort höflich verpackt. Schulung, Führung, Anreize und Vertrauen können jeweils die eigentliche Hürde sein. Eine saubere Kette früherer Entscheidungen ändert das Verhalten von Menschen nicht. Sie kann ihnen aber ein Werkzeug hinstellen, das zum Ablauf passt, klare Regeln dafür und jemanden, der reagiert, wenn es klemmt. Das Gegenteil verwandelt ein Gestaltungsproblem in etwas, das später wie Widerstand aussieht.

Nutzung allein sagt noch nicht, ob Wert entstanden ist. Mitarbeitende können das Werkzeug öffnen und die Arbeit trotzdem zweimal machen. Sie können Entwürfe rasch annehmen, während Korrektur und Nacharbeit an anderer Stelle wachsen. Belege müssen die Nutzung mit einem veränderten Prozess, tragbarer Qualität und dem ursprünglichen Rechenweg verbinden. Erst dann lässt sich sinnvoll entscheiden, ob die Anwendung wächst, sich ändert oder endet.

Zusammen betrachtet wählt das Unternehmen ein Problem, rahmt Wert und Risiko, setzt eine Testgrenze, verteilt Betriebsverantwortung, sorgt für verlässlichen Kontext, entscheidet über Anbindung und Arbeitsregeln, beobachtet die Einführung und beurteilt, was als Nächstes geschehen soll. Keine dieser Entscheidungen ist exotisch. Ihr Gewicht liegt darin, was jede der nächsten übrig lässt, besonders wenn die Verantwortung zwischen Geschäft, Risiko, IT, Daten, Betrieb und Finanzen wechselt.

Wo die Umsetzung wartet

Deshalb sehen getrennte Schwierigkeiten in Portfolio, Governance, Prozessverantwortung und Einführung nach und nach wie verschiedene Momente einer einzigen Kette aus. Ein Einwand liegt nahe. Sobald die Kette sichtbar ist, geht es dann noch um Architektur oder schlicht um Umsetzung?

Die Antwort kann tatsächlich Umsetzung heißen. Ein schwaches Lieferteam wird nicht stärker, weil seine Abhängigkeiten hübsch gezeichnet sind. Schlechte Anbindung, unzuverlässige Daten, dünne Besetzung und zögerliche Führung schaden dem Ergebnis weiterhin. Menschen müssen ihre Arbeitsweise trotzdem ändern. Und Architektur ist ein sehr respektables Versteck für praktische Probleme.

Nehmen wir an, der Serviceassistent besteht seinen Test. Die Antworten sind innerhalb der vereinbarten Grenze gut genug, die Mitarbeitenden sehen, wo er hilft, und das Unternehmen erwägt den täglichen Einsatz. Das Lieferteam kann die Anbindung bauen. Der Kundenservice kann den Ablauf vorbereiten. Keine dieser Handlungen klärt, ob die Anwendung in den Betrieb einziehen soll, den beide gerade vorbereiten.

Dieser Schritt braucht jemanden, der für den veränderten Serviceprozess geradesteht, nicht nur für die Software. Er braucht Belege, die den Zugriff auf gemeinsame Kundendaten und die dauerhafte Betreuung rechtfertigen. Die Risikogrenze muss an einem zähen Dienstagnachmittag halten und nicht nur im Regelwerk. Wenn schnellere Bearbeitung die Servicequalität zu drücken beginnt, muss jemand befugt sein, diesen Konflikt zu entscheiden. Und Erfahrungen aus dem laufenden Betrieb müssen irgendwohin führen. Sie sollten die Anwendung ändern, ausweiten oder beenden können.

Das sind keine Aufgaben, die eine Lieferorganisation nach dem Start improvisieren sollte. Sie entschuldigen ebenso wenig einen verpassten Termin oder eine fehlerhafte Schnittstelle. Ist die Anbindung zu spät, gehört sie als verspätete Anbindung gesteuert. Wartet das Team allerdings auf eine Entscheidung, für die sich niemand klar zuständig fühlt, wirkt der Appell zu mehr Umsetzungstempo etwas hohl.

Manche Organisationen verbinden diese Entscheidungen bereits über Portfolio, Governance, Betriebsmodell und Transformationspraxis. Die Regelungen dürfen unvollkommen sein und die Sprache ganz gewöhnlich. Entscheidend ist, dass Investition, Betriebsverantwortung und Risiko geklärt sind, bevor ein Team loslegen soll, und dass sie neu betrachtet werden, wenn sich die Faktenlage ändert. Ein solches Unternehmen braucht keine neue Funktion und kein besonderes Etikett.

Entscheidungsarchitektur

Was aber, wenn die Umsetzung immer wieder stockt, weil niemand die Entscheidungen gestaltet hat, von denen sie abhängt?

Wo bedeutende Entscheidungen wiederholt voneinander abhängen, nenne ich es Entscheidungsarchitektur, wie eine Organisation sie über Bereichsgrenzen und über die Zeit verbindet. Das steht nicht in Konkurrenz zur Umsetzung. Es gibt der Umsetzung Entscheidungen, mit denen sich arbeiten lässt, Verantwortliche, die ansprechbar bleiben, und einen Weg zurück, wenn die Erfahrung etwas anderes nahelegt.

Der Begriff verdient etwas Genauigkeit, schon weil Architektur die Angewohnheit hat, gewöhnliches Management bedeutsamer klingen zu lassen, als es ist. Es geht darum, was entschieden wird, wer entscheiden darf, welche Belege die Wahl verlangt, in welcher Reihenfolge entschieden werden muss und wie Erfahrung aus dem Betrieb den weiteren Verlauf verändert.

Das ist meine eigene Zusammenschau und nicht der Name einer etablierten Managementdisziplin. Entscheidungsrechte, Belege und Rückkopplung sind lange bekannt. Der nützliche Unterschied liegt darin, ihre gegenseitige Abhängigkeit als Gegenstand der Gestaltung zu behandeln. Eine gute Entscheidung an einer Stelle kann anderswo Ärger machen, wenn die Folgen ohne Eigentümer, Budget und Weg zur Revision ankommen.

Zurück zum Serviceassistenten. Eine Portfolioentscheidung, ihn über den Pilot hinauszuführen, ändert die Anforderungen an gemeinsame Technik und Anbindung. Das verschiebt den Kostenfall und die Belege, die vor weiterer Investition nötig sind. Eine Entscheidung über den Zugriff auf Kundendaten ändert das Betriebsrisiko, was wiederum den Ablauf, den Punkt der menschlichen Prüfung und den Lernbedarf der Mitarbeitenden betrifft. Die Entscheidungen tun Verschiedenes und reisen doch gemeinsam. Jede für sich in einem eigenen Termin gut zu treffen, ist noch nicht dasselbe wie Stimmigkeit.

Entscheidungsarchitektur ist deshalb keine weitere Governance-Schicht. Governance kann ihr natürliches Zuhause sein. Ein Betriebsmodell verteilt die Entscheidungsrechte. Unternehmensarchitektur verbindet technische Abhängigkeiten mit geschäftlichen Entscheidungen, und Transformationsmanagement trägt Prüfpunkte und Gelerntes zurück ins Portfolio. Wer das mit vorhandenen Mitteln schafft, braucht kein neues Büro, kein zusätzliches Gremium und kein größeres Vokabular. Der Terminkalender übersteht das Jahr vermutlich auch ohne eine weitere Regelrunde.

Manche Organisationen unterscheiden bereits sauber zwischen einer lokalen Anwendung, einer geteilten Fähigkeit und einer Festlegung für das ganze Unternehmen. Sie belassen Entscheidungen bei Menschen, die nah genug an der Arbeit sind, und machen die Übergaben ausdrücklich, sobald gemeinsame Daten, Technik, Risiko oder Geld ins Spiel kommen. Erfahrung aus dem Betrieb verschwindet nicht in einem Nutzenbericht. Sie kann den Ablauf ändern, die Leitplanken anpassen, eine breitere Nutzung begründen oder die Anwendung stoppen. Unsicherheit verschwindet dadurch nicht, sie bekommt nur einen brauchbaren Ort.

Führung ohne Zentralisierung

Nichts davon macht technische und wirtschaftliche Grenzen zweitrangig. Schlechte Daten machen die Anwendung unzuverlässig. Die Anbindung kann schwerer sein als gedacht. Können ist knapp, das Modellverhalten bleibt womöglich ungeeignet, und die Rechnung geht nicht auf, sobald der Dauerbetrieb eingepreist ist. Entscheidungsarchitektur repariert das nicht und garantiert kein gutes Ergebnis. Sie klärt, wer diese Dinge beurteilt, gegen welche konkurrierenden Ziele und ab wann die Antwort den Kurs ändern sollte.

Sobald Entscheidungen enger zusammenhängen, entsteht leicht der Reflex, sie nach oben zu ziehen. Zentralisiert man alles, genehmigt die Unternehmensspitze Dinge, die sie aus der Distanz nicht beurteilen kann. Die Aufgabe besteht nicht darin, mehr zu entscheiden. Sie besteht darin, dafür zu sorgen, dass verteilte Entscheidungen dort zusammenkommen, wo ihre Folgen zusammenkommen.

Noch einmal der Serviceassistent. Solange er lokal bleibt, kann das Serviceteam beurteilen, ob er hilft, wie Kolleginnen und Kollegen ihn nutzen sollen und wann geprüft werden muss. Sobald er auf gemeinsame Kundendaten, gemeinsame Infrastruktur und einen Ablauf über mehrere Bereiche zugreift, ändert sich etwas. Die operative Entscheidung darf bei den Menschen nah an der Arbeit bleiben, aber die Übergabe kann nicht länger aus einer technischen Spezifikation und einer hoffnungsvollen Termineinladung bestehen.

Das veränderte Serviceergebnis braucht einen anerkannten Eigentümer. Weitere Investitionen brauchen Belege, die das Unternehmen für gut genug hält, und die Kosten brauchen ein Zuhause, wenn das Projektbudget ausläuft. Risiko muss jemand akzeptieren, der dazu befugt ist, und nicht das Team, das es zufällig zuerst bemerkt. Wenn Tempo, Servicequalität und Kontrolle auseinanderlaufen, braucht es einen legitimen Weg, den Konflikt zu entscheiden. Nichts davon muss auf dem Tisch der Geschäftsführung landen. Dafür zu sorgen, dass es an einer passenden Stelle landet, bleibt Führungsaufgabe.

Vieles davon kann ein Unternehmen längst über Portfolio, Governance, Betriebsmodell und gewachsene Praxis abdecken. Diese Mechanismen müssen nicht Entscheidungsarchitektur heißen und nicht überall gleich aussehen. Ein Bereich braucht strengere Kontrollen als ein anderer. Eine nützliche Anwendung bleibt lokal, während eine andere den Zugang zu gemeinsamer Infrastruktur verdient. Stimmigkeit verlangt keine Einheitlichkeit. Sie verlangt, gewollte lokale Freiheit von einer Verantwortungslücke zu unterscheiden, die aus Versehen entstanden ist.

KI nimmt der Führung das Urteil nicht ab. Je weiter sie in die Organisation reicht, desto mehr Urteil liegt bei Führungskräften, Fachleuten und Teams über eine größere und stärker verflochtene Fläche. Diese Menschen brauchen Spielraum. Sie brauchen ebenso Entscheidungen von anderswo, die mit genug Eigentümerschaft, Belegen und Befugnis ankommen, um handeln zu können.

Die Unternehmensspitze verantwortet damit vor allem die Bedingungen, unter denen Urteil verteilt wird. Sie muss dafür sorgen, dass Entscheidungen an den Grenzen der Organisation aneinander anschließen und dass Erfahrung aus dem Betrieb zu breiterer Nutzung, einem Kurswechsel oder einem Ende führen kann. Diese Fähigkeit gibt es womöglich längst, still und ohne neues Gremium. Die Führungsfrage bleibt trotzdem.

Haben wir ein Entscheidungssystem gebaut, in dem sich Urteil verteilen lässt, ohne dass sich Verantwortung auflöst?

Eine lokale KI-Anwendung darf genau das bleiben und trotzdem etwas wert sein. Ein Unternehmen kann starke Governance, gute Teams und eingespielte Routinen haben, die Entscheidungen ohne besonderes Etikett verbinden. Die Führungsfrage beginnt, wenn eine Anwendung ihren ursprünglichen Ort verlässt und eine Entscheidung die Bedingungen für die nächste verändert. An dieser Grenze wandern Entscheidungen über gemeinsame Daten, Geld, Risiko, Technik und Betriebsverantwortung durch verschiedene Teile des Hauses. Sie dürfen verteilt bleiben, solange sie mit genug Zusammenhang und Befugnis ankommen und es einen Weg zurück gibt, wenn die Erfahrung das Urteil ändert.

Je weiter KI in die Organisation reicht, desto mehr verschiebt sich die Verantwortung der Führung hin zu den Entscheidungen, durch die aus technischer Möglichkeit eine verantwortete Betriebsfähigkeit wird. Der brauchbarste Test ist deshalb ein praktischer. Wo überschreitet eine KI-Entscheidung eine Organisationsgrenze, ohne dass Eigentümerschaft, Belege und Verantwortung mitgehen?