Smarter Systems: Wissen

Ohne Agentic FinOps zahlst du vermutlich zu viel. Dein Azure Advisor sagt es dir nicht.

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Über Agentic Ops habe ich bereits geschrieben: wie eine KI mit Zugriff auf Telemetrie, deployten Code und Daten einen Produktionsfehler in Minuten findet, und warum ein Agent mit reinen Leserechten weniger riskant ist als der Reflex dagegen. Einen Dienst upgraden, auf den neuesten Compute-Plan wechseln, eine Konfiguration nachziehen: Das sollte in jeder Firma längst Status quo sein. Wo der Sysadmin noch von Hand mit der Kommandozeile arbeitet, wird massiv Potenzial verschenkt. Aber das ist nicht das einzige verschenkte Potenzial.

Skalieren ist leicht, Sparen macht keiner

In den grossen Public Clouds ist es kinderleicht, Ressourcen bereitzustellen. Steigt die Nachfrage, skaliert man mit. Was ich dagegen selten erlebe: dass jemand FinOps etabliert, also die Cloud-Kosten genauso aktiv steuert wie die Leistung. Und noch seltener, dass jemand regelmässig nach Sparpotenzial sucht. Dabei gibt es davon reichlich. Es liegt nur selten auf der Hand, sondern meistens zwei oder drei Schritte entfernt.

Neuer ist billiger, aber nicht von selbst

Die neueren Compute-Pläne in Azure sind günstiger als die alten, und sie lassen sich reservieren. Ein Beispiel mit den Listenpreisen für die Region Schweiz Nord, in Franken pro Monat und Instanz:

App Service, Windows	Pro Monat	Ersparnis
Premium v2, P2v2 (2 Kerne)	267.25
Premium v3, P1v3 (2 vCPU)	225.86	15 %
P1v3, 1 Jahr reserviert	166.35	38 %
P1v3, 3 Jahre reserviert	132.37	50 %

Listenpreise aus der Azure Retail Prices API, Region Schweiz Nord, in Franken ohne MwSt., 730 Stunden pro Monat, Stand 5. Oktober 2026.

Das sind rund 1'620 Franken pro Jahr, für eine einzige Instanz. Bei zehn Instanzen bist du fünfstellig.

Der Haken: Premium v2 lässt sich nicht reservieren, das geht erst ab v3. Und nicht jede bestehende Umgebung unterstützt v3. Dann verlangt Microsoft einen neuen Plan in einer neuen Ressourcengruppe und ein erneutes Deployment der Anwendung. Erst danach kommt die Reservierung. Drei Schritte, und erst der dritte bringt die halbe Ersparnis.

Wo der Advisor aufhört

Azure hat für solche Fragen den Advisor. Er erkennt unterausgelastete Pläne und schlägt Reservierungen vor, für Ressourcen, die schon reservierbar sind. Was er laut seiner eigenen Empfehlungsliste nicht vorschlägt: den Wechsel auf einen neueren Plan, um dann reservieren zu können. Der Advisor rechnet einen Schritt weit. Die grosse Einsparung liegt dahinter.

Bei SQL-Datenbanken wird es noch deutlicher. Azure kennt zwei Preismodelle: DTU, ein Paket aus Rechenleistung, Speicher und Lizenz, und vCore, bei dem du die Bestandteile einzeln bezahlst. Auf den ersten Blick ist vCore teurer:

SQL-Datenbank, 200 DTU gegen 2 vCores, 250 GB	Pro Monat	gegenüber DTU
DTU, Standard S4	269.44
vCore, ohne Reservierung	379.41	41 % teurer
vCore, 1 Jahr reserviert	301.08	12 % teurer
vCore, 3 Jahre reserviert	256.28	5 % günstiger
vCore, 3 Jahre reserviert, mit eigenen SQL-Lizenzen	134.81	50 % günstiger

Umrechnung nach Microsofts Faustregel: pro 100 DTU im Standard-Tier mindestens 1 vCore. Gleiche Preisquelle wie oben.

DTU-Datenbanken lassen sich nicht reservieren, vCore-Datenbanken schon. Und bei vCore kannst du SQL-Server-Lizenzen anrechnen, die du ohnehin besitzt. Das heisst bei Microsoft Azure Hybrid Benefit. Ob sich der Wechsel lohnt, hängt also an drei Fragen: Wie lange brauchst du die Datenbank? Hast du Lizenzen? Wie viel Last trägt sie wirklich? Ohne Lizenzen ist die Ersparnis klein, mit Lizenzen halbieren sich die Kosten. Der Advisor stellt keine dieser Fragen. Er empfiehlt Reservierungen nur für Datenbanken, die schon auf vCore laufen.

Genau das macht die KI, wenn man sie lässt

Eine KI geht anders vor. Sie sieht sich jede Ressource an, rechnet alle Varianten durch, auch über zwei und drei Schritte hinweg, und nennt dir das Sparpotenzial auf den Rappen genau. Die beiden Tabellen oben von Hand zu erstellen ist Arbeit: Preise abfragen, Modelle umrechnen, Laufzeiten vergleichen. Für eine ganze Cloud-Umgebung macht das niemand regelmässig. Eine KI schon.

Dafür muss sie alle Ressourcen in der Cloud zumindest lesen dürfen. Richtig stark wird es, wenn sie zusätzlich mit dem Quellcode und der CI/CD-Pipeline verbunden ist. Dann erkennt sie Zusammenhänge, die in keiner Kostenübersicht stehen: welche Anwendung welche Datenbank wirklich nutzt, welche Umgebung seit Monaten niemand mehr deployt hat, welcher Plan nur für einen einzigen Nachtjob so gross ist. In den Umgebungen, die Claude zuletzt für mich analysiert hat, wurden regelmässig Einsparungen im vier- und fünfstelligen Bereich pro Jahr sichtbar. Die Analyse hat die KI gemacht, ich habe das Potenzial nur noch aufgezeigt.

Vom Vorschlag zur Umsetzung

Mit dem Vorschlag muss es nicht enden. Mit Schreibrechten und der klaren Anweisung, den laufenden Betrieb nicht zu gefährden, lassen sich viele dieser Schritte automatisieren, die sonst Stress oder manuelles Scripting bedeuten.

Ich habe das selbst ausprobiert. Claude verwaltet meine eigene Infrastruktur und meldet mir zuverlässig, wie lange eine Downtime gedauert hat. Beim letzten Upgrade waren es genau 9 Sekunden. In der Zeit hätte ich von Hand kaum entschieden, ob ich jetzt wirklich auf den Knopf drücke.

Auch bei der Sorgfalt muss ich der Maschine ein gutes Zeugnis ausstellen. Claude prüft jede Änderung zuerst mit dem What-if-Schalter von Azure. Der zeigt an, was eine Änderung bewirken würde, ohne etwas zu verändern. Erst wenn das Ergebnis stimmt, wird ausgeführt.

Die Maschine hat keinen Puls von 150

Wer das von Hand macht, braucht genau diese Disziplin. Nur fallen Deployments häufig ausserhalb der Bürozeiten, und genau dort werden Abkürzungen genommen, weil man müde ist und Feierabend haben will. Der Mensch arbeitet also unter den schlechtesten Bedingungen, die Maschine unter denselben wie am Morgen. Deshalb geht beim Menschen das eine oder andere schief. Dann steigt der Puls auf 150, und man repariert das Problem in Panik. Die Maschine repariert auch, aber ohne Puls von 150 und ohne die Müdigkeit im Nacken.

Aus genau diesem Grund macht bei mir die Maschine das Infrastruktur-Management.

Wie läuft das bei dir? Hast du über Sparpotenziale und Automatisierung noch gar nicht nachgedacht? Buch unten einen kostenlosen Termin, und wir finden heraus, wie ich dich unterstützen kann.

Bei einem KI-Angriff hat kein Mensch Zeit, die Abwehrstrategie freizugeben

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Gartner hat «Preemptive Cybersecurity» zu einem der strategischen Technologietrends für 2026 erklärt. Gemeint ist eine Abwehr, die nicht mehr nur Alarm schlägt, sondern mithilfe von KI eingreift, bevor der Angreifer zuschlägt. Gartner prognostiziert, dass bis 2030 die Hälfte aller Sicherheitsausgaben in solche Lösungen fliesst. Die Formel dazu: «prediction is protection». Ein zweiter Trend auf derselben Liste sind «AI Security Platforms», die KI-Anwendungen und KI-Agenten gegen Angriffe absichern. Bis 2028 sollen laut Gartner über die Hälfte der Unternehmen solche Plattformen einsetzen.

Das klingt nach Zukunft. Ich wollte wissen, wie weit diese Zukunft heute schon ist, vor allem in Azure und AWS. Und ob sie das Tempo mithalten kann, in dem Angriffe inzwischen ablaufen.

Angriffe in Maschinengeschwindigkeit

Ende September 2026 hat Microsoft einen Angriff beschrieben, der zeigt, wie schnell es heute geht. Die Gruppe, die Microsoft Storm-3168 nennt, übernahm bei einem Unternehmen zwei Service Principals, also Dienstkonten, mit denen Anwendungen auf Azure zugreifen. Die Zugangsdaten des einen hatte ein Mitarbeiter zuvor im Klartext in einem öffentlichen GitHub-Ticket gepostet. Danach startete der Angreifer über 150 zerstörerische Operationen in 35 Minuten. Die eigentliche Zerstörung dauerte etwa sieben Minuten. Gelöscht wurden ein Key Vault, eine Function App, ein App Service Plan und die Sperren, die Backups und Wiederherstellung schützen sollten. Mehr als 100 Storage Accounts standen auf der Liste.

Von einer automatischen Abwehr steht in Microsofts Bericht nichts.

Das ist kein Einzelfall. Anthropic hat 2025 eine Kampagne offengelegt, bei der eine KI 80 bis 90 Prozent des Angriffs selbst ausgeführt hat, mit oft mehreren Anfragen pro Sekunde. Bei diesem Tempo hat kein Mensch Zeit, die Abwehrstrategie freizugeben. Bis der Alarm geprüft und die Freigabe eingeholt ist, ist der Schaden passiert. Gartner hat also recht: Die Abwehr muss selbst handeln. Die Frage ist, wo sie das heute schon tut.

Benutzer und Geräte: Die Abwehr handelt bereits

Bei Angriffen auf Benutzer und Endgeräte ist die automatische Abwehr Stand der Technik. Microsoft Defender verknüpft mit Automatic Attack Disruption Signale von Geräten, Identitäten, E-Mail und Cloud-Anwendungen zu einem Gesamtbild. Ist Defender sich sicher, dass ein Angriff läuft, sperrt er kompromittierte Benutzer, beendet ihre Sitzungen, schottet befallene Geräte ab und entschärft bösartige Apps mit Zugriff auf Microsoft 365. Er fragt dafür niemanden. Microsoft gibt für diese Eindämmung eine Präzision von 99 Prozent oder höher an. Jede Aktion lässt sich rückgängig machen.

Mit Predictive Shielding, derzeit in der Preview, geht Defender noch weiter. Erkennt er, dass auf einem Gerät Zugangsdaten abgegriffen wurden, sperrt er die dort wahrscheinlich offengelegten Administratorkonten vorsorglich, bevor der Angreifer sie benutzt. Das ist nicht nur etwas für Konzerne: Attack Disruption ist auch in Microsoft Defender for Business enthalten, dem Paket für kleinere Unternehmen.

Bei Benutzern hat Microsoft die Frage also beantwortet: Die Maschine handelt, der Mensch prüft danach. Bei deinen Anwendungen sieht es anders aus.

Anwendungen und Dienste: Hier wartet die Abwehr

Attack Disruption kennt zwei Arten von Zielen: Geräte, auf denen der Defender-Agent läuft, und Benutzerkonten. Eine Azure Function, eine Web App oder ein Application Gateway ist nichts davon.

Web Apps und Functions: Defender for App Service erkennt Angriffe auf deine Anwendungen und gibt Empfehlungen ab. Eine automatische Gegenmassnahme ist nicht vorgesehen. Die Anwendung läuft weiter, während der Alarm auf jemanden wartet.
Application Gateway: Die Web Application Firewall blockiert einzelne bösartige Anfragen nach Regeln. Das ist wichtig, aber es ist ein Türsteher, kein Wachdienst. Ist der Angreifer schon drin, etwa über ein gestohlenes Dienstkonto, kommt er gar nicht über das Gateway.

Am deutlichsten wird die Lücke bei den Dienstkonten, mit denen deine Anwendungen auf Datenbanken, Speicher und Schlüssel zugreifen:

Registrierte Apps mit Zugriff auf Microsoft 365 werden von Attack Disruption erfasst. Liest eine kompromittierte App Postfächer aus, greift Defender automatisch ein.
Service Principals mit Azure-Rechten, also die Konten aus dem Fall Storm-3168, lassen sich über Conditional Access für Workload Identities automatisch blockieren. Das passiert, sobald Microsoft ein erhöhtes Risiko erkennt oder sich das Konto von ausserhalb bekannter Netze anmeldet. Dafür brauchst du die Zusatzlizenz Workload Identities Premium. Die Regel gilt nur für Dienstkonten aus deinem eigenen Tenant, und sie greift erst, wenn das Konto ein neues Token anfordert. Ein bereits ausgestelltes Token bleibt bis zum Ablauf gültig.
Managed Identities, die Konten hinter Functions und Web Apps, sind laut Microsoft ausdrücklich nicht abgedeckt, weder von Conditional Access noch von der Risikoerkennung. Sitzt ein Angreifer im Code einer Function, nutzt er deren Managed Identity, und nichts sperrt sie automatisch.

Das ist die Ironie: Microsoft empfiehlt Managed Identities zu Recht, weil es dort kein Passwort gibt, das in einem GitHub-Ticket landen kann. Storm-3168 wäre so wohl nicht passiert. Aber genau diese sicherste Art von Dienstkonto hat keinen automatischen Notschalter.

AWS wartet bewusst auf dich

AWS geht noch einen Schritt weiter Richtung Mensch. Der GuardDuty Investigation Agent, seit Juni 2026 in der Preview, analysiert einen Verdacht in Minuten und gibt Empfehlungen ab, ausführen tut er sie nicht. Beim Dienst AWS Security Incident Response kann AWS Server, Benutzer und Speicher zwar eindämmen, laut Dokumentation aber erst, nachdem du die Risiken geprüft und zugestimmt hast. Microsoft lässt die Maschine bei Benutzern handeln. AWS lässt sie ermitteln und dich entscheiden. Gegen einen Angreifer, der in sieben Minuten eine Umgebung löscht, kommt diese Entscheidung zu spät.

Was die Hersteller planen

Beide arbeiten daran. Microsoft hat im August 2026 Project Perception vorgestellt, ein System aus spezialisierten KI-Agenten, die Angriffspfade aufdecken, Alarme sortieren, Angriffe rekonstruieren und neue Erkennungsregeln schreiben. Es ist bisher nur für eingeladene Kunden verfügbar. Der Agent für die Behebung priorisiert heute, was zuerst repariert werden soll. Und laut Microsoft halten die Agenten vor folgenreichen Aktionen an und warten auf deine Freigabe. AWS hat im August 2026 seine Lösung Automated Security Response erweitert, mit der Funde automatisch behoben werden können. Diese Lösung rollst du allerdings selbst aus und konfigurierst sie selbst.

Die Richtung stimmt, aber was angekündigt ist, ermittelt und empfiehlt. Eine automatische Eindämmung für Web Apps, Functions und Managed Identities habe ich bei keinem der beiden gefunden, auch nicht angekündigt. Gemessen an Gartners Anspruch heisst das: Bei Benutzern und Geräten ist «prediction is protection» schon Realität. Bei deinen Anwendungen und Dienstkonten ist es noch ein Trend. Ich bin sicher, dass sich das ändert. Bis dahin musst du die Lücke selbst schliessen.

Was du jetzt tun kannst

Den Benutzerteil vollständig einschalten: Defender auf allen Geräten, Servern und Domain Controllern, die Automatik in den Gerätegruppen auf «voll». Jede Lücke dort ist ein blinder Fleck.
Dienstkonten automatisch blockieren lassen: Conditional Access für Workload Identities einrichten, mit einer Regel für erhöhtes Risiko und einer für unbekannte Netze.
Secrets abschaffen, wo es geht: Managed Identities statt Passwörtern. Was trotzdem ein Secret braucht, gehört in den Key Vault, nie in Code, Konfigurationsdateien oder Tickets. Ein veröffentlichtes Secret ist kompromittiert, auch wenn du es wieder löschst.
Rechte radikal begrenzen: Eine Function, die Dateien liest, braucht kein Recht, Storage Accounts zu löschen. Was das Dienstkonto nicht darf, kann auch ein Angreifer damit nicht tun.
Die Reaktion für deine Anwendungen selbst bauen: Defender for Cloud kann bei einem Alarm automatisch eine Logic App starten. Die kann einer Managed Identity die Rechte entziehen, eine Web App für alle ausser dem Admin-Netz sperren oder Schlüssel rotieren. Und lege fest, dass sie das ohne Freigabe tut. Sonst hast du dir die AWS-Philosophie nachgebaut.
Backups vor den eigenen Konten schützen: Storm-3168 hat zuerst die Sperren der Backups entfernt. Wer die Wiederherstellung löschen darf, sollte nicht dasselbe Konto sein, das die Anwendung betreibt.

Wenn du wissen willst, wo deine Azure-Umgebung heute selbst abwehrt und wo sie auf einen Menschen wartet, buch unten einen Termin, und wir schauen es uns gemeinsam an.

Quantencomputer 2029: Das Budget für 2027 entscheidet

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Microsoft hat im Juni 2026 seinen neuen Quantenchip Majorana 2 vorgestellt und dabei eine Ansage gemacht: Bis 2029 erwartet Microsoft einen skalierbaren Quantencomputer, der kommerziell nutzbar ist. Die eigene Zeitlinie hat Microsoft damit nach eigenen Angaben halbiert. Wer bisher mit «irgendwann nach 2030» geplant hat, sollte diese Planung jetzt anschauen.

KI baut am Quantencomputer mit

Der Sprung kommt nicht aus dem Nichts. Laut Microsoft hat agentische KI einen grossen Teil der Laborarbeit übernommen. Um einen der neuen Qubits zu erzeugen, müssen Hunderte Parameter eingestellt und anschliessend gemessen werden. Von Hand dauert jeder dieser Schritte Wochen. Die KI hat die Messungen automatisiert und die Zykluszeit um Grössenordnungen verkürzt. Nebenbei hat sie in den Fertigungsdaten einen falsch kalibrierten Temperatursensor gefunden, der die Ergebnisse verfälscht hatte. Das Resultat: Die Qubits halten ihren Zustand 1'000-mal länger als bei der ersten Generation, im Mittel 20 Sekunden.

Jetzt kommt meine Einschätzung dazu. KI entwickelt sich selbst in einem Tempo, das jede Prognose der letzten Jahre überholt hat. Wenn KI bereits die Quantenforschung so beschleunigt, würde es mich nicht wundern, wenn der Quantencomputer noch früher kommt als 2029.

Was 2029 heisst und was nicht

Ehrlich gerechnet: Microsoft sagt nicht, dass die Maschine von 2029 deine Verschlüsselung knacken kann. Um einen heute üblichen RSA-Schlüssel mit 2048 Bit zu brechen, braucht es nach einer Schätzung von Google-Forscher Craig Gidney aus dem Jahr 2025 knapp eine Million Qubits. Das entlastet dich aber nicht. Es gibt zwei Gründe, warum die Frist für dich früher abläuft als der Tag, an dem der erste Schlüssel fällt.

Der Angriff läuft schon heute

Angreifer müssen nicht warten, bis der Quantencomputer da ist. Sie speichern verschlüsselte Daten jetzt und entschlüsseln sie, sobald sie es können. Das Prinzip heisst «Harvest now, decrypt later». Entscheidend ist also nicht, wann der Quantencomputer kommt, sondern wie lange deine Daten geheim bleiben müssen. Verträge, Gesundheitsdaten, Konstruktionspläne, Kundendaten: Was in zehn Jahren noch schützenswert ist, ist schon heute gefährdet, wenn es über eine angreifbare Verbindung läuft.

Die Regulatoren haben den Zeitplan gesetzt

Die EU-Mitgliedstaaten haben sich im Juni 2025 auf eine Roadmap geeinigt. Bis Ende 2026 sollen sie mit der Umstellung auf quantenresistente Verschlüsselung beginnen, kritische Infrastruktur soll spätestens Ende 2030 umgestellt sein. In den USA sieht ein Entwurf der Standardisierungsbehörde NIST vor, die heutigen Verfahren RSA und ECC nach 2030 als veraltet einzustufen und nach 2035 ganz zu verbieten. Wer kritische Infrastruktur betreibt oder beliefert, hat seine Frist also schon schwarz auf weiss.

Die Rechnung

Nehmen wir Microsofts Schätzung beim Wort. Bis 2029 bleiben von heute an zwei bis drei Jahre. Ein Projekt, das quer durch Infrastruktur, Anwendungen und Lieferanten geht, ist nicht in ein paar Monaten erledigt. Es braucht eine Bestandsaufnahme, eine Priorisierung, Tests und eine schrittweise Umstellung im laufenden Betrieb. Spätestens 2027 müssen diese Projekte starten. Wer sie nicht startet, nimmt bewusst in Kauf, angreifbar zu werden.

Und wenn sich die Entwicklung noch einmal um ein Jahr verkürzt, sieht die Rechnung dramatischer aus. Dann reicht ein Start 2027 gerade noch, wenn alles glattläuft. Und es läuft selten alles glatt.

Was alles betroffen ist

Das Problem steckt in der asymmetrischen Verschlüsselung, also in den Verfahren, mit denen Systeme Schlüssel austauschen und Signaturen prüfen. Das sind vor allem RSA und Verfahren auf elliptischen Kurven. Die eigentliche Datenverschlüsselung mit AES und langen Schlüsseln gilt als weitgehend robust. Die asymmetrischen Verfahren stecken aber fast überall:

Infrastruktur, in der Cloud und On Premises: VPN, Fernzugriff, Load Balancer, Schlüsselspeicher, Verbindungen zwischen Rechenzentren.
Applikationen: eigener Code, der verschlüsselt oder signiert, Anmeldungen und Tokens, verschlüsselte Datenablagen.
Third-Party Libraries und eingekaufte Software: Was deine Lieferanten nicht umstellen, kannst du nicht umstellen. Das gehört in die Verträge.
Zertifikate: für Webseiten, interne Systeme und signierte Software.
Geräte mit langer Lebensdauer: Maschinen, Sensoren und Steuerungen, die sich nicht einfach aktualisieren lassen.
Archive und Backups, die heute verschlüsselt abgelegt werden und morgen noch vertraulich sein müssen.

Der erste Schritt: wissen, wo du stehst

Du kannst nicht migrieren, was du nicht kennst. Am Anfang steht ein Inventar: Wo setzt du welche Verschlüsselung ein, in welchen Systemen, bei welchen Lieferanten, und wie lange müssen die Daten dahinter geschützt bleiben? Daraus ergibt sich, was zuerst umgestellt werden muss und was warten kann. Und daraus ergibt sich, was es kostet.

Ohne Budget passiert 2027 nichts

In vielen Unternehmen wird jetzt das Budget für 2027 geplant. Wenn die Migration dort nicht als eigener Posten drinsteht, passiert nächstes Jahr nichts. Dann wird aus 2027 ein Jahr mit Diskussionen, und das Projekt startet 2028. Bei der Zeitlinie von Microsoft ist das zu spät. Die Augen davor zu verschliessen ist keine Option.

Wenn du wissen willst, wo deine Systeme stehen und welches Budget du für 2027 einplanen musst, buch unten einen Termin, und wir schauen es uns gemeinsam an.

Wer KI betreibt, muss jeden Aufruf belegen können

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Wer KI-Systeme betreibt, muss nachvollziehen können, was gepromptet wurde, was die KI geantwortet hat und was es gekostet hat. Fehlt einer dieser drei Punkte, verlierst du die Kontrolle.

Die erste Ebene gehört Microsoft

Logging gibt es auf mehreren Ebenen. Bei Microsoft Foundry liefert Microsoft die erste automatisch mit: das Abuse Monitoring. Damit prüft Microsoft, ob die KI entgegen den Produktbedingungen eingesetzt wird. Das ist Segen und Fluch zugleich. Solange du die KI intern nutzt, ist alles einfach. Sobald aber deine Kunden das System nutzen, trägst du auch deren Eingaben. Missbraucht ein einziger Kunde die KI, kann Microsoft den Zugang drosseln oder die ganze Subscription sperren. Dann fehlt allen anderen Kunden die Funktion, und dir fehlt der Umsatz. Mit dem Monitoring prüfen im Verdachtsfall Menschen, bevor gesperrt wird. Der Preis dafür: Microsoft verarbeitet deine Anfragen und Antworten, und bei einem Verdacht können Microsoft-Mitarbeitende sie einsehen. Auf der anderen Seite steht also der Datenschutz.

Microsoft bietet ein Formular an, mit dem du eine Änderung des Abuse Monitorings beantragen kannst. Wird sie genehmigt, speichert Microsoft Anfragen und Antworten nicht mehr, und niemand sieht sie sich an. Eine automatische Prüfung läuft laut Microsoft trotzdem weiter. Wer das Monitoring abschaltet, ist vor einer Sperre nicht geschützt: Die automatische Prüfung kann laut Microsoft weiterhin zu Einschränkungen führen, nur prüft dann kein Mensch mehr, bevor sie greifen. Ob der Antrag durch ist, siehst du in der JSON-Ansicht der Ressource: Dort steht dann ContentLogging auf false.

Für die Kontrolle über deine eigene Anwendung taugt dieses Monitoring nicht. Die geloggten Daten kann auch dein Azure-Administrator nicht einsehen. Hier musst du selbst etwas tun.

Welche Plattform?

Zuerst brauchst du eine gute Logging-Plattform. Ich habe über die Jahre einige ausprobiert. Die Produkte haben einen unterschiedlichen Leistungsumfang, und ich habe in Teams erlebt, dass dann zwei oder drei Logging-Senken für verschiedene Anwendungsfälle nebeneinander liefen, mit den entsprechenden Kosten fürs Projekt. Deshalb bevorzuge ich ein Verbundsystem: Logging, Tracing, Profiling und Metriken an einem Ort, in Dashboards aufbereitet und über den offenen Standard OpenTelemetry beliefert.

An diesem Anspruch habe ich die Anbieter gemessen, die ich kenne. Die Preise sind Listenpreise vom 30. September 2026 in US-Dollar, wo möglich für die Schweiz.

Anbieter	Logs, Metriken, Traces, Profiling	OpenTelemetry	KI-Aufrufe erfassen	Selbst betreibbar	Log-Preis	Einschätzung
Grafana Cloud	alle vier	nativ	ja: Prompts, Token, Kosten, Tool Calls	ja, Open Source	0.45 USD/GB plus 0.10 USD/GB Aufbewahrung, 50 GB gratis	Alles in einem System, offen, günstig. Dashboards und Abfragen erstellt die KI
Datadog	alle vier	ja	ja: Prompts, Token, Kosten	nein	0.10 USD/GB plus 1.70 USD pro Million indexierte Events; APM 31 USD pro Host und Monat	Funktional am nächsten, aber viele Einzelprodukte pro Host, schwer planbar
New Relic	Logs, Metriken, Traces; Profiling nicht dokumentiert	nativ	ja: Requests, Responses, Token	nein	0.40 USD/GB, 100 GB gratis; Pro-Benutzer 349 USD pro Monat	Gut, aber teuer pro Benutzer
Sentry	Fehler, Traces, Logs, Profiling; Metriken schwach	Traces und Logs, Beta	ja: Prompts, Token, Kosten, Tool Calls	ja	0.50 USD/GB, ab 26 USD pro Monat	Stark bei Exceptions, schwach bei Metriken
Better Stack	Logs, Metriken, Traces; kein Profiling dokumentiert	ja	nur KI-Fehleranalyse	nein	0.10 USD/GB plus 0.05 USD/GB pro Monat (Europa)	Günstigster GB-Preis, aber kein Profiling
Azure Application Insights	Logs, Metriken, Traces	über Microsoft-Distro	ja, Foundry-Tracing	nein	3.29 USD/GB (Switzerland North), 5 GB gratis	Naheliegend in Azure, teuerster GB-Preis
AWS CloudWatch	Logs, Metriken, Traces	ja, nur HTTP	ja, Schwerpunkt Bedrock	nein	0.69 USD/GB (Zürich); 0.30 USD pro Metrik und Monat	Naheliegend in AWS, viele Einzelpositionen
elmah.io	nur Fehler und Logmeldungen (.NET)	nicht dokumentiert	nein	nein	ab 26 USD pro Monat für 10'000 Meldungen	Nur Fehlerlogging
Stackify Retrace	wird am 31. März 2027 eingestellt					Keine Option mehr

Grafana ist mein Favorit, und ich empfehle es aktuell. Es ist das einzige System im Vergleich, das alle vier Signale abdeckt, KI-Aufrufe über OpenTelemetry erfasst und sich bei Bedarf auch selbst betreiben lässt. Datadog kommt funktional am nächsten heran, rechnet aber viele Produkte einzeln pro Host ab und lässt sich nicht selbst betreiben.

Die Hürde bei Grafana waren bisher die Abfragesprachen und Dashboards, die man von Hand zusammenbaut. Mit KI fällt diese Hürde weg. Das Leitstand-Dashboard für einen Kunden, auf dem ich die wichtigsten Metriken zur Systemstabilität im Blick behalte, hat Claude komplett erstellt. Ich prüfe die Ergebnisse, gebaut habe ich nichts davon selbst. Auch die Abfragen schreibe ich nicht mehr selbst. Ich sage Claude, welche Aspekte mich interessieren, und lasse sie analysieren.

Mit KI stellt sich die Frage neu, was geloggt werden soll und welches System sich dafür eignet. Die Tabelle gibt dir eine Grundlage, um das fundiert zu entscheiden.

Was du erheben musst

Request und Response sind klar, aber das reicht nicht. Diese Werte gehören für jeden KI-Aufruf ins Logging:

Request
Response
Exceptions
Anzahl Aufrufe des Modells
Fehlerrate
Dauer des Aufrufs
Erfolgreiche Tool Calls
Fehlerhafte Tool Calls
Verbrauchte Token
Gecachte Token
Token-Kosten

Damit baust du ein KI-Dashboard, auf dem du siehst, wenn Fehlerquote oder Kosten aus dem Ruder laufen.

Unveränderlich oder wertlos

Damit Logging und Monitoring unanfechtbar bleiben, müssen sie nach dem Prinzip WORM aufgebaut sein: Write Once, Read Many. Deshalb schlage ich keine lokale Datenbank vor. Dort müsstest du die Einträge wie eine Blockchain verketten, damit jeder Eintrag den vorherigen absichert und du nachweisen kannst, dass hinterher nichts manipuliert wurde. Das Ziel ist, vor Gericht Nachweise erbringen zu können, wenn ein Kunde etwas behauptet.

Das kollidiert mit dem Datenschutz. Prompts und Antworten enthalten oft Personendaten, und die musst du auf Anfrage löschen können. Aus einem unveränderlichen Speicher geht das nicht. Ich löse das mit Hashwerten. Für jeden Request und jede Response berechnet die Anwendung einen Hash mit einem geheimen Schlüssel, einen sogenannten HMAC. Ohne den Schlüssel liesse sich eine kurze Antwort wie «Ja» durch Ausprobieren zurückrechnen.

In der WORM-Senke landet nur der Hash, zusammen mit Zeitpunkt, Modell, Token und Kosten. In Grafana liegen Request und Response im Klartext, verknüpft mit demselben Hash. Nach einer Löschanfrage entfernst du den Klartext in Grafana, im Archiv existiert nur noch der Hash. Kommt ein Kunde mit einer Datei, was der Chatbot gesagt haben soll, berechnest du den Hash neu und vergleichst ihn mit dem Archiv. Stimmt er überein, ist die Aussage samt Zeitpunkt belegt. Das funktioniert mit dem exakten Wortlaut, nicht mit einem Screenshot oder einer sinngemässen Wiedergabe.

So sieht das mit AWS S3 aus

Ein S3-Bucket mit Versionierung und Object Lock im Compliance-Modus. Während der Aufbewahrungsfrist kann dort niemand einen Eintrag überschreiben oder löschen, laut AWS nicht einmal der Root-Benutzer des Kontos. Die Frist legst du einmal fest, verkürzen lässt sie sich danach nicht mehr.
Die Anwendung berechnet die Hashwerte und schickt alle Daten per OpenTelemetry an einen Collector.
Der Collector verteilt. Grafana bekommt alles, inklusive Klartext. Für das Archiv entfernt er den Klartext und schreibt nur Hash, Zeitpunkt, Modell, Token, Kosten und Fehler in den S3-Bucket.
Bei einer Löschanfrage löschst du den Klartext in Grafana. Das Archiv bleibt unangetastet.

Alle Aspekte der Nachweisbarkeit von KI richtig umzusetzen, braucht viel Erfahrung und Know-how. Wenn du dabei Unterstützung brauchst, buch unten ein kostenloses Erstgespräch von 30 Minuten, und wir schauen gemeinsam, wo du stehst.

Sicherheit durch Verschleierung funktioniert nicht mehr

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

In der IT kennen viele den Begriff «Security through Obscurity», zu Deutsch Sicherheit durch Verschleierung. Echte Sicherheit war das nie. Trotzdem hat es lange gut funktioniert, weil das Aufdecken mehr Aufwand kostete, als es einbrachte.

Ein Beispiel: .NET-Anwendungen, die auf Desktops installiert wurden, musste man vor der Auslieferung obfuscaten. Sonst liess sich der Code mit wenig Aufwand zurückübersetzen und damit stehlen. Heute kommt das seltener vor, weil Webanwendungen die Desktop-Anwendungen ersetzen. Dort liegt das Problem anders.

Die Verschleierung ist eine Ebene tiefer gerutscht

Im Web braucht der Quellcode keine Obfuscation, weil er den Server nie verlässt. Dafür ist die Verschleierung eine Ebene tiefer gerutscht, auf die REST-API. Den Verkehr dort kann jeder in den Developer Tools seines Browsers mitlesen. Angreifer lernen daraus, wie ein System intern funktioniert, und manipulieren gezielt Requests, bis das System Informationen herausgibt, die nie für sie gedacht waren.

Häufig hat es an dieser Stelle gereicht, die Daten des Requests zu verschleiern. Zum Beispiel, indem man das JSON vor dem Senden im Browser verschlüsselt und auf dem Server wieder entschlüsselt. Alles, was dafür nötig ist, liegt zwangsläufig im Browser, irgendwo in vielen tausend Zeilen minifiziertem JavaScript. Da hat sich niemand durchgewühlt, um zu verstehen, wie die Verschlüsselung funktioniert. Die Hürde war hoch genug, um Hacker abzuhalten.

KI liest unlesbaren Code in Sekunden

Mit KI sieht die Sache anders aus. Claude und Co. wühlen sich in Sekunden durch diese schwer lesbaren Dateien und helfen dabei, verschlüsselte Inhalte direkt im Browser zu entschlüsseln, mit genau den Funktionen, die die Anwendung dafür mitbringt. Ein Mensch kommt nicht auf die Idee, __func(a,z2) aufzurufen. Für die KI ist das kein Problem, und damit entsteht ein neuer Angriffsvektor.

Ich habe das selbst ausprobiert. Die Anwendung wird als einzelne kompilierte Datei ausgeliefert. Der Code des Herstellers steckt darin nur als Bytecode, der Quelltext ist entfernt. Nach dem Dekompilieren hiessen alle Variablen nur noch r0, r1 oder r8, aber jeder Funktionsname und jeder Text im Code war erhalten. Ein Passwort oder API-Schlüssel, der fest im Programm steht, liegt damit offen. Die interessanten Teile waren zusätzlich verschleiert: Jeder Text lag verschlüsselt vor und wurde erst zur Laufzeit entschlüsselt. Zusammen mit der KI habe ich die Entschlüsselung nachgebaut, ohne das Programm auch nur zu starten, und damit über 95 Prozent der verschlüsselten Texte zurückgewonnen. Am Ende hatte ich den Algorithmus, der mich interessiert hat, als lesbaren Code. Er liefert auf die Stelle genau dieselben Ergebnisse wie das Original.

Für mich war das ein Forschungslauf. Angreifer machen dasselbe mit anderen Absichten. Man muss heute davon ausgehen, dass alles, was ausnutzbar ist, auch ausgenutzt wird. Die Angriffe werden deutlich komplexer. Das sehe ich auch in Kundenprojekten, wenn Kunden eigene Sicherheitstests laufen lassen und Findings melden.

Stellt alles auf den Prüfstand, was nur verschleiert ist

Daher mein Aufruf an alle Entscheider: Stellt jede Stelle auf den Prüfstand, die ihr nur verschleiert statt gelöst habt. Gelöst heisst, dass der Server jede Anfrage selbst prüft und nichts glaubt, was der Browser schickt. Security through Obscurity ist seit KI tot.

Wenn du Unterstützung bei der Analyse eures Codes oder eurer Infrastruktur brauchst, buch unten ein kostenloses Erstgespräch. Dann schauen wir gemeinsam, ob ich einen Mehrwert bieten kann.

KI-Weiterbildung kostet nichts mehr, ausser Zeit

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Ein zweitägiger Kurs zu KI-Agenten kostet bei einem Schweizer Weiterbildungsanbieter knapp 2000 Franken. Die Anthropic Academy bietet mit «Building with the Claude API» einen Kurs zu denselben Themen gratis an: Tool-Nutzung, RAG, Agenten und MCP, in 67 Lektionen, vom Hersteller des Modells selbst. Einen Trainer im Raum bekommst du dort nicht. Die Disziplin musst du selbst mitbringen.

Wissen war noch nie so leicht zu haben. Fast alle Lerninhalte zu KI sind frei verfügbar. Wer bereit ist, Zeit zu investieren und sich im Selbststudium weiterzubilden, braucht dafür kein Budget.

Geld ist keine Ausrede mehr

Das gilt für die Geschäftsleitung genauso wie für die Sachbearbeiterin, und für Leute aus einkommensschwachen oder bildungsfernen Verhältnissen genauso wie für den Manager mit Weiterbildungsbudget. Die Ausrede, dass für KI-Weiterbildung kein Geld da ist, zählt nicht.

