Who should own master data for AI use cases in aerospace manufacturing?

No single team should own it alone.

In aerospace manufacturing, master data for AI use cases usually needs a federated ownership model: business functions own the data definitions, rules, and approval authority for their domains, while IT and data teams own the technical controls, integration patterns, access, lineage, and stewardship workflow.

A practical split looks like this:

• Engineering owns engineering master data such as part definitions, configurations, approved structures, and revision intent where PLM is the source of record.
• Operations owns routings, work centers, standard work attributes, production context, and certain execution parameters where MES or ERP governs them.
• Quality owns defect codes, inspection characteristics, disposition-related reference data, and quality status logic where QMS or MES holds the controlled values.
• Supply chain or materials owns supplier, material, and sourcing-related master data where ERP or supplier systems are authoritative.
• IT and data governance own identity, integration, synchronization rules, data quality monitoring, metadata management, retention controls, and stewardship processes across systems.

For AI, the key point is that ownership should stay closest to the process authority, not be reassigned to the data science team just because the data is being used for models. AI teams are consumers and sometimes contributors to feature engineering, labeling logic, and feedback loops, but they should not become the uncontrolled owner of regulated operational master data.

What matters more than the org chart

The real requirement is not a single owner title. It is explicit accountability for:

• system of record by data domain
• approved definitions and code sets
• revision and change control
• traceability from source data to AI input and output
• stewardship for exceptions, duplicates, and conflicts
• validation of transformations and integration logic where required by internal quality procedures

If those controls are weak, naming one executive owner will not fix the problem. AI performance will drift, model outputs will be hard to explain, and auditability will degrade.

Why this is harder in aerospace plants

In brownfield aerospace environments, master data is rarely cleanly centralized. The same part, operation, or quality code may exist across PLM, ERP, MES, QMS, data historians, spreadsheets, and supplier portals with different timing, granularity, or revision behavior. That means ownership is partly organizational and partly architectural.

Full replacement of legacy systems is often not realistic. It commonly fails because of qualification burden, validation cost, downtime risk, integration complexity, and the long lifecycle of production assets and programs. In practice, most plants need governed coexistence: clear source systems, mapped relationships, controlled replication, and documented override rules.

That is especially important for AI use cases such as predictive quality, scheduling support, anomaly detection, and knowledge retrieval. If the underlying master data is inconsistently synchronized, the model may appear accurate in a pilot but fail when exposed to live revisions, supplier changes, or shop-floor exceptions.

Recommended operating model

For most aerospace manufacturers, the most durable model is:

• Executive accountability through a cross-functional data governance council
• Domain ownership by the business function that is accountable for process correctness
• Technical stewardship by IT or a central data team
• AI-specific controls for feature definitions, training data lineage, model versioning, and retraining triggers

If you want one named owner for coordination, make it a data governance lead or chief data role with authority to enforce standards across functions. But that role should coordinate ownership, not replace the domain owners who control the actual business meaning of the data.

Common failure modes

• IT is named owner of all master data but cannot approve process meaning or code changes.
• Engineering assumes PLM is authoritative for everything, even when execution and quality data are maintained elsewhere.
• A data science team creates derived reference values that quietly become operational standards without change control.
• Plants run local spreadsheets or tribal conventions that never reconcile back to enterprise systems.
• AI teams train on historical data snapshots without accounting for revision history, superseded attributes, or missing genealogy.

If those conditions exist, ownership is not actually defined, even if a governance slide says it is.

Bottom line

Master data for AI in aerospace manufacturing should be jointly governed, with domain ownership in the business, technical stewardship in IT, and explicit controls for traceability, change management, and source-of-record integrity. If your organization is looking for one department to own everything, the answer is usually no.