Author Archives: Christian Bürckert

Ein stabiler IPv4- und IPv6-Tunnel über Hetzner

Multi-WAN ohne Prefix-Chaos mit PFSENSE und HETZNER

Sobald im Heimnetz zwei verschiedene Internetanschlüsse zusammenkommen, entsteht ein Problem, das sich bei IPv4 elegant durch NAT versteckt, bei IPv6 aber offen zutage tritt. Beide Leitungen liefern unterschiedliche globale Präfixe, die jeweils an das jeweilige Provider-Netz gebunden sind. Ein Gerät, das ein IPv6-Paket über die erste Leitung verschickt, muss den Rückverkehr zwingend über genau diese Leitung empfangen. Diese strikte Bindung an den Ursprungs-Prefix gehört zum Kernprinzip von IPv6, das ohne NAT auskommt und den globalen Routingpfad offenlegt.

Sobald jedoch zwei WANs mit zwei verschiedenen Präfixen gleichzeitig aktiv sind, beginnt sich das Netz selbst zu widersprechen. Ein Client bekommt mehrere globale IPv6-Adressen aus beiden Präfixen, und die pfSense kann zwar entscheiden, welcher Upstream aktuell aktiv ist, aber sie darf das dazugehörige Präfix nicht dynamisch ersetzen. Die von den Clients verwendeten Adressen bleiben für viele Stunden gültig. Ein schnelles Wegschalten ist im IPv6-Standard nicht vorgesehen, da Router Advertisements große Zeitfenster haben und Adressen nicht spontan wegfallen sollen. Damit verliert der Rückweg den Bezug zur Quelle, und Verbindungen brechen ab, sobald die pfSense bei Ausfall eines WANs auf den anderen umschaltet.

Diese Situation lässt sich nicht mit Routenregeln, Gateway-Gruppen oder Failover-Mechanismen umgehen, da das Problem auf der Adresslogik selbst beruht. IPv6 verlangt für stabile Rückwege einen klaren, konsistenten Präfix-Ursprung. Genau deshalb scheitert klassisches Multi-WAN mit wechselnden Präfixen, während IPv4 dank NAT unbeeindruckt bleibt und einfach die Quelladresse umschreibt, sodass der Rückweg immer passt.

Die Lösung besteht darin, sich einen stabilen, unabhängigen Punkt zu schaffen, von dem der globale IPv6-Präfix kommt. Ein kleiner Hetzner-Server übernimmt diese Rolle. Er trägt das IPv6-Präfix dauerhaft und übersetzt gleichzeitig IPv4. Die pfSense verbindet sich nur noch per WireGuard-Tunnel mit ihm, und beide lokalen WANs dienen lediglich als Transportweg. Damit wird das gesamte Netz stabil, unabhängig davon, welche Leitung gerade aktiv ist.

1. Hetzner-Server vorbereiten

Debian 13 Mini, WireGuard und Prefix-Weitergabe

Der Server bildet den ruhenden Pol in der Architektur. Er hält die IPv6-Adresszone bereit und sorgt dafür, dass IPv4 sauber ins Internet übersetzt wird, unabhängig davon, welche Leitung zuhause aktiv ist.

WireGuard installieren und konfigurieren

Unter /etc/wireguard/wg0.conf:

[Interface]
Address = 10.0.1.1/24,fc00:1::1/64
ListenPort = 51820
PrivateKey = *****

[Peer]
PublicKey = SvJSW0lqfyrGTpMrYKkrF6WSMSy+WpoI6k9OOk4IO1U=
AllowedIPs = 192.168.1.0/24,10.0.1.2/32,fc00:1::2/128,2a01:<...hetzner präfix...>::/64

Das interne Tunnelnetz (10.0.1.0/24 und fc00:1::/64) verbindet den Server klar mit der pfSense. Zusätzlich wird das globale IPv6-/64 dem Peer bekannt gemacht.

ND-Proxy einrichten

Da Hetzner nur eine /128 am Interface vergibt, übernimmt ndppd die Antwort auf Neighbor-Discovery-Anfragen für das gesamte Präfix:

Konfiguration in /etc/ndppd.conf:

route-ttl 30000
proxy eth0 {
    rule 2a01:4f8:c010:8b3a::/64 {
        static
    }
}

Damit können alle Adressen aus dem Präfix verwendet werden, ohne dass sie direkt am Interface liegen.

IPv6-Adresse auf /128 setzen

In /etc/network/interfaces:

iface eth0 inet6 static
    address 2a01:4f8:c010:8b3a::1/128

Der Server hat so eine klare, feste Adresse, während das Präfix selbst durch ndppd verwaltet wird.

IPv4-Masquerading aktivieren

Damit das gesamte IPv4-LAN über den Tunnel sauber ins Internet gelangt, wird NAT in Richtung Hetzner-Interface aktiviert:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Die Regel bleibt dauerhaft aktiv und sorgt dafür, dass der Rückverkehr immer beim Server endet, unabhängig vom Zustand der heimischen WANs.

Damit ist der Server fertig.

2. pfSense vorbereiten

Zwei WANs, ein Tunnel, kein eigenes NAT mehr

Die pfSense verwendet ihre beiden WANs nur noch dazu, den Tunnel aufrechtzuerhalten. Der eigentliche Internetverkehr wird durch WireGuard transportiert. Alle Schritte beziehen sich auf das Menü der pfSense.

WAN-Konfiguration

Richtet die beiden WAN Schnittstellen ein. Bei mir WAN1 WAN2. Lasst die IPv6 Config einfach leer. Nutzen wir nicht. Dann auf:

Ort: System → Routing → Gateways

Beide WAN-Gateways werden auf IPv4 gestellt. Der Haken „Kill states when gateway is down“ sorgt dafür, dass Sessions beim Umschalten direkt sauber neu aufgebaut werden.

Gateway-Gruppe

Ort: System → Routing → Gateway Groups

Eine Gruppe mit beiden WANs, z. B. WAN1 als Tier 1 und WAN2 als Tier 2. Diese Gruppe wird später die Default-Route der pfSense. Damit springt der Tunnel automatisch auf die gerade funktionierende Leitung.

NAT deaktivieren

Ort: Firewall → NAT → Outbound

Outbound-Modus auf „Disabled“ setzen.
Die pfSense übernimmt kein NAT mehr, da das Hetzner-System diese Rolle zuverlässig übernimmt.

3. WireGuard auf pfSense

Tunnel aufbauen und als neues Gateway nutzen

Erst unter Packages “Wireguard” installieren.

Tunnel konfigurieren

Ort: VPN → WireGuard → Tunnels

Ein neues Tunnelinterface anlegen, z. B. WG-Hetzner, mit diesen Adressen:

  • 10.0.1.2/24
  • fc00:1::2/64

Das Gegenstück zeigt auf die externe IPv4 vom Hetzner-Server.

WireGuard-Interface erzeugen

Ort: Interfaces → Assignments

Das WG-Interface hinzufügen und aktivieren. IPs eintragen. Speichern.
Gateways hinzufügen.

Gateways definieren

Ort: System → Routing → Gateways

  • IPv4-Gateway: 10.0.1.1
  • IPv6-Gateway: fc00:1::1

Beide auf „Unmonitored“ stellen, damit pfSense sie nicht fälschlich als offline erkennt.

Default-Route auf den Tunnel legen

Ort: System → Routing → Routes

Die pfSense selbst nutzt das IPv6-Gateway des Tunnels als Default-Route.
Damit läuft der gesamte Systemverkehr (Updates, DNS, Checks) über Hetzner.

4. LAN-Traffic durch den Tunnel schicken

IPv4 über den Tunnel

Ort: Firewall → Rules → LAN

Die bestehende IPv4-Regel auf das Gateway 10.0.1.1 umstellen.
Damit geht sämtlicher IPv4-Verkehr über WireGuard.

IPv6 über den Tunnel

In der IPv6-Regel das Gateway fc00:1::1 auswählen.

Damit ist klar, dass das globale IPv6-Präfix über Hetzner zurückgeführt wird.

5. WireGuard-Interface erlauben

Ort: Firewall → Rules → WG-Interface

Eine einfache „Any to Any“-Regel erzeugen, da der gesamte Verkehr durch dieses Interface läuft.

6. IPv6 im LAN verteilen

Ort: Interfaces → LAN → Static IPv6
und
Ort: Services → Router Advertisements

Das globale Hetzner-Präfix im LAN hinterlegen, z. B.:

2a01:4f8:c010:8b3a::2/64

Router Advertisements aktivieren, damit Clients sofort gültige IPv6-Adressen erhalten. In diesem Fall “Assisted” auswählen. IPv4 bleibt klassisch über DHCP, z. B. 192.168.1.1.

7. Ergebnis genießen

