Complete Claude Course for Business

1. Why Rules Are Essential

AI regulations are not just a matter for lawyers. They define what can be done, who is liable if something goes wrong, and what rights we have as citizens and workers.

The underlying problem is what we saw in the previous hour: it is often impossible to reconstruct why an AI system reached a particular decision. As a result, it becomes difficult to determine whether someone was treated unfairly—in recruitment, in a loan application, or in accessing a public service. Existing laws offer some protections, but they are not sufficient.

2. The European AI Act

Regulation (EU) 2024/1689, universally known as the AI Act, is the world's first comprehensive legal framework for artificial intelligence. Published in the Official Journal of the European Union on July 12, 2024, it entered into force on August 1, 2024, and takes effect in phases.

AI ACT: RISK LEVELS

AI Act and the Risk Pyramid

The 4 tiers: Prohibited, High Risk, Specific Transparency Risk, and Minimal Risk.

2.1 Four Risk Levels

The AI Act's approach: the higher the risk to individuals, the more stringent the obligations.

KEY DATES

Key Regulatory Deadlines

August 2, 2026 for transparency rules and December 2, 2027 for high-risk systems.

2.2 The Implementation Timeline

The AI Act did not take effect all at once. The timeline is phased to give companies time to adapt, and it has already been amended once: the simplification package known as Omnibus postponed the obligations for high-risk systems.

Timeline verified as of September 2026 on digital-strategy.ec.europa.eu and artificialintelligenceact.eu.

2.3 What Changes in Practice When Using a Chatbot

Starting August 2, 2026, transparency obligations apply. In practice:

• Anyone deploying a chatbot must make people aware that they are interacting with an AI system, not a human colleague.
• Artificially generated content must be identifiable: text, images, audio, and video.
• Deepfakes and text published to inform the public on matters of public interest must be labeled clearly and visibly.

Sanctions are not symbolic: for the most serious violations, the AI Act provides for fines of up to 7% of a company's global annual turnover.

2.4 Italy: Law 132/2025

Italy was the first EU Member State to enact a comprehensive national law complementary to the AI Act: Law No. 132 of September 23, 2025, in force since October 10, 2025. It does not replace the European regulation: it supplements it with national principles and delegated powers to the Government.

The designated national authorities are the Agency for Digital Italy (AgID) and the National Cybersecurity Agency (ACN).

Provisions Concerning the Workplace

• Duty to inform: employers must inform employees—and trade union representatives—of the use of AI systems.
• Ban on algorithmic discrimination: automated decisions cannot result in discrimination based on gender, age, ethnic origin, religious beliefs, or social status.
• Human oversight: employment decisions cannot be fully automated, and employees have the right to know the criteria and logic behind decisions concerning them.
• Knowledge professions: AI usage must remain instrumental and supportive, never replacing the intellectual work of licensed professionals.
• National Observatory established at the Ministry of Labor to monitor exposed sectors and support continuous professional development.

On the criminal front, the law introduces harsher penalties for crimes committed using AI systems, including the unlawful distribution of deepfakes.

3. Privacy: Data Leaving the Perimeter

This is where workplace enthusiasm for the tool can turn into a legal liability for the company. And in almost every case, hackers have nothing to do with it: it comes down to a well-intentioned copy-and-paste.

3.1 The AI Paradox

To perform well, AI requires data. Enormous amounts of it. The more useful it becomes, the more personal data it risks absorbing; the more it absorbs, the more powerful it gets; and the more powerful it gets, the harder it is to control what it knows about us.

The objective is simple to state and difficult to practice: enterprise data must stay within the perimeter.

DATA MINIMIZATION

GDPR and Data Minimization

Process only data strictly necessary. Never paste customer names, payroll data, or health records.

3.1 The GDPR in Five Principles

In Europe, personal data protection is governed by the GDPR, in force since 2018. It was not written specifically for AI, but it certainly applies. The key principles to keep in mind:

• Lawfulness, fairness, and transparency: individuals must know what happens to their data.
• Purpose limitation: data is collected for a specific, declared purpose, not 'just in case'.
• Data minimization: only what is strictly necessary is collected.
• Storage limitation: data is retained no longer than necessary.
• Integrity and confidentiality: data must be protected.

AI places significant pressure on these very principles. How do you guarantee purpose limitation if a model is trained on data collected for one purpose and then used for a thousand different tasks? And how do you reconcile data minimization with models hungry for ever-increasing volumes of data?

The AI Act does not replace the GDPR: it complements it, adding specific obligations regarding transparency, documentation, human oversight, and risk management.

3.2 The Threat Called Data Leakage

Imagine the scenario: Marco has an urgent deadline and a spreadsheet full of customer names, revenues, and profit margins. He opens a free consumer chatbot, uploads the file, and types: 'analyze this data and write me a summary.' Within thirty seconds, he has his report. He made a great impression.

What Marco failed to consider is that those data points are now on a server his company does not control, managed by a vendor with whom the company has no contract. They have left the perimeter—and they cannot be retrieved.

What Must Never Be Pasted into a Public Chatbot

• Personal and contact details of customers, suppliers, and employees.
• Contracts, price lists, margins, and confidential commercial information.
• Source code and proprietary technical documentation.
• Health data, judicial records, and special categories of data under the GDPR in general.
• Passwords, credentials, API keys, tax IDs, and bank details.

SHADOW AI IN THE WORKPLACE

Shadow AI in the Enterprise

Uncontrolled use of personal accounts with confidential company documents to get work done faster.

3.3 Shadow AI: The Invisible Threat

Marco's scenario has a name: Shadow AI. It refers to the spontaneous, unauthorized use of external AI tools by employees without the knowledge of IT or management. It does not require a sophisticated attack technique: a simple copy-and-paste is enough.

The damage is not just data leakage. Shadow AI makes information flows invisible: the company does not know what data has left, cannot control how it is used, and cannot prove that it took the necessary measures to protect it.

3.4 Two Italian Cases to Know

OpenAI and the Italian Data Protection Authority

The Italian Data Protection Authority (Garante per la protezione dei dati personali) fined OpenAI €15 million (order of November 2, 2024, published in December), citing deficiencies in transparency towards users, disproportionate data collection for model training, lack of age verification, and failure to notify a data breach. The fine was accompanied by an order to conduct a six-month public awareness campaign.

DeepSeek

On January 30, 2025, just days after the global launch of Chinese chatbot DeepSeek, the Italian Data Protection Authority urgently issued a temporary limitation order on the processing of Italian users' data, citing web scraping without adequate legal basis, the absence of a privacy policy in Italian, and breach of transparency obligations. The app was subsequently removed from Italian app stores.

3.5 Personal Account or Enterprise Subscription?

ENVIRONMENTAL IMPACT

Environmental Impact & Energy Use

Water consumption estimates range from 1 to 45 ml per query: highlighting the need for shared reporting standards.

4. The Environmental Footprint

This is the subject of Chapter 9 of the book, and the one that surprises participants most: every query we write carries a physical cost in electricity and water.

4.1 Energy

For nearly twenty years, data center electricity consumption remained surprisingly stable despite internet traffic growing twenty-fold: efficiency gains offset growth. Then, between late 2022 and early 2023, the curve spiked sharply.

Training and Inference: Two Distinct Demands

A model's lifecycle has two phases with very different costs.

• Training is the phase in which the model learns: intensive, concentrated over time, with thousands of GPUs running 24 hours a day for weeks. It is like sending a student to school for twelve years: expensive, but done once.
• Inference is the phase where the already-trained model responds to our questions. The cost of a single response is tiny, but multiplied across billions of daily interactions, it becomes the dominant footprint.

Until 2022, training was the dominant factor. Today that is no longer the case: inference—our daily usage—has taken the lead.

4.2 Water

Energy is only half the story. Data centers also consume fresh, often potable water for evaporative cooling of servers. And the GPUs performing AI computations run much hotter than traditional processors.

Two resources, one single bill: electricity to power the servers, water to cool them.

There is also an unseen water consumption: the water required to generate the electricity powering data centers. According to industry analyses, this represents the largest share of the total, scaling directly with energy consumption.

4.3 The Jevons Paradox

Here an economic mechanism observed in the 19th century by British economist William Stanley Jevons comes into play: when a technology becomes more efficient in its use of a resource, total consumption of that resource tends to increase, not decrease.

AI is experiencing this exact dynamic. Efficiency per operation is improving at a rate described by the International Energy Agency as likely unprecedented in energy history. Yet this very efficiency makes AI cheaper and more accessible, leading more people to use it for more tasks with larger models. Total consumption continues to rise.

4.4 Green AI: What We Can Do

• Choose the right model for the task. The most powerful model is not always needed: a simple task can easily be handled by a lightweight model consuming a fraction of the energy.
• Reduce redundant queries. Every avoided query saves energy and water. Long, meandering conversations and rapid-fire trial-and-error queries add up.
• Write precise prompts on the first attempt. Fewer attempts mean lower consumption and, not coincidentally, higher-quality answers. We will explore this thoroughly with the CO-STAR framework.
• Demand transparency from vendors. Disclosed energy consumption should be a selection criterion, just like pricing.

ACCOUNTABILITY LIES WITH THE SIGNATORY

Bias, Hallucinations, and Accountability

Structural limitations of AI models: ultimate accountability always rests with the human signatory.

5. Ethics: Bias and Hallucinations

While hallucinations are random errors, biases are systematic errors—and they are much harder to spot.

The model produces plausible text, not necessarily factual truth. Human verification is the essential counterweight.

5.1 Hallucinations

Imagine asking a friend who wrote The Leopard (Il Gattopardo). They answer with complete confidence: 'Italo Calvino.' It is wrong (it was Giuseppe Tomasi di Lampedusa), but their tone was identical to when they are right. If you do not know the actual answer, you believe them.

Technically, a hallucination is a syntactically correct and plausible response that is factually erroneous or fabricated. It is not an occasional glitch: it is a direct consequence of how LLMs work, as seen in the previous hour. The model does not access an archive of verified facts; it generates text by calculating probabilities. It is a mechanism of plausibility, not truth.

Because of this, hallucinations can be reduced, mitigated, and flagged—but not entirely eliminated under current architectures.

5.2 Biases

AI is often perceived as an impartial judge, precisely because it is made of numbers rather than emotions. That is a deceptive perception. Models learn from data, and data reflects our society with its inequalities and stereotypes.

As a result, AI can not only reproduce existing discrimination, but amplify it on a large scale, automatically and often invisibly. Research documents systematic distortions in describing professional roles across gender and ethnicity, as well as in automated resume screening.

The problem has three roots: training data reflecting a distorted mirror of society; the black box, meaning the opacity of deep models that makes proving discrimination extremely difficult; and the lack of diversity among the teams developing these systems.

6. Practical Exercise: Risk Assessment Audit

The exercise for this hour. It provides an honest snapshot of your company's actual situation, including tools that were never officially authorized.

Step One. List the AI tools currently used in the company, including 'unofficial' tools colleagues access from browsers or personal phones.

Step Two. For each tool, complete the row in the table.

Step Three. For every row combining a consumer account with company data, you have identified a vulnerability to resolve. Those are your starting points.

Lesson Glossary

The key terms encountered throughout this guide, explained in a single line. Keep this handy: they will reappear across all subsequent sessions of the course.

Further Reading & References

The primary sources used to compile this course guide. All references are publicly accessible: if a particular figure catches your attention, consult the original source to verify it. That is precisely what we must also do when using artificial intelligence.

The EU AI Act Official Regulatory Framework

European Commission, AI Act — digital-strategy.ec.europa.eu (updated as of August 3, 2026). Regulation (EU) 2024/1689.

Implementation Timeline

Implementation Timeline, artificialintelligenceact.eu (updated as of August 31, 2026), with article-by-article references.

Italian National Legislation

Law of 23 September 2025, No. 132, Provisions and Delegations to the Government on Artificial Intelligence, in force since 10 October 2025.

Privacy & Decisions by the Italian Data Protection Authority (Garante)

Italian Data Protection Authority (Garante per la protezione dei dati personali), garanteprivacy.it: Decision regarding OpenAI of November 2, 2024 (annulled by the Court of Rome on March 20, 2026 due to lack of jurisdiction) and urgent injunction regarding DeepSeek of January 30, 2025.

Energy & Data Centers

International Energy Agency, Energy and AI and Energy demand from AI, iea.org. The leading authoritative, independent reference for these figures.

AI Adoption in Europe

Eurostat, Statistics on the Use of Artificial Intelligence by Individuals, ec.europa.eu/eurostat.

Primary Reference Book

Gianluca Bonomo, Niente paura, è solo IA, Chapters 8 (Security, Privacy, and Risks), 9 (Environmental Impact), and 11 (Ethics and Society).

Lesson Objectives

Understand who Anthropic is and their operational priorities, what Constitutional AI means, how the Claude family of models is structured, and what genuinely changes with an expansive context window.

What You Will Be Able to Do by the End

• Explain the difference across the three tiers of the Claude family to a colleague and select the right one for a given task.
• Understand why a model may decline a request, and what it means that its criteria are written down.
• Estimate how much material can be fed into a single prompt.
• Recognize when cost optimization is sensible and when it is not.

ANTHROPIC & SAFETY

Anthropic and AI Safety

