AI pathway

When someone tries a generative AI system for the first time, the most common reaction swings between two extremes: the amazement of those who believe they are facing an infallible encyclopaedia that converses, and the mistrust of those who, having caught the first mistake, dismiss the whole thing as an unreliable toy. Both reactions spring from the same misunderstanding: judging the tool without knowing how it works. A large language model is trained by exposing it to enormous quantities of text — books, articles, web pages, documents of every kind — with an apparently modest task: learning to predict which word comes next, in every possible context. From this exercise, repeated over billions of examples, the model derives a statistical representation of language so rich that it can write, summarise, translate and answer questions. Behind the answers there is no archive consulted entry by entry, nor a programmer who anticipated that specific question: there is a text-prediction mechanism which produces, each time, the continuation best suited to the request received.

The difference from traditional software is not one of degree but of kind: the management system executes rules, the model produces plausibility. An accounting program adds up invoices because someone wrote the instruction to add them, and if the result is wrong there is, somewhere, a rule to be corrected. A generative model, faced with the same question, composes an answer that resembles the correct answers it saw during training — and as a rule it does so well, because correct answers are the preponderant part of its examples. But “resembling the right answer” and “being the right answer” remain different things, and the model has no internal mechanism to tell them apart: the same confidence of tone accompanies the accurate statement and the invented one. It is by now common for users of these tools to discover this in precisely that way, finding a wrong detail inside an otherwise excellent answer. Yet this does not make the tool unusable: it makes it necessary to use it knowing what can be expected of it, as with any colleague whose strengths and limits are known.

The two opposing myths must therefore be dispelled together. Generative AI is not an oracle: it does not “know” in the sense in which a professional who has studied and verified knows, and presenting its answers as certified truth is an error of method before it is one of prudence. But neither is it a toy: on tasks of writing, summarising, rephrasing and first analysis of a document, the quality of the work is real and the time saved is tangible. The correct posture is the one kept with a brilliant colleague who is not yet experienced: you gladly entrust them with the first draft, not the signature. Yet even this image has a limit, and it is worth stating it openly: the human colleague learns from their own mistakes in the working relationship with us, whereas the model, from one conversation to the next, normally retains no memory — supervision cannot therefore be relaxed over time out of habit, as it would be with a person.

Why this is worth knowing

• Understanding the mechanism — text prediction, not consultation of an archive — makes it possible to foresee where the tool will perform well (writing, summarising, rephrasing) and where caution will be needed (facts, figures, precise references).
• The distinction between plausible and true is the practical criterion for deciding what must be verified before use: everything that is verifiable and has consequences deserves a human check.
• Anyone in the business who starts from either of the two myths — blind trust or outright rejection — tends to use the tool badly in both cases: an honest explanation of how it works is the first training investment, before any rule of use.

Picture a small manufacturing firm that has to answer a qualification questionnaire from a prospective foreign customer. To save time, the administrative clerk asks a chatbot to draft the reply, and obtains an excellent text: professional, well structured, convincing. Inside it, however, there are a certification described with an abbreviation the company does not hold in that version, a production-capacity figure that is believable but was never actually calculated, and a reference to an industry practice expressed with such naturalness that it seems obvious — and which no one in the company could document. Nothing in the tone distinguishes the reliable parts from the invented ones: the text is uniformly sure of itself. If the document goes out as it stands, the company has declared untrue things to a customer without anyone ever having decided to do so. This is the typical scenario of hallucination in a professional setting: not the gross error anyone would notice, but the plausible detail nested inside otherwise good work, where the quality of the whole lowers the guard precisely on the point that needed checking.

Hallucinations, bias and temporal limits are not teething problems that the next version will eliminate: they are structural features of the way these systems work. Hallucination follows from the very mechanism of generation — the model always produces the most plausible continuation, even when nothing in its data supports an answer, and in that case plausibility fills the void. Bias follows from the training data, which no collection, however vast, renders neutral. The temporal limit follows from the fact that training is a process that closes, while the world goes on. Later versions attenuate these phenomena, sometimes remarkably, and it would be wrong to deny it; yet attenuating is not eliminating, and an organisation that designs its controls on the assumption that the problem will disappear is designing them on a hope. The operational consequence is clear-cut: human review and source verification are not a transitional phase pending perfect models, but a permanent component of any professional use of these tools.

How does one live, in practice, with limits that cannot be eliminated? With the same method used for every known risk: knowing where it concentrates. The fragile points of a generated answer can be identified in advance — precise references (sources, abbreviations, names, dates), figures, everything recent, everything that will be declared to third parties — and that is where verification must be concentrated, going back to the original source and not settling for asking the same tool for confirmation, since it tends to confirm with the same assurance with which it erred. The rest — the structure of the text, the tone, the flow — can happily be left to the machine. Yet the method only works if it becomes a shared habit rather than the scruple of an individual: if one person in the business verifies and the others do not, the effective level of control is that of the least prudent person.

Why this is worth knowing

