Italy’s AI Act Decree Turns AI Governance Into Audit Evidence

Any organization running a high-risk AI system in Italy should now assume that an inspector can examine how that system is tested, and can arrive without warning. Legislative Decree No. 179/2026 gives Italy’s national cybersecurity agency the power to do exactly that, and the questions that follow will be about data, not about model architecture.

The decree was published in the Official Journal on October 8, 2026 and entered into force on October 23, 2026. It is the second step in Italy’s two-step implementation of the EU AI Act, following Law No. 132 of September 23, 2025. IAPP reporter Alessandra Tramonte summarized the new framework, including the designation of AgID as notifying authority and ACN as the main market surveillance authority and single point of contact with EU institutions.

For a CISO or chief compliance officer, the practical meaning is simple. AI governance obligations that lived in policy documents now have named enforcers with investigative powers. Those enforcers will ask what data an AI system touched, who authorized it, and whether you can prove it. That is an AI data governance problem before it is a model problem, and it is the reason this decree matters to anyone who exchanges sensitive content with AI systems.

Key Takeaways

1. Italy now has named AI Act enforcers.

AgID acts as notifying authority for conformity assessment bodies, and ACN acts as the main market surveillance authority and single point of contact with EU institutions.

2. Inspections can happen without prior notice.

ACN may inspect real-world testing of high-risk AI systems remotely or on site, and it is not required to announce the visit in advance.

3. The decree designates authorities and procedures.

It does not create new AI Act obligations, so the substantive duties still come from the AI Act itself and from Italian Law 132.

4. Several details remain open.

Implementing acts without deadlines, a sandbox group that is not yet set up, and the EU Digital Omnibus timeline mean the full picture will keep shifting.

5. Evidence quality decides audit outcomes.

Regulators regulate data, not models, so the organizations that can show who accessed what data, under whose authority, and with what record will move through inspections fastest.

What Legislative Decree No. 179/2026 Establishes

Italy chose to implement the EU AI Act in two steps. The first step was Law No. 132 of September 23, 2025, published in Gazzetta Ufficiale no. 223 on September 25, 2025 and in force from October 10, 2025. That law set national principles and delegated the government to adopt implementing decrees. The second step is Legislative Decree No. 179 of October 7, 2026, adopted under the delegation in Article 24 of Law 132.

The decree runs to 54 articles. According to the consolidated text on Normattiva, it appeared in the General Series of the Gazzetta Ufficiale as number 234 on October 8, 2026, and took effect fifteen days later on October 23, 2026. A separate decree on police use of AI, Legislative Decree No. 160/2026, entered into force on September 30, 2026, so Italy’s AI framework is arriving in pieces rather than in a single act.

It helps to be precise about what this decree is. It is an institutional and procedural instrument. It assigns who supervises, who notifies, who inspects, who sanctions, and how complaints are handled. It does not rewrite the duties that the AI Act places on providers and deployers. A compliance team that reads the decree as a new rulebook for AI systems will misjudge it. A compliance team that reads it as the moment national enforcement became real will judge it correctly.

That distinction matters for planning. Your obligations around high-risk systems, transparency, and human oversight still trace back to the AI Act. What changed on October 23 is that Italian authorities now have defined roles and powers to test whether you are meeting them.

Who Holds the Authority, AgID and ACN

The decree splits supervision across two principal bodies, and understanding the split tells you who will ask which questions.

The Agency for Digital Italy, known as AgID, is the notifying authority. Under Article 4 it handles the designation of conformity assessment bodies, the organizations that check high-risk AI systems against the AI Act. Article 13 gives AgID a monitoring role over those bodies. AgID can restrict, suspend, or withdraw a designation, which means a conformity assessment body that cuts corners can lose its standing. For providers, that raises the quality bar on the assessments they buy, because a certificate from a body that later loses its designation is a weaker asset.

