Having files does not establish that a team can use them in an AI pilot. Before requesting a build estimate, identify the authoritative source for each kind of information, its owner, permitted purpose, eligible viewers, and how it will enter and be updated in the pilot. An unresolved essential source or permission should remain an explicit dependency, not disappear inside a confident estimate.
This is a data-and-access feasibility assessment for a specific task. It is not model training or permission to expose the organization’s entire information estate. A narrow experiment may be feasible with a small approved collection while live integration and customer records remain excluded.
Start with the question the system will answer
“Customer-service assistant” is broad. A more useful scope is: help staff find an approved returns policy and draft an answer they review before sending. Define exclusions too: no exception decisions, order changes, direct customer sending or searching private tickets without a separately approved scope.
AI Readiness Assessment connects that task with data, constraints and oversight. NIST offers a voluntary AI risk-management framework, not certification that a particular project is ready. NIST framework reference. The practical decision still depends on your sources, controls and verification evidence.
Trace information from source to reviewer
For each source, identify who approves its correctness, who authorizes its use, where the current version is maintained and what makes it obsolete. System ownership and content authority may differ. An administrator’s access does not authorize them to resolve contradictory commercial policies.
Map the information path: source, reading or export method, processing destination, storage or logs, and the person viewing the result. Do not assume a provider’s retention or data-use settings. Responsible specialists must verify the actual service, configuration and agreements before data transfer.
Product Discovery & Requirements can establish these roles and boundaries. They are not details to postpone until after model selection: they may change what the solution can do or exclude a proposed capability entirely.
Worked hypothetical example: support-answer drafting
All counts are instructional, not client results. A team has a folder of 120 files it believes is suitable for a pilot. Inventory identifies 70 currently approved files, 25 superseded versions, 15 duplicates and 10 files without a confirmed approval owner. The total is 120. Having 70 approved files does not establish that all intended questions are covered.
| Source | Inventory decision | Requirement before use |
|---|---|---|
| Current policies | Candidates for the limited pilot | Use approval and definition of covered categories and questions |
| Superseded versions | Excluded from answer sources | Owner-directed reference retention without mixing them into current content |
| Duplicates | Require reconciliation | Select the authoritative copy rather than count copies as new knowledge |
| Files without clear ownership | Pending | Assign an approver and approve or exclude the content |
| Customer tickets | Access not authorized for this pilot | Separate scope and review before extraction |
The team proposes evaluating general policy questions with staff review, without tickets or automatic sending. The content owner checks that each test question has an appropriate source or an expected “information unavailable” outcome. If returns policy varies by product type, the test data must preserve that condition rather than conceal it because most files concern other products.
Include a question the system should not answer, such as an undocumented commercial exception. In this example, the expected response is referral to the responsible person, not a plausible invented answer. This tests the boundary of the approved collection; it does not establish the system’s overall security or the quality of every possible answer.
The estimate can now distinguish content preparation from software work. Resolving the ten unowned files is an organizational dependency. Excluding them may permit a narrower pilot, but only if their absence does not invalidate the task being evaluated.
Verify actual access, not merely account availability
If the solution must read from an existing system, establish the actual supported interface, required fields, connection identity and provider constraints. Naming a system or holding an administrator account does not demonstrate that the proposed integration is suitable. API Integration & Development can specify the data contract, permissions and failure handling within an approved scope.
Request verification cases for required reads, prohibited reads, revoked access and an unavailable source. Agree expected results with security and data owners. Do not test with real records or personal accounts without authorization. If these checks have not been executed, describe them as verification requirements rather than proven controls.
Also distinguish a one-time approved export from a maintained connection. The former may suit an isolated experiment, but it does not demonstrate update reliability. The assessment should state which approach is being estimated and who maintains its inputs.
Separate estimable cleanup from a blocking dependency
Renaming known files can be a bounded task. Missing permission or uncertainty about the authoritative policy is not minor cleanup that developers should bypass. Give each gap an owner, required action and closure evidence, then state whether it permits a narrower experiment, needs remediation first or blocks the current task.
Once the foundations are verified, AI & Machine Learning Engineering can be scoped around approach comparison, output quality, failure cases and human review. A readiness assessment does not automatically include custom training, comprehensive integration or unrestricted autonomy.
Data-assessment acceptance checks:
- Every approved source has an owner, version and permitted purpose.
- Rejected and pending material remains visible in the inventory.
- Test questions relate to content coverage, not file count alone.
- Transfer, processing and storage arrangements receive the required review.
- Demonstrated access is distinct from assumed or pending access.
- The next decision defines the data, users and excluded actions.
The final recommendation should be specific enough for another team to understand what it may estimate. “Data ready” without a task, version or permission boundary is too broad to serve that purpose.
Frequently asked questions
Do we need a large dataset?
That depends on the task and implementation approach. In this example, correct coverage of the questions matters more than collecting more files. Do not infer training requirements from a staff-assistance use case.
Can we start with test data?
A bounded behaviour study may be possible with suitable, permitted data. Its success does not establish live-access feasibility or operational-data quality. Keep those checks separate.
Who decides whether the content is correct?
The domain owner or authorized approver, with required specialist review. The implementation team should not independently choose between conflicting policies.
Does the assessment guarantee compliance or security?
No. It documents scope, evidence and gaps and may require privacy, security and local-obligation review by qualified specialists. It is not a certificate.
When requesting an assessment, provide one task description and a source inventory rather than sending sensitive files before an approved sharing method is agreed.
Source
- NIST: AI Risk Management Framework. A voluntary reference; the example and matrix are original planning aids, not certification.