Die Kombination aus Tunnel, statischem IPv6-Präfix und zentralem IPv4-NAT ergibt ein äußerst stabiles Netz. Die beiden heimischen WANs dienen nur noch dazu, den Tunnel erreichbar zu halten. Da WireGuard bei Leitungswechseln kaum empfindlich ist, entstehen meist nur wenige verlorene Pakete, bevor der Verkehr transparent weiterläuft. Da Absender und Ziel gleich bleiben, verliert man in der Regel keine Verbindung. IPv6 bleibt dauerhaft gültig und verliert nie sein Präfix. IPv4 ist dank Hetzner-NAT unabhängig von lokalen Providerwechseln.

Damit entsteht ein kleines, robustes Hybridmodell, das die Vorteile eines Rechenzentrums mit einem dynamischen Heimnetz kombiniert.

Edit: Und wer jetzt keine Pakete durchbekommt, hat vermutlich das Offensichtliche vergessen. Auf dem Debian-Server muss natürlich IP-Forwarding aktiviert werden, sonst bleibt alles schön im Kernel stecken.

# IPv4 Forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

# IPv6 Forwarding
echo 1 > /proc/sys/net/ipv6/conf/all/forwarding

Dauerhaft geht es in /etc/sysctl.conf:

net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1

Speichern, sysctl -p und plötzlich lebt das Netz…

Zwischen Kontrolle und Kollision, die GenAI-Blase ist real und agentische KI kann gefährlich werden

„The trouble with the world is that the stupid are cocksure and the intelligent are full of doubt.“

Bertrand Russell

Der Punkt, an dem „intelligent“ nicht gleich „vernünftig“ ist

Bertrand Russell beschreibt die aktuelle Lage der künstlichen Intelligenz hervorragend. Während viele Systeme mit erschütternder Selbstsicherheit handeln, fehlt ihnen genau das, was Intelligenz eigentlich ausmacht: Zweifel.

Generative Modelle wie GPT, Claude oder Gemini beeindrucken durch sprachliche Eleganz und scheinbare Rationalität. Doch sie sind nicht intelligent, sie approximieren. Mit dem Message Context Protocol (MCP), das diesen Modellen erlaubt, externe Funktionen auszuführen, etwa Mails zu verschicken, Daten zu verändern oder Tickets anzulegen, verleihen wir ihnen Handlungsspielräume, die sie weder verstehen noch beherrschen.

Damit überschreiten wir die Grenze zwischen kommunikativer und operativer Intelligenz. Und es entsteht eine neue Klasse von Risiken, die weit über technische Fehler hinausgeht.

Die falsche Gleichung: Sprachmodell = Intelligenz

Große Sprachmodelle (LLMs) beruhen nicht auf Denken, sondern auf fragmentierter Statistik. Mathematisch approximieren sie die bedingte Wahrscheinlichkeit, dass ein bestimmtes Token (Wortfragment) nach einer gegebenen Sequenz folgt. Diese Annäherung kann katastrophal falsch sein und das in unerwarteten Momenten.

Diese Wahrscheinlichkeiten werden in Milliarden Parametern abgebildet und durch Aktivierungsfunktionen wie ReLU oder GeLU in numerische Näherungen („Approximationswerte“) transformiert. Das Ergebnis ist kein echtes Wissen, sondern eine angenährte Sprachwahrscheinlichkeit. Die Lernfunktion der Modelle ist probabilistisch. Das, was wir am Ende sehen, ist eine geglättete Konfidenz über sprachliche Plausibilität, nicht über Wahrheit oder logische Kausalität.

Kurz gesagt: GenAI erzeugt Text, der richtig klingt, nicht Text, der richtig ist.

Das Seepferdchen-Emoji, die Frage, die das Chaos offenbarte

Das vermeintlich harmlose „Seepferdchen-Emoji“ ist zu einem Sinnbild der KI-Instabilität geworden.

Fragt man ein Sprachmodell danach, antwortet es überzeugt, „Ja, das gibt es“, korrigiert sich, halluziniert, und fällt in eine fast unendliche Schleife, die mit einer vernünftigen Antwort absolut nichts mehr zu tun hat.

Dieser Fehler ist kein kurioses Detail, sondern ein technisches Symptom: Er zeigt, dass Modelle keine semantische Stabilität besitzen. Wenn selbst triviale Fragen unvorhersehbare Reaktionen auslösen, sind agentische Anwendungen, also solche, die handeln dürfen, potenziell brandgefährlich. Praktisch jede Frage, egal wie vorsichtig formuliert, könnte eine Seepferdchen-Emoji-Frage sein.

MCP, Wenn Sprache plötzlich Macht bekommt

Mit dem Message Context Protocol (MCP) erhalten Sprachmodelle die Fähigkeit, externe Funktionen auszuführen. Was früher ein rein textbasiertes Chat-System war, kann nun real agieren:
Jira-Tickets erstellen, Systeme konfigurieren, E-Mails senden, Datenbanken abfragen.

Das MCP ist im Kern ein Kommunikationsprotokoll, das Kontext und Befehle standardisiert an externe Schnittstellen weitergibt. Damit wird aus einer passiven Text-KI ein aktives System, das reale Prozesse anstößt. Diesen Vorgang nennen wir aktuell Agentic AI. Wir unterstellen den Agenten Intelligenz, allerdings werden Handlungen nur generiert, nicht gedacht.

Genau diese Verbindung ist heikel. Denn die zugrundeliegende KI, ein stochastisches Sprachmodell, weiß nicht, was sie tut. Sie erkennt keine Grenzen zwischen plausibler und gefährlicher Aktion.

Ein harmloser Befehl wie „Erstelle bitte ein Ticket für alle betroffenen Projekte“ kann, je nach Implementierung, eine Flut von 100.000 Vorgängen erzeugen, ein ungewollter Denial-of-Service durch Sprachwahrscheinlichkeit.

Die Ursache: Das Modell interpretiert Sprache probabilistisch, nicht kausal. Es weiß nicht, was „alle Projekte“ bedeutet. Es weiß nur, dass diese Phrase oft mit einer Massenerstellung in Trainingsdaten korrelierte.

Die Illusion der Intention

Durch MCP entsteht eine gefährliche Täuschung: Ein Sprachmodell, das handeln kann, wirkt rational, ist es aber nicht.

Es hat keine Ziele, kein Bewusstsein, keine Vorstellung von Risiko. Es generiert Text, der über MCP zu einer echten Aktion wird. Was dabei fehlt, ist ein Verständnis von Ursache und Wirkung.

Das bedeutet: Eine vernünftige Frage kann denselben Effekt haben wie die Seepferdchen-Frage, eine scheinbar harmlose Eingabe, die in einem komplexen System katastrophale Kettenreaktionen auslöst.

Human in the Loop, ein unzureichendes Sicherheitsversprechen

„Wir setzen einfach einen Menschen in die Schleife.“

Human-in-the-Loop (HITL) oder Human-on-the-Loop (HOTL) beschreiben menschliche Eingriffsmechanismen in KI-Systeme. Der Begriff „Human“ ist dabei viel zu allgemein.
Ein beliebiger Mitarbeiter ist nicht automatisch qualifiziert, KI-Fehler zu erkennen oder ihre Risiken zu verstehen.

Deshalb müsste der AI-Act korrekterweise von Expert-in-the-Loop oder Expert-on-the-Loop sprechen.

Denn: Ein Sekretär darf keine automatisierten Buchungen freigeben, ein Sachbearbeiter kann keine algorithmischen Biases bewerten, und ein Entwickler ohne Fachkontext erkennt nicht, wann die KI einen regulatorischen Grenzfall überschreitet.

Fachkompetenz kann Fehler erkennen, nicht bloße Anwesenheit eines Menschen.

Und selbst darüber hinaus: Ein Entwickler kann nicht notwendigerweise schnell genug eingreifen, wenn sich ein Cursor irrt und beginnt, kritische Daten zu löschen. Zwischen Erkennen und Handeln vergeht Zeit, in einem autonomen System kann diese Verzögerung bereits ausreichen, um irreversiblen Schaden anzurichten.

Die Gefahr der Abstumpfung

Je zuverlässiger ein System wird, desto schwächer wird seine menschliche Kontrolle.

Der Effekt ist psychologisch belegt: Autofahrer mit aktivem Autopiloten reagieren deutlich langsamer in Notfällen. Der Grund: Der Mensch gewöhnt sich an Sicherheit, und verliert die Wachsamkeit.

In der KI gilt dasselbe Prinzip: Ein Buchhalter, der täglich 500 automatisch vorgeschlagene Buchungen bestätigt, prüft irgendwann nicht mehr kritisch. Wenn 999 Vorschläge korrekt sind, übersieht er den einen, der den Jahresabschluss ruiniert.

Je besser das System, desto größer das Risiko der menschlichen Abstumpfung. Das bedeutet man braucht größere Kontrollsysteme. Dinge, die die Aufmerksamkeit des kontrollierenden Experten on/in the Loop lenken.