Bleibt die Zeit. Die Stunden am Tag sind für alle gleich, und wie viele davon in Netflix und TikTok verschwinden, entscheidet jeder selbst. Man muss den Hintern hochbekommen, den Feed ausmachen und etwas Sinnvolles tun.

Der Arbeitsmarkt sortiert bereits

Grosse Firmen trennen sich inzwischen von Leuten, die den Anschluss nicht schaffen. Accenture hat im September 2025 angekündigt, Mitarbeitende auf verkürztem Zeitplan zu entlassen, wenn eine Umschulung auf die benötigten KI-Fähigkeiten nicht machbar ist. CEO Julie Sweet dazu: «Those we cannot reskill will be exited.» (CNBC)

Bei Einstellungen ist KI zum Musskriterium geworden. Im Work Trend Index 2024 von Microsoft und LinkedIn, erhoben bei 31'000 Wissensarbeitenden in 31 Ländern, sagen 66 Prozent der Führungskräfte, dass sie niemanden ohne KI-Kenntnisse einstellen würden. Die Zahl stammt von einem Konzern, der KI verkauft, und beruht auf Selbstauskunft. An der Richtung ändert das nichts.

Das gilt auch ganz oben. Laut Handelsblatt steigt die Erwartung an KI-Kompetenz mit der Höhe des Postens, und Headhunter prüfen sie im Gespräch gezielt ab.

Zuerst der Einzelne, dann die Firma

Die Weiterbildung in KI liegt in erster Linie bei jedem selbst, und sie ist im eigenen Interesse. Erst in zweiter Linie ist es Sache des Arbeitgebers, das Umfeld zu schaffen, in dem sich Mitarbeitende weiterentwickeln.

Für dich als Führungskraft heisst das zweierlei. Die erste Regel gilt auch für dich: Wer ein Team durch diesen Wandel führen will, muss das Werkzeug selbst beherrschen. Und der zweite Teil ist deine Aufgabe. Was ein Mitarbeiter sich abends beibringt, bleibt zuerst bei ihm. Kündigt er, geht es mit ihm.

Lebenslanges Lernen müssen beide Seiten ernst nehmen, sonst verpassen beide den Zug. Wer stehen bleibt, wird unattraktiv, für den eigenen Arbeitgeber und für den Arbeitsmarkt insgesamt. Die lähmende Angst vor KI ist dabei der falsche Impuls.

Die Panik in den Schlagzeilen

Wer die Nachrichten über KI verfolgt, liest vor allem Panik: «KI wird uns alle vernichten», «Warnung vor KI-Gefahr». Zuletzt Bill Gates, zitiert mit «eine Milliarde Todesopfer».

Gesagt hat Gates Ende September 2026 in der NBC-Sendung «Meet the Press», KI sei mächtig genug, um Ereignisse auszulösen, die eine Milliarde Todesopfer fordern (NBC News). Gemeint hat er Menschen, die KI für Cyberangriffe oder Biowaffen missbrauchen. Einen Entwicklungsstopp lehnt er ab, er will Gesetze. In der Schlagzeile wird daraus eine KI, die eine Milliarde Menschen tötet.

Darin hat die Menschheit Übung. 1835 soll ein bayerisches Ärztekollegium vor der ersten deutschen Eisenbahn zwischen Nürnberg und Fürth gewarnt haben, das Tempo mache Fahrgäste und Zuschauer hirnkrank. Die «Eisenbahnkrankheit» wird bis heute zitiert. Eisenbahnhistoriker haben das Gutachten nie gefunden. Die Geschichte ist so gut, dass niemand sie prüft, und nach demselben Muster funktionieren die Schlagzeilen über KI.

Es ist richtig, dass parallel zur Entwicklung jemand auf die Gefahren hinweist. Für Angestellte, Selbständige und Firmen ändert es nichts daran, dass KI-Kenntnisse in Wissensberufen heute vorausgesetzt werden.

Die Sicht der Firmen

In meinem Buch «Schnelle Leute, langsame Firma», das bald erscheint, gehe ich das Thema aus Sicht der Arbeitgeber an: wie Firmen mit dem strukturellen Wandel umgehen, damit aus dem Können Einzelner ein Vorteil für das ganze Unternehmen wird.

Wenn du in deinem Unternehmen vor solchen Fragen stehst und einen Sparringspartner brauchst, der deine Ideen challengt, buch unten einen Termin. Ich gebe dir eine Einschätzung zu deinen Ideen.

Vertraulichkeit von Betriebswissen vs. massiver Produktivitätsgewinn

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

In meinen letzten beiden Artikeln habe ich beschrieben, was KI bei den Policies im ISMS und BCM leistet und was bei Infrastructure as Code. Immer wieder kommt daraufhin derselbe Einwand: Wir können einem KI-Agenten doch keinen Zugriff auf unsere Infrastruktur geben. Und schon gar nicht auf unser ISMS.

Warum eigentlich nicht.

Ein Service Principal mit Leserechten, sonst nichts

Für einen Infrastruktur-Audit in Azure legst du einen Service Principal an. Der bekommt Reader auf die Subscription. Kein Zugriff auf den Key Vault, damit der Agent keine Secrets sieht. Keine Schreibrechte, damit er nichts anfassen kann. Jeder Aufruf landet im Activity Log, mit Zeitstempel und Identität. Nach dem Audit löschst du den Principal wieder.

Dieses Rechtemodell bringt deine Cloud ohnehin mit. Wer sagt, wir können dem Agenten keinen Zugriff geben, sagt genau genommen: Wir trauen uns nicht zu, Zugriff sauber zu begrenzen. Das ist ein Satz über eure Organisation.

Ein Restrisiko bleibt. Der Agent sieht Konfiguration, Namen und Topologie, und der Bericht am Ende ist eine sortierte Liste eurer Schwachstellen. Dieses Dokument braucht denselben Umgang wie jeder Pentest-Bericht: Ablageort, Zugriffsschutz, Löschfrist. Das ist Arbeit, aber keine Grundsatzfrage.

Fremde haben bei euch längst mehr Rechte als der Agent

Dieselbe Firma, die einem lesenden Agenten den Zugriff verweigert, gibt

dem externen Pentester ein Zeitfenster mit deutlich mehr als Leserechten,
dem Wirtschaftsprüfer Einsicht in Konfigurationen und Protokolle,
dem Managed Service Provider dauerhafte Administrationsrechte,
und dem Hersteller-Support im Eskalationsfall einen Speicherauszug, in dem alles drin ist.

Jede dieser Freigaben ist begründet. Zusammen zeigen sie, dass ihr den Zugriff Dritter auf eure Infrastruktur längst geregelt habt, über Vertrag, Rollenmodell und Protokollierung. Der Agent ist ein weiterer Dritter, und von allen hat er die wenigsten Rechte.

Der Einwand sagt Datenschutz und meint Betriebsgeheimnis

In einer Ressourcenliste aus dem Azure Resource Manager stehen keine personenbezogenen Daten. In einer Netzwerkregel auch nicht. In einer Policy deines ISMS steht, wie ihr Zugriffe regelt, nicht wer wann welchen Antrag gestellt hat.

Geschützt wird Betriebswissen: Topologie, Versionsstände, Schwachstellen. Das Schutzziel heisst Vertraulichkeit und folgt anderen Regeln als Datenschutz. Vertraulichkeit regelst du über Rechte, Verträge und Protokolle, und diese Werkzeuge hast du bereits im Haus. Wer Datenschutz sagt und Betriebsgeheimnis meint, verschiebt die Diskussion in ein Rechtsgebiet, in dem sie gar nicht stattfindet, und macht sie damit unentscheidbar.

Wo Personenbezug im Spiel ist, im Ticketsystem oder in Logs mit Benutzerkennungen, gelten die üblichen Regeln: Auftragsverarbeitung, Zweckbindung, Löschfristen.

Euer Admin hat dieses tiefe Wissen seit Jahren

Der eigentliche Einwand lautet: Wir wollen nicht, dass ein Agent tiefes Wissen über unsere Infrastruktur aufbaut.

Tiefes Wissen über eure Infrastruktur hat euer Admin. Seit Jahren. Er hat jede Ausnahme selbst beantragt, jede Abweichung selbst begründet und jede Altlast selbst geerbt. Bei jeder Regel erinnert er sich daran, warum sie dasteht, statt zu prüfen, was sie tut. So winkt er dieselbe Schwachstelle im dritten Jahr wieder durch.

In einer Produktionsumgebung, die ich geprüft habe, gab es eine Netzwerkregel, deren Name mit Deny beginnt und deren Wirkung Allow ist. Ein Mensch liest den Namen und hakt ab. Eine Maschine liest das Feld.

Dazu kommt die Ausdauer. Eine Maschine prüft Objekt Nummer 400 mit derselben Sorgfalt wie Objekt Nummer 1. Bei langen Prüflisten ermüdet jeder Mensch, und es trifft zuverlässig das Ende der Liste.

Der Preis des Reflexes

Wer bei diesem Reflex bleibt, benutzt KI auch 2026 noch wie vor zwei Jahren: als besseres Frage-und-Antwort-Spiel. Jemand tippt eine Frage, bekommt eine Antwort, kopiert sie irgendwohin. Der Wertbeitrag hängt daran, dass ein Mensch die richtige Frage stellt und die Antwort anschliessend selbst anwendet.

Das Potenzial liegt dort, wo der Agent an die echten Systeme darf. Ein Fehlerticket, dazu Lesezugriff auf Metriken, Logs, Deployment-Historie und Quellcode. Am Ende steht eine benannte Stelle im Code und ein Vorschlag, was dort zu ändern ist. Der Mensch prüft und entscheidet. Zusammensuchen muss er nichts mehr.

Zum Vertrag, weil er immer kommt: Bei den kommerziellen Enterprise-Angeboten ist die Nutzung der Eingaben für das Training vertraglich ausgeschlossen. Du darfst das in Frage stellen. Dann stell dieselbe Frage bei deinem Cloud-Anbieter, deinem Mailsystem und deinem CRM, denn dort liegen eure Daten längst. Wer der vertraglichen Zusicherung seiner Lieferanten grundsätzlich nicht traut, hat ein Lieferantenproblem.

Die Güterabwägung, die nicht stattfindet

Es ist eine Güterabwägung. Auf der einen Seite ein Risiko, das du über Rechte, Vertrag und Protokoll begrenzen kannst. Auf der anderen Seite ein systematischer Review, den in dieser Gründlichkeit sonst niemand macht, zum ersten Mal von jemandem, der die Umgebung nicht selbst gebaut hat.

Wo der Reflex greift, wird diese Abwägung gar nicht erst durchgeführt. «Das geht bei uns aus Datenschutzgründen nicht» beendet die Prüfung, bevor sie angefangen hat.

Wie verlässlich ist dein Wiederanlaufplan beim Ausfall deines Rechenzentrums?

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Am Anfang war es ein Test. Ein paar Klicks im Portal, weil es schnell gehen musste und weil du sehen wolltest, ob die Idee überhaupt trägt. Sie trug. Dann kam die nächste Komponente dazu, wieder im Portal, wieder schnell. Heute läuft ein Teil deines Geschäfts darauf, und niemand hat je gesagt, so, das reissen wir jetzt ab und bauen es sauber mit Infrastructure as Code.

Das ist kein Versagen schlechter Teams. In jedem einzelnen Moment war es die vernünftige Entscheidung. Abreissen und neu bauen kostet Wochen, und am Tag danach kann dein Produkt keine einzige Sache mehr als vorher. Also passiert es nicht. Mit jedem Jahr wächst der Bestand, und mit dem Bestand wächst der Preis, ihn nachträglich in Code zu giessen. Deshalb sitzen ganze Unternehmen auf einer Infrastruktur, die sie nicht über Code steuern, und finden keinen Zeitpunkt, an dem sich der Umbau rechnet.

Der Tag, an dem es zählt

Richtig teuer wird der fehlende Code beim Business Continuity Management. Das BSI nennt in den RZ-Standortkriterien (Version 2.1, Dezember 2024) einen Mindestabstand von rund 200 Kilometern zwischen Rechenzentren, die sich gegenseitig Georedundanz geben. Weniger als 100 Kilometer sollen es keinesfalls sein, und jeder deutlich geringere Abstand ist schriftlich ausführlich darzulegen und einer Risikoanalyse zu unterziehen.

Die Zahl ist nicht gegriffen. Das BSI leitet sie aus der Flächenausdehnung vergangener Grossschadensereignisse ab, aus der sinkenden Wahrscheinlichkeit, dass ein Ereignis beide Standorte gleichzeitig trifft. Sobald dein BCM diesen Abstand übernimmt, verpflichtest du dich damit auch, deine Infrastruktur zweihundert Kilometer weiter weg in einer vereinbarten Zeit wieder hochzuziehen.

Ohne Code heisst das, dass Menschen unter Druck nachbauen, was über Jahre gewachsen ist, und zwar genau in den Stunden, in denen dein System steht. Das werden keine Stunden. Das werden Wochen, und so lange hält dir kein Kunde die Treue.

Code allein rettet dich an diesem Tag allerdings auch nicht. Infrastructure as Code baut das leere Haus. Daten, Secrets, Zertifikate, Identitäten und DNS stehen nicht im State, und sie gehören auch nicht dorthin. Ein Wiederanlaufplan, dessen einziges Artefakt ein Terraform-Repository ist, fällt im Ernstfall trotzdem durch.

Was dich das kostet, bevor überhaupt etwas passiert

Das Erste, was fehlt, ist die Revisionssicherheit. Dass niemand nachvollziehen kann, wer wann was umgestellt hat, stimmt in dieser Schärfe nicht. Das Activity Log deiner Plattform protokolliert Zugriffe durchaus. Nur ist ein Ereignisstrom mit begrenzter Aufbewahrung kein Nachweis. Du kannst ihn nicht nebeneinanderlegen, du kannst ihn nicht vorher prüfen, und auf die Frage, wie die Produktion im März konfiguriert war, gibt er dir keine Antwort.

Eine Änderung, die über einen Pull Request geht, wird geprüft, bevor sie wirkt. Eine Änderung im Cloud Portal wird protokolliert, nachdem sie gewirkt hat. Für einen Auditor ist das Erste eine Kontrolle und das Zweite ein Protokoll.

Warum das jetzt anders ist

Der naheliegende Einwand kommt sofort. Werkzeuge, die eine bestehende Cloud auslesen und daraus Code schreiben, gibt es längst, von aztfexport bis terraformer, und eine ARM-Vorlage lässt sich auch ohne KI nach Bicep übersetzen. Das Auslesen war nie das Problem.

Wer so einen Export einmal geöffnet hat, weiss warum. Was herauskommt, ist ein Abzug des Ist-Zustands. Jede Ressource einzeln, jede Eigenschaft ausgeschrieben, IDs fest verdrahtet, keine Module, keine Variablen, keine Umgebungen, dazwischen die Reste aus zwei Jahren Ausprobieren. Technisch korrekt und als Grundlage für die nächsten fünf Jahre wertlos.

Die Arbeit liegt im Übersetzen, und die ist Urteilsarbeit, Ressource für Ressource.

Was gehört fachlich zusammen und wird ein Modul.
Was ist umgebungsspezifisch und wird zur Variable, damit Test und Produktion aus derselben Quelle entstehen.
Was ist Überbleibsel und fliegt raus, statt die nächsten Jahre im Code mitzufahren.
Welche Eigenschaften sind blosse Vorgabewerte, die dir sonst bei jedem Lauf eine Abweichung melden, die keine ist.

Diese Arbeit hat bisher niemand bezahlt, weil sie in Personenwochen gemessen wird und am Ende keine neue Funktion liefert. Ein Modell, das an deiner Plattform hängt, den Ist-Zustand liest und diese Entscheidungen vorschlägt, verschiebt den Preis von Wochen auf Tage. An diesem Preis ist die Entscheidung bisher gescheitert.

Die Abnahme ist ein leerer Plan

Dafür gibt es ein Kriterium, das du ohne Spezialwissen prüfen kannst. Du lässt den Trockenlauf gegen die laufende Umgebung laufen, den Plan. Er muss leer sein. Keine Änderung, kein Neuaufbau, nichts.

Ein leerer Plan bedeutet, dass der Code exakt das beschreibt, was in der Cloud steht. Meldet er Änderungen, beschreibt der Code etwas anderes als die Realität, und dann ist er gefährlicher als gar kein Code, weil ihm jemand glauben wird.

Was das Modell nicht auflösen konnte, gehört auf eine Liste. Ein Secret, eine von Hand gesetzte Firewall-Regel, eine Abhängigkeit, die nirgends dokumentiert ist. Ein Werkzeug, das an dieser Stelle rät statt zu markieren, kostet dich irgendwann eine Produktionsumgebung.

Danach wird weiter geklickt

Mit dem leeren Plan ist es nicht vorbei, denn im Portal wird weiter geklickt. Der Plan läuft von da an regelmässig, und jede Abweichung stellt dieselbe Frage. Gehört die Änderung in den Code, oder gehört sie zurückgedreht.

Diese Richtung ist jedes Mal eine Entscheidung. Die Firewall-Regel, die um drei Uhr nachts die Produktion gerettet hat, gehört in den Code. Die Regel, die jemand auf eigene Faust gesetzt hat, gehört weg. Im Diff sehen beide identisch aus, und der Unterschied steht nirgends in der Cloud, sondern nur im Kopf der Person, die geklickt hat.

Deshalb endet die Automatik beim Vorschlag. Das Modell erkennt die Abweichung, ordnet sie ein, schreibt den Pull Request mit Begründung, und ein Mensch merged. Wer eine KI unbeaufsichtigt apply ausführen lässt, hat sein Drift-Problem gegen ein Risiko mit besserem Vokabular getauscht.

Der unbequeme Teil

Der Bestand ist nach ein paar Tagen in Code. Ob er in Code bleibt, entscheidet kein Werkzeug. Bleibt der Weg über das Portal offen, stehst du in einem halben Jahr wieder am selben Punkt, nur mit einem Repository, dem niemand mehr traut. In der Produktion haben Menschen lesenden Zugriff, geändert wird über die Pipeline. Das ist eine Führungsentscheidung, und sie durchzusetzen ist härter als alles Technische daran.

Wenn du wissen willst, wo du stehst, brauchst du dafür kein Programm. Nimm die Ressourcengruppe, an der dein wichtigstes System hängt, lass den Ist-Zustand in Code übersetzen und lass den Plan laufen. Was dann an Abweichungen auftaucht, ist dein ehrlicher Ausgangspunkt.

Und bevor das Ergebnis in deinem BCM als Nachweis auftaucht, baust du damit einmal wirklich in der Zielregion auf. Bis dahin ist es ungetesteter Code.

ISO 27001: Der gefährlichste KI-Befund ist der Freispruch

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Wenn ich über KI lese, geht es um Code oder um Text für Marketing und Sales. Beides funktioniert gut. Beides ist auch der Grund, warum ein Anwendungsfall kaum vorkommt, der in jedem zertifizierten Betrieb sofort Geld wert ist: der Abgleich zwischen dem, was dein ISMS behauptet, und dem, was deine Infrastruktur tatsächlich durchsetzt.

Du bist nach ISO 27001 zertifiziert. Deine Infrastruktur läuft in Azure, deine Endgeräte hängen an Intune. Dein ISMS beschreibt, welche Regel gilt und welche Policy sie erzwingt. Am Tag der Zertifizierung stimmt das.

Danach driftet es.

Zwei Dokumente, zwei Anlässe, selten dieselbe Person

Das ISMS fasst jemand an, wenn ein Kunde in der Lieferantenprüfung etwas wissen will. Die Policy fasst jemand an, wenn am Montagmorgen etwas nicht funktioniert. Zwei Auslöser, zwei Wochen, oft zwei Personen.

Du sagst einem Kunden eine Verschärfung zu und ziehst sie in Intune nach. Das ISMS bleibt stehen. Oder umgekehrt: die Regel steht sauber im Dokument, und die Policy, die sie durchsetzen soll, bekommt ein halbes Jahr später eine Ausnahme, weil ein Team sonst nicht arbeiten kann. Keiner der beiden Vorgänge ist ein Fehler. Zusammen ergeben sie eine Dokumentation, die etwas anderes behauptet als deine Maschinen tun.

Das findest du nicht durch Hinsehen. Nicht weil es versteckt wäre, sondern weil du den Blick verlierst. Wer ein ISMS über Jahre pflegt, liest die eigenen Sätze irgendwann nicht mehr, sondern erinnert sich an sie. Erinnerung ist grosszügig. «So war das gemeint» steht dann eben nicht da.

Die Policy, die es gibt und die nichts tut

Der unangenehmste Fall ist ein dritter. Die Policy existiert, sie ist sauber benannt, sie ist zugewiesen, und sie wirkt trotzdem nicht.

Intune ist über die Jahre gewachsen. Dieselbe Einstellung lässt sich heute an vier verschiedenen Orten setzen: im aktuellen Settings Catalog, in den älteren Konfigurationsprofilen, in den administrativen Vorlagen und in den alten Security Baselines. Jeder dieser vier Orte ist eine eigene Liste. Intune zeigt sie dir nirgends zusammengeführt, und wer sie auswertet, muss jede einzeln abfragen.

Am Gerät landen sie trotzdem alle an derselben Stelle. Setzen zwei zugewiesene Policies denselben Wert unterschiedlich, greift keine von beiden verlässlich.

Dein ISMS sagt dann: Defender wird über Policy X erzwungen. Policy X gibt es. Der Satz im Dokument ist wahr. Das Gerät ist trotzdem ungeschützt.

Solche Konstellationen entstehen in bester Absicht. Eine Baseline von vor vier Jahren pflegt Defender, BitLocker und Firewall mit, jemand legt später dedizierte Endpoint-Security-Policies an, niemand räumt die Baseline ab. Beide sind zugewiesen, beide sehen im Portal grün aus.

Wo die KI wirklich stark ist

Aus einem unspektakulären Grund: sie langweilt sich nicht. Dreihundert Einstellungen gegen einen Kontrolltext zu halten, Zuweisungen zu vergleichen, jede Behauptung im Dokument gegen den tatsächlich gesetzten Wert zu prüfen, ist genau die Arbeit, bei der ein Mensch nach zwanzig Minuten anfängt zu überfliegen. Verbindest du ein Modell mit dem ISMS und mit der Durchsetzungsebene, bekommst du in Stunden eine Gegenüberstellung, für die du sonst Wochen einplanst.

Sie findet dabei auch, wonach niemand ausdrücklich gefragt hat, solange es in den Daten steht. Ein Gerät, das sich in Entra anmeldet und in Intune gar nicht geführt wird, fällt beim Abgleich zweier Quellen sofort auf, weil die beiden Listen nicht zusammenpassen. Dasselbe gilt für Geräte, die als nicht konform zurückgemeldet werden, und für solche, die seit Wochen nicht mehr synchronisiert haben.

Und dann produziert dasselbe Modell mit voller Überzeugung den Befund, der dich teuer zu stehen kommt.

Ein falscher Treffer ist peinlich, ein falscher Freispruch ist gefährlich

Der Bericht, den du zurückbekommst, listet die Abweichungen auf, jede mit Fundstelle. Du arbeitest sie der Reihe nach ab. Und ganz unten steht, dass der Rest in Ordnung ist.

An diesen letzten Satz geht danach niemand mehr ran. Einen falschen Treffer prüfst du nach, er löst sich auf, du hast eine Stunde verloren und bist hinterher schlauer. Ein Freispruch kostet dich gar nichts, bis er im Audit als Nachweis auf dem Tisch liegt.

Was in den Daten steht, findet das Modell also. Die Lücke, die in den Daten kein Signal hinterlässt, ist die in deinem eigenen Export. Ziehst du eine der vier Listen von weiter oben und übergibst nur diese, lautet die Antwort «keine Konflikte», und sie stimmt sogar, für diese eine Liste. Über deine Geräte sagt sie nichts, und nirgends in der Antwort steht, dass es drei weitere Listen gibt. Ein Modell, das die Plattform gut kennt, fragt an dieser Stelle vielleicht nach. Verlassen kannst du dich darauf nicht, und wenn es nicht nachfragt, bekommst du keine Fehlermeldung, sondern ein sauberes Ergebnis. Ein sauberes Ergebnis liest sich wie ein sauberes System.

Dieselbe Falle wartet überall dort, wo ein System lange genug gewachsen ist, dass der alte Weg neben dem neuen weiterlebt, und das ist in einer zehn Jahre alten Umgebung eher die Regel als die Ausnahme.

Nach einem sauberen Ergebnis musst du deshalb wissen, was auf dem Tisch lag, als das Modell geprüft hat.

Die Arbeit steckt nicht im Prompt

Sie steckt in der Frage, was vollständig heisst, und die musst du beantworten, bevor die Auswertung läuft.

Zähl vorher auf, an welchen Stellen die Einstellung überhaupt stehen kann, und frag jede davon ab. Jedes System mit Geschichte hat neben dem heutigen Weg noch zwei oder drei alte, die weiterhin aktiv sind.
Behandle ein leeres Feld nicht als Beweis für Abwesenheit. Mach die Gegenprobe an einem zweiten Weg oder direkt im Portal, und zwar an einem Objekt, von dem du weisst, wie es gesetzt ist.
Frag bei allem, was falsch aussieht, zuerst nach dem Zweck. Eine Abweichung von der Norm ist noch kein Befund, sondern eine Frage nach der Absicht, die noch niemand gestellt hat.

Und nimm einen Status im Portal nicht für bare Münze. Ein Gerät, das seit drei Wochen nicht synchronisiert hat, zeigt dir den Zustand von vor drei Wochen. Halte den Zeitpunkt der letzten Synchronisierung gegen den Zeitpunkt deiner Änderung, sonst jagst du Konflikte, die längst behoben sind.

Dasselbe Vorgehen, bevor das ISMS überhaupt existiert

Baust du ein ISMS neu auf, bekommst du einen Satz Kontrolltexte aus einer Vorlage, formulierst sie auf dein Unternehmen um und beschreibst, wie es laufen soll. Danach beginnt die Arbeit, das Beschriebene und das tatsächlich Laufende in Deckung zu bringen. Der Drift aus diesem Artikel ist dann am ersten Tag schon angelegt.

Die Reihenfolge lässt sich umdrehen. Lies zuerst aus, was in Azure und Intune wirklich erzwungen wird, und lass die KI die Kontrolltexte aus diesem Befund heraus generieren. Für alles, was bereits sauber durchgesetzt ist, formuliert dir das Modell die Beschreibung samt der Policy. Für alles ohne Entsprechung bekommst du eine Liste dessen, was du umsetzen oder als akzeptiertes Restrisiko begründen musst. Es ist dieselbe Auswertung wie oben, nur früher, und sie ist an derselben Stelle angreifbar: ein unvollständiges Inventar produziert hier kein falsches Auditergebnis, sondern ein ISMS, das von Anfang an etwas anderes behauptet als deine Maschinen tun.

Der Auditor fragt dich nicht, womit du deine Abweichungen gefunden hast. Er fragt, ob dein Dokument stimmt. Zwischen «die KI hat nichts gefunden» und «da ist nichts» liegt dein Inventar. Das baust immer noch du.

Seit Juli gibt es eine Liste von Anbietern, auf deren Produkt nachweislich ein Agent läuft. Deiner steht vermutlich nicht darauf.

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Im Juli hat die MACH Alliance, ein Zusammenschluss von Technologieanbietern rund um offene, modulare Architekturen, zum ersten Mal einen Award namens Agent Ready vergeben. Mehr als dreissig Unternehmen haben ihn bekommen, darunter Amazon Web Services, Google Cloud, Stripe, Twilio, MongoDB, Adyen, Vercel und auf der Dienstleisterseite Accenture Song, Deloitte Digital und WPP.

Die Auszeichnung selbst ist nicht die Nachricht. Awards gibt es viele. Die Nachricht ist, was diese Unternehmen dafür nachweisen mussten.

Das Kriterium ist unangenehm konkret

Es genügt ausdrücklich nicht, eine Schnittstelle zu haben. Es genügt keine Roadmap, keine Absichtserklärung und kein Architekturdiagramm.

Verlangt wird der Nachweis, dass ein Kunde einen Agenten gebaut hat, der produktiv mit dem Produkt des Anbieters arbeitet. Über offene Standards, ausdrücklich genannt sind APIs, MCP, A2A und Webhooks, ausdrücklich in Abgrenzung zu einer proprietären Blackbox. Die Alliance prüft das gegen eingereichte Belege, und die Anerkennung muss jährlich erneuert werden.

Der Zweck steht offen dabei: eine dokumentierte, unabhängig geprüfte Antwort auf die Frage, was die Agenten-Strategie eines Anbieters ist und was davon heute läuft, damit ein Einkäufer diese Beurteilung nicht anhand eines Verkaufsdecks treffen muss.

Damit ist zum ersten Mal formuliert, wonach in diesem Feld überhaupt gefragt wird. Nicht nach einer Fähigkeit, sondern nach einem laufenden Fall.

Warum du das nicht nachrüsten kannst

Die meisten Anforderungen, die ein Einkäufer stellt, kannst du kurzfristig erfüllen. Eine Schnittstelle lässt sich nachbauen, eine Dokumentation nachschreiben, ein Prüfsiegel im Eiltempo durchziehen. Unangenehm, aber machbar.

Dieses Kriterium nicht, denn es verlangt keine Fähigkeit, sondern eine Referenz. Du brauchst einen Kunden, dessen Agent dein Produkt bereits im Betrieb bedient. Dafür brauchst du einen Kunden, der das will, ein Produkt, das es zulässt, und Zeit.

Wer heute anfängt, hat in zwölf Monaten einen produktiven Fall, den er benennen kann. Wer anfängt, wenn die Frage im Verkaufsgespräch steht, hat eine Absichtserklärung. Der Unterschied ist zeitlich, nicht technisch, und genau deshalb ist er nicht aufholbar.

Die ehrliche Einordnung, damit das hier keine Verbandswerbung wird

Drei Dinge, die gegen eine Überhöhung sprechen.

Der Award ist Mitgliedern vorbehalten. Wer nicht in der MACH Alliance ist, kann sich gar nicht bewerben, egal wie agentenfähig sein Produkt ist. Das ist kein offener Standard und keine Zertifizierung, die du wie ISO 27001 durchlaufen kannst.

Eine Auszeichnung, die an eine Mitgliedschaft geknüpft ist, hat immer eine Eigeninteressen-Komponente. Das entwertet den Nachweis nicht, aber man sollte es aussprechen.

Und die Alliance kommt aus einer bestimmten Ecke, dem Umfeld modularer Handels- und Content-Architekturen. Ob sich das über andere Branchen ausbreitet, ist offen.

Was davon unberührt bleibt, ist die Frage selbst. Ob sie Agent Ready heisst oder anders, ob sie von einem Verband kommt oder von einem Einkäufer: Sie lautet in jedem Fall, ob bei einem deiner Kunden ein Agent produktiv auf deinem Produkt läuft.

Und die Antwort darauf hängt nicht davon ab, ob du Mitglied irgendwo bist.

Die Frage kommt nicht vom Verband, sie kommt von deinem Kunden

Das ist der Punkt, an dem ich die Sache ernster nehme, als ein Award es rechtfertigen würde.

Der Druck entsteht nicht dadurch, dass eine Organisation ein Label vergibt. Er entsteht dadurch, dass in den Unternehmen deiner Kunden bereits Assistenten arbeiten. Sobald der Einkäufer auf der anderen Seite des Tisches selbst mit einem Agenten arbeitet, stellt er die Frage von allein, und zwar lange bevor sie in einem Pflichtenheft steht.

Wenn dreissig Anbieter, darunter die grössten Infrastrukturhäuser des Marktes, diese Frage seit Juli mit einem geprüften Ja beantworten können, dann ist damit auch der Vergleichsmassstab gesetzt. Nicht formal, aber praktisch.

Was du in den nächsten Monaten tun kannst

Beantworte die Frage einmal schriftlich für dich selbst. Wenn ein Kunde morgen nach einem produktiven Fall fragt, was steht in deiner Antwort? Steht dort «in Planung», hast du dein Ergebnis.

Such dir den einen Kunden, mit dem es geht. Du brauchst keine Marktabdeckung, du brauchst einen laufenden Fall, den du benennen darfst. Der beste Kandidat ist der Kunde, der ohnehin schon fragt.

Entscheide, welche Vorgänge nach draussen gehen, bevor jemand eine Zeile Code schreibt. Welche Aufgaben ein fremder Agent auslösen darf und wer sie mit wessen Rechten auslöst, ist eine Produktentscheidung und keine technische. Das Protokoll darunter ist die kleinste Entscheidung im ganzen Vorhaben und in Tagen erledigt.

Und rechne damit, dass du die Frage zuerst im Verkaufsgespräch hörst. Dort entscheidet sie sich, nur ohne Protokoll und ohne Absageschreiben, aus dem du lernen könntest.

Die dreissig Namen auf dieser Liste haben nichts gewonnen, was du nicht auch haben könntest. Sie haben nur zwölf Monate früher angefangen.

Deine Oberfläche war dein Produkt. Dein nächster Kunde wird sie nie sehen.

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Seit dem 14. August 2025 kannst du in Deutschland und neun weiteren europäischen Märkten ein Telefon kaufen, das die App-Oberfläche als zentrale Bedienung abgeschafft hat. Es heisst AI Phone, kommt von der Deutschen Telekom, kostet 149 Euro, und du bedienst es per Sprache über den Perplexity Assistant. E-Mail schreiben, anrufen, Musik starten, Kalendereintrag anlegen, Tisch reservieren, einkaufen. Ohne dass du eine App öffnest. Im Oktober 2025 kam die Pro-Version nach.

Das ist kein Konzeptvideo. Das ist ein Gerät mit einer Artikelnummer.

Und es ist erst der Anfang. Im April 2026 berichtete der Analyst Ming-Chi Kuo, dass OpenAI zusammen mit Qualcomm, MediaTek und Luxshare an einem Telefon arbeitet, dessen Bedienkonzept nicht aus Apps besteht, sondern aus Agenten. Die Spezifikation soll bis spätestens Anfang 2027 stehen, die Massenproduktion 2028 beginnen. Auf der Weltkonferenz für künstliche Intelligenz 2026 haben Honor, Nubia und Stepverse ihre eigenen agentischen Smartphones gezeigt.

Wenn du Software herstellst, ist das keine Gerätemeldung. Das ist die Ankündigung, dass dein wichtigster Kunde bald keine Augen mehr hat.

Der Kunde, der deinen Shop nie betritt

Im Handel ist es schon so weit. Am 29. September 2025 haben Stripe und OpenAI das Agentic Commerce Protocol veröffentlicht, einen offenen Standard, über den ein Assistent direkt beim Händler bestellt. Der Käufer bleibt im Chat. Der Händler nimmt die Bestellung an oder lehnt sie ab, bucht die Zahlung über seinen bestehenden Anbieter, rechnet die Steuer ab, versendet und bearbeitet Retouren wie bisher.

Lies den letzten Satz noch einmal. Der Händler macht alles wie bisher. Nur eines fällt weg: Niemand sieht seinen Shop.

Etsy-Händler sind angebunden, Shopify-Händler folgen. Das sind keine Nischenanbieter, das ist ein grosser Teil des europäischen und amerikanischen Kleinhandels. Ihre Produktseiten, ihre Filter, ihre Warenkorb-Optimierung, ihre A/B-Tests am Kaufknopf: für diesen Bestellweg vollständig irrelevant.

Was zuerst stirbt, sind deine Bequemlichkeits-Upsells

Jetzt kommt der Teil, der weh tut, und er trifft dein Preisblatt.

Schau dir an, wofür du heute Aufpreise verlangst. In den allermeisten Produkten steht dort dasselbe Muster: Der Kunde zahlt dafür, dass er weniger tun muss. Massenimport statt Einzelerfassung. Vorlagen statt Neuanlage. Der geführte Assistent statt sieben einzelner Masken. Der Bericht auf Knopfdruck statt Export und Excel. Das Premium-Paket, das eine Stunde Handarbeit pro Woche spart.

Diese Posten haben eines gemeinsam: Sie verkaufen gesparte menschliche Zeit.

Ein Agent kauft das nicht. Nicht weil seine Arbeit gratis wäre, Token kosten Geld und Latenz ist real. Sondern weil die Grössenordnung kollabiert. Zwanzig gesparte Minuten deiner Sachbearbeiterin sind einen zweistelligen Frankenbetrag wert. Zwei gesparte Aufrufe deines Kunden-Agenten sind Bruchteile eines Rappens wert. Der Wert verschwindet nicht auf null. Aber der Preis, den du dafür durchsetzen kannst, schon.

Deine Risikoliste ist damit keine Technikliste. Es ist deine Preisliste. Geh sie durch und markiere jede Position, deren Nutzenversprechen «spart Aufwand» lautet. Was übrig bleibt, ist das, was du wirklich verkaufst.

Die UX-Arbeit ist nicht verloren. Sie liegt am falschen Ort.

Hier widerspreche ich der bequemen Lesart, dass zehn Jahre Oberflächenarbeit umsonst waren.

Ein guter Assistent ist nicht bloss Grafik. Er ist eine Antwort auf harte Fragen: In welcher Reihenfolge muss ein komplexer Vorgang abgearbeitet werden. Welche Angabe ist zwingend, welche optional. An welcher Stelle braucht es eine Entscheidung, die niemand automatisch treffen darf. Was passiert, wenn eine Voraussetzung fehlt.

Diese Fragen stellen sich für einen fremden Agenten haargenau gleich. Die Antworten stehen nur nicht mehr auf einem Bildschirm, sondern im Zuschnitt deiner Werkzeuge, in ihren Schemata und in dem, was du als zwingend deklarierst.

Wer den Assistenten gebaut hat, hat die eigentliche Denkarbeit also längst geleistet. Er hat sie an einer Stelle abgelegt, die der neue Nutzer nicht mehr aufruft. Das ist die gute Nachricht: Du musst nicht neu denken, du musst umziehen.

Die schlechte: Ein Team, das diese Arbeit weiterhin ausschliesslich in Pixeln ablegt, produziert ab heute Wissen mit begrenzter Haltbarkeit.

Und wer bezahlt das eigentlich

Die Frage, an der es bei den meisten hakt, wenn sie das zu Ende denken: Ich würde meinem Assistenten heute keine Kreditkartennummer geben.

Solltest du auch nicht. Und genau darum wird gerade an etwas anderem gebaut.

