Shipping fixes is now a legal duty — and a capacity problem. What PostHog showed us at AI Tinkerers Vienna

CRA, NIS2 and the new Product Liability Directive make security fixes a duty. At AI Tinkerers Vienna we saw how PostHog turns signals into reviewed fixes.

Two forces on one product: EU regulation 2024–2028 and limited team capacity — bridged by signals, AI-drafted fixes and human review

Every software team knows the tension. On one side, regulation: publishing fixes for vulnerabilities and defects is no longer good practice but a legal obligation in the EU — with deadlines, reporting duties and liability. On the other side, capacity: the same engineers are needed to improve the product, ship features and stay competitive. Both are non-negotiable. Neither waits.

Why fixing is no longer optional: the EU timeline 2024–2028

Date	Regulation	What it means for software fixes
17 Oct 2024	NIS2 (transposition deadline)	Risk management, incident handling and supply-chain security for essential and important entities.
10 Dec 2024	Cyber Resilience Act (CRA) enters into force	Start of the transition period for all products with digital elements.
13 Dec 2024	GPSR applies	General product safety, including corrective actions and recalls.
17 Jan 2025	DORA applies	ICT risk and incident management in the financial sector and its ICT providers.
1 Aug 2025	Radio Equipment Directive — cybersecurity requirements	Connected radio devices must meet security requirements (EN 18031).
11 Sep 2026	CRA reporting obligations	Actively exploited vulnerabilities and severe incidents: early warning within 24 h, notification within 72 h, final report — also for products already on the market.
1 Oct 2026	NISG 2026 in force (Austria)	National NIS2 implementation; registration of affected entities.
9 Dec 2026	Product Liability Directive (EU) 2024/2853	Software is a product. A missing security update within the manufacturer’s control can make a product defective.
11 Dec 2027	CRA fully applies	Secure by design, vulnerability handling, free security updates for the support period (as a rule at least five years), CE marking.
2 Dec 2027 / 2 Aug 2028	AI Act — high-risk obligations	Postponed by the 2026 AI Omnibus; robustness, accuracy and cybersecurity of high-risk AI systems.

The message for architects is clear: the ability to find, fix, document and ship corrections quickly becomes a compliance capability — not just an engineering virtue.

The capacity gap

Regulation adds work without adding people. Triage, root-cause analysis, patch, test, release notes, evidence, reporting — every fix carries a process. If that process runs manually, it competes directly with the product work that keeps a company in business. The answer cannot be “work harder”. It has to be better architecture of the work itself.

AI Tinkerers Vienna, 1 October 2026: PostHog

I am a convinced fan of GitHub and open source — but not every repository deserves a blog post. The project presented at the AI Tinkerers meetup in Vienna on 1 October 2026 does: PostHog.

PostHog is an open-source product platform (MIT-licensed core, with a fully free FOSS edition) that combines product analytics, session replay, error tracking, feature flags, experiments, surveys, logs and LLM observability in one stack. Since July 2026 it adds a “self-driving” mode: AI agents (“scouts”) continuously watch real product signals — exceptions, rage clicks, failed queries — cluster and prioritise them in an inbox, research the cause and draft a pull request in a sandbox. A developer reviews the change and decides whether to merge it.

Real improvements

From signal to fix in one chain. The error, the affected session, the user impact and the code change live in one context instead of five tools.
Prioritised, de-duplicated issues. Similar errors are clustered and ranked, so the team works on what hurts users most.
Draft fixes instead of empty tickets. Engineers start from a researched proposal and a ready pull request — not from a blank page.
Human in control. Nothing reaches production without review and merge by a person.
Open and inspectable. The code is on GitHub; teams can self-host or choose the EU cloud for data residency.

Real benefits

Shorter time-to-fix — which directly supports CRA reporting deadlines and liability prevention.
Capacity back for product work — triage and first-draft fixing no longer consume senior engineers.
Traceability as a by-product — signal, analysis, change and approval are documented in one place: useful evidence for audits and incident reports.
Better product quality — real user signals instead of guesswork decide what gets fixed first.
Lower lock-in risk — open source means the approach remains reproducible and auditable.

As with any tool that processes user data, the rules stay the same: consent where required, data minimisation, EU hosting or self-hosting, and clear permissions for what agents may change.

The architect’s conclusion: delegate — but never blindly

For us, the result is simple: we saved a lot of time. But the real lesson goes deeper. Human resources are the most vulnerable resource of every software company: they are limited, hard to replace and burn out fastest on repetitive work. Architects should therefore delegate — to tools, to automation, to well-designed loops. But they must not follow processes that make no sense just because a tool can run them faster. Automating a bad process only produces bad results faster.

Question the process first. Then automate it. And keep the decision with people.

Would you like to know how your fix-and-release process could meet the new EU requirements without draining your team? Talk to us.

This article provides general information on EU regulation and is not legal advice. For AI governance questions, see our sister brand KI-Beratung.st.

Sources

Sources checked: 3 October 2026.

Cyber Resilience Actsecurity updatesopen sourcePostHogAI Tinkererssoftware architecture

← All insights & news