The National Cybersecurity Agency, known as ACN, is the market surveillance authority under Article 5 and the single point of contact with EU institutions under Article 6. That is a substantial grant of power to a cybersecurity body. As the analysis from NicFab lays out, the choice places AI supervision close to Italy’s cyber resilience apparatus, which already works with operators of essential services under the NIS 2 Directive.

Sector supervisors keep a role. Article 17 involves the Bank of Italy, CONSOB, and IVASS for financial institutions, so a bank or insurer can expect its existing supervisor to stay in the picture. The privacy regulator, the Garante, is limited to the scope of Article 74(8) of the AI Act under Article 5(1)(c) of the decree. In other words, the Garante keeps a defined lane rather than becoming the general AI enforcer.

For a multinational, this means one Italian entry point for most AI Act questions, with sector supervisors layered on for regulated industries. Organizations already working through GDPR programs will recognize the pattern of a lead authority plus specialist regulators, and should map each relationship before an inspection rather than during one.

Inspections Without Notice and What They Examine

The most consequential provision for operators is Article 15. It gives ACN the power to carry out inspections remotely or on site, including without prior notice, and it extends that power to checks on real-world testing of high-risk AI systems. The decree builds on Article 24(2)(m) of Law 132, which already set out that inspection power in the delegation. Article 15(3) leaves the detailed modalities to a decree of the Presidency of the Council of Ministers, adopted on ACN’s proposal, so the procedural specifics are still to come.

Think about what a no-notice inspection of real-world testing means in practice. Real-world testing involves live data, often personal data, flowing through a system that has not yet been placed on the market. An inspector examining that testing wants to see the test plan, the data used, the safeguards applied, and the records that prove those safeguards worked. There will be no week of preparation to assemble that evidence. The records either exist and are retrievable, or they do not.

Other articles define how proceedings start. Article 16 sets out the triggers for proceedings, and Article 18 provides a complaints channel, which means an affected person can prompt scrutiny without waiting for ACN to act on its own. Article 14 adds a registration duty handled by ACN for high-risk systems used in critical infrastructure, those falling under point 2 of Annex III to the AI Act. Critical infrastructure operators therefore face both a national registry and inspection powers over the testing of those same systems.

The pattern across these articles is consistent. The decree gives authorities the means to ask questions quickly, at the moment evidence is fresh. Organizations that depend on assembling audit evidence after the fact will find that model difficult.

Penalties and the Money Behind Enforcement

Article 23 sets the penalty ceilings. It reproduces the maximums in Article 99 of the AI Act, which reach EUR 35 million or 7 percent of worldwide annual turnover for the most serious breaches, EUR 15 million for the next tier, and EUR 7.5 million for supplying incorrect information. The decree then adds a national band of its own, a lower penalty of EUR 1 million or 0.5 percent of turnover tied to the obligations in Articles 27 and 86 of the AI Act. Those cover fundamental rights impact assessments for certain deployers and the right to an explanation of individual decision making.

The funding design is worth noticing. Proceeds of fines imposed by ACN and AgID are prioritized to those agencies. An enforcement body that funds itself in part from its own penalties has a structural reason to build inspection capacity. At the same time, Article 54 states financial neutrality, meaning no new public spending, which the Garante flagged as being in tension with Article 70(3) of the AI Act, the requirement that national authorities have adequate resources. Whether ACN and AgID will be staffed to inspect at scale is therefore an open question.

One point deserves care. The decree contains no clause stating when its penalties take effect, and it does not mention Regulation (EU) 2026/1744, the EU Digital Omnibus on AI. Anyone telling you precisely when fines start to bite is filling a gap in the text with an assumption. The prudent reading is that the institutional powers are live from October 23, 2026, and that the timing of sanctions for specific obligations depends on the underlying AI Act dates.

What Remains Unsettled

Several pieces of the framework are not finished, and a readiness plan should account for them.

