Generative AI Implementation Guide

Tomohiro Iida · Published: April 12, 2026Last updated: September 29, 2026

When bringing AI into business work, some things need deciding before the model name or the PoC duration: the job the AI is given, the authority and data it receives, the conditions for passing and for stopping, how the change is confirmed in production, and how results are measured. Write these as a single operating contract, and assign a model or product that fits the contract afterwards.

The first version of this guide, published in April 2026, described five steps from problem identification to embedding AI in operations, with a 2–4 week PoC and measurement at 3, 6, and 12 months as rules of thumb. Since then, Netsujo ran into three problems in its own AI development operations: work stalled because a role was tied to one AI product; work did not move until a person pressed "resume", even though its state had been saved; and deployment success was easy to mistake for production completion. Netsujo reorganized its operations as a result. The September 2026 revision translates those changed decisions into enterprise AI adoption and removes the general claims about durations and products.

The strength of each item is not uniform. Uses that are easy to undo and have no customer impact, such as drafting support for internal use, get light controls; uses that are hard to undo, such as sending, publishing, or changing production systems, get heavier ones.

What changed from the original five steps

The parts of the original guide that still hold are kept: start from "we want to solve this business problem" rather than "we want to use AI"; define success criteria before the PoC; leave high-impact judgments such as legal, medical, and HR decisions with people; and redesign the workflow instead of only swapping in a tool. What changed are the parts that presented durations, cadences, and the order of technology choices as general rules.

1. Decide one business job and its baseline

Start by writing whose work, in which business process, and which output will change. "Make sales more efficient" is too coarse to judge pass or fail. Narrow it to a level where the input, the output, the recipient, and the final user are clear — for example, "draft the first reply to contact-form inquiries for the person in charge to review before sending." Begin with one business process whose effect is easy to measure.

Next, record the current value of that work as the baseline: time per case, how often work is corrected or sent back, waiting time before a response, number of cases per month — values that can be measured the same way after adoption. If the current value has not been measured, measure it before introducing AI. Without a baseline, you can tell that AI is being used, but not whether things got better. If there are several candidate processes and the starting point is undecided, sort out applicability and priority for each first; that process is covered in the AI implementation diagnosis article.

2. Set authority and data boundaries by reversibility and customer impact

Once the business job is set, decide what data AI can read, what operations AI can perform, and who approves those operations. Match the strength of the checks to whether the operation can be undone and how much it affects customers.

Classify data the same way. Whether data may be passed to an external AI service differs for public information, internal-only information, and customers' personal or contract information. For each class, decide whether it may be passed, under which service terms it may be passed, and where records of inputs and outputs are kept. For an individual using AI to draft internal documents, this much procedure is excessive. The aim is to keep the top rows of the table light and the bottom rows heavy, not to require the same review for every use.

3. Choose Role and Runtime separately

A Role is what job a function does and how much authority it has. A Runtime is the model, product, or provider that actually executes that job. If the two are decided together — "this AI product is the person in charge" — the business process itself stops when that product is congested or hits a usage limit. Netsujo hit this problem in its own development operations during a period when roles were tied to specific products: work stopped because of usage allowance or concurrency limits. It now defines roles and authority first and chooses a Runtime by required capability, the authority it may be given, remaining usage allowance, and whether it can actually process work at that moment. Even when one Runtime is unavailable, the requirement for independent review is not dropped.

In enterprise adoption too, an API, existing SaaS, and a model adapted for the company are chosen by whether they fit the operating contract, not lined up as maturity stages. The inputs are the usage terms for the data handled, the required capability, integration with existing systems, cost, and usage limits. Using the newest or top-tier model, or owning a company-specific model, is not a goal in itself. Comparisons and rankings of specific models are out of scope because they change quickly and depend on business conditions. The allocation Netsujo uses in its role-separated development decides three things for each Role first — authority, unit of work, and acceptance criteria — and assigns a Runtime afterwards.

4. Design the PoC and first live operation around acceptance and stop criteria

What the PoC decides first is what must be confirmed to move on (acceptance criteria) and what event stops it (stop criteria). The duration is set after that.

Acceptance criteria

Which indicators must change by how much against the baseline to pass, with the level set by the business owner; which kinds of errors are unacceptable (errors in amounts, dates, or proper nouns, output of information that must not be passed, and so on) and how they are handled; how many cases are evaluated, and who evaluates them

Stop criteria

An unacceptable kind of error occurred; data that must not be passed reached the AI or appeared in its output; results stayed below the baseline; the effort people spend checking exceeded the work time saved

Set the duration per project, as a guide long enough to collect the cases needed for evaluation and to observe the target process through its cycle (a weekly report, a monthly close, and so on). Working backwards from a uniform number of weeks leads either to judging with too few cases or to postponing the decision. Passing the PoC does not necessarily mean moving straight to full rollout. Between the PoC and full rollout, place a "first live operation" limited to certain staff or cases, and confirm the same acceptance and stop criteria with production data and the real workflow. What the PoC should leave behind is a record usable for this decision, more than a working demo. For turning stop criteria into numbers and deadlines, the Web3 PoC consultation case on exit criteria is a useful reference; for the reasons PoCs struggle to reach commercialization, see the article on PoC failure patterns.

5. Record independent review, deployment, and production verification separately

