devs group Blog

Agenten, die niemand freigegeben hat

Robert Pupel — Fri, 04 Sep 2026 00:00:00 GMT

Wer nicht festlegt, welche Agenten mit welchen Rechten auf welchem Code laufen dürfen, hat diese Entscheidung trotzdem getroffen, nur unbewusst. Agentenplattformen wie OpenClaw laufen auf der Maschine der Entwicklerin, brauchen keine Beschaffung und stehen in keinem Verzeichnis. Agenten-Governance besteht deshalb aus drei Teilen: einer Positivliste, abgestuften Rechteklassen und einer Erkennung, die ohne Verdächtigungen auskommt.

Der typische Auslöser ist ein Nebensatz im Daily. Jemand erwähnt, dass der Agent das Refactoring über Nacht gemacht hat, per Telegram angestossen, vom privaten MacBook aus. Und dann ist die Frage nicht mehr, ob so etwas im Einsatz ist, sondern seit wann.

Ein Repository mit 386’890 Sternen, das nie durch die Beschaffung ging

OpenClaw steht am 20.08.2026 bei 386’890 GitHub-Sternen und ist damit das sechstmeistgesternte Repository überhaupt, deutlich vor React mit 247’443 (GitHub-API, Abruf 20.08.2026). Das ist keine Herstellerangabe, sondern der Zählerstand der Plattform selbst.

Was dahintersteckt: eine offene Agentenplattform von Peter Steinberger, die auf der eigenen Maschine läuft und über gewöhnliche Chat-Apps bedient wird, WhatsApp, Telegram, Discord, Slack, Teams. Das Projekt formuliert es selbst als «Your assistant. Your machine. Your rules.» Kein SaaS, also kein Vertrag, keine Rechnung, kein Beschaffungsvorgang, den ein CTO je zu sehen bekommt.

Für die Inventarisierung ist auch die Namensgeschichte relevant. Aus dem Wochenendprojekt «WhatsApp Relay» vom November 2025 wurde «Clawd», danach «Moltbot», seit dem 29.01.2026 heisst es OpenClaw. Wer eine Liste erlaubter Werkzeuge pflegt und nach dem alten Namen sucht, findet nichts.

Welche Rechte so ein Agent tatsächlich hat

OpenClaw kann Dateien lesen, Befehle ausführen, Plugins installieren und Netzwerkverbindungen aufbauen, und das Projekt sagt dazu selbst den entscheidenden Satz: «It is not a sandbox.» Die Sicherheitsdokumentation beschreibt stattdessen Grenzen, etwa Pfadschutz und einen Proxy, räumt aber ein, dass ein Plugin mit Shell-Rechten weiterhin alles tun kann, was Shell-Rechte erlauben.

Diese Offenheit ist ehrlicher als das Marketing der meisten kommerziellen Werkzeuge. Sie beschreibt aber genau die Klasse von Software, die auf einem Rechner mit Kundencode nicht unbeaufsichtigt laufen sollte.

Dass die Rechteverwaltung dabei brechen kann, ist belegt. CVE-2026-33579 beschreibt eine Privilege Escalation mit CVSS v4.0 9,4 und CVSS v3.1 9,9, eingestuft als CRITICAL durch die CNA VulnCheck, CWE-863, veröffentlicht am 31.03.2026. Betroffen sind alle Versionen vor 2026.3.28: Ein Aufrufer mit Pairing-, aber ohne Admin-Rechten konnte Geräteanfragen mit erweiterten Rechten inklusive Admin genehmigen, weil die Scope-Prüfung im Genehmigungspfad fehlte.

Wenn Sie gerade nicht sagen können, welche Agenten auf Ihren Entwicklungsrechnern laufen und mit welchen Rechten: Genau diese Bestandsaufnahme machen wir in einem halben Tag mit Ihrem Team, ohne Werkzeugempfehlung am Ende. Schreiben Sie uns über Kontakt.

Was der lokale Betrieb unter revDSG auslöst

Ein Agent, der Repository-Inhalte an ein Modell schickt, ist datenschutzrechtlich eine Bekanntgabe, und zwar meist ins Ausland. Enthält der Code Personendaten, etwa in Fixtures, Logs oder Migrationsskripten, greifen Art. 16 und Art. 9 des revDSG.

Besonders unangenehm ist Art. 9 Abs. 3: Ein Auftragsbearbeiter darf die Bearbeitung «nur mit vorgängiger Genehmigung des Verantwortlichen einem Dritten übertragen». Ein selbst installierter Agent, der einen zusätzlichen Modellanbieter anspricht, erzeugt exakt diesen ungenehmigten Dritten, und niemand im Unternehmen weiss davon.

Die Sanktion trifft Menschen, nicht Abteilungen. Art. 61 revDSG stellt Bussen bis CHF 250’000 in Aussicht, gegen private Personen, auf Antrag, bei Vorsatz. Erfasst sind unter anderem die Bekanntgabe ins Ausland ohne die Voraussetzungen nach Art. 17 und die Übergabe an einen Auftragsbearbeiter ohne die Voraussetzungen nach Art. 9 Abs. 1 und 2.

Wie sich das in Architektur übersetzt, haben wir in revDSG-konforme KI-Architektur Norm für Norm ausgeführt.

Drei Rechteklassen statt einer einzigen Freigabe

Eine binäre Freigabe scheitert, weil «erlaubt» für einen Autocomplete etwas anderes heisst als für einen Agenten, der nachts committet. Wir arbeiten deshalb mit drei Klassen, und die Klasse ergibt sich aus dem Zugriff, nicht aus dem Produktnamen.

Klasse	Sichtbarer Code	Ausführung	Netz	Freigabe durch	Typischer Fall
A Assistenz	offener Arbeitsbereich, keine Secrets	keine	Modellanbieter der Positivliste	Team-Lead	Autocomplete, Chat im Editor
B Beauftragt	ein Repository, Secrets über Vault	ja, in Container oder VM, Ergebnis als Pull Request	Positivliste plus freigegebene MCP-Server	Tech-Lead plus Datenschutzverantwortliche	Coding-Agent im Auftrag
C Autonom	mehrere Repositories, Produktionsnähe	ja, ausserhalb der Arbeitszeit, ohne Beobachtung	jede ausgehende Verbindung möglich	Geschäftsleitung, befristet, mit Protokoll	Allzweck-Agent über Chat-App

Die Linie, die zählt, liegt zwischen B und C. Alles, was in Klasse C fällt, gehört auf eine dedizierte Maschine mit eigenem Betriebssystem-Konto, nicht auf das Notebook, auf dem morgen ein Kundenprojekt geöffnet wird. Die OpenClaw-Dokumentation empfiehlt für geteilte Hosts von sich aus, Vertrauensgrenzen zu trennen, mit eigenen Betriebssystem-Nutzern oder eigenen Hosts.

Für Klasse B lässt sich der Rahmen konfigurativ festhalten. OpenClaw kennt dafür eine restriktive Grundhaltung, die als Vorgabe taugt, Gateway nur auf Loopback, Ausführung standardmässig verweigert:

{
  gateway: {
    mode: "local",
    bind: "loopback",
    auth: { mode: "token", token: "<langes-zufaelliges-token>" },
  },
  tools: {
    deny: ["group:automation", "group:runtime", "gateway", "cron"],
    exec: { security: "deny", ask: "always" },
  },
  agents: {
    defaults: {
      sandbox: { mode: "all", scope: "agent" },
      workspaceAccess: "ro",
    },
  },
}

Die Datei selbst gehört abgeriegelt, ~/.openclaw auf 700 und ~/.openclaw/openclaw.json auf 600. Das Projekt liefert dafür eine Prüfung mit, die auch Konfigurationsdrift findet:

openclaw security audit --deep
openclaw security audit --fix

Wie Sie den Einsatz erkennen, ohne jemanden zu jagen

Erkennung heisst hier Inventar, nicht Überwachung: Sie fragen die Maschine, nicht die Kollegin. Drei Signale reichen für eine erste Runde, und alle drei lassen sich in einem Onboarding-Skript oder im MDM-Check unterbringen.

# 1. Global installierte Agenten-Pakete
npm ls -g --depth=0 2>/dev/null | grep -Ei 'openclaw|opencode|codex|claude-code'

# 2. Konfigurationsverzeichnisse dauerhaft laufender Agenten
ls -ld ~/.openclaw ~/.claude ~/.codex 2>/dev/null

# 3. Der OpenClaw-Gateway lauscht per Vorgabe auf 127.0.0.1:18789
lsof -nP -iTCP:18789 -sTCP:LISTEN 2>/dev/null

Der zweite Teil betrifft nicht die Rechner, sondern die Repositories. Ein Agent sieht alles, was das Arbeitsverzeichnis hergibt, und das ist regelmässig mehr als gedacht:

git ls-files | wc -l
git grep -nIE '(api[_-]?key|secret|BEGIN [A-Z ]*PRIVATE KEY)' -- ':!*_test*' | head

Wenn diese zweite Abfrage etwas findet, ist das Agenten-Thema nachrangig. Dann haben Sie ein Secret-Management-Problem, das jeden Klon des Repositories betrifft.

Werkzeugbindung ist das zweite, leisere Risiko

Wer Governance nur als Sicherheitsfrage denkt, übersieht die Konsolidierung im Markt. Windsurf existiert als eigene Marke nicht mehr: windsurf.com antwortet am 20.08.2026 mit HTTP 308 auf devin.ai/desktop, geprüft mit einem einfachen Redirect-Check. Cursor baut mit «Origin» seit dem 17.08.2026 eigenes Code-Hosting samt Repositories und Pull Requests, laut Changelog in offener Beta für alle zahlenden Pläne, mit einer Opt-out-Möglichkeit für Enterprise-Administratoren.

Die Nutzungsanteile verschieben sich im gleichen Tempo. Die JetBrains Developer Ecosystem Survey 2026 mit über 15’000 Befragten, erhoben von Mai bis Juli 2026, misst eine Umverteilung innerhalb weniger Monate. Zu beachten: JetBrains ist im selben Markt tätig und damit kein neutraler Erheber.

Werkzeug	Vorher	Erhebung Mai bis Juli 2026
Claude Code	18 %	39 %
GitHub Copilot	29 %	21 %
Codex	3 %	16 %
Cursor	18 %	12 %

Ein Werkzeug, das binnen zwei Quartalen ein Drittel seiner Nutzerschaft abgibt oder verdoppelt, ist keine Plattformentscheidung, sondern eine Momentaufnahme. Bindend sollte deshalb nicht das Werkzeug sein, sondern das, was den Wechsel überlebt.

Portabel sind heute drei Dinge: das Model Context Protocol in der Spezifikationsversion vom 28.07.2026, das Format AGENTS.md, das laut agents.md über 60’000 Open-Source-Projekte nutzen und das unter dem Dach der Linux Foundation gepflegt wird, sowie A2A in Version 1.0, ebenfalls an die Linux Foundation übergeben.

Wer seine Projektkonventionen dort ablegt statt in werkzeugeigenen Einstellungen, wechselt das Werkzeug ohne Migrationsprojekt. Wie ein eigener MCP-Server dabei aussieht, haben wir in MCP-Server in Go produktiv betreiben beschrieben.

Die MCP-Spezifikation ist in der Sicherheitsfrage bemerkenswert deutlich: Tool-Beschreibungen und Annotationen seien als nicht vertrauenswürdig zu behandeln, sofern sie nicht von einem vertrauenswürdigen Server stammen. Zugleich hält sie fest, dass das Protokoll diese Prinzipien nicht erzwingen kann. Die Absicherung liegt beim Host, also bei Ihnen.

Was in die Richtlinie gehört, und wovon wir abraten

Eine Agenten-Richtlinie passt auf zwei Seiten. Länger wird sie nur gelesen, wenn ein Audit ansteht.

Positivliste mit Version, nicht nur mit Produktnamen. OpenClaw fährt seit dem 30.07.2026 einen Extended-Stable-Kanal, die erste solche Ausgabe ist 2026.6.33. Freigegeben wird ein Kanal, nicht «das Tool».
Rechteklasse pro Einsatz, nach der Tabelle oben, dokumentiert mit einem Satz Begründung.
Ausgehende Ziele benannt. Welche Modellanbieter, welche MCP-Server. GitHub führte am 06.08.2026 MCP-Allowlists in den Enterprise-Einstellungen ein, das ist der richtige Hebel.
Private Abos sind kein Firmenzugang. Nicht weil das Werkzeug damit nicht liefe, sondern weil der Vertrag ein anderer ist: Free, Pro und Max laufen unter Consumer-Bedingungen, bei denen die Trainingsnutzung an einer persönlichen Kontoeinstellung hängt, die der Arbeitgeber weder sieht noch steuert. Anthropic beschreibt das ausdrücklich für die Nutzung von Claude Code aus solchen Konten. Welche Tarif- und Bezugswege es stattdessen gibt, steht in Coding-Agenten datenschutzkonform nutzen.
Ein Meldeweg ohne Konsequenz. Wer einen bisher nicht freigegebenen Agenten meldet, bekommt eine Klasse zugewiesen, keine Rüge.

Wovon wir abraten: von einem Verbot. Ein Verbot erzeugt besser verstecktes Schatten-IT und kostet Sie genau die Information, die Sie brauchen.

Ebenso raten wir davon ab, den Agenten seine eigene Arbeit abnehmen zu lassen. Review, Tests und Merge-Gate bleiben ausserhalb des Agenten, sonst prüft sich das System selbst. Warum das architektonisch zählt, steht in KI schreibt den Code. Wer schreibt die Architektur?.

Wann unsere Empfehlung nicht passt: In einem Zweipersonen-Team mit einem einzigen Repository ohne Personendaten ist die Rechteklassen-Matrix Overhead. Dort genügt eine gepflegte Liste im README und die Regel, dass kein Agent ohne Container Befehle ausführt.

Häufige Fragen

Ist OpenClaw für Firmen grundsätzlich ungeeignet?

Nein. OpenClaw ist ein technisch beeindruckendes Projekt mit einer offenen Sicherheitskommunikation, das seine Grenzen selbst benennt. Ungeeignet ist das Betriebsmodell auf einem Arbeitsgerät mit Kundencode: lokal, weitreichend berechtigt, über Consumer-Chat-Apps gesteuert. Auf einer dedizierten Maschine mit eigenem Betriebssystem-Konto, Loopback-Bindung und restriktiver Tool-Policy ist ein sanktionierter Einsatz möglich.

Woran erkenne ich, ob ein Agent Personendaten an ein Modell geschickt hat?

Am ausgehenden Verkehr und an der Agenten-Sitzung, nicht am Repository. Praktikabel ist der umgekehrte Weg: Sie prüfen, welche Verzeichnisse der Agent lesen durfte, und behandeln alles darin als bekanntgegeben. Deshalb steht in Klasse B workspaceAccess: "ro" und ein einzelnes Repository. Weniger Sichtbarkeit macht die datenschutzrechtliche Beurteilung nach Art. 16 revDSG erst führbar.

Reicht ein Container als Absicherung?

Ein Container begrenzt den Schaden, er verhindert ihn nicht. Er schützt das Dateisystem des Hosts und trennt Agenten voneinander, ändert aber nichts daran, welche Daten der Agent im Container sieht und wohin er sie sendet. Container plus enge Tool-Policy plus benannte ausgehende Ziele wirken zusammen. Einzeln wirkt keines der drei.

Was tun wir mit einem Agenten, der seit Monaten unbemerkt läuft?

Erst inventarisieren, dann einordnen, dann entscheiden. Version prüfen, insbesondere gegen CVE-2026-33579 und die Grenze 2026.3.28, Rechte und Zugriffsumfang festhalten, Secrets rotieren, die in seiner Reichweite lagen. Erst danach die Frage nach Weiterbetrieb oder Abschaltung stellen. Ein sofortiges Abschalten vernichtet die Information darüber, was der Agent überhaupt getan hat.

Der nächste Schritt

Nehmen Sie sich 30 Minuten mit einem unserer Engineers, ohne Verkaufsgespräch: Wir gehen Ihre Werkzeugliste durch, ordnen jeden Eintrag einer Rechteklasse zu und benennen die Stellen, an denen revDSG-Pflichten berührt sind. Termin buchen oder formlos über Kontakt, beides führt zur selben Person.

Wenn daraus mehr wird als eine Richtlinie, etwa ein Agent, der in Ihrer Umgebung sauber abgegrenzt laufen soll, ist das unser Tagesgeschäft unter Künstliche Intelligenz & Machine Learning.

Guardrails für Coding-Agenten: nie der eigene Prüfer

Ralph Segi — Wed, 02 Sep 2026 00:00:00 GMT

Ein Coding-Agent darf seine eigene Arbeit nicht abnehmen. Die Prüfung gehört in eine Instanz, die er nicht steuert: deterministische Gates in der CI und ein Mensch, der bei Eingriffen in bestehenden Code das ganze Diff liest. Wie tief geprüft wird, bestimmt der Aufgabentyp, nicht der Confidence-Wert des Agenten.

Robert Pupel hat in KI schreibt den Code. Wer schreibt die Architektur? drei Regeln formuliert, die bei uns gelten. Dieser Beitrag beschreibt die Mechanik darunter: welche Gates in der Pipeline stehen, was sie auslöst und wo ein Mensch nicht ersetzbar ist. Guardrails für Coding-Agenten sind kein Prozessdokument, sondern Code im Repository.

Drei Quellen, die unabhängig zum selben Schluss kommen

Forschung, Beratung und Praxis kamen 2026 aus verschiedenen Richtungen zur selben Regel: Ein Agent darf nicht sein eigener Prüfer sein.

Der Thoughtworks Technology Radar Vol. 34 vom April 2026 führt „Putting coding agents on a leash” als eines von vier Themen. Die Begründung dort: Weil Agenten bessere Ergebnisse liefern, steigen Menschen zunehmend aus der Schleife aus, und Teams beginnen deshalb, in Harnesses zu investieren. Thoughtworks ist eine Beratungsfirma, die KI-Transformationsprojekte verkauft, und deklariert den Radar selbst als Praktikermeinung, nicht als Empirie.

Octomind, Anbieter eines Testwerkzeugs, hat im August 2026 die Selbstverifikation aus dem eigenen Agenten entfernt. Der Satz aus dem Release, der das Problem präzise trifft: „a model that wants to be done has a way to look done: advance the checklist, mark tasks complete, close the plan.” Ein externer Plan-Manager besitzt seither den Fortschritt, der Agent hat auf das Werkzeug keinen Zugriff mehr. Das ist eine Selbstauskunft eines Anbieters, aber eine mit nachvollziehbarer Mechanik.

Die dritte Quelle ist die interessanteste, weil sie zählbar ist.

Was 932’791 agentenerzeugte Pull Requests zeigen

Seit Februar 2026 existiert eine belastbare Datenbasis für Aussagen über Coding-Agenten. Der Datensatz AIDev (Li, Zhang, Hassan, arXiv:2602.09185) sammelt 932’791 agentenerzeugte Pull Requests aus 116’211 Repositories von 72’189 Entwickelnden, erzeugt von fünf Agenten: OpenAI Codex, Devin, GitHub Copilot, Cursor und Claude Code. Offen, akademisch, ohne ausgewiesene Anbieterfinanzierung.

Darauf aufbauend haben Ferdous, Banik, Chowdhury und Shamim 7’191 agentenerzeugte gegen 1’402 menschliche Pull Requests aus Python-Repositories verglichen und Breaking Changes über eine AST-Analyse erkannt (arXiv:2603.27524, eingereicht am 29.03.2026). Das Ergebnis ist kontraintuitiv:

Kontext	Breaking-Change-Rate
Neubau, Agenten	3,45 %
Neubau, Menschen	7,40 %
Agenten bei Refactoring	6,72 %
Agenten bei Chore-Änderungen	9,35 %

Auf der grünen Wiese brechen Agenten die Kompatibilität also seltener als Menschen. Sobald sie bestehenden Code anfassen, kehrt sich das Bild um. Genau umgekehrt zu dem, was die meisten Teams intuitiv absichern.

Die Confidence Trap: warum der Selbstvertrauens-Wert als Filter ausfällt

Ein hoher Confidence-Wert des Agenten sagt nichts darüber, ob der Pull Request kompatibel bleibt. Dieselbe Arbeit von Ferdous et al. benennt das als „Confidence Trap”: Pull Requests mit hohem Selbstvertrauens-Wert enthalten trotzdem Breaking Changes. Die Autoren leiten daraus wörtlich die Notwendigkeit strengerer Prüfung bei Wartungsarbeiten ab, „regardless of reported confidence score”.

Das ist die praktisch wichtigste Zahl des Jahres, weil sie einen verbreiteten Kurzschluss zerstört. Wer Merge-Gates an einer Selbsteinschätzung aufhängt, hat den Agenten zum Prüfer seiner selbst gemacht, nur mit mehr Schritten.

Wenn Sie gerade einen Agenten auf ein bestehendes Go-Backend loslassen und nicht sicher sind, welche Gates dafür stehen müssen: Das ist ein 30-Minuten-Gespräch, kein Projekt. Wir schauen uns die Pipeline an, die Sie haben, und sagen, was fehlt.

Review-Tiefe nach Aufgabentyp, nicht nach Confidence

Die Ableitung aus den Daten ist eine Matrix mit zwei Spuren. Sie ersetzt die Frage „wie sicher ist sich der Agent?” durch die Frage „was fasst dieser Pull Request an?”.

Aufgabentyp	Belegte Rate	Automatische Gates	Menschliche Prüfung
Neubau, neue Dateien, kein bestehender Code berührt	3,45 %	Build, Tests, `govulncheck`, Lint, Coverage-Schwelle	Schnittstelle und Datenmodell lesen, nicht jede Zeile
Refactoring an bestehendem Code	6,72 %	zusätzlich `gorelease` gegen den letzten Tag, gerenderter Manifest-Diff	vollständiges Diff, zweites Augenpaar
Chore, Abhängigkeiten, Build, Konfiguration	9,35 %	zusätzlich Lockfile-Diff, Image-Digest-Pinning, Manifest-Diff	vollständiges Diff, zweites Augenpaar
Bearbeitung von Personendaten berührt	keine	alles oben	Pflicht, unabhängig vom Aufgabentyp

Die letzte Zeile ist kein Datenbefund, sondern Schweizer Recht. Art. 7 DSG verlangt Datenschutz durch Technik ab der Planung, Art. 2 DSV nennt Nachvollziehbarkeit als eines von vier Schutzzielen. Ein Merge, den niemand namentlich abgenommen hat, erfüllt das nicht. Was das für die Architektur bedeutet, steht in revDSG-konforme KI-Architektur.

Wie die zwei Spuren in einer CI-Pipeline aussehen

Die Zuordnung zur Spur muss deterministisch und ausserhalb der Reichweite des Agenten passieren. Sie darf nicht davon abhängen, wie der Agent seinen Pull Request betitelt.

Der Commit-Typ nach Conventional Commits ist ein brauchbarer Hinweis, aber kein Beleg: Den Titel schreibt der Agent. Das harte Kriterium liefert das Diff selbst. Gelöschte Zeilen bedeuten, dass bestehender Code angefasst wurde.

# .github/workflows/agent-gate.yml
name: agent-gate
on: pull_request

jobs:
  spur:
    runs-on: ubuntu-latest
    outputs:
      lane: ${{ steps.wahl.outputs.lane }}
    steps:
      - uses: actions/checkout@v7
        with:
          fetch-depth: 0
      - id: wahl
        env:
          # Titel nie direkt in `run` interpolieren: Script Injection.
          TITEL: ${{ github.event.pull_request.title }}
          BASIS: ${{ github.event.pull_request.base.sha }}
        run: |
          case "$TITEL" in
            feat:*|"feat("*) LANE=neubau ;;
            *)               LANE=bestand ;;
          esac
          GEAENDERT=$(git diff --numstat "$BASIS"...HEAD | awk '$2 > 0' | wc -l)
          if [ "$GEAENDERT" -gt 0 ]; then LANE=bestand; fi
          echo "lane=$LANE" >> "$GITHUB_OUTPUT"

Unbekannt landet in der strengen Spur. Das ist der ganze Trick: Die Voreinstellung ist streng, nicht locker.

Zwei Gates, die im Go- und Kubernetes-Alltag tatsächlich greifen

Für die Spur Bestand braucht es Prüfungen, die Kompatibilitätsbrüche mechanisch sichtbar machen, statt sie einem Review zu überlassen.

Im Go-Modul erledigt das gorelease aus golang.org/x/exp/cmd/gorelease. Es vergleicht die öffentliche API des ausgecheckten Stands gegen eine Basisversion und beendet sich bei inkompatiblen Unterschieden ab Major-Version 1 mit einem Exit-Code ungleich null. Damit ist der AST-Befund der Studie exakt das, was das Gate misst.

  api-vertrag:
    needs: spur
    if: needs.spur.outputs.lane == 'bestand'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
        with:
          fetch-depth: 0
      - uses: actions/setup-go@v7
        with:
          go-version-file: go.mod
      - run: go install golang.org/x/exp/cmd/gorelease@latest
      - run: gorelease -base=latest

Auf der Kubernetes-Seite ist das Äquivalent der gerenderte Manifest-Diff. Nicht das Chart vergleichen, sondern das Ergebnis: Ein Agent, der einen Wert umbenennt, hinterlässt im Chart eine harmlose Zeile und im Deployment eine fehlende Umgebungsvariable.

# Rendert Basis und PR-Stand und vergleicht das Ergebnis, nicht die Quelle.
helm template svc ./chart > /tmp/neu.yaml
git worktree add /tmp/basis "$BASE_SHA"
helm template svc /tmp/basis/chart > /tmp/basis.yaml
diff -u /tmp/basis.yaml /tmp/neu.yaml

Was die Pipeline nicht abfangen kann

Statische Analyse allein ist kein Sicherheitsgate. Firouzi und Ghafari haben 1’080 LLM-erzeugte Codebeispiele gegen eine von Menschen validierte Referenz gehalten (arXiv:2602.05868, 05.02.2026): Nur 65 % der Semgrep- und 61 % der CodeQL-Befunde trafen die Referenz. Auf aggregierter Ebene sahen beide Werkzeuge plausibel aus, pro Beispiel wichen sie erheblich ab.

Der Bedarf ist da. Peng, Wang und Zhu fanden bei 3’700 Snippets aus dem LLMSecEval-Benchmark, dass 68,8 % mindestens eine Sicherheitsanforderung verletzten, bei hartkodierten Zugangsdaten 79,1 % (arXiv:2607.12089). Ma et al. berichten über acht Modelle hinweg durchschnittliche Verwundbarkeitsraten über 56 % (arXiv:2607.23088, Poster). Die absoluten Werte sind zwischen den Arbeiten nicht vergleichbar, die Richtung ist über ein Dutzend unabhängiger Arbeiten hinweg konsistent.

Was messbar wirkt, ist nachgelagerte Reparatur statt besserer Prompts: Sriram, Pradhan und Saha kombinierten Compiler-Diagnostik, CodeQL und symbolische Ausführung und senkten die Sicherheitsdefekte von CodeLlama 7B in C-Code von 49 % auf 19 % (arXiv:2607.21641). Ein Reparaturlauf gehört also in die Pipeline, ein Freibrief daraus nicht.

Planung und Ausführung trennen

Der Plan muss vor dem Code stehen und von einem Menschen abgenommen sein. Boris Tane beschreibt das als das am häufigsten geteilte Arbeitsmuster überhaupt: „The separation of planning and execution is the single most important thing I do”, und daraus folgend „never let Claude write code until you’ve reviewed and approved a written plan” (boristane.com, Februar 2026).

Das ist die Schnittstelle zwischen dem Agenten und Ihrem Team. Ein abgenommener Plan ist prüfbar, ein fertiges Diff von 2’000 Zeilen nicht mehr. Wo der Plan eine Architekturentscheidung enthält, gehört er ohnehin ins Repository, siehe Entscheidungen, die man in zwei Jahren noch versteht.

Ein Wort zu Kontextdateien, weil hier viel Aufwand versickert: Gloaguen, Mündler, Müller, Raychev und Vechev von der ETH Zürich haben AGENTS.md-Dateien systematisch evaluiert (arXiv:2602.11988, revidiert am 23.06.2026). Befund: Kontextdateien verbessern die Erfolgsrate generell nicht und erhöhen die Inferenzkosten um über 20 %. Anweisungen werden befolgt, Repository-Übersichten bringen nichts. Schreiben Sie also Konventionen und Fallstricke hinein, keine Verzeichnisbäume.

