Your AI data strategy needs a use-case queue

Most mid-size companies do not need a broad data modernization program before they can use AI. They need a ranked queue of business decisions, a precise account of the data each decision requires, and permission to stop work that does not move one of those decisions into production.

That sounds narrower than an enterprise data strategy because it is. I have watched companies spend two quarters cataloging tables, standardizing names, and moving data between platforms while the sales team still copies renewal notes into a spreadsheet. The activity looks responsible. It produces architecture diagrams and steering meetings. It does not prove that AI can improve a decision, shorten a workflow, or remove enough manual work to justify its operating cost.

A useful AI data strategy connects every data task to an AI use case with an owner, a measurable decision, an evaluation set, and a release gate. The plan should make the first useful system possible within one quarter, then reuse what that system taught you. Mid-size companies cannot afford to imitate the foundation programs of a bank or a global marketplace. They have less data, fewer specialists, and a much shorter distance between an operational problem and the executive who owns it. That is an advantage if they resist platform theater.

Put use cases ahead of data domains

Start with a queue of decisions or work products that AI could change, not a list of databases that need attention. A domain such as customer data is too broad to fund sensibly. A decision such as "which open support cases need escalation before the service deadline" gives the team something it can test. It names the users, the moment of use, the cost of a miss, and the records needed to judge the result.

I ask operating leaders for recurring work where someone reads, classifies, drafts, predicts, or searches. Then I discard ideas that lack a named workflow owner or a way to compare the AI result with current practice. "Chat with all our data" fails both tests. It has no bounded decision and no stable definition of a good answer. A renewal risk brief for account managers can pass: the owner is the head of customer success, the output is a brief produced before a renewal review, and historical briefs plus outcomes can form an evaluation set.

Keep the first queue short. Five to eight candidates are enough to expose the tradeoffs without creating a bureaucratic intake process. For each candidate, record the current volume, time per item, error cost, available source records, person accountable for adoption, and action taken after the output. If nobody acts differently after seeing the result, the use case is reporting with an AI label.

A practical queue mixes one near term productivity case with one decision support case. Drafting a first response for support agents may save time quickly, while detecting likely renewal blockers may create more value but require harder evaluation. Do not fill the queue with ten versions of summarization simply because they are easy to demo. Easy demos often hide weak economics: people still review every output, the workflow stays unchanged, and the company adds model cost without removing work.

The queue is also your refusal mechanism. When someone proposes cleaning all product telemetry "for future AI," ask which queued use case cannot proceed, which field blocks it, and what acceptance test the cleanup will pass. If the answer is vague, leave the task unfunded. Data debt is real, but unbounded cleanup is not a strategy.

Readiness belongs to a use case, not a warehouse

Data is ready only relative to a particular prediction, answer, draft, or decision. A warehouse can be well modeled for monthly finance reporting and still be useless for a support assistant because ticket comments arrive late, attachments are missing, and resolution codes mean different things across teams. Calling the warehouse "AI ready" hides those facts.

Separate three questions that teams routinely blur. Data availability asks whether the required records can be accessed lawfully and reliably. Semantic correctness asks whether fields mean what the use case assumes. Evaluation fitness asks whether you have representative examples with outcomes or human judgments that can distinguish a useful result from a plausible one. Passing the first question does not imply the other two.

Consider a churn model trained on a customer_status field. The column is complete and documented, so an availability review passes. Sales operations changed the meaning of "inactive" halfway through the year, so the semantics fail. Even after correcting that change, cancellations caused by a discontinued product dominate the old records and no longer represent current customers, so evaluation fitness fails. A team that treats completeness as readiness will train successfully and ship the wrong model.

Use a compact readiness card for each candidate. This is the minimum artifact I want before data engineering starts:

use_case: renewal-risk brief
workflow_owner: head of customer success
decision: which accounts receive an intervention this week
output: five-sentence brief with cited CRM events
source_records:
  - account activity
  - support cases
  - renewal date
allowed_uses: internal account planning
forbidden_uses: automated price or contract changes
evaluation_set: 150 closed renewals sampled by segment
acceptance_gate: owner approves evidence and action for 80% of briefs
rollback: disable brief generation and keep current review

The numbers in a real card must come from the owner, not from this example. The point is the shape: an accountable decision, bounded input, permitted use, evaluation evidence, a release threshold, and a way back. If the team cannot fill a field, it has found a specific data or governance task. That is much more useful than assigning a maturity score to the whole company.

