When the supplier had got this far, management raised the question of what to watch out for legally before anything goes live. The most expensive answer is the one you look for too late. This page shows which questions belong early and in what order.
This article does not replace legal advice. It describes which questions typically arise in an AI project and in what order they are sensibly clarified. Whether and how a regulation applies to your specific case can only be assessed in the individual case. In case of doubt, consult a specialist before you make decisions or put a system into operation.
The questions listed here are meant to help you get started and make no claim to completeness. They are, however, important for avoiding expensive wrong decisions.
For management
Responsibility and evidence are settled before budget is committed, not afterwards.
For IT
Clarity on which obligations apply, from labelling through logging to the competence of the users.
For the department
Certainty about what is permitted, without having to assess the legal situation yourself.
The sequence is decisive
In practice, legal questions are asked at the end of a project, when technology and budget are already fixed. That is the most expensive sequence. If the check then finds that an application is subject to special requirements, the rework is regularly more laborious than the original project.
Sensible is the reverse sequence. First clarify which area a planned application falls into. Then decide whether it is economically worthwhile. And only then talk about technology.
How intrusive is the application?
European AI law distinguishes applications according to how strongly they intervene in people's rights. The stronger the intervention, the higher the requirements for documentation, control and record-keeping.
For practice, a rough self-assessment along three questions is sufficient at first.
Does the application make decisions about people or prepare such decisions? This includes, for example, the pre-selection of applications, the assessment of performance, the allocation of tasks or the judgement of business partners' solvency. If so, considerably increased requirements are to be expected. Such projects should not be begun as a first project and should in any case be checked in advance.
Do people communicate directly with the system, or does it generate content for the public? Then, as a rule, transparency and labelling requirements exist. This concerns chat solutions on the website as well as generated texts, images or voice outputs in external communications. These requirements can be met with manageable effort, but they must be known.
Does the application evaluate exclusively its own documents for internal purposes? Then, as a rule, it lies in the uncritical area. This applies to searching technical documents, evaluating test protocols or making a maintenance history searchable.
The largest part of what manufacturing companies actually intend falls into the third category.
Still to check is the exact classification of your application, especially if it moves between two categories or if it is planned to extend it later. An extension can change the classification.
Who is affected by the data?
Independently of the AI-specific classification, the general requirements of data protection continue to apply. As soon as data of employees, customers or suppliers is processed, it must be clarified on what basis this happens and where the processing takes place.
Local operation on your own hardware simplifies this question considerably, because no external service provider is involved and no data reaches other countries. But it does not replace the check of whether the processing is permissible at all and whether data subjects have to be informed.
A point that is often overlooked in supplier companies: your own customer contracts too can restrict processing by third parties. Many framework contracts in industry contain corresponding clauses. Check these before you give customer documents to an externally operated system.
Still to check is the data-protection basis for your specific processing, the information obligations towards data subjects and the contractual ties from your customer contracts.
Does the works council have to be involved?
This point stops more projects than any authority, and it is almost always considered too late.
As soon as a system is suitable for making the behaviour or performance of employees measurable or evaluable, co-determination has to be taken into account. What is decisive is the technical suitability, not the intention. A log that records who submitted which query and when already fulfils this condition, even if no one intends to evaluate it.
The practical recommendation is unambiguous. Involve the works council before the system stands, not afterwards. A project that has to be negotiated after the fact loses months and trust. A project in which the works council helps shape it from the start, especially on the question of which log data arises at all, as a rule goes through.
Still to check, whether and in what form co-determination applies in your specific case and what a viable arrangement can look like. That is to be clarified under employment law.
What do your customers demand?
For many companies in the region, the actual pressure comes not from an authority, but from the supply chain.
Larger clients increasingly pass their own security requirements on to suppliers. That can mean you have to provide evidence, even though you yourself do not formally fall under a particular regulation. In a region with a dense supplier structure, this is the more likely trigger.
Therefore look into your current framework contracts and into the requirement catalogues of your most important customers before you introduce a system. The requirements there are often more concrete and take effect at shorter notice than statutory specifications.
Still to check, which evidence obligations arise from your customer contracts and whether a planned system fulfils them.
Under what conditions may you use the model?
Freely available models are under different licences. Some allow every lawful use without further conditions. Others contain restrictions, for example on certain fields of application, on passing on to third parties or on attribution. And some reserve the right to change the conditions later.
For purely internal use this is mostly unproblematic. It becomes critical as soon as you want to pass a system on to customers or embed it in a product of your own.
Two points therefore belong in every procurement. The licence applies per model variant, not per provider, so the licence text of the exact version is to be checked. And the licence does not replace a regulatory requirement; the two levels are independent of each other.
Still to check is the licence text of the model version actually used, especially before passing it on to third parties.
Who has to be trained?
Anyone who uses AI in the company must ensure that the people working with it have sufficient competence. What sufficient means depends on the use. Someone who has drafts generated needs different knowledge than someone who evaluates test protocols or works with customer data.
For later record-keeping, what counts is the reference to your company and your actual use cases, not a general certificate of attendance.
Still to check, what scope is appropriate for your forms of use and how you document it.
What you should do regardless of any check
These five points are in no case wrong and can hardly be retrofitted later.
- Record in writing which data types may go into which tool, and name a person who decides in case of doubt.
- Log for every output the input, the user, the point in time, the model name and the model version.
- Let the system answer exclusively from presented documents and output the source reference with it.
- Map access rights in the data layer, not in the model. A language model has no rights management of its own.
- Put a check stage in between before a generated answer automatically triggers an action.
What a written data rule concretely looks like is set out under Which data may leave the company.
When to talk to experts
In these cases you should not decide for yourself.
- When the application prepares decisions about people, especially in the HR area or in the assessment of business partners.
- When a language model is to be embedded in a product that you place on the market.
- When a system intervenes in a machine or plant control.
- When employee data is processed and no arrangement with the works council exists.
- When a customer demands an obligation of proof and it is unclear what exactly has to be proven.
- When you are unsure which area your application falls into. This uncertainty itself is already a sufficient reason.
In depth, risk classes and deadlines
You need the following only once a concrete use case is defined. Open what concerns you.
The four levels
The EU AI Act follows a risk-based approach with four levels. They range from prohibited practices through high-risk systems such as in personnel selection, lending or critical infrastructure and limited risk with transparency obligations such as for chatbots to minimal risk without special requirements.
For manufacturing companies, most typical use cases lie in the minimal or limited risk.
The overview below classifies typical use cases roughly. It serves as orientation and is not a binding classification; the classification of your specific case may differ and should be documented in the individual case and, in case of doubt, checked professionally.
| Use case | Risk class (orientation) | What typically follows from it |
|---|---|---|
| Searching your own technical documents | Minimal | No special obligations from the AI Act |
| Summarising test protocols for employees | Minimal | Internal quality assurance is sufficient |
| Evaluating complaint texts | Minimal | No special obligations |
| Making a maintenance history searchable | Minimal | No special obligations |
| Assistant for employees with a chat interface | Limited | Users must recognise that they are talking to AI |
| Customer chat on the website | Limited | Labelling obligation under Article 50 |
| AI-generated texts, images or voice outputs in marketing | Limited | Labelling of the content |
| Pre-selection of applications | High | Full programme of obligations under Annex III |
| Performance assessment or task allocation of employees | High | Personnel management falls under Annex III |
| Credit assessment of customers or suppliers | High | Creditworthiness assessment falls under Annex III |
| Assessing employees by general behaviour | Prohibited | Social scoring is prohibited |
The categories in Annex III include biometric identification, AI in the management of critical infrastructure, education and vocational training, personnel management, creditworthiness assessment, social benefits, law enforcement as well as migration and border control.
A number that should give pause
According to the Bitkom survey 2026, 37 percent of the companies affected by the AI Act state that they probably have one high-risk system in use, 29 percent two, and only 2 percent assume they operate no high-risk system at all. The average is 1.5 systems per affected company.
That practically no one assumes zero, even though the typical applications in the mid-market are document search and text work, could point to a broad misjudgement. For a company that means either unnecessary effort or a false sense of security. Both are expensive.
Source: Bitkom, Artificial Intelligence in Germany, study report 2026, survey of 604 companies with 20 or more employees, survey period 2025.
What applies to AI built into a machine?
Here there is a special feature that is immediately relevant for machine and plant builders.
AI that sits in machines as a safety component remains high-risk in principle. What has changed is the interplay with the Machinery Regulation: in the course of the Digital Omnibus, the Machinery Regulation was moved within Annex I of the AI Act, so that conformity runs primarily through the sector-specific product law and no double conformity assessment under the AI Act arises. The high-risk classification as such is not removed by this. Other product groups such as medical devices and toys remain covered as well.
This simplifies conformity for plant builders, but does not release them from the requirements of the Machinery Regulation itself. Anyone building a language model into a control system or into an operating interface should have this point clarified legally before the project begins.
Which deadlines apply
The timetable shifted in 2026, the content did not. The so-called Digital Omnibus postpones deadlines but abolishes no obligations. The substantive requirements remain unchanged in substance.
| Obligation | Status |
|---|---|
| Prohibited AI practices under Article 5 | Subject to sanctions since August 2025 |
| AI competence obligation under Article 4 | Applicable since February 2025 |
| Transparency obligations under Article 50 | Since 2 August 2026 |
| Labelling for systems already on the market in August 2026 | Transition period until 2 December 2026 |
| Full high-risk obligations under Annex III | Postponed to 2 December 2027 |
| High-risk AI in regulated products under Annex I | Postponed to 2 August 2028 |
The additional time reduces neither the scope nor the complexity of the requirements. Building up risk management, technical documentation, data quality and governance takes, in experience, considerably longer than initially assumed.
The amended deadlines come from the Digital Omnibus, Regulation (EU) 2026/1744, in force since 27 July 2026. For legal decisions, check the current status at the source.
The obligation that already applies and almost no one fulfils
While high-risk deadlines are being discussed, another requirement has long applied. The AI competence obligation under Article 4 has been applicable since February 2025 and requires every company using AI to ensure a sufficient level of AI competence among the people working with it. This applies regardless of the risk class and regardless of how small the use is.
The fulfilment rate is low. 43 percent of companies so far offer no training on AI. Only 8 percent train all employees, 21 percent a large part and 25 percent selected employees. From the workforce's point of view, 70 percent of employed people state that their company offers no further training on AI.
What sufficient means depends on the use. Someone who has texts drafted needs different knowledge than someone who evaluates test protocols or processes customer data. General online courses convey a basic understanding but do not replace the question of which data may go into which tool in your company and how your specific application is to be classified. For documentation, what counts is the reference to your company, not a certificate of attendance.
Source: Bitkom, Artificial Intelligence in Germany, study report 2026.
NIS2 and why this affects smaller suppliers too
The NIS2 Implementation Act and the amended BSI Act came into force on 6 December 2025 without a transition period.
Covered are, depending on size and sector, primarily medium-sized and large companies, across 18 sectors in total. As a rough orientation, you are covered if you have at least 50 employees, or if your annual turnover and balance-sheet total each exceed ten million euros. Mechanical engineering is among the other critical sectors under Annex II of the NIS2 Directive, not among the sectors of high criticality. Check the exact applicability in the individual case with the BSI applicability check.
The point decisive for the region, however, concerns the companies below these thresholds. They too are increasingly obliged by their larger clients to comply with the NIS2 security standards, whereby compliance becomes a prerequisite for the business relationship. In a region with a dense automotive supplier structure, this is the more likely trigger than the authority.
For management, it additionally applies that the risk-management measures are to be approved and monitored and that a training obligation exists. The responsibility lies expressly with management, mere delegation is not enough.
Status: 9 August 2026. On the registration deadline at the BSI there are contradictory statements. Check the current status directly with the BSI.
What AI systems add in terms of security
The BSI formulates the principle such that AI systems are to be treated as security-critical infrastructure, not as isolated tools, and that the goal is controllable risks, not absolute security.
Concretely, attack paths arise that classical applications do not have. The BSI guideline for penetration tests names prompt injections and membership-inference attacks and is expressly aimed also at organisations that provide language models internally. As a framework, the BSI and the French ANSSI published joint design principles for zero trust in language-model-based systems on 11 August 2025.
Translated into practice, this means three control points. They comprise least privileges in all connected systems, checking the inputs before processing and checking the outputs before they reach users or downstream systems.
The last point is regularly overlooked. As long as a human reads the answer, the damage is limited. As soon as an answer automatically triggers an action, such as an entry in a ticketing system or a material request, you need a check stage in between.
Frequently asked questions
Do we need a special permit for an internal document search?
As a rule, no. An application that evaluates exclusively its own documents for internal purposes usually lies in the uncritical area. You should nevertheless document the classification of your specific case.
Does a locally operated system solve the data-protection question?
It simplifies it considerably, because no external service provider is involved. Whether the processing is permissible and which information obligations exist remains to be clarified separately.
Do we have to tell employees that they are talking to an AI system?
If a chat interface is in use, users should be able to recognise it. In practice this is settled with a note in the interface.
From when must the works council be involved?
As soon as a system is technically suitable for making behaviour or performance measurable. The intention does not matter. Involve it early.
Are we allowed to use a freely available model commercially?
That depends on the licence of the specific model version. For internal use it is mostly unproblematic, for passing it on to third parties not always.
What happens if we have used AI in an uncontrolled way so far?
The practicable path is not a ban, but a permissible access, a written rule and the explicit statement that the previous use has no consequences. Without the third point you will not get a reliable inventory.
Does our mechanical engineering company fall under NIS2?
If you have at least 50 employees, very probably yes, since mechanical engineering is among the covered sectors. It can also apply below that, if annual turnover and balance-sheet total each exceed ten million euros. The BSI provides an applicability check, whose result is, however, not legally binding.
What changed on 2 August 2026?
The transparency obligations became effective. Anyone using a chatbot, a voice assistant or AI-generated content has to make that recognisable. The full high-risk obligations, by contrast, were postponed.
Is a locally operated Chinese model compliant with data protection?
From a pure data-protection view, yes, because no data leaves the company. The origin of the training data, possible biases and the geopolitical dependency nevertheless belong in the risk assessment. When using the provider's cloud, the assessment looks different.
What is a prompt injection?
A hidden instruction in a document that the model adopts. It becomes relevant as soon as you automatically evaluate external documents, such as supplier emails or customer specifications.
Do we need a penetration test for the AI system?
From the point at which the system is connected to productive data sources or triggers actions, it makes sense. The BSI has published its own guideline for this.
Who in the company is responsible?
Management, and, under the amended BSI Act, expressly not fully delegable. The operational implementation lies with IT, the technical responsibility in the respective area.
This article serves for orientation and does not replace legal advice. Deadlines, paragraphs and classifications reflect the status at the time of writing and can change; applying them to your specific case requires a professional check. In case of doubt, have each of the points marked above checked by a lawyer before you put a system into operation or make commitments to customers.
If you are unsure which of the questions are relevant to you at all, we clarify that in a conversation beforehand. Arrange an appointment.