Fehlerbehebung ist jetzt Pflicht – und eine Kapazitätsfrage. Was uns PostHog bei AI Tinkerers Wien gezeigt hat

CRA, NIS2 und Produkthaftung machen Sicherheitsupdates zur Pflicht. Bei AI Tinkerers Wien sahen wir, wie PostHog daraus geprüfte Fixes macht.

Zwei Kräfte auf ein Produkt: EU-Regulierung 2024–2028 und begrenzte Teamkapazität – verbunden durch Signale, KI-Fixentwürfe und menschliche Prüfung

Jedes Softwareteam kennt dieses Spannungsfeld. Auf der einen Seite die Regulierung: Korrekturen für Schwachstellen und Fehler zu veröffentlichen, ist in der EU keine gute Praxis mehr, sondern gesetzliche Pflicht – mit Fristen, Meldepflichten und Haftung. Auf der anderen Seite die Kapazität: Dieselben Entwicklerinnen und Entwickler werden gebraucht, um das Produkt weiterzuentwickeln, Funktionen auszuliefern und wettbewerbsfähig zu bleiben. Beides ist unverzichtbar. Keines von beiden wartet.

Warum Fehlerbehebung nicht mehr optional ist: der EU-Zeitplan 2024–2028

Datum	Regelwerk	Bedeutung für Software-Korrekturen
17. Okt. 2024	NIS2 (Umsetzungsfrist)	Risikomanagement, Vorfallbehandlung und Lieferkettensicherheit für wesentliche und wichtige Einrichtungen.
10. Dez. 2024	Cyber Resilience Act (CRA) tritt in Kraft	Beginn der Übergangsfrist für alle Produkte mit digitalen Elementen.
13. Dez. 2024	GPSR gilt	Allgemeine Produktsicherheit, einschließlich Korrekturmaßnahmen und Rückrufen.
17. Jan. 2025	DORA gilt	IKT-Risiko- und Vorfallmanagement im Finanzsektor und bei dessen IKT-Dienstleistern.
1. Aug. 2025	Funkanlagenrichtlinie – Cybersicherheitsanforderungen	Vernetzte Funkgeräte müssen Sicherheitsanforderungen erfüllen (EN 18031).
11. Sep. 2026	CRA-Meldepflichten	Aktiv ausgenutzte Schwachstellen und schwere Vorfälle: Frühwarnung binnen 24 h, Meldung binnen 72 h, Abschlussbericht – auch für bereits vermarktete Produkte.
1. Okt. 2026	NISG 2026 in Kraft (Österreich)	Nationale NIS2-Umsetzung; Registrierung betroffener Einrichtungen.
9. Dez. 2026	Produkthaftungsrichtlinie (EU) 2024/2853	Software ist ein Produkt. Ein fehlendes Sicherheitsupdate im Einflussbereich des Herstellers kann ein Produkt fehlerhaft machen.
11. Dez. 2027	CRA gilt vollständig	Security by Design, Schwachstellenbehandlung, kostenlose Sicherheitsupdates für den Unterstützungszeitraum (in der Regel mindestens fünf Jahre), CE-Kennzeichnung.
2. Dez. 2027 / 2. Aug. 2028	AI Act – Hochrisiko-Pflichten	Durch den AI Omnibus 2026 verschoben; Robustheit, Genauigkeit und Cybersicherheit von Hochrisiko-KI-Systemen.

Die Botschaft für Architekten ist eindeutig: Die Fähigkeit, Korrekturen schnell zu finden, umzusetzen, zu dokumentieren und auszuliefern, wird zur Compliance-Fähigkeit – nicht nur zur Ingenieurstugend.

Die Kapazitätslücke

Regulierung bringt Arbeit, aber keine zusätzlichen Menschen. Triage, Ursachenanalyse, Patch, Test, Release Notes, Nachweise, Meldungen – hinter jedem Fix steht ein Prozess. Läuft dieser Prozess manuell, konkurriert er direkt mit der Produktarbeit, die ein Unternehmen am Markt hält. Die Antwort kann nicht „mehr arbeiten“ lauten. Sie muss lauten: bessere Architektur der Arbeit selbst.

AI Tinkerers Wien, 1. Oktober 2026: PostHog

