Outsourcing contract checklist for software and AI work

Scope and acceptance

• Identify deliverables, milestones, dependencies, buyer responsibilities, and exclusions.
• Define objective acceptance evidence, review time, rejection process, and remediation.
• State what happens when the buyer delays access or a third-party dependency changes.
• Use a written change process with schedule and price impact.

Commercial terms

• Reconcile currencies, taxes, expenses, deposits, milestone payments, and recurring charges.
• Tie payment to a defined period or accepted deliverable; avoid unclear “completion” triggers.
• Define rate changes, invoice disputes, late payment, and audit evidence where relevant.
• Document whether tools, cloud usage, models, travel, and licenses are included.

Intellectual property and confidentiality

• Separate pre-existing materials, third-party components, open-source software, and newly created deliverables.
• State ownership or license scope for code, documentation, designs, data transformations, prompts, model artifacts, and evaluations.
• Require compatible contributor and subcontractor obligations.
• Define permitted portfolio use and publicity; do not assume silence prevents a case study.

Data and security

• Describe authorized data, purposes, locations, subprocessors, transfers, retention, deletion, and return.
• Set access controls, logging, vulnerability handling, incident notification, and cooperation duties.
• Attach any required processing or transfer terms and verify they fit the actual data flow.

People, continuity, and exit

• Name key roles, substitution approval, working hours, subcontracting, and non-solicitation if appropriate and enforceable.
• Define termination rights, notice, work-in-progress treatment, refunds or final charges, and transition support.
• Require current documentation, repository access, credentials rotation, data return/deletion evidence, and knowledge transfer.

The source-code and IP guide adds technical controls that a contract alone cannot provide.

Parties, authority, and document hierarchy

• Confirm the legal names, addresses, registration details, signing authority, and notice contacts.
• Identify affiliates, staffing entities, subcontractors, and individuals that may perform or receive work.
• State which document controls when the master agreement, statement of work, proposal, security schedule, data terms, and purchase order conflict.
• Prevent sales materials or online terms from silently changing the negotiated allocation.
• Define the language of control and whether electronic signatures and notices are permitted.

Delivery model and governance

Describe whether the supplier provides staff augmentation, a managed project, or a hybrid. Allocate product decisions, backlog, architecture, coordination, quality, security, dependencies, release, acceptance, and incident roles.

Name governance meetings only where they support decisions. Define required reports, escalation contacts, response expectations, decision deadlines, and the record that captures approved changes. A steering committee is not useful if no one can resolve a blocked dependency.

Detailed scope and assumptions

• Attach deliverables, boundaries, environments, integrations, data, volumes, service hours, and required documentation.
• List buyer inputs, access, decisions, and dependencies with owners and dates.
• Maintain an assumptions register and state what happens when an assumption is wrong.
• Separate required, optional, and out-of-scope work.
• Define third-party products and who selects, contracts, pays, and accepts their terms.

Avoid incorporating a marketing proposal without reconciling its disclaimers and vague phrases. Terms such as “industry standard,” “production ready,” or “best effort” need observable meaning in context.

Acceptance and remediation

For each milestone, state the evidence, review period, approver, rejection content, remediation period, retest, and outcome if failure continues. Address partial acceptance and minor defects without forcing the buyer to reject an otherwise useful delivery.

Acceptance by silence can be risky when the buyer needs time or specialized review. If the parties use it, choose a realistic period and preserve the right to address hidden defects, security issues, warranty claims, and obligations that cannot be verified during ordinary review.

Changes, delay, and suspension

Define who may request and approve change, the required impact analysis, and how price, timing, resources, risks, and acceptance change. Distinguish a scope change from correction of nonconforming work.

Allocate delay by cause. Require notice, mitigation, updated forecast, and evidence. Address buyer delay, provider delay, third-party dependency, force majeure, and accumulated effects. Limit suspension rights so access, data, security, and continuity are not placed at unnecessary risk during a payment dispute.

Pricing, invoicing, and audit evidence

• State rates or prices, currency, taxes, exchange treatment, expenses, deposits, minimums, and rate-review rules.
• Define time-record requirements where relevant without making activity the acceptance standard.
• Tie milestones to observable delivery evidence.
• Establish invoice timing, detail, dispute window, undisputed payment, credits, and setoff where appropriate.
• Identify recurring cloud, model, license, platform, and support charges.
• Address records needed to verify charges and how long they remain available.

