Before a business's data reaches an AI buyer, every name, contact detail, and identifier has to go, while the useful patterns stay. This post walks through how we think about that line at BDLG.ai (Big Data/Little Guy) and why it matters for both privacy and model quality.
What we mean by "operating data"
Operating data is the exhaust of running a business. It isn't marketing copy or a polished dataset. It's the stuff that piles up in point-of-sale systems, scheduling tools, spreadsheets, and ticketing software:
- Orders: what was bought, when, in what quantity, at what price, and through which channel.
- Schedules: shifts, appointments, bookings, cancellations, and no-shows.
- Inventory: stock levels, reorder points, deliveries, spoilage, and stockouts.
- Service logs: jobs performed, time to complete, parts used, follow-ups, and outcomes.
Small and mid-sized businesses generate a lot of this, and most of it sits unused once the books are closed. For people building models, it's valuable because it reflects how real operations behave: messy, seasonal, constrained, and full of edge cases that synthetic data tends to smooth over.
The catch is that raw operating data is also full of people.
What sanitizing removes
"Sanitized" is easy to say and harder to do well. At a minimum, it means removing anything that identifies a person, directly or indirectly.
Direct identifiers are the obvious ones: names, email addresses, phone numbers, street addresses, account numbers, loyalty IDs, license plates, payment details. If a field on its own points to a specific person, it has to go or be transformed.
Indirect identifiers (quasi-identifiers) are fields that look harmless alone but can single someone out when combined: a ZIP code, a birth date, a job title, an exact appointment time, a rare product purchase. One of these rarely identifies anyone. Three of them together often can.
Free-text PII is where a lot of real-world leakage happens. Notes fields, ticket descriptions, delivery instructions, and technician comments regularly contain things like "Call Maria on her cell, gate code is…" or "Same issue as last visit at the Elm St. house." Structured columns can be cleaned by schema; free text has to be scanned and scrubbed on its own terms.
Techniques, at a conceptual level
No single technique makes a dataset safe. In practice it's a combination, chosen field by field.
Removal
The simplest tool: drop the column. If a buyer doesn't need customer names to learn demand patterns, names shouldn't be in the export at all. Removal is the default for direct identifiers that carry no analytical value.
Pseudonymization
Sometimes the relationship matters even when the identity doesn't. A model learning repeat-purchase behavior needs to know that two orders came from the same customer, not who that customer is. Pseudonymization replaces the identifier with a consistent token, so jane.doe@example.com becomes something like cust_8f3a everywhere it appears.
One important caveat: pseudonymized data is not the same as anonymous data. If the mapping can be reversed, or if the token's behavior is distinctive enough, it can still point back to a person. Pseudonymization reduces exposure; it doesn't end the analysis.
Generalization and bucketing
Precision is often the enemy of privacy, and models frequently don't need it. Generalization trades exact values for ranges or categories:
- Exact timestamps become hour-of-day or day-of-week.
- Full addresses become a broader region.
- Ages become age bands.
- Exact order totals become price tiers, where appropriate.
The goal is to keep the signal a model needs while removing the detail that makes a record unique.
k-anonymity-style thinking
A useful mental model: for any combination of quasi-identifiers in the dataset, how many records share it? If a given combination of region, age band, and visit day matches only one record, that record stands out. k-anonymity formalizes this by requiring every combination to appear at least k times. Even if you don't apply it as a strict rule, asking "how many rows look like this one?" is a good way to find records that need more generalization or should be suppressed.
Re-identification risk from combining fields
This is the part that's easy to underestimate. Each column can pass review on its own while the combination fails. A neighborhood, a time window, and an unusual service type might together describe exactly one household. The same applies across datasets: a buyer may hold other data that, joined with yours, narrows things down. Sanitizing has to be evaluated on the dataset as a whole and with realistic assumptions about what else is out there, not column by column.
What stays useful for models
If sanitizing strips the people out, what's left? Quite a lot, because most of the value in operating data was never about individuals:
- Patterns: seasonality, weekly cycles, which products move together, how demand shifts around holidays or weather.
- Volumes: order counts, job counts, inventory turnover, staffing levels relative to demand.
- Timing: lead times, time to fulfillment, appointment durations, gaps between reorders, cancellation windows.
- Outcomes: completed vs. cancelled, fixed on first visit vs. callback, in stock vs. stockout, on time vs. late.
These are the things forecasting, scheduling, logistics, and operations models actually learn from. A well-sanitized dataset can preserve them with little loss, as long as the generalization choices are made with the intended use in mind rather than applied blindly.
Why business owners keep control
This data belongs to the business that generated it, and the people inside it trusted that business, not an AI company. So the business owner should decide:
- whether their data is shared at all,
- which parts of it are included,
- how aggressively it's sanitized, and
- what terms it's licensed under.
That's the core of how we approach it at BDLG.ai: help small and mid-sized businesses clean their operating data, strip out anything private, and license what's left on terms they control. The owner stays in the loop, and the people in the data stay out of it.
Wrapping up
"Sanitized" shouldn't be a checkbox. It's a set of deliberate decisions about what to remove, what to transform, and what to keep, made with re-identification risk in mind and with the downstream use in view. Done well, it protects the people behind the records and still gives model builders the real-world signal they're looking for.
If you're building with operating data, or you run a business sitting on years of it, follow BDLG.ai here for more posts on how this works in practice.
Top comments (0)