# Personal data, commercial disclosures and privacy policy — the legal check before selling an AI-built app

> What you need legally before launching and charging for an app you built with AI, organised for non-engineers. Why a privacy policy is required from the first email address you hold, the mandatory items in Japan's commercial-transaction disclosure, and what to watch when you use external services such as AI APIs, analytics and payments.

- Published: 2026-08-06
- Author: 友田 陽大
- Tags: バイブコーディング, 個人開発, 発注, セキュリティ
- URL: https://tomodahinata.com/en/blog/ai-app-legal-checklist-japan
- Category: Running the app you built with AI
- Pillar guide: https://tomodahinata.com/en/blog/ai-app-pre-launch-guide-for-non-engineers

## Key points

- If you hold even one email address, publishing your purpose of use is an obligation under Japan's personal data protection law. Being an individual, or offering the service free, is not an exemption.
- If you charge, you need the disclosure required by the Specified Commercial Transactions Act. Payment providers such as Stripe also check for it during onboarding review.
- Sending user input to an AI API can constitute provision to a third party. If it isn't in your privacy policy, the practice is undisclosed.
- You are obliged to honour deletion requests, but AI-generated schemas commonly leave orphaned data or fail on a foreign-key constraint. Try it once for real.
- This is a general orientation, not legal advice. For a real business, have the final wording reviewed by a qualified professional.

---

This isn't a technical topic, but **it is the one that becomes most tedious after launch**. The work itself takes a day.

Up front: **this is a general orientation, not legal advice.** If you are running this as a business, have the final wording reviewed by a qualified professional. What follows is a map for avoiding the state of launching without knowing what is required.

Note that this article describes the Japanese legal framework. If you operate elsewhere, the shape of the obligations will be similar but the specific statutes will not.

---

## 1. Where the obligations start

Let's clear the common misconceptions first.

**"I'm an individual, so it doesn't apply."** — It applies. The law covers "businesses handling personal data," and corporate status is not a criterion. An individual handling personal data in the course of business is in scope.

**"It's free, so it doesn't apply."** — Whether you charge is not a criterion.

**"I only have a few users so far."** — There is no lower threshold (the former 5,000-record threshold was removed in 2017).

**"It's only an email address, so it isn't personal data."** — An email address becomes personal data when its format includes a name, or when combined with other information it identifies an individual. In practice, treating it as personal data is the safe assumption.

So — **if you hold even one email address, assume you are in scope.**

---

## 2. Privacy policy — what to write

The law requires you to specify your purpose of use and to **publish or notify** it when handling personal data. A privacy policy is the means of publishing.

### The minimum sections

**(1) Who you are**
Name (a trading name is acceptable) and contact details. Sole traders often want to avoid publishing a home address, but a means of contact is mandatory.

**(2) The personal data you collect**
Specifically what you gather. The commonly missed ones:

- Registration details (email address, name)
- The contents of contact-form submissions
- **Analytics identifiers** (cookies, device information, IP addresses)
- **Payment-related information** (if Stripe or similar handles it, state that you do not retain it)
- **Input sent to an AI** ← easily overlooked

**(3) Purpose of use**
"To provide the service" alone is not sufficient. Be specific. If you intend to send marketing email later, say so now or you cannot send it.

**(4) Third-party provision and external services**
List the external services you use.

```
example:
- analytics: Google Analytics / Microsoft Clarity
- payments: Stripe
- email: Resend
- hosting: Vercel
- database: Supabase
- AI processing: OpenAI / Anthropic
```

**(5) Retention and deletion**
How long you keep data, and where to send a deletion request.

**(6) Contact point**
An email address or other reachable channel.

### Where to put it

**Link it from the footer on every page.** Make it reachable from the signup screen and the contact form too. "It's there if you look" is weak as publication.

---

## 3. Extra steps when you use an AI API

This is the point specific to AI-built apps, and the most often missed.

If user input is sent to an OpenAI or Anthropic API, **that can constitute provision to an external party**.

### What to confirm

**(1) Establish what is being sent**
For a chat feature, the conversation. For summarisation, the uploaded document. For image generation, the input image. Write down everything you send to an AI.

**(2) Confirm whether that data is used for training**
The APIs of major AI services (via the API rather than the consumer console) commonly default to not training on submitted data — but **this varies by service and plan**. Confirm it against the current terms.

**(3) Put it in the privacy policy**
State plainly that "to process your input, it is transmitted to the API operated by X." Without that, users are using the service unaware their data leaves.

**(4) Reconsider if the data is sensitive**
If you handle special-category data such as health, beliefs, or criminal history, obtaining it generally requires the person's consent in the first place. A design that then sends it to an AI needs revisiting from that premise.

---

## 4. Commercial-transaction disclosures — mandatory once you charge

**If you offer only a free service, skip this section.**

Selling online in Japan obliges you, under the Specified Commercial Transactions Act, to display certain information about your business.

### The main items

- Seller's name
- Name of the representative or responsible officer
- Address
- Contact details (phone number, email address)
- Price (state clearly whether tax is included)
- Any costs beyond the price of the goods
- Payment method and timing
- When the goods or service are delivered
- **Return and cancellation terms**

