AI for internal business training

In internal training AI does not teach a trade: makes available at the time when it serves what the company already knows. It is a change of perspective that shifts work from "building courses" to "answering operational questions", which is the real need in almost every Italian SME.

There is then a second theme that concerns internal training from a different angle, and that many companies do not link to the first: the AI Act asks those who use artificial intelligence systems to deal with the skills of their staff on these tools. It is not an optional good management initiative: it is a written obligation in the standard, separate from any internal assistant project.

What can he really do, and what remains a people's business

The last line is the most important to say clearly to who introduces the tool. Professional judgment, the way to treat a difficult customer, the ability to recognize when a standard procedure does not apply: you learn by supporting someone, not by reading a generated response. Presenting the assistant as a substitute for this step creates expectations that then disappoint.

The obligation that concerns the company, not just its customers

Those who think about internal training almost always look at how AI helps train people. However, there is an obligation that goes in the opposite direction: to train people on AI itself.

In practice this means that an SME using an AI assistant in production, administration or customer care should be able to show that it has been responsible for making its own staff able to use that tool in a conscious way, in proportion to each one's role. We don't need a formal course for everyone: we need a reasonable, documented measure, designed for those who will really use the system. The general framework on the obligations of the AI Act for an Italian company is in AI Act: the guide for Italian companies.

This obligation adds, does not replace, to the internal training work described in the rest of this article: a company can build an excellent assistant on procedures and at the same time forget to take care of the AI skills of its staff, and it is a mistake worth avoiding from the beginning of the project.

In practice, for an SME this translates into a few concrete things: explaining to those who will use an AI assistant how it works in broad terms, what can be wrong and why, and what to do when the answer seems doubtful instead of trusting anyway. There is no need for an expensive external course: an internal session, even short, held by those who followed the project, and the written track of that session, are already a defensible measure if someone asks for it.

The Real Work: Writing What No One Ever Wrote

In almost all SMEs the procedures exist in practice but not on the sheet: "it's always done this way" works as long as the person who knows is present in the company.

1. Collect the questions that those who have just entered ask in the first few weeks.
2. Check which ones already have a written and updated response somewhere.
3. For the others, record an explanation in the voice of those who know and turn it into text.
4. Get that text validated by the same person: it's the passage that ensures it's correct.
5. Only at this point does he connect the assistant to that material.

The third step is what makes the project workable. Asking an experienced technician to "write the procedures" produces resistance and poor results. Asking him to explain them by voice while someone recording works much better, and AI turns that recording into a text that he then corrects instead of writing from scratch.

What sources to feed the assistant, and which ones not

The most common temptation is to connect the assistant to the entire company archive. It is a mistake on several fronts.

The point on the classified material is the most serious: an assistant open to anything can show those who have just entered information that they should not yet see, from a fee to an internal evaluation. The selection of sources is a choice of security rather than quality of answers, as described in Business Data and AI. The technical mechanism by which the assistant retrieves the right content is explained in RAG: what is it.

Two companies, two different starting points

A service company with frequent staff turnover. Each new entry involved weeks of questions to more experienced colleagues. After writing the most requested procedures and connecting an assistant, colleagues are interrupted much less and those who are new find the majority of operational responses on their own.

A workshop with only one technician who knows the particular workings. All the knowledge about certain jobs lay in a person close to retirement. The project consisted of recording his explanations and turning them into searchable cards. Here the value is not speed: it is the continuity of work on the day that that person will be gone.

A company with procedures already written and updated. Rare and lucky case: the project boils down to connecting the assistant to the material that already exists, without the writing work weighing on the other two examples. Low cost, near-immediate benefit, and counterproof that software is never the slow part of this type of project.

The content that feeds a training assistant always comes from one of three sources, in order of increasing ease. The already written but missing material is the easiest to retrieve, and must be exploited first. Voice explanations of those who know, recorded and then transcribed, unlock the resistance to writing when the material does not exist. The unanswered questions, i.e. what the assistant cannot say, precisely indicate what is still missing and feed the project over time instead of leaving it stationary at the first version.

How to keep him from growing silent

The benefit of this work is not even primarily the assistant: it is that the procedures, once written, remain even if the software project is abandoned. It is one of the few cases where the by-product is worth as much as the product thought at the beginning, a principle that is worth even more on a larger scale in AI for business base knowledge.

Those involved in internal training often also follow the inclusion of people from the point of view of the staff in the strict sense: the complete picture on minimum risk HR uses and regulated ones is in AI for Human Resources, while the map of where to start between different business functions is in AI by business function.

To figure out where to start, ask the last person who walked in what questions they asked in the first two weeks: you will get a short, concrete, surprisingly repetitive list, which is already the specification of the project. Then compare that list with what already exists in writing: the difference between the two lists is the work to be done, and it is a useful job regardless of any software, because it stays with the company even if in the future you change tool or supplier.

It is worth closing on a point that links the two themes of this article. Those involved in writing procedures for the training assistant are often the same person who should be involved in explaining to the team how to use AI tools consciously: two different responsibilities on paper, but that in the practice of an SME converge on the same desk. Plan them together, instead of one after another as if they were disconnected, avoid doing the same analysis twice on who does what and with what tools.

If you need a hand setting up a real assistant, a Customized AI Agent can be built around the procedures you have already written, without obliging you to complete the entire archive before seeing if the project works.