Wovon wir abraten

Bauen Sie kein Merge-Gate, das nur wahr oder falsch kennt. Ein einzelner grüner Haken über allen Aufgabentypen ist entweder für den Neubau zu teuer oder für die Wartung zu billig, meistens beides.

Setzen Sie keinen zweiten Agenten als alleinigen Reviewer ein. Ein Review-Agent ist nützlich, um ein Diff zu strukturieren und Kandidaten zu markieren. Er ist kein Prüfer, weil er dieselben Fehlerklassen teilt wie der Agent, den er prüft, und weil die Kette dann wieder in einer Selbstauskunft endet.

Und der ehrliche Trade-off: Die lockere Spur beim Neubau lässt Fehler durch. Die 3,45 % sind besser als der menschliche Wert, aber sie sind nicht null. Wer diese Staffelung übernimmt, entscheidet sich bewusst dafür, Prüfaufwand dorthin zu verschieben, wo er statistisch mehr bringt. Für ein Team mit zwei Entwicklern und einem Prototypen lohnt sich der ganze Apparat nicht. Für ein Produkt mit externen API-Konsumenten und einem Cluster in Produktion schon.

Häufige Fragen

Warum sollen Agenten bei Wartung strenger geprüft werden als bei Neubau?

Weil die Daten es so zeigen. In der Vergleichsstudie von Ferdous et al. über 7’191 agentenerzeugte Pull Requests lag die Breaking-Change-Rate bei Neubau bei 3,45 %, bei Refactoring bei 6,72 % und bei Chore-Änderungen bei 9,35 %. Wartung setzt Kenntnis bestehender Verträge voraus, die im Kontextfenster oft nur teilweise vorliegen. Neubau definiert die Verträge selbst.

Kann ich den Confidence-Wert des Agenten als Merge-Kriterium nutzen?

Nein. Dieselbe Studie beschreibt eine „Confidence Trap”: Pull Requests mit hohem Selbstvertrauens-Wert enthalten trotzdem Breaking Changes. Der Wert ist eine Selbstauskunft des Systems, dessen Arbeit geprüft werden soll. Nutzen Sie stattdessen Kriterien, die der Agent nicht beeinflusst: Wurde bestehender Code geändert, bricht die öffentliche API, ändert sich das gerenderte Manifest.

Reicht ein Security-Scanner in der Pipeline als Gate?

Als alleiniges Gate nicht. Firouzi und Ghafari fanden auf 1’080 validierten Beispielen, dass nur 65 % der Semgrep- und 61 % der CodeQL-Befunde der menschlich validierten Referenz entsprachen. Scanner gehören in die Pipeline, ihre Befunde sind Hinweise. Wirksamer ist ein nachgelagerter Reparaturlauf, der Compiler-Diagnostik und statische Analyse zusammenführt und das Ergebnis erneut prüft.

Wie klassifiziere ich Pull Requests, wenn der Agent den Titel schreibt?

Über das Diff, nicht über den Titel. Ein Pull Request, der Zeilen löscht, hat bestehenden Code angefasst und gehört in die strenge Spur. git diff --numstat liefert das in einer Zeile. Der Commit-Typ nach Conventional Commits bleibt ein nützlicher Hinweis für Menschen, taugt aber nicht als Gate, weil ihn der Prüfling selbst setzt.

Ihre Pipeline durchgehen, nicht Ihre Strategie. 30 Minuten mit einem unserer Go-Engineers: welche Gates Sie heute haben, welche Aufgabentypen bei Ihnen ungeprüft durchlaufen und was sich davon in einer Woche nachrüsten lässt. Ohne Verkaufsgespräch.

Termin buchen · Kontakt aufnehmen · Wie wir KI-Systeme und Agenten-Infrastruktur bauen, steht unter Künstliche Intelligenz & Machine Learning.

Coding-Agenten datenschutzkonform nutzen: die Lücke im Abo

Ralph Segi — Mon, 31 Aug 2026 00:00:00 GMT

Ein Entwickler, der mit seinem privaten Pro- oder Max-Abo an Firmencode arbeitet, fällt unter Anthropics Consumer-Bedingungen, nicht unter die kommerziellen. Dort ist die Trainingsnutzung eine Kontoeinstellung, ausdrücklich „including when you use Claude Code from these accounts”, und bei aktivierter Einstellung liegen die Daten fünf Jahre statt dreissig Tage.

Das ist kein Skandal und kein verstecktes Kleingedrucktes. Anthropic dokumentiert die Unterschiede auf einer öffentlichen Seite zur Datennutzung, detaillierter als die meisten Anbieter. Die Lücke entsteht in den Firmen, die den Unterschied zwischen Consumer- und Geschäftstarif nie geregelt haben. Wer Coding-Agenten datenschutzkonform nutzen will, beginnt deshalb beim Konto, nicht beim Werkzeug.

Warum das private Abo überhaupt auf Firmencode landet

Coding-Agenten kommen über den Entwickler ins Unternehmen, nicht über die Beschaffung. Jemand testet Claude Code abends am eigenen Projekt, findet es gut, tippt am nächsten Morgen claude im Kundenrepository und ist dabei immer noch mit dem privaten Konto angemeldet. Es gibt keinen Installationsdialog, der das bemerkt.

Der zweite Weg ist die Spesenabrechnung. Ein Team, das noch keine Lizenz hat, vergütet zwanzig Dollar im Monat als Auslage. Damit ist das Abo bezahlt, aber vertraglich bleibt es ein Konsumentenvertrag zwischen Anthropic und einer Privatperson. Der Arbeitgeber ist darin keine Partei.

Beide Wege sind technisch unauffällig. /status in Claude Code zeigt die Anmeldemethode und die Organisation an, aber niemand schaut dort hin, solange nichts kaputt ist.

Ist Firmencode überhaupt ein Datenschutzthema?

Firmencode ist ein Datenschutzthema, sobald Personendaten darin vorkommen, und das ist häufiger der Fall als gedacht. Test-Fixtures mit echten Namen, ein Datenbank-Dump für die Migration, ein Log-Auszug, den jemand in den Prompt kopiert: In diesen Momenten bearbeitet ein Coding-Agent Personendaten.

Der EDÖB hat am 24.09.2025 im Beitrag KI und Datenschutz festgehalten, dass „das Schweizer Datenschutzgesetz (DSG) auf KI-gestützte Datenbearbeitungen direkt anwendbar ist”. Es braucht kein KI-Sondergesetz, damit Pflichten gelten. Welche Normen im Einzelnen greifen und wer für einen Verstoss haftet, steht in unserem Beitrag zur revDSG-konformen KI-Architektur.

Wo keine Personendaten im Spiel sind, bleiben zwei andere Bindungen: das Geschäftsgeheimnis des Kunden und die Vertraulichkeitsklausel im Rahmenvertrag. Ob eine bestimmte Klausel die Weitergabe an einen Inferenzanbieter deckt, ist eine Frage des Einzelfalls und gehört vor den ersten Prompt geprüft, nicht danach.

Was Anthropic pro Tarif zusagt

Die Zusagen unterscheiden sich zwischen Consumer- und Geschäftstarifen in drei Punkten: Training, Aufbewahrung und Verhandelbarkeit. Alle Angaben stammen aus der Datennutzungsseite und der Preisseite, abgerufen am 20.08.2026.

Tarif	Training auf Ihrem Code	Aufbewahrung bei Anthropic	Listenpreis (USD)
Free, Pro, Max	abhängig von einer Kontoeinstellung, inklusive Claude-Code-Nutzung aus diesen Konten	5 Jahre bei aktivierter Einstellung, sonst 30 Tage	Pro 17 im Jahresabo, 20 monatlich; Max ab 100
Team	kein Training unter kommerziellen Bedingungen	30 Tage	20 pro Standard-Seat, 100 pro Premium-Seat, jeweils jährlich
Enterprise	kein Training unter kommerziellen Bedingungen	30 Tage; Zero Data Retention auf Antrag	20 pro Seat plus Nutzung zu API-Preisen
API, Bedrock, Google Cloud, Microsoft Foundry	kein Training; das Development Partner Program ist über Bedrock und Google Cloud gar nicht verfügbar	30 Tage, bei Foundry „Hosted on Azure” bleiben Prompts und Completions in Azure	nutzungsabhängig

Drei Details, die in Beschaffungsgesprächen regelmässig falsch wiedergegeben werden:

Zero Data Retention ist nicht im Standard-Enterprise-Plan enthalten. Anthropic schreibt, ZDR sei für qualifizierte Konten verfügbar und werde pro Organisation vom Account-Team nach einer Eignungsprüfung freigeschaltet. Wer ZDR braucht, verhandelt ihn.
Über /feedback, /bug und /share geteilte Transkripte werden fünf Jahre aufbewahrt, unabhängig vom Tarif. Freiwillig hochgeladene Sitzungstranskripte aus der Qualitätsumfrage bis zu sechs Monate.
Fehlerberichte sind nur bei Pro- und Max-Anmeldung aktiv, ab Version 2.1.198 und nur bei direkter Verbindung zur Claude-API. Auch das ist eine Consumer-Eigenschaft, die im Geschäftstarif gar nicht erst auftritt.

Was es kostet, die Lücke zu schliessen

Der Wechsel von privaten Abos auf Team-Seats kostet ein zwölfköpfiges Team drei Dollar pro Kopf und Monat. Modellrechnung aus den Listenpreisen: zwölf Pro-Abos im Jahresabo kosten 12 × 17 = 204 USD monatlich, zwölf Team-Standard-Seats 12 × 20 = 240 USD. Delta: 36 USD im Monat, 432 USD im Jahr.

Für Vielnutzer sieht die Rechnung anders und noch günstiger aus. Wer heute ein Max-Abo für 100 USD monatlich hat, kostet als Team-Premium-Seat im Jahresabo ebenfalls 100 USD. Der Wechsel ist bei diesem Nutzungsprofil preisneutral.

Der ehrliche Vorbehalt: Ein Standard-Seat ist kein Ersatz für ein Max-Abo, die Nutzungskontingente unterscheiden sich. Wer heute Max spesiert, braucht einen Premium-Seat, nicht den günstigsten. Trotzdem bleibt die Grössenordnung dieselbe, und sie ist der Grund, warum diese Lücke ärgerlich ist: Sie kostet fast nichts, ausser der Entscheidung.

Wenn Sie nicht wissen, mit welchen Konten Ihr Team heute arbeitet, ist das eine Stunde Arbeit, keine Woche. Dreissig Minuten mit einem unserer Engineers reichen, um daraus eine Inventarliste und eine Reihenfolge zu machen.

Drei Datenflüsse, die auch im Geschäftstarif bleiben

Ein kommerzieller Tarif regelt das Training, nicht jeden Datenfluss. Drei davon bleiben bestehen und gehören ins Bearbeitungsverzeichnis, weil sie sonst in keiner Vertragsprüfung auftauchen.

Lokale Transkripte im Klartext. Claude Code legt Sitzungstranskripte unter ~/.claude/projects/ ab, standardmässig 30 Tage. Die Dokumentation ist dabei unmissverständlich: „Transcripts and history are not encrypted at rest. OS file permissions are the only protection.” Liest ein Tool eine .env-Datei, steht der Inhalt in der .jsonl-Datei. Steuerbar über cleanupPeriodDays, CLAUDE_CODE_SKIP_PROMPT_HISTORY und claude project purge.

Die WebFetch-Domainprüfung. Vor jedem Abruf sendet WebFetch den angefragten Hostnamen an api.anthropic.com, um ihn gegen eine Blockliste zu prüfen. Nur den Hostnamen, nicht die volle URL. Das läuft unabhängig vom Modellanbieter, also auch über Bedrock, und CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC erfasst es nicht. Abschaltbar allein über skipWebFetchPreflight.

Telemetrie und Fehlerberichte. Steuerbar über DISABLE_TELEMETRY, DISABLE_ERROR_REPORTING, DISABLE_FEEDBACK_COMMAND und CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC. Bei Amazon Bedrock, Google Cloud, Microsoft Foundry und Claude Platform on AWS sind Metriken, Fehlerberichte und /feedback bereits standardmässig aus. Sitzungsumfragen und die WebFetch-Prüfung laufen dort weiter.

Welcher Bezugsweg für welche Art von Code?

Der Bezugsweg richtet sich nach dem Inhalt des Repositorys, nicht nach der Grösse der Firma. Die Frage lautet also nicht „welchen Tarif kaufen wir”, sondern „was liegt in diesem Repository und was landet aus ihm im Prompt”.

Was im Repository und im Prompt landet	Bezugsweg	Was zusätzlich nötig ist
Eigenes Tooling, Open-Source-Beiträge, keine Kundendaten	Team-Seat	nichts über die interne Richtlinie hinaus
Kundencode unter NDA, keine Personendaten	Team oder Enterprise	Vertraulichkeitsklausel des Kunden prüfen, Egress dokumentieren
Personendaten in Fixtures, Dumps oder Logs	Enterprise, ZDR verhandeln	Auftragsbearbeitung nach Art. 9 DSG, Löschkonzept für lokale Transkripte
Besonders schützenswerte Personendaten nach Art. 5 lit. c DSG	Bedrock mit kundenverwalteten KMS-Schlüsseln oder Foundry „Hosted on Azure”	Datenschutz-Folgenabschätzung prüfen, keine Produktionsdaten im Prompt
Zugesicherte Datenresidenz oder Berufsgeheimnis	eigenes Hosting, offene Modelle	siehe souveräne KI-Inferenz in der Schweiz

Amazon Bedrock verschlüsselt mit AES-256 und erlaubt kundenverwaltete Schlüssel über AWS KMS, Google Cloud unterstützt CMEK. Bei Microsoft Foundry und „Hosted on Azure” bleiben Prompts und Completions in Azure, nur Nutzungsmetadaten und von Sicherheitssystemen markierte Inhalte gehen an Anthropic. Welche Regionen konkret verfügbar sind, steht nicht in der Datennutzungsseite und ist beim jeweiligen Cloud-Anbieter zu prüfen.

Wie Sie die datenschutzkonforme Nutzung technisch erzwingen

Die Anmeldung an einer bestimmten Organisation lässt sich erzwingen, und das ist der einzige Punkt der ganzen Liste, der ohne Disziplin auskommt. forceLoginOrgUUID und forceLoginMethod gehören in die Managed Settings und werden über Ihr Device Management ausgerollt: auf macOS nach /Library/Application Support/ClaudeCode/managed-settings.json, auf Linux nach /etc/claude-code/managed-settings.json.

{
  "forceLoginMethod": "claudeai",
  "forceLoginOrgUUID": "550e8400-e29b-41d4-a716-446655440000",
  "cleanupPeriodDays": 7,
  "env": {
    "DISABLE_TELEMETRY": "1",
    "DISABLE_ERROR_REPORTING": "1",
    "DISABLE_FEEDBACK_COMMAND": "1"
  },
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

Vier Einschränkungen, die Anthropic in der Dokumentation zur Authentifizierung selbst benennt und die man kennen muss, bevor man den Haken setzt: claude setup-token und /install-github-app erzwingen nur forceLoginMethod, können also ein Token in einer anderen Organisation erzeugen. Sitzungen über Cloud-Anbieter werden nicht blockiert, die schränken Sie über IAM ein. ANTHROPIC_API_KEY und apiKeyHelper werden beim Start blockiert, weil sich die Organisationszugehörigkeit dort nicht prüfen lässt. Und wenn Sie zusätzlich Server-managed Settings verteilen, müssen beide Schlüssel an beiden Orten stehen, weil die Quellen sich nicht mischen.

Die zweite Hälfte gehört ins Repository, nicht aufs Gerät, damit sie im Code-Review sichtbar ist. Eine .claude/settings.json mit Deny-Regeln greift für jeden, der das Projekt auscheckt:

{
  "permissions": {
    "deny": [
      "Read(./deploy/*.key)",
      "Read(./fixtures/prod-*.sql)"
    ]
  }
}

Und ein Prüfskript, das als MDM-Check oder im Onboarding läuft:

#!/usr/bin/env bash
# Prüft, ob die Vorgaben für Claude Code auf diesem Gerät greifen.
# Exit 1, sobald eine Vorgabe fehlt.
set -euo pipefail

case "$(uname -s)" in
  Darwin) managed="/Library/Application Support/ClaudeCode/managed-settings.json" ;;
  *)      managed="/etc/claude-code/managed-settings.json" ;;
esac

fail=0
note() { printf '%-26s %s\n' "$1" "$2"; }

if [ -f "$managed" ]; then
  org=$(jq -r '.forceLoginOrgUUID // empty' "$managed")
  [ -n "$org" ] || { note "forceLoginOrgUUID" "fehlt"; fail=1; }
  days=$(jq -r '.cleanupPeriodDays // empty' "$managed")
else
  note "managed-settings.json" "nicht vorhanden"
  fail=1
fi

# Klartext-Transkripte oberhalb der eigenen Aufbewahrungsfrist
alt=$(find "$HOME/.claude/projects" -name '*.jsonl' -mtime +"${days:-30}" 2>/dev/null | wc -l | tr -d ' ')
[ "$alt" = "0" ] || { note "alte Transkripte" "$alt Dateien über der Frist"; fail=1; }

exit "$fail"

OpenAI Codex: gleicher Prüfpfad, andere Namen

Bei OpenAI verläuft die Prüfung entlang derselben drei Fragen, die Bezeichnungen unterscheiden sich. Der Business-Tarif kostet laut Codex-Preisseite 20 USD pro Nutzer und Monat im Jahresabo und trägt die Zusage „No training on your business data by default”. Enterprise ergänzt Kontrollen für Aufbewahrung und Datenresidenz, SCIM, External Key Management, rollenbasierte Zugriffskontrolle sowie Audit-Logs über die Compliance-API.

Für Firmen, die den Datenfluss zu OpenAI ganz vermeiden wollen: Die Codex CLI unterstützt seit Release 0.148.0 Amazon Bedrock Runtime als eingebauten Provider, inklusive AWS-Profil und Region. Damit gilt für Codex derselbe Weg wie für Claude Code, nämlich Inferenz im eigenen AWS-Konto statt beim Modellanbieter.

Die praktische Konsequenz ist unbequem: Wer beide Werkzeuge im Haus hat, braucht zwei Prüfungen und zwei Richtlinienzeilen. Ein einziger Absatz „KI-Tools sind erlaubt” deckt das nicht ab.

Was am Montag in die Richtlinie gehört

Sechs Zeilen genügen, und sie sind in einer Stunde geschrieben. Der Reihe nach, weil die Reihenfolge den Aufwand bestimmt:

Inventar. Wer arbeitet mit welchem Werkzeug unter welchem Konto? /status beantwortet das pro Gerät in Sekunden.
Spesenregel. Private KI-Abos werden nicht mehr vergütet. Diese Zeile schliesst den zweiten Einfallsweg.
Anmeldung erzwingen. forceLoginOrgUUID und forceLoginMethod über das Device Management, mit den vier Einschränkungen oben im Hinterkopf.
Repository-Klassifikation. Eine Spalte im Repository-Inventar: Enthält es Personendaten, ja oder nein? Danach richtet sich der Bezugsweg aus der Tabelle.
Egress dokumentieren. api.anthropic.com gehört auf die Allowlist und in das Verzeichnis der Bearbeitungstätigkeiten, wegen der WebFetch-Prüfung auch dann, wenn Sie über Bedrock fahren.
Feedback-Pfad regeln. Entweder DISABLE_FEEDBACK_COMMAND setzen oder im Team festhalten, dass /feedback und /share Code an einen Empfänger geben, der ihn fünf Jahre aufbewahrt.

Die Leitplanken gehören dabei ins Repository und ins Gerätemanagement, nicht in ein Wiki, aus demselben Grund, aus dem wir sie auch bei der KI-gestützten Entwicklung dorthin legen: Was nicht im Werkzeug steht, gilt nach drei Wochen nicht mehr.

Wovon wir abraten

Vom Verbot. Ein Verbot von Coding-Agenten führt nicht dazu, dass niemand sie nutzt, sondern dazu, dass niemand es sagt. Das Ergebnis ist genau der Fall, den dieser Beitrag beschreibt: privates Konto, unbekannter Tarif, keine Aufsicht. Ein bezahlter Team-Seat ist die billigere Kontrolle.

Von Zero Data Retention als Reflex. ZDR ist nicht im Standard-Enterprise-Plan enthalten, wird pro Organisation freigeschaltet und braucht eine Verhandlung mit dem Account-Team. Für Repositories ohne Personendaten lösen dreissig Tage Aufbewahrung plus dokumentierte Auftragsbearbeitung dasselbe Problem, ohne Beschaffungsprojekt.

Von skipWebFetchPreflight als Standardeinstellung. Wer die Prüfung abschaltet, ruft URLs ohne Abgleich mit der Blockliste ab, und das ist bei einem Agenten, der Webinhalte in seinen Kontext zieht, kein guter Tausch. Der bessere Weg ist die Allowlist plus ein Eintrag im Verzeichnis.

Der Trade-off, den wir offen benennen: Bedrock und Foundry kaufen Datenresidenz mit Betriebsaufwand. Sie verwalten Regionen, IAM-Rollen und eigene Schlüssel, Sie verlieren die Abrechnung über einen einzigen Seat-Preis, und neue Modellversionen erreichen Sie tendenziell später. Für ein Repository mit Gesundheitsdaten ist das richtig. Für das interne Admin-Tool ist es Aufwand ohne Gegenwert.

Häufige Fragen

Darf ein Entwickler mit privatem Claude-Pro-Abo an Kundencode arbeiten?

Vertraglich möglich, betrieblich schwer zu verantworten. Consumer-Tarife unterliegen den Consumer-Bedingungen, die Trainingsnutzung hängt an einer persönlichen Kontoeinstellung, die der Arbeitgeber weder sieht noch steuert, und bei aktivierter Einstellung beträgt die Aufbewahrung fünf Jahre. Ob im konkreten Fall zusätzlich Datenschutz- oder Geheimhaltungspflichten verletzt werden, hängt vom Repository und vom Kundenvertrag ab.

Reicht ein Team-Abo, oder brauchen wir Enterprise?

Für die Trainingsfrage reicht Team: Anthropic trainiert unter kommerziellen Bedingungen nicht auf Code oder Prompts, und die Aufbewahrung liegt bei dreissig Tagen. Enterprise brauchen Sie für SSO, rollenbasierte Berechtigungen, die Compliance-API und die Managed Policy Settings für organisationsweite Konfiguration. Zero Data Retention gibt es nur auf diesem Weg, und auch dort nur nach Eignungsprüfung.

Wie bekommen wir Zero Data Retention?

Über das Account-Team, nicht über einen Schalter im Admin-Bereich. Anthropic beschreibt ZDR als für qualifizierte Konten verfügbar und pro Organisation nach bestätigter Eignung freigeschaltet, ausdrücklich nicht als Bestandteil des Standard-Enterprise-Plans. Rechnen Sie mit einer Vorlaufzeit und klären Sie vorher, für welche Repositories Sie ihn tatsächlich benötigen.

Löst Amazon Bedrock unsere Datenschutzfragen?

Bedrock löst die Residenz- und Schlüsselfrage, nicht die Bearbeitungsfrage. Verschlüsselung mit AES-256 und kundenverwaltete Schlüssel über AWS KMS sind dokumentiert, Telemetrie und Fehlerberichte sind dort standardmässig aus. Bestehen bleiben die lokalen Klartext-Transkripte, die WebFetch-Domainprüfung gegen api.anthropic.com und Ihre eigenen Pflichten zu Zweckbindung, Information und Protokollierung.

Nehmen Sie Ihre Entwicklerliste und tragen Sie in eine Spalte ein, unter welchem Konto jede Person angemeldet ist. Wenn dort ein privates Abo auftaucht, haben Sie das Ergebnis dieses Beitrags schon in der Hand.

Dreissig Minuten mit einem Engineer über Tarifwahl, Bezugsweg und Managed Settings, ohne Verkaufsgespräch: Termin buchen. Lieber schriftlich? Über Kontakt. Wie wir KI-Systeme bauen und absichern, steht unter Künstliche Intelligenz & Machine Learning.

Alle Produkt- und Vertragsangaben am 20.08.2026 an den Primärquellen von Anthropic und OpenAI geprüft. Dieser Beitrag beschreibt Produkt- und Vertragsbedingungen und leitet daraus technische Konsequenzen ab; er ist keine Rechtsberatung.

KI-Produktivität: Die 19 Prozent von METR sind überholt

Robert Pupel — Sat, 29 Aug 2026 00:00:00 GMT

Die meistzitierte Zahl zur KI-Produktivität ist überholt. METR mass 2025 an 16 erfahrenen Open-Source-Entwicklern 19 Prozent mehr Zeitbedarf mit KI-Werkzeugen. Die Nachfolgestudie derselben Organisation, ab August 2025 mit 57 Entwickelnden, misst 18 Prozent weniger Zeit bei denselben Personen. Beide Intervalle sind so breit, dass gesichert davon nichts ist.

Warum die 19-Prozent-Zahl heute falsch zitiert wird

Die 19 Prozent stammen aus einer randomisierten Studie von METR, Februar bis Juni 2025: 16 erfahrene Entwickler, 246 Issues in ihren eigenen Repositories mit im Schnitt über 22’000 Sternen. Werkzeug war überwiegend Cursor Pro mit Claude 3.5 und 3.7 Sonnet.

Der Befund war unbequem und wurde deshalb viel zitiert: Die Entwickler erwarteten vorher 24 Prozent Beschleunigung, glaubten nachher an 20 Prozent Beschleunigung, und waren gemessen 19 Prozent langsamer.

METR hat die Untersuchung fortgesetzt. Die Aktualisierung vom 24. Februar 2026 berichtet eine zweite Studie ab August 2025: 57 Entwickelnde, davon 10 aus der Originalstudie und 47 neu, 143 Repositories, über 800 Aufgaben. Alle Werte in derselben Metrik, Zeitbedarf mit KI gegenüber ohne, ein Minus bedeutet weniger Zeit:

Gruppe	Punktschätzer	Konfidenzintervall
Originalstudie, Feb bis Juni 2025	+19 %, also mehr Zeit	+2 % bis +39 %
Dieselben Entwickler, Zweitstudie	−18 %, also weniger Zeit	−38 % bis +9 %
Neu rekrutierte Entwickler	−4 %, also weniger Zeit	−15 % bis +9 %

Das Ergebnis hat sich nicht abgeschwächt, es hat das Vorzeichen gewechselt. Wichtiger ist der Unterschied in den Intervallen: Das der Originalstudie schliesst die Null aus, die beiden neuen schliessen sie ein. Belegt ist damit weder Verlangsamung noch Beschleunigung.

METR misstraut dem eigenen Ergebnis, und begründet das sauber

METR schreibt selbst, die Daten taugten nicht als Produktivitätsmass. Wörtlich zur Selektionsverzerrung: «Because of the selection effects in our experiment, our data is only very weak evidence for the size of this increase.» Und zum zentralen Schätzwert: «we believe it is likely a bad proxy for the real productivity impact.»

Der Grund dafür ist die interessanteste Stelle der ganzen Debatte. METR senkte die Vergütung von 150 auf 50 Dollar pro Stunde. Damit veränderte sich, wer überhaupt mitmacht und welche Aufgaben eingereicht werden.

«30% to 50% of developers told us that they were choosing not to submit some tasks because they did not want to do them without AI», heisst es im Bericht. Ein Teilnehmer im Originalton: «I avoid issues like AI can finish things in just 2 hours, but I have to spend 20 hours.»

Genau dort bricht die Messbarkeit. Wer die Aufgaben aussortiert, bei denen KI am meisten hilft, misst systematisch zu tief. METR räumt ein, dass die Ergebnisse den wahren Effekt wahrscheinlich unterschätzen. Dazu kommt: Manche Teilnehmenden liessen mehrere Agenten parallel laufen, was die Zeitmessung entwertet.