Intellectual property and third-party materials

With counsel, define background materials, project-created deliverables, inventions, feedback, data, documentation, designs, prompts, evaluation assets, configuration, and model-related artifacts. State whether rights transfer by assignment, license, or another permitted mechanism, and when that takes effect.

Require a schedule of third-party and open-source components, applicable licenses, source, versions, modifications, and obligations. The supplier cannot grant rights it does not hold. Address moral rights, contributor agreements, portfolio use, publicity, and buyer trademarks as applicable.

Confidentiality, privacy, and data

Define confidential information, permitted use, recipients, protection, exclusions, compelled disclosure, return or deletion, and survival. Do not make confidentiality so broad that it conflicts with required legal reporting or the buyer’s ability to use deliverables.

Attach data terms that reflect the real flow: roles, purposes, categories, subjects, locations, subprocessors, security, transfer mechanism if required, assistance, retention, deletion, audit evidence, and incident notification. Avoid naming a legal mechanism without checking that it applies to the parties and transfer.

Security and software supply chain

Select requirements from the actual threat model. Address identity, least privilege, multi-factor authentication, secrets, buyer-controlled environments, secure development, review, testing, dependencies, provenance, vulnerability handling, logging, incident response, backups, and offboarding.

Define notification content and cooperation rather than relying only on a clock. Preserve evidence, coordinate communications, identify remediation ownership, and address costs according to cause and contract allocation.

Personnel and subcontractors

• Name key roles, allocation, work location, overlap, start, and substitution process.
• Require notice and equivalent evidence for replacements.
• State screening or training only where lawful and relevant.
• Flow confidentiality, IP, data, and security duties to every approved contributor.
• Require approval or notice for material subcontractors and location changes.
• Review non-solicitation, non-compete, and worker-control provisions for applicability and enforceability.

Warranties, indemnities, and liability

Align promises with controllable behavior: authority to contract, conformity to specifications, professional performance, malicious code, rights in deliverables, legal compliance allocated to the relevant party, and remediation. Avoid broad AI or software guarantees that no provider can measure or control.

Review indemnity triggers, control of defense, settlement, cooperation, exclusions, and interaction with insurance. Make liability caps, carve-outs, excluded damages, credits, and exclusive remedies fit the plausible losses and bargaining context. This requires qualified legal advice; a checklist cannot choose the numbers.

Term, termination, and exit

Cover initial term, renewal, notice, termination for cause, cure, insolvency, convenience if negotiated, and consequences. Define payment for accepted work, treatment of work in progress, refunds or credits, and continuing obligations.

Attach an exit schedule: current source and artifacts, data export, documentation, account transfer, identity and credential revocation, secret rotation, deletion evidence, open-risk register, knowledge transfer, transition assistance, rate, duration, and cooperation with a replacement supplier. Test the practical handover before termination.

Disputes and governing terms

Choose governing law, forum, escalation, mediation, arbitration, litigation, interim relief, fees, confidentiality, and service of process with counsel. WIPO publishes model dispute-resolution clauses, but the parties must select a mechanism suited to the jurisdictions and engagement.

Address assignment, change of control, notices, waiver, severability, entire agreement, amendments, relationship of parties, compliance responsibilities, and survival. Do not copy provisions without understanding their interaction.

Attach operational schedules that teams can use

The main agreement should allocate legal and commercial risk; operational schedules should make those promises executable. Depending on the service, attach a responsibility matrix, acceptance plan, security schedule, data-flow record, subprocessor list, service levels, incident plan, business-continuity requirements, asset register, and exit checklist.

Give each schedule an owner, approval method, effective date, review cadence, and controlled change process. Distinguish a routine operational update from a contractual change that requires authorized signatures. Preserve prior versions so the parties can determine which obligation applied to an event or deliverable.

Reconcile the schedules against reality before signature. The named repository, environment, model provider, data location, support window, and subcontractors should match the proposed architecture and team. A polished schedule that describes a different service can create false assurance.

Cover AI systems and supplier tools explicitly

If the work uses AI, address prompts, system instructions, retrieval sources, evaluation cases, output, feedback, embeddings, fine-tuning data, model artifacts, and logs according to the actual architecture. Allocate rights and permitted use without assuming every artifact fits the same ownership category.

Require an approved-service process for model APIs, coding assistants, data-labeling services, hosted notebooks, analytics, and other tools that can receive buyer material. Record data use, retention, training or secondary use where relevant, location, subprocessors, account ownership, administrative access, model or service changes, and exit.

