Nearshore customer support data: who can license tickets and calls

Who controls the records a nearshore support team produces?#

In most setups the client company controls them. If a nearshore team in Mexico, Colombia, Costa Rica or Brazil answers your customers in your Zendesk, Salesforce Service Cloud or Genesys Cloud tenant, the tickets, chats, call recordings and dispositions are your customer records, and the provider handles them on your instructions as a service provider or processor.

That control is the starting point, not the answer. Whether you can license those records to an AI developer depends on four separate things: who controls the records, what your contract with the provider says, what you told the customers in the records, and what any work product written by the provider's staff actually belongs to. De-identification lowers privacy risk but does not settle any of the four.

The operating model changes who you have to talk to. The table shows the four common models and the first question each one raises.

Ownership and permission matrix for nearshore support records#

Use this matrix record type by record type. A single support program produces customer-authored content, agent-authored content, vendor operational data and data about the agents themselves, and each sits under a different control and a different document.

Fill in the last column for your own program before anyone discusses price or scope. Anything you cannot answer from a document is a question for the provider or for counsel, not an assumption.

Which contracts govern reuse of nearshore support data?#

Your master services agreement, statements of work and data processing addendum with the provider govern it, read together with your own customer terms. Pull all of them before scoping any license, including amendments, because support contracts are often renewed with changes to data clauses.

Look for these clauses specifically. Most problems come from a missing IP assignment or a data-return clause that never ran, not from the privacy language.

• 1Ownership of client data: confirms that records created in performing the services are client data, including call recordings and transcripts stored on vendor systems.
• 2Work product and IP assignment: whether macros, knowledge articles, scripts and SOPs written by vendor staff are assigned to you in writing.
• 3Permitted use by the vendor: any right the vendor reserved to use client data for service improvement, analytics or training its own AI tools, which you will want to know about before you license the same records.
• 4Subprocessors and locations: which entities and countries touch the data, including cloud regions and any vendor-side recording or QA tools.
• 5Data return and deletion: whether vendor-held copies were returned or deleted at renewal or exit, and whether you can still obtain a complete export.
• 6Confidentiality: whether the vendor must be told, or must consent, before you disclose materials that include its confidential information, such as its QA rubrics or process documents.
• 7Agent privacy cooperation: whether the vendor will help remove or de-identify agent names, voices and IDs, and on what terms.

Whose data law applies: the team's country or the customer's?#

Both apply, but to different questions. The law that protects your customers, such as the CCPA for California residents or the GDPR for people covered by it, governs whether you may disclose their records for AI training. The law of the team's country mainly governs the provider as a processor and the provider's duties to its own agents.

Latin American laws draw the same processor line that U.S. and EU law draw. Mexico replaced its private-sector data protection law with a new Federal Law on the Protection of Personal Data Held by Private Parties, published on March 20, 2025; it defines a persona encargada as someone who processes personal data on behalf of the responsable, and treats a communication to anyone other than the data subject, the responsable or the encargado as a transfer. Colombia's Law 1581 of 2012 defines the encargado as the party processing on behalf of the responsable, and Decree 1377 of 2013 requires the contract between the responsable and the encargado to set the scope of the processing. Brazil's LGPD defines the operador as the party that processes on behalf of the controlador and requires it to follow the controlador's instructions.

In practice that means a nearshore provider holding your records under one of these laws is acting for you, not licensing on its own account. It also means local law can matter to your license when records were stored or exported locally, when the team itself collected data from local residents, or when agents' own personal data is in the dataset. Colombia, for example, restricts international transfers to countries without an adequate level of protection, with listed exceptions. Have counsel in the relevant country confirm how its rules apply to your specific records.

Who owns the macros, articles and notes nearshore agents write?#

Not automatically you. Under U.S. copyright law, work by a contractor is a work made for hire only if it falls into one of nine listed categories and a written agreement signed by both parties expressly says so; support macros and SOPs often do not fit, so you usually need a written assignment from the provider.

The provider's own rights against its agents depend on its employment contracts and its local law, which is a matter for the provider and its counsel. Your concern is the chain: agent to provider under local law, provider to you under the MSA. If the MSA assigns work product to you, check that it covers knowledge content and not only deliverables named in an SOW.

Free-text internal notes on a ticket are usually treated as part of the client's record, but the same clause should cover them. A buyer will ask for warranties that you have the rights to what you license, so close this gap in writing before an offer, not after.

What about the agents' own personal data?#

