Short, specific pieces on what new rules ask of engineering teams, how to decide on AI infrastructure, and how to make delivery measurable — each one ending in something you can do this quarter.
NIS2 for engineering teams: the ten measures, read as work
Read the articleThe EU’s NIS2 Directive extended cybersecurity duties to thousands of organisations in manufacturing, transport, health, digital services and more. Most of its ten minimum measures are things engineering teams build and run.
An assistant that answers from your own documents is only useful if people can check it. What it takes to build one that grounds every answer, respects permissions and says when it does not know.
The EU’s Digital Operational Resilience Act has applied since 17 January 2025. Most of what it asks lands on the teams that build, test and run software. Here is what that means in practice.
Most of what the AI Act asks of high-risk systems is engineering work — logging, documentation, human oversight, data governance. Building it in now costs far less than retrofitting it.
Running models inside your own boundary solves real problems — data that cannot leave, cost at volume, control over versions — and creates others. A practical way to decide, workload by workload.
Cybersecurity and software-update management are now conditions of vehicle type approval in the EU and other markets that apply UN regulations. What that asks of the teams who write and ship the software.
Many delivery slips are decided before a line of code is written. How to spot an untestable requirement, fix it while it is cheap, and keep it fixed.
A 98% pass rate says nothing about whether the stories you committed to were tested at all. How traceability and recorded quality gates change the release conversation.
GxP software has to be shown fit for its intended use, and the record has to stand up to inspection. Validation does not have to mean a mountain of documents or a waterfall plan.
The time to find out what a service is doing is not the night it fails. What to instrument from day one, how to choose alerts people will not learn to ignore, and why service level objectives settle arguments.
Most peak-day failures were visible weeks earlier to anyone testing the right thing. How to build a load model from real traffic, test the dependencies you do not own, and decide what to switch off before it breaks.
How to replace a system the business runs on one piece at a time, behind an interface that lets everything else keep calling the same address.
Tell us which article is closest to the problem you have. We will come back with what we would look at first.
Topics we write about
