AI Act for Italian Companies: A Practical Compliance Guide

Artificial intelligence is already part of ordinary Italian business operations. A sales team drafts replies with a general purpose AI tool, customer service summarizes calls, a factory predicts maintenance needs, and HR uses software to rank applications. The legal question is no longer whether a company uses AI. It is whether the company knows what it uses, what role it plays, what risk follows, and what evidence it can produce when someone asks.

This guide is written for leaders, compliance owners, product teams, and operations managers in Italian companies. It is practical rather than legal advice. The legal framework is changing, and a company should confirm application dates, sector obligations, and its specific position with qualified counsel. The status described here is current as of September 2026. It distinguishes binding rules from guidance and from implementation details that remain pending.

The legal map in one page

The central instrument is Regulation (EU) 2024/1689, commonly called the EU AI Act. It applies to providers, deployers, importers, distributors, product manufacturers, and other actors whose systems are placed on the Union market, put into service in the Union, or whose output is used in the Union. The official text is available in the EUR-Lex AI Act. It is a directly applicable regulation, although many obligations depend on the system category, actor role, and date.

The 2026 amendment, Regulation (EU) 2026/1744, changes several dates and transitional arrangements, including the timetable for certain high-risk systems. Read the official amendment text together with the consolidated Act and any applicable Commission material. Do not copy an old implementation calendar into a policy. In particular, revised high-risk dates can depend on whether the system is embedded in a regulated product, whether the product approval regime is ready, and which transitional provision applies.

The Commission's regulatory framework for AI is a useful source for implementation information, guidance, codes, standards, and institutional updates. These materials help an organization understand how to comply, but guidance is not the same as a new binding obligation. Codes of practice and harmonized standards can be important routes to demonstrating conformity, but teams should record whether a document is legally binding, voluntary, under development, or simply explanatory.

Italy also has Law 132/2025, in force since 10 October 2025. The Normattiva text is the authoritative place to check the Italian provisions and their wording. The law establishes a national framework and assigns roles and actions to Italian institutions, while interacting with the directly applicable EU Act. It does not turn every operational detail into a completed Italian decree. Some institutional, technical, and sector implementation work is still developing. A responsible Italian policy should say what is already required, what is a prudent control, and what is awaiting a competent authority or further guidance.

Dates, duties, and what changed in 2026

The AI Act is phased. Prohibitions and AI literacy duties became relevant before the full high-risk regime. Transparency requirements and governance duties have their own dates, while high-risk obligations have transitional rules. Regulation 2026/1744 revises the dates for some high-risk systems, so the question for a system owner is not simply, 'Is the Act in force?' Ask instead, 'Which provision applies to this system, in which role, on which date, and with which transition?'

A transition register should contain the original date, the amended date, the trigger for the date, the source link, the accountable owner, and the action needed. Mark dates as binding where they come from the Regulation or amendment. Mark Commission guidance, voluntary codes, standards, and internal target dates separately. This simple discipline prevents a common failure mode: treating a helpful summary page as though it were the legal text, or treating a future proposal as current law.

Start with an AI inventory, not a policy document

A policy drafted before discovery usually describes an imaginary company. Start with an inventory that is broad enough to include purchased software, experiments, embedded features, APIs, browser tools, open source models, spreadsheets with AI add-ons, and uses that employees created without procurement approval. Ask every function to list the tool, the business purpose, the users, the data, the supplier, the model or feature, the countries involved, and whether output affects a person, a product, a safety decision, or a legal obligation.

• Identify the system and feature, including model version, interface, API, plug-ins, agents, retrieval sources, and connected actions.
• Record the provider, reseller, importer, distributor, hosting location, contract owner, support channel, and sub-processors where known.
• Describe the purpose in operational terms, such as ranking candidates, approving credit, forecasting demand, answering customers, or drafting marketing copy.
• Map input data and output recipients. Flag personal data, special category data, confidential information, trade secrets, financial data, children’s data, and safety relevant information.
• Record human decisions around the system. Note who reviews, who can override, who is accountable, what happens when confidence is low, and whether the system can act automatically.
• Capture lifecycle status, affected population, countries, sector, incidents, known limitations, monitoring metrics, and the planned retirement date.