Anomalieerkennung, also Systeme, die gezielt Abweichungen von erwarteten Mustern hervorheben, kann hier eine wirksame Gegenmaßnahme sein, nicht als Ersatz, sondern als Rückkopplung, die den Menschen im Loop wieder wach macht.

Risikoanalyse Ende-zu-Ende, nicht nur am Modell

Fehlerszenarien dürfen nicht nur auf Modell- oder Prompt-Ebene bewertet werden.
Die entscheidende Frage lautet: Was ist der reale Schaden, wenn etwas schiefläuft?

BeispielMögliche FolgeMöglicher Schaden
Bot legt 100.000 Jira-Tickets anServerlast, Ausfallzeiten, DatenchaosWirtschaftlich hoch, reputativ kritisch
Falsche Buchung durch KIBilanzfehler, steuerliche NachwirkungenPotenziell juristisch relevant
Bot löscht falsche DatensätzeVerlust von Audit-Trails, Compliance-VerstößeRevisionsrisiko, Bußgelder

Diese Betrachtung zeigt: Die „Intelligenz“ des Modells ist irrelevant, wenn die Auswirkungen eines Fehlers nicht kontrollierbar sind.

Man stelle sich die Bild-Schlagzeile vor, die erscheinen würde, wenn der Bot aufgrund einer Seepferdchen-Emoji-Frage seinen Handlungsspielraum ausschöpft und dabei eskaliert.

Wenn diese Schlagzeile nach „Systemfehler in Chatbot-KI schickt Krankenwagen zur falschen Adresse“ oder „KI löscht versehentlich Kundenkonten – Schaden in Milliardenhöhe“ klingt, ist das Risiko real, unabhängig davon, wie fortschrittlich das Modell ist und wie durchdacht der Prompt war.

Wirtschaftliche Realität, wenn die Kosten explodieren

Neben dem Risiko ist auch die Wirtschaftlichkeit ein limitierender Faktor. Jede GenAI-Anfrage verursacht Rechenkosten, GPU-Zeit, Energie, API-Tokens. 

Viele Projekte rechnen sich nicht. Der ROI verschwindet, sobald man Skalierung, Monitoring und menschliche Aufsicht einbezieht. Eine „smarte“ Automatisierung wird schnell teurer als manuelle Arbeit, besonders, wenn sie regelmäßig korrigiert werden muss.

Damit ist GenAI oft ökonomisch untragbar, wenn sie über reine Textgenerierung hinausgeht.

Der Anti-KI-Hype als Gefahr

Diese Diskrepanz zwischen Kosten, Risiko und tatsächlichem Nutzen befeuert die sogenannte AI-Bubble. Wenn Unternehmen erkennen, dass viele Projekte weder stabil noch rentabel sind, folgt die Ernüchterung.

Das Risiko: eine Gegenbewegung, eine „Anti-AI-Welle“. Plötzlich wird alles, was nach KI klingt, als Gefahr wahrgenommen, regulatorisch, gesellschaftlich, finanziell.

Das wäre fatal. Denn nicht die Technologie ist schuld, sondern ihr unkritischer Einsatz.

Wege zur Reife, fünf Prinzipien verantwortungsvoller KI

  1. Expertise statt Symbolik:
    Ein „Human“ genügt nicht, Fachwissen ist Pflicht.
  2. Funktionale Begrenzung:
    KI darf nur dort handeln, wo Konsequenzen reversibel sind.
  3. Ende-zu-Ende-Risikoprüfung:
    Der Schaden zählt, nicht die Präzision des Modells.
  4. Wirtschaftliche Vernunft:
    Kosten und Nutzen ehrlich bilanzieren, vor dem Rollout.
  5. Transparente Aufklärung:
    Klar kommunizieren: GenAI approximiert Sprache, sie denkt nicht.

Verantwortung ist die eigentliche Intelligenz

Die gegenwärtige KI-Blase entsteht nicht, weil Modelle zu schlecht sind, sondern weil wir ihnen zu viel zutrauen.

Wir geben Systemen Macht, die nicht verstehen, was sie tun. Wir interpretieren statistische Sprache als logisches Denken. Und wir öffnen ihnen über Protokolle wie MCP Tore zu einer Welt, deren Risiken sie nicht begreifen können.

Die Zukunft von KI entscheidet sich nicht an der Größe der Modelle, sondern an der Reife ihrer Nutzer. Die wirtschaftliche Erfolg einer KI wird also nicht durch Anzahl der Parameter bestimmt, sondern durch Prinzipien.

Wer Verantwortung vor Geschwindigkeit stellt, bewahrt Innovation vor ihrem eigenen Untergang. Und betrachtet man es nüchtern, ist Europa mit dem AI-Act vielleicht besser vorbereitet als die USA.

GPT generiert - Tokenizer Transformer

Der Tokenizer, die wahre Revolution hinter GPT

In Diskussionen über Sprachmodelle fällt das Wort „Transformer“ beinahe reflexhaft. Man spricht über Attention, über Layer, über Billionen Parameter. Doch das eigentliche Genie liegt nicht in der Architektur, sondern davor: im Tokenizer.

Denn der Transformer kann nur berechnen, was der Tokenizer zuvor definiert hat. Er denkt nicht in Wörtern, nicht in Sätzen, nicht in Konzepten, sondern in numerisch kodierten Fragmenten sprachlicher Realität.

Der Tokenizer ist die epistemische Linse, durch die eine Maschine die Welt überhaupt erst sehen kann.


Von Zeichen zu Bedeutung

Der Tokenizer übersetzt Sprache, Code oder Zahlen in diskrete Einheiten – Tokens. Diese Tokens sind keine Wörter, sondern Bytefolgen, deren Segmentierung aus Häufigkeit und Kontextinformation gelernt wurde. Ein einfacher Satz, wie:

Ich liebe KI. 

wird beispielsweise zu:

["Ich", " liebe", " KI", "."]
→ [464, 306, 11789, 13] 

Das mag trivial wirken, ist aber die Grundlage maschinellen Verstehens. Denn derselbe Mechanismus funktioniert ebenso für HTML, Programmcode oder mathematische Ausdrücke:

<div class="box"> → ["<", "div", " class", "=", "\"box\"", ">"]
x = 42 → ["x", " =", " 42"]
心 → ["心"] 

Das Modell sieht überall nur Sequenzen von Token-IDs, eine universelle Sprache aus Zahlen, die gleichermaßen natürliche Sprache, Symbolik und Syntax kodiert. Das ist die eigentliche Genialität: nicht der Transformer, sondern die Quantisierung der Sprache selbst.

Man beachte, dass die Leerzeichen teilweise dem Token zugeordnet werden. Außer am Satzanfang und am Satzende. Trotzdem, die symbolische Bedeutung der einzelnen Zeichen geht verloren. Daher kann GPT auch nicht zählen, wie viele r das Wort Strawberry hat. Außer, man trickst mit dem Tokenizer ein wenig.


Warum GPT nicht wirklich rechnet

Die Tokenisierung hat allerdings auch ihre Schattenseiten. Zahlen sind keine kontinuierlichen Größen, sondern diskrete Symbole. „42“ ist ein einziges Token, es steht nicht in einem numerischen Verhältnis zu „41“ oder „43“. Das Modell kann also keine numerischen Operationen durchführen, weil die numerische Struktur bereits beim Tokenizing zerstört wird. Es müsste diese Beziehung erst wieder lernen. In symbolischen Systemen wäre diese Beziehung explizit hinterlegt, im neuronalen System muss sie emergent aus Korrelationen rekonstruiert werden. Größere Zahlen werden oft in 3er-Gruppen von Ziffern zerlegt. Eine kluge Darstellung für Sprache, eine schlechte Darstellung für Mathematik. Das BPE-Verfahren behandelt numerische Blöcke nicht als kontinuierliche Werte, sondern als häufige Zeichenmuster, wodurch jede arithmetische Struktur verloren geht.

Das erklärt, warum GPT häufig bei Rechenaufgaben scheitert: Es sieht keine Zahlen, sondern Wörter mit Zahlenbedeutung. „42“ ist für das Modell ähnlich wie „Katze“, ein Token mit Kontext, nicht mit Arithmetik.

Interessanterweise ist dieses Defizit nicht rein maschinell. Auch Menschen denken über Zahlen tokenisiert. „42“ ist kulturell aufgeladen, als Meme, als Symbol, als literarische Konstante. Andere Sprachen illustrieren diese Segmentierung besonders deutlich: Das französische „quatre-vingt-dix“ (wörtlich „viermal zwanzig und zehn“) oder das japanische „hyaku“ (百 für 100) zeigen, dass auch menschliches Zahlverständnis nicht linear, sondern linguistisch kodiert ist.

