Data Types in Gen AI: Quality, Structured vs Unstructured, Labeled Data

Every generative AI capability an organization deploys is only as good as the data behind it, because data shapes the model at every stage: foundation models learn from the data they were trained on, customization techniques such as fine-tuning use company data to specialize behavior, and grounding techniques connect a model's answers to enterprise data at the moment a question is asked. If that data is wrong, stale, or missing, the model's fluent, confident output will be fluently and confidently wrong.

Those are also the only routes by which company data changes what a model does. A deployed foundation model does not keep learning from the requests it serves: answering thousands of customer questions does not teach it your products or correct its mistakes. Its behavior changes only when someone deliberately tunes it on new examples or updates the data it is grounded in — so improving output is a data task, not something time and usage take care of.

This is why Google Cloud frames data strategy as a leadership concern, not a technical detail. A leader deciding where to apply gen AI must ask two questions before choosing any model: do we have the data this use case needs, and can the AI actually reach it? Many organizations discover that their most valuable knowledge sits in formats a traditional analytics program never touched — contracts, emails, call recordings, support chats — and gen AI is often the first technology that can unlock it.

The exam approaches this topic from the business angle. You will not be asked to build a data pipeline; you will be asked to recognize what makes data usable for AI, to classify examples of data as structured or unstructured and labeled or unlabeled, and to predict the business consequences when data quality is poor. The rest of this lesson gives you exactly those tools.

Data quality describes whether data is fit to teach or ground an AI system, and its first three characteristics concern the content of the data itself.

Completeness asks whether all the necessary information is present — every required value, record, and group. If a retailer's product catalog is missing size, material, and care details for a third of its items, a gen AI shopping assistant grounded on that catalog cannot answer a third of customer questions. Completeness also covers information that exists but never reached the data: a product catalog loaded before this season's range was added is incomplete about the new items, even if every entry it holds is still accurate. In training data, a gap in coverage becomes a gap in behavior: when a group is under-represented — applicants from one region, patients of one age band — the model learns little about that group and tends to treat it worse. That is how a completeness problem turns into a bias problem, and why the fix is collecting representative data for the missing group, not just adjusting the model.

Consistency asks whether the same fact agrees across sources and over time, in the same form. When one system records a customer as 'J. Perera', another as 'Jayani Perera', and a third under an old address, or one system writes dates day-first and another month-first, an AI assistant may treat one customer as three people and give contradictory answers. Inconsistent formats, duplicated records, and conflicting values are among the most common — and most expensive — data problems enterprises face when preparing for AI.

Relevance asks whether the data applies to the problem you are solving, today. A model intended to draft legal clauses gains nothing from terabytes of marketing analytics, however well maintained. Content that is about the right subject but out of date is also a relevance problem: superseded price sheets, retired policies, and manuals for discontinued products no longer apply, and an assistant grounded on them answers confidently from the wrong material. Relevance is also a cost lever: collecting and preparing data that a use case does not need consumes budget without improving outcomes.

Data accessibility describes whether the right systems and people can actually use the data, and it has three characteristics of its own.

Availability asks whether the data can be reached when the AI needs it. Data locked in departmental silos, personal spreadsheets, a partner's systems, or a legacy platform with no integration path is invisible to a gen AI application, however valuable it is — and that stays true even when the content itself is clean, typed text.

Cost covers what it takes to acquire, store, clean, label, and maintain data. Data work is typically the largest hidden expense of an AI initiative: licensing third-party datasets, paying people to label examples, and storing large media libraries all add up. Leaders should weigh this cost — and the time it takes — against the value of the use case before committing; sometimes a narrower use case with data already in good shape delivers a better and faster return than an ambitious one with a large preparation bill.

Format asks whether data is in a form the AI system can process. Scanned paper forms may need converting to text, audio transcribed, or inconsistent file types normalized before a given tool can use them. Being connected to a store is not the same as being able to read it: an assistant already connected to an archive of handwritten intake forms it cannot interpret has a format problem, not an availability problem.

When several problems coexist, solve access first. Data that cannot be reached cannot be transcribed, cleaned, or labeled, so an availability blocker — a vendor platform with no API, a department that has not granted access — has to be cleared before format or quality work can even start.

To classify a data problem, ask what is actually wrong with the data — not where it is stored or how the symptom looks. The table separates the characteristics that are most often confused.

Two distinctions decide most scenarios. Missing versus stale: grounding data that lacks newer content is incomplete; grounding data whose existing pages are out of date is a relevance problem. Missing versus never labeled: if a new use case needs labels that were never part of the records — risk ratings for archived contracts, sentiment scores for old survey comments — the records are not defective; creating those labels is new preparation work, so their absence is a labeling-cost decision rather than a completeness gap.

Keeping grounding data current is ongoing governance, not a one-off cleanup. A one-time snapshot of a knowledge base starts going stale the day it is taken; grounding sources should stay synchronized with the systems where documents are created, updated, and retired, and someone must own removing superseded content so the assistant cannot quote it.

Structured data is data organized into a predefined model — typically rows and columns with fixed fields and data types — which makes it easy to store in relational databases, query precisely, and analyze at scale. Each piece of information has a defined place: a customer ID goes in one column, an order date in another, an amount in a third.

Real-world examples appear in every business function: sales transactions in a point-of-sale system, customer records in a CRM, inventory levels in a warehouse database, financial entries in an accounting ledger, sensor readings arriving as timestamped values, and website analytics events. On Google Cloud, structured data typically lives in databases and in BigQuery, where it can be queried and analyzed — increasingly in plain language, with Gemini translating a business question into a query.

