IBM Bob ist kein weiterer Codegenerator, der nach einer freundlichen Aufforderung eine Java-Klasse oder ein paar Zeilen COBOL erzeugt. IBM positioniert Bob als KI-gestützten Partner für den gesamten Software Development Lifecycle. Bob kann Quellcode analysieren, Dateien verändern, Kommandos ausführen, Tests unterstützen und über das Model Context Protocol, kurz MCP, externe Werkzeuge und Systeme einbeziehen.
Für Unternehmen, die Bob innerhalb der eigenen Entwicklung einsetzen, ist das bereits ein Governance-Thema. Für einen IT-Dienstleister kommt jedoch eine zusätzliche Ebene hinzu.

Denn plötzlich arbeitet die KI nicht mit dem eigenen Quellcode.

Sie arbeitet mit dem Quellcode eines Kunden.

Und damit ändern sich die Spielregeln.

Es geht nicht mehr nur darum, ob Bob guten Code erzeugt

Die erste Frage bei KI-gestützter Entwicklung lautet häufig: Wie gut ist der erzeugte Code?

Für einen Dienstleister ist das eigentlich erst die zweite oder dritte Frage.

Zuerst muss geklärt werden, ob und unter welchen Bedingungen Kundendaten, Kundenquellcode und Informationen über die Kundenarchitektur überhaupt durch ein solches System verarbeitet werden dürfen.

IBM beschreibt Bob als agentische Entwicklungsumgebung. Das bedeutet, dass Bob nicht lediglich Textvorschläge liefert. Je nach Freigabe kann das System Dateien lesen und verändern, Shell-Kommandos ausführen und über MCP mit externen Systemen kommunizieren. IBM selbst weist deshalb ausdrücklich darauf hin, Berechtigungen zu begrenzen, sensible Dateien auszuschließen und automatisch freigegebene Aktionen sehr vorsichtig einzusetzen.

Genau hier beginnt die besondere Verantwortung eines Dienstleisters.

Wer von einem Kunden Zugriff auf dessen Git-Repository erhält, erhält damit nicht automatisch die Erlaubnis, diesen Quellcode einem beliebigen KI-System zugänglich zu machen.

Kundencode ist nicht einfach nur „Input“

Quellcode gehört häufig zu den wertvollsten Informationen eines Unternehmens. Er dokumentiert Geschäftslogik, Sicherheitsmechanismen, Schnittstellen, Datenmodelle und mitunter Prozesse, die über Jahrzehnte entstanden sind.

Gerade bei Legacy-Anwendungen steckt im Code häufig wesentlich mehr Unternehmenswissen, als es auf den ersten Blick scheint.

Ein COBOL-Programm kann beispielsweise erkennen lassen, wie Kreditentscheidungen getroffen werden. Ein Java-Service beschreibt unter Umständen interne Preisberechnungen. Konfigurationsdateien können Servernamen, Systemstrukturen oder technische Benutzer enthalten.

Nicht alles davon sind personenbezogene Daten im Sinne der DSGVO. Vertraulich und geschäftskritisch können diese Informationen trotzdem sein.

Deshalb sollte der Einsatz von IBM Bob bei einem Dienstleister ausdrücklich Bestandteil der Vereinbarung mit dem Kunden sein. Das gilt besonders dann, wenn bestehende Geheimhaltungsvereinbarungen oder Entwicklungsverträge die Nutzung externer Cloud- oder KI-Dienste bislang überhaupt nicht berücksichtigen.

Ein Satz wie „Wir verwenden moderne Entwicklungswerkzeuge“ dürfte dafür kaum ausreichen.

„Wird nicht zum Training verwendet“ löst nicht alle Fragen

Bei generativer KI wird häufig zuerst gefragt, ob eingegebene Informationen zum Training zukünftiger Modelle verwendet werden.

Für IBM Bob gibt es hierzu eine wichtige Aussage: IBM erklärt, dass Prompts nicht für Trainingszwecke verwendet werden. Nach der aktuellen Dokumentation werden Prompts allerdings zeitweise zwischengespeichert, um die Inferenz zu unterstützen. IBM erfasst außerdem Nutzungsinformationen für Abrechnung und optional Telemetriedaten. Die Telemetrie enthält laut IBM keinen Quellcode und keine Prompts.

