Der KI-Workshop liefert keine Software

8 Min. Lesezeit

Auch der schlaue Kollege braucht Tests

Der Satz, der den Unmut auslöste, war der vom „IQ-500-Kollegen“.

Er ist ein hervorragender Köder für Führungskräfte: kurz, eindrucksvoll, leicht mystisch. Er lässt KI wie eine brillante Neuanstellung klingen, die still im Team auftaucht und alle durch schiere kognitive PS mitzieht.

Der Slogan tauchte in Diskussionen rund um betriebliche KI-Reifegradmodelle auf. Stufe 0: Zugang zu Modellen. Stufe 1: Kapazitätsgewinne durch optimierte Abläufe. Stufe 2: Agenten-Werkzeuge im Team. Höhere Stufen: Veränderungen des Geschäftsmodells selbst. Das ist ein ernsthafter Rahmen.

Dann übernahm die Metapher: Was würden wir umbauen, wenn ein unvorstellbar intelligenter Kollege ins Team käme?

Als Anstoß, KI nicht mehr als besseres Suchfeld zu behandeln, ist das harmlos. Wörtlich genommen ist es Unsinn. Modelle werden nicht zu Kollegen, weil eine Folie ihnen eine Zahl verpasst. Sie tragen keine Verantwortung, verstehen keinen geschäftlichen Kontext und haften für keine Konsequenzen. Sie stimmen zu schnell zu, halluzinieren plausibel und klingen selbstsicher, während sie falsch liegen.

Die Gefahr ist nicht der Ehrgeiz. Die Gefahr ist, dass die Metapher es erlaubt, strategisch zu klingen und gleichzeitig der betrieblichen Realität auszuweichen.

Das Gespräch ist zu bequem

Das Problem ist kein Mangel an klugen Stimmen. Es ist der Filter.

Die Personen, die eingeladen werden, der Geschäftsleitung KI zu erklären, sind selten diejenigen, die das Ergebnis im Betrieb stabil halten müssen. Es sind Change Manager, HR-Strategen, Innovationsmoderatoren und Keynote-Berater, die festgestellt haben, dass der Markt schnelles Selbstbewusstsein belohnt.

Manche bringen Struktur. Manche helfen der Führung über Berührungsängste hinweg. Doch die Gefahr beginnt, wenn diese Einführungssprache zur gesamten Strategie wird: Mindset, Kompetenz, Befähigung, Kultur.

Das sind keine erfundenen Themen. Es sind unvollständige Themen.

KI-Einführung wird erst real, wenn sie einen Arbeitsablauf verändert. Und ein Arbeitsablauf ist keine Folie. Er ist der unordentliche Ort, an dem geschäftliche Absicht auf Software-Realität trifft: Identitäten, Berechtigungen, Datenqualität, Altsysteme, Ausnahmen, Prüfpfade und undokumentierte Kompromisse.

Hier endet die Inspiration und beginnt die Softwarearbeit.

KI-Einführung ist Softwarearbeit

Die bequeme Fiktion lautet, KI-Transformation bestehe vor allem darin, dass Menschen neue Gewohnheiten lernen.

Lernen ist wichtig. Doch in dem Moment, in dem KI einen operativen Prozess berührt, fordern Software-Fragen konkrete Antworten:

• Welche Daten darf das Modell sehen?
• Welche Entscheidungen darf es beeinflussen und welche lösen automatisierte Aktionen aus?
• Wer prüft das Ergebnis?
• Was wird protokolliert, ist reproduzierbar und lässt sich zurückrollen?
• Welcher Fehler ist bloß lästig und welcher ist ein geschäftlicher Vorfall?
• Wer wartet den Prompt, die Integration oder den Agenten, sobald das Pilot-Team weiterzieht?

Das ist die Mindestanforderung an Ernsthaftigkeit.

