# 10-Question Data Readiness Survey for AI Adoption > A Data readiness survey for AI adoption is a short, structured assessment that tells you if your data can actually support the AI use cases you want. It works best when it is scoped to a handful of business outcomes, run with the people closest to the systems, and backed by quick evidence checks. Use it to surface missing fields, inconsistent definitions, access bottlenecks, and governance gaps before you commit to a build. The output should be practical: a ranked list of use cases by feasibility, the top data blockers that will delay delivery, clear ownership for fixes, and a phased plan that reduces risk while keeping momentum. Published: 2026-08-11T13:40:53.833Z · Canonical: https://zealsight.com/blog/10-question-data-readiness-survey-for-ai-adoption Most AI initiatives don’t fail because the model is “not smart enough.” They fail because the data is fragmented, inaccessible, or untrusted, and nobody finds out until the pilot is already burning time and budget. A data readiness survey is one of the fastest ways to surface those issues early and turn “we should use AI” into an execution plan you can defend. ## What is Data readiness survey for AI adoption Data readiness survey for [AI adoption](/services) is a structured assessment that measures an organization's data quality, accessibility, governance, and infrastructure to determine preparedness for AI projects and guide prioritization and planning. In plain terms, it’s a short, systematic set of questions (plus a few evidence checks) that tells you whether your data can support the AI use cases you care about, what will break first, and what to fix in what order. A good survey does two things at once: - De-risks delivery by identifying data blockers before you commit to a build. - Improves decision-making by helping you rank AI use cases based on feasibility, not excitement. ## Why run a data readiness survey before adopting AI AI projects often stall on fundamentals: missing fields, unclear definitions, slow access approvals, and governance gaps. A readiness survey makes those constraints visible before you commit engineering time and change management effort. It also prevents a common mismatch: the team proposing an AI copilot assumes the data is clean and complete, while the people who live in the systems know it is not. Without a structured intake, you end up debating opinions instead of diagnosing reality. Finally, it forces governance to become practical. It is not enough to say “we’ll be careful with data.” You need to answer who can access what, under what conditions, how the system should behave when it is uncertain, and how you will audit usage. > Treat data readiness as a pre-flight checklist: it won’t fly the plane for you, but skipping it is how “quick pilots” become expensive delays. ## Designing an effective data readiness survey: scope, stakeholders, and format A survey only helps if it’s scoped to decisions you actually need to make. The best version is not a generic questionnaire. It is anchored to a short list of candidate use cases and the data they require. ### 1) Start with a narrow scope tied to business outcomes Pick a small set of candidate AI use cases and design the survey around them. Example set for a mid-size services firm: - Customer support knowledge assistant (RAG over policies, product docs, tickets) - Sales proposal generator (RAG over past proposals and pricing rules) - Finance: invoice coding and anomaly detection - Operations: demand forecasting using historical orders - HR: onboarding Q&A assistant (policies, benefits, training) This keeps the survey actionable. “How good is our data?” is too broad. “Can we support invoice coding with our current AP data and document capture process?” produces decisions. ### 2) Involve the people who know where the bodies are buried If you only ask leadership, the survey will look cleaner than reality. Include: - Business owner for each use case (support lead, finance lead, etc.) - Data owner/steward (often operations or analytics) - IT/data engineering (access, pipelines, tooling) - Security/compliance/legal (PII, retention, audit needs) - Frontline users (how data is actually entered; what “good” looks like) ### 3) Choose a format that balances speed with evidence A practical approach: - Pre-read survey (30–45 minutes): structured questions with “select one” maturity options plus short free-text. - Working session (60–90 minutes per domain): reconcile answers, capture examples, list systems and tables, clarify ownership. - Evidence spot-checks (1–2 hours): quick queries or samples (e.g., 50 tickets, 50 invoices) to validate quality claims. ### 4) Make “unknown” an acceptable answer Many teams will not know lineage, access constraints, or quality metrics. Design the survey so “unknown” is a valid response. You are mapping risk, not grading people. ## Key survey dimensions and sample questions (quality, availability, lineage, governance, tooling) Below are the dimensions that most directly predict whether an [AI pilot](/services) will ship on time and whether it will be trusted after launch. ### Data quality (accuracy, completeness, consistency) Focus on the data elements your use cases need. Sample questions: - What share of records are missing critical fields (e.g., customer segment, invoice line items, ticket category)? - Are there known duplication issues (duplicate customers/vendors/leads)? How are duplicates resolved? - Are key fields standardized (country codes, product SKUs, reason codes), or free-text? - How often do business rules change (pricing, policy, eligibility), and how is the change reflected in data? - What were the most recent data quality incidents, and what caused them? Evidence to request: - Recent data quality report (if any) - Simple profiling output (null rates, distinct values) for 3–5 key fields ### Data availability and accessibility (can you actually get it?) AI teams lose time here. Sample questions: - Which systems contain the source data (CRM, ERP, ticketing, shared drives, email, data warehouse)? - Who can grant access, and what is the typical approval path? - Is the data centralized (warehouse/lake) or siloed across departments? - Are there API limits, export restrictions, or vendor constraints? - Is historical data available for the needed time period (e.g., last 24 months)? ### Lineage and context (definitions, provenance, “what does this field mean?”) AI output depends on meaning, not just existence. Sample questions: - Do we have a data dictionary for the key entities used by the use case? - Are definitions consistent across teams (what counts as “active customer,” “resolved ticket,” “churn”)? - Can we trace a metric back to source systems and transformation steps? - How are corrections handled (backfills, overrides), and are they documented? ### Governance and risk (privacy, compliance, model behavior constraints) Especially important for customer data and employee data. Sample questions: - What data is sensitive (PII, PHI, financial, employee), and how is it classified? - Are retention policies defined and enforced? - Is there an approval process for using certain datasets in AI systems? - What are the acceptable failure modes? (For example: the assistant can suggest an answer, but must cite sources; it cannot invent policies.) - How will you audit usage and outcomes (who asked what, what did the system answer)? ### Tooling and infrastructure (pipelines, storage, monitoring) You don’t need perfect tooling, but you need enough to run and maintain the system. Sample questions: - Where will the “system of record” live for the AI application (warehouse, operational DB, vector store)? - Do we have a standard approach for ETL/ELT and scheduling? - Can we monitor data drift and pipeline failures? - Do we have a secure environment for model experimentation and deployment? - Who will support it after launch (on-call, incident response, change management)? ### A quick reference table you can reuse | Dimension | What “ready” looks like | Common red flags | What it breaks first | | --- | --- | --- | --- | | Quality | Critical fields mostly complete; clear standards; known error patterns | Free-text where codes are needed; duplicates; inconsistent IDs | Model accuracy, trust, and adoption | | Availability | Access paths are known; approvals are predictable; historical coverage exists | “We can export it if someone has time”; vendor limits; missing history | Pilot timeline and scope | | Lineage | Definitions documented; transformations traceable | Metric disputes; unknown transformations; tribal knowledge | Validation, explainability, stakeholder alignment | | Governance | Data classified; permissions clear; audit plan exists | No owner; unclear PII handling; no retention policy | Security review, compliance, and rollout approval | | Tooling | Stable pipelines; monitoring; clear support ownership | Manual extracts; brittle scripts; no monitoring | Reliability and cost to operate | ## Scoring and maturity framework: how to interpret responses and rank use cases The goal of scoring is not to produce a heatmap. It is to answer two leadership questions: 1. Which AI use cases can we ship with acceptable risk in the next 6–12 weeks? 2. What data work must happen to unlock the next wave? ### A simple 0–3 maturity scale per dimension Use something like this across each dimension (quality, availability, lineage, governance, tooling): - 0 = Unknown/Absent: no clear owner, no documentation, or cannot access data. - 1 = Ad hoc: can get data manually; quality issues known but unmanaged. - 2 = Defined: documented process; repeatable access; basic monitoring. - 3 = Managed: measurable metrics; automated pipelines; governance is operational. Then score each use case by weighting what matters most. Example: - Customer support knowledge assistant: weight governance + availability + lineage heavily. - Forecasting: weight historical availability + quality + consistency heavily. - Invoice coding: weight quality (structured line items) + tooling (document ingestion) heavily. ### Ranking use cases with a feasibility x value matrix Combine two scores: - Business value (revenue, cost, risk reduction, cycle time) - Data feasibility (your maturity scores, plus effort to close gaps) This helps you avoid a common failure mode: picking the “highest value” use case that requires months of data cleanup before you can learn anything. ### Concrete example: three use cases, different readiness Imagine a mid-size B2B company considering: 1. Support assistant for agents 2. Sales proposal drafting 3. AP invoice coding Your survey might reveal: - Support content exists but is scattered in SharePoint and PDFs; governance is acceptable; access is straightforward. - Proposals are in many formats; pricing rules change and live in multiple spreadsheets; lineage is weak. - Invoices are mostly PDFs; line-item extraction is inconsistent; vendor master data has duplicates. Result: you might pilot (1) first, start a data workstream for (3) (vendor master + document ingestion standardization), and postpone (2) until pricing rules are centralized. ## Turning survey results into an AI roadmap: prioritization, pilots, and resource planning A survey becomes valuable when it produces an [AI roadmap](/services) that ties each use case to specific prerequisites, owners, and timing. ### Use survey outputs to define “pilot-ready” criteria For each pilot candidate, write 6–10 non-negotiable criteria, for example: - Data access approved for the pilot team - Minimum dataset assembled (what, where, time range) - Source-of-truth agreed for key fields - Safety and governance requirements defined (what the system can and cannot do) - Success metrics agreed (cycle time, resolution rate, deflection, error rate) This is where strategy becomes execution. You stop debating whether to “do AI” and start deciding what to do first, with what constraints. ### A practical, concrete 7-step plan (use this as your template) 1. Pick a small set of AI use cases tied to a measurable business outcome (cost, time, revenue, risk) and name an accountable business owner for each. 2. Map each use case to required datasets, systems, and users (who creates the data, who consumes it, where it lives). 3. Run the data readiness survey with business, IT, and risk stakeholders, allowing “unknown” answers and capturing evidence requests. 4. Score each use case across quality, availability, lineage, governance, and tooling using a simple 0–3 maturity model, then weight scores by what each use case needs most. 5. Identify the top data blockers and convert them into discrete work items with owners and dependencies (for example: “standardize customer IDs across CRM and billing”). 6. Select 1–2 pilot use cases that are high value and high feasibility, define pilot-ready criteria, and lock success metrics before building. 7. Publish a 90-day plan that includes: pilot build, required data workstreams, governance changes, and an operating model for support and iteration. ### Resource planning: who you’ll actually need Survey findings typically translate into resourcing like: - A business product owner (per pilot) - A data lead (to assemble datasets, resolve definitions) - Data engineering support (pipelines, access, integrations) - Security/compliance reviewer (especially if customer or employee data) - An AI engineer/partner for the application layer (RAG, copilots, agents) - Someone accountable for change management and training If you want an external partner to pressure-test this quickly, an [AI assessment](/contact) that includes use case selection and data readiness scoring can reduce rework and prevent pilots that cannot scale. ## Operationalizing findings: governance changes, data workstreams, and measuring ROI “Readiness” is not a one-time score. It becomes operating discipline. ### Turn blockers into data workstreams (not vague “cleanup”) A useful survey output is a backlog with clear categories: - Access workstream: permissioning, SSO, role-based access, vendor approvals - Quality workstream: deduplication, field standardization, validation at entry - Lineage workstream: data dictionary, metric definitions, transformation documentation - Governance workstream: classification, retention, audit logging, acceptable-use policies - Tooling workstream: pipelines, monitoring, incident response Each work item should answer: what changes, who owns it, when it’s done, and how you’ll verify. ### Make governance practical for GenAI Governance is not a PDF. It is decisions embedded into systems: - What data can be used for retrieval and summarization? - Must answers cite sources? (Often yes for policy, finance, legal, and HR.) - What content is excluded (confidential contracts, private employee data)? - How are prompts, outputs, and user actions logged? - What is the escalation path when the system is wrong? ### Measuring ROI: pick metrics you can actually attribute Measure outcomes that connect to a specific workflow and a clear baseline. Examples: - Support assistant: time to first response, issues resolved per hour, escalation rate, QA score - Invoice coding: cycle time per invoice, exception rate, % straight-through processing - Sales proposals: time from request to first draft, pricing/terms error rate, win rate (longer lag) ### Closing the loop: from survey to measurable business results A data readiness survey for AI adoption is not “data bureaucracy.” It is how you avoid spending weeks building demos that cannot ship, and how you create an AI roadmap that sequences pilots alongside the data and governance work required to scale. If you want a simple operating rhythm that keeps this grounded, use a structured lifecycle: Discover → Pilot → Scale → Operate. In practice, that means you confirm readiness and value drivers first, launch a tightly scoped pilot with clear success metrics, then invest in the data workstreams and governance needed to expand safely. The payoff is not “having AI.” The payoff is faster cycle times, fewer errors, and better decisions you can measure, defend, and repeat across the organization.