Hiring a nearshore AI team: contracts, IP and security checklist

Before you hire a nearshore AI team, get written answers to five questions: who owns the code and when, where the code and data live, who can access what, what happens to your data and models, and what the exit looks like. This checklist covers contracts, intellectual property and security, with the exact wording to ask for and the red flags to watch for. It applies to any vendor, including us.

We contract with US companies through Cloudsoft Industries LLC, a Delaware company with an engineering studio in Colombia, so we answer these questions regularly. Treat this article as a buyer's tool. It is not legal advice, and your counsel should review any agreement before you sign.

1. The contracting entity and currency

Start with who you are actually signing with. A vendor that cannot tell you the legal name of the contracting entity, its jurisdiction and the invoicing currency is asking you to take a lot on trust.

• Legal entity. Ask for the exact legal name and jurisdiction on the contract. Ours is Cloudsoft Industries LLC, a Delaware limited liability company.
• Currency. Prefer contracts and invoices in USD so you carry no exchange-rate risk. Contracts and invoicing in USD through Cloudsoft Industries LLC (Delaware).
• Governing law and dispute venue. Have counsel agree these explicitly. Silence tends to lead to expensive arguments about where a dispute is heard.
• Subcontracting. Ask whether the people on the call are the people doing the work, and whether any work is passed to third parties. Require written approval for subcontractors who touch your code or data.

2. Code and IP ownership

This is the clause with the most downstream consequences. Ownership that is vague at signing becomes a negotiation when you want to raise money, sell the company or switch vendors.

• Assignment. The contract should assign work product to you, not just license it. Look for the words "assigns" and "work made for hire" or their equivalents.
• Timing. Ask when ownership transfers. Our terms: clients own 100% of the code and IP once each milestone is paid, so ownership accrues as you pay and is not held back to the end.
• Pre-existing tools. Vendors often bring their own libraries or frameworks. Ask for a list, and for a perpetual licence to anything embedded in your product.
• Open-source components. Ask for a bill of materials with licences, so you know whether anything in the code carries obligations.
• Employee and contractor assignments. Confirm that the vendor's own staff have assigned their rights to the vendor. If they have not, the vendor cannot assign to you.

3. Repositories and environments

The simplest way to protect ownership is to keep the work where you control it. Code lives in the client's repositories from day one. That means the vendor works inside your GitHub, GitLab or Azure DevOps organization, and your cloud accounts host the environments.

• Repositories created under your organization on day one, not exported at the end.
• Cloud accounts owned by you, with the vendor invited under least-privilege roles.
• Infrastructure defined as code, committed to your repositories, so a new team can recreate it.
• Documentation as a deliverable: architecture notes, runbooks and how to run the system locally.

If a vendor insists on keeping code in their repositories "for convenience", ask what happens if the relationship ends. Convenient for them is not the same as convenient for you.

4. Security practices

Security questions for an AI project are mostly the same as for any software project, plus a few extra around data and models. Ask for specifics and be wary of generic answers.

• Access control. Least-privilege access, single sign-on where possible, access removed when someone leaves the project.
• Secrets. Credentials stored in a managed secrets vault, never in code or chat.
• Environments. Separate development, staging and production, with real customer data kept out of development.
• Devices. Ask how vendor laptops are managed, whether disks are encrypted and what happens if one is lost.
• Incident handling. Ask how quickly you would hear about a security event, and from whom.
• Reviews. Ask whether code is peer-reviewed before merge and how dependencies are monitored for known vulnerabilities.

On certifications, we do not claim any. If your procurement process requires a SOC 2 report or ISO 27001 attestation from vendors, say so in the first call so neither side wastes time. We would rather lose a bid honestly than imply a badge we do not hold. Our practices are described on the trust page.

5. AI-specific questions

AI projects add risks that older checklists miss. These questions are worth adding to your vendor review:

• Training on your data. Confirm in writing that your data is not used to train models. Our position: no training models on client data.
• Model providers. Which model APIs will the system call, under whose account, and what are the provider's data-retention terms?
• Where data lives. Which cloud region, who can read it and how long is it retained?
• Evaluation. How will quality be measured before launch? We write evals as acceptance criteria, using real examples from your business.
• Human handoff. For agents that talk to customers, what happens when the system is unsure?
• Prompt and tool ownership. Prompts, evaluation sets and tool definitions are part of the work product. They should be assigned to you and live in your repositories.

For how these apply to specific builds, see AI agent development and AI integration and RAG.

6. Confidentiality

A mutual NDA should be signed before detailed discussions begin. Mutual NDA available. Check that the NDA covers employees and approved subcontractors, survives the end of the contract and defines what happens to confidential material when the engagement ends, such as return or deletion on request.

7. Exit and continuity

A good contract is easy to leave. This is the part buyers skip and later regret.

• Termination for convenience with a short notice period, and a clear process for handing over work in progress.
• Documentation and a knowledge-transfer session included in the scope.
• Ownership of everything paid for, regardless of who ends the contract.
• A named replacement process if a key engineer leaves.

Red flags and what good looks like

Topic	Red flag	What good looks like
IP	Licence only, or ownership transfers "at project completion"	Assignment of work product, with ownership tied to payment per milestone
Code location	Code in vendor repositories, exported at the end	Code in your repositories from day one
Access	Shared admin accounts or credentials in chat	Named users, least privilege, secrets in a vault
Certifications	Badges with no report or scope you can inspect	Honest statement of what is and is not held
AI data	No answer on training or retention	Written commitment that client data is not used for training
Exit	Long lock-in with no handover obligation	Short notice and documented handover
Staffing	Different people than the sales team, undisclosed subcontractors	Named team, approved subcontractors

The one-page version

1. Legal entity, jurisdiction and currency are written in the contract.
2. Work product is assigned to you, with timing tied to payment.
3. Repositories and cloud accounts belong to you from the first commit.
4. Access is least-privilege, and secrets are in a managed vault.
5. Your data is not used for training and its location and retention are documented.
6. A mutual NDA is signed before detailed discussions.
7. Exit terms and handover are written down.

Frequently asked questions

Do we need a vendor with a SOC 2 report?

It depends on your own obligations. If your customers or auditors require it, you do. If they do not, practices such as least-privilege access, secrets management and code in your repositories do more to protect you than a badge you cannot inspect. We do not claim any certification, and we will say so in the first call.

Who owns the code if we stop mid-project?

Under our terms, clients own 100% of the code and IP once each milestone is paid, and the code is in your repositories already. Whatever you have paid for is yours, and there is nothing to extract.

Can a foreign team work with US customer data?

It can, depending on the data and your contractual and regulatory obligations. Some regulated work requires US-only handling, and in that case a nearshore team is the wrong choice. Raise this before any discussion of price.

What should a nearshore AI contract include that a regular software contract does not?

Terms on model providers, data retention, training on your data, evaluation criteria and ownership of prompts and evaluation sets. These are the parts of AI work that older templates do not cover.

How do we start safely?

Sign a mutual NDA, run a small paid discovery and review the contract for the full build once the scope is clear. Our AI Readiness Sprint starts at $4,500 and is built for this.

For the broader context on working with a Colombian studio, see nearshore software development in Colombia. If you want us to walk through this checklist against your own project, book a scoping call.