Back to Blog
Data for AI: What You Need and How to Prepare It

Data for AI: What You Need and How to Prepare It

Data for AI: What You Need and How to Prepare It

Data steward sorting customer support records

Data for AI is every piece of information used to build, run and monitor an AI system: the examples a model learns from, the inputs it receives once live, and the outputs and logs you keep to check it. For a French business, the practical task is the same in every project: know where each dataset comes from, check that you may reuse it, clean and structure it, and keep the personal data to what the use case strictly needs. This guide walks through each step, with the French regulator’s guidance as the backbone.

Botiqueai
Turn Prepared Data Into AI Tools
BotiqueAI builds custom chatbots, intelligent agents, and automations tailored to business needs, helping put AI to work across your operations.
Explore BotiqueAI

TL;DR

  • Training data teaches a model to recognize patterns. Production data is what the system processes once it is live. They carry different risks and should be handled separately.
  • Before any cleaning, check the origin of each dataset and your legal right to reuse it. In France, the CNIL’s guidance makes this the first step.
  • Reliable data is truthful, representative of the real environment and correctly annotated. Volume has to be justified by the difficulty of the task, not maximized by default.
  • Under the GDPR, minimization applies to AI too: collect only what the defined purpose needs.
  • AI can also help you clean your own data (deduplication, normalization, anomaly detection), as long as a person validates the rules.

Table of Contents

What “data for AI” really covers

The phrase is wider than “the dataset you train on”. The Open Data Institute’s 2025 taxonomy describes data involved in developing, using and monitoring AI systems: training data is processed specifically so a model can learn to recognize patterns, while user data is ingested and processed once the model is deployed.

That split matters in practice. Government technical guidance from Australia, for example, separates deployment data (live production inputs, user data, configuration, and outputs such as predictions and logs) from development data. The CNIL, the French data protection authority, goes further for personal data: it recommends clearly distinguishing the learning phase from the production phase and using pseudonymization or masking techniques.

A simple way to organize your thinking is to ask three questions of any project:

  1. What does the model learn from? (training, validation and test data)
  2. What does it receive when it works? (live inputs, documents, customer messages)
  3. What does it produce and what do we keep? (outputs, logs, feedback used to monitor it)

Each answer has its own owner, its own retention period and its own legal basis. Mixing them in one shared folder is the most common governance mistake we see in early projects.

The types of data and where they come from

Types

The ODI describes raw data such as text, images and audio, structured data, and metadata. It also names reference data: material that enriches a training set with extra context, such as linguistic thesauri, mathematical proofs or knowledge graphs.

For a typical company, that translates into familiar assets:

Data type Business examples Typical AI use
Text Support tickets, emails, product sheets, contracts Chatbots, classification, summarization
Structured data CRM records, orders, invoices, stock levels Prediction, segmentation, scoring
Images and audio Product photos, call recordings Visual search, transcription
Sensor and log data Machine readings, application logs Anomaly detection, maintenance
Reference data Product taxonomies, glossaries, FAQs Grounding answers, consistent vocabulary

Who provides it

The ODI lists three routes: public sources such as the internet, third parties under license, and end users generating data as they interact with a service. The US Government Accountability Office notes that commercial developers often collect publicly accessible web material, but that being publicly available is not the same as being public domain or free of copyright. The same report says developers also buy licensed datasets, for instance to reach conversation data at scale.

Most companies building a business AI tool do not need any of that. Your strongest asset is usually your own data: years of customer exchanges, catalog information and process documentation. It is specific to your market, and you already hold it. It still has to pass the checks below.

How to prepare your data, step by step

The CNIL’s guide on collecting and qualifying training data gives an order of work that suits any organization. Here it is, adapted to a business project.

Six stages for preparing business AI data

1. Check origin and right of reuse

For each dataset, write down where it came from and why you may use it for this new purpose. Data collected to fulfil an order is not automatically reusable to train a model. This is a legal question and a quality one: data of unknown origin is data you cannot defend later. Our CNIL checklist for GDPR and AI covers what to settle before a first training run.

2. Decide what you really need

Minimization is not only a legal principle, it is good engineering. The CNIL explains that the GDPR requires data that is appropriate, relevant and limited to what is necessary for the defined purpose, even when training AI. It also suggests that tests on fictitious data with the same structure as the real data, but linked to no individual, can help determine which data you need.

In practice: list the fields, and for each one, write which output of the model depends on it. A field with no answer is a candidate for removal.

3. Clean

The CNIL describes cleaning as a crucial step toward a quality dataset: correcting empty values, detecting outliers, removing duplicates and dropping useless fields. The ODI is blunt about why this is needed: data is often messy and not necessarily ready for AI.

A short cleaning checklist:

  • Merge duplicate customer or product records and keep one reference.
  • Standardize formats (dates, phone numbers, currencies, country names).
  • Decide a rule for missing values: fill, flag or exclude.
  • Remove test records, internal accounts and obsolete products.
  • Keep a log of every transformation so the result can be reproduced.

4. Select and balance

Selecting relevant data is meant to optimize performance while avoiding over-fitting and under-fitting, notably by ensuring a good balance between the classes represented, according to the same CNIL guidance. Take a support classifier: if 90% of your tickets are “delivery delay”, the model will look excellent by always guessing that category, and fail on the rare, expensive cases such as billing disputes.

5. Annotate with care

