Reading time: about 8 minutes

Shadow AI in the Engineering Department: Why Drawings End Up in ChatGPT

Shadow AI in the engineering department is not a problem of employee discipline, it is a tooling gap. Designers paste drawing fragments, material notes and customer requirements into public AI tools because those tools solve a real problem faster than the alternatives they have at hand. A ban written into the policy will not stop this, because it does not remove the reason people reach for these tools. In this post we show how design know-how actually leaks, where the real risk sits and where it is only panic, and which response we see as effective: replacement, not prohibition.

Table of contents

• What shadow AI is
• Why the engineering office in particular
• Where know-how actually leaks
• What this post does not cover
• Why bans do not work
• What works instead of a ban
• How to start the conversation with your team
• FAQ
• Related

What shadow AI is

Shadow AI means using AI tools outside the knowledge and control of the IT department. An employee opens a free account in a public chatbot, pastes in working content and gets a result in seconds. From the designer's point of view it is a simple improvement. From the company's point of view it is a channel through which technical data leaves the building with no trace at all.

The phenomenon is more widespread than internal surveys suggest, because people rarely admit to working around a procedure. The effect is easier to spot than the act itself: suddenly the team knows that some tool is great at cleaning up technical descriptions or translating documentation into English.

Why the engineering office in particular

The engineering department is especially exposed for three reasons.

First, a designer's work is largely work with text and documents: descriptions, calculation notes, specifications, customer correspondence, translations. These are exactly the tasks where public language models are most tempting.

Second, the time pressure in quoting and design work is constant. When a deadline looms, a tool that turns an hour of work into ten minutes beats any security policy.

Third, this is where the knowledge that forms the company's edge is concentrated: how an unusual joint was solved, the choice of material, the history of fixes after complaints. This knowledge is rarely written down in one place, so when a designer describes the problem to an AI tool, they describe it more fully than they ever would in any internal document.

Where know-how actually leaks

It is worth separating real risk from imagined risk, otherwise the response will miss the mark.

The most common and most underrated leak is not a single drawing, it is context. A designer rarely pastes the file alone. They paste the description: what it is for, which material, which customer requirement, what could not be solved before. That is the know-how, not the geometry, which could be recovered from a finished product anyway.

The second area is customer data inside the query. The recipient's name, commercial terms, an unusual requirement written in an email that someone pasted in full so the AI would extract a parameter list from it. Here the risk is double, both internal and contractual, because some agreements explicitly forbid passing documentation to third parties.

The third area, the one most often exaggerated, is the geometry itself or a single dimension. For most products this is not a secret worth panicking over, because it can be read from the physical part anyway. Treating it as the main threat draws attention away from the two more serious channels above.

What this post does not cover

This post is about the operational risk of know-how leakage and the organizational response to it. We do not discuss regulatory obligations or the requirements of specific cybersecurity directives here: that is a separate topic and a separate track. We also do not compare specific AI tools by name, nor the technical configuration of a private model deployment. We focus on what happens inside the engineering department and what its manager can do before the matter goes higher up.

Why bans do not work

The typical first reaction is an email with a ban and a clause in the policy. The problem is that a ban addresses the symptom, not the cause.

A designer does not reach for public AI out of disregard. They reach for it because they have a real task and a tool that shortens it. A ban changes neither the task nor the time pressure. It changes only one thing: the employee stops talking about it. After a ban, shadow AI does not disappear, it goes deeper and becomes harder to notice.

There is a side effect too: a ban without an alternative signals that the company prefers slower work over solving the problem. In a department already dealing with deadline pressure, that is an expensive signal to send.

What works instead of a ban

An effective response rests on the principle of replacement, not prohibition. If people reach for a tool because it solves a problem, you have to give them a tool that solves the same problem without sending data outside.

In practice this means providing a controlled AI environment in which data stays within the company's infrastructure. The designer still gets help with descriptions, translations and organizing requirements, but the content never leaves the organization. When the internal tool is at least as convenient as the public one, the motivation to bypass the rules disappears on its own, because bypassing no longer gains anything.

The second element is a clear, short rule instead of a long policy: what may be pasted and what may not, ideally on concrete examples from the department's own work. People follow rules they understand and that do not get in the way of their work.

The third element is a conversation, not an audit. A manager who asks the team which tools they use and what for will learn more than any security policy reveals, because people talk more readily about improvements than about breaking rules.

How to start the conversation with your team

The simplest first step is to map where the temptation actually arises today. Just ask the designers which tasks are the most tedious and repetitive: descriptions, translations, pulling requirements out of emails. Those are the places where shadow AI has already appeared or will appear any moment.

Next, name the risk without scaremongering. Instead of threatening consequences, show concretely that a pasted email with customer terms is not an abstract legal problem but the actual content of a contract. A concrete example convinces better than a generality about security.

Only against that background does proposing an internal tool make sense. Then it is not a restriction but a faster route to the same result the team was already looking for on its own.

FAQ

Does shadow AI only affect large companies?

No. In smaller manufacturing firms the phenomenon can be even stronger, because there are fewer formal procedures and a single designer has more freedom in choosing tools. The volume of data is smaller, but the concentration of key knowledge in one person is often greater.

Can you detect that someone is using public AI?

Partly, and with delay. You can monitor network traffic, but that is an audit route that builds an atmosphere of control and pushes the phenomenon deeper. It is more effective to remove the reason people reach for external tools than to chase the fact of use.

Is it enough to block access to popular AI tools on the company network?

No. A block on the company network does not cover a private phone or remote work, and a designer under deadline pressure will use whatever is at hand. A block without an alternative moves the problem out of sight instead of solving it.

What is the most urgent thing to protect in the engineering office?

Context and customer data, not the geometry itself. The problem description, the choice of material, the history of fixes and the commercial terms are knowledge that cannot be recovered from a finished product. That is the company's edge, and that is what needs protecting first.

Related

• Five AI workflows already paying off in Polish manufacturing
• AI in the engineering office: what it really automates and what it only promises
• AI for service knowledge management: how to feed the system and where the limits are
• How to assess a manufacturing company's readiness for AI: 5 questions