KI-Governance darf kein nachträglicher Gedanke sein

Abhishek Ranjan ist der CTO bei Apna und Blue Machines, wo er maßgeblich an der Transformation sowohl der menschlichen Belegschaft als auch der KI-Belegschaft beteiligt ist.

Wir haben uns mit ihm zusammengesetzt, um über Governance in KI-Workflows zu sprechen. Das hat er gesagt.

Technologie an der Seite von Menschen

Ich bin Abhishek Ranjan. Ich bin der CTO bei Apna und Blue Machines. Zwei sehr miteinander verbundene und doch unterschiedliche Welten haben meinen Weg bis zu diesem Moment der KI-Transformation geprägt.

Bei Apna entwickeln wir Lösungen für die menschliche Belegschaft. Apna ist eines der am schnellsten wachsenden Einhörner Indiens, mit über 60 Millionen Nutzern auf der Plattform. Bei dieser Größenordnung erhalten wir einen sehr genauen Einblick in die indische Arbeitswelt. Wir sehen Millionen von Menschen, die nach besseren Möglichkeiten suchen, Arbeitgeber, die schneller einstellen möchten, unterschiedliche Sprachen, verschiedene Qualifikationsniveaus sowie unterschiedlich ausgeprägten Zugang zu digitalen Technologien und entsprechendes Selbstvertrauen.

Bei Blue Machines entwickeln wir Lösungen für die KI-Belegschaft. Wir konzentrieren uns auf Unternehmens-Sprach-KI und verarbeiten täglich Millionen von Gesprächsminuten. Wir entwickeln mehr als nur Bots, die Fragen beantworten. Wir entwickeln KI-Arbeitskräfte, die mit Kunden sprechen, den Kontext verstehen, Feedback aufnehmen, sich im Laufe der Zeit verbessern und echte Geschäftsabläufe ausführen können.

Ich habe erlebt, wie Technologie Menschen dabei hilft, Arbeit zu finden, sich weiterzuentwickeln und an der Wirtschaft teilzunehmen. Und jetzt sehe ich, wie KI selbst zu einer neuen Art von Belegschaft wird, die Seite an Seite mit Menschen arbeiten kann.

Für mich geht es in diesem Moment daher nicht nur darum, KI für mehr Produktivität einzusetzen oder schneller Code zu schreiben. Es geht darum, neu zu denken, wie Unternehmen arbeiten und wie Arbeit selbst erledigt wird.

Die Architektur zweier sehr unterschiedlicher Unternehmen

Die Architektur von Apna ist wie eine große Marktplatzplattform aufgebaut. Wir verfügen über Systeme für Verbraucher und Arbeitgeber, Datenplattformen, KI- und Matching-Systeme, Suche, Kommunikation, Betrugsbekämpfungs- und Vertrauensebenen sowie inzwischen KI-Recruiter- und KI-Funktionen zur Vorbereitung auf Bewerbungsgespräche. Das Bereitstellungsmodell ist cloudorientiert, hochgradig skalierbar und auf hohe Verfügbarkeit ausgelegt, da Millionen von Nutzern und Tausende von Unternehmen die Plattform verwenden.

Die Engineering-Organisation umfasst über 100 Personen, die in den Bereichen Produktentwicklung, Backend, Frontend, Mobile, Daten, KI, Infrastruktur, Sicherheit und Plattformteams arbeiten. Unser Fokus liegt nicht nur auf der Entwicklung von Funktionen, sondern auch auf dem Aufbau zuverlässiger Systeme, die in enormem Maßstab betrieben werden können.

Blue Machines ist eine andersartige Technologieorganisation. Sie konzentriert sich auf Unternehmens-Sprach-KI und agentenbasierte Workflows. Wir entwickeln KI-Arbeitskräfte, die sprechen, Schlussfolgerungen ziehen, Aktionen ausführen, in Geschäftssysteme integriert werden und sich durch Feedback verbessern können. Bereits heute arbeiten wir in einem erheblichen Maßstab und verzeichnen täglich Millionen von Minuten mit Sprach-KI.