Wenn Sie gerade einen Business Case für KI-Werkzeuge schreiben und merken, dass Ihnen die belastbare Zahl fehlt: Das liegt nicht an Ihrer Recherche. Eine halbe Stunde mit jemandem, der die Primärquellen gelesen hat, ist an dieser Stelle billiger als eine weitere Woche Suche.

Die Gegenzahl aus dem anderen Lager stammt von 2022

Die berühmten 55 Prozent Beschleunigung sind eine Anbieterzahl aus dem Jahr 2022. GitHub Next veröffentlichte sie am 7. September 2022, gemeinsam mit dem Office of the Chief Economist von Microsoft. 95 Entwickelnde, zufällig in zwei Gruppen geteilt, eine einzige Aufgabe: einen HTTP-Server in JavaScript schreiben.

Die Copilot-Gruppe brauchte 1 Stunde 11 Minuten, die Kontrollgruppe 2 Stunden 41 Minuten. Das Konfidenzintervall reicht von 21 bis 89 Prozent.

Drei Dinge daran sollte man kennen, bevor man die Zahl in eine Präsentation setzt. Sie stammt vom Hersteller des getesteten Werkzeugs. Sie misst eine abgeschlossene Laboraufgabe ohne bestehende Codebasis, ohne Review und ohne Betrieb. Und sie ist vier Jahre alt, aus einer Zeit vor agentischen Werkzeugen.

Wer welche Zahl erhoben hat, und wer sie bezahlt hat

Die folgende Gegenüberstellung ordnet die sechs Zahlen, die in dieser Debatte tatsächlich zirkulieren, nach Herkunft, Finanzierung und Haltbarkeit. Stand aller Abrufe: 20. August 2026.

Zahl	Wer hat erhoben	Wer hat bezahlt	Stichprobe	Status im August 2026
55 % schneller	GitHub Next, Microsoft	GitHub, also Microsoft	95 Personen, eine Laboraufgabe	Anbieterzahl von 2022, für heutige Werkzeuge nicht gültig
19 % langsamer	METR	gemeinnützig, kein Anbieter	16 Personen, 246 Issues	von der eigenen Nachfolgestudie überholt
18 % bzw. 4 % schneller	METR	gemeinnützig, kein Anbieter	57 Personen, 143 Repos, 800+ Aufgaben	aktuell, aber Intervall schliesst null ein
KI wirkt als Verstärker	DORA	Google Cloud	State of DevOps 2025	letzter Stand, kein 2026er Report
3,45 % gegen 7,40 % Breaking Changes	Ferdous et al.	akademisch, arXiv	7’191 Agenten-PRs, 1’402 menschliche PRs	aktuell
Kontextdateien ohne Wirkung, +20 % Inferenzkosten	Gloaguen et al., ETH Zürich	akademisch, arXiv	SWE-bench plus reale Repositories	aktuell, revidiert Juni 2026

Die Finanzierungsspalte ist keine Höflichkeit. DORA ist ein Programm von Google Cloud, und Google verkauft mit Gemini, Jules und Antigravity konkurrierende Werkzeuge. Das macht die Methodik nicht schlecht, sie geniesst zu Recht Ansehen. Aber ein Report, der Firmen hilft, KI-Budgets zu verteidigen, hat einen Absender mit Interesse an KI-Budgets.

Der Verstärker-Befund ist die belastbarste Aussage der Forschung

Die stabilste Erkenntnis lautet, dass KI-Werkzeuge vorhandene Engineering-Reife verstärken statt sie zu ersetzen. DORA formuliert es im State of DevOps 2025 so: «AI acts as an amplifier, but the greatest returns come from focusing on the underlying sociotechnical systems.»

Zwei akademische Arbeiten aus 2026 zeigen denselben Mechanismus von unten. Die Untersuchung «Safer Builders, Risky Maintainers» von Ferdous, Banik, Chowdhury und Shamim verglich 7’191 agentenerzeugte Pull Requests mit 1’402 menschlichen aus Python-Repositories und erkannte Breaking Changes über eine AST-Analyse.

Kontext	Rate an Breaking Changes
Code-Generierung, Agenten	3,45 %
Code-Generierung, Menschen	7,40 %
Agenten beim Refactoring	6,72 %
Agenten bei Chore-Änderungen	9,35 %

Beim Neubau brechen Agenten seltener die Kompatibilität als Menschen. Bei Wartungsarbeiten kehrt sich das um. Die Autoren beschreiben zusätzlich eine «Confidence Trap»: Auch Pull Requests mit hohem Selbstvertrauens-Score des Agenten enthalten Breaking Changes. Der Score taugt nicht als Review-Filter.

Die zweite Arbeit, «(Im)Paired Programming» von Balepur und Kollegen, liess 54 Studierende eine Website bauen, mit einem Agenten oder mit einem Chatbot, und prüfte danach das Verständnis über Verständnisfragen und über eine Erweiterungsaufgabe ohne Agent. Befund: Agenten helfen beim Fertigwerden und schaden dem Verständnis, und ausgerechnet die bequemen Interaktionsformen, Copy-Paste-Prompts und automatisch akzeptierte Edits, korrelieren mit dem schlechtesten Verständnis. Die Einschränkung gehört dazu: 54 Studierende sind kein Engineering-Team.

Warum das die Verstärkerthese stützt: In beiden Arbeiten entscheidet nicht das Werkzeug, sondern wo und wie es eingesetzt wird. Dieselbe Beobachtung aus der Praxisseite, ohne Zahlen, steht in KI schreibt den Code, wer schreibt die Architektur.

Was die Spannweite für eine Kapazitätsplanung bedeutet

Das Konfidenzintervall der Zweitstudie ist zu breit, um damit zu budgetieren. Rechnen wir es einmal in Schweizer Franken durch, damit die Grössenordnung sichtbar wird.

Modellrechnung, keine Erhebung: ein Team von zehn Entwickelnden, 1’800 Arbeitsstunden pro Person und Jahr, also 18’000 Stunden. Als Stundensatz nehmen wir CHF 160, den Mittelwert aus dem publizierten Rechenbeispiel von gryps.ch für Softwareentwicklung in der Deutschschweiz (abgerufen 20. August 2026). Die Jahreskapazität entspricht damit CHF 2’880’000.

Szenario aus dem METR-Intervall	Zeitbedarf	Stunden pro Jahr	Gegenwert
Untere Intervallgrenze	−38 %	6’840 Stunden frei	CHF 1’094’400
Punktschätzer	−18 %	3’240 Stunden frei	CHF 518’400
Obere Intervallgrenze	+9 %	1’620 Stunden zusätzlich	CHF 259’200

Zwischen den beiden Intervallgrenzen liegen CHF 1’353’600. Mit einer solchen Bandbreite plant niemand ein Budget, und das ist die ehrliche Auskunft der Forschung, nicht ihr Versagen.

Die Rechnung überträgt METRs Werte bewusst grob auf eine Jahreskapazität. METR hat Issue-artige Aufgaben in reifen Open-Source-Repositories gemessen, keine vollständigen Arbeitsjahre mit Meetings, Betrieb und Incidents. Wer die Zahlen eins zu eins auf sein Team überträgt, macht denselben Fehler wie die Lager, die er kritisiert.

Messen Sie stattdessen Ihre eigene Basislinie

Die brauchbarste Reaktion auf eine unklare Studienlage ist eine eigene Vorher-Messung. Zwei Kennzahlen genügen für den Anfang, und beide liegen bereits in Ihrem Repository.

Erstens ein Proxy für die Change Failure Rate, aus dem Git-Log über 90 Tage:

# Alle Commits der letzten 90 Tage
git log --since="90 days ago" --no-merges --oneline | wc -l

# Davon Reverts und Hotfixes
git log --since="90 days ago" --no-merges --oneline \
  --grep="^Revert" --grep="^hotfix" --grep="^fix!" -i | wc -l

Zweitens die Grösse der Änderungen pro Autor, um agentenerzeugte und menschliche Pull Requests zu trennen:

gh pr list --state merged --limit 200 \
  --json number,author,additions,deletions,mergedAt \
  --jq '.[] | [.author.login, .additions + .deletions] | @tsv'

Erheben Sie beides einen Monat vor dem Rollout und drei Monate danach. Diese zwei Zahlen sagen mehr über Ihr Team aus als jede Studie in diesem Beitrag. Wie Sie die Entscheidungen dahinter festhalten, damit die Messung in einem Jahr noch interpretierbar ist, steht in Architekturentscheidungen dokumentieren.

Was es im August 2026 nicht gibt

Drei häufig erwartete Quellen existieren zum Zeitpunkt dieses Beitrags nicht, und wer sie zitiert, zitiert etwas Erfundenes.

Keinen State-of-DevOps-Report 2026. dora.dev/research führt 2025 als jüngsten Eintrag. Neu ist nur ein Zwischenprodukt, der «ROI of AI-assisted Software Development report», zuletzt aktualisiert am 22. April 2026, samt ROI-Rechner.
Keine Stack Overflow Developer Survey 2026. Das Archiv listet 2011 bis 2025. Die 2025er Ausgabe bleibt der Stand.
Keinen Technology Radar Vol. 35. Vol. 34 vom April 2026 ist die aktuelle Ausgabe, mit «Putting coding agents on a leash» als einem der vier Themen.

Wovon wir abraten

Wir raten von drei Dingen ab, und das erste betrifft die Zahlen in diesem Beitrag selbst. Erstens: einen ROI-Business-Case auf einen Punktschätzer stützen, gleich aus welchem Lager. Die belastbare Aussage der Forschung ist eine Bandbreite, kein Wert.

Zweitens: den Confidence-Score eines Agenten als Review-Filter benutzen. Die Confidence Trap aus «Safer Builders, Risky Maintainers» ist genau dieser Fehler, empirisch belegt. Staffeln Sie die Review-Tiefe stattdessen nach Aufgabentyp. Neubau darf lockerer laufen, Refactoring und Wartung brauchen strenge Kontrolle.

Drittens: Auto-Accept als Standardeinstellung. Nach «(Im)Paired Programming» ist es die Interaktionsform mit dem schlechtesten Verständnisergebnis.

Wo unsere Empfehlung nicht passt: bei Wegwerf-Prototypen und Spikes. Wer eine Woche lang eine Machbarkeit prüft und den Code danach löscht, braucht keine gestaffelte Review-Tiefe. Der Aufwand lohnt sich ab dem Moment, in dem jemand den Code in einem Jahr noch lesen muss.

Und ein Schweizer Detail, das in der internationalen Debatte untergeht: Die methodisch sauberste Arbeit zu Kontextdateien für Coding-Agenten kommt von der ETH Zürich. Gloaguen, Mündler, Müller, Raychev und Vechev zeigten im Februar 2026, revidiert im Juni, dass AGENTS.md-Dateien die Erfolgsrate generell nicht verbessern, die Inferenzkosten aber um über 20 Prozent erhöhen. Drei der Autoren sind mit LogicStar AG in Zürich verbunden, Martin Vechev leitet an der ETH das Secure, Reliable and Intelligent Systems Lab.

Häufige Fragen

Stimmt es, dass KI Entwickler 19 Prozent langsamer macht?

Das war der Befund einer METR-Studie von Februar bis Juni 2025 mit 16 erfahrenen Open-Source-Entwicklern. Die Nachfolgestudie derselben Organisation, ab August 2025 mit 57 Entwickelnden und über 800 Aufgaben, misst das Gegenteil: 18 Prozent weniger Zeitbedarf bei den wiederkehrenden Teilnehmenden. Wer die 19 Prozent heute als Beleg anführt, zitiert den überholten Stand.

Woher kommt die Zahl «55 Prozent schneller»?

Aus einer Untersuchung von GitHub Next und dem Office of the Chief Economist von Microsoft, publiziert am 7. September 2022. 95 Entwickelnde schrieben einen HTTP-Server in JavaScript, mit oder ohne Copilot. Es ist eine Anbieterzahl aus dem Jahr 2022, gemessen an einer einzelnen Laboraufgabe ohne bestehende Codebasis, ohne Review und ohne Betrieb.

Welche Aussage der Forschung ist am belastbarsten?

Der Verstärker-Befund. DORA formuliert im State of DevOps 2025, KI wirke als Verstärker und die grössten Erträge entstünden durch Arbeit an den zugrunde liegenden soziotechnischen Systemen. Zwei akademische Arbeiten aus 2026 zeigen denselben Mechanismus im Detail: Der Effekt hängt vom Aufgabentyp und von der Arbeitsweise ab, nicht vom Werkzeug.

Warum ist der Produktivitätseffekt so schwer zu messen?

Weil die Teilnehmenden die Messung beeinflussen. Als METR die Vergütung von 150 auf 50 Dollar pro Stunde senkte, gaben 30 bis 50 Prozent der Entwickelnden an, bestimmte Aufgaben nicht einzureichen, weil sie diese nicht ohne KI erledigen wollten. Wer genau die Aufgaben aussortiert, bei denen KI am meisten hilft, misst systematisch zu tief.

Was misst man im eigenen Team stattdessen?

Zwei Kennzahlen aus dem eigenen Repository, je einmal vor und drei Monate nach der Einführung: die Rate an Reverts und Hotfixes über 90 Tage als Proxy für die Change Failure Rate, und die Änderungsgrösse pro Autor, um agentenerzeugte von menschlichen Pull Requests zu trennen. Beide sind mit git log und gh pr list in wenigen Minuten erhoben.

Legen wir Ihre Zahlen daneben

Bringen Sie Ihre Git-Historie und die Frage mit, die Ihr Management Ihnen gestellt hat. Wir erheben die Basislinie gemeinsam und sagen Ihnen, welche der zitierten Studien auf Ihren Fall überhaupt zutrifft und welche nicht.

Termin buchen oder schreiben Sie uns. Womit wir Teams beim Einsatz dieser Werkzeuge begleiten, steht unter Künstliche Intelligenz & Machine Learning.

CRA-Meldepflicht ab 11.9.2026 technisch umsetzen

Ralph Segi — Fri, 28 Aug 2026 00:00:00 GMT

Die CRA-Meldepflicht trifft Hersteller von Produkten mit digitalen Elementen ab dem 11. September 2026: aktiv ausgenutzte Schwachstellen binnen 24 Stunden vorläufig melden, binnen 72 Stunden vollständig, den Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrekturmassnahme. Gemeldet wird nach Art. 14 Abs. 1 CRA gleichzeitig an das koordinierende CSIRT und an die ENISA, über eine einzige Einreichung.

Was ab dem 11. September 2026 konkret gilt

Artikel 14 der Verordnung (EU) 2024/2847 gilt ab dem 11. September 2026, die übrigen Herstellerpflichten erst ab dem 11. Dezember 2027. Die Meldepflicht kommt also fünfzehn Monate vor allem anderen, was einen Hersteller trifft. Wer auf die volle Anwendbarkeit wartet, hat die erste Frist bereits verpasst.

Ein drittes Datum geht dabei regelmässig unter: Kapitel IV zu den notifizierten Stellen (Artikel 35 bis 51) gilt schon seit dem 11. Juni 2026. Es betrifft die Konformitätsbewertungsstellen, nicht Sie als Hersteller.

Zwei Auslöser, zwei Fristenketten:

Auslöser	Frühwarnung	Meldung	Abschlussbericht
Aktiv ausgenutzte Schwachstelle im Produkt	24 h ab Kenntnis	72 h ab Kenntnis	14 Tage nach Verfügbarkeit einer Korrektur- oder Risikominderungsmassnahme
Schwerwiegender Sicherheitsvorfall	24 h ab Kenntnis	72 h ab Kenntnis	ein Monat nach der Vorfallmeldung

Die Frist läuft ab Kenntnis, nicht ab Bestätigung. Wer intern erst eine Freigaberunde dreht, verbrennt die Hälfte des Budgets. Verstösse gegen Artikel 13 und 14 sind nach Artikel 64 Absatz 2 CRA mit Bussgeldern bis 15 Mio. EUR oder 2,5 % des weltweiten Jahresumsatzes bewehrt, je nachdem, was höher ist.

Gilt der Cyber Resilience Act für Schweizer Unternehmen?

Ja, sobald ein Produkt mit digitalen Elementen in der EU in Verkehr gebracht wird. Der Sitz in Kreuzlingen, Zug oder Zürich ändert daran nichts. Interessant wird nur, an welches CSIRT ein Hersteller ohne Niederlassung in der Union meldet.

Artikel 14 Absatz 7 CRA löst das über eine Kaskade: massgeblich ist der Mitgliedstaat, in dem der Bevollmächtigte für die meisten Produkte sitzt. Fehlt der, der Einführer. Fehlt auch der, der Händler. Bleibt das offen, entscheidet der Mitgliedstaat mit den meisten Nutzern.

Das ist eine Architekturentscheidung, keine juristische Fussnote. Wer heute nicht weiss, welches nationale CSIRT zuständig ist, registriert sich am 11. September nicht mehr rechtzeitig.

Wohin die Meldung geht, und wer Ihre Gegenstelle ist

Die Meldung hat zwei Empfänger und wird trotzdem nur einmal abgesetzt. Artikel 14 Absatz 1 CRA verpflichtet den Hersteller, eine aktiv ausgenutzte Schwachstelle gleichzeitig dem als Koordinator benannten CSIRT und der ENISA zu melden. Für schwerwiegende Sicherheitsvorfälle sagt Absatz 3 dasselbe.

Der technische Weg ist einer. Nach Artikel 14 Absatz 7 CRA läuft die Meldung über den Meldeendpunkt des CSIRT, das im Mitgliedstaat der Hauptniederlassung als Koordinator benannt ist, und ist gleichzeitig für die ENISA zugänglich. Die Kommission fasst das auf ihrer Seite zu den CRA-Meldepflichten so: „Manufacturers report only once through the CRA Single Reporting Platform (SRP)”.

Wer zurückfragt, ist das CSIRT. Nach Artikel 14 Absatz 6 kann es einen Zwischenbericht verlangen, und es validiert vorab Ihren Zugang zur Plattform. Die ENISA baut und betreibt sie. Wer wissen will, bei wem er im Ernstfall anruft: beim CSIRT der Hauptniederlassung.

Für die Umsetzung sind drei Details aus der ENISA-FAQ zur SRP (Stand 3. August 2026) wichtiger als jede Rechtsfrage:

Es gibt vorerst keine API. Sie können den Weg bis zum Absenden automatisieren, das Absenden selbst tippt ein Mensch in ein Browserformular.
Die Registrierung läuft über EU Login (ecas.ec.europa.eu), die Validierung anschliessend über das zuständige CSIRT. Beides dauert und gehört vor den Ernstfall.
Die Plattform war Mitte August 2026 noch nicht live, die öffentliche URL noch nicht publiziert. Betriebsbereit soll sie zum 11. September sein.

Der letzte Meter Ihrer Kette ist also manuell. Umso wichtiger, dass die neunundvierzig Meter davor es nicht sind.

Zwei Behörden werden dabei regelmässig falsch einsortiert. Das BSI ist seit Oktober 2025 notifizierende und marktüberwachende Behörde für den CRA in Deutschland. Marktüberwachung ist aber nicht Meldungsentgegennahme.

Und das BACS ist im CRA-Kontext gar keine Adresse. Es ist die Adressatin der Schweizer ISG-Meldepflicht, eines eigenen Regimes mit eigener Rechtsgrundlage. Wer beides zusammenwirft, meldet an der falschen Stelle.

CRA-Meldepflicht und Schweizer ISG-Meldepflicht nebeneinander

Zwei Regime, zwei Adressaten, zwei Rechtsgrundlagen, beide mit einer 24-Stunden-Frist. Ein Schweizer Softwarehersteller, der in die EU liefert und dessen Produkte von Schweizer kritischen Infrastrukturen genutzt werden, fällt unter beide. Wir haben die Gegenüberstellung gebaut, weil wir sie nirgends gefunden haben. Jede Zeile ist am Gesetzestext belegt.

	CRA (EU)	ISG-Meldepflicht (CH)
Rechtsgrundlage	VO (EU) 2024/2847, Art. 14	ISG (SR 128), Art. 74a bis 74h, dazu CSV (SR 128.51)
Gilt seit	11.09.2026	01.04.2025, Sanktionen ab 01.10.2025
Wer meldet	Hersteller von Produkten mit digitalen Elementen	Betreiberinnen kritischer Infrastrukturen, darunter Herstellerinnen von Hard- oder Software, deren Produkte von kritischen Infrastrukturen genutzt werden, sofern mit Fernwartungszugang oder eingesetzt zur Steuerung und Überwachung betriebstechnischer Systeme oder für die öffentliche Sicherheit (Art. 74b Abs. 1 lit. u)
Auslöser	aktiv ausgenutzte Schwachstelle im Produkt oder schwerwiegender Vorfall	Cyberangriff auf die eigenen Informatikmittel nach vier Kriterien (Art. 74d)
Gegenstand	das ausgelieferte Produkt	der eigene Betrieb
Adressat	koordinierendes CSIRT der Hauptniederlassung und ENISA gleichzeitig, eine Einreichung (Art. 14 Abs. 1 und 7)	BACS
Kanal	CRA Single Reporting Platform, EU-Login-Konto, keine API	Meldeformular im Cyber Security Hub des BACS, alternativ E-Mail-Formular
Erstmeldung	24 h ab Kenntnis	24 h ab Entdeckung (Art. 74e Abs. 1)
Zweite Stufe	72 h	keine
Abschluss	14 Tage nach Verfügbarkeit der Korrektur, bei Vorfällen ein Monat	14 Tage zur Ergänzung, gewährt durch das BACS (Art. 16 Abs. 1 CSV)
Nutzer informieren	ja, Art. 14 Abs. 8, möglichst maschinenlesbar	nicht vorgesehen
Extraterritorial	ja, über Inverkehrbringen in der EU	ja, für Angriffe mit Auswirkung in der Schweiz, auch bei Systemen im Ausland (Art. 74b Abs. 3)
Sanktion	bis 15 Mio. EUR oder 2,5 % Weltjahresumsatz (Art. 64 Abs. 2)	Busse bis CHF 100’000 gegen natürliche Personen, subsidiär bis CHF 20’000 gegen den Geschäftsbetrieb (Art. 74h)
Durchsetzung	Marktüberwachungsbehörden der Mitgliedstaaten	BACS setzt Frist, erlässt dann eine Verfügung mit Strafdrohung; Verfolgung durch die Kantone (Art. 74g)

Der interessanteste Unterschied steht in der letzten Zeile. Der CRA sanktioniert das Versäumnis direkt. Das ISG sanktioniert es nicht: Nach Art. 74g ISG setzt das BACS zuerst eine Frist, erlässt dann eine Verfügung, und erst deren vorsätzliche Missachtung ist nach Art. 74h strafbar.

Dieselbe indirekte Konstruktion kennen wir aus dem revDSG, wo der EDÖB ebenfalls keine direkte Sanktionskompetenz hat. Wer die ISG-Meldepflicht deshalb für zahnlos hält, übersieht Art. 74h Abs. 1: Die Busse trifft natürliche Personen, nicht die GmbH.

Die Zahlen dazu kommen vom BACS selbst. Im Halbjahresbericht 2025/2 (publiziert 30.03.2026) verarbeitete das Amt 145 meldepflichtige Cybervorfälle im zweiten Halbjahr 2025, verteilt auf öffentlichen Sektor (25 %), IT und Telekommunikation (18 %) sowie Finanz und Versicherung (15,7 %). Daneben 64’733 freiwillige Meldungen im Gesamtjahr.

Was Sie bauen müssen, damit 24 Stunden reichen

Vier Artefakte müssen fertig sein, bevor die Uhr läuft. Keines lässt sich im Vorfall improvisieren.

Eine SBOM pro Release, unveränderlich gespeichert. Anhang I Teil II Nummer 1 CRA verlangt eine Software-Stückliste in einem gängigen maschinenlesbaren Format, die mindestens die Top-Level-Abhängigkeiten abdeckt. Das ist der Rechtsboden, nicht das Ziel: Wer bei transitiven Abhängigkeiten aufhört zu schauen, findet Log4Shell-Klassen nicht.
Eine rückwärtsgerichtete Auskunft. Die Frage im Ernstfall lautet nicht „ist die Bibliothek verwundbar”, sondern „welche ausgelieferten Versionen enthalten sie und wer betreibt die”. Das muss eine Abfrage sein, keine Rekonstruktion.
Ein Alarmpfad mit benannter Person. Nicht „das Security-Team”, sondern ein Name und eine Stellvertretung, mit Zugriff auf das registrierte EU-Login-Konto. Am Sonntag um drei.
Ein Incident-Log mit UTC-Zeitstempeln. Sie müssen nicht nur fristgerecht melden, Sie müssen es belegen können.

Fünf Jahre Support, ab dem 11. Dezember 2027

Artikel 13 Absatz 8 CRA legt den Unterstützungszeitraum auf mindestens fünf Jahre fest, kürzer nur, wenn das Produkt erwartbar kürzer im Einsatz ist. Fünf Jahre Security-Updates heissen fünf Jahre lauffähige Build-Pipeline für jeden noch unterstützten Release-Zweig. Das ist die teuerste Pflicht des ganzen CRA, und sie steht in keiner Meldefrist.

Wer nicht sicher ist, ob die eigene Kette von der Detektion bis zum abgesendeten Formular innerhalb eines Arbeitstags trägt, sollte sie einmal an einer echten, bereits behobenen Schwachstelle durchspielen und dabei mitstoppen. Als Übung ist das ein Nachmittag. Was auffällt, ist selten das Werkzeug und fast immer die Übergabe zwischen zwei Personen.

SBOM in der Pipeline: ein Aufbau, der rückwirkend Auskunft gibt

Die SBOM gehört an den Image-Digest gebunden, nicht an den Tag. Tags werden überschrieben, Digests nicht. Der folgende Workflow erzeugt beide gängigen Formate, prüft gegen CVE-Feeds und signiert das Ergebnis keyless über OIDC. Versionen vom August 2026: Syft v1.51.0, Grype v0.117.0, cosign v3.1.3.

# .github/workflows/release.yml
name: release
on:
  push:
    tags: ["v*"]

permissions:
  contents: read
  packages: write
  id-token: write            # keyless signing, kein Schlüsselmaterial im Repo

jobs:
  sbom:
    runs-on: ubuntu-24.04
    env:
      IMAGE: ghcr.io/${{ github.repository }}
    steps:
      - uses: actions/checkout@v7

      - uses: docker/login-action@v4
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Bauen, pushen, Digest festhalten
        run: |
          docker build -t "$IMAGE:$GITHUB_REF_NAME" .
          docker push "$IMAGE:$GITHUB_REF_NAME"
          DIGEST=$(docker buildx imagetools inspect "$IMAGE:$GITHUB_REF_NAME" \
                     --format '{{ .Manifest.Digest }}')
          echo "REF=$IMAGE@$DIGEST" >> "$GITHUB_ENV"

      - name: Werkzeuge auf feste Versionen pinnen
        run: |
          curl -sSfL https://get.anchore.io/syft  | sh -s -- -b /usr/local/bin v1.51.0
          curl -sSfL https://get.anchore.io/grype | sh -s -- -b /usr/local/bin v0.117.0

      - uses: sigstore/cosign-installer@v4
        with:
          cosign-release: v3.1.3

      - name: SBOM in beiden Formaten erzeugen
        run: |
          syft registry:"$REF" \
            -o cyclonedx-json=sbom.cdx.json \
            -o spdx-json=sbom.spdx.json

      - name: Gegen CVE-Feeds prüfen, Build bei Kritischem stoppen
        run: grype "sbom:sbom.cdx.json" --fail-on critical

      - name: SBOM an den Digest binden und signieren
        run: cosign attest --yes --type cyclonedx --predicate sbom.cdx.json "$REF"

      - uses: actions/upload-artifact@v7
        with:
          name: sbom-${{ github.ref_name }}
          path: sbom.*.json
          retention-days: 90       # GitHubs Maximum, deshalb nur ein Puffer

Der upload-artifact-Schritt ist die schwächste Stelle und bewusst so gelassen: Produktiv gehören die SBOMs in einen Objektspeicher mit Versionierung und Object Lock, abfragbar nach Komponente. GitHub-Artefakte sind ein Zwischenschritt, kein Archiv. Mehr dazu in unserer Arbeit an CI/CD und Supply Chain.