Founded in 2021: model safety engineered as a structural governance constraint.

1. Who Anthropic Is

Before entrusting company documents to a tool, it is essential to know who builds it, under what constraints, and with what priorities.

1.1 A Company Founded with a Statutory Mandate

Anthropic was founded in 2021 by Dario and Daniela Amodei alongside other researchers who came from OpenAI. Their declared mission is to build safe, reliable artificial intelligence systems.

So far, nothing that any company in the industry would not claim. The difference lies in its legal structure: Anthropic is a Public Benefit Corporation.

For anyone evaluating a vendor, this is a governance consideration, not a superficial detail: it dictates the legal priorities the company is required to weigh when commercial and safety goals come into conflict.

CONSTITUTIONAL AI

Constitutional AI

A framework of explicit written principles used to critique and refine model outputs.

1.2 Constitutional AI: The Self-Correcting Model

In the first hours of the course we saw that models are aligned with human expectations using techniques like RLHF (Reinforcement Learning from Human Feedback): people evaluate responses, and the model learns to generate preferred ones.

It works, but has two limitations: it is slow and lacks transparency. Who decided that a given response was better? By what criteria? It is not documented anywhere.

Anthropic's approach is different, known as Constitutional AI: providing the model with a 'constitution'—a set of explicit, written principles inspired in part by the Universal Declaration of Human Rights—and training it to critique and correct itself against them.

The cycle: the model responds, critiques itself against the principles, and rewrites.

In daily practice, this translates into a model that tends to be cautious, clearly flags when it does not know something, and declines problematic requests. At times it is more cautious than necessary: that is the other side of the same coin.

1.3 What This Means in Day-to-Day Use

A model trained this way tends to behave in three recognizable ways, and it helps to know them in advance so you do not mistake them for defects.

• It flags when it does not know. Instead of filling the void with a plausible fabrication, it tends to state that the information is absent. That is a strength, even if it feels inconvenient in the moment.
• It softens ambiguous requests. If a question lends itself to problematic usage, it often answers the harmless interpretation and explicitly says so.
• At times it is more cautious than necessary. It may decline a legitimate request that superficially resembles a problematic one: that is the other side of the same coin.

What Happens When It Declines

Sooner or later it happens to everyone: a legitimate request is declined, or answered with a preamble of irrelevant caveats. This happens because the model is applying its principles to a scenario it did not frame properly, not because your task is forbidden.

In the vast majority of cases, the root cause is missing context, and the solution is simply to provide it.

1.4 Model, Product, Interface: Three Distinct Concepts

In the classroom, people almost always confuse three terms that seem synonymous but are not. Clarifying them now avoids misunderstandings throughout the rest of the course.

The same model is accessed through different products and with different contractual guarantees. This is why the question 'Is it secure?' has no single answer: it depends on the product tier, not the model.

THE 3 CLAUDE TIERS

The Three Claude Tiers

Choose by task: Lightweight for volume, Balanced for 90% of business tasks, Powerful for complex reasoning.

2. The Model Family

There is no single 'best model.' There is only the model suited to the task at hand, and choosing it well is a core competency.

2.1 Three Tiers of the Same Tool

The three tiers: version names change over time, but the underlying tiered logic remains constant.

2.2 How to Choose in Practice

The right question is not 'which one is smartest,' but what does an error cost.

• If an error is immediately obvious and takes ten seconds to fix, use the lightweight model: it is faster and costs less.
• If an error ends up in a contract, an official quote, or customer communication, use the most capable model and verify thoroughly regardless.
• If you are creating something that will be reused a hundred times, it is worth spending more once to do it right.

2.3 Costs and How to Think About Pricing

Usage is metered in tokens, both input and output. As a rule of thumb: 1,000 tokens are roughly 750 words in Italian, equivalent to about a page and a half of dense text.

With subscription plans, you do not pay per token: you pay a flat fee and have a usage allowance. Therefore, for most enterprise users, cost reasoning translates into a different question: How quickly am I consuming my usage limit?

2.4 Version Names Age Quickly

Every few months a new version is released with a different number and increased capabilities. This is the part of the course that ages fastest, and it is best to know that from the start.

What does not change is the selection framework: three tiers—one economical and fast, one balanced workhorse, one for difficult reasoning tasks. Names change; the decision criteria do not.

CONTEXT WINDOW

The Context Window

Working memory capacity: from a single page (~550 tokens) to entire comprehensive dossiers.

3. The Context Window

This is the single metric that has transformed how we work with these tools more than any other.

The context window is how much text the model can keep in view in a single prompt: your question, attached documents, and previous conversation history, all combined. It is measured in tokens, the text units discussed in the first hour.

Orders of magnitude: from a single email to an entire document archive.

The current generation of flagship models reaches up to one million tokens; lighter models top out around 200,000, which is already roughly five hundred pages—an entire book.

3.1 A Large Context Window Does Not Mean Memory

This is the most common confusion. The context window applies only to that specific prompt session: it is like the desk the model works on, not an archive.

Once the conversation is closed, the content is not retained anywhere: next time, you start from scratch. To make reference documents permanently available, you use Projects, which we explore in Hour 9.

3.2 What One Million Tokens Means in Practice

Context window numbers remain abstract until converted into something familiar. As a rule of thumb, for Italian, one token is worth about three-quarters of a word.

In practice: a 200,000-token window comfortably holds a 300-page dossier plus the entire follow-up conversation. A one-million-token window accommodates an entire project archive.

SUMMARIZE AND RESTART

Reset and Start a New Chat

When conversations get too long, summarize key decisions and start fresh in a clean chat.

3.3 Working Effectively in Long Conversations

Even with a large window, a conversation that goes on for hours becomes difficult to manage: material piles up, instructions contradict one another, and eventually output quality degrades without an obvious reason. Three habits resolve nearly all of these situations.

1. One conversation, one task. When switching topics, open a new chat. Trying to analyze a contract and draft a newsletter in the same thread doesn't save time: it degrades the quality of both.

2. The transition summary. Before moving to a new phase of work, prompt: “summarize what we have agreed upon so far in ten lines.” Paste that summary as the opening prompt of your next conversation.

3. Materials first, instructions second. Upload your reference documents at the beginning and leave them untouched; append your queries and instructions at the end. We will revisit this structural principle in Hour 6 when covering context caching.

Questions Frequently Asked in the Classroom

They are the same in every workshop. It is worth having a concise, honest answer ready, including for when a colleague asks.

“Which model is the best?”

There is no single best model, and anyone telling you otherwise is oversimplifying. The most powerful on a trivial task is a waste of time and usage limits; the lightest on a contract is a risk.

The right question is: What does an error cost here?

“Why does Claude sometimes refuse to answer?”

Because it is trained on written principles, and a legitimate request can superficially resemble problematic usage.

In the vast majority of cases, simply providing context is enough: who you are, why you need it, and the professional setting.

“Do answers change if I ask the exact same question again?”

Yes, and that is normal: as seen in the first hour, generation is probabilistic.

If you need consistent formatting, the solution is not to repeat the question until it comes out right: it is to fix the format using tags, which we cover in Hour 5.

“Is it worth waiting for the new version?”

No. Versions come out every few months, and waiting means you never get started. What you learn—how to structure a request, how to select a model, how to verify outputs—applies across all versions.

3.4 Three Ways to Supply Source Material, and When to Use Them

The same document can be provided in three different ways, with distinct practical implications. Choosing wisely saves a great deal of time.

4. Practical Exercise of the Hour

Five business scenarios, one model choice for each. The exercise is not guessing the model name: it is knowing how to explain your reasoning.

Lesson Glossary

The key terms encountered throughout this guide, explained in a single line. Keep this handy: they will reappear across all subsequent sessions of the course.

Further Reading & References

The primary sources used to compile this course guide. All references are publicly accessible: if a particular figure catches your attention, consult the original source to verify it. That is precisely what we must also do when using artificial intelligence.

Primary Reference Book

Gianluca Bonomo, Niente paura, è solo IA. La guida completa per capirla, usarla e restare umani.

Official Tool Documentation

Anthropic's support portal and technical documentation (support.claude.com and platform.claude.com). This is the only source that remains current: model names, rate limits, and pricing evolve within months.

Where to Check Available Models

The model selector dropdown within Claude’s web interface always displays the active versions for your subscription plan: it is your most up-to-date guide.

Lesson Objectives

Understand why allowing employees to use personal accounts is a risk for the company, what changes with an enterprise subscription, and how to establish minimal yet sound governance.

What You Will Be Able to Do by the End

• Explain to executive leadership why the real difference is not the price.
• Know who decides whether conversations are used for model training.
• Recognize the roles of Data Controller and Data Processor.
• Draft the three core rules of a corporate AI policy.

THE DOCUMENTS ARE NOT YOURS

Data Leaks via Personal Accounts

Pasting corporate contracts into personal consumer accounts transmits sensitive assets outside company boundaries.

1. The scenario playing out in every company

There are no villains in this story. That is precisely what makes it so hard to address.

The company hasn't bought anything. Employees, however, have discovered that artificial intelligence saves hours of work. So everyone fends for themselves: some use the free tier, some pay for a personal subscription, some use company phones logged into private accounts.

It works brilliantly. And that is exactly the problem.

This is the Shadow AI we discussed in the second hour. The company does not know what documents have left the premises, cannot control how they are used, and, in the event of a dispute, cannot prove it took the necessary precautions to protect them.

1.1 Why it happens: it is not ill will

An employee pasting contract text into a personal assistant isn't circumventing a rule: almost always, they simply don't know one exists. They are doing their job with the fastest tool at their disposal.

It is the same dynamic that previously brought corporate files onto personal cloud storage and work conversations onto private messaging apps. The solution that worked then is the same one that works today: provide a corporate alternative before banning the personal one.

1.2 What is really at stake

The consequences of ungoverned usage are not textbook theoretical scenarios: they are four concrete situations, none of which requires bad faith to occur.

1. Loss of confidentiality for commercial information. The quote you are preparing, the margin on a contract, the bidding strategy for a tender. They don't need to end up with a competitor: it is enough that they left the corporate perimeter without a contractual basis.

2. Breach of a third-party obligation. Many contracts and non-disclosure agreements strictly forbid transferring materials to unauthorized parties. A service provider not covered by the contract is an unauthorized party.

3. Unlawful processing of personal data. Uploading a CV, a payslip, or a client list to a service without an adequate contract constitutes data processing without a legal basis. Along with everything that entails in the event of a complaint.

4. Reputational damage. It is what executive management fears most, and the only damage that cannot be remedied with a payment.

ZERO TRAINING ON CUSTOMER DATA

Enterprise Account Data Protection

Controller vs Processor under GDPR: enterprise inputs and outputs are never used to train frontier models.

2. Who decides what happens to the data

This is the focal point of the hour, and almost no one understands it with precision.

The same four questions, two very different answers.

2.1 On personal accounts, the user decides

On consumer plans (free, paid individual, and variations thereof), the choice belongs to the user: you can allow or deny your conversations being used to improve models. This choice is made in the settings and can be changed at any time.

The practical consequence also affects retention periods: if consent is active, content may be kept for a significantly longer period compared to users who opted out.

2.2 On enterprise products, the company decides

On commercial products—enterprise plans and API access—the default rule is reversed: data is not used to train models, unless the organization itself chooses otherwise.

This is not a setting an individual user can change on the sly: it is the contractual condition under which the service is delivered to the organization.

2.3 Controller and Processor: what matters under GDPR

There is a second aspect, less known yet far more important: with an enterprise subscription, the legal relationship fundamentally changes.

• The customer company is the Data Controller: it determines purposes and means, and issues instructions.
• The vendor acts as the Data Processor: it processes data exclusively on behalf of the customer and according to its instructions.

This is precisely the structure required by the GDPR whenever data processing is outsourced. With a personal account, that structure does not exist: the contract is strictly between the provider and the individual employee, and the enterprise is not a party to it.

2.4 What to specifically ask to see

When evaluating a vendor, "your data is safe" is not an acceptable answer. These four documents exist and can be requested: if they are not provided, that alone is telling information.

1. The Data Processing Agreement (DPA). This is the contract required by Article 28 of the GDPR between controller and processor. Without it, the company is processing personal data outside regulatory compliance.

2. The list of sub-processors. Who else touches the data, in what capacity, and in which country. This is needed to know where the data actually ends up.

3. Model training terms. They must state in writing that customer content is not used to train models, and specify under which circumstances, if any, it might be.

4. Data retention periods. How long content is retained, what happens upon contract termination, and how to request data deletion.

2.5 Where data physically ends up

This question always comes up, and warrants an exact answer: data is processed on the vendor's servers, which for major industry players are largely located outside the European Union, typically in the United States.

This does not make processing unlawful: it means it must be governed. The GDPR provides specific instruments for transfers to third countries, and any reputable vendor details them in their contract.

• Standard Contractual Clauses (SCCs), approved by the European Commission: the most widespread instrument, which must be appended to the contract.
• Adequacy decisions, where they exist for the destination country: these significantly simplify the controller's compliance position.
• Supplementary measures, such as encryption of data in transit and at rest, which the vendor must document.

3. Comparing the plans

What you are truly buying when upgrading from a personal account to an enterprise one.

