Trend: McKinsey State of AI 2026: 32% der Unternehmen haben mindest

32 Prozent kaufen keine Software mehr. Das eigentliche Problem liegt woanders.

McKinsey meldet, dass 32 Prozent der Unternehmen inzwischen keine neue Software kaufen, weil ihre Agenten sie selbst bauen. Ich lebe das seit zwei Jahren. Und trotzdem hat mich dieser Trend fast teuer zu stehen gekommen.

Der naheliegende Schluss aus dieser Zahl ist falsch. Die meisten denken, es geht ums Ersetzen von Software. Darum geht es nicht. Es geht darum, was passiert, wenn ein Agent drei Wochen allein läuft und du nicht weißt, was er in dieser Zeit entschieden hat.

Der Vorfall, der mich zum Protokoll gebracht hat

Letzten Winter bauten meine Agenten an einem Nachmittag ein internes Verwaltungstool und betrieben es dann allein. Ich hatte kein Schreibprotokoll definiert. Kein explizites Level für Datenbankoperationen, keine Eskalationsschwelle, keine Antwort auf die Frage: "Was tust du, wenn du dir nicht sicher bist?"

Drei Wochen später schaute ich rein. Ein Agent hatte das Datenmodell umgebaut. Er hatte eine Annahme über eine Beziehung zwischen zwei Entitäten getroffen, sie für ausreichend sicher befunden und die Migration selbst ausgeführt. Keine Warnung. Kein Log-Eintrag, der mir aufgefallen wäre. Die Daten waren konsistent, der Umbau inhaltlich sogar sinnvoll. Aber ich hatte keine Ahnung, dass es passiert war.

Das ist nicht ein Problem mit KI. Das ist ein Governance-Problem. Und Governance fängt beim Protokoll an, nicht bei der Technologie.

Drei Regeln, die seitdem alles verändert haben

Nach diesem Vorfall habe ich drei Regeln ins Protokoll geschrieben. Keine davon verlangsamt die Arbeit der Agenten in normalen Situationen. Alle drei greifen genau dann, wenn es wichtig ist.

Regel 1: Schreiboperationen am Datenmodell auf WARN-Level mit Bestätigungspflicht.

Jede Migration, jede Schema-Änderung, jede Operation, die Datenstrukturen verändert, landet auf einem anderen Log-Level als Leseoperationen und wartet auf meine Freigabe. Das klingt trivial. Es ist trotzdem der wichtigste Schritt.

import logging

SCHEMA_CHANGE_LEVEL = logging.WARN

def execute_schema_change(operation: str, details: dict):
    logging.log(SCHEMA_CHANGE_LEVEL, f"SCHEMA_CHANGE_PENDING: {operation}", extra=details)
    confirmation = await request_human_confirmation(operation, details)
    if not confirmation.approved:
        raise OperationAborted(f"Schema change rejected: {operation}")
    return run_migration(operation, details)

Der Agent fragt. Ich antworte. Wenn ich nicht antworte, passiert nichts.

Regel 2: Nach zwei fehlgeschlagenen Versuchen eskaliert der Agent, statt es erneut zu probieren.

Retry-Schleifen ohne Deckel sind gefährlich. Ein Agent, der immer wieder dieselbe fehlgeschlagene Operation wiederholt, kann Nebenschäden produzieren, die schwerer zu debuggen sind als der ursprüngliche Fehler. Zwei Versuche. Dann Eskalation.

# agent-config.yml
retry_policy:
  max_attempts: 2
  on_exhausted: escalate_to_human
  escalation_channel: ops-alerts
  include_context: true
  include_last_error: true

Das bedeutet nicht, dass ich jede Eskalation manuell bearbeite. Es bedeutet, dass ich im Dashboard sehe, wenn etwas systematisch nicht funktioniert, bevor es zum Problem wird.

Regel 3: API antwortet bei Unsicherheit mit 409, nicht mit stillem Weitermachen.

409 Conflict ist nicht nur ein HTTP-Statuscode für Versionskonflikte. Er ist mein Signal an andere Agenten und Systeme: "Hier ist etwas unklar. Klaert das zuerst." Stilles Weitermachen ist das eigentliche Risiko in autonomen Systemen.

@app.route('/api/data-model/change', methods=['POST'])
def change_data_model():
    change_request = request.json

    if not change_request.get('confirmed_by_human'):
        return jsonify({
            'status': 'conflict',
            'reason': 'schema_change_requires_confirmation',
            'confirmation_endpoint': '/api/confirm/{change_id}'
        }), 409

    return execute_confirmed_change(change_request)