Do not wait for perfect technical discovery. Give each entry an owner and a confidence rating. A procurement invoice may prove that a tool exists even when nobody knows the model version. That is a finding to resolve, not a reason to omit the tool. Reconcile the inventory with identity and access records, software asset management, cloud bills, data processing registers, security questionnaires, product roadmaps, and expense reports.

Map roles before assigning controls

The same company can have several AI Act roles. A company building a customer-facing assistant may be a provider for the assistant it places on the market, a deployer of a foundation model obtained from another company, and an importer or distributor for a device containing an AI component. Role mapping should be done system by system, not once at company level.

• Provider: the actor that develops an AI system or general purpose AI model and places it on the market or puts it into service under its name or trademark. A substantial modification can change the analysis.
• Deployer: an organization or person using an AI system under its authority, except for personal nonprofessional use. Most internal business users are deployers, even when the system is bought as a finished SaaS product.
• Importer: an actor established in the Union that places a system from a third country on the Union market. Distribution and contractual arrangements matter.
• Distributor: an actor in the supply chain other than the provider or importer that makes a system available in the Union.
• Product manufacturer: a manufacturer that places an AI system together with a product under its name or trademark, or puts both into service as a product covered by relevant Union legislation.
• Employer and operator: a company may have additional duties when AI is used in employment, workplace management, access to work, or worker monitoring. Check the Act, Italian employment rules, collective arrangements, privacy law, and sector requirements together.

A vendor contract does not transfer every responsibility. A SaaS provider may be the provider of its system, while the Italian customer remains the deployer responsible for lawful use, instructions, human oversight, monitoring, and records within its control. Make the role conclusion explicit in the inventory and have legal, compliance, procurement, security, and product owners sign off on unusual cases.

Prohibited practices require an immediate gate

The first substantive review is not a risk score. It is a prohibited-practice screen under Article 5. The Act prohibits specified AI practices, including certain manipulative or deceptive techniques, exploitation of vulnerabilities, social scoring, and some forms of biometric categorization or emotion inference. The details and exceptions matter. Do not rely on a marketing description such as 'wellbeing analytics' or 'fraud prevention' to decide that a use is safe.

Create a launch and change gate with plain questions: Does the system influence behavior through subliminal or manipulative techniques? Does it exploit age, disability, or a social or economic situation? Does it evaluate people over time to produce unjustified detrimental treatment? Does it infer sensitive attributes or emotions in a prohibited context? Does it use biometric identification or categorization in a restricted setting? If the answer is uncertain, pause deployment and escalate. A prohibited use cannot be rescued by adding a human reviewer or a disclaimer.

AI literacy is already an operating requirement

Article 4 requires providers and deployers to take measures to ensure, to the best of their ability, a sufficient level of AI literacy for staff and other persons operating or using AI on their behalf. This is not satisfied by sending a generic slide deck once a year. Training should match the system and the person's role. A customer service user needs instruction on fabricated answers, disclosure, escalation, and personal data. A product engineer needs model evaluation, security, documentation, and release controls. A manager needs accountability and the limits of automation.

Keep a training matrix that records role, system, learning objective, delivery date, assessment, refresher trigger, and evidence. Include contractors and temporary staff where they operate systems on the company's behalf. Track practical competence with short scenarios, such as identifying a prompt injection, refusing to paste a payroll export into an unapproved tool, challenging a biased recommendation, or reporting an unexpected autonomous action.

Transparency and Article 50 in daily work

Transparency duties depend on the use and system. Article 50 addresses, among other things, informing people when they interact with certain AI systems, making machine generated or manipulated content identifiable in specified situations, and disclosing certain generated or manipulated content. The exact scope, exceptions, technical feasibility, and date must be checked against the current legal text and implementation material. Do not reduce Article 50 to a single label placed on every AI output.