Die Architektur von Blue Machines ist stärker echtzeitfähig und von Grund auf für KI konzipiert. Sie umfasst Sprachinfrastruktur, Telefonie, Sprache-zu-Text, Schlussfolgerungen durch große Sprachmodelle, Text-zu-Sprache, Workflow-Orchestrierung, Integrationen, Analysen, Überwachung und Bewertungssysteme. Die Produktkomplexität ist hoch, weil Unternehmens-Sprach-KI in der Produktion, in echten Gesprächen, mit geringer Latenz, hoher Genauigkeit, Maßnahmen zur Einhaltung von Vorschriften und klaren Geschäftsergebnissen funktionieren muss.

Bei Blue Machines hat ein Kernteam aus vier Ingenieuren innerhalb weniger Wochen eine verteilte Plattform zur Sprach-Orchestrierung entwickelt. Außerdem verfügen wir über ein sehr erfahrenes Forschungsteam, das intensiv an Sprach-KI, der Bewertung von Agenten, Schlussfolgerungen, Latenz, mehrsprachigen Systemen und der kontinuierlichen Verbesserung von Agenten arbeitet. Diese Forschungstiefe ist wichtig, weil sich Unternehmens-Sprach-KI nicht allein durch das Zusammensetzen von Modellen lösen lässt. Sie erfordert eine starke Produktentwicklung, eine starke Systementwicklung und eine starke angewandte KI-Forschung.

Insgesamt sitzt die Technologieorganisation, die ich leite, an der Schnittstelle zwischen Plattformen im großen Maßstab und KI-nativen Systemen.

Wie gut gesteuerte KI den Softwarelebenszyklus verbessert

Im vergangenen Jahr hat KI verändert, wie wir Technologie entwickeln, testen und veröffentlichen.

Zuvor war unser Veröffentlichungsprozess eher traditionell. Ingenieure entwickelten Funktionen, erstellten Pull-Anfragen, durchliefen Begutachtungen durch Kollegen, führten Testfälle aus und stellten die Änderungen anschließend über die übliche Bereitstellungspipeline bereit. Das funktionierte, aber die Geschwindigkeit hing von manuellen Review-Zyklen, manueller Qualitätssicherung und dem Vertrauen des Teams in die Veröffentlichung ab.

Als KI-gestütztes Programmieren zu einem größeren Bestandteil der Entwicklung wurde, führten wir es ein – und erkannten bald, dass Geschwindigkeitssteigerungen allein nicht ausreichten. KI kann Ingenieuren helfen, schneller Code zu schreiben, aber wenn sich die Governance nicht verbessert, kann sie auch mehr unentdeckte Fehler, übersehene Sonderfälle oder schlechte Abstraktionen verursachen.

Also änderten wir das Betriebsmodell.

1. Wir fügten eine KI-gestützte PR-Review-Ebene hinzu. Jeder PR wurde vor dem menschlichen Review auf riskante Logik, fehlende Sonderfälle, Brüche bei API-Verträgen, Sicherheitsprobleme, Migrationsrisiken und unzureichende Testabdeckung geprüft. Dadurch wurden offensichtliche Auslassungen bereits vor dem Review reduziert.
2. Wir verschärften die CI-Gates. Eine Änderung konnte nicht allein deshalb weitergeführt werden, weil der Code fehlerfrei aussah. Sie musste Unit-Tests, Integrationstests, Linting, Sicherheitsprüfungen, API-Vertragstests und Regressionssuiten für den betroffenen Produktbereich bestehen.
3. Wir erstellten umfangreichere Regressionspakete für kritische Arbeitsabläufe. Dazu gehörten beispielsweise zusätzliche Testfälle für reale Benutzerszenarien, Sonderfälle, mehrsprachiges Verhalten, Fehlerbehandlung und Geschäftsergebnisse.
4. Wir änderten die Governance für Eingabeaufforderungen. Mehr dazu gleich.
5. Wir machten Canary-Releases für Bereiche mit hohem Risiko verpflichtend. Statt für alle Nutzer zu veröffentlichen, geben wir die Änderung zunächst für einen kleinen Prozentsatz des Datenverkehrs frei, überwachen Fehler, Latenz, Konversion, Abbrüche, Agentenqualität und Kundenauswirkungen und führen sie anschließend weiter aus oder rollen sie zurück.
6. Wir verbesserten die Beobachtbarkeit. Wenn etwas ausfiel, wollten wir genau wissen, welche Codeversion, Version der Eingabeaufforderung, welches Modell, welcher Arbeitsablauf oder welche Abhängigkeit dafür verantwortlich war.

