Who Can Supply the Data for an AWS AI Pilot?
Prepare a source-by-source data handoff record before an AI pilot: permitted purpose, evaluator access, copied fields, retention and the claims a narrowed dataset...
Before transferring data into an AWS AI pilot, identify who may authorize each source for the proposed processing and who will account for its copies. A sponsor's promise to provide examples is not that authorization. Neither is an engineer's ability to export them. The useful starting artifact is a data handoff record with a permitted purpose, named recipients, versioned scope and explicit holds for unresolved sources.
This article helps a pilot sponsor and data owner agree that handoff before collecting model scores. It focuses on whether the proposed test may receive its inputs, not on designing an enterprise data platform or certifying legal rights. The records and counts below are fictional. No dataset was collected, permission authenticated, Bedrock evaluation run or customer outcome observed. Qualified privacy, security, legal and domain owners must resolve the requirements applicable to real material.
Start with the use, not the name of the repository
Write one sentence describing the proposed processing. For example: “Evaluate whether a read-only assistant can draft a source-linked explanation of an internal policy exception, using an approved snapshot and two authorized domain evaluators.” Then list what is excluded: employee case histories, individual decisions, customer records, training, external publication and live operational advice. These exclusions need to survive the actual collection path. A folder named pilot-data does not enforce them.
A source owner may be accountable for document meaning without being authorized to approve every downstream use. An application administrator may grant technical access without deciding the contractual purpose. A privacy reviewer may constrain fields but not know which policy revision is authoritative. Record these decisions separately, even when one person holds several roles. Ask for the organizational evidence each role relies on rather than treating a job title as proof of authority.
The AWS Responsible AI design principles tie risks and release criteria to a narrowly defined use case. For this handoff, that means approving an identifiable use, not “AI use” in general. A later request to fine-tune, retain feedback or expose answers to new users changes the question. It requires affected review before those activities occur.
Trace the fields through evaluation and retention
List the minimum fields the test requires and the stores or people that can receive them. The inventory includes the original source, export, sanitized dataset, prompts, generated outputs, evaluator interface, reports and traces. A field removed from the exported table may still survive in an attachment, quoted passage or saved response. Keep evidence references in the handoff record; do not copy sensitive source content into a widely shared worksheet.
For model evaluation jobs, Bedrock data-management documentation describes a temporary copy in an AWS-owned S3 bucket, deleted after the job finishes, with encryption choices. That documented job-copy handling does not establish disposal of the original export, your evaluation reports or your logs. Customer-managed encryption also has service-role and key-policy requirements. A selection in a form does not authenticate the organization's permission to supply the data.
Configured logging creates another boundary. Bedrock invocation logging is disabled by default and can collect inputs, outputs and metadata for supported runtime calls. Coverage depends on the endpoint and configuration. Record the actual planned path and destination policies before processing; do not assume either that every request is logged or that disabling future logging erases retained copies. This article does not configure those services.
Work an adverse handoff before moving the data
Fictional packet D33 proposes 100 policy-question records: 65 routine records, 20 exception records with employee attachments, and 15 supplier-specific records. The sponsor has promised a representative sample by Friday. The routine source owner supplies a purpose-specific authorization reference. The employee-attachment review is unresolved. The supplier contract has not been reviewed for the proposed evaluator access. All three collections are technically exportable, but only the routine collection has a supplied authorization record for this scenario.
| Collection in fictional D33 | Proposed records | Supplied handoff evidence | Current teaching disposition |
|---|---|---|---|
| Routine policy questions | 65 | Owner, snapshot, permitted purpose and evaluator-access reference | Eligible for an independently checked, routine-only handoff |
| Employee-linked exceptions | 20 | Source known; attachment processing authority unresolved | HOLD transfer of this collection |
| Supplier-specific questions | 15 | Source known; contractual evaluator scope unresolved | HOLD transfer of this collection |
- Routine policy questions
- Proposed records: 65
- Supplied handoff evidence: Owner, snapshot, permitted purpose and evaluator-access reference
- Current teaching disposition: Eligible for an independently checked, routine-only handoff
- Employee-linked exceptions
- Proposed records: 20
- Supplied handoff evidence: Source known; attachment processing authority unresolved
- Current teaching disposition: HOLD transfer of this collection
- Supplier-specific questions
- Proposed records: 15
- Supplied handoff evidence: Source known; contractual evaluator scope unresolved
- Current teaching disposition: HOLD transfer of this collection
The proposed population is 100 records. The supplied routine-only subset is 65/100, or 65 percent of that proposal; 35 remain held. This is inventory arithmetic, not an authorization score or an estimate of the organization's workload. The routine subset cannot establish performance on employee-linked exceptions or supplier-specific questions. A report describing it as the original representative population would change the study's claim without collecting the missing evidence.
Suppose the sponsor offers to remove employee names and proceed with the 20 exceptions. That may reduce exposure, but names are not the only identifying or restricted content. Dates, narrative details and attachments can still matter. The appropriate owner needs to review the transformed version and its remaining purpose before transfer. Do not label it anonymous because one column disappeared. A technical minimization step and an appropriate-use decision are separate evidence.
Choose a narrower test without concealing the lost question
The team has three defensible next actions. It can hold the original test while the two source reviews proceed. It can commission a routine-only experiment with a revised question and explicit exclusions. Or it can construct synthetic exception cases to test specified failure behavior without using the withheld sources. These options answer different questions. Choose the one that can inform an actual decision within the available authority and time.
A synthetic case can test whether a missing authorization field causes a denial or whether contradictory policies cause escalation. It cannot establish how common those conditions are in real work or how actual reviewers behave with sensitive records. Preserve synthetic provenance and keep those outcomes separate from observations on permitted real examples. A realistic-looking case is still constructed evidence. Do not mix it into a prevalence calculation without a defensible design.
The Bedrock evaluation overview describes different computed and human evaluation approaches. Selecting a mode does not solve the handoff problem. Human evaluators may need access to inputs and outputs that an automated check does not. A proposed judge model introduces another processing choice to review. Check the selected model's evaluation support, but retain the separate data-use decisions.
Use one reusable record per source and purpose
Copy these prompts into the controlled record system already used by the organization. One blanket row for “company data” is too broad to establish what entered the pilot. A collection can have multiple rows when purposes or recipient groups differ. Empty fields mean unresolved, not unrestricted. Evidence references should resolve for the authorized reviewers without exposing their contents to everyone receiving the pilot summary.
| Handoff field | What the owner must supply | D33 routine-only example |
|---|---|---|
| Decision supported | The question this source can help answer | Supported explanations of routine policy questions only |
| Source and version | Collection identity, snapshot and authoritative meaning | Routine snapshot R33; fictional alias, not authenticated evidence |
| Authority | Decision owner and reference for this purpose | Routine owner plus supplied purpose reference |
| Fields and exclusions | Minimum input fields, attachments and forbidden material | Policy passage and question; no employee attachments |
| Recipients and processing | Evaluators, service path and allowed downstream use | Two named-role evaluators; selected path still subject to review |
| Copies and retention | Each store, access owner, retention and disposal evidence | Export, job copy, report and trace reviewed separately |
| Coverage and held claims | Missing sources and conclusions not supported | Exceptions and supplier-specific performance remain unknown |
| Expiry and next action | Invalidating change, hold owner and next review | New purpose or evaluator group reopens affected review |
- Decision supported
- What the owner must supply: The question this source can help answer
- D33 routine-only example: Supported explanations of routine policy questions only
- Source and version
- What the owner must supply: Collection identity, snapshot and authoritative meaning
- D33 routine-only example: Routine snapshot R33; fictional alias, not authenticated evidence
- Authority
- What the owner must supply: Decision owner and reference for this purpose
- D33 routine-only example: Routine owner plus supplied purpose reference
- Fields and exclusions
- What the owner must supply: Minimum input fields, attachments and forbidden material
- D33 routine-only example: Policy passage and question; no employee attachments
- Recipients and processing
- What the owner must supply: Evaluators, service path and allowed downstream use
- D33 routine-only example: Two named-role evaluators; selected path still subject to review
- Copies and retention
- What the owner must supply: Each store, access owner, retention and disposal evidence
- D33 routine-only example: Export, job copy, report and trace reviewed separately
- Coverage and held claims
- What the owner must supply: Missing sources and conclusions not supported
- D33 routine-only example: Exceptions and supplier-specific performance remain unknown
- Expiry and next action
- What the owner must supply: Invalidating change, hold owner and next review
- D33 routine-only example: New purpose or evaluator group reopens affected review
Require the receiving evaluation owner to acknowledge the accepted version and exclusions. Otherwise the source owner can approve one packet while an engineer uploads a later export with additional columns. Bind the handoff to a controlled snapshot identity and record changes. A checksum can detect byte changes, but cannot establish legal permission, semantic correctness or whether an omitted source makes the sample unrepresentative.
Stop on changed purpose or unaccounted copies
Hold further transfer when a source lacks the required authority, the exported version differs from the reviewed one, a new recipient appears, or the processing path introduces an unreviewed copy. If transfer has already occurred, stop new use and ask the responsible owners to inventory recipients, outputs and retained material. Follow the applicable incident and disposition process. Do not promise that deleting one local file removes every service, report or backup copy.
Changes can preserve some evidence while invalidating other parts. Adding approved routine questions may extend a compatible collection process; adding employee attachments changes the reviewed boundary. A new judge model can change processing even when the questions are unchanged. Keep both the old and revised handoff records so the evaluation report identifies which version it used. An after-the-fact note should not silently convert an unresolved transfer into an authorized one.
For corpus quality, permission propagation and retrieval tests, use the data-readiness checklist. For selecting an experiment that can change an investment choice, use the AI pilot decision paper. The next action here is smaller: ask the sponsor and source owner to complete one proposed source-purpose row, identify its actual recipients and choose a permitted test or an owned hold before any data leaves the source boundary.
Related resources
Which AI Pilot Is Worth Running? Decision Value, Exposure and Adoption
Compare no pilot, shadow replay, human assistance and limited live use using decision-reversal evidence, separate review capacity and honest adoption denominators.
Data Readiness for Generative AI: An Evidence Checklist
Assess whether an information corpus is safe and useful enough for a generative AI system across rights, access, quality, retrieval, freshness, deletion and evaluation.
Related services
AI Data Readiness Assessment Services
Data readiness assessment for generative AI and RAG. Examine quality, access, provenance and coverage before choosing ingestion and retrieval approaches.
AI Readiness Assessment Services
AI readiness assessment covering workflow needs, feasibility and operating constraints. Identify the evidence, team capability and controls needed for adoption.