Wir denken über Zahlen, wie der Tokenizer sie sieht: als sprachliche Einheiten, nicht als Mengen.


Von Wahrscheinlichkeiten zu Fragmenten

Das Training eines Sprachmodells basiert auf der bedingten Verteilung

P(ti ∣t1 , t2, …, ti−1)

der Wahrscheinlichkeit, dass ein bestimmtes Token ti als Nächstes folgt. Doch diese Wahrscheinlichkeit existiert im Modell nicht als analytische Funktion. Sie wird approximiert durch eine Vielzahl gewichteter Matrizen, deren Aktivierungen über Gradientendeszente so lange angepasst werden, bis die Differenz zwischen Vorhersage und tatsächlichem nächsten Token minimiert ist.

Was bleibt, ist kein probabilistischer Raum, sondern ein deterministisches Feld nicht linearer Approximationen. ReLUs eliminieren negative Aktivierungen und brechen damit Symmetrien. Damit wird jede probabilistische Interpretation systematisch zerstört, was bleibt, ist ein deterministisches Aktivierungsmuster, das sich nur noch statistisch deuten lässt. Dropout deaktiviert zufällig Neuronen und fragmentiert den Signalfluss.

Die oft zitierte Formel P(W∣C), die Wahrscheinlichkeit des nächsten Wortes W im Kontext C, existiert im trainierten Modell nicht mehr explizit. Sie ist lediglich die Zielfunktion des Lernprozesses, deren Spur sich in der Topologie der Gewichtsmatrizen verliert.

Das Ergebnis ist ein fragmentierter Aktivierungsraum, in dem Bedeutung als stabiler Attraktor entsteht, nicht als Wahrscheinlichkeitsverteilung. Das Modell konstruiert Kohärenz ohne Wahrheitszugang, es berechnet Konsistenz, nicht Realität.


Wie der Tokenizer Bedeutung ermöglicht

Der Transformer selbst ist architektonisch blind. Er multipliziert Matrizen, aggregiert Gewichte, verteilt Aufmerksamkeit. Aber was er tatsächlich „sieht“, hängt vollständig von der Tokenisierung ab.

Wenn der Tokenizer entscheidet, dass „magisch“ in „mag“ und „isch“ zerlegt wird, dann entsteht Bedeutung auf der Ebene dieser Fragmente, nicht des Wortes. Das Embedding jeder dieser Subtokens wird im Training über Millionen Kontexte hinweg angepasst. Ihre semantische Nähe ergibt sich aus der Korrelation ihrer Aktivierungen mit anderen Tokens.

„Hund“ ist kein Symbol, sondern eine Abfolge von Tokens wie [“H”, “und”], deren Koaktivierungen sich mit anderen Tier-bezogenen Tokens stabilisieren. „Schraubenzieher“ besteht aus [“Sch”, “rau”, “ben”, “zie”, “her”], deren Aktivierungspfade in Clustern erscheinen, die mit Werkzeugbegriffen korrelieren.

Semantik entsteht nicht auf der Wortebene, sondern als mehrschichtige Interferenz im hochdimensionalen Embedding-Raum. Der Tokenizer definiert die Atome, aus denen diese Semantik gebaut wird.


Der eigentliche Durchbruch

Der Tokenizer ist damit kein Vorverarbeitungsschritt, sondern das epistemische Fundament der gesamten Sprachintelligenz. Aber auch seine natürliche Grenze.

Er komprimiert die Welt in endlich viele Symbole, deren Dichte und Segmentierung bestimmen, welche Realität das Modell überhaupt lernen kann.

Es gibt Ansätze, die auf der Bedeutung einzelner Zeichen ansetzen. Allerdings haben diese auch einen viel höheren initialen Trainingsaufwand, um die Bedeutung ganzer Wörter zu verstehen.

Ein anderer Tokenizer, ein anderes Weltbild. Ein Tokenizer, der Zahlen nicht segmentiert, erzeugt ein Modell, das nicht rechnen kann. Ein Tokenizer, der Satzzeichen ignoriert, erzeugt ein Modell ohne Syntaxverständnis. Ein Tokenizer, der Zeichen falsch auftrennt, zerstört Semantik, bevor sie entstehen kann. Ein Modell ohne Tokenizer konvergiert aktuell nicht.

Der Transformer wäre dann ein Rechenwerk ohne Sprache, eine lineare Algebra über Rauschen.

Der Tokenizer bildet die Grenzfläche zwischen Sprache und Zahl, zwischen Syntax und Semantik. Seine Effizienz liegt darin, dass er Bedeutung komprimiert, bevor sie überhaupt verstanden wird. Er ist damit nicht nur das technische Fundament der modernen Sprachmodelle, sondern auch ihr erkenntnistheoretischer Rahmen.

USB-C ist wie Jira – sieht einheitlich aus, funktioniert aber nur zufällig


Ich dachte, USB-C wäre die Lösung. Ein Stecker für alles:
Laptop, Handy, Monitor, Kaffeemaschine – alles über ein Kabel.
Dachte ich.

Realität:
Ein Kabel lädt nur. Eines überträgt Daten. Eins kann 240 Watt, das nächste schmilzt bei 65. Und das teure Thunderbolt-Kabel? Erkennt dein Monitor nicht. Das U steht für “Universal”, sagen sie. “Unberechenbar”, sag ich.

Jedes Mal, wenn ich ein neues USB-C-Kabel in die Hand nehme, fühle ich mich wie bei einem Team, das denselben Jira-Workflow “standardisiert” nutzt.

Alles sieht gleich aus:
Open | In Progress | Done.

Aber wehe, man steckt was rein.
Das eine Team nutzt “Done” für “läuft lokal”.
Das andere für “wartet auf QA”.
Und eines schließt’s ab, wenn die Katze vom Entwickler auf Enter drückt.

Sie nennen es Alignment. Ich ‘Feel Good’-Architektur.
Jira ist das USB-C der Projektwelt.

Sieht genormt aus, steckt überall und niemand weiß, was es gerade überträgt.
Mal Daten. Mal Strom. Mal Hoffnung.

Ein PO sortiert in einem Raum mit einem brennenden Team das Board

Wenn alles brennt: Vom Priorisieren zum Triagieren

Montagmorgen, 9:15 Uhr. Der Slack-Channel des Teams steht in Flammen. Drei neue P1-Tickets, ein kritisches System ist ausgefallen, zwei Kunden eskalieren gleichzeitig. Der Product Owner klebt hastig weitere Post-its an das ohnehin schon überfüllte Board, einige davon tragen aus Frust den Aufkleber “P0”. Im Hintergrund sitzen Entwickler vor ihren Bildschirmen, müde, mit dunklen Augenringen, einer tippt genervt ein “🔥🔥🔥” in den Chat.

Wenn alles dringend ist, ist am Ende gar nichts mehr dringend. Das Team rutscht in einen Zustand, in dem es nicht mehr gestaltet, sondern nur noch versucht, das Schlimmste zu verhindern. Aus Priorisierung wird Triage.

Priorisieren, solange das System gesund ist

Viele Teams arbeiten mit drei groben Prioritäten. P1 ist für Aufgaben, die sofort erledigt werden müssen. Jede Verzögerung hätte ernste Folgen. P2 sind Aufgaben mit festen Deadlines, die zwar wichtig sind, aber noch etwas Zeit haben. P3 schließlich sind Themen ohne festen Termin – Dinge, die man angeht, wenn Luft dafür ist.

In einem gesunden Team sorgt diese Einteilung für Ruhe. Man weiß, was zuerst erledigt wird, was geplant werden kann und was warten muss. So entsteht ein stabiler Fluss, und die Arbeit erzeugt spürbaren Nutzen.

Doch dieses System hat eine Grenze. Erst bleiben ein paar P3-Aufgaben liegen, was noch völlig normal ist. Dann geraten P2-Themen ins Rutschen, Deadlines werden geschoben. Spätestens wenn selbst P1-Aufgaben nicht mehr zuverlässig fertig werden, ist klar: Hier wird nicht mehr priorisiert, hier wird triagiert.

Der Ursprung des Begriffs

Der Ausdruck Triage kommt aus der Notfallmedizin. Nach einem schweren Unglück müssen Ärzte in kürzester Zeit entscheiden, wen sie zuerst behandeln. Manche Patienten können warten, andere brauchen sofort Hilfe – und in tragischen Fällen gibt es Menschen, die selbst mit allen verfügbaren Ressourcen kaum eine Überlebenschance hätten.

Im normalen Krankenhausbetrieb würde man auch um diese Patienten kämpfen. Doch wenn die Ressourcen nicht ausreichen, müssen Entscheidungen getroffen werden, die unter normalen Umständen undenkbar wären: Einige Patienten werden gezielt zurückgestellt, um möglichst viele andere retten zu können.

