Reflections from Trust Valley 2026 on reconciling speed with control, frontier AI with confidentiality, and efficiency with legal obligations.
“I think it’s fair to say that for all of us in the room, the rate of technological change has never been faster in our lifetime than it is today.”
— Edouard Bugnion
Coming from Edouard Bugnion, VMware co-founder and professor at the École polytechnique fédérale de Lausanne (EPFL), that assessment carries weight. His career spans decades of change in computing infrastructure. Opening the second day of Trust Valley Days at EPFL on 24 September, he connected the pace of artificial intelligence (AI) development to an immediate responsibility: maintaining the resilience of the systems we already depend on.
His argument was direct. AI produces breakthroughs that can strengthen trust and capabilities that can undermine it. Organisations need to use the new tools to reduce technical debt and improve the quality of their systems, because attackers are gaining access to those tools too.
“Because if you don’t use the latest techniques in order to improve the quality of your own systems, the bad actors will use the latest techniques in order to break into these systems. So we are in a race at an accelerated pace between the solutions enabled by AI and the problems created by AI.”
— Edouard Bugnion
That observation stayed with me throughout the day. So did the security discussions, the case for openness made by Apertus, the possibilities of quantum–AI convergence, and a reminder from the public sector that efficiency must operate within the law.
Together, they raised a question: how do we move at the pace these technologies make possible while retaining the capacity to understand, control and correct what we deploy?
Integrating AI changes how we operate
Bugnion’s call to improve the systems we already depend on raises a practical question for organisations: what must change when AI becomes part of how those systems work?
AI can support a decision, generate software or become part of a business workflow. Agentic systems extend that role by selecting steps and invoking tools to carry out a task. The degree of autonomy varies, but in each case the organisation has to understand how the AI component affects the wider system and who remains accountable for the result.
The opportunity therefore reaches beyond installing a new tool. Realising it can require changes to workflows, responsibilities and decision-making. Controls also need to reflect the consequences: a recommendation reviewed by an employee and an automated action affecting a customer call for different safeguards. Some approvals can be streamlined; others protect rights or establish authority and must remain.
In rock climbing, some difficult moves require a dynamic commitment. There is no stable position at every point along the movement. You prepare, assess the next hold and commit, supported by protection appropriate to the route.
That analogy helps me think about organisational change. We need preparation and protection that support movement, with clear limits on what we are prepared to attempt. For systems incorporating AI, that means being able to evaluate a change, bound its effects and intervene when the result differs from what we expected.
Those capabilities have to last beyond the first deployment. This is where I see Continuous Delivery becoming a strategic capability.
Integrating AI creates a maintenance obligation
Consider an organisation that integrates an AI system into an operational workflow. It draws on internal information, interacts with business applications and, within defined permissions, carries out some actions. The initial deployment works and teams begin to depend on it. But the organisation’s release process means changes to the system take six months.
During that period, a vulnerability may be discovered in a connector, a model provider may change a service, or experience may reveal that the system acts incorrectly on particular inputs. The organisation needs a way to respond. Keeping a version stable can be a deliberate choice; being unable to apply a security fix, restrict an integration or correct harmful behaviour leaves it exposed.
The responsibility begins with adoption. Before relying on AI in an operational system, we need to know how we will evaluate changes, introduce fixes, detect regressions, revoke access and recover from failure. Those capabilities need an owner, time and resources throughout the system’s life, including when parts of it are supplied by others.
Continuous Delivery is the discipline of keeping software in a state where changes can be released safely and promptly. Small changes, automated verification and a repeatable path into production help us meet that obligation. Release decisions can still include human approval where the consequences require it.
For systems incorporating AI, the scope extends beyond application code. Model versions, instructions, data sources, tools and permissions can all affect behaviour. Evaluations need to cover representative tasks and known failure cases, including the actions an agentic system is allowed to take. Monitoring remains necessary because live inputs and connected services can differ from the evaluation environment.
The goal is a dependable cycle: change, evaluate, release, observe and correct. That capacity to respond becomes especially important when we turn to the security threats discussed at Trust Valley.
Delivery and defence have to develop together
The cybersecurity panel, including the contribution of Juan Avellan, General Manager at ELCA Security, was another moment that stayed with me. It belongs alongside a separate intervention by Alain Mowat of Orange Cyberdefense, whose talk, AI: A Double-Edged Sword for Cybersecurity, made the relationship between capability and exposure concrete.
Mowat described three dimensions: AI assisting attackers, AI strengthening defenders, and AI systems becoming targets themselves. With agents, the third dimension becomes particularly consequential. Instructions hidden in material an agent reads can redirect its behaviour, a form of attack known as prompt injection. If the agent can invoke tools, that redirection may lead to actions beyond producing text.
He also described laboratory work in which orchestrating several specialised agents improved offensive results. That observation matters for people building agentic workflows: orchestration can amplify capabilities on both sides of the security equation.
He qualified those results. Laboratory benchmarks operate under particular conditions, and fundamentals such as least privilege, segmentation and defence in depth remain essential. His expectation was that attackers could benefit more in the short term, while defenders could gain a stronger position over time.
“All the security basics that we’ve been trying to drill into companies for years now, defense in depth, least privileges, segmentation, and so on, are still as important, if not more important, than ever before.”
— Alain Mowat
For me, this reinforces Bugnion’s opening argument. There are two reasons to move: developing new capabilities and maintaining our ability to defend what we operate. AI-assisted monitoring, vulnerability discovery and incident investigation can help shorten the defensive feedback loop. Their effectiveness still depends on sound engineering, access controls and people able to act on what they reveal.
That creates a practical connection to Continuous Delivery. Finding a vulnerability quickly is valuable when we can also correct it quickly. Detecting unexpected agent behaviour is useful when we can restrict a tool, withdraw a release or isolate the affected environment.
Small releases, automated security checks, runtime monitoring and tested recovery mechanisms belong in the same operating model. For irreversible actions, such as disclosing sensitive information or making a legally binding commitment, safeguards must act before execution. A rollback cannot recover a secret that has already left the organisation.
Openness creates the conditions for independent scrutiny
Imanol Schlag’s contribution on Apertus added a further condition: access to the information needed to examine a system.
In the panel on Europe’s AI strategy, he described openness across model weights, training methods, data provenance and the values shaping intended model behaviour. He linked that transparency to the ability to research alignment and assess risks as models become components of semi-autonomous and autonomous systems.
“As we move into this more agentic world and these systems, these models become the brains of semi-autonomous and autonomous systems, we’re also transparent about the values that we bake into these models.”
— Imanol Schlag
This matters beyond the choice between suppliers. Organisations accepting responsibility for AI need grounds on which to assess the claims made about it.
A closed system can be evaluated through its observable behaviour. But investigating how it was trained, which data informed it or how its intended behaviour was defined requires information that may remain inaccessible. Openness enables additional forms of independent investigation and gives researchers a basis for reproducing, questioning and extending the work.
It also creates responsibilities. Access to a model does not establish that a particular deployment is secure. We still have to evaluate its behaviour in our setting and examine the surrounding tools, data flows and permissions.
I see a connection between this argument and delivery practice: openness supports scrutiny, while Continuous Delivery provides a route for acting on what scrutiny reveals. Both become more useful when the organisation has the competence to use them.
Convergence makes adaptability more valuable
Kelly Richdale’s keynote, The Next Technology Frontier: At the Edge of What’s Possible, widened the perspective from individual technologies to their interaction.
Her examples explored how AI can support the development of quantum technologies and how quantum sensing combined with machine learning can enable new applications. She also discussed physics-based modelling for scientific and industrial discovery. These strands have different levels of maturity; quantum sensing, physics-informed models and large-scale quantum computing should be assessed on their own evidence and timelines.
What stayed with me was the broader idea of convergence. Advances in one field can change the possibilities of another. The smartphone offers a familiar precedent: its capabilities emerged from the combination of computing, connectivity, sensing and software.
“So fundamentally, what we’re thinking about in tech convergence is not just how the technologies interact, but what kind of society we are building for tomorrow.”
— Kelly Richdale
For organisations, that raises the value of adaptability. Infrastructure choices, supplier relationships and security architectures need room to evolve as capabilities and threats change. Quantum computing’s potential implications for cryptography provide one example: knowing where cryptography is used and being able to replace implementations are concrete preparation tasks, even while the timeline for a cryptographically relevant quantum computer remains uncertain.
The same maintenance question returns at a larger scale. How readily can we change the foundations on which our services depend?
Public authority has a legal boundary
Carlos Orjales, Program Manager at the Swiss State Secretariat for Economic Affairs (SECO), provided a necessary boundary during the panel From pilot to policy: governing AI in the public sector.
“My task as a public official is not to be efficient. I mean, it’s good if I’m efficient, but what I have to do is respect the law.”
— Carlos Orjales
He explained that public administrations operate under laws and regulations adopted through political processes. Using citizens’ data requires a legal basis. Separate ministries can have distinct mandates that cannot simply be merged because a unified technical system would be more convenient.
This point changes how we should read organisational friction. Some of it reflects a lack of technical capacity. Some of it expresses a deliberate distribution of public authority, rights and responsibilities. A transformation programme needs to understand the distinction.
Continuous Delivery can improve the implementation of an authorised service. It cannot supply the authority to use data or make a decision. Human approval and legal review remain necessary at the boundaries where they protect rights and establish accountability.
For public institutions, the capacity to move safely therefore includes the capacity to demonstrate that a change is lawful. Efficiency gains have to fit within that framework.
The capacity to keep moving
My takeaway from Trust Valley’s second day is an operational one. Integrating AI into our systems creates pressure to move, both to develop capabilities and to maintain effective defences. It also increases the importance of knowing what our systems can access, what they are doing and how we can intervene.
Bugnion established the urgency. The security discussions made the exposure concrete. Schlag’s argument for openness addressed independent scrutiny. Richdale’s convergence perspective widened the horizon. Orjales reminded us that public action rests on legal authority.
The connection I draw between them is the need for an organisation that can keep learning and changing safely after the first deployment. That requires inspectable systems, bounded permissions, continuous evaluation, reliable updates and accountable decisions.
In a dynamic climbing move, preparation and protection make commitment possible. As AI becomes part of our operational systems, our delivery and governance capabilities must support the movement we intend to make.
The ability to change a system safely is becoming part of the ability to defend it.