Quick answerGet explicit, specific consent before an AI agent shares a customer's data across separate products or business units, even though all of them belong to the same company. Customers form a mental model of who has their information based on which product they signed up for, and a shared backend does not automatically extend that trust. At minimum, disclose which business units can see the data, what they will use it for, and give the customer a real choice, not a buried clause in a general terms of service update.
Why "we are one company" is not sufficient disclosure
A customer who signs up for one product from your company has a specific mental model of what they agreed to: this product, these features, this level of visibility into their activity. When an AI agent starts pulling that customer's history into a different product or business unit under the same corporate umbrella, the company's internal org chart is not the customer's frame of reference. They did not consent to the business unit, they consented to the product.
This matters more with an AI agent than it did with a human support team, because an agent can act on shared data instantly and at scale, surfacing something from one product inside a conversation happening in a completely different one. A human agent working across departments would likely pause and ask before doing that. An AI agent will not pause unless you have built the pause in.
What "specific" consent actually looks like
Vague consent buried in a broad terms of service update does not meet the bar, both practically and often legally, depending on your regulatory footprint. Specific consent means:
Naming the business units or products involved. "We may share information across our family of products" is not specific. "Your support history from Product A may be visible to our Product B agent if you use both" is specific.
Explaining what will actually happen with the shared data, not just that sharing occurs. Will it be used to personalize recommendations, resolve a support ticket faster, or something else? Customers evaluate the tradeoff differently depending on the purpose.
Giving a real choice. If a customer declines, what happens? The agent should degrade gracefully, for example not referencing the other product, rather than the feature becoming unusable for anyone who opts out.
Timing the ask close to the moment it becomes relevant, not only at initial signup for the first product, since a customer who joins a second business unit later is a distinct moment where the sharing decision actually starts mattering.
From the team
We build production AI systems for startups.
LLM pipelines, RAG, and agent workflows that hold up under real traffic — not just in the demo.
How this differs from safeguards you use with outside partners
If you have already built the safeguards described in Safeguards Before an AI Agent Touches a Partner's Data, it is tempting to assume internal business units are a lower bar because there is no separate company on the other end of the exchange. The opposite is often true from the customer's perspective: a genuinely external partner integration is usually disclosed explicitly because it is a distinct product decision, while internal sharing between your own business units can happen silently through shared infrastructure with no customer facing disclosure event at all. The absence of an obvious integration point is exactly why it needs a deliberate consent step, not an assumed one.
This is also a different question from how you structure the organization that builds and governs your agents. Build-Once vs. Per-Unit: The AI Center of Excellence Operating Model is about whether one team builds AI agent capability for the whole company or each business unit builds its own. You can centralize the engineering and still keep customer data segmented by consent; the org chart for who builds the agent and the data boundary for what the agent can see are independent decisions.
Building the technical boundary to match the consent boundary
Consent that exists on paper but is not enforced in the system is a liability, not a safeguard. Once you have defined which sharing is permitted, the technical implementation should include:
- A consent flag tied to the specific data category and business unit pairing, not a single global opt-in, since a customer might reasonably consent to one combination and not another.
- Enforcement at the data access layer, not just in the agent's prompt instructions, so a misconfigured or updated prompt cannot silently start pulling data the customer never agreed to share. This is the same class of control described in AI Agent Security Guardrails for Customer Data, applied specifically to the internal boundary between your own products.
- An audit log of cross-unit data access, so if a customer asks what was shared and when, you have a real answer rather than a reconstruction.
- A path to revoke consent that actually removes the sharing going forward, tested the same way you would test any other customer rights request.
FAQ
Do we need separate consent for every possible business unit combination? You need consent granular enough that a customer can meaningfully understand what they are agreeing to. If your business units serve very different purposes, treat each pairing as its own disclosure. If they are close variants of the same core product, a single clear disclosure covering the family may be sufficient, but confirm that against your specific regulatory obligations.
What if the business units share the same underlying database already? Shared infrastructure does not substitute for consent. The technical ease of sharing data is unrelated to whether the customer agreed to it, and a shared database actually raises the stakes, since it removes the natural friction that used to make cross-unit sharing a deliberate, visible act.
Who should own this decision internally? Whoever owns the specific product relationship with the customer should be involved before any cross-unit sharing is enabled, alongside legal or privacy review, since a decision that looks like a technical integration choice is actually a customer trust decision.