KI-Agenten brauchen mehr als AI-Act-Checklisten

Auf X wird gerade viel über zwei Dinge gleichzeitig gesprochen: KI-Agenten werden in Unternehmen realer, und der EU AI Act rückt als operativer Druckpunkt näher. Dazwischen liegt ein Thema, das für deutsche Produktteams wichtiger ist als die nächste Tool-Debatte.

KI-Agenten brauchen Architektur.

Nicht Architektur im Sinne von Diagrammen für die Schublade. Gemeint ist die praktische Frage, wie ein System funktioniert, wenn KI nicht nur Text generiert, sondern Daten liest, Tools aufruft, Entscheidungen vorbereitet, Code ändert, Workflows auslöst oder interne Prozesse beeinflusst.

Für Gründer, CTOs, Product Owner und Mittelstandsteams ist das ein guter Moment, kurz zu bremsen. Nicht, um KI zu vermeiden. Dafür ist der Nutzen zu groß. Sondern um sie so einzubauen, dass sie später nicht zu einem Risiko, einem Compliance-Schmerz oder einer schwer wartbaren Black Box wird.

Der EU AI Act ist dabei nicht der eigentliche Grund, sauber zu arbeiten. Er macht nur sichtbar, was gute Softwareentwicklung ohnehin braucht: Inventar, Grenzen, Nachvollziehbarkeit, Review-Pfade, Verantwortlichkeiten und Betriebskonzepte.

Oder kürzer: Wer KI-Agenten ernsthaft einsetzen will, sollte nicht mit einer Compliance-Checkliste anfangen. Er sollte mit der Systemarchitektur anfangen.

Warum der aktuelle X-Trend relevant ist

Die Diskussion der letzten Tage zeigt ein klares Muster. Unternehmen experimentieren nicht mehr nur mit Chatbots am Rand. Sie schauen auf Agenten, die Aufgaben übernehmen: Recherche, Support, Softwareentwicklung, Prozessautomatisierung, Compliance-Workflows, interne Tools, Datenaufbereitung, Reporting.

Parallel wird auf X über Auditability, Logging, AI Act Readiness, Traceability, Runtime Control Planes und agentische Sicherheit gesprochen. Manche Posts sind überdreht, manche vermischen Timelines unsauber, aber das Grundproblem ist real.

Ein KI-Agent ist operativ anders als ein klassisches Feature.

Ein klassisches Feature tut im Idealfall genau das, was im Code steht. Ein Agent arbeitet mit Wahrscheinlichkeiten, Kontext, Tools, Instruktionen und oft mehreren Zwischenschritten. Er kann unterschiedliche Pfade nehmen, auch wenn der Nutzer dieselbe Art von Aufgabe stellt. Er kann mit Daten interagieren, deren Sensibilität erst zur Laufzeit sichtbar wird. Und er kann Ergebnisse erzeugen, die Menschen als Entscheidungshilfe verwenden.

Das heißt nicht, dass Agenten unkontrollierbar sind. Es heißt nur, dass Kontrolle explizit gebaut werden muss.

Genau hier berühren sich AI Act, Softwarearchitektur und Produktverantwortung.

Der AI Act ist kein PDF-Projekt

Viele Teams werden versucht sein, den EU AI Act als juristisches Dokumentationsprojekt zu behandeln. Irgendwann erstellt jemand eine Policy. Ein Vendor-Fragebogen wird ausgefüllt. Eine Risikoanalyse landet in einem Ordner. Fertig.

Das wird für viele reale KI-Systeme nicht reichen.

Die wichtigsten Fragen sind nicht nur juristisch. Sie sind technisch und operativ:

• Wo im Produkt oder Unternehmen wird KI bereits genutzt?
• Welche Systeme beeinflussen Nutzer, Kunden, Mitarbeiter oder geschäftliche Entscheidungen?
• Welche Daten sieht ein Agent?
• Welche Tools darf er aufrufen?
• Wer prüft kritische Ergebnisse?
• Welche Version von Modell, Prompt, Tool und Datenbasis war beteiligt?
• Wie wird ein Fehler erkannt, erklärt und zurückgerollt?
• Wer ist Anbieter, Betreiber, Nutzer oder Verantwortlicher im konkreten Prozess?

Wenn diese Antworten erst nachträglich zusammengesucht werden müssen, ist das ein Architekturproblem. Nicht nur ein Compliance-Problem.

Für viele deutsche Unternehmen wird genau das die unbequeme Stelle sein. Die KI-Nutzung ist oft schneller gewachsen als die Systemlandkarte. Einzelne Teams nutzen Copilots, Chatbots, Automationen, interne Skripte, SaaS-Funktionen, OpenAI- oder Azure-basierte Helfer, vielleicht auch lokale Modelle. Jedes Tool wirkt für sich genommen klein. Zusammen entsteht aber ein operatives KI-System ohne klares Inventar.

