Is your data ready for AI? A pre-flight checklist
Models amplify whatever you feed them. Before you buy models or hype retainers, run this plain checklist on sources, quality, access, privacy, and whether your data is a pipeline or a pile of exports.
Vinerals TechnologiesWorkshop notes
A lot of AI projects fail before the model does anything interesting. They fail in the data: scattered exports, inconsistent labels, access nobody can get, privacy rules nobody checked until legal saw the proposal.
Vendors will sell you a pilot anyway. Some will wrap the data cleanup inside a large retainer and call it “AI transformation.” The model is the easy part now. Your data is the part that is yours, and the part that decides whether any of this works.
This is a pre-flight checklist for ops leads and founders who have a specific AI use case in mind and want to know, honestly, whether the ground is solid enough to spend money. No fake thresholds. No magic numbers. Just questions worth answering on paper before anyone trains anything.
Sources, ownership, and access
Start with a simple inventory. Not a data lake strategy. A list on one page of where the information for this project actually lives today.
Name every source.
CRM, ERP, support inbox, shared drive, supplier portal, paper forms someone types up on Fridays. If it feeds the use case, it goes on the list.
Say who owns each source.
Department, vendor, individual. Ownership tells you who can grant access and who can break the integration next quarter.
Confirm you can get it out.
API, scheduled export, manual download, screenshot. Be honest about manual steps. They have a labour cost and an error cost.
Check admin access.
If the only person who can pull the export is leaving in April, that is a blocker, not a detail.
Write down what “one record” means.
A customer, an order, a document, a ticket. AI projects stumble when the unit of data is undefined.
Pre-flight pass: you can pull a sample from every source on the list without a week of IT tickets. Pre-flight fail: the data you need is “in the system somewhere” and nobody has exported it in a year.
Quality, labels, and volume
People want a magic minimum: ten thousand rows, six months of history, 95 percent accuracy. Real projects are messier. What matters is whether the data fits the job you are asking the model to do.
Quality questions
Are the same things named the same way?
Customer names, product codes, categories. If four spellings mean one client, the model learns the mess.
Are fields filled when they matter?
Optional fields that everyone skips are optional for a reason. Either make them required in the process or stop expecting the model to use them.
Do examples include the hard cases?
Scanned PDFs, blurry photos, bilingual labels, the supplier format that only shows up in November. Training only on clean samples is how pilots look brilliant and production falls apart.
Is there a human-verified answer to learn from?
For classification or extraction, you need examples where someone already decided the right label or the right fields. Without that, you have text, not training data.
Volume without fake thresholds
Ask relative to the task, not against a blog post.
Document extraction.
Enough real documents of each type to see variation, plus a few hundred labeled examples if you want the model to beat a simple template. The ugly variants matter more than the count.
Sorting and routing.
Enough past examples of each category to see overlap. If two categories look identical in the data, the model will not separate them either.
Search over your material.
Less about row count, more about whether the content is indexed, current, and permissioned.
Anything predictive.
Usually needs longer, cleaner history than people expect. If you have three months of patchy records, you are not ready for forecasting. You are ready for a data cleanup project.
Privacy, consent, and sector rules
This section is boring until it is the reason legal shuts the project down. For Québec SMEs, Law 25 is part of the pre-flight, not a launch-day checkbox.
What personal information is in the data?
Names, emails, health information, employee records, customer children’s camp registrations. Name it explicitly.
Do you have a lawful basis to use it for this purpose?
Consent, contract, legitimate interest. “We always had this data” is not the same as “we can feed it to a model for this new task.”
Where will processing happen?
Your servers, a Canadian cloud region, a vendor in another country. Location matters for contracts and for customer trust.
Will data leave your environment?
Third-party APIs, hosted fine-tuning, support staff at the vendor reading samples. Each path needs a decision, not a shrug.
Sector-specific rules.
Health, finance, education, minors. Some data should never be in a general model workflow without specialist review.
Retention and deletion.
If the model provider keeps copies for training or support, you need to know how to get them deleted when a client asks.
Pre-flight pass: legal or a qualified privacy lead has seen a one-page summary of what data goes where. Pre-flight fail: “we will figure out compliance after the pilot.”
Pipelines vs one-off exports
A pile of CSV files on a drive is data. It is not a system. AI that needs fresh input every day cannot run on a monthly export someone forgets to run.
One-off exports.
Fine for a two-week pilot to see if document extraction works on last quarter’s invoices. Not fine for production without a plan to refresh.
Scheduled exports.
Nightly or weekly drops to a known location. Better, if someone monitors failures and the schema does not change silently.
APIs and event streams.
Data arrives when things happen. More engineering upfront, less heroics later.
Human-in-the-loop capture.
Sometimes the right “pipeline” is a simple internal tool where people confirm labels as they work. That is valid if you count the labour honestly.
Match the pipeline to the freshness the task needs. Search over policies that change monthly can use a monthly sync. Fraud flags on live transactions cannot use a spreadsheet from Tuesday.
If the pre-flight inventory only works with manual exports, budget the cleanup and automation as part of the project. Do not hide it inside “model tuning.”
Grounding, evaluation, and who checks the output
Before you go live, you need a way to know when the model is wrong and who catches it. This is part of data readiness because the evaluation set is data too.
Holdout examples.
Real cases the model has not seen, labeled the same way as training data. Run them before you trust a demo.
Failure categories.
Wrong field, wrong class, hallucinated clause, missed edge case. Track them separately instead of one “accuracy” number.
Human review path.
Who sees low-confidence outputs? How fast? What do they do with them? A model without a review path is a liability.
Rollback.
If quality drops next month, can you turn it off without breaking the workflow? Readiness includes an exit ramp.
Go / no-go checklist
Score each line yes or no. A few nos does not always kill the project. It tells you what to fix first and what to stop pretending is ready.
1. We named the specific task the model will do.
One job, not a platform vision.
2. We listed every data source and can pull a sample this week.
Without heroics.
3. We have labeled or verifiable examples for that task.
Or we budgeted time to create them.
4. The messy real-world variants are in the sample.
Not only the clean ones.
5. Privacy and sector rules are reviewed for this use.
Documented in plain language.
6. We know how data stays fresh after pilot.
Pipeline, schedule, or human process.
7. We have a human review plan for wrong outputs.
With named owners.
8. We measured the baseline without AI.
Time, errors, cost. So we can tell if the project helped.
Eight yes answers: you are in pilot territory. Five to seven: fix the gaps or narrow the task. Below five: you likely have a data and operations project wearing an AI hat. That project may be worth doing. It is probably not worth buying models yet.
What to do when you are not ready
Not ready is a normal result. It is better than a pilot that teaches you the same thing for ten times the price.
Narrow the task.
One document type, one inbox, one report. Smaller scope often drops the data bar to something you can clear in a month.
Fix capture first.
A simple internal form or integration that makes the record right at the source beats a model guessing from incomplete exports.
Run a labeling sprint.
Two weeks of structured human labeling on past cases. Unglamorous, often enough to unlock the pilot.
Improve search before chat.
If the real problem is finding answers in existing docs, structured search plus good metadata may solve it without a model.
Postpone predictive work.
If history is short or dirty, descriptive tools and dashboards come first.
Saying “not yet” is not anti-AI. It is how you avoid paying model prices for spreadsheet work.
Data readiness is not a one-time certification. Systems change, vendors change fields, and last year’s clean export becomes this year’s mixed-up CSV. The checklist is worth rerunning whenever the use case, the source, or the privacy context shifts.
We build software by hand for SMEs, and a fair share of our AI work starts with no model at all: inventories, pipelines, labeling, and the quiet fixes that make a pilot worth running. If you have a use case in mind and want a plain pre-flight read on the data side, we are glad to walk through this list with you. Bring your source list and one messy sample. We will start there.