Rank work by value, evidence, and friction

Prioritize each candidate with a small scoring model that makes disagreements visible. Do not pretend the score is objective. Its job is to force the CFO, workflow owner, data lead, and engineering lead to state why one use case deserves scarce attention before another.

Score four factors from one to five: annual value if adopted, strength of available evaluation evidence, workflow adoption probability, and delivery friction. Value should count labor actually removed, losses plausibly avoided, or revenue actions the owner can trace. Evidence measures whether past examples and outcomes represent present work. Adoption probability asks whether the output appears inside an existing workflow and whether the owner can change that workflow. Friction covers access, privacy review, integration, data repair, and operational support.

Use a simple formula such as priority = value * evidence * adoption / friction. Multiplication punishes a candidate with no evidence or no adoption path. A weighted sum can let a glamorous high value estimate conceal the fact that nobody knows how to test or use the result. The exact arithmetic matters less than writing the assumptions beside every score.

Suppose a support reply assistant scores 3 for value, 5 for evidence, 5 for adoption, and 2 for friction. Its score is 37.5. A demand forecasting project scores 5, 2, 2, and 5, giving 4. The forecast may carry the larger theoretical prize, but it should not lead the first quarter. It lacks representative evidence, sits outside a daily approval loop, and needs several source systems reconciled. Build evidence before funding integration.

Set two vetoes. First, reject a candidate without a workflow owner who controls adoption. A technology sponsor cannot force sales or operations to change how they work. Second, reject a candidate when harm from a wrong answer cannot be contained through review, restricted actions, or rollback. High value does not excuse an unsafe release path.

NIST's AI Risk Management Framework organizes work into govern, map, measure, and manage, and it explicitly says the actions are not an ordered checklist. That qualification matters. Companies often turn guidance into a long compliance preface before they test anything. Map the actual context and risk of a queued use case, measure it with representative records, govern who may use it, and manage what happens after release. Apply those activities to the work at hand instead of demanding that the whole organization finish a universal AI program first.

Quarter one proves a complete decision loop

The first quarter should deliver one bounded use case through a complete decision loop, including evaluation and rollback. It should not deliver an AI platform. Choose the highest ranked candidate that one cross functional team can put in front of real users without giving the model authority to make an irreversible decision.

During weeks one and two, baseline the current workflow. Measure arrival volume, handling time, rework, delay, and the business outcome the owner cares about. Sample actual work instead of relying on interview estimates. People omit exception handling when they describe a process, and exceptions usually consume the time an AI proposal claims it will save. Record where source data arrives late, where staff leave free text, and where judgment changes the next action.

During weeks three through five, assemble an evaluation set before building the polished interface. Sample across customer size, product line, language, season, and known difficult cases where those dimensions apply. Remove duplicates that would let a retrieval or generation system appear to remember the answer. Ask domain reviewers to define acceptable evidence, unacceptable claims, and cases that require abstention. Keep disagreements; they reveal policy gaps the model cannot solve.

A plain acceptance query makes progress harder to fake. For a classification use case, store one row per evaluation item and run something like this after every candidate release:

SELECT
  model_version,
  COUNT(*) AS reviewed_items,
  ROUND(AVG(CASE WHEN reviewer_decision = 'accept' THEN 1.0 ELSE 0 END), 3) AS acceptance_rate,
  SUM(CASE WHEN severity = 'critical' AND reviewer_decision = 'reject' THEN 1 ELSE 0 END) AS critical_rejects
FROM ai_eval_results
GROUP BY model_version
ORDER BY model_version;

The output should look like v0.3 | 150 | 0.827 | 1, not a slide that says quality improved. A release gate can require an agreed acceptance rate and zero critical rejects, but the owner must set those thresholds for the risk. Track latency and cost separately. A model can pass quality review and still be too slow or expensive for the workflow.

During weeks six through nine, run the system in shadow mode or require human approval. Capture the source records used, model and prompt version, output, reviewer change, final action, and later outcome. Do not log sensitive raw content by default; store the minimum evidence needed to reproduce and investigate a decision under your retention rules.

Use the final weeks to decide whether to release, revise, or stop. A stop is a useful result when the evidence shows weak value or an unfixable access constraint. Preserve the evaluation set, source definitions, and decision record because another use case may reuse them. Do not preserve a pilot as permanent production software if it failed its gate.

