Sending user text to an external AI: what actually goes in Play's Data safety form

Route everything outbound through one place

To avoid redoing the inventory each release, I narrowed the exit. No scattered fetch calls across screens — one function, with each destination's properties held in the type.

// src/net/outbound.ts
// Everything leaving the app goes through here.
// The destination declaration doubles as a draft of the Data safety form.
 
export type Retention = "none" | "shortTerm" | "persisted";
 
export type Destination = {
  id: string;                 // human-readable name used in the form
  host: string;               // where it actually goes
  retention: Retention;       // how long they keep it (from their docs, not a guess)
  usedByThirdParty: boolean;  // do they use it for their own purposes
};
 
export const DESTINATIONS = {
  assistant: {
    id: "Text tidy-up assistant",
    host: "api.example-model.com",
    retention: "shortTerm",   // docs state logs are held for abuse monitoring
    usedByThirdParty: false,
  },
} satisfies Record<string, Destination>;
 
type SendOptions = {
  destination: Destination;
  body: unknown;
  signal?: AbortSignal;
};
 
export async function sendOutbound({ destination, body, signal }: SendOptions) {
  const startedAt = Date.now();
  const requestId = Math.random().toString(36).slice(2, 10);
 
  try {
    const res = await fetch(`https://${destination.host}/v1/complete`, {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify(body),
      signal,
    });
    if (!res.ok) throw new Error(`upstream ${res.status}`);
    return await res.json();
  } finally {
    // The payload never reaches the log. Only what tracing needs.
    console.log(
      `[outbound] id=${requestId} to=${destination.id} ms=${Date.now() - startedAt}`
    );
  }
}

Drafting the form got easier once this was in place. Reading DESTINATIONS top to bottom gives you destination, retention and third-party use in one column. And because a new entry will not typecheck without retention, you cannot ship a destination you never looked up.

The quiet win is what the finally block leaves out. Put body in there and the user's text lives on in the device log. The ephemeral premise has to hold on your side too, not just theirs.

Get the redaction order wrong and half of it survives

Before sending, strip what you do not need. This is where I actually tripped.

I wrote a function to mask email addresses, phone numbers and long digit strings, then ran it over a sample. The input:

The save button freezes the screen since last week's update.
Reach me at taro.example@example.com or 090-1234-5678.
Receipt 4901234567890 shows the same symptom.
Device is iPhone 15 Pro, app v2.1.0.

Replacing in the order email → phone → long digits produced this:

Reach me at [email] or [phone].
Receipt 49[phone] shows the same symptom.

The receipt became 49[phone]. The Japanese phone pattern consumed the 0123456789 slice first, leaving the leading 49 sitting in the payload in the clear. I thought I had masked it. I had masked most of it.

The cause was ordering, nothing more. Settle long digit runs first and the phone pattern has nothing left to cut into:

// src/net/redact.ts
const EMAIL = /[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}/g;
const LONG_DIGITS = /\d{10,}/g;   // order and membership numbers, unhyphenated
const PHONE_JP = /(?:\+81[-\s]?|0)\d{1,4}[-\s]?\d{1,4}[-\s]?\d{3,4}/g;
 
export function redact(input: string) {
  const hits = { email: 0, longDigits: 0, phone: 0 };
  let out = input.replace(EMAIL, () => { hits.email++; return "[email]"; });
  out = out.replace(LONG_DIGITS, () => { hits.longDigits++; return "[number]"; }); // settle first
  out = out.replace(PHONE_JP, () => { hits.phone++; return "[phone]"; });
  return { text: out, hits, before: [...input].length, after: [...out].length };
}

Same input, rerun:

Reach me at [email] or [phone].
Receipt [number] shows the same symptom.
Device is iPhone 15 Pro, app v2.1.0.

{"beforeChars":146,"afterChars":118,"email":1,"longDigits":1,"phone":1}

146 characters down to 118 — roughly 19% shorter — with one email, one long digit run and one phone number removed. Returning the counts is worth the two extra lines — later you can look at how much a given screen typically strips.

I also checked the opposite failure. Version strings like v2.1.0, the date 2026-09-07, iOS 27, 0.5s, the crash code 0x8badf00d and the resolution 1080x1920 all passed through untouched. The parts that make a bug report useful survive.

Redaction always looks correct on the page you wrote it on. You cannot judge it until you run real text through and read the before and after side by side.

Count your outbound hosts in a dev build

A destination declaration is only half the picture. Traffic your own code never wrote will not appear in it.

In dev builds I wrap fetch and collect hostnames.

// src/dev/outboundAudit.ts
// Dev builds only. This never ships.
 
const seen = new Map<string, number>();
 
export function installOutboundAudit() {
  if (!__DEV__) return;
  const original = global.fetch;
 
  global.fetch = async (input: RequestInfo | URL, init?: RequestInit) => {
    const url = typeof input === "string" ? input : input.toString();
    try {
      const host = new URL(url).host;
      seen.set(host, (seen.get(host) ?? 0) + 1);
    } catch {
      // relative URLs are not counted
    }
    return original(input, init);
  };
}
 
export function dumpOutboundHosts() {
  const rows = [...seen.entries()].sort((a, b) => b[1] - a[1]);
  console.log("[outbound-audit] " + JSON.stringify(Object.fromEntries(rows)));
}

Walk the whole app once, call dumpOutboundHosts(), and reconcile the list against your declarations. Native-side traffic that bypasses fetch will not show up, so treat this as a starting point rather than a complete picture. Even so, one unrecognised host is enough to send you into that SDK's documentation, which is exactly where the answer lives.

For the ordering of consent prompts at startup, I covered that in the production guide to Rork with AdMob UMP and ATT consent management.

The table I use to pick a classification

Three columns per destination, filled in before I choose a row.

The gap between row one and row two is the point of this whole piece. The text is identical; only the recipient's retention window differs, and that alone changes what appears on your listing. Which is why the thing to check is not your code but their terms and their retention documentation.

When retention is unstated, or an enquiry does not produce a firm answer, I declare it as retained. Over-declaring and trimming later keeps releases moving. Under-declaring and getting sent back does not.

Four questions before I save the form

1. Does the audit log show a host that is missing from my destination declarations?
2. Did I compare before and after on real text, not a contrived string?
3. Is the payload still sitting in a debug log somewhere?
4. Did I confirm retention from the provider's own documentation rather than a secondhand summary?

Question three catches me most often. A log line added while chasing a bug has a way of staying. I now pair the console.log sweep with the form review rather than treating them as separate chores.

If you ship several apps from one codebase, the destinations differ per app while the form gets copied wholesale from last time. I touched on that trap in the one-page value manifest I keep for a second app built from the same codebase.

What to do next

Walk your shipping app end to end in a dev build and write down the outbound hosts. Declarations and redaction can come after. Reverse the order and you end up declaring what you imagine your app does rather than what you have observed.

Wiring in an external AI is half a day of work now. The slow part is getting to where you can describe, in your own words, what your app is sending. I am still partway through that inventory myself, but narrowing the exit to a single function is the decision I have been glad of. Thank you for reading.