These: 50 % Developer auf Claude ohne Scale-Governance

Wenn Barclays erwartet, dass die Hälfte der Developer-Population bis Ende 2026 mit Claude Code arbeitet, dann ist das keine Tool-Nachricht. Es ist eine Betriebsfrage. Ohne Owner, ohne Audit, ohne Aufsicht und ohne einen Scale-Rahmen entsteht Shadow-IT mit einem Frontier-Modell. Ich nenne das eine Governance-Lücke, und die ist kein Detail.

Klartext: Der Modellzugang ist heute nicht der Engpass. Ihn bekommt jeder, der einen Vertrag unterschreibt. Es scheitert an dem, was danach kommt. Wer die Hälfte seiner Entwicklerinnen und Entwickler auf Frontier-Code loslässt und keine Rollen benennt, bekommt Shadow-IT mit besserem Autocomplete.

Schluss damit, Modellzugang mit Betrieb zu verwechseln. Das ist meine redaktionelle These, kein Zitat von Anthropic oder Barclays. Die Meldung selbst ist an vielen Stellen vorsichtiger, als es die Schlagzeile vermuten lässt. Wir bei digital-magazin.de lesen sie deshalb Satz für Satz, mit allen Qualifiern.

Barclays rollt Claude aus, der Zugang ist nicht der Engpass

Die Quelle ist eine Meldung von Anthropic vom 1. Oktober 2026. Nachzulesen ist sie bei Anthropic News unter „Barclays scales Claude“. Alles Folgende ist Angabe von Anthropic oder Barclays. Gemessen haben wir nichts.

Barclays, die britische Universalbank, erweitert demnach die strategische Zusammenarbeit mit Anthropic. Sichere Enterprise-KI soll über die globalen Operations der Bank integriert werden. Claude soll sich über die Bank ausbreiten, um Softwareentwicklung zu beschleunigen, Legacy-Systeme zu modernisieren und die operative Effizienz zu verbessern.

Das sind Ziele. Keine gemessene Ersparnis. Die Meldung nennt dazu keine Zahl, und ich erfinde auch keine.

Dann kommt die Marke, um die es hier geht. Barclays erwartet, dass die Adoption von Claude Code bis Ende 2026 die Hälfte der Developer-Population erreicht. Im Jahr 2027 soll sie auf eine Mehrheit der Software-Ingenieurinnen und Software-Ingenieure steigen. Beachten Sie die Wortwahl. Erst steht dort „Developer-Population“, dann „Mehrheit“ der Software-Ingenieurinnen und -Ingenieure.

Das ist nicht dasselbe. Eine Developer-Population kann mehr Rollen umfassen als Software-Ingenieurinnen im engeren Sinn. Und „Mehrheit“ heißt: mehr als die Hälfte. Wie viel mehr, sagt die Meldung nicht. Ich rechne es nicht in eine Zahl um.

Warum das zählt? Weil sich Verantwortung nicht an einer Schlagzeile festmachen lässt. Wer wissen will, wer was nutzt, braucht saubere Gruppen. Sonst zählt jeder etwas anderes.

Hand aufs Herz: Die Frage ist nicht, ob eine Bank dieser Größe Zugang zu einem guten Modell bekommt. Die Frage ist, wer am Montagmorgen dafür geradesteht, was daraus im Code landet.

Dazu schweigt die Meldung. Das ist kein Vorwurf an Barclays. Eine Pressemeldung ist kein Betriebshandbuch. Aber wer sie als Blaupause liest, sollte wissen, was in der Blaupause fehlt.

Genau an dieser Stelle setzt die Governance an, die ich meine: der Scale-Rahmen. Gemeint ist keine Formel aus der Meldung, sondern mein Arbeitsbegriff für die Summe aus Owner, Audit, Aufsicht und Freigabe. Barclays beschreibt ihn nicht im Detail, und Claude kommt in der Meldung als Werkzeug vor, nicht als geregelter Betriebsgegenstand. Eine Governance, die nur auf der Folie existiert, schützt weder Barclays noch die Kundschaft.

Was Claude im Haus schon tut

Barclays startet nicht bei null. Der Colleague Knowledge Assistant ist laut Meldung seit 2025 live. Er hilft Mitarbeitenden von Barclays UK, Informationen zu finden, während sie über 20 Millionen UK-Retail-Kundinnen und -Kunden unterstützen.

