This series connected a simple strategic idea—reducing lock‑in and increasing control—to how modern EU rules ask you to prove security, resilience, data respect, and product discipline. Open source is a means, not a certificate. The outcome regulators care about is operational: defensible governance, tested recovery, traceable software, and honest data handling.

Frontier coding assistants are capable, but they arrive with constraint layers baked in. For security researchers, low-level systems work, or any task touching edge-case logic, those constraints become a productivity tax rather than a safety net. The model declines; the sprint stalls.

The EU Data Act introduces rules on access to and use of data, contractual fairness, switching between data processing services, and interoperability in several contexts (including Internet of Things and B2B data sharing scenarios per its scope). It is explicitly aimed at reducing lock‑in and unfair contractual imbalance—not identical to GDPR, but complementary when you negotiate cloud and platform contracts.

The Cyber Resilience Act (CRA) targets products with digital elements placed on the EU market: secure by design, vulnerability handling, and transparency obligations that flow through manufacturers, importers, and distributors. If you ship hardware or software as a product—or embed connectivity in what you sell—CRA logic eventually touches how you build, update, and disclose flaws.

The demo was never lying: a few dollars of API spend can draft what might have taken a human afternoon. In production you run two ledgers. One is the vendor bill—frontier models are still on the order of dollars per million input tokens and more for output (OpenAI API pricing). The other is retries, review, security fixes, and escalations when “almost right” ships.

The EU AI Act regulates how AI systems are placed on the market and used, with escalating obligations for high‑risk categories, transparency for certain general‑purpose and consumer‑facing cases, and governance expectations that land on deployers as well as providers. Open‑source weights or code do not automatically exempt a real‑world deployment from duties once the system is part of a product or business process.

NIS2 raises the floor for cyber risk management, supply‑chain security, incident handling, and accountability across essential and important entities in Member States’ transpositions. Open source can strengthen security when you control patching and architecture; it weakens it when “community maintenance” becomes an excuse for drift.

The Digital Operational Resilience Act (DORA) is not a licensing discussion; it is an ICT risk and third‑party regime for the financial sector. Whether your database is proprietary or open source, you must prove you can manage and recover critical functions when suppliers, software, or infrastructure fail.

The GDPR does not mandate open source. It mandates accountability: lawful basis, purpose limitation, data minimisation, security of processing, subprocessors, transfers, breach notification, and the rights of data subjects. When you migrate workloads to open‑source platforms or self‑hosted stacks, supervisors still ask one question: can you show how controls are implemented and who is responsible?

Proprietary stacks are not “bad,” but they concentrate risk. When critical workloads, encryption keys, audit logs, and AI inference paths all depend on opaque roadmaps and a single commercial trajectory, you inherit someone else’s priorities: price changes, feature deprecation, regional product splits, and incident timelines you do not control.

Over this series we moved from one core idea to its full implication: once AI is connected to business systems, it becomes an attack surface with real operational consequences.

Prevention is essential, but it is no longer enough. If AI systems are in production, incident response must evolve accordingly.