Im letzten Artikel ging es um die Reife vor dem ersten Agenten. Am Ende stand dort eine Frage, die harmloser klingt, als sie ist: Wer prüft eigentlich, was der Agent produziert?
Genau dort hört Readiness auf. Und Governance fängt an.
Die meisten denken bei dem Wort an Richtlinien, Freigabematrizen und ein PDF, das niemand öffnet. In der Praxis läuft es auf drei Fragen hinaus:
Wer setzt welchen Agenten wofür ein? Wer sieht sich das Ergebnis an, bevor es das Haus verlässt? Und wohin geht es, wenn etwas nicht stimmt?
Fallen die Antworten im Team gleich aus, existiert Governance bereits. Ganz ohne Dokument. Fallen sie unterschiedlich aus, ändert daran auch das schönste Regelwerk nichts.
Bei der AIC Group haben wir das nach und nach gemerkt. Erst kam ein zweites Themengebiet dazu, dann weitere Aufgaben, weitere Wissensdateien, weitere Leute, die mit dem Agenten arbeiten. Jede Erweiterung für sich war klein.
Nur bleibt bei einem Agenten nichts für sich stehen. Eine neue Wissensdatei beantwortet nicht nur die neue Frage, sie mischt sich in die alten ein. Eine zusätzliche Regel kann eine bestehende aushebeln, ohne dass es jemandem auffällt, bis das erste Ergebnis daneben liegt. Und je mehr Leute mit ihm arbeiten, desto weniger merkt man, dass sie ihn unterschiedlich verstehen.
Die eigentliche Arbeit beim Erweitern ist deshalb nicht das Hinzufügen. Sie liegt in der Frage, ob das Neue mit dem Vorhandenen zusammenspielt und ob die Leitplanken von damals noch reichen. Das war der Moment, in dem aus einer Arbeitsweise eine Absprache werden musste.
Zwei Muster sehen wir immer wieder. Die einen wollen erst alles geregelt haben und fangen deshalb nie an. Die anderen legen los, und das sind deutlich mehr. Sie machen sich durchaus Gedanken darüber, wer prüft und was der Agent besser nicht tun soll. Nur bleiben diese Gedanken im Kopf. Ein halbes Jahr später weiß niemand mehr genau, was davon vereinbart war.
Beim Zuschnitt. Wer Rolle, Aufgabe und Kontext eines Agenten sauber beschreibt, hat die Einordnung faktisch schon vorgenommen. Über das Risiko entscheidet nämlich nicht das System, sondern der Einsatzzweck. Dasselbe Sprachmodell ist als interne Recherchehilfe unkritisch und im Bewerbungsprozess ein Hochrisiko-Fall. Ableiten lässt sich das nur aus der Frage, wofür der Agent da sein soll. Mit der beginnt ohnehin jedes vernünftige Agentenprojekt. Die KI-Verordnung formalisiert hier also, was Governance sowieso meint.
Bei den Leitplanken. Der System Prompt ist der Ort, an dem Grenzen tatsächlich wirken. Was der Agent nicht tun soll, wo er nachfragt, wann er abgibt: Das steht dort, nicht in einer Anlage zum Projekthandbuch.
Bei der Optimierung. Ein Agent, der ein Jahr läuft, macht selten dasselbe wie am ersten Tag. Aufgaben wachsen, Zugriffe kommen dazu, jemand hat eine Idee. Die Frage ist nicht nur, ob der Output besser wird, sondern ob sich der Einsatzzweck verschoben hat.
Die Agenten-Landkarte. Sie zeigt, was wo läuft: welche Agenten es gibt, aus welchen Quellen sie schöpfen, in welchen Teams sie im Einsatz sind und in welche Richtung das Ganze wächst. Wir legen sie früh an und schreiben sie fort. Für Governance ist sie das wichtigste davon, weil sich an ihr Fragen beantworten lassen, die sonst offenbleiben. Wer greift außer diesem einen Agenten noch auf diese Quelle zu? Was hängt an einer Änderung, die gerade harmlos aussieht? Und wenn ein Agent mehr Zugriff oder mehr Spielraum bekommen soll: Ist das noch derselbe Einsatzzweck wie am Anfang? Auf einer Übersicht sieht man das sofort. Über viele einzelne Dokumente verteilt sieht es niemand.
Das Agentenkonzept. Je Agent eine lesbare Bauanleitung. Sie hält fest, welche Rolle der Agent hat, welche Aufgaben er unterstützt, wo seine Grenzen liegen, wer prüft und freigibt und ab wann ihr das selbst verantwortet. Mit Versionsstand und Datum. Es ist das einzige Dokument, das auch jemand versteht, der nie mit dem Agenten arbeitet: Geschäftsführung, Datenschutz, Betriebsrat, die Nachfolgerin im Team. Was nur im System Prompt steht, ist für diese Leute unsichtbar.
Das übergreifende Konzept. Sobald mehrere Agenten zusammenarbeiten sollen, reicht das Einzelkonzept nicht mehr. Wer darf was, wo wird übergeben, wo greift der Mensch ein. Wir leiten es aus den Einzelkonzepten ab. Was vorher aufgeschrieben wurde, zahlt sich hier aus.
Beim dritten Punkt sind wir selbst noch am Anfang und probieren gerade aus, wie das aussehen kann. Eines ist uns dabei von vornherein klar: Wenn Agenten zusammenarbeiten, die einzeln noch nicht sauber laufen, vervielfachen sich ihre Fehler. Die Reife der einzelnen Agenten ist keine Vorstufe, die man überspringt. Sie ist die Voraussetzung.
Eine Reihenfolge verhandeln wir nicht: Governance vor Autonomie. Erst die Leitplanken, dann die Freiheiten. Umgekehrt geht es eine Weile gut und dann nicht mehr.
Im Alltag heißt das bei uns: Der Agent schlägt vor, wir bestätigen, dann wird umgesetzt. Das ist kein Dogma, sondern die Konsequenz aus der Reihenfolge. Wie viel ein Agent allein erledigt, verschiebt sich mit seiner Reife und mit der Aufgabe. Was sich nicht verschieben darf, ist die Reihenfolge: Erst wird besprochen und aufgeschrieben, was er darf, dann bekommt er den Spielraum. Nicht andersherum, und nicht nebenbei.
Das klingt nach einer Bremse und ist das Gegenteil. Wer weiß, dass jemand draufschaut, kann den Agenten früher und mutiger einsetzen. Und wer die Leitplanken einmal bewusst gesetzt hat, kann sie später bewusst weiter stecken. Ohne sie wird jede Ausweitung zur Zitterpartie
Readiness klärt, ob das Team tragen kann. Governance klärt, wer was verantwortet. Bleibt die dritte Frage, und sie ist die unbequemste: Bringt das eigentlich etwas?
Darum geht es beim nächsten Mal.
Schreibt uns. Wir teilen unser Vorgehen gern.
Weitere Artikel…
„Sind wir reif für KI?“ – die Frage klingt nach Selbsteinschätzung, nach Bauchgefühl, nach einem komplizierten Reifegrad-Modell. So gestellt, lähmt sie. Sie ist zu groß, um eine klare Antwort zuzulassen.
Aus einer großen, vagen Frage werden drei konkrete, die man beantworten kann. Wir nennen sie Wissens-, Prozess- und Aufsichts-Readiness.
Je besser unser KI-Agent wird, desto größer die Versuchung, vor allem mit ihm zu arbeiten. Und seltener mit den Kolleginnen und Kollegen, deren Einarbeitung länger dauert und deren Rückmeldung nicht immer entspannt ausfällt.
Über unseren KI-Agenten sagen wir gern einen Satz: Er ist kein Texter, sondern ein Sparringspartner. – In den ersten drei Teilen dieser Reihe ging es darum, ihn dazu zu machen. Wie wir bei der AIC Group GmbH intern angefangen haben. Warum die Wissensdatenbank mehr entscheidet als der perfekte Prompt. Und zuletzt, dass ein Agent nicht durch Nutzung besser wird, sondern durch Pflege.
*Artikel sind teilweise mit der KI erstellt.
Vor einigen Monaten haben wir bei der AIC Group GmbH begonnen, intern einen KI-Agenten aufzubauen. Nicht als formales Pilotprojekt. Nicht mit externer Agentur. Nicht über ein IT-Ticket.
Dass das Thema gerade überall ist, war auch auf der OMR in Hamburg deutlich zu spüren: Keynotes, Podiumsdiskussionen, Pausengespräche. Was uns dabei auffiel: Viele Unternehmen wissen, dass sie sich mit Agentic AI auseinandersetzen sollten. Aber der Einstieg fühlt sich oft groß an. Nach IT. Nach Budget. Nach externer Lösung. Nach Zeit, die gerade fehlt.
Genau dieses Muster kennen wir. Und wir wissen inzwischen aus eigener Erfahrung: Es gibt einen anderen Weg.
Der Use Case: Content Creation. Konkret die Planung und Ausarbeitung unserer LinkedIn- und Instagram-Posts.
Warum genau dieser Use Case? Weil er niedrigschwellig ist. Marketingcontent ist öffentlich zugänglich – er enthält keine vertraulichen Informationen, keine sensiblen Daten. Man braucht kein aufwändiges Datenprojekt, um zu starten. Was man braucht, ist ein klares Vorgehen.
Ein funktionierender Agent ist kein Zufallsprodukt. Er entsteht durch Entscheidungen – und durch Iteration. Unser Prozess folgt sechs Phasen.
Phase 1 – Rolle & Ziel definieren
Wofür soll der Agent eingesetzt werden? Was sind seine Aufgaben – und was ausdrücklich nicht? Ohne diese Klarheit bleibt der Agent generisch.
Phase 2 – System Prompt entwickeln
Der System Prompt ist das Herzstück. Er definiert Kontext, Rolle, Tonalität, Arbeitsweise und Qualitätsansprüche. Er macht den Agenten nicht kreativ – er macht ihn verlässlich.
Phase 3 – Wissensdatenbank aufbauen
Ein Agent ist nur so gut wie das Wissen, das ihm zur Verfügung steht. Wir haben dafür strukturierte Dokumente erstellt: Positionierungsgrundlagen, Sprachregeln, Designvorgaben, Redaktionspläne.
Drei Typen von Quellen haben sich dabei bewährt: strategisch-fachliche Dokumente, Stil- und Formatvorgaben sowie Planungsunterlagen.
Wissen schlägt Prompt-Länge.
Phase 4 – Skills entwickeln
Für wiederkehrende Aufgaben haben wir vordefinierte Arbeitsanweisungen entwickelt – sogenannte Skills. Sie sorgen dafür, dass der Agent konsistente, reproduzierbare Ergebnisse liefert, ohne jedes Mal neu instruiert zu werden.
Die Wissensdatenbank liefert das Was und Warum, der Skill das Wie.
Phase 5 – Arbeiten mit dem Agenten
Ein Agent ist kein Texter. Er ist ein Sparringspartner.
Dialog statt perfekter Prompts. Feedback statt Neuanfang.
Wer so arbeitet, kommt schneller zu besseren Ergebnissen.
Phase 6 – Kontinuierlich optimieren
Jeder falsche Output ist eine Lernchance. Die Optimierungsschleife – Fehler erkennen, Ursache identifizieren, nachschärfen – ist entscheidend für die langfristige Qualität.
Jeder falsche Output macht den Agenten besser.
In Gesprächen mit anderen Unternehmen – und beim Besuch von KI-Anbietern, die uns ihre Lösungen vorstellen – beobachten wir dasselbe Muster immer wieder.
Viele Anbieter bauen Oberflächen, die genau das zugänglich machen, was einen Agenten ausmacht: System Prompt, Wissensdatenbank, vordefinierte Arbeitsanweisungen. Dahinter steckt ein Sprachmodell, ergänzt um Integrationen – in die Website, ins CMS, in bestehende Workflows.
Das ist kein schlechter Ansatz. Aber er löst eine Herausforderung nicht: Den Unterbau sauber aufzubauen.
Was soll der Agent wissen? Wie soll er kommunizieren? Welche Aufgaben soll er reproduzierbar erledigen? Diese Arbeit bleibt immer. Egal ob mit eigenem Agenten oder mit einem Dienstleister.
Genau das hat unsere Entscheidung bestätigt: Wir bauen den Unterbau selbst. Nicht weil wir Tools ablehnen – sondern weil wir verstehen wollen, was einen guten Agenten ausmacht. Und weil dieses Wissen wiederverwendbar ist. Für den nächsten Use Case. Und den übernächsten.
