No single team should unilaterally own master data for AI use cases in aerospace manufacturing.
In practice, the right answer is a federated ownership model: the business function that is accountable for a data domain should own its meaning, approval, and change decisions, while IT and data teams own platform controls, integration patterns, access, lineage, and technical quality checks.
For example:
-
Engineering typically owns product and configuration definitions sourced from PLM or engineering records.
-
Operations typically owns routing, work center, and execution-related master data that drives MES behavior.
-
Quality typically owns defect codes, inspection plans, dispositions, and controlled quality attributes.
-
Supply chain or materials teams typically own supplier, part, and inventory planning attributes in ERP.
-
IT or data governance teams typically own the integration framework, identity, access, retention rules, and master data synchronization controls.
If the question is who should own it for AI, the answer is still not a separate AI team acting alone. AI teams can define data requirements, fitness criteria, and model-specific transformations, but they should not become the system of record for enterprise master data. When that happens, plants often end up with shadow copies, conflicting definitions, weak traceability, and brittle pipelines that fail under audit, change control, or production exceptions.
What ownership should look like
A practical model is:
-
Domain owner: accountable for the business definition and approval of master data in that domain.
-
Data steward: responsible for day-to-day quality, completeness, issue resolution, and coordination across sites or programs.
-
System owner: responsible for the source application, interfaces, security, backups, and technical administration.
-
AI or analytics owner: responsible for documenting how master data is used in models, what assumptions are made, and what happens when source data changes.
-
Quality and validation stakeholders: responsible for assessing whether data changes affect validated workflows, traceability, reporting, or decision support in regulated processes.
That separation matters because ownership is not just about who can edit a field. It is about who is accountable when part classifications drift, routings are obsolete, supplier attributes are inconsistent across ERP and MES, or model outputs become unreliable because a code set changed without downstream review.
Why centralizing ownership in one group usually fails
A fully centralized model under IT, data science, or a transformation office sounds simpler, but in brownfield aerospace environments it often breaks down. The reason is not organizational preference alone. It is that master data is embedded in qualified processes, legacy integrations, long-lived assets, and site-specific work practices.
Common failure modes include:
-
business definitions detached from real shop floor use
-
local workarounds that bypass the official master record
-
AI pipelines trained on extracted copies that are no longer synchronized
-
change requests implemented in one system but not propagated across MES, ERP, PLM, QMS, and reporting layers
-
poor lineage when investigators need to explain why a model recommendation changed over time
In aerospace manufacturing, full replacement strategies also often fail for the same reasons: qualification burden, validation cost, downtime risk, integration complexity, and long equipment and system lifecycles. Most organizations need coexistence, not a clean-sheet rebuild. That means master data governance has to work across existing systems, not assume one new platform will become authoritative overnight.
What to decide before assigning ownership
Before naming an owner, define these boundaries clearly:
-
Which domains count as master data for the use case
-
Which system is the system of record for each domain
-
Who approves changes and under what change control process
-
How downstream AI features, labels, and reference mappings are versioned
-
What lineage must be retained to reproduce model inputs and outputs later
-
How site or program-specific variants are handled without corrupting enterprise definitions
If those decisions are vague, assigning ownership will not solve much. You will still have disputes over which revision was valid, whether a model used superseded routing logic, or why the same part family appears with different attributes across plants.
Bottom line
The best owner is usually the accountable business function for each data domain, with formal stewardship and technical governance shared across IT, quality, engineering, and operations. No, master data for AI should not sit solely with the AI team. In regulated aerospace environments, ownership must support traceability, controlled change, cross-system consistency, and reproducibility, or the AI use case will be fragile regardless of model quality.