Der erste Schritt ist deshalb unspektakulär, aber stark: aufschreiben, wo KI tatsächlich im Spiel ist.

Ein KI-Inventar ist Architekturarbeit

Ein gutes KI-Inventar ist keine Excel-Liste für die Ablage. Es ist eine Arbeitsgrundlage für Produkt, Engineering, Operations und Compliance.

Es sollte nicht nur Toolnamen enthalten. Nützlicher sind Fragen wie:

• Welche Aufgabe übernimmt die KI?
• Ist sie nur assistierend oder beeinflusst sie eine Entscheidung?
• Welche Nutzergruppe ist betroffen?
• Welche Daten fließen hinein und heraus?
• Welche externen Anbieter sind beteiligt?
• Welche Aktionen kann das System auslösen?
• Gibt es menschliche Freigabe?
• Gibt es Logs, Tests, Monitoring und Rollback?
• Wem gehört das System fachlich und technisch?

Diese Fragen wirken trocken. In der Praxis sparen sie Zeit, weil sie spätere Diskussionen konkret machen. Ein KI-Assistent, der Marketingtexte vorschlägt, braucht andere Kontrollen als ein Agent, der Bewerber vorsortiert, Supportfälle priorisiert, Rechnungen vorbereitet oder produktiven Code ändert.

Nicht jedes KI-System ist hochriskant. Nicht jedes braucht denselben Aufwand. Aber ohne Inventar kann ein Team diese Unterscheidung nicht belastbar treffen.

Bei McDougall Digital ist genau das der Punkt, an dem wir Architektur und Produktjudgement zusammenbringen. Die Frage ist nicht “Wie machen wir alles möglichst bürokratisch?” Die Frage ist: Welche Entscheidungen sind riskant genug, dass das System bessere Grenzen, Nachweise und Review-Pfade braucht?

Agenten brauchen Grenzen, nicht nur gute Prompts

Viele KI-Projekte beginnen mit Prompt Engineering. Das ist verständlich, aber zu eng. Ein guter Prompt ist hilfreich. Er ist aber keine Zugriffskontrolle, kein Audit-Log, kein Rollback-Konzept und kein Sicherheitsmodell.

Sobald ein Agent Tools nutzen darf, wird die Grenze wichtiger als die Formulierung.

Ein sinnvoller Agent sollte nicht einfach mit den Rechten eines Menschen laufen. Er braucht eine eigene Identität, einen begrenzten Aufgabenbereich und klare Regeln darüber, was er lesen, schreiben, ausführen und auslösen darf. Das gilt für interne Business-Tools genauso wie für Coding-Agenten in Softwareteams.

Praktisch bedeutet das:

• separate Agenten-Identitäten statt geteilter Nutzerkonten
• minimale Berechtigungen statt pauschalem Zugriff
• zeitlich begrenzte Tokens statt dauerhafter Secrets
• Freigabe für riskante Aktionen
• getrennte Umgebungen für Test, Staging und Produktion
• klare Blockaden für besonders sensible Daten oder Systembereiche
• nachvollziehbare Protokolle jeder wichtigen Aktion

Das klingt nach Security, ist aber auch Produktqualität. Ein Agent, der zu viel darf, macht das System schwerer zu verstehen. Ein Agent, der klar begrenzt ist, lässt sich testen, betreiben und verbessern.

Gerade im Mittelstand ist das wichtig. Viele Unternehmen wollen pragmatische KI-Lösungen, keine riesigen Plattformprogramme. Das ist vernünftig. Aber Pragmatismus heißt nicht, einem Agenten einen Generalschlüssel zu geben. Pragmatismus heißt, die wenigen Grenzen zu bauen, die wirklich zählen.

Logging ist kein nachträglicher Luxus

Wenn ein KI-Agent in einem relevanten Prozess arbeitet, muss später nachvollziehbar sein, was passiert ist. Nicht aus Misstrauen gegenüber KI, sondern aus normaler operativer Verantwortung.

Gute Logs beantworten Fragen wie:

• Wer oder was hat den Agenten gestartet?
• Welche Aufgabe wurde gestellt?
• Welche Datenquellen wurden genutzt?
• Welche Tools wurden aufgerufen?
• Welche Modell- oder Promptversion war aktiv?
• Welche Ausgabe wurde erzeugt?
• Welche menschliche Prüfung gab es?
• Welche Änderung wurde übernommen?
• Welche Folgeaktion wurde ausgelöst?