Google hat am 16. September 2025 das Agent Payments Protocol vorgestellt, zusammen mit über sechzig Organisationen, darunter Mastercard, American Express, PayPal, Adyen, Revolut, Worldpay, UnionPay, Coinbase, Etsy und Salesforce. Es erweitert ausdrücklich auch das Model Context Protocol, also genau die Schicht, über die ein Agent dein Produkt bedient.

Der Kern ist nicht die Zahlung, sondern die Vollmacht. Das Protokoll arbeitet mit signierten Mandaten: Ein Intent Mandate hält fest, was du deinem Agenten überhaupt erlaubt hast, inklusive Preisgrenzen und Bedingungen. Ein Cart Mandate hält unveränderbar fest, was konkret bestellt wurde. Zusammen ergeben sie eine Beweiskette für drei Fragen, die ohne sie unbeantwortbar sind: Hatte der Agent die Erlaubnis. Entspricht die Bestellung dem tatsächlichen Willen des Menschen. Und wer trägt es, wenn es schiefgeht.

Bei der Abrechnungsschiene ist die Sache offen. Es gibt den Weg über die Kartennetze, und es gibt den Weg über Stablecoins, weil eine Kartentransaktion für einen Einkauf unter einem Franken schlicht unwirtschaftlich ist. Für die zweite Schiene hat die Solana Foundation zusammen mit Google Cloud Pay.sh gestartet, über das ein Agent bezahlpflichtige Programmierschnittstellen direkt aus einer Wallet bezahlt, ohne Konto und ohne Schlüssel. Der Satz dazu ist bemerkenswert kurz: die Zahlung ist die Berechtigung.

Welche Schiene sich durchsetzt, weiss heute niemand. Dass die Frage entschieden wird, bevor dein Produkt sie stellt, ist ziemlich sicher.

Was du dieses Jahr tun kannst, ohne etwas umzubauen

Vier Dinge, die nichts kosten ausser Denkarbeit.

Trenne Oberfläche von Fähigkeit. Geh durch deine wichtigsten Vorgänge und markiere jeden, der nur über einen Klickpfad existiert und keine aufrufbare Entsprechung hat. Für einen Agenten ist das kein schlecht bedienbarer Vorgang. Es ist ein Vorgang, den es nicht gibt.
Nimm dir die Preisliste vor, wie oben beschrieben. Wenn mehr als ein Drittel deiner Aufpreise gesparte Handarbeit verkauft, hast du kein Produktproblem, sondern ein Geschäftsmodellproblem mit Vorlaufzeit.
Prüfe, ob eine Maschine versteht, wofür dein Produkt taugt. Ein Agent, der nicht weiss, welches Problem du löst, nimmt dich nicht in die Auswahl. Das ist die andere Hälfte derselben Entwicklung, und sie entscheidet, ob du überhaupt gefragt wirst.
Kläre die Vollmachtsfrage, bevor der erste fremde Agent bestellt. Wer darf in wessen Namen etwas auslösen, wie weist du es nach, und was passiert bei einer Fehlbestellung. Das ist keine technische Frage, und sie gehört nicht ins Entwicklungsteam allein.

Die ehrliche Einschränkung

Das kommt nicht überall gleich schnell. Im Handel läuft es bereits, im Fachverfahren einer Pensionskasse dauert es Jahre. Und es läuft auch nicht reibungslos: OpenAI hat den eigenen Bestellweg im März 2026 bereits wieder umgestellt.

Die Oberfläche stirbt auch nicht. Es gibt Vorgänge, bei denen ein Mensch sehen will, was passiert, und überall dort, wo jemand geradestehen muss, wird er hinschauen. Wer das Gegenteil verkauft, verkauft dir eine Folie.

Was sich ändert, ist die Rangfolge. Die Oberfläche war jahrelang der Ort, an dem dein Produkt gewonnen oder verloren hat. Sie wird zu einem von mehreren Zugängen, und nicht mehr zum wichtigsten.

Die Frage ist nicht, ob deine Nutzer dich weiterhin anklicken. Die Frage ist, was von deinem Produkt übrig bleibt, wenn niemand mehr hinsieht.

Deine KI-Ersparnis steht im Prüfstau deines Teams

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Du wirst es nicht an dir selbst merken. Brain Fry trifft die Leute, die prüfen, nicht die, die entscheiden. Bei dir kommt es als Kennzahl an: Die Fehlerquote steigt, obwohl alle mehr schaffen. Freigaben dauern länger. Jemand Gutes kündigt und nennt im Austrittsgespräch keinen Grund, den du beheben könntest.

Anfang März hat die Harvard Business Review den Begriff in Umlauf gebracht, dahinter steckt eine BCG-Studie mit 1'488 Vollzeitbeschäftigten in grossen US-Unternehmen. Der Befund: Wer den Tag damit verbringt, KI-Ergebnisse zu überwachen statt selbst etwas zu produzieren, berichtet mehr Fehler, mehr Entscheidungsüberlastung und häufiger die Absicht zu kündigen. Es sind Selbstauskünfte aus einer Umfrage, keine gemessenen Fehlerquoten. Die Richtung ist belastbar, die Nachkommastellen nicht.

Was du siehst, und was deine Leute erleben

Vor der KI hat dein Team fünf Vorgänge pro Woche geprüft, weil fünf entstanden sind. Heute entstehen fünfzig, weil ein Modell Code, Werbetexte oder eine ganze Landingpage in Minuten erzeugt. Die Erzeugung ist billig geworden, die Prüfung nicht. Der Stau steht jetzt vor der letzten menschlichen Instanz.

Für die Person auf diesem Stuhl ist das nicht einfach mehr Arbeit, sondern eine andere Arbeit. Aus dem Vorgang ist die gestaltende Hälfte verschwunden und die kontrollierende ist übrig geblieben. Wer beides hatte, erlebt den Rest als Verlust, auch wenn die Stückzahl steigt. Es fühlt sich an wie Fliessband, weil es eines ist.

Der für dich teuerste Teil des Befundes ist die Kündigungsabsicht. Es trifft nicht die Schwächsten, sondern die mit dem meisten Erfahrungswissen, denn nur die bekommen die Prüfung überhaupt zugeteilt. Und dieses Wissen ist nirgends dokumentiert, sondern steckt in ihren Köpfen. Das ist kein Personalthema, das ist ein Klumpenrisiko.

Der erste Fehler passiert in deiner Messung

Die Studie beschreibt Firmen, die den Token-Verbrauch ihrer Leute als Leistungsindikator belohnen. Das ist die extreme Variante eines verbreiteten Fehlers: Du misst die Hälfte, die billig geworden ist. Anzahl generierter Entwürfe, Adoptionsrate, ausgelieferte Pull Requests vor dem Review. Wer das belohnt, belohnt das Wachsen der Warteschlange.

Zwei Grössen sagen dir, was wirklich passiert. Erstens der Durchsatz bis zur Auslieferung, nicht bis zur Erzeugung. Zweitens die Zahl der Fehler, die trotz Prüfung durchgerutscht sind, gemessen an dem Punkt, an dem sie später auffallen. Steigt die erste Zahl nicht und die zweite schon, hast du keine Effizienz gekauft, sondern Tempo vor einer verstopften Stelle.

Prüftiefe zu differenzieren ist eine Erlaubnis, keine Technik

Nicht jeder Vorgang verdient dieselbe Tiefe. Ein Modell irrt nicht gleichmässig, sondern an bestimmten Stellen systematisch. Drei Grössen entscheiden gemeinsam: wie oft es hier danebenliegt, was der Fehler kostet, und ob er später ohnehin auffliegt. Ein Tippfehler im Newsletter ist häufig, billig und wird dir von der ersten Leserin gemeldet. Eine falsch gesetzte Berechtigungsprüfung ist selten, teuer und bleibt still, bis sie es nicht mehr ist.

Hier liegt der Punkt, den nur du lösen kannst. Kein Mitarbeiter prüft von sich aus oberflächlicher, denn im Fehlerfall steht er allein da. Ohne eine geschriebene Regel, welche Vorgangsklassen flach geprüft werden und wer die Konsequenz trägt, prüft jeder alles, aus Selbstschutz. Risikobasiertes Prüfen ist keine Methode, die man einführt, sondern eine Rückendeckung, die man gibt.

Ein KI-Review ist eine Investition mit Messpflicht

Der naheliegende Griff ist, ein zweites Modell vorprüfen zu lassen. Das kann funktionieren, es ist aber der schwächste der drei Hebel, und schlecht eingekauft verschlimmert er das Problem. Ein KI-Review erzeugt Findings, und Findings muss wieder jemand prüfen. Wenn zwei von drei Fehlalarme sind, hast du die Prüflast erhöht, und zwar mit genau der Sorte Arbeit, die ermüdet.

Bevor du so etwas ausrollst, lass die Trefferquote an zwanzig bereits geprüften Vorgängen messen. Zähle, was das Modell findet und was es erfindet. Ein Finding lohnt sich nur, wenn es billiger zu beurteilen ist, als die Stelle selbst zu suchen: mit Fundstelle, mit Verweis auf die verletzte Regel, mit konkretem Gegenvorschlag. «Der Text könnte klarer sein» kostet mehr, als es spart.

Das Wertvollste in deiner Abteilung steht nirgends

Menschen prüfen nicht willkürlich. Über Monate bildet sich ein Katalog: die Stellen, an denen es schon einmal schiefging, die Formulierung, die in der Freigabe immer beanstandet wird, die Zahl, die nie stimmt. Deine Leute arbeiten ihn ab, teils bewusst, teils ohne es zu merken. Dieser Katalog ist der eigentliche Wert der Prüfarbeit, und er verlässt das Haus mit der Person.

Lass ihn aufschreiben. Nicht an einem Vorgang, sondern an zehn, sonst hältst du Zufall für Muster. Was sich wiederholt, ist das Verfahren, der Rest sind Einzelfälle.

Der Haken ist banal und wird trotzdem fast immer übersehen: Wer fünfzig Vorgänge pro Woche prüft, hat keine Zeit dafür. Das passiert nicht nebenbei und nicht aus Eigeninitiative. Wenn du es willst, stellst du dafür Zeit frei und nimmst sie aus dem Durchsatz. Sonst passiert es nie, und das ist der häufigste Grund, warum dieser Ansatz scheitert.

Genau hier liegt auch der Unterschied zwischen normaler Anstrengung und Brain Fry. Wenn jemand bei dreissig von fünfzig Vorgängen dieselbe Korrektur macht und diese Korrektur nirgends hinfliesst, macht er sie nächste Woche wieder. Prüfen ermüdet nicht, weil es anstrengend ist, sondern weil es folgenlos bleibt. Jede Korrektur, die zum zweiten Mal gemacht wird, ist eine Regel, die noch niemand geschrieben hat.

Automatisieren, und zwar ohne Modell

Wenn die Regeln stehen, gehören sie in ein Werkzeug, das stur ist. Ein Workflow in n8n, ein Skript, ein Linter, ein Pflichtfeld im Formular. Was zählt, ist die Eigenschaft: gleiche Eingabe, gleiches Urteil, heute wie in drei Monaten.

Deshalb gehört an diese Stelle kein Sprachmodell. Ein Modell driftet. Es beurteilt denselben Vorgang morgen anders, es verschiebt sich mit dem nächsten Release, und niemand merkt es, weil das Ergebnis weiterhin plausibel klingt. Ein Prüfverfahren, das sich unbemerkt selbst ändert, ist kein Prüfverfahren, sondern eine zweite Meinung. Und die Regel bricht ab, statt durchzuwinken: Ein sichtbar gestoppter Vorgang ist billiger als einer, der still falsch durchläuft.

Was danach noch bei Menschen landet, sind die Spezialfälle. Dafür hast du sie eingestellt.

Drei Einwände, die stimmen

Der erste ist der Widerstand deiner Leute, und er ist berechtigt gemeint: Wer sein Prüfwissen aufschreibt, fragt sich, ob er sich überflüssig macht. Wenn du diese Frage nicht von dir aus beantwortest, bekommst du einen unvollständigen Katalog und merkst es nicht. Die ehrliche Antwort ist, dass der schwierige Teil bei ihnen bleibt und der stumpfe verschwindet, und dass sie das nur glauben, wenn du es vorher schriftlich sagst.

Der zweite ist der Kalibrierungsverlust. Wer nur noch Ausnahmen zu sehen bekommt, verliert das Gefühl für den Normalfall und hält bald alles für eine Ausnahme. Ein kleiner Anteil Normalfälle bleibt deshalb in der Stichprobe, nicht weil er nötig wäre, sondern weil er das Urteilsvermögen eicht.

Der dritte ist die Alterung. Ein Katalog prüft, was letztes Quartal schiefging. Wechselt das Modell, wechselt die Fehlerverteilung. Und nicht alles ist deterministisch prüfbar: Vollständigkeit, Form, Konsistenz, Zahlen, Grenzwerte und Verweise ja, ob ein Text gut ist nicht. Der automatisierbare Teil ist oft der kleinere. Er ist aber der ermüdende, und deshalb lohnt er sich.

Was du davon hast

Der Engpass verschwindet nicht. Er wandert weiter, zur Entscheidung, zur Verantwortung, zur Auslieferung. Das Ziel ist kein Betrieb ohne Engpass, sondern einer, in dem der Engpass nicht auf einem einzelnen Menschen sitzt, der ihn mit seiner Aufmerksamkeit bezahlt.

Was diese Person zurückbekommt, taucht in keiner Effizienzrechnung auf: die Pause, das Gespräch am Kaffeeautomaten, den Feierabend ohne Restrauschen. Das ist kein Wohlfühlargument. Es ist die Bedingung dafür, dass sie die schwierigen Fälle morgen noch erkennt, und die schwierigen Fälle sind die einzigen, die du ihr noch gibst.

Die KI hat deinem Team die schöne Hälfte der Arbeit abgenommen. Was übrig bleibt, automatisierst du, oder es kostet dich die Leute.

Kein Mensch in deinem Betrieb sieht den ganzen Fehler. Eine KI schon.

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Nicht weil sie klüger wäre, sondern weil sie gleichzeitig sehen darf, was dein Team nacheinander zusammentragen muss. Was dieses Nacheinander kostet, weiss jeder, der schon einmal einen Produktionsfehler unter Kundendruck gejagt hat.

DevOps wühlt sich durch Berge von Logs, stellt Zusammenhänge her, korreliert Zeitstempel mit Code und Datenkonstellation. Unter Zeitdruck, weil eben etwas schief gegangen ist. Dann die Übergabe an die Entwicklung. Warten. Rückmeldung: nicht reproduzierbar. Kontext nachliefern. Warten. Analyse, Fix. Halber Tag im Eimer, und ein guter Teil davon war reine Latenz zwischen zwei Menschen, die denselben Fehler aus zwei verschiedenen Blickwinkeln betrachtet haben.

Diese Kette existiert nicht, weil Fehlersuche schwer ist. Sie existiert, weil das Wissen an drei Orten liegt: die Telemetrie bei DevOps, der Quellcode bei der Entwicklung, die auslösende Datenkonstellation in der Produktion. Keiner dieser Orte spricht mit den anderen. Der Mensch ist das Transportmittel dazwischen, und der Mensch ist langsam.

Was sich geändert hat, ist nicht das Modell

Konkretes Setup: Grafana für Logs, Metriken und Traces. Der Quellcode in exakt dem Stand, der aktuell deployed ist, nicht im Hauptzweig. Zugriff auf die Datenbank, in der das Szenario tatsächlich vorliegt. Und Claude Code als Agent darüber.

Der Punkt mit dem deployten Stand ist der, an dem klassische Reproduktionsversuche am häufigsten scheitern. Der Entwickler debuggt gegen den Code von heute, der Fehler ist im Code von vorletzter Woche passiert. Genau diese Korrelation, über drei Systeme und einen Zeitversatz hinweg, ist die Aufgabe, für die eine Maschine gebaut ist und ein Mensch nicht.

Der Ablauf

DevOps gibt dem Agenten die Fehlermeldung. Ab da läuft die Analyse autonom:

Fehlerstelle finden. Der Agent sucht den Vorfall in Grafana, über eine angemeldete Session oder ein API-Token, und arbeitet sich vom Symptom über Trace und Korrelation zur auslösenden Anfrage vor.
Reproduzieren. Er zieht die Datenkonstellation, die das Verhalten erzeugt hat, und giesst sie in einen Test, der den Fehler zuverlässig auslöst. Ab diesem Moment ist der Fehler kein Bericht mehr, sondern ein roter Balken.
Ursache lokalisieren. Mit dem produktiven Kontext und dem passenden Quellcode findet er die Stelle, die den Fehler auslöst.
Fix vorschlagen und belegen. Der Test zeigt, dass der Fix greift. Danach bleibt er als Regressionstest liegen, statt mit dem Ticket zu verschwinden.

Der ganze Block dauert Minuten, nicht Stunden. Und die Kategorie «nicht reproduzierbar» verschwindet, weil der reproduzierende Test Teil der Analyse ist und nicht ihr Ergebnis.

Während der Mensch den Fix prüft, schreibt der Agent die Root-Cause-Analyse für den Kunden. Er hat als Einziger den vollständigen Kontext dafür im Kopf, den ein Mensch sonst hinterher mühsam rekonstruiert.

Was der Mensch behält

Alles, was Konsequenzen hat.

Das Review des Fixes. Den Commit. Das Hotfix-Deployment. Die Freigabe der Root-Cause-Analyse, bevor sie an den Kunden geht, weil dein Name darunter steht und nicht der eines Modells. Und das Aufräumen der temporären Zugänge danach.

Der eigentliche Gewinn steckt in der Zeit dazwischen. Bisher war die Person, die den Stakeholdern erklären könnte, was los ist, exakt dieselbe Person, die gerade bis zum Hals in den Logs steckt. Kommunikation blieb liegen, und zwar immer genau dann, wenn sie am dringendsten gebraucht wurde. Diese Kollision löst sich auf, sobald das Heavy Lifting parallel läuft.

Die Zugriffsfrage, an der es meistens scheitert

Ein Agent, der Produktionsdaten sieht, ist ein Zugriff wie jeder andere und gehört behandelt wie einer. Vier Punkte reichen:

Ein eigener technischer Account, nicht die Credentials eines Menschen. Lesend, gescopt auf genau die Quellen, die der Vorfall braucht. Befristet auf die Dauer des Vorfalls und danach widerrufen. Und weil es ein eigener Account ist, steht im Audit-Log hinterher, was angefasst wurde.

Der zweite Teil der Antwort ist unbequemer. Was der Agent lesen darf, verlässt deine Umgebung, sobald es in seinem Kontext landet. Die Auswahl der Daten ist damit selbst eine Entscheidung und keine Nebensache. Eine Konstellation, die einen Fehler zeigt, braucht in aller Regel keine Klarnamen dazu. Wer diese Frage einmal sauber beantwortet, hat sie für jeden weiteren Vorfall beantwortet.

Die verbreitete Alternative ist, MCP-Server, API-Zugänge und Agenten pauschal zu sperren. Das ist die einzige Variante, die garantiert nichts bringt und trotzdem etwas kostet. Der Nutzen fällt vollständig weg, das Risiko bleibt, weil deine Leute die Werkzeuge privat weiterbenutzen, nur ohne dein Log.

Warum ausgerechnet dieser Use Case trägt

«KI produziert nur Prototypen» ist ein berechtigter Einwand. Er stimmt überall dort, wo man KI auf offene Probleme wirft. Ein Incident ist das exakte Gegenteil eines offenen Problems:

Die Erwartung ist definiert. Das Fehlverhalten ist beobachtbar. Der Erfolg ist binär prüfbar, rot oder grün. Der Kontext ist vollständig verfügbar, wenn man die Zugänge gewährt.

Diese vier Eigenschaften sind das Auswahlkriterium. Nicht die beeindruckendste Demo, sondern der Ablauf, bei dem eine Maschine ihr eigenes Ergebnis nachweisen kann. Wer nach Use Cases sucht, sucht nach genau diesem Muster, stellt dafür die Werkzeuge bereit und schult die Leute darin. Der Rest ist Theater.

Die Maschine trägt die Last, der Mensch trägt die Verantwortung. Wer diese Reihenfolge umdreht, bekommt am Ende beides nicht.

Du kannst dem Agenten die Schreibrechte nehmen. Deine Leute bringen dann ihren eigenen Laptop mit.

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Ich habe es mehr als einmal gesehen. Unter dem Firmenlaptop liegt ein zweiter, zugeklappt, unauffällig. Er hängt an einem mobilen Hotspot. Er sieht euer Netz nie von innen. Und auf ihm läuft genau das, was die IT letzten Monat gesperrt hat.

Der Mann, dem er gehört, ist kein Saboteur. Er ist der Typ, der seine Arbeit fertig machen will.

Was Cloudflare in neun Tagen gebaut hat

Cloudflare hat im August zwei Bausteine für KI-Governance nachgeschoben, neun Tage auseinander.

Am 5. August kam WriteGuard in die private Beta. Das Werkzeug sitzt zwischen deinem Agenten und dem MCP-Server und entscheidet pro Werkzeug, was passieren darf. Jedes Werkzeug bekommt eine Risikostufe, von read-only über minimal impact und contained write bis critical. Ein Aufruf wird dann entweder durchgelassen, mit Attribution und einem Audit-Event angereichert, oder blockiert, bevor der Handler überhaupt anläuft. Cloudflares eigenes Beispiel: Der Agent soll keinen Merge Request abschliessen und kein Produktions-Deployment auslösen.

Am 14. August kam die Erkennung. Cloudflare Gateway liest bei TLS-inspizierten Anfragen den MCP-Protocol-Version-Header mit und klassifiziert den Verkehr. Damit wird zweierlei sichtbar: Schatten-MCP, also Verbindungen zu Servern, die niemand freigegeben hat. Und Portal-Umgehung, also Leute, die sich direkt mit einem genehmigten Server verbinden und dabei an euren Schutzmechanismen vorbeigehen.

Beides ist sauber gebaut. Und beides beantwortet eine Frage, die du wahrscheinlich gar nicht hast.

Die Erkennung sieht nur die, die ohnehin durch die Tür gehen

Der Satz, an dem alles hängt, ist «bei TLS-inspizierten Anfragen». Übersetzt: Der Verkehr muss durch dich hindurch, damit du ihn siehst.

Der Laptop unter dem Laptop läuft nicht durch dich hindurch. Er läuft über Mobilfunk. Er taucht in keinem Gateway auf, in keinem Header, in keinem Dashboard. Nicht weil Cloudflare schlecht wäre, sondern weil dort schlicht kein Messpunkt ist.

Und jetzt kommt der Teil, den die meisten übersehen. Dein Dashboard wird trotzdem grün. Es zeigt die Compliance derer, die sich ohnehin an die Regeln halten. Je konsequenter du blockst, desto sauberer sieht die Auswertung aus, weil jede Umgehung aus der Messung herausfällt. Du bekommst also nicht Sicherheit, du bekommst eine Zahl, die mit dem Ausmass des Problems negativ korreliert.

Das ist gefährlicher als gar keine Messung, weil du danach handelst.

Der Schalter entscheidet, bevor jemand die Aufgabe kennt

Jetzt Punkt zwei, und der ist unbequemer.

Nimm Confluence. Wir sperren dem Agenten spasseshalber den Schreibzugriff auf Seiten. Was hat das gelöst?

Liest der Agent ohnehin nur, hat die Regel nie gegriffen. Sie steht als grüner Haken in der Governance-Übersicht und hat exakt null bewirkt.

Soll der Agent aber eine Seite aktualisieren, dann fährt er vor die Wand. Und mit ihm der Mitarbeiter, der ihn beauftragt hat.

Denn das ist die eigentliche Schwäche: Die Entscheidung fällt pro Werkzeug, nicht pro Aufgabe. Sie wird von jemandem getroffen, der nicht weiss, was dein Mitarbeiter an diesem Dienstag zu erledigen hat. Der MCP-Entwickler hat den Schreibzugriff nicht aus Übermut eingebaut, sondern weil ohne ihn eine ganze Klasse von Aufgaben unlösbar ist. Wer ihn abschaltet, streicht diese Aufgaben, ohne sie je gesehen zu haben.

Danach gibt es zwei Ausgänge, und beide kosten dich Geld.

Der engagierte Mitarbeiter besorgt sich einen Weg daran vorbei. Du kennst ihn jetzt, er liegt zugeklappt unter dem Firmenlaptop. Aus einem kontrollierten Werkzeug ist ein unkontrolliertes geworden, und du hast es selbst dorthin geschoben.

Der nicht engagierte Mitarbeiter macht die Faust im Sack und erledigt die Aufgabe von Hand. Er beschwert sich nicht, er eskaliert nicht, er fällt in keiner Statistik auf. Die Effizienz, für die du die Agenten eingeführt hast, ist einfach weg. Still.

Rate, welcher der beiden in deinem Reporting auftaucht.

Es gibt eine Kontrolle, die niemanden vor die Wand fährt

Interessanterweise steckt sie im selben Produkt, nur bewirbt Cloudflare sie kaum.

Bei jedem erlaubten Schreibvorgang hängt WriteGuard die Agenten-Attribution an und protokolliert, wer im Namen von wem gehandelt hat. Jeder Aufruf wird als erfolgreich, fehlgeschlagen oder blockiert klassifiziert und als Ereignis weggeschrieben, quer über alle MCP-Server hinweg.

Das ist die Beweiskette. Und es ist die Frage, die dich im Ernstfall wirklich beschäftigt. Nicht «durfte der Agent das», sondern «wer hat es angeordnet, wann, in wessen Namen, und können wir das jemandem zeigen».

Der entscheidende Unterschied ist nicht juristisch, er ist verhaltensökonomisch: Protokollieren erzeugt keinen Umweg. Niemand schleppt einen zweiten Laptop ins Büro, weil sein Name in einem Audit-Log steht. Deshalb ist das die einzige Kontrolle in diesem Produkt, die auch nächstes Jahr noch misst, was wirklich passiert.

Das Wettrüsten hast du verloren, bevor es angefangen hat

Und damit sind wir beim eigentlichen Punkt.

Die Branche verkauft dir gerade immer feinere Blockierwerkzeuge, und jedes einzelne ist besser als sein Vorgänger. Nur ist die Rechnung dahinter absurd. Du rüstest mit Lizenzen, Projektbudget, Betriebsaufwand und einem Team, das Richtlinien pflegt. Dein Mitarbeiter rüstet mit einem alten Laptop und einem Hotspot, den er ohnehin in der Tasche hat.

Du kannst dieses Rennen nicht gewinnen. Nicht weil deine Werkzeuge zu schwach wären, sondern weil du gegen die eigenen Leute antrittst und die immer den billigeren Ausweg haben. Jede Verschärfung bringt dir kurz eine sauberere Statistik und schiebt dauerhaft ein weiteres Stück Arbeit dorthin, wo du nichts mehr siehst.

Das Problem ist nie gewesen, dass zu wenig blockiert wird. Das Problem ist, dass der freigegebene Weg langsamer ist als der Umweg. Solange das so bleibt, ist jede zusätzliche Sperre nur eine weitere Einladung, ihn zu nehmen.

Also dreh die Aufgabe um. Nicht «welche Werkzeuge sperren wir», sondern «welche Aufgabe stirbt mit jeder Sperre, die wir setzen». Halte die Sperrliste gegen die Aufgabenliste, nicht gegen die Risikoliste. Wo dein Agent eine Berechtigung wirklich braucht, gib sie ihm und protokolliere mit, statt ihn auszubremsen.

Deine Logs sind keine Fahndungsliste

Damit hast du plötzlich etwas in der Hand, und jetzt kommt es darauf an, was du damit machst.

Die naheliegende Lesart ist die Fahndungsliste. Wer hat was getan, wo war jemand zu weit, was sperren wir als Nächstes. Diese Lesart ist verlockend, weil sie sofort eine Massnahme produziert. Sie ist auch die teure, weil jede Massnahme daraus die Spirale von oben eine Windung weiterdreht.

Die nützliche Lesart ist die andere. In deinen Logs steht, wie deine Leute tatsächlich arbeiten. Welche Werkzeuge sie in welcher Reihenfolge greifen. Wo sie abbrechen. Welchen Schritt sie zum fünften Mal von Hand machen, weil der Agent ihn nicht darf. Wo der Umweg schneller ist als der vorgesehene Weg, und um wie viel. Das sind Daten, für die andere Unternehmen Nutzerforschung einkaufen. Du hast sie ohnehin liegen, und niemand liest sie so.

Was dabei gut läuft, machst du zum Standard, damit es nicht bei den drei Leuten bleibt, die es sich selbst beigebracht haben. Was schlecht läuft, räumst du weg, statt es zu verbieten. Und wo jemand regelmässig an derselben Stelle ausweicht, hast du keinen Compliance-Fall vor dir, sondern eine Anforderung.

Genau dort entscheidet sich, ob deine Governance trägt. Nicht in der Richtlinie, sondern in der Frage, ob du deine Leute in die Lage versetzt, ihre Arbeit regelkonform und trotzdem effizient zu erledigen. Solange sie sich zwischen beidem entscheiden müssen, verlierst du jedes Mal, und zwar unbeobachtet.

Kontrolle funktioniert nur, wenn der erlaubte Weg auch der schnellste ist. Alles andere ist ein Rüstungswettlauf gegen Leute, die eigentlich für dich arbeiten wollen.

Warum du auf das Schweizer KI-Gesetz nicht warten solltest.

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

«Wir liefern nicht in die EU, uns betrifft das nicht.» Dieser Satz war nie ganz richtig. Seit dem 2. August 2026 kann er teuer werden.

An diesem Datum ist der EU AI Act in seinen allgemeinen Geltungsbeginn getreten (Artikel 113). Gleichzeitig arbeitet der Bund an einer eigenen Vorlage, die viele in der Schweiz für eine Kopie davon halten. Sie wird keine sein. Beides zusammen ergibt eine Lage, die anders aussieht als die Schlagzeilen.

Was die Schweiz wirklich beschlossen hat

Der Bundesrat hat sich am 12. Februar 2025 festgelegt, und der Weg heisst nicht AI Act. Die Schweiz ratifiziert die KI-Konvention des Europarats, unterzeichnet im März 2025. In deren Geltungsbereich fallen, wörtlich aus der Mitteilung des Bundesrats, «in erster Linie staatliche Akteure». Wo Gesetzesanpassungen nötig sind, sollen sie «möglichst sektorbezogen» ausfallen. Eine allgemeine, sektorübergreifende Regulierung beschränkt sich auf zentrale grundrechtsrelevante Bereiche wie den Datenschutz.

Übersetzt: kein Schweizer Pendant zu Risikoklassen, Konformitätsbewertung und CE-Kennzeichnung für KI. Stattdessen Transparenz, Datenschutz, Nichtdiskriminierung und Aufsicht, verteilt auf bestehende Gesetze und ergänzt um Branchenlösungen und Selbstdeklaration.

Der Zeitplan, soweit er belegt ist

Fest steht ein einziges Datum: Das EJPD erstellt mit UVEK und EDA bis Ende 2026 eine Vernehmlassungsvorlage. Parallel erarbeitet das UVEK bis Ende 2026 einen Plan für rechtlich nicht verbindliche Massnahmen.

Alles danach ist Schätzung, und wer Jahreszahlen nennt, sollte den Massstab dazuliefern. Beim Datenschutzgesetz sah der Takt so aus: Botschaft des Bundesrats am 15. September 2017, Beschluss der Bundesversammlung am 25. September 2020, Inkrafttreten am 1. September 2023. Sechs Jahre von der Botschaft bis zur Geltung, und die Vernehmlassung lag noch davor.

Legt man diesen Takt an, ist ein Schweizer KI-Erlass frühestens gegen 2030 in Kraft. Der Beirat Digitale Schweiz hat es am 10. Februar 2026 selbst so gesagt: Rechtsetzungsvorhaben ziehen sich «in der Regel über mehrere Jahre» hin, deshalb brauche es kurzfristig Selbstverpflichtungen, Ethikkodizes und Standards.

Das ist die eigentliche Nachricht: Die verbindliche Schweizer Regel kommt spät. Der Druck kommt früher, und aus einer anderen Richtung.

Warum der AI Act dich heute schon erfasst

Er gilt nicht nur für Anbieter in der EU, sondern auch für Anbieter und Betreiber aus Drittstaaten, «wenn die vom KI-System hervorgebrachte Ausgabe in der Union verwendet wird» (Artikel 2 Absatz 1 c).

Das ist ein weit grösserer Auslöser als Export. Du musst nichts verschiffen, es reicht das Ergebnis: dein Screening-Tool bewertet Bewerber in München, deine Tochter in Wien arbeitet mit dem Score aus deinem Modell, dein Chatbot beantwortet Anfragen aus dem EU-Raum. Dazu kommt der Weg über die Lieferkette. Deine EU-Kunden müssen selbst konform sein und geben die Anforderungen im Einkauf weiter, ganz unabhängig davon, was in Bern gerade beraten wird. Genau so kam die DSGVO in Schweizer Firmen an, Jahre vor dem revidierten DSG.

Die Pflichten, die zählen

Verbotene Praktiken (Artikel 5), seit 2. Februar 2025. Kein Übergang, keine KMU-Ausnahme. Dazu gehört das Ableiten von Emotionen am Arbeitsplatz und in Bildungseinrichtungen, ausser aus medizinischen oder Sicherheitsgründen. Wer Sentiment-Analyse über Mitarbeitergespräche laufen lässt, ist mitten im Verbotstatbestand.
KI-Kompetenz (Artikel 4), seit 2. Februar 2025. Anbieter und Betreiber müssen Massnahmen ergreifen, damit die Leute, die mit KI arbeiten, sie auch verstehen. Der Digital Omnibus hat diese Pflicht im Juli 2026 abgeschwächt: geschuldet ist jetzt die Förderung der Kompetenz, ausdrücklich nicht mehr die Garantie eines bestimmten Niveaus. Eigene Bussdrohung hatte Artikel 4 nie. Wer ihn deshalb ignoriert, hat ihn falsch verstanden: Er ist der Massstab, an dem später die Sorgfalt gemessen wird.
Transparenz (Artikel 50), seit 2. August 2026. Die praktisch wichtigste Neuerung. Ein System, das direkt mit Menschen interagiert, muss offenlegen, dass es eine Maschine ist. Synthetische Audio-, Bild-, Video- und Textinhalte müssen maschinenlesbar als künstlich erzeugt gekennzeichnet sein. Deepfakes müssen als solche offengelegt werden. Für Systeme, die vor dem 2. August 2026 auf dem Markt waren, läuft die Frist zur Kennzeichnung bis zum 2. Dezember 2026 (Artikel 111 Absatz 4).
Hochrisiko-Anwendungen, verschoben. Der Digital Omnibus hat die Pflichten für Systeme nach Anhang III auf den 2. Dezember 2027 und für KI in regulierten Produkten nach Anhang I auf den 2. August 2028 verlegt. Anhang III trifft nicht nur Exoten: Bewerbersichtung, Entscheide über Beförderung und Kündigung, Aufgabenzuteilung und Leistungsüberwachung stehen dort ausdrücklich (Anhang III Ziffer 4), ebenso Kreditwürdigkeitsprüfung und Risikobewertung bei Lebens- und Krankenversicherungen.
Betreiberpflichten (Artikel 26). Wer ein solches System nur einsetzt, statt es zu bauen, ist nicht aus dem Schneider. Die menschliche Aufsicht muss an Personen mit Kompetenz und Befugnis übertragen werden, die Protokolle sind mindestens sechs Monate aufzubewahren, und vor dem Einsatz am Arbeitsplatz sind Arbeitnehmervertretung und Betroffene zu informieren.

Der Swiss Finish wird nicht milder, nur anders

Die Erwartung, Bern werde das schon abfedern, stützt sich auf die Bussen. Der Vergleich lohnt sich, führt aber woandershin, als die meisten denken.

Der AI Act droht bis zu 35 Millionen Euro oder 7 Prozent des weltweiten Jahresumsatzes bei verbotenen Praktiken, bis zu 15 Millionen oder 3 Prozent unter anderem bei Verstössen gegen die Betreiber- und die Transparenzpflichten (Artikel 99). Das Schweizer Datenschutzgesetz kennt maximal 250'000 Franken (Artikel 60 bis 63 DSG). Zehnerpotenzen Unterschied.

Nur trifft die Schweizer Busse nicht die Firma, sondern die verantwortliche natürliche Person. Erst unterhalb von 50'000 Franken kann die Behörde stattdessen den Geschäftsbetrieb verurteilen, und auch nur, wenn die Ermittlung der schuldigen Person unverhältnismässig wäre (Artikel 64 DSG). In Brüssel zahlt die Bilanz, in Bern der Mensch mit dem Namen auf dem Organigramm. Wenn der Gesetzgeber dieses Muster auf KI überträgt, und dafür spricht einiges, ist der Swiss Finish für Geschäftsleitungen kein Rabatt.

Was du bis dahin tun kannst

Drei Dinge, die unabhängig vom Ausgang der Vernehmlassung richtig sind. Erstens ein Inventar: Welche KI-Systeme laufen bei dir, wer ist Anbieter, wer Betreiber, wo landet die Ausgabe. Zweitens die Einordnung der Anwendungsfälle, nicht der Werkzeuge. Nicht der Chatbot ist hochriskant, sondern die Frage, worüber er entscheidet. Drittens die Transparenz: Kennzeichnung und Offenlegung sind heute fällig und in Wochen umsetzbar, nicht in Quartalen.

Euer Unternehmenswissen liegt in Mailboxen von Leuten, die längst gekündigt haben

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Die Zahl, mit der Wissensmanagement verkauft wird, gibt es nicht.

Du kennst sie: Das Menschheitswissen verdoppelt sich alle zwölf Stunden. Die Behauptung wird auf einen IBM Report zurückgeführt. Diesen Report hat nie jemand vorgelegt. Die Spur endet in einem Blogartikel von 2013, der auf «ein IBM Papier» verweist, ohne Titel, ohne Datum, ohne Link. Buckminster Fuller wird als Urheber der Kurve genannt, die zwölf Stunden hat er nie gesagt.

Was sich tatsächlich messen lässt, ist die Menge wissenschaftlicher Publikationen. Bornmann, Haunschild und Mutz haben 2021 vier Literaturdatenbanken über den Zeitraum ab 1675 ausgewertet. Ergebnis: 4.10 Prozent Wachstum pro Jahr, eine Verdopplung alle 17.3 Jahre. Seit 1952 sind es 5.08 Prozent, eine Verdopplung alle 14 Jahre. In der Phase vor der Industrialisierung dauerte dieselbe Verdopplung 24.5 Jahre.

