AI and personal data: where it actually sits in an ERP
There is more personal data in an ERP than people expect. That map needs drawing before an AI layer goes live.
“There’s no personal data in our ERP, we track stock.” We hear this often, and it is nearly always wrong. In a live ERP, personal data is spread well beyond the HR module — and the map needs drawing before an AI layer is switched on.
This is not legal advice; it is an implementation checklist. Work with your own counsel on the final assessment.
Where personal data accumulates
The obvious place is HR: employment records, leave, performance notes. The list does not end there.
Accounts include sole traders, and a sole trader’s trading name is often a real person’s name. On the sales side, the contact’s name, phone and email are held. In production, an operator identity is attached to a work order. Quality records name the inspector. Logistics holds the name and signature of whoever accepted the delivery.
Each of these, alone or combined with something else, makes a real person identifiable.
Purpose, notice and retention
Three questions should be answered separately for every field. What purpose is this data processed for? Has the person been informed of that processing? And how long will it be kept?
The third is the one skipped most in practice. ERPs delete nothing by default; that is the right assumption for accounting and a problem for personal data. What happens when a retention period expires — deletion or anonymisation — should be decided up front.
What the AI layer changes
Bringing in a recommendation engine adds two questions.
First: which fields go to the model? A production sequencing recommendation may need an operator identifier; it does not need the operator’s name. De-identifying the input is possible and costless in most scenarios.
Second: where does the model service come from? If an external model provider is used, that is a data transfer and it belongs in your notice. On our side, that is written plainly in the Privacy Policy.
Automated decisions
Several data protection regimes give people a right to object to decisions produced solely by automated analysis that affect them adversely. This bears directly on HR: an output such as an attrition risk score, if it alone is used as the basis of a decision, falls here.
The practical consequence lines up with the product design: no recommendation is applied automatically, a person decides, and the reasoning is recorded. Those three are both the foundation of our approach to AI and what this requirement calls for.
A short checklist
Have written answers to four questions before go-live. Which personal data lives in which module? For what purpose and for how long is each held? Which of the inputs going to the model can be de-identified? And which automatically generated outputs could produce a consequence for a person?
If the fourth answer is empty, you probably have not looked hard enough.
Topics
- compliance
- digital transformation