Four decisions IT leads should settle before adopting generative AI

Hi, this is the AVIATE Content team.

"We'd love to bring generative AI in-house — but where do we actually start?" When we talk to IT leads, this question keeps coming up right before a PoC kicks off.

The short answer: starting from tool selection tends to create expensive rework, so settling four design decisions up front saves a lot of backtracking later. In this post, drawing on Japan's AI Business Operator Guidelines v1.2 as of April 2026, we'll walk through those four items — scope of use, data boundary, model selection, and operational ownership — alongside the patterns that most commonly trip people up. The intended reader is an IT or DX lead at a small-to-mid-sized enterprise in Japan.

Don't start from "which tool"#

When you lock in a model first, the "what are we allowed to do with this model, and what are we not" conversation happens afterwards — and the cost of rework starts to compound quietly after the rollout. Picking the tool isn't the end of adoption; if anything, that's when it really begins.

From what we see in the field, the blind spots for IT leads cluster into three shapes.

The first is when scope of use never gets fixed, and each department ends up running its own parallel setup. The second is when "data inputs can, in principle, leave your network" isn't communicated internally. The third is when accountability for incidents stays vague, and operation starts anyway. None of these can be solved by tool selection alone — they need to be handled upfront, as design decisions.

For reference, Japan's Ministry of Internal Affairs and METI published AI Business Operator Guidelines v1.2 in March 2026. It splits participants into AI Developer / AI Provider / AI User, and organizes risk management across the full lifecycle. Most companies deploying generative AI internally fall into the "AI User" role, and the four items in this post map cleanly onto that framing.

The four items at a glance#

Let's start with a rough map.

All four are things you'd want on paper before a tool goes in. Let's walk through them one by one.

Judgment criteria, and the patterns people actually hit#

Scope of use — fix the boundary before opening the gates#

Scope tends to work best when defined across two axes: which departments, and which business processes. An all-at-once, company-wide rollout tends to let individual use outrun governance, and the handling of training data and outbound transmission quietly becomes a black box. It usually pays to name the target process and department for the PoC first, then expand from there.

That said, "company-wide rollout always fails" is too strong a claim. For some company sizes and industries, getting employees hands-on early accelerates learning. What matters is making the scope explicit and tying evaluation metrics and operational ownership to that same scope.

Data boundary — write down what's allowed in before anyone types#

If you skip the "what can the model learn from or store" conversation, you tend to find out the hard way — when an employee pastes confidential or customer data into the tool and only then waves a red flag.

Designing the data boundary usually comes down to mapping input data categories (public / internal / confidential / personal) against tool settings (whether inputs are used for training, retention windows, region). METI's AI Use and Development Contract Checklist, published February 2025, is a practical reference when you're negotiating these boundaries with an external vendor: it covers scope of provided data, terms of use for AI outputs, and risks around misuse.

Model selection — don't decide on "newest" alone#

A model at the top of a benchmark chart doesn't always match your business requirements. The useful judgment axes are context length (for long documents like meeting notes and contracts), output safety, Enterprise-tier data retention, pricing, and integration with existing systems.

A "just pick the latest model" approach quietly forces re-evaluation at every release, and the operating team gets worn down. Fixing the axes first, lining several models up against them, and mapping them to business use cases makes subsequent model updates far less exhausting to absorb.

Operational ownership — don't dump everything on IT#

If you concentrate all post-adoption operation on IT, IT stops having the bandwidth to keep up with the business side's changing requirements. Monitoring, incident response, policy updates, and user support should each have an owner assigned before rollout — whether that's IT, the business unit, or an external vendor.

By the way, choosing an on-prem LLM doesn't magically solve this. Hardware maintenance, model updates, and log management still sit in-house. "On-prem is safe" is not the summary this article wants to leave you with.

A checklist for moving from PoC to production#

Most of how a PoC plays out is already decided by whether the evaluation metrics were written down beforehand. At a minimum, put these four on paper before the PoC starts — you won't have to argue about them later.

Closing — get the design decisions onto one page#

If any of the four items is still blank when the PoC starts, you lose the ability to tell whether a weak result came from operational gaps or model limitations.

Scope, data boundary, model selection, operational ownership — put them on a single page, bullet points are fine. That one page becomes the smallest design document you can reference consistently, from rollout through daily operation.

Business-specific adaptations — accounts payable, customer support, and so on — will be covered in upcoming use-case posts. Running the big-picture design decision and the per-business design decisions in parallel changes the first-year operating cost by a very noticeable margin.

If you'd like a sounding board while shaping an adoption plan, feel free to reach out via Contact.