Die Auswirkungen sind sehr deutlich. Unsere Veröffentlichungsgeschwindigkeit hat sich erheblich erhöht. Teams, die zuvor größere, gebündelte Releases bereitstellten, veröffentlichen nun kleinere Änderungen in kürzeren Abständen. In einigen Bereichen stieg die Veröffentlichungshäufigkeit um fast das 2- bis 3-Fache, weil die Prüfungen stärker automatisiert sind und das Vertrauen größer ist. Und so baute ein Team aus vier Personen innerhalb weniger Wochen eine komplexe verteilte Plattform.

Auch die Anzahl der Produktionsprobleme ging zurück, weil jede Veröffentlichung kleiner, besser getestet und leichter zurückzurollen ist. Wir beobachten einen deutlichen Rückgang von Fehlern in der Produktion, insbesondere dort, wo automatisierte Regressionstests und Canary-Releases inzwischen verpflichtend sind. Heute liegen die Fehler fast 40 % unter dem ursprünglichen Ausgangswert.

KI allein sorgt für Geschwindigkeit. KI mit Governance sorgt für Geschwindigkeit und Qualität.

Warum Eingabeaufforderungen wie Code behandelt werden müssen

Abhishek teilt mit

Für KI-Systeme begannen wir ebenfalls, Eingabeaufforderungen wie Code zu behandeln … Das war eine wichtige Verbesserung. Wir wissen, welche Eingabeaufforderung aktiv war, was geändert wurde, was sich verbessert hat und ob sich die Ergebnisse für Kunden verbessert haben.

Für KI-Systeme begannen wir ebenfalls, Eingabeaufforderungen wie Code zu behandeln.

Wir versionieren, prüfen und testen Eingabeaufforderungen nun, führen sie über verschiedene Umgebungen weiter und rollen sie schrittweise aus. Eingabeaufforderungen werden nicht länger wie kleine Konfigurationsänderungen behandelt. Sie durchlaufen Testdialoge, Sonderfälle, Prüfungen des mehrsprachigen Verhaltens, Latenzprüfungen, Compliance-Prüfungen und Prüfungen der Geschäftsergebnisse.

Wir können eine neue Eingabeaufforderung oder einen Agenten-Arbeitsablauf zunächst für einen kleinen Prozentsatz des Datenverkehrs freigeben, die Ergebnisse beobachten und ihn anschließend weiter ausrollen, wenn die Kennzahlen besser aussehen.

Das war eine wichtige Verbesserung. Zuvor war es schwierig festzustellen, ob eine Änderung der Eingabeaufforderung den Agenten verbessert oder lediglich sein Verhalten verändert hatte. Jetzt können wir Versionen objektiver vergleichen. Wir wissen, welche Eingabeaufforderung aktiv war, was geändert wurde, was sich verbessert hat und ob sich die Ergebnisse für Kunden verbessert haben.

Die größere Veränderung besteht darin, dass das gesamte Technologiesystem stärker automatisiert, messbarer und besser gesteuert wurde.

Ein agentischer Arbeitsablauf für Entwicklung und Veröffentlichung

Wir verwenden einen agentischen Arbeitsablauf für Entwicklung und Veröffentlichung, bei dem Menschen an wichtigen Punkten eingebunden sind.

