</AI> Protocol FAQ: questions and answers about the framework

When organisations talk about supervised artificial intelligence, most declare that human oversight is in place. The challenge, in practice, is not declaring it. The challenge is demonstrating it in a way that is verifiable, consistent and defensible outside the system that generated the decision.

For this reason we have collected on this page the most frequently asked questions about the THE </AI> PROTOCOL framework, with clear, technical answers oriented towards the operational realities of audit, governance, documentary verification and potential dispute.

---

---

What is the </AI> Protocol?

The </AI> Protocol is an operational framework designed to transform declared human oversight into demonstrable human oversight. The underlying idea is straightforward: saying that a human was “in the loop” is not enough. It must be possible to demonstrate, in a structured way, who was the responsible party, which decision was closed, in what context, with what integrity and at what moment.

The framework is not designed to replace existing governance systems. It is designed to fill a very specific gap: the transition from a declared internal control to an evidentiary unit that is verifiable by third parties.

---

Does the protocol certify that the AI decision was correct?

No. This is one of the most important points to clarify.

The protocol does not certify that the decision-making process was correct, fair, compliant or legitimate on its merits. It does not enter the internal logic of the source system and does not replace legal, ethical or organisational judgment on the process that led to the decision.

Its purpose is different: to create an external, structured and verifiable point that attests that a certain decision unit was received in a defined state, with a specific structure, with specific contextual references and with precise integrity at the moment of intake.

In more direct terms: the system does not promise the substantive truth of the decision, but the verifiable fixation of the declared state at the moment of intake.

---

What problem does it solve compared to standard AI governance?

Traditional governance deals with rules, roles, processes, approvals, responsibilities and internal controls. All of this is necessary. But it is often not enough when a decision is challenged or must be demonstrated outside the system that generated it.

At that point the question changes. It is no longer simply “did a control procedure exist?”. It becomes “can we independently demonstrate what actually happened, who assumed responsibility, what state the decision object was in, and when it entered the chain of custody?”.

The protocol intervenes precisely here, in this space. It does not replace governance. It adds an external evidentiary layer.

---

Is it the same as a vendor-managed registry?

No. The difference is architectural.

A vendor-managed registry typically remains within the trust boundary of the system that produced the decision. In other words, the party that generates the data often also controls the place where that data is recorded, stored, exposed or re-exposed.

The </AI> Protocol, by contrast, is designed as an external evidentiary intake layer. The value is not in saying “trust what the system declares”. The value is in separating the decision from its original environment and fixing it at an external point, with structured and verifiable custody that does not depend on the survival or correctness of the system that produced it.

---

What is the difference between declared and demonstrable oversight?

Declared oversight is a statement. Demonstrable oversight is a structure.

In the first case, it is said that a human reviewed, approved, controlled or closed something. In the second case, there exists a unit in which that responsibility, that context, that temporal reference and that integrity are recorded in a way that can be verified subsequently, even by parties who were not present and have no reason to trust the original system.

The distance between these two conditions is exactly the gap that the protocol sets out to fill.

---

What is meant by “decision context”?

By “decision context” we mean a decision unit that is sufficiently closed and interpretable to enter an external evidentiary chain. It is not a generic file or an arbitrary JSON. It is an object that represents a decision that has matured enough to be taken into custody without ambiguity.

This context may include, for example, the declared identity of the human authority, the decision result, the closure state, the version of the rules applied, the contextual reference, the relevant timestamps and the integrity elements. The goal is not to accumulate as much data as possible, but to fix the minimum structural set necessary to make the unit interpretable and defensible outside the original system.

---

Does the protocol accept processes that are still open or evolving?

No. The framework has been designed precisely to avoid the intake of objects that are still fluid or in the process of elaboration.

The central idea is that the unit must already be closed enough to be received as a submission-ready evidentiary unit. If a process is still open, negotiable, modifiable or not yet ratified, we are not yet looking at a stable object to anchor externally.

