Chapter 1. Evaluating AI Applicability

Learning objectives

• Choose the right solution for each task among rules/lookups, search, classification models, generative models, workflows, and agents, and explain the reasoning.
• Distinguish between problems where AI is better and those where it is not, and filter out demands that do not require AI during early planning.
• Evaluate data conditions (records, expected outputs, representativeness, feasibility of external transmission) and cost conditions (development, evaluation, and operational costs versus benefits) to decide whether to proceed.
• Assess how high-impact areas and generative AI obligations under the AI Basic Act, along with automated decision provisions under the Personal Information Protection Act (PIPA), affect planning.
• Record the rationale for decisions in a one-page AI applicability evaluation memo.

Introduction

Suppose a conversation like this takes place in a meeting room: "A competitor added AI consultations. Let's add one this quarter too." "Where?" "Well, on the inquiry side for now." In this conversation, the question is inverted. The solution (AI) was decided first, and the problem is being sought afterward. Features that start this way usually end in one of two ways: making something that could be handled with a few lines of rules expensive and unstable, or being unable to even touch areas where AI is genuinely needed because there is no data.

Evaluating AI applicability is not about asking "how should we use AI?", but asking "does this problem need AI, and if so, what is the simplest form?" In its agent design guidelines, Anthropic states that one should find the simplest possible solution and increase complexity only when necessary, which might mean not building an agent system at all. A planner's first job is to preserve this sense of simplicity.

This chapter first sets up a ladder of solutions and examines when each rung of the ladder is appropriate. Next, it categorizes problems AI excels at and those it does not using classifications from the Google PAIR Guide, adding the real-world conditions of data and cost. Finally, it addresses where the law intersects with planning—specifically, high-impact areas and automated decisions—and covers how to record all of these evaluations in a one-page memo.

Key concepts

What is evaluating AI applicability?

Evaluating AI applicability is the task of determining three things for a single work task. First, is automation or augmentation needed? Second, if needed, what solution achieves the objective in the simplest way? Third, are the conditions (data, cost, legal requirements) in place to build that solution right now? If the answer to any of the three is "no," the AI feature is not initiated or its form is changed.

By analogy, evaluating AI applicability is like the order of care at a hospital. A doctor does not recommend surgery the moment they hear the symptoms. They first identify the cause, check if medication works, and choose heavier treatments only when that still fails. AI is the same. Using a generative model for something that can be handled by rules is like recommending surgery for a common cold.

The ladder of solutions

Solutions for AI features can be set up as a ladder from lightweight to heavy. Moving upward broadens what can be done, but variability of results, costs, and things that must be verified increase alongside it.

Anthropic distinguishes workflows as systems orchestrated through predetermined code paths with LLMs and tools, and agents as systems where LLMs dynamically direct their own processes and tool usage. They explain that agents should be used for open-ended problems where the number of steps is difficult or impossible to predict, and that one must accept increased costs and potential error accumulation in exchange for autonomy. Therefore, they recommend extensive testing in sandboxes and appropriate guardrails.

When rules and lookups win

For tasks where results are completely determined by inputs and rules, rules and lookups are the most accurate, cheapest, and fastest. Shipping fee calculations, membership tier discounts, remaining point lookups, and deadline calculations are examples of this. Even if a user asks in natural language, the conclusion does not change. If question expressions fall into several predetermined patterns, one only needs a lightweight intent classification, while simply displaying the exact value from the system as the answer.

A common misconception here is that "since the question is in natural language, the answer must also be generated by a model." The moment a model transcribes numbers into sentences, the risk of misrepresenting the numbers arises. Adding a generative step to a task where the correct answer already exists in the system yields nothing while only increasing what must be verified. The Google PAIR Guide also lists tasks requiring predictable outcomes as a category where AI is unlikely to be better.

When search wins

