AI Agents for Multinational Companies: Entities, Languages, Rules

AI agents work for multinational companies when the group treats each legal entity as its own boundary for data, permissions and approvals, and shares only what is safe to share: the agent's design, its evaluation method and its operating routines. Languages, local data rules and approval chains are configured per entity, not improvised in each conversation. The result is one governed pattern that can run in many places without mixing what must stay apart.

Key takeaways

• Treat every legal entity as a boundary for data, credentials and approvals. Share the design and the method, not the information.
• Decide in advance what is shared across the group and what stays local. A simple test: if a mistake would expose one entity's data to another, keep it local.
• Language is more than translation. Test each agent in each working language, using terminology and examples written by people who work in that language.
• Local data rules, including employment, privacy and sector rules, must be checked with qualified advisers in each country before an agent touches the data.
• Separate approvals for what an agent may do from approvals for changing the agent. Give each a named owner and a deputy in every entity.

Why does a group with several entities need a different approach?

A single company with one office can describe an agent's job in a paragraph and hand it a set of folders. A group cannot. The same request, such as summarizing supplier contracts or answering a customer about a delivery, touches different employers, different contracts, different regulators and different languages depending on where it comes from.

Three problems appear when a group copies a single-company setup across units.

• Data crosses boundaries by convenience. A shared knowledge base is easy to build, and it quietly lets staff in one entity retrieve documents that belong to another.
• One approval chain is applied everywhere. Either it is too slow for local teams, who then work around it, or it is too loose for the entity with the strictest obligations.
• The agent speaks the head office's language and follows the head office's habits. Local staff try it twice and go back to their old tools.

None of these is a model problem. They are design problems about boundaries, ownership and context, and they are solved before the first agent goes live. This article is general guidance for planning, not legal advice. Your counsel in each country decides what is permitted.

What should be shared across entities and what should stay local?

The most useful decision a group makes is where the line sits between the common pattern and the local instance. A pattern is cheap to share and expensive to rebuild. An instance holds the data and the authority, so it should be kept close to the entity that owns them.

Use this decision guide for each element of an agent.

• Share: the role definition (what the agent is for, what it never does), the evaluation method, the log format, the change process and the naming of settings. These make the group's agents comparable and easier to review.
• Share with care: model and provider choices. A common provider simplifies operations, but some entities may need a different region or a different contract. Keep the option open (see how to avoid vendor lock-in if you want to preserve it).
• Keep local: knowledge sources, customer and employee records, credentials for each system, retention periods and the names of people who approve actions.
• Keep local by default: memory. What an agent remembers about a person, a customer or a negotiation belongs to the entity where it was learned, unless someone with authority decides otherwise.
• Decide case by case: shared prompts or instructions that contain policy. If the policy differs by country, the instruction should too.

Write the result down as a short table in prose or a list your leaders can read in a few minutes. If you have not yet drawn your stack, the one-page architecture map is a good place to mark which layers are common and which are per entity.

How do languages change the design?

Language shows up in four places, and each needs a deliberate choice.

• The language the user writes in. People should be able to ask in the language they think in.
• The language of the source documents. A Portuguese contract and an English policy may both inform one answer, and the agent should say which source it used.
• The language of the output. Drafts for internal use can be flexible. Anything that reaches a customer, a regulator or a counterparty should follow the entity's own reviewed wording.
• The language of escalation. If the agent hands a case to a human, that human needs to read and answer in the case's language.

Terminology matters more than grammar. Job titles, product names, legal forms and department names often have no clean equivalent between countries. Keep a short glossary per entity and give it to the agent as part of its context. It is also worth stating which language version of a policy governs when two versions differ, because the agent cannot decide that for you.

Testing must be done per language. A set of example questions written by native speakers, with the answers the entity expects, will reveal problems that a translated test set hides: a formal tone that sounds cold, a date format that causes errors, an abbreviation that means something else locally.

Which data rules shape where an agent can run?

Data rules are the part of a multinational deployment that most often changes the architecture. They vary by country, by type of data and by sector, and they change over time, so do not hardcode assumptions into the design. Ask for a written answer from qualified advisers on questions like these.

