Draft Decree No. 418 marks the next operational phase of Italy’s AI framework — and the precise wording matters.

In September 2025, Italy adopted Law No. 132/2025, a comprehensive national framework governing the development, deployment and governance of AI. The Italian government described it as the first national regulatory framework of its kind in Europe, fully aligned with the European AI Act.

That does not mean Italy “transposed” the EU AI Act. Regulation (EU) 2024/1689 is a regulation, not a directive. Under Article 288 of the Treaty on the Functioning of the European Union, an EU regulation is binding in its entirety and directly applicable in every Member State. No act of national transposition is required.

What Member States must still do is build the national machinery around the regulation: designate and empower authorities, establish enforcement and procedural rules, use the options left to national law and adapt domestic legislation where necessary.

Italy is now moving into that second phase.

Draft Legislative Decree No. 418 — officially titled a decree adapting national law to Regulation (EU) 2024/1689 in relation to police use of AI and civil and criminal liability — is one of the most concrete examples of what national implementation can look like.

There is an important status warning. As of 19 July 2026, this text is still a draft submitted for parliamentary scrutiny. The Italian Senate’s official record shows that it was presented on 24 June 2026, assigned to the competent committees on 26 June and remains subject to parliamentary opinion. It may still change before final adoption.

A sectoral decree with system-wide consequences

Draft Decree No. 418 is not a general restatement of the AI Act. Its centre of gravity is narrower and more sensitive: police use of artificial intelligence, biometric identification, criminal procedure, civil liability and the production of evidence.

Yet its technical consequences extend far beyond a single model or application. The draft effectively treats the entire data and evidence chain as part of the compliance architecture.

This includes:

• the provenance and lawful acquisition of data;
• the segregation of operational and evidentiary records;
• human review before legally significant effects occur;
• time-bound authorisations and purpose limitations;
• automatic and verifiable deletion;
• non-modifiable logs retained for years;
• the ability to disclose intelligible evidence in court; and
• the reconstruction of how a system behaved at a specific point in time.

The practical lesson is simple: AI compliance cannot live only in model documentation. It must be engineered into the data platform, the application workflow and the operating model.

This shift from legal language to system design is part of a wider European movement from compliance to architecture, also explored in Understanding the EU Tech Sovereignty Package.

Human oversight must be an enforceable workflow

The draft follows an anthropocentric and risk-based approach. AI output is intended to support human decision-making, not silently replace it.

For systems capable of affecting a person’s legal position, “human in the loop” cannot be a label placed on an architecture diagram. The application should be able to prove who reviewed an output, which version was reviewed, what decision was made, why it was made, whether the machine recommendation was overridden and when each transition occurred.

That implies blocking approval gates, role-based access control, segregation of duties and an append-only history of the decision workflow. A reviewer who can simply be bypassed is not effective human oversight.

For agentic systems, this requirement becomes even more important. An agent may plan a sequence of actions, query multiple sources, invoke external tools and update operational state. The relevant evidence surface therefore includes tool calls, retrieved sources, model and configuration identifiers, actions attempted, actions completed, errors and human approvals.

This does not require storing a model’s hidden chain of thought. It requires preserving the observable facts needed to reconstruct the system’s behaviour.

Biometric identification must remain exceptional and targeted

The most sensitive provisions concern biometric identification by law-enforcement authorities.

The draft permits narrowly defined uses but builds them around strict conditions. Reference databases must be appropriate to the operation and populated from lawful sources. Untargeted or unlawful scraping cannot be used to construct biometric databases. Real-time use is tied to judicial authorisation, limited duration and defined purposes, with an urgency procedure subject to subsequent validation.

The system must stop when the legal conditions cease to exist. Data, results and outputs obtained without the required basis may have to be deleted and may become unusable as evidence.

The draft also requires a Fundamental Rights Impact Assessment before real-time biometric systems are used. Negative decisions cannot be based solely on a recognition result, and generalised identification disconnected from a specific offence or proceeding is prohibited.

From an architectural perspective, every biometric operation should therefore be bound to a case, purpose, authority, legal basis and expiry time. Matching capabilities should not become a general-purpose search function merely because the underlying technology makes that convenient.

The seven-day and five-year problem

One of the clearest technical design challenges is the coexistence of two very different retention periods.

For certain local facial-recognition databases, operational biometric and identifying data may be retained for no more than seven days and must be deleted automatically. By contrast, access and operation logs must be non-modifiable and retained for five years.

These are not two settings on the same collection. They are two distinct data classes with different purposes, access rules, legal bases, security controls and lifecycle requirements.

