Every Prompt Is a Cross-Border Transfer: AI Governance Under Law 2019-014

An insurance company in Lomé equips two hundred employees with an AI assistant. A bank in Dakar wires its support team to the same providers. A public agency in Abidjan runs a pilot on document summarization. In every case the work is real, the productivity gain is real, and the procurement was a corporate card and a base URL. In every case, nobody filed anything with the data protection authority, because nobody framed what was happening as a data transfer. It was framed as buying a tool.

The first article in this series showed that no one can say what a company spends on AI. The second built the gateway that answers that question. This one takes up the second of the three unknowns, exposure, in a setting where it stops being a matter of internal preference: what leaves the building, under which law, and what a gateway does and does not change about it.

Two caveats before anything else. This is an engineering analysis and not legal advice, and the reader who needs an opinion should get one from counsel admitted in the relevant jurisdiction. And the legal texts referenced here were written before conversational inference existed, so applying them requires interpretation. I flag each place where I am extending a text rather than reading it.

The qualification nobody performed

Start with what is actually in the request. A support agent pastes a customer email to get help with a reply. The email contains a name, an address, a policy number and a complaint. A recruiter pastes a CV to summarize it. A lawyer uploads a contract naming the parties. A manager asks for help drafting a warning letter about a named employee.

Each of those payloads is personal data by any ordinary reading: information relating to an identified or identifiable natural person. Sending it to a model hosted outside the country is a processing operation performed by a third party on behalf of the company, and the data crossed a border to get there. Those are the two facts from which everything else follows, and the reason they get missed is that neither of them looks like the mental image people have of a transfer. There is no database export, no file, no migration project, no signature. There is a person typing into a text box.

The mental image matters more than it should, because compliance processes are triggered by recognition. A company that would never email a customer list to a foreign vendor without review will let the same content leave one paragraph at a time, thousands of times a day, because each individual act is small and looks like using software rather than sending data.

There is a second population being processed here and it is routinely forgotten: the employees themselves. Every prompt is authored by an identified person, and once a gateway is logging, the company is processing employee data about what its staff asks, when, and how often. That is its own processing activity, with its own basis and its own obligation to inform the people concerned. Deploying a gateway without telling employees what it records is a compliance problem created by the compliance solution.

What law 2019-014 actually asks

Togo's law 2019-014 on the protection of personal data conditions the transfer of data to a third country on that country offering a sufficient level of protection, and requires prior notice to the Instance, the data protection authority, which issues a reasoned opinion. Alongside it sit law 2017-007 on electronic transactions and its implementing decree 2018-062, and the cybersecurity rules of the 2022-040 order issued by the ANCY. Neighbouring UEMOA jurisdictions have structurally similar regimes with different institutions and thresholds.

The question the text asks is not where the disk sits. It is which legal system can reach the data, and whether you declared that exposure. This is the same point the multi-cloud analysis in this blog made about storage, and it transposes to inference without modification.

What does not transpose cleanly is the shape of the thing being declared. A transfer regime of this kind assumes a described processing: a defined dataset, a stated purpose, a known recipient, a retention period, a security description. That framing fits a payroll export to a foreign processor. It fits an LLM gateway badly, because the content of what gets transferred is decided at runtime by whichever employee is typing, and no declaration written in advance can enumerate it. You can declare the categories of data likely to be sent, the recipients, the purposes and the safeguards. You cannot declare the payload, because the payload is whatever two hundred people decide to paste tomorrow.

This is the genuine gap, and it is worth stating precisely because it cuts both ways. It is not an excuse to skip the declaration; the categories, recipients and safeguards are declarable and refusing to declare them because the exercise is imperfect is not a defensible position. But it does mean that the control which actually bounds the transfer is not the paperwork. It is whatever mechanism constrains what employees can send, which is a technical control, which is the gateway. The declaration describes the boundary. The gateway is the boundary.

Jurisdiction, briefly

The reason a "sufficient level of protection" analysis rarely ends well for American inference providers is the same reason it rarely ends well for American cloud providers, and this blog has already made the argument at length for storage. The short version: the CLOUD Act of 2018 amends the Stored Communications Act so that a provider subject to United States jurisdiction must produce data in its possession, custody or control in response to valid legal process, regardless of where that data physically sits. A regional endpoint changes geography. It does not change which court can compel the parent company.