Das Incident-Log, das Ihre Frist belegt

Ein Incident-Log ist kein Ticket-Verlauf, sondern ein append-only Ereignisstrom mit UTC-Zeitstempeln. NDJSON reicht, eine Zeile pro Ereignis, ts immer zuerst. Entscheidend ist der maschinell festgehaltene Zeitpunkt der Kenntnisnahme, den niemand später aus einer Slack-Historie rekonstruieren muss. Dieselbe Disziplin verlangt das revDSG für Personendaten; wie ein Audit-Log aussieht, das eine Auskunftsanfrage übersteht, haben wir separat beschrieben.

{"ts":"2026-09-14T07:12:41Z","event":"aware","incident":"INC-2026-0007","cve":"CVE-2026-31337","product":"acme-gateway","affected_versions":["3.4.0","3.4.1"],"component":"pkg:golang/github.com/example/parser@1.8.2","evidence":"WAF-Signatur 8841, 3 Treffer aus 2 Quell-ASN","actively_exploited":true,"detected_by":"grype-nightly+SIEM","owner":"r.segi"}
{"ts":"2026-09-14T07:41:02Z","event":"triaged","incident":"INC-2026-0007","regime":["cra","isg"],"cra_trigger":"actively_exploited_vulnerability","due_early_warning":"2026-09-15T07:12:41Z","due_notification":"2026-09-17T07:12:41Z","csirt":"NCSC-NL","owner":"r.segi"}
{"ts":"2026-09-14T09:03:55Z","event":"reported","incident":"INC-2026-0007","channel":"eu-srp","stage":"early_warning","reference":"SRP-2026-114872","elapsed_h":1.85,"submitted_by":"r.segi"}
{"ts":"2026-09-14T10:26:33Z","event":"reported","incident":"INC-2026-0007","channel":"ch-bacs-csh","stage":"erstmeldung","reference":"BACS-2026-3391","elapsed_h":3.23,"submitted_by":"r.segi"}
{"ts":"2026-09-14T11:48:07Z","event":"users_informed","incident":"INC-2026-0007","format":"csaf-2.0","url":"https://acme.example/security/ACME-SA-2026-004"}

Die Fristen im triaged-Ereignis werden gerechnet, nicht getippt. Das ist eine Funktion, kein Kalendereintrag:

// Fristen nach Art. 14 CRA, gerechnet ab Kenntnisnahme in UTC.
type Deadlines struct {
	EarlyWarning time.Time // 24 h ab Kenntnis
	Notification time.Time // 72 h ab Kenntnis
	Final        time.Time // 14 Tage nach Verfügbarkeit der Korrekturmassnahme
}

func CRADeadlines(awareAt, fixAvailableAt time.Time) Deadlines {
	awareAt = awareAt.UTC()
	return Deadlines{
		EarlyWarning: awareAt.Add(24 * time.Hour),
		Notification: awareAt.Add(72 * time.Hour),
		Final:        fixAvailableAt.UTC().AddDate(0, 0, 14),
	}
}

Warum der Aufwand für ein Log, das hoffentlich nie gebraucht wird: Weil im Streitfall die Beweislast bei Ihnen liegt. Wer das Prinzip vertiefen will, findet es in Observability, die man liest und in Architektur-Entscheidungen dokumentieren ausgeführt.

Was Sie jetzt nicht tun sollten

Kaufen Sie kein Compliance-Tool, bevor Sie die Meldekette einmal an einer echten Schwachstelle durchgespielt haben. Bei dieser Empfehlung bekommen wir am häufigsten Widerspruch, und wir bleiben dabei.

Der Markt für CRA-Plattformen ist seit Frühjahr 2026 laut, und die Produkte lösen fast alle dasselbe Problem: Sie erzeugen Dokumente. Das Problem, das Ihnen die Frist reisst, ist die Stunde zwischen „ein Alert ist aufgelaufen” und „jemand mit Zugang hat entschieden, dass das meldepflichtig ist”.

Der Trade-off, ehrlich benannt: Ein Werkzeug ist in zwei Wochen eingekauft, die Probe kostet einen Nachmittag plus die Korrekturen danach. Wer im September 2026 noch gar nichts hat, fährt mit gekauftem Werkzeug plus Probe besser.

Wo unsere Empfehlung nicht passt: Bei mehr als einer Handvoll Produktlinien mit unterschiedlichen Bevollmächtigten in der EU wird „welches Produkt meldet an welches CSIRT” zur Datenhaltungsfrage. Dann ist ein Werkzeug ab Tag eins richtig. Bei einem Produkt und einem CSIRT ist es Geldverbrennung.

Das Zweite, was Sie nicht tun sollten: die Registrierung auf den Ernstfall verschieben. EU Login anlegen, CSIRT bestimmen, Validierung anstossen. Ein Vormittag, und die einzige Aufgabe, die sich am 11. September nicht nachholen lässt.

Häufige Fragen

Ab wann gilt die CRA-Meldepflicht?

Ab dem 11. September 2026, über Artikel 14 der Verordnung (EU) 2024/2847. Dann laufen drei Fristen: 24 Stunden bis zur Frühwarnung, 72 Stunden bis zur vollständigen Meldung, 14 Tage nach Verfügbarkeit einer Korrekturmassnahme bis zum Abschlussbericht, bei Vorfällen ein Monat.

Die übrigen Herstellerpflichten werden erst am 11. Dezember 2027 anwendbar. Kapitel IV zu den notifizierten Stellen gilt bereits seit dem 11. Juni 2026.

Wer muss nach dem CRA melden?

Der Hersteller des Produkts mit digitalen Elementen, unabhängig vom Sitz, sobald das Produkt in der EU in Verkehr gebracht wird. Meldepflichtig sind aktiv ausgenutzte Schwachstellen im Produkt und schwerwiegende Sicherheitsvorfälle, die dessen Sicherheit beeinträchtigen. Bestandsprodukte sind eingeschlossen. Zusätzlich müssen betroffene Nutzer informiert werden, nach Artikel 14 Absatz 8 möglichst in einem strukturierten, maschinell verarbeitbaren Format.

Was ist eine SBOM und wofür brauche ich sie?

Eine SBOM (Software Bill of Materials) ist ein maschinenlesbares Inventar aller Komponenten eines Software-Artefakts, üblicherweise im Format CycloneDX oder SPDX. Der CRA verlangt sie in Anhang I Teil II Nummer 1 mindestens für die Top-Level-Abhängigkeiten. Praktisch brauchen Sie sie, um innerhalb von Stunden zu beantworten, welche ausgelieferten Versionen eine gerade bekannt gewordene verwundbare Komponente enthalten.

Muss ein Schweizer Unternehmen doppelt melden?

Möglicherweise ja, aber an verschiedene Stellen und aus verschiedenen Gründen. Der CRA adressiert Sie als Hersteller eines EU-Produkts und meint dessen Schwachstellen. Die ISG-Meldepflicht adressiert Sie als Betreiberin kritischer Infrastruktur und meint Angriffe auf Ihre eigenen Systeme. Ein Ransomware-Vorfall in Ihrem Build-System kann beides gleichzeitig auslösen.

Was passiert, wenn die Single Reporting Platform am 11. September nicht läuft?

Die Meldepflicht entsteht aus Artikel 14, nicht aus der Verfügbarkeit der Plattform. Mitte August 2026 war die SRP noch nicht live und ihre URL noch nicht publiziert. Protokollieren Sie den Zeitpunkt der Kenntnisnahme und jeden Zustellversuch, samt Vermerk, wenn eine Einreichung technisch nicht möglich war. In dieser Lage ist ein lückenloses Log das einzige, was Sie in der Hand haben.

Wenn die Kette noch nicht steht. Bis zum 11. September bleiben zwei Wochen, bis zur ersten realistischen Meldung vermutlich länger. Wenn Sie wissen wollen, ob Ihre Kette von der Detektion bis zum abgesendeten Formular trägt: 30 Minuten mit einem Engineer, der SBOM-Pipelines gebaut und in regulierten Umgebungen wie dem Formularservice für das BIT gearbeitet hat. Kein Verkaufsgespräch, keine Folien.

Termin direkt buchen oder kurz über Kontakt schreiben, was Sie bauen. Wir sagen Ihnen, wo wir die Frist reissen sehen.

Alle Rechtsangaben geprüft am 19.08.2026 an EUR-Lex und Fedlex. Dieser Beitrag beschreibt die technische Umsetzung, er ist keine Rechtsberatung.

revDSG-konforme KI-Architektur: was wirklich zählt

Robert Pupel — Thu, 27 Aug 2026 00:00:00 GMT

Unter dem revidierten Datenschutzgesetz haftet für einen Verstoss die handelnde natürliche Person mit einer Busse bis CHF 250’000, nicht das Unternehmen. Das ist der Unterschied zur DSGVO, der die meisten Architekturentscheide prägt, und er steht nicht im Pflichtenkatalog, sondern im Strafrecht.

Verboten ist der Einsatz von KI damit nicht. Das revDSG verlangt vier Dinge: eine zweckgebundene Bearbeitung nach den Grundsätzen von Art. 6 DSG, Transparenz über die Beschaffung nach Art. 19, Datensicherheit nach Art. 8 in Verbindung mit der Datenschutzverordnung (DSV), und bei automatisierten Einzelentscheidungen das Recht auf Überprüfung durch eine natürliche Person nach Art. 21.

Die Rechtsabteilung fragt nach Konformität. Was man dazu findet, sind Gutachten: Sie sagen, was gilt, nicht, welche technische Massnahme das erfüllt. Hier steht die zweite Hälfte.

Welche vier Anforderungen stellt das revDSG an ein KI-System?

Das revDSG ist das totalrevidierte Bundesgesetz über den Datenschutz vom 25. September 2020 (SR 235.1), in Kraft seit dem 1. September 2023. Vier seiner Normen bestimmen, wie ein KI-System gebaut sein muss. Verbindlich ist der Gesetzestext auf Fedlex, keine Zusammenfassung.

Art. 6 DSG, Grundsätze. Personendaten dürfen nur zu einem bestimmten, erkennbaren Zweck beschafft werden und müssen weg, sobald sie dafür nicht mehr erforderlich sind. Der Zweck muss pro Verarbeitungsschritt festhaltbar sein, nicht pro Produkt.
Art. 19 DSG, Informationspflicht. Die betroffene Person erfährt Identität des Verantwortlichen, Zweck und Kategorien der Empfänger. Ein Inferenzanbieter ist ein Empfänger. Geht es ins Ausland, kommen nach Abs. 4 der Staat und die Garantien nach Art. 16 Abs. 2 dazu.
Art. 8 DSG, Datensicherheit. Die Mindestanforderungen stehen in der DSV. Art. 2 DSV nennt vier Ziele: Vertraulichkeit, Verfügbarkeit, Integrität, Nachvollziehbarkeit. Am vierten scheitern KI-Systeme.
Art. 21 DSG, automatisierte Einzelentscheidung. Beruht ein Entscheid ausschliesslich auf automatisierter Bearbeitung und ist er mit einer Rechtsfolge verbunden oder beeinträchtigt er die betroffene Person erheblich, gilt eine Informationspflicht. Die betroffene Person kann verlangen, dass ein Mensch den Entscheid überprüft.

Dazu kommt Art. 7 DSG: Die Bearbeitung ist ab der Planung technisch so auszugestalten, dass die Vorschriften eingehalten werden. Der Artikel, der die Rechtsfrage zur Architekturfrage macht.

Wer zahlt die Busse, wenn ein KI-System gegen das revDSG verstösst?

Die natürliche Person zahlt, nicht das Unternehmen. Art. 60 bis 62 DSG stellen private Personen mit Busse bis CHF 250’000 unter Strafe. Der Geschäftsbetrieb kommt nur subsidiär ins Spiel: Nach Art. 64 Abs. 2 DSG kann die Behörde ihn statt der handelnden Personen verurteilen, wenn eine Busse von höchstens CHF 50’000 in Betracht fällt.

Die für ein KI-Projekt einschlägige Norm ist meist nicht Art. 60, sondern Art. 61 DSG, Verletzung von Sorgfaltspflichten. Er trifft genau die drei Fehler, die eine Architektur macht:

Bekanntgabe ins Ausland entgegen Art. 16 Abs. 1 und 2, ohne dass die Voraussetzungen nach Art. 17 erfüllt sind (lit. a)
Übergabe an einen Auftragsbearbeiter entgegen Art. 9 Abs. 1 und 2 (lit. b)
Mindestanforderungen an die Datensicherheit nach Art. 8 Abs. 3 nicht eingehalten (lit. c)

Der EDÖB verhängt diese Bussen nicht. Nach Art. 65 Abs. 1 DSG obliegen Verfolgung und Beurteilung den Kantonen, in der Regel den Staatsanwaltschaften. Er kann verfügen und Anzeige erstatten, wie er auf seiner Seite zu den Strafbestimmungen selbst festhält.

Punkt	revDSG	DSGVO
Sanktionsadressat	die handelnde natürliche Person (Art. 60 bis 62 DSG); der Geschäftsbetrieb nur subsidiär (Art. 64 Abs. 2)	der Verantwortliche oder Auftragsverarbeiter als Unternehmen (Art. 83)
Bussenhöhe	bis CHF 250’000; Unternehmensbusse bis CHF 50’000	bis EUR 20 Mio. oder 4 % des weltweiten Jahresumsatzes, je nachdem, was höher ist (Art. 83 Abs. 5)
Verschulden	nur Vorsatz; Art. 60 Abs. 1, 61 und 62 sind Antragsdelikte	auch Fahrlässigkeit wird sanktioniert (Art. 83 Abs. 2 lit. b)
Wer verfolgt	kantonale Strafverfolgungsbehörden (Art. 65 Abs. 1); der EDÖB verfügt, sanktioniert aber nicht	die Aufsichtsbehörde verhängt die Geldbusse selbst
Meldung einer Sicherheitsverletzung	„so rasch als möglich” an den EDÖB, wenn voraussichtlich hohes Risiko (Art. 24 Abs. 1)	unverzüglich, möglichst binnen 72 Stunden (Art. 33 Abs. 1)
Automatisierte Einzelentscheidung	zulässig; Informationspflicht, auf Antrag Überprüfung durch einen Menschen (Art. 21)	grundsätzlich untersagt, zulässig nur in den Fällen von Art. 22 Abs. 2
Auftragsbearbeitung	Voraussetzungen in Art. 9; Unterauftrag nur mit vorgängiger Genehmigung (Art. 9 Abs. 3)	detaillierter Pflichtkatalog für den Vertrag (Art. 28)
Verjährung der Strafverfolgung	fünf Jahre (Art. 66)	in der DSGVO nicht geregelt, richtet sich nach nationalem Recht

Praktische Folge: Unter der DSGVO ist Compliance ein Bilanzrisiko und wird delegiert. Unter dem revDSG ist sie persönlich. Wer ein Agentensystem freigibt, unterschreibt mit seinem Namen.

Was ändert sich bei besonders schützenswerten Personendaten?

Bei besonders schützenswerten Personendaten verschärfen sich drei Pflichten. Art. 5 lit. c DSG zählt die Kategorien abschliessend auf: Gesundheit, Intimsphäre und Zugehörigkeit zu einer Rasse oder Ethnie, genetische Daten, biometrische Daten, die eine Person eindeutig identifizieren, religiöse, weltanschauliche, politische oder gewerkschaftliche Ansichten, Daten über verwaltungs- und strafrechtliche Verfolgungen sowie Daten über Massnahmen der sozialen Hilfe.

Die Einwilligung muss ausdrücklich sein (Art. 6 Abs. 7 lit. a DSG). Ein Hinweis in der Nutzungsordnung genügt nicht.
Datenschutz-Folgenabschätzung bei umfangreicher Bearbeitung (Art. 22 Abs. 2 lit. a DSG).
Protokollierung, wenn sie in grossem Umfang automatisiert bearbeitet werden oder ein Profiling mit hohem Risiko stattfindet, und präventive Massnahmen den Datenschutz nicht gewährleisten können (Art. 4 Abs. 1 DSV). Beide Bedingungen müssen zusammenkommen.
Bearbeitungsreglement bereits dann, wenn sie in grossem Umfang bearbeitet werden oder ein Profiling mit hohem Risiko stattfindet (Art. 5 Abs. 1 DSV). Ohne die Einschränkung der Protokollierungspflicht.

Der Haken für ein Agentensystem ist die Klassifikation zur Laufzeit. Ein Freitext-Prompt aus einem HR- oder Supportkanal enthält solche Daten, ohne dass ein Datenbankfeld sie markiert. Wer sie nicht erkennt, protokolliert zu wenig. Deshalb führt das Audit-Log unten ein Feld data_classes.

Wo landen Personendaten in einem Agentensystem tatsächlich?

Personendaten landen an sieben Stellen, und das Modell ist die harmloseste davon. Souveränität bricht fast nie beim Inferenzanbieter, sondern an der Peripherie, weil dort niemand hinschaut.

Prompt. Was die Nutzerin eintippt. Der einzige Ort, an dem die meisten Konzepte hinsehen.
Systemkontext. Retrieval-Ergebnisse, Few-Shot-Beispiele, Stammdaten aus dem CRM. Oft mehr Personendaten als im Prompt, und niemand hat sie bewusst dorthin gegeben.
Tool-Aufrufe. Der Agent ruft eine API mit Argumenten auf. Diese Argumente sind Personendaten und gehen an ein zweites System.
Vektordatenbank. Ein Vektorindex über Kundenkorrespondenz ist eine Personendatensammlung mit ungewohntem Dateiformat und braucht dieselben Löschpfade wie die Quelle.
Logs. Ein Stacktrace enthält den Payload, ein Debug-Log den ganzen Prompt.
Telemetrie. Die GenAI-Semantikkonventionen von OpenTelemetry definieren gen_ai.input.messages, gen_ai.output.messages und gen_ai.system_instructions als Span-Attribute. Sie stehen auch nach dem Umzug in ein eigenes Repository mit Release v1.42.0 vom 12.06.2026 im Status „Development” (Attributregister) und transportieren den vollständigen Gesprächsinhalt.
Monitoring- und Eval-SaaS. Error-Tracking, Tracing, Prompt-Evaluation. Drei Dienste, die selten in einer Vertragsprüfung auftauchen und oft im Drittstaat laufen.

Die gepunkteten Kanten sind Bekanntgaben ins Ausland, die in keinem Konzept stehen. Wer seinen Datenfluss so aufzeichnet, findet meist zwei oder drei.

Zeichnen Sie Ihren eigenen Fluss einmal so auf. Das dauert eine Stunde und ist die billigste Datenschutz-Massnahme, die wir kennen. Wenn Sie dabei jemanden am Whiteboard wollen, der die Peripherie schon kennt: eine halbe Stunde, ohne Vorbereitung.

Wie sich derselbe Datenfluss auf der Infrastrukturebene aufbauen lässt, mit Anbietervergleich und GPU-Kosten in CHF, steht in souveräne KI-Inferenz in der Schweiz.

Was heisst „Hosting in der Schweiz” technisch, und wo hört es auf?

„Hosting in der Schweiz” beschreibt den Speicherort, nicht die Zugriffsmöglichkeit. Beides fällt auseinander, sobald der Anbieter eine Muttergesellschaft in einem Drittstaat hat, sein Support aus einer anderen Zeitzone eskaliert oder sein Control Plane anderswo läuft. Zugriff von aussen ist eine Bekanntgabe ins Ausland nach Art. 16 DSG.

Die Prüfung ist zweistufig: Steht der Empfängerstaat in Anhang 1 DSV? Falls nein, braucht es eine Garantie nach Art. 16 Abs. 2, etwa vom EDÖB anerkannte Standarddatenschutzklauseln.

Für die USA gilt eine Zwischenlage, die häufig falsch wiedergegeben wird. Seit dem 15.09.2024 gelten sie als Staat mit angemessenem Datenschutz, aber nur für Unternehmen mit Zertifizierung nach dem Swiss-U.S. Data Privacy Framework (EDÖB). Zertifiziert wird pro Unternehmen, nicht pro Land.

Daraus folgen drei technische Konsequenzen:

Egress wird erzwungen, nicht vereinbart. Eine Allowlist auf Netzwerkebene ist der einzige Nachweis, der eine Prüfung übersteht.
Der Inferenz-Endpunkt gehört hinter eine eigene Abstraktion. Wer gegen ein Anbieter-SDK programmiert, kann nicht wechseln, wenn die Zertifizierung fällt.
Jede ausgehende Verbindung braucht eine hinterlegte Jurisdiktion. Bei AIgent ist das Startbedingung: Ein Endpunkt ohne Jurisdiktionsangabe läuft nicht an.

Wie sitzt das Human-in-the-Loop-Gate im Agent-Graph?

Das Gate sitzt zwischen Entscheidung und Wirkung, nicht zwischen Modellantwort und Entscheidung. Art. 21 Abs. 2 DSG verlangt die Überprüfung durch eine natürliche Person, und überprüfbar ist ein Entscheid nur, solange er nicht vollzogen ist. Eine Freigabe nach dem Versand der Absage erfüllt die Norm nicht.

Entscheidend ist das Verhalten bei Zeitablauf: Ein Gate, das nach einem Timeout durchlässt, ist kein Gate.

package hitl

import (
	"context"
	"errors"
	"fmt"
	"time"
)

// Decision ist der Vorschlag des Agenten, bevor er wirksam wird.
type Decision struct {
	RunID       string
	SubjectRef  string   // Pseudonym der betroffenen Person, nie der Klarname
	Action      string   // z. B. "antrag.ablehnen"
	Rationale   string   // Begründung für die prüfende Person
	DataClasses []string // z. B. []string{"bonitaet", "beschaeftigung"}
}

// Review ist das Ergebnis der Prüfung durch eine natürliche Person.
type Review struct {
	ReviewerID string
	Approved   bool
	Comment    string
	At         time.Time
}

type Auditor interface {
	Append(ctx context.Context, runID, event string, payload any) error
}

type ReviewQueue interface {
	Await(ctx context.Context, d Decision) (Review, error)
}

var (
	ErrExpired  = errors.New("hitl: keine Freigabe innerhalb der Frist, Entscheid verworfen")
	ErrRejected = errors.New("hitl: durch prüfende Person abgelehnt")
)

// Gate hält eine automatisierte Einzelentscheidung nach Art. 21 DSG an, bis
// eine natürliche Person sie bestätigt hat. Läuft die Frist ab, gilt die
// Entscheidung als nicht getroffen. Es gibt keinen Pfad, auf dem ein Timeout
// zu einer stillen Freigabe führt.
func Gate(ctx context.Context, a Auditor, q ReviewQueue, d Decision, wait time.Duration) error {
	if err := a.Append(ctx, d.RunID, "decision.proposed", d); err != nil {
		return fmt.Errorf("audit: %w", err)
	}

	waitCtx, cancel := context.WithTimeout(ctx, wait)
	defer cancel()

	r, err := q.Await(waitCtx, d)
	if err != nil {
		// Der Abbruchgrund gehört ins Log, auch wenn der Kontext bereits tot ist.
		_ = a.Append(context.WithoutCancel(ctx), d.RunID, "decision.expired", err.Error())
		return ErrExpired
	}

	event := "decision.rejected"
	if r.Approved {
		event = "decision.approved"
	}
	if err := a.Append(ctx, d.RunID, event, r); err != nil {
		return fmt.Errorf("audit: %w", err)
	}
	if !r.Approved {
		return fmt.Errorf("%w: %s", ErrRejected, r.ReviewerID)
	}
	return nil
}

Zwei Dinge sind bewusst gesetzt. Der Vorschlag wird protokolliert, bevor jemand ihn sieht; sonst lässt sich nicht belegen, dass eine Prüfung stattfand. Und Decision trägt ein Pseudonym statt eines Namens: Die prüfende Person löst die Identität über ihre eigene Berechtigung auf. Dieselbe Trennung, die wir in Architektur-Entscheidungen dokumentieren als Schnittstellenfrage behandeln, ist hier eine Datenschutzfrage.

Wie sieht ein Audit-Log aus, das eine Auskunftsanfrage übersteht?

Ein revDSG-taugliches Audit-Log beantwortet pro betroffener Person, welche Personendaten wann, von wem und wozu bearbeitet wurden. Art. 4 Abs. 4 DSV nennt die Pflichtfelder: Identität der bearbeitenden Person, Art, Datum und Uhrzeit, gegebenenfalls den Empfänger. Abs. 5 verlangt mindestens ein Jahr Aufbewahrung, getrennt vom System, in dem die Personendaten bearbeitet werden. Wer Software in die EU liefert, braucht daneben ab September 2026 ein zweites, ähnlich gebautes Log: das Incident-Log für die CRA-Meldepflicht.

-- Eigene Datenbank, eigene Credentials, eigener Backup-Zyklus.
-- Art. 4 Abs. 5 DSV verlangt die Trennung vom bearbeitenden System.
CREATE TABLE agent_audit (
    id           bigserial PRIMARY KEY,
    occurred_at  timestamptz NOT NULL DEFAULT now(),  -- Art. 4 Abs. 4 DSV
    run_id       uuid        NOT NULL,
    actor        text        NOT NULL,  -- 'user:4711', 'agent:triage@2.3.1', 'reviewer:rp'
    operation    text        NOT NULL   -- die sechs Vorgänge aus Art. 4 Abs. 1 DSV
        CHECK (operation IN ('speichern','veraendern','lesen',
                             'bekanntgeben','loeschen','vernichten')),
    subject_ref  text        NOT NULL,  -- Pseudonym, auflösbar nur im Identitätsdienst
    data_classes text[]      NOT NULL,  -- welche Kategorien, nicht welche Inhalte
    recipient    text,                  -- 'llm:apertus@ch-inference', 'crm:abacus'
    jurisdiction char(2)     NOT NULL,  -- 'CH', 'EU', 'US'
    purpose      text        NOT NULL,  -- Art. 6 Abs. 3 DSG nachweisbar halten
    payload_sha  bytea       NOT NULL   -- Hash statt Inhalt
);

-- Auskunftsbegehren nach Art. 25 DSG in einer Abfrage beantwortbar machen.
CREATE INDEX ON agent_audit (subject_ref, occurred_at DESC);
CREATE INDEX ON agent_audit (run_id);

Die Zeile, die am häufigsten fehlt, ist payload_sha. Ein Audit-Log mit dem Prompt im Klartext ist eine zweite Kopie der Personendaten, die ein Jahr liegen bleiben muss. Der Trade-off: Der Hash belegt die Bearbeitung, aber niemand kann nachlesen, was drinstand.

Hier stossen zwei Normen aufeinander. Art. 6 Abs. 4 DSG verlangt Vernichtung, sobald die Daten nicht mehr erforderlich sind; Art. 4 Abs. 5 DSV verlangt ein Jahr Aufbewahrung des Protokolls. Das löst sich nur mit getrennten Lebenszyklen, wie im Formularservice für das BIT.

Wovon wir abraten

Vom Enterprise-Abo als Konformitätsnachweis. Ein Enterprise-Tarif regelt, ob der Anbieter Ihre Daten zum Training verwendet. Das ist die einzige der vier Anforderungen, die er für Sie erfüllen kann. Zweckbindung, Informationspflicht, Nachvollziehbarkeit und Überprüfbarkeit nach Art. 21 entstehen in Ihrem System, nicht in seinem Vertrag.

Von Prompt-Inhalten in der allgemeinen Observability. Wer gen_ai.input.messages in dasselbe Trace-Backend schreibt wie seine HTTP-Spans, hat den Gesprächsinhalt in einem System, dessen Retention nach Kosten eingestellt ist. Prompts gehören ins Audit-Log, nicht in die Telemetrie.

Und der Trade-off, den wir offen benennen: Selbsthostung des Modells kostet Geschwindigkeit. Sie betreiben GPU-Kapazität, hinken bei Modellfähigkeiten hinterher und verlagern Aufwand von einer Rechnung in ein Team.

Ein Inferenzanbieter aus einem Staat in Anhang 1 DSV, kombiniert mit strenger Kontrolle der Peripherie, erfüllt dieselben vier Anforderungen mit weniger Betriebsaufwand. Selbsthostung ist die richtige Antwort bei besonders schützenswerten Personendaten, etwa Gesundheitsdaten, und wie das geht, steht in souveräne KI-Inferenz in der Schweiz. Für einen internen Wissensassistenten ist sie die falsche.

