Data Locality as a Requirement for AI Productization

AI product teams often speak about data pipelines, data lakes, and data readiness. These are necessary concepts, but they can hide a deeper issue: data is not neutral input. Yanni Alexander Loukissas’s “All Data Are Local” provides a critical reminder that every dataset is shaped by local practices, infrastructures, classifications, and histories. For AI productization, this is not a philosophical detail. It is a system requirement.

The excerpt centers on the author’s experience with the Metropolitan Museum of Art’s American Wing collections data. The data looked like structured records about objects, but those records were created for curators’ work. Fields such as gallery location supported internal needs, including tracking objects for cleaning, photography, display, and security. Old label text, black-and-white images, gaps, and internal categories made sense in the museum’s back-stage context. They were not automatically suitable for visitor-facing digital interfaces.

This is exactly the kind of problem AI teams encounter in enterprise projects. A dataset created for one operational purpose is reused for another analytical or AI purpose. CRM data becomes a churn model. ERP data becomes a demand forecast. Ticketing data becomes a support automation model. Sensor logs become predictive maintenance. In each case, the original local context travels with the data, whether the product team notices it or not.

From a product perspective, data locality affects requirements, model design, evaluation, and user experience.

First, requirements must include data provenance. Who created the data? What workflow produced it? Which fields are mandatory, optional, or socially negotiated? Which categories reflect organizational convenience rather than reality?

Second, model design must account for local bias and missingness. Missing values may not be random. Labels may reflect historical processes. Categories may encode institutional assumptions. Without understanding this, a model may optimize for artifacts of the system rather than the business reality.

Third, evaluation must involve domain users. In the museum example, guards had practical knowledge of visitor movement and orientation that curators did not fully provide. In enterprise AI, frontline employees often understand data use better than central teams. Product validation should include these users early.

Fourth, interfaces must translate data between contexts. The Met’s visitor displays required selecting, simplifying, and reframing data. AI products face the same challenge. A model output that makes sense to a data scientist may not be meaningful to a salesperson, factory operator, compliance officer, or customer.

The book’s broader table of contents includes local origins, collecting infrastructures, newsworthy algorithms, market/place/interface, and models of local practice. This suggests a general framework: data systems are always embedded in places and practices. Product teams should therefore treat context discovery as part of technical delivery.

For ozycore.de, the consulting implication is practical: every AI product should include a data locality assessment. This can be lightweight but systematic: lineage mapping, stakeholder interviews, workflow observation, field definitions, known gaps, maintenance responsibilities, and context-specific evaluation criteria.

AI products fail when they assume that data speaks for itself. Data never speaks alone. It speaks with the accent of the place that produced it. Good productization listens for that accent before building the model.