When a model learns from labeled examples, the labels are the lesson. The CNIL’s page on annotating data calls annotation crucial to the quality of the trained model and pairs the performance goal with a rigorous method that respects personal data protection. Write labeling instructions, test them on a small sample with two people, and compare their answers before scaling up.

6. Document, then measure

Keep a one-page record per dataset: source, legal basis, period covered, known gaps, who validated it. Then define success before you train: an error rate you can live with, tested on data the model has never seen. Our guide to AI data strategy shows how this record fits into a broader plan, and the post-implementation audit process explains how to keep measuring after launch.

What makes data reliable

The CNIL ties reliability to three things: truthfulness, representativeness and annotation quality. It also asks you to justify the volume of data against the difficulty of the learning task. Four criteria follow from that.

Quality. The quality of an algorithm’s outputs depends directly on the quality of its training data. The CNIL recommends checking that data is truthful and controlling the training and work of annotators.

Volume. More is not automatically better. A narrow task, such as routing emails into six categories, needs far less data than an open conversational assistant, and you should be able to explain the number you chose.

Representativeness. Compare your dataset to the real environment. If your training emails come from one product line but the system will serve all of them, it will be weakest where it has seen least. The CNIL also asks you to inspect potential biases.

Traceability. You should be able to say which version of which dataset trained which version of a model. The GAO observed that transparency about training data for generative models has worsened over time, with developers often citing proprietary reasons. When you rely on a third-party model, that is a reason to keep your own records tight.

What makes data reliable — overview diagram

French and EU rules to settle first

In France, building a training database must respect the GDPR, including the rules on sensitive data under Article 9 and the minimization principle, according to the CNIL. Reuse must be legally justified, and compliance follow-up can include a data protection impact assessment (AIPD in French). Where personal data is involved, the CNIL also asks you to apply measures that limit the risk of misuse.

Three practical consequences:

  • Sensitive data (health, political opinions, biometric data and similar categories) needs a specific exception before it enters a dataset. If you can avoid it, avoid it.
  • Anonymization is not a label you can simply apply. Data only counts as anonymous if it passes demanding tests; our article on client data anonymization and the EDPB’s three tests explains them for DPOs.
  • Governance needs an owner. Someone must decide what enters a dataset and who can change it. Our AI governance framework guide sets out a workable structure for decision-makers.

Using AI to improve your own data

The reverse also works: AI can help prepare the data that later feeds other AI. The common uses on customer and operational data are:

  • Normalization: turning “Paris 8e”, “75008 PARIS” and “paris” into one consistent address format.
  • Deduplication and identity resolution: spotting that two records with slightly different spellings are the same customer.
  • Enrichment: filling product attributes from descriptions, or tagging tickets by topic.
  • Anomaly detection: flagging an order with a negative quantity or a sudden drop in a field’s completeness.
  • Segmentation: grouping customers by behavior once the data is clean. Our AI-driven segmentation best practices go through this for marketing teams.

Two cautions apply. First, let people approve merge and correction rules on a sample before they run on the whole base, since an automatic merge of two different customers is hard to undo. Second, sending customer records to an external model is itself a processing of personal data: it needs the same legal basis, minimization and contractual framework as any other.

Our perspective: start from the use case, not the dataset

We build chatbots, workflow automations and custom AI tools for businesses, and the pattern repeats. Teams ask us how much data they need, when the better question is which decision or conversation the tool will handle. Once that is clear, the data requirement shrinks to something concrete: a catalog, a set of resolved tickets, a handful of process documents.

That is why we favor a short proof of concept on a narrow scope before any large data program. A PoC shows within days which data is usable, which is missing and which cannot be used for legal reasons, at a fraction of the cost of a full data-lake project. We would rather discover a gap in a two-week test than six months into a build.

Our second conviction is that production data deserves as much design as training data. A chatbot that talks to your customers generates a stream of new personal data every day. Decide up front what is stored, for how long, who can read it and how it feeds improvements, and the compliance work stays light.

— Botiqueai

Turning prepared data into a working tool

Once your data is qualified, the next step is a tool that uses it: a website or e-commerce assistant, a WhatsApp channel, or an automation that connects your CRM and back-office systems. We design these projects around your own data and existing systems, starting with a free initial audit and with no long-term contract required. You can see the range on the Botiqueai site, or look at our custom AI automations if your priority is internal processes.

Botiqueai

For Shopify merchants, we also publish packaged apps at 19 USD per month (Starter) and 49 USD per month (Pro), described on the Shopify app page.

FAQ

What types of data can be used to train an AI?

Text, images, audio, structured tables, sensor readings and metadata can all be used, as can reference data such as glossaries or knowledge graphs that add context. What you may use depends on origin and rights, not on format. For personal data in France, the GDPR and the CNIL’s guidance apply.

Who supplies the data behind AI systems?

Three sources dominate: public material collected from the internet, datasets licensed from third parties, and data generated by users when they interact with a service. For a company’s own tool, the main source is usually its own records, such as CRM data, tickets and documents.

How much data does my company need?

There is no universal figure. The CNIL asks you to justify the volume against the difficulty of the task, so a narrow classification task needs much less than an open-ended assistant. Start small, test on data the model has not seen, and add data only where errors cluster.

Can I use my customers’ data to train an AI?

Only if you have checked that the new purpose is legally justified, kept the data to what is necessary and applied protective measures such as pseudonymization. A data protection impact assessment may be required. Ask your DPO or a data protection lawyer before the first training run.

Sources

© 2026 BotiqueAI — Reproduction prohibited without attribution.