Wie in der KI-gestützten Entwicklung: Die Leitplanken stehen im Repository, nicht im Kopf.

Häufige Fragen

Brauche ich einen Auftragsbearbeitungsvertrag für einen KI-Anbieter?

Ja, sobald er Personendaten in Ihrem Auftrag bearbeitet, und das tut jeder gehostete Inferenzdienst. Art. 9 Abs. 1 DSG erlaubt die Übertragung nur, wenn die Daten so bearbeitet werden, wie Sie sie selbst bearbeiten dürften. Regelmässig gerissen wird Abs. 3: Unteraufträge brauchen Ihre vorgängige Genehmigung. Prüfbar ist das über die versionierte Subprozessorenliste, nicht über den Vertragstext.

Darf ich Personendaten in ChatGPT eingeben?

Rechtlich möglich, technisch selten sauber. Nötig sind eine Bearbeitung nach den Grundsätzen von Art. 6 DSG, eine Auftragsbearbeitung nach Art. 9, die Information nach Art. 19 inklusive Empfängerstaat und, falls der Anbieter nicht Swiss-U.S.-DPF-zertifiziert ist, eine Garantie nach Art. 16.

Welche Strafnorm greift, hängt davon ab, was fehlt: bei der Garantie Art. 61 lit. a, bei der Auftragsbearbeitung Art. 61 lit. b, bei der Information Art. 60 Abs. 1 lit. b.

Reicht ein Enterprise-Abo für revDSG-Konformität?

Nein. Ein Enterprise-Abo regelt die Trainingsnutzung und meist die Datenresidenz. Es erzeugt weder das Protokoll nach Art. 4 DSV noch die Überprüfbarkeit nach Art. 21 DSG, und es sagt nichts über Ihre Vektordatenbank, Ihre Logs und Ihr Monitoring.

Brauchen wir eine Datenschutz-Folgenabschätzung für einen KI-Assistenten?

Wenn die Bearbeitung ein hohes Risiko für Persönlichkeit oder Grundrechte mit sich bringen kann, ja (Art. 22 Abs. 1 DSG). Abs. 2 nennt zwei Regelfälle: umfangreiche Bearbeitung besonders schützenswerter Personendaten und systematische Überwachung umfangreicher öffentlicher Bereiche. Bleibt trotz Massnahmen ein hohes Risiko, ist der EDÖB zu konsultieren (Art. 23).

Gilt der EU AI Act für unser Schweizer Unternehmen?

Er kann extraterritorial greifen. Art. 2 Abs. 1 lit. c der KI-Verordnung erfasst Anbieter und Betreiber aus Drittstaaten, wenn das Ergebnis des KI-Systems in der Union verwendet wird. Die Pflichten für Hochrisikosysteme nach Anhang III gelten seit der Verordnung (EU) 2026/1744 erst ab 02.12.2027, für eingebettete Systeme nach Anhang I ab 02.08.2028.

Nehmen Sie Ihr Architekturdiagramm und zeichnen Sie die Jurisdiktionsgrenzen ein. Tauchen Kanten auf, die Sie nicht erklären können, reden wir darüber.

30 Minuten mit einem Engineer über Ihre Agenten-Architektur, ohne Verkaufsgespräch: Termin buchen. Lieber schriftlich? Über Kontakt. Was wir bauen, steht unter Künstliche Intelligenz & Machine Learning.

Alle Gesetzesangaben geprüft am 18.08.2026 an Fedlex und beim EDÖB. Dieser Beitrag ist Architekturberatung, keine Rechtsberatung.

Kubernetes v1.37: Upgrade ohne Ausfall

Ralph Segi — Wed, 26 Aug 2026 00:00:00 GMT

Kubernetes v1.37 ist am 26. August 2026 erschienen. Drei Änderungen brechen laufende Cluster beim Upgrade: Static Pods dürfen keine Secrets oder ConfigMaps mehr referenzieren, das kubelet startet nicht mehr, wenn veraltete cAdvisor-Flags gesetzt sind, und SELinuxMount ist neu standardmässig aktiv. Die oft zitierte containerd-1.x-Frist dagegen wurde erneut verschoben.

Die vollständigen Release Notes stehen in CHANGELOG-1.37.md im Repo kubernetes/kubernetes, die Feature-Übersicht im Sneak Peek vom 31. Juli 2026. Wer zwei bis zwanzig produktive Cluster betreibt, braucht davon nur den Teil, der wehtut: eine Reihenfolge und ein paar Prüfbefehle. Genau das steht unten.

Static Pods dürfen keine Secrets und ConfigMaps mehr referenzieren

Kubernetes v1.37 entfernt das Feature Gate PreventStaticPodAPIReferences. Static Pods, die configMapRef oder secretRef verwenden, starten nach dem Upgrade nicht mehr. Betroffen sind vor allem Bare-Metal-Installationen und selbstverwaltete Control Planes, nicht von kubeadm verwaltete Standardkomponenten.

Das ist ein Bugfix, keine Schikane. Static Pods werden vom kubelet direkt aus /etc/kubernetes/manifests/ gelesen und laufen nicht über den API-Server. Dass sie trotzdem API-Objekte referenzieren konnten, war ein Fehler. Laut Release-Eintrag wurde das Gate entfernt und kann nicht mehr deaktiviert werden.

Die Prüfung dauert eine Minute pro Node:

# Auf jedem Control-Plane- und Worker-Node
grep -rlE 'configMapRef|secretRef' /etc/kubernetes/manifests/

Jede Ausgabezeile ist ein Manifest, das Sie vor dem Upgrade umbauen müssen. Der Ersatz ist unspektakulär: Werte als Literal in die Pod-Spec schreiben, Dateien über hostPath einhängen, oder die Komponente aus dem Static-Pod-Verzeichnis in ein echtes DaemonSet überführen.

Das kubelet startet nicht mehr, wenn alte cAdvisor-Flags gesetzt sind

Das kubelet in v1.37 verweigert den Start, sobald eine veraltete cAdvisor-Option in seiner Konfiguration steht. Das eingebettete cAdvisor nutzt neu das schlankere Modul github.com/google/cadvisor/lib, und von den alten Flags überlebt nur --housekeeping-interval.

Diese Änderung ist in den Release Notes als Deprecation geführt, wirkt in der Praxis aber wie ein harter Breaking Change: Ein Node mit --containerd, --boot-id-file, --machine-id-file, --container-hints, --global-housekeeping-interval, --event-storage-age-limit oder einem der --storage-driver-*-Flags kommt nach dem Neustart schlicht nicht zurück.

Wichtig ist, an welchen Stellen Sie suchen. Die systemd-Unit ist nur eine davon: kubeadm legt seine Flags in /var/lib/kubelet/kubeadm-flags.env ab, viele Distributionen zusätzlich in /etc/default/kubelet. Wer nur systemctl cat prüft, bekommt auf einem betroffenen Node ein sauberes Ergebnis.

# Auf jedem Node: verbotene cAdvisor-Flags in allen drei Quellen finden
FLAGS='--(application-metrics-count-limit|boot-id-file|container-hints|containerd|enable-load-reader|event-storage-|global-housekeeping-interval|log-cadvisor-usage|machine-id-file|storage-driver-)'

systemctl cat kubelet 2>/dev/null | grep -E -- "$FLAGS"
grep -hE -- "$FLAGS" /var/lib/kubelet/kubeadm-flags.env /etc/default/kubelet 2>/dev/null

Keine Ausgabe heisst: sauber. Zusätzlich verschwinden die Metriken container_cpu_load_average_10s, container_cpu_load_d_average_10s und container_tasks_state aus /metrics/cadvisor. Wer davon ein Grafana-Panel oder eine Alerting-Regel abhängig gemacht hat, sieht nach dem Upgrade eine stumme Lücke statt eines Fehlers. Das ist die unangenehmere Variante. Mehr dazu in unserem Beitrag über Observability, die man liest.

containerd 2.0 unter Kubernetes: ist der Wechsel für v1.37 Pflicht?

