2.1.3. Data Types and Data Quality
💡 First Principle: A model can only learn the patterns that are present in its data, and it learns the flaws as faithfully as the facts. Data type determines which kinds of AI can use it; data quality determines how good the result can possibly be. No model, however advanced, can recover truth that the data never contained.
Structured vs. unstructured data. Structured data fits neatly into rows and columns with defined fields: transactions, inventory records, CRM fields, sensor readings. Unstructured data has no predefined schema: emails, contracts, call recordings, chat logs, images, PDFs, social posts. Semi-structured data sits in between (JSON, XML, log files with tags). Analysts commonly estimate that most enterprise data is unstructured, and until recently most of it was effectively invisible to analytics.
This is why generative AI changed the business conversation. Classic ML has always worked best on structured data. Foundation models can read, summarize, classify, and extract from unstructured content at scale, unlocking value from contracts, support tickets, and research documents that previously required human reading. A strategist should therefore ask early: where does the information we need actually live? If it lives in documents, generative AI with retrieval may be the right path. If it lives in clean transaction tables, classic ML or even standard analytics may suffice.
Data quality dimensions. "Garbage in, garbage out" is old advice that matters more with AI, because AI amplifies patterns at scale.
| Quality dimension | Question to ask | What goes wrong if it fails |
|---|---|---|
| Accuracy | Are values correct? | Model learns wrong relationships |
| Completeness | Are records and fields missing? | Gaps in coverage; skewed results |
| Consistency | Do systems agree on definitions and formats? | Conflicting signals; integration failures |
| Timeliness | Is the data current? | Model reflects an outdated world |
| Representativeness | Does it cover all the populations and conditions the model will face? | Poor or unfair performance on under-represented groups |
| Label quality | Are the known outcomes reliable? | Model learns from mistakes in the "answer key" |
More data does not fix bad data. A million mislabeled support tickets teach the wrong routing a million times. A dataset that over-represents one customer segment produces a model that serves that segment well and others poorly, which is both a performance problem and a fairness problem (Phase 4). The business implication is that data assessment belongs at the start of any AI initiative, and that data quality work is often the largest and least glamorous part of the budget.
⚠️ Exam Trap: When a scenario offers "collect more data" versus "improve the quality and representativeness of existing data," and the problem is biased or inconsistent results, quality is usually the better answer. Volume helps only when the additional data is accurate and representative.
Reflection Question: A hospital network wants to use AI on discharge summaries (free text) and on billing codes (structured fields). What different questions would you ask about each data source before approving the initiative?
