What to Decide at the Design Stage When Your Product Sends Customer Input to an Overseas AI API

A proof of concept for an AI feature usually starts by sending real text straight to an overseas provider's API. It is fast to build, and I think that is the right way to start.

The trouble comes when it turns into a product. Legal, or a customer's IT department, asks "where does our customers' data go, and how is it handled?" and the team realizes it has no answer ready. Rebuilding screens and processing at that point almost always pushes the release back.

I design products with AI built in, and these are the decisions I would make first. I am a designer, not a lawyer. Make the final call with a professional. What follows is what the product side can prepare before that conversation.

What the Personal Information Protection Commission asks for

On June 2, 2023, Japan's Personal Information Protection Commission issued a notice on the use of generative AI services. The part for businesses is short and comes down to two points.

First, if you enter a prompt that contains personal information, confirm carefully that it falls within the purpose of use you have specified.

Second, if you enter a prompt containing personal data without the person's consent, and that data is handled for anything other than producing the response, you may be breaking the law. So if you do enter such prompts, confirm carefully that the AI provider does not use that data for machine learning, among other things.

The notice reads as if it is about staff using ChatGPT at work. But when you build AI into your own product, the shape is the same: customer input goes to the provider.

Sending data to a provider abroad

The other provision to check is Article 28 of the Act on the Protection of Personal Information. As a rule, providing personal data to a third party in a foreign country requires the person's consent in advance. When you ask for that consent, you have to give the person information such as the foreign country's personal data protection system and the measures the recipient takes.

The exceptions are a provider in a country the Commission recognizes as having an equivalent level of protection, and a recipient whose setup meets the standard in the Commission's rules. In that second case, the company that provided the data still has a duty to check that the recipient keeps those measures in place.

Which route your product takes depends on the contracts, so confirm it with a professional. What matters on the design side is that every route needs the same three decisions.

One: check the API settings and write them down

Each AI provider handles data differently, and much of it can be changed in the dashboard settings or the contract.

OpenAI's documentation on data handling, for example, says:

• data sent to the API is not used to train models unless you opt in
• abuse monitoring logs are kept for up to 30 days
• Zero Data Retention needs prior approval
• you can choose Japan for data storage, but in Japan that covers storage only, and you cannot choose the region where processing happens

That last point is easy to miss. Choosing the Japan region does not necessarily mean everything stays in Japan.

Once you pick a provider, I recommend a one page table: use for training, retention period, where data is stored and processed, and the name of the contract. When a customer's IT department sends a security questionnaire, the table is the answer. Update it every time you change models or providers.

Two: strip it before you send it

The most effective measure is not sending the data at all.

What the AI usually needs is the meaning of the text. It rarely needs the names, phone numbers or addresses in it. Before sending, replace a name with something like "Customer A" and a phone number with "Phone 1," then swap the real values back on your own server once the response returns. Build this in from the start and the nature of what you send changes a lot.

The other habit is not sending the whole customer record. If you only need to summarize the body of an inquiry, send only the body. Sending everything is easier during development, so unless someone decides this on purpose, it stays that way in the product.

Be careful with what the law calls special care required personal information, such as medical history. As a rule, acquiring it requires the person's consent in advance (Article 20, paragraph 2). Give users a free text field and they will write more detail than you expect. If the use case invites people to write about their health or family, put a line next to the field such as "Please do not enter illnesses or medical conditions," or build a consent screen designed for that use.

Three: explain and ask at the moment of use

A line deep in the privacy policy means users never find out.

What I recommend is a short explanation the first time someone uses the AI feature: which provider and which country the data goes to, whether it is used for training, and how long it is kept if it is kept. Three or four lines is enough. If you take the Article 28 consent route, add a link explaining the destination country's system and so on, and this becomes the consent screen.

Also keep a way to do the task without AI, so people who do not consent are not pushed out of the whole service: entering it by hand, or sending it to a staff member.

Once you collect consent, record when each person agreed and to which version of the explanation. If you change the wording and cannot tell who saw which version, the only option left is asking everyone again.

Decide what stays on your own side too

Attention tends to go to the provider's settings, but data also stays on your own servers. If you log prompts and responses, those logs hold exactly what customers typed.

During development it is normal to keep every log to chase bugs. For the product, decide what you keep and for how many days, and make it delete itself when the time is up. If all you need to investigate problems is timing and error types, you can choose not to keep the text at all.

Before you ask a provider about its retention period, be ready to state your own. Most security questionnaires ask about both.

At the first meeting

If you are preparing a product with AI built in, tell me three things at the first meeting: what information users will enter, which AI provider and plan you plan to use, and your current privacy policy.

Start by drawing the data flow on a single page, and the conversation with legal and the screen design can both work from the same diagram.