When the objective is fully met by finding and displaying the original text from designated documents, search is the right choice. In particular, for tasks where users must read and judge the original text directly and where paraphrased sentences are not accepted as evidence (such as legal affairs, audits, and final confirmations of regulatory interpretations), a generative step adds no value. Instead, it only creates the risk that a summary subtly diverges from the source text.

Conversely, if content scattered across multiple documents must be synthesized and explained plainly, search alone is insufficient. In this case, an architecture that finds supporting passages through search and grounds generation in those passages (retrieval-augmented generation) is used. Claude documentation explains that when handling long documents, extracting direct quotations first as grounding and verifying each claim against those quotations can reduce fabricated answers.

Problems requiring models

The Google PAIR Guide lists eight types of tasks where AI is likely to be better. The four most commonly encountered in planning are recommending different content to different users, predicting future events, understanding natural language, and detecting rare events that change over time. The remaining four are improving experiences through personalization, recognizing an entire category of objects, domain-specific agent and bot experiences, and tasks where dynamic content is more efficient than predictable interfaces. What they have in common is that all cases cannot be written out in advance with rules. Categorizing free-form inquiries into types, predicting a customer's next purchase timing, and catching fraudulent transactions with constantly evolving tactics belong in this category.

Insisting strictly on rules for these tasks causes rules to multiply endlessly, falling behind whenever new cases emerge. Even so, models do not guarantee correct answers. Determining that a problem requires a model means that "rules will not work," not that "a model will solve it." Therefore, one must evaluate the conditions of the next rungs: data and evaluation.

Once the conclusion is reached that a model is needed, one must also determine whether to stand on rung 3 (classification and prediction models) or rung 4 (generative models) of the ladder.

Even for tasks that divide inputs into predetermined categories, if labeled records are scarce or expressions are diverse, assigning classification to a generative model allows for a faster start. In either case, verifying whether standards are met using an evaluation set remains the same.

Problems where AI is not appropriate

The same guide also lists six types of tasks where AI is unlikely to be better: maintaining predictability, providing static or bounded information, minimizing costly errors, needing complete transparency, cases where building quickly and cheaply is most critical, and automating tasks that people value and want to do themselves.

Among these, costly errors and complete transparency are particularly easy for planners to overlook. For judgments where the cost of a single error is very high and irreversible (for example, judging physical safety from a single photograph), deciding not to delegate the task to AI can be the right choice even if accuracy is high. The same applies to tasks where the process leading to an outcome must be demonstrated at every step without omission (such as decisions scrutinized line by line in audits or appeals, including the basis of tax calculations or the sequence in which regulations were applied). Models that generate answers probabilistically struggle to fully reproduce and demonstrate the reasoning process the way rules do. Therefore, such tasks are built with rules, while AI is kept in an auxiliary role to assist with explanations. The NIST AI RMF includes determining whether a system achieves its intended purpose and whether to proceed with development or deployment as part of risk management. "Do not build" is also a legitimate planning conclusion.

Automation and augmentation

AI features can be divided into automation, which replaces human work, and augmentation, which assists human work. The PAIR Guide explains that automation is preferred when completely eliminating tasks that people want to avoid, while people want to retain—or must retain—control when the stakes in their roles are high.

Planners separate the two using two questions: Does the user want to do this work themselves, and who bears responsibility for the outcome? Automation is suitable for repetitive, tedious tasks where errors can be easily corrected, whereas augmentation is appropriate for tasks where judgment carries accountability and users must understand the outcome. For irreversible outcomes, such as customer responses that promise financial compensation, an augmentation model where AI drafts the response and a human approves it is a common solution.

Criteria for choosing between workflows and agents

Even after concluding that an LLM is necessary, there are various architectures: whether it finishes with a single call, follows predetermined steps sequentially (prompt chaining), classifies inputs to route to different processing paths (routing), alternates between generation and evaluation (evaluator-optimizer), or must determine its own steps dynamically (agent).

Anthropic describes routing as a pattern that classifies an input and directs it to specialized downstream tasks, noting that it is well-suited when classification can be handled accurately by an LLM or traditional classification models. They recommend using the evaluator-optimizer pattern when clear evaluation criteria exist and iterative refinement delivers measurable value.

