Task 2.1: Develop AI strategies that align with business objectives.

• AFund the ideas with the most senior sponsors

  Incorrect

  Sponsorship matters for adoption, but seniority alone says nothing about whether an idea is feasible or valuable. Ranking by title skips the evidence the committee wants.

• BFund the ideas that use the newest model capabilities, to build the most advanced skills

  Incorrect

  Picking by technical novelty optimizes for experimentation, not for business value or feasibility, and can leave the bank with impressive demos that solve low-priority problems.

• CA use case matrix scoring feasibility, business impact and strategic fit

  Correct

  AWS's generative AI maturity guidance recommends a use case matrix that prioritizes projects by feasibility, business impact and alignment with strategic goals, then a short list of the top use cases for proofs of concept.

• DFund an even share of ideas from every business unit, so that adoption is balanced

  Incorrect

  Spreading money evenly feels fair, but it ignores differences in value and feasibility between ideas. Balance can be a secondary criterion, not the basis for selection.

A small number of proofs of concept should go to the ideas with the best combination of value, feasibility and fit with strategy. A use case matrix makes that trade-off explicit and repeatable, and gives the committee a defensible short list instead of a popularity contest.

• ABuild a custom assistant on Amazon Bedrock with a knowledge base and an internal user interface

  Incorrect

  Bedrock is the right platform when a team builds its own generative AI application. Here there is no engineering staff to build and run one, and the timeline is two months.

• BSubscribe to Amazon Quick, a managed AI assistant priced per user

  Correct

  Amazon Quick is fully managed, needs no infrastructure or ML expertise, connects to organizational documents and data, and is sold as per-user subscription plans, which matches every stated constraint.

• CTrain a proprietary model on Amazon SageMaker AI

  Incorrect

  SageMaker AI suits teams that need to train and customize models with full control. A trained model does not deliver an assistant to employees on its own, and the firm has no engineering staff to build one around it.

• DCommission a data science team to fine-tune an open model and host it on dedicated instances

  Incorrect

  Fine-tuning and self-hosting add hiring, training and always-on instance costs. The firm wants a ready service with a predictable per-user price.

The build-buy-partner decision follows the constraints: no technical staff, a short timeline and a wish for per-user pricing all point to buying a managed, seat-based product. Building on Bedrock or SageMaker AI makes sense when the organization can staff the build and needs control that a packaged product does not give.

• AAmazon SageMaker AI

  Incorrect

  SageMaker AI is designed for building, training and deploying models with maximum control. It fits teams whose customization needs go beyond prompting and retrieval; a common path is to start on Bedrock and move there as those needs grow.

• BAmazon Quick

  Incorrect

  Quick is a ready-made AI assistant for employees. It is not a platform for building a customer-facing assistant into the company's own product.

• CAWS Marketplace

  Incorrect

  AWS Marketplace is a catalog for finding and buying third-party software, data and services. It is a procurement channel, not the platform the developers would build on.

• DAmazon Bedrock

  Correct

  AWS's decision guide recommends Bedrock for building applications with pre-trained models, prompt engineering and RAG without deep ML expertise, on a fully managed, serverless platform.

Bedrock and SageMaker AI serve different needs: Bedrock gives developers managed access to foundation models plus capabilities such as knowledge bases, with no infrastructure to run; SageMaker AI gives ML practitioners full control to train, customize and deploy models. Start with the least customization that meets the need.

• AReframe the use case or choose a non-AI approach for now

  Correct

  AWS guidance asks whether reliable training, fine-tuning and test examples exist. If they do not, the organization may lack the data to develop or evaluate an AI system and should reframe the use case or consider alternate solutions.

• BApprove the model and let it learn from its own mistakes during the events

  Incorrect

  Deploying a model that cannot be tested before launch exposes riders to unmeasured errors, and learning from live mistakes is no substitute for having data to evaluate against first.

• CApprove the model but require the vendor to use the largest available foundation model

  Incorrect

  A larger model does not create ridership data that does not exist. Model size cannot replace the examples needed to build and evaluate a prediction.