Operational data should expire quickly. Evidentiary logs should survive, remain intelligible and resist alteration. The two should be separated technically and logically.

Automatic expiry mechanisms such as database TTL policies can help, but a TTL index is not an end-to-end deletion strategy. Data may also exist in replicas, backups, caches, search indexes, vector stores, feature stores, data lakes, exports, observability platforms, test environments and support systems.

Deletion must therefore be orchestrated across the full technology chain and accompanied by verifiable evidence that the required lifecycle action occurred.

“Immutable logs” are an evidentiary requirement

The draft’s requirement for non-modifiable logs should not be confused with ordinary database or application logging.

Conventional logs are often rotated, truncated or accessible to privileged administrators. They are useful operational records, but they should not automatically be presented as tamper-proof evidence.

A defensible design may combine database auditing with an append-only or WORM-capable repository, trusted timestamps, integrity controls, restricted access, separation of privileges and legal-hold procedures. The goal is not simply to collect more telemetry. It is to preserve evidence whose integrity, completeness and chain of custody can withstand scrutiny.

This is where data architecture becomes procedural architecture.

Liability changes the value of technical evidence

The civil-liability provisions are potentially as consequential as the police-use rules.

The draft would allow courts to order the disclosure of evidence concerning the operation of an AI system, including logs, risk-management records, technical documentation and evidence of human oversight. Failure to produce relevant material may carry direct procedural consequences.

It also introduces a rebuttable presumption linking certain violations of AI Act obligations to the damage alleged, while making clear that formal conformity with the AI Act is not civil immunity. A certified or nominally compliant system can still cause damage through its actual configuration, data, deployment or operation.

This shifts the question from “Can we show that the product was compliant?” to “Can we reconstruct what this specific system did in this specific case?”

Organisations should therefore design for litigation-ready evidence: versioned configurations, relevant dataset and model identifiers, query and retrieval settings, output records, human interventions, incident history and reproducible exports — all subject, of course, to privacy, security and trade-secret controls.

MongoDB can support the architecture, but it cannot certify the solution

A database is not automatically an “AI system” merely because an AI application uses it. MongoDB will normally be an infrastructure component within a broader solution. Classification depends on the system as a whole, the functions it performs and the roles of the parties involved.

MongoDB can nevertheless support several important controls:

• replica sets and backup strategies for availability;
• role-based access control and network segregation;
• Enterprise auditing and encryption controls;
• schema validation and versioned metadata;
• TTL indexes for time-bound operational data;
• change streams for controlled event processing;
• separate collections or deployments for cases, environments and data classes;
• search and vector-search metadata that records scores, thresholds, index versions and source provenance.

None of these features makes an AI solution compliant by itself. Legal basis, governance, impact assessments, human oversight, operating procedures, contractual allocation of responsibility and evidentiary controls remain solution-level obligations.

The same caution applies to vector similarity. A score is not a legal decision. In sensitive uses, the system should retain the source, query parameters, index configuration, score and threshold, while preventing an adverse decision based exclusively on similarity output.

What organisations should do now

Although the decree is not final, the architectural direction is already clear. Organisations developing or operating sensitive AI systems should begin with eight actions:

1. Inventory the full system, not only the model: data stores, indexes, tools, agents, logs, copies and support environments.
2. Map every data class to a purpose, legal basis, owner, access policy and retention period.
3. Make human approval gates technically enforceable and auditable.
4. Separate short-lived operational data from long-lived evidentiary records.
5. Design deletion across the entire data supply chain, including derived data and embeddings.
6. Export critical audit events to a genuinely tamper-resistant repository.
7. Preserve enough version and configuration context to reproduce material system behaviour.
8. Review legacy and in-flight systems rather than assuming they are grandfathered indefinitely.

From European rules to national enforcement

Italy’s legal trajectory is significant, but the accurate story is more interesting than the simplistic headline.

Italy did not need to transform the EU AI Act into national law. The regulation already applies directly. What Italy did first was adopt a broad national AI framework through Law No. 132/2025. Draft Decree No. 418 now seeks to make part of that framework operational in areas where legal authority, evidence and accountability are particularly sensitive.

If adopted, its most durable impact may be the recognition that trustworthy AI is not only a model-governance problem. It is also a data-lifecycle, workflow, security and evidence problem.

For data-platform and agentic-AI teams, that means compliance must be visible in the architecture — and provable after the system has acted.

This article analyses a draft legislative measure as of 19 July 2026. The text may change before final adoption. It is provided for informational purposes and does not constitute legal advice.