“Who owns the code?” is important, but it does not settle every question about an AI application. A project may combine custom development, reusable components, open-source dependencies, customer data and external model services.
This guide is a commercial discussion checklist, not legal advice or a statement of the law applicable to every project. The agreement must be reviewed for the actual parties and jurisdiction.
Identify the different materials
Separate project-specific code and designs from components that existed before the engagement. Identify third-party software and services, their licences and any restrictions relevant to the intended deployment.
Make the distinction visible in the proposal. A general ownership sentence should not conceal dependencies that the client cannot use independently.
Discuss data and generated outputs
Define which party supplies data, what access is granted and what the supplier may do with it during the project. Treat permission to deliver a system separately from permission to reuse data, train a model or publish a case study.
Clarify how generated outputs are handled under the applicable agreement and selected services. Do not assume every provider or content type has the same terms.
Define what handover includes
Depending on the scope, handover can include repository access, source code, configuration instructions, dependency information, data schemas, deployment procedures, test datasets, evaluation scripts and an operating runbook.
Specify what the receiving team must demonstrate. For example, can it deploy the release in the agreed environment, run the acceptance tests and identify the owner of each external service?
Separate possession from operational independence
Receiving files does not automatically mean the client can operate the application without the supplier. Accounts, infrastructure, domain settings, build systems or undocumented dependencies can remain critical.
Identify those dependencies early and decide which accounts the client owns, which the supplier operates and how the arrangement changes at the end of the engagement.
Agree post-launch responsibility
Distinguish defect handling, routine maintenance and new functionality. Define support coverage and escalation, model or dependency updates, and how changes are approved.
Resolve what happens when the relationship ends: outstanding work, access removal, data return or deletion, and assistance with transition. These should be contract-specific terms rather than an assumption that all projects include indefinite support.
Publication is a separate permission
A project can be completed without becoming a public reference. Names, logos, screenshots, quotations and measurements need agreed publication rights. Anonymous descriptions can still reveal a client or confidential process and should be reviewed accordingly.
Questions for the proposal review
Which deliverables are assigned or licensed? Which components remain the supplier's pre-existing materials? Which licences apply? What is needed to run the system? Who controls the operational accounts? What support is included? What happens at termination? What may be published?
A supplier should be willing to resolve those questions before development, not after the client asks for the repository.