Das ist für Enterprise-Kunden zweifellos relevant.

Für einen Dienstleister ist die Prüfung damit aber noch nicht abgeschlossen.

Denn entscheidend ist nicht nur, ob Daten später zum Training verwendet werden. Entscheidend ist auch, wo sie während der eigentlichen Verarbeitung hingehen, wer daran beteiligt ist, wie lange Informationen gespeichert werden und auf welcher vertraglichen Grundlage dies geschieht.

Hinzu kommt eine Besonderheit von Bob: Nach der aktuellen IBM-Dokumentation kann der Anwender das zugrunde liegende Sprachmodell nicht selbst auswählen. Bob entscheidet abhängig von Aufgabe, Komplexität, benötigten Fähigkeiten, Kontextgröße und Kosten automatisch über das geeignete Modell.

Für die Bedienung ist das komfortabel.

Für einen IT-Dienstleister stellt es jedoch eine Governance-Frage dar. Wenn ein Kunde Vorgaben darüber macht, welche Modelle, Anbieter oder Verarbeitungsregionen für seinen Quellcode zulässig sind, muss sichergestellt werden, dass diese Anforderungen mit dem konkreten IBM-Bob-Vertrag und dessen technischer Bereitstellung vereinbar sind.

Diese Prüfung sollte vor Projektbeginn erfolgen und nicht erst dann, wenn der erste Entwickler das Kundenrepository in Bob geöffnet hat.

Auch die Vertragskette muss stimmen

Noch deutlicher wird die Situation, sobald personenbezogene Daten ins Spiel kommen.

Quellcode selbst ist nicht automatisch personenbezogen. Entwicklungsumgebungen enthalten aber regelmäßig Testdaten, Logdateien, Dumps, Beispieldatensätze, Tickets oder Konfigurationsinformationen, in denen personenbezogene Informationen vorkommen können.

Arbeitet ein Dienstleister bei der Verarbeitung solcher Daten weisungsgebunden für seinen Kunden, kann er datenschutzrechtlich als Auftragsverarbeiter tätig sein. Werden für diese Verarbeitung weitere Anbieter eingesetzt, können daraus zusätzliche Anforderungen an die Unterauftragsverarbeitung entstehen. Artikel 28 DSGVO sieht hierfür entsprechende vertragliche und organisatorische Anforderungen vor.

Deshalb sollte bei einem professionellen Einsatz nicht pauschal gefragt werden:

„Ist IBM Bob DSGVO-konform?“

Die bessere Frage lautet:

Welche Daten verarbeitet unser konkretes Projekt mit IBM Bob, in welcher Rolle tun wir das und welche Vertrags- und Verarbeitungskette entsteht dadurch?

Das klingt weniger spektakulär. Für einen Dienstleister ist es aber die wesentlich wichtigere Frage.

Jeder Kunde braucht seine eigene Sicherheitsgrenze

Technisch sollte sich dieselbe Denkweise fortsetzen.

Ein Entwickler, der heute für Kunde A und morgen für Kunde B arbeitet, sollte Bob nicht wie sein persönliches Universalwerkzeug behandeln, in dessen Kontext irgendwann Informationen aus zahlreichen Kundenprojekten zusammenlaufen.

Kundenprojekte benötigen getrennte Repositories, getrennte Arbeitsbereiche und klar definierte Zugriffsrechte.

IBM stellt dafür verschiedene Mechanismen bereit. Über .bobignore lässt sich beispielsweise festlegen, auf welche Dateien Bob nicht zugreifen darf. IBM weist allerdings ausdrücklich darauf hin, dass .bobignore keine systemweite Sandbox darstellt. Die Datei begrenzt den Zugriff innerhalb des jeweiligen Workspace, ersetzt aber keine weitergehende Isolation.

Für sensible Kundenprojekte sollte deshalb das bekannte Prinzip gelten: Least Privilege auch für die KI.

Bob bekommt nicht alles, was theoretisch erreichbar ist, sondern nur das, was für die konkrete Aufgabe notwendig ist.