The right comparison, however, is not between twenty and twenty-five euros. It is between twenty-five euros a month and the cost of a data breach: notifying the Data Protection Authority, potentially communicating with affected data subjects, regulatory fines, wasted operational hours, and reputational damage.

3.1 The calculation that convinces leadership

The question from senior leadership is always the same: why should we pay if it already works for free? Done properly, the business case is brief.

3.2 Five questions to ask your IT team before getting started

These are short questions, but the answers determine how much work is truly required. It is well worth asking them before committing to timelines with leadership.

1. Do we already have an enterprise identity system (single sign-on, centralized account management)? If so, license management is practically immediate; if not, extra setup work must be planned for.

2. Who revokes access when an employee leaves? If there isn't already an offboarding procedure, now is the time to write one: this applies to all software tools, not just this one.

3. Do we have an up-to-date Record of Processing Activities (ROPA)? A new entry must be added. It is a quick compliance task, but the first thing requested during an audit.

4. Who signs the Data Processing Agreement? It must be someone with authorized signing authority, not the person activating the licenses.

5. What do we tell employees, and when? The notice must be provided prior to activation, not after.

THE RIGHT ORDER OF OPERATIONS

The Right Order of Operations

1. Provide approved tools, 2. Establish clear policies, 3. Enforce compliance. Preemptive bans only drive usage underground.

4. The Console: the piece that changes everything

The most concrete difference between a personal account and an enterprise one is not in Claude's features: it is in everything surrounding them.

A single centralized hub to govern licenses, roles, and access.

4.1 The roles

• Owner — owns the organization, manages billing, and configures global settings.
• Admin — manages users, permissions, and shared projects.
• Member — uses Claude within the established rules.

4.2 Why employee offboarding matters

This is the classroom question that causes the most embarrassment. On a personal account, there are months of work: drafts, analyses, price lists, perhaps client data. The company cannot access it, cannot retrieve it, and cannot delete it.

With a console, however, access is revoked from an admin panel, and materials residing in shared projects remain with the company.

THE 3 KEY DOCUMENTS

The 3 Core Policy Documents

1. Acceptable Use Policy (3-min read) • 2. Employee Privacy Notice • 3. Offboarding Procedure.

4.3 Three things to put in writing before buying

Purchasing licenses is the easy part. What makes the real difference are three brief documents, each easily fitting on a single page.

1. The Acceptable Use Policy. What can be uploaded, what can never be uploaded, and who to consult in doubtful cases. It must be readable in three minutes, otherwise no one will read it.

2. Employee disclosure notice. Italian regulations require employees and their representatives to be informed when the company adopts artificial intelligence systems that impact workplace tasks.

3. The offboarding procedure. What happens to access permissions and workspace content when an employee leaves the company or changes roles.

4.4 What the administrator sees, and what they do not

This is the first question employees ask, and it deserves an unequivocal answer because it concerns their privacy: what can console administrators actually see?

Stating this in advance, and in writing, also has a practical effect: it removes the suspicion that is the primary reason people continue using their personal accounts.

5. Practical exercise for this hour

A simulated setup. Three simple lines: yet they represent the difference between governed adoption and Shadow AI.

Questions from the classroom

These come up in every course. It is worth having a short, honest answer ready, including for when a colleague asks.

“Do they actually read our data?”

On enterprise products, customer content is not used to train models by default: this is a contractual condition, not a courtesy.

This does not mean data stays on-premise: it is still processed on the vendor's servers. That is why formal contracts and evaluations are required, not mere trust.

“What if an employee secretly uses their personal account?”

This is the most frequent scenario, and also the reason why a ban alone does not work.

Legal liability before the Data Protection Authority remains with the company, which in that case has neither visibility nor proof of having taken necessary steps: literally the worst possible legal position.

“Can we provide the enterprise plan to only some departments?”

Yes, and it is often the most sensible way to start: begin with those handling the most sensitive data or those who stand to gain the greatest advantage.

The critical requirement is that the policy applies to everyone, including those who do not yet have a license. Otherwise, you are merely shifting the problem.

“Whose responsibility is it: IT or executive leadership?”

Both, and that is not a diplomatic answer. IT manages access and security; leadership decides what can be done with company data and assumes ultimate responsibility.

The role that is almost always missing is the third one: someone to train the team. Without that, the other two work in vain.

Lesson Glossary

The terms you encounter in this handout, explained in one line. Keep it handy: they will come up in all subsequent hours of the course.

Further Reading & References

The sources used to compile this handout. They are all public and accessible: if a piece of information interests you, go to the source and verify it. This is exactly what we ask artificial intelligence to do as well.

Vendor data privacy policy

Anthropic's privacy center explicitly distinguishes consumer products from commercial ones: for commercial products, by default, customer data is not used to train models.

Plans and pricing

Claude's pricing page and help center detail prices, seat minimums, and included features. These can change over time: always verify them.

Regulatory framework

Regulation (EU) 2016/679 (GDPR) for data controller and data processor roles; Italian Law No. 132 of September 23, 2025 for obligations toward workers.

Reference book for the course

Gianluca Bonomo, Niente paura, è solo IA. La guida completa per capirla, usarla e restare umani.

Lesson Objectives

Learn how to structure a professional prompt using tags, clearly separating instructions from the material to be analyzed, and achieve a consistent output that does not shift form with every attempt.

What You Will Be Able to Do by the End

• Recognize when a free-text prompt is no longer sufficient.
• Write a complete prompt using the six essential tags.
• Avoid the common mistakes that render a structured prompt useless.
• Turn a working prompt into a reusable template.

A SINGLE STREAM OF TEXT

The Flat Text Stream Challenge

The model receives a single continuous stream of tokens: trailing instructions can easily be lost or confused with document text.

1. The problem of ambiguity

For a short question, common sense is enough. When a document is involved, things change.

In the first hour, we saw that the model generates text by calculating which token has the highest probability of following next. There is no point at which it “understands” that one part of your prompt is a command and another part is material to examine: it has to deduce this from the text.

With a two-line request, it always succeeds. With a prompt containing an eight-page contract, the instruction gets drowned in the text and starts being treated as part of the contract.

Two ways to ask for the same thing: only one clearly defines the boundaries.

1.1 What the model actually sees

When you paste a contract followed by «summarize it in ten lines», the model receives a single strip of text. There is no «document» field and no «request» field: there is only a single stream, and the boundary between the two must be inferred from the text itself.

Over two lines, this works. Over eight pages, the final sentence is a drop in an ocean of clauses, and one of three things happens:

• the instruction is ignored, and the model does whatever seems most plausible given the document;
• the instruction is read as part of the document—for example, as if it were an additional clause in the contract;
• the instruction is executed, but only partially: whatever appears last in the prompt carries more weight than what appears in the middle.

Tags eliminate ambiguity at its root. They don't make the model smarter: they remove an uncertainty the model would otherwise have to resolve by guessing.

MEASURABLE RULES

Measurable Rules vs Vague Adjectives

Replace 'professional' or 'concise' with objective rules: third person, max 2 sentences, 'state not specified if missing'.

1.2 Why "write professionally" does not work

There is a second type of ambiguity, more insidious than the first because it does not concern prompt structure, but the words you put inside it.

Adjectives like professional, concise, effective, or engaging look like instructions, but they are not: each of us imbues them with a different meaning, and the model chooses the most common one—which is almost never yours.

THE 4 CORE TAGS

The 4 Core Prompting Tags

Modular prompt architecture: <context>, <documents>, <instructions>, <output_format>.

2. The six tags that truly matter

There is no need to learn dozens of them. These six cover any professional request.

A tag is written inside angle brackets, opened and closed: <instructions> … </instructions>, like a pair of brackets. Inside, you write in normal language. You are free to name them as you wish, but using them consistently turns a personal habit into an enterprise standard operating procedure.

2.1 A well-assembled prompt

Order matters: first who you are, then what you are looking at, then what you need to do, and finally how the output should look.

The same prompt from the example, assembled in full.

2.2 A complete, annotated prompt

Let's examine it in a real-world case: reviewing a supply agreement received from a client. First the prompt, then the rationale for each block.

The context block

<context> You are a senior legal counsel. We work for an Italian manufacturing SME. This contract was proposed to us by a client, and we need to evaluate it before signing. </context>

It defines the role and, crucially, whose side we are on: the same contract reads very differently depending on whether you are proposing it or receiving it.

The source material block

<documents> [full text of the contract here] </documents>

Source material only, without commentary. Any extra word added inside risks being read as part of the contract itself.

The instructions block

<instructions> List the termination clauses. Flag any clauses disproportionately unfavorable to the supplier. Indicate the reference section or clause number for each. </instructions>

One request per line, using action verbs. Three requests: if there were ten, some would inevitably be overlooked.

The format block

<output_format> Table with three columns: clause | risk level (high/medium/low) | section. Maximum ten rows. If any data point cannot be deduced from the text, write «not specified». </output_format>

Without this block, the response turns out discursive, twice as long, and different every time. The last line is the most important: it prevents the model from hallucinating or inventing details just to fill an empty box.

2.3 The other two tags: <example> and <thinking>

Six tags appear in the table, but so far we have used four. The other two are what elevate prompt quality to the next level, and are the core topic of the next hour.

<example>: showing instead of explaining

Describing your desired format in words often takes half a page and still leaves room for interpretation. An example of the output defines it in three lines, with zero ambiguity.

<example> Clause: Early termination by the client Risk: High Section: Clause 7.2 </example>

With this reference in place, every subsequent entry follows the exact same structure, identical field names, and the same ordering. It is the most effective way to lock in a consistent format.

<thinking>: prompting reasoning before answering

On tasks requiring multiple steps—comparing, calculating, cross-referencing two documents—asking the model to walk through its reasoning before concluding significantly reduces errors.

<thinking> First, identify all clauses addressing contract duration and termination. Next, evaluate who benefits under each clause. Only then populate the table. </thinking>

3. The mistakes we see most often

3.1 Too many tags

There is also the opposite error, and in classroom training it is almost as common: cluttering the prompt with labels until it becomes completely unreadable.

<request><tone>formal</tone><length>short</length><recipient><name>client</name><type>company</type></recipient></request>

A prompt structured like this is not more precise: it is simply harder to review and debug. Three or four well-separated blocks work far better than a dozen nested labels.

SAVE THE TEMPLATE

Save Successful Templates

When a prompt works reliably, save it as a template: next time you only need to swap the documents block.

4. From prompt to standard procedure

The real payoff is not a single output: it is the ability to repeat the exact same process tomorrow, and have a colleague do the same.

When a structured prompt works, save it. A plain text file is all you need. What you are saving is a template: next time, you only change the content inside <documents> and the rest remains untouched.

In the tenth hour, we will see how this personal habit evolves into a shared prompt library, and why it transforms how an entire department works.

4.1 From prompt to project

There is a subsequent step, which we will explore in the ninth hour. The parts of the prompt that never change—role, tone, constraints, output format—can be moved outside the prompt and written once, as permanent custom instructions in a project workspace.

From that moment on, every conversation begins with that context pre-loaded, leaving only the daily material and specific request for the prompt. It is the same principle behind tags, applied at a higher architectural level: separating what is fixed from what changes.

4.2 Three ready-to-use templates

These three templates cover a large portion of day-to-day office work. Copy them as they are: simply fill in what appears in square brackets.

Responding to a difficult email

<context> You are the customer support manager at [COMPANY]. Respond on behalf of the company, not in a personal capacity. </context> <documents> [the email received] </documents> <instructions> Draft a response that acknowledges the issue without conceding liabilities we have not yet verified. Propose a concrete next step. Do not promise turnaround times unless explicitly specified by me. </instructions> <output_format> Maximum twelve lines. Polite and concise tone. Provide two variations: one more formal, one more direct. </output_format>

Extracting data from a document

<context> I need to prepare an executive summary for leadership based on a technical document. </context> <documents> [the document] </documents> <instructions> Extract [the required items]. For each item, cite the originating page or section. If any data point is not present, write «not specified»: do not estimate or extrapolate. </instructions> <output_format> Three-column table: item | value | source citation. </output_format>

Preparing for a meeting

<context> Tomorrow I have a meeting with [COUNTERPART] regarding [TOPIC]. My objective is [GOAL]. </context> <documents> [materials: proposals, past emails, project specs] </documents> <instructions> List the top three points where we risk disagreeing. For each, identify the counterpart's strongest argument. Suggest a strategic question to gauge how much negotiating room exists. </instructions> <output_format> Bullet-point list, one page maximum. </output_format>

5. Practical exercise for this hour

Three complete prompts based on scenarios encountered in every company.

1. Commercial contract analysis—role, attached contract, what to look for, output table.

2. Customer complaint response—role, complaint text, required tone, maximum length, two alternatives to choose from.

3. Report executive summary—role, attached report, three key points to extract, bulleted format citing source pages.

For each exercise, write the prompt before opening Claude. Then test and refine it: almost always, something is missing in <output_format>.

5.1 How to test a prompt before sharing it with others

A prompt you have run once with success is not yet ready to be shared. Testing is quick and always consists of the same four checks.

1. The standard case test. A typical document. It must perform well: if it doesn't, the prompt is not ready.

2. The empty case test. A document where the requested information is absent. The prompt is effective if the response explicitly states that; it is dangerous if it invents something plausible.

