Quick answer
Start with the inputs for one workflow, the approved information it must consult, and examples showing what a correct outcome looks like. You also need permission to use that material and an owner who can resolve mistakes. A business AI implementation does not automatically require a large training dataset; using an existing model, retrieving company information, and training a model are different choices.
Separate the jobs your data will do
‘We have years of data’ does not establish whether a workflow can use it. An inbox may contain the requests, a business system may hold the authoritative record, and an experienced employee may be the only person who knows how to resolve an exception. Identify each source before estimating the build.
Microsoft’s AI strategy guidance distinguishes ready-made applications, low-code extensions, managed AI services, and infrastructure-based builds. A custom application can use a managed model. Training or fine-tuning should be a justified design choice, not a presumed prerequisite for every project.
| Purpose | What to collect | What to establish |
|---|---|---|
| Run a case | The email, document, event, or record that starts the work | Required fields, identifiers, formats, and access |
| Ground a decision | Approved policies, product records, or current account information | Authority, freshness, access restrictions, and conflicting versions |
| Evaluate the result | Representative cases with expected outcomes and explanations | What passes, what fails, and when the system must ask for help |
| Adapt a model, if needed | Suitable examples for a specific training objective | Why adaptation is needed, permitted use, and separate evaluation evidence |
Make a small inventory before moving files
Start with source locations and owners. Do not copy every shared drive into a new repository just to make the project feel ready. For each source, record which part of the workflow needs it, who may access it, how it changes, and how the implementation will identify the right version.
The download below is a working inventory. Complete it with the people responsible for the data and the systems involved. Record unresolved permissions as dependencies; possession of an export does not establish permission to send it to a different service.
- Authority: which system or document wins when two sources disagree?
- Identity: can the input be matched to the correct customer, order, or case without guessing?
- Access: which users and services may see each record, including retrieved results and logs?
- Freshness: how will changes and withdrawn documents reach the workflow?
- Quality: what is missing, duplicated, unreadable, or inconsistently labeled?
- Handling: where may copies be stored, who approves retention, and how are corrections or deletions applied?
Collect the awkward cases as well as the easy ones
Choose cases across the sources, formats, teams, and exceptions the first release will encounter. Add examples where the correct behavior is to stop or ask a person. Label the expected business outcome and the reason, rather than assuming the historical action was correct.
AWS’s Machine Learning Lens recommends validation with data representative of production, including typical patterns and edge cases. It warns that synthetic or unrepresentative validation can hide problems that appear after deployment. Synthetic cases can supplement a collection; they do not establish that real operating conditions have been covered.
There is no universal document count that makes a workflow ready. Build a coverage list first, identify missing categories, and reserve cases that are not repeatedly used to tune the implementation. If reviewers disagree about an expected outcome, resolve the policy or label it for escalation before using it to judge the system.
Illustrative example: preparing invoices for review
Imagine a fictional finance team that wants an assistant to prepare invoice records for human approval. It needs incoming invoices, supplier identifiers, purchase-order records, and the current approval policy. Payment execution stays outside the proposed scope. This is a design example, not a customer case study.
The evaluation collection includes a clean invoice, an unreadable scan, a duplicate, a supplier-name mismatch, a missing purchase order, and an amount outside the reviewer’s authority. A finance owner records the expected result for each. A readable invoice can still fail the workflow if the supplier cannot be identified reliably.
The first useful data task might therefore be mapping supplier aliases to approved identifiers and defining the unmatched-supplier queue. Collecting thousands more clean PDFs would not resolve that specific blocker. If purchase-order access remains unavailable, narrow the first release to extraction for review and state that matching has not been delivered.
Decide what is ready—and what must wait
A bounded evaluation can start when you have approved examples, access to the necessary reference material, a person who can judge outcomes, and a clear list of missing evidence. That does not by itself authorize a live release. Production also needs working permissions, updates, monitoring, and a way to handle cases outside the tested scope.
Turn each gap into a decision: obtain access, repair identifiers, clarify a rule, narrow the workflow, or stop. Prioritize the data work that changes the feasibility of the chosen use case. Cleaning an entire company’s data estate is a different project.
Take this into the conversation
Find the data gaps before the build.
Use this editable inventory to record sources, permissions, representative cases, and the next decision for each gap.
Download the data inventory (.md)Sources & further reading
Primary documentation for the technical points cited above. The decision frameworks and illustrative examples are PlatformBridge’s editorial guidance.