"Adoption complete" is not a single state. In Netsujo's development operations, the following five are recorded as separate states and each is confirmed with different evidence. The state names are Netsujo's operating definitions, not an industry standard. The right-hand column shows how they read when translated to enterprise AI adoption. Independent review sits between IMPLEMENTED and MERGED, confirming that the reviewed version is the same as the version being merged.

Independent review means a reviewer with a separate assignment and decision authority from the implementation confirms the same version that will actually be applied. Merely switching Runtime does not make the review independent. If the content changes after review, the old review result is not carried over to the new version; it is checked again. When the author or the same assignment also reviews its own work, it is not an independent review.

A successful deployment shows only that the apply operation ran to the end. Whether the intended change works in the user's environment is known only after confirming, in production, an output or screen that only that change could alter. The same separation works when adoption is only a SaaS configuration change: record separately the configuration change, the check, the release to users, the confirmation in the users' environment, and the judgment that it may be used in the business. How to confirm that the reviewed version and the applied version match, and how to verify all the way to the public production domain, are covered in the exact-SHA and production-verification articles.

6. Split stops into three kinds

When AI is built into a business workflow, there will be moments when processing stops partway. Decide before going live whether an automatic retry is allowed in each case.

Draw the boundaries conservatively. A stop whose class is unclear does not go into "recovers if you wait". Automatically retrying an operation whose outcome is unknown adds failures that are hard to undo, such as sending the same email twice or registering the same order twice. At Netsujo, even after introducing a mechanism that saves work state, a problem remained where stalled work did not move until a person noticed it and instructed a resume. Netsujo therefore added a mechanism that keeps observing and re-evaluating only enumerated "recovers if you wait" states, such as a reviewer Runtime being temporarily unavailable. General stops and outcome-unknown states are not given authority for automatic retry. The background is described in the article on state management in AI agent development.

7. Measure operational KPIs and business KPIs separately

Numbers of users, prompts, and generated documents or changes show how much AI was used or how much it produced. They are not evidence of business results. Netsujo itself has records from a period when its AI-assisted development volume rose sharply, but treats them as evidence of production capacity, not as evidence of product-market fit, revenue, or retention. That distinction is covered in the articles on measuring time to verified production and on founder productivity.

Choose measurement points by the target process's cycle and how the baseline was taken, not by a fixed number of months: after the close for monthly-close work, after a set number of cases for project-based work — points that can be compared in the same unit as before adoption. When results do not appear, before replacing the tool, review the workflow on the receiving side of the AI output, the effort people spend checking it, and how the baseline was measured.

Write down what people decide, by role

Writing only "a person checks at the end" leaves unclear who decides what. In the operating contract, write the content of each decision by role. One person may hold several roles, but the author and the independent reviewer are kept separate.

Business owner

The business job, the baseline, and the acceptance level; whether to move from the first live operation to rollout, or to stop

Information management owner

Which data classes may be passed to AI, and the conditions for using external AI services

Approver for each operation

Whether to approve, before execution, operations that are hard to undo such as sending, publishing, or production changes

Independent reviewer

Whether the same version that will actually be applied meets the acceptance criteria

Operations owner

Which class a stop falls into; whether an operation with an unknown outcome actually executed; whether it is safe to resume

Management

Looking at business KPIs, whether to continue investing, change scope, or stop

Final decisions not left to AI

• Final decisions carrying legal responsibility (signing contracts, medical judgments, final HR evaluation decisions, and so on). Whether legal, medical, or HR decisions are legally appropriate should be confirmed with specialists
• Setting the acceptance level, and deciding whether to continue or stop adoption
• Settling whether an operation with an unknown outcome actually executed, and deciding whether to re-run it afterwards

Keep "do not introduce generative AI" as an option

• Work already efficient under the existing workflow, with little room for improvement
• Processing whose response characteristics do not suit generative AI, such as control systems requiring millisecond-level response
• Work with almost no data to base judgments on, where neither a baseline nor acceptance criteria can be set

Checklist before handing over to the first live operation

If any of the following cannot be answered yet, add it to the operating contract before choosing a model or product.

• The business job is written at the level of input, output, recipient, and final user
• The baseline is recorded in a form that can be measured the same way after adoption
• The data classes AI can read, and the data that must not be passed, are decided
• The operations AI can perform, and the approver for each hard-to-undo operation, are decided
• Roles and authority are written independently of specific product names
• Acceptance and stop criteria are decided, including the number of cases evaluated and the evaluators
• The independent reviewer, and the method for confirming that the reviewed version and the applied version are the same, are decided
• The items to confirm in production after deployment, and who confirms them, are decided
• The three stop classes exist, and the states allowed to resume automatically are enumerated
• There is a contact and recovery procedure for when a hard-to-undo operation fails
• Operational and business KPIs are separated, and measurement points are set to fit the business cycle

Assumptions and limits of this decision order

• These are lessons drawn from Netsujo's small-team, heavily automated development operations. Read the state names and classes as Netsujo's operating definitions
• No specific model, product, or provider is rated against another
• No improvement range for return on investment or adoption rate is given. Effects are confirmed against each company's own baseline
• Set the PoC duration and measurement cadence per project to fit the business cycle and risk

Measure time to verified production, not PR count（日本語）

AI made the company faster. Did the founder get time back?（日本語）

Pin the verification target with an exact SHA, not a PR number

Five reasons PoCs fail to reach commercialization