KI wird Ihr Unternehmen nicht allein führen. Sie verstärkt das System, an das man sie anbindet. Gekoppelt an klare Abläufe und disziplinierte Deployments verschafft sie echte Hebelwirkung. Gekoppelt an organisatorisches Chaos erzeugt sie schnelleres Chaos in schönerer Sprache.

Change Management hilft Menschen, sich zu bewegen. Software-Disziplin entscheidet, ob das Ziel tragfähig ist.

Der Forward Deployed Engineer als nützlicher Hinweis

Palantir hat den Forward Deployed Software Engineer bekannt gemacht. Die Unternehmens-KI belebt das Muster nun wieder, weil der Wert niemals in der Plattform allein liegt. Wert entsteht erst, wenn erfahrene Fachleute nah am Problem sitzen und Software an den realen Betrieb anpassen.

Nimmt man das Mystische weg, bleibt der Kern: eine technische Fachkraft, die direkt am Geschäftsproblem arbeitet und genug Befugnis besitzt, vage Absichten in funktionierende Software zu verwandeln.

Die Rolle sitzt in der produktiven Mitte:

• nah genug an den Nutzern, um tatsächliche Arbeitsabläufe zu verstehen
• technisch versiert genug, um die reale Umsetzung zu bauen und zu leiten
• erfahren genug, um eine Demo abzulehnen, die im Produktivbetrieb scheitern würde
• diszipliniert genug, um Tests, Deployment-Pfade und klare Zuständigkeiten zu hinterlassen

Die Führung braucht keine weiteren Visionäre, die das Potenzial von KI beschreiben, und keine isolierten Entwickler, die wochenlang auf bereinigte Anforderungen warten. Sie braucht jemanden, der im Arbeitsablauf steht und klärt, welche Software existieren muss, damit die Veränderung hält.

Die Demo ist nicht das System

KI-Demos verführen, weil die sichtbare Oberfläche in wenigen Tagen steht. Ein Chatbot beantwortet Fragen zu Dokumenten, ein Agent entwirft Kundenantworten oder ein Dashboard aktualisiert sich live. Der Raum applaudiert, Berater sprechen von Skalierung und die Präsentation verbucht einen schnellen Erfolg.

Dann verlangt die Realität ihren Stundensatz.

Interne Dokumente widersprechen sich. Berechtigungen sind zu grob vergeben. Das Modell zitiert veraltete Richtlinien. Der Agent führt Aktionen aus, die sich nicht nachvollziehen lassen. Die Fehlerbehandlung externer Schnittstellen versagt. Die Rechtsabteilung fragt nach Datenhaltung, die IT-Sicherheit nach Zugriffen und der Betrieb danach, wer nachts um zwei Uhr gerufen wird.

Das ist der Teil, den der Workshop niemals liefert.

Vibe Coding ist keine Software-Entwicklung, weil Software die umgebende Disziplin ist, die Ergebnisse über Zeit, Last und Fehler hinweg stabil hält. Demos wurden billig. Robuste Systeme nicht.

Was echte Entwicklung beisteuert

Die Kernpraktiken der Softwareentwicklung melden sich mit einem Schmunzeln zurück. Genau die Methoden, die früher als Vorlieben von Entwicklern abgetan wurden, machen KI überhaupt erst sicher einsetzbar.

• TDD definiert das erwartete Verhalten explizit, bevor ein Modell daran Änderungen vornimmt.
• CI deckt Brüche auf, solange die Änderung noch klein genug ist, um verstanden zu werden.
• CD macht Releases zu einer verlässlichen Routine statt zu einem vierteljährlichen Stoßgebet.
• Trunk-Based Development verhindert langlebige Nebenäste, in denen Integrationsrisiken unbemerkt wachsen.
• Ausführbare Spezifikationen geben Geschäftsregeln überprüfbare Zähne.
• Beobachtbarkeit (Observability) zeigt dem CTO, wie sich der Arbeitsablauf unter echten Bedingungen verhält.

