2.5 AI Use-Case Fit and No-AI Decisions

Start With the Decision, Not the Model

A good AI use case starts with a business decision or workflow that can improve. The decision may be too slow, too inconsistent, too expensive, or too large for manual handling alone. Examples include classifying support tickets, detecting unusual transactions, recommending products, summarizing long documents, forecasting demand, translating content, transcribing calls, and helping employees find policy answers.

A weak AI use case starts with a vague request to add AI without a defined action. If no one can say what will change after the model produces output, the project is not ready. A dashboard, search improvement, training update, workflow rule, or process redesign may solve the real problem with less risk. Practitioners should be comfortable recommending no AI when the facts point there.

No-AI is not a failure. It is often the most professional recommendation. Use deterministic logic when the rule is known, testable, and must always produce the same outcome. Use traditional reporting when leaders need visibility rather than prediction. Use workflow automation when the process is repeatable. Use human review when context, ethics, legal judgment, or customer impact makes automation too risky.

Cost-benefit analysis should include more than service pricing. AI projects require data preparation, security review, monitoring, user training, exception handling, and maintenance. A model that saves minutes for a small team may not justify the operational burden. A model that changes a high-volume workflow may be worth investment if errors are manageable and the business can measure improvement.

Risk changes the acceptable level of automation. A retail recommendation that is occasionally irrelevant may be tolerable. A medical, financial, legal, hiring, or safety-related recommendation may require strict review, explainability, auditability, and human approval. Services such as Amazon A2I, Guardrails for Amazon Bedrock, CloudWatch, CloudTrail, IAM, KMS, and policy controls can support governance, but they do not remove the need for accountability.

Fit also depends on data. A fraud model needs enough examples of fraud and legitimate behavior to learn meaningful differences. A recommendation system needs interaction history. A chatbot over enterprise knowledge needs current, approved documents. A vision inspection model needs representative images. If data is sparse, biased, inaccessible, or legally restricted, the correct near-term answer may be data work before AI.

A service-first shortcut can lead to overbuilding. Amazon Bedrock is powerful for generative AI, but it is not the answer for every prediction. Amazon SageMaker AI supports custom ML, but it may be unnecessary when a managed AI service directly solves the task. Amazon Q can help employees interact with enterprise information, but a simple curated knowledge base may be enough for stable policies and exact answers.

Use this approval checklist:

• The business action changed by the AI output is written down.
• The baseline process and success metric are known.
• The required data is available, permitted, and representative.
• The team compared managed AI, GenAI, custom ML, analytics, automation, and no-AI options.
• Failure modes, human review, escalation, and fallback behavior are defined.
• Owners are named for cost, security, model quality, user feedback, and retirement.

Scenario: a service desk wants to reduce time spent reading long internal articles. If agents need fast summaries and answers from approved knowledge, Amazon Q or a Bedrock retrieval workflow may fit. If the article set is small and stable, better tagging and search might be enough. If generated answers could misstate refund policy, the workflow should show sources and route uncertain cases to human review.

Scenario: an operations team wants to block all shipments to a sanctioned country list. This should be a deterministic control using approved reference data. AI would add uncertainty to a requirement that needs exact enforcement. AI might later help detect suspicious address variations, but the core policy block should remain a rules-based compliance control.

Scenario: a sales group wants lead scoring. This may fit supervised learning if historical leads include outcomes such as converted or not converted, the sales process is stable, and the score changes follow-up behavior. It may be a poor fit if the CRM data is incomplete, outcomes are inconsistently recorded, or the team cannot agree on how to use the score. A reporting cleanup might come first.