This principle is also important to avoid ambiguity, interpretive conflicts and false anchoring points. Closure is not verified on its merits: it is required as an admissibility condition at intake.

---

What is the role of human identity in the protocol?

The identity of the supervisor or human authority is one of the key elements of the framework. Not because the system needs to validate every aspect of the internal process, but because demonstrable oversight requires a declared, recognisable and structured human reference.

In the operational model, identity is connected to the DAPI certificate: a verified identification system that allows the declared responsibility to be associated with a human subject identified consistently over time. This point is essential for distinguishing a simple narrative declaration from a documentable accountability.

The framework does not attempt to reconstruct or certify the internal path of human intervention. It captures the point at which a decision becomes accountable: who assumes responsibility for the outcome at the moment it is declared closed.

---

How are timestamps and temporal references managed?

The framework is built around a rigorous logic of temporal consistency. All references are expressed in UTC, so as to avoid ambiguity, uncontrolled reconversions or discrepancies between different systems.

In particular, the model clearly distinguishes between two separate moments:

• the timestamp declared by the source system, meaning the moment at which the decision is considered closed or ratified in the original context;
• the intake timestamp, meaning the moment at which the unit is received by the external layer and becomes a verifiable custody point.

This distinction is fundamental. The second does not replace the first. But it creates the first externally verifiable custody point, independent of the source system.

---

How is output or decision integrity protected?

Integrity is addressed with a clear technical approach. The goal is to ensure that the received unit can be linked to a verifiable fingerprint, so as to reduce the risk of undetected alterations after intake.

For structured objects, the model applies deterministic normalisation of the payload before hash calculation, to avoid inconsistencies caused, for example, by the simple ordering of keys in a JSON. Two semantically identical payloads must not produce inconsistent results due to formal differences alone.

When the source system provides a declared hash, the framework enforces a clear distinction between the source hash and the intake hash. The two values are not the same thing and must not be confused.

---

What is the intake hash and how does it differ from the source hash?

They are two distinct elements with different functions.

The intake hash is calculated by the system at the moment of receiving the decision unit. It is the authoritative value within the certification workflow: it attests that that structure, at that precise moment, entered the external layer in that form. From that moment forward, any alteration is detectable.

The source hash, when present, is a value declared by the system that generated the decision. If provided, it is compared against the result of the calculation on the received payload: if the two values do not match, the intake is not considered valid and the request is suspended for integration.

The presence of a source hash is not mandatory, but it significantly strengthens the integrity chain, extending the guarantee to cover the pre-intake transit as well.

---

What does “declared closure” mean?

The framework distinguishes between two levels that must not be conflated.

Declared closure is the state communicated by the source system: the decision has been ratified, approved, finalised or closed according to the internal logic of that system. The intake layer does not verify that this condition is substantively true. It treats it as an admissibility prerequisite.

Integrity verification at intake is the responsibility of the external layer: it ensures that the received payload corresponds to what was declared and has not been altered between generation and custody.

These two levels do not replace each other. They serve different purposes and must be kept separate in communication towards third parties as well.

---

Does the protocol only work with ChatGPT, Claude or Gemini?

No. And this is precisely one of its strengths.

The protocol is not designed as a specific integration for a single AI model. It is not tied to a vendor, a platform or a specific brand. It is designed to operate at a different level – downstream of the model – when a decision, an output or a closure of context must be taken into custody and made verifiable.

This approach allows the system to remain system-agnostic and to adapt over time to different scenarios – medical, financial, HR, legal, logistics – without depending on a single proprietary technology or having to rewrite the architecture for each application context.

---

Is an API integration required to use the framework?

No. The platform is accessible directly via browser without any technical integration requirement.

The full operational workflow – from intake creation to FEDIS request, from EVIDE registry publication to evidence chain management – is entirely manageable through the platform’s web interface, accessible to holders of a DAPI certificate.

In a subsequent phase, the model can evolve towards structured intake via API for machine-to-machine integrations. But the central point does not change: the objective remains to create an interpretable, closed and externally verifiable unit.