• The most expensive error is not the obvious one but the plausible one: verification must be concentrated on references, figures and recent data, that is, on the points where hallucination hides best.
• Asking the model whether its answer is correct is not verification: the confirmation arrives with the same assurance as the error. Verifying means going back to the original source.
• Because these limits are structural, controls must be designed as a stable part of the process — who verifies, what, before which use — and not as a provisional precaution pending a better tool.

So far we have spoken of systems that produce text: you ask a question, you read the answer, and every practical consequence passes through a human decision. AI agents mark a further step. An agent receives a goal — “prepare the replies to the documentation requests that arrived yesterday”, “gather the data for the quotation and fill in the form” — and pursues it on its own, breaking it into steps: it reads the messages, opens the documents it needs, extracts the information, fills in, prepares. At each step it decides the next on the basis of what it has found, without every move having been anticipated by anyone. It is by now common for the tools offered to businesses to incorporate functions of this kind, sometimes without even calling them “agents”: the assistant that sorts the post, the system that prepares repetitive files by itself. The advantage is evident — not a suggestion to be copied out, but work actually done — and explains the interest surrounding this evolution. Yet it is precisely the advantage that requires a clear understanding of what is being handed over to the tool: no longer just a question, but a piece of the business’s operations.

With an agent, the error does not stay on the screen: it becomes a completed action. This is the direct consequence of everything seen in the previous chapter. Hallucinations, bias and the variability of answers do not disappear when the model stops answering and starts acting; they change destination. The invented reference that in a chat would have remained a text to correct can, inside an agent, end up in a form filled in and transmitted; the misreading of a message can translate into a reply sent to the wrong recipient. And since the agent chains several steps together, an error committed at the beginning propagates to the subsequent steps, which build on it with the usual, imperturbable coherence. That is why autonomy must be dosed, not granted wholesale: the human control point, which with a chatbot is natural — it is we who read the answer before using it — must with an agent be reintroduced deliberately, deciding at which points in the chain the agent must stop and show what it is about to do. Yet the opposite reaction would also be a mistake, that is, demanding human confirmation at every single step: an agent that asks permission for everything saves nothing, and supervision reduced to repeated clicks soon ceases to be real supervision.

The notion to take home is that of the perimeter: the explicit list of what the agent may do on its own and what requires confirmation. The guiding criterion is reversibility, corrected by common sense: preparing, sorting, classifying, proposing are activities that can be delegated, because an error can be corrected; sending, signing, paying, deleting, communicating externally are thresholds that are best guarded with a human go-ahead. A serious perimeter is not a wish but a configuration: it is written in the tool’s settings, not only in the intentions of whoever uses it, and it is reviewed when experience shows it to be too wide or too narrow. There remains, in the background, the question every business owner asks as soon as they imagine an agent at work: and if it gets it wrong, who answers for it? We deliberately defer it to chapter 8, where the subject is treated in full; here it is enough to say that the answer begins precisely with the perimeter, because the delegation that can be defended is the one you were able to describe.

Why this is worth knowing

• Before adopting a tool it is worth asking whether it only answers or whether it acts: many recent products incorporate agent functions without declaring them under that name, and the level of control needed changes accordingly.
• The perimeter — what alone, what with confirmation — must be decided and configured before the tool goes into operation, using the reversibility of the action as the first criterion of delegation.
• Supervision must be concentrated on the thresholds that matter (sending, signatures, payments, communications to third parties), not diluted over every step: too much confirmation wears down attention as much as too much autonomy.

Until a few years ago an attempted fraud gave itself away through its mistakes: approximate Italian, a blurry logo, a patently invented email address. That safety margin has closed. Today an artificial-intelligence system reconstructs a voice from a few seconds of recording, animates a face in a video call, writes a message impeccable in its wording and consistent with the habits of the person receiving it. The recurring forms are three. The first is the fake executive fraud: the managing director’s voice orders the head of administration to make an urgent, confidential payment. The second is the fake video of a well-known figure — a journalist, a representative of an institution — who appears to promote a safe investment: these are often genuine television appearances, altered; the Postal Police, the Bank of Italy and Consob have published explicit warnings about this phenomenon, making clear that the messages attributed to those authorities are false. The third is the tailor-made message, built on genuinely public information — an order in progress, a regular supplier, the name of a colleague — which for that very reason arouses no one’s suspicion.

The defence against these frauds is not technological, it is organisational: the point is not to recognise the fake, but to make its credibility useless. Hunting for the imperfection in the image or the sound is a battle already lost, because the quality of artificial content improves faster than the ability to perceive it. What does not age, on the other hand, are four elementary safeguards, which any business can adopt at no cost. The first is verification through a different channel: a request received by telephone is answered by calling back the known internal number, never the number the call came from, and a request that arrived by email is not dealt with by pressing “reply”. The second is dual written authorisation for payments above a threshold set by the business, with no exceptions granted for urgency. The third is a password agreed in advance between management and administration, and — in the personal sphere — a word agreed within the family, because the same technique feeds the fake pleas for help attributed to a son or a grandchild. The fourth is cultural, and must be stated openly in the business: whoever stops to verify is not showing a lack of trust, and will never be reproached for having done so.