For a customer assistant, tell the person at the point of interaction that they are communicating with an AI system, unless a reasonable person would already understand it from the context or another exception applies. For generated content, define when provenance metadata, a visible notice, or an internal record is appropriate. For synthetic audio, images, or video, create a review before publication, especially where the material could mislead. Keep a record of the notice language, trigger, owner, localization, and accessibility review.

Transparency is also a design issue. A disclaimer hidden in terms and conditions is often a poor user experience and weak evidence of meaningful notice. Put the information where the decision or interaction occurs, use clear language, and make it possible for a person to ask for human assistance. Coordinate AI Act notices with GDPR information duties, consumer law, advertising rules, intellectual property controls, and Italian language expectations.

Classify high-risk systems by function and context

High-risk classification is one of the areas where shortcuts create expensive mistakes. The Act uses categories and conditions, including AI systems that are safety components of products covered by listed Union legislation and systems listed in Annex III. A system used for hiring, worker management, access to essential services, creditworthiness, law enforcement, migration, justice, or democratic processes may be high risk when the applicable conditions are met. A general purpose model used to draft an email is not automatically high risk merely because the model is powerful.

Use a documented decision tree. First identify whether the system is prohibited, a safety component, an Annex III use, a general purpose AI model, a transparency use, or outside the Act's scope. Then test the relevant exclusions and carve-outs. Record the intended purpose, actual use, affected people, autonomy, impact, and connection to a regulated product. Revisit classification after a material change, new data source, new user population, new geography, or new downstream action.

If a system is high risk, build the control plan around the applicable obligations rather than waiting for a certificate. Depending on the role and system, this can include a risk management system, data and data governance, technical documentation, records and logging, transparency and instructions, human oversight, accuracy, robustness, cybersecurity, quality management, conformity assessment, registration, post-market monitoring, and incident reporting. The revised high-risk timetable under Regulation 2026/1744 makes the date field especially important.

Data governance, logging, and human oversight

Data governance is more than checking whether a dataset has a lawful source. Document the purpose, provenance, relevance, representativeness, labeling method, preprocessing, known gaps, protected groups, retention, access, and quality tests. For an Italian company, include language and geography in the assessment. A model may perform well in English and poorly on Italian names, dialects, invoices, addresses, or industry terminology. Test the failure modes that matter to the business, not only a generic benchmark.

Logging should make a meaningful reconstruction possible. Depending on the system, capture the timestamp, version, input reference or data source, output, confidence or signal, user, action taken, override, policy result, and incident link. Minimize personal data in logs, limit access, set retention periods, and prevent silent overwriting. A log that records only 'model ran successfully' is rarely enough to investigate an incorrect customer decision.

Human oversight must be real. Name the person or team, define what they can see, give them enough time and authority to override, and measure whether overrides are possible in practice. Do not appoint a reviewer who lacks the domain knowledge or is pressured to approve every recommendation. For high impact uses, define automatic stops, dual review, escalation thresholds, and a route for the affected person to obtain a human explanation or correction where applicable.

Third party GPAI tools need a company boundary

General purpose AI tools are not low risk simply because they are sold as productivity software. An Italian company using a third party GPAI chatbot is usually a deployer of the tool and may be a provider if it builds and markets a system on top of it, substantially modifies it, or puts a branded system into service. The upstream provider has its own GPAI obligations, but the customer still controls prompts, data, access, use cases, and downstream decisions.

Set an approved tool catalogue with permitted data classes, blocked activities, retention settings, account ownership, identity controls, administrator rights, model training choices, and export rules. Separate public chat, enterprise workspace, API, and embedded product terms. An employee's assertion that a tool does not train on data is not a substitute for checking the contract and configuration.

