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.
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:
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.