Dieser Arbeitsablauf eignet sich nicht für jede Veröffentlichung. Bei sehr komplexen Plattformänderungen, tiefgreifenden Architekturänderungen oder sensiblen Systemen verwenden wir weiterhin einen traditionelleren, von Menschen gesteuerten Prozess. Für einige Produktbereiche, insbesondere für sich schneller entwickelnde Arbeitsabläufe, ist er jedoch zur standardmäßigen Vorgehensweise bei der Entwicklung geworden.

Hier ist der Arbeitsablauf:

1. Der Prozess beginnt, wenn eine Produktanforderung oder ein technisches Problem eintrifft. Ein KI-Planungsagent liest die Anforderung, unterteilt sie in Aufgaben, identifiziert Abhängigkeiten, weist auf riskante Bereiche hin und schlägt einen Implementierungsplan vor. Der Ingenieur prüft den Plan, korrigiert Annahmen und entscheidet über den endgültigen Ansatz.
2. Anschließend generiert ein Programmieragent Code, strukturiert Module um, erstellt Standardcode und legt Unit- und Integrationstests an. Ein Prüfagent kontrolliert den PR auf riskante Logik, fehlende Randfälle, Sicherheitsprobleme, Brüche von API-Verträgen und Lücken bei den Tests.
3. Als Nächstes erstellt ein Testagent Regressionsszenarien und validiert Randfälle. Bei KI-Workflows führt er außerdem Prompt-Evaluierungen, Konversationstests, Mehrsprachenprüfungen, Latenzprüfungen und Prüfungen der Geschäftsergebnisse durch.
4. Der Release-Agent empfiehlt anschließend anhand der Testergebnisse, des betroffenen Bereichs, früherer Fehler und der Bereitschaft für die Überwachung, ob die Änderung sicher für eine Canary-Bereitstellung ist. Menschen genehmigen jedoch weiterhin kritische Freigaben, insbesondere wenn die Änderung den Umsatz, die Kundenerfahrung, die Sicherheit oder die Kerninfrastruktur betrifft.
5. Nach der Veröffentlichung überwacht der Monitoring-Agent Fehler, Latenz, Konversionen, Abbrüche, die Qualität des Agenten und die Auswirkungen auf Kunden. Wenn etwas nicht richtig aussieht, empfiehlt er ein Rollback, eröffnet einen Vorfall, fasst Protokolle zusammen und erstellt einen ersten RCA-Entwurf.

Dieser Workflow ist agentenbasiert, aber nicht blind autonom. KI-Agenten planen, programmieren, prüfen, testen, veröffentlichen, überwachen und fassen zusammen. Menschen genehmigen, hinterfragen, priorisieren und treffen die endgültige Entscheidung.

Wo Claude Code und Cursor besonders stark sind

Meine bevorzugten Tools sind Claude Code und Cursor, je nach Workflow.

Cursor ist besonders geeignet, wenn Ingenieure KI tief in ihre IDE integrieren möchten – für die tägliche Programmierung, das Umstrukturieren von Code, das Verständnis der Codebasis und eine schnellere Implementierung.

Claude Code erweist sich als äußerst nützlich für stärker agentenbasierte Aufgaben: das Verstehen größerer Codebasen, Änderungen an mehreren Dateien, das Erstellen von Tests, die Behebung von Problemen und iterative Arbeit wie mit einem technischen Partner.

Warum KI einen Hebel bietet, während Menschen Urteilsvermögen einbringen

Wir verlassen uns inzwischen stark auf KI bei allem, was Geschwindigkeit, Abdeckung oder Konsistenz verbessert, nicht jedoch bei Aufgaben, die Urteilsvermögen, Verantwortlichkeit oder langfristige Abwägungen erfordern.

KI unterstützt uns beispielsweise inzwischen bei Code-Reviews, der Generierung von Testfällen, der Regressionsabdeckung, der Dokumentation, der Fehlersuche, der Protokollanalyse und sogar bei der Triage von Vorfällen. Sie kann riskante Codepfade, fehlende Randfälle, mögliche Sicherheitsprobleme oder Muster bei Fehlern in der Produktion schnell erkennen. In KI-Systemen hilft sie uns außerdem, Prompt-Versionen zu vergleichen, Konversationen zu bewerten und zu verstehen, an welcher Stelle ein Agent scheitert.