Technisch läuft Claude dabei über eine Retrieval-Augmented-Generation-Architektur. Auf Deutsch: Das Modell antwortet nicht aus dem Gedächtnis, sondern greift auf hinterlegte Wissensbestände zu und formuliert daraus. Das ist ein sinnvoller Aufbau für Auskünfte. Er verschiebt aber die Qualitätsfrage. Die Antwort ist nur so gut wie der Bestand dahinter.

Mehr als 16.000 Kolleginnen und Kollegen haben den Assistenten laut Meldung angenommen. Er hat über eine Million Suchen bearbeitet. Das Ergebnis, wie die Meldung es beschreibt: schnellerer Zugriff auf Information und schnellere Unterstützung. Eine Prozentzahl gibt es nicht. Ich liefere auch keine.

Ich finde diesen Fall deutlich aufschlussreicher als die Developer-Marke. Hier sitzt eine Technik mitten im Kundenkontakt. Jemand fragt, das System antwortet, ein Mensch gibt die Auskunft weiter. Dazwischen liegen mehrere Stellen, an denen etwas schiefgehen kann.

Wer pflegt den Wissensbestand? Wer merkt, wenn eine Antwort veraltet ist? Wer sieht, dass eine Auskunft falsch war, bevor die Kundin sie bekommt? Die Meldung beantwortet das nicht. Sie muss es auch nicht. Ein Institut, das Ähnliches plant, muss es schon.

Für den Assistenten heißt Governance zuerst: Inventur. Welche Wissensbestände hängen an Claude, wer hat sie freigegeben, und für welchen Zweck? Die Freigabe des Modells ist nicht die Freigabe der Nutzung. Barclays kann Claude für Auskünfte zulassen und trotzdem je Wissensbestand neu entscheiden müssen, ob er in den Kundenkontakt darf. Ohne diese Governance wächst der Bestand, und niemand weiß mehr, woraus der Assistent eigentlich antwortet.

Fünf Angaben, und keine ist eine Rangliste

Bis hierhin sind fünf Größen aufgetaucht: das Claude-Code-Ziel von 50 Prozent, über 16.000 Mitarbeitende am Assistenten, mehr als eine Million Suchen, über 20 Millionen UK-Retail-Kundschaft und rund 120.000 E-Mails pro Tag in Global Markets. Die letzte Zahl behandeln wir im nächsten Abschnitt genauer. Die Grafik fasst alle fünf zusammen.

Wichtig: Das sind verschiedene Einheiten. Ein Prozentziel, eine Zahl Mitarbeitender, eine Zahl Suchen, eine Zahl Kundschaft, eine Zahl E-Mails pro Tag. Das ist keine Rangliste. Die 20 Millionen sind nicht „mehr Erfolg“ als die 50 Prozent. Sie beschreiben nur, wessen Kundschaft im Support-Kontext betroffen ist, nicht was die Technik erreicht hat. Wir bei digital-magazin.de haben diese Werte nicht gemessen. Es sind Angaben aus der Meldung.

Auch die Qualifier tragen Gewicht. „Über“, „mehr als“, „rund“: Das sind keine Rundungsgesten, das ist die Genauigkeit der Quelle. Wer daraus glatte Zahlen macht, fälscht leise.

Genau das passiert in der Meldung selbst, und zwar auf interessante Weise. Paul Smith, Chief Commercial Officer bei Anthropic, wird sinngemäß so wiedergegeben: Claude helfe 16.000 Kolleginnen und Kollegen von Barclays, sortiere 120.000 E-Mails am Tag und werde bis 2027 in den Händen der meisten Ingenieurinnen und Ingenieure von Barclays sein.

Vergleichen Sie das mit dem Nachrichtentext. Dort steht „mehr als 16.000“, Smith sagt 16.000. Dort steht „approximately 120.000“, bei Smith sind es 120.000. Und die 50 Prozent bis Ende 2026 stehen im Nachrichtentext, nicht in Smiths Satz. Er sagt „die meisten“ bis 2027.

