Ich habe Software Tailor im Jahr 2006 gegründet. Neunzehn Jahre später hat das Unternehmen vier verschiedene Wirtschaftskrisen, sechs Fortune Global 500 Kunden aus den Bereichen Pharma, Finanzen, Regierung, Recht, Verteidigung und Energie erfolgreich bedient – und seit 2007 keinen einzigen Projektfehler verzeichnet. Diese letzte Zahl ist die, nach der Investoren und Beschaffungsprüfer am häufigsten fragen, und sie ist die einzige, die einer Erklärung bedarf. Hier sind die vier technischen Grundsätze, die diesen Rekord sichern.

Regel 1: Ein Liefermodell, keine Vermischung von Service und Produkt

Jedes Software Tailor-Projekt basiert auf demselben Liefermodell – eine eng umrissene Pilotphase, die funktionierende Software liefert, gefolgt von einer Erweiterung, die der Kunde auf Grundlage der gelieferten Ergebnisse finanziert (oder nicht). Wir betreiben keine separate „Service“-Abteilung, die nach Anforderungsdokumenten liefert, und keine separate „Produkt“-Abteilung, die nach Roadmaps liefert. Die beiden würden sich widersprechen; eine würde immer die andere querfinanzieren.

Das einheitliche Modell bedeutet, dass jeder Entwickler weiß, wie „fertig“ aussieht, bevor er beginnt. Das ist die Voraussetzung dafür, nicht zu scheitern.

Regel 2: Disziplin bei der Kundenauswahl – nur Kunden, für die wir liefern können

Unsere Kundenauswahl erfolgt gezielt – nicht opportunistisch. Sechs Fortune Global 500-Kunden in 19 Jahren sind keine langsame Vertriebspipeline, sondern eine bewusste Auswahlgrenze. Jeder Kunde, den wir annehmen, muss vor Projektstart drei Tests bestehen: Sein Problem muss eines sein, das wir bereits gelöst haben, sein interner Sponsor muss die Person sein, die die Software nutzt (nicht eine Zwischenschicht), und seine Hardware-/Datenumgebung muss es uns ermöglichen, ohne sechsmonatige Beschaffungsverzögerung zu liefern.

Ein Kunde, der einen dieser Tests nicht besteht, wird an jemand anderen verwiesen, nicht als Projekt angenommen. Diese Regel kostet uns am häufigsten Umsatz. Sie ist aber auch die einzige, die in 19 Jahren keine Ausnahmen kennt.

Regel 3: Ingenieursdisziplin orientiert an einem anerkannten Rahmenwerk

Lange bevor das Risikomanagement für KI ein eigenes Rahmenwerk hatte, entsprachen die von mir für Software Tailor kodifizierten Ingenieursregeln demselben Muster: Arbeit steuern, Risiken abbilden, Ergebnisse messen, Änderungen managen. Das NIST AI RMF 1.0 [1] formalisierte dieses Muster 2023 für KI, und das Critical Infrastructure-Profil [1] von April 2026 erweiterte es auf regulierte Branchen. Beim Lesen dieser Dokumente lässt sich unsere interne Disziplin klar auf die vier Funktionen abbilden.

Was uns das gibt: Jedes Projekt ist durchgängig gegen ein externes Rahmenwerk prüfbar, nicht nur gegen unsere eigenen Gewohnheiten. Wenn ein Beschaffungsteam fragt, wie der Umfang der Pilotphase festgelegt wird, ist die Antwort dieselbe, die das NIST für das Risikomanagement geben würde – und das Compliance-Team des Kunden hat diesen Wortschatz bereits verinnerlicht.

Regel 4: Aufzeichnungsfähig, wiederherstellbar, rekonstruierbar

Die vierte Regel ist älter als die Audit-Trail-Terminologie, die wir heute für AI Suite verwenden. Jedes Software Tailor-Projekt läuft in einem Zustand, in dem jede Entscheidung, jedes Artefakt, jede Version des Codes aus versionierten Eingaben rekonstruiert werden kann. Das ist für Softwareentwicklung allgemein nicht ungewöhnlich; ungewöhnlich ist, dass wir das auf das Projektanwenden, nicht nur auf den Codebestand. Sprint-Entscheidungen, Umfangsänderungen, Kundenfreigaben – alles aufgezeichnet, alles wiederherstellbar.

Diese Disziplin ist der Grund, warum unser inhaltsfreier Audit-Log-Ansatz für AI Suite so geliefert wurde, wie er ist. Das Audit-Row-Muster ist dasselbe Muster, das wir bereits auf Projekte angewandt haben. Der Wortschatz stammt aus Compliance-Rahmenwerken; die Praxis ist der Art entlehnt, wie wir liefern.

Was sich in AI Suite fortsetzt

Die Produktlinie Local AI Suite + AI Admin Console — siehe Warum wir AI als installierbare Binärdateien ausliefern und nicht als Cloud-SaaS — ist dieselbe ingenieurtechnische Disziplin, angewandt auf eine Produktlinie statt auf ein individuelles Projekt. Dasselbe einheitliche Liefermodell (Desktop-Installer mit einer kostenlosen einwöchigen Testphase), dieselbe Kundensegment-Disziplin (regulierte Branchen mit klaren Datenresidenz-Anforderungen), dieselbe Rahmenwerkszuordnung (NIST AI RMF + EU AI Act Deploy-Verpflichtungen), dieselbe nachvollziehbare, wiederherstellbare und reproduzierbare Audit-Haltung.

Keine Projektfehler seit 2007 ist kein Werbeslogan. Es ist das Ergebnis einer kleinen Anzahl von Regeln, die ohne Ausnahme angewendet werden. Dieselben Regeln bestimmen nun, wie AI Suite entwickelt wird.

Quellen

  1. NIST. „AI Risk Management Framework (AI RMF 1.0).“ https://www.nist.gov/itl/ai-risk-management-framework. Zugriff am 15.07.2026.