Assess readiness for a Bedrock pilot

Gather evidence rather than a numerical score

Interview the business owner, data owner and technical operator around one proposed workflow. Ask for examples of current work, its baseline cost or delay, permitted data and the expected decision after the pilot. A broad ambition such as “use AI” is not a pilot objective.

Area	Evidence to request	A gap to resolve
Business	Real requests, baseline and acceptance owner	No agreed definition of a useful result
Data	Approved sources, ownership, versions and permissions	Conflicting or unmaintained documents
Platform	Account, Region, network, model access and identity	No authorized execution environment
Operations	Budget owner, incident path and human fallback	Nobody can handle a failed workflow

Separate blockers from experiments

A missing permission boundary or unapproved processing location blocks use of real sensitive data. Uncertain answer quality is normally a question to test. Record each issue, its owner, evidence needed and consequence for scope. Do not combine them into an unexplained pass/fail score.

If approved real data is unavailable, start with representative synthetic or public material and state what that experiment cannot prove. A successful demonstration on public documents does not establish readiness for confidential records.

Define the pilot's decision and outputs

Choose a narrow task with accessible sources and a named reviewer. Agree a bounded dataset, quality criteria, cost observation and failure cases. Include at least a missing-information request and an unauthorized request.

Deliver a readiness register, proposed architecture, evaluation plan and dependencies. The decision can be to proceed, narrow the task or fix a prerequisite. Set duration from data preparation, access and review availability; do not promise a standard number of weeks.

Official references

Documentation checked: 17 October 2026. The instructions are reference guidance; no cloud API was called for this article.