Ist das ein Skandal? Nein. Es ist die normale Verdichtung eines Zitats. Aber es zeigt, wie schnell aus einem Qualifier eine Behauptung wird. Und es zeigt, warum ein Institut intern mit eigenen, sauber definierten Zahlen arbeiten sollte, nicht mit der Version, die sich am besten zitieren lässt.

Auch hier gilt: Eine Governance, die mit Zahlen arbeitet, muss die Einheit festlegen. Wer bei Barclays die Developer-Population definiert, definiert zugleich, wer unter die Governance fällt. Ein Scale-Rahmen, der den Code-Einsatz für die Hälfte freigibt, braucht eine Liste der Rollen, nicht nur eine Quote. Die Governance beginnt bei der Zählweise.

Global Markets und die Poststrecke

Der zweite Einsatz ist unspektakulärer und gerade deshalb interessant. In Global Markets klassifizieren Claude-Modelle eingehende E-Mails, reichern sie an und bestimmen die passende Bearbeitungsroute. Ziel laut Meldung: Anfragen werden priorisiert und enthalten die nötigen Informationen.

Die Plattform verarbeitet rund 120.000 E-Mails pro Tag und senkt laut Meldung die manuelle Handhabung. Wieder ohne Prozentzahl. Die Quelle sagt „approximately“, deshalb schreibe ich „rund“.

Stellen Sie sich das als Poststelle vor. Früher sortierten Menschen. Jetzt sortiert ein Modell und entscheidet, wohin ein Vorgang geht. Das ist eine Entscheidung, auch wenn sie nach Routine aussieht.

Und hier fehlt in der Meldung einiges. Wer verantwortet die Route? Gibt es einen Owner für die Klassifikation, oder gehört sie „dem System“? Wer kann stornieren, wenn eine Mail falsch einsortiert wurde? Wer bemerkt es überhaupt? Eine Fehlroute ist leise. Es knallt nichts. Eine Anfrage liegt am falschen Ort, bis sich jemand beschwert.

Welches Audit sieht die Fehlroute? Ein Log, das niemand liest, ist kein Audit. Es ist Ablage.

Die Governance der Poststrecke braucht deshalb eigene Bausteine. Ein Owner für die Klassifikation, ein Audit der Fehlrouten, eine Aufsicht mit Ausnahmeliste. Wenn Claude Anfragen verteilt, muss die Governance festhalten, wer die Regeln der Verteilung ändern darf und wer die Änderung freigibt. Die Freigabe des Modells deckt das nicht ab. Die Bank hätte hier einen Fall, an dem sich jede Governance messen lassen muss, ohne dass ich Barclays eine konkrete Lücke unterstelle. Die Meldung schließt sie nur nicht.

Das ist der Kern meiner Skepsis. Eine saubere Demo zeigt den Normalfall. Governance beginnt dort, wo der Normalfall endet: bei der Mail, die zwei Anliegen enthält, bei der Beschwerde im Gewand einer Anfrage, bei der Frist, die niemand erkannt hat.

Governance, die Barclays nennt

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptPhotorealistic photo of a long empty conference table and one empty chair in a quiet office, no logos, no readable text, no watermarks, 16:9

Barclays nennt in der Meldung zu Claude drei Kontrollen: Governance, Security Controls und Human Oversight. Security Controls sind Sicherheitskontrollen. Human Oversight ist menschliche Aufsicht. Das ist die Angabe der Bank, keine Messung von uns.

Dazu zwei Stimmen, sinngemäß nach der Anthropic-Meldung, nicht als Gespräch mit uns.

Sinngemäß, als Angabe aus der Anthropic-Meldung: Das Maß einer Technologie sei ihre Wirkung auf Kundschaft, Mandantinnen und Mandanten sowie Kolleginnen und Kollegen. Die Ausweitung von Claude sei mehr als KI-Adoption. Es gehe darum, Prozesse neu zu denken, Erlebnisse zu verbessern und eine einfachere Organisation in einer sicheren und gut gesteuerten Umgebung zu schaffen. Menschen sollten weniger Zeit für Routine brauchen, Entscheidungswege würden gestrafft, Expertise komme dorthin, wo sie zählt.

Anne Marie Darling, Group Co-Chief Operating Officer, wiedergegeben nach der Anthropic-Meldung

