Hiring an Overseas AI Provider: Contract, Currency and Courts

To hire an overseas AI provider safely, settle four things in the contract before any work starts: which country's law governs, how disputes are resolved, which currency you pay in and who carries tax and exchange differences, and where your data is stored and processed. Everything else is ordinary vendor diligence. Distance does not make the deal riskier by itself, but it makes vague drafting much more expensive to repair later.

Key takeaways

• Choose governing law and a dispute method deliberately, and check that a ruling can actually be enforced where the provider holds its assets.
• Fix the payment currency, the exchange rate reference and the invoice timing in writing, so a currency move never changes the deal silently.
• Ask your accountant about withholding, indirect taxes and permanent establishment before signing, then record who bears each tax in the contract.
• Treat data terms as the core of the agreement: location, subprocessors, training use, deletion and breach notice.
• Write the exit in advance: what you take with you, what the provider deletes, and how access ends.

Why does hiring abroad change the contract?

With a provider in your own country, many questions are answered by default. You share courts, a currency, a tax system and a data protection regime. When the provider sits abroad, each of those defaults becomes a decision that must appear on paper, or it will be decided for you later by whoever has more leverage.

An AI provider raises the stakes beyond a typical software purchase. The agent they build and operate holds access to your systems, carries memory about your business and may act on your channels. So the contract is not only about a deliverable. It governs an ongoing relationship with access to sensitive material, run by people in another jurisdiction and often in another time zone (see working with a remote AI provider across time zones for the operating side of that).

This article is a business guide, not legal advice. The points below are the questions to bring to a lawyer who knows both jurisdictions, so the conversation is short and specific.

Which law and which court should govern the agreement?

Three separate choices hide inside one clause. Governing law decides what the words of the contract mean. The forum decides where a dispute is heard. Enforcement decides whether a result can be turned into money or action. Owners often negotiate the first two and forget the third.

A judgment from your home court is only useful if it can be enforced where the provider has assets or operations. If the provider has no presence in your country, a favorable ruling at home may be hard to use. Arbitration is often preferred for cross-border services because arbitral awards are generally easier to recognize abroad than court judgments, though this depends on the countries involved and should be confirmed by counsel.

Use this decision guide as a starting point:

• Your law and your courts: easiest for you to read and manage, but you may struggle to enforce against a provider with no local assets.
• The provider's law and courts: easiest for them, and usually slow and costly for you. Accept only if the relationship is small and the data exposure is low.
• A neutral law with arbitration in a neutral seat: balanced and often practical for larger engagements, with the cost of agreeing a seat, language and rules.
• Your law for data and confidentiality, arbitration for commercial disputes: a split that some parties use when data protection rules are mandatory in one country.

Two details deserve attention. First, state the language of the contract and of any proceedings, since a translated version should never be the one that controls by accident. Second, name a notice address and a person who can receive formal letters. Some rules cannot be contracted away, especially data protection duties, so your choice of law does not remove local obligations for either side.

How should payment currency be handled?

Currency looks like an accounting detail until it moves. A contract that says only that fees are payable monthly leaves open which currency, which rate, which day and who pays bank charges. Each blank is a future argument.

Settle these points in writing:

• The currency of the fees, and whether usage costs passed through from model vendors follow the same currency.
• The exchange rate source and date, if conversion is needed: the invoice date, the payment date or a published reference rate.
• Who pays transfer and intermediary bank fees, so the provider receives the invoiced amount in full or an agreed net.
• Payment terms, late payment treatment and how disputed invoice lines are handled without freezing the undisputed ones.
• A review trigger, if the currency moves far enough to distort the economics for either party.

Illustrative scenario: a company in one country hires a provider in another, and the contract says fees are invoiced in the provider's currency each month. Midway through the year the company's own currency weakens against it. Nothing about the work has changed, yet the monthly cost to the company rises and the finance team did not budget for it. If the contract had fixed the currency, named a rate reference and set a review trigger, the change would have been a planned conversation rather than a surprise. For the commercial structures themselves, see AI agent pricing models explained.

Also decide how a spending ceiling works when costs vary with usage. A limit expressed in one currency, with alerts, keeps the commitment visible to the person who owns the budget.

What tax questions should you raise before signing?

Tax treatment of cross-border services differs widely, and the contract cannot settle it alone. What the contract can do is state who is responsible for what, and oblige both parties to cooperate. Bring these questions to your accountant before signature, not after the first invoice:

