As Europe accelerates the adoption of AI across its strategic sectors, one question is becoming increasingly central:
How do we govern AI systems once they no longer simply generate responses, but actively participate in real operational workflows?
This question becomes especially important with agentic AI systems.
An AI agent can call tools, retrieve information, combine multiple sources, interact with business systems, trigger actions, escalate decisions to humans, and operate across several technical environments.
This changes the nature of risk.
It is no longer sufficient to know whether a model was evaluated before deployment. We also need to understand how the system behaves during real execution.
In operational environments, the critical questions become very concrete:
- What action did the AI system attempt?
- Which tool or system was involved?
- Was the action authorised?
- Was the context valid and up to date?
- Was human oversight triggered when necessary?
- Was the action executed, blocked, modified, or escalated?
- Can the decision chain be reconstructed after an incident?
These questions are not theoretical. They directly affect healthcare, finance, industry, public services, energy, transport, and critical infrastructure.
In these sectors, AI adoption will depend not only on model performance, but also on operational trust.
This is precisely the area we are exploring with OBELISK.
OBELISK is being developed as a runtime execution, evidence, and reconstruction layer for high-impact AI systems.
The goal is not to add yet another monitoring tool. The goal is to make execution itself a source of usable evidence.
A trustworthy AI system should not only be evaluated before deployment. It should also produce, during operation, the elements needed to understand, control, and reconstruct what it actually did.
OBELISK is not presented here as an abstract promise.
The project is built around concrete technical primitives:
- execution control before action;
- execution evidence linked to decisions;
- technical traceability of calls, transitions, and outcomes;
- runtime anomaly and drift detection;
- forensic reconstruction of decision chains after incidents;
- separation between observation, authorisation, execution, and proof.
These elements address a real problem: in many AI systems, we may observe logs, but we cannot always clearly reconstruct why an action was produced, in which exact context, with which dependencies, and under which level of control.
The distinction matters.
A log indicates that an event occurred.
An execution proof should help determine whether the action was authorised, contextualised, verifiable, and reconstructible.
This approach can strengthen several practical needs. Traceability becomes more useful when linked to real execution steps. Human oversight becomes more demonstrable when interventions are captured in context. Risk management becomes more effective when based on evidence from real operation. Robustness becomes more measurable when incidents can be reconstructed. Cybersecurity becomes stronger when abnormal behaviour is detected during execution.
This point is particularly critical for AI agents.
An agent may take a micro-decision that appears valid in isolation, while still creating risk through the full workflow sequence. A tool call may be correct. A chain of calls may nevertheless produce drift, unintended actions, or loss of operational control.
This is why Europe may need shared technical practices for execution governance:
- usable execution traces;
- tool-call evidence;
- action authorisation mechanisms;
- runtime anomaly detection;
- causal incident reconstruction;
- human escalation mechanisms;
- monitoring of agentic workflows;
- safe interruption of unverified actions.
The goal is not to slow innovation.
On the contrary, better execution governance can accelerate the transition from AI pilots to real production environments. Companies, SMEs, public administrations, and industrial actors need operational guarantees in order to deploy AI without losing the ability to control its effects.
This directly connects with European priorities around compliance, digital resilience, and technological sovereignty.
The AI Act establishes important requirements regarding risk management, traceability, human oversight, robustness, and cybersecurity.
DORA and NIS2 further reinforce the importance of operational resilience, digital risk management, continuity, incident detection, and response capabilities across critical sectors.
In this context, OBELISK aims to contribute to a broader European discussion:
How do we move from AI that is compliant on paper to AI whose real behaviour can be governed, verified, and improved over time?
What makes this approach verifiable is not marketing language.
It is its ability to produce concrete artefacts:
- an execution trace;
- an authorisation decision;
- evidence of blocking or escalation;
- an incident reconstruction;
- a record of human intervention;
- an analysis of anomalies and drift;
- a link between business workflows, risk levels, and actual system behaviour.
If Europe wants to industrialise AI adoption across its strategic sectors, it cannot focus only on evaluating models. It must also develop the operational layers required to govern their execution.
The question is therefore no longer only:
“Was the system compliant before deployment?”
But also:
“Can we prove, audit, and control what it actually does in production?”
- Tags
- agentic ai AI Governance
- Log in om opmerkingen te posten
Reacties
The direction you describe is both necessary and strategically aligned with the reality of high-impact AI deployment in Europe.
From a cybersecurity and operational governance perspective, I fully agree with the core premise: once AI systems evolve from isolated inference engines into agentic operational actors, governance can no longer stop at model evaluation. Runtime behaviour itself becomes part of the security perimeter.
This changes the nature of accountability.
An AI system capable of invoking tools, interacting with industrial systems, querying sensitive databases, orchestrating workflows, or triggering operational actions is no longer merely “software producing outputs.” It becomes an active participant within critical infrastructures.
In such environments, post-deployment governance is no longer optional. It is foundational.
The challenge is not the existence of the tool itself. The real problem is the absence of such operational governance layers across large portions of the current AI ecosystem.
For decades, software engineering, cybersecurity, and critical systems design have relied on principles that are already well understood:
AI systems should not be exempt from these engineering realities.
If organisations develop foundation models, autonomous agents, orchestration systems, or future generations of cognitive architectures, they carry the same obligation that exists in any mature engineering discipline: systems must be explainable not only conceptually, but operationally.
This includes commenting and documenting model architectures, exposing governance assumptions, identifying datasets and provenance chains, and providing mechanisms allowing independent verification of runtime behaviour.
The issue is therefore not whether operational evidence systems such as OBELISK are “too restrictive.” The issue is that without them, organisations are effectively deploying partially opaque autonomous systems into environments where accountability, resilience, and security are legally and operationally required.
This becomes particularly visible in several concrete scenarios.
In healthcare, an AI orchestration layer may combine patient records, diagnostic models, scheduling systems, and pharmaceutical recommendation engines. A single isolated action may appear valid, while the overall workflow sequence produces unintended escalation risks or treatment inconsistencies. Without runtime reconstruction, investigators may know that an event occurred, yet remain unable to determine why the chain evolved as it did.
In industrial environments, an agent coordinating predictive maintenance across OT infrastructures may trigger a sequence of technically authorised actions which, under abnormal contextual conditions, create cascading operational instability. Traditional logging alone may confirm execution. It may not provide sufficient causal evidence regarding contextual validity, escalation paths, or authorisation boundaries.
In finance or public administration, the inability to reconstruct why a workflow bypassed human validation can rapidly become both a regulatory and institutional liability.
This is precisely why execution evidence matters.
A log confirms occurrence.
Operational evidence establishes contextual legitimacy, authorisation state, escalation history, and reconstructibility.
The distinction is fundamental for European resilience objectives.
The AI Act, DORA, and NIS2 are progressively converging toward a common operational reality: compliance alone is insufficient if institutions cannot demonstrate effective control during live execution.
From a cybersecurity engineering standpoint, this also introduces another essential dimension: trust in the governance layer itself.
If systems such as OBELISK — or their future successors — become part of the execution governance stack for strategic AI infrastructures, then these systems must themselves remain auditable, transparent, and independently verifiable.
We are no longer in 1986.
A modern execution-governance layer for AI should not evolve as a closed and inaccessible black box controlled by a small number of actors. If Europe genuinely seeks technological sovereignty, then the governance infrastructure surrounding AI must itself embody the principles Europe claims to defend:
This is where the open-source dimension becomes strategically critical.
An execution-governance framework intended for critical AI systems should ideally be inspectable, extensible, and reproducible across heterogeneous environments. Public administrations, research institutions, SMEs, industrial operators, and cybersecurity teams must be able to verify not only the AI models, but also the systems responsible for supervising them.
This also has a broader ecosystem implication.
If such tooling were distributed through mainstream Linux ecosystems and open repositories, it would not only strengthen institutional trust. It would also create educational and industrial capacity.
Students, independent researchers, security engineers, hobbyists, and open-source contributors could experiment with operational AI governance directly. Over time, this creates skills, vocations, security culture, and European technical competence at scale.
Historically, many of the most resilient components of modern digital infrastructure emerged precisely because they were observable, modifiable, and collectively improved over time.
Europe should think larger than simple compliance tooling.
The long-term objective should not merely be “AI oversight.”
It should be the emergence of a sovereign operational governance ecosystem for agentic systems:
auditable by design,
resilient by architecture,
and verifiable under real-world conditions.
The strategic question is therefore no longer only whether AI systems are performant.
It is whether Europe can build infrastructures capable of proving — continuously, operationally, and independently — that these systems remain governable after deployment.