3. The edge case test. An unusually formatted document, very short or very long. Useful to see where the prompt breaks down.

4. The colleague test. Hand the prompt to someone else without explanations. If they ask a clarifying question, the answer to that question must be added into the prompt.

5.2 The same prompt across different AI tools

A recurring question in corporate environments: if we switch AI assistants, are our prompts wasted? No, and it is worth understanding why.

1. The structure remains valid. Separating context, source material, instructions, and format helps any large language model: it is a matter of clarity, not a vendor-specific feature.

2. Sensitivity varies, not the principle. Some models adhere to tags more strictly, others less; some adhere better to length constraints. The prompt needs fine-tuning, not a complete rewrite.

3. Instructions for uncertain cases must be retested. "If you cannot find the data, write 'not specified'" is the line models respect most inconsistently. It is the first thing you should re-evaluate.

This is also a compelling argument for leadership: time invested in writing well-structured prompts is not a bet on a single vendor—it is a durable, transferable skill.

Questions from the classroom

These come up in every training session. It is worth having a concise, honest answer ready, including for when a colleague asks.

“Do I need to write like this even for a simple question?”

No. For a brief question, write naturally just as you speak: tags are needed when a document is involved, or when the output must be strictly repeatable.

The practical rule of thumb: if the prompt fits in two lines, keep it unstructured. If you are attaching a file, or if you plan to reuse it tomorrow, structure it.

“Must I use these exact tag names?”

You are free to name them as you wish: <role> would work just as well as <context>. Those presented here are the most widely adopted across the industry, making them easiest to explain to colleagues and reference in documentation.

What truly matters is using them consistently: that is how a personal prompt matures into an enterprise standard.

“Does this work with other AI assistants too?”

Yes. Modular block structure benefits any language model, because the problem it solves—separating instructions from source data—is vendor-independent.

What varies is how much each model benefits: some models are more responsive to prompt structure than others.

“What if the output still doesn't match what I want?”

Nine times out of ten, the format block is missing or too vaguely defined. «Make a table» is not enough: you need to specify columns, maximum row count, and what to write when data is unavailable.

The tenth time, providing an example of the desired output is what solves it: that is the exact technique we cover in the next hour.

Lesson Glossary

The terms you encounter in this handout, explained in one line. Keep it handy: they will come up in all subsequent hours of the course.

Further Reading & References

The sources used to compile this handout. They are all public and accessible: if a piece of information interests you, go to the source and verify it. This is exactly what we ask artificial intelligence to do as well.

Official prompt engineering guidelines

Anthropic's documentation dedicates a section to prompt structure and the use of XML tags: this is the primary source for this lesson.

The CO-STAR framework

For conversational prompts, the six-step method covered in the dedicated guide remains valid: Context, Objective, Style, Tone, Audience, Response. Tags make this framework explicit.

Reference book for the course

Gianluca Bonomo, Niente paura, è solo IA. La guida completa per capirla, usarla e restare umani.

Lesson Objectives

Learn how to make the model reason before responding, how to teach it a format using two examples instead of ten lines of instructions, and how to avoid paying twice for the same document.

What You Will Be Able to Do by the End

• Apply step-by-step reasoning to high-stakes tasks where errors are costly.
• Use two examples to lock down tone, structure, and output format.
• Understand prompt caching and how to structure prompts to take full advantage of it.
• Select the right technique based on the nature of the task.

REASON STEP BY STEP

Step-by-Step Reasoning

'Analyze step by step before concluding': makes reasoning verifiable and surfaces hidden clauses like auto-renewals.

1. Reasoning before answering

The simplest technique in the course, and the most underestimated.

Asking a model for the final answer alone is like demanding that someone calculate a complex formula in their head without scratch paper. Occasionally they get it right. Often they don't.

Chain-of-Thought reasoning consists of explicitly asking the model to think step-by-step before delivering the final answer. A single phrase is enough: «first analyze, then answer». Or using the <thinking> tag to make the request explicit.

The same question, two very different paths.

1.1 Why it works

Let's return to the mechanism covered in the first hour: the model generates one word at a time, and each word depends on the words already generated. If you only ask for the end result, it must get there in a single leap. If you instruct it to write out the intermediate steps, each step becomes foundational context for the next.

It is not a gimmick: it simply gives the model the scratchpad space to do what any of us would do on a notepad.

1.2 What it looks like in practice

When you request step-by-step reasoning, the output changes structure: first comes the analysis, followed by the conclusion. On a contract expiration review, for instance, you go from this:

The contract expires on December 31, 2026.

to this:

Analysis: Article 12 specifies a duration of 24 months from execution. The signing date at the bottom is January 15, 2025. Twenty-four months from January 15, 2025 leads to January 15, 2027. However, Article 13 provides for automatic renewal unless terminated with 90 days' prior written notice. Conclusion: The contract term ends on January 15, 2027; the absolute deadline for notice of termination is October 17, 2026.

The second answer is longer, but it is verifiable: every analytical step can be audited. And in generating it, an automatic renewal clause came to light that had vanished entirely from the first answer.

1.3 The limitations of visible reasoning

Prompting the model to reason significantly improves outcomes, but does not make it infallible, and it is crucial to know what it does not solve.

• Well-articulated reasoning can still be wrong. A well-ordered, confident presentation makes an erroneous conclusion sound more convincing: a well-documented cognitive bias, true among humans as well.
• It cannot add information that isn't there. If the data is absent from the document, no amount of reasoning will make it appear: at best, it will fabricate it more convincingly.
• It does not replace actual calculation. For complex arithmetic operations, always request explicit intermediate figures and verify them independently with a calculator.

TWO GUIDING EXAMPLES

Two Guiding Examples (Few-Shot)

Provide two clear examples to illustrate format and logic rather than isolated rules, ensuring all real data is anonymized.

2. Teaching through examples

Language models are extraordinarily adept at recognizing and replicating patterns. The fastest way to get the exact format you want is simply to show it.

Few-Shot prompting involves including two or three examples of the desired output within the prompt: a representative input paired with your target output. The model grasps the pattern and replicates it.

Two or three examples are plenty. Beyond that, you burn context window tokens with no added benefit, and risk the model memorizing specific trivia from the examples rather than the underlying pattern.

Examples belong inside the <example> tag, clearly segregated from real working documents: otherwise, the model may confuse the example with the document to be processed.

2.1 A complete example

Imagine needing to triage incoming customer support tickets. Describing the categories in prose takes half a page and still leaves gray areas. Two clear examples define them better than any lengthy explanation.

<example> Ticket: «The package was supposed to arrive on Tuesday; it's Friday and no one has shown up.» Category: LOGISTICS — Urgency: Medium — SLA Target: Within 24h Ticket: «You billed me twice for the exact same order.» Category: BILLING — Urgency: High — SLA Target: Within 4h </example>

With these two examples in front of it, subsequent ticket classifications follow the exact right format, with consistent category taxonomies and identical urgency scales. Without them, output drifts with every query: «logistics» becomes «shipping», «high» becomes «urgent».

2.2 When examples make things worse

There are three specific cases where adding examples causes harm, and it pays to recognize them.

2.3 Examples or instructions? How to choose

The same requirement can be conveyed by describing it in words or showing it with an example. They are not equivalent, and choosing between them follows a simple rule.

In practice, they are best used together: instructions dictate what to do, while examples demonstrate what the final output should look like. When the two contradict each other, the example almost always wins: which is why a flawed example does far more damage than a flawed instruction.

2.4 Where to source examples

The practical challenge is not understanding that examples are valuable: it is locating them without spending half a day searching. Here are three viable paths you can use immediately.

1. From work already done. Last year's document, a well-handled customer complaint response, a properly completed form. This is the best source because it already matches your style.

2. From an initial response edited by hand. You prompt without examples, refine the output until it is right, and that corrected version becomes the example for all future runs.

3. From a purpose-built example with synthetic data. This is the mandatory approach when actual material contains personal or confidential information.

LOAD ONCE, QUERY REPEATEDLY

Context Reuse and Prompt Caching

Load static background materials once at the start, then run all follow-up questions within the same thread.

3. Paying only once

The most technical section of this hour, explained without jargon. Essential for anyone submitting the same reference materials on a daily basis.

3.1 The problem

Each request is processed in isolation: the model retains no memory between API calls. This means that if you attach a 100-page manual and ask ten consecutive questions, that manual is re-transmitted and re-processed ten times. You pay ten times, and you wait ten times.

3.2 The solution

Prompt caching stores the unchanging initial segment of your prompt. On subsequent requests, if that initial prefix remains identical, it is read directly from cache: significantly faster and at a fraction of the cost.

You only pay full price for the static content once.

3.3 How savings are measured

Those working via the API can inspect exact figures: each response indicates how many tokens were read from cache and how many were processed from scratch. If cache read tokens remain at zero, caching is failing—and almost invariably because something shifted at the beginning of the prompt.

Those using the standard web chat interface do not see raw token counts, but can observe two equally telling indicators:

• Response latency. On long documents, the speed difference between the initial query and subsequent follow-ups is immediately noticeable.
• How quickly usage limits deplete. This is the most tangible metric available: if you work all day against the same large document without hitting message caps, your prompt workflow is properly structured.

3.4 When context reuse is unnecessary

Not all tasks benefit from caching, and forcing it where it isn't needed complicates your prompt without benefit.

• If source material changes with every prompt, there is nothing to reuse: each run starts from scratch regardless.
• If the document is short, the savings are negligible: on half a page of text, there is nothing meaningful to economize.
• If you ask a single question and close the session, there is no subsequent request to capitalize on the cached prefix.

The scenario where it delivers massive ROI is always identical: large, static reference material queried with many diverse questions. Case file audits, technical spec reviews, reference manual deep-dives.

3.5 What this means for non-programmers

While prompt caching is explicitly configured in code via the API, the underlying architectural principle transforms how you work even within the standard web interface. It translates into three daily habits:

1. Upload the material just once at the beginning. Then ask all your questions within that same conversation, rather than starting from scratch each time.

2. Do not modify the material midway through. Replacing the initial document with an edited version forfeits the caching benefit and causes confusion: from that point on, it is no longer clear which version prior answers refer to.

3. Keep separate conversations per document. One conversation per file/case works much better than a single sprawling thread where multiple documents accumulate.

4. Matching the right technique to the task

4.1 How they combine

The three techniques in this hour are not mutually exclusive: their true power is unlocked when combined, each occupying its rightful place in the prompt architecture.

1. Examples go first. They belong with the static material at the top of the prompt: they represent the constant part that pays off to reuse via cache.

2. The reasoning request goes into instructions. A single line: "first analyze, then conclude".

3. The format goes last. It is the constraint that must be freshest in the model's memory as it begins generating.

The result is a prompt retaining the same core structure from Hour Five, enhanced by two high-impact additions: an example block near the top and a reasoning directive in the instructions. It is not a new framework: it is the same solid scaffolding, utilized with greater precision.

5. Practical exercise for this hour

A single prompt uniting two techniques applied to a concrete corporate scenario.

Objective: extract key operative clauses from a commercial contract.

1. Draft the prompt using the XML tags from Hour Five.

2. Add step-by-step reasoning: "first identify the contract sections, then analyze each section one by one".

3. Add an example: a clause already extracted in your preferred format, placed inside <example>.

4. Place the contract and example first, followed by the specific question.

Then compare this output with the one generated by the plain prompt from the previous hour. That difference represents the entire value of this lesson.

5.1 A side-by-side comparison to test yourself

The most enlightening exercise in this hour is also the simplest: run the exact same request twice, and compare the outputs side by side.

1. First round. Take a real task of yours that requires multiple steps—checking deadlines, comparing two vendor quotes, classifying items—and prompt it naturally without special structure.

2. Second round. The exact same request, with two additions: "first analyze step-by-step, then conclude" and an example of the desired output.

3. Comparison. Place both outputs side by side in two columns and evaluate three aspects: what appeared in the second that was missing from the first; how the format changed; and how much time you would need to verify each of them.

This exercise convinces faster than any slide deck or lecture, because the test is run on real work where you already know the right answer.

Questions from the classroom

These questions surface in every cohort. Keep a concise, candid response ready for when colleagues ask.

“Does asking the model to reason cost more?”

Yes: slightly more tokens generated and a few additional seconds of latency. But missing an automatic renewal clause or miscalculating a contractual deadline costs exponentially more.

Furthermore, on repetitive document workflows, context caching recaptures most of that cost difference.

“Do I have to expose the reasoning process to the client?”

No. You can instruct the model to reason internally and output only the final conclusion: «analyze step by step, then output only the final response in three lines».

You retain the analytical quality improvement; only the displayed output changes.

“How many examples should I provide?”

Two or three. With only one, the model may overfit to specific details rather than the underlying pattern; beyond three, you consume context window tokens with diminishing returns.

If three clear examples still fail to yield the desired format, the issue is not the examples: it usually means the output format has not been clearly defined by the human.

“Does context reuse apply in the standard chat interface?”

Prompt caching is engineered primarily for API usage, where developers have explicit programmatic control.

However, the underlying design rule it teaches—placing static reference material first and variable queries last—is the optimal way to write long prompts in general, and becomes second nature when setting up workspace projects.