---

Is it compatible with existing governance frameworks?

Yes. The protocol is not in competition with existing governance frameworks.

Governance defines who can decide, under which rules, with which constraints and through which organisational structures. The </AI> Protocol operates at a different level: it defines what must be captured and made verifiable so that those decisions remain defensible when challenged.

The two layers are complementary. One builds the process. The other makes it demonstrable when that process is contested.

---

Is it compatible with the European AI Act?

The framework is designed in coherence with the principles of the European AI Act, particularly with regard to the traceability of high-impact decisions, verifiable human oversight and defensible documentation.

The AI Act progressively shifts the burden of proof towards those who develop and use AI systems in regulated contexts. It is no longer sufficient to declare that controls exist: it must be possible to demonstrate that those controls were active, documented and reconstructable. The </AI> Protocol is designed to respond precisely to this type of requirement.

---

Can the protocol be useful in audits, reviews or disputes?

Yes, precisely because its primary value is not in the internal narrative of the system, but in the ability to create a verifiable basis for external parties as well.

This can be useful in technical audit scenarios, documentary review, internal accountability, process verification, engagement with control authorities or situations where an automated or semi-automated decision must be explained in a more robust way.

The protocol does not by itself replace legal evaluation or full proof on the merits, but it can become a very strong technical element when it is necessary to demonstrate the state of a decision and its external custody.

---

What type of proof or documentation does the system produce?

The goal is not to produce a simple log or a screenshot to present. The goal is to produce a structured evidentiary unit with sufficient elements to be read, understood and verified outside the original system.

Such a unit includes: the declared identity of the responsible party via DAPI certificate, the SHA-256 hash of the content calculated at the moment of intake, an independent UTC timestamp, a formalised decision state, optional FEDIS certification with CWC code, and publication in the public EVIDE registry with a unique identifier in the format EVIDE-YYYYMMDD-XXXX.

The point is not to accumulate as much data as possible. The point is to fix the right unit with the minimum structural set necessary to make it interpretable and defensible.

---

What happens if the declared authority at closure is later disputed?

If the declared authority at a closure point is later challenged, the system does not attempt to resolve that dispute internally.

What the evidentiary object protects is not the correctness of the authority, but the integrity of the declaration.

In other words, it guarantees that:

• a specific authority was declared
• at a specific moment in time
• under a defined decision state and structure
• and that this declaration has not been altered since

This remains valid even if the authority itself is later challenged.

The structure holds independently, but only at the level of attribution and integrity, not at the level of legitimacy.

If the dispute concerns whether that authority was valid, authorised, or legitimate, resolution necessarily happens outside the system:

• through governance rules
• organizational records
• legal or contractual frameworks

What EVIDE and FEDIS prevent is a different class of failure:

• retroactive rewriting of “who decided”
• ambiguity about when the decision was made
• loss of the structural conditions under which it was declared

In practice, this becomes critical in disputes. Instead of arguing about reconstructed narratives, the discussion shifts to a fixed evidentiary point: what was declared, by whom, and under which conditions, at that specific moment.

At that point, the question is no longer what happened, but whether that declared authority was valid. And that is a legal or governance question, not a technical one.

This distinction is fundamental: the protocol does not resolve authority disputes, but it prevents those disputes from expanding into interpretation of the evidence itself.

---

Does it protect against the risk of post-event log revision?

Yes. This is one of the most concrete values of the framework, often underestimated.

The primary risk in AI systems is not only the gap between the actual decision and its acquisition. The most frequent and operationally relevant risk is post-event revisionism: the possibility that, after an incident or a dispute, internal logs are modified, reconstructed or reformulated in a way that makes supervision appear that was not there, or that conceals what actually happened.

The external layer creates a point of no return: once the decision unit has been acquired with its SHA-256 hash and UTC timestamp, the source system can no longer silently modify what was declared. This guarantee has direct value in audit and dispute proceedings.

---

Does the protocol cover the original moment of the decision?