KI erzeugt mehr Code, Abläufe und plausible Erklärungen, als herkömmliche Releasezyklen aufnehmen können. Ohne Disziplin entsteht eine Inflation von Artefakten: größere Repositories, aufgeblähte Prozesskarten und wachsende Risiken. Mit Disziplin entsteht echter Hebel.

Der Motor für vorhersagbare Software-Auslieferung ging nie um Prozessgläubigkeit. Es ging um schnelle Feedbackschleifen. KI hebt den Preis dafür an, wenn sie fehlen.

Führung ohne Lieferfähigkeit ist Papierkram

Compliance ist unverhandelbar. DSGVO, der AI Act, Datensouveränität und Nachvollziehbarkeit sind reale Rahmenbedingungen. Wer Unternehmen rät, schnell voranzugehen und Regeln zu ignorieren, verkauft importierten Leichtsinn.

Doch Führung hat ihre eigene Falle: Richtlinien an die Stelle von Lieferfähigkeit zu setzen.

Ausschüsse verfassen Grundsätze, Risikomatrizen und Betriebsmodelle, während die reale Arbeit in unüberwachte Skripte, SaaS-Automatisierungen und spontane Prompts abwandert. Das ist Papierkram, der Schatten-IT beim Wachsen zusieht.

Wirksame Führung erfordert Sicht auf die Umsetzung. Sie muss wissen, welche Systeme existieren, wohin Daten fließen, wer Komponenten besitzt und wie Vorfälle gelöst werden.

Der CTO muss diesen Dialog führen – nicht um Fortschritt zu verhindern, sondern um Zusagen betrieblich ehrlich zu machen.

Fragen, die der CTO stellen sollte

Wenn Begeisterung den Raum erfasst, muss der CTO keine Skepsis vorspielen. Die stärkere Haltung ist, beharrlich operative Fragen zu stellen:

• Zeigen Sie mir den genauen Arbeitsablauf.
• Welche Daten werden berührt und wer haftet für das Ergebnis?
• Wo liegen die automatisierten Tests?
• Wie sieht der Rollback-Pfad aus, wenn das Modell versagt?
• Woran messen wir, dass das Ergebnis besser geworden ist?
• Wer spielt Fixes ein und was wird protokolliert?
• Wer wartet dieses System, wenn das Pilot-Team aufgelöst ist?

Diese Fragen durchbrechen die Abstraktion. Change Manager können weiter ihren Beitrag leisten, Anbieter müssen ihre Funktionsweise erklären und die Geschäftsführung erkennt: Der CTO blockiert nicht den Fortschritt, sondern definiert, was der Fortschritt aushalten muss.

Das ist nicht technologiefeindlich. Es ist theaterfeindlich.

Mit dem CTO, nicht an ihm vorbei

Die riskantesten KI-Initiativen beginnen unschuldig: ein Abteilungspilot, ein fertiges Herstellerpaket, ein Arbeitsablauf an der IT vorbei, weil dort angeblich keine Kapazität frei ist.

Das schafft Software-Haftung ohne technische Verantwortung. Wenn die IT schließlich gerufen wird, hat das Werkzeug bereits aktive Nutzer, politische Dynamik und ungelöste Risiken, die der CTO plötzlich absichern soll.

KI-Arbeit gehört zum CTO, sobald sie Systeme, Daten oder Kundenprozesse berührt.

Ein nützlicher externer Partner stärkt diese Verantwortung, statt sie zu umgehen. Er arbeitet nah am Geschäftsproblem und nah am Entwicklungsteam, um unternehmerische Absichten in verlässliche Software zu übersetzen.

Ob man das Forward Deployed Model, Delivery-Partnerschaft oder schlicht erfahrene Software-Urteilskraft vor Ort nennt: Die Erkenntnis bleibt dieselbe. Der Workshop liefert nicht, die Präsentation integriert sich nicht und der schlaue Kollege schreibt keine Fehleranalyse.

Jemand muss das System bauen, die Konsequenzen tragen und wissen, wo Software bricht.