Operations data that stays out of general AI services

Operations work is full of tables: delivery lists, driver schedules, trip logs, customer lists, vendor invoices. They all feel like "ordinary work data", and that is exactly why they are easy to paste whole into a general AI service. Yet those tables often hold other people's personal data and the company's trade secrets.

In Level 1 you learned which data must not go in in general. In logistics there are four groups to know by heart because they come up every day:

• Driver and crew data. Full name, national ID number, driving licence number, home address, phone number, photo, health notes and offence records. This is personal data protected by the PDP Law, and some of it can be used for fraud.
• Customers with their addresses. A recipient's name paired with a home address and phone number. One row like "Mrs Sari, 12 Melati Street, electronics parcel" is enough to point to a person and what is in their home.
• Where a vehicle is right now. The live position of a truck shows where a driver is at this moment, and often where a high-value load is passing. That is safety information, not just a dot on a map.
• Contract rates and customer lists. Prices per route agreed with customers or carriers, and who our customers are. These are usually bound by confidentiality duties in the contract, and they are valuable to competitors.

All of this can be called operations data: data born from daily work. Operations data is not automatically dangerous, but it is almost always mixed with data that is.

The good news is that almost every task you want AI help with does not need that data. To draft a load plan, a model needs vehicle capacity and cargo weight, not the driver's name. To write a delay message, it needs the general cause and the new estimated time, not the recipient's address. To summarise this month's delays, it needs figures per route, not the position of every truck.

So the habit is simple:

1. Drop columns the task does not use. Licence numbers, home addresses and phone numbers are almost never needed.
2. Replace identifiers with codes. A driver becomes DRV-03, a vehicle TRK-07, a customer PLG-12, a route RUTE-B.
3. Raise the level of location. A full address becomes a district or region; a live position becomes "still on the toll road" or "already at the destination warehouse".
4. Replace contract figures with a placeholder. Write "‹tarif-kontrak›" in the draft, then fill in the number yourself in the internal system.

This is pseudonymisation, not anonymisation: with the code table, DRV-03 can still be traced back to a person. So masked data is still treated as personal data, and the code table is never sent.

Some tasks really cannot be done with masked data. Finding which driver's licence expires next month, checking a mistyped customer address, or seeing which truck is closest to the warehouse: these need real data. Tasks like these are done in the system that actually holds the data, such as the fleet app or the warehouse system, with access already controlled.

If your organisation has an approved AI service set up for internal data, follow its rules: who may use it, which data may go in, and where results are kept. If there is none, treat every AI service outside internal systems as a general service. The guiding question: if what I paste here were read by an outsider, who would be harmed? If the answer is a driver, a customer or the company, the task stays inside.