Wenn ein Finanzinstitut beschliesst, eine regulierte Aufgabe zu automatisieren, stellt sich die Beschaffungsfrage meist als Entweder-oder: ein KI-Berater oder ein KI-Entwickler, als wären beide derselbe Einkauf zu zwei Preisen. Das sind sie nicht. Ein Berater verkauft eine Entscheidung; ein Entwickler verkauft gebaute Software. In einem unregulierten Umfeld kostet die falsche Wahl Zeit. In der FINMA-regulierten Finanzwelt sind die Teile, die jede Seite unberührt lässt (die Diagnose auf der einen, der laufende Prozess auf der anderen), genau jene, die entscheiden, ob eine Automatisierung ihre erste Prüfung übersteht. Die ehrliche Antwort ist meist nicht das eine oder das andere, sondern beide, in Folge.
Beginnen Sie mit dem Berater und dem, was die Rolle tatsächlich tut: die Diagnose vor jedem Code. Ein Berater kartiert den Workflow von Anfang bis Ende, misst eine Baseline, benennt die Kontrollpunkte und Freigaben, entscheidet, was automatisiert wird und, ebenso oft, was besser unangetastet bleibt, und rahmt die Compliance-Frage. Das Ergebnis ist eine Entscheidung und ein Plan, nicht Software. Ein Berater allein ist das richtige Mandat, wenn das Institut noch wissen muss, ob und was, und noch nicht wie: wenn das Denken unfertig ist und die Festlegung auf einen Build die Festlegung auf eine Vermutung wäre.
Ein Entwickler verwandelt eine klare Spezifikation in funktionierende Software, und er tut es gut und oft schnell, wenn ein kartierter Prozess, eine definierte Datenquelle, eine vereinbarte Erfolgskennzahl und eine bereits im Institut sitzende, für Compliance verantwortliche Person vorliegen. Das Ergebnis ist der Build. Ein Entwickler allein ist das richtige und effiziente Mandat, wenn dieses Denken wirklich abgeschlossen ist. Der Fehler ist, die Lage zu verkennen: einen Entwickler zu engagieren, der Code gegen eine Spezifikation schreibt, die es noch gar nicht gibt, und Monate später festzustellen, dass der fehlende Teil nie der Code war.
Deshalb braucht die regulierte Finanzwelt meist beide. Eine einzelne regulierte Automatisierung ist keine einzelne Fähigkeit. Der grösste Teil davon ist Prozess, Daten und Compliance, und nur eine Minderheit ist Code. Diagnose und Build sind zwei verschiedene Disziplinen, und die Institute, die stehen bleiben, haben meist die eine gekauft und angenommen, sie decke die andere mit ab: einen polierten Build für ein Problem, das niemand diagnostiziert hat, oder eine durchdachte Standortbestimmung, die nie zu einem laufenden Prozess wurde. Die Frage ist nicht abstrakt Berater oder Entwickler, sondern welche Teile des Bogens Sie noch selbst verantworten müssen.
Die tragfähige Form ist eine geordnete. Zuerst kommen Standortbestimmung und Roadmap (die Arbeit des Beraters: die Baseline, der Umfang, die Entscheidung, was automatisiert wird), dann der Build und die Integration über Systeme hinweg, die nie dafür gebaut wurden, miteinander zu sprechen (die Arbeit des Entwicklers), dann die Messung zurück gegen die Baseline (wieder die Arbeit des Beraters). Die Gestaltung des Fehlerfalls, die Rückfallebene und die revisionssichere Aufzeichnung sind kein später Schritt; sie ziehen sich durch den ganzen Bogen, denn in einem kontrollierten Prozess ist die Gestaltung des Fehlerfalls die eigentliche Gestaltung.
Worauf Sie achten sollten, ist kein Titel, sondern die Verantwortung über die ganze Folge: entweder eine einzige Partei, die von der Diagnose bis zum gemessenen Ergebnis geradesteht, oder eine saubere, dokumentierte Übergabe zwischen Berater und Entwickler, ohne eine Lücke, durch die der Besitz fällt. Und die Bedingung, die beide überdauert, ist der Besitz: Ihnen gehören der Workflow, der Code und die Dokumentation vollständig, und Sie können den Prozess ohne die Menschen betreiben und prüfen, die ihn gebaut haben, mit dokumentierten Regelungen zu Datenhaltung und Zugriff. Ein Partner, der Ihnen dieses Bild zeichnen kann, bevor ein File den Besitzer wechselt, hat ein reguliertes Ergebnis bereits verantwortet.
Genau diese geordnete Disziplin, die Arbeit einzugrenzen statt sie zu weiten und einen bewiesenen Fall den nächsten verdienen zu lassen, ist es, wie das Reporting über 39+ Fonds bei der IST Investmentstiftung aufgebaut wurde: ein messbarer Workflow nach dem anderen, jeder durch Diagnose, Build, Integration und Messung geführt, bevor der nächste versucht wurde. Wenn Sie einen Berater gegen einen Entwickler abwägen und es auf Belege statt auf den Bauch stützen möchten, ist eine KI-Standortbestimmung der Ausgangspunkt: Sie kartiert den Workflow, die Baseline und den echten Umfang, sodass sich die Beschaffungsfrage von selbst beantwortet. Es ist dieselbe Disziplin, die sich durch alles zieht, was wir bauen.