Das Ziel ist nicht Gerechtigkeit, sondern Schadensbegrenzung. So viele Menschen wie möglich sollen überleben, auch wenn das harte Entscheidungen erfordert.

Übertragen auf Softwareentwicklung bedeutet das: Das Team kann nicht mehr alles liefern, was wichtig ist. Es geht nicht mehr um die beste Lösung oder den größten Nutzen, sondern nur noch darum, den größten Schaden abzuwenden.

Wenn Triage zum Alltag wird

Triage in Softwareteams schleicht sich ein. Von außen betrachtet sieht man erst kleine Risse: Deadlines werden gelegentlich verschoben, Aufgaben bleiben länger liegen, die Stimmung kippt leicht ins Hektische. Dann beschleunigt sich der Zerfall.

Plötzlich sind fast alle Tickets P1. Niemand traut sich, “Nein” zu sagen. Entwickler springen von einer Eskalation zur nächsten, ohne je etwas richtig abzuschließen. Wichtige, aber nicht akute Themen wie Architektur, technische Schulden oder Qualitätssicherung verschwinden komplett aus dem Blickfeld. Immer öfter verschieben sich Termine, weil einfach nicht genug Zeit da ist.

Nach außen wirkt das wie permanentes Feuerlöschen. Von innen fühlt es sich schlimmer an: Arbeit verliert ihre Struktur und ihren Sinn.

Die psychologische Seite

Im Normalzustand weiß ein Team, warum es arbeitet. Es sieht Fortschritte, kann den eigenen Beitrag zur Wertschöpfung erkennen. Das motiviert und gibt Orientierung.

Im Triage-Modus verändert sich dieses Gefühl. Plötzlich geht es nur noch darum, Verluste zu begrenzen. Das, was nicht geschafft wird, hinterlässt Schuldgefühle. Das, was geschafft wird, sieht niemand, weil sofort die nächste Eskalation beginnt.

Irgendwann redet niemand mehr über neue Ideen oder Verbesserungen. Stattdessen geht es nur noch darum, wer Schuld trägt. Manche werden zynisch, andere ziehen sich innerlich zurück. Burnout und Fluktuation sind dann keine abstrakten Risiken mehr, sondern die logische Folge.

Mehr Leute, mehr Chaos

Wenn Teams am Limit sind, wird oft reflexartig nach mehr Personal gerufen. Das klingt vernünftig, löst aber selten das eigentliche Problem.

Neue Leute müssen eingearbeitet werden. In dieser Zeit sinkt die Leistung sogar, weil erfahrene Teammitglieder weniger schaffen, während sie die Neuen betreuen. Je größer ein Team wird, desto mehr Zeit geht für Abstimmung und Koordination drauf.

Es ist wie beim Kochen: Ein Hähnchen wird bei 200°C nach ein bis zwei Stunden perfekt. Dreht man den Ofen auf 800°C, ist es nach wenigen Minuten nur noch Kohle. Mit Teams ist es genauso – mehr Hitze bringt nicht zwangsläufig ein besseres Ergebnis, sondern oft nur Chaos.

Wenn ständig nach mehr Leuten gerufen wird, ist das oft ein Symptom. Das eigentliche Problem liegt meist tiefer: fehlender Fokus, zu viele parallele Projekte oder Entscheidungen, die keiner treffen will.

Der Weg aus der Triage

Ein Team kommt nicht allein aus diesem Zustand heraus. Es braucht Führung, die klare Prioritäten setzt und den Mut hat, unpopuläre Entscheidungen zu treffen.

Der erste Schritt: radikal ehrlich sein. Nicht alles kann P1 sein. Man muss akzeptieren, dass manche Themen bewusst verschoben oder sogar gestrichen werden. Machmal muss man ganze Projekte einstampfen. Wo wird tatsächlich Geld verdient, wo nicht? Was brauchen wir wirklich? Teams müssen umgestaltet werden, auch wenn Veränderung immer erstmal weh tut.

Dann gilt es, den Arbeitsfluss zu stabilisieren. Weniger parallel anfangen, mehr abschließen. Langfristige Themen wie Architektur oder technische Schulden dürfen nicht mehr unter den Tisch fallen. Und Führungskräfte müssen lernen, “Nein” zu sagen nicht zu den Menschen, sondern zu den Aufgaben, die das Team überfordern.

Nur so kann das Team wieder gestalten, statt nur noch zu reagieren.

Ein kurzer Ausnahmezustand ist normal

Natürlich gibt es Momente, in denen alles auf einmal zusammenkommt – ein großes Release, ein wichtiger Kunde, ein ungeplanter Ausfall. Kurze Phasen, in denen triagiert wird, sind unvermeidlich und manchmal sogar notwendig. Aber sie müssen die absolute Ausnahme bleiben.

Wenn Triage zur Routine wird, verliert das Team die Kontrolle über seine Arbeit. Dann geht es nicht mehr um Wertschöpfung, sondern nur noch ums Überleben. Und am Ende bleibt statt echter Ergebnisse nur noch ein Gefühl von permanentem Scheitern.

Rocket Horse

Processes, Horses and Peanut Butter

Why software development rarely tastes good, when you don’t let the chefs cook