Quarter two turns one path into a reusable pattern

The second quarter should make the proven path cheaper to repeat while adding one or two related use cases. Reuse only components that survived real operation. Teams routinely generalize too early, creating a grand ingestion framework around assumptions from a three week prototype.

Promote the source contracts, identity rules, permission checks, evaluation harness, and release logging that the first use case actually needed. A source contract states who owns a dataset, what each critical field means, acceptable delay, permitted uses, and how a breaking change is announced. It does not need a new catalog product. A versioned file reviewed by the data owner and consumer is enough until search and scale justify more tooling.

Add automated tests at the boundary where data enters the use case. Check freshness, row volume, identifier uniqueness, allowed values, and joins that unexpectedly drop records. Test business semantics too. If resolved_at can precede created_at because of a migration, a generic null check will miss the failure that breaks handling time calculations. Each test should name the decision it protects so future maintainers know whether to repair, revise, or delete it.

Choose adjacent use cases that reuse a source or workflow, not merely the same model vendor. A support triage classifier may lead naturally to an escalation brief because both rely on ticket history, customer tier, service deadlines, and agent review. An accounts payable extraction project does not become adjacent because both systems call a language model. Data and operational reuse create economies; a shared API alone rarely does.

By quarter end, one team should be able to create a new readiness card, obtain approved sample data, run the common evaluation harness, and produce a release decision without inventing the process again. Keep the platform team small. If it starts accepting requests unrelated to queued use cases, it will become an internal vendor with a growing backlog and no business outcome.

Quarter three expands access without losing evidence

The third quarter should widen the portfolio only after the company can trace each output to source evidence, a version, an owner, and a user action. Expansion means more workflows can use the pattern safely. It does not mean opening a general assistant over every document.

Add the access controls that repeated use has shown you need. Separate the right to query a source from the right to use its content for model training, prompt context, evaluation, or logs. These permissions differ. A customer contract might permit staff to read a support case while prohibiting reuse for training. A role based database grant cannot express that distinction by itself, so the use case needs an allowed use field and enforcement at retrieval and logging boundaries.

Create a small registry of production AI use cases. Record the owner, users, decision, sources, allowed uses, model and prompt versions, evaluation set, gate result, monitoring signals, review date, and shutdown procedure. NIST recommends mechanisms to inventory AI systems according to risk priorities. A spreadsheet or repository file can satisfy that outcome for a mid-size company if someone owns it and release reviews use it. Buying a governance suite does not create ownership.

Now add cases with harder retrieval or prediction requirements. Evaluate retrieval separately from generation. If an answer lacks the correct policy paragraph, rewriting the prompt cannot repair missing evidence. Measure whether retrieval returns the needed record, then measure whether the model uses that record accurately, then test whether the complete answer helps the employee act. One blended satisfaction score cannot tell the team which layer failed.

This is also the right quarter to test how behavior changes after release. Compare acceptance, editing, completion time, escalation, and downstream outcomes across user groups. Watch for automation bias: reviewers may approve plausible text faster as they become familiar with the system. Periodically insert known difficult examples or conduct blinded reviews so confidence does not replace evaluation.

Do not expand access when the first workflow still depends on a data engineer fixing records by hand every Monday. That is an unresolved production dependency, not an operating pattern. Fund the fix or narrow the use case before adding consumers.

Quarter four funds winners and retires passengers

The fourth quarter should turn the use case queue into a portfolio with explicit renewal and retirement decisions. Every production use case now competes for data maintenance, model spend, review time, and engineering attention. A system that once passed its gate can become a passenger when volume falls, the workflow changes, or manual review consumes the claimed savings.

Review actual value against the quarter one baseline. Count completed work and downstream action, not generated outputs. If an assistant drafted 20,000 responses but agents rewrote most of them and handling time did not change, it did not create the stated value. If a risk brief changed which accounts received an intervention and improved the owner's chosen outcome, the result can justify more investment even at lower volume.

Recalculate the queue with real evidence. Some candidates will become cheaper because source contracts and evaluation tooling now exist. Others will lose value after the team observes edge cases or adoption resistance. Move them accordingly. A roadmap that never changes after evidence arrives is a sales promise, not a management tool.