Sinngemäß, als Angabe aus der Anthropic-Meldung: Softwareentwicklung und Cybersicherheit würden von immer fähigeren KI-Systemen umgeformt. Barclays bewege sich hin zu KI als zunehmend agentischer Fähigkeit, eingebettet in Bauen, Testen, Sichern und Betreiben. Claude helfe, Legacy-Plattformen zu modernisieren, die Softwarequalität zu verbessern und technische Expertinnen und Experten auf die komplexesten Aufgaben zu konzentrieren. Die Meldung sieht darin eine Chance.

Craig Bright, Group Co-Chief Operating Officer, wiedergegeben nach der Anthropic-Meldung

Beide Aussagen bleiben Claims. Darling spricht von einer gut gesteuerten Umgebung. Bright spricht davon, Claude in Bauen, Testen, Sichern und Betreiben einzubetten. Die Meldung nennt den Rahmen. Sie nennt nicht den Owner jedes Anwendungsfalls, nicht das Audit-Log und nicht, wie die Aufsicht im Alltag von Claude Code aussieht.

Der Ausblick der Meldung spricht von einem langfristigen Bekenntnis, von Produktivität, Resilienz und Ergebnissen für die Kundschaft, von Frontier-Fähigkeiten plus verantwortlicher Innovation bei Barclays. Das ist ein Claim. Ein Versprechen, keine Messung.

Ich lese beide Aussagen als Maßstab, nicht als Beweis. Sie sagen, was Barclays für nötig hält. Sie sagen nicht, wie die Umsetzung im Detail aussieht. Das müssen Sie bei Ihrem eigenen Vorhaben selbst klären. Neue Zahlen liefert die Meldung dazu nicht, und ich erfinde keine.

Interessant ist die Reihenfolge der drei Begriffe. Governance steht vorn. Sie ist der Rahmen, in dem Security Controls und Human Oversight erst Gestalt annehmen. Ohne Rahmen bleibt Sicherheit ein Wunsch und Aufsicht ein Zufall. Wer morgens zufällig in das Postfach schaut, übt keine Aufsicht aus. Aufsicht ist eine Aufgabe mit Namen, Zeit und Befugnis.

Shadow-IT mit besserem Autocomplete

Nun zur unbequemen Seite. Je besser Werkzeuge wie Claude werden, desto leichter wandern sie unbemerkt in den Alltag. Niemand muss einen Server bestellen. Ein Browserfenster genügt. Das ist Shadow-IT mit besserem Autocomplete: gleiche Dynamik, nur dass der Text, der entsteht, plausibler klingt und deshalb seltener hinterfragt wird.

Dazu gehört die Schattennutzung, die niemand inventarisiert. Sie entsteht nicht aus Bosheit. Eine Sachbearbeiterin will eine Antwort schneller formulieren, ein Analyst will eine lange Unterlage zusammenfassen. Beides ist nachvollziehbar. Doch was nicht erfasst ist, kann nicht geprüft werden, und was nicht geprüft wird, taucht im Risikobild nicht auf.

Das zweite Problem ist die Zuständigkeit. Es gibt KI im Unternehmen ohne benannten Owner, und das ist häufiger, als man denkt. Die IT betreibt, der Fachbereich nutzt, die Compliance fragt nach, und am Ende fühlt sich niemand verantwortlich. Bei einem Haus von der Größe Barclays wäre das ein Problem. Bei einem Mittelständler ist es genauso eines, nur kleiner und deshalb leichter zu übersehen.

Die Gegenmittel sind unspektakulär. Erstens eine Liste: Wer nutzt was, wofür, mit welchen Daten? Zweitens eine Regel, was erlaubt ist und was nicht. Drittens ein Weg, wie jemand einen neuen Einsatz anmeldet, ohne dafür drei Wochen zu warten. Ist der offizielle Weg zu zäh, nimmt man den inoffiziellen. Das ist keine Charakterschwäche, sondern Ökonomie.

Owner, Audit, Aufsicht

Drei Wörter tragen den größten Teil der Last. Der Owner entscheidet, der Audit prüft, die Aufsicht greift ein. Fehlt eines davon, kippt das Gerüst.