Das klingt zahmer als zwölf Stunden. Ist es nicht. Rechne es auf ein Berufsleben um: 40 Jahre bei 5.08 Prozent sind Faktor sieben. Wer heute in Pension geht, hat miterlebt, wie sich der Bestand an wissenschaftlicher Literatur mehr als versiebenfacht hat. Deine Aufnahmefähigkeit ist im selben Zeitraum exakt gleich geblieben.

Und das ist nur der Teil, der gezählt wird. Publikationen sind nicht Wissen, sie sind das, was jemand indexiert hat. Alles, was dein Unternehmen weiss, taucht in keiner dieser Datenbanken auf.

Das Problem ist nicht die Menge. Es ist der Ort.

Wissen liegt bei euch quer verstreut. In KI-Chats, in Slack, in Teams, in Confluence, in Jira, in zwei weiteren Wikis, in Dokumenten auf dem Shared Drive, in SharePoint, in PowerPoints, die jemand vor drei Jahren für ein Steering gebaut hat.

Jede dieser Ablagen enthält eine Sicht auf die Wahrheit. Einen Teilausschnitt, aus der Perspektive des Autors, zum Zeitpunkt des Schreibens. Nicht falsch, aber auch nicht vollständig, und für die meisten Kolleginnen und Kollegen schlicht nicht auffindbar.

Nimm Meeting Minutes. Meine Erfahrung nach vielen Jahren in Projekten: Minutes entstehen bei etwa jedem dritten Meeting, und wenn sie entstehen, gehen sie exakt an den Teilnehmerkreis. Kündigt morgen jemand und fängt übermorgen jemand Neues an, ist diese Information weg. Sie liegt in einer Mailbox, die niemand mehr durchsucht, oder in einer, die deaktiviert wurde.

Minutes sind nur so lange wertvoll, wie jemand, der dabei war, sie wieder hervorkramt und sich darauf berufen kann. Ist diese Person nicht mehr im Unternehmen, verliert die Information ihre Bedeutung. Das Wissen ist nicht gelöscht. Es ist unerreichbar, und das ist praktisch dasselbe.

Slack ist dasselbe Muster in schneller. Hast du schon einmal einen Slack-Channel zwei Jahre zurückgespult? Eben. Alles, was über «machst du das oder soll ich» hinausgeht, also Implementierungsdetails, Investitionsabsprachen, die Begründung, warum ihr euch gegen die andere Variante entschieden habt, ist damit verloren.

Jetzt kommt der übliche Einwand: Diese Informationen verlieren doch mit der Zeit an Wert. Stimmt, die Information selbst schon. Die Herleitung nicht. Entscheidungen bauen auf Entscheidungen auf. Wenn niemand mehr rekonstruieren kann, warum etwas so ist, bekommst du auf jede Warum-Frage dieselbe Antwort: Ist so, weil ist so.

Das ist der Moment, in dem ein Unternehmen anfängt, seine eigenen Altlasten für Naturgesetze zu halten.

«Wir haben ein Wiki. Da schaut nur keiner rein.»

Diesen Einwand höre ich zu Recht. Wikis sind der klassische Ort, an dem Wissen stirbt: 400 Seiten, die Hälfte veraltet, die Suche findet nichts, also fragt man wieder den Kollegen. Ein weiteres Tool löst das nicht.

Drei Dinge sind heute anders.

Erstens die Indexierung. Berechtigungen sind nicht das Unterscheidungsmerkmal, die hat jedes Fileshare. Auf dem S-Drive kannst du sauber steuern, wer welchen Ordner sieht. Nur ist der Inhalt dort nicht indexiert. Du suchst nicht nach einer Aussage, sondern nach einem Dateinamen, und im besten Fall öffnest du danach zwanzig Dokumente, um die eine Zeile zu finden, die du brauchst. Was in der Geschäftsleitungssitzung besprochen wird, darf nicht jeder lesen, verloren gehen soll es trotzdem nicht, und für die Berechtigten muss es auffindbar sein. Erst diese Kombination aus Zugriffssteuerung und indexiertem Inhalt ist der Unterschied. Confluence bildet sie über Spaces und Seitenbeschränkungen ab.

Zweitens die Suche. Der Grund, warum niemand ins Wiki schaut, war nie die Ablage, sondern das Wiederfinden. Eine KI, die in natürlicher Sprache antwortet und dabei nur Inhalte verwendet, auf die du ohnehin Zugriff hast, dreht das um. Bei Atlassian heisst das Rovo, und die Berechtigungstreue ist dokumentiert. Das ist eine Herstelleraussage, also prüf sie in deinem eigenen Tenant, bevor du dich darauf verlässt. Prüf sie unbedingt, denn hier liegt das eine echte Risiko: Wenn die Suche still schweigt statt «dazu gibt es etwas, du darfst es nicht sehen» zu sagen, glaubt der Neue, es gäbe nichts.

Drittens, und das ist der eigentliche Punkt: Das Befüllen war früher Handarbeit. Deshalb ist es nie passiert.

Warum das jetzt geht

Der übliche Reflex lautet: Das initial aufzusetzen ist wahnsinnig viel Arbeit.

Sieht so aus. Ist es aber nicht mehr, denn die Arbeit besteht aus genau dem, was Sprachmodelle können: grosse Mengen bestehender Texte durchgehen, pro Thema konsolidieren und sauber aufbereitet aufschreiben. Die alten Informationssenken durchsuchen, Dubletten zusammenführen, aus fünf Fassungen einer Absprache eine Seite machen.

Zwei Stellen bleiben beim Menschen, und beide sind nicht verhandelbar.

Widersprüche löst der Mensch auf. Wenn drei Quellen drei verschiedene Dinge sagen, entscheidet nicht das Modell, welche gilt. Das Modell legt den Widerspruch offen, jemand mit Verantwortung entscheidet.

Jede Aussage behält ihre Herkunft. Konsolidierung ohne Quellverweis ist kein Wissen, sondern ein selbstbewusst formulierter Text. Wenn die Seite später bestritten wird, musst du zur ursprünglichen Mail, zum ursprünglichen Thread zurückkommen können.

Pro Abteilung ein Space, darunter eine Struktur, darin Seiten mit Querverweisen und einer Eigentümerin oder einem Eigentümer pro Seite. Erst wenn ein Thema drin ist, wird die alte Quelle abgeschaltet. Und bevor du irgendetwas löschst: Aufbewahrungspflichten prüfen. Konsolidieren heisst nicht entsorgen.

Sonst ist es eine Einmalaktion

Ein konsolidierter Space verfällt, wenn er nicht weitergeführt wird. Nach zwölf Monaten ist er wieder das tote Wiki, gegen das du angetreten bist. Deshalb ist der Aufräumteil der kleinere Teil des Projekts.

Der grössere Teil sind die Prozesse drumherum. Das Meeting wird künftig direkt in Confluence abgelegt, von der KI, in der richtigen Struktur, mit den richtigen Berechtigungen. Damit stellt sich die Frage nicht mehr, wer die Minutes schreibt und ob es überhaupt welche gibt. Der Entscheid ist dort, wo er hingehört, samt Herleitung.

Und der neue Mitarbeiter arbeitet in der ersten Woche den Space seiner Abteilung durch, statt in vier Wochen dieselben zwölf Fragen an dieselben drei Leute zu stellen.

Zum ROI

Ich könnte dir jetzt schreiben, dass sich das in unter einem Jahr rechnet. Das behaupten alle, und niemand legt die Rechnung offen. Also mach sie selbst, sie ist simpel: Die Investition ist einmalig und in Personentagen messbar. Der Nutzen ist wiederkehrend und liegt in Suchzeit, in Einarbeitungszeit und in Entscheidungen, die nicht ein zweites Mal getroffen werden müssen.

Wenn du diese drei Grössen in deinem Unternehmen nicht beziffern kannst, hast du kein ROI-Problem, sondern ein Messproblem. Dann fang damit an.

Das ist der erste KI-Anwendungsfall, der wirklich etwas verändert, und er geht deutlich über «wir machen jetzt mal was mit KI» hinaus. Er ist nachhaltig, er ist messbar, und er wäre von Hand praktisch unmöglich gewesen. Deshalb hat ihn bisher niemand gemacht.

Warum MCP, wenn der Agent doch unsere API aufrufen kann?

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Diese Frage kommt in jedem zweiten Gespräch, und sie kommt von den Leuten, die ihr Produkt am besten kennen. Meistens vom CTO. Sie ist berechtigt, und die ehrliche Antwort fängt mit einem Zugeständnis an.

Zuerst das Zugeständnis

Es gibt nichts, was MCP technisch kann und eine gut gebaute API nicht. Kein Merkmal, keine Fähigkeit, keinen Trick. Alles, was das Protokoll macht, kannst du selbst bauen, mit HTTP, JSON und OAuth. Wer dir etwas anderes erzählt, verkauft dir gerade etwas.

Der Unterschied liegt nicht darin, was möglich ist. Er liegt darin, wer was wissen muss, damit es funktioniert.

Vier Stellen, an denen sich das zeigt.

1. Der Schlüssel und der Ausweis

Ein API Key ist ein Schlüssel. Er gehört einem System, nicht einer Person. Er passt, bis ihn jemand sperrt, und er weiss nicht, wer ihn gerade in der Hand hält. Was der Schlüssel darf, darf jeder, der ihn hat.

OAuth ist ein Ausweis. Ausgestellt auf einen Menschen, mit Ablaufdatum, mit begrenztem Umfang, jederzeit einziehbar. Dein System sieht, wer handelt.

Und jetzt das Zugeständnis: Deine API kann OAuth genauso. Viele APIs machen das seit Jahren.

Was MCP hinzufügt, ist nicht der Ausweis, sondern der Weg dorthin. Ein fremder Client klopft ohne Token an deinen Server. Er bekommt eine Abfuhr, in der steht, wo das Ausweisbüro ist und welche Berechtigung er für diese eine Aufgabe braucht. Danach geht er selbst hin. Niemand verschickt einen Key per Mail, niemand trägt irgendwo Zugangsdaten ein, und niemand aus deinem Support erklärt einem Kunden, wo er sein Token findet.

Dazu kommt etwas, das im Alltag mehr wert ist, als es klingt: Berechtigungen lassen sich mitten in der Arbeit nachziehen. Der Agent darf lesen. Sobald er etwas schreiben will, sagt dein Server, welche Berechtigung dafür fehlt, und der Mensch erteilt genau diese. Nicht alles am Anfang, auf Verdacht.

Der Vollständigkeit halber: MCP zwingt dich zu nichts davon. Die Spezifikation nennt Autorisierung ausdrücklich optional, und ein lokal laufender Server darf seine Zugangsdaten weiterhin aus der Umgebung lesen. Standardisiert ist der Weg, nicht die Pflicht.

2. Breit gebaut oder zugeschnitten

Deine API ist bewusst breit, und das ist ihre Stärke, nicht ihr Mangel. Sie ist für Entwickler gebaut, die damit Dinge lösen sollen, an die beim Entwurf niemand gedacht hat. Vollständigkeit ist das Merkmal. Wer eine API auf neun Endpunkte zusammenstreicht, hat keine gute API gebaut, sondern eine schlechte.

Die Agentenschnittstelle hat die umgekehrte Anforderung, aus einem sehr konkreten Grund: Die Liste der verfügbaren Aufgaben liegt dem Modell vor, bevor irgendjemand weiss, worum es überhaupt geht. Sie wird bei jeder einzelnen Anfrage mitgelesen. Eine Schnittstellenbeschreibung dagegen wird nachgeschlagen, wenn die Frage bereits existiert.

Deshalb kostet Breite in den beiden Welten etwas völlig Verschiedenes. In der API kostet sie im Ruhezustand nichts. In der Aufgabenliste kostet sie bei jedem Aufruf, und sie kostet Orientierung genau in dem Moment, in dem entschieden wird.

Das ist ausdrücklich kein Argument über die Grenzen des Modells. Ich lasse täglich ein Modell eine öffentliche API bedienen, mit nichts als der Schnittstellenbeschreibung und einem Zugang, und es arbeitet sich sauber durch. Der Unterschied liegt nicht im Können. Er liegt darin, was im Augenblick der Entscheidung vor dem Modell liegt.

Also wird anders geschnitten. Nicht «Objekt anlegen, Feld setzen, Feld setzen, Status ändern, veröffentlichen», sondern «Befragung starten». So konkret wie möglich, entlang der Aufgaben, die deine Kunden wirklich haben. Neun davon statt zweihundert Operationen.

Dazu kommt ein Nebeneffekt, der im Verkauf schwerer wiegt als die Orientierung. Beim Schnitt nach Aufgaben liegt die Reihenfolge in deinem Code. Bei zweihundert generischen Endpunkten setzt der Agent sie selbst zusammen, jeder Kunde ein wenig anders, und die Regeln, die zwischen den Aufrufen gelten und nirgends geschrieben stehen, kennt er nicht. Das Ergebnis kann technisch einwandfrei und fachlich falsch sein. Der Kunde sieht dann nicht seinen Agenten, sondern dein Produkt.

Und wieder das Zugeständnis: Deine API kann diesen Schnitt auch. Ein Endpunkt namens «Befragung starten» ist kein Protokollmerkmal, sondern eine Entwurfsentscheidung.

Nur muss sie es nicht. Breit funktioniert für sie, denn davor sitzt ein Entwickler, der die Dokumentation liest und fünf Schritte hintereinander macht. Die Agentenschnittstelle funktioniert breit nicht. MCP macht den Schnitt nicht möglich. Es macht ihn nötig.

Was du dabei in Kauf nimmst: Du pflegst ab jetzt zwei Oberflächen auf demselben Kern. Die breite für Entwickler, die schmale für Agenten. Kein Umbau deiner API, sondern eine zweite Sicht darauf, aber es ist Arbeit, die vorher nicht da war.

Und die eigentliche Frage steckt genau dort. Welche neun Aufgaben es sind, ist keine Protokollfrage, sondern eine Produktfrage. Sie ist der teure Teil.

3. Die dritte Partei

Hier trennen sich die beiden Welten wirklich.

Ein API Aufruf kennt zwei Beteiligte: das aufrufende Programm und deinen Server. Der Mensch kommt im Vertrag nicht vor. HTTP hat keinen Begriff dafür, dass hinter dem Aufrufer jemand sitzt. Dein Server kann dem Programm antworten, mehr nicht: ja, nein, Fehler.

Der MCP Vertrag kennt drei Beteiligte. Der dritte ist der Mensch.

In der aktuellen Fassung vom 28. Juli 2026 läuft das so: Dein Server kann eine Aufgabe nicht zu Ende bringen, ohne etwas zu wissen, das nur ein Mensch entscheiden kann. Also liefert er statt eines Ergebnisses eine Zwischenantwort, mit der Frage und mit einem Formular, das er für genau diesen Fall erzeugt hat. Der Client zeigt es der Person. Die Person antwortet. Der Client ruft dieselbe Aufgabe noch einmal auf, diesmal mit der Antwort im Gepäck.

Damit dich niemand damit erwischt: Das ist kein offener Draht. Es ist ein zweiter Anruf. Seit dieser Fassung hat MCP überhaupt keine Sitzungen mehr, jede Anfrage steht für sich allein. Für den Menschen davor fühlt es sich trotzdem wie ein Gespräch an, und darauf kommt es an.

Zwei Dinge sind darin festgelegt, die eine API so nicht kennt.

Erstens entsteht die Frage zur Laufzeit, aus den Daten. Sie ist keine Auswahl aus einer Liste, die jemand vor zwei Jahren beim Entwurf vorgesehen hat.

Zweitens gibt es einen Modus, in dem dein Server die Person auf eine eigene Seite schickt, und weder der Client noch das Modell sehen, was dort passiert. Für Zugangsdaten schreibt die Spezifikation das sogar vor: Passwörter, Schlüssel und Zahlungsdaten dürfen nie im Formular abgefragt werden. So bekommst du sensible Dinge am Modell vorbei, vertraglich zugesichert statt selbst gebastelt.

Und der Mensch hat drei Antworten statt zwei: ja, nein, und «ich entscheide das jetzt nicht». Ein REST Aufruf hat keine Vokabel dafür, dass jemand den Dialog weggeklickt hat.

4. Der Fall, an dem eine API nicht mehr reicht

Ein konstruiertes Beispiel, aber eines aus meiner Welt.

Jemand sagt seinem Assistenten: «Schick die Zufriedenheitsbefragung an alle Kunden, die im letzten Quartal einen Supportfall hatten.»

Der Aufruf ist vollständig. Kein Pflichtfeld fehlt, nichts ist mehrdeutig, jede API würde jetzt senden.

Dann fällt deinem Produkt etwas auf, das der Aufrufer nicht wissen konnte: Ein Teil dieser Gruppe hat einen Fall, der eskaliert und noch offen ist.

Das ist kein technisches Problem, sondern eine Abwägung.

Schickst du an alle, misst du die Verstimmung der offenen Fälle mit und verzerrst genau die Kennzahl, um die es ging. Nimmst du sie heraus, fehlt dir das Segment, dessen Meinung am meisten zählt. Oder du schickst ihnen später eine andere, kürzere Fassung, sobald der Fall geschlossen ist.

Niemand hat «hat offene Eskalation» als Parameter von «Befragung senden» vorgesehen. Niemand konnte das, denn der Konflikt entsteht erst aus den Daten von heute.

Der Einwand, der jetzt kommt: Der Agent könnte doch vorher nachsehen. Nein. Dafür müsste er wissen, dass offene Eskalationen einen Zufriedenheitswert verzerren. Dieses Wissen steckt in deinem Produkt, nicht im Modell.

Darum geht es: Das Fachwissen sitzt in deinem System, das Gespräch sitzt in einem fremden Client. Bis hierhin gab es keinen festgelegten Weg, das eine ins andere zu bringen.

Und ja, deine API kann auch einen Fehlercode mit drei Optionen zurückgeben. Danach erklärst du ChatGPT, Copilot, Claude und dem selbstgebauten Agenten deines grössten Kunden, was dieser Fehlercode bedeutet. Einmal pro Client. Für immer.

Die Konvention, und was sie kostet

Der eigentliche Grund für MCP ist kein technischer.

Im Dezember 2025 wurde das Protokoll an die Agentic AI Foundation übergeben, einen Fonds unter der Linux Foundation. Mitgegründet von Anthropic, Block und OpenAI, unterstützt von Google, Microsoft, AWS, Cloudflare und Bloomberg. Direkte Unterstützung gibt es unter anderem in ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot und Visual Studio Code.

Die Branche hat sich geeinigt. Nicht auf den besten Entwurf, sondern auf einen. Mehr ist eine Konvention nie, und weniger auch nicht.

Was sie dir bringt: Dein Kunde verbindet dein Produkt mit seinem Assistenten, ohne dass du für diesen Assistenten irgendetwas gebaut hättest. Das ist der ganze Nutzen, und er ist gross.

Was sie kostet, ebenso ehrlich:

Sie bewegt sich. Zwischen Juni 2025 und Juli 2026 kamen zwei neue Fassungen, beide mit Brüchen. Der Handshake ist weg, die Sitzungen sind weg, drei Funktionen aus dem Kern sind abgekündigt. Meistens nimmt dir das dein SDK als Abhängigkeitsupdate ab. Teuer wird es dort, wo du um die entfernten Teile herum etwas Eigenes gebaut hast. Und der Takt kommt von aussen, nicht aus deiner Roadmap.
Sie ist kein Burggraben. Was du damit begründest, dass es alle so machen, hat genau die Lebensdauer dieser Aussage.
Die dünne Hülle bringt nichts. Eine MCP Schicht, die deine öffentliche API nur weiterreicht, fügt nichts hinzu ausser einem zweiten Endpunkt, den du pflegen musst. Der Wert liegt dort, wo die Berechtigungen und die internen Methoden liegen, also mitten in deinem Produkt.
Es entsteht eine neue Fläche. Die Beschreibungen deiner Werkzeuge sind Text, den ein Modell liest und ernst nimmt. Wer dort schreibt, schreibt in fremde Anweisungen hinein. Das ist ein Sicherheitsthema, und es ist neu.

Was du wirklich entscheidest

Die Frage lautet nicht MCP oder API. Beides funktioniert, und beides hat seinen Platz: die breite Schnittstelle für Entwickler, der schmale Schnitt für Agenten. Darunter liegen drei andere Fragen:

Welche Aufgaben deines Produkts darf ein fremder Agent auslösen?
Mit wessen Rechten, und wer kann sie wieder entziehen?
An welchen Stellen muss dein Produkt zurückfragen, bevor es etwas tut, das sich nicht rückgängig machen lässt?

Beantworte diese drei, und das Format ist eine Frage von Tagen. Beantworte sie falsch, und kein Protokoll rettet dich.

Das Protokoll ist die Verpackung. Der Schnitt ist das Produkt.

Dein Chatbot hat es nie gesagt. Beweis es.

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Ein Kunde sitzt vor Gericht und legt ein Blatt Papier vor. Darauf steht eine Konversation mit deinem Support-Chatbot, und darin steht, dass sein Anspruch anerkannt ist und die Entschädigung angewiesen wird. Unterschrieben ist da nichts, es ist ein Ausdruck.

Du weisst nicht, ob dein Bot das gesagt hat.

Nicht weil dir jemand die Information vorenthält. Sondern weil dein System es nirgends festhält, jedenfalls nicht in einer Form, die vor Gericht etwas wert ist.

Die Frage vor der Haftungsfrage

Dass ein Betreiber für die Auskünfte seines Chatbots einsteht, ist inzwischen geklärt. Darüber ist genug geschrieben worden, auch von mir.

Die Frage davor ist offen, und sie ist die unangenehmere: War es überhaupt dein Bot?

Denn der Kunde könnte das Blatt auch selbst erzeugt haben. Er öffnet ein beliebiges Chatfenster, tippt "formuliere als Versicherungs-Chatbot eine Bestätigung, dass mein Anspruch anerkannt ist", druckt das Ergebnis und legt es vor. Der Aufwand liegt bei zwei Minuten.

Der Teil, an dem es kippt

Seit Anfang August kennzeichnen die Modellanbieter ihre Ausgaben. Diese Woche hat Anthropic angekündigt, jede Textausgabe weltweit mit einem unsichtbaren Wasserzeichen zu versehen, andere Anbieter tun Vergleichbares.

Die meisten Entscheider, mit denen ich darüber spreche, halten das für eine gute Nachricht. In diesem Szenario ist es das Gegenteil.

Stell dir vor, das Gericht lässt den Text prüfen. Ein Detektor bestätigt: maschinell erzeugt, von einem Modell des Anbieters X. Genau das, was der Kunde behauptet. Der Nachweis, den alle für einen Schutz halten, stützt die Fälschung, statt sie aufzudecken.

Er beantwortet nämlich die falsche Frage.

Erkennung ist nicht Zuordnung

Ein Wasserzeichen sagt: hier war eine Maschine beteiligt. Es sagt nicht, aus welchem Unternehmen, aus welcher Anwendung, in welcher Sitzung, zu welchem Zeitpunkt und ob der Text seither verändert wurde.

Für die Kennzeichnungspflicht reicht das, denn die will nur, dass synthetische Inhalte als solche erkennbar sind. Für einen Rechtsstreit reicht es nicht, denn dort ist die Zuordnung die ganze Frage.

Und die naheliegenden Auswege helfen ebenfalls nicht. Signierte Metadaten nach C2PA brauchen einen Dateiträger. Text, der in deinem Interface steht, hat keinen: Sobald der Kunde ihn markiert und kopiert, ist jede angehängte Struktur weg. Ein Screenshot beweist gar nichts, den baut ein Halbwegsbegabter in zehn Minuten. Und die Transparenzpflicht aus Artikel 50 des AI Act, über die alle gerade reden, adressiert eine völlig andere Sorge.

Alle diese Verfahren beschreiben die Ausgabe. Keines verbindet sie mit dir.

Die Verbindung musst du selbst herstellen

Und zwar nicht an der Ausgabe, sondern in deinem eigenen System. Fünf Bausteine, alle ohne Mitwirkung eines Modellanbieters umsetzbar.

Protokolliere serverseitig, nicht nur die Antwort. Jede ausgelieferte Bot-Ausgabe mit Zeitstempel, Sitzung, Nutzerbezug, vollständigem Verlauf, Modellversion, Version des Systemprompts und der genutzten Wissensbasis. Der Kontext ist wichtiger als der einzelne Satz, weil vor Gericht immer die Frage kommt, worauf der Bot geantwortet hat.

Verkette die Einträge. Jeder Eintrag wird gehasht und bindet den Hash des vorhergehenden ein. Wer nachträglich einen einzelnen Eintrag ändert oder entfernt, bricht die Kette sichtbar. Ohne diesen Schritt ist dein Protokoll eine Datenbank, in der du selbst Schreibrechte hast, und genau das wird dir die Gegenseite vorhalten.

Verankere die Kette ausserhalb deines Hauses. Die Kettenwurzel bekommt in festen Abständen einen qualifizierten Zeitstempel nach eIDAS. Damit ist belegt, dass dein Protokoll zu einem Zeitpunkt existierte, der vor dem Streit liegt. Ohne externe Verankerung bleibt die schönste Hash-Kette ein Selbstzeugnis.

Gib jeder Antwort eine sichtbare Kennung. Eine kurze Referenz unter jeder Bot-Ausgabe, die der Nutzer sieht und mitkopiert. Wer sich später auf eine Aussage beruft, kann sie benennen. Ein vorgelegtes Papier ohne gültige Kennung ist ab diesem Moment erklärungsbedürftig, und zwar auf der Gegenseite.

Signiere, was als Datei rausgeht. Wo dein Produkt eine Zusammenfassung, ein PDF oder eine Bestätigungsmail erzeugt, hängst du ein signiertes Manifest an. Dann existiert eine authentische Fassung, an der sich jede andere messen lassen muss.

Das Ziel ist der Negativbeweis

Du wirst nie in der Lage sein, fremde Papiere auf Echtheit zu prüfen. Das ist auch nicht deine Aufgabe.

Deine Aufgabe ist die umgekehrte: zeigen zu können, dass diese Aussage in deinem lückenlosen, extern verankerten Protokoll nicht vorkommt. Das ist ein Argument. "Wir glauben nicht, dass unser Bot so etwas sagen würde" ist keines.

Und es wirkt in beide Richtungen. Hat dein Bot es tatsächlich gesagt, weisst du das, bevor du in ein Verfahren gehst, und kannst dich vergleichen, statt es herauszufinden, während der Richter zuhört.

Der Punkt, den ich für den entscheidenden halte: Wer als Einziger hätte dokumentieren können und es nicht getan hat, muss damit rechnen, dass ihm diese Lücke angerechnet wird. Das ist meine Laienlesart und kein Rechtsrat, aber die Richtung ist in jeder Verfahrensordnung dieselbe. Fehlende Protokolle sind kein neutraler Zustand.

Der Zielkonflikt, den du einplanen musst

Was ich hier beschreibe, ist eine Datenbank voller Kundengespräche mit langer Aufbewahrung. Das kollidiert mit Speicherbegrenzung, Zweckbindung und Löschansprüchen, und wer das erst nach dem Bau bemerkt, baut zweimal.

Es gibt einen eleganten Ausweg, und er hat einen Preis. Du kannst den Klartext löschen und nur den Hash je Ausgabe behalten. Legt jemand später ein Papier vor, hashst du dessen Inhalt und schaust nach, ob er in deiner Kette steht. Damit bewahrst du keine personenbezogenen Inhalte auf und kannst trotzdem prüfen.

Der Preis ist Sprödigkeit. Ein Hash trifft nur bei zeichengenauer Übereinstimmung. Eine andere Zeilenumbrechung, ein eingefügtes Leerzeichen, eine kopierte Passage statt der ganzen Antwort, und du bekommst keinen Treffer, obwohl der Text von dir stammte. Ein Falsch-Negativ in einem Verfahren ist teurer als ein Datenschutzkonzept.

Der praktikable Mittelweg ist eine Aufbewahrung, die sich an der Verjährungsfrist der Ansprüche orientiert, ein vom Betrieb getrenntes Beweisprotokoll mit eigenem Zweck und engem Zugriff, und eine Normalisierung des Textes vor dem Hashen. Das ist Architekturarbeit, keine Konfiguration.

Was du in den nächsten zwei Wochen klären kannst

Ob dein Bot heute überhaupt speichert, was er ausgeliefert hat, und nicht nur, was der Nutzer eingegeben hat. Das ist erstaunlich oft nicht der Fall.

Ob jemand mit Datenbankzugriff diese Einträge unbemerkt ändern könnte. Wenn ja, ist dein Protokoll vor Gericht wenig wert.

Wie lange ihr aufbewahrt, und ob diese Frist zu den Verjährungsfristen der Ansprüche passt, um die es gehen könnte. Meistens ist sie erheblich kürzer, weil sie aus dem Betrieb kommt und nicht aus der Rechtsabteilung.

Und die unangenehmste: Was ihr tun würdet, wenn morgen jemand mit so einem Ausdruck vor der Tür steht.

Jede Firma, die einen Chatbot betreibt, hat sich gefragt, wofür sie haftet. Fast keine hat sich gefragt, was sie beweisen kann.

Dein KI-Pentest hat keinen Massstab. Seit sieben Wochen gäbe es einen.

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Der Bericht liegt vor. Zwei Wochen Testing, ein sauberes Dokument, die Findings sind eingeplant, das Häkchen für den Verwaltungsrat ist gesetzt. Dein Jahres-Pentest hat funktioniert, so wie er seit Jahren funktioniert.

Und jetzt eine unangenehme Frage: Gegen welchen Massstab wurde eigentlich der KI-Teil geprüft?

Nicht ob er geprüft wurde. Gegen was.

Warum der klassische Pentest so gut funktioniert

Der Grund ist nicht, dass Pentester besonders clever sind. Der Grund ist, dass es einen geteilten Massstab gibt, auf den sich Käufer und Anbieter einigen, bevor jemand eine Zeile Code anfasst.

OWASP ASVS, seit Version 5.0 vom Mai 2025 mit rund 350 Anforderungen in siebzehn Kapiteln und drei Verifikationsleveln. Steht Level 2 im Vertrag, wissen beide Seiten, was Bestehen bedeutet, was im Scope ist und was der Bericht am Ende belegen muss. Der Standard macht die Leistung vergleichbar, und Vergleichbarkeit ist der Grund, warum aus dem Pentest eine Commodity werden konnte.

Genau dieser Massstab fehlt beim KI-Teil. Nicht das Testen fehlt. Der Massstab.

Die Lücke ist vermessen, und sie sieht anders aus, als du denkst

Pentera hat im Dezember 2025 dreihundert CISOs und Security-VPs aus Unternehmen ab dreitausend Mitarbeitenden befragt. Die Zahlen widerlegen die bequeme Annahme, KI-Sicherheit sei ein Awareness-Problem.

52 Prozent haben KI-Szenarien bereits im adversarialen Testumfang. Es wird also längst getestet. Nur:

30 Prozent sagen ausdrücklich, die Testmethodik für KI-Sicherheit sei unklar. Elf Prozent haben Werkzeuge, die für KI gebaut wurden. Drei Viertel schützen ihre KI-Systeme mit Endpoint-, Cloud- und API-Tools, die für etwas anderes entworfen wurden.

Und der Wert, der die Lage am ehrlichsten beschreibt: Kein einziger der dreihundert Befragten meldet vollständige Sichtbarkeit über die eigenen KI-Systeme. Null. Zwei Drittel haben begrenzte Sicht, das restliche Drittel hat gute Sicht und rechnet trotzdem mit Schatten-KI im Haus.

Als grösste Hürde nennt die Hälfte der Befragten fehlende interne Expertise. Budget nennen siebzehn Prozent. Das Geld ist da. Der Massstab ist es nicht, und die Leute, die ihn anlegen könnten, auch nicht.

Was sich am 24. Juni geändert hat

An diesem Tag ist OWASP AISVS 1.0 erschienen, der Artificial Intelligence Security Verification Standard. Aufgebaut wie ASVS, mit denselben drei Verifikationsleveln, in zwölf Kapiteln.

Die Kapitelliste allein sagt einem Entscheider mehr als jede Bedrohungsanalyse, weil sie zeigt, welche Angriffsfläche sein Haus in den letzten achtzehn Monaten dazubekommen hat: Trainingsdaten-Integrität, Eingabevalidierung, Modell-Lebenszyklus, Infrastruktur, Zugriffskontrolle und Identität, Lieferkette, Modellverhalten, Memory und Vektordatenbanken, Orchestrierung und agentische Aktionen, MCP-Sicherheit, adversariale Robustheit, Monitoring.

MCP-Sicherheit ist ein eigenes Kapitel in einem Standard. Vor achtzehn Monaten gab es das Protokoll noch nicht in dieser Verbreitung.

Dazu zwei Bedrohungskataloge: die OWASP LLM Top 10 in der Fassung von Anfang August 2026, und die OWASP Top 10 for Agentic Applications vom Dezember 2025. Zwei Listen, weil sie zwei verschiedene Dinge beschreiben. Die eine behandelt das Modell als Komponente, die Eingaben bekommt und Ausgaben produziert. Die andere behandelt es als Akteur mit Zielen, Zugangsdaten, Werkzeugen und Gedächtnis.

Wenn dein Produkt Agenten hat, brauchst du beide. Und dein Pentest-Anbieter hat vermutlich von keiner der beiden gehört, als er dir das Angebot geschrieben hat.

Die eine Bewegung in der Liste, die deine Risikorechnung ändert

Die 2026er Fassung der LLM Top 10 wurde erstmals nicht nur durch Expertenvotum bestimmt, sondern zu einem Viertel durch reale Vorfälle. 7 714 analysierte Incidents. Das verschiebt die Rangfolge, und zwei Verschiebungen erzählen dieselbe Geschichte.

Excessive Agency ist von Platz sechs auf Platz drei gestiegen. Zu viel Handlungsvollmacht für das Modell.

Improper Output Handling ist von Platz fünf auf Platz zehn gefallen. Die unsaubere Weiterverarbeitung der Modellantwort.

Übersetzt für die Vorstandssitzung: Der Schaden entsteht nicht mehr dort, wo das Modell etwas Falsches sagt. Er entsteht dort, wo es etwas Falsches tut. Die relevante Frage lautet nicht mehr, wie gut deine Antworten sind. Sie lautet, was dein System auslösen darf und mit wessen Rechten.

Prompt Injection steht unverändert auf Platz eins, jetzt erweitert um Angriffe, die in Bildern und Audio versteckt sind.

Guardrails sind deine WAF. Was fehlt, ist die Schicht darunter.

Im Web sichern wir Injection auf zwei Ebenen ab, und nur zusammen ergeben sie den Standard, den heute jeder akzeptiert.

Unten liegt die deterministische Ebene: parametrisierte Abfragen. Damit ist SQL Injection nicht zu neunundneunzig Prozent verhindert, sondern strukturell unmöglich, weil Anweisung und Daten getrennte Kanäle haben. Darüber liegt die probabilistische Ebene: die Web Application Firewall, seit März 2025 in PCI DSS für öffentlich erreichbare Anwendungen sogar verpflichtend. Sie rät, sie hat Falsch-Negative, und das ist völlig in Ordnung. Sie darf raten, weil unter ihr etwas liegt, das nicht raten muss.

Bei KI hast du heute nur die obere Ebene. Guardrails sind deine WAF, und sie sind erstaunlich gut geworden: Für ein gehärtetes Modell nennt Anthropic rund ein Prozent Erfolgsquote bei Injection-Versuchen. Als WAF-Kennzahl wäre das ein Spitzenwert.

Die parametrisierte Abfrage fehlt trotzdem. Ein Sprachmodell verarbeitet Systemanweisung, Nutzereingabe und den Text aus der eingehenden Mail in einer einzigen Tokenfolge. Es gibt keine Privilegiengrenze zwischen Anweisung und Daten, deshalb zeigt Forschung gegen sechs verbreitete Schutzsysteme, darunter Azure Prompt Shield und Meta Prompt Guard, Umgehungsraten von bis zu hundert Prozent, sobald ein Angreifer seine Eingaben gezielt anpasst.

Der Unterschied liegt also nicht in der Erkennungsrate. Er liegt darin, was hinter der Lücke wartet. Kommt eine Payload an der WAF vorbei, trifft sie auf Code, der sie nicht ausführt. Kommt eine Injection am Guardrail vorbei, trifft sie auf einen Agenten mit deinen Werkzeugen und deinen Rechten.

Und damit ist das Problem lösbar, nur eben nicht dort, wo die meisten es suchen. Die fehlende Ebene baust du nicht aus besserer Erkennung, sondern aus Berechtigungen. Was ein Agent nicht darf, kann keine Injection auslösen. Das ist deterministisch, genau wie die parametrisierte Abfrage, und es ist die einzige Kontrolle in der ganzen Kette, die nicht raten muss.

Das ist auch der Grund, warum die Guardrails in Azure AI Foundry an vier Interventionspunkten greifen: bei der Nutzereingabe, vor dem Werkzeugaufruf, an der Werkzeugantwort und an der finalen Ausgabe. Die drei Punkte nach der Eingabe sind nicht Redundanz, sie sind der Ersatz für die Ebene, die es im Modell nicht gibt. Wer nur am Eingang filtert, hat eine WAF gekauft und die parametrisierten Abfragen weggelassen.

Der Termin, der wirklich zählt, ist nicht der Regulator

Viele Programme warten auf den AI Act. Dieser Druck ist gerade weggefallen. Mit dem Digital Omnibus, im Rat final bestätigt Ende Juni 2026, sind die Hochrisiko-Pflichten verschoben: eigenständige Systeme nach Anhang III auf den 2. Dezember 2027, KI in regulierten Produkten nach Anhang I auf den 2. August 2028. Seit dem 2. August 2026 gilt die Transparenzpflicht nach Artikel 50, mehr nicht.

Wer sein KI-Sicherheitsprogramm am AI Act aufgehängt hat, hat gerade sechzehn Monate geschenkt bekommen. Die Angreifer nicht.

Der Termin, der zählt, steht in einem anderen Dokument. 44 Prozent der befragten Sicherheitsverantwortlichen geben an, ihr Cyberversicherer verlange bereits heute einen Nachweis über Pentests des KI-Ökosystems. Nicht 2027. Beim nächsten Renewal.

Und bis vor sieben Wochen gab es für diesen Nachweis keinen anerkannten Massstab. Jetzt gibt es einen.

Was du in den nächsten neunzig Tagen tun kannst

