B4. Data Strategy
Every AI strategy is only as good as the data it is built on.
What this chapter delivers: the strategic foundation of data work: which data must be available and where it comes from (data-source inventory, sourcing and labeling), how its quality is assured (six quality dimensions), who decides over it (data governance), and what the knowledge bases of generative use cases additionally need. The data layer of the architecture (see chapter B5) describes the associated technical building blocks.
Data quality
Poor data quality is one of the most common causes of failed AI initiatives and becomes visible late. Six dimensions must be assessed. Each entry states why it matters for AI and what happens when it is ignored:
| Dimension | Key question | Why it matters, with example |
|---|---|---|
| Completeness | Are relevant values or records systematically missing? | Systematic gaps skew the model. Example: if rejection reasons were only recorded for large customers, the model learns nothing for small customers. |
| Correctness | Do the values match reality? | A model reproduces data-entry errors at scale. Example: incorrectly maintained industry codes lead to wrong customer segmentation in every single prediction. |
| Consistency | Do values contradict each other across systems? | Contradictions force manual clarification in every project. Example: the customer address in CRM differs from the billing system. Which one counts? |
| Currency | How old is the data relative to the use case? | Outdated data delivers forecasts for a world that no longer exists. Example: demand data from before the last product-range overhaul. |
| Uniqueness | Are there duplicates or conflicting identities? | Duplicates distort frequencies and customer pictures. Example: the same person exists three times with different spellings and appears as three customers. |
| Representativeness | Does the dataset cover all relevant groups without bias? | Underrepresented groups get worse treatment from the model, a fairness and reputational risk (see chapter B10). |
Data access
After quality, access is the second building block of the data strategy: even high-quality data creates no value if projects can’t find it or wait months for approvals. This section defines how data becomes discoverable, usable, and legally accessible.
- Discoverability: a central data catalog with a business description, owner, and currency for every source. Without a catalog, every project starts with weeks of searching for the right contacts.
- Access model: role-based access following least privilege, with documented approval processes. Goal: access in days instead of weeks, without sacrificing the security level.
- Purpose limitation: every use is tied to a defined purpose and traceable (a GDPR requirement, see chapter B8).
- Cross-domain use: standard interfaces and shared formats prevent every application from creating its own data copy.
Data governance
The third building block defines responsibility, quality, and control across the entire data lifecycle. Data governance answers two separate questions: who decides about data (roles), and by which rules data is handled (rules and processes). The two belong together: rules without named owners are not enforced, and owners without rules decide case by case.
Roles: who decides about data
| Role | Responsibility | What this means concretely |
|---|---|---|
| Data owner per domain | Business-side authority over a dataset | Decides who may access the data, which quality goals apply, and for which purposes the data may be used. Typically a manager of the business unit that owns the data, for instance the head of sales for customer data. Role details in chapter B7. |
| Data steward per domain | Operational implementation of the quality rules | Maintains the data catalog and metadata, checks compliance with quality goals, and is the first point of contact for data questions. Supports the data owner. |
Rules and processes: how data is handled
| Building block | What it governs | Why it is needed |
|---|---|---|
| Data classification | Categorization of every dataset by sensitivity (public, internal, confidential, strictly confidential) with protection measures per tier | The classification decides, for example, whether data may be sent to a cloud model (see chapters B3 and B9). Without it, either everything is treated overcautiously and nothing moves, or everything equally laxly and an incident is a matter of time. |
| Metadata management | Documentation per dataset: origin, format, refresh cadence, usage terms | Metadata makes datasets assessable without every project having to ask the business unit; it fills the data catalog from the data-access section. |
| Lifecycle and deletion rules | Retention periods and deletion processes per data type, coordinated with data protection | The GDPR requires deletion once the purpose is fulfilled; without defined processes, legacy data accumulates and becomes a legal and quality risk. |
Data for generative AI: curating knowledge bases
The sections so far deal mainly with structured records. Generative use cases draw, via RAG (see chapter A2), on a different kind of asset: a knowledge base of documents. It follows the same governance rules but poses its own requirements that a classic quality check does not cover. Four questions decide the quality of a knowledge base:
| Question | Why it matters | What to do |
|---|---|---|
| What belongs in it? | An overloaded knowledge base returns worse matches than a curated one. Not every document in the company belongs in the index. | Decide per use case which sources are included, and keep the corpus deliberately small and relevant |
| Is it current and free of contradictions? | Outdated or mutually contradictory documents produce wrong but seemingly sourced answers. The model then cites an obsolete policy. | Actively remove outdated versions, designate a leading source per statement, track currency per document |
| Who may see what? | The knowledge base does not inherit the source documents’ access rights automatically. Without control, the system answers confidential questions for unauthorized users. | Enforce permissions at query time (see chapter B9), not only at ingestion |
| Is provenance verifiable? | An answer is only as trustworthy as its source. Without provenance it can be neither checked nor corrected. | Keep source, version, and owner per document, so the answer can cite the source |
The technical implementation (preparation, embedding, index) is described in chapter B5; here it is about the content-level curation that belongs to the business unit, not to IT.
Data sourcing and labeling
Where the data comes from and how it is prepared for learning decides cost, quality, and risk before the first model exists. Data comes from four sources, often combined:
| Source | Strength | Caution |
|---|---|---|
| Own holdings | The differentiating core, exclusively available | Quality and access often unresolved (sections above) |
| Purchased data | Fast coverage of missing areas | License lock-in, currency, reuse rights |
| Public sources | Free and broadly available | Quality varies, check usage rights and provenance |
| Synthetic data | Replace scarce or sensitive real data, artificially generated, e.g. for rare cases without real personal data | Reflect reality only as well as their generating model |
The usage rights per source must be clarified before use, especially for purchased and public data (see chapter B8).
Labeling. Supervised learning and evaluation (see chapter D1) need labeled data, that is, examples with the known correct answer. Labeling is often the largest hidden effort of an initiative and at the same time a source of error: inconsistent labeling rules produce a model that learns the inconsistency. What works: clear labeling guidelines, trained labelers, spot checks, and reconciliation between several labelers on contested cases. Bias arises here first, because whoever labels shapes what the model treats as normal (see chapter B10).
Template: data-source inventory
The inventory brings the three previous sections together in one table and makes them concrete per data source: quality (data-quality section, as a score from 1 to 5), access path and purpose limitation (data-access section), and data owner and sensitivity (data-governance section). It is thus the central working artifact of the data strategy.
How to use the inventory: before every new use case, check whether the required data is already captured. If a source is missing, it is added and assessed before project start, not during development. That is exactly where pilots otherwise fail (see chapter C3).
| Data source | Domain | Data owner | Quality (1 to 5) | Sensitivity | Access path | Purpose limitation clarified? |
|---|---|---|---|---|---|---|
| Example: customer-service ticket history | Service | N. N. (head of service) | 4 | Confidential (personal data) | Ticket-system API | Yes, purpose “reply suggestions” documented |
Building vs. buying data competence
Why this section: everything this chapter demands (quality checks, a data catalog, governance roles) has to be done by someone with skills and tools. So the resource question from chapter B1 also applies to data, and the answer comes in two parts: core competencies such as data modeling and governance processes are usually built internally, because they require deep knowledge of your own data and are needed permanently. Specialized tools such as data catalogs and quality platforms, by contrast, are frequently bought, because they are standard products with no differentiation potential (decision path in chapter B3).
Checklist: robust data strategy
The checklist verifies that the three building blocks quality, access, and governance are in place for the prioritized use cases:
- Data-source inventory complete for the prioritized use cases
- All six quality dimensions assessed and gaps prioritized
- Data catalog in place and maintained: business description, owner, and currency for every source
- Access model implemented on a least-privilege basis, approval processes documented
- Purpose limitation documented per use
- Standard interfaces and shared formats defined for cross-domain use
- Data owner and data steward named per domain
- Sensitivity classification applied consistently
- Metadata documented per data set: origin, format, update cycle, terms of use
- Deletion periods and lifecycle rules aligned with data protection
- Sources clarified per data need and usage rights secured (own, purchased, public, synthetic)
- Labeling guidelines and quality control for labeled data defined
- Knowledge bases of generative use cases curated: inclusion criteria, currency, access rights in the index, provenance
- Decided which data competencies are built internally and which tools are bought