Applied to inference, there is one aggravating detail worth noting. With storage, the exposure is a stock: the data sits there and could be compelled. With inference, the exposure is a flow, and the interesting artifact is often not the payload but the pattern. A log of what an administration's staff asked, over a year, is a description of what that administration was working on. Even a provider that retains no content retains billing records, and billing records are metadata about volume, timing and department. That is a smaller exposure than content and it is not nothing.

What the gateway genuinely fixes

Against that backdrop, the gateway from the previous article does five specific things, and it is worth being exact about them because the temptation to claim more is strong.

It creates a single egress point, which means the transfer becomes inventoriable. Before, the honest answer to "which providers receive our data" was a guess. After, it is a list, and a list is the precondition for any declaration.

It makes the flow describable. Categories of data, recipients, volumes, per department: all of that is in the ledger you built for cost reasons, and it is exactly the material a reasoned-opinion request needs.

It allows pre-transfer transformation. Masking personal data before the request leaves your infrastructure reduces what actually crosses the border, and this is a real reduction rather than a cosmetic one, subject to a limitation covered below.

It gives you retention control on your side of the line. What you log, for how long, and who can read it become your decisions rather than a vendor default. Choosing to log metadata and not content, as the previous article recommended, is a data protection decision as much as a storage one.

It makes the recipient replaceable. Because callers address internal model names rather than vendor names, changing provider is a configuration change. That matters legally, not just operationally: a company that can move its traffic to a different jurisdiction in an afternoon is in a different negotiating and remediation position than one that would need a six month project.

What it does not fix

The gateway does not change the legal nature of the transfer. The data still leaves, a foreign processor still processes it, and the same jurisdiction still reaches that processor. Routing through your own proxy first is not a transformation, it is a hop. Anyone presenting a gateway as the answer to a residency obligation is selling the AI version of the multi-cloud illusion: a change in topology described as a change in exposure.

It does not resolve the terms you accepted. Retention windows, whether inputs may be used for training, sub-processor chains, and the jurisdictions those sub-processors sit in are all set by contract, and they differ substantially between a consumer tier and an enterprise API agreement with the same vendor. Read the tier you are actually on, not the marketing page of the tier you would like to be on, and re-read it when it changes.

And masking is not anonymization. Detection is statistical: entity recognition misses unusual name forms, local address conventions and identifiers it was never trained on, and West African name and address patterns are exactly the kind of thing a model tuned on European and American data handles least well. Beyond the accuracy question there is a legal one, and it is genuinely open: replacing a name with a placeholder while retaining the rest of a case file is pseudonymization, not anonymization, because the surrounding context often re-identifies the person to anyone holding the source. Masked data is very probably still personal data. The mask reduces the exposure and does not remove the transfer, and any internal communication that blurs those two claims will be quoted back at you.

The residency options, honestly ranked

There are four postures available, and they differ far more in cost than in the slide that describes them.

Public API with contractual safeguards. The default. Cheapest per token, best models, no infrastructure. The transfer is real, the safeguard is contractual, and the declaration burden is entirely yours. For non-sensitive workloads this is a defensible choice made explicitly rather than by accident, and making it explicit is most of the improvement.

Regional endpoint from the same vendor. The data may be processed closer to home and latency improves. Jurisdiction over the parent company is unchanged. This is worth having, and it is worth not overstating: it addresses locality, not reachability.

Model deployed inside your own cloud tenancy. The managed-cloud offerings that run a model inside an account you control narrow the exposure meaningfully, because the weights execute in your tenancy rather than the vendor's service. The cloud provider's own jurisdiction still applies, so this improves the sub-processor story rather than eliminating the foreign-control problem. Cost rises, and it typically rises in the direction of reserved capacity, which changes the FinOps shape from purely variable to partly committed.

Open-weight model self-hosted on infrastructure you control. The only option where no foreign entity processes the data at all. It is also the only one where you own the entire operational burden: GPUs, drivers, serving stack, evaluation, upgrades, and the capability gap between a mid-size open model and the current frontier, which is real and which shrinks and reopens with every release cycle. For a narrow, well-defined task on regulated data, a small open model is frequently sufficient. As a general-purpose assistant for two hundred people, it usually disappoints, and the disappointment sends people back to their personal accounts, which is the outcome the whole exercise exists to prevent.