Inventar vor Test. Kein Assessment ist etwas wert, solange niemand sagen kann, welche KI-Systeme, Agenten und Anbindungen produktiv laufen. Null von dreihundert Befragten haben hier volle Sicht. Das ist der erste Arbeitsschritt, nicht der letzte.

Massstab in den Vertrag. AISVS-Level festlegen, so wie du es bei ASVS längst tust. Die beiden Top-10-Listen als Bedrohungskatalog danebenlegen. Ein Angebot, das keinen Standard nennt, ist ein Angebot über unbestimmte Leistung.

Berechtigungen sind deine parametrisierte Abfrage. Der Sprung von Excessive Agency auf Platz drei ist keine Modellfrage, sondern eine Rechtefrage. Kurzlebige Anmeldeinformationen statt Dauer-Token, Rechte pro Aufgabe statt pro Agent, und für jede Werkzeuganbindung die Frage, was ein Angreifer damit anstellen könnte, der die Eingabe kontrolliert. Das ist die einzige Massnahme auf dieser Liste, die auch dann wirkt, wenn alles andere versagt.

Bestehende Guardrails auf Vollständigkeit prüfen. Die meisten Implementierungen sichern die Eingabe und lassen die Werkzeugkette offen. Lass dir zeigen, welche Kontrolle an welchem Punkt greift, und welche davon beim Anbieter noch als Vorschau ohne Service Level läuft.

Frequenz. Bei quartalsweiser Prüfung berichten 80 Prozent der Befragten Zuversicht in ihre KI-Sicherheit, bei jährlicher 71. Der eigentliche Grund liegt aber nicht in der Statistik: Modell, Systemprompt, Werkzeuge und Datenanbindungen ändern sich bei KI-Systemen monatlich. Ein Jahresbericht beschreibt ein System, das es so nicht mehr gibt.

Vor sieben Wochen war "es gibt dafür keinen Standard" noch eine Erklärung. Jetzt ist es eine Entschuldigung.

Erst die Daten aufräumen, dann KI. Genau falsch herum.

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Nimm irgendeine Regel in deinem wichtigsten System. Eine Preisstaffel, eine Freigabegrenze, eine Ausnahme für einen Grosskunden. Frag dein Team, warum sie genau so ist, wie sie ist. Du bekommst zwei Antworten: "historisch gewachsen" und "das war vor meiner Zeit".

Dabei existiert die Antwort. Sie steht in einem Ticket-Kommentar unter einem Bug, den längst niemand mehr sucht, und in einem Chat-Verlauf, in dem ein paar Leute an einem Nachmittag etwas entschieden haben, das bis heute läuft. Es gibt kein Protokoll, weil es keine Sitzung war. Zwei der Beteiligten arbeiten inzwischen woanders.

Dein Unternehmen hat kein Dokumentationsproblem. Es hat ein Auffindbarkeitsproblem. Das ist ein Unterschied, und er entscheidet darüber, was du dagegen tun kannst.

Wo das Wissen wirklich liegt

Im Wiki steht, wie es geplant war. Wie es geworden ist, steht woanders.

In den Chats liegen die Absprachen. Teams und Slack sind längst der Ort, an dem Entscheidungen fallen, und zwar genau die kleinen, die niemand für protokollwürdig hält. Sie sind trotzdem verbindlich, sie laufen jahrelang weiter, und sie sind nirgends sonst festgehalten.

In den Tickets liegt die Geschichte der Logik. Ein Bug-Report, die Diskussion darunter, ein Change Request ein halbes Jahr später: zusammen ergeben sie die Begründung für eine Regel, die im Code nur noch als Bedingung steht. Der Code sagt dir, was das System tut. Nur das Ticket sagt dir, warum. Und das Warum ist genau das, was du brauchst, sobald jemand etwas ändern will.

Im Support liegt die Wahrheit über deine Kunden. Nicht, was die Spezifikation über sie annimmt, sondern was sie tatsächlich tun, wo sie hängenbleiben und welche Zusagen ihnen jemand gemacht hat.

Kein Mensch setzt das zusammen. Nicht aus Faulheit, sondern weil es eine Suchaufgabe über Jahre, über Systemgrenzen und über drei Namen desselben Features hinweg ist, deren Ertrag man vorher nicht kennt. Also bekommt niemand Zeit dafür. Also passiert es nie. Und mit jedem Abgang wird der Rest teurer.

Der Einwand, der die meisten Projekte stoppt

"Bevor wir KI einsetzen, müssen wir erst unsere Daten in Ordnung bringen."

Der Satz klingt erwachsen, und in der Sache ist er halb richtig. Eine KI, die auf einen widersprüchlichen Bestand gesetzt wird und daraus Auskunft gibt, antwortet widersprüchlich. Schlimmer noch: sie antwortet mit einer Selbstsicherheit, die der Bestand nicht hergibt.

In der Konsequenz ist der Satz trotzdem fatal. Das Aufräumen dieser Bestände ist exakt die Arbeit, die aus den oben genannten Gründen nie jemand macht. Wer sie zur Vorbedingung erklärt, hat KI nicht sorgfältig geplant, sondern auf unbestimmte Zeit vertagt.

Der Ausweg liegt in der Rolle, die du der KI gibst. Das sind zwei völlig verschiedene Aufgaben:

Auskunft geben aus dem Rohbestand. Das ist die Variante, vor der die Skeptiker zu Recht warnen.
Den Rohbestand aufarbeiten, unter menschlicher Abnahme. Sachverhalte recherchieren, verstreute Fragmente zusammenziehen, Widersprüche benennen, Struktur vorschlagen.

Nicht "antworte mir aus dem Chaos", sondern "lies das Chaos, ordne es, und zeig mir, wo es sich selbst widerspricht". Diese Arbeit skaliert mit Rechenzeit statt mit Kalenderwochen, und sie ist das Einzige, was die Vorbedingung jemals erfüllen wird.

Was dabei herauskommt

Kein weiteres Dokument. Ein Wissensgraph ist die Zerlegung deines Wissens in einzelne Fakten, jeder mit Herkunft, jeder mit Verweisen auf verwandte Fakten, gruppiert nach fachlichen Domänen statt nach Werkzeugen. Aus fünf Systemen, die nichts voneinander wissen, wird ein Netz, in dem eine Regel, ihre Begründung, ihre Ausnahme und der Kunde, für den sie gemacht wurde, aneinanderhängen.

Der entscheidende Teil für dich ist nicht die Struktur, sondern die Prüfbarkeit. Jede Aussage muss ihre Quelle mitführen. Der Unterschied zwischen "die KI sagt" und "das steht so im Ticket, wurde im Chat bestätigt und widerspricht der Wiki-Seite" ist der Unterschied zwischen einem Spielzeug und einer Entscheidungsgrundlage. Der Test dafür ist simpel: Kannst du zu jeder Aussage die Originalstelle aufrufen? Wenn nicht, hast du keine Wissensbasis, sondern eine Meinung mit Datenbank.

Ich arbeite selbst so, im Kleinen: mein gesamtes projektübergreifendes Wissen liegt als Graph aus einzelnen Fakten, verlinkt und versioniert, statt in Notizen. Der Unterschied ist nicht das Ablegen. Der Unterschied ist, dass jede KI, mit der ich arbeite, sofort auf diesem Stand aufsetzt statt bei null.

Der unbequeme Teil

Die KI löst deine Widersprüche nicht auf. Sie legt sie dir hin.

Wenn drei Quellen drei Varianten derselben Regel enthalten, bekommst du eine Entscheidungsvorlage und keine Antwort. Jemand muss entscheiden, welche gilt. Genau dort kippt ein solches Vorhaben oder erzeugt seinen Wert: Der erste Bericht sagt dir, dass eine zentrale Regel seit Jahren in zwei Fassungen existiert, dass beide angewendet werden, und niemand will derjenige sein, der festlegt, welche stimmt.

Ein Wissensgraph produziert zuerst Arbeit und dann Ersparnis. Wer nur die Ersparnis eingeplant hat, hört nach dem ersten Bericht auf. Und die offengelegten Widersprüche waren vorher auch schon da, sie hatten nur noch niemandem geschadet, der sie hätte benennen müssen.

Drei Dinge, die du vorher klärst

Berechtigungen. Ein Graph führt zusammen, was in den Quellsystemen getrennt war. Wer in einem geschlossenen Kanal nichts verloren hat, darf den Inhalt auch über die Suche nicht sehen. Wandern die Rechte der Quelle nicht mit, baust du deinen ersten unternehmensweiten Datenabfluss und nennst ihn Wissensmanagement.

Personendaten. Chats sind voll davon. Neben Zweckbindung und Mitbestimmung gibt es einen praktischen Effekt, der oft übersehen wird: Wer Chats indexiert, ohne zu erklären wofür, bekommt Chats, in denen nichts mehr steht. Die Absprachen wandern dann in Direktnachrichten und aufs private Handy. Dann hast du die Quelle nicht erschlossen, sondern zerstört.

Aktualität. Ein einmalig gebauter Graph ist ein Foto. Er beginnt am Tag nach der Fertigstellung zu altern. Entweder er läuft mit den Quellsystemen mit, oder er wird genau das, was er ersetzen sollte: eine Dokumentation, der niemand mehr traut.

Warum das strategisch ist und nicht nur ordentlich

Einarbeitung wird schneller, Übergaben werden möglich, Abgänge reissen kleinere Löcher. Das sind die naheliegenden Effekte, und sie sind real.

Der grössere Punkt liegt woanders. Solange dein Wissen verstreut ist, kann KI bei dir nur Oberflächenarbeit leisten. Texte formulieren, Protokolle zusammenfassen, Code-Bausteine liefern. Alles Aufgaben, für die man von deinem Unternehmen nichts wissen muss. Deshalb sehen die Ergebnisse überall gleich aus, und deshalb ist der Effekt klein genug, dass man ernsthaft über den Nutzen von KI streiten kann.

Der Unterschied entsteht, wo eine KI weiss, warum eure Freigabegrenze dort liegt, wo sie liegt, wer welche Ausnahme wann zugesagt hat und welcher Kunde deshalb anders behandelt wird. Dieses Wissen kannst du nicht einkaufen und kein Anbieter hat es. Es liegt längst bei dir, in Systemen, die es nicht herausgeben.

Wenn du damit anfangen willst: nimm nicht alles auf einmal. Nimm eine Domäne, in der es regelmässig weh tut, und arbeite deren Bestand auf, mit Quellenangabe bei jedem Fakt und mit einem Menschen, der die Widersprüche abnimmt. Nach dieser einen Domäne weisst du zwei Dinge, die dir vorher niemand sagen konnte: was in deinen Systemen tatsächlich steckt, und was es kostet, es herauszuholen.

Das Gedächtnis deiner Firma ist nicht leer. Es ist unsortiert. Das ist die deutlich bessere Nachricht.

Am Ende einer guten KI-Schulung steht kein Zertifikat, sondern ein gelöstes Problem.

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Die Schulung war gut. Der Referent war gut. Die Bewertungsbögen waren gut.

Am Montag arbeitet jeder wieder wie am Freitag davor.

Das ist kein Trainerproblem. Und es liegt auch nicht an deinen Leuten.

Wissen kannst du nicht besitzen

Frontalunterricht produziert Wissen. Wissen sitzt in Köpfen, und Köpfe gehen abends nach Hause, im Sommer in die Ferien und irgendwann zur Konkurrenz.

Ein Unternehmen kann Wissen nicht besitzen. Es kann nur Verfahren besitzen: einen beschriebenen Weg, den ein anderer gehen kann, ohne den Erfinder zu fragen.

Dazu kommt die Sache mit den Beispielen. Seminarbeispiele sind sauber. Deine Probleme sind es nicht. Bei dir fehlt die Berechtigung auf das Laufwerk, das Ausgangsdokument liegt in drei Versionen vor, und der Kollege, der die Freigabe erteilen müsste, ist zwei Wochen weg. Genau an diesem Dreck scheitert die Übertragung, und genau dieser Dreck kommt im Seminar nicht vor.

Die Frage nach einer Schulung ist deshalb nicht, ob sie gut war. Sondern: Was liegt jetzt im Unternehmen, das vorher nicht da war?

Bevor du auf die naheliegende Antwort kommst: Ein einzelnes Projekt ist auch nur ein Termin.

Was letztes Jahr der richtige Weg war, ist heute der Umweg. Ein Beispiel ohne Fachbegriffe: Vor zwei Jahren hat man eine Frage gestellt und einen Text zurückbekommen, den man selbst weiterverarbeitet hat. Heute gibt man eine Aufgabe ab und bekommt ein Ergebnis, inklusive der Schritte dazwischen. Wer immer noch fragt, statt abzugeben, arbeitet sauber und diszipliniert nach einem Stand, den es nicht mehr gibt. Er merkt es nicht, weil ihm nie jemand das andere gezeigt hat.

Die Frage ist also nicht, wie gut du einmal schulst. Sondern ob du einen laufenden Betrieb hast.

Nimm ein echtes Problem

Der Formatwechsel ist unspektakulär und ändert alles.

Statt eines Seminars nimmst du ein echtes Problem aus dem eigenen Haus. Eines, das weh tut. Und eines, bei dem am Ende jemand sagen kann, ob es gelöst ist oder nicht.

Dieses Problem löst ihr durch, von vorne bis hinten. Nicht bis zur Demo. Bis zu dem Punkt, an dem klar ist, wer es nächste Woche macht, woher die Daten kommen, wer sie freigibt und was passiert, wenn das Ergebnis falsch ist.

Das ist der unbequeme Teil, und er ist der eigentliche Lernstoff. Piloten sterben nicht am Prompt. Sie sterben an der Schnittstelle: an der Freigabe, am Datenzugang, an der Übergabe, an der Frage, wer geradesteht. Wer das einmal komplett durchgearbeitet hat, hat mehr gelernt als in jedem Kurs.

Und dann kommt der Teil, den fast alle weglassen. Ihr schreibt auf, wie ihr es gemacht habt. Nicht das Ergebnis. Den Weg.

Das dokumentierte Vorgehen ist das Produkt der Schulung, nicht die Lösung.

Rechne es gegen: Ein Seminar kostet Geld und Arbeitszeit und liefert Wissen. Dieses Format kostet dasselbe und liefert zwei Dinge. Ein Problem, das weg ist. Und ein Verfahren, das bleibt. Es refinanziert sich am ersten Tag. In deiner Buchhaltung ist das keine Weiterbildungsposition mehr, sondern Projektarbeit, bei der nebenbei gelernt wird.

Das Dokument ist der Vermögenswert

Können ist nicht übertragbar. Ein Vorgehen schon.

Der Test dafür ist simpel. Nimm jemanden, der nicht dabei war, und gib ihm das Dokument. Kann er damit arbeiten, ohne den Autor zu fragen? Wenn ja, hat dein Unternehmen etwas dazugewonnen. Wenn nein, hat eine Person etwas dazugewonnen.

Dieser Unterschied ist der ganze Punkt. In vielen Firmen gibt es inzwischen drei oder vier Leute, die mit diesen Werkzeugen erstaunliche Dinge tun. Die Firma ist trotzdem exakt so schnell wie vorher. Das ist kein Motivations- und kein Talentproblem. Es fehlt schlicht der Weg von der Person zur Organisation.

Was den Betrieb am Laufen hält

Damit das kein Einzelfall bleibt, braucht es ein paar unspektakuläre Festlegungen.

Kadenz statt Kalendertermin. Es gibt immer ein laufendes Problem, nicht einen Termin pro Quartal.

Jemand hat den Hut, mit Mandat und Budget. Ein Hut ohne beides ist dieselbe Grauzone wie vorher, nur mit einem Namen dran.

Zeit ist eingeplant, nicht geduldet. Wer eine Technik findet und aufschreibt, erbringt damit Arbeitsleistung. Das ist kein Feierabendhobby, und es gehört nicht in die Kategorie "wenn du mal Luft hast".

Es gibt einen Ort für Verfahren, den Leute finden, ohne zu fragen.

Und es gibt eine Ausmusterung. Verfahren altern so schnell wie die Werkzeuge. Ein ungepflegtes Verfahrensarchiv ist schlimmer als gar keines, weil deine Leute dann sauber und gewissenhaft nach einem Weg arbeiten, den ein besseres Werkzeug längst überholt hat. Wer Verfahren anlegt, muss sie auch beerdigen.

Bleibt die Messgrösse. Nicht Schulungsstunden, nicht Lizenz-Logins. Sondern die Anzahl Verfahren, die von einer Person auf ein Team übergegangen sind.

Und der AI Act?

Kurz, weil es zur Sache weniger beiträgt, als alle denken.

Artikel 4 verlangt seit dem 2. Februar 2025 KI-Kompetenz, und zwar für jeden KI-Einsatz, nicht nur für Hochrisiko-Anwendungen. Mit dem Digital Omnibus, seit dem 27. Juli 2026 in Kraft, hat Brüssel die Pflichten für Hochrisiko-Systeme auf Dezember 2027 und August 2028 verschoben und Artikel 4 abgeschwächt: aus "KI-Kompetenz sicherstellen" wurde "Massnahmen ergreifen, um die Entwicklung von KI-Kompetenz zu unterstützen". Ein bestimmtes Kompetenzniveau einer einzelnen Person muss niemand mehr garantieren.

Du kannst die Pflicht jetzt also mit einem Halbtag erfüllen.

Du kannst sie nur nicht mehr mit einem Halbtag begründen.

Der Regulierer hat den Druck herausgenommen. Der Grund zu schulen bleibt trotzdem bestehen, er ist nur wieder das geworden, was er immer war: eine betriebswirtschaftliche Frage, keine juristische.

Der Unterschied

Eine Schulung, die nichts hinterlässt ausser Wissen, war nicht zu lang und nicht zu kurz.

Sie war das falsche Format.

Die KI hat den Fall nicht bedacht. Du hast ihn nie aufgeschrieben.

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Ich lese es inzwischen jede Woche. Die KI hat diesen Sonderfall nicht bedacht. Die KI hat die Fehlerbehandlung falsch gemacht. Die KI hat schon wieder etwas kaputtgemacht, das vorher lief.

Die Beobachtung stimmt meistens. Die Schlussfolgerung fast nie.

Denn eine KI tut in aller Regel genau das, was man ihr sagt. Was sie nicht kann, ist deine Gedanken lesen und deine Wünsche erraten.

Die Frage, die vor jeder Schuldzuweisung kommt

Bevor du der KI einen Fehler anhängst, beantworte eine einzige Frage ehrlich:

Hast du diese Regel gefordert, und sie wurde nicht umgesetzt? Oder war dein Requirement schlampig, und die KI hat exakt das gebaut, was dort stand?

Fall eins ist ein Werkzeugproblem. Den gibt es, und dann darfst du dich zu Recht aufregen.

Fall zwei ist ein Hausaufgabenproblem. Und Fall zwei ist der häufigere.

Der unangenehme Teil daran: Fall zwei sieht von aussen exakt gleich aus wie Fall eins. Am Ende steht in beiden Fällen ein Ergebnis, das nicht dem entspricht, was du im Kopf hattest. Nur war es in Fall zwei nie irgendwo ausser in deinem Kopf.

Früher hat das jemand für dich aufgefangen

Und hier sind wir am Kern.

Nachlässiges Requirements Engineering ist keine Erfindung des KI-Zeitalters. Es war immer da. Es ist nur nie aufgefallen, weil gute Entwicklerteams es abgefangen haben. Die haben zwar die Augen verdreht, es aber mit ihrer Erfahrung richtig gemacht. Sie haben die fehlende Regel ergänzt, den nicht spezifizierten Sonderfall behandelt und die drei Annahmen mitgedacht, die im Ticket nicht standen.

Diese stille Reparaturschicht war der eigentliche Qualitätsprozess in den meisten Firmen. Nur stand sie in keinem Prozesshandbuch, weil sie in keinem Prozesshandbuch stehen konnte. Sie war in Köpfen.

Genau das kann eine KI nicht. Und ehrlich gesagt: sie muss es auch nicht können.

Stattdessen müssen Requirements Engineers, im Scrum-Sprech Product Owner, endlich anfangen, ihren Job ernst zu nehmen. Ein Ticket, das sich nur mit fünf Jahren ungeschriebenem Hauswissen korrekt umsetzen lässt, ist kein Ticket. Das ist eine Andeutung. Und was dir gerade durch den Kopf schiesst, ist noch lange kein Requirement, auch wenn es sich im Refinement so anfühlt.

Die KI hat diese Lücke nicht erzeugt. Sie hat sie nur sichtbar gemacht.

Human in the Loop ist richtig. Nur nicht aus dem Grund, den du denkst

Die zweite Gruppe, die ich gerade überall lese, sind die, die bei KI alles kontrollieren wollen. Stichwort Human in the Loop.

Der Punkt ist richtig. Aber die Begründung ist fast immer falsch.

Warum kontrolliert der Senior Developer oder der Architekt das Ergebnis? Nicht weil die KI grundsätzlich unzuverlässig wäre. Sondern weil nirgends dokumentiert ist, wie in eurem Haus etwas zu tun ist. Welches Vorgehensmodell gilt. Welche Bibliothek warum verboten ist. Wie ihr Fehler behandelt, wie ihr loggt, was in diesem einen Altsystem niemals angefasst werden darf.

Der Senior prüft gegen einen Standard, den es nur in seinem Kopf gibt. Er ist nicht die Qualitätssicherung. Er ist die Spezifikation.

Und genau deshalb tut es so weh, wenn diese Leute gehen. Sie nehmen nicht Arbeitskraft mit. Sie nehmen den Standard mit.

Human in the Loop als Dauerzustand ist damit kein Qualitätsprozess. Es ist ein Abo auf Personenabhängigkeit.

Die Lösung ist unspektakulär: schreib es auf. Aber richtig

Nicht als Wiki. Ein Wiki wird geschrieben, wenn jemand Zeit hat, und gelesen, wenn jemand verzweifelt ist. Beides passiert selten genug, damit es nie funktioniert.

Sondern als Wissensgraph, der im Team mitläuft und sich permanent selbst ausbaut.

Ich habe damit vor rund drei Monaten angefangen. Inzwischen sind es 196 Markdown-Dateien, versioniert in Git. Ein Fakt pro Datei, untereinander verlinkt, nach Domänen sortiert. Darin steht sehr viel von meinem Vorgehensmodell: wie ich arbeite, was ich nicht will, welche Entscheidung wann aus welchem Grund gefallen ist, welche Annahme sich als falsch herausgestellt hat.

Zwei Dinge machen den Unterschied aus, und beide sind wichtiger als der Inhalt:

Geschrieben wird selbstständig. Claude legt einen neuen Knoten an, wenn etwas Neues gelernt wurde oder wenn ich korrigiert habe. Ohne dass ich jedes Mal daran erinnere. Wissen, dessen Erfassung an einer menschlichen Fleissaufgabe hängt, wird nicht erfasst.

Gelesen wird zuerst. Bei einer neuen Aufgabe liest er zuerst seinen Wissensgraphen und fängt nicht wieder bei Adam und Eva an. Ein Speicher, in den nur geschrieben wird, ist ein Friedhof.

Der Teil, der eure Geschäftsleitung interessieren sollte

Der schönste Nebeneffekt ist einer, über den in der ganzen KI-Diskussion viel zu wenig geredet wird: dieser Graph ist wiederverwendbar, wenn du das KI-Tool austauschst.

Wechselst du von ChatGPT zu Claude oder umgekehrt, weiss das neue Modell ab dem ersten Prompt exakt das, was das alte wusste. Kein Neuaufbau, kein Anlernen, keine sechs Wochen, in denen wieder alles zweimal erklärt wird.

Das ist die eigentliche strategische Erkenntnis für Entscheider: Vergrabt euer Wissen nicht in Chats. Chats sind kein Speicher, sie sind Verkehr. Organisiert es ordentlich in Wissensgraphen, die jeder neue Mitarbeiter und jedes neue KI-Modell mitnutzen kann.

Wer sein Firmenwissen in den Chatverläufen einzelner Mitarbeiter liegen lässt, hat sein Wissensmanagement an einen Anbieter ausgelagert, mit dem er keinen Vertrag darüber hat.

Was sich damit über die Zeit von selbst erledigt

Beides. Die fehlenden Requirements und die Nachkontrolle.

Nicht weil plötzlich alle sauber spezifizieren, sondern weil die KI so viel Kontext bekommt, dass praktisch keine Frage mehr offen bleibt. Der Sonderfall, den du nicht ins Ticket geschrieben hast, steht im Graphen, weil er beim letzten Mal geklärt wurde. Die Regel, die dein Architekt sonst im Review durchgesetzt hätte, greift schon beim Schreiben.

Genau wie beim Senior, der den Gap mit einem Augenrollen ausgeglichen hat. Nur ohne die Abhängigkeit von Einzelpersonen. Und diesmal reproduzierbar.

Die KI macht nicht mehr Fehler als dein Team. Sie macht nur die Fehler sichtbar, die dein Team seit Jahren stillschweigend für dich repariert hat.

Euer KI-Budget liegt in der IT. Deshalb misst niemand, was es bringt.

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Für alle, die KI liefern sollen, ohne dass jemand entschieden hat, was dabei herauskommen soll.

Die Lizenzen laufen. Die Modelle sind angebunden. In deinem Statusbericht steht grün. Und wenn dich jemand fragt, was das Ganze gebracht hat, nennst du Nutzungszahlen, weil du nichts Besseres hast.

Das ist kein Versäumnis deiner Leute. Es ist die logische Folge davon, wo die Sache verbucht ist.

Der Reflex ist gelernt, nicht dumm

ERP, CRM, Cloud-Migration: alles Vorhaben, die in der IT lagen und dort richtig lagen. Der Auftrag war beschreibbar, die Abnahme war technisch, und das Geschäft musste sich nicht verändern, um den Nutzen zu bekommen. Es gibt auch bei KI Arbeit, die genau so funktioniert: Infrastruktur, Modellbetrieb, Werkzeuge für dein eigenes Entwicklungsteam. Da bist du zuständig, und zwar allein.

Die Linie verläuft woanders. Sobald KI einen Kunden, einen Prozess oder eine Haftung berührt, ist sie kein IT-Projekt mehr. Dann ist sie eine Geschäftsentscheidung, die zufällig Software braucht.

Wo das Budget liegt, entsteht die Erfolgsdefinition

Ein Vorhaben im IT-Budget wird an IT-Grössen gemessen: ausgerollt, verfügbar, im Zeitplan, im Rahmen. Diese Grössen können vollständig grün sein, während der Beitrag zum Geschäft null ist. Niemand lügt dabei. Es misst nur niemand das, worauf es ankommt, weil es in dieser Berichtslinie gar nicht vorgesehen ist.

Das ist der Grund, warum du auf die Frage nach dem Nutzen mit Nutzungszahlen antwortest. Du berichtest, was dein Auftrag hergibt.

Wer nicht entscheidet, entscheidet trotzdem

Jetzt kommt der teure Teil. Ein Vorhaben, das nach aussen wirkt, braucht Entscheidungen, die oben oft niemand ausdrücklich trifft: wie viel Fehlerquote tragbar ist, welche Daten hineindürfen, welcher Prozess wirklich verändert wird. Werden sie nicht getroffen, verschwinden sie nicht. Sie werden bei dir getroffen. In einem Ticket, in einem Prompt, in einer Schwelle, die jemand im Team auf irgendeinen Wert setzt, weil dort ein Wert stehen muss.

Damit hat dein Team stellvertretend über Kundenkommunikation, Risiko und Haftung entschieden. Ohne Mandat, ohne Budget für die Folgen, und ohne dass es oben jemand mitbekommt.

Das ist übrigens auch die Antwort auf den Satz, die IT würde bremsen. Du bremst nicht. Du sollst eine Frage beantworten, die du nie stellen durftest.

Die fünf Entscheidungen, die du nicht allein treffen darfst

Nimm diese fünf Punkte in die nächste Runde mit. Nicht als Beschwerde, sondern als Liste, die abgearbeitet wird.

1. Welche Zahl sich bewegen soll. Stunden, Franken, Durchlaufzeit, Abbruchquote. Eine Zahl, gemessen vorher und nachher, mit einem Namen dahinter, der nicht deiner ist.

2. Welche Fehlerquote akzeptabel ist, und wer den Fehler bezahlt. Fehlerfrei gibt es nicht. Sagt niemand, was tragbar ist, entsteht die Schwelle in deinem Code, und die Verantwortung dafür bleibt trotzdem beim Betreiber.

3. Ob der Prozess verändert oder nur beschleunigt wird. Ein kaputter Prozess mit KI ist ein kaputter Prozess mit höherem Durchsatz. Das ist eine Organisationsentscheidung, keine technische.

4. Wer womit auf welchen Daten arbeiten darf. Wird das nicht entschieden, entscheiden es die Leute selbst, nur eben nicht mehr innerhalb eurer Systeme.

5. Woran ihr erkennt, dass ihr aufhört. Kein Abbruchkriterium heisst, dass nichts je endet. Das Vorhaben lebt im Budget weiter, lange nachdem klar ist, dass es nichts trägt.

Was du sehr wohl entscheidest

Damit kein falscher Eindruck entsteht: Das ist keine Abgabe nach oben. Es gibt genau eine Frage, die niemand ausser dir beantworten kann, und sie ist die Voraussetzung für alle fünf Punkte: was zu welcher Fehlerquote und zu welchen Kosten überhaupt geht. Ohne diese Antwort entscheidet das Geschäft im luftleeren Raum, und du bekommst ein Mandat mit Termin, das sich nicht bauen lässt.

Das Was gehört an einen Tisch, an dem beide sitzen. Allein gehört dem Geschäft nur die Frage, wer die Folgen trägt.

Fünf Minuten, dann weisst du, wo ihr steht

In welchem Budget steht euer KI-Vorhaben?
Wer berichtet das Ergebnis, und an wen?
Nenn die Zahl, die sich bewegen soll, ohne nachzuschlagen.
Wer hat entschieden, welche Fehlerquote ihr akzeptiert?
Wer darf abschalten?

Wenn bei drei dieser Fragen die Antwort die IT ist, führt ihr ein IT-Projekt. Dann bekommt ihr auch die Ergebnisse eines IT-Projekts: pünktlich, verfügbar, wirkungslos.

Eine Entscheidung, die oben niemand trifft, verschwindet nicht. Sie wird in deinem Code getroffen, von deinen Leuten, auf deine Rechnung.

Du hast deiner KI beigebracht, wie ihr arbeitet. Dein Kollege fängt bei null an.

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Wenn du seit Monaten mit einem KI-Agenten arbeitest, hast du ihm eine Menge beigebracht. Nicht in einem Schwung, sondern in hunderten kleinen Korrekturen. So schreiben wir das hier nicht. Diese Bibliothek nicht, die ist abgekündigt. Dieses Vorgehensmodell, nicht jenes. Nein, auch nicht beim zweiten Versuch.

Dieser Aufwand ist echt und er ist gut investiert. Er hat nur eine Eigenschaft, die selten jemand mitdenkt: er ist vollständig privat. Er liegt in deinen Sitzungen, auf deinem Rechner, und er endet an der Kante deines Schreibtischs.

Im Team bricht das sofort auf

Du gibst eine Aufgabe an einen Kollegen ab. Gleiches Werkzeug, gleiches Modell, er ist nicht schlechter als du. Trotzdem kommt etwas anderes heraus.

Nicht weil er es falsch macht, sondern weil seine KI nichts von den hunderten Korrekturen weiss, die deine gelernt hat. Sie kennt eure Namenskonventionen nicht, eure Ablagestruktur nicht, und vor allem nicht die Dinge, die ihr schon ausprobiert und wieder verworfen habt. Sie liefert eine plausible Lösung. Nur eben nicht eure.

Damit ist Reproduzierbarkeit weg, und zwar an der Stelle, an der niemand sie sucht. Beide benutzen dasselbe Werkzeug, also nimmt man an, beide arbeiten gleich.

Bei Entwicklern kostet das mehr als eine Abweichung

Im Code ist der Schaden nicht kosmetisch, sondern strukturell.

Ein Agent, der den Lösungsweg nicht kennt, kennt auch die Begründung nicht. Er sieht ein Pattern und hält es für Zufall. Er sieht eine Umgehung und hält sie für schlechten Stil. Beim nächsten Refactoring räumt er beides weg, sauber, konsistent, gut begründet. Und zerstört dabei genau die Entscheidung, die vor einem Jahr aus einem echten Grund so getroffen wurde.

Der Kollege merkt es nicht, weil ihm der Grund fehlt. Sein Agent merkt es nicht, weil ihm derselbe Grund fehlt. Der Fehler fällt Wochen später auf, in einem Kontext, in dem niemand mehr auf dieses Refactoring zurückschaut.

Code dokumentiert das Was. Das Warum lebt in den Gesprächen, die ihr mit euren Agenten geführt habt. Und die wirft ihr jeden Abend weg.

Der zweite Verlustkanal ist dein Laptop

Es braucht nicht einmal einen Kollegen, damit dieses Wissen verschwindet. Es reicht, dass dein Gerät neu aufgesetzt wird oder du ein neues bekommst.

Ohne einen Wissensgraphen, der irgendwo eingecheckt liegt, ist an diesem Tag alles weg und du fängst wieder bei Adam und Eva an. Genau das war bei mir der Anlass. Ich hatte den Graphen nicht von Anfang an. Ich habe ihn gebaut, als ich meine Festplatte formatiert und mein System neu aufgesetzt habe.

Die gute Nachricht: das lässt sich nachträglich einsammeln

Du musst nicht von vorne anfangen und du musst auch nichts anders machen als bisher. Du gehst deine bestehenden Chats durch und setzt in jedem denselben Prompt ab:

Extrahiere alle wichtigen Erkenntnisse und alles was du gelernt hast in einen Knowledge Graphen. im Open Knowledge Format.

Das Ergebnis ist kein Werkzeug und kein Produkt, sondern ein Ordner mit Markdown-Dateien. Ein Fakt pro Datei, ein kurzer Kopf mit Name und Beschreibung, und Verweise zwischen den Dateien. Lesbar in jedem Editor, vergleichbar Zeile für Zeile, von Hand korrigierbar, wenn etwas darin falsch ist.

Bei mir stammte das Material aus 49 Arbeitssitzungen. Die reine Schreibarbeit des ersten Durchlaufs dauerte dreizehneinhalb Minuten.

Danach fehlt nur noch der Schalter, der aus dem Ordner eine Wissensquelle macht. In die CLAUDE.md gehört dieser Block:

## Einzige Wissensquelle: der AI-Knowledge-Graph
Das gesamte projektübergreifende Wissen liegt ausschliesslich hier:
C:\Mein\Pfad\Zum\Graphen\Claude-Code\AI-Knowledge

Ab da liest der Agent zu Beginn jeder Aufgabe nach, statt zu raten. Und er schreibt neu Gelerntes dorthin zurück, statt es in der Sitzung zu lassen.

Zwei Dinge, die fast immer vergessen werden

Erstens die Werkzeuge. Claude und Codex bauen sich mit der Zeit ihre eigenen Helfer: Skripte, die eine wiederkehrende Aufgabe in zehn Sekunden erledigen, für die du sonst eine halbe Stunde brauchst. Diese Skripte sind genauso wertvoll wie das Wissen und verschwinden genauso leise. Sie gehören mit in den Graphen, samt einer Zeile, wozu sie da sind und wie man sie startet.

Zweitens die Wegwerfsachen. Ein Agent produziert laufend temporäre Dateien, und im Moment der Entstehung ist nicht zu unterscheiden, was Wegwerfzeug ist und was du nächste Woche wieder brauchst. Wenn du das nicht regelst, sauigelt dir das quer über die Festplatte. Die Regel ist simpel und muss trotzdem explizit dastehen: alles Temporäre in ein einziges Temp-Verzeichnis, alles Wiederverwendbare an einen einzigen definierten Ort.

Wo der Graph liegen soll

Das ist die eigentliche Entscheidung, und sie hängt vom Team ab.

Entwicklerteams checken den Graphen in die Quellcodeverwaltung ein. Damit ist jede Wissensänderung ein Commit. Du siehst, wer welche Regel wann geändert hat, du kannst eine Änderung diskutieren wie einen Pull Request, und du kannst sie zurückdrehen. Wissen wird revisionierbar, genau wie Code.

Für nicht technische Teams ist das zu viel Overhead. Ein geteiltes Netzlaufwerk oder ein NAS reicht vollkommen. Entscheidend ist nicht das Werkzeug, sondern dass alle in dieselbe Quelle schreiben.

Und das ist der Punkt, an dem aus einer persönlichen Optimierung eine organisatorische wird: das lohnt sich erst abteilungsweit. Ein Graph pro Person ist nur eine besser sortierte private Insel. Ein geteilter Graph ist der Ort, an dem eure Standards, eure Vorgehensmodelle und das Wissen über eure Organisation zusammenlaufen. Erst dann kann ein Kollege eine Aufgabe übernehmen und dasselbe Ergebnis liefern.

Der Nebeneffekt, den niemand einplant

Weil das Ganze aus strukturierten Textdateien besteht und nicht aus einem proprietären Speicher, ist es nicht an ein Werkzeug gebunden.

Wer heute von Codex auf Claude wechselt oder umgekehrt, nimmt sein gesamtes Wissen einfach mit. Kein Export, keine Migration, kein Neuaufbau. Bei der Geschwindigkeit, mit der sich dieser Markt gerade bewegt, ist das kein Randaspekt. Es ist der Unterschied zwischen einer Entscheidung, die du jederzeit korrigieren kannst, und einer, in der du feststeckst.

Am Ende ist das keine Frage der Werkzeuge. Es ist die Frage, ob das Wissen darüber, wie ihr arbeitet, eurer Organisation gehört oder einzelnen Sitzungen auf einzelnen Laptops.

Warum dein Claude Abo nicht in n8n läuft, und wie du es trotzdem hinbekommst

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Die Klage liest man überall: Ich zahle jeden Monat für Claude, und trotzdem will meine Automatisierung einen API Key. Das stimmt. Ich wollte wissen, warum genau, und habe mich zwei Stunden lang in die falsche Richtung graben lassen. Hier ist, was dabei herauskam.

Der naheliegende Versuch

Der erste Gedanke ist immer derselbe: Ich habe ein Abo, ich hole mir daraus einen Token und schicke ihn an die normale Anthropic-Schnittstelle. Technisch spricht nichts dagegen, das Token-Format ist dokumentiert, die Bibliotheken nehmen es an.

Und dann kam die Antwort: HTTP 429, Rate Limit.