Nein, containerd 2.0 ist auch mit Kubernetes v1.37 nicht Pflicht. Die Behauptung kursiert seit dem v1.36-Zyklus in Upgrade-Guides und stimmt nicht. Die Entfernung der veralteten kubelet-Konfigurationsflags samt CRI-Fallback wurde zweimal verschoben: in CHANGELOG-1.36.md von v1.36 auf v1.37, und in CHANGELOG-1.37.md erneut von v1.37 auf v1.38 (PR #139121, gemergt am 22. Mai 2026), ausdrücklich „to align with containerd v1.7 support”.

Entspannen Sie sich trotzdem nicht. Laut containerd RELEASES.md endet der verlängerte Support für containerd 1.7 im September 2026, und er ist explizit auf Kubernetes 1.30 bis 1.32 auf GKE beschränkt. Für alles andere ist 1.7 bereits jetzt unbetreut.

Das kubelet sagt Ihnen selbst, wann Schluss ist:

# Node-Inventar: kubelet-Version, Runtime, OS-Image
kubectl get nodes -o custom-columns='NODE:.metadata.name,\
KUBELET:.status.nodeInfo.kubeletVersion,\
RUNTIME:.status.nodeInfo.containerRuntimeVersion,\
OS:.status.nodeInfo.osImage'

# kubelet-Metriken: cgroup-Version und Support-Ende der Runtime
kubectl get --raw "/api/v1/nodes/<NODE>/proxy/metrics" \
  | grep -E '^kubelet_(cgroup_version|cri_losing_support)'

kubelet_cri_losing_support ist ein Gauge mit dem Label version und meldet, in welcher Kubernetes-Version die aktuell laufende CRI-Implementierung ihren Support verliert. Alpha-Stabilität, aber genau die Zahl, die man beim Planen braucht.

Was der Sprung von 1.7 auf 2.x konkret bedeutet:

Punkt	containerd 1.7	containerd 2.x
Support	verlängert bis September 2026, nur für K8s 1.30 bis 1.32 auf GKE	2.3 als LTS bis 30.04.2028
CRI-API	`v1` und `v1alpha2`	nur `v1`, `v1alpha2` entfernt
`config.toml`	Version 2	Version 3 empfohlen, Version 2 läuft weiter
Docker-Schema-1-Images	Pull möglich, deprecated	in 2.0 deaktiviert, in 2.1 entfernt
Runtime-Plugins als `*.so`	unterstützt	in 2.1 entfernt, externe Plugins nutzen

Wenn Sie migrieren, gehen Sie auf containerd 2.3: LTS bis 30. April 2028. containerd 2.2 läuft schon am 6. November 2026 aus, 2.1 ist seit dem 3. Juli 2026 EOL. Die Config muss dabei nicht sofort mitwandern, Version 2 wird von containerd 2.x weiterhin gelesen.

Wer nicht sicher ist, ob seine Nodes nach dem kubelet-Neustart zurückkommen, findet das in etwa einer Stunde heraus: Node-Inventar, kubelet-Unit-Diff, Static-Pod-Scan. Wenn Sie das nicht selbst durchgehen wollen, schauen wir es uns gemeinsam an.

cgroup v1 ist seit v1.35 erledigt, nicht erst jetzt

Das kubelet startet seit Kubernetes v1.35 auf cgroup-v1-Nodes nicht mehr, weil failCgroupV1 dort standardmässig auf true steht. Der Sneak Peek zu v1.37 führt das als laufende Änderung, nicht als Neuerung.

Praktisch heisst das: Wer heute noch auf v1.34 sitzt, trifft cgroup v1 nicht beim Sprung auf v1.37, sondern schon beim Zwischenschritt auf v1.35. Betroffen sind ältere Node-Images und On-Prem-Bestände, typischerweise CentOS 7, RHEL 7 und Ubuntu 18.04. Die Metrik kubelet_cgroup_version aus dem Block oben beantwortet das pro Node, ohne dass jemand sich einloggen muss.

kube-proxy IPVS: die Uhr läuft, aber langsam

Der IPVS-Modus von kube-proxy verschwindet über vier Releases, nicht in diesem. KEP-5495 legt den Pfad fest: v1.35 Warnungen, v1.37 neues Feature Gate KubeProxyIPVS (standardmässig aktiv), v1.40 Gate standardmässig aus, v1.43 Code entfernt, v1.46 Gate entfernt.

Die Begründung ist ehrlich und im KEP nachlesbar: „sig-network currently lacks maintainers who are familiar with the ipvs backend code.” Dazu kommt, dass IPVS unter der Haube weiterhin iptables benutzt. Migrationsziel ist nftables, GA seit v1.33.

kubectl -n kube-system get configmap kube-proxy \
  -o jsonpath='{.data.config\.conf}' | grep 'mode:'

Ein leeres mode: ist ab v1.37 ebenfalls eine Warnung wert: kube-proxy meldet neu, wenn kein Modus explizit gesetzt ist, weil der Linux-Default künftig von iptables auf nftables wechselt. Setzen Sie den Wert explizit, auch wenn Sie beim aktuellen Verhalten bleiben wollen.

Welche Kubernetes-Version noch Support hat

Kubernetes pflegt die drei jüngsten Minor-Releases. Die Dokumentation nennt das „rund ein Jahr”, die letzten drei Releases liefen tatsächlich 14,0, 14,4 und 14,2 Monate. Rechnen Sie mit zwölf Monaten und freuen Sie sich über den Rest. Stand kubernetes.io/releases vom 18. August 2026:

Version	Release	End of Life	Was zu tun ist
v1.34	27.08.2025	27.10.2026	Akut. Zwei Monate Rest, drei Minor-Sprünge bis v1.37
v1.35	17.12.2025	28.02.2027	cgroup v1 bereits scharf, IPVS-Warnungen aktiv
v1.36	22.04.2026	28.06.2027	Komfortabelste Ausgangslage, ein Sprung auf v1.37
v1.37	26.08.2026	ca. Oktober 2027 *	Neu, anfangs .0-Patchstand

* EOL für v1.37 ist noch nicht publiziert. Der Wert ist aus dem 14-Monats-Muster der drei Vorgänger extrapoliert und als Planungsgrösse zu behandeln, nicht als Zusage.

Für Schweizer Teams auf Exoscale SKS kommt ein zweiter Takt dazu: Minor-Versionen werden dort rund 14 Monate unterstützt, Upgrades müssen sequenziell durch jede Minor-Version laufen, und der Control Plane wird zuerst gehoben, danach werden die NodePools durchgetauscht. Von v1.34 auf v1.37 sind das drei Runden, nicht eine.

Die Upgrade-Reihenfolge, die wir empfehlen

Ein Upgrade ohne Ausfall folgt der offiziellen Version Skew Policy: Control Plane vor Nodes, keine übersprungenen Minor-Versionen beim kube-apiserver.

Prüfen, bevor irgendetwas angefasst wird. Static-Pod-Scan, cAdvisor-Flag-Scan, kubelet_cgroup_version, kubelet_cri_losing_support, kube-proxy-Modus. Alle fünf Befehle stehen oben.
scheduling.k8s.io/v1alpha2 aus etcd räumen. v1.37 entfernt die Version vollständig. Die Kerntypen Workload und PodGroup sind nach scheduling.k8s.io/v1beta1 promoted, der Rest nach v1alpha3. Bestehende Objekte müssen vor dem Update weg.
kube-apiserver hochziehen, danach kube-controller-manager, kube-scheduler und cloud-controller-manager. Diese drei dürfen höchstens eine Minor-Version älter sein als der API-Server.
Einen Worker-Node exemplarisch heben. kubelet und kube-proxy dürfen bis zu drei Minor-Versionen älter sein als der kube-apiserver. Sie haben also Zeit, und Sie brauchen sie: Der erste Node ist der Test.
Restliche NodePools rollen, mit PodDisruptionBudgets, die den Namen verdienen. Ein PDB mit minAvailable: 1 bei zwei Replicas blockiert kein Drain, er verzögert es nur.

Ein Punkt, der gern untergeht: SELinuxMount ist in v1.37 GA und standardmässig aktiv. Auf Clustern mit aktiviertem SELinux, also praktisch jedem RHEL- und OpenShift-Bestand, kann das laufende Workloads brechen. Kubernetes hat dazu am 22. April 2026 einen eigenen Blogbeitrag publiziert, der die betroffenen Muster im v1.36-Cluster identifizierbar macht. Ohne SELinux ändert sich nichts.

Wann Sie nicht upgraden sollten

Upgraden Sie nicht auf v1.37.0. Warten Sie auf v1.37.1 oder v1.37.2, ausser Sie haben einen konkreten Grund. Ein .0-Release ist am Erscheinungstag der am wenigsten in Produktion gelaufene Stand einer Version, und die Historie der Urgent Upgrade Notes gibt einem wenig Anlass zu Optimismus.

Der Trade-off ist real und geht in beide Richtungen: Wer wartet, sammelt Distanz zu v1.34, dessen Support am 27. Oktober 2026 endet. Weil kube-apiserver keine Minor-Versionen überspringen darf, sind das drei sequenzielle Upgrades. Wer erst im Oktober anfängt, macht drei Sprünge unter Zeitdruck statt einen entspannt. Jeder Sprung ist Betriebsaufwand, und der ist der grösste Posten, wenn man durchrechnet, was Kubernetes in der Schweiz wirklich kostet.

Unsere Linie: Wer auf v1.36 sitzt, hat bis Juni 2027 Ruhe und kann auf .2 warten. Wer auf v1.34 sitzt, fängt diese Woche an, und zwar mit v1.35, nicht mit v1.37. Und wer mitten im Quartalsabschluss steckt oder ein Release-Freeze fährt, verschiebt das Ganze bewusst und schriftlich, statt es zu vergessen.

Packen Sie ausserdem nicht alles in dasselbe Wartungsfenster. Ingress NGINX wurde im März 2026 retired, ohne weitere Security-Patches, laut interner Datadog-Recherche mit rund der Hälfte aller Cloud-Native-Umgebungen im Rücken. Der Wechsel auf die Gateway API ist ein eigenes Projekt mit eigenem Risiko, kein Nebenschauplatz eines Minor-Upgrades.

Ein Cluster ist ohnehin kein Selbstzweck. Bevor Sie drei Upgrade-Runden planen, lohnt die Frage, ob ein Cluster überhaupt die richtige Antwort ist.

Häufige Fragen

Wie funktioniert ein Kubernetes-Cluster-Upgrade ohne Ausfall?

Ein ausfallfreies Upgrade hebt zuerst den Control Plane, dann die Nodes. Der kube-apiserver kommt zuerst, danach controller-manager und scheduler, zuletzt kubelet und kube-proxy. Workloads bleiben verfügbar, wenn jede Anwendung mindestens zwei Replicas, ein sinnvolles PodDisruptionBudget und funktionierende Readiness-Probes hat. Nodes werden einzeln gedraint, nicht parallel.

Welche Kubernetes-Version wird noch unterstützt?

Unterstützt sind v1.35, v1.36 und v1.37, sobald v1.37 veröffentlicht ist. v1.34 erreicht am 27. Oktober 2026 sein End of Life. Kubernetes pflegt grundsätzlich die drei jüngsten Minor-Releases, was rund ein Jahr Patch-Support pro Version ergibt. Managed-Anbieter weichen ab: Exoscale SKS gibt rund 14 Monate.

Wie prüfe ich, welchen kube-proxy-Modus mein Cluster nutzt?

Der Befehl kubectl -n kube-system get configmap kube-proxy -o jsonpath='{.data.config\.conf}' | grep 'mode:' liest den Modus aus der ConfigMap. Ein leerer Wert bedeutet Default, aktuell iptables auf Linux. Steht dort ipvs, planen Sie die Migration auf nftables ein: ab v1.40 ist IPVS standardmässig deaktiviert, ab v1.43 entfernt.

Muss ich für Kubernetes v1.37 auf containerd 2.x wechseln?

Nein, nicht zwingend. Die Entfernung des kubelet-CRI-Fallbacks wurde auf v1.38 verschoben. Der verlängerte Support für containerd 1.7 endet aber im September 2026 und deckt nur Kubernetes 1.30 bis 1.32 auf GKE ab. Praktisch heisst das: Planen Sie den Wechsel auf containerd 2.3 jetzt, aber nicht im selben Wartungsfenster wie das v1.37-Upgrade.

Gut zwei Monate bis zum End of Life von v1.34. Bis v1.37 sind das drei sequenzielle Sprünge, und jeder braucht sein eigenes Wartungsfenster. Wir gehen den Pfad einmal mit Ihnen durch: welche Version zuerst, was pro Sprung bricht, wie lange das realistisch dauert. Am Ende haben Sie eine Reihenfolge, keine Präsentation.

Schreiben Sie uns über Kontakt, welche Version bei Ihnen läuft und wie viele Cluster dranhängen, dann bereiten wir den Pfad vor. Oder setzen Sie gleich einen Termin. Was wir sonst an Clustern bauen und betreiben, steht unter Kubernetes und Infrastruktur.

Was kostet Kubernetes in der Schweiz wirklich?

Ralph Segi — Tue, 25 Aug 2026 00:00:00 GMT

Ein produktiver Kubernetes-Cluster mit drei Worker-Nodes zu je 4 vCPU und 16 GB RAM, 500 GB Storage und einer Control Plane mit SLA kostet bei Schweizer Anbietern zwischen CHF 158 und CHF 779 pro Monat. Das ist die kleinere Hälfte der Rechnung. Der Betrieb kostet ab CHF 1’730 monatlich, gerechnet mit vier Stunden pro Woche zum tiefsten Schweizer Stundensatz.

Beide Zahlen sind eine Modellrechnung. Jeder Eingangswert stammt aus einer öffentlichen Preisliste, abgerufen am 19. August 2026. Zum Einordnen haben wir dasselbe Szenario bei Azure in Switzerland North und bei AWS in Europe (Zurich) durchgerechnet. Die Herleitung steht weiter unten, Posten für Posten.

Warum die Suche nach Kubernetes-Preisen in der Schweiz ins Leere läuft

Wer nach Kubernetes-Kosten sucht, findet Rechner von AWS, Azure und Google in USD und EUR. Für Schweizer Anbieter existiert keine einzige durchgerechnete Gegenüberstellung in CHF. Das ist der Grund für diesen Beitrag.

Stattdessen kursieren zwei Zahlen, die beide aus Suchzusammenfassungen stammen und nicht aus geprüften Preislisten: „Managed Kubernetes ab CHF 100 pro Monat” und „CHF 150 bis 400 pro Monat”. Wir haben beide nachgeschlagen. Beide sind falsch, und zwar in unterschiedliche Richtungen.

Der günstigste publizierte Einstieg liegt deutlich tiefer. Bei Infomaniak ist die Shared Control Plane kostenlos, drei Worker-Nodes mit 2 vCPU und 4 GB RAM kosten CHF 0.01043 pro Stunde und Node, also rund CHF 23 pro Monat zusammen. Mit einem Load Balancer landet ein minimaler Cluster bei etwa CHF 33.

Und ein Cluster in produktiver Grösse liegt deutlich höher als CHF 400. Bei Flow Swiss kostet allein ein einzelner Worker-Node mit 4 vCPU und 16 GB RAM CHF 197 pro Monat. Drei davon sind Pflicht.

Die vier Kostenblöcke, aus denen sich die Rechnung zusammensetzt

Eine Kubernetes-Rechnung besteht aus Control Plane, Worker-Nodes, Storage samt Traffic und Betrieb. Die ersten drei stehen auf der Preisliste. Der vierte steht nirgends und ist der grösste.

Vorweg, weil es die zweithäufigste Suchanfrage in diesem Umfeld ist: Kubernetes ist Open Source unter Apache-2.0-Lizenz und damit lizenzkostenfrei. Der Betrieb ist es nicht. Sie zahlen keine Lizenz, Sie zahlen Maschinen und Personen.

Control Plane. Der Preis für die verwaltete Steuerebene. Exoscale und Infomaniak geben sie in der Basisvariante gratis ab, dann allerdings ohne SLA. Bei Flow Swiss kostet sie pro Cluster CHF 73 im Monat, unabhängig von der Clustergrösse.

Worker-Nodes. Der grösste Posten auf der Rechnung. Hier liegen zwischen den Schweizer Anbietern Faktoren, keine Prozente.

Storage und Traffic. Block Storage wird pro GiB und Stunde verrechnet. Beim Egress unterscheiden sich die Modelle stark: Infomaniak gibt Bandbreite grundsätzlich gratis ab, Flow Swiss inkludiert 20 TB pro Organisation und Monat, Exoscale gewährt pro Instanz 1.42 GiB pro Stunde und verrechnet danach CHF 0.02 pro GiB.

Betrieb. Upgrades, Zertifikate, Netzwerk-Policies, Alarme um drei Uhr morgens. Dieser Block taucht auf keiner Preisliste auf, weil ihn kein Anbieter verkauft.

Genau hier verrutschen Budgets. Ein Managed-Kubernetes-Angebot von Infomaniak oder Exoscale übernimmt die Control Plane, die etcd-Backups und die Node-Bereitstellung. Alles oberhalb der Kubernetes-API bleibt bei Ihnen: Ingress, Zertifikatsrotation, RBAC, Backups der Applikationsdaten, Alerting, und die Frage, wer den Upgrade-Pfad plant.

Was Managed Kubernetes kostet: der Anbietervergleich Schweiz

Von sieben Schweizer Anbietern führen vier eine öffentliche Preisliste und drei nicht. Alle Werte in der folgenden Tabelle stammen aus den verlinkten Preislisten, abgerufen am 19. August 2026, exklusive Mehrwertsteuer.

Anbieter	Control Plane	Worker 4 vCPU / 16 GB	Block Storage	Egress	Datenstandort	SLA
Exoscale SKS	Starter gratis, Pro CHF 0.054995/h	CHF 0.18667/h	CHF 0.00014 pro GiB/h	1.42 GiB/h pro Instanz frei, dann CHF 0.02/GiB	Zonen ch-gva-2, ch-dk-2	99.95 % (Pro)
Infomaniak	Shared gratis, Dediziert 4 ab CHF 0.04/h	CHF 0.03429/h	CHF 0.00012 pro GiB/h	inklusive	eigene RZ in der Schweiz	99.9 % (dediziert)
Flow Swiss	CHF 73/Monat pro Cluster	CHF 197/Monat (k1.4x16)	CHF 0.22 pro GB/Monat	20 TB pro Organisation inklusive	ZRH1 Zürich, ALP1 Luzern	99.9 %
cloudscale.ch	kein eigenes Managed Kubernetes	CHF 4.40 pro 24 h (Flex-16-4)	publiziert	100 GB pro 24 h inklusive	Schweiz	99.99 %
VSHN / APPUiO	im Servicepreis enthalten	ab CHF 4’900/Monat für den ganzen Cluster	Infrastruktur des Kunden	Infrastruktur des Kunden	frei wählbar	bis 99.99 % 24/7
Metanet	keine öffentliche Preisliste	keine öffentliche Preisliste	keine öffentliche Preisliste	keine öffentliche Preisliste	Schweiz, ISO 27001	Enterprise-SLA auf Anfrage
Swisscom	keine öffentliche Preisliste	keine öffentliche Preisliste	keine öffentliche Preisliste	keine öffentliche Preisliste	Schweiz	nicht publiziert
Azure AKS, Switzerland North	Free-Tier gratis, Standard CHF 0.082/h	CHF 0.2075/h (D4s v5)	CHF 72.68/Monat (P20, 512 GiB)	100 GB/Monat gratis, dann CHF 0.0656/GB	Switzerland North	Free ohne SLA, Standard mit hinterlegtem Uptime-SLA
AWS EKS, Europe (Zurich)	USD 0.10/h pro Cluster	USD 0.253/h (m6i.xlarge)	USD 0.1142 pro GB/Monat (gp3)	USD 0.09/GB bis 10 TB	eu-central-2	99.95 %

Drei Anmerkungen dazu. Erstens rechnet Flow Swiss Monatspreise mit 730 Stunden, Exoscale mit 720; wir vereinheitlichen unten auf 730. Zweitens publiziert AWS für die Zürcher Region ausschliesslich USD, Azure liefert über die Retail-Prices-API echte CHF-Preise für Switzerland North. Wir rechnen nichts um, weil wir keinen belegbaren Stichtagskurs haben.

Drittens gehört Exoscale seit 2017 zu A1 Digital, einer Tochter der Telekom Austria Group. Die Daten liegen in der Schweiz, die Eigentümerschaft nicht. Für revDSG-Fragen zählt beides.

Die Modellrechnung: derselbe Cluster bei fünf Anbietern

Dasselbe Referenzszenario kostet zwischen CHF 158.10 bei Infomaniak und CHF 779.00 bei Flow Swiss. Das Szenario: drei Worker-Nodes zu je 4 vCPU und 16 GB RAM, 500 GB persistenter Storage, eine Control Plane mit SLA, ein Load Balancer, Egress unter 1 TB, gerechnet mit 730 Stunden.

Anbieter	3 Worker-Nodes	Control Plane	Storage	Load Balancer	Total pro Monat
Infomaniak	CHF 75.10	CHF 29.20	CHF 43.80	CHF 10.00	CHF 158.10
Exoscale	CHF 408.81	CHF 40.15	CHF 66.43	CHF 25.35	CHF 540.74
Azure AKS, Switzerland North	CHF 454.42	CHF 59.86	CHF 72.68	CHF 14.78	CHF 601.74
Flow Swiss	CHF 591.00	CHF 73.00	CHF 110.00	CHF 5.00	CHF 779.00
AWS EKS, Europe (Zurich)	USD 554.07	USD 73.00	USD 57.10	USD 21.68	USD 705.85

Modellrechnung, keine Offerte. Preise exklusive MwSt., abgerufen am 19. August 2026 aus den oben verlinkten Preislisten. Die Storage-Zeile enthält bei Exoscale zusätzlich die Node-Disks (3 × 50 GiB), die dort separat verrechnet werden; bei Infomaniak sind 50 GB pro Node im Flavor enthalten, bei Azure entspricht sie einer Premium-SSD P20 mit 512 GiB. Der Egress liegt bei allen fünf im Freikontingent oder ist gratis.

Preis ist nicht Leistung. Infomaniak fährt Shared vCPUs im OpenStack-Verbund und positioniert sich ausdrücklich über den Preis. Flow Swiss liefert dedizierte Ressourcen, ein 99.9-Prozent-SLA und zwei Schweizer Regionen. Was die Tabelle nicht abbildet: Support-Qualität, Reaktionszeit bei Incidents, Reifegrad der API, wie schnell eine neue Kubernetes-Minor-Version verfügbar ist.

Was kostet Kubernetes bei Azure und AWS in der Schweiz?

Azure AKS in Switzerland North kostet im selben Szenario CHF 601.74 pro Monat, AWS EKS in Europe (Zurich) USD 705.85. Beide liegen damit im Feld der Schweizer Anbieter, nicht darüber. Das widerlegt die verbreitete Annahme, ein Hyperscaler sei automatisch die teure Variante.

Azure ist günstiger als Flow Swiss und teurer als Exoscale. Infomaniak unterbietet Azure um fast den Faktor vier. Die Preisspanne innerhalb der Schweiz ist also grösser als der Abstand zwischen Schweiz und Hyperscaler.

Zwei Unterschiede, die auf keiner Preisliste stehen. Erstens den Egress: Azure gibt 100 GB pro Monat gratis und verlangt danach CHF 0.0656 pro GB, AWS USD 0.09 pro GB bis 10 TB. Bei Infomaniak ist Bandbreite gratis, bei Flow Swiss sind 20 TB inklusive. Wer 2 TB (2’000 GB) pro Monat ausliefert, zahlt bei Azure CHF 124.64 zusätzlich und bei Infomaniak nichts.

Zweitens die Rechtslage. Microsoft und AWS betreiben Schweizer Regionen, unterstehen als US-Konzerne aber dem CLOUD Act. Für revDSG-Prüfungen mit erhöhtem Schutzbedarf ist das der Punkt, an dem die Preisfrage endet und die Architekturfrage beginnt.

Was der Betrieb kostet: Schweizer Stundensätze als Rechengrösse

Der Betrieb kostet ein Vielfaches der Infrastruktur. gryps.ch nennt für Softwareentwicklung in der Deutschschweiz CHF 100 bis 150 pro Stunde für Junior-Profile und CHF 140 bis 180 für Senior-Profile, mit CHF 160 als Mittelwert im publizierten Beispiel (abgerufen 19.08.2026). Cluster-Betrieb ist Senior-Arbeit.

Betriebsaufwand	CHF 100/h	CHF 140/h	CHF 180/h
4 h pro Woche (17.3 h/Monat)	CHF 1’730	CHF 2’430	CHF 3’120
10 h pro Woche (43.3 h/Monat)	CHF 4’330	CHF 6’070	CHF 7’800
20 h pro Woche (86.7 h/Monat)	CHF 8’670	CHF 12’130	CHF 15’600

Die Zeile, auf die es ankommt: Selbst die vorsichtigste Annahme, vier Stunden pro Woche zum tiefsten publizierten Satz, ergibt CHF 1’730 pro Monat. Das ist mehr als die teuerste Infrastrukturrechnung im Vergleich oben.

Vier Stunden pro Woche sind für einen produktiven Cluster knapp bemessen. Kubernetes gibt pro Jahr drei Minor-Versionen frei, jede mit Deprecations. Wie viel Vorbereitung ein einzelnes Upgrade kostet, haben wir am Beispiel 1.37 durchgespielt.

Rechnen Sie Ihren eigenen Fall einmal komplett durch, Infrastruktur plus Personentage. Wir machen das in einem Termin mit Ihnen, mit Ihren Node-Grössen und Ihrer Preisliste, und Sie behalten die Tabelle. 30 Minuten mit einem Engineer, der Schweizer Cluster betreibt.

Managed, selbst betrieben oder betreiben lassen

Es gibt drei Betriebsmodelle, und sie unterscheiden sich weniger im Preis als darin, wer nachts aufsteht. Die folgende Matrix ordnet sie entlang der Kriterien, die in Budgetdiskussionen tatsächlich auftauchen.

Kriterium	Managed beim Anbieter	Selbst betrieben auf IaaS	Betreiben lassen
Infrastruktur pro Monat	CHF 158 bis 779	CHF 132 pro Node und 30 Tage bei cloudscale.ch	wie Managed oder IaaS
Betriebsaufwand intern	4 bis 10 h pro Woche	10 bis 20 h pro Woche	nahe null
Zusatzkosten Betrieb	CHF 1’730 bis 6’070	CHF 4’330 bis 12’130	ab CHF 4’900 bei VSHN
Control Plane	Anbieter	Sie	Partner
Anbieterbindung	hoch	tief	tief
Datenstandort steuerbar	nur Anbieter-Zonen	vollständig	vollständig
Passt, wenn	ein Team, klare Workloads	Compliance verlangt eigene Hoheit	Plattform ist kritisch, Team ist klein

Der Preis für „betreiben lassen” ist öffentlich: VSHN publiziert für Managed OpenShift auf Cloud-Provider-Infrastruktur CHF 4’900 pro Monat als Baseline, CHF 7’500 mit 99.9 Prozent rund um die Uhr und CHF 10’100 bei 99.99 Prozent (abgerufen 19.08.2026). Der Stundensatz für Zusatzarbeiten liegt bei CHF 250.

Hier liegt die Lücke im Schweizer Markt. Exoscale, Infomaniak, Flow Swiss, cloudscale.ch, Metanet und Swisscom verkaufen Infrastruktur. VSHN verkauft eine eigene Plattform. Niemand verkauft „wir bauen und betreiben Ihre Plattform auf Ihrer Infrastruktur, mit Ihren Tools”. Genau das ist unsere Position, und deshalb steht sie hier in der Matrix und nicht in einem Werbekasten.

Wo die Über-Provisionierung sitzt, die niemand sieht

Die Infrastrukturrechnung entsteht an einer Stelle, die im Code steht, nicht im Portal. Kubernetes plant Pods nach requests, nicht nach tatsächlicher Last. Wer grosszügig requestet, bezahlt Nodes für Kapazität, die nie genutzt wird.

resources:
  requests:
    cpu: "2"
    memory: "4Gi"
  limits:
    cpu: "2"
    memory: "4Gi"

Vier solche Pods belegen 8 vCPU und binden damit CPU-seitig zwei der Worker-Nodes aus unserem Referenzszenario. Bei Flow Swiss sind das CHF 394 pro Monat, bei Infomaniak CHF 50.06. Ob die Pods 5 Prozent oder 95 Prozent davon brauchen, sieht man auf der Rechnung nicht.

Der Abgleich zwischen angefordert und verbraucht dauert zwei Befehle:

kubectl get pods -A -o custom-columns=\
NS:.metadata.namespace,\
POD:.metadata.name,\
CPU_REQ:.spec.containers[*].resources.requests.cpu,\
MEM_REQ:.spec.containers[*].resources.requests.memory

kubectl top pods -A --containers

Wo die zweite Ausgabe dauerhaft weit unter der ersten liegt, zahlen Sie für Luft. Das ist der einzige Hebel in diesem Beitrag, der ohne Anbieterwechsel wirkt.

Wann sich der Cluster nicht rechnet

Unter etwa fünf Diensten und einem Team rechnet sich Kubernetes in der Schweiz nicht. Bei CHF 158 Infrastruktur und CHF 2’430 Betrieb pro Monat zahlen Sie rund 94 Prozent der Rechnung für Betriebswissen, das eine einzelne gut dimensionierte VM mit Docker Compose, systemd und einem sauberen Deploy-Skript nicht braucht.

Wir raten in diesen Fällen ab, auch wenn wir Kubernetes bauen und betreiben. Die ehrliche Frage steht in Kubernetes ist kein Ziel: Was passiert, wenn dieser Dienst um drei Uhr morgens ausfällt, und wer schaut hin? Lautet die Antwort „ein Alarm, ein Runbook, ein Neustart”, braucht es keinen Orchestrator.

Der Cluster rechnet sich, sobald mehrere Teams unabhängig deployen, Lastspitzen unvorhersehbar sind oder Compliance reproduzierbare, deklarative Infrastruktur mit Audit-Trail verlangt. Für onocoy und Relai trifft genau das zu. Für eine Anwendung mit einer Datenbank und bekanntem Traffic trifft es nicht zu.

Was sich über zwölf Monate an der Rechnung ändert

Über zwölf Monate bewegen sich vor allem die Worker-Nodes, und zwar in beide Richtungen. Right-Sizing der Requests holt typischerweise am meisten heraus, weil es direkt die Anzahl Nodes senkt.

Cluster Autoscaling hilft nur bei schwankender Last. Bei konstanter Grundlast verschiebt es die Rechnung nicht, es verkompliziert sie. Infomaniak und Exoscale unterstützen Node-Pools mit Minimum und Maximum; wer beide gleich setzt, hat Autoscaling nur nominell.

Was in der Schweiz fehlt: Reservierungen. Weder Exoscale noch Infomaniak noch Flow Swiss publizieren Rabatte für Laufzeitbindung, wie sie AWS mit Savings Plans anbietet. Wer plant, mit einer Vorauszahlung 30 Prozent zu sparen, plant mit einem Instrument, das es hier nicht gibt.

Die Betriebsseite bewegt sich in die andere Richtung. Im ersten Jahr ist der Aufwand am höchsten, weil Ingress, Secrets-Handling, Backup-Strategie und CI-Anbindung erst entstehen. Danach sinkt er auf ein Grundrauschen aus Upgrades und Incidents, und genau dieses Grundrauschen ist die Zahl, mit der Sie planen sollten, nicht der Aufbauaufwand.

Der Posten, der diese Rechnung am schnellsten sprengt, steht hier nicht drin: GPUs. Eine einzige Inferenz-Karte kostet mehr als der gesamte Cluster oben. Was souveräne KI-Inferenz auf Schweizer Infrastruktur kostet und ab welchem Anfragevolumen sich Eigenbetrieb gegenüber einer API rechnet, steht in souveräne KI-Inferenz in der Schweiz.

Häufige Fragen

Was kostet ein Managed-Kubernetes-Cluster in der Schweiz pro Monat?

Ein Cluster mit drei Worker-Nodes zu je 4 vCPU und 16 GB RAM, 500 GB Storage und Control Plane mit SLA kostet zwischen CHF 158 und CHF 779 pro Monat, je nach Anbieter. Das Minimum für einen sehr kleinen Cluster liegt bei Infomaniak bei rund CHF 33. Alle Werte aus publizierten Preislisten, abgerufen am 19. August 2026, exklusive MwSt.

Ist Kubernetes nicht kostenlos?

Kubernetes ist Open Source unter Apache-2.0-Lizenz, es fallen keine Lizenzkosten an. Kosten entstehen durch Maschinen und Menschen: Control Plane, Worker-Nodes, Storage und Traffic ergeben CHF 158 bis 779 pro Monat für einen Cluster in produktiver Grösse, dazu kommt der Betriebsaufwand ab CHF 1’730 monatlich. Der lizenzfreie Teil ist der kleinste Teil der Rechnung.

Was kostet Kubernetes bei Azure und AWS in der Schweiz?

Azure AKS in der Region Switzerland North kostet im Referenzszenario CHF 601.74 pro Monat, AWS EKS in Europe (Zurich) USD 705.85. Beide liegen im Feld der Schweizer Anbieter: teurer als Exoscale mit CHF 540.74, günstiger als Flow Swiss mit CHF 779.00. AWS publiziert für Zürich ausschliesslich USD-Preise, Azure liefert echte CHF-Preise (Stand 19.08.2026).

Brauche ich als KMU überhaupt Kubernetes, oder reicht Docker Compose?

Docker Compose auf einer VM reicht, solange eine Anwendung, eine Datenbank und ein Team im Spiel sind und der Traffic bekannt ist. Kubernetes lohnt sich ab mehreren unabhängig deployenden Teams, unvorhersehbaren Lastspitzen oder Compliance-Anforderungen an deklarative Infrastruktur. Die Betriebskosten von CHF 1’730 aufwärts pro Monat entscheiden diese Frage häufiger als die Infrastrukturkosten.

Bleiben meine Daten bei einem Schweizer Kubernetes-Anbieter in der Schweiz?

Das hängt vom Anbieter und von der gewählten Zone ab. Infomaniak betreibt eigene Rechenzentren in der Schweiz, Flow Swiss die Regionen ZRH1 und ALP1. Exoscale bietet die Schweizer Zonen ch-gva-2 und ch-dk-2 an, gehört aber seit 2017 zur Telekom Austria Group. Für revDSG-Prüfungen ist neben dem Standort auch die Eigentümerschaft relevant.

Rechnen wir Ihren Cluster durch

Bringen Sie Ihre Node-Grössen, Ihre Storage-Klasse und eine ehrliche Schätzung der internen Stunden mit. Wir legen die aktuellen Preislisten daneben und rechnen beide Seiten der Rechnung, Infrastruktur und Betrieb, in einem Termin durch.

Termin buchen oder schreiben Sie uns, wenn Ihnen eine Frage per Mail lieber ist. Was wir dabei bauen und betreiben, steht unter Kubernetes und Infrastruktur.

Souveräne KI-Inferenz in der Schweiz: die Architektur

Robert Pupel — Mon, 24 Aug 2026 00:00:00 GMT

Souveräne KI-Inferenz ist eine Eigenschaft des gesamten Datenflusses, nicht des Modells. Ein in Zürich gehostetes Apertus-Modell ist nicht souverän, wenn die Traces bei einem US-Monitoring-Dienst landen, die Vektordatenbank in Irland liegt oder der Support aus einem Drittstaat in die Logs schaut. Souverän ist eine Architektur erst, wenn Prompt, Kontext, Gewichte, Logs und Metadaten dieselbe Jurisdiktion nie verlassen.

Über digitale Souveränität ist viel geschrieben worden. ipt etwa führt eine Seite mit dem Title-Tag „Souveräne KI Plattformen auf Kubernetes” und hat das Thema mit dem ETH AI Center bespielt. Was fehlt, ist die Ebene darunter: welche Anbieter es gibt, was sie kosten, wie der Betrieb aussieht.

Wir rechnen das am Schweizer Markt durch, weil dort Preise und Rechtslage öffentlich prüfbar sind. Die Architektur darunter ist dieselbe, ob die souveräne Cloud in Zürich, Frankfurt oder Paris steht.

Was souveräne KI-Inferenz technisch bedeutet

Souveränität lässt sich an fünf Artefakten prüfen, die bei jeder Inferenz-Anfrage entstehen. Modellgewichte, Prompt, abgerufener Kontext, generierte Antwort und die Telemetrie darüber. Jedes hat einen physischen Speicherort und einen rechtlichen Zugriffsberechtigten, und die beiden sind nicht dasselbe.

Das Schweizer Recht macht daraus eine konkrete Prüfung. Art. 16 revDSG erlaubt die Bekanntgabe von Personendaten ins Ausland nur, wenn der Bundesrat den Zielstaat als angemessen eingestuft hat.

Die Liste steht in Anhang 1 der Datenschutzverordnung (SR 235.11). Die USA stehen seit dem 15. September 2024 darauf, aber nur für Organisationen, die unter dem Swiss-US Data Privacy Framework zertifiziert sind.

Der zweite Prüfpfad läuft über den Anbieter selbst. 18 U.S.C. § 2713, eingeführt mit dem CLOUD Act, verpflichtet US-Anbieter zur Herausgabe gespeicherter Daten „regardless of whether such communication, record, or other information is located within or outside of the United States”.

Ein Rechenzentrum in Zürich ändert daran nichts, wenn die betreibende Gesellschaft US-Konzernrecht untersteht. Welche Architekturentscheidungen daraus folgen, steht in revDSG-konforme KI-Architektur.

Welche Schweizer Cloud-Anbieter souveräne KI-Inferenz anbieten

Vier Anbieter kommen für produktive GPU-Inferenz in der Schweiz realistisch infrage, dazu der Eigenbetrieb. Nur einer davon publiziert vollständige Preise.

Anbieter	GPU-Typen	Abrechnungsmodell	Datenstandort	Kubernetes-Zugang	Öffentliche Preise
Exoscale	RTX Pro 6000 (96 GB), A40, A5000, A30, V100, 3080ti; B300 auf Anfrage	Instanz pro Stunde, Dedicated Inference pro Sekunde	je nach GPU-Typ CH-DK-2 (Schweiz), DE-FRA-1, AT-VIE-2, HR-ZAG-1	ja, SKS	ja, vollständig in CHF
Infomaniak	B300, H200, H100, A100, L40S, L4, A2, T4	GPU-Instanz pro Stunde, AI Services pro Token	Genf und Zürich	ja, Kubernetes-Dienst	teilweise: Token-Preise publiziert, Instanzpreise nur im Konfigurator
Swisscom Swiss AI Platform	NVIDIA SuperPOD	GPU as a Service, dazu Inference-Endpunkte pro Token	Schweiz	nicht dokumentiert	nein
Phoenix Technologies	H100, H200	nicht publiziert	Schweiz	nicht dokumentiert	nein
Eigenbetrieb, Colocation	frei wählbar	CapEx plus Housing	frei wählbar	ja, selbst gebaut	entfällt

Ein Detail, das bei der Souveränitätsprüfung zählt: Exoscales RTX-Pro-6000-Instanzen laufen in DE-FRA-1, HR-ZAG-1 und CH-DK-2, die 3080ti-Instanzen ausschliesslich in AT-VIE-2. Ein Schweizer Anbieter garantiert also nicht automatisch eine Schweizer Zone (abgerufen 19.08.2026).

Apertus 1.5: was das Schweizer Modell heute kann

Apertus 1.5 erschien am 24. Juli 2026 und ist gegenüber der Fassung vom September 2025 ein anderes Modell. Das Kontextfenster liegt bei 262’144 Tokens, eine Vervierfachung. Die Modelle nehmen neu Bilder entgegen, Audio ist als experimentell gekennzeichnet. Lizenz: Apache 2.0.

Für den Betrieb zählt die Tool-Integration mehr als die Multimodalität. Die Modellkarte für Apertus-v1.5-70B dokumentiert einen eigenen Tool-Call-Parser und einen optionalen Thinking-Modus, beides direkt in vLLM ansteuerbar. Damit ist Apertus für Agenten-Architekturen brauchbar, nicht nur für Chat.

Entwickelt haben es EPFL, ETH Zürich und das CSCS auf dem Alps-Supercomputer in Lugano. Wer nicht selbst betreiben will: Infomaniak führt swiss-ai/Apertus-v1.5-70B als API-Modell, aktuell als Beta.

Apertus selbst betreiben: Hugging Face, Ollama oder Apertus Mini

Für den Eigenbetrieb gibt es drei Wege mit sehr unterschiedlichem Produktionsreifegrad.

Hugging Face plus vLLM ist der produktive Pfad. swiss-ai/Apertus-v1.5-70B und die 8B-Variante liegen dort unter Apache 2.0 und laden ohne Konvertierungsschritt.

Ollama ist der schnellste Weg zum Prompt und der langsamste zur Produktion. Es gibt keinen offiziellen Apertus-Build von swiss-ai; die verbreiteten GGUF-Pakete stammen von Community-Packagern und führen die Fassung 2509, also Apertus 1.0. Wer 1.5 lokal will, quantisiert selbst. Für einen Laptop-Test ist das in Ordnung, für einen Dienst mit Parallellast nicht.

Apertus Mini löst oft das eigentliche Problem. Die offizielle Collection enthält Distillate der Reihe v1.1 in 0.5B, 1.5B und 4B, dazu Quantisierungen für MLX und vLLM. Für Klassifikation, Extraktion und Routing reicht ein 4B-Modell meist, und es verschiebt die GPU-Kosten um eine Grössenordnung.

Was Inferenz auf eigener Infrastruktur kostet

Modellrechnung, hergeleitet aus publizierten Preislisten, abgerufen am 19. August 2026. Sie gilt für Apertus-v1.5-70B und vergleicht zwei Bezugswege beim selben Souveränitätsniveau.

Die Modellkarte nennt als Referenzkonfiguration --tensor-parallel-size 4 bei vollen 262’144 Tokens Kontext. Bei 72 Milliarden Parametern in BF16 sind das 144 GB reine Gewichte, dazu der KV-Cache. Vier Karten mit je 96 GB sind damit das Minimum, keine Grosszügigkeit.

Eigenbetrieb, Exoscale Dedicated Inference auf RTX Pro 6000, publizierte Preisliste:

CHF 2.15277778 pro GPU und Stunde, sekundengenau abgerechnet
4 GPUs im Dauerbetrieb: 4 × 2.15277778 × 720 h = CHF 6’200 pro Monat (720 Stunden, wie Exoscale selbst auf Monatspreise umrechnet)
Modellspeicher 134 GiB (144 GB Gewichte) zu CHF 0.0000275 pro GiB-Stunde: CHF 2.65 pro Monat

API-Bezug, Infomaniak AI Services, publizierte Preisliste: CHF 0.70 pro Million Input-Tokens, CHF 2.50 pro Million Output-Tokens für dasselbe Modell.

Angenommenes Anfrageprofil: 3’000 Tokens Input (Systemprompt plus RAG-Kontext), 500 Tokens Output. Das ergibt CHF 0.00335 pro Anfrage oder CHF 0.96 pro Million gemischter Tokens.

Der Kipppunkt liegt bei rund 1.85 Millionen Anfragen pro Monat, also etwa 62’000 pro Tag. Darunter ist die API günstiger. Das entspricht 6.5 Milliarden Tokens im Monat oder rund 2’500 Tokens pro Sekunde im Dauerdurchsatz.

Bei 2’500 Tokens pro Sekunde laufen die vier Karten allerdings rund um die Uhr am Anschlag, und kein Betrieb fährt so. Wer Reserve für Lastspitzen und eine zweite Zone für Ausfälle einplant, verdoppelt die GPU-Kosten und damit den Kipppunkt: realistisch drei bis vier Millionen Anfragen pro Monat.

Umgekehrt hilft die Sekundenabrechnung: Wer nur zu Bürozeiten Last hat und auf null skaliert, zahlt bei 220 Stunden im Monat CHF 1’894 statt CHF 6’200, und der Kipppunkt fällt auf rund 566’000 Anfragen. Die geforderte Spitzenlast bleibt dieselbe.

Nicht enthalten: der Cluster darunter (Exoscale SKS Pro CHF 0.054995 pro Stunde, rund CHF 40 im Monat, im Detail in was Kubernetes in der Schweiz wirklich kostet) und Ihre Zeit.

Rechnen Sie den Kipppunkt für Ihr Profil nach. Er verschiebt sich stark durch Prompt-Caching, ein kleineres Modell oder einen anderen Input-Output-Schnitt. Wenn Sie Ihr Anfrageprofil kennen, rechnen wir das gemeinsam durch, mit Ihren Zahlen statt unseren Annahmen.

GPU-Scheduling auf Kubernetes: DRA statt Device Plugins

Dynamic Resource Allocation ersetzt die Zählweise „gib mir eine GPU” durch eine Anforderung an Eigenschaften. Der Kern von DRA ist seit Kubernetes v1.34 GA, die API-Gruppe ist resource.k8s.io/v1; die Konzeptseite der Doku führt DRA inzwischen als Kubernetes v1.35 [stable].

Das alte Device Plugin kannte nur nvidia.com/gpu: 4. Welche vier Karten der Scheduler nimmt, war ihm egal. Bei einem 70B-Modell mit Tensor-Parallelismus ist das kein Detail: Vier Karten mit 24 GB sind nicht dasselbe wie vier mit 96 GB, und der Pod stirbt erst beim Laden der Gewichte.

Mit DRA formulieren Sie die Anforderung als CEL-Ausdruck gegen die Attribute, die der Treiber publiziert:

# Vier GPUs mit je mindestens 80 GiB, exklusiv für einen vLLM-Pod.
# Setzt den DRA-Treiber für NVIDIA-GPUs voraus (DeviceClass gpu.nvidia.com).
apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
  name: apertus-70b-gpus
  namespace: inference
spec:
  spec:
    devices:
      requests:
        - name: gpu
          exactly:
            deviceClassName: gpu.nvidia.com
            allocationMode: ExactCount
            count: 4
            selectors:
              - cel:
                  expression: |
                    device.capacity['gpu.nvidia.com'].memory.isGreaterThan(quantity('80Gi'))

Der Pod referenziert das Template, statt eine Zahl zu fordern:

spec:
  resourceClaims:
    - name: gpu
      resourceClaimTemplateName: apertus-70b-gpus
  containers:
    - name: vllm
      image: vllm/vllm-openai:v0.27.1
      resources:
        claims:
          - name: gpu

Der Unterschied in der Praxis: Ein falsch dimensionierter Node fällt beim Scheduling durch, nicht nach acht Minuten Modell-Download. Der DRA-Treiber für NVIDIA-GPUs publiziert dafür unter anderem productName, architecture und cudaComputeCapability.

Inference-Serving: was zwischen Modell und Anwendung gehört

vLLM ist der Modellserver, nicht die Plattform. Es macht Continuous Batching, PagedAttention und einen OpenAI-kompatiblen Endpunkt. Was es nicht macht: entscheiden, welche von acht Replicas eine Anfrage bekommt.

Ein Deployment-Ausschnitt für Apertus. Tool-Parser und Chat-Template stammen aus der Modellkarte; das Kontextfenster ist halbiert, weil der KV-Cache sonst den GPU-Speicher füllt:

containers:
  - name: vllm
    image: vllm/vllm-openai:v0.27.1
    args:
      - --model=swiss-ai/Apertus-v1.5-70B
      - --served-model-name=apertus-70b
      - --tensor-parallel-size=4
      - --max-model-len=131072
      - --gpu-memory-utilization=0.90
      - --chat-template-content-format=string
      - --enable-auto-tool-choice
      - --tool-call-parser=apertus
    ports:
      - containerPort: 8000
    readinessProbe:
      httpGet: { path: /health, port: 8000 }

Das Routing gehört eine Ebene höher. Die Gateway API Inference Extension (v1.6.0 vom 17.08.2026) bringt den InferencePool und einen Endpoint Picker, der Warteschlangentiefe und KV-Cache-Auslastung auswertet. Ein Round-Robin-Loadbalancer trifft dagegen ein Replica, dessen Cache den Präfix nicht hat, und zahlt den Prefill zweimal.

apiVersion: inference.networking.k8s.io/v1
kind: InferencePool
metadata:
  name: apertus-70b
spec:
  selector:
    matchLabels: { app: apertus-70b }
  targetPorts:
    - number: 8000
  endpointPickerRef:
    name: apertus-70b-epp
    port: { number: 9002 }
    failureMode: FailOpen

llm-d (v0.9.0 vom 17.08.2026) kombiniert beides zu disaggregiertem Serving, also Prefill und Decode auf getrennten Pods. Für die meisten Installationen dieser Grösse ist das eine Nummer zu gross.

Wo Souveränität real bricht

Das Modell ist selten das Problem. Die Bruchstellen sitzen in der Peripherie, die niemand als KI-Komponente wahrnimmt und deshalb niemand prüft.

Monitoring-SaaS ist die häufigste Bruchstelle. Ein OpenTelemetry-Trace um einen LLM-Aufruf transportiert Attribute wie gen_ai.input.messages und gen_ai.output.messages, also den vollständigen Gesprächsinhalt. Wer den Collector auf einen US-Anbieter zeigen lässt, exportiert damit den Prompt, nicht nur Latenzen. Das ist kein Konfigurationsfehler, sondern das Default-Verhalten gängiger Instrumentierungen. Welche datenschutzrechtlichen Folgen daran hängen, steht in revDSG-konforme KI-Architektur.

Die Vektordatenbank speichert den Klartext gleich mit. Jede RAG-Implementierung legt den Quelltext-Chunk als Payload neben den Vektor, sonst kann sie ihn nicht in den Prompt setzen. Eine Managed-Vektordatenbank mit Region Irland ist damit eine Kopie Ihres Dokumentenbestands ausserhalb der Schweiz.

Der Support-Zugriff steht im Vertrag, nicht im Architekturdiagramm. Ob ein Anbieter Second-Level-Support aus einem Drittstaat leistet und ob dieses Team Leseberechtigung auf Produktivsysteme hat, ist eine Frage an den Einkauf. Sie wird selten gestellt.

Das CDN sieht jede Anfrage, bevor sie den Origin erreicht. Wer einen US-CDN vor den Inference-Endpunkt setzt, hat den Prompt im Klartext bei einem Anbieter unter CLOUD-Act-Zugriff.

Dazu die leiseren: der Embedding-Dienst, oft ein anderer Anbieter als der LLM-Dienst, und der Objektspeicher für Modellgewichte, dessen Bucket-Region niemand mehr prüft. Wer diese Punkte auditiert, hat mehr für die Souveränität getan als mit der Wahl des Modells. Dieselbe Disziplin brauchte die verteilte Plattform, die wir für onocoy gebaut haben.

Wann souveräne Inferenz die falsche Antwort ist

Für die Mehrheit der Anwendungsfälle, die wir sehen, ist eigener GPU-Betrieb die teurere und langsamere Lösung. Unterhalb von etwa einer Million Anfragen pro Monat zahlen Sie für Souveränität einen Aufschlag, ohne technischen Gegenwert.

Ein API-Anbieter mit sauberem Auftragsbearbeitungsvertrag, dokumentiertem Datenstandort und einer Zusicherung zum Modelltraining deckt die revDSG-Anforderungen für Geschäftsdaten in aller Regel ab. Infomaniak etwa verarbeitet in Genf und Zürich. Das ist in Tagen produktiv, nicht in Wochen.

Eigenbetrieb lohnt sich, wenn eines davon zutrifft: Das Volumen liegt dauerhaft über dem Kipppunkt. Die Daten fallen unter ein Berufsgeheimnis nach Art. 321 StGB. Oder Sie brauchen eine gepinnte Modellversion, weil eine Validierung daran hängt.

Wovon wir abraten: von der Zwischenlösung mit eigenem Cluster, aber Monitoring, Vektordatenbank und CDN beim US-Anbieter. Das kostet den vollen Betriebsaufwand und liefert die Souveränität trotzdem nicht.

Die Entscheidungsmatrix

Kriterium	API-Bezug	Dedizierte GPU in der Schweiz	On-prem oder Colocation
Anfragevolumen	bis rund 1 Mio. pro Monat	ab rund 3 Mio. pro Monat, planbar	dauerhaft hoch, über 3 Jahre gerechnet
Datenklasse	Geschäftsdaten ohne besondere Kategorien	besonders schützenswerte Personendaten (Art. 5 lit. c revDSG)	Berufsgeheimnis (Art. 321 StGB), Daten mit Ausfuhrverbot
Modellkontrolle	Anbieter bestimmt Version und Deprecation	Sie pinnen Version und Quantisierung	zusätzlich Treiber und Kernel
Latenzsteuerung	keine, Batching liegt beim Anbieter	Batchgrösse, KV-Cache, Präfix-Routing	zusätzlich der Netzwerkpfad
Betriebsaufwand	API-Schlüssel und Rechnung	Cluster, DRA-Treiber, vLLM, Gateway, Kapazitätsplanung	zusätzlich Hardware-Lifecycle
Zeit bis produktiv	Stunden	Tage bis Wochen	Monate

Die Zeilen sind nicht gleich gewichtet. Fast immer entscheidet die zweite: Welche Datenklasse fliesst durch den Prompt. Der Rest ist danach eine Kostenfrage.

Häufige Fragen

Welche Schweizer Alternativen zu ChatGPT gibt es?

Apertus ist das offene Schweizer Sprachmodell von EPFL, ETH Zürich und CSCS, in Version 1.5 seit dem 24. Juli 2026 verfügbar. Beziehen lässt es sich über Infomaniak AI Services, die Swisscom Swiss AI Platform, Phoenix Technologies oder von Hugging Face zum Eigenbetrieb. Daneben betreiben Schweizer Anbieter Endpunkte für offene Modelle von Mistral, Qwen und Google.

Was kostet ein selbst gehostetes LLM im Vergleich zur API?

Nach unserer Modellrechnung vom 19. August 2026 kosten vier RTX Pro 6000 bei Exoscale im Dauerbetrieb CHF 6’200 pro Monat. Dieselbe Last über die Infomaniak-API kostet bei 3’000 Input- und 500 Output-Tokens CHF 0.00335 pro Anfrage. Der rechnerische Kipppunkt liegt bei 1.85 Millionen Anfragen im Monat, mit Reserve für Spitzen und Ausfälle eher bei drei bis vier Millionen.

Welche Hardware brauche ich für ein eigenes LLM?

Für Apertus-v1.5-70B nennt die Modellkarte vier GPUs bei vollem Kontextfenster: 72 Milliarden Parameter in BF16 sind 144 GB reine Gewichte, dazu kommt der KV-Cache. Das 8B-Modell läuft auf einer Karte mit 48 GB komfortabel. Quantisierung senkt den Bedarf, kostet aber Qualität und muss für den konkreten Anwendungsfall gemessen werden.

Schützt Schweizer Hosting vor dem US CLOUD Act?

Nur, wenn der Betreiber nicht US-Recht untersteht. 18 U.S.C. § 2713 verpflichtet US-Anbieter zur Herausgabe von Daten unabhängig vom Speicherort. Entscheidend ist also die Gesellschaftsstruktur des Anbieters, nicht die Adresse des Rechenzentrums. Ein Rechenzentrum in Zürich, betrieben von einer Schweizer Tochter eines US-Konzerns, fällt weiterhin unter den Zugriff.

Inferenz-Architektur besprechen. 30 Minuten mit einem unserer Engineers über Ihren konkreten Fall: welches Modell, welches Volumen, wo die Daten liegen und wo die Peripherie die Jurisdiktion verlässt. Kein Verkaufsgespräch, keine Vorbereitung nötig.

Einen Termin gibt es hier. Wer lieber erst schreibt, erreicht uns über Kontakt. Woran wir arbeiten, steht unter Künstlicher Intelligenz und Kubernetes und Infrastruktur.

MCP-Server in Go produktiv betreiben

Ralph Segi — Fri, 21 Aug 2026 00:00:00 GMT

Ein MCP-Server nach der Spezifikation vom 28. Juli 2026 hält keinen Sitzungszustand. Die Revision entfernt den initialize-Handshake und den Mcp-Session-Id-Header: Jede Anfrage trägt Protokollversion und Client-Identität selbst, in _meta. Für einen produktiven Server in Go heisst das drei Dinge: Round-Robin hinter einem gewöhnlichen Load Balancer, Zustand in server-vergebenen Handles, Identität in einem OAuth-Token pro Aufruf.

Primärquelle ist die Änderungsliste der Revision 2026-07-28. Alle Codebeispiele unten sind gegen das offizielle Go-SDK v1.7.0 übersetzt, das am selben Tag stabil erschienen ist.

Was die Spezifikation vom 28. Juli 2026 ändert

Die Revision 2026-07-28 macht MCP von einem bidirektionalen, zustandsbehafteten Protokoll zu einem Request/Response-Protokoll. Neun Punkte führt die Änderungsliste als „Major changes”, und sechs davon zwingen zu Arbeit an einem bestehenden Server.

Vorher (2025-11-25)	Nachher (2026-07-28)	Was Sie anpassen müssen
`initialize`-Handshake, `Mcp-Session-Id`-Header	Jede Anfrage selbstbeschreibend über `_meta`; neu Pflicht-RPC `server/discover`	Sticky Sessions am Load Balancer abschalten, prozesslokalen Sitzungsspeicher entfernen
Server-initiierte Requests (`roots/list`, `sampling/createMessage`, `elicitation/create`) über gehaltenen Stream	Multi Round-Trip Requests: Server antwortet mit `resultType: "input_required"`, Client wiederholt mit `inputResponses`	Zwischenzustand in `requestState` kodieren statt im Prozess halten
Routing durch Inspektion des JSON-Bodys	Pflicht-Header `Mcp-Method` auf jedem Streamable-HTTP-POST, `Mcp-Name` zusätzlich bei `tools/call`, `resources/read` und `prompts/get`	Gateway-Regeln auf Header umstellen, sonst `HeaderMismatchError` (`-32020`)
Listenergebnisse ohne Cache-Hinweis	`ttlMs` und `cacheScope` sind auf `tools/list`, `prompts/list`, `resources/list`, `resources/read` und `resources/templates/list` Pflichtfelder	Werte bewusst setzen; bei nutzerabhängigen Toollisten `cacheScope: "private"`
Roots, Sampling und Logging aktiv	Alle drei deprecated (SEP-2577), weiterhin funktionsfähig	Nach `stderr` oder über OpenTelemetry loggen, Sampling durch direkten Aufruf der Provider-API ersetzen
Dynamic Client Registration (RFC 7591) als Standardweg	Deprecated zugunsten von Client ID Metadata Documents	CIMD unterstützen, DCR nur noch als Rückfallebene betreiben

Für die Planung zählt der Governance-Teil: Die Spezifikation hat erstmals eine Feature-Lifecycle- und Deprecation-Policy mit einem Mindestfenster von zwölf Monaten. Wer Roots, Sampling oder Logging im Einsatz hat, muss nicht diese Woche umbauen. Wer neu baut, fasst sie gar nicht erst an.

Ein verbreitetes Missverständnis betrifft Tasks: Sie sind nicht in den Kern gewandert, sondern aus dem experimentellen Kern heraus in die Erweiterung io.modelcontextprotocol/tasks. MCP Apps (io.modelcontextprotocol/ui) und Enterprise-Managed Authorization stehen ebenfalls ausserhalb des Kerns, waren dort aber nie: Beide sind von Beginn weg Erweiterungen. Erweiterungen sind opt-in und werden über das Feld extensions ausgehandelt.

Warum ein MCP-Server in Go gebaut wird

Go ist die Sprache, in der die Agenten-Infrastruktur ohnehin schon geschrieben ist: Kubernetes-Controller, Inference-Gateways, agentgateway, kagent. Warum wir kritische Backends generell in Go bauen, steht in einem eigenen Beitrag über Go für langlebige Systeme, und der Rest dieses Texts wiederholt das nicht.

Ein Punkt kommt für MCP neu dazu. Ein Tool-Server ist ein kurzlebiger Prozess, der oft neu startet, in vielen Instanzen läuft und gelegentlich pro Mandant separat deployt wird. Ein statisches Binary in einem FROM scratch-Image ist dafür eine andere Ausgangslage als ein Interpreter mit Paketbaum.

Das Go-SDK verlangt in seiner go.mod mindestens Go 1.25.0. Als Unterbau empfiehlt sich Go 1.26 mit dem Patch-Stand 1.26.6 vom 13. August 2026.

Zustandslos heisst, dass der Zustand einen Namen bekommt

Ein produktiver MCP-Server hält keinen Sitzungszustand im Prozess. Zustand gehört in einen externen Speicher und wird über ein server-vergebenes Handle adressiert, das als gewöhnliches Tool-Argument hin und zurück läuft. So beschreibt es SEP-2567.

Der Gewinn: Der zweite Aufruf darf auf einer anderen Instanz landen, ein Deployment mitten in einer Agenten-Sitzung zerstört nichts, und der Load Balancer braucht keine Klebrigkeit. Im Go-SDK ist das ein Feld, StreamableHTTPOptions.Stateless.

Die vier Beispiele in diesem Beitrag sind vollständige Programme: kopieren, go get github.com/modelcontextprotocol/go-sdk@v1.7.0, go run .

// Vollständiges Programm. go get github.com/modelcontextprotocol/go-sdk@v1.7.0
package main

import (
	"context"
	"encoding/json"
	"fmt"
	"log"
	"net/http"
	"sync"
	"time"

	"github.com/modelcontextprotocol/go-sdk/mcp"
)

// Store ist der externe Zustandsspeicher. Produktiv: Redis, Valkey, Postgres.
// Nur nicht der Prozess, denn der nächste Aufruf landet auf einer anderen Instanz.
type Store interface {
	Put(ctx context.Context, handle string, v any, ttl time.Duration) error
	Get(ctx context.Context, handle string, v any) error
}

// memStore ist die Wegwerf-Variante, damit dieses Beispiel ohne Redis läuft.
type memStore struct{ m sync.Map }

func (s *memStore) Put(_ context.Context, h string, v any, _ time.Duration) error {
	b, err := json.Marshal(v)
	if err != nil {
		return err
	}
	s.m.Store(h, b)
	return nil
}

func (s *memStore) Get(_ context.Context, h string, v any) error {
	b, ok := s.m.Load(h)
	if !ok {
		return fmt.Errorf("Handle %q unbekannt oder abgelaufen", h)
	}
	return json.Unmarshal(b.([]byte), v)
}

type exportState struct {
	UserID string   `json:"user_id"`
	Zeilen []string `json:"zeilen"`
}

type startIn struct {
	Mandant string `json:"mandant" jsonschema:"Mandantenkürzel, drei Grossbuchstaben"`
}

type startOut struct {
	Handle string `json:"handle" jsonschema:"Undurchsichtiges Handle, unverändert an export_seite zurückgeben"`
	Gesamt int    `json:"gesamt" jsonschema:"Anzahl Zeilen im Export"`
}

type seiteIn struct {
	Handle string `json:"handle" jsonschema:"Handle aus export_starten"`
}

func addExport(s *mcp.Server, store Store) {
	mcp.AddTool(s, &mcp.Tool{
		Name:        "export_starten",
		Description: "Startet einen Buchungsexport und liefert ein Handle. Ruft selbst keine Daten ab.",
	}, func(ctx context.Context, req *mcp.CallToolRequest, in startIn) (*mcp.CallToolResult, startOut, error) {
		zeilen := []string{"B-1", "B-2", "B-3"}
		handle := fmt.Sprintf("exp_%s_%d", in.Mandant, time.Now().UnixNano())
		st := exportState{UserID: userID(req), Zeilen: zeilen}
		if err := store.Put(ctx, handle, st, 15*time.Minute); err != nil {
			return nil, startOut{}, fmt.Errorf("Handle konnte nicht abgelegt werden: %w", err)
		}
		return nil, startOut{Handle: handle, Gesamt: len(zeilen)}, nil
	})

	mcp.AddTool(s, &mcp.Tool{
		Name:        "export_seite",
		Description: "Liefert die Zeilen eines mit export_starten begonnenen Exports.",
	}, func(ctx context.Context, req *mcp.CallToolRequest, in seiteIn) (*mcp.CallToolResult, any, error) {
		var st exportState
		if err := store.Get(ctx, in.Handle, &st); err != nil {
			return nil, nil, fmt.Errorf("%w, bitte export_starten erneut aufrufen", err)
		}
		// Das Handle gehört dem Aufrufer, oder es wird nicht bedient.
		if st.UserID != userID(req) {
			return nil, nil, fmt.Errorf("Handle %q gehört zu einer anderen Identität", in.Handle)
		}
		b, _ := json.Marshal(st.Zeilen)
		return &mcp.CallToolResult{Content: []mcp.Content{&mcp.TextContent{Text: string(b)}}}, nil, nil
	})
}

// userID liefert die Identität aus dem Bearer Token, siehe Abschnitt Authentifizierung.
func userID(req *mcp.CallToolRequest) string {
	if req.Extra != nil && req.Extra.TokenInfo != nil {
		return req.Extra.TokenInfo.UserID
	}
	return ""
}

func main() {
	store := &memStore{} // eine Instanz, ausserhalb des Request-Pfads

	handler := mcp.NewStreamableHTTPHandler(func(r *http.Request) *mcp.Server {
		s := mcp.NewServer(&mcp.Implementation{Name: "erp-bridge", Version: "1.4.0"}, nil)
		addExport(s, store)
		return s
	}, &mcp.StreamableHTTPOptions{
		// Kein Mcp-Session-Id, keine gehaltene Verbindung, kein Prozessgedächtnis.
		Stateless:    true,
		JSONResponse: true,
	})

	log.Fatal((&http.Server{
		Addr:              ":8080",
		Handler:           handler,
		ReadHeaderTimeout: 5 * time.Second,
	}).ListenAndServe())
}

Das Handle bekommt eine TTL und einen Eigentümer. Ohne TTL wächst der Speicher unbegrenzt, ohne die Eigentümerprüfung in export_seite kann ein zweiter Nutzer ein fremdes Handle einlösen. Beides sind zwei Zeilen, und beide fehlen in den meisten Beispielprojekten.

Authentifizierung: wie ein Tool-Aufruf an eine Benutzeridentität gebunden wird

Ein Tool-Aufruf wird über ein OAuth-2.1-Access-Token an eine Identität gebunden, dessen aud-Claim die kanonische URI genau dieses MCP-Servers enthält. Die Spezifikation ist hier ungewöhnlich deutlich: MCP-Server müssen prüfen, dass ein Token für sie als Zielgruppe ausgestellt wurde, und sie dürfen keine anderen Tokens akzeptieren oder weiterreichen.

Das ist der Abschnitt, den die Beispielprojekte auslassen. Ein Prototyp läuft mit einem geteilten Bearer-Token in einer Umgebungsvariable, und alle Tool-Aufrufe erreichen die Datenbank unter demselben Dienstkonto. Im Log ist dann nicht mehr feststellbar, welcher Mensch was ausgelöst hat.

Dazu kommt eine Pflicht, die nicht neu ist, aber regelmässig fehlt: Der Server muss OAuth 2.0 Protected Resource Metadata nach RFC 9728 ausliefern, sonst findet kein Client den zuständigen Authorization Server. Das steht so schon in der Revision 2025-06-18.

// Vollständiges Programm. go get github.com/modelcontextprotocol/go-sdk@v1.7.0 github.com/golang-jwt/jwt/v5
package main

import (
	"context"
	"fmt"
	"log"
	"net/http"
	"slices"
	"strings"

	"github.com/golang-jwt/jwt/v5"
	"github.com/modelcontextprotocol/go-sdk/auth"
	"github.com/modelcontextprotocol/go-sdk/mcp"
	"github.com/modelcontextprotocol/go-sdk/oauthex"
)

const (
	// canonicalURI ist der Resource Indicator nach RFC 8707. Genau dieser Wert
	// muss in der aud-Claim stehen, sonst war das Token für einen anderen Dienst.
	canonicalURI = "https://mcp.example.ch/mcp"
	issuer       = "https://login.example.ch/realms/erp"
)

// claims ergänzt die Standard-Claims um scope, wie es Keycloak und Entra ID liefern.
type claims struct {
	Scope string `json:"scope"`
	jwt.RegisteredClaims
}

func verifyToken(parser *jwt.Parser, keyFunc jwt.Keyfunc) auth.TokenVerifier {
	return func(ctx context.Context, raw string, _ *http.Request) (*auth.TokenInfo, error) {
		var c claims
		if _, err := parser.ParseWithClaims(raw, &c, keyFunc); err != nil {
			return nil, fmt.Errorf("%w: %v", auth.ErrInvalidToken, err)
		}
		if c.Issuer != issuer {
			return nil, fmt.Errorf("%w: unerwarteter Aussteller %q", auth.ErrInvalidToken, c.Issuer)
		}
		if !slices.Contains(c.Audience, canonicalURI) {
			return nil, fmt.Errorf("%w: Token nicht für %s ausgestellt", auth.ErrInvalidToken, canonicalURI)
		}
		if c.Subject == "" {
			return nil, fmt.Errorf("%w: kein sub-Claim, keine Identität", auth.ErrInvalidToken)
		}
		return &auth.TokenInfo{
			UserID:     c.Subject,
			Scopes:     strings.Fields(c.Scope),
			Expiration: c.ExpiresAt.Time,
		}, nil
	}
}

type buchungIn struct {
	Konto   string `json:"konto" jsonschema:"Kontonummer nach Schweizer KMU-Kontenrahmen"`
	Rappen  int    `json:"betrag_rappen" jsonschema:"Betrag in Rappen, ganzzahlig"`
	IdemKey string `json:"idempotenz_schluessel" jsonschema:"Vom Aufrufer erzeugte UUID. Derselbe Schlüssel bucht nie zweimal."`
}

func buchen(ctx context.Context, req *mcp.CallToolRequest, in buchungIn) (*mcp.CallToolResult, any, error) {
	tok := req.Extra.TokenInfo
	if tok == nil {
		return nil, nil, fmt.Errorf("Aufruf ohne Identität")
	}
	if !slices.Contains(tok.Scopes, "buchhaltung:schreiben") {
		return nil, nil, fmt.Errorf("Scope buchhaltung:schreiben fehlt")
	}
	// Ab hier läuft jede Abfrage unter tok.UserID, nicht unter einem Dienstkonto.
	log.Printf("buchung user=%s konto=%s rappen=%d idem=%s", tok.UserID, in.Konto, in.Rappen, in.IdemKey)
	return &mcp.CallToolResult{Content: []mcp.Content{&mcp.TextContent{Text: "gebucht"}}}, nil, nil
}

func main() {
	server := mcp.NewServer(&mcp.Implementation{Name: "erp-bridge", Version: "1.4.0"}, nil)
	mcp.AddTool(server, &mcp.Tool{
		Name:        "buchung_erfassen",
		Description: "Erfasst eine Buchung. Schreibend. Derselbe Idempotenz-Schlüssel erzeugt nie eine zweite Buchung.",
		Annotations: &mcp.ToolAnnotations{IdempotentHint: true},
	}, buchen)

	mcpHandler := mcp.NewStreamableHTTPHandler(
		func(*http.Request) *mcp.Server { return server },
		&mcp.StreamableHTTPOptions{Stateless: true},
	)

	var keyFunc jwt.Keyfunc // aus dem JWKS des Ausstellers, gecached
	requireToken := auth.RequireBearerToken(
		verifyToken(jwt.NewParser(jwt.WithValidMethods([]string{"RS256", "ES256"})), keyFunc),
		&auth.RequireBearerTokenOptions{
			Scopes:              []string{"buchhaltung:lesen"},
			ResourceMetadataURL: "https://mcp.example.ch/.well-known/oauth-protected-resource",
		},
	)

	mux := http.NewServeMux()
	mux.Handle("/mcp", requireToken(mcpHandler))
	// RFC 9728. Die Spezifikation macht dieses Dokument zur Pflicht: ohne es
	// findet kein Client den zuständigen Authorization Server.
	mux.Handle("/.well-known/oauth-protected-resource", auth.ProtectedResourceMetadataHandler(
		&oauthex.ProtectedResourceMetadata{
			Resource:             canonicalURI,
			AuthorizationServers: []string{issuer},
			ScopesSupported:      []string{"buchhaltung:lesen", "buchhaltung:schreiben"},
		}))

	log.Fatal(http.ListenAndServe(":8080", mux))
}

Der entscheidende Punkt liegt in einer einzigen Zeile: tok.UserID stammt aus dem sub-Claim und steht ab da jedem Tool-Handler zur Verfügung. Der Agent erbt damit exakt die Rechte des angemeldeten Menschen, nicht die eines Dienstkontos.

In der Schweiz ist das nicht bloss guter Stil. Artikel 4 der Datenschutzverordnung (DSV, SR 235.11), der Ausführungsverordnung zum revDSG, verpflichtet private Verantwortliche zur Protokollierung, sobald sie besonders schützenswerte Personendaten in grossem Umfang automatisiert bearbeiten und die präventiven Massnahmen den Datenschutz nicht gewährleisten können. Absatz 4 sagt, was drinstehen muss: Aufschluss über „die Identität der Person, die die Bearbeitung vorgenommen hat, die Art, das Datum und die Uhrzeit der Bearbeitung”.

Absatz 5 setzt die Aufbewahrung auf mindestens ein Jahr, getrennt vom bearbeitenden System. Ein geteiltes Dienstkonto erfüllt das technisch nicht. Was das revDSG darüber hinaus von einem Agentensystem verlangt, Norm für Norm, steht in revDSG-konforme KI-Architektur.

Genau hier bleiben die meisten Prototypen stehen, und meistens erst dann, wenn das Sicherheitsreview kommt. Wenn Sie an dieser Stelle stehen: Wir schauen uns Ihre Kette vom Identity Provider bis zum Tool-Handler einmal gemeinsam an und sagen, wo sie reisst. Termin buchen.

Tool-Design: die Fehler, die wir am häufigsten sehen

Die drei häufigsten Fehler im Tool-Design sind zu viele Werkzeuge, unscharfe Beschreibungen und fehlende Idempotenz. Alle drei zeigen sich erst im Betrieb, als falsch gewählte Werkzeuge und doppelte Buchungen.

Eine Beschreibung ist der einzige Kontext, den das Modell bei der Auswahl hat. Sie gehört mit Abgrenzung geschrieben: was das Werkzeug tut, was es nicht tut, und welches andere Werkzeug für den Nachbarfall zuständig ist.

// Vollständiges Programm, spricht Streamable HTTP auf :8080.
package main

import (
	"context"
	"fmt"
	"log"
	"net/http"

	"github.com/modelcontextprotocol/go-sdk/mcp"
)

type sucheIn struct {
	KundenNr string `json:"kunden_nr" jsonschema:"Kundennummer im Format K-00000, exakt wie in Abacus hinterlegt"`
	Jahr     int    `json:"jahr" jsonschema:"Geschäftsjahr, vierstellig, zwischen 2015 und 2030"`
}

type sucheOut struct {
	Treffer  []string `json:"treffer" jsonschema:"Rechnungsnummern, absteigend nach Datum"`
	Gesamt   int      `json:"gesamt" jsonschema:"Anzahl Treffer insgesamt, auch wenn die Liste begrenzt ist"`
	Begrenzt bool     `json:"begrenzt" jsonschema:"true, wenn auf 50 Einträge gekürzt wurde"`
}

func suchen(ctx context.Context, req *mcp.CallToolRequest, in sucheIn) (*mcp.CallToolResult, sucheOut, error) {
	if in.Jahr < 2015 || in.Jahr > 2030 {
		// Fehlertext als Anweisung, nicht als Statuscode. Das Modell liest ihn.
		return nil, sucheOut{}, fmt.Errorf(
			"Jahr %d liegt ausserhalb des gepflegten Bereichs 2015 bis 2030, bitte mit einem Jahr in diesem Bereich erneut aufrufen", in.Jahr)
	}
	return nil, sucheOut{Treffer: []string{"RE-2026-0184"}, Gesamt: 1}, nil
}

func main() {
	server := mcp.NewServer(&mcp.Implementation{Name: "erp-bridge", Version: "1.4.0"}, nil)

	mcp.AddTool(server, &mcp.Tool{
		Name: "rechnungen_suchen",
		Description: "Sucht Debitorenrechnungen eines Kunden in einem Geschäftsjahr. " +
			"Liefert höchstens 50 Rechnungsnummern und ändert nichts. " +
			"Nicht verwenden, um eine bekannte Rechnungsnummer zu laden, dafür ist rechnung_lesen da.",
		Annotations: &mcp.ToolAnnotations{ReadOnlyHint: true, Title: "Rechnungen suchen"},
	}, suchen)

	handler := mcp.NewStreamableHTTPHandler(
		func(*http.Request) *mcp.Server { return server },
		&mcp.StreamableHTTPOptions{Stateless: true},
	)
	log.Fatal(http.ListenAndServe(":8080", handler))
}

Aufrufen lässt sich das mit curl. Ein Streamable-HTTP-POST braucht seit 2026-07-28 drei Header und zwei Pflichtfelder in _meta, sonst antwortet der Server mit -32020 oder -32602:

curl -sN -X POST http://localhost:8080/ \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'Mcp-Protocol-Version: 2026-07-28' \
  -H 'Mcp-Method: tools/call' \
  -H 'Mcp-Name: rechnungen_suchen' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{
        "name":"rechnungen_suchen",
        "arguments":{"kunden_nr":"K-00042","jahr":1999},
        "_meta":{
          "io.modelcontextprotocol/protocolVersion":"2026-07-28",
          "io.modelcontextprotocol/clientCapabilities":{},
          "io.modelcontextprotocol/clientInfo":{"name":"curl","version":"1"}}}}'