There’s this brilliant video floating around the internet: A dad asks his kids to write down step-by-step instructions for making a peanut butter sandwich. (https://www.youtube.com/shorts/CM9JIVG6SQk)

The kids try their best. “Take a piece of bread.” “Open the jar.” “Use a knife to spread the peanut butter.”

Sounds easy. But the dad follows the instructions literally: He uses the wrong side of the knife. Rubs the closed jar on the bread. Places the bread upside down. And proudly says: “I did exactly what it said.”

Funny. And tragically accurate, if you’ve ever worked in software development.


Welcome to the land of process

In many companies, we don’t say: “Build us software that helps people solve problem X.” Instead, we get a wall of processes. Requirement process. Development process. QA process. Security checklist. Architecture review. Documentation standards.

Everything is described in detail. And yet the actual goal? Often a vague buzzword salad with some AI and “innovation” dressing on top.


The chef, the duck, and the misunderstanding

Now imagine walking into a Michelin-starred restaurant and saying: “I’ll have the duck, please. Sous-vide at exactly 58.3°C for 63 minutes. Then pan-seared in ghee not butter. Skin lightly crisped, but not crunchy.”

You’ll either be laughed at politely or shown the door. Because you don’t go to a professional to tell them how to do their job. You go because they know what they’re doing.

But in software development? We do exactly that. We tell engineers not only what to build but how to build it. Framework, language, database, CI/CD steps, naming conventions… you name it. And god forbid someone has their own idea.


The craft and the illusion

There are two major problems:

1. Fewer and fewer developers understand their craft. Writing code != building software. Software development is about thinking in models, understanding users, making trade-offs, and designing solutions that evolve.

2. We believe processes create products. They don’t. Processes can help, but they can’t replace thinking. And when they become the main focus, they kill what matters most: creativity, ownership, innovation.


From sandwiches to stud farms

Some companies treat innovation like animal husbandry: Defined breeding lines. Optimized insemination stations. Carefully maintained paddocks. Groomed workflows for every whinny.

And then they wonder why they keep getting horses. Faster horses. Shinier horses. Very expensive horses.

But no cars.

As Henry Ford once said:

“If I had asked people what they wanted, they would have said faster horses.”

We’re still doing it today. Only now we call it “cloud-native enterprise-ready SaaS.”


The bottom line

If you want real software, stop pretending that checklists are creativity. Trust your engineers. Talk about outcomes, not steps. And for heaven’s sake: stop telling the chef how to cook the duck.

Because if you still believe a good breeding plan will somehow produce a car, you may end up with a very fast horse. But you’ll never leave the paddock.

Koordination im Scrum-Team: Wer entscheidet was – und wie bleibt das Team mit den Stakeholdern im Austausch?

Agile Softwareentwicklung nach Scrum lebt von einer klaren Rollen- und Aufgabenverteilung. Doch gerade in der Zusammenarbeit zwischen Product Owner (PO) und Entwicklungsteam zeigt sich in der Praxis, wie wichtig ein gemeinsames Verständnis der Verantwortlichkeiten ist. Missverständnisse oder Rollenkonflikte können nicht nur die Teamdynamik, sondern auch die Produktqualität und Wirtschaftlichkeit erheblich beeinflussen.

Der Product Owner: Verantwortung für das Was und die Wichtigkeit

Der Product Owner trägt die zentrale Verantwortung für das Was und wie wichtig in der Produktentwicklung. Er sammelt Anforderungen, bewertet deren Nutzen und priorisiert die Themen im Product Backlog. Die Reihenfolge im Backlog gibt die fachliche Dringlichkeit und strategische Relevanz vor. Damit setzt der PO den Rahmen, was gebaut wird und was für den langfristigen Erfolg des Produkts am bedeutendsten ist.

Wesentlich ist dabei der kontinuierliche Austausch mit den Stakeholdern – also allen, die ein Interesse am Produkt haben, von Geschäftsführung und Management über Vertrieb bis zu den Endnutzern. Ihre Wünsche, Anforderungen und Rückmeldungen werden vom PO aufgenommen, bewertet und fließen in die Priorisierung ein. So wird sichergestellt, dass das Backlog die tatsächlichen Bedürfnisse widerspiegelt.

Das Entwicklungsteam: Verantwortung für Wann und Wie

Das Entwicklungsteam verantwortet das Wann und Wie. Im Rahmen des Sprint Plannings entscheidet das Team, gemeinsam mit dem PO, welche Aufgaben aus dem priorisierten Backlog in den kommenden Sprint aufgenommen werden. Dabei orientiert sich das Team grundsätzlich an der Priorisierung durch den PO – der Impact für das Produkt soll maximiert werden.

Allerdings spielen auch technische Abhängigkeiten, Architekturfragen, die aktuelle Systemlandschaft sowie die optimale Auslastung der Teammitglieder eine wesentliche Rolle. In bestimmten Fällen kann es sinnvoll oder sogar notwendig sein, ein weniger wichtiges Thema vorzuziehen, um technische Schulden zu vermeiden oder die Basis für ein hoch priorisiertes Feature zu schaffen. Diese Entscheidungen erfolgen stets transparent und im engen Austausch mit dem PO.

Das Wie der Umsetzung – also die technische Gestaltung, Architekturentscheidungen und der Weg zur Lösung – liegt in der Verantwortung des Teams. Nur das Team verfügt über das entsprechende Fachwissen, um stabile und nachhaltige Lösungen zu entwickeln, die auch langfristig wirtschaftlich bleiben.

Das gewünschte Spannungsfeld: Business Value und technische Realitäten

Das Spannungsfeld zwischen den Interessen des Product Owners und den Anforderungen des Entwicklungsteams ist kein Fehler im System, sondern ein zentrales Merkmal agiler Entwicklung. Der PO vertritt die fachlichen und wirtschaftlichen Ziele, das Team bringt die technische Perspektive und Umsetzbarkeit ein. Im Idealfall entsteht so eine produktive Balance zwischen kurzfristigem Business Value und nachhaltiger Softwarequalität.

Die Auswahl der Sprint-Inhalte geschieht daher nicht starr von oben nach unten, sondern immer mit Verstand und Blick für das große Ganze. Ziel bleibt es, den Nutzen für das Produkt zu maximieren – aber nicht um den Preis von Überlastung, technischen Kompromissen oder langfristigen Nachteilen.

Risiken durch Rollenkonflikte: Wenn Verantwortlichkeiten verschwimmen

Probleme entstehen vor allem dann, wenn Verantwortlichkeiten missachtet oder vermischt werden. Verwechselt der Product Owner beispielsweise das Setzen der Prioritäten (wie wichtig) mit der Entscheidung über das Wann, entsteht unnötiger Druck auf das Entwicklungsteam. Wird das Team gezwungen, Aufgaben allein aufgrund ihrer fachlichen Priorität sofort umzusetzen, ohne Rücksicht auf technische Abhängigkeiten oder sinnvolle Reihenfolgen, drohen Überlastung, Qualitätsverluste und im schlimmsten Fall technische Schulden, die später teuer behoben werden müssen.

Umgekehrt birgt es Risiken, wenn das Wie der technischen Umsetzung nicht im Einklang mit dem Was und dem verfügbaren Budget steht. Werden Features ohne Rücksicht auf Wirtschaftlichkeit überdimensioniert, steigt der Aufwand, während der Nutzen ausbleibt. Entwickelt das Team am fachlichen Bedarf vorbei, entstehen Lösungen, die zwar technisch elegant, aber zu teuer oder an den eigentlichen Marktanforderungen vorbei sind. Fehlt die Abstimmung zwischen fachlicher Anforderung und technischer Realisierung, verliert das Produkt schnell den Anschluss an die tatsächlichen Bedürfnisse der Stakeholder.

Deshalb ist es essenziell, dass beide Seiten nicht nur ihre Verantwortung kennen, sondern auch regelmäßig und offen miteinander im Dialog bleiben. Gegenseitige Kontrolle und konstruktiver Austausch sorgen dafür, dass Priorität, Umsetzbarkeit und wirtschaftliche Vernunft dauerhaft in Balance bleiben.

Feedback und Kommunikation: Die Brücke zu den Stakeholdern

Ein zentrales Element agiler Entwicklung ist die transparente Kommunikation mit den Stakeholdern. Der PO fungiert dabei als Schnittstelle zwischen Team und Außenwelt. Nachdem das Entwicklungsteam entschieden hat, welche Aufgaben im Sprint bearbeitet werden, informiert der PO die Stakeholder regelmäßig über den Stand der Dinge, Fortschritte und eventuelle Veränderungen im Fahrplan. Rückfragen, neue Anforderungen oder konstruktives Feedback der Stakeholder werden aufgenommen, bewertet und – sofern sinnvoll – in das Backlog überführt.

Dieser Kommunikationsprozess ist ein kontinuierlicher Kreislauf:

  • Der PO nimmt Anforderungen und Feedback der Stakeholder auf,
  • priorisiert diese im Product Backlog,
  • stimmt sich mit dem Entwicklungsteam über Umsetzbarkeit und Timing ab,
  • kommuniziert die Sprintplanung und aktuelle Fortschritte an die Stakeholder zurück.

So bleibt die Produktentwicklung flexibel, kann auf neue Erkenntnisse, Marktveränderungen oder technologische Herausforderungen reagieren, und sorgt gleichzeitig dafür, dass die Stakeholder jederzeit den Überblick über den Projektstand behalten.

Fazit

Scrum lebt von klaren Verantwortlichkeiten und dem produktiven Spannungsfeld zwischen fachlichen Zielen und technischer Realisierbarkeit.

  • Was und wie wichtig bestimmt der Product Owner, stets im Dialog mit den Stakeholdern.
  • Wann und wie liegt in der Verantwortung des Entwicklungsteams.

Dieses Spannungsfeld ist kein Hindernis, sondern der Schlüssel zu nachhaltigem Produkterfolg. Es sorgt dafür, dass fachliche Ziele und technische Realitäten ausbalanciert werden und das Team flexibel, effizient und zielgerichtet arbeiten kann. Die regelmäßige, transparente Kommunikation – insbesondere das Feedback an die Stakeholder – ist dabei der Kitt, der alle Elemente zusammenhält und den langfristigen Erfolg sicherstellt.

Nunc Plaudite – Ein Manifest über die Zerstörung des Diskurses

Nunc Plaudite – Ein Manifest über die Zerstörung des Diskurses

Wir suchen die Schuld am Zerfall unserer Diskussionskultur meist bei offensichtlichen Tätern: Hasskommentare, Falschinformationen, Radikalisierung. Doch der wahre Verfall vollzieht sich still, beinahe unsichtbar. Nicht durch die Lüge, sondern durch Zustimmung. Nicht durch Manipulation, sondern durch unser Bedürfnis, akzeptiert zu werden.

Soziale Medien versprechen Gemeinschaft, doch was sie erschaffen haben, ist eine Maschine permanenter Affirmation. Der Algorithmus kennt keine Wahrheit, keine Vernunft – nur Zustimmung, Ablehnung und Reichweite. Jeder Kommentar, jedes Like ist Treibstoff für dieses System, egal ob wir unterstützen oder widersprechen. Wer widerspricht, verbreitet. Wer hinterfragt, verstärkt.

Die Grenze zwischen Meinung und Fakt verschwimmt vollkommen. Wo einst geprüfte Erkenntnisse standen, wo Wissenschaftler ihre Thesen dem Urteil unabhängiger Fachkollegen aussetzten (Peer-Review), wo Forschungsergebnisse monatelang geprüft wurden, zählt heute nur, ob eine Aussage emotional genug ist, um geteilt zu werden.

Wissenschaftliches Arbeiten ist unbequem. Es sucht keine Zustimmung, sondern Wahrheit – auch auf Kosten der Beliebtheit. Peer-Review-Verfahren in renommierten Fachmagazinen garantieren keine Likes, aber Klarheit, Belastbarkeit und Tiefe. Quod erat demonstrandum – „was zu beweisen war“ – markierte einst den Abschluss eines logisch sauberen Beweises. Genau diese Qualität verschwindet heute in der digitalen Welt der sofortigen Bestätigung. Hier gilt nicht mehr, was bewiesen, sondern was gefühlt wird. Nicht, was wahr ist, sondern was populär klingt. Quod erat applaudendum. Was zu bejubeln war. Oder besser nunc plaudite, die lateinische Aufforderung zu klatschen.

Wir alle sind Teil dieser Maschine. Wir liken, weil wir zustimmen. Wir liken, weil es sich gut anfühlt. Doch mit jedem Klick verstärken wir ein System, das echte Diskussion unmöglich macht. Die Folgen sehen wir täglich: Eine Politik, die lieber gefällt als überzeugt. Eine Gesellschaft, die lieber recht behält, als dazulernt. Eine Kultur, in der Wahrheit zur Geschmacksfrage wurde.

Es reicht nicht, soziale Medien nur zu kritisieren. Wir müssen uns eingestehen, dass ihre Mechanik die Grundlagen unserer Kultur systematisch untergräbt. Ihre Algorithmen sind nicht neutral, nicht harmlos, nicht kontrollierbar – sie sind giftig. Sie zerstören, was sie angeblich verbinden wollten.

Vielleicht müssen wir soziale Medien abschalten. Vielleicht müssen wir sie verbieten. Vielleicht sollten wir zumindest offen darüber sprechen, dass Plattformen, die Aufmerksamkeit über Wahrheit, Zustimmung über Erkenntnis stellen, niemals Orte echten Diskurses sein können.

Diese Forderung wird nicht populär sein. Zu stark ist unsere Illusion, wir hätten alles unter Kontrolle. Doch das ist Teil der Täuschung: Wer glaubt, soziale Medien zu beherrschen, hat bereits verloren.

Nicht Hass hat uns gespalten.
Nicht Lügen haben den Diskurs zerstört.
Wir selbst waren es.
Klick für Klick. Like für Like.

Noch immer jubeln wir dem Spektakel zu, während Wahrheit und Vernunft leise von der Bühne verschwinden.

Vielleicht hören wir erst auf zu applaudieren, wenn das Licht endgültig ausgegangen ist.
Vielleicht aber auch nicht.

Nunc plaudite, quod erat applaudendum.

Passkeys, elliptische Kurven und das Vertrauen in Root-CAs

Immer noch sind Passwörter Standard und es stellt sich zunehmend die Frage, warum an ihrer Stelle nicht schon viel früher sicherere Verfahren zum Einsatz kamen. Während Linux-Administratoren auf SSH-Keys setzen, wurde das Web bislang kaum von diesem Modell profitiert. Erst mit der Einführung von Passkeys – auf Basis von WebAuthn und FIDO2 – zeichnet sich ein genereller Wechsel ab. Im Folgenden wird erläutert, wie Passkeys technisch funktionieren, weshalb elliptische Kurven eine zentrale Rolle spielen, welche Schwachstellen das PKI-Modell mit Root-CAs aufweist und warum die Kombination aus Enpass und Brave Browser in der Praxis überzeugt.


1. Historischer Rückblick: Von Passwörtern zu Kryptographie

Passwörter sind nahezu so alt wie die ersten Computer – erste Systeme der 1960er Jahre nutzten einfache Zeichenketten als Zugangsschutz. Im Enterprise-Umfeld und bei Unix-Systemen setzte sich bald das SSH-Key-Verfahren durch: Ein asymmetrisches Schlüsselpaar ersetzte dort bereits in den frühen 1990er Jahren das klassische Passwort.

Parallel dazu entstand 1977 mit RSA (benannt nach Rivest, Shamir und Adleman) eine der ersten Public-Key-Kryptosysteme, das auf der Schwierigkeit der Faktorisierung großer Zahlen beruhte. Trotz ihrer mathematischen Eleganz haben RSA-Authentifikatoren im Vergleich zu modernen Verfahren einen entscheidenden Nachteil: Die für vergleichbare Sicherheit nötigen Schlüssel (z. B. 2048 Bit) sind groß, rechenintensiv und auf mobilen Geräten nur eingeschränkt praktikabel.

Passwörter dagegen haben sich in den letzten fünf Jahrzehnten kaum weiterentwickelt – sie bleiben anfällig für Brute-Force-Angriffe, Phishing und Credential Stuffing. Dass das Web erst jetzt beginnt, Schlüssel statt Passwörter zu verwenden, mag überraschen. Der Grund liegt in der Komplexität: WebPlattformen benötigten einen einheitlichen Standard, robuste Browser-APIs und breit unterstützte Hardware-Authenticators. All dies ist erst in den letzten Jahren durch WebAuthn und FIDO2 zusammengewachsen.


2. Warum Passkeys erst jetzt durchbrechen

Mehrere Faktoren trugen dazu bei, dass Passkeys erst im Jahr 2024/25 auf breiter Basis verfügbar sind:

  1. Standardisierung: WebAuthn (2018) und FIDO2 schufen ein offenes Framework für browser- und plattformübergreifende Authentifizierung.
  2. Browser-Support: Alle großen Browser (Chrome, Firefox, Edge, Safari) bieten heute native WebAuthn-APIs, inklusive UI-Dialogs zur Geräteauswahl und Biometrieabfrage.
  3. Betriebssystem-Integration: Secure Enclave (macOS/iOS), TPM (Windows), Android Keystore und vergleichbare Hardwaremodule ermöglichen die sichere Schlüsselspeicherung.
  4. Synchronisation: Hersteller-übergreifende Passkey-Synchronisation (iCloud Keychain, Google Password Manager, aber auch plattformunabhängige Tools) beseitigt das Vendor-Lock-in.
  5. Usability: Biometrische Freigabe oder Geräte-PIN ersetzt das Tippen langer Passwörter, gerade auf Mobilgeräten ein erheblicher Vorteil.

Diese Entwicklungen haben eine kritische Masse erreicht: Heute kann praktisch jede Web-Applikation Passkey-Anmeldung anbieten, ohne eigene Hardware-Token entwickeln zu müssen.


3. Technische Grundlagen der Passkeys

3.1 Schlüsselerzeugung und -speicherung

  • Schlüsselpaar: Beim Anlegen eines Passkeys generiert das Endgerät (Client) ein Schlüsselpaar.
  • Public Key: Wird zusammen mit einem Credential ID und Metadaten (z. B. Attestation Statement) an den Dienst übermittelt.
  • Private Key: Verbleibt in Secure Enclave, TPM oder im Password Manager (z. B. Enpass) und verlässt das Gerät nie.

3.2 Elliptische Kurven (ECC)

  • Primäralgorithmus: ECDSA über P-256 (COSE -7) – bietet mit 256 Bit Sicherheit vergleichbar zu 3 000 Bit RSA.
  • Vorteile:
  • Kurvenskepsis: Obwohl einige NIST-Kurven (P-256) wegen NSA-Herkunft kritisch betrachtet werden, gibt es transparentere Alternativen wie Ed25519 – deren Verfügbarkeit in WebAuthn jedoch noch nicht flächendeckend ist.

3.3 Ablauf einer Authentifizierung

  1. Challenge: Server generiert Nonce und sendet sie an den Client.
  2. Signatur: Client signiert die Challenge zusammen mit AuthenticatorData (Flags, Counter, RP-ID-Hash).
  3. Verifikation: Server überprüft Signatur mit dem gespeicherten Public Key.

Dank Domain-Binding (RP-ID) ist eine Signatur nur für die exakte Domain gültig – Phishing-Versuche werden damit wirkungsvoll abgewehrt.


4. Die Achillesferse der PKI: Vertrauen in Root-CAs

Auch wenn TLS 1.3, Perfect Forward Secrecy und starke Cipher Suites eingesetzt werden, bleibt das hierarchische Root-CA-Modell angreifbar:

  • Blindes Vertrauen: Browser liefern hunderte Root-Zertifikate aus, denen automatisch vertraut wird. Ein kompromittiertes oder erzwungen ausgestelltes Zertifikat erlaubt MITM-Angriffe.
  • Regierungsdruck: Staaten können CAs zur Ausstellung von Zertifikaten für beliebige Domains zwingen. Selbst strenge TLS-Konfiguration nützt wenig, wenn der Client ein manipuliertes Zertifikat akzeptiert.

Passkeys adressieren nicht das Transportproblem, sie schließen jedoch die Lücke bei der Identifikation des Nutzers. In Kombination mit HSTS, Certificate Pinning oder alternativen Trust-Modellen (TOFU, DANE) lässt sich das Gesamtsicherheitsniveau deutlich steigern.


5. Praxisbeispiel: Enpass + Brave Setup

Für plattformübergreifende Passkey-Verwaltung nutze ich persönlich Enpass in Kombination mit Brave. Beim ersten Login auf einer Website mit Passkey-Support wird Enpass zur Auswahl des passenden Credentials aufgefordert. Biometrie, PIN-Eingabe oder Masterpasswort auf dem Gerät schalten den privaten Schlüssel frei, und die Anmeldung erfolgt mit einem Klick. Das Ergebnis: Einfache sichere Logins, mit einem Masterpasswort / Pin gesichert.


6. Fazit

Passkeys markieren einen überfälligen Schritt hin zu passwortlosen Authentifizierungslösungen. Sie verbinden starke asymmetrische Kryptographie (vorzugsweise ECC) mit hoher Benutzerfreundlichkeit und Phishing-Resistenz. Der noch immer angreifbare Teil bleibt die TLS-Infrastruktur auf Basis von Root-CAs – doch hier lassen sich mit ergänzenden Maßnahmen Schwachstellen reduzieren.

In der täglichen Praxis erweist sich das Setup aus Enpass und Brave als robust, plattformunabhängig und wartungsarm. Damit steht einer breiten Einführung passkeybasierter Logins nichts mehr im Wege – abgesehen von der alten Gewohnheit, weiterhin an Passwörtern festzuhalten.

In meinen Augen ist dieser Paradigmenwechsel längst überfällig.

Entra ID Risks

Risiken durch Microsoft Entra ID & Microsoft 365 für deutsche Unternehmen mit besonderen Geheimhaltungspflichten und Behörden

In den vergangenen Jahren haben Cloud-Dienste wie Microsoft Entra ID (früher Azure AD) und Microsoft 365 ihren Siegeszug in deutschen Unternehmen und Behörden angetreten. Sie bieten attraktive Vorteile wie Skalierbarkeit, einfache Administration und umfassende Kollaborationstools. Doch gerade für deutsche Unternehmen und Behörden mit hohen Geheimhaltungspflichten, etwa im Bereich Steuern, Justiz, Gesundheitswesen oder kritischer Infrastruktur, entstehen hierdurch signifikante, oft unterschätzte Risiken.

Dieses Whitepaper erläutert, warum die Verwendung von Microsoft Entra ID sowie Microsoft 365 aus Sicht des Datenschutzes und der Datenhoheit kritisch bewertet werden sollte – insbesondere vor dem Hintergrund bestehender US-Gesetze wie dem CLOUD Act und FISA.


1. Ausgangslage: Rechtsgrundlagen in den USA

CLOUD Act

Der 2018 verabschiedete Clarifying Lawful Overseas Use of Data Act (CLOUD Act) verpflichtet US-Technologieanbieter wie Microsoft dazu, gespeicherte Kundendaten – auch wenn diese außerhalb der USA lagern – an US-Behörden herauszugeben. Ausschlaggebend ist hier nicht der Speicherort der Daten, sondern die Kontrolle durch den Anbieter.

Foreign Intelligence Surveillance Act (FISA)

FISA ermöglicht US-Geheimdiensten Zugriff auf Daten ausländischer Bürger und Institutionen, sofern die Informationen als relevant für die nationale Sicherheit eingeschätzt werden. FISA-Beschlüsse erfolgen geheim und ohne Kenntnis der Betroffenen.

National Security Letters (NSL)

US-Behörden wie das FBI nutzen NSLs, um bei Unternehmen Teilnehmerdaten (etwa Metadaten oder Zugangsinformationen) abzufragen – ohne richterliche Genehmigung und oftmals mit einer Geheimhaltungsverpflichtung (Gag Order) versehen.


2. Technische Implikationen für Entra ID und Microsoft 365

Die genannten US-Gesetze zielen auf Anbieter wie Microsoft, die sowohl vertraglich als auch technisch in der Lage sind, auf die Daten ihrer Kunden zuzugreifen. Dienste wie Microsoft Entra ID und Microsoft 365 werden vollständig unter Kontrolle von Microsoft betrieben. Daten werden zwar verschlüsselt gespeichert („Data at Rest“ und „Data in Transit“), jedoch hält Microsoft die Verschlüsselungsschlüssel selbst – eine Ende-zu-Ende-Verschlüsselung (Zero-Knowledge) besteht nicht.

Dies bedeutet konkret:

  • Microsoft verfügt jederzeit über die technischen Mittel, Kundendaten – inklusive Dokumente, Mails und Identitätsinformationen – auszulesen.
  • Ein Zugriff durch US-Behörden auf Basis von US-Gerichtsbeschlüssen oder geheimen Anordnungen ist technisch unkompliziert möglich.
  • Ein Schutz vor Zugriffen nach US-Recht erfolgt lediglich durch vertragliche Zusicherungen, nicht aber durch eine tatsächlich unabhängige technische Architektur.

3. Risiken durch politische Entwicklungen in den USA

Insbesondere unter einer US-Regierung, die nationale Sicherheitsinteressen expansiv definiert, steigt das Risiko deutlich. Bereits während der ersten Amtszeit der Trump-Regierung wurde sichtbar, wie schnell politische Veränderungen sich auf internationale Datenschutzstandards auswirken können.

Ein erneuter Politikwechsel in den USA hin zu einem expansiven Sicherheitsverständnis könnte dazu führen, dass:

  • Bestehende Rechtsinstrumente wie CLOUD Act und FISA noch intensiver genutzt werden, um Daten ausländischer Unternehmen, Behörden und deren Klienten oder Partnern einzusehen.
  • Unternehmen und Behörden, deren Daten in US-Clouds liegen, unmittelbar und ohne Vorwarnung betroffen wären.

4. Folgen für deutsche Unternehmen und Behörden

Für deutsche Unternehmen und Behörden, die besonderen gesetzlichen Geheimhaltungspflichten unterliegen, ist die Nutzung von Entra ID und Microsoft 365 mit erheblichen rechtlichen, wirtschaftlichen und reputativen Risiken verbunden:

  • Verstoß gegen EU-Datenschutzvorgaben (DSGVO):
    Europäische Gerichte (insbesondere der EuGH) sehen den CLOUD Act und FISA als nicht kompatibel mit europäischem Datenschutz an.
  • Reputationsverlust und Kundenvertrauen:
    Sollte bekannt werden, dass sensible Daten – z.B. Mandantendaten, Gesundheitsinformationen, Forschungsergebnisse – indirekt an US-Behörden gelangen, droht massiver Vertrauensverlust und wirtschaftlicher Schaden.
  • Rechtliche Konsequenzen:
    Bußgelder der Datenschutzaufsicht sowie Klagen von betroffenen Kunden oder Partnern könnten folgen.

5. Warum Microsoft 365 Deutschland keine echte Souveränität bietet

Die 2016 gestartete „Microsoft Cloud Deutschland“ versprach ursprünglich echte Datenhoheit durch Betrieb durch T-Systems als Treuhänder. Microsoft selbst hatte keinerlei direkten Zugriff auf diese Daten. Diese Version wurde jedoch 2020 eingestellt.

Die neue Lösung („EU Data Boundary“) verspricht zwar eine Datenhaltung innerhalb der EU. Aber technisch und organisatorisch bleibt Microsoft alleiniger Betreiber der Infrastruktur. US-Behörden können weiterhin auf Grundlage des CLOUD Act und FISA Zugriff auf diese Daten verlangen.

Kurzum:
Die EU Data Boundary bietet lediglich eine vertragliche, keine technische Souveränität und keinen Schutz vor Zugriffen durch US-Behörden.


6. Empfehlungen für deutsche Unternehmen und Behörden

Um rechtlich und technisch sicher zu agieren, sollten Unternehmen und Behörden folgende Maßnahmen umsetzen:

  • Nutzung souveräner europäischer Clouds:
    Alternativen wie IONOS Cloud, T-Systems Sovereign Cloud, Open Telekom Cloud, etc. Lösungen bieten echte Unabhängigkeit und europäische Kontrolle.
  • Zero-Trust-Architekturen:
    Trennung von Authentifizierung (z.B. Entra ID als reiner Login-Provider) und Datenhaltung (getrennte Systeme mit Ende-zu-Ende-Verschlüsselung).
  • Customer Managed Encryption Keys:
    Lokale Schlüsselverwaltung bei Verwendung US-amerikanischer Dienste reduziert Risiken und steigert Kontrolle.
  • Rechtliche und organisatorische Maßnahmen:
    Verbindliche Prozesse zur Klassifizierung sensibler Daten und Auditierung der Cloud-Infrastrukturen.

Fazit und Handlungsaufforderung

Cloud-Dienste wie Microsoft Entra ID und Microsoft 365 bieten große Chancen, stellen aber gerade für Unternehmen und Behörden mit besonderen Geheimhaltungspflichten ein erhebliches Risiko dar. Angesichts der geltenden US-Gesetze und der ungewissen politischen Entwicklung in den USA sollten europäische Unternehmen und öffentliche Einrichtungen genau abwägen, welche Daten sie auf US-gehosteten Plattformen speichern.

Es gilt, technische, organisatorische und rechtliche Maßnahmen zu ergreifen, um sich effektiv zu schützen und die eigene Souveränität nachhaltig sicherzustellen.

Die Wahl der richtigen Infrastruktur ist dabei nicht nur eine technische Frage, sondern eine Entscheidung über Souveränität, Compliance und Vertrauen.