Das ist der Moment, in dem die meisten falsch abbiegen, und ich war keine Ausnahme. Ein Rate Limit heisst: zu viel benutzt, warte ab. Also wartet man. Und es passiert nichts, weil man auf ein Fenster wartet, das nie aufgeht.

Die falsche Fährte

Statt weiter zu raten, habe ich die Antworten mitgeschnitten, also nicht nur den Text, sondern auch die Kopfzeilen, die Anthropic mitschickt. Da lag der eigentliche Hinweis, und zwar in dem, was fehlte.

Bei einem erfolgreichen Aufruf kommt ein ganzer Satz Rate-Limit-Header zurück: wie viel vom Fenster verbraucht ist, wann es zurückgesetzt wird, ob ein Überlauf erlaubt ist. Bei den abgewiesenen Aufrufen kamen diese Header überhaupt nicht. Kein einziger.

Ein echtes Kontingentproblem würde genau diese Zahlen mitliefern, es ist ja die ganze Botschaft. Ihr vollständiges Fehlen bedeutet etwas anderes: Das ist kein Verbrauchsproblem, sondern eine Berechtigungssperre, die sich als Rate Limit ausgibt. Der Statuscode war schlicht irreführend.

Der Beweis

Um sicher zu sein, habe ich alle Modelle durchgemessen, die mein Zugang überhaupt anbietet. Das Ergebnis war eindeutig: Von elf Modellen kam genau eines durch, das kleinste das auch ohne Abo funktioniert. Alle anderen wurden abgewiesen, Sekunden später, mit demselben Zugang, im selben Code.

Das ist keine Drosselung. Das ist eine Tür, die für fast alles zu ist.

Warum Umgehen keine Option ist

Ja, es gibt Wege, das zu umgehen. Sie sind erstaunlich simpel, und ich werde sie hier nicht beschreiben. Nicht aus Prinzipienreiterei, sondern weil es nichts bringt.

Nimm an, es funktioniert heute. Dann hängt dein produktiver Workflow an etwas, das der Anbieter jederzeit zumachen kann, ohne Vorwarnung und ohne dass das als Fehler zählt. Es braucht keine grosse Gegenmassnahme, eine Kleinigkeit reicht. Deine Automatisierung steht dann morgens still, und du suchst den Fehler zuerst bei dir.

Ein Trick, der funktioniert, ist noch keine Grundlage. Und niemand baut gern auf Sand, den er selbst geschüttet hat.

Was tatsächlich erlaubt ist

Der interessante Teil kam, als ich aufgehört habe, gegen die Sperre zu arbeiten, und nachgelesen habe, was der Anbieter eigentlich will. Die Trennung ist klarer, als der Frust vermuten lässt:

Wer ein Produkt für fremde Nutzer baut und deren Anfragen über sein Abo leitet, braucht einen API Key. Das ist untersagt, und das ist auch nachvollziehbar.

Wer sein eigenes Abo für seine eigene Arbeit automatisiert, darf das. Vorgesehen ist dafür Claude Code und die Agent SDK, inklusive des nicht-interaktiven Modus. Das ist dokumentiert und ausdrücklich erlaubt.

Im Kern läuft es also darauf hinaus, deine Claude Code Konsole fernzusteuern. Genau das, was du täglich lokal tust, nur angestossen von einem Workflow statt von deiner Tastatur.

Und der Gegentest war die eigentliche Genugtuung: Über diesen Weg lief sofort das grösste Modell, dasselbe, das die Schnittstelle Minuten vorher noch abgewiesen hatte. Nicht mit einem Trick, sondern weil es der vorgesehene Weg ist.

Was ich daraus gebaut habe

Die Konsole direkt aus n8n heraus aufzurufen ist unschön. Also habe ich einen kleinen Service gebaut, der sie kapselt und als HTTP-Endpunkt bereitstellt. Er ist Open Source auf GitHub.

Vier Entscheidungen darin sind es wert, erwähnt zu werden, weil sie beim Bauen nicht offensichtlich waren:

Er hält keinen Zustand. Die Konsole speichert Gespräche selbst auf Platte. Ein eigener Speicher im Service wäre nicht nur doppelt, er wäre schlechter: Nach einem Neustart wären die Sitzungen weg, obwohl die Gespräche noch existieren. So überlebt eine Unterhaltung den Neustart problemlos.
Der Aufrufer bestimmt, wann ein neues Gespräch beginnt. Du schickst eine ID mit. Gleiche ID heisst weiterreden, neue ID heisst neuer Chat, keine ID heisst Einmalfrage.
Strukturierte Antworten kommen über ein Schema, nicht über eine höfliche Bitte im Prompt. Wer im Prompt um JSON bittet, bekommt es oft in Markdown eingepackt und darf es hinterher auspacken. Mit Schema kommt sauberes JSON zurück, auf das ein Workflow sich verlassen kann.
Er ist mit einem API-Key abgesichert. Solange der Key fehlt und du die Absicherung nicht ausdrücklich abgeschaltet hast, verweigert er den Dienst. Security first: Er läuft erst, wenn du entschieden hast, wie er geschützt sein soll.

Was du dafür brauchst

Einen Service-User mit eigenem Abo. Teste ruhig zuerst mit deinem eigenen Zugang, aber trenne es danach. Das Kontingent hängt am Konto, nicht an der Maschine. Läuft die Automatisierung über deinen Account, frisst sie dir genau das Fenster weg, das du zum Arbeiten brauchst.
Claude Code auf dem Server, installiert und angemeldet, auf dem der Service läuft. Der Service ruft die Konsole auf, mehr passiert da nicht.
Den Service auf dem Server installieren. Ist die Umgebung abgeschottet, brauchst du keine Authentisierung. Soll er übers Internet erreichbar sein, was bei n8n Cloud der Normalfall ist, dann sicherst du ihn ab.

Was du damit sauber automatisieren kannst

Weil du die volle Konsole fernsteuerst und nicht nur ein Sprachmodell anfragst, geht deutlich mehr als Text rein, Text raus:

Den täglichen Blogpost oder Newsletter-Entwurf, angestossen vom Zeitplan statt von dir.
Wiederkehrende Auswertungen, etwa der Wochenrückblick aus deinen eigenen Zahlen.
Dokumente verarbeiten. Du lädst eine Datei hoch, das Modell liest sie als Kontext. Angebote, Rechnungen, Berichte, Protokolle zusammenfassen oder vergleichen.
Strukturiert extrahieren. Aus einem Fliesstext ein festes JSON gewinnen, das der nächste Workflow-Schritt direkt weiterverarbeitet, ohne Nachbearbeitung.
Eingehendes einsortieren, also Kommentare, Anfragen oder Tickets klassifizieren und mit einer Begründung anreichern.
Mehrstufige Arbeit in einem Lauf. Entwurf, dann Kritik am eigenen Entwurf, dann Überarbeitung, alles im selben Gespräch statt in drei kontextlosen Aufrufen.
Aufgaben in Dateien und Repositories, weil die Konsole Werkzeuge mitbringt. Sie kann lesen und, wenn du es erlaubst, auch schreiben.
Eine Wissensbasis pflegen, die über die Läufe hinweg wächst, statt jedes Mal bei null anzufangen.

Wo die Grenze liegt

Das sage ich lieber selbst, bevor es jemand herausfindet. Für hochfrequente Aufrufe ist das nichts. Jeder Aufruf startet einen Prozess und läuft gegen dein Nutzungsfenster. Wenn du im grossen Stil aufrufen willst, brauchst du weiterhin einen API Key, dafür ist das nicht gebaut, und dafür ist der API Key auch nicht zu teuer.

Für alles, was ein paar Mal am Tag läuft, reicht es problemlos. Und genau das sind die Fälle, für die die meisten überhaupt erst einen API Key lösen wollten.

Wenn dein Chatbot lügt, haftest du. Nicht der Anbieter.

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Die meisten behandeln eine falsche KI-Antwort wie einen Ausrutscher. Ein Bug, der mal passiert, den man wegpatcht. Das ist der teure Denkfehler. Ohne Fundament ist die plausible Erfindung nicht die Ausnahme, sie ist der Normalzustand.

Warum ein Modell ohne Grundlage strukturell falsch liegt

Ein Sprachmodell ohne Anbindung an deine Daten beantwortet jede Frage aus seinem Trainingswissen. Dieses Wissen ist komprimiert, hat einen Stichtag und enthält deine Preise, deine AGB und den Beschluss von gestern schlicht nicht. Es kennt deinen Betrieb nicht.

Das Entscheidende: Das Modell hat keinen eingebauten Begriff von "weiss ich nicht". Wo ihm die Grundlage fehlt, schweigt es nicht. Es füllt die Lücke mit dem, was klingt wie eine richtige Antwort. Und es klingt am selbstsichersten genau dort, wo es am wenigsten weiss.

Das ist keine Fehlfunktion, die man wegtrainiert. Das ist die Funktionsweise. Wer einen Bot ohne Anbindung an geprüfte Quellen auf Kunden loslässt, hat keinen hilfreichen Assistenten gebaut, sondern einen sehr eloquenten Ratemann.

Der Fall, den jeder Betreiber kennen sollte

2024 musste sich Air Canada vor einem Tribunal in British Columbia verantworten. Ein Kunde hatte nach einem Todesfall in der Familie beim Chatbot der Airline nach den Regeln für eine vergünstigte Rückerstattung gefragt. Der Bot nannte ihm eine Regel, die es so nicht gab, und stellte eine nachträgliche Erstattung in Aussicht.

Als der Kunde sein Geld wollte, verweigerte Air Canada. Das Argument des Konzerns vor Gericht war bemerkenswert: Der Chatbot sei eine eigenständige Instanz, für deren Auskünfte man nicht hafte.

Das Tribunal wischte das weg. Ein Unternehmen haftet für alle Informationen auf seiner Website, ob sie aus einer statischen Seite kommen oder aus einem Chatbot. Air Canada musste zahlen.

Genau das ist der Punkt. Es gibt keine Rechtsfigur, die deine KI von dir trennt. Der Kunde verklagt nicht das Modell und nicht den Anbieter des Modells. Er verklagt dich.

Wo es richtig teuer wird

Der Air-Canada-Fall ist kein Einzelfall, er ist ein Muster. Am gefährlichsten sind genau die Auskünfte, die verbindlich wirken:

Rückerstattungen und Kulanz. Der Bot verspricht eine Erstattung, die deine Richtlinie nicht deckt. Der Kunde hat den Screenshot. Du zahlst.

Preise und Rabatte. Der Bot nennt einen Preis von vorletztem Jahr oder erfindet einen Mengenrabatt. Im Zweifel ist das ein bindendes Angebot.

Garantie und AGB. Der Bot fasst deine Bedingungen "hilfreich" zusammen und verschiebt dabei eine Frist oder eine Bedingung. Die falsche Zusammenfassung gilt gegenüber dem Kunden.

Regulierte Bereiche. In Versicherung, Kredit oder Gesundheit ist eine falsche Auskunft nicht nur teuer, sondern schnell ein Aufsichtsthema.

Das Grundmuster bleibt immer gleich: Der Bot klingt am überzeugendsten dort, wo er keine Grundlage hat, und produziert die Zusage, die dich bindet.

Was RAG wirklich leistet, und was nicht

Hier ist die ehrliche Abgrenzung, weil an dieser Stelle die meisten übertreiben.

RAG, also die Anbindung des Modells an deine geprüften Quellen, nimmt dir die Haftung nicht ab. Die bleibt beim Betreiber. Immer. Wer RAG als Haftungsschild verkauft, verkauft dir dieselbe Illusion in Neu.

Was RAG tut, ist konkreter und wertvoller: Es senkt die Eintrittswahrscheinlichkeit. Statt aus komprimiertem Trainingswissen zu raten, zieht das Modell die Antwort aus dem Dokument, das du hinterlegt und geprüft hast, und kann die Fundstelle mitliefern. Der häufigste Fehlermodus, die freie Erfindung ins Leere, fällt damit weitgehend weg.

Und es ändert deine Position, falls doch etwas schiefgeht. "Mein Bot hat frei fantasiert" und "mein Bot hat aus einer von mir gewählten, geprüften und protokollierten Quelle geantwortet" sind juristisch zwei verschiedene Welten. Das eine sieht aus wie grobe Fahrlässigkeit. Das andere sieht aus wie Sorgfalt. Wenn du im Streitfall zeigen kannst, woher eine Antwort kam, stehst du grundlegend anders da.

Der eigentliche Reifegrad

Die Frage bei einem produktiven KI-Assistenten ist nicht, ob er irgendwann mal falsch liegt. Er wird. Die Frage ist, ob dieser Fall die Ausnahme ist oder der Normalzustand, und ob du danach erklären kannst, woher die Antwort kam.

Ohne Grundlage ist der Fehler der Normalzustand, und du kannst nichts erklären. Mit einer geprüften Grundlage ist der Fehler die seltene Ausnahme, und du hast eine Spur. Beides bleibt deine Verantwortung. Aber nur eines davon ist ein Standpunkt, den du verteidigen kannst.

Wenn dein Bot mit Kunden spricht

Die Frage ist nicht, ob dein KI-Assistent clever klingt. Sie ist, ob er aus deinen geprüften Quellen antwortet und ob du das im Streitfall belegen kannst.

Verbiete KI ruhig. Deine Leute nutzen sie trotzdem, nur nicht mehr bei dir.

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Es gibt ein Bild, das jede KI-Richtlinie in einem Satz zusammenfasst: das private Handy neben der Firmentastatur.

Auf dem Firmenrechner ist ChatGPT gesperrt. Also tippt die Sachbearbeiterin den Kundenvertrag ab, fotografiert den Absatz, den sie nicht versteht, oder schiebt ihn per Copy-Paste in die App auf dem eigenen Telefon. Zehn Sekunden später hat sie ihre Antwort. Die Firma hat davon nichts gesehen, nichts geloggt, nichts geschützt. Genau das ist Schatten-KI, und sie entsteht nicht trotz des Verbots, sondern wegen ihm.

Was ein Verbot wirklich bewirkt

Ein Verbot verhindert nicht die Nutzung. Es verlegt sie nur dorthin, wo du keine Kontrolle mehr hast.

Der Reflex vieler Unternehmen klingt vernünftig: KI sperren, bis sie sicher ist. Das Ergebnis ist das Gegenteil von Sicherheit. Solange das Tool im Firmenkonto lief, war das Risiko begrenzt und steuerbar. Sobald es auf das Privatgerät wandert, wird aus einem beherrschbaren Restrisiko ein potenzieller Datenabfluss, den niemand mehr einsehen kann.

Und hier kommt der Teil, den die wenigsten Mitarbeiter kennen. Kostenlose Konsumenten-Pläne verwenden Eingaben in aller Regel zum Training der Modelle. Was dort hineingeht, verlässt die Kontrolle des Nutzers. Unternehmenspläne schliessen genau das vertraglich aus: keine Nutzung der Eingaben fürs Training, klare Datenverarbeitung, Nachweisbarkeit. Der Unterschied zwischen beiden ist nicht das Feature. Der Unterschied ist, ob dein Vertragstext morgen in einem Trainingsdatensatz liegt oder nicht.

Das Verbot dreht diesen Hebel in die falsche Richtung. Es drängt die Leute vom geschützten Firmenkonto auf genau die Free-Version, die am meisten mitliest.

Das Problem ist nicht Böswilligkeit, sondern Sorglosigkeit

Kaum jemand tut das aus Trotz. Die meisten Mitarbeiter wissen schlicht nicht, dass ihre Eingabe im Free-Plan zum Trainingsmaterial wird. Sie sehen die Arbeitsersparnis, nicht die Datenspur. Bequemlichkeit schlägt ein Risiko, das man nicht spürt, jedes Mal.

Deshalb ist die Aufgabe des Unternehmens nicht, strenger zu verbieten. Die Aufgabe ist, ein Umfeld zu schaffen, aus dem niemand ausbrechen muss. Wer im Firmennetz ein gutes, schnelles, erlaubtes Werkzeug hat, greift nicht zum Handy daneben. Ausbrüche sind kein Disziplinproblem. Sie sind ein Designproblem.

Der Grat: wer braucht eine Lizenz und wer nicht

Damit beginnt die eigentliche Managemententscheidung, und sie ist unangenehm, weil beide Extreme teuer sind.

Verteilst du Lizenzen mit der Giesskanne, zahlst du für hunderte Konten, von denen ein Teil das Tool zweimal im Monat öffnet. Vergibst du sie zu restriktiv, brechen genau die Leute aus, die KI täglich bräuchten, und tragen deine Daten wieder nach draussen. Der richtige Grad liegt nicht in der Mitte, sondern in der Triage: Welche Rollen arbeiten regelmässig mit Text, Recherche oder Code, und welche nicht? Wer produktiv damit arbeitet, bekommt ein geschütztes Konto, bevor er sich selbst eines besorgt. Das ist keine Kostenfrage, das ist eine Risikoentscheidung, die zufällig auch die Kosten steuert.

Governance heisst: klare Grenzen, mit Begründung

Eine Lizenz allein schützt nichts. Es braucht eine Governance, die zwei Fragen beantwortet: Welche Dokumente dürfen hinein, welche nicht, und warum. Und was passiert, wenn jemand die Grenze trotzdem überschreitet.

Hier lauert eine Falle, die viele übersehen. Ein einzelner Mitarbeiter kann mit einem neuen Anwendungsfall die Risikoeinschätzung der ganzen Firma umwerfen. Wer anfängt, mit KI Bewerbungen vorzusortieren oder Leistungsbeurteilungen zu formulieren, verschiebt den Einsatz aus einer harmlosen Kategorie in einen regulatorisch heiklen Bereich, ganz ohne dass die Geschäftsleitung davon weiss. Die Firma steigt in ihrem realen Risikoprofil auf, während sie glaubt, immer noch im ungefährlichen Feld zu stehen. Ein Flyer mit Do's und Don'ts fängt das nicht ab. Wer nicht versteht, warum eine Grenze existiert, hält sie nicht ein, sobald sie unbequem wird.

Warum der EU AI Act hier ausnahmsweise auf deiner Seite steht

Und genau an diesem Punkt setzt der EU AI Act an, mit einer Pflicht, die man leicht überliest.

Artikel 4 verlangt seit dem 2. Februar 2025, dass Anbieter und Betreiber von KI-Systemen für ein ausreichendes Mass an KI-Kompetenz ihrer Belegschaft sorgen. Nicht nur bei Hochrisiko-Systemen, sondern bei jedem KI-Einsatz. Die Aufsicht dazu greift ab dem 2. August 2026. Das ist kein Bussgeld-Paragraf mit erhobenem Zeigefinger, sondern eine Sorgfaltspflicht. Und über die Marktortwirkung reicht sie bis in Schweizer Unternehmen hinein, sobald deren KI-Ergebnisse in der EU landen.

Das Bemerkenswerte daran: Der Gesetzgeber schreibt genau das vor, was ohnehin im Eigeninteresse jeder Firma liegt. Nicht verbieten, sondern befähigen. Nicht sperren, sondern schulen. Der Regulierer hat hier ausnahmsweise dasselbe Ziel wie dein Risikomanagement.

Der Hebel

Der Hebel gegen Schatten-KI liegt nicht im Verbot. Er liegt im Verständnis. Menschen, die wissen, was geht, was nicht geht und warum, umgehen keine Regel, die sie verstanden haben. Menschen, denen man nur eine Sperre hinstellt, umgehen sie, sobald das Handy in Reichweite liegt.

Ein Verbot verlagert das Risiko nur dorthin, wo du es nicht mehr siehst. Sichtbarkeit bekommst du nicht, indem du die Tür zuschliesst, sondern indem du den besseren Weg durch das Haus baust.

KI erkennen kann jeder. Rechnen offenbar nicht.

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Die Obduktion

Auf LinkedIn hat sich eine neue Freizeitbeschäftigung etabliert: die forensische Textanalyse. Ein Beitrag erscheint, und bevor jemand über den Inhalt nachdenkt, steht im ersten Kommentar der Befund. Zu saubere Absätze. Verdächtig symmetrische Aufzählung. Und natürlich der lange Gedankenstrich, das Brandmal, an dem die Community jede Maschine zu erkennen glaubt.

Eine bequeme Disziplin. Man braucht kein Fachwissen zum Thema, muss nicht widersprechen, nicht argumentieren, nicht einmal zu Ende lesen. Man zweifelt die Herkunft an, und die Sache ist erledigt, ohne je Position bezogen zu haben.

Nebenbei funktioniert das Verfahren nicht. Es bestraft nach oben jeden, der sauber schreiben gelernt hat, und es scheitert nach unten an jedem, der dreissig Sekunden in ein paar Tippfehler investiert. Ein Test, den man durch absichtliche Schlamperei besteht, ist kein Test. Er ist ein Kult.

Aber das ist nicht der interessante Teil. Der interessante Teil ist, dass dieselbe Frage in vielen Firmen gerade mit umgekehrtem Vorzeichen gestellt wird. Dort zählt sie niemand mehr. Dort bezahlt man sie.

Derselbe Denkfehler, andere Richtung

Im Kommentarfeld heisst er: "Das ist doch mit KI gemacht." Abwertung, weil KI drin ist.

In der Firma heisst er: "Wir setzen jetzt KI ein." Aufwertung, weil KI drin ist.

Das ist dieselbe Bewegung. Beide behandeln KI als eine Eigenschaft des Ergebnisses, als eine Art Herkunftsbezeichnung, die man dem Resultat ansieht und aus der man ableiten kann, ob es taugt. Der eine leitet nach unten ab, der andere nach oben. Beide haben das Ergebnis nie angeschaut.

Der Denkfehler ist nicht die Richtung. Der Denkfehler ist, dass KI überhaupt in der Bewertung auftaucht. Denn KI ist kein Ergebnis. KI ist ein Mittel, und Mittel bewertet man ausschliesslich an dem, was sie bewirken.

Erfolg heisst nicht "Wir setzen jetzt KI ein". Erfolg heisst gesparte Stunden und Franken.

Die Ankündigung ist die teuerste Form von Nichts

Der Satz "Wir setzen jetzt KI ein" hat eine bemerkenswerte Eigenschaft: Er lässt sich vollständig erfüllen, ohne dass irgendjemandem irgendetwas leichter wird. Ein Tool ist lizenziert, ein Pilot läuft, eine Folie existiert. Alle Kriterien erfüllt. Der Kalender aller Beteiligten sieht danach exakt aus wie davor, nur mit einem zusätzlichen wöchentlichen Termin zum Thema KI.

Das ist die Managementvariante der Textforensik. Wieder wird über die Herkunft geredet statt über die Wirkung, nur eben stolz statt misstrauisch. Und wieder ist die Debatte deswegen so beliebt, weil sie den unbequemen Teil ersetzt.

Der unbequeme Teil ist immer derselbe: Man muss vorher wissen, was man messen will, und hinterher nachschauen.

Die Frage, die stattdessen zählt

Statt Beiträge zu obduzieren, obduziere deine eigene Woche.

Nimm die letzten fünf Arbeitstage und markiere jede Tätigkeit, die drei Bedingungen erfüllt: Sie hat sich wiederholt. Sie hat Zeit gefressen. Und sie hat dich beim Erledigen kein Stück klüger gemacht.

Was da stehen bleibt, ist deine Kandidatenliste. Nicht das, was in Vorträgen als KI-Anwendungsfall vorkommt, sondern das, was dich tatsächlich Stunden kostet.

Danach sortierst du diese Liste nach drei Kriterien, und nur nach diesen:

Wie oft kommt es vor? Eine Aufgabe, die zwanzig Minuten dauert und täglich anfällt, ist mehr wert als eine, die zwei Tage dauert und einmal im Jahr kommt. Automatisierung verzinst sich über Wiederholung, nicht über Dramatik.

Wie schnell erkennst du einen Fehler? Wenn du das Ergebnis in zehn Sekunden prüfen kannst, ist die Aufgabe geeignet. Wenn ein Fehler erst drei Monate später in einer Bilanz auffällt, ist sie es nicht. Das ist der eigentliche Filter, nicht die Schwierigkeit der Aufgabe.

Was kostet ein Fehler? Ein danebengegangener Entwurf kostet eine Wiederholung. Eine danebengegangene Zusage an einen Kunden kostet den Kunden.

Diese drei Fragen sind nicht spannend. Sie kommen in keinem Impulsvortrag vor. Sie sind aber der ganze Unterschied zwischen einem Piloten, der etwas spart, und einem Piloten, der etwas beweisen sollte.

Was dagegen spricht, und das ehrlich

Zwei Dinge muss man dazusagen, sonst wird daraus wieder eine Heilsbotschaft.

Erstens: Wer einen kaputten Prozess automatisiert, bekommt keinen guten Prozess. Er bekommt einen kaputten Prozess mit höherem Durchsatz. Wenn eine Aufgabe nur existiert, weil vor Jahren jemand ein Formular erfunden hat, ist die richtige Massnahme nicht Automatisierung, sondern Streichung. Das gesparte Ergebnis ist dasselbe, die Kosten sind niedriger.

Zweitens: Es gibt Arbeit, bei der die Mühe der Punkt ist. Denken, entscheiden, verantworten. Wo jemand geradestehen muss, kann er die Prüfung nicht delegieren, und zwar unabhängig davon, wie überzeugend der Entwurf aussieht. Aber das ist keine Aussage über KI. Das war schon immer wahr für jeden, der ungeprüft weitergibt, was ein anderer geschrieben hat.

Der Massstab

Also: Streich die Herkunftsfrage. In beide Richtungen. Sie hat im Kommentarfeld nichts zu suchen und in der Strategiepräsentation erst recht nichts.

Frag stattdessen den Text, was du gelernt hast. Und frag das Projekt, was es gespart hat. In Stunden, in Franken, in Durchlaufzeit. Wenn darauf keine Zahl kommt, war es kein Projekt, sondern eine Ankündigung.

Niemand fragt einen Taschenrechner nach seiner Biografie. Man fragt ihn nach dem Ergebnis.

Deine Produktsuche hat kein Suchproblem. Sie hat ein Wissensproblem.

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Ein Kunde tippt in eure Suche: "robuste Schuhe für nasse Bergtouren, Grösse 44."

Null Treffer.

Dabei habt ihr 800 davon im Lager.

Der beste Schuh dafür heisst bei euch "Meindl Bhutan MFS GTX". Kein einziges Wort aus der Anfrage kommt im Produktnamen vor. Also findet die Suche nichts. Der Kunde geht. Ihr hattet ihn im Lager und habt ihn trotzdem verloren.

In einem guten Fachgeschäft passiert das nie.

Da hört ein erfahrener Verkäufer "nasse Bergtouren" und geht ohne Umweg zum richtigen Regal. Er weiss: nass heisst Membran, nicht nur imprägniert. Er weiss, dass Meindl genau dafür baut. Er weiss, dass zur Bergtour ein knöchelhoher Schnitt und eine griffige Sohle gehören.

Nichts davon steht auf dem Schuhkarton.

Und genau das ist das Problem. Nicht die Suche. Das Wissen.

Mehr KI auf das Problem zu werfen, macht es nicht besser

Der Reflex ist immer derselbe: grösseres KI-Modell, "KI-Suche" über den ganzen Katalog, fertig.

Das war absehbar zum Scheitern verurteilt. Hier ist der ehrliche Grund.

Die klassische Suche vergleicht Wörter. "Nasse Bergtour" trifft im Namen "Meindl Bhutan GTX" exakt null Wörter. Kein Match, kein Treffer.

Die KI-Bedeutungssuche (oft Vektorsuche genannt) klingt nach der Lösung. Sie versteht Bedeutung statt Buchstaben. Nur rät sie Zusammenhänge aus Ähnlichkeit. Und da liegt die Falle.

Für die KI klingen "wasserdicht" und "wasserabweisend" fast gleich. Die beiden Begriffe liegen für sie direkt nebeneinander. Genau der Unterschied, an dem im Regen trockene Füsse hängen, verschwimmt der KI zu einem Brei.

Und das Grundproblem bleibt: Die KI kann nicht wissen, was nie jemand aufgeschrieben hat. Das Wissen des Verkäufers stand in keinen Daten.

KI beantwortet die Frage "welcher Text sieht ähnlich aus". Sie beantwortet nicht die Frage "wie hängt das zusammen".

Die fehlende Schicht: das Wissen des Verkäufers, aufgeschrieben

Der Schritt, den fast alle überspringen: das Wissen über die Produkte als eigene Schicht bauen. Getrennt vom Katalog.

Nicht "was kostet dieser Schuh und ist er auf Lager" (das ist der Katalog). Sondern "was bedeutet wasserdicht, wozu gehört eine Bergtour, welche Marke steht wofür" (das ist das Wissen).

Dafür gibt es seit Kurzem ein offenes Format von Google: das Open Knowledge Format, kurz OKF (Juni 2026). Kein Produkt, keine Plattform, kein Abo. Im Kern ist es nur eines: ein Ordner mit einfachen Textdateien.

Eine Datei ist ein Konzept. "Wasserdicht" ist eine Datei. "Wanderschuh" ist eine Datei. "Meindl" ist eine Datei. Und die Dateien verweisen aufeinander. Diese Verweise sind das Wissensnetz (der Knowledge Graph).

So sieht so ein Baustein aus, stark vereinfacht:

Baustein: WASSERDICHT
Bedeutung: Membran hält Wasser komplett ab.
            Das ist NICHT dasselbe wie wasserabweisend.
Gehört zu: Membran, Nasswetter
Verweist: → wasserabweisend (nur Imprägnierung, keine Membran)
            → Meindl, GORE-TEX, SympaTex

Drei Dinge arbeiten hier zusammen, und erst zusammen ergeben sie die extrem guten Ergebnisse:

Das Format (OKF) hält das Wissen fest, in lesbaren Dateien, die jeder Mensch und jede Maschine versteht.
Das Wissensnetz (Knowledge Graph) verbindet die Bausteine. "Nasse Bergtour" führt über "Wanderschuh" zu "wasserdicht" zu "Membran" zu den passenden Marken. Genau die Gedankenkette des Verkäufers.
Die Bedeutungssuche (Vektorsuche) findet den Einstieg. Sie erkennt, dass "nasse Bergtour" beim Baustein "Wanderschuh" und "wasserdicht" landet, auch wenn der Kunde diese Wörter nie tippt.

Der entscheidende Schnitt: zwei Schichten, nicht eine

Hier machen es die meisten falsch. Sie kippen alle drei Millionen Artikel in die KI und hoffen.

Trennt stattdessen sauber:

Die Katalog-Schicht: drei Millionen Artikel. Ändert sich stündlich (Preis, Bestand). Läuft maschinell. Das ist das Lager voller Schuhe.
Die Wissens-Schicht: rund 5000 gepflegte Bausteine. Stabil. Von Menschen geprüft. Das ist das Hirn des erfahrenen Verkäufers.

5000 Bausteine sind eine Grösse, die ein Team wirklich betreuen kann. Drei Millionen sind es nicht.

Wie die Suche dann läuft

Die Reihenfolge wird umgedreht. Nicht zuerst durch drei Millionen Artikel wühlen, sondern:

Zuerst fragt das System die Wissens-Schicht: Was will dieser Kunde überhaupt? Antwort: Wanderschuh, wasserdicht. Diese Frage läuft gegen 5000 Bausteine, nicht gegen drei Millionen Artikel.

Dann folgt es den Verweisen im Wissensnetz: wasserdicht führt zu Membran, Bergtour führt zur Grössentabelle, dazu die passenden Marken. Die Assoziationen des Verkäufers, in Sekundenbruchteilen.

Daraus leitet das System harte Filter ab: Kategorie Wanderschuh, wasserdicht ja, Grösse 44, auf Lager. Allein das schrumpft drei Millionen Artikel auf einige Zehntausend.

Erst jetzt läuft die teure Bedeutungssuche, aber nur noch auf diesem kleinen Rest.

Zum Schluss die Feinsortierung: Relevanz plus eure Geschäftsregeln (Marge, Verfügbarkeit).

Und wenn die Wissens-Schicht einmal ausfällt, fällt das System auf die normale Suche zurück. Langsamer, aber nie eine leere Ergebnisseite. (Die genannten Grössenverhältnisse sind Grössenordnungen aus der Architektur, keine gemessenen Benchmarks.)

Die Wissens-Schicht ist kein zusätzlicher Umweg. Sie ist ein Präzisions-Verstärker: Sie kostet ein bisschen und spart sehr viel, weil die teure KI-Suche nur noch einen winzigen Bruchteil durchsehen muss.

Der Betriebsvorteil, über den keiner redet

Drei Dinge, die im Alltag den Unterschied machen.

Preis und Bestand ändern sich stündlich. Die gehen direkt in den Katalog, die KI muss dafür nichts neu einlesen.

Das Wissen ändert sich vielleicht wöchentlich. Ändert jemand einen Baustein, wird nur dieser eine neu verarbeitet. Sekunden statt Stunden.

Und der eigentliche Knaller: Wenn jemand festlegt "wasserdicht heisst Membran, nicht nur Imprägnierung", ist das eine dokumentierte, geprüfte, rückgängig machbare Änderung. Mit Verlauf. Mit Freigabe. Wie eine saubere Software-Änderung.

Vergleicht das mit dem heutigen Zustand: ein anonymer Eintrag in einer Synonymliste, den vor 18 Monaten jemand gemacht hat, der nicht mehr in der Firma ist, und niemand traut sich, ihn anzufassen.

Gewöhnliches RAG gegen OKF plus Wissensnetz plus Bedeutungssuche

Kurz zur Einordnung: "RAG" ist der übliche Weg, einer KI Zugriff auf eure Daten zu geben. Man kippt die Inhalte in eine Bedeutungssuche und lässt die KI das Ähnlichste heraussuchen. Das ist der Standard. Und hier ist, wo er gegen den beschriebenen Ansatz verliert.

"Aber wer pflegt 5000 Dateien?" Niemand. Die KI erzeugt sie.

Der berechtigte Einwand: 5000 Dateien von Hand schreiben, das schafft kein Team.

Stimmt. Und das soll auch niemand. Das wäre so absurd, als müsste der erfahrene Verkäufer vor seinem ersten Arbeitstag eigenhändig ein Lexikon schreiben.

Das Rohmaterial habt ihr längst. Die KI baut den Erstentwurf. Menschen geben frei, worauf es ankommt.

Die Daten, die ihr schon habt (und in denen das Wissen versteckt liegt):

Euer Kategoriebaum und eure Attribute. Das ist das Skelett, schon strukturiert. "Wanderschuh" und "wasserdicht" existieren bei euch längst als Filter.
Eure Produktdaten und Herstellerangaben. Die GORE-TEX-Angabe von Meindl sagt euch schwarz auf weiss, dass es eine Membran ist.
Eure Bewertungen und Retouren. Kunden schreiben wörtlich "dachte, der wäre wasserdicht, Füsse waren nass". Das ist die Verwechslung wasserdicht gegen wasserabweisend, dokumentiert von euren eigenen Kunden.
Eure Suchprotokolle, vor allem die Suchen mit null Treffern. Das ist das Gold. Jede erfolglose Suche nach "robuste Schuhe für nasse Bergtouren" ist ein fehlender Baustein, benannt in den Worten des Kunden.
Eure vorhandenen Kaufberatungen und Ratgebertexte.
Und ja, die alten Synonymlisten. Die werden zu sauberen Bausteinen.

Wie die Daten aufbereitet werden müssen:

Vereinheitlichen: "wasserdicht", "wdicht", "GORE-TEX", "waterproof" zeigen auf einen Baustein, nicht auf vier.
Entdoppeln und den Kategoriebaum sauber ziehen.
Den Katalog nach Mustern gruppieren, damit die natürlichen Konzepte sichtbar werden.

Wie die Architektur aussieht (eine KI-Veredelungs-Strecke):

Die KI liest alle Quellen und schreibt Erstentwürfe der Bausteine: die Beschreibungen, und sie schlägt die kritischen Unterscheidungen vor ("wasserdicht ist nicht wasserabweisend"), markiert zur Prüfung.
Die KI schlägt die Verweise zwischen den Bausteinen vor. Das ist das Wissensnetz, automatisch gesponnen.
Jeder Schwung kommt als Vorschlag zur Freigabe, wie eine Änderung, die jemand absegnet. Eine Fachperson prüft und gibt frei. Nicht schreibt. Prüft.
Und dann läuft es weiter. Jede neue Null-Treffer-Suche wird zum Kandidaten für einen neuen Baustein. Das System sagt euch selbst, welches Wissen ihm noch fehlt.

Die Aufteilung ist der ganze Trick. Die KI macht die 90 Prozent (entwerfen, verknüpfen, gruppieren, die Protokolle auswerten). Der Mensch macht die 10 Prozent, die wirklich Urteilskraft brauchen (ist wasserdicht für unsere Bergkunden wirklich etwas anderes als wasserabweisend? Ja). Genau diese 10 Prozent sind euer Vorsprung, den kein Wettbewerber einfach kopiert.

Ihr schreibt kein Lexikon. Ihr gebt eines frei, das eure eigenen Daten längst geschrieben haben.

Ein Aufbau, mehrfacher Nutzen

Das Schönste kommt zum Schluss. Diese Wissens-Schicht arbeitet nicht nur für die Suche.

Derselbe geprüfte Wissensbestand erdet auch euren Chatbot, damit er aufhört, Unsinn zu erfinden, und stattdessen aus eurem echten Wissen antwortet. Er speist die Kaufberatung. Er trägt die Produktempfehlung.

Ihr baut das Hirn eures besten Verkäufers einmal. Danach arbeitet es überall, wo ein Kunde eine Frage hat.

Die ehrliche Einschränkung

Damit das hier Analyse bleibt und nicht Werbung:

Die Wissens-Schicht ist Arbeit, die am Anfang anfällt. Gibt niemand die Bausteine frei, habt ihr einen leeren Ordner und ein ganz normales KI-Setup. Die Arbeit verschwindet nicht, sie wandert nur dahin, wo sie hingehört: zu euren Fachleuten.

Das Format ist jung (Version 0.1, noch Entwurf). Ein paar Dinge sind bewusst offen.

Und der wichtigste Punkt: Die KI entwirft, aber die Entscheidung "wasserdicht ist für unsere Kunden etwas anderes als wasserabweisend" ist eine Geschäftsentscheidung, keine Rechenaufgabe. Das ist keine Schwäche. Das ist der Grund, warum es funktioniert.

Die eigentliche Frage

Die Frage ist nicht, ob euer KI-Modell gross genug ist.

Die Frage ist, ob jemals irgendwer aufgeschrieben hat, was euer Modell wissen müsste.

