Many AI features need no data of yours at all, because general models already read, classify, summarise and draft well. Features that predict from your history, personalise from behaviour, or handle a task specific to your business need examples: typically hundreds for classification, thousands for prediction, and a clean, consistent record of what happened. If you have none, start with the features that need none, and design the product to collect clean data from day one so the others become possible.
"We do not have enough data for AI" is one of the most common things founders tell us, and it is half right. Some AI features need your data and most early products do not have it. Other features need none, because the model already knows how to do the task. This guide separates the two, says what enough looks like, and explains how to get there.
Features that need no data of yours
General models are trained on enormous amounts of text and images. They can read a document, extract fields, classify a message into categories you describe, summarise, translate, draft and answer questions from content you give them, without any examples from you. For these, what you need is not data but a clear description of the task, a set of real examples to test against, and your content where the task is about your content. Most first AI features belong here. See AI features that actually work.
Features that need your data
| Feature | What it needs | Roughly how much | Why |
|---|---|---|---|
| Classification specific to you | Examples labelled with your categories | Hundreds per category | The model has to learn what your categories mean |
| Prediction | History of the thing you want to predict, with the factors that influenced it | Thousands of records over a period long enough to show patterns | Forecasting needs seasons, churn needs churn |
| Personalisation | What each user did, over time | Weeks to months of behaviour from active users | Recommendations learn from choices |
| Detection of your specific things | Images or records of your products, defects, cases | Hundreds to thousands, covering the variety | General models know what a crack is, not your crack |
| Your tone and format | Examples of outputs done your way | Dozens to hundreds | Fine-tuning or examples in the prompt |
The quantities are rough. Quality matters more than volume. Five hundred clean, consistent, correctly labelled examples beat fifty thousand inconsistent ones.
What counts as usable data?
- Consistent. The same thing recorded the same way every time. A field that sometimes holds a date and sometimes a note is not data.
- Complete enough. Missing values are normal. Missing the field that matters is fatal.
- Labelled, where labels are needed. For classification, each example needs its correct category, decided by a person who knows.
- Representative. Covering the real variety of cases, including the rare ones that matter.
- Timestamped. Prediction needs to know when things happened.
- Lawfully usable. Personal data can only be used for AI within what users consented to and privacy law permits.
If you have none
- Ship the features that need none. Extraction, summarisation, drafting, search, bounded support. They deliver value now.
- Use rules where you would later want prediction. A rules engine handles the known cases and, crucially, records every decision and outcome. That record becomes the training data.
- Collect deliberately. Add the fields you will need later. Ask users the one question that labels their data. Log outcomes, not only actions.
- Label as you go. Every support ticket a person categorises, every document a person checks, is a labelled example. Capture the correction.
- Revisit in six months. With a few thousand clean records, the prediction and personalisation features become possible.
Data hygiene that makes AI possible later
The decisions that determine whether you can use AI in a year are made in the first release, in the database design: consistent fields, sensible types, timestamps on everything, outcomes recorded alongside actions, and a clear separation of personal data from the rest. None of this costs much at the start. All of it is expensive to retrofit. A development team that understands where you want to go will build the data model for it without being asked twice.
How 7L handles the data question
Our AI Business Empowerment approach starts with a data assessment: what you have, what it can support, what needs to be collected. We recommend features that work with what exists, and we design the product to collect what the next features need. An AI project is a data project, and treating it that way is how the second phase becomes possible. Tell us what data you have, even if the answer is none.
Frequently asked questions
Can I buy or download data to train on?
For some tasks, public and commercial datasets exist and can help, especially for detection and general classification. For anything specific to your business, your own data is what matters and no dataset replaces it.
Is my spreadsheet enough to start?
Often, yes, for a first look. A clean spreadsheet of a few thousand rows with consistent columns and dates can support a prototype prediction. The question is whether the columns that matter are there.
How do I label data without a team?
Build labelling into the work people already do. Every time a person categorises, approves, corrects or closes something in your product, record it. Labels accumulate as a by-product of operations.
Can I use customer data to train AI?
Only within what customers consented to and privacy law allows, and with sensitive data handled accordingly. Tell users, minimise what is used, and get advice for regulated data. Many features can work on anonymised or aggregated data.
What if my data is in several old systems?
Then the first project is consolidating it into one clean, consistent store, which is valuable regardless of AI. Our post on software modernisation covers the approach.