The regulatory sandbox provisions in Articles 26 to 31 describe a Joint Operating Group that has not yet been set up, and the decree sets no deadline for doing so. Several implementing acts, including the modalities for inspections of real-world testing, also have no deadline. Article 41 declares void employment decisions made solely by automated means, and consent is not an exception, which is a stricter national position that employers using automated screening or scheduling should read closely.

The larger moving part sits at EU level. Regulation (EU) 2026/1744, the Digital Omnibus on AI, was published in the Official Journal on July 24, 2026 and entered into force on July 27, 2026. Cooley’s analysis describes how it delays key AI Act deadlines. The high-risk obligations for Annex III systems move to December 2, 2027, and those for Annex I systems move to August 2, 2028, while the Article 50 transparency requirements apply from August 2, 2026.

These dates change the pacing of substantive obligations, but they do not erase the institutional change in Italy. Authorities exist, inspection powers exist, and real-world testing of high-risk systems can occur before the high-risk obligations formally apply to systems on the market. Treat the delay as time to build evidence capability, not as permission to wait. Sources that still cite a high-risk deadline in August 2026 predate the Omnibus and should not guide your planning.

Why Regulators Regulate Data, Not Models

Executives often picture AI regulation as scrutiny of algorithms. An inspector sitting in your office will ask different questions. They will ask what personal and sensitive data entered the system, who approved that access, whether the access matched the stated purpose, and what record proves it. A model is hard to inspect from the outside. The data trail around it is not.

That is why zero trust principles for generative AI translate so directly into audit readiness. An AI system is, from a control perspective, another actor requesting data. It needs an identity, a defined scope, an authorization decision per request, and a record of what happened. Organizations that already enforce those controls for people and applications extend them to AI at modest cost. Organizations that let AI tools pull from file shares, email archives, and repositories through broad service accounts discover that they cannot answer the inspector’s first question.

The same logic explains why the decree’s focus on real-world testing is significant. Testing is the phase in which teams are most tempted to move fast with real data and loose controls, since the system is not yet in production. It is also the phase an Italian inspector can now examine without notice. The control environment around test data must meet the same standard as production, and the evidence must be just as retrievable.

Data protection and AI governance also converge in practice. A zero trust approach to AI data privacy already requires minimization, purpose limitation, and access logging, which are the same artifacts an AI Act inspection would request. A company that has done this work for GDPR is closer to ready than it may think. A company that treats AI as outside its data governance program is not.

How the Decree Lands for Different Roles

The decree does not hit every organization the same way, and a useful readiness conversation starts by asking where your company sits. The three scenarios below are illustrative, not drawn from any specific case.

Consider a provider that builds a high-risk AI system for use in critical infrastructure. This organization faces the most direct exposure. Its system may need to be registered with ACN under Article 14, its conformity assessment body is subject to AgID monitoring, and any real-world testing is open to inspection. The provider needs test records, data governance documentation, and a defensible account of how it chose and supervised its assessment body.

Consider next a deployer, for example a bank using an AI tool to support credit decisions. Here the Bank of Italy or CONSOB may be the relevant supervisor under Article 17, and the bank’s existing supervisory relationship shapes the conversation. The questions will center on how the bank controls the data the tool consumes, how it supervises outputs, and whether its records show a human accountable for each decision path. A bank that already meets demanding ICT and third-party evidence expectations has a head start, provided those records extend to the AI tool.

Consider finally an employer that uses automated screening or scheduling. Article 41 declares void employment decisions made solely by automated means, and it states that consent does not cure the problem. That is a strict national rule, and it makes human review in the workflow a legal requirement rather than a courtesy. An employer in this position should verify that a person with real authority reviews each decision, and should keep records proving it. The audit trail for such review is itself a data governance artifact.

In all three scenarios the same foundation applies. Know which data your AI systems reach, tie each access to an accountable person, and keep a record that stands up when someone else examines it.