• DDelay until the agency hires its own data scientists

  Incorrect

  In-house skills do not solve the missing-data problem either. The issue is the absence of reliable examples, not who would build the model.

AI is not the right answer when the data needed to build and judge it does not exist. Before committing, check that reliable examples are available; if they are not, reframe the use case into one that data can support, or solve it with planning rules, expert judgment or another non-AI approach.

• APivot the approach or end the proof of concept, as the exit criteria require

  Correct

  Exit criteria exist so that a proof of concept that misses its quality, latency or cost thresholds is pivoted or ended, preventing wasted effort and sunk costs.

• BExtend the proof of concept by another quarter, because quality is close to target

  Incorrect

  Extending without a credible path to the cost threshold is the sunk-cost pattern exit criteria are meant to stop. Being close on one criterion does not offset failing another by a factor of three.

• CLaunch to all customers and optimize cost later, because the assistant already works

  Incorrect

  Launching at three times the cost limit scales an unprofitable unit economics problem. Cost per request determines financial viability at scale.

• DReplace the exit criteria with softer targets that the current results meet

  Incorrect

  Moving the goalposts after the fact removes the evidence the steering group needs and turns the proof of concept into a demo.

A proof of concept is an experiment that should end in a clear decision. Setting thresholds for quality, latency and cost up front, and acting on them when results miss, keeps the portfolio honest and stops sunk costs from growing.

• AKeep using it; AWS migrates Legacy workloads automatically

  Incorrect

  Bedrock does not migrate workloads automatically. After end of life the model is removed from all Regions and requests to it fail.

• BPurchase new Provisioned Throughput for the model to keep it available after end of life

  Incorrect

  New Provisioned Throughput cannot be created for a model in the Legacy state, and it would not keep a model available after end of life.

• CPlan, test and complete a migration to an Active model before the end-of-life date

  Correct

  A Legacy model is scheduled for retirement; after its end-of-life date requests to it fail and migration does not happen automatically. AWS recommends moving to an Active model before that date.

• DWait until the last month, because Legacy models keep working for every customer until the date

  Incorrect

  During the Legacy period, existing customers may lose access after 15 days of inactivity, and a rushed migration leaves no time for testing.

Moving between models is a business continuity event. The Legacy notice period exists so that the switch can be planned, tested and completed before the end-of-life date removes the old model.

• ASelect the foundation model the project will be built on, based on benchmarks

  Incorrect

  Model selection depends on the problem the system must solve. Picking a model before the problem is defined puts the solution ahead of the need.

• BSign an enterprise agreement with an AI vendor to lock in pricing

  Incorrect

  Committing to a vendor before the problem and its value are understood risks paying for a capability that does not fit.

• CMeasure how often each complaint type occurs and what it costs

  Correct

  Clarifying the business problem means describing it and assessing its frequency, location and concrete impacts, using quantitative and qualitative data.

• DValidate a written problem statement with key stakeholders

  Correct

  AWS suggests drafting a structured problem statement and validating it with key stakeholders, refining it based on their feedback.

• EHire a team of prompt engineers to start building prototypes

  Incorrect

  Building prototypes is useful once the problem is clear. Starting with builders before defining the problem risks a demo that does not address the real need.

The narrower and better quantified the problem, the more precisely risks and value can be assessed. Data on how often the problem occurs and what it costs, plus a validated problem statement, should come before any choice of model, vendor or team.

• AA detailed final report from each team, in the team's own format

  Incorrect

  More detail in five different formats still cannot be compared; AWS recommends a value assessment scorecard for each proof of concept, with success metrics and an ROI measure.

• BOne user-satisfaction survey run across all five proofs of concept

  Incorrect

  A single satisfaction measure leaves out feasibility and cost; AWS guidance is to measure each proof of concept's ROI and check it against its success criteria.

• CA value assessment scorecard used for every proof of concept

  Correct

  AWS's maturity guidance recommends creating value assessment scorecards for each proof of concept, together with success metrics and ROI measures.

• DFunding all five into production and comparing them after a year

  Incorrect

  The budget covers two, and AWS guidance is to measure each proof of concept's ROI and success before deciding what advances, not after a year in production.

