Blog / Enterprise AI / LLMs & Agents
ENTERPRISE AI · AI AGENTS
Fünf Agenten, ein Orchestrator, 70 Prozent weniger Routinearbeit. Warum der Prozess die Architektur von AI Agents bestimmt.
Autor: Julia Rose / Veröffentlicht: August 2026
Was ein AI Agent grundsätzlich kann, ist inzwischen kein Geheimnis mehr: recherchieren, Dokumente auswerten, Systeme bedienen, Antworten formulieren. Die schwierigere Frage ist, welche dieser Fähigkeiten sich im eigenen Unternehmen tatsächlich in produktive Arbeit übersetzen lassen, und wo ein überzeugender Prototyp im Alltag zum Ärgernis werden kann.
In einer Demo sieht ein AI Agent schnell souverän aus. Er bekommt eine Aufgabe, greift auf Informationen zu, führt Aktionen aus und liefert am Ende genau das Ergebnis, das man sehen möchte. Auch ein Proof of Concept (POC) kann überzeugend zeigen, dass eine bestimmte Idee technisch funktioniert. Aber damit ist noch nicht bewiesen, dass daraus im Enterprise-Betrieb ein verlässliches Arbeitssystem wird.
Denn dort sieht es anders aus. Und das hat weniger mit dem Modell zu tun als mit dem Umfeld, in das man es hineinstellt: gewachsene Prozesse, Berechtigungslogiken, Legacy-Landschaften, Compliance-Vorgaben, unzählige implizite Ausnahmen, die niemand dokumentiert hat und die trotzdem jeden Tag greifen. An genau dieser Reibung entscheidet sich, ob ein Agent zu einem produktiven Arbeitssystem wird, oder zu einem weiteren netten Experiment, das nach dem Piloten in der Schublade verschwindet.
Die verfügbaren AI-Agent-Plattformen zeigen, was technisch möglich ist. Was sie einem nicht abnehmen, ist die Frage, wie sich diese Möglichkeiten in die Realität des eigenen Unternehmens übersetzen lassen. Bevor sich also die Frage stellt, welchen Agenten man einsetzt, muss eine viel unbequemere Frage geklärt sein: Welche konkrete Arbeit soll ein AI-System im eigenen Unternehmen übernehmen, unter welchen Bedingungen, mit welchem Wissen im Hintergrund und mit welcher Verantwortung im Vordergrund?
Dabei ist „AI Agent” für uns die übergeordnete Kategorie: Je nach Prozess kann daraus ein einzelner Agent, ein Multi-Agent-System oder eine Kombination aus AI, klassischer Software und menschlichen Freigaben entstehen. Die Architektur folgt dem Prozess und nicht umgekehrt.
Genau deshalb fangen wir bei theBlue.ai nicht mit dem Modell an und auch nicht mit der Frage, welchen Agenten man bauen könnte. Wir fangen mit dem Prozess an, so wie er im Unternehmen tatsächlich läuft, mit allen Verzweigungen und Ausnahmen, und leiten daraus eine individuelle Architektur ab.
Wie das im Ergebnis aussehen kann, zeigt ChatRPP: Für die RPP Group, ein Public-Affairs-Beratungshaus mit vertraulichen politischen Dokumenten, haben wir ein Multi-Agent-System gebaut, in dem fünf spezialisierte Agenten als koordiniertes System zusammenarbeiten. Der Zeitaufwand für routinemäßige manuelle Aufgaben konnte dadurch um rund 70 Prozent reduziert werden. Dazu später mehr.
Dieser Artikel zeigt, was hinter einer solchen Lösung steckt, warum Prozessanalyse wichtiger ist als Prompt Engineering und warum bei komplexer Enterprise-Arbeit je nach Prozess ein einzelner Agent, mehrere spezialisierte Agenten oder eine Kombination aus AI, klassischer Software und menschlicher Verantwortung die richtige Architektur sein kann.
Warum ein LLM noch kein Enterprise-Agent ist
Zu den häufigeren Fehlern bei KI-Initiativen gehört der Reflex, eine bestehende Anwendung um ein Sprachmodell zu erweitern und das Ergebnis dann als Agent zu bezeichnen. Ein Dokument wird an ein LLM geschickt, das Modell liefert eine Zusammenfassung, vielleicht kommt noch ein RAG-Layer dazu, vielleicht ein paar API-Aufrufe für den Zugriff auf interne Systeme. Technisch funktioniert das und für einen Proof of Concept (POC) reicht es meistens sogar aus. Aber ein Proof of Concept muss vor allem zeigen, dass etwas grundsätzlich funktioniert. Ein Enterprise-System muss dagegen jeden Tag zuverlässig mit der Realität umgehen.
Diese Realität besteht aus unterschiedlichen Eingaben, wechselnden Zuständigkeiten, Ausnahmen und Abhängigkeiten zu anderen Systemen. Ein produktiver Agent muss deshalb nicht nur Antworten generieren können. Er muss erkennen, welche Information gerade relevant ist, welcher Verarbeitungsschritt als Nächstes ansteht, welche Komponente dafür zuständig ist, welche Daten verwendet werden dürfen und an welchem Punkt ein Mensch übernehmen muss.
Dazu kommen die weniger sichtbaren, im Alltag aber entscheidenden Fragen: Wie wird der Zustand eines Vorgangs über mehrere Schritte hinweg gehalten? Was passiert, wenn ein System nicht erreichbar ist oder ein Agent eine Aufgabe nicht zuverlässig lösen kann? Wie werden Berechtigungen durchgesetzt? Wie lässt sich nachvollziehen, warum ein System eine bestimmte Entscheidung getroffen oder Aktion ausgeführt hat? Und wie fügt sich das Ganze in die bestehende Systemlandschaft ein?
Das LLM ist dabei nur eine von mehreren Komponenten. Der eigentliche Unterschied zwischen einem einfachen GPT-Wrapper und einer maßgeschneiderten Agentenarchitektur liegt in der Systemlogik, die um das Modell herum entsteht: in der Orchestrierung, den Zuständigkeiten, den Kontrollmechanismen und den Übergaben an andere Systeme oder an Menschen.
Ein Enterprise-Agent muss deshalb nicht möglichst autonom sein, nein, er muss zuverlässig, nachvollziehbar und kontrollierbar arbeiten. Genau das ist eine andere Designaufgabe als die reine Optimierung von Modell-Output.
Prozessanalyse vor Prompt Engineering
Aus diesem Grund ist unser erster Schritt bei theBlue.ai nicht die Modellauswahl und auch nicht die Konzeption eines konkreten Agenten, sondern eine ausführliche Analyse des Prozesses, um den es geht. Wir fragen uns: Was passiert dort im Alltag tatsächlich? Wer sucht welche Informationen zusammen, welche Systeme werden geöffnet und welche Entscheidungen treffen die beteiligten Menschen an welcher Stelle? Was ist explizit dokumentiert, und was existiert nur als Erfahrungswissen im Kopf einzelner Mitarbeiter? Und vielleicht die wichtigste Frage: Welche Teile des Prozesses lassen sich sinnvoll mit einem probabilistischen System automatisieren und welche sollten besser in einer deterministischen Logik bleiben?
Gerade dieser letzte Punkt wird in der Praxis häufig unterschätzt. Nicht jeder Prozessschritt braucht ein LLM. Für klar definierte Ableitungen ist eine deterministische Regel schneller, günstiger und nachvollziehbarer. Für den Zugriff auf bekanntes Wissen ist Retrieval das richtige Werkzeug, für die strukturierte Extraktion aus PDFs oft nach wie vor klassische Dokumentenverarbeitung. Ein Agent kommt dort ins Spiel, wo Informationen bewertet, mehrere Schritte miteinander verknüpft oder freie Eingaben interpretiert werden müssen.
Aus dieser Aufteilung entsteht die Architektur und nicht umgekehrt. Erst wenn klar ist, welche Aufgabe welches Werkzeug am besten erfüllt, lässt sich sinnvoll entscheiden, wo ein Agent gebraucht wird, wo klassische Software ausreicht und wo ein Mensch die Verantwortung übernehmen sollte.
Damit verschiebt sich die Perspektive spürbar. Die Frage lautet nicht mehr: „Welche Tätigkeit kann ich automatisieren?” Sondern: „Wie modelliere ich diesen Arbeitsprozess als System, in dem Menschen, Software und AI sinnvoll zusammenarbeiten?”
Ein einzelner Agent kann in diesem System durchaus mehrere Tools verwenden. Umgekehrt kann ein komplexer Prozess mehrere spezialisierte Agenten erfordern. Entscheidend ist am Ende nicht, wie viele Agenten zum Einsatz kommen, sondern welche Architektur den Prozess zuverlässig abbildet, wie klar die Verantwortlichkeiten definiert sind und wie kontrolliert das Zusammenspiel funktioniert.
KEY TAKEAWAY
Nicht das Modell entscheidet über den Erfolg, sondern die Systemlogik, die darum herum gebaut wird. Ein Enterprise-Agent muss nicht möglichst autonom sein. Er muss zuverlässig, nachvollziehbar und kontrollierbar arbeiten, eine grundlegend andere Designaufgabe als die reine Optimierung von Modell-Output.
Ein reales Beispiel: fünf Agenten für einen einzigen Geschäftsprozess
RPP Group ist ein Public-Affairs-Kunde, der an der Schnittstelle von Policy, Politik und Kommunikation arbeitet. Zugang zu einem leistungsfähigen LLM zu bekommen, war für das Haus nie das entscheidende Problem, das kann sich heute jeder besorgen. Das eigentliche Problem lag tiefer: Hochqualifizierte Analysten haben einen erheblichen Anteil ihrer Zeit mit vorhersehbarer, wiederkehrender Arbeit verbracht. Konkret ging es dabei um die Analyse umfangreicher Dokumente, die Strukturierung von Policy-Informationen und die Vorbereitung von Kommunikationsmaterial. Diese Aufgaben verlangen fachliches Verständnis und einen wachen Blick, folgen aber gleichzeitig wiederkehrenden Mustern. Genau diese Kombination hat sie zu einem guten Kandidaten für eine systematische Automatisierung gemacht.
Ein konkretes Beispiel aus dem Alltag: Policy-Dokumente sind selten kurz, hundert Seiten und mehr sind eher die Regel als die Ausnahme. Inhalte müssen extrahiert, strukturiert, gegeneinander abgeglichen und schließlich in einen kommunizierbaren Kontext gebracht werden. Dazu kommt eine harte Randbedingung, die viele Standardlösungen sofort ausschließt: Mit vertraulichen politischen Dokumenten darf die Verarbeitung nicht auf einer beliebigen externen Cloud laufen.
Ein einzelner Chatbot hätte das Problem nur teilweise abbilden können. Aus dieser Mischung aus fachlichem Anspruch, Datenschutzanforderungen und wiederkehrender Struktur ist ChatRPP als Multi-Agent-System mit fünf spezialisierten Agenten, einem Orchestrator und der bestehenden Infrastruktur der RPP Group entstanden.
Die Zahl fünf ist dabei kein Selbstzweck, sie hat sich aus der Arbeitsteilung ergeben. Eine Anfrage wandert nicht in ein einzelnes großes Modell, das den ganzen Prozess in einem Rutsch bewältigen soll. Ein zentraler Orchestrator leitet Anfragen an den passenden Spezialisten weiter, etwa für Dokumentenanalyse, Inhaltserstellung, strategische Planung oder Policy-Recherche, und stellt den für den jeweiligen Verarbeitungsschritt benötigten Kontext und die passenden Werkzeuge bereit. So wird aus mehreren spezialisierten Agenten ein koordiniertes Arbeitssystem statt eines einzelnen Allzweck-Chatbots.
Wie aus fünf spezialisierten Agenten ein produktives Arbeitssystem wurde: Zur RPP Case Study.
Warum Spezialisierung in Multi-Agent-Systemen relevant wird
Je komplexer ein Prozess ist, desto sorgfältiger muss geprüft werden, ob ein einzelner universeller Agent wirklich die passende Architektur ist. Ein System, das Dokumente analysiert, im Web recherchiert, interne Daten interpretiert, Inhalte formuliert, Compliance-Regeln einhält und Ergebnisse kontrolliert, kann technisch als ein Agent umgesetzt werden. Für bestimmte Prozesse kann eine Aufteilung auf spezialisierte Agenten jedoch sinnvoller sein, wenn unterschiedliche Aufgaben unterschiedliche Kontexte, Werkzeuge, Berechtigungen oder Kontrollmechanismen erfordern. Multi-Agent ist dabei kein Selbstzweck, sondern eine mögliche Architekturentscheidung.
Ein Team aus spezialisierten Agenten lässt Aufgaben und Verantwortlichkeiten sauber voneinander trennen. Der Orchestrator koordiniert, die einzelnen Spezialisten übernehmen jeweils klar definierte Verarbeitungsschritte, Datenquellen werden gezielt und in kontrollierten Bahnen eingebunden, und Zwischenergebnisse können auf dem Weg durch die Kette geprüft, ergänzt oder verworfen werden. Damit ändert sich auch, was Qualität in einem solchen System bedeutet. Es geht weniger darum, wie gut ein einzelnes LLM auf einem Benchmark abschneidet, und mehr darum, wie robust die gesamte Kette aus Routing, Retrieval, Verarbeitung, Generierung und Kontrolle in der täglichen Produktion trägt. Für einen Enterprise-Kontext ist das die relevantere Perspektive.
Bei ChatRPP haben wir für diese Aufgabe Multi-Agent-Orchestrierung, mehrere LLMs, RAG, Dokumentenverarbeitung und klassische Python-Logik kombiniert, den branchen-spezifischen Dienst Policy-Insider.AI integriert und den ganzen Betrieb innerhalb einer DSGVO-konformen Infrastruktur aufgesetzt. Wer sich diese Zutatenliste anschaut, merkt schnell, warum „AI Agent” als alleinige technische Kategorie das Produkt nur unvollständig beschreibt. Produktiv läuft hier kein isolierter Agent, sondern eine individuelle AI-Architektur, in der mehrere spezialisierte Agenten mit klassischen Softwarekomponenten, Datenquellen und Governance zusammenspielen.
Die Datenfrage ist keine Fußnote
In Agenten-Demos wird Integration üblicherweise als Komfortfunktion verkauft: Der Agent kann sich mit Slack, CRM, Kalender und Dokumentenablage verbinden und dadurch mehr für seine Nutzer erledigen. Im Enterprise ist Zugriff aber selten eine Komfort- und fast immer eine Governance-Frage. Was darf ein Agent überhaupt lesen, welche Informationen darf er über Systemgrenzen hinweg miteinander verknüpfen, was darf er selbst verändern, und was muss er einem Menschen zur Freigabe vorlegen? Und mindestens genauso wichtig: Wie wird protokolliert, wer wann was ausgelöst hat, damit ein bestimmter Output auch Wochen später noch nachvollziehbar bleibt?
Diese Fragen gehören von Anfang an in die Architektur. Agenten müssen innerhalb sauber definierter Berechtigungen arbeiten, bei sensiblen Aktionen pausieren, auf Freigaben warten und im Zweifel lieber zu wenig als zu viel tun. Governance ist deshalb kein Zubehör, das man einem fertigen Agenten später anschraubt, sondern ein Teil seiner Konstruktion.
Für eine individuelle Enterprise-Lösung reicht es dabei nicht, ein generisches Governance-Modell aus dem Regal zu nehmen. Ein Marketing-Agent, der einen Blog-Entwurf schreibt, braucht eine andere Freigabelogik als ein Agent, der mit vertraulichen Finanzdaten hantiert oder Datensätze in einem produktiven System verändert. Individuelle Architektur bedeutet in der Konsequenz auch individuelle Governance, und wer das eine will, kommt am anderen selten vorbei.
Legacy-Integration ist der eigentliche Architekturtest
Demos funktionieren dort am besten, wo alle beteiligten Systeme bereits saubere APIs mitbringen. Die Enterprise-Realität sieht meistens weniger aufgeräumt aus. Daten liegen in einem Sammelsurium von Anwendungen, manche davon modern und dokumentiert, andere über zehn oder fünfzehn Jahre gewachsen und nur noch von einer Handvoll Menschen im Haus wirklich verstanden. Berechtigungsmodelle sind zwischen den Systemen selten kompatibel, und ein nicht kleiner Teil der eigentlichen Prozessarbeit läuft immer noch über E-Mail-Verkehr, Excel-Anhänge und manuelle Übergaben zwischen Abteilungen. Ausgerechnet an diesen Nahtstellen entscheidet sich, ob ein Agent tatsächlich Arbeit übernimmt oder am Ende nur eine hübschere Oberfläche für dieselben alten Handgriffe wird.
Eine maßgeschneiderte Lösung muss deshalb weit mehr beantworten als die Frage, was das Modell am Ende ausgeben soll. Zu klären ist zum Beispiel, welches System für welche Information die Source of Truth ist, wann eine Information live abgerufen werden muss und wann sie zwischengespeichert werden darf. Ebenso wichtig ist die Frage, wie der Zustand eines mehrstufigen Prozesses gehalten wird, was passiert, wenn zwei Systeme widersprüchliche Angaben liefern oder ein Tool-Aufruf fehlschlägt und welche Schritte sich überhaupt sinnvoll rückgängig machen lassen. Und natürlich muss klar sein, an welchen Stellen ein Mensch eingebunden wird und welche Aktionen später auditierbar sein müssen.
Im Kern sind das klassische Architekturfragen, die jeder Software-Architekt kennt. Neu ist der Kontext: Sie stellen sich heute innerhalb probabilistischer Systeme, deren Verhalten sich nicht mehr vollständig in einer Wahrheitstabelle abbilden lässt. Genau deshalb reicht es im AI-Engineering nicht, nur die Schnittstellen zwischen Systemen zu verbinden. Man muss auch definieren, wie ein System mit Unsicherheit, Fehlern und Entscheidungen umgeht.
Der wirtschaftliche Wert entsteht nicht durch gute Antworten
Diese architektonische Sorgfalt zahlt am Ende auf einen sehr wirtschaftlichen Punkt ein. Bei RPP Group lässt sich der Unterschied zwischen Technologie-Demo und tatsächlichem Business Case besonders deutlich beobachten. Das Ziel war nie, mit besonders beeindruckenden Antworten zu glänzen. Das Ziel war, Senior-Analysten von der Sorte Arbeit zu entlasten, die zwar Zeit frisst, aber ihre Expertise gar nicht braucht. Die Case Study spricht von rund 70 Prozent weniger Zeitaufwand für routinemäßige manuelle Aufgaben. Analyse- und Drafting-Schritte, die vorher Stunden gebraucht haben, sind heute in Minuten erledigt, und die Ergebnisse fließen direkt in die täglichen Workflows der Analysten ein.
Das ist eine ganz andere Metrik als die klassischen LLM-Benchmarks, mit denen die Fachpresse gerne operiert. Für einen CTO ist es letztlich zweitrangig, ob ein Modell auf MMLU oder einem anderen Testset zwei Prozentpunkte oben oder unten liegt. Interessant wird es dort, wo sich ein realer Geschäftsprozess strukturell verändert oder ganz aus dem Alltag verschwindet. Weniger Zeit für Routineaufgaben ist im Kern nichts anderes als gewonnene Kapazität. Und diese Kapazität wird bei RPP Group jetzt in strategische und kundennahe Arbeit investiert.
Custom bedeutet nicht, alles selbst zu bauen
„Custom AI” wird manchmal so verstanden, als würde man für jedes Unternehmen ein eigenes Foundation Model trainieren. Das ist verständlich, aber falsch, und es beschreibt unseren Ansatz gerade nicht. Maßanfertigung bedeutet aus unserer Sicht etwas anderes: die Freiheit zu haben, für jedes Problem die passende Abstraktionsebene zu wählen.
Das Basismodell darf durchaus von einem externen Anbieter kommen, RAG ist häufig die pragmatische Wahl, bestehende APIs bleiben ohne Ersatzaufwand in Betrieb, und auch fertige Komponenten für Dokumentenverarbeitung oder Agenten-Orchestrierung dürfen zum Einsatz kommen, wenn sie zum Problem passen. Custom wird die Lösung erst dort, wo diese Bausteine zu einem spezifischen Unternehmenssystem zusammengesetzt werden, das genau die Prozesse abbildet, um die es im Haus tatsächlich geht.
Die eigentliche Ingenieursarbeit steckt entsprechend nicht im Modell selbst, sondern in Prozessdesign, Systemarchitektur, Orchestrierungslogik, Datenzugriff, State-Management, Governance-Regeln, der Integration in die bestehende IT-Landschaft und, oft am meisten unterschätzt, in der Evaluation.
Genau darum verstehen wir die Prozessanalyse als eigenständigen Schritt, den man nicht mit der Implementierungsvorbereitung verwechseln sollte. Sie entscheidet, was überhaupt gebaut werden sollte, und in vielen Fällen auch, was besser nicht gebaut wird, weil es sich schlicht nicht lohnt.
Vom Feature zur Infrastruktur
Wenn Unternehmen anfangen, individuelle AI-Systeme in reale Prozesse einzuflechten, statt sie als Einzelanwendungen zu behandeln, entsteht in der Systemlandschaft eine neue Ebene zwischen Mensch und Unternehmenssoftware. ERP, CRM, DMS, Collaboration Tools und interne Datenbanken laufen weiter wie bisher, aber darüber entsteht eine Prozessschicht, die Informationen zwischen diesen Systemen bewegt und Aufgaben über mehrere Anwendungen hinweg koordiniert.
Standardisierte Agenten sind für viele generische Aufgaben eine gute Wahl. Sobald aber unternehmensspezifisches Wissen, proprietäre Prozesse, sensible Daten und eine gewachsene Systemlandschaft zusammenkommen, kann eine individuell entworfene Lösung zum entscheidenden Hebel werden. Dabei braucht nicht jeder Prozess gleich fünf Agenten, und ehrlich gesagt braucht auch nicht jeder Prozess überhaupt einen.
Manches sollte deterministisch bleiben, weil ein probabilistisches System dort keinen zusätzlichen Nutzen bringt. Anderes profitiert von einem einzelnen, klar abgegrenzten AI-Schritt in einer ansonsten konventionellen Anwendung. Und wieder andere Prozesse entfalten ihr Potenzial erst, wenn mehrere spezialisierte Agenten unter einem Orchestrator gemeinsam der Arbeitslogik eines Unternehmens folgen.
Die entscheidende Kompetenz besteht darin, für jeden Prozess ehrlich zu bewerten, ob ein AI-System für diese konkrete Form von Arbeit wirklich die passende Architektur ist, oder ob eine schlichtere Lösung dem Unternehmen mehr bringt.
Aus Prozessen werden produktive AI-Systeme
An genau dieser Stelle setzt unsere Arbeit bei theBlue.ai an. Wir entwickeln keine generischen Agenten für einen unspezifischen Kundenkreis. Am Anfang jeder Zusammenarbeit steht eine ausführliche Analyse davon, wie die Arbeit in einem bestimmten Unternehmen tatsächlich läuft: welche Entscheidungen getroffen werden, welche Informationen zusammengeführt werden müssen, welche Systeme beteiligt sind und an welchen Stellen menschliche Expertise unverzichtbar bleibt.
Wenn Sie wissen möchten, welche Prozesse in Ihrem Unternehmen sich für eine individuelle AI-Lösung eignen, sprechen wir gerne darüber. Statt mit einem Produktkatalog zu beginnen, starten wir mit einer konkreten Prozessanalyse und schauen gemeinsam darauf, wo AI tatsächlich Arbeit abnehmen kann, ob ein einzelner Agent, ein Multi-Agent-System oder eine andere Architektur sinnvoll ist und wo eine Automatisierung wirtschaftlich Sinn ergibt, und auch wo nicht.
Von der Prozessanalyse bis zum produktiven AI-System: theBlue.ai entwickelt individuelle Lösungen für die Arbeitsabläufe, die in Ihrem Unternehmen wirklich zählen. Kontaktieren Sie uns für ein unverbindliches Erstgespräch. Wir hören zunächst zu.
Ein LLM, das an eine bestehende Anwendung angeflanscht wird, ist noch kein Enterprise-Agent. Zuverlässigkeit, Nachvollziehbarkeit und Kontrolle zählen mehr als reine Autonomie.
Prozessanalyse kommt vor Modell- oder Agentenauswahl. Nicht jeder Schritt profitiert von einem probabilistischen System, manches bleibt besser deterministisch.
ChatRPP zeigt, was Spezialisierung in der Praxis bringt: Fünf Agenten unter einem Orchestrator übernehmen bei der RPP Group rund 70 Prozent der Routinearbeit.
Ein einzelner Universal-Agent ist meist ein Kompromiss. Spezialisierte Agenten mit klar definierten Verantwortlichkeiten halten im produktiven Betrieb besser stand.
Datenzugriff ist von Anfang an eine Governance-Frage, kein Feature, das man einem fertigen Agenten nachträglich anschraubt.
Legacy-Systeme, uneinheitliche APIs und manuelle Übergaben sind der eigentliche Architekturtest, nicht die saubere Demo-Umgebung.
Der wirtschaftliche Wert entsteht durch gewonnene Kapazität, nicht durch beeindruckende Antworten auf einer Benchmark-Tabelle.
Custom heißt nicht, alles selbst zu bauen. Es heißt, für jeden Teil des Problems die richtige Abstraktionsebene zu wählen.
Über die Autorin
Julia Rose, Marketing Lead, theBlue.ai
Julia ist seit 2019 Teil von theBlue.ai und begleitet die Entwicklung von KI-Anwendungen im Enterprise-Umfeld seit den frühen Tagen des Unternehmens. In ihrer Rolle als Marketing Lead arbeitet sie eng mit den Engineering- und Consulting-Teams zusammen und macht komplexe technische Themen für Entscheider verständlich und zugänglich.
In ihren Artikeln schreibt sie über praktische Erfahrungen aus Enterprise-AI-Projekten sowie über die Herausforderungen und Chancen beim Einsatz von KI in Unternehmen.