# event: message
# data: {"jsonrpc":"2.0","id":1,"result":{"content":[{"type":"text",
#   "text":"Jahr 1999 liegt ausserhalb des gepflegten Bereichs 2015 bis 2030,
#           bitte mit einem Jahr in diesem Bereich erneut aufrufen"}],
#   "isError":true,"resultType":"complete"}}

Der Fehlerfall kommt als isError: true mit lesbarem Text zurück, nicht als JSON-RPC-Fehler. Das ist Absicht: Ein Modell kann einen Satz lesen und den Aufruf korrigieren, einen Statuscode kann es nur raten.

Ein Detail, das beim Nachbauen auffällt: Das Go-SDK setzt auf tools/list standardmässig cacheScope: "public". Wer eine nutzerabhängige Werkzeugliste ausliefert, muss private selbst setzen, sonst darf ein Gateway die Liste des einen Nutzers dem nächsten zeigen.

Für schreibende Werkzeuge gilt dieselbe Logik wie für eine Zahlungs-API: Der Aufrufer schickt einen selbst erzeugten Schlüssel mit, der Server reserviert ihn vor der Verarbeitung, und eine Wiederholung liefert dieselbe Antwort ohne zweite Wirkung. Wie wir das bauen, steht in unserem Beitrag über Idempotenz in Zahlungs-APIs.

