Compliance for enterprises using relay sites, broken into executable moves

Define the scope first

"Compliance" is too broad a word. For an enterprise using a third-party API relay, four relatively independent issues are actually involved:

1. Cross-border data transfer: did the request content reach a foreign jurisdiction?
2. Personal information processing: does the request contain personal information, and was consent obtained?
3. Supplier management: the counterparty's qualifications, data processing agreement, audit capability.
4. Internal policy: who may use it, what data may be used, how it is logged.

These four have to be handled separately. Discussed together they yield the conclusion "all of it matters and none of it is actionable".

One disclaimer first: what follows is an engineering and process view, not legal advice. For specific compliance judgements, consult legal counsel or a professional firm.

One: cross-border data transfer

The key fact

If a request passes through a relay and reaches a model provider abroad, then the request content has left the jurisdiction. This does not depend on the relay being domestic. The test is where the data is actually received.

Three cases to distinguish

The second row is where mistakes happen: you assume that "we used a domestic relay" makes it fine, while the request is being forwarded overseas.

Executable moves

1. Map the chain first: ask the site directly "where is my request ultimately processed", and ask for a written answer. This is a question worth asking and one that produces a real answer.
2. Classify your data: sort request content into "no sensitive information", "internal information" and "personal information". Only the first category can go over a foreign link directly.
3. Pre-process what needs protecting: redact, substitute, or handle it domestically only.
4. If it genuinely must go abroad, follow the applicable compliance path. That falls within legal territory and needs professional assessment.

Two: personal information processing

The key fact

Both the input to a model and the output from it can constitute personal information processing.

In particular:

• user feedback, support conversations and user-uploaded documents may all contain personal information;
• even if all you do is content rewriting, the processing still counts.

Executable moves

1. State it in your privacy policy: that necessary information will be processed using third-party AI services, and describe the types and purposes.
2. Minimise: send only the fields you need. Send the question without the user identifier, for example.
3. Avoid sending special categories of personal information, such as biometrics, health data or financial account details, unless there is a clear basis.
4. Set a retention policy: confirm the retention and training-use policies of the site and its upstreams. This has to be asked, because some providers train on API data, with some not training by default and others requiring an explicit opt-out.

Item 4 is the most practical: "will my data be used for training" has different answers at different providers, and it directly determines whether you can send internal information.

Three: supplier management

Executable moves

1. Require verifiable qualification information: the operating entity, filing status.
2. Sign a data processing agreement: covering the scope of processing, retention period, deletion mechanism and sub-processors, meaning its own upstreams.
3. Confirm availability and support commitments: there must at least be an incident response mechanism. Do not rely on "they seem like decent people".
4. Establish an exit mechanism: the ability to get your data back, to migrate, and to be refunded. See our article on the five terms to check before topping up.

For business-critical work, a pragmatic step is to prepare two suppliers, one primary and one standby. That is both availability insurance and negotiating leverage.

Four: internal policy

This layer is the most easily skipped, and it determines whether the previous three can actually be implemented.

Four things to make explicit

1. Who may use it: which roles, which projects.
2. What data may be used: the data classification and the corresponding permitted routes.
3. How it is logged: logs, key separation, usage records.
4. Who owns problems: a named owner, rather than "everyone uses it together".

A minimum viable implementation

If you have nothing in place today, do these three in order:

1. Establish key separation: production, test and personal keys, each with a spending cap. See our article on emergency response to a key leak.
2. Establish a data classification list: one page listing which data may be sent, which must be redacted, and which must never be sent.
3. Establish usage and log retention: keep all call records for at least six months.

None of these needs additional procurement or approval, and together they move most of the risk from "uncontrolled" to "controlled".

On MLPS

The subject of MLPS grading and assessment is your own information system. It does not directly constrain which API you use. But if your system falls within MLPS scope, using a third-party API becomes a review point, and assessments usually look at:

• supply chain security, meaning whether external dependencies are managed;
• data transmission security, meaning whether it is encrypted;
• backup and recovery, meaning availability guarantees when you depend on an external service.

So: if your system is within MLPS scope, establishing "third-party API supplier management" as a standing policy is far less work than assembling materials in a hurry later.

One sentence to close

The key to compliance is not "find the most compliant relay site". It is getting your own data, chains, permissions and logging straight. The supplier is only one part of that.

Our listings note public information such as filing status and operating details, but this is not compliance advice. Specific judgements depend on your industry, your data types and your jurisdiction.