• Where may this entity's data be stored and processed, and can it be sent to a model provider in another region?
• Which records need special handling, such as employee files, health information or financial data?
• Does any planned use fall into a category that carries extra obligations? The [EU AI Act overview](https://artificialintelligenceact.eu/) describes a risk-based approach where some uses, for example in employment decisions, are treated more strictly than others.
• Which authority oversees data protection in each country? For Brazil, that is the [ANPD](https://www.gov.br/anpd/pt-br), and each country you operate in has its own.

Once the answers are written, translate them into technical controls. Keep a separate knowledge store per entity, or enforce entity filters on every retrieval. Issue credentials that are scoped to one entity so that an agent working for one unit cannot reach another's systems. Apply the principle in the [OWASP authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html): check permissions on every request, on the server side, and grant the least access needed. Store logs where the entity's rules require them. For a deeper look at the storage question, read AI data residency for business.

How should approvals work across entities?

Groups usually blur two different kinds of approval. Separating them removes most of the friction.

The first is approval of actions: the agent wants to send a message to a customer, update a record, or prepare a payment instruction. These approvals belong to the entity, because the entity carries the legal and commercial responsibility. Define which actions the agent may take alone, which need a human to confirm, and which it may never take. Name an approver and a deputy in each entity, so holidays and time zones do not stall work or push people to approve blindly.

The second is approval of changes to the agent: new tools, new knowledge sources, new instructions, new permissions. Changes to the shared pattern need a group owner who sees the effect on every entity. Changes to local settings need the local owner. A change that affects both should be raised once and reviewed by both. The process in how to request and approve changes to a managed AI agent fits this split well.

Review permissions on a schedule, since people move between entities and roles change. The permission review steps work as a recurring routine for each entity, with the group owner looking at the results side by side.

What does a step-by-step plan look like for the first entities?

Start small and keep the pattern repeatable. This plan assumes a group that wants one useful role in a few units.

• Step 1: Choose one role with a clear, observable outcome, such as answering internal policy questions or preparing standard supplier correspondence.
• Step 2: List the entities that will use it and record, for each, the legal entity name, the data owner, the approver, the deputy and the working languages.
• Step 3: Get written guidance from advisers on data location, special categories of data and any extra obligations for this use.
• Step 4: Draw the shared and local line using the decision guide above, and record it.
• Step 5: Build the instance for one entity first, with its own knowledge, credentials, glossary and approval rules.
• Step 6: Test in the local language with questions written by local staff, and include cases where the agent should refuse or escalate. The success criteria guide helps define what passing means.
• Step 7: Run the pilot with a small group, review the logs with the local owner, and fix what the logs show.
• Step 8: Copy the pattern, not the data, to the next entity. Repeat steps 2 to 7, and record what differed.

Illustrative scenario: a group has a holding company, a services subsidiary in one country and a manufacturing subsidiary in another. The first role is an internal policy assistant. The group owner writes one role definition and one evaluation method. Each subsidiary gets its own knowledge store, its own glossary and its own approver. When the manufacturing subsidiary asks to add a maintenance manual source, that request goes to its local owner. When the group wants to change the refusal wording for every instance, it goes to the group owner, who checks it with each local owner. Nothing in either subsidiary's store is visible to the other.

When the first two entities run well, the approach in how to scale AI agents across a company covers adding units without losing control.

How does a managed approach handle this?

Be Human designs one role at a time, with the memory, tools, permissions and approval boundaries it needs, and sets up each legal entity as a separate instance under a shared pattern. The client's people keep control of approvals, access and data decisions, and each entity names its own owners. Managed operations can then include monitoring, recurring evaluations in each working language, integration maintenance, permission reviews, incident response and controlled improvements, delivered remotely in English and Portuguese. The group sees comparable reports across entities, and each entity sees only its own records.

Frequently asked questions

Do we need a separate agent for every country? Usually you need a separate instance, not a separate design. Each entity gets its own data, credentials, glossary and approvers, while the role definition and evaluation method stay common. If two entities share the same legal and data situation, your advisers may allow a shared instance, but start separate and merge later only if it is justified.

Can one agent answer in several languages? Yes, many models handle several languages, but quality varies by language and by topic. Test each language with questions written by people who use it at work, and set the rule for which language version of a policy governs. Where output reaches customers or regulators, have a local person review the wording before it is used.

Who should own the agents, the group or the local entities? Split ownership by what is being decided. The group owns the shared design, the evaluation method and the change process. Each entity owns its data, its action approvals and its local settings. Writing this down in a short operating model avoids disputes later, and the AI operating model guide shows one way to do it.

How do regulations such as the EU AI Act affect this? They can affect which uses are allowed and what documentation or oversight is needed, depending on the use and on where its outputs are applied. Classify each planned use, ask counsel in each relevant country, and record the answer next to the role definition. Frameworks such as the [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) can help structure that record, though they do not replace legal advice.

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