Die endgültigen Entscheidungen bleiben jedoch menschlich. Hier sind einige Beispiele:

• Architekturentscheidungen müssen beim Menschen bleiben, da sie Abwägungen hinsichtlich Skalierbarkeit, Kosten, Zuverlässigkeit, Teamkompetenz und langfristiger Produktrichtung beinhalten.
• Eine durchgängige RCA kann von KI unterstützt werden, aber Menschen müssen weiterhin die Zusammenhänge herstellen, die Hypothese validieren und die Lösung festlegen.
• Die Priorisierung des Backlogs bleibt menschlich, da sie Kundenkontext, Geschäftsstrategie und die Einschätzung erfordert, was wirklich wichtig ist.
• Bei Sicherheitsprüfungen kommt KI zum Einsatz, aber fachliches Urteilsvermögen ist notwendig. KI kann Probleme kennzeichnen, aber auch falsch-positive Ergebnisse erzeugen oder Risiken übersehen, die sich nur aus dem Geschäftskontext ergeben. Die Verantwortung bleibt beim Menschen, da Risiko und Verantwortlichkeit zu hoch sind.

Praxisbeispiele für Fehler von KI beim technischen Urteilsvermögen

Hier sind einige Beispiele dafür, wie wichtig menschliches Urteilsvermögen ist.

Der erste Fall betraf Latenzspitzen im Millisekundenbereich in unserer Sprachpipeline. Die KI kommentierte das Problem korrekt und erkannte, dass die Latenz in einem Pfad zu einem Problem werden könnte. Der von ihr vorgeschlagene Code war jedoch falsch. Er sah sauber aus, hätte unter Last aber einen anderen Engpass verursacht. Ein menschlicher Ingenieur griff ein, verstand das Laufzeitverhalten und behob das Problem ordnungsgemäß.

Ein weiteres Beispiel ergab sich bei der Untersuchung eines Produktionsproblems. Mehrere nachgelagerte Systeme fielen aus, und die KI analysierte diese Systeme weiterhin unabhängig voneinander und schlug Optimierungen vor. Wir wussten jedoch bereits, dass die eigentliche Ursache eine vorgelagerte Abhängigkeit war, die zuerst ausgefallen war. Die KI verwechselte sichtbare Ausfälle mit der Grundursache.

Hier hat die KI weiterhin Schwierigkeiten. Sie kann Protokolle lesen, Traces zusammenfassen, Korrekturen vorschlagen und die Fehlersuche beschleunigen. In komplexen verteilten Systemen kann sie jedoch Kausalität, zeitliche Abläufe und den Kontext auf Systemebene übersehen.

Warum Teams kleiner werden und gleichzeitig breiter aufgestellt sind

Die KI hat das Anforderungsprofil bei Einstellungen stärker verändert als das Organigramm.

Früher stellten wir Mitarbeiter mit engerem funktionalem Spezialwissen ein: Backend, Frontend, Qualitätssicherung, DevOps, Daten und so weiter. Diese Fähigkeiten sind weiterhin wichtig, aber heute schätze ich Ingenieure, die über den gesamten Stack hinweg arbeiten, KI intensiv einsetzen und ein Problem mit deutlich weniger Anleitung bis in die Produktion bringen können.

Die besten Ingenieure schreiben heute nicht einfach nur Code. Sie entwerfen Arbeitsabläufe, nutzen KI für die Implementierung, erstellen Tests, prüfen Ergebnisse, beheben Fehler schneller und achten auf die Qualität der Veröffentlichung.

Dadurch verschob sich die Einstellungshürde hin zu Ingenieuren mit hoher Verantwortungsbereitschaft und ausgeprägtem Urteilsvermögen. Zu Menschen, die die richtigen Fragen stellen, KI-Ergebnisse überprüfen, Systeme tiefgreifend verstehen und eigenständig ausliefern können.