Agent data is a separate privacy question, and the provider is usually the party with obligations to the agents. Names, employee IDs, QA scores, coaching notes and recorded voices are personal data about people employed in Mexico, Colombia, Brazil or elsewhere, and their local law and employment terms govern how that data may be used.

The simplest approach is to keep agent-level data out of the licensed scope: replace agent names and IDs with consistent pseudonymous role labels, drop QA scorecards and coaching notes unless the buyer specifically needs them, and treat call audio as containing two voices, the customer's and the agent's. If a buyer needs agent-level signals, such as which responses resolved tickets, agree with the provider how its agents were informed and what it will confirm in writing.

Recording consent is its own check. California, for example, makes it an offense to record a confidential communication without the consent of all parties, and a disclosure that the call is recorded for quality purposes is a separate question from whether the recording can later be licensed for AI training.

How do you define an English-language scope for a nearshore program?#

Define it on the records you would actually offer, not on the team's language or the queue's name. A nearshore team hired for English queues often also runs Spanish or Portuguese queues, writes internal notes in its own language, and handles customers who switch languages inside one conversation.

Start from queue or brand configuration, then confirm at the record level. Help desks usually store a requester language or locale field, and telephony platforms store queue or skill routing, which gives a first cut; a language identification pass over a sample then tells you how many records in the English scope still contain other languages.

Write the rule down. Decide how you will treat English tickets with Spanish internal notes, bilingual conversations and machine-translated replies, and report the share as an estimate with its method until it has been measured on the final offered scope. Do not translate records to enlarge the English set; translated text is a different kind of data from conversations that happened in English.

• 1Scope boundary: brands, queues, channels and date range included.
• 2Language rule: how mixed-language tickets and non-English internal notes are counted or removed.
• 3Measurement: sample size, tool or reviewer, and result with date.
• 4Exclusions: other-language queues, translated replies and any client-of-vendor data that is not yours.

Can the nearshore provider license your support data itself?#

Generally no, not for records it handles as your processor. The CCPA regulations bar a service provider from using personal information collected under its contract except for listed business purposes, and allow internal service improvement only when the provider does not use it to perform services for another person. The GDPR requires a processor to act only on the controller's documented instructions, and the Mexican, Colombian and Brazilian rules above likewise define the processor as acting on behalf of the responsable or controlador.

That is why AI developers approaching BPOs directly end up needing each client's approval, which our guide to sourcing training data through BPOs covers from the buyer side. If you are the client, the useful question is the reverse one: has your provider reserved any right to reuse your data, and has it already done so? The FTC has warned that companies may be liable for using customer data for undisclosed purposes such as model training, and that quietly changing terms to permit it may be unfair or deceptive.

A provider can license what it genuinely owns: its own process documents, aggregate operational statistics that contain no client information, and training material it created independently. Those are its decisions, not yours.

A pre-licensing checklist for nearshore support records#

Work through these steps in order. Each one produces a document or a written answer you can hand to counsel and, later, to a buyer's diligence team.

• 1Map the program: operating model, provider entity, countries, queues, channels, platforms and date range.
• 2Collect the contracts: MSA, SOWs, DPA, amendments, subprocessor list and any EOR or intercompany agreement.
• 3Confirm control: which entity is the controller for the customers in the records, and that the provider is acting as processor.
• 4Close IP gaps: obtain a written assignment for macros, knowledge articles and SOPs written by vendor staff if the MSA does not cover them.
• 5Check customer-facing promises: privacy notices, terms and recording disclosures for every period in the date range.
• 6Locate every copy: your tenant, vendor systems, QA tools and any local exports, and decide which copy you would license from.
• 7Set the agent-data rule: remove or pseudonymize agent names, IDs and scorecards, and decide how agent voices in audio are handled.
• 8Define the English scope and measure it on the offered records.
• 9Ask counsel in the customers' jurisdictions and, where copies sit locally, the team's country to review the specific records and transfers.

How this applies when licensing through SourceX#

SourceX works with U.S., Canadian and EU companies that had 50 or more full-time employees at their peak, contractors excluded. For such a company, a nearshore team is part of how its support records were produced, and the questions above become part of the rights review before anything is released.

The first step is a short company assessment that needs no data uploads. The company approves exactly what is released, once per deal, and de-identification is performed by SourceX directly or through its processing partner. Contract, consent and transfer questions stay with the company and its counsel; de-identification does not by itself create a right to license.

SourceX can consider companies in Latin America when the data they offer is at least 90% English, confirmed on the actual dataset; every dataset still goes through rights, privacy, quality and buyer-fit review.