• Require the vendor to identify its AI role, model family, relevant versions, intended purpose, known limitations, and applicable compliance route.
• Request instructions and technical information needed for safe deployment, including logging, security, data residency, retention, subprocessors, and incident contacts.
• Define whether customer inputs are used for training, how deletion and correction requests work, and what happens when the vendor changes a model.
• Reserve audit or evidence rights proportionate to risk, including cooperation with regulator requests and serious incident investigations.
• Set notification windows for outages, vulnerabilities, unauthorized outputs, data exposure, material model changes, and loss of a compliance status.
• Prohibit the vendor from using the company's confidential information for unrelated purposes, and require return or deletion at exit where feasible.

Employee use and customer use are different workflows

For employees, publish a short acceptable-use standard backed by technical controls. Define approved tools, prohibited data, verification duties, intellectual property review, disclosure rules, prompt injection handling, and reporting. Provide a safe route for experimentation so employees do not hide useful use cases in personal accounts. Monitor adoption through aggregated signals where appropriate and coordinate with privacy, works council, employment, and collective bargaining requirements before monitoring individuals.

For customers, design a service journey that explains AI involvement, preserves a human escalation route, prevents sensitive decisions from being delegated casually, and records consent or notice where required. Customer facing automation should have tested fallback language, refusal behavior, language coverage, accessibility, rate limits, and a way to correct an account or case when the model is wrong. Make the responsible team visible internally even when the customer sees a brand rather than a model name.

Incident handling should start before an incident

An AI incident can be a wrong recommendation, discriminatory pattern, privacy breach, security attack, unsafe autonomous action, misleading synthetic media, loss of traceability, or failure of human oversight. Define severity levels and a single intake channel. The intake form should capture the system, version, affected people, date, input and output references, action taken, harm, containment, and reporter. Preserve relevant logs and prompts without spreading sensitive data unnecessarily.

The response playbook should cover immediate containment, access suspension, human review of affected cases, customer or employee communication, vendor escalation, legal assessment, regulator notification where required, root cause, remediation, and controlled restart. Run tabletop exercises for a customer chatbot leaking confidential data, a recruiting model producing disparate outcomes, and a factory system issuing an unsafe maintenance recommendation. Record decisions and owners. A post-incident meeting without a control change is not remediation.

Sector considerations for Italy

The EU AI Act does not replace sector regulation. Financial services companies should connect AI classification to banking, payments, insurance, outsourcing, governance, consumer protection, and prudential expectations. Manufacturers should connect AI controls to product safety, machinery, medical device, industrial cybersecurity, and conformity assessment processes. Healthcare organizations must combine the Act with medical device, clinical, privacy, professional, and patient safety obligations.

Retail and consumer businesses should review profiling, pricing, advertising, customer service, and synthetic content. Logistics and utilities should examine safety, access, infrastructure, and worker management. Public sector suppliers should understand procurement requirements and the public body's role. Italian employment uses deserve special care because workplace AI can touch worker information, evaluation, surveillance, safety, consultation, and collective rights. Use AgID's artificial intelligence materials for Italian public administration and national context, while recognizing that AgID guidance is not a substitute for the Regulation or applicable sector law.

A realistic 30, 60, and 90-day plan

Days 1 to 30 should create visibility and stop avoidable risk. Appoint an accountable executive, a compliance lead, and system owners. Issue a temporary rule for sensitive data and high impact decisions. Collect the inventory from business, IT, security, HR, procurement, product, and suppliers. Screen each use for prohibited practices, high risk indicators, GPAI dependence, transparency triggers, and regulated sectors. Identify unknowns and put a decision date beside each one.

Days 31 to 60 should turn findings into controls. Approve a role and classification method. Publish the employee AI standard and role based training. Update procurement questionnaires and priority vendor contracts. Configure access, retention, logging, notices, human review, and incident intake for the highest exposure systems. Start evidence folders and a transition register that reflects Regulation 2026/1744. Take legal advice on ambiguous classifications and on Italian requirements where implementing details remain pending.

Days 61 to 90 should test and govern. Complete risk assessments for priority systems, run bias and performance tests, conduct a tabletop incident exercise, and sample logs and human overrides. Approve a change management gate for new models, prompts, data, integrations, and use cases. Report an executive dashboard with open high risks, overdue vendor evidence, training coverage, incidents, review quality, and upcoming dates. Then set a quarterly review cadence rather than declaring the project finished.