There remains the plane of reaction, which must be prepared beforehand and not improvised afterwards. Everyone in the business must know who is called first — the bank — and that no one should fear reporting the error as soon as they realise they have made it: the delay with which the deception is admitted is, in practice, the factor that most often makes the money unrecoverable. On the legal plane, two elements deserve to be known even by those who do not deal with the law. Disseminating without consent images, videos or voices falsified with artificial-intelligence systems, capable of misleading as to their genuineness, and thereby causing unjust harm to a person, is today a self-standing criminal offence, punished with imprisonment of one to five years and prosecutable as a rule upon complaint by the victim (art. 612-quater of the Italian Criminal Code, introduced by Law 132/2025, the Italian AI law, of 23 September 2025). And the transparency obligations of the European regulation on artificial intelligence, applicable from 2 August 2026, require the deployer who generates or manipulates images, audio or video constituting a deepfake to disclose that the content is artificial (art. 50, para. 4, first subparagraph, of Regulation (EU) 2024/1689); for manifestly artistic, creative, satirical or fictional works the obligation softens to disclosing the existence of the generated content, in a way that does not hamper the enjoyment of the work. Yet neither rule gives back the money of a transfer that has gone out: they serve to punish and to make content recognisable, not to replace the verification phone call that no one made.

Why this is worth knowing

• The voice and face of anyone with a visible role in the business are already available material: the defence cannot consist in recognising the fake, but in never deciding a payment on the basis of a single contact channel.
• Urgency and confidentiality, when they appear together in a payment request, are not circumstances of the case: they are the very technique of the fraud, and must be treated as the first clue.
• The reaction procedure — bank first, then criminal complaint and preservation of every trace — must be written down and known before it is needed: in an emergency you carry out what has already been decided, not what you improvise.

Regulation (EU) 2024/1689 — the act everyone calls the AI Act — is not a law about technology, but a law about the use made of it. This is the key to reading it without getting lost. The text first of all defines two subjective positions, and makes almost everything depend on them: the provider is whoever puts its own name or trademark on a system and brings it to the market; the deployer is whoever uses it under its own authority in the exercise of a professional activity (art. 3, points 3 and 4, of Regulation (EU) 2024/1689). Almost all of the Firm’s business clients are in the second position. There is, however, one case in which the first position is assumed unintentionally: the business that has software developed by third parties and distributes it under its own trademark is a provider, not a mere user, and at that point the burden of obligations changes considerably. This is a point on which it pays to pause before signing a development contract, not after. As for the objective scope, the regulation defines an “AI system” as an automated system, endowed with a margin of autonomy, that infers from the input it receives how to generate outputs such as predictions, content, recommendations or decisions (art. 3, point 1): a spreadsheet with deterministic formulas does not fall within it, a model that generates text or scores does.

The postponement decided in July 2026 moved part of the timetable, it did not suspend the regulation: anyone who reads “AI Act postponed” and concludes “I need do nothing” is taking a wrong decision on a false premise. Regulation (EU) 2026/1744, published on 24 July 2026 and in force since 27 July 2026, rewrote part of art. 113: the obligations on the high-risk systems of Annex III, which were due to bite on 2 August 2026, will arrive on 2 December 2027, and those on the systems of Annex I on 2 August 2028. The European legislator justified the choice by the delay in the availability of the technical standards and guidance and by the delay in setting up the competent national authorities, which would have made entry into application burdensome and not very effective. But the general date of application of the regulation, set at 2 August 2026, was not touched, and neither were the earlier dates of 2 February 2025 and 2 August 2025. The resulting picture, today, is that of a regulation largely operational, with one chapter — the most demanding — arriving in a little over a year.

The prohibited practices of art. 5 deserve an explicit list, because they have been applicable since 2 February 2025 and their breach falls within the highest penalty band: subliminal or purposefully manipulative techniques that materially distort behaviour and cause significant harm; the exploitation of vulnerabilities due to age, disability or social and economic situation; social scoring that produces detrimental treatment in contexts unrelated to those in which the data were collected, or otherwise unjustified or disproportionate; the predictive assessment of the risk of committing a criminal offence based solely on profiling or on personality traits; the creation or expansion of facial-recognition databases through the untargeted collection of images from the internet or from CCTV footage; emotion recognition in the workplace and in education institutions, save for medical or safety reasons; biometric categorisation that infers race, opinions, trade-union membership, beliefs, sex life or sexual orientation; and “real-time” remote biometric identification in publicly accessible spaces for law-enforcement purposes, save for the exhaustively listed authorised cases (art. 5, para. 1, points (a) to (h)). For an SME the concrete pitfalls lie in social scoring and emotion recognition: software that analyses employees’ emotions or “engagement” on video calls, or an internal behavioural-scoring system, falls within the prohibition even if it is offered as an ordinary productivity tool.