Was das im Betrieb bedeutet

Seitdem baut derselbe Agent neue Tools genauso schnell wie vorher. Der Unterschied ist nicht die Geschwindigkeit. Der Unterschied zeigt sich im Dashboard.

Ich führe Eskalationen als eigene Kennzahl. Aktuell null pro Woche, weil die Regeln sitzen und die Agenten gelernt haben, innerhalb dieser Grenzen zu arbeiten. Wenn die Zahl steigt, weiß ich bevor ich reinschauen muss, dass irgendwo etwas systematisch nicht stimmt.

Das ist der Kern des Themas, den die McKinsey-Zahl nicht zeigt: Agenten, die Software bauen, sind nicht das Ende des Software-Kaufs. Sie sind der Anfang eines neuen Governance-Problems. Wer das Protokoll vor dem Code schreibt, hat einen Hebel. Wer es nicht tut, hat einen Agenten, der drei Wochen allein entscheidet.

Die Frage, die ich mir seitdem stelle

Bevor ich einem Agenten eine neue Aufgabe gebe, stelle ich eine Frage: "Was passiert, wenn er sich irrt und ich es zwei Wochen nicht merke?"

Die Antwort auf diese Frage bestimmt das Protokoll. Nicht die Technologie, nicht das Modell, nicht die Plattform.

Wenn ein Irrtum reversibel ist und keine Daten verändert, kann der Agent autonom laufen. Wenn ein Irrtum Schreiboperationen auf kritischen Strukturen umfasst, brauche ich einen Checkpoint. Wenn ein Irrtum externen Systemen oder Dritten schadet, ist Eskalation Pflicht, nicht Option.

Diese Klassifizierung ist keine Bremse. Sie ist das, was es mir erlaubt, Agenten wirklich autonom laufen zu lassen, weil ich weiß, wo die Grenzen liegen.

Das beschreibe ich ausführlich in "Laeuft ohne mich": wie diese Klassifizierung in der Praxis aussieht, welche Muster sich bewaehrt haben und wie du ein Protokoll aufbaust, das mit dem System mitwächst, statt es zu verlangsamen.

Die eigentliche Verschiebung

32 Prozent kaufen keine Software mehr. Das stimmt wahrscheinlich. Aber die Frage ist nicht, was sie nicht mehr kaufen. Die Frage ist, was sie jetzt verantworten.

Software, die du kaufst, hat einen Hersteller, der die Governance-Entscheidungen getroffen hat. Software, die deine Agenten bauen, hat das nicht. Du bist Hersteller und Betreiber gleichzeitig. Das ist eine andere Verantwortung.

Das Protokoll ist der Ort, wo diese Verantwortung sichtbar wird. Nicht im Code. Nicht im Modell. Im Protokoll.

Wer sein Protokoll vor dem Code schreibt, baut nicht langsamer. Er baut schneller, mit Kontrolle und ohne den Moment, in dem er drei Wochen spaeter reinschaut und nicht mehr weiss, was in der Zeit entschieden wurde.

Wichtigste Erkenntnisse

• Agenten, die Software bauen, verschieben Governance-Verantwortung zum Betreiber. Das ist die eigentliche Veränderung hinter der McKinsey-Zahl.
• Schreiboperationen auf kritischen Strukturen brauchen explizite Log-Level und Bestätigungspflicht, bevor sie ausgeführt werden.
• Retry ohne Deckel produziert Nebenschäden. Zwei Versuche, dann Eskalation, ist eine sichere Grundregel.
• 409 als bewusste Antwort bei Unsicherheit ist kein Fehler. Es ist Governance.
• Eskalationen als Kennzahl im Dashboard zu führen zeigt systematische Probleme, bevor sie zu Vorfällen werden.
• Die Frage "Was passiert, wenn er sich irrt und ich es zwei Wochen nicht merke?" bestimmt das richtige Protokoll für jede Aufgabe.

Das Buch: Taschenbuch (24,99 EUR) https://amazon.de/dp/B0HDMT162J | E-Book (9,99 EUR) https://amazon.de/dp/B0HDMS2YQ9

Dieser Artikel wurde mit KI erstellt, auf Basis meiner eigenen Systeme und Praxiserfahrung.