Bei Agenten ist die Wiederholung häufiger als bei Menschen, weil ein Modell nach einem Timeout einfach nochmals aufruft.

Zur Menge: Zwanzig scharf geschnittene Werkzeuge schlagen sechzig überlappende. Und tools/list soll seit dieser Revision deterministisch sortiert sein, was die Prompt-Cache-Trefferquote der Clients verbessert.

Betrieb: Timeouts, Rate Limits und was in die Logs gehört

Ein fehlgeschlagener Tool-Aufruf ist rekonstruierbar, wenn eine einzige Logzeile Werkzeugname, Identität, Protokollversion, Dauer und Korrelations-ID enthält. Die Revision 2026-07-28 dokumentiert dafür erstmals die OpenTelemetry-Konventionen für _meta: traceparent, tracestate und baggage reisen im Protokoll mit.

// Vollständiges Programm. Jeder Tool-Aufruf erzeugt genau eine JSON-Logzeile.
package main

import (
	"context"
	"log"
	"log/slog"
	"net/http"
	"os"
	"time"

	"github.com/modelcontextprotocol/go-sdk/mcp"
)

// logToolCalls schreibt pro Tool-Aufruf eine Zeile, aus der sich ein
// Fehlschlag ohne Rückfrage rekonstruieren lässt.
func logToolCalls(logger *slog.Logger) mcp.Middleware {
	return func(next mcp.MethodHandler) mcp.MethodHandler {
		return func(ctx context.Context, method string, req mcp.Request) (mcp.Result, error) {
			call, ok := req.(*mcp.CallToolRequest)
			if !ok || method != "tools/call" {
				return next(ctx, method, req)
			}

			start := time.Now()
			res, err := next(ctx, method, req)

			attrs := []any{
				slog.String("tool", call.Params.Name),
				slog.String("protocol_version", call.ProtocolVersion()),
				slog.Duration("dauer", time.Since(start)),
			}
			// traceparent reist nach der Spezifikation 2026-07-28 in _meta mit.
			if tp, ok := call.Params.Meta["traceparent"].(string); ok {
				attrs = append(attrs, slog.String("traceparent", tp))
			}
			if extra := call.GetExtra(); extra != nil && extra.TokenInfo != nil {
				attrs = append(attrs, slog.String("user_id", extra.TokenInfo.UserID))
			}
			if err != nil {
				logger.Error("tool_call fehlgeschlagen", append(attrs, slog.String("fehler", err.Error()))...)
			} else {
				logger.Info("tool_call", attrs...)
			}
			return res, err
		}
	}
}

func main() {
	logger := slog.New(slog.NewJSONHandler(os.Stderr, nil))

	server := mcp.NewServer(&mcp.Implementation{Name: "erp-bridge", Version: "1.4.0"}, nil)
	server.AddReceivingMiddleware(logToolCalls(logger))

	mcp.AddTool(server, &mcp.Tool{
		Name:        "ping",
		Description: "Antwortet mit pong. Dient nur der Prüfung der Logkette.",
		Annotations: &mcp.ToolAnnotations{ReadOnlyHint: true},
	}, func(ctx context.Context, req *mcp.CallToolRequest, _ struct{}) (*mcp.CallToolResult, any, error) {
		return &mcp.CallToolResult{Content: []mcp.Content{&mcp.TextContent{Text: "pong"}}}, nil, nil
	})

	handler := mcp.NewStreamableHTTPHandler(
		func(*http.Request) *mcp.Server { return server },
		&mcp.StreamableHTTPOptions{Stateless: true},
	)
	log.Fatal(http.ListenAndServe(":8080", handler))
}

Zwei Betriebsgrössen setzen Sie besser explizit, bevor der erste Vorfall sie für Sie setzt. Erstens ein Timeout pro Werkzeug, nicht pro Server: Eine Volltextsuche darf zehn Sekunden brauchen, ein Kontostand nicht.

Zweitens ein Rate Limit pro Identität statt pro IP. Hinter einer IP sitzt ein ganzes Unternehmen, hinter einer Identität ein Agent, der im Fehlerfall in einer Schleife läuft. Was auf die Dashboards gehört und was nicht, steht in Drei Dashboards statt dreissig.

Ist ein Pod die richtige Einheit für einen Agenten?

Ein Pod pro Agent ist die naheliegende, aber nicht offensichtlich richtige Antwort. Lin Sun von Solo.io hat die Frage am 14. Juli 2026 im CNCF-Blog unter genau diesem Titel gestellt: Is a Pod the right deployment unit for an AI agent?

Ein eigener Pod bringt Prozessisolation und über den ServiceAccount eine Kubernetes-Identität, kostet aber Grundlast: Ein Agent ist Sekunden aktiv und danach lange leer.

Für einen MCP-Server, der reine Tool-Ausführung macht, ist das eine gute Nachricht: Er ist ein gewöhnlicher zustandsloser Dienst und braucht diese Diskussion nicht. Sie wird erst relevant, sobald der Server fremden Code ausführt. Dann ist der Pod die falsche Grenze, und es braucht eine echte Sandbox.

Wovon wir abraten

Bauen Sie keinen MCP-Server, wenn eine gewöhnliche HTTP-API reicht. MCP löst ein Entdeckungsproblem, kein Integrationsproblem: Es beschreibt Werkzeuge so, dass ein Modell sie zur Laufzeit findet und auswählt, ohne dass jemand die Integration vorher fest verdrahtet. Wenn Ihre Anwendung genau weiss, welchen Endpunkt sie aufrufen will, ist ein POST /rechnungen/suchen billiger und einfacher zu betreiben.

Der Trade-off ist real. MCP kostet einen Authorization Server, ein RFC-9728-Dokument, gepflegte Tool-Beschreibungen und ein Protokoll in Bewegung. Dafür bekommen Sie Werkzeuge, die jeder MCP-fähige Client entdecken kann, ohne dass Sie für ihn etwas bauen.

Unsere Linie: Ein MCP-Server lohnt sich, wenn mehr als ein Client dieselben Werkzeuge braucht, oder wenn die Auswahl der Werkzeuge selbst Teil der Aufgabe ist. Für die AI-Agenten-Plattform AIgent trifft das zu.

Für eine einzelne interne Automatisierung mit drei bekannten Aufrufen trifft es nicht zu. Das sagen wir auch dann, wenn ein Projekt anders budgetiert war.

Und: Fangen Sie nicht mit der Deprecation-Migration an, solange die Authentifizierung fehlt. Roots, Sampling und Logging haben zwölf Monate. Ein Server ohne Identitätsbindung hat keine Frist, sondern ein Problem.

Häufige Fragen

Was ist das Model Context Protocol?

Das Model Context Protocol ist ein offenes Protokoll, über das KI-Anwendungen Werkzeuge, Ressourcen und Prompts eines Servers zur Laufzeit entdecken und aufrufen. Es setzt auf JSON-RPC auf und kennt zwei Transporte: STDIO für lokale Prozesse und Streamable HTTP für Netzwerkdienste. Seit der Revision 2026-07-28 ist der Protokollkern zustandslos, jede Anfrage beschreibt sich selbst.

Wie baue ich einen MCP-Server in Go?

Mit dem offiziellen github.com/modelcontextprotocol/go-sdk, aktuell v1.7.0. Ein Server entsteht mit mcp.NewServer, Werkzeuge werden über die generische Funktion mcp.AddTool registriert, die Ein- und Ausgabeschema per Reflection aus Ihren Go-Typen ableitet. Für den Netzwerkbetrieb kommt mcp.NewStreamableHTTPHandler dazu, für lokale Prozesse server.Run mit mcp.StdioTransport.

Wie authentifiziere ich Tool-Aufrufe eines KI-Agenten?

Über OAuth 2.1 mit dem MCP-Server als Resource Server. Der Client holt ein Access Token, dessen aud-Claim die kanonische URI des Servers nennt, und schickt es in jedem HTTP-Request als Bearer Token. Der Server prüft Signatur, Aussteller und Zielgruppe und übersetzt den sub-Claim in eine Identität, unter der die Tool-Handler arbeiten. Ein geteiltes statisches Token erfüllt das nicht.

Muss ich meinen bestehenden MCP-Server jetzt migrieren?

Nicht sofort, aber die Richtung ist klar. Roots, Sampling, Logging, der HTTP+SSE-Transport und Dynamic Client Registration sind deprecated und laufen mindestens zwölf Monate weiter. Die zustandslose Umstellung ist dagegen kein Deprecation-Thema, sondern eine Protokolländerung: Sitzungen und Mcp-Session-Id sind in 2026-07-28 entfernt. Wer neu baut, baut zustandslos.

Über Ihre Agenten-Infrastruktur reden. 30 Minuten mit einem unserer Go-Engineers: welche Werkzeuge Sie überhaupt exponieren wollen, wie die Identität vom Login bis zum Tool-Handler durchgereicht wird, und ob MCP für Ihren Fall die richtige Antwort ist. Ohne Verkaufsgespräch, ohne Vorbereitung auf Ihrer Seite.

Termin buchen · Kontakt aufnehmen · Mehr zu KI- und Agenten-Systemen und Backend-Entwicklung

Warum wir kritische Backends in Go bauen

Ralph Segi — Tue, 04 Aug 2026 00:00:00 GMT

Wenn wir gefragt werden, warum ein Backend in Go und nicht in Node, Java oder Rust entstehen soll, kommt die Antwort selten von den Benchmarks. Go ist schnell, ja. Aber schnell sind viele. Der Grund ist ein anderer: Go zwingt zu einer Einfachheit, die man drei Jahre später noch lesen kann.

Die Sprache hat wenig Meinung – und genau das ist die Meinung

Go hat keine Vererbung, keine Exceptions, keine Generics-Akrobatik, keine drei Wege, eine Schleife zu schreiben. Was auf den ersten Blick wie ein Mangel wirkt, ist im Betrieb ein Geschenk: Code, den ein Junior schreibt, sieht fast so aus wie Code, den ein Senior schreibt. Reviews drehen sich um Fachlichkeit, nicht um Stil.

Ein Backend, das man nicht mehr lesen kann, ist kein Backend mehr. Es ist eine Hypothek.

Für Systeme, die zehn Jahre laufen sollen – und das ist bei Behörden, Banken und Infrastruktur die Regel –, wiegt Lesbarkeit schwerer als jede Feature-Liste.

Fehler sind Werte, keine Überraschungen

if err != nil wird gern belächelt. Wir mögen es. Jeder Fehler ist ein sichtbarer Pfad im Code, den man behandelt oder bewusst weiterreicht. Es gibt keinen Stack, der irgendwo drei Ebenen höher aufschlägt und die Anfrage still verschluckt.

order, err := repo.FindOrder(ctx, id)
if err != nil {
    return fmt.Errorf("find order %s: %w", id, err)
}

Die Fehlerkette, die daraus entsteht, ist im Log lesbar wie ein Satz: handle payment: find order 4711: connection refused. Das ist Observability, für die man kein Tool kaufen muss.

Ein Binary, ein Container, kein Rätsel

Go kompiliert zu einem statischen Binary. Das Deployment ist ein FROM scratch-Container mit einer Datei darin – kein Runtime-Image, kein Paket-Manager, kaum Angriffsfläche. Für Kubernetes-Umgebungen heisst das: kleine Images, schnelle Starts, wenig CVE-Rauschen. Dasselbe Muster tragen wir auch in neue Protokolle, etwa wenn wir MCP-Server in Go produktiv betreiben. Was wir als Golang-Entwickler aus der Schweiz konkret anbieten, steht auf der Leistungsseite.

Nebenläufigkeit, die man erklären kann

Goroutines und Channels sind kein Zauber, aber sie erlauben es, nebenläufige Abläufe so zu schreiben, wie man sie am Whiteboard zeichnet: ein Worker-Pool, eine Pipeline, ein Fan-out. Wer das Modell einmal verstanden hat, liest fremden Code ohne Angst.

Wann wir nicht zu Go greifen

Ehrlichkeit gehört dazu: Für datenlastige Explorationen und ML-Pipelines bleibt Python die richtige Wahl. Für Frontends selbstverständlich TypeScript. Und wo ein Team bereits tief in einem Ökosystem steckt und gut damit fährt, ist ein Sprachwechsel selten die wichtigste Entscheidung.

Aber wo ein System die kritische Infrastruktur eines Unternehmens ist – Zahlungen, Identität, Verwaltung –, ist Go für uns die Sprache, die den geringsten Preis für Klarheit verlangt.

KI schreibt den Code. Wer schreibt die Architektur?

Robert Pupel — Tue, 21 Jul 2026 00:00:00 GMT

Die Code-Menge, die ein Team pro Woche produzieren kann, hat sich mit KI-Assistenten vervielfacht. Die Menge an Code, die ein Team pro Woche verstehen kann, nicht. Genau in dieser Lücke entstehen die technischen Schulden der nächsten Jahre.

Das Problem ist nicht die KI. Es ist die fehlende Bremse.

Ein Assistent, dem man sagt „bau mir das”, baut es. Er fragt nicht, ob es das dritte Repository-Pattern im selben Service ist, ob die neue Abhängigkeit nötig ist oder ob die Funktion, die er gerade schreibt, schon existiert. Das ist keine Kritik an den Werkzeugen. Es ist eine Beschreibung ihrer Aufgabe. Die Bremse muss von aussen kommen.

Drei Regeln, die bei uns gelten

1. Architektur zuerst, dann Prompt. Bevor ein Feature an einen Assistenten geht, ist geklärt, in welches Modul es gehört, welche Schnittstelle es benutzt und was es nicht anfassen darf. Diese Leitplanken stehen im Repository, nicht im Kopf.

2. Jede Änderung wird von einem Menschen gelesen – ganz. Nicht überflogen. Ein Review, das nur die Diff-Statistik prüft, ist kein Review. Wenn ein Diff zu gross ist, um gelesen zu werden, war der Prompt zu gross.

3. Löschen zählt als Fortschritt. Wir messen nicht, wie viel Code entsteht, sondern wie viel Komplexität pro gelöstem Problem übrig bleibt. Ein Assistent ist hervorragend darin, Duplikate zu finden und zusammenzuführen – wenn man ihn danach fragt.

Was sich dadurch verändert

Die Rolle des Entwicklers verschiebt sich vom Schreiben zum Entscheiden. Das ist anspruchsvoller, nicht einfacher: Man muss wissen, wie ein System aussehen soll, bevor man es beschreiben kann. Wer das kann, bekommt mit KI einen Hebel, den es so noch nie gab. Wer es nicht kann, bekommt sehr schnell sehr viel Code.

Menschliche Intelligenz steuert die künstliche – nicht als Slogan, sondern als Arbeitsteilung.

Ein Beispiel aus dem Alltag

Ein Kunde brauchte einen Import für ein neues Datenformat. Der erste KI-Vorschlag: ein neuer Parser, ein neues Datenmodell, 600 Zeilen. Nach zehn Minuten Architektur-Gespräch: ein Adapter von 80 Zeilen, der das bestehende Modell füttert. Beide Varianten hätten funktioniert. Nur eine davon versteht in einem Jahr noch jemand.

Kubernetes ist kein Ziel

Ralph Segi — Tue, 30 Jun 2026 00:00:00 GMT

Kubernetes ist ein hervorragendes Werkzeug. Es ist auch das am häufigsten missverstandene. Wir sehen regelmässig Cluster, die drei Container betreiben, von zwei Personen gewartet werden und mehr kosten als die Anwendung, die darauf läuft.

Die ehrliche Frage vor jedem Cluster

Nicht „können wir Kubernetes?”, sondern: Was passiert, wenn dieser Dienst um 3 Uhr morgens ausfällt – und wer schaut hin?

Wenn die Antwort „ein Alarm, ein Runbook, ein Neustart” ist, braucht es keinen Orchestrator. Wenn die Antwort „zwölf Dienste müssen in der richtigen Reihenfolge wieder hochkommen, mit Rolling Updates und Zero Downtime” ist, dann schon.

Wann sich Kubernetes lohnt

Mehrere Teams deployen unabhängig voneinander in dieselbe Umgebung.
Lastspitzen sind unvorhersehbar und Skalierung muss automatisch passieren.
Compliance verlangt reproduzierbare, deklarative Infrastruktur mit Audit-Trail.
Es gibt Menschen, die den Cluster betreiben – nicht nur benutzen.

Wann nicht

Eine Anwendung, eine Datenbank, ein Team.
Der Traffic ist bekannt und passt auf eine gut dimensionierte Maschine.
Niemand im Team hat Zeit, sich um Upgrades, Netzwerk-Policies und Zertifikate zu kümmern.

In diesen Fällen ist eine VM mit systemd, einem Reverse Proxy und einem sauberen Deploy-Skript nicht rückständig. Sie ist die richtige Grösse. Wer die Entscheidung mit Zahlen unterlegen will: Wir haben durchgerechnet, was ein Cluster bei Schweizer Anbietern kostet, inklusive des Betriebsaufwands, der auf keiner Preisliste steht. Die Zahlen machen die Entscheidung nicht schwieriger, sondern leichter: Sie zwingen dazu, das Ziel zu benennen, bevor man das Werkzeug wählt.

Was wir stattdessen zuerst bauen

Egal ob Cluster oder VM – drei Dinge kommen immer zuerst:

Ein Deployment, das jeder auslösen kann. Ein Befehl, ein Ergebnis, kein Wissen im Kopf einer Person.
Observability, die man liest. Wenige Metriken, klare Alarme, Logs mit Kontext.
Ein Rollback, das schneller ist als die Analyse. Zurückrollen, dann verstehen.

Wer diese drei hat, kann jederzeit von der VM in den Cluster wachsen. Wer sie nicht hat, hat mit Kubernetes nur ein grösseres Problem.

Entscheidungen, die man in zwei Jahren noch versteht

Robert Pupel — Tue, 09 Jun 2026 00:00:00 GMT

Jedes System, das älter als ein Jahr ist, hat Stellen, an denen ein neues Teammitglied fragt: „Warum ist das so?” Und die ehrliche Antwort lautet zu oft: „Das weiss nur noch jemand, der nicht mehr da ist.” Die Abhilfe kostet fast nichts: Architektur-Entscheidungen dokumentieren, in dem Moment, in dem sie fallen, mit dem Kontext, der sie erzwungen hat. Nicht als Prosa für die Nachwelt, sondern als kurze, datierte Notiz mit drei Feldern: Was wurde entschieden, welche Alternativen standen zur Wahl, was gab den Ausschlag.

Ein ADR ist eine Seite, nicht ein Dokument

Ein Architecture Decision Record hält fest, was entschieden wurde, warum, und was man dafür in Kauf nimmt. Er hat vier Abschnitte und passt auf einen Bildschirm:

Kontext – Was war die Situation? Welche Zwänge gab es?
Entscheidung – Was tun wir?
Alternativen – Was haben wir verworfen, und warum?
Konsequenzen – Was wird dadurch einfacher, was schwieriger?

Er liegt im Repository, neben dem Code, den er erklärt. Nicht im Wiki, nicht in einem Ticket, nicht in einer Slack-Nachricht.

Warum das mehr bringt als jede Doku

Dokumentation beschreibt, wie ein System ist. Sie veraltet in dem Moment, in dem sich das System ändert. Ein ADR beschreibt, warum es so wurde. Das veraltet nie – selbst wenn die Entscheidung später revidiert wird, bleibt der Record wahr. Man ergänzt einen neuen, der auf den alten verweist.

Ein System ohne Entscheidungsgeschichte ist wie ein Vertrag ohne Datum. Man kann ihn lesen, aber nicht einordnen.

Wie wir es im Alltag halten

Jede Entscheidung, die schwer rückgängig zu machen ist, bekommt einen ADR. Datenbankwahl, Modulschnitt, Auth-Modell – ja. Farbe des Buttons – nein.
Der ADR entsteht vor der Umsetzung und wird im selben Pull Request reviewt.
Nummeriert, chronologisch, nie gelöscht. Überholt wird ein Record durch einen neuen, nicht durch Editieren.

Der Aufwand: zwanzig Minuten pro Entscheidung. Der Ertrag: ein Team, das auch nach dem dritten Wechsel noch weiss, warum das System aussieht, wie es aussieht.

Idempotenz: das unscheinbarste Feature einer Zahlungs-API

Ralph Segi — Tue, 19 May 2026 00:00:00 GMT

Eine Anfrage geht raus, die Antwort kommt nicht zurück. Timeout. Der Client versucht es noch einmal. Hat die Zahlung jetzt einmal stattgefunden – oder zweimal? Wenn eine API diese Frage nicht eindeutig beantworten kann, ist sie für Geld nicht geeignet. Das gilt für alle Zahlungs-APIs, unabhängig von Anbieter und Protokoll.

Das Prinzip

Ein Endpoint ist idempotent, wenn dieselbe Anfrage – beliebig oft wiederholt – denselben Effekt hat wie einmal. Für GET ist das selbstverständlich. Für POST /payments muss man es bauen.

Der Client schickt mit jeder schreibenden Anfrage einen selbst erzeugten Schlüssel:

POST /v1/payments
Idempotency-Key: 8f1c2a4e-3b7d-4c9e-a1f0-5d6e7f8a9b0c

Der Server merkt sich unter diesem Schlüssel das Ergebnis der ersten Verarbeitung. Jede Wiederholung mit demselben Schlüssel bekommt dieselbe Antwort – ohne die Zahlung erneut auszuführen.

Was oft übersehen wird

Der Schlüssel muss zur Anfrage passen. Derselbe Schlüssel mit einem anderen Body ist ein Fehler, keine Wiederholung. Wir prüfen einen Hash des Bodys und antworten mit 422, wenn er abweicht.

Nebenläufige Wiederholungen. Zwei identische Anfragen treffen im selben Moment ein. Der Schlüssel muss vor der Verarbeitung reserviert werden – ein INSERT ... ON CONFLICT DO NOTHING in derselben Transaktion – sonst arbeiten beide.

Ablauf. Schlüssel leben nicht ewig. 24 Stunden sind ein guter Standard; danach ist eine Wiederholung eine neue Anfrage.

Ein Ausschnitt in Go

func (s *Service) CreatePayment(ctx context.Context, key string, req PaymentRequest) (Payment, error) {
    return s.idem.Run(ctx, key, req.Hash(), func(ctx context.Context) (Payment, error) {
        return s.payments.Create(ctx, req)
    })
}

Die gesamte Logik – reservieren, ausführen, Ergebnis ablegen, bei Wiederholung zurückgeben – lebt in einem Paket, das jeder schreibende Endpoint benutzt. Kein Endpoint entscheidet selbst, ob er idempotent ist.

Warum das die Grundlage ist

Retries sind kein Fehlerfall, sie sind der Normalfall: mobile Netze, Load Balancer, Timeouts, Queues mit At-least-once-Zustellung. Eine API, die Wiederholungen nicht als Wiederholungen erkennt, verlagert das Problem in die Buchhaltung des Kunden. Dort ist es teurer.

Drei Dashboards statt dreissig

Ralph Segi — Tue, 28 Apr 2026 00:00:00 GMT

Fast jede Umgebung, die wir übernehmen, hat Grafana. Und fast jede hat Dashboards, die seit Monaten niemand geöffnet hat. Das Problem ist nicht zu wenig Beobachtung – es ist zu viel davon, ohne Frage dahinter. Observability, die man liest, beginnt deshalb nicht beim Werkzeug, sondern bei der Frage, welche drei Aussagen über das System jederzeit beantwortbar sein müssen: Läuft es, wird es langsamer, und wo klemmt es gerade. Alles, was diese drei Fragen nicht beantwortet, ist Dekoration, so hübsch das Panel auch aussieht.

Jedes Dashboard beantwortet genau eine Frage

Bevor ein Panel entsteht, muss klar sein, welche Entscheidung es unterstützt. „Ist der Dienst gesund?” ist eine Frage. „CPU-Auslastung aller Pods” ist keine – es ist eine Zahl.

Wir kommen fast immer mit drei Ansichten aus:

Geht es dem Nutzer gut? Fehlerrate, Latenz an der Kante, erfolgreiche Kernaktionen pro Minute.
Geht es dem System gut? Sättigung der knappen Ressourcen: Verbindungen, Queue-Länge, Speicher.
Was hat sich zuletzt geändert? Deployments, Konfigurationsänderungen, Feature-Flags – als Marker in der Zeitachse.

Alles Weitere ist Diagnose. Diagnose gehört in Ad-hoc-Abfragen, nicht auf ein Dashboard.

Alarme, die man ernst nehmen kann

Ein Alarm, der wöchentlich fehlfeuert, wird stummgeschaltet. Dann ist er kein Alarm mehr. Unsere Regel: Jeder Alarm hat einen Namen, eine Schwelle, die aus dem Nutzerversprechen abgeleitet ist, und ein Runbook. Fehlt eines davon, wird er gelöscht, nicht ergänzt.

Ein Alarm ist eine Bitte um menschliche Aufmerksamkeit. Man verschickt sie sparsam.

Logs mit Kontext, nicht mit Volumen

Strukturiert, mit Request-ID, mit dem Warum – nicht dem Was. payment declined: limit exceeded, limit=500 amount=620 sagt alles. error in handler sagt nichts, und es steht trotzdem in jedem zweiten Log, das wir sehen.

Was am Ende bleibt

Weniger Panels, weniger Alarme, weniger Logzeilen – und ein Team, das bei einem Vorfall in dreissig Sekunden weiss, wo es hinschauen muss. Das ist Observability. Der Rest ist Speicherplatz.