Der Owner ist eine Person, keine Abteilung. Er kennt den Einsatzfall, trägt das Risiko und darf Nein sagen. Der Audit ist mehr als ein Protokoll. Er beantwortet die Frage, ob das System tut, was die Freigabe verspricht, und zwar nachweisbar. Die Aufsicht schließlich ist der Mensch, der eine Ausnahme sieht und handeln kann, bevor aus der Ausnahme ein Muster wird.

Wichtig ist, dass Freigaben nicht pauschal gelten. Es gibt Freigaben, die am Einsatzfall hängen. Dasselbe Modell kann in einem Fall harmlos sein und in einem anderen heikel. Eine Zusammenfassung für den internen Gebrauch ist etwas anderes als eine Entscheidung, die einen Kunden betrifft. Wer die Freigabe am Modell festmacht statt am Einsatz, prüft das Falsche.

Für Banken kommt der Zeitfaden hinzu. Es gibt Freigaben, die eine Bank über den Lebenszyklus dokumentieren muss. Ein Modell ändert sich, Daten ändern sich, Prozesse ändern sich. Die Freigabe vom ersten Tag beweist wenig über den Betrieb im zweiten Jahr. Dokumentation heißt hier: Was wurde wann geändert, wer hat es genehmigt, was wurde danach beobachtet?

Wir bei digital-magazin.de halten das für das typische Muster, nicht für einen Einzelfall. Der Pilot läuft gut, ein Team ist begeistert, und dann soll es auf die Breite ausgerollt werden. In diesem Schritt geht die Governance verloren, weil sie für den Pilot-Maßstab gebaut war: ein paar Menschen, die sich kennen, kurze Wege, viel Augenmaß. Im größeren Rahmen trägt Augenmaß nicht mehr. Dann braucht es Verfahren.

Barclays nimmt Claude als Modell in den Betrieb, und das ist eine Entscheidung über ein Werkzeug. Sie sagt noch nichts darüber, ob jeder konkrete Einsatz bei Barclays tragfähig ist. Die Governance eines Modells prüft Anbieter, Datenwege und Vertragsfragen, die Governance eines Einsatzes fragt dagegen, wer was womit tut und wer dafür geradesteht. Beides wird gern vermischt. Wer die erste Freigabe für die zweite hält, hat Governance auf ein Häkchen reduziert. Es gibt aber drei Einsatzfälle, und jeder braucht eine eigene Antwort.

Nehmen Sie Claude Code für die Developer-Population. Das Modell schlägt Änderungen vor, am Ende steht ein Diff. Wer verantwortet ihn, bevor er in ein Bestandssystem von Barclays geht? Die Person, die ihn freigibt, das Review-Team oder niemand, weil der Vorschlag ja plausibel aussah? Gute Governance legt das vorher fest und nicht erst nach dem Vorfall. Ein Diff ohne benannte Person, die ihn gelesen hat, ist eine Behauptung. Bei Barclays darf daraus kein Code im laufenden Betrieb werden.

Der Colleague Knowledge Assistant arbeitet mit RAG, und das hat eine unbequeme Konsequenz. Die Antworten sind nur so gut wie der Bestand, aus dem sie geholt werden. Veraltete Richtlinien, doppelte Dokumente und verwaiste Seiten erscheinen mit der Selbstsicherheit eines fertigen Satzes. Claude kann das nicht ausgleichen. Governance muss deshalb benennen, wer den Bestand pflegt, wer Lücken meldet und wer Inhalte entfernt. Der Assistent klingt klar. Genau deshalb braucht das Vertrauen bei Barclays eine Person mit Namen dahinter.

Die E-Mail-Route in Global Markets ist der stillste der drei Fälle. Eine Fehlroute knallt nicht, sie landet einfach im falschen Postfach und fällt vielleicht erst Wochen später auf. Audit heißt hier nicht, dass ein Protokoll existiert. Es heißt, dass jemand die Stichprobe tatsächlich liest, Abweichungen notiert und Konsequenzen zieht. Ein Log, das niemand öffnet, ist Dekoration. Wer bei Barclays diese Aufsicht trägt, muss in der Governance stehen, mit Rhythmus und Eskalationsweg.