For each live use case, choose one decision: fund, constrain, rebuild, or retire. Funding increases reach or removes a measured bottleneck. Constraining limits users, inputs, or permitted actions after a risk appears. Rebuilding changes a failed component while preserving a valid workflow. Retirement removes access, scheduled jobs, stored prompts, stale derived data, and monitoring, then records why the system stopped. Turning off the interface alone leaves cost and exposure behind.

Set the next year's data budget from this portfolio. Shared work earns funding when at least two proven or highly ranked cases need it. That might include customer identity resolution, document permissions, event freshness, or evaluation storage. Work with no named consumer returns to the backlog. This rule will annoy architecture purists, but it keeps a mid-size company from spending its growth capital on hypothetical reuse.

Ownership must follow the operating decision

The business leader who controls the workflow must own the outcome, while data and engineering leaders own the reliability of their components. Assigning the entire program to the CIO or head of data creates a predictable failure: technology ships an output, operations treats adoption as optional, and nobody owns the gap.

Use a small decision group. The workflow owner approves the use case, evaluation rules, and workflow change. The data owner approves definitions, access, and source quality obligations. Engineering owns delivery, observability, rollback, and cost. Security or legal staff define constraints where the data and decision warrant them. The executive sponsor resolves priority and funding disputes. One person may hold several roles in a smaller company, but each decision still needs a name.

Budget by complete use case, not by horizontal department. The cost estimate should include source repair, labeling or review, integration, model usage, monitoring, user training, and ongoing exception handling. A cheap model call can sit inside an expensive human approval loop. Conversely, higher inference cost may be sensible if it removes enough review without raising error cost. Finance needs the whole operating unit, not cost per token in isolation.

Charge shared components to the first use case until a second consumer appears. This exposes the true cost of the pioneer and prevents a platform budget from hiding speculative work. When reuse becomes real, split maintenance based on consumption or business value. Do not spend weeks perfecting internal chargeback arithmetic; the purpose is to reveal ownership and economics.

A Team & AI Audit can compress the initial queue, cost model, and savings review into a five business day engagement when internal incentives make prioritization difficult. The service is a useful forcing function, but the company still needs its workflow owners to accept the decisions and run the plan.

A good plan makes data work easier to stop

The quality of an AI data strategy shows in what the company refuses and retires. Data teams have been trained to treat more collection, more history, and more centralization as progress. AI use cases often need the opposite: a smaller permitted slice, clearer semantics, representative evaluation records, and faster feedback from the person acting on the result.

Beware the popular recommendation to centralize every source before delivering AI. It appeals because one platform sounds easier to govern and avoids visible duplication. In practice, the migration becomes the program, source semantics get flattened, and operating teams wait for data that already exists where the work happens. Centralize a source when multiple proven cases need consistent access or when its current location cannot meet security, reliability, or cost requirements. Do not make centralization an entry fee for learning.

The same discipline applies to data quality. Do not promise clean data. Define the fields, records, freshness, and error tolerance a decision needs, then test them at the boundary. A duplicate customer may be harmless in document search and disastrous in a next best action system that contacts the same person twice. Quality is a contract tied to consequence.

At the end of each quarter, the executive team should be able to answer five questions without a new presentation: Which decision changed? What evidence shows the change helped? Which data obligation keeps it running? What does it cost in total? Under what condition will we stop it? If the answers live only with the technical team, the use case is not part of the business yet.

Keep those answers in a one-page quarterly decision record. For each continued use case, record the owner, baseline period, current result, full quarterly cost, unresolved risk, and next review date. For stopped work, record the failed assumption and assets worth retaining. This document prevents a new executive or vendor from restarting a rejected pilot six months later because nobody can find the reason it ended.

Do one more reconciliation against the engineering backlog. Every data task should point to a live or queued use case, an incident, or a mandatory operational obligation. Mark everything else as unallocated and total its planned effort. I have seen the unallocated bucket expose more waste than the AI business cases themselves: duplicated pipelines, unused semantic layers, and integrations maintained for reports nobody opens. The point is not to delete all shared infrastructure. It is to make its consumers and renewal decision explicit. A shared component without a current consumer needs an owner willing to defend its cost at the same review.

By the end of the year, success is not a perfect data foundation or the number of AI pilots. It is a small portfolio of adopted systems, each tied to a decision, tested on evidence, supported by named data obligations, and easy to shut down. The queue should contain better candidates because the company learned where its records, workflows, and judgment are strong. Fund the next quarter from that evidence. Leave the rest unfunded until a use case earns the work.