Planning the Validation Phase of an AI Engagement
A common belief holds that data access can be arranged after an AI engagement begins, but the source treats it as something to design before the engagement starts.
The Belief That Access Can Wait
A very common way of thinking about an AI project goes like this. First the team agrees on the goal. Then a vendor is brought in. Only afterward does anyone worry about how the vendor will get at the data. In this view, data access is a small administrative detail, something that can be handled with a request or two once the real work is underway. This is the misconception this article addresses.
The source takes the opposite position. The vendor will need access to your production data, in some form, during the validation phase. The way that access is arranged has to be designed before the engagement starts. Access is therefore not a late-stage detail. It is one of the things that determines whether the engagement can move at all.
What do you think happens?
Suppose a buyer has never planned how a vendor will reach production data, and getting that access normally takes several months through the organization's standard processes. Where in the project will this delay be felt?
Reveal answer
The delay is felt in the validation phase, because the vendor needs production data during validation and cannot proceed with that work until access arrives.
The source states that the vendor needs production data during validation. If the access path is a multi-month process by default, the engagement will stall in validation.
Where the Delay Lands
Trace what happens when access is unplanned. The engagement begins, and the validation work needs production data. A data-access request enters the organization's standard process. If that process takes several months by default, the validation work that depends on the data has nothing to run on. The delay does not stay inside the access request. It moves forward into validation, which is where the vendor's work on production data is supposed to happen.
The timeline shows the key point. The data-access step is early in time, but its effect shows up late, in validation. A buyer who looks only at when the request was made will miss where the schedule actually breaks.
What a Data-Access Path Is
A data-access path is the arrangement by which a vendor reaches production data during the validation phase. The source treats it as one design with four parts, and the path is complete only when all four are decided in advance.
The four parts are separate questions. A buyer can be willing to share a dataset and still not have settled the environment it lives in, the controls that govern it, or the date it can actually be delivered. Agreement on one part does not settle the others. That is why the source describes access as something to design rather than something to request later.
The diagram shows one path with four decisions. The caption question asks which decisions must be made before the engagement starts. The answer, drawn from the source, is all four, made in advance.
Two Buyers, One Vendor
The following scenario is invented to show how the source's rule plays out in practice. It is not a case from the source. Two buyers begin identical AI validation work with the same vendor, and both want the vendor to see production data during validation.
Comparing an unplanned path with a designed path
Buyer A never planned the data-access path and relies on the standard process. Buyer B designed the full path before the engagement started. Both need production data during validation. What happens to each engagement?
- 1Buyer A starts without a path
Access is treated as a request to be made once the work is underway, which is the misconception the source describes.
- 2Buyer A enters the standard process
Under the standard process, access takes several months by default, so the data does not arrive when validation needs it.
- 3Buyer A's validation stalls
The vendor needs production data during validation, so the validation work waits and the engagement stalls there.
- 4Buyer B settles all four decisions first
Buyer B decides what data, in what environment, with what controls, and on what timeline before the engagement begins.
- 5Buyer B's validation can proceed
With the path designed in advance, the vendor's validation work is not held up by an unplanned access request.
Both buyers needed the same production data. Buyer A's engagement stalls in validation because access was left unplanned. Buyer B's engagement can move because the path was designed before the work began.
Expedited Access and Engagement Progress
The source notes that if data access is a multi-month process by default, the engagement will stall in validation, while expedited access for prioritized projects can let the engagement move. Expedited access therefore changes how fast the validation schedule can advance, because it removes the wait that a standard process would impose.
Mistakes Buyers Make When Access Is Unplanned
Common mistake Treating data access as a small administrative detail
What it looks likeThe team agrees on the goal, brings in a vendor, and plans to handle access with a request or two later.
Why it failsThe vendor needs production data during validation, so access determines whether validation can start and continue.
Do this insteadDesign the data-access path before the engagement starts, settling all four decisions in advance.
Common mistake Assuming agreement on the data means the path is complete
What it looks likeThe buyer agrees to share a dataset but has not decided where it lives, which controls govern it, or when it can be delivered.
Why it failsThe path is complete only when all four decisions are made, so one agreed part leaves the others open.
Do this insteadCheck each of the four decisions separately before treating the path as finished.
Common mistake Leaving the timeline undecided
What it looks likeThe data is chosen and controlled, but no delivery date is set.
Why it failsWithout a delivery date, the validation phase has no known start, and a multi-month default process can stall the engagement there.
Do this insteadSettle the date the data can actually be delivered as part of the path.
Common mistake Relying on the standard process when the project needs to move, without considering expedited access for prioritized projects
Practice Designing a Data-Access Path
A buyer is about to start validation work with an AI vendor. The vendor needs production data during validation. The buyer has agreed in principle to share a customer dataset, but has not discussed where it is stored, what controls apply, or when it can be delivered. Using the four decisions, list what the buyer must settle before the engagement starts, and explain which of those gaps would stall validation if left open.
Hints
- Check each of the four decisions separately: what data, which environment, what controls, and what timeline.
- Agreement on one part of the path does not settle the others.
- Think about the step the vendor cannot proceed without during validation.
Key Takeaways
- A common belief holds that data access can be arranged after an AI engagement begins, but the source treats it as something to design before the engagement starts.
- The vendor needs access to production data, in some form, during the validation phase, and that access is the data-access path.
- A data-access path settles four things in advance: what data, in what environment, with what controls, and on what timeline. The path is complete only when all four are decided.
- If data access is a multi-month process by default, the engagement will stall in validation, while expedited access for prioritized projects can let the engagement move.
- Leaving data access unplanned leads buyers to treat it as a small detail, to assume one agreed part completes the path, or to leave the timeline undecided.