Assess Whether the Data Can Actually Carry the AI Use Case

Workflow area: AI Opportunity & Feasibility · Tier: Advanced · Hands-on time: ~45 minutes

Data readiness is where AI initiatives die quietly. The demo ran on the vendor's curated sample; production has 34% nulls in the critical field, the consent basis covers billing but not model input, and the knowledge base the agent needs at runtime lives in a system with no API. None of these are discovered by enthusiasm — they are discovered by assessment, and the analyst who runs it before the business case is funded converts fatal surprises into scoped prerequisites. Profiling scripts and LLMs make the assessment an afternoon's work; the judgment about what blocks and what merely delays stays yours.

When to use — and when not to

• Use it on every AI candidate before the business case is approvedreadiness gaps change the cost stack and the timeline, so they belong in the case, not after it.
• Use it when a vendor claims "it just needs your data"this assessment is the checklist that sentence is designed to skip.
• Use it to compare candidateswhen two opportunities score similarly on value, data readiness is usually the honest tiebreaker.
• Skip it before the use case is specific"readiness" is relative to a defined purpose: which decisions, which inputs, at what freshness; assess against a use-case one-pager, not a theme.
• Skip treating it as a data-governance audityou are assessing fitness for one use case, not certifying the estate; scope creep here kills the afternoon-sized assessment.
• Skip legal conclusions made soloyou draft the legal-usability analysis with citations to consent records and policies; privacy counsel confirms it. That review is a prerequisite like any other, with an owner.

The recipe

1. 1.

   Write the data demand profile. From the use case, list what the AI actually needs: input fields at prediction/generation time, context or knowledge sources, historical examples for evaluation (and training, if any), required freshness, and volume. Have the AI draft it from the use-case description, then correct it — a fuzzy demand profile makes every later score meaningless.

2. 2.

   Assess existence and quality with profiling, not opinions. For each demanded source, run the profiling pattern (see the data-profiling playbook): does the data exist for the full population or a biased slice, and at what quality on the fields that matter? Generate the scripts with the AI; run them in the governed environment. Capture per-source: coverage %, null rates on critical fields, format consistency, and label quality where ground truth is needed.

3. 3.

   Establish ownership and legal usability with citations. For each source, record the accountable owner (a name, not a department) and their answer to "can this use case use this data?" Then draft the legal analysis:

   Copy

   You are helping a business analyst draft a data-usability
   analysis for privacy-counsel review (DPDP Act 2023 + GDPR
   context). Use case: [ONE LINE]. For each source below, I
   provide: data categories, collection purpose as stated in
   the notice/consent record, and storage location.
   [PASTE PER-SOURCE FACTS]
   
   For each source, output: personal data? Y/N | original
   purpose vs this use — COMPATIBLE / STRETCH / INCOMPATIBLE,
   with reasoning | consent or legal basis gap, if any |
   cross-border transfer issue, if any | minimization option
   (could the use case work with masked, aggregated, or
   synthetic data?) | questions counsel must answer.
   Rules: cite only the facts I provided — where a consent
   record or notice is missing, say MISSING, do not assume.
   This is a draft for counsel, not a legal conclusion.
   

4. 4.

   Test runtime retrievability — the dimension everyone forgets. For each source the AI needs at runtime: is there an API or query path with acceptable latency? Is access permissioned in a way the AI system can inherit? Is the data fresh enough at the moment of use? A knowledge base that is perfect but only exportable as a monthly PDF dump scores zero here. Where feasible, prove it: one test retrieval per source, timed, is worth a page of architecture assurances.

5. 5.

   Score the scorecard and classify the gaps. Five dimensions × each source, scored 1–5 with written anchors, worst-dimension-wins per source (a 5-quality source with an INCOMPATIBLE legal basis is not usable). Sample:

   Copy

   SOURCE          EXIST QUAL OWN LEGAL RETR  VERDICT
   Claims history    5    3   5    4     4   READY-WITH-WORK
     Gap: assessor_notes 34% null post-2024 (system change)
     → P1: backfill or exclude; owner: R. Iyer; 3 wks
   Customer emails   5    4   3    1     3   BLOCKED
     Gap: consent covers service delivery, not AI training
     → P2: counsel review + notice update OR synthetic
       substitute; owner: privacy office; gating
   Policy documents  4    2   5    5     1   READY-WITH-WORK
     Gap: no API; quarterly PDF export only
     → P3: retrieval pipeline; owner: IT; cost to case
   

   Every gap becomes a prerequisite: description, owner, effort estimate, and whether it is GATING (blocks the pilot) or PARALLEL (runs alongside).

6. 6.

   Feed the verdict into the business case, whatever it says. Deliverable: the scorecard, the prerequisite register with owners, the counsel-review draft, and a one-paragraph verdict — proceed, proceed-after-prerequisites (with their cost added to the case's cost stack), or stop-and-fix-data-first. An honest "the data cannot carry this yet, and here is the funded path to change that" is a career-making finding, not a failure.

Make it yours

• Data-catalog exports as the head start: where Collibra/Purview-class catalogs exist, export lineage, ownership, and classification per source and have the AI pre-fill the scorecard — then verify the catalog against reality, because catalogs drift.
• NIST AI RMF checklists as the governance wrapper: map the assessment's dimensions to the Map/Measure functions so the scorecard slots into enterprise AI governance without translation.
• Script-only mode for restricted sources: the AI writes profiling scripts from schemas; data engineers run them in place and return findings tables — full assessment, zero rows moved.
• Portfolio heatmap at program scale: stack scorecards across candidates into a sources × dimensions heatmap — shared blockers (one consent gap blocking three use cases) become the data team's funded roadmap.

Quality check

• Assessed against a specific demand profilefields, freshness, volume, and eval data needs written down before any scoring.
• Quality scores come from profiles, not interviewsevery quality claim carries a measured figure; owner beliefs were tested, not transcribed.
• Legal usability is drafted with citations and routed to counselpurpose-compatibility reasoned per source, MISSING records flagged, counsel review logged as a gating prerequisite.
• Retrievability was tested, not assertedat least one timed retrieval per runtime source, or the gap is scored and registered.
• Every gap has an owner, an estimate, and a gating classificationthe register reads as a plan, not a lament.
• The verdict reached the business caseprerequisite costs in the cost stack, and a stop verdict delivered as findings, not buried.