Lesson Glossary

The terms you encounter in this handout, explained in one line. Keep it handy: they will come up in all subsequent hours of the course.

Further Reading & References

The sources used to compile this handout. They are all public and accessible: if a piece of information interests you, go to the source and verify it. This is exactly what we ask artificial intelligence to do as well.

Prompt caching documentation

Anthropic's technical documentation describes how prompt caching works, the recommended ordering of components, and how to verify that it is active.

Step-by-step reasoning in the book

Niente paura, è solo IA, Chapter 6.3, covers chain-of-thought and few-shot prompting among intermediate prompting techniques.

Reference book for the course

Gianluca Bonomo, Niente paura, è solo IA. La guida completa per capirla, usarla e restare umani.

Lesson Objectives

Learn how to use Artifacts to generate and preview web pages, graphics, diagrams, and documents in real time, and understand how they genuinely create business value for non-programmers.

What You Will Be Able to Do by the End

• Recognize when an Artifact opens and why.
• Prompt for an Artifact so that it produces a useful result on the first attempt.
• Refine it iteratively step by step without starting over from scratch.
• Understand what can be handed off to a colleague and what cannot.

ARTIFACTS PANEL

The Artifacts Panel

Request functional assets instead of plain text: interactive dashboards, forms, and calculators displayed beside the chat.

1. What is an Artifact

It is the moment the output stops scrolling away in the chat stream and becomes an object you can actually work on.

When you ask Claude for something complex—a web page, code, a chart, a lengthy document—the output doesn't get buried in the chat thread. A dedicated side panel opens alongside it: the Artifact.

On the left the conversation continues; on the right your work takes shape.

Inside that panel, you can toggle between preview and code with a single click, watch the output update with every revision you request, revert to previous versions, and download a ready-to-use file.

1.1 What becomes an Artifact

Six types of content that open a dedicated panel.

In short: functional web pages, substantial source code, vector graphics, flowcharts, lengthy documents, tables, and structured datasets.

1.2 What it is not

It is worth clearing up three common misconceptions right away, as they lead to the greatest disappointments.

That said, most office work doesn't need an enterprise-grade application: it needs a tool that works this morning, for three people, on a specific problem. That is precisely where an Artifact is unbeatable.

2. Why it matters to non-programmers

This isn't a feature for developers. It's a feature for anyone who needs to communicate an idea quickly.

IMMEDIATE PROTOTYPING

Working Prototype vs Requirements Doc

Bringing colleagues a live, functional prototype accelerates alignment far faster than a hundred pages of specs.

2.1 The prototype to show in a meeting

Describing in words how a tool should work takes ten minutes and leaves half the room with a different picture. Demonstrating it visually takes the same amount of time and leaves no doubts.

2.2 The calculator to use or share

A quote estimator, an ROI calculation, an interactive table: tasks handled today with a messy spreadsheet, turned into a page that anyone can use intuitively.

2.3 The diagram updated live

A process flowchart or org chart generated from a verbal description and edited while reviewing it together. It is the fastest way to get everyone on the same page about how a process actually works.

2.4 The document rewritten right before your eyes

The least flashy use case is often the most valuable day-to-day: a lengthy document—a proposal, an SOP, a report—that stays open in a side panel and updates on command without being rewritten from scratch every time.

The difference compared to standard chat is tangible: asking "shorten the third paragraph" in a regular conversation produces the entire document again, forcing you to copy it out. With an Artifact, only that paragraph changes, while the rest remains untouched, word for word.

• «Make the tone more direct, but don't touch the pricing section.»
• «Add a five-line introduction for someone unfamiliar with the project.»
• «Rewrite the conclusion with a decision-maker in mind, not someone seeking an explanation.»
• «Turn this into a bulleted list, keeping all the same information.»