Do not require impossible guarantees about probabilistic output. Define the evaluation cases, quality thresholds, human review, prohibited actions, release approvals, monitoring, change evidence, safe failure, and rollback appropriate to the use. State which party supplies domain reviewers and who may accept residual risk.

Make incident and recovery duties observable

Define what constitutes a security, privacy, availability, data-quality, or material delivery incident for the service. Set the reporting channel, initial content, update cadence, evidence preservation, containment cooperation, decision authority, external-communication control, recovery validation, and post-incident obligations.

Avoid treating a notification clock as the whole incident clause. The buyer may need enough information to assess people, systems, data, locations, and customer commitments. The supplier needs clear contacts and an emergency path that works outside routine governance.

Require continuity evidence proportionate to the dependency: current repositories, build instructions, backups, runbooks, qualified backup people, account ownership, restore testing, and supplier-chain recovery. Define which exercises may be requested, how frequently, and how material gaps are corrected.

Control public statements and relationship claims

State whether either party may use the other’s name, trademarks, screenshots, testimonials, performance figures, or project description. Define the approval owner, permitted channels, exact approved form, duration, withdrawal, and removal period. Cover portfolio pages, sales decks, award submissions, social media, directories, and AI-generated promotional content.

Do not let a confidentiality clause carry this issue implicitly. A supplier may believe it can list a customer name while the buyer expects complete silence. Conversely, a buyer should not imply a partnership, certification, customer result, or provider endorsement that has not been approved.

Require factual correction and removal when an authorized claim becomes inaccurate. Preserve required legal or financial disclosures through appropriate exceptions reviewed by counsel.

Define service measurement and correction

Choose measures that reflect the purchased service: accepted outcomes, availability where relevant, response and restoration, decision or review delay, defect escape, data-quality thresholds, evaluation results, support, and transition. Define the measurement source, exclusions, calculation period, evidence access, dispute process, and consequence.

Service credits can be one remedy, but they should not convert chronic failure into an acceptable subscription discount. Preserve remediation plans, escalation, termination, and other negotiated rights for repeated or material failure. Align each measure with the party that controls it; buyer-caused delay should remain visible rather than being silently charged to supplier performance.

Avoid incentives that reward activity over value. Lines of code, online presence, ticket count, or model calls can be manipulated and may conflict with quality. Use them only as diagnostic context, not as acceptance by themselves.

Accept the transition as a deliverable

Treat exit as a milestone with evidence, reviewer, rejection, remediation, and completion criteria. The transition packet may include current source and artifacts, open work, decisions, dependencies, asset and identity inventories, data exports, deletion evidence, account transfers, runbooks, support history, license records, costs, risks, and qualified contacts.

Test the packet before dependency becomes urgent. Ask an authorized person outside the supplier team to reproduce a build, locate an operational owner, follow a runbook, and verify access revocation in a safe environment. Record gaps and require correction.

State whether the supplier must cooperate with a replacement, for how long, at what rate, with which response expectations, and without withholding buyer assets during a disputed invoice. Counsel should align this with applicable rights and remedies; the operating team should confirm that the promised transition is technically possible.

Frequently asked questions

Can we use the vendor’s standard agreement?

It can be a starting point. Reconcile it with the actual scope, risk, operating model, data, rights, acceptance, and exit. Standard does not mean balanced or complete for your engagement.

Should software outsourcing be fixed price?

Price structure should fit uncertainty and risk allocation. Fixed price can work for bounded outcomes with assumptions and change control; it does not make unknown work predictable.

Is an NDA enough to protect source code?

No. Confidentiality is one layer. Rights, repositories, access, secure development, third-party licenses, documentation, backup, and offboarding also matter.

When should legal counsel review the contract?

Before commitments become difficult to change, especially where employment, tax, IP, regulated data, security, international transfer, or material liability is involved. Give counsel the real delivery and data flow, not only the paper.

What is the most overlooked clause?

There is no universal answer, but practical exit and handover are often underdeveloped. A clear right is less useful when the buyer cannot access current work, accounts, records, or knowledge.

Should the contract name every AI model?

Name material approved services and establish how changes are proposed, evaluated, approved, recorded, and reversed. Hard-coding every version can become impractical, while unrestricted substitution can change cost, data use, quality, or risk. Draft the balance with counsel from the real architecture.