The pattern that survives contact with reality is not to choose one. It is to route by data class: regulated and sensitive traffic to the self-hosted or tenancy-deployed tier, everything else to the public API, with the routing enforced at the gateway rather than left to the judgment of whoever is typing. This is precisely what per-model access control and internal model naming exist for, and it is the concrete reason the previous article insisted on naming models by role.

Where the economics actually sit

The self-hosting decision is usually presented as a compliance choice with a cost penalty. In the UEMOA context the cost side has three features that change the arithmetic, and none of them appear in analyses written for European companies.

Power and hosting are the first. A sovereign deployment means either a local datacenter with the power and cooling profile that GPUs demand, or bare metal in a facility that has it. This blog has already argued the reference architecture case for sovereign bare-metal Kubernetes; inference workloads make the same argument with more expensive hardware and a harsher tolerance for interruption. Capacity that sits idle overnight is capacity you paid for, which is the opposite of the token model's one genuine virtue.

Currency is the second, and it is the reason the previous article kept every unit cost in dollars. Provider invoices are denominated in dollars. The CFA franc is pegged to the euro at a fixed parity, so the local cost of a dollar-denominated AI bill tracks the euro against the dollar and nothing West African at all. A company reporting AI cost in local currency will see its unit costs move for reasons that have nothing to do with its own consumption, which is why consumption belongs in dollars at the gateway and currency exposure belongs to treasury. Self-hosting converts a dollar-denominated variable cost into a mostly local capital cost, and that is a genuine strategic argument for it that has nothing to do with data protection.

Payment friction is the third and it is the one nobody writes about. Paying American providers from the sub-region means a card that works, ceilings high enough for a bill that scales with usage rather than headcount, and a finance process that can absorb a variable foreign-currency charge without a manual approval each month. Organizations routinely end up with the bill on one person's card, which is an operational risk and an accounting problem before it is a compliance problem. A gateway helps here in a way that is easy to miss: consolidating all provider relationships behind a single set of company-held credentials replaces dozens of individual payment arrangements with a small number of manageable ones.

A decision framework

Route by data class, and enforce the routing at the gateway rather than in a policy document.

The last row deserves a specific warning. Fallbacks are a resilience feature and they are a compliance hazard, because a fallback silently reroutes traffic to a different jurisdiction at exactly the moment nobody is watching. Any model name reserved for regulated data must have no fallback path to a public provider, and that constraint belongs in the router configuration rather than in an operator's memory.

Limits and open questions

The largest open question is the one raised above: whether masked or pseudonymized content still constitutes a transfer of personal data. On the reasoning most data protection regimes apply, it does, because pseudonymized data remains personal data when re-identification is possible for someone. That reading makes the mask a risk reduction and not a legal exemption, which is the conservative position and the one I would build on. It is not settled, and a company relying on masking to avoid a declaration is relying on an interpretation, not a rule.

The second is institutional. The Instance has not, to my knowledge, published doctrine specifically on conversational inference, and neither have most of its regional counterparts. Companies are therefore reasoning by analogy from transfer rules written for datasets. That analogy is the best available and it is still an analogy, and the first published opinion in the sub-region on this question will settle points this article can only argue.

The third is that this analysis stops at the API boundary. It says nothing about AI features embedded in SaaS products the company already uses, where the transfer happens inside a vendor's own infrastructure under a contract signed before anyone considered this question. That surface is larger than the one a gateway controls and it is governed through procurement rather than engineering, which is a different article and, for most organizations, a larger unmeasured exposure than the one they are currently worrying about.

Sources

• Togo, law 2019-014 of 29 October 2019 on the protection of personal data, in particular the regime governing transfers to third countries and the role of the Instance.
• Togo, law 2017-007 on electronic transactions and implementing decree 2018-062; order 2022-040 establishing the cybersecurity rules overseen by the ANCY. Analyzed in detail in Decree 2018-062 and Kubernetes.
• United States, Clarifying Lawful Overseas Use of Data Act (CLOUD Act), 2018, amending the Stored Communications Act. Applied to storage in The Multi-Cloud Illusion for the State.
• Sovereign bare-metal deployment patterns: A Reference Architecture for a Sovereign Government Cloud.
• LiteLLM documentation, Guardrails: PII masking with Presidio, for the pre-transfer masking mechanism discussed here. docs.litellm.ai/docs/proxy/guardrails/pii_masking_v2
• Provider data processing terms, which differ by tier and change over time, and should be read for the specific tier in use.