Ausgangssituation und Zielsetzung
Die meisten KI-Business-Tools kommen aus den USA – englischsprachig, auf US-Server gehostet, DSGVO bestenfalls nachträglich drangeflickt. Für Unternehmen in Deutschland, Österreich und der Schweiz ist das ein echtes Problem, kein Detail: Wer sensible Kundendaten durch eine KI verarbeiten lässt, will wissen, wo diese Daten liegen und dass sie dort rechtssicher bleiben.
Aus genau dieser Lücke ist BrAInEngine entstanden: eine KI-Plattform für Business-Automatisierung, gehostet in Frankfurt, DSGVO-nativ gedacht statt nachgerüstet, auf Deutsch bedienbar. Kein Chatbot-Spielzeug, sondern konkrete Aufgaben, die sonst Zeit fressen – Telefonate annehmen, E-Mails sortieren und beantworten, Buchhaltungsbelege erfassen, Social-Media-Content planen und veröffentlichen.
Strategie und Funktionskonzept
Am Anfang stand eine deutlich größere Vision: Content-Generatoren, ein KI-Influencer-Baukasten, ein Musik-Studio, Video-Erstellung – ein Tool, das fast alles kann. Je weiter das Produkt wuchs, desto klarer wurde ein Problem, das ich auch aus eigener Erfahrung kenne: Breite ist verführerisch, aber sie verwässert. Viele halb ausgereifte Funktionen schlagen selten eine Handvoll, die wirklich rund laufen.
Die Konsequenz war eine bewusste Verschlankung. Mediengenerierung wie das Musik-Studio oder der KI-Influencer-Hub sind rausgeflogen – nicht weil sie technisch nicht funktionierten, sondern weil sie nicht der eigentliche Kern des Produkts waren, dafür aber überproportional Wartung, Supportaufwand und Abhängigkeit von Drittanbietern gekostet hätten. Übrig blieb, was den eigentlichen Unterschied macht: Call-Agent, E-Mail-Agent, Buchhaltungsagent und Social-Media-Automatisierung – die Business-Automatisierung, für die DACH-Unternehmen tatsächlich zahlen, nicht das, was am meisten Aufmerksamkeit auf Social Media bekommt.
UX-Konzeption und Prototyping
Eine Erfahrung hat meinen Blick auf Nutzerführung nachhaltig geprägt: Das Dashboard war zunächst konsequent Desktop-first gedacht – verständlich für ein komplexes Business-Tool, aber ein Fehlschluss. Ein Blick auf das tatsächliche Nutzerverhalten zeigte: Gerade Interessenten informieren sich zuerst am Handy, oft über kurze Video-Einblicke.
Das bedeutete, große Teile des Dashboards im Nachhinein für Mobilgeräte zu überarbeiten – von der Navigation über den Content-Kalender bis zur Medienbibliothek. Machbar, aber deutlich aufwendiger, als es von Anfang an mitzudenken. Die Lehre daraus nehme ich seither in jedes Projekt mit: Mobile-first ist kein Nice-to-have, sondern eine Entscheidung, die man am Anfang trifft – nicht am Ende nachträglich korrigiert.
UI-Design und Designsystem
Design-Entscheidungen wirken oft erst, wenn echte Menschen sie sehen. Ein neu registrierter Nutzer meldete früh, dass Teile der Navigation im Dark Mode kaum lesbar waren – graue Schrift auf dunklem Hintergrund, für die meisten Augen gerade noch erkennbar, für manche nicht.
Das Problem war kein Einzelfall in einer Komponente, sondern lag im Kontrast-System selbst: Zu viele Textfarben waren mit sehr niedriger Deckkraft definiert – gut genug, um am eigenen, gut kalibrierten Bildschirm zu wirken, zu schwach für den echten Alltag. Die Lösung war eine systematische Anhebung der Kontrastwerte im gesamten Designsystem, nicht nur an der gemeldeten Stelle. Genau dieses Prinzip – Barrierefreiheit als Grundeinstellung statt Nachbesserung – ziehe ich seitdem konsequent durch jedes Projekt, das ich baue.
Entwicklung und KI-Integration
Die technische Seite von BrAInEngine verbindet mehrere KI-Anbieter zu einem stimmigen Ganzen: Spracherkennung und Sprachsynthese für den Call-Agent, Texterkennung für die Buchhaltung, Sprachmodelle für die E-Mail-Klassifizierung – jede Komponente mit eigenen Grenzen, eigenem Verhalten, eigenen Fehlerfällen.
BEISPIEL — Ein Bug, an dem ich besonders lange gesessen habe: Hashtags, die ein Nutzer im Kalender einträgt, verschwanden nach dem Speichern wieder. Zwei naheliegende Fixes brachten keine dauerhafte Besserung. Erst der dritte Anlauf zeigte die eigentliche Ursache – ein Datentyp-Missverständnis zwischen Datenbank und Anwendungscode, tief unter der Oberfläche versteckt. Die Lehre daraus: Wenn ein Fix nicht hält, liegt der Fehler fast nie dort, wo man zuerst hinschaut, sondern eine Ebene tiefer.
Genau diese Beharrlichkeit – nicht beim ersten Fix aufhören, sondern die tatsächliche Ursache finden – unterscheidet ein Produkt, das nur funktioniert, von einem, dem man vertrauen kann.
Tests, Optimierung und Launch
Vor dem Launch stand nicht nur klassisches Testen, sondern auch die rechtliche Seite: Als KI-Anwendung fällt BrAInEngine unter den EU AI Act. Der Call-Agent kündigt sich Anrufern deshalb aktiv als KI an, KI-generierte Inhalte werden im Dashboard sichtbar gekennzeichnet – Transparenzpflichten, die von Anfang an mitgedacht wurden statt nachträglich draufgesetzt.
Eine der wichtigsten Lehren aus der Testphase betrifft stille Fehler: Ein Vorgang, der als erfolgreich gemeldet wird, ohne tatsächlich erfolgreich gewesen zu sein, ist gefährlicher als ein Vorgang, der offen scheitert. Mehrfach zeigte sich genau dieses Muster – ein System meldete Erfolg, obwohl im Hintergrund nichts passiert war. Seitdem gilt bei mir ein fester Grundsatz für jedes Projekt: Eine Erfolgsmeldung ohne echte Prüfung im Hintergrund ist keine Erfolgsmeldung, sondern eine Behauptung.
BrAInEngine ist für mich der Beweis, dass sich KI nicht nur bereden, sondern bauen lässt – mit allen Ecken und Kanten, die dazugehören. Einen visuellen Einblick in das fertige Produkt gibt’s auf der Projektseite. Wenn du überlegst, eine eigene KI-gestützte Plattform oder Automatisierung umzusetzen, lass uns darüber sprechen.