Data conditions

Even if a problem requires a model, it cannot be built without data, and even if built, it cannot be verified. There are four data conditions planners must verify:

1. Do records exist? Are the events to be predicted recorded in the system? If orders are exchanged only via personal messenger apps and dates are not recorded, predicting purchase timing cannot begin.
2. Are there expected outputs? Are there ground-truth labels or records of human judgments showing what the correct answer is? Without them, an evaluation set cannot be constructed.
3. Is there representativeness? Does the available data represent actual users and inputs? The PAIR Guide emphasizes that data must reflect the diversity and context of the people who will actually use the system.
4. Is it permissible to use? Can that data be transmitted to an external model provider? If personal information or contractual confidential data is included, verify the provider's data handling terms (retention period, whether it is used for training, etc.) in contractual documents, and mask it before transmission if necessary.

If records do not exist, begin by establishing operational workflows that capture data; if records exist but expected outputs are missing, begin by labeling samples with expected outputs.

Cost conditions

The cost of an AI feature is not limited to model invocation fees. It includes development, evaluation set construction, security and legal reviews, operational monitoring, personnel for handling failures, and responding to model migrations. Benefits are typically measured as "time saved × unit labor cost" or "increased revenue."

Start with a simple calculation. Even if a task occurring 500 times a year at 4 minutes per case is fully automated, the time saved is only about 33 hours per year. Conversely, if a task occurring 5,000 times a day at 2 minutes per case is only half-automated, it saves about 83 hours per day. For tasks with low throughput, it is difficult to recoup costs no matter how well the system is built.

Invocation costs themselves can also be reduced through design. According to Claude documentation, bulk tasks that do not require immediate responses can be processed asynchronously using the Message Batches API, which mostly completes within one hour and reduces costs by 50%. However, because batches expire if not processed within 24 hours, buffer time should be allowed for time-sensitive tasks. Asking whether real-time processing is truly necessary is the first question in cost evaluation.

Applicability to high-impact areas

The AI Basic Act defines high-impact artificial intelligence as artificial intelligence systems used in designated areas that have a significant impact on, or pose a potential risk to, human life, physical safety, and fundamental rights (Article 2, Subparagraph 4). The areas planners should memorize are as follows:

When providing products or services, artificial intelligence business entities must review in advance whether the artificial intelligence constitutes high-impact AI, and may request confirmation from the Minister of Science and ICT if necessary (Article 33). Requesting confirmation is a discretionary procedure ("may request"). If it constitutes high-impact AI, the entity must implement risk management measures, explanation measures within technically feasible limits, user protection measures, human supervision and oversight, and the preparation and retention of documentation to verify such measures (Article 34, Paragraph 1). There is also a provision on high-impact artificial intelligence impact assessments stating that entities should endeavor to evaluate impacts on human fundamental rights in advance (Article 35, Paragraph 1).

Even if an AI is not high-impact, there are points where the law intervenes. To provide products or services using high-impact or generative artificial intelligence, that fact must be notified to users in advance (Article 31, Paragraph 1); outputs generated by generative artificial intelligence must be labeled with the fact that they were produced by generative artificial intelligence (Article 31, Paragraph 2); and synthetic sound, images, or video that are difficult to distinguish from reality must be notified or labeled so that users can clearly perceive them (Article 31, Paragraph 3).

Automated decisions and the Personal Information Protection Act (PIPA)

Separate from the AI Basic Act, Article 37-2 of the Personal Information Protection Act (PIPA) governs decisions made by processing personal information through fully automated systems (automated decisions). Automated administrative dispositions by administrative agencies pursuant to Article 20 of the General Act on Public Administration are excluded from automated decisions under this Article. Because the statutory text states "including systems applying artificial intelligence technology," it can also apply to automated decisions made by non-AI rule engines.