Evidence checklist for an audit or board review

• AI inventory with system owners, roles, purposes, versions, data, vendors, users, affected people, and classification decisions.
• Legal and guidance register showing source, binding status, application date, amended date, and interpretation owner.
• Prohibited-practice screening and high-risk assessment, including rationale and approval.
• AI literacy curriculum, attendance, assessments, and role based refreshers.
• Data sheets, dataset provenance, quality tests, evaluation results, limitations, and Italian language or demographic performance evidence.
• Technical documentation, configuration records, access reviews, logs, retention settings, and change history.
• Human oversight instructions, override records, escalation routes, and evidence that review was possible and effective.
• Vendor due diligence, contract clauses, model information, subprocessor list, security evidence, incident commitments, and exit plan.
• Transparency notices, content labels, customer scripts, accessibility checks, and records of where notices appear.
• Incident register, investigation reports, corrective actions, regulator or customer communications, and post-incident testing.

KPIs that show control, not paperwork

Measure coverage and effectiveness together. Useful leading indicators include the percentage of AI uses inventoried, the percentage with a named owner, classification completion, approved tool adoption, staff training by role, vendor evidence coverage, and systems with tested rollback. Useful operating indicators include human review completion, override rate by use case, error rate by relevant group and language, unresolved incidents, time to contain, time to correct affected records, and percentage of material changes reviewed before release.

Avoid vanity metrics. A high number of completed trainings can coexist with staff pasting customer data into an unapproved tool. A low override rate can mean a model is excellent, or that reviewers cannot challenge it. Pair every metric with a quality sample, a threshold, an owner, and an action. Report trends and exceptions to the executive sponsor, not just a green dashboard.

Common mistakes to avoid

• Treating the vendor's statement that a product is compliant as a classification, risk assessment, or deployment decision.
• Assuming all generative AI is prohibited or, at the other extreme, assuming a productivity tool is outside the Act.
• Writing one broad policy and failing to configure access, data controls, notices, logging, review, and incident response.
• Ignoring shadow AI because it is not in procurement. Shadow use is evidence that the approved workflow is missing or unusable.
• Calling a person a human-in-the-loop when they only click approve and cannot see, understand, or challenge the recommendation.
• Using an old date table after the 2026 amendment, without checking the revised high-risk transitional provisions.
• Presenting guidance, voluntary standards, or a pending Italian decree as binding law.
• Keeping logs indefinitely, copying sensitive prompts into tickets, or failing to restrict access to model inputs and outputs.
• Launching an Italian language experience after testing only English performance.
• Buying a compliance platform that creates a second inventory instead of integrating with identity, procurement, security, data protection, product, and incident systems.

Build versus buy

Buy commodity controls where they are mature: identity, access management, asset discovery, training delivery, ticketing, evidence storage, monitoring, and vendor questionnaires. Build or configure the parts that depend on your business judgment: role mapping, use case taxonomy, risk appetite, prohibited-use gate, human review design, Italian language evaluation, escalation, and executive reporting. A platform can help organize evidence, but it cannot decide whether your recruitment workflow materially affects people or whether an operator is genuinely able to override a recommendation.

For a small or mid-sized company, begin with a controlled register, approved tool catalogue, contract addendum, training matrix, and incident workflow. For a larger company, integrate those controls with the existing GRC, privacy, security, quality, product lifecycle, and supplier management systems. The right architecture is the one that leaves an accountable trail without adding a manual spreadsheet for every new tool.

What can we do for you?

Magna Products helps Italian companies move from scattered AI experiments to controlled, useful operations. We can map your AI inventory, classify use cases and roles, design approved workflows for third party GPAI tools, connect human review and evidence to the systems your teams already use, and build practical dashboards for owners and leadership. Talk with Magna Products to plan a focused discovery workshop and leave with a prioritized 30, 60, and 90-day compliance backlog.