Meine erste Berührung mit KI war keine Vorlesung und kein Startup-Hype. Es war eine Idee mit 16, für die ich Code schreiben musste.
Die Gesundheitswesen-Wurzel.
Aufgewachsen mit einem tiefen Verständnis dafür, wie verletzlich Systeme sind, in denen Menschen auf korrekte Entscheidungen angewiesen sind. Meine Familie kommt aus dem Gesundheitswesen. Das prägt, wie ich Software betrachte: nicht nur als Produkt, sondern als Verantwortung. Fehler haben Adressaten.
Das ist der Grund, warum ich mich so schwer mit „move fast and break things“ tue. In manchen Branchen bricht nicht nur die Software. Es bricht ein Prozess, der einen Menschen betrifft. Für den Mittelstand in regulierten Umgebungen ist das Alltag.
KI seit 16.
Mit 16 wollte ich ein Programm schreiben, das für mich Texte zusammenfasst. 2013 war das eine ernsthafte Aufgabe: keine fertigen Schnittstellen, kein GPT, keine fertigen Embeddings. Das hat mich ins Software-Engineering gezogen: Will etwas intelligent wirken, muss man erst lernen, wie Systeme überhaupt laufen.
Seitdem: acht Jahre professionelles Engineering in Finanzdienstleistung, öffentlicher Hand und Gesundheitsdaten. Und parallel die ganze Zeit die Faszination: Was machen diese Modelle, wo brechen sie, wo helfen sie wirklich?
Warum garten.ai.
Weil ich sehe, was passiert, wenn der Mittelstand KI als Zusatzfunktion behandelt: Shadow-AI auf Laptops, Prototypen ohne Besitzer, Beratungsfolien ohne System, das am Ende wirklich läuft. Und weil ich merke: Menschen, die ehrlich mit diesem Thema umgehen, sind selten.
garten.ai ist genau darauf gebaut: Engineering und Betrieb statt Beratung als Selbstzweck. Ich baue, was funktioniert, und ich sage „Nein, das braucht keine KI”, wenn es stimmt. Governance heißt auch: Nicht alles, was möglich ist, ist sinnvoll.
Was mich von einer Beratung unterscheidet.
Ich liefere Code, Dokumentation, Runbooks und Infrastructure as Code. Keine Folien. Am Ende eines Projekts läuft etwas, das ihr selbst weiterentwickeln könnt oder das ich als Retainer für euch betreibe. Technische Abhängigkeiten sind dokumentiert, damit ein Team später darauf aufsetzen kann.