One nearby date remains to be flagged, 2 December 2026, which is worth keeping distinct because it hides two different deadlines and commentaries tend to confuse them. The first concerns the new prohibitions inserted into art. 5 by Regulation (EU) 2026/1744, which will become applicable on that day. The second, entirely separate, is the deadline by which providers of generative systems already placed on the market before 2 August 2026 must comply with the obligation to mark synthetic outputs (art. 111, para. 4, introduced by Regulation (EU) 2026/1744): it is an obligation of the provider, not of the deployer, and the user business need do nothing except expect the tools it uses to fall into line. However, precisely because Chapter III on high risk will arrive in 2027 and 2028, the purchasing choices businesses make now — recruitment software, a customer-scoring tool — should already be made today with those rules in mind: a contract signed in 2026 will produce its effects when the obligations are fully enforceable, and renegotiating it then costs far more than asking the right questions now.

Why this is worth knowing

• The position of deployer is not a neutral one: it is assumed by the mere fact of using an AI system in a professional activity, without any formal act and without anyone notifying the business.
• The postponement decided in 2026 concerns exclusively high-risk systems: building a generalised wait-and-see on it means being exposed precisely on the obligations already applicable, which are also the easiest to breach through inattention.
• Distributing under your own trademark a system you had developed by third parties triggers the qualification of provider (art. 3, point 3): it is a circumstance to be checked before settling the contractual arrangement with the software house, not downstream.

Seen from the standpoint of the business that uses AI without developing it, the subject boils down to three ordered questions: what must I do in any event, what must I declare, and what changes if the tool I have chosen falls among the high-risk ones. On the first point, the regulation today asks less than it did in the 2024 version. Art. 4, rewritten by Regulation (EU) 2026/1744, no longer requires ensuring “to their best extent, a sufficient level” of literacy, but taking measures to support its development, calibrated to the staff’s skills, the context of use and the persons on whom the systems are used; and it makes clear that no one is required to guarantee a specific level for anyone. The reason for the lightening, stated by the European legislator, is that rigid obligations would not suit all types of providers and deployers and would produce disproportionate burdens, above all for the smallest businesses. An obligation nonetheless remains, applicable from 2 February 2025, and documenting the measures adopted remains advisable: a register of training sessions and written operating instructions on the use of the tools are the simplest record to produce.

The transparency obligations of art. 50 are the part of the AI Act that today concretely touches almost every business, and they must be read by distinguishing precisely who bears them. Systems intended to interact directly with natural persons must be designed so that the person knows they are talking to an AI system, and this is the provider’s task (art. 50, para. 1). Synthetic outputs — audio, image, video, text — must be marked in a machine-readable format as artificially generated or manipulated, and this too is the provider’s task (art. 50, para. 2), excluding cases in which the AI performs an assistive function for standard editing without substantially altering the input. A limit that precedes the information obligation must, however, be stated first: art. 5, para. 1, point (f), prohibits the use of emotion-recognition systems in the workplace and in education institutions, save for medical or safety reasons — a prohibition applicable since 2 February 2025 and placed in the highest penalty band —, so that the obligation to inform persons exposed to emotion-recognition or biometric-categorisation systems (art. 50, para. 3) covers only the contexts in which use remains permitted and does not legitimise the analysis of employees’ emotions. Also resting on the deployer is the obligation to disclose the artificial character of published deepfakes (art. 50, para. 4, first subparagraph). The second subparagraph of the same paragraph then contains the provision most useful to explain to clients: whoever publishes AI-generated text to inform the public on matters of public interest must declare it, but the obligation does not apply where the content has undergone human review or editorial control and a natural or legal person holds editorial responsibility for it. All the information must be provided in a clear and distinguishable manner at the latest at the time of the first interaction or exposure (art. 50, para. 5).

The high-risk chapter is not yet enforceable, but it already conditions purchasing choices. From 2 December 2027 for the systems of Annex III and from 2 August 2028 for those of Annex I, the deployer will have to use the system in accordance with the instructions for use, assign human oversight to persons with adequate competence, training and authority, ensure the relevance and representativeness of input data where it controls them, monitor operation and suspend use with notification to the authorities in the cases provided for, keep the automatically generated logs for at least six months, inform workers’ representatives and the affected workers before putting a high-risk system into service in the workplace, and inform the natural persons subject to the use of the system where it takes or assists decisions concerning them (art. 26 of Regulation (EU) 2024/1689). On the employment front, however, a recurring mistake should be avoided: an information obligation towards the worker already exists today, because art. 11 of Law 132/2025 of 23 September 2025 does not create a new one but refers back to art. 1-bis of Legislative Decree 152/1997, which was already applicable. Yet on the national penalty side the picture is not complete: Law 132/2025 designates AgID and ACN as the national authorities for artificial intelligence, assigning ACN supervision including inspection and penalty activities (art. 20), but the formal conferral of the power to impose the penalties of art. 99 is left to a delegated decree which the Council of Ministers finally approved on 4 August 2026 and which, as far as can be ascertained at the date of this page, has not yet been published in the Official Gazette; the deadline of the delegation, set at 10 October 2026, remains subject to the extension mechanisms the statute provides for parliamentary scrutiny. To say that the AI Act’s penalties are already fully operational in Italy would be inaccurate; to say that Italy has not designated its authorities would be just as inaccurate.