Diese Informationen sind nicht nur für Compliance nützlich. Sie helfen beim Debugging, bei Supportfällen, bei Sicherheitsanalysen, bei Produktverbesserung und bei der Frage, ob ein KI-Workflow überhaupt zuverlässig genug ist.

Viele Teams bauen Logging erst, wenn etwas schiefgeht. Bei KI ist das besonders teuer, weil Fehler ohne Spuren schwer zu erklären sind. Wenn ein Agent eine falsche Empfehlung gibt, eine falsche Datei ändert oder einen Prozess falsch priorisiert, reicht “das Modell hat es so gemacht” nicht als Antwort.

Die bessere Lösung ist, Evidenz in den Workflow einzubauen. Nicht übertrieben, nicht überall gleich, aber dort, wo Entscheidungen, Rechte oder Kundenauswirkungen im Spiel sind.

Human-in-the-loop muss konkret sein

“Ein Mensch prüft das” klingt beruhigend. In vielen Systemen ist es aber zu vage.

Wer prüft was? Vor oder nach der Aktion? Nach welchen Kriterien? Mit welchen Informationen? Wird die Prüfung protokolliert? Kann die Person die Entscheidung wirklich ablehnen oder nur abnicken? Was passiert bei Unsicherheit?

Ein echter Review-Pfad ist ein Produktdetail, kein Slogan.

Bei einem internen Reporting-Agenten kann es reichen, dass ein Teammitglied die Zusammenfassung liest, bevor sie verschickt wird. Bei einem Agenten, der Vertragsrisiken markiert, braucht es vielleicht einen fachlichen Review. Bei einem Coding-Agenten, der Datenbankmigrationen erstellt, braucht es Tests, Code Review, Staging und klare Deployment-Regeln. Bei einem HR- oder Kreditprozess können zusätzliche rechtliche Anforderungen greifen.

Der Punkt ist: Human-in-the-loop muss zur Aufgabe passen.

Ein guter Architekturprozess unterscheidet deshalb zwischen niedriger, mittlerer und hoher Auswirkung. Nicht jeder KI-Schritt braucht dieselbe Hürde. Aber kritische Schritte brauchen mehr als Vertrauen.

Was Teams jetzt tun sollten

Für die meisten deutschen Produktteams ist der sinnvollste nächste Schritt kein großes AI-Act-Programm. Es ist ein ehrlicher, technischer Readiness-Check.

Fünf Fragen reichen für den Anfang:

1. Wo nutzen wir heute KI in Produkt, Entwicklung, Betrieb oder internen Prozessen?
2. Welche dieser Systeme sehen sensible Daten oder beeinflussen relevante Entscheidungen?
3. Haben diese Systeme klare Besitzer, Grenzen und Berechtigungen?
4. Können wir später erklären, welche KI-Ausgabe zu welcher Aktion geführt hat?
5. Welche Workflows müssten wir umbauen, wenn ein Kunde, Auditor oder Partner morgen Nachweise sehen will?

Wenn die Antworten schwammig sind, ist das kein Grund zur Panik. Es ist ein guter Hinweis darauf, wo Architekturarbeit den größten Hebel hat.

McDougall Digital kann hier praktisch helfen: KI-Nutzung inventarisieren, Risiken nach Produktwirkung sortieren, Agenten-Workflows entwerfen, Berechtigungen und Review-Pfade definieren, Logging und Monitoring einbauen und bestehende Software so weiterentwickeln, dass KI-Unterstützung nicht gegen Wartbarkeit und Betriebssicherheit arbeitet.

Der wertvolle Teil ist nicht ein dicker Ordner voller abstrakter Regeln. Der wertvolle Teil ist ein System, das im Alltag funktioniert.

Die eigentliche Chance

Der AI Act wird oft als Bremse erzählt. Für gute Teams kann er aber auch ein Filter sein.

Er zwingt zu Fragen, die ohnehin gestellt werden sollten: Welche KI-Funktionen schaffen echten Nutzen? Welche sind nur Spielerei? Welche Entscheidungen dürfen automatisiert werden? Welche brauchen menschliche Verantwortung? Welche Daten und Rechte sind wirklich nötig? Wie erklären wir das System, wenn es wichtig wird?

Teams, die diese Fragen früh beantworten, bauen nicht nur compliant aussehende Software. Sie bauen bessere Software.

KI-Agenten werden in den nächsten Jahren tiefer in Produkte, interne Tools und Delivery-Prozesse wandern. Die Gewinner werden nicht die Teams sein, die am meisten automatisieren. Es werden die Teams sein, die Automatisierung so gestalten, dass Menschen ihr vertrauen, sie betreiben und sie verbessern können.

Das ist keine juristische Nebensache. Das ist Architektur.