Why Evidence Quality Matters More Than Policy Volume

Many compliance programs measure progress by the number of policies written. Inspection regimes measure it differently. An inspector reading a well drafted AI policy will ask the obvious next question, which is how you know the policy was followed. The answer lives in operational records, not in the policy.

This gap between written policy and operational proof is where most organizations are exposed. A policy may say that AI tools may access only approved repositories, yet the technical configuration allows broad access through a shared credential. A policy may say that sensitive data requires human approval, yet no system records who approved what. When an inspector tests the claim against the record, the gap becomes a finding.

Closing the gap requires controls that enforce policy automatically and record the enforcement decision. When access rules are applied by the system at each request, the log shows both the rule and its application, and the policy stops being aspirational. This is the logic behind policy-driven data governance, where the Data Policy Engine approach applies rules to content exchange consistently and leaves a record of each decision.

It also changes the economics of audit preparation. If evidence is a byproduct of normal operation, an inspection request becomes a retrieval task. If evidence must be reconstructed from scattered systems, each inspection becomes a project. With no-notice powers now in place in Italy, the difference between those two states is the difference between a calm afternoon and a crisis.

The Evidence an Inspector Will Ask For

If an ACN inspector asked to review a high-risk AI system’s testing today, the request would likely resolve into a small set of evidence categories. Preparing these in advance converts a stressful inspection into a routine document exchange.

• Identity of the actor. Which AI system, agent, or integration accessed data, and which human or business owner authorized it.
• Scope of access. Which repositories, folders, and records the system could reach, and which it reached, with the policy that allowed each operation.
• Data classification. Whether personal, confidential, or regulated content was involved, and how the system treated it.
• Chain of custody. A record showing what happened to the data after the AI system touched it, including any onward sharing. A documented chain of custody turns this from a reconstruction exercise into a lookup.
• Tamper evidence. Proof that the logs themselves were not altered after the fact. Logs an administrator can edit carry little weight with an inspector.
• Incident handling. How anomalies were detected and escalated, supported by an incident response process that covers AI-related events.

Most organizations can produce some of these artifacts for people and applications, but far fewer can produce them for AI systems, and fewer still can produce them in a unified form. Evidence scattered across the AI platform, the file system, the identity provider, and a SIEM must be stitched together by hand, and stitching takes days. A no-notice inspection does not allow days.

Quality matters as much as completeness. A unified audit log that records each operation with the identity, policy decision, and outcome is stronger evidence than a collection of platform-specific records that disagree on timestamps and naming. Inspectors reward evidence they can verify and that tells a consistent story. They discount evidence that arrives late, incomplete, or in conflicting formats.

Where AI Agents Fit in the Same Controls

AI agents add a wrinkle. An agent can chain actions, call tools, and pull data across systems faster than a person can review each step. The right response is not a separate and looser regime for agents. Agents should be governed alongside human users, under the same identity, authorization, and audit model, with the added rule that every agent action traces to an accountable human.

That principle fits how the Model Context Protocol, or MCP, is being adopted. MCP connects AI assistants to enterprise data sources and tools, which is useful and also creates a new path to sensitive content. Without controls, an MCP integration can become a way for an assistant to read content that the requesting user should never see. The Kiteworks Secure MCP Server addresses that path by applying role-based and attribute-based access control and OAuth authentication to MCP requests, with each request logged in the Kiteworks control plane.

Human parity is the test worth applying to every agent deployment. If a human employee could not open a file, the agent acting for that employee should not be able to either. If a human action would be logged with identity and timestamp, so should the agent’s. If a human needs a documented business reason to export a record, the agent needs the same. Under this model an inspector asking about an agent’s data access gets the same kind of answer as an inspector asking about an employee’s.

This approach also contains the compliance cost of agent adoption. Rather than building a bespoke control framework for each new AI tool, security teams extend the existing data layer controls, using role-based access control and attribute-based access control, to cover a new class of requester.