Euer bester Verkäufer wusste es. Er hat es nur nie aufgeschrieben. Jetzt könnt ihr es.

Eine Frage zum Schluss, weil sie fast überall den wunden Punkt trifft: Wer pflegt bei euch eigentlich die Synonymliste, und weiss diese Person, dass sie damit euer Ranking steuert?

Wer Outsourcing nicht hinbekommen hat, bekommt auch KI nicht hin

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Es gibt ein Muster, das sich gerade wiederholt. Nur schneller und günstiger.

Die Firmen, die früher schon am Outsourcing gescheitert sind, scheitern heute an der KI. Der Grund ist in beiden Fällen identisch, und er hat nichts mit Technologie zu tun: Anforderungen werden nicht klar kommuniziert.

Wer früher "mach mir mal eine Oberfläche" an ein Offshore-Team geschickt und dafür Murks zurückbekommen hat, bekommt genau diesen Murks heute von der KI. In Sekunden statt in Wochen, zu einem Bruchteil der Kosten. Aber besser wird es dadurch nicht.

Murks bleibt Murks

Ohne Spezifikation der Prozesse, ohne dass sich vorher jemand ernsthaft über Abläufe, Datenhaltung und Business-Objekte Gedanken gemacht hat, bleibt jedes Projekt an der Oberfläche stecken. Die KI ändert daran nichts. Sie nimmt dir das Nachdenken nicht ab, sie beschleunigt nur das, was du ihr vorgibst. Gibst du ihr Unklarheit, bekommst du sehr effizient produzierte Unklarheit zurück.

Die Kehrseite ist genauso wahr: Wenn Outsourcing in einem Unternehmen bereits sauber funktioniert, dann sind mit hoher Wahrscheinlichkeit exakt die Voraussetzungen da, um auch mit KI vernünftig zu arbeiten. Klare Anforderungen, definierte Prozesse, jemand der weiss, was er eigentlich will. Diese Firmen steigern ihre Effizienz gerade drastisch. Die anderen produzieren schnelleren Murks.

Die Wertschöpfung war nie das Tippen

Hier liegt der Denkfehler, den viele gerade machen. Die Wertschöpfung in der Softwareentwicklung war nie das Tippen und Implementieren von Code.

Kluge Firmen haben sich das Preisgefälle zu anderen Regionen längst zunutze gemacht. COVID hat das noch einmal massiv verstärkt. Denn wenn das Entwicklerteam ohnehin nur noch remote arbeiten will, warum soll es dann in der Schweiz sitzen? Das kostet nur mehr Geld und ergibt keinen Sinn. Das Gegenargument kenne ich: "Wir sind dafür effizienter." Ich habe das in mehreren Projekten widerlegt. Es lässt sich getrost ins Land der Mythen und Legenden verbannen.

Das ideale Setup 2026: Downsizing statt Armada

Wie sieht dann das ideale Setup aus? Das Stichwort heisst Downsizing. Es braucht nicht mehr die Armada von Entwicklern. Es braucht Leute, die mitdenken und die kommunizieren können.

Ich mache das nicht an Rollen oder an Seniorität fest, sondern am Mindset. Ein kleines Team aus Leuten, die verstehen, was das Business braucht, und es präzise formulieren können, schlägt heute jede grosse Mannschaft, die nur Tickets abarbeitet.

Der Hebel ist dabei grösser, als die reine Kostenrechnung vermuten lässt. Kommunikation wird mit jeder zusätzlichen Person teurer, und zwar überproportional. Jede neue Schnittstelle, jedes zusätzliche Abstimmungsmeeting, jedes Missverständnis zwischen Beteiligten frisst Zeit und erzeugt Reibung. Wenige Leute, die jeweils mehr abdecken, reden schneller und präziser miteinander als eine grosse Gruppe, die sich ständig gegenseitig erklären muss, was eigentlich gemeint war. Downsizing senkt also nicht nur die Kosten, es macht die Kommunikation selbst effizienter.

Wie sieht dieser Kopf konkret aus? Für mich ist das ideale Teammitglied 2026 ein Requirements Engineer mit echtem Architekturverständnis. Jemand, der mit dem Business spricht und dessen Bedürfnisse in saubere Anforderungen übersetzt, und der zugleich weiss, wie sich diese Anforderungen technisch tragfähig strukturieren lassen. Genau diese Person schliesst die Lücke, an der die meisten Projekte scheitern: die Übersetzung zwischen dem, was das Business will, und dem, was das System können muss. Das Tippen übernimmt heute zu grossen Teilen die KI. Das Verständnis dafür, was gebaut werden soll und wie alles zusammenhängt, übernimmt sie nicht.

Fixpreis ist zurück. Storypoints sind es nicht.

Das alte Scrum-Debakel "es dauert so lange wie es dauert" ist endgültig vom Tisch.

Fixpreisprojekte kommen zurück. Die Dienstleister, die das Spiel verstanden haben, merken es selbst: Stundenbasierte Abrechnung ergibt bei extremer Effizienz keinen Sinn mehr. Und die Kunden profitieren von Planbarkeit statt von offenen Rechnungen.

Wenn dir heute jemand im Team noch keine sauberen Schätzungen liefert und sich stattdessen hinter diffusen Storypoints versteckt, dann hast du einen Streichkandidaten gefunden. Direkt neben dem Agile Coach, der sich seit Jahren ohne messbare Wirkung eine goldene Nase verdient.

Worum es eigentlich geht

KI ist kein Ersatz für Klarheit. Sie ist ein Verstärker. Sie macht gute Organisationen dramatisch schneller, und bei schlechten legt sie gnadenlos offen, dass nie jemand genau wusste, was eigentlich gebaut werden sollte.

Die Frage für 2026 ist deshalb nicht "welches Tool?". Die Frage ist: Habt ihr die Leute, die sagen können, was ihr wollt?

Wenn Claude Code viele Tokens verbrennt, liegt das nicht an Claude. Es liegt an deiner Nachlässigkeit.

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Unangenehme Wahrheit: Viele Teams jammern über KI-Kosten, aber füttern Claude Code, Codex und Co. jeden Tag mit ihrem organisatorischen Chaos.

Das Problem ist meistens nicht das Modell. Das Problem ist fehlendes Knowledge Management.

Wer regelmässig mit KI arbeitet, weiss: Kosten entstehen nicht durch Magie. Sie entstehen durch Tokens. Und Tokens entstehen durch Kontext.

Je mehr Chatverlauf, Dateien, Tool-Ausgaben, Logs und Wiederholungen Claude verarbeiten muss, desto teurer und langsamer wird die Arbeit.

Und genau hier beginnt das eigentliche Problem.

Viele Entwickler arbeiten an Aufgaben, die aufeinander aufbauen. Also bleibt man im gleichen Chat, weil man denkt:

„Wenn ich einen neuen Chat anfange, muss ich Claude ja wieder bei Adam und Eva abholen.“

Ja. Stimmt.

Aber wenn das wirklich nötig ist, hast du ein anderes Problem.

Dann steckt dein Projektwissen im Chatverlauf. Nicht im Code. Nicht in der Dokumentation. Nicht im Repository. Nicht im Team.

Sondern in einem temporären KI-Dialog.

Das ist kein professionelles Setup. Das ist digitales Bauchgefühl mit Token-Flatrate.

Stell dir eine einfache Frage:

Könnte ein Kollege deinen Task morgen übernehmen, ohne deinen Claude-Chat gelesen zu haben?

Wenn die Antwort nein ist, hast du kein KI-Problem. Du hast ein Knowledge-Management-Problem.

Und genau hier trennt sich Vibe-Coding von professioneller Softwareentwicklung.

Viele Teams haben punktuelle Lösungen. Ein README hier. Ein Confluence-Artikel dort. Ein paar Notizen in Slack. Vielleicht eine lokale Markdown-Datei auf dem Rechner eines Entwicklers.

Aber keine durchgängige, teamweite Strategie.

Das reicht nicht.

Der bessere Ansatz ist einfach:

Nach relevanten Aufgaben müssen die wichtigen Erkenntnisse zurück ins Projekt.

Nicht jeder Gedanke. Nicht jeder Prompt. Nicht jeder Zwischenschritt.

Aber alles, was für die nächste Aufgabe wichtig ist.

Zum Beispiel:

Architekturentscheidungen
technische Einschränkungen
API- und Datenmodell-Entscheidungen
bekannte Workarounds
Setup- und Deployment-Hinweise
offene Risiken
Folgeaufgaben
Dinge, die ein neuer Entwickler wissen muss
Besonderheiten, die Claude beim nächsten Task kennen sollte

Und jetzt kommt der entscheidende Punkt:

Diese Informationen gehören nicht nur in deinen Chatverlauf. Und auch nicht nur auf deinen lokalen Rechner.

Sie gehören ins Repository.

Als Markdown. Versioniert. Reviewbar. Teil des Projekts.

Zum Beispiel als:

CLAUDE.md
AGENTS.md
Architecture Decision Records
docs/architecture/
docs/ai-context/
projektspezifische Implementation Notes

Damit wird Wissen nicht mehr in langen Chats versteckt, sondern zu einem echten Asset des Teams.

Das hat mehrere Effekte:

Jeder im Team kann Aufgaben leichter übernehmen.
Neue Chats können mit deutlich weniger Kontext gestartet werden.
Claude Code und Codex müssen nicht jedes Mal alles neu rekonstruieren.
Entscheidungen bleiben nachvollziehbar.
Architekturwissen bleibt im Projekt statt im Kopf einzelner Entwickler.
Das Kontextfenster bleibt kleiner.
Kosten und Laufzeiten sinken.
Die Qualität der KI-Ergebnisse steigt.

Natürlich ist das kein Freipass für Dokumentationsmüll.

Eine KI-generierte Knowledgebase darf kein unkontrollierter Dump sein. Sie muss kuratiert werden. Sie muss aktuell bleiben. Sie muss reviewed werden.

Und natürlich gehören keine Secrets, Zugangsdaten, personenbezogenen Daten oder sensiblen Interna unbedacht in solche Dateien.

Aber das Prinzip bleibt:

Wenn Claude etwas über eure Implementierung gelernt hat, das für spätere Arbeit relevant ist, dann darf dieses Wissen nicht im Chat sterben.

Es muss zurück ins Projekt.

Die einfache Regel lautet:

Alles, was ein Kollege für den nächsten Task wissen müsste, gehört nicht nur in den Chat, sondern ins Repository.

Das ist kein Overhead. Das ist Engineering Hygiene.

Und ja: Genau dadurch werden KI-Workflows günstiger.

Nicht weil Claude plötzlich weniger intelligent sein muss. Sondern weil du aufhörst, ihm jeden Tag denselben Kontext neu zu erklären.

KI-Kosten sind oft kein Tool-Problem. Sie sind ein Symptom für schlechte Projektorganisation.

Provokante Frage zum Schluss:

Wenn morgen ein neuer Entwickler in dein Projekt kommt: Findet er das relevante Wissen im Repository?

Oder müsste er erst deinen Claude-Chat lesen?

Automatisierung, die sich rechnet: Warum n8n vom Freelancer bis zum Konzern gewinnt

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Eine ehrliche Tool-Entscheidung, und warum Self-Hosting fast immer die bessere Wahl ist.

Gerade dreht sich jede zweite Diskussion um KI-Agenten, die bald alles von allein erledigen. Die unspektakuläre Wahrheit: Den grössten und schnellsten Nutzen holen Firmen aktuell nicht aus autonomen Agenten, sondern aus solider, planbarer Workflow-Automatisierung. Und genau dort liegt für kleine Firmen und Freelancer der grösste Hebel.

Social-Media-Kanäle automatisch bespielen, Newsletter ohne Handarbeit versenden, Produktvideos generieren, Leads qualifizieren, Angebote vorbereiten: Das ist keine Zukunftsmusik, das läuft heute. Wer als kleines Team jede dieser Aufgaben von Hand macht, verschenkt Zeit, die er nicht hat. Für grosse Firmen ist Automatisierung ein Effizienzthema. Für kleine ist sie ein Wettbewerbsvorteil.

Bleibt die Frage nach dem Werkzeug. Vier Namen tauchen immer wieder auf.

Vier Werkzeuge im Vergleich

Zapier ist der schnellste Weg zu einer simplen Verknüpfung und hat den grössten App-Katalog. Make ist visuell stark und kommt mit komplexen Abläufen gut zurecht. Power Automate ist die naheliegende Wahl, wenn das halbe Unternehmen ohnehin in Microsoft 365 lebt. Alle drei haben eines gemeinsam: Du mietest dich in eine fremde Cloud ein und zahlst pro Ausführung.

Warum n8n für mich klar gewinnt

Zwei Gründe geben den Ausschlag.

Erstens: Kostenkontrolle. n8n läuft als Community Edition kostenlos auf deinem eigenen Server. Du kannst es auch gehostet bei n8n beziehen, aber der eigentliche Hebel ist, dass die Software selbst nichts kostet und deine Daten dein Haus nicht verlassen.

Zweitens: Low-Code statt No-Code. Solange die Standard-Bausteine reichen, klickst du deinen Workflow visuell zusammen. Sobald es anspruchsvoller wird, schreibst du eigenen Code direkt im Workflow. Bei Zapier und Power Automate stösst du irgendwann an eine künstliche Decke. Bei n8n nicht.

Warum Self-Hosting fast immer die bessere Wahl ist

Die Zahl der Workflow-Ausführungen ist bei den Cloud-Tarifen gedeckelt. Wer darüber kommt, zahlt schnell deutlich mehr. Und das Tückische daran: Bis du an diese Grenze stösst, hast du deine Prozesse längst auf der Plattform gebaut. Ein Wechsel kostet dann Zeit und Nerven. Du bist im Lock-in, genau dann, wenn es teuer wird.

Deshalb meine Empfehlung: von Anfang an selbst hosten. Du drehst die Logik um. Statt mit jeder neuen Automatisierung abhängiger und teurer zu werden, zahlst du einen festen, kleinen Betrag und baust, so viel du willst.

Der einfachste Weg zur eigenen n8n-Instanz

VPS bestellen. Ein kleiner Server bei Hostinger oder Contabo kostet unter 10 Euro im Monat. Ubuntu LTS als Basis reicht völlig.
n8n per npm installieren, bewusst ohne Docker-Overhead: npm install -g n8n. Davor einmal Node.js LTS einrichten.
Prozess-Monitoring mit PM2. PM2 hält n8n am Leben, startet es nach einem Absturz und nach jedem Reboot neu: pm2 start n8n, danach pm2 startup.
Nginx als Reverse Proxy davor, mit HTTPS über Let's Encrypt. So läuft n8n unter deiner eigenen Domain und verschlüsselt.
Update-Script als Cronjob. Ein Zweizeiler (npm update -g n8n && pm2 restart n8n), wöchentlich per Cron, hält die Instanz aktuell.

Ergebnis: Full Service ohne manuelle Eingriffe. (Hinweis: Standardmässig nutzt n8n SQLite. Sobald viele Workflows parallel laufen, stellst du auf PostgreSQL um.)

Und für Enterprise?

Dasselbe Prinzip skaliert nach oben. Für High-End-Umgebungen mit hoher Last und Ausfallsicherheit läuft n8n auf Kubernetes in Azure oder AWS, mit mehreren Worker-Knoten und horizontaler Skalierung. n8n dokumentiert beide Wege sauber:

Genau das ist die Stärke: Dasselbe Werkzeug trägt dich vom ersten Freelancer-Workflow bis zur konzernweiten Plattform. Du musst die Technologie nie wechseln, nur die Betriebsform.

Und wozu das alles, wenn KI bald alles macht?

Damit zurück zum Anfang. Wenn KI-Agenten bald alles erledigen, wozu dann noch Workflows?

Weil ein Agent interpretiert und ein Workflow garantiert. Für alles, was verlässlich, wiederholbar und nachvollziehbar laufen muss, willst du deterministische Ausführung, keine kreative Auslegung. Du willst wissen, was dein System um drei Uhr nachts tut, und du willst die Kosten im Griff behalten. KI gehört in diese Workflows hinein, genau dort, wo Sprache verstanden oder Inhalt erzeugt werden muss. Aber sie ist ein Baustein, nicht das Fundament.

Nicht KI statt Automatisierung. KI im Rahmen einer verlässlichen Automatisierung.

Wie ich Claude Code beigebracht habe, Bilder zu generieren

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Eine Schritt-für-Schritt-Anleitung: Vom ChatGPT-API-Key über die Absicherung bis zum ersten Bild direkt aus dem Claude Code Chat.

Jedes Titelbild unter meinen letzten Artikeln ist mit einem einzigen Befehl entstanden: /generate-image. Kein Designer, kein Stockfoto, kein Wechsel in den Browser. Ich tippe einen Prompt, und Sekunden später liegt ein fertiges PNG im richtigen Ordner und im Chat.

Das Schöne daran: Es ist kein Produkt, das man kauft, sondern ein Handgriff, den man sich selbst beibringt. Claude Code lässt sich über sogenannte Skills erweitern, kleine Bausteine, die dem Editor eine neue Fähigkeit geben. Hier ist es: eine fremde API bedienen, konkret den Bildgenerator von OpenAI. Wer den Weg einmal kennt, bindet danach fast jede API auf dieselbe Art an.

Hier ist die ganze Anleitung, von null. Plane zwanzig Minuten ein. Wie du die fertige Zip-Datei bekommst, steht am Schluss.

Was du am Ende hast

Einen Befehl /generate-image "dein prompt" direkt im Chat.
Flags für Quer-, Hoch- und Quadratformat.
Das Bild landet automatisch als PNG auf der Platte und erscheint im Chat.
Den OpenAI-Key sicher verstaut, mit einem Budget, das dich vor bösen Überraschungen schützt.

Voraussetzungen

Claude Code (CLI, Desktop oder IDE-Erweiterung).
Windows mit PowerShell (5.1 oder 7). Auf Mac oder Linux funktioniert dasselbe, dann portierst du das Script nach bash.
Eine Zahlungsart für den OpenAI-API-Account.

Wichtig vorab: ChatGPT ist nicht die API

Der häufigste Stolperstein zuerst. Dein ChatGPT-Abo auf chat.openai.com und die OpenAI-Plattform-API sind zwei getrennte Produkte mit getrennter Abrechnung. Das Abo zahlt keine API-Aufrufe. Für die Bildgenerierung brauchst du einen API-Account auf platform.openai.com mit eigener Zahlungsart oder Prepaid-Guthaben. Den Schlüssel nennen alle "ChatGPT-API-Key", korrekt heisst er OpenAI-API-Key.

Teil 1: Den OpenAI-API-Key anlegen

Geh auf platform.openai.com und melde dich an oder registriere dich. Bei neuer Registrierung verlangt OpenAI eine E-Mail-Bestätigung und eine Handynummer zur SMS-Verifizierung, das ist die Missbrauchssperre.
Hinterlege eine Zahlung: Settings, dann Billing, dann Add payment method. Ohne Guthaben oder Karte gibt die API nichts heraus. Wer das Risiko von Natur aus begrenzen will, kauft ein Prepaid-Guthaben statt nachträglicher Abrechnung.
Lege ein eigenes Projekt an (empfohlen), zum Beispiel "claude-code-images". Ein eigenes Projekt bedeutet eigenes Budget, eigene Schlüssel, saubere Trennung. Das spart später Ärger.
Öffne im linken Menü API keys (oder direkt platform.openai.com/api-keys) und klick Create new secret key. Gib ihm einen sprechenden Namen, etwa "claude-code", und häng ihn an dein Projekt.
Kopiere den Schlüssel sofort. Er beginnt mit sk- und wird nur ein einziges Mal vollständig angezeigt. Schliesst du den Dialog, siehst du nur noch die letzten vier Zeichen. Verlierst du ihn, widerrufst du ihn und legst einen neuen an, kein Drama.
Setz ein hartes Limit: Settings, dann Limits, und trag eine monatliche Obergrenze plus eine Benachrichtigungsschwelle ein. Das ist dein Sicherheitsnetz.

Eine Notiz zu den Kosten, damit du nicht im Dunkeln tappst: gpt-image-2 rechnet nach Bildgrösse und Qualität ab. Ein Titelbild kostet dich einstellige Centbeträge (Stand 2026, prüfe die aktuelle Preisseite). Das gesetzte Monatslimit deckelt alles Weitere.

Teil 2: Den Key absichern

Der Schlüssel ist ein Bearer-Token. Wer ihn hat, kann auf deine Rechnung Anfragen stellen. Behandle ihn wie eine Kreditkartennummer.

Die goldene Regel: Der Key gehört nie in den Code, nie in den Prompt, nie in ein Git-Repo. Er gehört in eine Umgebungsvariable. Unter Windows, dauerhaft, in einer Zeile:

setx OPENAI_API_KEY "sk-dein-key"

Kurz-Checkliste:

Dedizierter, projektgebundener Key, nicht dein Allzweck-Schlüssel.
Hartes Monatsbudget im Dashboard, das ist dein Schadensradius bei einem Leck.
Bei Verdacht im Dashboard widerrufen (ein Klick) und neu erzeugen, kostet nichts.
Nie loggen, nie in einen Screenshot, nie in einen Chat kopieren.

Teil 3: Die Skill installieren

Eine Skill in Claude Code ist ein kleiner Ordner mit zwei Dateien: SKILL.md (sagt Claude, wann der Befehl reagiert und was er tut) und generate-image.ps1 (schickt den Prompt an OpenAI und speichert das PNG). Installiert wird sie direkt in der Oberfläche, ohne Build und ohne Dateien von Hand zu verschieben:

Hol dir die Zip-Datei.
Öffne in Claude Code die Ansicht Customize, dann Skills.
Klick oben in der Spalte Skills auf das Plus, dann auf Create skill, dann auf Upload a skill.
Wähle die Zip-Datei aus. Die Skill erscheint danach unter Personal skills.
Tippe /generate-image, und du bist startklar.

Zip rein, fertig. Kein Paketmanager, kein Neustart.

Teil 4: Der erste Aufruf

Tipp im Editor:

/generate-image eine goldene Waage in einem dunklen Raum, kinoreif, Bernsteinlicht

Standard ist Querformat. Mit Flags steuerst du das Seitenverhältnis:

--portrait für Hochformat
--square für Quadrat
ohne Flag Querformat

Das Bild landet als image-zeitstempel.png in deinem Ordner generated-images und erscheint direkt im Chat. Fertig.

Teil 5: Wenn es klemmt

"OPENAI_API_KEY is not set": Variable setzen und ein neues Terminal öffnen. Die häufigste Ursache.
"OpenAI request failed": Das Script gibt die Originalmeldung von OpenAI aus. Meist ist es fehlendes Guthaben, ein abgelaufener Key oder die Inhaltsrichtlinie. Ursache beheben, nicht blind wiederholen.
Schräge Seitenverhältnisse: gpt-image-2 kann nur drei Grössen, 1024x1024, 1536x1024 und 1024x1536. Für ein LinkedIn-Cover (1.91 zu 1) nimmst du Querformat und schneidest nach.

Wie die Skill unter der Haube funktioniert

Der Reiz liegt darin, wie wenig dahintersteckt. Die SKILL.md ist reiner Text: Sie beschreibt den Auslöser (/generate-image), die Flags und die Schritte, die Claude abarbeiten soll. Claude liest das wie eine Arbeitsanweisung.

Das Script ist keine hundert Zeilen. Es liest den Key aus der Umgebungsvariable, packt deinen Prompt in eine JSON-Anfrage, schickt sie an einen einzigen OpenAI-Endpunkt, nimmt das zurückgelieferte Bild entgegen und schreibt es als PNG auf die Platte. Den Key fasst es nur an einer einzigen Stelle an, im Authorization-Header, und gibt ihn nie aus.

Und genau das ist die Lektion, die über Bilder hinausgeht: Eine Skill ist eine Brücke zwischen deinem Editor und einer beliebigen API. Heute ist es der Bildgenerator. Mit demselben Muster bindest du morgen einen Wetterdienst, deine eigene Datenbank oder ein internes Werkzeug an. Der Editor hört auf, nur ein Texteditor zu sein, und wird zur Schaltzentrale.

Schluss

Vor einem Jahr hätte dieser Ablauf ein kleines Projekt gebraucht, ein SDK, etwas Boilerplate, einen Nachmittag. Heute sind es zwei Dateien und zwanzig Minuten, und der teuerste Teil ist nicht der Code, sondern die Disziplin beim Umgang mit dem Schlüssel.

Die fertige Zip-Datei (SKILL.md, Script und ein README mit der kompletten Key-Absicherung) kannst du hier herunterladen.

Zwei Billionen Dollar sind verdampft, weil die KI funktioniert hat. Eine Seziertabelle für SaaS.

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Nicht "SaaS" stirbt, sondern ein Preismodell. Und ob es dich trifft, entscheidet eine einzige Frage: Wofür bezahlt der Sitzplatz eigentlich?

In rund dreissig Tagen sind etwa zwei Billionen Dollar Marktwert aus Unternehmenssoftware verschwunden. Die bequeme Erklärung wäre, die KI habe enttäuscht, die Demos seien Theater gewesen, der Hype platze gerade. Die unbequeme und richtige Erklärung ist das Gegenteil: Sie hat zu gut funktioniert.

Schaut man in die Quartalszahlen vom Jahresende, wiederholt sich ein Muster, das die Branche zwei Jahrzehnte lang nicht kannte. Das Wachstum flacht ab, und zwar nicht, weil Kunden abspringen, sondern weil sie Sitzplätze streichen. Ein Mitarbeiter, der mit Agenten arbeitet, erledigt die Arbeit von dreien. Also braucht das Unternehmen weniger Lizenzen, nicht mehr. Zum ersten Mal wird ein erfolgreiches Software-Upgrade beim Anbieter als Umsatzrückgang sichtbar. Das ist kein Betriebsunfall. Das ist die Logik des Geschäftsmodells, die sich gegen ihren eigenen Erfinder dreht.

Per-Seat war immer eine Fiktion

Um zu verstehen, was hier stirbt, muss man benennen, was nie wirklich gestimmt hat. Der Preis pro Nutzer und Monat war immer eine elegante Fiktion. Er tat so, als sei der Wert einer Software proportional zur Zahl der Menschen, die sie bedienen. Das war nie der Wert, es war ein bequemer Stellvertreter dafür. Solange Arbeit menschliche Hände brauchte, war die Näherung gut genug, dass niemand sie hinterfragte. Pro Kopf zu zahlen fühlte sich fair an, weil pro Kopf gearbeitet wurde. Die KI hat diese Kopplung nicht angegriffen. Sie hat sie einfach durchtrennt.

Die einzige Frage, die zählt

Jetzt kommt die Unterscheidung, an der alles hängt, und sie ist feiner, als die Schlagzeilen sie machen. Der Unterschied zwischen einem Werkzeug und einem Agenten ist nicht die Autonomie. Es ist die Frage, wer die kognitive Last trägt. Ein Werkzeug zwingt dich, an seiner Oberfläche zu denken, du bedienst es. Ein Agent übernimmt das Denken und tritt als Stellvertreter auf, du delegierst. Daraus folgt die einzige Frage, die zählt, wenn du wissen willst, ob ein Anbieter den Umbruch überlebt: Wofür bezahlt der Sitzplatz eigentlich?

Es gibt zwei grundverschiedene Antworten. Entweder der Sitzplatz bezahlt die verstärkte Arbeitskraft eines Menschen. Dann ist die Software ein Multiplikator auf das, was der Nutzer ohnehin tut, und der Agent ist der direkte Konkurrent genau dieses Multiplikators. Weniger Menschen, die das Werkzeug brauchen, bedeuten weniger Sitzplätze, und der Umsatz folgt nach unten. Oder der Sitzplatz bezahlt den Zugang zu etwas, das der Mensch gar nicht selbst herstellt: zu Daten, zu einem geschützten Bestand, zu einem Netzwerk, zu einem regulatorisch abgesicherten System of Record. Dann ändert die KI an der Rechnung nichts, denn sie senkt die Zahl der Leute nicht, die diesen Zugang wollen. Der Agent kann den Wert weder erzeugen noch ersetzen, er kann ihn nur konsumieren.

Drei Klassen, eine Trennlinie

Damit lässt sich der Markt sezieren, und das Ergebnis ist unbequem konkret.

Die erste Klasse sind die Multiplikatoren, abgerechnet pro Kopf: generische Produktivitäts-Werkzeuge, dünne Workflow-Schichten, alles, was im Kern eine schöne Oberfläche auf einer Datenbank ist und sein Geld damit verdient, dass viele Menschen es bedienen. Diese Klasse fällt zuerst und am härtesten. Wer eine Maske auf eine fremde Datenquelle gelegt und pro Nutzer kassiert hat, ist genau der Wrapper, den ein Agent in einer Nachmittagssitzung ersetzt.

Die zweite Klasse hält den Wert selbst. Das sind die Systems of Record, die proprietären Datenbestände, die Marktplätze mit Netzwerkeffekt, die Software, in der die regulatorische Wahrheit eines Unternehmens liegt. Hier gilt das Gegenteil. Je mehr Agenten im Umlauf sind, desto wertvoller wird die verlässliche Quelle, auf die sie alle zugreifen müssen. Diese Anbieter sterben nicht, sie werden zur Infrastruktur, auf der die Agenten der anderen laufen. Per-Seat darf hier sogar bleiben, denn der Sitzplatz hat nie die Arbeit bezahlt, sondern den Zugang.

Dazwischen liegt die dritte Klasse, die Systems of Engagement, und sie ist die eigentlich spannende, weil sie in beide Richtungen kippen kann. Wer es schafft, vom bedienten Werkzeug zur Plattform zu werden, auf der die Agenten der Kunden andocken, wechselt die Seite des Grabens. Wer am Preis pro Kopf festhält und darauf wartet, dass die Nutzer schon weiterklicken, rutscht in die erste Klasse ab, ohne es zu merken.

Es stirbt nicht, es wird auseinandergenommen

Deshalb ist "SaaS ist tot" die falsche Schlagzeile, so verführerisch sie klingt. Was passiert, ist kein Aussterben, es ist ein selektives Auseinandernehmen. Das Geld verschwindet ja nicht, es wandert nur. Deloitte rechnet damit, dass bis zur Hälfte der Unternehmen 2026 mehr als die Hälfte ihres Digitalbudgets in KI-Automation steckt, und die Nutzung agentischer Systeme hat sich im Jahresvergleich vervielfacht. Es fliesst weg von der Sitzplatz-Lizenz und hin zum Ergebnis. Das ist auch die eigentliche strategische Entscheidung jedes Anbieters, und sie ist keine Frage von KI ja oder nein. Sie lautet: Stelle ich rechtzeitig von Preis pro Kopf auf Preis pro Ergebnis um, oder sehe ich zu, wie mein Umsatz fällt, während meine Software so intensiv genutzt wird wie nie?

Bain führt die ganze Sache bewusst als offene Debatte und nicht als Grabrede, und das ist die ehrliche Haltung. Technologische Umbrüche sind selten binär. "Alles bleibt" ist so falsch wie "alles stirbt". Was bleibt, ist eine neue Trennlinie, und sie verläuft quer durch die alte Branche.

Welche Seite des Grabens

Die nützliche Frage ist deshalb nicht, ob die KI dein SaaS frisst. Sie lautet, auf welcher Seite des Grabens du sitzt, und sie lässt sich heute Nachmittag beantworten. Schau auf deinen eigenen Software-Stack und sortiere ihn nach einer einzigen Linie: Welche dieser Werkzeuge bezahlen den Zugang zu etwas, das du nicht selbst herstellst, zu Daten, zu einem Record, zu einem Netzwerk? Und welche bezahlen nur die Arbeit von Menschen, die du bald mit weniger Köpfen erledigst?

Die erste Liste ist deine Infrastruktur. Die zweite ist deine Kündigungsliste fürs nächste Jahr.

Welches eurer Tools landet auf welcher Seite?

Die KI ersetzt nicht die Juniors. Sie entlarvt die falschen Seniors.

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Warum die ganze Branche das falsche Opfer sucht, und wie aus Seniors Multiplikatoren statt Flaschenhälse werden.

Du kennst das Bild. Die Massenmedien haben es jahrzehntelang gezeichnet, und es sitzt so tief, dass wir es alle sofort vor Augen haben: der Programmierer. Übergewichtig, Chipstüte in Reichweite, kein Partner, keine Freunde, im abgedunkelten Keller im Haus seiner Mutter. Er redet mit niemandem. Er muss auch mit niemandem reden. Er hat ja seinen Code.

Das war nie fair. Aber jetzt wird es interessant. Denn genau dieses Klischee beschreibt exakt die eine Sorte Entwickler, die die nächsten Jahre nicht übersteht. Nicht wegen der Chips. Wegen einer Sache, die das Bild so beiläufig miterzählt, dass wir sie überlesen: Er arbeitet allein und bringt niemandem etwas bei.

Und während die ganze Branche panisch fragt, ob die KI die Juniors abschafft, schaut keiner auf den, der wirklich ein Problem hat.

Die Angst, die alle haben

Die Logik klingt erst einmal zwingend. Ein Junior schreibt einfachen Code, macht Fehler, braucht Betreuung. Die KI schreibt einfachen Code in Sekunden, rund um die Uhr, ohne Kaffeepause. Also, so der Schluss, braucht niemand mehr Juniors.

Der Denkfehler steckt im Wort "also".

Wenn die KI die Einstiegsarbeit übernimmt, verschwindet nicht der Junior. Es verschwindet die Tätigkeit, an der wir Juniors bisher gemessen haben. Das ist nicht dasselbe. Wer heute keine Juniors mehr ausbildet, hat in zehn Jahren keine Seniors mehr. Und Seniors sind genau die, die der KI sagen können, wann ihr Output Mist ist. Du kannst nicht die ganze Pipeline kappen und dich dann wundern, dass oben nichts mehr nachkommt.

Die Frage ist also nicht "Junior oder KI". Die Frage ist: Wie bringen wir beide so zusammen, dass am Ende mehr herauskommt als vorher?

Das alte Modell, ein Wort getauscht

Bisher galt:

Seniors bringen Juniors bei, wie man richtig codet und auf saubere Code-Qualität kommt.

Das neue Modell tauscht genau ein Element:

Seniors bringen Juniors bei, wie man die KI richtig einsetzt und von der KI saubere Code-Qualität einfordert.

Das klingt nach einer Kleinigkeit. Ist es nicht. Es verschiebt die wichtigste Kompetenz eines Entwicklers von "Code schreiben" zu "Code beurteilen".

Und hier liegt die eigentliche Falle, über die kaum jemand redet: Ein Junior, der nie selbst um eine saubere Lösung gerungen hat, erkennt auch nicht, wenn die KI ihm eleganten Unsinn liefert. Die KI ist überzeugend, gerade auch wenn sie falsch liegt. Wer ihren Output nicht beurteilen kann, merkt den Fehler erst in der Produktion. Genau dieses Urteilsvermögen ist das, was der Senior jetzt vermitteln muss. Nicht mehr "schreib es so". Sondern "erkenne, warum das, was da steht, gut oder gefährlich ist".

Vom Entwickler zum Coach

Damit verändert sich, was ein Senior überhaupt ist.

Früher war der Senior der beste Coder im Raum. Sein Wert lag in seinen Händen, in dem, was er selbst produzierte. Der neue Senior misst sich an etwas anderem: an dem, was sein Team durch ihn produziert. Er ist nicht mehr der schnellste Spieler. Er ist der Trainer.

Und Trainer brauchen andere Fähigkeiten als Spieler:

Kommunizieren können. Wissen, das man nicht weitergeben kann, ist in der neuen Welt totes Kapital.
Gerne lehren. Nicht als lästige Pflicht zwischen zwei Tickets, sondern als die eigentliche Aufgabe.
Loslassen können. Das Ende der "Geh weg, das mach ich selbst"-Mentalität. Wer alles selbst macht, hat genau einen Output: seinen eigenen.

Der Senior, der diese Fähigkeiten hat, wird zum Multiplikator. Aus einem produktiven Entwickler wird ein ganzes produktives Team. Das ist der grösste Hebel, den ein Unternehmen heute überhaupt hat.

Und jetzt zurück zum Keller

Der Senior, der sich nur über seinen eigenen Code definiert, der sein Wissen hütet wie einen Schatz, der lieber drei Nächte allein durchcodet als einen Nachmittag zu erklären, der wird nicht von der KI ersetzt. Er ersetzt sich selbst. Denn seine eine Stärke, besser zu coden als alle anderen, ist genau die, die die KI gerade einebnet.

Das Klischee aus dem Intro war nie eine Frage von Aussehen oder Chips. Es war immer eine Frage der Haltung: allein arbeiten, nicht reden, nichts abgeben. Diese Haltung war früher tolerierbar, solange der Output stimmte. Jetzt ist sie ein Karriererisiko.

Die gute Nachricht: Haltung kann man ändern. Niemand muss als Multiplikator geboren werden. Aber man muss es wollen.

Die KI ersetzt keine Menschen. Sie verschiebt, was wertvoll an uns ist: weg von dem, was wir allein tun, hin zu dem, was wir aus anderen herausholen.

Die spannende Frage ist also nicht, ob die Juniors überleben. Die spannende Frage ist: Welcher Senior-Typ bist du, und willst du es bleiben?

Und an alle, die Teams führen: Bildet ihr eure Leute schon darin aus, die KI zu beurteilen, statt sie nur zu bedienen? Oder wartet ihr noch, dass sich das von selbst löst? Ich bin gespannt auf eure Sicht.

Wenn deine KI-Anwendung nur ein Modell kennt, ist sie eine Behördenanordnung vom Totalausfall entfernt.

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Nicht durch einen Hack. Durch eine simple Bitte: Lies diese Codebasis und behebe die Fehler.

Am 12. Juni 2026, um 17:21 Uhr US-Ostküstenzeit, wies die US-Exportkontrolle Anthropic an, Fable 5 und Mythos 5 sofort für alle Kunden abzuschalten. Der Auslöser: Man hatte entdeckt, dass sich das Modell mit genau dieser Aufgabe aushebeln lässt, Code lesen und Fehler beheben. Keine Vorankündigung, keine Übergangsfrist.

Wenn deine produktive Anwendung an diesem Nachmittag auf genau diesem Modell lief, stand sie um 17:22 Uhr.

Das ist kein Einzelfall, sondern ein Vorgeschmack.

Das Problem hat zwei Seiten

Wer KI in Produktion betreibt, hat zwei Probleme, die selten zusammen gedacht werden: Verfügbarkeit und Kosten.