Why this is worth knowing

• The literacy obligation is today an obligation of means, not of result: proportionate, documented measures suffice, but the total absence of measures remains a breach of a rule applicable since 2 February 2025.
• On the transparency obligations, the allocation matters more than the content: what concerns chatbots and the marking of outputs belongs to the provider and must be demanded by contract; what concerns published deepfakes belongs to the business and cannot be delegated to anyone.
• If the software affects the recruitment, management or evaluation of staff, or the creditworthiness of natural persons, the starting assumption is that it is high-risk: the burden of having documented the contrary lies with the provider, and it should be requested in writing before purchase.

The point to start from is that personal data protection did not wait for the AI Act and does not follow its calendar. Regulation (EU) 2016/679 has applied since 2018 and continues to apply unchanged to anyone using AI tools on data relating to people: clients, suppliers, job applicants, employees. From this follows an order of priorities that must be reversed compared with what businesses expect: first one checks compliance with the GDPR, which is already fully enforceable, and only afterwards does one consider the obligations of the AI Act, some of which have been deferred. The first check is the most elementary and the most neglected: knowing where the data end up. An AI service hosted by a third party involves a transfer of information outside the company’s systems, and before adopting it one must read the terms of the service to establish who processes the data and for what purposes, whether and for how long they are retained, and whether the provider uses them to train its own models. This last aspect is the one over which the business has the greatest leverage: where the provider offers settings that exclude the use of content for training purposes, the exclusion should be switched on and the choice documented, because it is an organisational measure that concretely reduces exposure.

The most effective operating rule, and also the easiest to enforce, is that data relating to third parties are not entered into an external service without a legal basis and without having checked the terms of the service. The member of staff who asks an AI tool to summarise a contract, to redraft a disciplinary letter or to analyse a list of debtor positions is processing the data of people who have no relationship whatsoever with that provider. The question to ask is not whether the tool is reliable, but whether that processing was permitted. It is worth spelling out three practical prohibitions, which cover almost all real incidents: no documents containing health, judicial or otherwise special-category data are entered, except within a processing operation expressly provided for and assessed; no name lists of clients or employees are entered for analysis purposes not declared in the privacy notice; no tools chosen independently by the individual outside those authorised by the business are used. Three lines of internal instruction, communicated and kept on file, are worth more than any statement of principle.

There remains the most delicate case, the one in which the AI does not process information but decides about people. If a system screens job applications, assigns a score to a customer or determines the outcome of a request, and the decision produces legal effects or similarly significantly affects the person, one enters the scope of art. 22 of Regulation (EU) 2016/679, with everything that follows in terms of permitted legal basis, safeguards to be ensured and information to be provided. In these same cases the precondition for an impact assessment under art. 35 also frequently arises, and the two exercises should be conducted together: the AI Act indeed expressly provides that the deployer of a high-risk system shall use the information received from the provider to comply with its obligation to carry out an impact assessment under art. 35 of the GDPR (art. 26, para. 9, of Regulation (EU) 2024/1689). The two assessments complement each other; they are not duplicated. It must however be said frankly that the classification is not always clear-cut: establishing whether human involvement is effective or merely formal, and whether an effect is “similarly significant”, is a judgement that admits margins of appreciation. Precisely for this reason the best defence is not a confident answer but a reasoned and documented decision: if the business can show what elements it weighed and what safeguards it put in place, the discussion shifts from the failure to assess to the merits of the assessment.

Why this is worth knowing

• The postponement of the high-risk obligations offers no shelter on the personal-data front: arts. 13, 14, 22 and 35 of Regulation (EU) 2016/679 apply today, exactly as they applied before the AI Act.
• The choice of which data may leave the company must be made upstream and put in writing: left to the individual at the moment of use, it becomes a decision taken without information and without a trace.
• Where the service allows content to be excluded from training, switching the setting on and keeping evidence of it is one of the few measures that cost nothing and can actually be demonstrated if challenged.

The question clients ask first — “if the system gets it wrong, who pays?” — has an answer that is simpler than feared and less comfortable than hoped. There is, as things stand, no rule allowing the damage to be imputed to the system: liability rests with whoever put it to work in their business, and towards the end client it is the business that answers. A comparative example illustrates this better than any abstract statement, and it must be introduced with its caveat: it is a foreign decision, delivered in February 2024 by a Canadian small-claims dispute-resolution body, devoid of any effect in the Italian legal system, and usable only as an example of how an identical problem was dealt with elsewhere. A passenger had asked the chatbot on Air Canada’s website for information and was told of a discounted fare that the airline’s actual policy did not allow to be obtained retroactively; the airline defended itself by arguing that the chatbot was a separate entity, responsible for its own actions. The argument was rejected: the chatbot is part of the website, and the business answers for the information its own website provides. The award concerned a modest sum — in the order of six hundred and fifty Canadian dollars, plus interest and costs — but it is the principle that matters: “the bot got it wrong” is not a defence. In the Italian legal system the same facts would fall between art. 1218 and art. 2043 of the Italian Civil Code, depending on whether or not there was a contract.