2.5 When an Artifact makes sense (and when it doesn't)

Not everything warrants becoming an Artifact. The deciding factor is whether you need the output as an actionable object or simply as readable text.

When in doubt, you can always ask Claude to convert an existing answer: "Turn that into a page I can present in a meeting." You don't have to start from scratch.

3. How to prompt effectively

Before walking through the full cycle, let's nail down the four details in the initial prompt that will save you two rounds of revisions.

1. Who will use it. «A sales rep will use it on the phone» changes everything: large fonts, few fields, no technical jargon.

2. What goes in and what comes out. The input data and the expected result, explicitly listed. This is the part people take for granted, and it's what matters most.

3. Where it runs. «It needs to work on a mobile phone» versus «it will be projected in a meeting» lead to two very different outcomes.

4. What it must not do. «It must not ask for personal data», «it must not save anything»: constraints stated upfront are worth ten corrections later.

ITERATIVE REFINEMENTS

Iterative Refinements

Four fast cycles of iterative polish: core calculation, visual chart, brand styling, and export/print button.

3.1 The iterative refinement cycle in practice

The most effective way to work with an Artifact isn't crafting the single perfect prompt: it's getting there across four quick iterations. Here is a real-world sequence for an ROI calculator.

3.2 Prompts that unstick a tricky revision

Sometimes you get stuck in a loop: you ask for a tweak, get something unexpected, try again, and make it worse. Four phrasing patterns almost always break the deadlock.

4. What can actually be put into production

There is, however, one immense value worth highlighting: showing up to a vendor with a working prototype demonstrating the exact desired behavior, rather than a dry requirements spec, slashes delivery times and misunderstandings dramatically.

4.1 Sharing the output

An Artifact can be downloaded as a standalone file that lives on its own: open it in any browser without needing Claude or an active connection to the service. It is the easiest way to hand it off to a colleague or attach it to an email.

4.2 Technical limitations to keep in mind

Three recurring limitations are essential to know before making promises to a colleague.

• It doesn't talk to your internal systems. An Artifact doesn't connect to your ERP or company archives: you supply the data yourself, by typing or pasting it in. True live integration requires the tools covered in Hour 11.
• It doesn't persist data on its own. When the page is closed, any data entered during the session is gone, unless browser-side storage was explicitly built in.
• It only scales so far. Beyond a certain level of complexity, you should stop: not because Claude can't build it, but because at that point you are building full-scale software, and real software demands formal engineering.

4.3 What to hand off to a developer

Once your prototype has served its purpose and you move to production, how you hand it off is the difference between two weeks and two months.

1. The downloaded Artifact file. It's worth more than any specification document: you open it and see exactly how it should behave.

2. A list of what is real versus what is dummy data. In the prototype, data is simulated and calculations are simplified: you need to explain the real-world business logic.

3. The edge cases that matter to you. What should happen if a field is empty, if a value is negative, or if the result cannot be calculated.

4. Who will use it and how many users there are. This information dictates half of the technical choices, yet almost no one writes it down.

5. Hands-on exercise

An ROI calculator dashboard built completely from scratch starting from a single sentence.

1. Ask for a page with three input fields: monthly tool cost, hours saved per week, and average hourly rate.

2. As output: monthly savings, months needed to break even, and a chart.

3. Then one change at a time: company brand colors, a print button, and a field for the number of people involved.

4. Download the file. It works even without Claude: it's yours.

5.1 What to try first

If you can pick only one project to try after this course, pick one that meets these three criteria: you know it inside out, it serves a small group, and today it relies on a clunky spreadsheet.

• The quick pricing calculator a sales rep uses on calls to give ballpark figures.
• The field service report a technician fills out on site, currently done on paper.
• The internal form someone fills in manually only to re-enter the data somewhere else.
• The recurring monthly chart manually recreated from the same source data.

These are all low-risk, high-visibility scenarios where no sensitive data is involved and the contrast with your current workflow is immediately obvious. It's the kind of test that proves in thirty minutes whether the tool adds real value.

Frequently Asked Questions

These come up in every single training session. It pays to have a concise, honest answer ready, especially when a colleague asks.

«Can I really put this into production?»

For a prototype, an internal tool, or a simulation, yes: what comes out works right away.

For anything handling customer data, processing payments, or customer-facing, you need professional technical review. An Artifact doesn't replace a software developer: it spares them the tedious groundwork.

«I can't code: can I still modify it?»

Yes, and that is actually the intended workflow: you request changes in plain language without ever touching the code.

The code tab is there for those who can read it; for everyone else, preview mode and natural conversation are all you need.

«If a change goes wrong, do I lose my work?»

No: every modification creates a new version, and earlier versions remain accessible. Just step back one version and pick up from there.

«What's the point if an outside vendor rebuilds it anyway?»

To communicate exactly what you want. Approaching a vendor with an interactive prototype that already behaves the way it should, rather than a static requirements spec, cuts timelines and eliminates misunderstandings dramatically.

It's the leap from "I'd like something along these lines" to "it must do exactly this."

Lesson Glossary

Key terms encountered in this handout, explained in a single line. Keep this handy: they will reappear throughout the upcoming hours of the course.

Further Reading & References

Sources used to create this handout. They are all public and accessible: if a particular data point interests you, go to the source and verify it. That is exactly what we ask artificial intelligence to do as well.

Documentation on Artifacts

Claude's Help Center explains what types of content open an Artifact, how to manage versions, and how to share them.

Chapter on practical prompting

Niente paura, è solo IA, Chapter 6.6, compiles prompt examples for creativity, study, work, and daily life.

Course reference book

Gianluca Bonomo, Niente paura, è solo IA. La guida completa per capirla, usarla e restare umani.

Lesson Objectives

Learn how to upload long documents, images, and scans, and extract structured data rather than generic summaries—and understand where human verification is strictly required.

What You Will Be Able to Do by the End

• Upload the right materials in the right format.
• Write extraction prompts that deliver structured data instead of useless summaries.
• Always demand the exact source for every extracted data point.
• Identify scenarios where figures must be cross-checked manually.

STRUCTURE AND REFERENCES

Structure and Visual References

Uploading original files preserves complex layouts, table columns, charts, and signatures without fragmentation.

1. Beyond plain text

The breakthrough isn't simply that Claude can read a PDF. It's that it can turn it into actionable data you can immediately work with.

Documents and images go in; structured output comes out.

As input, you can provide text, PDF documents, images, screenshots, and scans. As output, you can request tables, lists, spreadsheet-ready files, and structured analytical summaries.

The difference from simple optical character recognition (OCR) is that Claude doesn't merely transcribe: it links a figure to the financial statement line item it belongs to, a date to its corresponding deadline, and a clause to the article that references it.

1.1 What you can upload

• PDFs even hundreds of pages long, within the limits of your subscription plan and file size.
• Images: photos of documents, screenshots, video frames, diagrams.
• Spreadsheets and plain text files.
• Scanned documents without selectable text: here, scan quality makes all the difference.

Practical file limitations

There are thresholds beyond which you should change strategy, and it pays to know them before you get stuck facing a tight deadline.

• Individual file size. Very heavy documents must be split. A 200-page PDF with high-resolution images often weighs more than a 1,000-page text-only document: file size matters, not page count.
• Number of files per conversation. There is a cap, and beyond a certain volume, it makes far more sense to move them into a Project knowledge base.
• The total capacity fitting into the context window. The math from Hour 3 applies: documents, prompts, and responses all share the very same space.

1.2 How it differs from copy-pasting

The most common question asked in training is: why upload the file if I can just select the text and paste it? There are three concrete reasons.

1. Structure is preserved. When manually copying from a PDF, tables break apart and columns get scrambled. By uploading the file, layout formatting is interpreted alongside the text.

2. References remain intact. Page numbers, chapter headings, and the exact position of an entry in a table: these are precisely the details you need for verification, which are lost when copying and pasting raw text.

3. Non-text elements can be read too. A chart, a diagram, a signature, a checked checkbox: you can't paste them, but the model can read them.

2. The methodology

Uploading a document and typing "summarize this" is the most common waste of potential seen in the classroom.

A generic summary of a financial statement helps no one: what you need is total revenue, operating margin trends, and debt position. Four steps, always the same.

From fifty pages to a table ready to paste into a spreadsheet.

1. Upload the document.

2. State what it is and who you are. «This is the 2025 financial statements of a manufacturing company; I am the financial controller.»

3. Ask for specific data points, not a vague summary. «Extract revenue, EBITDA, and cash flow for the last three fiscal years.»

4. Specify the output format. «In a table, one row per metric, including the source page number.»

These are the XML tags from Hour 5 applied to a document: <context> explains who you are and what the file is, <instructions> specifies what to look for, and <output_format> dictates the layout.

ALWAYS REQUEST THE SOURCE

Always Request Page Citations

Requiring a source page number column turns 30 minutes of manual verification into a 30-second spot check.

2.1 The game-changing trick: asking for the source

2.2 Four prompt templates that almost always work

For uploaded documents, these four formulas cover the vast majority of day-to-day office tasks. They are written to be copied and tailored.

Extract into a table

From the attached document, extract all cost items into a three-column table: description, amount, and source page number. If an amount is not stated, write "not stated": do not calculate or estimate it.

The third column is the most crucial: it allows you to verify the data in thirty seconds instead of thirty minutes.

Compare two documents

I am attaching two versions of the same contract. List only substantive differences, ignoring wording changes that do not alter legal meaning. For each difference, indicate the clause/section and which version is more favorable to us.

Summarize for a specific audience

Summarize the attached report in ten lines for a non-technical CEO who has three minutes. Conclude with the specific decision required of them.

A summary without a defined audience is almost always useless: the reader's role determines what must be kept and what can be cut.

Read an image

This is a photo of the whiteboard at the end of the meeting. Transcribe everything you can read, preserving the column structure. Where handwriting is not clearly legible, flag it as [illegible] rather than guessing.

CROSS-REFERENCING DOCUMENTS

Cross-Referencing Documents

Compare outbound proposals against countersigned contracts to pinpoint every covert discrepancy or markup.

2.3 Working with multiple documents simultaneously

The scenario that saves the most time by far isn't reading a single document: it's cross-referencing multiple files. Three situations occur in every company.

Version comparison

Two versions of the same contract, or two revisions of technical specifications. Asking only for substantive differences, while ignoring rephrasing, turns half a day of manual cross-reading into a ten-minute verification.

Cross-document consistency

I am attaching the proposal we sent and the signed contract they returned. List every point where the contract diverges from the proposal, citing references in both documents for each discrepancy.

It is the check that in theory is always performed, but in practice, under tight deadlines, is rushed and error-prone. Here it takes two minutes.

Cross-document search

Ten documents, a single question: «Which of these contain a confidentiality obligation, and for what duration?». The actionable output isn't a vague summary: it's a pinpointed list with exact citations across each document.

3. Where human oversight is essential

Multimodality is the most rewarding feature, and the one that demands the highest discipline.

3.1 Three checks that take two minutes

You don't need to re-read everything: you just need to check the right things. On extractions from long documents, these three checks catch almost every mistake that matters.

1. The total. If you extracted financial amounts, sum them up and compare the result against the total shown in the document. If it doesn't match, an entry is either missing or duplicated.

2. The boundaries. Check the first and last entries of the list: boundary errors—such as a header line misread as data or a skipped final row—are concentrated there.

3. Three random entries. Spot-check three sample rows against the source document using the page references. If all three match, the extraction is reliable; if even one fails to match, it must be redone.

3.2 Practical limitations to be aware of

There are three situations where automated document reading falls short, and it's far better to know them before finding out in front of a client.

• Low-quality scans. A PDF from a skewed or blurry photocopy will be misread, just as you would struggle to read it. If the document is critical, rescan it.
• Complex tables. Merged cells, multi-tier headers, and table footnotes: these are prime spots for values to land in the wrong column. Always spot-check them.
• Very long documents. A multi-hundred-page file fits inside the context window, but asking a generic question («summarize it») yields mediocre results. Break it down into targeted questions, chapter by chapter.

BEFORE UPLOADING: VERIFY

The External Consultant Rule

Would you email this document to an outside consultant without NDA permission? If no, do not upload it.

3.3 The boundaries: what you can safely upload

Everything covered in this hour hinges on the decision made in Hour 4: which account tier you are using. It is worth reiterating here, because document analysis is where the temptation to upload anything and everything is strongest.

4. Hands-on exercise

A fifty-page report and a deliverables table.

Write the complete prompt before uploading the file:

Then run it, and spot-check three numbers against the original PDF. Note how many were accurate: this is the most valuable takeaway you will gain from this lesson.

4.1 An exercise with your own document

This exercise is far more impactful if you run it on a document whose content you already know well: it is the only way to genuinely evaluate the output quality rather than blindly accepting it.

1. Choose a document you already worked through manually in recent months: a tender specification, financial statements, or a contract from which you previously extracted data.

2. Request the exact same extraction, specifying page citations and clear instructions on what to do when data is missing.

3. Compare against your manual work. Count: how many entries match, how many are missing, how many are incorrect, and how many it found that you missed.

4. Time both approaches, including verification. That number will be your most persuasive argument when pitching this to anyone in your company.

The final finding of this exercise is almost always the most eye-opening: the "items you overlooked" count is almost never zero.

Frequently Asked Questions

These come up in every single training session. It pays to have a concise, honest answer ready, especially when a colleague asks.

«Can I upload any document?»

Technically, almost anything. Legally and compliance-wise, no: the rules covered in Hours 2 and 4 apply, depending on the document's sensitivity and the account tier you are using.

The question to ask isn't "can it read this?" but rather "is this content permitted to leave our company perimeter?".

«How can I trust an extraction from a 100-page document?»

You shouldn't trust blindly: you must verify. That's why you always require precise citations (page, section, row) alongside every extracted item.

Spot-checking five random entries takes two minutes and tells you almost everything about the reliability of the entire extraction.

«Why does it sometimes misread a number that is clearly written?»

This happens primarily in tables with merged cells or hierarchical multi-row headers, where a visual structure obvious to human eyes becomes ambiguous when flattened into text.

This is why extractions from complex tables must always be spot-checked, even when the first ten rows look flawless.

«Can this be used to process invoices automatically?»

For high-volume, recurring automated pipelines, dedicated document-processing solutions integrated with your ERP are far better suited and should be evaluated separately.

For low volumes or ad-hoc checks, however, this approach works remarkably well and is ready to use right out of the box.

Lesson Glossary

Key terms encountered in this handout, explained in a single line. Keep this handy: they will reappear throughout the upcoming hours of the course.

Further Reading & References

Sources used to create this handout. They are all public and accessible: if a particular data point interests you, go to the source and verify it. That is exactly what we ask artificial intelligence to do as well.

Technical limitations on documents

Anthropic's documentation outlines file size and page count limits for attached documents, which vary by model and subscription tier.

Hallucinations and verification

Niente paura, è solo IA, Chapter 8.1: why a model can state an incorrect fact with absolute confidence.

Course reference book

Gianluca Bonomo, Niente paura, è solo IA. La guida completa per capirla, usarla e restare umani.

Lesson Objectives

Learn how to create a Project, write robust custom instructions that stand the test of time, and build a knowledge base that delivers accurate, verifiable answers rather than mere plausible guesses.

What You Will Be Able to Do by the End

• Understand the difference between a standalone chat and a Project.
• Write project instructions that explicitly define what not to do.
• Curate which documents to upload and which to leave out.
• Establish who updates the knowledge base and how often.

ENTERPRISE PROJECTS

Enterprise Project Architecture

The three layers: persistent project instructions on top, knowledge base in the center, and child chats beneath.

1. What is a Project

It is the turning point where the assistant stops being generic.

Up to this point, we've worked in standalone conversations. That works, but has a structural flaw: context dies when you close the tab. The next day you re-upload files, re-introduce yourself, and re-explain your preferred output format.

The same four key differences you notice after a week of use.

A Project is a dedicated workspace built around a specific goal—such as "HR Policy Assistant," "Proposal Generator," or "Contract Reviewer"—where the foundation stays permanently in place.

1.1 What it consists of

Two permanent foundations, inherited by countless conversations.

• Project instructions: who Claude is in this workspace, how it should reply, and what it must never do. They apply across every chat within the Project.
• The knowledge base: files uploaded once—policies, price lists, manuals, standard contracts—that remain permanently available.
• Conversations: dynamic day-to-day chats that all start fully pre-briefed.

1.2 When to use a Project vs. a standard chat

Not every task warrants a Project. The deciding factor is simple: is this a recurring workflow?

ASK BEFORE PROCEEDING

From Output Generator to Collaborator

'If information is missing, ask clarifying questions before proceeding; never invent facts or extrapolate unstated terms.'

2. Project instructions

This is the section most people rush through, yet it determines whether the Project succeeds or fails.

An effective prompt instruction addresses five core elements.

2.1 A complete real-world instruction example

Here are the custom instructions from a real-world project used by a professional services firm for client correspondence.

You are the firm's editorial drafting assistant. Write in professional Italian, in the second-person plural, with a polite and concise tone: never informal, never bureaucratic. Every communication closes with the firm's standard sign-off found in the document 'templates.docx'. Never promise response times or specific outcomes: if the draft requires them, insert [TO BE CONFIRMED] and flag it at the bottom. When citing a regulation, always specify the article and subsection; if unsure of the reference, state so explicitly rather than reconstructing it. If you lack sufficient information to draft the response, ask before proceeding: do not invent case details.

These are five sentences, yet they capture everything that would otherwise have to be repeated in every single chat: tone, formatting, boundaries, and behavior in uncertain scenarios.

2.2 Common pitfalls in project instructions

Project instructions are the most delicate part of a project, and mistakes tend to follow the exact same patterns.

2.3 A second example: the technical support project

The first example covered business correspondence. This one is entirely different—product technical support—and demonstrates that the underlying structure remains identical.

You are the Tier-1 technical support assistant. Our products are documented in the manuals stored in the knowledge base: they are the sole authoritative source. Always respond by citing the exact manual and section where you found the information. If the answer is not in the manuals, state so explicitly and offer to escalate the ticket to Tier-2 support. Do not extrapolate an answer by analogy with other products. Never suggest interventions that require opening the hardware device: in those cases, point to the official authorized service procedure. Write in plain language, for a non-technical customer. Maximum eight lines.

The two lines that make all the difference are the second and third: they mandate citing the source and forbid filling gaps by analogy. Together, they transform a generic assistant into a trustworthy support tool.

10 CURATED FILES BEAT 100

Knowledge Base Quality

10 curated, authoritative files easily outperform 100 messy drafts. Routinely purge outdated documents.

3. The project knowledge base

A few up-to-date files beat an entire messy archive.

3.1 The question that governs everything: who updates it?

A project is a living system. Regulations change, price lists get updated, SOPs get rewritten. An unmaintained project, within six months, becomes an archive of false information delivered with absolute confidence.

• Assign an owner by name and surname, not a generic department.
• Set a recurring update schedule: an actual date on the calendar.
• Define the triggers for out-of-cycle updates: a new collective bargaining agreement, a revised price list, an amended procedure.

3.2 How to organize the knowledge base

A project knowledge base is not a shared drive dump: it is a curated selection. Four criteria, applied to every file before uploading, keep it valuable over time.

1. Is it up to date? An outdated document coexisting with the current version is worse than a missing document: the model has no way of knowing which one takes precedence.

2. Is it authoritative? A colleague's rough draft and an approved standard operating procedure look identical to the model. Only the latter belongs in the project knowledge base.

3. Is it genuinely needed? If a document hasn't been useful in any of your last ten conversations, it wastes context space and attention without adding value.

4. Can it be uploaded? The security perimeter established in Hour 4 applies here—with an added complication: in a shared project, other colleagues will see it too.

A simple yet remarkably effective tip: add a header line at the top of every document stating its effective date and purpose. «Price list effective January 1, 2026; supersedes previous version». The model reads this and uses it to determine document precedence.

3.3 Documents or instructions? What belongs where

This is the most common dilemma when creating a first project: should a piece of information be written into the instructions or uploaded as a document? The rule of thumb is straightforward and rarely fails.

4. Project knowledge base vs. web search

The question that always surfaces, and that deserves a clear-cut answer.

4.1 When a project stops working properly

A project ages, just like any corporate process. Three warning signs indicate it's time for maintenance.

SEPARATE PROJECTS FOR SEPARATE ACCESS

Permissions and Access Control

Project members can view all attached files: managing distinct user roles and confidentiality tiers requires dedicated projects.

4.2 Projects and data privacy

A project gathers the most valuable departmental knowledge in a single repository. That is what makes it so powerful, but it also demands two key precautions.

• Everyone who joins sees everything. There are no granular permissions within a single knowledge base: adding someone to the project grants them access to every document it holds. If access levels must differ, you need separate projects.
• Outputs inherit internal content. An answer generated inside the project can quote or reference any uploaded document. Before forwarding a draft to a client, review it with that in mind.

5. Hands-on exercise

Let's build an internal assistant that answers questions on company policies.

1. Upload three real documents: internal company bylaws, vacation/leave policy, expense report procedure.

2. Draft the custom instructions following the five components from the Chapter 2 table.

3. Test with five real questions—the kind of requests that actually arise in the office daily.

4. Then test a question that the documents do not cover.

5.1 How to create a Project in ten minutes

The fastest way to get started isn't overthinking the design: it's reverse-engineering it from a chat that already worked.

1. Find a past chat conversation that went particularly well for a recurring task.

2. Ask the model itself to extract instructions: «Based on this conversation, draft custom instructions for a project so I can reliably reproduce this exact result». You will get a solid draft in thirty seconds.

3. Trim aggressively. The draft will be too long: retain only what applies to every future conversation, not what was specific to that one case.

4. Add the two lines that are always missing: what to do when information is not found, and the required output format.

5. Upload two or three core reference documents, not twenty.

The resulting Project won't be perfect, and that's completely fine: you will refine it after the third conversation, when you see what it actually lacks.

Frequently Asked Questions

These come up in every single training session. It pays to have a concise, honest answer ready, especially when a colleague asks.

«How many documents can I upload?»

The technical ceiling is high, but the practical threshold is much lower: ten well-chosen documents work far better than a hundred random files.

The litmus test for every file is: «If a new hire were tasked with this job, would I give them this to read?». If the answer is no, leave it out.

«Do custom instructions apply to files uploaded later?»

Yes: they govern the entire lifecycle of the Project and all chats created within it, regardless of when a document was added.

«If I edit the instructions, do past conversations change?»

No. Completed conversations remain exactly as they are; revisions apply only to subsequent chats.

This is reassuring: it means you can continuously refine your instructions without fear of breaking or altering past deliverables.

«Is it better to have one large Project or several focused ones?»

Multiple small, focused projects, almost always. A Project should map to a specific workflow, not an entire department: «Client Proposals» works, «Sales Department» does not.

When your instructions start reading like «if it's about this... otherwise if it's about that...», it's a clear signal that you need two distinct Projects.

Lesson Glossary

Key terms encountered in this handout, explained in a single line. Keep this handy: they will reappear throughout the upcoming hours of the course.

Further Reading & References

Sources used to create this handout. They are all public and accessible: if a particular data point interests you, go to the source and verify it. That is exactly what we ask artificial intelligence to do as well.

Documentation on Projects

Claude's Help Center explains how to create a Project, upload documents, and what limits apply per plan.

Retrieval-augmented generation in the book

Niente paura, è solo IA, Chapter 5.2, explains the principle of retrieval-augmented generation: having the model answer based on your documents.

Course reference book

Gianluca Bonomo, Niente paura, è solo IA. La guida completa per capirla, usarla e restare umani.

1. Sharing a Project

This is the transition where AI stops being an individual skill and becomes a way of working.

In business plans, a project created by an individual can be shared with the organization or selected colleagues. This means everyone works from the same knowledge base and the same instructions.

One project, multiple departments, a single source of truth to update.

1.1 Three Projects That Actually Work

THE COST OF SILOS

The Cost of Knowledge Silos

Five team members reinventing the exact same prompt from scratch: hours and budget squandered in isolation.

1.2 What Happens When You Don't Share

The cost of not sharing doesn't appear on the balance sheet, which is why it goes unnoticed for months. Yet it takes three very recognizable forms.

1. The same work done five times. Five people independently fine-tune how to generate a proposal. Each spends half a day on it, and they end up with five different results.

2. Quality that hinges on the individual. The customer receives an excellent or mediocre reply depending entirely on who writes it, and no one knows why.

3. Expertise that leaves when the person leaves. When the employee who 'knows how to do it' transfers to another department or leaves the company, everything restarts from scratch: what they had learned was never documented anywhere.

These are the exact same issues that led companies over the years to draft standard operating procedures and document templates. The subject matter is new, but the remedy is time-tested: write it down in one central place.

FEW BUILD, ALL BENEFIT

Few Build, Everyone Benefits

Not everyone needs to engineer prompts from scratch: 1-2 prompt builders per team, enabling everyone else to execute easily.

1.3 Who Builds and Who Uses

Sharing works when you accept an idea that isn't always popular in companies: not everyone needs to become an expert at prompt engineering.

It's the same division of labor that already exists for corporate document templates: someone designs them, everyone uses them. Nobody expects every colleague to know how to configure a stylesheet.

ENTERPRISE PROMPT LIBRARY

Enterprise Prompt Library

Not fragmented notes, but structured prompt cards with explicit placeholders and strictly anonymized test data.

2. The Prompt Library

An effective prompt is not a personal talent: it is a company procedure that no one had written down yet.

Nine personal versions, or one versioned and shared standard.

In nearly every company we help onboard, the situation is the same after a few months: everyone has their own prompts, stored in personal files or browser history. They work, but no one knows which ones are best or why.

• An approved prompt, with an owner and a version number.
• Stored where everyone can find it, not buried in someone's inbox.
• Updated whenever a better way of phrasing the prompt is discovered.

2.1 What Makes a Prompt Reusable

A prompt that works for you is not yet a prompt that works for the company. Making that transition requires three additions, and they are always the same.

1. The title specifies when to use it, not just what it is. "Responding to a Tier-1 Customer Complaint" is a solid title; "Complaints Prompt" is not: it tells anyone unfamiliar with the context nothing about whether it fits their needs.

2. Placeholders are immediately obvious. Use an unmistakable convention, such as [CUSTOMER NAME] or [AMOUNT], so anyone reusing it sees at a glance what needs to be filled in.

3. It includes an example of the expected output. A two-line sample is worth more than half a page of explanation, instantly making clear whether the prompt delivers what's needed.

2.2 A Prompt Template, Field by Field

This is the template sheet we recommend using: six fields, takes five minutes to fill out, and makes the prompt immediately usable by anyone.

3. Minimal Governance

Technology does not solve an organizational problem. It only accelerates it.

3.1 The Four Minimal Rules

Governance sounds like a big word for something that fits into four lines. These four rules are sufficient for an organization of any size, and far more effective than a twenty-page policy document that no one ever reads.

1. Every shared project has a designated owner with a full name. This person decides what goes into the project instructions and reference document base.

2. Every project has a set review date. Even just "review in January." Without a date, it will never get reviewed.

3. Personal data and confidential documents do not belong in a shared project's document base unless an explicit assessment has approved it.

4. Outputs are reviewed by a human before leaving the company. Always, with zero exceptions made for tight deadlines.

3.2 What Should Not Be Shared

Sharing also has boundaries, and it pays to define them from day one: a clear list of what stays out makes it much easier to say yes to everything else.

1. Individual employee files: disciplinary actions, performance reviews, HR matters. These require a strictly confidential space, not a departmental project.

2. Documents bound by third-party obligations: NDA-covered materials, tender/bidding documents, and client information not authorized for broad internal dissemination.

3. Unapproved drafts. In a shared project, a draft looks identical to an official document and will be treated as authoritative.

4. Credentials in any form. This is not an edge case: passwords and API keys accidentally slip into operational documents far more often than people realize.

4. Which Projects Are Worth Sharing

GETTING STARTED IN THE ENTERPRISE

Getting Started Across Teams

Skip endless committee meetings: ask 5 colleagues 3 targeted questions about repetitive chores and friction points.

4.1 Where to Start, Practically

The fastest way to kick off collaboration isn't a meeting: it's a round of questions. Three questions, asked to five different people.

• “What is the task you repeat most often, in exactly the same way?” — that is where your first project lies.
• “What have you asked an AI assistant this week?” — the answer tells you where the company really stands, far better than any internal survey.
• “What don't you trust it to do?” — that gives you the list of concerns to address in your policy, voiced by the very people who will need to follow it.

From five answers, you almost always discover a shared project that delivers genuine value and gets adopted without having to convince anyone.

4.2 How to Tell If It's Working

Measuring hours saved is the most obvious route, but also the least convincing: nobody can prove it and everyone is skeptical. These four indicators require no special tools to observe and reveal far more.

1. The ratio of active shared project users versus total eligible staff. If it falls below 50%, you have an adoption challenge, not a software limitation.

2. How many new prompts enter the library each month. If additions drop to zero after month one, the initiative has already stalled, even if no one has admitted it yet.

3. How many net-new capabilities have been unlocked. This is the most honest metric: not just "doing the same task faster," but "running analyses we simply couldn't do before."

4. Onboarding duration for new team members. A department equipped with shared projects and prompt templates ramps up new hires in a fraction of the time. It is immediately noticeable and makes a compelling business case to executive leadership.

5. Practical Exercise for This Hour

A project spanning three departments, configured together.

1. Document base: price list, sales terms, three benchmark proposal templates.

2. Instructions: tone of voice, proposal structure, what never to promise.

3. Roles: who owns it, who updates the price list, who has usage-only access.

4. Validation testing: test it against a real customer inquiry and benchmark the output against the latest manually crafted proposal.

5.1 The Project Registry

A single document, with one row per project, eliminates nearly all governance issues. Maintain it in a spreadsheet and update it in under a minute.

Common Questions from the Classroom

These questions arise in every course. It helps to have a concise, honest answer ready, especially when asked by a colleague.

“Who should keep the library updated?”

One person per business unit, not one person for the entire company. A single company-wide owner becomes a bottleneck, and the library withers away within three months.

The responsibility is lightweight: approve new prompts and prune obsolete ones. Half an hour a month, nothing more.

“What if someone writes a flawed prompt?”

It happens, and it's less damaging than it sounds: a bad prompt produces visibly incorrect answers, and users notice immediately.

The real danger is different: a prompt that works flawlessly but embeds an outdated instruction, such as an expired deadline or obsolete tax rate. That is why every project needs a scheduled review date.

“Do we need a dedicated tool for the prompt library?”

No. A shared folder with one document per prompt works perfectly, and has the advantage of requiring no software procurement approvals.

A dedicated platform makes sense once you manage dozens of prompts and require advanced search and version control—a great problem to have.

“How do I convince colleagues to share their prompts?”

Not by asking them to share, but by asking them to show. Ten minutes during a team meeting where someone demonstrates how they automated a tedious task is worth more than any corporate memo.

Sharing happens naturally the moment a colleague asks: “Can you send me that?”

Lesson Glossary

Key terms encountered in this booklet, explained in a single line. Keep it handy: they will reappear throughout the upcoming lessons.

Further Reading & References

The sources referenced in creating this booklet. All are publicly accessible: if a particular detail catches your attention, consult the original source to verify it. That is precisely what we instruct artificial intelligence to do as well.

Sharing Capabilities in Enterprise Plans

The Claude Help Center details how projects are shared and which permissions apply to each organizational role.

Human-Machine Collaboration

Niente paura, è solo IA, Chapter 10.3: AI as a force multiplier for team capabilities, rather than a replacement.

The Course Reference Book

Gianluca Bonomo, Niente paura, è solo IA. The comprehensive guide to understanding it, using it, and staying human.

1. Out of the Browser

As long as the assistant lives in a browser tab, your data remains behind glass: you have to feed it manually.

The desktop application for Windows and Mac places Claude right alongside your everyday software. The advantage isn't aesthetic: from there, it becomes possible to connect it to local files and corporate systems.

Up to this point in the course, the workflow has always been the same: open the file, copy, paste into chat. It works, but every step is manual, and every manual step is an opportunity for error.

1.1 What This Means in Practice

Until now, we've always worked the same way: open a page, type, paste materials. It works, but has an obvious limitation: you must manually bring everything it needs, every single time.

The next step is giving the assistant direct access to where your data already lives.

It's a tremendous leap in convenience, and also the exact moment when questions about security and permissions stop being theoretical: from here on, the tool no longer waits for you to feed it data—it goes and retrieves it.

1.2 Three Types of Connectivity

“Connecting the assistant to our systems” encompasses three very different approaches in terms of effort, cost, and risk. Distinguishing them prevents confusing debates within the organization.

For almost all small and medium-sized businesses, the sensible roadmap follows this exact sequence: start with the first tier, and move to the second only after the first has proven its value.

MCP: THE OPEN CONNECTION STANDARD

MCP: The Universal Standard

Model Context Protocol: the open 'USB port' connecting AI assistants directly to databases, APIs, and ERP systems.

2. The Model Context Protocol

The technical part of the hour. It can be explained best with a single metaphor.

Every corporate system speaks a different language: the ERP, the document archive, the database, the code repository. Building a custom integration for each one is expensive and quickly becomes obsolete.

The Model Context Protocol (MCP) is an open protocol published by Anthropic that defines a standard way to expose data and tools to an assistant. It's like an electrical wall socket: behind the wall there can be any wiring system, but the plug is always universal.

A single protocol instead of ten custom integrations.

2.1 Why We Needed a Standard

Until recently, every connection between an assistant and a business application had to be custom-built: dedicated development work for every pair of tool and system. With five assistants and ten ERPs, you faced fifty potential connectors, and nobody ever built them.

A standard inverts the math: each system exposes its data just once, in a format any assistant can read. Fifty custom development jobs shrink to fifteen reusable components.

In practice, for your business this means two things: the connector for your software likely already exists, and if you switch AI models tomorrow, your investment isn't thrown away.

START WITH LEAST PRIVILEGE

Start with Least Privilege

Five safety checks before connecting: read-only access, single folder scopes, audit logging, and an instant kill switch.

2.2 What to Ask a Vendor Before Connecting Anything

Connecting an assistant to your ERP or document management system is not a technical decision: it is a data governance decision. Here are five questions to ask before signing, not after.

1. What specific data does it access? Not just "the archive," but which folders, tables, and exact fields.

2. Read-only or read-write access? An integration limited to reading carries managed risk; one that can modify or delete data introduces risk of an entirely different magnitude.

3. Who sees what? Does the connector honor existing user access rights within the underlying system, or does it bypass them, exposing equal visibility to everyone?

4. What audit trail is logged? Is there an immutable log of who queried what and when? Without audit logs, you have zero evidence if a dispute arises.

5. How do you pull the plug? There must be an immediate kill switch to revoke access, along with designated staff trained to use it.

2.3 Three Common Enterprise Integrations

Beyond the theory, these are the three integrations most frequently deployed in small and medium-sized businesses, delivering the quickest return.

1. The document repository. Read-only access to select folders. Used to answer questions about operational procedures, contracts, and technical specifications without manual hunting. It delivers the best utility-to-risk ratio of any integration.

2. The customer support or ticketing system. Reading tickets to extract category trends, summaries, and recurrence patterns. Write capabilities—such as closing tickets or emailing clients—are kept strictly off-limits, at least initially.

3. The codebase repository for software teams. This offers the most quantifiable productivity gains because the technical context lives entirely within the repository.

2.4 Who Is Accountable for What Once Connected

With an active integration, organizational accountability doesn't change, but it becomes harder to trace. It pays to define responsibilities upfront, because clarifying them after an incident is too late.

This is why configuring access permissions is not a technical detail to delegate: it carries legal and compliance consequences, and must be authorized by someone with the appropriate authority.

AUTONOMOUS AGENTS

Autonomous Agents

Agents do not merely execute isolated commands: they assess state, plan intermediate steps, and autonomously pursue goals.

3. From Assistant to Agent

The final frontier of the journey: a system that doesn't just answer, but executes.

In the book, Chapter 7 defines an agent as a system that perceives its environment, reasons toward a goal, decides which actions to take, and inspects the outcomes to self-correct. The difference between an agent and the assistant we've used so far isn't raw power: it's autonomy.

Four cyclical phases, and one non-negotiable checkpoint where a human must remain.

• Observe: reads the screen, files, and accessible data.
• Decide: selects the next action towards the goal.
• Act: clicks, writes, invokes a tool, or modifies a file.
• Verify: inspects the outcome and adjusts course if needed.

IRREVERSIBLE ACTIONS: HUMAN DECIDES

Irreversible Actions: Human Approval Required

The agent proposes, the human authorizes: payments, public messages, and deletions must always require human sign-off.

3.1 Safety Rules Before You Begin

3.2 When an Agent Makes Sense (and When It Doesn't)

3.3 An Agentic Workflow, Step by Step

To understand what truly changes, let's walk through an end-to-end task: preparing the weekly incident report for the Monday morning meeting. This is a real-world task that takes an hour every week in many organizations.

The third step is what distinguishes an agent from traditional automation: nobody explicitly instructed it to inspect prior months. It did so autonomously because that historical context was needed to deliver an accurate answer.

4. Practical Exercise for This Hour

Two architecture designs on paper. You don't need to configure software yet: you need to think through the logic first.

4.1 The Integration

4.2 The Agentic Workflow

Take a repetitive task from your workplace and break it down into the four phases: what does it observe, what does it decide, what action does it take, and how does it verify? Then mark with an X the exact checkpoint where a human must give approval before proceeding.

4.3 What to Test Without Taking Risks

To gain hands-on experience, you don't need to touch production systems. These three safe tests can be done immediately without special permissions and teach you almost everything you need to know.

1. A read-only connection to a repository of public or non-sensitive documents: user manuals, regulatory guidelines, standard operating procedures. Its purpose is to observe how your questioning techniques evolve.

2. A multi-step workflow tested on synthetic dummy data. Assemble a sandbox dataset and prompt for cross-referenced analysis. Observe what steps the agent initiates autonomously without being explicitly told.

3. A guardrail stress test. Instruct the agent to perform an action explicitly forbidden in its system instructions and verify that it halts. It is the test almost everyone skips, yet reveals more about your safeguards than any vendor documentation.

Common Questions from the Classroom

These questions arise in every course. It helps to have a concise, honest answer ready, especially when asked by a colleague.

“Do we need an IT specialist to set up these integrations?”

For initial setup, yes, almost always: it involves permissions, credentials, and access controls for enterprise infrastructure.

For daily usage, no: once connected, you interact using natural language just as before.

“Is it risky to grant access to our systems?”

It depends entirely on how it's configured. Read-only access to a specific folder with an audit log represents a manageable, governed risk.

Unrestricted write access across an entire archive without logging is an unmanageable hazard. The underlying technology is identical; the configuration makes all the difference.

“Can an agent make mistakes and cause damage?”

Yes, which is why boundaries must be defined in advance: what it can modify, what it can only propose, and where it must pause for human confirmation.

Irreversible actions—sending, publishing, deleting, paying—remain strictly human tasks. Always.

“Is this technology mature, or should we wait?”

For read-only integrations, it is mature: it works reliably and can be safely governed.

For autonomous agents acting independently on business operations, we are at the stage where you should experiment on low-stakes tasks to build institutional knowledge, not rely on them for mission-critical operations.

Lesson Glossary

Key terms encountered in this booklet, explained in a single line. Keep it handy: they will reappear throughout the upcoming lessons.

Further Reading & References

The sources referenced in creating this booklet. All are publicly accessible: if a particular detail catches your attention, consult the original source to verify it. That is precisely what we instruct artificial intelligence to do as well.

Protocol Specification

The Model Context Protocol is published as an open-source initiative: specifications, reference connectors, and documentation are freely accessible.

Agentic AI in the Reference Book

Niente paura, è solo IA, Chapter 7, dedicated to agents: definitions, real-world implementations, risks, and operational limits.

The Course Reference Book

Gianluca Bonomo, Niente paura, è solo IA. The comprehensive guide to understanding it, using it, and staying human.

Lesson Objectives

Execute the capstone project on a real business process, from selection to presentation, and take home an adoption checklist that remains valuable long after the course ends.

What You Will Be Able to Do by the End

• Select a suitable business process and articulate why it was chosen.
• Verify compliance and governance before building, not after.
• Bring together a Claude Project, structured prompt, and Artifact.
• Define how you will measure success three months from now.

THE 5 PROJECT STEPS

The 5 Implementation Steps

Process selection, business rules, document base, tagged prompt templates, metric measurement: the end-to-end framework.

1. The Capstone Project

A real process, not an exercise: that is the only way to find out whether AI truly adds value to your business.

The five steps of the capstone project, in the order they must be performed.

SELECTING THE RIGHT PILOT

Selecting the Right Pilot Project

Repetitive task, tolerable error margin, small team, low stakes: insulated from bureaucratic friction.

1.1 Step One: Select the Process

Not the flashiest one: the one that wastes the most time today. Three key criteria make a process suitable.

• It is recurring: it happens every week, not once a year.
• It involves language: documents to read, draft, rewrite, or categorize. If it's purely numerical calculations, use a spreadsheet.
• Errors are detectable: there is an easy way to spot mistakes before they cause harm.

1.2 Step Two: Check Governance Rules Before Starting

1.3 Steps Three, Four, and Five

1. Build the project: configure system instructions, upload reference documents, and designate an owner. These are the principles learned in Lesson 9.

2. Write the prompt using XML tags: context, documents, instructions, output_format. If the output has visual or structured layout, generate an Artifact.

3. Present to the cohort: how the workflow operated before, how it operates now, and how much time is saved.

1.4 Common Pitfalls in Process Selection

The final project succeeds or fails almost always at step one. These four selection pitfalls are the ones we observe most frequently, and they are completely avoidable.

2. The AI Adoption Checklist

Five points to print and keep on your wall. None of them are optional.

The synthesis of twelve hours in five lines.

3-MONTH ROADMAP: ADOPTION

3-Month Adoption Roadmap

Measure success not merely by hours saved, but by newly unlocked business capabilities previously out of reach.

2.1 The First 90 Days

The checklist shows what is required; this roadmap shows the exact rollout sequence. It is designed for an organization starting from scratch and scales effectively even with lean teams.

2.2 Measuring Results and ROI

At the end of three months, leadership will ask if it was worthwhile. You should decide how to answer beforehand, because baseline data cannot be reconstructed retrospectively.

1. Select two core metrics, not ten. One adoption metric (how many people genuinely use it weekly) and one outcome metric (a concrete result that previously couldn't be done, or took significantly longer).

2. Establish your baseline on day one. "How long does it take us today to draft a standard proposal?" Measure it now, not three months down the road.

3. Collect two or three concrete real-world anecdotes. A direct quote from an active user ("we simply couldn't produce this analysis before") persuades leadership faster than any percentage on a chart.

4. Document what did not work with complete honesty. That candid transparency lends credibility to every success claim and helps teams who follow in your footsteps.

3. Key Takeaways

Twelve hours boiled down to what truly matters on Monday morning.

3.1 The Twelve Hours on a Single Page

If you could keep only one single page from the entire course, this is it.

4. How to Stay Current Without Burning Out

• For legal and regulatory updates, use official sources: the European Commission's AI Act portal and the Data Protection Authority website. Avoid second-hand interpretations.
• For tooling, consult official vendor documentation: model names, rate limits, and pricing change every few months.
• For the big picture, read the book Niente paura, è solo IA.
• For practical guides, check the YouTube channel and tutorial archive at www.gianlu.it.

4.1 Mistakes We See Most Frequently at the Six-Month Mark

Alumni reporting back six months later almost always run into one of these four stumbling blocks. Recognizing them in advance costs nothing.

• Purchasing licenses before deciding on rules. Licenses are provisioned, but nobody knows what data is allowed, so out of caution nobody uploads anything, leaving the tool abandoned.
• Training only one person. When that person is on vacation, operations grind to a halt. Every team, even small ones, needs at least two champions.
• Measuring only time saved. It's the hardest metric to validate and the least compelling. It is far more effective to measure new capabilities—tasks accomplished that were previously never attempted.
• Allowing projects to become personal silos. Without a clear owner and scheduled review dates, after six months everyone creates their own fork, killing team collaboration.

What to Follow, and How Often

Thirty minutes a month across four specific sources is all it takes to stay ahead.

• The official release notes of your AI provider: the only place where updates are described with technical precision rather than hype.
• European and national regulatory bodies on the AI Act and data privacy: the European Commission and data protection authorities publish actionable guidelines, not opinions.
• One single industry newsletter, chosen for deep analysis rather than hype.
• Colleagues in your department. The most valuable insight you will gain this year will come from a teammate testing something hands-on, not an article.

THE 3 GOLDEN RULES

The 3 Immutable Principles

Accountability rests with the signatory, sovereignty over enterprise data, mastery in prompt instruction.

4.2 Three Things That Will Not Change

The question that almost always concludes the course: how much of this will still hold true a year from now? The honest answer is that product names will change, but the methodology will hardly change at all.

1. Accountability remains with the person who signs. No technological leap will ever shift responsibility for a document from the human who sends it to the software that generated it. This is a foundational legal principle, not a temporary limitation.

2. Data leaving the enterprise perimeter remains a business governance decision. Tech vendors and terms of service will evolve; what will never change is the requirement that humans decide what data is allowed to leave.

3. Prompting clearly will always matter. As models become more capable, precise instructions make all the difference: because a powerful engine driven by a vague prompt will produce an enormous mountain of useless work in record time.

5. The In-Class Capstone Project

In groups, one hour of work, one real process. Four questions to address during presentation.

To lead with AI rather than follow it, we must dismantle cinematic myths and unfounded fears.

Gianluca Bonomo, Niente paura, è solo IA

5.1 Presenting the Capstone Project

Whether pitching in class or to your executive board, the effective structure is the same, delivered in five minutes.

1. The Before: How it is done today, how much time it takes, and where mistakes most frequently happen. Thirty seconds, anchored by a concrete number.

2. The After: A live demonstration using real operational material. No slideware: show the working workflow in action.

3. What remains human: Which decisions remain strictly in human hands and why. This reassures stakeholders and is the deciding factor that gets projects formally approved.

4. What is required to scale: Licenses, dedicated hours, and an accountable project owner. Quantified with numbers, not vague adjectives.

5. What didn't work: One hiccup or limitation, stated candidly. That honest admission gives total credibility to everything else you presented.

Common Questions from the Classroom

These questions arise in every course. It helps to have a concise, honest answer ready, especially when asked by a colleague.

“Where do I begin on Monday morning?”

Start with the discovery questions from Hour 10, not by purchasing software. Five ten-minute conversations will tell you what is genuinely needed and what shadow AI tools are already in use.

Procurement comes later, and at that point it becomes an informed decision.

“How much time do I need to invest each week?”

For project coordinators, a couple of hours. For everyday users, zero extra time: the tool is integrated directly into existing workflows, not added on top.

If it requires extra hours, you are automating the wrong thing.

“How do I keep pace with all the rapid changes?”

By ignoring daily news cycles, which are mostly noise. Thirty minutes a month reading official vendor documentation and regulatory updates is more than enough.

What changes rapidly are model version numbers; what remains constant—how to structure prompts, how to govern data, and where human oversight is vital—comprises virtually everything you learned in these twelve hours.

“What if everything is completely different in a year?”

Some things will be: models, pricing, product names. The core methodology will not.

Separating instructions from source data, demanding step-by-step reasoning, validating against source citations, and deciding what leaves the corporate perimeter: these skills will remain essential for whatever tool comes next.

Lesson Glossary

Key terms encountered in this booklet, explained in a single line. Keep it handy: they will reappear throughout the upcoming lessons.

Further Reading & References

The sources referenced in creating this booklet. All are publicly accessible: if a particular detail catches your attention, consult the original source to verify it. That is precisely what we instruct artificial intelligence to do as well.

Regulatory and Legal Sources

European Commission, official AI Act portal (digital-strategy.ec.europa.eu); Italian Data Protection Authority (Garante per la protezione dei dati personali, garanteprivacy.it); Italian Law no. 132 of September 23, 2025.

Product Documentation

Anthropic Help Center and technical documentation, for current platform features, rate limits, and enterprise plans.

The Course Reference Book

Gianluca Bonomo, Niente paura, è solo IA. The comprehensive guide to understanding it, using it, and staying human. Chapter 12 is specifically devoted to ongoing experimentation and staying up to date.

Further Resources

www.gianlu.it — comprehensive guides, training archives, and the YouTube channel 'La Formula Magica Tech'. For tailored enterprise training and corporate consulting: info@gianlu.it