Italian packaging SME case: AI supports planning, but integration matters more

Case: off-the-shelf AI tools in a small packaging manufacturer

An OECD report on AI use by small and medium-sized firms describes a small bag and flexible-packaging manufacturer in Provaglio d’Iseo, in the province of Brescia. The company uses off-the-shelf tools, including ChatGPT, Gemini, and Copilot, as well as machine-learning models. According to the OECD description, these help analyse production capacity, streamline processes, and automate parts of operational workflows.

This is a useful example not because it promises a striking percentage saving. The case gives no such figure. Its value is a more practical picture: a small manufacturing company combines ready-made language tools with ML, moves from individual tasks toward operational workflows, and encounters a challenge not solved by choosing “the smartest model”: connecting solutions to the wider business ecosystem and preparing employees.

In short, a model may suggest where to look for a bottleneck, but a production plan does not update itself because a chart looks tidy. Someone must agree on the data, rules, and responsibility. Even the most diligent digital intern cannot know what the shift supervisor considers urgent until the process makes that explicit.

Context: the adoption gap still varies by company size

For context, Eurostat estimated that in 2025 AI was used by 17% of small, 30.36% of medium-sized, and 55.03% of large EU enterprises. In this statistic, small enterprises have 10–49 people employed and medium-sized enterprises have 50–249; firms with fewer than 10 people are outside the survey scope. This is an EU-wide measure, not an outcome from the case and not an estimate for the Russian market. It simply helps explain why a small manufacturer example is useful: adoption paths depend on company size and integration capacity, not on an immediate need to build a proprietary model.

What the source confirms—and what it does not

The OECD presents the company description as a case, not as an independent impact audit. The source records that:

• the business produces and sells flexible packaging;
• it uses off-the-shelf AI products and machine-learning models;
• the stated applications are production-capacity analytics, process optimisation, and automation of operational workflows;
• benefits mentioned by the company include speed, efficiency, deeper analysis, finding solutions, and taking on new tasks;
• the challenges include integrating AI into the broader company ecosystem and calibrating employee training;
• the company received Italian government support during its adoption journey.

The published description does not identify the ML models, integration architecture, production volume, baseline costs, forecast accuracy, or measured savings. We therefore cannot attribute a specific increase in output, reduction in defects, or payback period to this manufacturer. Nor can we claim that every tool is connected automatically to the production line: the OECD mentions analytics and operational workflows but does not disclose the technical design.

How to apply the lesson in your own company

For a small manufacturer in Russia, a reasonable starting point is not to copy product names but to choose one narrow decision. For example, estimate line utilisation for the next shift or flag a conflict between orders and available capacity. This is a project hypothesis to test, not a confirmed detail of the Italian case.

A minimum design could look like this:

1. **Agree on what capacity means.** Define available line time, including shifts, changeovers, planned maintenance, downtime, and material constraints.
2. **Prepare a data source.** Bring the order plan, deadlines, operation routes, available lines, and historical actual durations into one table. If data remain in separate files and are entered inconsistently, start with basic cleaning and a shared reference list.
3. **Separate calculation from language.** A transparent algorithm or existing planning system should calculate schedules and arithmetic. A language model can explain a deviation, collect inputs from notes, or help an employee formulate a scenario, but it should not invent operation durations.
4. **Show the basis for each recommendation.** Display the order, line, calendar constraint, and data behind each suggestion. If a source is empty or stale, the system should say “not enough data” rather than confidently filling in a plan.
5. **Keep the decision with the dispatcher or supervisor.** During the pilot, the system proposes an option; the accountable person approves it and records why they changed it. Automatically changing a production order should follow a separate accuracy check and agreement on permissions.

Many tasks do not need RAG: if an answer is based on structured orders, calendars, and reference data, careful integrations and a calculation layer matter more. RAG may be useful separately when employees need to search instructions, procedures, or descriptions of changeover causes; it is not a substitute for current load data.

Data, people, and infrastructure you will need

Before evaluating a model, check whether:

• orders, operations, lines, and shifts have stable identifiers;
• actual operation start and end times are available, not just the plan;
• changeovers, repairs, material shortages, and urgent orders are coded consistently;
• someone corrects inaccurate statuses and owns the reference data;
• ERP/MES data can be accessed through an API or regularly refreshed export;
• data may be sent to an external provider, or must stay in a local environment;
• an accountable person owns the recommendation and can override it.

Infrastructure depends on the process. An initial test can use an anonymised export and a separate report with no write-back to ERP. If data are sensitive or an external service is not permitted, a local model can be evaluated, but it does not eliminate the work on data normalisation, permissions, and observability. Local inference addresses some data-transfer concerns; it does not make a forecast automatically accurate.

A pilot: test usefulness, not the first impression

Start with one line, one planning horizon, and a limited number of order types. Use past periods with known actual outcomes and compare the forecast or recommendation with what happened. Then operate in shadow mode for several weeks: the new system calculates suggestions but does not change the plan.

Set metrics before launch:

• share of orders for which a recommendation could be prepared;
• error in estimated duration and capacity, separated by operation type;
• number of conflicts identified before a shift starts;
• share of recommendations accepted by a supervisor without changes;
• correction frequency and reasons for rejection;
• employee time spent gathering data and reviewing results;
• integration, support, and compute cost per decision.

A modelled economics example: if a dispatcher spends 40 minutes each day manually reconciling plans and the new workflow reduces that specific task by 15 minutes, it frees five hours per month over 20 working days. This is an assumption-based calculation, not a result reported for the Italian company. Subtract review time, source-data correction, integration support, and licences from any benefit. If freed time does not become useful work, or if the pilot needs more manual checking, it has not yet paid for itself.

The management takeaway

The OECD case is not a universal formula of “buy a chatbot and automate the factory.” It shows a more measured adoption path: ready-made tools can support analysis and workflows, while sustained use depends on integration and employee capability. For a small company, the first investment may be a process owner, a shared data vocabulary, and a clear way to measure results—not a new model.

Start with a short interview with the dispatcher and supervisor: what do they reconcile manually every day, which data inform their decisions, and what counts as an expensive mistake? Choose one process, run a shadow calculation, and connect systems only after checking the result.

For now, let the robot intern sort the cards. It is too early to give it the “rearrange the entire production schedule” button.