If a decision has a significant impact on their rights or obligations, the data subject has the right to refuse the decision; however, this right of refusal is restricted if the decision is based on consent, statutory provisions, contract performance, or similar grounds (Paragraph 1). On the other hand, the right to request explanations of the decision (Paragraph 2), the controller's obligation to take measures accordingly (Paragraph 3), and the obligation to disclose the criteria, procedures, and manner in which personal information is processed so that they can be easily checked (Paragraph 4) apply across all automated decisions without requiring the condition of significant impact. The Enforcement Decree allows for simpler explanations for decisions that do not have a significant impact.

The Enforcement Decree specifies these details. Requests for explanation and related actions are divided into explanations regarding the criteria and processing of the decision, and requests by the data subject submitting opinions (such as adding personal information) to review whether those opinions can be reflected in the decision (Enforcement Decree, Article 44-2). In the absence of justifiable grounds, the controller must provide a concise and meaningful explanation detailing the outcome of the decision, types of major personal information used, primary criteria, and processing procedures, or review and notify whether the submitted opinions were reflected. In the case of refusal, the controller must either not apply the decision or reprocess it with human intervention, and measures must in principle be taken within 30 days from the date of receiving the request (Enforcement Decree, Article 44-3). Items subject to disclosure are also stipulated in Article 44-4 of the Enforcement Decree.

The lesson for planners is simple: the belief that "building with rules instead of AI avoids regulation" can be wrong. If a system is designed to make decisions automatically using personal information without substantial human review (excluding automated administrative dispositions by administrative agencies), regardless of the technology, planners must incorporate disclosure of criteria, intake channels for explanation and review requests, and handling procedures for designated personnel. Furthermore, if the decision significantly affects rights, procedures for processing refusal requests must also be included.

Questions to filter out demands that do not require AI

When a candidate AI task is proposed, ask the following five questions in sequence. Questions 1 through 4 determine whether to use AI, and Question 5 determines in what form to use it if chosen. If caught by an earlier question, do not proceed further; record the conclusion reached at that checkpoint directly into the evaluation memo.

The conclusion will be one of these six: Proceed (automation), Proceed (augmentation), Change form (rules/search), Data prerequisites first, Put on hold (maintain current method), or Do not build. Do not discard filtered-out tasks; record them with next actions and an assigned owner.

AI applicability evaluation memo

Evaluations must always be documented in writing. One must be able to explain later "why this feature was built with AI" or "why it was not built at that time," and it also serves as evidence for legal prior reviews. A single page is sufficient.

[AI Applicability Evaluation Memo]
Task: (One sentence)
Current processing method and throughput: (○ cases per month, ○ minutes per case, error rate ○%)
Ladder of solutions: (Selected rung) / Why lower rungs will not work: (One sentence)
Data conditions: Records (Yes/No) · Expected outputs (Yes/No) · Representativeness · Feasibility of external transmission
Cost conditions: Expected benefits vs. development, evaluation, and operational costs
Legal review: Applicability to high-impact areas (Article 2, Subparagraph 4, Item ○ review result), generative AI notice/labeling, applicability to automated decisions
Conclusion: Proceed (automation) / Proceed (augmentation) / Change form (rules/search) / Data prerequisites first / Put on hold (maintain current method) / Do not build
Next actions and owner:

Going deeper

The trap of deciding to "wait until the model gets better"

When putting an AI task on hold, people often say, "Let's look at this again once model performance reaches a level where it can be completely entrusted with this work." This judgment is correct in only two cases: when an error leads to irreversible and major harm that cannot be reduced even with human intervention, and when evaluation with current models falls significantly short of the criteria.

In all other cases, this judgment misses two things. First, work that could be built right now with rules may have been misclassified as an AI problem. Second, even if it is not at a "level to be completely entrusted," combining it with human intervention can deliver value right now. If it is a classification where errors can be reversed, you can start today by escalating only low-confidence cases to humans. When deciding to put a task on hold, write down in numbers what needs to change before revisiting it (evaluation score, cost, data).

Does risk disappear if a human decides?