### What matters most for digital services

**Return handling.** Digital content generally does not lend itself to returns, and you need to state that. Say nothing and you have a dispute later.

**Subscription cancellation.** The cancellation procedure, how long access continues afterwards, and whether pro-rata refunds apply. Recurring-billing disputes are an area the Consumer Affairs Agency watches closely, so be thorough here.

**Automatic renewal.** That it renews automatically, when, and whether notice is given beforehand.

### Its relationship to payment review

Practically: **payment providers including Stripe check for this disclosure during review.** Without it you fail review and cannot take payments.

"The code is finished but I can't enable payments" usually traces back to this. **Preparing it before you finish the code is faster.**

### On publishing an address

Publishing a home address is a genuine concern for sole traders. Options include using a virtual office, or omitting certain items where the conditions permit — but **the conditions for omission are narrow**. Check the Consumer Affairs Agency guidance, or consult a professional.

---

## 5. Deletion requests — try it for real

The law obliges you, subject to conditions, to honour requests to stop using or erase personal data.

As law, that is the whole of it. **The technical problem is bigger.**

### What commonly happens with AI-generated schemas

Deleting a user in a database structure AI produced tends to do one of:

- **Fail on a foreign-key constraint** so the deletion cannot proceed (related rows still exist)
- **Delete only the user**, leaving posts, orders and logs orphaned
- **Cascade unintentionally**, deleting payment history you were required to keep

The third is dangerous in the opposite direction. Payment and transaction records may carry a statutory retention obligation.

### What to do

**Create a test account and actually delete it.** Once, before launch.

- Does it delete without erroring?
- Is any related data left behind?
- Did anything get deleted that must not be?

### How to think about the design

For data that plausibly carries a retention obligation (payment history, transaction records), the standard approach is **anonymisation rather than deletion**: strip the personally identifying fields and keep the amounts and dates.

---

## 6. Terms of service — not mandatory, but near-essential

There is no blanket legal requirement, but without them you have nothing to point to when something goes wrong.

At minimum, define:

- **Prohibited conduct** — what gets an account suspended
- **Scope of liability** — your responsibility if the service stops or data is lost
- **Changing or ending the service** — especially important for a solo project: that you may stop at any time
- **Governing law and jurisdiction**

**The freer the service, the more the point of stating the limits of your liability.** Even a hobby tool offered free becomes a different matter once someone uses it for work and something goes wrong.

---

## 7. Instructions to paste into your AI tool

The legal documents themselves shouldn't be handed entirely to an AI, but **taking inventory of what you collect is something AI is good at** — and without an accurate inventory you cannot write a correct policy.

```text
For this app, produce tables covering the following.

(1) The items of personal data collected, and on which screen or feature each is
    collected (including signup, contact forms, analytics, cookies and logs)
(2) The external services used and the data sent to each (hosting, database,
    payments, email, analytics, AI APIs, error monitoring)
(3) If there is billing, the price, when charges occur, and the cancellation
    terms, as far as they can be read from the code
(4) Places where personal data is written verbatim into logs or error reports

Then draft a privacy policy matching the reality of (1) and (2), and a
commercial-transaction disclosure page based on (3).

Conditions:
- Include only what this app actually collects; do not produce a copy of a
  generic template
- Mark anything I must fill in myself, such as business details, as [TO FILL]
- Note at the top of the output that the final wording requires review by a
  qualified professional
```

And for the deletion implementation:

```text
Read this app's database schema and produce a table of what happens to related
data when a user is deleted (cascade, orphaned rows, or a foreign-key error).

Then implement complete deletion of a user account and its related data. For
data that may carry a statutory retention obligation, such as payment history,
also propose anonymisation — removing only the personally identifying fields —
instead of deletion.
```

---

## 8. Pre-launch checklist

**Everyone**

- [ ] Wrote a privacy policy and linked it from the footer
- [ ] Listed the personal data collected, matching reality
- [ ] Listed every external service used
- [ ] Stated what is sent to AI APIs
- [ ] Published a contact point
- [ ] Prepared terms of service (liability, prohibited conduct, ending the service)
- [ ] Actually deleted a test account

**If you charge**

- [ ] Published the commercial-transaction disclosure, reachable from the purchase flow
- [ ] Stated the price and the tax treatment
- [ ] Wrote the return and cancellation terms
- [ ] (Subscriptions) Stated the cancellation method, automatic renewal and its timing
- [ ] Checked what the payment provider's review requires

---

## Summary

- If you hold even one email address, publishing your purpose of use is an obligation. Individual and free are not exemptions
- If you charge, you need the commercial-transaction disclosure. Payment review checks for it, so preparing it before the code is finished is faster
- If you send user input to an AI API, say so in the privacy policy. Otherwise the practice is undisclosed
- You must honour deletion requests, and AI-generated schemas tend to break on deletion. Try it once before launch
- Terms of service aren't mandatory, but without them you have nothing to point to

Again: **this is a general orientation, not legal advice.** If you run this as a business, have the final wording reviewed by a qualified professional.

The technical checks are in [Before you launch the app you built with AI](/blog/ai-app-pre-launch-guide-for-non-engineers).