The serious legal problem is not establishing whether someone is liable — someone always is — but governing in advance the internal apportionment among the parties in the chain. There are at least three roles, and they must be kept distinct: whoever uses the system under their own authority in the course of the business, i.e. the deployer, which is the position occupied by almost all businesses and professional firms; whoever places the system on the market or puts it into service under their own name or trademark, i.e. the provider — a qualification that can also be triggered inadvertently for the small business that distributes under its own brand software it commissioned from third parties; and whoever produces it, a position which European law is redefining right now. The defective-product regime currently in force, built on arts. 114 and 115 of the Italian Consumer Code, rests on a notion of product anchored to movable goods, within which software supplied on a stand-alone basis — as an online or cloud service — does not comfortably fit. Directive (EU) 2024/2853 closes this gap, expressly including software in the notion of product whatever the mode of supply, introducing presumptions of defectiveness and of causal link in favour of the injured party in cases of excessive technical complexity, and providing that the manufacturer is not exempt where the defect stems from the software or from the lack of the necessary security updates, for as long as the product remains under its control. The transposition deadline is 9 December 2026 and the directive applies to products placed on the market or put into service after that date. Two caveats are however due: as at 1 September 2026 the Italian implementing legislative decree has not been published in the Official Gazette — the delegation was conferred by the European delegation law of March 2026 and the draft is before Parliament — and even after 9 December 2026 the two regimes will coexist for years, distinguished by the date the product was placed on the market. Anyone designing contracts and insurance cover today must therefore reason on the European text, not wait for the Gazette.

On two much-cited reconstructions it pays to be blunt, because their circulation as if they were the law in force is a source of errors. That the “software agent” could be treated as an electronic shop assistant, with art. 2049 of the Italian Civil Code applied by analogy to the principal, is a scholarly thesis authoritatively argued but devoid, as things stand, of legislative confirmation; what is law is the imputation to the employer or principal of the wrongful act of persons within their organisation, and thus of the employee who misuses an AI system. Likewise, that the use of AI systems constitutes in itself a “dangerous activity” within the meaning of art. 2050 of the Italian Civil Code is a contested thesis, argued for high-impact uses and denied by another part of the literature on the ground that dangerousness must be established in the concrete case: for an ordinary business it is neither a threat to fear nor a protection to rely on. Finally, the circle must be closed on the professional, because the rule applies first of all to those who teach it: art. 13, para. 2, of Law 132/2025 requires that the information concerning the artificial-intelligence systems used by the professional be communicated to the recipient of the intellectual service in clear, simple and exhaustive language, in safeguard of the relationship of trust; the provision prescribes no particular form and carries no sanction of its own, but its breach is assessed on the disciplinary plane and on that of contractual non-performance. That is exactly what this pathway does when it declares to the client which tools the Firm uses and for what. The principle must however be stated in both directions, and it is the reciprocity risk that this chapter must make explicit: the same rule that protects the business when it is a user of services exposes it when it is the one deploying AI towards its own clients.

Why this is worth knowing

• Towards the client the burden of proof works against the business: showing that the error was the tool’s is not enough, because the choice, the configuration and the supervision of the tool are its own.
• Joint and several liability with the presumption of equal fault (art. 2055 of the Italian Civil Code) makes the contract with the provider decisive: without express indemnity and apportionment clauses, the residual risk is spread by presumption of parity.
• The traceability of technical and organisational choices — operating instructions, human checks, training, retention of logs — is no mere formality: in court it is the documentation that distinguishes diligence from fault.

Saying that a professional firm “uses artificial intelligence” means almost nothing, because very different practices coexist under the same formula: those who merely ask for a summary and those who entrust the tool with the substance of the answer to the client. It therefore pays to be precise about the method, rather than the announcement. Within the Firm, AI is used as a preparation tool: it gathers, organises, proposes a first draft, flags what is missing. For technical content the work is not entrusted to a single generic tool but to several agents specialised by subject — the tax area, the legal area, the customs area — each set up with its own language and its own sources, whose texts are then subjected to cross-review: the person who set up the content is not the same figure who re-reads it. It is an ordinary technique in professional firms, applied to a new material: the four-eyes principle was not invented for AI, but with AI it becomes indispensable, because the tool produces well-written texts even when they are wrong, and a well-written text lowers the reader’s guard.