Bleibt die Inventur. Neben der offiziellen Claude-Instanz bei Barclays können Skripte, private Konten, Plugins in Entwicklungsumgebungen oder Team-Experimente laufen, die nie jemand angemeldet hat. Niemand muss dabei böse Absicht haben. Aber was Governance nicht sieht, kann sie weder prüfen noch verantworten. Deshalb beginnt jede ernsthafte Aufsicht mit einer Liste dessen, was tatsächlich im Einsatz ist, und nicht dessen, was genehmigt wurde. Wie wollen Sie etwas steuern, von dem Sie nicht wissen, dass es existiert?

Was ein Scale-Rahmen vor der Hälfte verlangt

„Vor der Hälfte“ heißt: bevor der Einsatz die Hälfte der vorgesehenen Bereiche erreicht hat. Dann ist noch Zeit, Strukturen zu setzen. Danach wird jede Korrektur teuer, weil sie laufende Abläufe stört. Ein tragfähiger Rahmen enthält mindestens diese fünf Punkte:

• Owner: Für jeden Einsatzfall gibt es eine benannte Person mit Entscheidungsbefugnis, auch für das Abschalten.
• Audit: Fehlrouten, Abweichungen und Änderungen werden regelmäßig von jemandem geprüft, der nicht selbst betreibt.
• Aufsicht: Menschen sehen Ausnahmen rechtzeitig und haben Zeit, Befugnis und Werkzeug, einzugreifen.
• Freigabe je Einsatzfall: Nicht das Modell wird einmal freigegeben, sondern jede Verwendung mit ihren Daten, Risiken und Grenzen.
• Inventur neben Claude: Eine laufende Übersicht erfasst auch das, was neben dem offiziellen Claude-Einsatz im Haus genutzt wird.

Diese Liste ist kurz, aber unbequem. Sie kostet Zeit in einer Phase, in der alle Tempo wollen. Dafür verhindert sie, dass aus einem guten Anfang ein Haftungsfall wird. Und sie macht den Unterschied sichtbar zwischen einem Einsatz, der wächst, und einem, der nur größer wird.

Zurück zur Poststrecke. Wenn Claude dort Anfragen verteilt, greifen alle fünf Punkte gleichzeitig. Der Owner verantwortet die Klassifikation. Der Audit zählt die Fehlrouten. Die Aufsicht sieht die Ausnahmeliste. Die Freigabe gilt für genau diesen Zweck, nicht für „Mails im Allgemeinen“. Und die Inventur zeigt, ob nebenbei noch jemand eigene Regeln baut. So sieht ein Scale-Rahmen aus, wenn man die Governance, die Barclays nur benennt, in den Alltag übersetzt.

Bei Barclays darf Governance für Claude kein Folienwort bleiben. Wenn die Hälfte der Developer-Population Claude nutzen soll, reicht keine Governance, die nur im Strategiepapier steht. Governance muss dort greifen, wo Entwicklerinnen und Entwickler morgens ihr Repository öffnen und Claude um Hilfe bitten. Das heißt: Jede Nutzung von Claude hat einen Owner, der benannt ist und die Entscheidungen verantwortet. Ohne Owner bleibt Governance eine Absicht, und eine Absicht besteht keine Prüfung.

Zweitens braucht Barclays ein Audit, das nachvollziehbar zeigt, was Claude getan hat und wer es freigegeben hat. Governance ohne Audit ist Behauptung, Audit ohne Governance ist Archiv. Drittens braucht es eine Aufsicht, die nicht erst nach dem Vorfall nachfragt. Die Aufsicht von Barclays muss Governance als laufende Praxis sehen, nicht als Dokument. Sagt Governance, wer Claude wofür einsetzen darf, muss sie auch sagen, was passiert, wenn jemand die Grenze überschreitet. Governance ist dann Arbeit im Alltag. Wer Claude in der Breite einführt, muss Governance vorher klären, nicht nachher erklären. Sonst entscheidet am Ende nicht Governance, sondern der Zufall. Gute Governance für Claude bleibt bei Barclays kurz und prüfbar.

Der Punkt ist:

Ein großer Einsatz von Claude ist nur so vertrauenswürdig wie die Struktur darum herum. Modelle werden besser, doch Verantwortung wird nicht automatisch mitgeliefert. Sie muss benannt, geprüft und beaufsichtigt werden, bevor der Betrieb sie einfordert.

Wer ist in Ihrem Haus heute der Owner für den Einsatzfall, der als Nächstes wachsen soll?