A Novel Initiative to Simplify AI Act Implementation Without Amending the Regulation

Your point on mechanisms such as ALF (Algorithmic Logic Fingerprints) and CVID is particularly relevant, especially in how they bring compliance closer to the execution layer.

A major difficulty in implementing the AI Act does not lie in understanding the requirements, but in translating them into technically verifiable mechanisms in production.
There is currently a structural gap between documented behaviour and actual system behaviour at runtime.

This can be expressed simply:

compliance often resembles a flight certification validated before take-off,
without any real in-flight monitoring, maintenance tracking, or incident visibility

However, in critical systems, safety depends precisely on the ability to observe, trace, and analyse behaviour after deployment, not only before.

In this context, we are currently developing a complementary layer designed to introduce runtime verifiability and proof.
It is based on:

• deterministic replay of decisions
• append-only logs acting as a verifiable chain of evidence
• continuous behavioural observation
• precise reconstruction of the decision state at the exact moment of execution

This enables a shift from a model based on documentation and pre-deployment validation
to a model based on continuous proof and operational observability.

In other words, no longer just describing what the system is supposed to do,
but demonstrating what it actually did — at any point in time.

This approach directly aligns with key regulatory expectations, where systems must ensure traceability, logging, and post-deployment monitoring across their lifecycle

It also opens the door to:

• predictive maintenance, by detecting behavioural drift before it becomes critical
• continuous system improvement, by transforming execution traces into actionable data
• innovation acceleration, grounded in real-world system behaviour rather than static assumptions

In this perspective, compliance is no longer a constraint, but becomes a driver of resilience and innovation.

Ultimately, the objective is not only to demonstrate that:

“the system is compliant before deployment”

but to be able to state:

“this is exactly what the system did, when, and why and it can be proven”

This represents a shift from static compliance
to dynamic, operational, and continuously verifiable assurance.

Do you think mechanisms such as ALF or CVID could evolve to explicitly integrate this dimension of continuous runtime proof, while also supporting predictive maintenance and system improvement?

Thank you. I agree that continuous runtime proof is essential, particularly because documented or pre-deployment behaviour may diverge from the behaviour of the deployed system.

ALF can directly support this dimension. A Runtime ALF may identify the effective model, weights, inference graph, retrieval sources, tools, memory state, policy configuration and relevant runtime code involved in a particular decision. When that fingerprint is bound to the candidate act, validation predicates and protected execution evidence, it becomes possible to establish not only what the system was expected to do, but which concrete computational configuration actually produced the act.

I would, however, distinguish two complementary layers.

Your proposed approach primarily provides operational observability, reconstruction and post-execution proof. The execution-finality architecture adds a separate pre-effectuation control: a consequential act remains technically non-effective until the relevant authority and compliance predicates are validated at the finality boundary.

The resulting structure could therefore be:

1. continuous behavioural observation and append-only evidence capture;
2. Runtime ALF and decision-state commitments identifying the exact execution configuration;
3. protected validation evidence showing which predicates were satisfied;
4. pre-effectuation verification before the act becomes externally effective; and
5. subsequent reconstruction, audit, drift analysis and predictive-maintenance use.

One qualification concerns deterministic replay. In distributed, adaptive or partly nondeterministic AI systems, exact replay may not always be technically achievable. In those cases, the stronger formulation may be precise reconstruction of the committed decision state and validation context, rather than assuming that the entire execution can always be reproduced identically.

CVID could also incorporate this evidentiary dimension, although its role is narrower. It could bind a communication or service-discovery interaction to its permitted query, purpose, destination, consent state and execution record. ALF is more directly suited to model and decision-state provenance, while CVID is more suited to scoped identity, communication authority and purpose-bound interaction.

Predictive maintenance and system improvement can then be derived from these trusted execution records, for example by detecting drift, repeated validation failures, abnormal decision pathways or changes in runtime fingerprints. I would treat those as valuable secondary uses of the evidence layer, while keeping the primary compliance guarantee fail-closed and pre-effectuation.

So yes, I see continuous runtime proof as highly complementary—but the strongest architecture would combine proof of what happened with technical control over whether the consequential act was permitted to happen at all.