Verfügbarkeit. Modelle verschwinden. Meistens geplant: Anthropic hat allein in den letzten Monaten Opus 3, Sonnet 3.7 und Haiku 3.5 in den Ruhestand geschickt. Das ist beherrschbar, weil es mit Vorlauf passiert. Du migrierst.

Der Fable-Fall zeigt die unangenehmere Variante, den externen Schock: Regulierung, ein Sicherheitsbefund, eine rechtliche Anordnung. Von einer Sekunde auf die andere, ohne Migrationsfenster. Dagegen hilft kein Zeitplan, nur ein Ersatzmodell, das sofort einspringt. In diesem konkreten Fall blieben die übrigen Modelle von Anthropic verfügbar, ein Ausweichen innerhalb desselben Anbieters hätte also genügt. Aber der Vorfall beweist die Risikoklasse, und ein regulatorischer Schock kann grundsätzlich einen ganzen Anbieter treffen. Wer Hochverfügbarkeit verspricht, kann sich an ein einziges Modell eines einzigen Anbieters nicht mehr binden.

Kosten. Die zweite, schleichende Variante. Der Stückpreis pro Token fällt zwar Jahr für Jahr. Bei Anthropic lag Opus 3 noch bei 15/75 USD pro Million Token (Eingabe/Ausgabe), Opus 4.8 liegt bei 5/25, also rund einem Drittel. Aber zwei Dinge laufen dagegen. Erstens kommt immer eine neue, teurere Spitzenstufe oben drauf. Zweitens, und das ist der eigentliche Treiber, explodiert der Verbrauch: Agenten, lange Kontexte und Reasoning-Tokens vervielfachen die Token pro Aufgabe. Die Stückpreise sinken, deine Rechnung steigt.

Der teuerste Fehler dabei ist banal: für jede Aufgabe das stärkste Modell zu nehmen. Eine simple Klassifikation auf einem Spitzenmodell laufen zu lassen, ist, als würde man für jeden Brief einen Kurier buchen. Bei Claude kostet die kleinste Stufe ein Fünftel der grössten. Wer alles über das Topmodell schickt, zahlt das Fünffache für Aufgaben, die es nie gebraucht hätten.

Die Lösung: ein Modell-Router

Ein Modell-Router ist eine Schicht zwischen deiner Anwendung und den Modellen. Statt einen Anbieter und ein Modell fest zu verdrahten, entscheidet der Router pro Anfrage, welches Modell sie bearbeitet.

Wichtig, und oft übersehen: Das sind eigentlich zwei verschiedene Schalter.

Kosten-Routing wählt das günstigste Modell, das für die Aufgabe ausreicht.
Failover-Routing wählt ein Ersatzmodell, wenn das bevorzugte nicht verfügbar ist.

Ein guter Router beherrscht beides, aber es lohnt sich, sie getrennt zu denken. Ein reiner Kosten-Router rettet dich nicht beim Fable-Szenario, und ein reines Failover spart kein Geld.

Die Varianten

1. Statische Regel-Engine. Du legst per Regel fest, welche Aufgabe an welches Modell geht. Extraktion und Klassifikation an die günstige Stufe, Planung und komplexe Entscheidungen an die starke. Geroutet wird nach Aufgabentyp, Kontext oder der Funktion, die den Aufruf auslöst.

Pro: deterministisch, transparent, auditierbar. Keine Trainingsdaten, keine zusätzliche Latenz. Du weisst jederzeit, warum welche Anfrage wohin ging.
Contra: Regeln veralten und brauchen Pflege. Du musst deine Anwendung sauber in Aufgabentypen zerlegen. Und eine bequeme Heuristik wie die Promptlänge ist eben nicht gleich Schwierigkeit.

Für die meisten Anwendungen ist das der beste Startpunkt, oft schon achtzig Prozent des Nutzens.

2. Kaskaden-Eskalation. Erst das günstige Modell, und nur wenn das Ergebnis nicht gut genug ist, eskalierst du auf das stärkere.

Pro: Du zahlst das teure Modell nur, wenn es wirklich gebraucht wird.
Contra: Die Latenz stapelt sich, du wartest erst die billige Antwort ab und dann die teure. Bei jeder Eskalation zahlst du beide Modelle.

Die entscheidende Frage, an der die Kaskade steht oder fällt: Wer beurteilt, ob das Ergebnis gut genug ist? Drei Optionen, ehrlich bewertet:

Das günstige Modell bewertet sich selbst. Unzuverlässig, denn es weiss oft nicht, was es nicht weiss.
Ein separates Bewerter-Modell. Das kostet extra und muss selbst klug sein. Dann hättest du oft gleich das starke Modell nehmen können.
Deterministische Prüfungen: Kompiliert der Code? Ist das JSON valide? Besteht der Test? Billig und verlässlich, aber nur dort, wo das Ergebnis maschinell prüfbar ist.

Daraus folgt die ehrliche Regel: Eine Kaskade lohnt sich nur, wenn die Qualitätsprüfung billiger und verlässlicher ist als der direkte Griff zum stärkeren Modell. Bei prüfbaren Ergebnissen wie Code oder strukturierten Daten hervorragend, bei freiem Text selten.

3. Managed Router. Du kaufst die Routing-Logik als fertiges Produkt ein, statt sie selbst zu bauen.

Pro: schnell einsatzbereit, gepflegt, Failover oft eingebaut, skaliert ohne eigenen Betriebsaufwand.
Contra: Die Routing-Entscheidung ist eine Blackbox. Es kommen eigene harte Grenzen dazu (Azures Router etwa nutzt nur das Kontextfenster des kleinsten Modells im Pool und ist an wenige Regionen gebunden). Und du tauschst einen Lock-in gegen einen anderen, jetzt hängst du am Router-Anbieter.

Die Anbieter von Managed Routern

Eine ehrliche Vorbemerkung: Es gibt keine saubere, öffentliche Vergleichsmessung über alle Anbieter hinweg. Wie gut ein Router die Modellwahl trifft, hängt stark von deinen eigenen Aufgaben ab. Microsoft liefert für seinen Router sogar ein separates Bewertungs-Toolkit, weil sich Routing-Qualität nicht pauschal beziffern lässt. Belastbar ist nur, was du an deinen eigenen Daten misst. Behandle die folgenden Zahlen als Anbieter-Angaben, nicht als Naturgesetz.

Azure Model Router: trainierter Router als ein einziges Deployment, allgemein verfügbar. Echtes Komplexitäts-Routing. Du zahlst den Preis des gewählten Modells plus einen Aufschlag auf die Eingabe-Tokens. Microsoft nennt bis zu sechzig Prozent Einsparung.
OpenRouter (Auto): Marktplatz mit automatischem Router. Echtes Komplexitäts-Routing, du zahlst den Preis des gewählten Modells ohne Extragebühr, mit einem Regler für die Kosten-Qualitäts-Abwägung.
Not Diamond: reine Routing-Middleware, anbieterunabhängig. Echtes Komplexitäts-Routing, positioniert sich ausdrücklich gegen Lock-in.
Martian: Router plus Gateway. Echtes Komplexitäts-Routing, der Anbieter nennt zwanzig bis siebenundneunzig Prozent Einsparung (ungeprüft).
Portkey: Gateway mit Regeln und Fallback. Kein Komplexitäts-Routing, sondern Regel- und Ausfallrouting.
LiteLLM (Open Source): Proxy mit Lastverteilung. Kein Komplexitäts-Routing, sondern Betriebs-Routing.

Zwei Dinge fallen auf. Erstens: Nicht jeder, der sich Router nennt, routet nach Komplexität. Portkey und LiteLLM verteilen Last und fangen Ausfälle ab. Das ist Failover und Governance, nicht Kostenoptimierung nach Aufgabe. Beides ist wertvoll, aber es ist nicht dasselbe. Zweitens, und das ist für den Ausblick entscheidend: Die anbieterübergreifenden Optionen sind die, die dich nicht an ein einziges Ökosystem fesseln.

Als Referenz, was Routing im Idealfall leisten kann: Das Forschungsprojekt RouteLLM zeigte rund fünfundachtzig Prozent Kostenersparnis bei etwa fünfundneunzig Prozent der Qualität des Spitzenmodells. Aber das war ein spezifischer Benchmark mit einem bestimmten Modellpaar, kein Wert, den du blind auf deinen Fall überträgst.

Wo ein Router Sinn ergibt, und wo nicht

Eine Abgrenzung, die in den meisten Diskussionen fehlt: Ein Modell-Router ist vor allem für automatisierte KI-Workflows sinnvoll, nicht für die interaktive Arbeit mit einem Agenten im Chat.

Der Grund: In der chatbasierten Arbeit bringt der Mensch die Intelligenz mit. Er wählt das Modell, merkt, wenn eine Antwort schlecht ist, und eskaliert selbst. Die Feedbackschleife ist der Mensch. In einem automatisierten Workflow gibt es diesen Menschen nicht, also muss das System die Entscheidung treffen. Genau dorthin gehört der Router.

Aber Vorsicht mit dem Wort Chat, hier lohnt sich eine Unterscheidung:

Chat als Werkzeug für Experten (Entwickler in der IDE, Analyst im Assistenten): Der Mensch steuert, automatisches Routing ist kaum nötig.
Chat als Produkt (ein Bot für tausende Endkunden): Der Nutzer wählt kein Modell, das Produkt muss routen. Das ist faktisch ein automatisierter Workflow.

Und hier liegt ein Paradox, das man kennen sollte. Die grösste Verschwendung passiert im Experten-Chat, wo Menschen aus Bequemlichkeit immer das stärkste Modell nehmen, auch für Trivialitäten. Aber genau dort ist Routing am schwersten, weil du die Wahl des Menschen überstimmen müsstest, und das mag niemand. Die Lösung ist dort nicht unsichtbares Routing, sondern eine kluge Voreinstellung und ein einfacher Umschalter. Im Workflow automatisierst du die Modellwahl, im Chat erziehst du die Voreinstellung.

Ausblick

Langfristig wirtschaftlich erfolgreich wird sein, wer zwei Dinge gleichzeitig schafft: seine KI-Kosten im Griff behalten und Hochverfügbarkeit garantieren. Ein Modell-Router ist das Werkzeug für beides.

Ein ehrliches Wort zum Vendor-Lock-in: Ein Router reduziert ihn nur, wenn er anbieterübergreifend routet. Ein Managed Router, der dich an ein Ökosystem bindet, tauscht einen Lock-in gegen einen anderen. Wirklich frei bist du erst mit einer eigenen Abstraktionsschicht, oder einer offenen, die mehrere Hersteller kennt.

Und das ist der eigentliche, oft unterschätzte Gewinn. Ein Router ist nicht nur ein Sparwerkzeug, er ist Optionalität als Infrastruktur. Wer seine Anwendung gegen eine Router-Schnittstelle baut statt gegen das SDK eines einzigen Herstellers, kann Modelle tauschen, sobald die Preise fallen, beim nächsten Fable-Moment ausweichen, und neue Modelle gegeneinander testen, ohne den Code anzufassen.

Die Frage ist also nicht, ob du dir einen Modell-Router leisten kannst. Sondern, ob du es dir leisten kannst, dich an ein einziges Modell zu ketten, das morgen um 17:21 Uhr verschwinden könnte.

Wenn die KI überzeugt danebenliegt: Wie man Sprachmodellen das Halluzinieren bei Geschäftsdaten abgewöhnt

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Jeder, der eine KI-Demo erlebt hat, kennt den Moment der Magie: Man stellt eine Frage, und in Sekunden kommt eine flüssige, kluge Antwort. Und jeder, der KI in den Geschäftsalltag gebracht hat, kennt den zweiten Moment: Dieselbe KI nennt mit derselben Souveränität eine Kundennummer, eine Vertragsklausel oder einen Lagerbestand, den es nie gegeben hat.

Bei einem Chatbot, der Gedichte schreibt, ist das eine Anekdote. Bei Geschäftsdaten ist es ein Haftungsrisiko. Vertrauen in ein System ist binär: Wer einmal eine erfundene Zahl in einem Reporting hatte, glaubt der nächsten richtigen Zahl auch nicht mehr.

Der wichtigste Satz vorweg, und er klingt unbequem: Ein Sprachmodell ist keine Datenbank. Es ist eine Wahrscheinlichkeitsmaschine für plausibel klingenden Text. Es optimiert auf "klingt richtig", nicht auf "ist richtig". Hat es zu einer Frage keine Fakten, füllt es die Lücke mit dem statistisch Naheliegenden, und das ist manchmal schlicht Fiktion. Genau das nennen wir Halluzination.

Die gute Nachricht: Man löst das Problem nicht, indem man auf das nächste, noch grössere Modell wartet. Man löst es mit Architektur. Zwei Bausteine tragen dabei die Hauptlast, RAG und MCP.

RAG: erst nachschlagen, dann antworten

RAG steht für Retrieval-Augmented Generation, frei übersetzt: Antworten mit vorgeschaltetem Nachschlagen. Statt die KI aus dem Gedächtnis raten zu lassen, durchsucht das System zuerst eine Wissensbasis aus Ihren eigenen Dokumenten, findet die passenden Stellen und legt sie der KI zusammen mit der Frage vor. Die KI formuliert ihre Antwort dann aus diesen mitgelieferten Fakten.

Das Bild dazu: kein Prüfling, der frei aus dem Kopf antwortet, sondern einer, der vor jeder Antwort kurz im richtigen Handbuch nachschlägt. Die Technik ist nicht neu, Forscher von Meta haben sie bereits 2020 beschrieben. Neu ist, wie selbstverständlich sie heute zum Standard für seriöse Unternehmens-KI gehört.

Wichtig: RAG liefert Wissen, lesend. Es weiss, was in Ihren Dokumenten steht. Es weiss nicht, wie der Kontostand eines Kunden gerade jetzt lautet. Dafür braucht es den zweiten Baustein.

MCP: die genormte Leitung zu Ihren Systemen

MCP steht für Model Context Protocol, ein offener Standard, den Anthropic Ende 2024 vorgestellt hat. Wenn RAG das Nachschlagen ist, dann ist MCP die Steckdose: eine einheitliche Leitung, über die eine KI mit Ihren Live-Systemen spricht, mit dem CRM, der Datenbank, dem ERP, dem Ticketsystem.

Der oft genutzte Vergleich ist "USB-C für KI". Früher brauchte jede Anbindung ihre eigene Speziallösung. MCP normt diesen Anschluss, und zwar in beide Richtungen: Die KI kann damit nicht nur aktuelle Daten lesen, sondern auch Aktionen auslösen. Dass inzwischen auch andere grosse Anbieter den Standard übernommen haben, macht ihn für eine strategische Entscheidung interessant. Es ist keine Wette auf einen einzelnen Hersteller.

Kurz: RAG bringt das geprüfte Wissen, MCP bringt den Live-Zugriff und die Handlungsfähigkeit. Damit beides verlässlich funktioniert, braucht es Sorgfalt an zwei Stellen.

Voraussetzung 1: eine Vektordatenbank, die wirklich trägt

Die Wissensbasis hinter RAG ist meist eine Vektordatenbank. Sie speichert Ihre Dokumente nicht als Text, sondern als "Bedeutungs-Koordinaten", damit das System nach Sinn suchen kann, nicht nur nach exakten Stichwörtern. Ob das gut funktioniert, entscheidet sich an wenigen, sehr praktischen Punkten:

Saubere, aktuelle Quellen. Garbage in, garbage out. Veraltete Dokumente müssen raus, sonst zitiert die KI souverän die Preisliste von vorletztem Jahr. Eine Aktualisierungs-Pipeline ist Pflicht, kein Nice-to-have.
Sinnvolle Zerteilung (Chunking). Dokumente werden in Stücke zerlegt. Zu gross, und die Suche ertrinkt im Rauschen. Zu klein, und der Zusammenhang geht verloren. Diese Stücke entlang von Bedeutung zu schneiden statt nach starrer Zeichenzahl ist einer der grössten Hebel für die Qualität.
Passende Embeddings. Das Modell, das Text in Bedeutung übersetzt, muss zu Ihrer Sprache und Ihrer Fachdomäne passen. Ein rein auf Englisch trainiertes Modell findet in deutschen Fachtexten weniger.
Hybride Suche. Reine Bedeutungssuche übersieht exakte Begriffe wie Artikelnummern oder Eigennamen. Die Kombination aus Bedeutungs- und Stichwortsuche liefert in der Praxis messbar bessere Trefferquoten.
Reranking. Ein zweiter, genauerer Durchgang sortiert die ersten Treffer nach echter Relevanz, bevor sie an die KI gehen.
Metadaten und Zugriffsrechte. Jedes Stück trägt mit, woher es stammt, wie alt es ist und wer es sehen darf. Gerade im Unternehmen entscheidend: Die KI darf einem Nutzer niemals etwas vorlegen, das er selbst nicht sehen dürfte.
Messbarkeit. Ob die Suche wirklich die richtigen Stellen findet, muss man messen, nicht hoffen. Ohne ein Test-Set aus echten Fragen bleibt Retrieval-Qualität Gefühlssache.

Verkürzt: RAG ist nur so gut wie die Suche darunter. Die meisten enttäuschenden KI-Projekte scheitern nicht am Modell, sondern an dieser Schicht.

Voraussetzung 2: MCP einführen, ohne die Tür offen zu lassen

In dem Moment, in dem die KI echte Geschäftssysteme berührt, ändert sich die wichtigste Frage. Sie lautet nicht mehr "Ist die Antwort schön", sondern "Wer darf hier eigentlich was". Der Leitsatz: Eine KI darf nie mehr Rechte haben als der Mensch, in dessen Auftrag sie handelt.

Technisch löst man das mit OAuth, dem etablierten Standard für delegierten Zugriff, den jeder schon erlebt hat, der irgendwo "mit Google anmelden" geklickt hat. Für KI gibt es dabei zwei typische Situationen:

Der Chat läuft in Ihrer Anwendung (Token Injection). Der Nutzer ist bereits angemeldet. Die Anwendung reicht diese geprüfte Identität an die KI weiter, und die KI erbt exakt die Rechte dieses Nutzers, nicht mehr und nicht weniger. Kein zweiter Login, und sie kann per Definition nichts sehen oder tun, was dem Nutzer selbst verwehrt ist.

Der Agent handelt autonom (Anmelde-Delegation). Hier ist im entscheidenden Moment kein Mensch dabei, etwa bei einem nächtlichen Auswertungslauf. Der Agent braucht deshalb ein eigenes, einmalig erteiltes Mandat: Ein Verantwortlicher erteilt ihm per ausdrücklicher Einwilligung einen klar umrissenen, jederzeit widerrufbaren Zugriff. Dasselbe Prinzip, mit dem Sie einer Dritt-App erlauben, in Ihrem Namen auf ein Postfach zuzugreifen. Der Agent bewegt sich danach nur innerhalb dieses Mandats.

Über beide Fälle hinweg gelten drei Prinzipien, die ein CTO von seinem Team einfordern sollte:

Geringste Rechte. Lesen, Schreiben und Löschen sind getrennte Stufen mit getrennter Freigabe. Ein Auswertungsagent braucht kein Löschrecht.
Einwilligung. Hinter jedem Zugriff steht eine bewusste, menschliche Freigabe, kein stillschweigender Durchgriff.
Nachvollziehbarkeit. Jede Aktion ist lückenlos zuordenbar: wer hat was, in wessen Auftrag, wann getan. Das ist der Unterschied zwischen einer schönen Demo und etwas, das Security und Compliance abnehmen.

Die Kombination: RAG plus MCP für belastbare Antworten

Getrennt sind beide nützlich. Zusammen werden sie zum eigentlichen Mittel gegen Halluzination, weil sie zwei verschiedene Lücken schliessen:

RAG liefert die Regeln und das Wissen. Was steht in unseren Verträgen, Richtlinien, Handbüchern.
MCP liefert die Fakten und die Handlung. Wie ist der Stand jetzt, im System, und führe bei Bedarf etwas aus.

Ein Beispiel, bewusst einfach gehalten: Eine Mitarbeiterin fragt den Assistenten, ob Kunde Müller auf einen höheren Tarif wechseln darf und wie sein aktueller Stand ist. RAG holt die geltende Tarif- und Vertragslogik aus der Wissensbasis, die Regel. MCP zieht live den realen Kontostand und die Vertragslaufzeit aus dem CRM, den Fakt, und könnte den Wechsel auf Wunsch gleich anstossen. Die Antwort steht damit auf zwei Beinen, der geltenden Regel und der aktuellen Realität, und jeder Schritt ist berechtigt und protokolliert.

Warum das die Halluzination einschnürt: Dem Modell bleibt kaum noch Raum, Lücken mit plausibler Fiktion zu füllen, weil die Lücken bereits mit nachgeschlagenem Wissen und Live-Daten gefüllt sind. Und weil jede Aussage auf eine Quelle oder einen Systemaufruf zurück zeigt, ist sie überprüfbar statt nur überzeugend.

Eine ehrliche Einschränkung gehört dazu: Das senkt Halluzination drastisch, es macht sie nicht mathematisch zu null. Ein Modell kann mitgelieferten Kontext immer noch falsch zusammenfassen. Deshalb bleiben die Leitplanken wichtig: Quellen in der Antwort sichtbar machen, bei unumkehrbaren Aktionen einen Menschen entscheiden lassen, und die Qualität laufend messen.

Fazit: ein Architektur-Thema, kein Modell-Thema

Halluzination bei Geschäftsdaten ist kein Makel, der sich durch Warten auf die nächste Modellgeneration von selbst erledigt. Sie ist eine Frage der Architektur.

Das Modell ist der Motor. RAG ist der Treibstoff aus geprüftem Wissen. MCP ist die kontrollierte Leitung in die reale Systemwelt. Und OAuth ist das Schloss an der Tür. Wer diese vier sauber zusammenbaut, bekommt eine KI, die nicht nur eloquent ist, sondern belastbar.

Für die Führungsebene verschiebt das die eigentliche Frage. Sie lautet nicht mehr "Welches Modell kaufen wir", sondern "Wie organisieren wir unser Wissen und unsere Zugriffe". Das ist die langlebigere Investition, denn sie überlebt jeden Modellwechsel, der ohnehin kommt.

Europa hat die KI reguliert, bevor es eine hatte. Glückwunsch!

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Während du diesen Satz liest, hat ein Team in den USA schon ausprobiert, wofür wir in der DACH-Region noch einen Arbeitskreis gründen.

Schau dir an, wo das Geld sitzt

Die wertvollsten Technologieunternehmen der Welt stehen in den USA und in China. Nicht eines davon in der DACH-Region. Das ist kein statistischer Zufall und auch kein Pech. Das ist das Ergebnis einer Haltung.

Die USA sind uns technologisch nicht ein bisschen, sondern dauerhaft meilenweit voraus. Ja, sie machen Abstriche, beim Datenschutz zum Beispiel. Aber dafür preschen sie mit einer Geschwindigkeit vor, die ihresgleichen sucht. Sie bauen erst, lernen unterwegs und korrigieren im Fahren.

Und wir? Wir diskutieren. Gründlich. Bis zum letzten Komma. Während drüben das Produkt schon im Markt ist, sitzt hier noch das vierte Gremium zusammen und prüft, ob man überhaupt anfangen darf.

Das Gefälle multipliziert sich

Das eigentlich Bittere ist nicht der Rückstand selbst, sondern dass er sich aufsummiert.

Erste Stufe: die Cloud. Azure, AWS, Google. Die Rechenzentren, auf denen die halbe europäische Wirtschaft läuft, gehören drei amerikanischen Konzernen. Zweite Stufe, jetzt oben drauf: die KI. Alles Professionelle kommt wieder aus den USA oder aus China. Wir mieten die Infrastruktur, und jetzt mieten wir auch noch die Intelligenz.

Das deutsche Vorzeigeprojekt in dem Feld, Aleph Alpha, hat sich faktisch aus dem Rennen um die grossen Modelle zurückgezogen und konzentriert sich auf Enterprise-Werkzeuge. Das französische Mistral hält tapfer dagegen, kommt an die Spitze aus den USA und China aber schlicht nicht heran.

Reguliert, bevor wir etwas hatten

Europas Antwort heisst EU AI Act. Eine Regulierung von Weltrang, für eine Industrie, die es bei uns kaum gibt.

Vielleicht wäre es klüger gewesen, erst die KI-Unternehmen aufzubauen und sie dann zu regulieren, statt die Leitplanken zu giessen, bevor überhaupt jemand auf die Strasse fährt. Aber sei es drum, das Kind ist in den Brunnen gefallen.

Der Unterschied sitzt im Kopf, nicht im Werkzeug

Am sichtbarsten wird die Lücke im täglichen Umgang. Während in der DACH-Region noch darüber diskutiert wird, ob man KI überhaupt einführen soll und ob die Tokenpreise nicht vielleicht zu teuer sind, machen es die Amerikaner einfach. Sie probieren, scheitern, lernen, skalieren. Und lassen uns wieder als Verlierer zurück, während wir noch das Risiko-Memo schreiben.

Das ist der Punkt, an dem ich ungeduldig werde. Denn das ist die eine Stelle, an der die Ausrede nicht zieht.

Wenn schon kein eigenes Pferd, dann wenigstens reiten

Dass wir keinen eigenen ernstzunehmenden KI-Champion haben, ist bitter, aber kurzfristig nicht zu ändern. Was wir sehr wohl ändern können, ist, ob wir die vorhandenen Werkzeuge nutzen.

Genau hier liegt die Wahl, die jedes Unternehmen in der DACH-Region heute trifft, ob bewusst oder durch Wegschauen. Die Modelle stehen allen offen. Sie kosten einen Bruchteil eines Mitarbeitergehalts. Wer sie nicht nutzt, spart nichts, er fällt nur leiser zurück.

Wir müssen die KI nicht erfunden haben, um mit ihr zu gewinnen. Aber wir müssen sie benutzen. Und dabei hilft kein Bedenkenträger, kein Arbeitskreis und kein weiteres Mimimi.

Der Reframe

Vorsicht ist eine Tugend, solange sie eine Entscheidung vorbereitet. Sie wird zur Ausrede, sobald sie die Entscheidung ersetzt.

Die USA haben uns nicht überholt, weil sie klüger sind. Sie haben uns überholt, weil sie angefangen haben, während wir noch beraten haben. Den Rückstand bei den Modellen holen wir so schnell nicht auf. Den Rückstand bei der Nutzung schon, und der ist gerade der teurere von beiden.

«Das ist nur eine Blase»: die drei beruhigendsten Worte für Menschen, die Angst haben

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Gestern, unter meinem letzten Post, ein Kommentar: Wann diese KI-Firmen endlich profitabel würden? Es werde so viel Geld verbrannt, man hätte mehrfach den Welthunger bekämpfen können. Fazit in drei Worten: Es ist eine Blase.

Sauber serviert. Zahlen, Empörung, ein moralisches Ausrufezeichen obendrauf.

Und trotzdem ging es kein bisschen um Bilanzen.

Denn „Blase" ist das erwachsene, seriös klingende Wort für einen viel älteren Satz:

Bitte lass das nicht echt sein.

Jede Umwälzung bekommt denselben Reflex serviert:

„Das Internet ist eine Modeerscheinung." „Smartphones sind Spielzeug für Erwachsene." „Remote Work funktioniert in der Praxis nie."

Wir nennen es Analyse. Meistens ist es Abwehr in einem besseren Anzug.

Was wirklich unter so einem Kommentar liegt, steht fast nie im Kommentar. Es ist die Frage, die sich kaum jemand laut zu stellen traut:

Was, wenn das, was ich kann, bald weniger wert ist?

Das ist keine Schwäche. Das ist Verlustangst, und Verlustangst ist eines der mächtigsten Gefühle, die wir haben. Die Verhaltensökonomie zeigt seit Jahrzehnten: Wir fürchten den Verlust von etwas ungefähr doppelt so stark, wie wir den gleich grossen Gewinn geniessen.

Wer 15 Jahre lang ein Handwerk perfektioniert hat, hört bei „KI kann das jetzt auch" keine Technologie-News.

Er hört: deine 15 Jahre.

Dazu kommt der zweite Mechanismus: der Ablehnreflex.

Etwas abzulehnen ist schlicht billiger, als sich anzupassen. Ablehnung kostet einen Kommentar und ein bisschen Empörung. Anpassung kostet das Eingeständnis, dass man wieder Anfänger sein könnte, in einem Feld, in dem man gerade noch Experte war.

„Es ist eine Blase" heisst im Kern: Ich muss mich nicht bewegen. Das verschwindet von allein.

Verständlich. Schützt nur vor gar nichts.

Und jetzt wird es teuer.

Denn die Ablehnung bleibt nicht im Kommentarfeld. Sie wandert ins Büro. Da sitzt dann jemand vor dem neuen KI-Tool, dem dieselbe Angst im Nacken sitzt, und tut etwas, das er sich selbst nie eingestehen würde: Er wünscht sich, dass es scheitert.

Also bekommt das Tool die halbherzige Anfrage. Den nutzlosesten Prompt. Die Aufgabe, an der es garantiert zerbricht. Keine Korrektur, kein zweiter Versuch, kein Kontext. Und dann, fast erleichtert:

„Siehste. Das dumme Ding bekommt's nicht hin."

Das ist keine Faulheit. Das ist eine sich selbst erfüllende Prophezeiung mit Vorsatz. Wer recht behalten will, dass KI nicht funktioniert, hat ein erstaunlich wirksames Werkzeug in der Hand: sich selbst. Man muss ein Tool nicht offen torpedieren. Es reicht, ihm beim Scheitern nicht im Weg zu stehen, und das Ergebnis dann als Beweis hochzuhalten.

Und das kostet. Nicht im übertragenen Sinn, sondern in echtem Geld.

Eine viel zitierte MIT-Studie von 2025 fand, dass rund 95 % der generativen KI-Pilotprojekte in Unternehmen keinen messbaren Ertrag liefern, bei 30 bis 40 Milliarden Dollar an Investitionen. 2025 haben 42 % der Unternehmen die meisten ihrer KI-Initiativen wieder eingestampft.

Die offiziellen Gründe heissen „Integration", „Datenqualität", „Governance". Klingt sauber. Klingt nach Technik.

Aber es gibt eine Variable, die keine dieser Studien sauber misst: Menschen, die innerlich auf das Scheitern wetten, bringen es auch zustande. Ein Tool, das niemand will, das jeder nur halb bedient und über das alle erleichtert die Augen verdrehen, wird zu den 95 %. Nicht weil die Technik versagt, sondern weil sie nie eine faire Chance bekommen hat.

Das Bittere daran: Am Ende stimmt der Satz „hat doch eh nicht funktioniert" sogar. Nur nicht aus dem Grund, den alle glauben.

Jetzt der unbequeme Teil.

Vielleicht ist ein guter Teil davon eine Blase. Vielleicht platzen Bewertungen, vielleicht verbrennen noch Milliarden. Gut möglich.

Aber die Dotcom-Blase ist geplatzt, und das Internet ist trotzdem geblieben und hat ganze Berufsbilder neu gegossen. Die Blase und die Umwälzung sind zwei verschiedene Dinge. Man kann auf das Platzen der einen wetten und von der anderen trotzdem überrollt werden.

Wer „Blase!" ruft, um sich selbst zu beruhigen, wirft beides absichtlich in einen Topf.

Die ehrlichere Reaktion wäre nicht „das ist nur Hype".

Sie wäre: „Das macht mir Angst, und ich weiss noch nicht, was ich damit anfange."

Aber das schreibt niemand in einen LinkedIn-Kommentar.

Also meine Frage an euch:

Wann habt ihr das letzte Mal etwas „Hype" oder „Blase" genannt, und wie viel davon war wirklich Analyse, wie viel war einfach Erleichterung?

Die gefährlichste KI in deiner Firma ist die, die nicht mehr nachfragt

benjamin.lutz@smarter-systems.com (Benjamin Lutz)

Ich habe einer KI einmal freie Hand gelassen. Sie hat drei Stunden damit verbracht, denselben Fehler immer wieder zu produzieren, mit wirklich beeindruckender Konsequenz.

Das war kein Bug. Das war Autonomie, die genau das tat, was Autonomie bedeutet.

Zwei Paradigmen, die gerne in einen Topf geworfen werden

Es gibt heute zwei grundverschiedene Arten, mit KI zu arbeiten, und das Marketing verwischt den Unterschied mit Absicht, weil "autonomer Agent" sich besser verkauft als "Chat".

Der KI-Chat arbeitet turnbasiert. Du sagst etwas, die KI antwortet, du entscheidest, was als Nächstes passiert. Der Mensch bleibt bei jedem Schritt in der Schleife. Langsamer, vielleicht. Aber eben auch: in Kontrolle.

Die agentische KI bekommt ein Ziel und wählt den Weg selbst. Sie plant, führt aus, bewertet, korrigiert, wiederholt, alles ohne dich zu fragen. Das klingt nach Zukunft. Manchmal ist es das auch. Und manchmal sind es drei Stunden, in denen ein Python-Skript gebaut wird, das bei jedem Durchlauf denselben Fehler wirft, weil der Agent sich früh auf einen falschen Ansatz festgelegt hat und seine beachtliche Energie danach darauf verwendet, diese Entscheidung gegen die Realität zu verteidigen.

Der Charme und die Falle der Autonomie

Der Reiz ist offensichtlich: Die KI erledigt die Arbeit, während du etwas anderes tust. Die Falle ist subtiler: Sie wählt die Route, und wenn die Route falsch ist, merkst du es erst, wenn der Schaden da ist.

Ein autonomer Agent hält nicht inne und fragt "bist du sicher, dass das die richtige Richtung ist?". Er nimmt an, dass die Antwort ja lautet. Er ist zuversichtlich. Und Zuversicht ohne Kontrollpunkt ist nur Geschwindigkeit in Richtung des falschen Ziels.

Wohlgemerkt, das ist nicht das Versagen des Modells. Du hast ihm Autonomie und ein unscharfes Ziel gegeben. Es hat geliefert, was Autonomie heisst.

Der unterschätzte Held: Chat plus MCP

Hier kommt der Teil, den die Euphorie überspringt. Ein schlichter KI-Chat wird in dem Moment ernsthaft mächtig, in dem du ihm über ein MCP (Model Context Protocol) Werkzeuge gibst. MCP ist der offene Standard, der den Chat in echte Systeme greifen lässt: deine Datenbank, dein Ticketsystem, dein Repository, deine APIs. Der Chat bekommt damit Hände.

Aber, und das ist der ganze Punkt, er bleibt turnbasiert. Er schlägt vor, du gibst frei, er handelt, du siehst das Ergebnis, du steuerst den nächsten Schritt. Du bekommst Fähigkeit, ohne die Kontrolle abzugeben. Für die meisten Szenarien im Unternehmen ist das kein Kompromiss, sondern das richtige Design.

Autonomie ist wunderbar in einer Demo und beunruhigend in der Produktion.

Moment, ein Agent kann doch auch MCP

Richtig, und genau hier wird es interessant. MCP ist nicht dem Chat vorbehalten. Auch ein autonomer Agent kann dieselben Werkzeuge über MCP nutzen. Das heisst: Der Unterschied zwischen den beiden Welten ist nicht das Werkzeug, sondern die Kontrolle darüber.

Ein Agent plus MCP ist ein kraftvolles Gerät. Er erbt dieselbe nutzerbasierte Rechtevergabe (dazu gleich mehr), also kann er nie mehr tun, als der angemeldete Nutzer darf. Sein Schadensradius ist begrenzt. So weit, so gut.

Das Problem ist nicht, was er darf, sondern was er innerhalb des Erlaubten unbeaufsichtigt anrichtet. Zwischen zwei Kontrollpunkten reiht der Agent viele echte Aktionen aneinander. Wenn die Richtung falsch ist, sind drei, vier, fünf reale und voll legitime Schritte bereits passiert, bevor du überhaupt hinschaust. Least Privilege begrenzt, wie schlimm es wird, nicht ob es schiefgeht.

Kurz: Der Agent plus MCP glänzt bei abgegrenzten, wiederholbaren, umkehrbaren Aufgaben mit klarem Ziel. Sobald die Aufgabe unscharf, folgenreich oder schwer rückgängig zu machen ist, schlägt der Chat plus MCP ihn fast immer, weil ein Mensch noch zwischen den Schritten steht.

MCP-Authentifizierung: der Abschnitt, der die Compliance glücklich macht

Hier löst MCP leise das Problem, das jedem CISO den Schlaf raubt, und zwar für beide Welten. Ein MCP-Server kann Authentifizierung verlangen, üblicherweise über OAuth. Das bedeutet: Die KI verbindet sich nicht mit einem allmächtigen Service-Account, der alles darf. Sie verbindet sich im Namen des angemeldeten Nutzers, mit dessen Identität, Rollen und Rechten.

Konkret heisst das:

Die KI sieht und tut nur das, was der reale Nutzer sehen und tun darf. Dein bestehendes Rollen- und Rechtemodell greift unverändert durch.
Least Privilege wird auf dem Server erzwungen, nicht in einem Prompt erhofft.
Jede Aktion ist einer echten Person zurechenbar. Du bekommst ein Audit-Protokoll statt eines Schulterzuckens.
Wird der Nutzer entzogen, ist auch der Zugriff der KI weg. Keine verwaisten Tokens mit Gott-Modus, die irgendwo herumliegen.

Mit anderen Worten: Die KI erbt dein vorhandenes Zugriffsmodell, statt es zu umgehen. Für ein reguliertes Unternehmen ist allein diese eine Eigenschaft mehr wert als jede Menge autonomer Cleverness.

Ein autonomer Agent mit einem Service-Account-Key ist ein Praktikant mit dem Generalschlüssel zum Gebäude und ohne Vorgesetzten. Was soll da schon schiefgehen.

Wann du was nehmen solltest

Das Muster ist simpel: Je echter die Konsequenzen und je teurer ein falscher Weg, desto mehr Mensch gehört zwischen die Schritte.

Der Reframe

Die Frage war nie Chat oder Agent. Die Frage ist, wie viel Autonomie eine Aufgabe gefahrlos verträgt. Die Euphorie verkauft maximale Autonomie als maximalen Wert. Im Unternehmen ist es meistens umgekehrt: Der Wert liegt in Kontrolle, Nachvollziehbarkeit und einem Menschen, der noch "stopp, falsche Richtung" sagen kann, bevor die dritte Stunde desselben Fehlers anbricht.

Das fortschrittlichste KI-Setup ist nicht das, das dich am wenigsten braucht. Es ist das, das dich genau so eingebunden lässt, wie die Sache es verlangt.