How to Use AI Without Exposing Engineering Data

As artificial intelligence becomes more integrated into engineering workflows, we must also pay attention to important questions around data security, privacy, and governance.


Technical Article one hour ago by Antonio Armenta

Every time we provide inputs to an AI-enabled system, we are potentially sending sensitive data outside of our traditionally secure engineering environment. While sharing a PLC program or an equipment specification may provide useful context for an AI model, these documents may also contain information that should not leave the organization.

 

 Figure 1. Consider the sensitivity of engineering data before sharing it with AI. All images used courtesy of the author and were generated with ChatGPT for this article about AI.

Figure 1. Consider the sensitivity of engineering data before sharing it with AI. All images used courtesy of the author and were generated with ChatGPT for this article about AI.

 

The AI Platform Matters

The first step towards addressing data security is to distinguish between consumer AI applications and enterprise AI platforms. The data we submit to an AI model must be processed somewhere, and that is why this distinction is important to understand.

Consumer applications are designed for broad accessibility and are tailored to individual users, many of whom consult AI models for everyday questions.

Enterprise platforms, on the other hand, usually leverage AI engines that are built specifically to provide data protection, administrative controls, identity management, and audit capabilities, built around an organization’s existing security environment.

Another important consideration is whether the information we submit will be used for training the model, and whether the training is limited to the local model or is used to advance the broader software capability across customers. These answers depend entirely on the model’s provider, the account type, and the contract terms.

From a control engineer’s perspective, knowing that every AI tool handles information differently should make us more cautious about what we share and where we share it.

 

Know What You Are Sharing

Some types of data features are easy to recognize as confidential, such as personal information, passwords, and intellectual property. In control engineering, however, the sensitivity of the information we work with may not always be as obvious.

For example, let’s consider the typical network architecture of a manufacturing facility. This document may contain IP addresses, firewalls, servers, and details around remote connections. Individually, each feature may appear harmless, but together, they actually provide a detailed map of the facility’s control infrastructure.

Even an equipment list can potentially reveal more than expected when paired with publicly available specifications. Troubleshooting guides and system integration specifications can also describe how critical equipment communicates and how a network is structured.

Most business organizations already have in place internal frameworks for classifying data into categories such as public, internal, confidential, or restricted. Instead of creating a different set of rules for AI, this same framework can be applied to input data and AI model selection.

Broadly speaking, public information may be acceptable to use with a broad range of AI tools, while internal engineering data may require an approved enterprise platform. Certain confidential or restricted information may not be suitable for any external AI system at all. Engineers should always ask the question of whether a particular type of information is approved to be used with a particular AI environment.

 

Share Only What is Needed

Another practical approach to inherently enhance security is to reduce the amount of sensitive information provided to the model. Suppose, for instance, that you are seeking AI assistance troubleshooting communication between a PLC and another device. You may need to give the model relevant information details, such as the com protocol, configuration parameters, a description of the symptoms, and any error messages. But you probably do not need to reveal data such as the plant’s name, the actual IP addresses, or the server names. Most likely you do not need to input any specific network infrastructure details in order to uncover possible problems.

 

 Figure 2. Share only the information AI needs to solve the problem.

Figure 2. Share only the information AI needs to solve the problem.

 

You can remove sensitive data features or replace them with generic values before feeding them into the model. This practice is called sanitization, and it requires careful judgment. When pieced together, sanitized data can still reveal confidential processes or infrastructure details. As a rule of thumb, engineers should always keep this in mind: if a piece of information is not necessary to solve the problem, then there is no reason to provide it to the AI model.

 

Creating a Secure Path for AI

Using AI does not inherently mean that you are sending information to a public cloud service. Businesses have multiple options for deploying AI, providing different levels of data control and security.

 

 Figure 3. Secure AI starts with the right environment, tools, and guardrails.

Figure 3. Secure AI starts with the right environment, tools, and guardrails.

 

One option is to keep the models locally hosted, keeping certain information within the organization’s own environment, providing greater control over sensitive information. However, the tradeoff is that these typically require larger infrastructure, model management, cybersecurity controls, and in-house technical expertise. Cloud-hosted services reduce this burden and improve scalability, but the organization must understand how the cloud provider processes and protects any information it is given. Every organization needs to determine the appropriate environment given the application and the sensitivity of the data involved.

However, just as important as selecting the right technology is giving engineers a practical way to leverage AI. If the approved approach is too restrictive, employees may turn to practices such as an account on a personal cell phone, a browser extension, or simply making use of unapproved applications. This is referred to as shadow AI, and it can leave organizations with little control or visibility over what is being shared.

The key is to implement effective AI governance that provides clear and practical guardrails and is supported by best practices. The objective should not be to prevent engineers from using AI, but to make the most secure option also the easiest one to use.