Das betrifft Dateien ebenso wie APIs, Datenbanken und externe Systeme.

Screenshot aus der IBM Bob for Z Enterprise Edition

MCP macht Bob mächtiger – und die Sicherheitsgrenze größer

Besonders interessant wird das beim Model Context Protocol.

MCP ermöglicht Bob den Zugriff auf zusätzliche Werkzeuge und Dienste. Damit kann aus einem Coding Assistant sehr schnell ein System werden, das beispielsweise mit einem Repository, einem Ticketsystem, einer Dokumentationsplattform oder anderen Entwicklungswerkzeugen kommuniziert.

Das eröffnet enorme Möglichkeiten.

Es erweitert aber gleichzeitig die Angriffs- und Berechtigungsfläche.

IBM empfiehlt deshalb selbst für MCP-Server Authentifizierung, verschlüsselte Kommunikation, Zugriffskontrollen und Auditing. Bei gemeinsam genutzten MCP-Servern sollen Aktionen eindeutig Benutzern oder Sitzungen zugeordnet werden können.

Für Dienstleister ist das ein entscheidender Punkt.

Ein MCP-Server, der für Kunde A freigegeben wurde, gehört nicht automatisch in die Entwicklungsumgebung von Kunde B. Auch technische Credentials sollten nicht projektübergreifend verwendet werden.

IBM empfiehlt ausdrücklich zeitlich begrenzte Tokens, delegierte Verfahren wie OAuth und eine möglichst geringe Berechtigung. Geheimnisse sollen weder in Prompts noch in für Bob zugänglichen Dateien abgelegt werden.

Eigentlich sind das klassische Security-Grundsätze.

KI macht sie nicht überflüssig. Sie macht ihre konsequente Umsetzung wichtiger.

Auto-Approve ist bequem. Im Kundenprojekt kann es teuer werden.

Agentische Entwicklungswerkzeuge leben davon, dass sie Aufgaben zunehmend selbstständig erledigen können.

Genau das erzeugt aber ein interessantes Spannungsfeld.

Je mehr Bestätigungsschritte abgeschaltet werden, desto produktiver fühlt sich die Arbeit an. Gleichzeitig sinkt die Zahl der Momente, in denen ein Mensch kontrolliert, was das System gerade tun möchte.

IBM bewertet automatische Freigaben für Dateiänderungen und die Ausführung von Kommandos selbst als risikoreich und empfiehlt, solche Funktionen nur in kontrollierten Umgebungen einzusetzen.

Für einen Dienstleister sollte deshalb gelten: Produktivitätsgewinne dürfen nicht dadurch entstehen, dass die Kontrollmechanismen des Kundenprojekts ausgeschaltet werden.

Ein Agent sollte beispielsweise nicht allein deshalb Produktionszugriff erhalten, weil dies technisch möglich ist.

Der Entwickler bleibt verantwortlich

Vielleicht ist das der wichtigste Punkt überhaupt.

IBM Bob ist kein Ersatz für Code Review, Architekturentscheidungen, Tests oder fachliche Abnahmen.

IBM fordert in seinen eigenen Security Guidelines ausdrücklich dazu auf, erzeugte Inhalte zu überprüfen und nicht davon auszugehen, dass KI-generierte Ergebnisse automatisch korrekt oder sicher sind.

Für einen IT-Dienstleister hat das noch eine weitere Dimension.

Der Kunde kauft am Ende keine Prompts und keine besonders beeindruckende Bob-Session.

Er kauft Software.

Damit bleiben dieselben Qualitätsanforderungen bestehen wie bei jeder anderen professionellen Entwicklung: Code Reviews, automatisierte Tests, Security Scans, Dependency Checks, nachvollziehbare Commits und definierte Freigabeprozesse.

Ein sinnvoller Grundsatz könnte daher lauten:

Bob darf Code erzeugen. Verantworten muss ihn weiterhin ein Mensch.

Auch der AI Act gehört inzwischen zum Thema

Seit dem 2. August 2026 ist der EU AI Act grundsätzlich anwendbar; einzelne Verpflichtungen galten bereits früher. Unternehmen, die KI-Systeme professionell einsetzen, müssen unter anderem das Thema AI Literacy berücksichtigen. Die Europäische Kommission beschreibt diese Verpflichtung ausdrücklich auch für Mitarbeiter und andere Personen, die im Auftrag eines Unternehmens mit KI-Systemen arbeiten.