How Kiteworks Supports Audit Readiness for AI Data Access

Kiteworks does not hold an EU AI Act certification, and no vendor can make an organization compliant with the decree. What Kiteworks provides is control over and evidence of how AI systems access sensitive content, the layer inspectors will probe.

Kiteworks Compliant AI governs AI access at the data layer. Each AI request is authenticated through OAuth 2.0 with an identity linked to the human who authorized it, so accountability does not dissolve into a shared service account. Attribute-based access control is evaluated at the operation level, which means the policy decision applies to what the system is trying to do with a specific piece of content, not just to whether it may connect at all. Content is protected with FIPS 140-3 validated encryption, and activity is recorded in a tamper-evident audit trail that can be streamed to a SIEM for correlation with other security events. Learn more about FIPS 140-3 compliance and how it applies to data protection.

Mapped against the evidence categories above, this design helps demonstrate identity of the actor, scope of access, and operation-level decisions through a single record. The tamper-evident trail supports the evidence-integrity question, and the SIEM integration supports the incident handling question. Because the control sits on the data exchange path rather than inside a single AI product, the same record can cover multiple AI tools, which matters when your organization uses more than one.

Organizations in financial services, where the Bank of Italy, CONSOB, and IVASS keep a supervisory role under the decree, will find that DORA and similar frameworks already demand strong third-party and ICT evidence. A common data layer for AI access lets one set of records serve several regulators. Public sector bodies deploying AI can apply the same approach to the data exchange side of that work.

The honest limit is that product controls do not replace governance decisions. You must still classify your AI systems, decide which are high-risk, define permitted purposes, and assign owners. Technology makes those decisions enforceable and provable. It cannot make them for you.

A Practical Readiness Plan for CISOs and CCOs

A decree that takes effect while key implementing acts remain unwritten rewards organizations that prepare for the likely shape of scrutiny rather than waiting for every detail. The following sequence works regardless of how the open questions resolve.

1. Inventory AI systems and their data paths. List every AI system, agent, and integration in use or in testing, including those introduced by individual business units. For each, record what data it can reach and through what route.
2. Classify against the AI Act. Determine which systems may be high-risk, including those in critical infrastructure under Annex III point 2, since those carry a national registration duty through ACN under Article 14.
3. Bind every AI actor to an accountable human. Replace shared service accounts with identities linked to a named authorizer, so each action traces to someone who can explain it.
4. Move access decisions to the data layer. Enforce policy on each operation against sensitive content, not only at the application boundary, and apply the same policy to agents and humans.
5. Unify the audit trail. Route AI access records into one tamper-evident log, and stream it to your SIEM so inspectors and your own responders see the same record.
6. Rehearse a no-notice request. Run a tabletop in which an inspector asks for the testing evidence of one high-risk system within a day. Measure how long it takes and fix the gaps the exercise exposes.
7. Map regulators and track the open items. Document which authority or sector supervisor applies, and watch for the inspection modalities decree, the sandbox group, and any Omnibus guidance.

For organizations that move data across borders, a data sovereignty review belongs in step one, because AI testing that sends Italian data to a model hosted elsewhere raises both AI Act and transfer questions.

Italy has made AI enforcement a matter of named authorities, inspection powers, and penalties, and the evidence they will want sits in your data layer. To see how a unified, tamper-evident record of AI data access can support your readiness, schedule a demo with Kiteworks.

Additional Resources

• Blog Post
  Zero‑Trust Strategies for Affordable AI Privacy Protection
• Blog Post
  How 77% of Organizations Are Failing at AI Data Security
• eBook
  AI Governance Gap: Why 91% of Small Companies Are Playing Russian Roulette with Data Security in 2025
• Blog Post
  There’s No “–dangerously-skip-permissions” for Your Data
• Blog Post
  Regulators Are Done Asking Whether You Have an AI Policy. They Want Proof It Works.