Ich bin überzeugter GitHub- und Open-Source-Fan – aber nicht jedes Repository verdient einen Blogbeitrag. Das Projekt, das beim AI-Tinkerers-Treffen in Wien am 1. Oktober 2026 vorgestellt wurde, schon: PostHog.

PostHog ist eine Open-Source-Produktplattform (Kern unter MIT-Lizenz, zusätzlich eine vollständig freie FOSS-Edition), die Produktanalyse, Session Replay, Error Tracking, Feature Flags, Experimente, Umfragen, Logs und LLM-Observability in einem System vereint. Seit Juli 2026 kommt ein „Self-Driving“-Modus hinzu: KI-Agenten („Scouts“) beobachten laufend reale Produktsignale – Exceptions, Rage Clicks, fehlgeschlagene Abfragen –, bündeln und priorisieren sie in einer Inbox, recherchieren die Ursache und erstellen einen Pull-Request-Entwurf in einer Sandbox. Eine Entwicklerin oder ein Entwickler prüft die Änderung und entscheidet über den Merge.

Echte Verbesserungen

Vom Signal zum Fix in einer Kette. Fehler, betroffene Sitzung, Auswirkung auf Nutzer und Codeänderung liegen in einem Kontext statt in fünf Werkzeugen.
Priorisierte, entdoppelte Probleme. Ähnliche Fehler werden gebündelt und gereiht – das Team arbeitet an dem, was Nutzer am meisten trifft.
Fix-Entwürfe statt leerer Tickets. Entwickler starten von einem recherchierten Vorschlag und einem fertigen Pull Request – nicht von einem leeren Blatt.
Der Mensch behält die Kontrolle. Nichts geht ohne Prüfung und Merge durch eine Person in Produktion.
Offen und nachvollziehbar. Der Code liegt auf GitHub; Teams können selbst hosten oder die EU-Cloud für Datenresidenz wählen.

Echter Nutzen

Kürzere Zeit bis zum Fix – das unterstützt direkt die Meldefristen des CRA und die Vermeidung von Haftung.
Kapazität zurück für Produktarbeit – Triage und erste Fix-Entwürfe binden keine Senior-Entwickler mehr.
Nachvollziehbarkeit als Nebenprodukt – Signal, Analyse, Änderung und Freigabe sind an einem Ort dokumentiert: wertvolle Nachweise für Audits und Vorfallmeldungen.
Bessere Produktqualität – echte Nutzersignale statt Vermutungen bestimmen, was zuerst behoben wird.
Geringeres Lock-in-Risiko – Open Source heißt: Der Ansatz bleibt reproduzierbar und prüfbar.

Wie bei jedem Werkzeug, das Nutzerdaten verarbeitet, gelten dieselben Regeln: Einwilligung, wo erforderlich, Datenminimierung, EU-Hosting oder Self-Hosting und klare Berechtigungen dafür, was Agenten ändern dürfen.

Für uns ist das Ergebnis einfach: Wir haben sehr viel Zeit gespart. Die eigentliche Lehre reicht aber tiefer. Menschliche Ressourcen sind die verletzlichste Ressource jedes Softwareunternehmens: begrenzt, schwer ersetzbar und am schnellsten erschöpft durch Routinearbeit. Architekten sollen daher delegieren – an Werkzeuge, an Automatisierung, an gut gestaltete Loops. Aber sie dürfen keinen unsinnigen Abläufen folgen, nur weil ein Werkzeug sie schneller ausführen kann. Wer einen schlechten Prozess automatisiert, erhält nur schneller schlechte Ergebnisse.

Zuerst den Prozess hinterfragen. Dann automatisieren. Und die Entscheidung beim Menschen lassen.

Möchten Sie wissen, wie Ihr Fix- und Release-Prozess die neuen EU-Anforderungen erfüllen kann, ohne Ihr Team auszulaugen? Sprechen Sie mit uns.

Dieser Beitrag dient der allgemeinen Information über EU-Regulierung und stellt keine Rechtsberatung dar. Zu Fragen der KI-Governance siehe unsere Schwestermarke KI-Beratung.st.

Quellen

Quellen geprüft: 3. Oktober 2026.

Cyber Resilience ActSicherheitsupdatesOpen SourcePostHogAI TinkerersSoftwarearchitektur

← Alle Beiträge