Where the compliance line sits when enterprise data goes through a third-party API

First, this is not legal advice

This article is about compliance considerations in technical selection. It helps you identify risk points and know what to ask your legal team. A concrete compliance judgement depends on your industry, your data types, and where you operate, so consult a professional.

Three independent risk dimensions

Many people treat compliance as one thing when it is really three:

The three are independent. A request can be harmless in content yet cross a border, or sensitive in content yet stay domestic.

Dimension one: data content

The internal tier is the one most often overlooked. Many people assume internal documents are uninteresting, but code repositories and customer lists carry real commercial value.

Dimension two: data path

With a mainland relay site the chain usually looks like this:

your server, domestic -> relay site, domestic -> upstream, possibly overseas -> model vendor

Two things to note:

1. The data reaches the relay site, which is a visible point in the chain
2. It may cross a border, because if the upstream connects to an overseas vendor the data leaves the country

Border crossing is regulated very differently across industries, so judge it against your own situation. You can ask the provider where requests are forwarded, whether they cross a border, and whether a domestic processing option exists.

Dimension three: accountability

When something goes wrong, is there anyone to hold responsible.

A hard threshold in corporate procurement is whether a contract can be signed. Without one you have nothing to stand on when something goes wrong, and this single point often decides the selection independently of price.

An assessment process you can follow

1. List the data types you will actually send
        |
2. Assign a sensitivity tier to each
        |
3. For anything at sensitive or above, ask three questions:
   - Can it be redacted before sending? If yes, treat it as a lower tier
   - Can it be split so that only the necessary part is sent?
   - Can it move to a local model or self-hosting?
        |
4. For the third-party calls that remain, require written confirmation:
   - the data handling and retention policy
   - whether it crosses a border, and to which regions
   - whether a data processing agreement can be signed
        |
5. Record the conclusion in your technical selection document

Step 5 matters because compliance judgements need a paper trail. Six months later, when someone asks why this option was chosen, you need something to point to.

Three technical ways to reduce risk

1. Redact before sending.

import re
def mask(text):
    text = re.sub(r'1[3-9]\d{9}', '[PHONE]', text)
    text = re.sub(r'\d{17}[\dXx]', '[ID]', text)
    text = re.sub(r'[\w.-]+@[\w.-]+', '[EMAIL]', text)
    return text

It works well on structured data and costs almost nothing.

2. Minimise what you transmit. Do not send a whole document, send only the section that needs processing.

3. Process in layers.

sensitive parts -> local model / official platform
non-sensitive parts -> third-party relay site

Many workloads can be split this way, controlling risk and cost at the same time.

When to walk away from third parties

• the data contains clear personal information that cannot be redacted
• the industry is heavily regulated, such as finance or healthcare, and the provider cannot supply compliance documents
• cross-border transfer is unacceptable
• the business has a hard accountability requirement and the provider cannot sign an agreement

In these cases, a self-hosted gateway with an official upstream, or a locally deployed open-source model, is the steadier choice.

A pragmatic view

Compliance is not a cost item to avoid where possible, and it is not insurance that makes everything safe once it is done.

What it actually does is let you see where the boundaries of risk lie when you make a technical choice, and keep the controllable part under control.

Most companies do not need to abandon third-party APIs entirely. They need categorised handling: isolate the genuinely sensitive parts and use the rest as normal.

Related reading

• Who handles your request: the data boundaries inside a relay chain
• Self-hosting a gateway vs buying a relay service: cost and where each fits
• Corporate procurement of a relay service: invoices, contracts, compliance and risk control