A structure where a human makes the final decision reduces risk, but does not eliminate it. If someone looks at thousands of cases a day for a few seconds each and simply approves the AI's recommendations as they are, it is automation in substance even if it is a human decision in form. This issue is covered in detail in Chapter 4, but even at the applicability decision stage, two things must be verified: whether the reviewer will have the authority and evidentiary basis to overturn the outcome, and whether the throughput is manageable for review.

Legally, this distinction is also important. Automated decisions under the Personal Information Protection Act (PIPA) target "completely" automated decisions, so the scope of application can differ if substantive human review is present. By contrast, because the definition of high-impact under the AI Basic Act is based on domain and application, the obligation of prior review remains even if a human reviews it. The same "human decision" operates differently across the two laws.

Items easily overlooked in cost comparisons

If you calculate the cost of an AI feature solely from the development fee in an estimate and monthly call fees, you will almost always underestimate it. Items that are easily overlooked are as follows:

Claude documentation states that notice of public model retirements is given at least 60 days in advance, and requests sent to models past their retirement date will fail. Factor into your costs that an AI feature is not an asset that is done once built, but a service that requires continuous care.

At work

Shipping document verification at Seaway Shipping

The operations team at shipping company 'Seaway Shipping' received 400 shipping documents daily and verified whether cargo weight, container numbers, and hazardous material markings matched booking information. The team lead requested, "It would be great if an AI could read the documents and verify everything."

The planner broke down the task. Seventy percent of the documents were electronic documents in a fixed format, and 30% were scanned paper. Because values in electronic documents could be read directly as fields, rule-based comparison was sufficient to cross-check them against booking information. Scanned documents required reading text and locating fields, so a model was necessary.

The initial proposal was: "An agent reads the documents, finds discrepancies, and even sends correction request emails to shipping lines." The planner discarded this proposal. Sending a correction request was an outward-facing action that was difficult to reverse if sent in error, and there was also no reason to entrust a task with predetermined steps to an agent. The proposal to "put it on hold until model performance improves" was also discarded. Seventy percent could be built with rules today.

The final decision was as follows. Electronic documents were automatically processed via rule-based cross-checking. For scanned documents, a model extracted fields with a fixed output format, and whether to proceed was to be decided after creating an evaluation set by attaching staff-verified ground truth to 300 scanned documents from the past three months. Because errors in hazardous material markings caused significant harm, a human always verified them whenever a discrepancy appeared. Correction request emails were sent by a human. In the legal review section, the planner documented the findings and rationale of reviewing whether this feature fell under Article 2, Subparagraph 4, Item (h) of the AI Basic Act (major operation and management of transport vehicles, transport facilities, and transport systems). The judgment was that document cross-checking was an internal verification task that did not directly control vessel navigation or the operation of transport systems, and ambiguous points were left as items for confirmation by the legal team. In the decision memo, the following sentence was also recorded: "Hazardous material marking items require human verification regardless of accuracy."

New menu copy at Dawn Bakery Workshop

The marketing team at the bakery franchise 'Dawn Bakery Workshop' wanted to use AI to generate candidate copy introducing new menu items each month. At the same time, the sales team requested, "Please predict next month's order volume by franchise store using AI."

The copywriting task contained few factual claims, humans selected and polished the output, and throughput was only a few dozen items per month. While this seemed at odds with the principle that small throughput makes it difficult to recover costs, this task did not involve building a separate system and simply received candidates using an already-contracted general-purpose AI tool, so it incurred almost no development or operational costs; furthermore, because a human selected the copy every time, a separate evaluation framework was not needed. The planner judged this task to be an assistive feature where a single call to a generative model was sufficient. However, rules were added so that sentences containing facts, such as raw ingredients or allergen labeling, were pulled directly from product information, and a note was left for legal team review on whether the labeling obligation for generative AI outputs (Article 31, Paragraph 2) applied even to advertising copy revised by humans.