Not completely, and it is important to say this clearly.

There is always a time gap between the moment a decision is made in the source system and the moment it is acquired by the external layer. The protocol does not eliminate this interval.

What the protocol does is create the first verifiable and independent custody point: from that moment forward, integrity is guaranteed. Before that moment, responsibility remains with the source system and its internal chain of control.

This limitation is declared, not hidden. And it is manageable by combining the external layer with a source hash provided by the originating system, which extends the guarantee to cover the pre-intake transit as well.

---

Who should be interested in this framework?

The framework may be of interest to those working in AI governance, compliance, audit, digital accountability, AI-assisted decision processes, human oversight, technical documentation, risk management and high-impact systems where a simple declaration of human control is no longer sufficient.

It may also be relevant for those building supervision systems who realise that the real challenge is not only organising the process, but making it demonstrable when it is called into question.

---

Is it relevant for law firms and consultants?

Yes, directly.

Those assisting clients exposed to AI governance risks, disputes over automated decisions or regulatory reviews need a technical instrument that translates declared oversight into something structurally verifiable. The protocol responds to exactly this need: it is not a policy document, but an operational layer that produces defensible evidentiary units.

The platform supports multi-organisation management: a law firm can operate with a single DAPI identity across multiple clients, keeping requests, evidence chains and billing separate for each mandate.

For those interested in exploring collaboration, a dedicated section is available: Legal Partners Network.

---

What value does it have for an organisation already using AI?

The primary value is the external defensibility of decisions already taken.

An organisation using AI in its processes may have solid internal governance, documented processes and internal audit trails. But when someone challenges a decision from outside, the value of that documentation depends on whether the challenging party has reason to trust the system that produced it.

The external layer resolves this problem structurally: the decision is no longer defended only with internal logs, but with an independent anchoring point that the source system cannot control or modify retroactively.

---

Evidence chain and multi-organisation management

What is the verifiable evidence chain?

The evidence chain is an operational feature of the EVIDE platform that allows multiple intakes to be linked in sequence, documenting the evolution of content, a decision or a version over time in a verifiable way.

Each intake remains independent and immutable: it has its own SHA-256 hash and its own UTC timestamp. The link to the previous intake is optional and does not modify the integrity of the individual element. The chain is built declaratively, not retroactively.

A typical structure is:

• Intake #1 – original document, first version, initial decision
• Intake #2 – revision, update, integration
• Intake #3 – final version, with optional FEDIS certification and EVIDE publication

In legal proceedings or audits, demonstrating the final decision is not enough. It is often necessary to reconstruct the path: what changes were made, when, and in what order. The EVIDE evidence chain responds precisely to this need.

You are not storing a file. You are documenting professional accountability over time.

---

Does linking intakes affect the integrity of individual elements?

No. This is a fundamental architectural point.

Each intake has its own hash calculated independently at the moment of receipt. The link to the chain is a logical reference that does not modify either the content or the fingerprint of the individual intake.

In practice: if intake #2 declares itself linked to intake #1, this information is recorded in the system but does not alter the hash of either element. Each remains independently verifiable.

This principle is essential to ensure that the chain does not become a point of vulnerability: a contested link does not invalidate the others.

---

In which scenarios is the evidence chain useful?

The evidence chain is useful in all cases where it is necessary to document an evolution over time in a verifiable way:

• Contracts under negotiation: each version is certified, the sequence is reconstructable and unassailable
• Company policies and procedures: subsequent revisions are linked to the original version with a certain date
• AI system outputs: every model update, response change or decision revision is tracked in sequence
• Medical or legal decisions: the decision-making process is documented step by step with identity and timestamp
• Regulatory compliance: versions of policies and procedures are verifiable over time without depending on internal logs
• Document version disputes: the chronological sequence is demonstrable in an independent way

---

Can a professional manage multiple organisations with a single login?

Yes. This is one of the operational features of the platform, designed specifically for lawyers, DPOs, consultants and professional firms managing multiple clients or mandates simultaneously.