In einigen Bereichen hat dies auch den Bedarf an großen Teams verringert. Ein kleineres Team mit starker Unterstützung durch KI kann heute Aufgaben erledigen, für die früher deutlich mehr Menschen erforderlich waren.

Warum KI die Ausbildung neuer Ingenieure erschwert

Abhishek teilt

Ich glaube nicht, dass ein Verbot von KI oder die Forderung, Menschen so programmieren zu lassen wie im Jahr 2010, die Lösung ist. Das wäre falsch. Ich glaube aber auch nicht, dass wir vollständig gelöst haben, wie man ein tiefgreifendes ingenieurtechnisches Urteilsvermögen aufbaut, wenn die KI so viel der Vorarbeit übernimmt. Vorerst besteht meine beste Antwort darin, Verständnis sichtbar zu machen.

Wie bilden wir neue Ingenieure im Zeitalter der KI aus? Ich habe noch keine perfekte Antwort.

Als wir anfingen, halfen uns integrierte Entwicklungsumgebungen. Dann half uns Google. Danach half uns Stack Overflow. In all diesen Phasen mussten wir uns jedoch weiterhin durch das Problem hindurcharbeiten. Wir mussten die Antwort verstehen, sie anpassen, Fehler beheben und lernen, warum sie funktionierte.

Mit KI und Vibe-Coding können wir diese Anstrengung überspringen. Ein neuer Ingenieur kann funktionierenden Code erzeugen, ohne das System, die damit verbundenen Abwägungen oder die Fehlerfälle wirklich zu verstehen. Das bereitet mir Sorgen.

Ich glaube nicht, dass ein Verbot von KI oder die Forderung, Menschen so programmieren zu lassen wie im Jahr 2010, die Lösung ist. Das wäre falsch. Ich glaube aber auch nicht, dass wir vollständig gelöst haben, wie man ein tiefgreifendes ingenieurtechnisches Urteilsvermögen aufbaut, wenn die KI so viel der Vorarbeit übernimmt.

Vorerst besteht meine beste Antwort darin, Verständnis sichtbar zu machen. Ingenieure sollten erklären können, warum der Code funktioniert, wo er fehlschlagen kann, welche Tests wichtig sind, was im großen Maßstab geschieht und wie sie den Code in der Produktion debuggen würden.

So lässt sich der Token-Verbrauch verwalten

Auch die Kosten stellen bei der KI eine Herausforderung dar.

Der Token-Verbrauch wirkt anfangs harmlos, aber sobald KI in Programmierung, Prüfungen, Tests, Fehlersuche und agentenbasierte Arbeitsabläufe einfließt, können die Kosten sehr schnell steigen.

Daher müssen wir den ROI nach Arbeitsablauf messen und eine intelligentere Orchestrierung einsetzen. Nicht jede Aufgabe benötigt das teuerste Modell.

Die Zukunft besteht darin, für die jeweilige Aufgabe das passende Modell einzusetzen.

Warum CTOs schnell handeln müssen – mit Kontrollmechanismen

Mein Rat lautet: Entwickelt schnell. Experimentiert schnell. Setzt KI in echten Arbeitsabläufen in den Bereichen Technik, Produkt, Support, Vertrieb, Betrieb und internen Prozessen ein. Tut nicht so, als würde sie nicht funktionieren. Sie funktioniert – manchmal erstaunlich gut.

Aber werdet nicht zu blinden Gläubigen. KI ist leistungsfähig, aber keine Magie. Ihr braucht Kontrolle, Governance, Tests, Beobachtbarkeit und klare Verantwortlichkeiten. Andernfalls erzeugt ihr lediglich schnelleres Chaos.

Die richtige Einstellung lautet weder „KI wird alles ersetzen“ noch „KI wird überschätzt“. Die richtige Einstellung lautet: „Wie kann ich dies nutzen, um meine Organisation zehnmal leistungsfähiger zu machen?“

Bleiben Sie dran

Begleitet Abhishek Ranjan auf LinkedIn. Und seht euch seinen Hacktivate-Newsletter an.

Weitere Interviews mit Experten folgen im CTO-Club!