The first legal checklist for companies launching AI services

Hello, this is Legal Agent.

Adding an AI feature to an existing SaaS. Offering an AI assistant that searches internal documents. Building a chatbot into customer support. Generating images, text, video or audio. Building an AI agent that acts on a user's behalf. Launching a generative AI service is moving fast across every industry, and speed tends to come first as a product matter.

In that rush, pushing AI legal review to "one big check before launch" lets the workload pile up all at once, since personal data, copyright and AI governance all become live questions together, and a provider can never fully anticipate what a user will type in or what the AI will output. What an AI company needs from the start is not a thick internal policy but a checklist naming what to keep checking as the service runs.

Before looking for AI-specific law

People sometimes ask whether there is a special law just for generative AI. In Japan, practice runs on checking existing law, the APPI, the Copyright Act and sector-specific rules, against what the service actually does, alongside public guidance such as the AI Business Operator Guidelines from the Ministry of Internal Affairs and Communications and METI, and METI's guide to civil liability in AI use. These are not statutes, but they carry real weight in thinking about what controls a provider should have. AI does not so much create entirely new legal issues as set several existing ones moving at once, so a review process built into the service design matters as much as knowing the individual laws.

Work out the company's role first

The checklist should start with which role the company plays, AI developer, AI provider, or AI user, and whether that changes feature by feature, since the points to check depend entirely on the role: developing its own model, building on an external model, using AI only internally, delivering AI output to users, or running an agent that acts on external services on a user's behalf.

A company only using an external API still looks like an "AI service provider" to its users. Where user input goes to that API, its terms, data storage and any overseas transfer need checking, and how far the company is liable for a wrong AI answer becomes a question for the terms of service too. Even AI used purely internally raises confidentiality and APPI questions once a client's confidential information gets entered; not offering the AI to anyone else is not a reason to skip the check.

What to check about input data

Input data is where AI legal work most directly touches the product. What will users put into a prompt? Will they upload files? Could internal documents, contracts or trade secrets end up in there? Drafting the terms of service without looking at this first produces terms that are out of step with reality from day one. Worth checking:

• whether personal information may be entered
• whether sensitive personal information could be mixed in
• whether a customer's trade secrets or confidential information could be mixed in
• whether third-party copyrighted material may be entered
• whether input data is sent to an external AI provider
• whether input data is used for model training
• how long input data and logs are retained
• whether prohibited inputs are stated clearly in the terms and on screen
• whether a corporate customer's admin can control employee use

B2B services in particular see employees upload internal documents without much thought, so the more convenient the product gets, the more input-data control becomes the legal pressure point. Writing "please do not enter personal information" into the terms does not solve this alone, since a screen that visibly invites uploads will not change user behaviour just because the terms say otherwise; the UI, warnings and contract language need designing together.

Training data and copyright

Rights in training and reference data are a real question too. Japan's Copyright Act includes a limitation for information analysis, but that does not make every use of data safe. The Agency for Cultural Affairs' guidance on AI and copyright separates the AI development and training stage from the generation and use stage, looking at the training purpose, how the data is used, whether it unreasonably harms rights holders' interests, and whether the output resembles an existing work.

Start by asking whether the company fine-tunes a model itself; if so, check the training data's source and terms of use, and whether scraping or API collection violated the source site's terms. A RAG setup referencing the company's own or third-party documents needs a separate check on whether the company actually has the right to copy, transmit and display those documents. On the output side there is a design question, reducing the risk that output resembles an existing work, alongside a contract question, allocating responsibility where a user's own input carried a third party's copyrighted work, and having a complaint channel and takedown process ready avoids scrambling once a real complaint arrives. Terms often want to say output belongs to the user, but that single clause sits on top of separate questions, including possible third-party rights in the output and whether the output is even copyrightable, so it should not be treated as the whole answer.

Output and civil liability

AI output can be wrong, and in fields such as law, medicine or finance, where users act on that output, the resulting harm can be serious. METI's April 2026 guide to civil liability in AI use lays out how liability applies under current law given AI's black-box nature and autonomy, and the message is not that AI use excuses liability but that the design, explanation and operational controls in place get examined.

In practice this starts with deciding the AI's role, supplementary information or central to a business decision, then where human review sits in the workflow and how accuracy and legality get explained to users. Operationally that means a process for inquiries, correction and suspension when output is wrong, a line on whether high-risk uses are barred or need separate review, and logs kept well enough to verify what happened in a dispute. A disclaimer alone should not be relied on to absorb the whole risk, since it can be limited under the Consumer Contract Act and does little to rebuild trust after an actual incident.

Personal data and outbound transfers

APPI questions come up constantly: the purpose for which user-entered data is used, whether sending it to an external AI provider counts as outsourcing or third-party provision, whether it counts as an overseas transfer, and whether a breach requires reporting and notice to individuals. "We're just passing it to an external API" does not hold up once the company is the one holding user data. Worth starting from for an AI service's privacy policy:

• what categories of information the AI feature collects
• the purpose of use
• outsourcing or provision to external AI providers, cloud services or analytics tools
• any transfer to a third party overseas
• retention period for logs, prompts and uploaded files
• whether the data is used for training
• how disclosure, correction and suspension requests are handled
• the internal process if a breach occurs

These tend to shift mid-development: swapping a model changes where data goes, and adding a feature changes what gets collected, so a one-time check at launch is not enough; the checklist needs revisiting with every model change or new feature.

Terms of service built around how the AI will actually be used

An AI service's terms need to address usage more than an ordinary SaaS does: how prohibited uses such as illegal activity, rights infringement or malware creation are handled, how far the provider can use input data and output, whether users can use output commercially, and how liability is split if a third party's rights are infringed. A B2B AI service should also define an admin's ability to monitor usage and suspend accounts, and how responsibility is handled if an employee misuses the service. Writing the terms purely as a liability shield misses this opportunity; treating them instead as a design document that the provider and user agree on for how the service may be used changes what actually goes into them.

A checklist as a business decision tool

An AI legal checklist is not only for legal to flag risk. Should this feature ship? Can the external API be swapped? Should users be asked to consent to training use? How long should logs be kept? Should the terms differ for corporate and individual users? How far should high-risk uses in medicine, law or finance be allowed? These are not decisions legal can make alone; management, product and customer success need to weigh in together, and a shared checklist reduces gaps in that discussion and leaves a record of the decision. Being able to explain later why a feature was built a certain way turns directly into an answer when a regulator or a corporate customer's security review asks for one.

LegalAgent, as a firm built for the AI era, does not stop at drafting AI service contracts and terms; legal judgment here looks at the product's specifications, data flow and internal operations too, because AI legal work touches how the business actually runs, not only its documents. An AI service keeps changing after launch, in its features, its model and how it gets used, so legal does not need to be heavy from day one, but deciding from day one what to keep checking cuts the most rework later.