The model is based on two distinct levels:

• DAPI – identifies the individual in a unique and verified way. It is personal and non-transferable.
• Organisation – defines the operational perimeter. The same professional can be associated with multiple organisations with different roles.

Concrete examples:

• Lawyer – manages the law firm, three client companies and a public body with a single DAPI login, keeping requests, chains and billing separate for each mandate
• External DPO – operates across twenty organisations as data protection officer, with separate logs and certifications per organisation
• AI governance consultant – certifies outputs and decisions for different clients, with strictly separated operational perimeters
• Professional firm – collaborators operate under the same structure but across distinct client perimeters, with differentiated roles and access levels

Each request originates within a specific organisational perimeter. Requests, chains and certifications always remain separate by organisation.

---

How does billing work in a multi-organisation context?

Billing is associated with the organisation, not the individual user. This reflects the operational reality: the professional acts on behalf of a client, and the cost of certification must be attributed to the correct perimeter.

Each organisation has its own billing record, entered and confirmed by a user with the owner or admin role. Users with the member role can create requests on behalf of the organisation but do not manage billing data.

Before submitting a new certification request, the system verifies that a valid and confirmed billing record exists for the selected organisational perimeter. This block is intentional: it ensures that every request is associated with a clear and verifiable economic perimeter from the outset.

---

What roles exist within an organisation?

The platform provides three distinct roles within each organisation:

• Owner – the organisation’s principal. Manages billing data, can add or remove users and has full operational control. Typically the legal representative or the founding partner of the firm.
• Admin – delegated administrator. Has the same operational powers as the owner over certification management and billing, but is not the formal principal. Typically a trusted collaborator with full operational authority.
• Member – ordinary member. Can create certification requests on behalf of the organisation and view their own requests, but does not manage billing or organisational settings.

The same DAPI user can hold different roles in different organisations: owner in their own firm and member in a client organisation, for example.

---

Context and emerging risks

Do AI agents really represent a risk for organizations?

Over the past few months, the debate around AI agents has intensified, particularly regarding the level of operational access these systems require in order to function effectively.

In many application scenarios, agents can interact with corporate systems, email, documents, calendars, and other sensitive environments. This increases the level of operational autonomy and, as a result, raises exposure to risks related to errors, misuse, or loss of control.

However, the central issue is not simply how much access an AI agent has.

The real problem emerges at the moment a decision is made. At that point, in most systems, no independent and verifiable record exists that would allow a reliable reconstruction of:

• which decision was actually produced;
• what state it was in at the moment of closure;
• who assumed responsibility for its validation;
• what decision context was associated with it.

The current debate focuses primarily on access control and agent autonomy. The </AI> Protocol addresses a different and complementary level: the demonstrability of a decision once it has been considered closed.

In other words, it does not intervene on what an agent can or cannot do, but on what must be demonstrable after the action has been taken.

This distinction is fundamental in audit, accountability, and litigation contexts, where it is not enough to know that a system was under control – it is necessary to be able to demonstrate what actually happened, in a verifiable way, outside the system that generated the decision.

---

Is it better to restrict AI agents or make their decisions verifiable?

In recent months, several initiatives have emerged aimed at limiting the access and behavior of AI agents, for example by defining what content can be accessed, which actions can be performed, and which contexts should remain restricted to human interaction.

This approach is important and addresses a real need: reducing risk before a system acts.

However, there is a second, equally critical problem that these measures do not solve.

At the moment a decision is made, the question changes:

• what exactly was decided;
• in what state the decision was at the moment of closure;
• who assumed responsibility for it;
• whether there is an independent and verifiable record of that event.

Restricting what an agent can do reduces risk ex ante. But it does not eliminate the need to demonstrate ex post what actually happened.

The Protocol operates at this second level. It does not intervene on access control or agent behavior, but on transforming a decision into a verifiable event, with identity, context, integrity, and temporal references.