Order volume forecasting was a problem type that AI excels at, but it stalled on data prerequisites. Franchise orders were received via phone calls and text messages, leaving only month-end totals in the headquarters system. The planner put "initiating AI forecasting" on hold and proposed "introducing a franchise ordering app to record dates, items, and quantities" as a prerequisite project. The sales team was disappointed, but once three months of records accumulated, the forecasting project was brought back up alongside an evaluation set. The discarded alternative was "let's build a model for now with aggregate data." This was because month-end totals cannot learn the timing of the next order.

Common mistakes

1. "Because the question is asked in natural language, an LLM must answer it." The format of the question and the nature of the answer are different. If the answer is a value in a system, a lookup is appropriate; generation only adds the risk of incorrectly transcribing numbers.
2. "Because agents are the most advanced form, they are the best." Agents are for open problems where the number of steps cannot be predicted. Using them for tasks with fixed steps only increases costs and the accumulation of errors.
3. "If a problem requires a model, development can begin immediately." If you lack records and expected outputs, you cannot verify the system even after building it. Data readiness is the condition for kickoff.
4. "Automating even small tasks yields benefits." If throughput is low, development, evaluation, and operational costs cannot be recovered. Calculate the annual time saved first.
5. "If a human makes the final decision, it is not high-impact." High-impact is defined by domain and application. Human management and supervision is an obligation for high-impact AI, not a ground for exemption.
6. "If it is built with rules rather than AI, there are no legal concerns." The automated decision provisions of the Personal Information Protection Act (PIPA) can apply even to fully automated systems that do not use AI.
7. "When determining whether something is high-impact, halt planning until ministerial confirmation is received." A request for confirmation is a legitimate procedure to use when applicability remains truly ambiguous even after an internal prior review. However, halting planning just to wait for a reply when the judgment is clear—such as for loan screening, which is a domain explicitly stated in the statutory text—is merely postponing the obligation of prior review.

Summary at a glance

Check the official docs

• Anthropic — Building effective agents: Principle of simplest solutions, distinction between workflows and agents, routing, and evaluator-optimizer.
• Google PAIR Guidebook — User Needs + Defining Success: Tasks where AI is better and where it is not, automation and assistance.
• Google PAIR Guidebook — Data Collection + Evaluation: From user needs to data needs, representativeness, and test sets.
• Claude Docs — Batch processing: Costs and processing time of batch processing, expiration conditions.
• NIST AI RMF — Core: MAP 3.1 (review of benefits), MANAGE 1.1 (determination of whether to proceed).
• National Law Information Center — Article 2 of the AI Basic Act: Definitions of high-impact artificial intelligence and generative artificial intelligence. Also read Articles 31, 33, 34, and 35 of the same Act.
• National Law Information Center — Article 37-2 of the Personal Information Protection Act (PIPA): Rights of data subjects regarding automated decisions. Articles 44-2 through 44-4 of the Enforcement Decree of the same Act specify request methods, measures, and items to be disclosed.

Self-check

1-1. Write in one sentence the condition of a problem for which an agent is the right solution on the ladder of solutions, and state two of its trade-offs.

1-2. Write four or more tasks for which the Google PAIR Guide considers AI is unlikely to be better.

1-3. In a library seat reservation app, a feature to "interactively inform users of the number of remaining seats" was proposed. The seat count exists in real time in the reservation system. Which solution is appropriate, and why is a generative model not suitable?

1-4. You want to create a feature that predicts a customer's next visit timing, but visit records exist only in an on-site paper ledger. What is the very first thing the planner should do?

1-5. Write three or more measures that a business operator must take if a system qualifies as high-impact artificial intelligence under the AI Basic Act.

1-6. Explain the problem with the claim that "if the right to refuse a decision is restricted due to a contract, one does not need to worry about the automated decision provisions" using Article 37-2 of the Personal Information Protection Act (PIPA).

1-7. (Design) Select one candidate AI task from the service you are currently responsible for, answer the chapter's five screening questions in order, and write the conclusion in one line.

Hands-on tasks