Prioritizing AI initiatives requires comparable evidence. A common scorecard makes value, feasibility and cost visible in the same terms across projects, so the steering group can decide which to continue, pause or stop.

• AConduct detailed threat modeling of the vendor's model internals

  Incorrect

  Detailed threat modeling of the application is emphasized for Scopes 3 to 5, where the organization builds and controls more of the solution.

• BRetrain the vendor's model on the firm's documents before use

  Incorrect

  A bought application is used as provided; retraining its model is a builder's activity outside the buyer's control.

• CReview the vendor's enterprise agreement and data terms carefully

  Correct

  For Scope 1 or Scope 2 off-the-shelf solutions, AWS advises a buyer's perspective focused on risk management through data governance and a careful review of enterprise agreements.

• DDefine which firm data is authorized for sharing, and when

  Correct

  AWS stresses clearly understanding which data is authorized for sharing and under what circumstances when using off-the-shelf AI.

• ESkip governance review, because the vendor is responsible for everything

  Incorrect

  Buyers still govern what data they send and on what terms.

Build-buy-partner choices change where risk is managed. When buying, governance focuses on contracts and data sharing; when building, the organization takes on threat modeling and more of the controls.

• AIgnore regulation, because both features use similar technology

  Incorrect

  Risk-based rules depend on the use, not the technology, so the two features face different requirements.

• BTreat both as equally regulated, because they serve the same customers

  Incorrect

  The same customers do not make the uses equally risky in a risk-based regime.

• CWeigh the higher bar for ranking people in feasibility and timing

  Correct

  AWS notes that risk-based regulations such as the EU AI Act set a higher bar for high-risk applications, including those affecting human rights, which can include human-in-the-loop requirements or even prohibition.

• DChoose the ranking feature first, because high-risk uses bring higher value

  Incorrect

  The values are similar; the higher regulatory bar adds effort and time that prioritization must account for.

Feasibility includes regulatory feasibility. Under risk-based AI rules, uses that affect people's rights carry heavier obligations, which changes cost, timeline and design and therefore priority.

• ABuild the models in-house on Amazon SageMaker AI

  Correct

  SageMaker AI is a fully managed service for building, training and deploying ML models, which AWS positions for use cases that need extensive training and customization and control over the full ML lifecycle, a fit for a skilled team building a capability it wants to own.

• BBuy a third-party agronomy AI application and configure it

  Incorrect

  No product works with the trial data, and a bought application is used as the vendor provides it: at the consumer and enterprise app scopes the buyer does not control how the model is trained.

• CContract a consulting partner to build and run the models

  Incorrect

  A partner adds skills an organization lacks, but this company already has the expertise, and an outside firm building and running the models keeps the know-how outside the company.

• DPrompt a pretrained foundation model on Amazon Bedrock

  Incorrect

  Bedrock suits building generative AI applications on existing foundation models; yield prediction from the company's own trial data needs custom-trained models with control over training, which is what SageMaker AI is for.

Build, buy and partner decisions turn on how strategic the capability is and which skills are in house. When the capability is core, no product fits and a skilled team must keep control and know-how, building on a managed ML platform fits; buying suits common needs, and partnering fills missing skills.

• AUse the real files now and request approval in parallel

  Incorrect

  AWS's proof of concept guidance requires explicit approval before real personal data is ingested into any system and names skipping this step as one of the most common pitfalls.

• BStop the initiative and fund the next-ranked one instead

  Incorrect

  The use case keeps its value; a pending approval calls for pausing the step that needs the data, not for terminating the top-ranked initiative.

• CCopy the files to an analyst's laptop to keep them off shared systems

  Incorrect

  AWS notes that once data reaches a local workstation, controlling access to it becomes almost impossible, so this adds risk without the approval.

• DHold the real files until security and legal approve them

  Correct

  AWS's proof of concept guidance requires explicit approval from information security and legal before real data containing personal information is ingested; work that does not need it, using synthetic or anonymized data, can continue.

Prioritizing initiatives includes deciding what to pause and what to stop. Pausing only the step that waits on approval keeps the top initiative moving toward its deadline without creating compliance exposure.