The rule that holds up the entire method is a single one: AI prepares, the professional signs. From it the others follow. Every legislative reference destined for publication is checked against the primary sources — the text of the provision as it appears in the official Italian and European databases — before the content goes out: no reliance is placed on the tool’s memory or on a second-hand source, because rules change and a tool trained on materials from the past can confidently return a text no longer in force. Content in foreign languages goes through a dedicated language review, because a machine translation that is grammatically correct can be technically imprecise, and in tax matters the difference between two neighbouring terms is often the difference between two different legal concepts. Clients’ identifying data stay out of external tools. And nothing is sent to a client or to an authority without a person at the Firm having read and approved it. However, it must be said just as clearly that none of these rules makes the result infallible: they reduce the probability of error and make its origin traceable, which is what can reasonably be demanded of a method.

The reason this chapter appears in a course addressed also to clients is twofold. The first is transparency: anyone entrusting a firm with their accounts, their returns and their contracts has the right to know how that work is carried out, and the answer “with AI”, without further detail, is not an answer. The second is transferability. The five rules are not a protocol built to measure for a professional firm: they are principles of sound organisational common sense that a small business can adopt at its own scale, with its own letterhead and its own processes. Whoever writes quotations, replies to complaints, website copy or staff communications is in exactly the same situation — a tool that writes well and does not know what is true — and needs the same safeguards. The difference between a mature and an improvised use of AI does not lie in the quality of the tool, but in the existence of a written method and in the fact that someone applies it even when in a hurry.

Why this is worth knowing

• Asking your adviser how they use AI is a legitimate and useful question: the answer that matters is not which tool they use, but who re-reads, what gets verified and which data never leave the firm.
• Cross-review — the person re-reading is not the one who set up the text — is the cheapest and most effective safeguard, because it intercepts precisely the error AI produces best: the well-written one.
• The Firm’s five rules can be replicated in a business without investment: separation by subject, source verification, re-reading by another person, no confidential data in external tools, human approval before sending.

AI adoption in a small or medium-sized enterprise almost always fails in the same way: a tool is bought, handed out to the staff, and something is expected to happen. It does not happen, or it happens in a disorderly fashion — someone uses it a lot and well, someone not at all, nobody knows what was produced with which tool — and after a few months the project is shelved with the conclusion that “it wasn’t for us”. The design flaw lies at the origin: the starting point was the tool rather than the process. The right question is not which technology to adopt, but which activity in one’s working day is repetitive, textual, frequent and low-risk. Once that activity has been identified, the choice of tool becomes almost secondary, because the criterion is clear and the result is measurable. Until then every assessment is abstract, and abstract assessments in business end with buying the solution one has heard about most.

The cost of an AI project is not the licence: it is the time for set-up and checking, and that time must be budgeted before starting. Setting up a repetitive task well requires writing it out explicitly — what it must produce, in what form, under what constraints, what it must never do — and this work of making things explicit is the most laborious part, because it forces people to say out loud how they actually work, something which in many businesses has never been written down anywhere. Then it must be decided who checks the output and with what care, because a check that costs as much as redoing the work wipes out the benefit. The time spent here is recouped only on volumes: that is why the first use case should be sought among the things done every week, not among those done once a year, however tedious they may be. However, even a project that produces no measurable saving may be worthwhile, if it serves to build internal competence in a use that will become routine: provided this is declared from the outset, instead of telling oneself the story of an economic return that is not there.

The approach that holds up best in businesses of modest size is gradual and reversible: one process at a time, with a snapshot of the starting position — how many hours, how many people, how many errors or reworkings — and a follow-up check after a few months on the same indicators. It serves two purposes. The first is to find out whether the benefit really exists, instead of relying on the impression of whoever championed it, which is always favourable. The second, more important, is to be able to stop: a project that does not work must be closed without this becoming someone’s personal defeat, and that is possible only if it was said at the start that it was a trial with exit criteria. Whoever extends use to the whole company before measuring the first process is not accelerating: they are merely making any step back more expensive. Prudence here is not distrust of the technology, but the same caution one would apply to any other organisational investment with uncertain effects.

Why this is worth knowing

• The selection criterion for the first use case is fourfold — repetitive, textual, high-volume, low-risk — and it should be applied before looking at any tool.
• Untidy company data are the most frequent cause of failure and at the same time the one least blamed on the AI: tidying up archives and documents produces value even if the project then goes no further.
• Fixing two or three measurable indicators and a review date at the outset is what makes it possible to stop without internal reputational costs, and therefore what makes trying acceptable.

Rules on the use of AI are almost always written after the first incident: a confidential document that ended up in an external tool, a reply to a client containing a non-existent reference, a communication that went out without anyone having re-read it. It is the worst moment to write them, because the heat-of-the-moment reaction produces blanket prohibitions that are then disapplied within a few weeks. The policy is needed beforehand, and it serves above all to make explicit decisions that each person otherwise takes on their own: which tools may be used for work and which may not, whether a personal account is allowed, what may be uploaded and what may not. In the absence of guidance people do not stop using AI: they use it covertly, with tools of their own choosing, and the business loses any chance of knowing what was produced, how, and with which data. The first effect of a policy is not to limit use, but to bring it into the open.