Für einen Dienstleister bedeutet das mehr als eine einstündige Einführung unter dem Titel „Wie schreibe ich gute Prompts?“.

Entwickler müssen verstehen, welche Fähigkeiten Bob besitzt, welche Fehler auftreten können, welche Informationen eingegeben werden dürfen, wie Berechtigungen funktionieren und wann eine menschliche Überprüfung erforderlich ist.

Ein Entwickler, der Bob bedienen kann, ist noch lange kein Entwickler, der Bob verantwortungsvoll in einem Kundenprojekt einsetzen kann.

Nachvollziehbarkeit wird zum Teil der Leistung

Interessant sind deshalb auch die Enterprise-Funktionen von IBM Bob.

IBM bietet unter anderem eine zentrale Benutzer- und Seat-Verwaltung, Teams, Kostenkontrollen und Enterprise-Administration. Darüber hinaus können Aktivitätsprotokolle zu Authentifizierungs- und administrativen Vorgängen bereitgestellt werden. Enterprise-Instanzen lassen sich außerdem in unterschiedlichen Regionen anlegen.

Für einen Dienstleister sind solche Funktionen nicht nur Komfortmerkmale.

Sie können Bestandteil eines Governance-Modells werden.

Wer durfte Bob einsetzen? Welches Team arbeitete für welchen Kunden? Welche Premium-Funktionen waren freigeschaltet? Welche MCP-Verbindungen waren zulässig? Welche Regeln galten für den Workspace?

Solche Fragen dürften künftig genauso selbstverständlich werden wie heute Fragen nach Git-Berechtigungen oder CI/CD-Pipelines.

Die eigentliche Veränderung findet deshalb nicht im Editor statt

IBM Bob kann Softwareentwicklung erheblich verändern. Gerade bei großen und historisch gewachsenen Anwendungen sind Funktionen wie Codeanalyse, Dokumentation, Refactoring, Testgenerierung und Modernisierungsunterstützung interessant. IBM adressiert inzwischen ausdrücklich auch Java-, IBM-i- und IBM-Z-Modernisierung.

Für IT-Dienstleister besteht die eigentliche Herausforderung aber nicht darin, möglichst schnell möglichst viele Entwickler mit dem Werkzeug auszustatten.

Sie besteht darin, daraus einen beherrschten Entwicklungsprozess für Kundenprojekte zu machen.

Dazu gehören vertraglich freigegebene Nutzungsszenarien, eine geklärte Datenverarbeitung, getrennte Kundenumgebungen, definierte Modelle für Identitäten und Berechtigungen, kontrollierte MCP-Anbindungen, klare Regeln für Secrets und Produktionszugriffe sowie verbindliche menschliche Reviews.

Und vielleicht braucht die Branche dafür einen kleinen Perspektivwechsel.

Die relevante Frage lautet künftig nicht mehr:

„Dürfen unsere Entwickler KI verwenden?“

Sie lautet:

„Unter welchen nachvollziehbaren Bedingungen dürfen unsere Entwickler KI mit dem Wissen, dem Quellcode und der Infrastruktur unserer Kunden arbeiten lassen?“

Wer diese Frage sauber beantworten kann, hat aus einem interessanten KI-Werkzeug ein professionelles Entwicklungswerkzeug gemacht.

Wer sie nicht beantworten kann, sollte mit dem ersten Kundenrepository vielleicht noch etwas warten.

Über den Autor: Uwe Graf ist Head of Consulting bei der EasiRun Europa GmbH und gilt auf LinkedIn als eine der profiliertesten Stimmen in Sachen Mainframe-Modernisierung. Seine Beiträge sind fachlich präzise, pointiert – und unverkennbar durch den kleinen Dino, der als Symbol für den Brückenschlag zwischen Tradition und Innovation steht. Für sein Engagement in der Mainframe-Community wurde er 2025 sowohl als IBM Champion als auch als „Influential Mainframer“ von planetmainframe.com ausgezeichnet