The two approaches are not alternatives. They are complementary. The first reduces the probability of error or misuse. The second makes it possible to demonstrate, in a defensible way, what occurred once a decision has already been made. In regulated or high-impact contexts, both become necessary.

---

What happens if an AI system behaves unpredictably or becomes misaligned?

In recent months, there has been growing evidence that some AI systems, in real-world contexts, can produce unexpected, misaligned, or difficult-to-interpret behaviors. This includes cases where outputs do not reflect the instructions received, or where the system adopts strategies not anticipated by the governance model.

These scenarios introduce a concrete challenge: it is no longer sufficient to assume that the system will always operate in a predictable or fully controllable way.

In this context, the central question shifts. It is no longer just “how do we prevent the system from behaving incorrectly?”, but rather:

• what was actually decided;
• in what state the decision existed at the moment of closure;
• who assumed responsibility for validating that decision;
• whether an independent and verifiable proof of all this exists.

The Protocol does not aim to make AI systems infallible or to prevent unexpected behavior. Its role is different and complementary: to create an external intake point that makes the decision demonstrable, regardless of the internal behavior of the system that produced it.

In other words, if an AI system generates an output that is unexpected or contested, the protocol allows that decision to be anchored to a verifiable evidentiary unit, including identity, context, integrity, and defined temporal references.

---

Who is responsible if an AI system generates errors or harmful code?

The use of artificial intelligence systems does not transfer responsibility to the tool itself.

In professional contexts, responsibility remains with the human who uses, reviews, or approves the generated output. This applies even when AI produces unexpected, incorrect, or potentially harmful results.

The real challenge, however, is not only identifying responsibility, but proving it in a verifiable way.

In many operational environments, there is no clear trace that allows reconstruction of:

• who validated the output;
• when the decision was made;
• the state of the system at the time of validation;
• whether an independent proof of content integrity exists.

The Protocol addresses this gap. Through a verifiable intake process, each decision is anchored to: a declared human identity via DAPI certificate, an independent UTC timestamp, an immutable SHA-256 hash of the content, and a formalised decision state.

This ensures that even when AI systems behave unpredictably, it is still possible to clearly and defensibly demonstrate who assumed responsibility for the final decision.

---

Does the system prevent false declarations or misuse?

No.

The system is not designed to prevent false declarations, but to make them traceable, verifiable, and attributable over time.

Users can submit and declare content, outputs, or decisions. However, each declaration is anchored to objective elements:

• a declared identity via DAPI certificate;
• an independent UTC timestamp;
• a cryptographic SHA-256 hash of the content;
• a formalised decision state;
• optional FEDIS certification with CWC code.

This means that a declaration cannot be modified or denied later without leaving evidence. If a user makes a false declaration, and other sources demonstrate otherwise, that declaration becomes a liability for the person who made it.

In other words, the system does not prevent misuse, but makes it traceable and risky. An unverifiable statement can be ignored. A recorded, identified, and time-anchored declaration can be examined, compared, and challenged.

This shifts the question from “Can I declare anything?” to “Can I defend this declaration over time, under independent scrutiny?”

---

Where is the project right now?

The conceptual and technical framework is defined and publicly documented. The application platform is operational and accessible to holders of a DAPI certificate.

The active workflow includes:

• Evidentiary intake with SHA-256 hash and UTC timestamp for FILE, ZIP, URL and TEXT
• FEDIS request and management with approval and quote workflow
• Publication in the public EVIDE registry with unique identifier
• Verifiable evidence chains between linked intakes
• Multi-organisation management with separate operational perimeters
• Billing per organisation with owner, admin and member roles
• Public registry accessible without authentication

Access the platform

Try the interactive demo

---

Where can I find more information?

For a general overview of the project and the logic of supervised AI, the following pages are available:

→ The </AI> Protocol
→ Evidentiary Layer in AI Governance
→ Real Cases: AI Governance and Verifiable Responsibility
→ Legal Partners Network
→ EVIDE – Evidentiary registry for digital content and decisions