A useful policy is short, concrete and names names: it says what may be done, with which tools, with which data, and above all it says who checks what before a piece of content leaves the business. The checkpoint is where its effectiveness is decided, and it should be written so that each type of output has a person attached: communications to clients, published texts, documents destined for authorities and agencies, internal materials do not carry the same risk and do not deserve the same intensity of verification. Alongside it, a simple channel for reporting errors should be provided — whom to approach, in what form, with what consequences — because a report that exposes the person making it never arrives, and the errors nobody reports are repeated. Finally, a review date should be set: tools change quickly, and a policy frozen two years earlier lists prohibitions on services that no longer exist and says nothing about those people actually use. However, none of these provisions works if the document stays in a shared folder: the policy is worth as much as the training that accompanies it, and it is the training that turns it from a compliance exercise into practice.

There is one final argument, worth spelling out because it is usually the one that convinces the decision-maker. The policy protects twice over. The first time, preventively: most incidents involving AI in business arise not from bad faith but from an absence of instructions, and a written rule prevents them at practically no cost. The second time, after the fact: if something goes wrong — a piece of data that went out where it should not have, a piece of incorrect content that reached a third party — the business that can show written rules, adopted before the event, communicated to staff and accompanied by training, is in a radically different position from the one that has nothing to produce. It is not a guarantee of exemption from liability, and it should not be presented as such: it is documentary evidence of organisational diligence, which always carries weight in subsequent assessments. The difference between the two situations lies not in the fact — which is identical — but in the ability to show that the business had done what it was reasonable to do.

Why this is worth knowing

• A policy of a few pages, with examples drawn from the business’s real activity, produces more effect than a long, generic document: it should be written before the first incident, not after.
• The minimum core is always the same: approved tools, prohibited data, a person responsible for checking each type of output, an error-reporting channel, staff training, a review date.
• The policy prevents errors and, if something goes wrong, documents the business’s diligence: two distinct functions, both lost if the document is not communicated and explained to the people who work.

Closing a pathway on AI by talking about people is not a rhetorical return to humanism: it is the practical consequence of everything seen so far. A tool that writes fluently, replies quickly and never shows hesitation produces a precise psychological effect on its user — the impression that the matter is settled. In many cases it is; in some it is not, and they are precisely the ones in which the answer seemed most certain. Hence the need to distinguish sharply between two ways of working that look alike from the outside. Getting help to decide means using the tool to see more: gathering what is scattered, comparing alternatives, surfacing the objection that had not been considered. Letting it decide means instead adopting the outcome because it arrived, without having the elements to challenge it. The second mode is rarely chosen: one slides into it, through volumes, through tight deadlines, through accumulated trust. And it is precisely for this reason that it must be named before it happens, not recognised afterwards.

Some decisions are not delegated, and not because the machine errs more than the human, but because those on the receiving end are entitled to an interlocutor who answers for them. They are the decisions that touch people — who gets hired, who gets appraised, who is granted financial trust — and those from which there is no way back. An algorithm can rank a hundred applications by a criterion, and even do it well; it cannot own the fact that a person was not called, nor explain the reason to them in a way that is verifiable and contestable. The same goes for credit, for the terms applied to a customer, for a measure concerning an employee. The practical criterion to hold onto is twofold: ask whether someone will be entitled to ask “why”, and ask whether the error will be correctable tomorrow. If the first answer is yes or the second is no, the decision stays with a person, who may use all the elements prepared by the tool but cannot hide behind them. However, this line is not to be drawn once and for all: it changes with experience, with the quality of the data and with the type of activity, and it should be re-examined periodically rather than inherited.

There remains the hardest question, which is one of habit and not of rules. Re-reading takes effort, and the cost is felt every day while the benefit shows once a year, when an error is caught. It is an asymmetry no procedure eliminates entirely: it can only be made less burdensome, by concentrating the checking where the harm would be greatest instead of spreading it evenly over everything, and by accepting that what is irrelevant is checked less. The point of this pathway, if it has one, lies in a simple formula: use AI a great deal and delegate to it very little. A great deal, because the time freed from repetitive work is time that becomes available again for what deserves attention. Very little, because responsibility for what is communicated, signed and decided stays where it has always been — with people — and no evolution of the tools will move it elsewhere. The professional who signs does not guarantee never to err: they guarantee that behind that document there is someone who has read it, understood it and answers for it.

Why this is worth knowing

• The boundary between assistance and delegation is not technical but organisational: it depends on whether the person approving has enough time, information and authority to reject the proposed outcome.
• Two questions are enough to place a decision: will someone be entitled to ask “why”, and will the error be correctable? If the answer is yes to the first or no to the second, a person decides.
• Attention declines through repetition, not through negligence: it pays to concentrate checking where the potential harm is greatest, rather than demand a uniform vigilance that does not hold over time.