• Does your country require withholding on payments for services performed abroad, and does a tax treaty change that?
• How are indirect taxes such as VAT or similar charges handled on a foreign invoice, including any reverse charge mechanism?
• Does the invoice need specific fields or a tax identifier to be deductible or accepted by your authorities?
• Could the provider's staff, working for you, create a taxable presence in your country, or could your own presence create one in theirs?
• Who bears a tax that is later assessed, and does the contract include a gross-up if withholding reduces what the provider receives?

The contract should say that each party bears its own income taxes, that the paying party applies withholding where the law requires it, and that both provide the documents needed to claim relief. Vague language such as all fees are inclusive of taxes can become a dispute when a tax is unexpectedly due. Precision is cheaper than a later amendment.

What data terms matter when the provider is abroad?

Data terms are where an overseas arrangement most often carries real risk, because the agent works with your information every day. Start with where data is stored and processed, which includes the infrastructure of the model vendors the provider uses. The detail matters, and AI data residency for business explains how to ask for it.

Then cover the following in the agreement:

• A list of subprocessors and model vendors, with a duty to notify you before a change and a right to object.
• A clear statement on training: whether your data may be used to train or improve any model. Get this in writing, as described in does your AI provider train on your company data.
• The legal basis for moving personal data across borders, aligned with the rules that apply to you. In Brazil, the data protection authority ([ANPD](https://www.gov.br/anpd/pt-br)) publishes guidance. In Europe, the [EU AI Act](https://artificialintelligenceact.eu/) may also apply if the agent is used there, so ask the provider how they classify the use case.
• Breach notification within a defined window, to a named contact, with the information you need to meet your own duties.
• A process for government or third-party access requests, including a duty to tell you unless the law forbids it.
• Deletion on exit, with written confirmation, plus the handling of backups.
• Ownership of what the work produces: configuration, prompts, memory and documentation. The point is practical, because without it moving to another provider becomes difficult. How to avoid AI vendor lock-in with business agents covers this in depth.

A risk framework helps structure the conversation. The [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) gives a neutral vocabulary for governance, mapping and measurement that both sides can refer to in the agreement's schedules.

A step-by-step plan before you sign

Use this sequence to move from a promising proposal to a contract you can operate under:

• Step one: define the role, the systems it touches and the approval boundaries in a statement of work, following AI agent statement of work, section by section.
• Step two: ask the provider for its legal entity, its address, the countries where its people and infrastructure sit, and its list of subprocessors.
• Step three: decide your preferred governing law and dispute method, and ask counsel whether the result would be enforceable against this specific provider.
• Step four: agree currency, rate reference, invoice timing, fees and a ceiling for variable costs.
• Step five: take the tax questions to your accountant and write the answers into the payment clause.
• Step six: attach the data terms as a schedule, covering location, subprocessors, training, breach notice and deletion.
• Step seven: write the exit: what you receive, in what format, within what time, and how the provider's access is removed.
• Step eight: name the people on each side who approve changes and receive notices, and record the review dates.

If any step meets resistance, note it. How a provider answers a clear contractual question is useful evidence of how they will behave during an incident.

How does a managed approach handle this?

Be Human is a brand operated by Hive Technology and works remotely, in English and Portuguese. A first engagement defines one useful role, the memory and tools it needs, approval boundaries and an observable success criterion, and these are written down before operation begins. Access to your systems is granted through permissions you control and can review, and changes follow an agreed approval path rather than informal requests. The same discipline applies to the commercial terms: the scope, the data handling and the exit are documented so that your team can see what the agent can reach and what happens to its memory and configuration if the relationship ends. Specific legal terms such as governing law and currency are agreed per engagement with your own counsel.

Frequently asked questions

Should I always insist on my own country's law? Not always. Your law is easier for you to read, but a favorable ruling is only valuable if it can be enforced against the provider. For larger engagements, a neutral law with arbitration is common, and counsel in both countries can tell you which route works in practice.

Can I pay in my own currency? Often yes, and it is worth asking, since it moves exchange risk to the provider. Expect them to price that risk in, or to propose a rate reference and review trigger instead. Either approach works if it is written down.

Do I need the provider to have a local entity? It is not required, but it can simplify invoicing, tax treatment and enforcement. If the provider has no local entity, give more weight to the dispute method, the data schedule and the exit terms, since they become your main protection.

What happens to the agent if the contract ends or a dispute begins? That depends on what you wrote. Agree in advance what you receive, in what format and how access is removed, so work can continue or pause without argument. For a controlled wind-down, see how to stop an AI pilot without wasting the work already done.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.