For gen AI, structured data plays two main roles. It grounds factual answers: when an AI assistant reports a customer's order status or current stock level, that answer must come from a structured system of record, not from the model's general training. It also supplies the historical signal for personalization and prediction — purchase histories and behavioral events are the structured backbone behind a personalized experience. The business appeal of structured data is precision and trust: it is easy to validate, aggregate, and govern, which is why regulated reporting runs on it.

Unstructured data is data without a predefined model — free-form content such as text documents, images, audio, and video — and it makes up the large majority of the data most organizations hold. There are no fixed fields: the meaning is inside the content itself, which is why traditional analytics tools largely ignored it and why generative AI changes its value so dramatically.

Real-world examples surround every team: emails and chat threads, contracts and policy documents, presentations and reports, customer reviews and survey comments, support-call recordings, product photos, security footage, and social media posts. Semi-structured formats — data with organizing tags or keys but no rigid table structure, such as JSON or XML files — sit between the two categories, and the exam treats recognizing examples as the key skill.

Structure is a property of the content, not the container. Free-text product reviews stored in a column of a relational database are still unstructured: the database gives each review a row, but the opinions inside the text have no fields, so understanding them still takes a model that reads language. Likewise, a table of fixed numeric columns is structured whether it sits in a warehouse or arrives as an email attachment.

Foundation models are the breakthrough technology for unstructured data because they understand language, images, audio, and video natively. A multimodal model like Gemini can read a contract and extract its obligations, listen to support calls and identify recurring complaints, or examine product photos for catalog errors. This is the strategic point leaders should internalize: the majority of enterprise knowledge — the reasoning in documents, the voice of the customer in reviews and calls — was effectively dark data before gen AI, because reviewing it by hand was impractical at scale. Organizations that make their unstructured data available to AI convert an unused asset into answers, insight, and automation.

The distinction comes down to organization: structured data fits a predefined schema of rows and columns, while unstructured data is free-form content whose meaning lives inside it. The comparison below is the exam-ready summary.

Two exam cues are worth memorizing. First, classification questions give you an example — 'customer support call recordings', 'a spreadsheet of quarterly sales' — and ask which type it is. Second, value questions test whether you know that gen AI's distinctive advantage over earlier analytics is its ability to work with unstructured data, which is where most untapped business knowledge lives.

Labeled data is data in which each example is paired with the correct output for a task — an email marked 'spam', an image tagged 'defective part', a transaction flagged 'fraudulent' — while unlabeled data is raw data with no such answers attached. The distinction matters because it determines which machine learning approach can use the data and what it will cost to prepare.

A label is the answer, not a description. Metadata such as author, date, source, or file size describes an example; a record key such as a customer ID identifies it. Neither tells a model what the correct output is, so a dataset rich in metadata can still be unlabeled for a task. For supervised tuning, the data must be input-output pairs: a customer question paired with the answer a product expert wrote, an invoice paired with the cost center it was booked to. Who applied the label — a specialist annotator or a salesperson recording an outcome as part of daily work — does not change the fact that it is a label.

The two distinctions are independent. Structured versus unstructured describes how the content is organized; labeled versus unlabeled describes whether each example carries a correct answer. Free-text CRM call notes, each paired with whether the deal was won or lost, are unstructured and labeled — exactly what a model that predicts outcomes from notes needs.

Why foundation models need no labels to pretrain. Pretraining is self-supervised: the raw text supplies its own training signal, because the model learns by predicting the next piece of text from what came before, and the real next piece is the answer. That is why foundation models can learn from vast unlabeled corpora that nobody could ever annotate by hand.

Labeling is a genuine business cost. Accurate labels usually require paid human effort, and tasks that depend on expert judgment — reading medical images, rating legal risk — need expert labels even for a small tuning set; substituting cheaper non-expert labelers trades a cost problem for a quality problem. This is one reason foundation models are so economically attractive: an organization can often adapt one with prompts, grounding, or a small, carefully labeled tuning set instead of labeling millions of examples to build a model from scratch — and show value far sooner.

Poor data quality converts directly into business risk when gen AI is involved, because a generative model usually fails silently on bad data. A traditional report or pipeline tends to fail visibly — a job crashes or a total refuses to reconcile — but a generative model raises no error and does not correct its sources: it produces plausible, confident output built on whatever it was given, which is far harder to catch.

The implications cluster into four areas leaders are expected to recognize. Trust and accuracy. An assistant grounded on inconsistent or outdated data gives wrong answers to customers and employees, and every wrong answer erodes willingness to use the system. Unrepresentative data also introduces bias, producing outputs that are unfair to particular groups — a responsible-AI risk with reputational and regulatory consequences. Cost and delay. Data preparation is typically the largest single expense in an AI initiative; discovering mid-project that data is incomplete or badly formatted stalls timelines and inflates budgets. Decision quality. Summaries, forecasts, and insights generated from low-quality data mislead the leaders who rely on them — worse than no insight, because it arrives with confidence. Missed opportunity. Valuable use cases stay out of reach when the data they need is siloed or inaccessible.

Because the model will not validate its own data, quality has to be managed around it. Check data before it reaches the model, ground answers that need exact figures in the system of record rather than the model's general knowledge, and after launch monitor answers against trusted sources so problems surface in days rather than weeks. Generation settings are not a substitute: lowering temperature makes output less varied, not more accurate, so it cannot correct answers drawn from wrong data.

Consider a bank deploying a gen AI assistant for relationship managers. With complete, consistent, current customer data, the assistant summarizes each client accurately and suggests relevant products; with duplicated records and balances that disagree with the core banking system, it recommends products clients already own and misstates their positions — damaging exactly the relationships it was meant to strengthen. The underlying rule: assess and improve data quality and accessibility before scaling a gen AI use case, and keep monitoring it after.