Technology creates business value when an organization has the rights, relationships, and capacity to use it as intended. Software can improve delivery, data can reveal opportunities, and AI can expand what a team can accomplish. Those benefits depend on decisions about access, ownership, reliability, responsibility, and control that a product demonstration rarely resolves.
A company may buy a useful platform but lack the rights to make it available to customers. A service provider may promise protection it cannot obtain from its own suppliers. A board may approve an AI initiative without knowing which decisions the system will influence. In each situation, the technology can work while the business arrangement remains incomplete.
This guide is for executives, owners, and boards evaluating technology relationships in the United States, including organizations that sell technology or services to others. It connects the legal issues across selection, contracting, use, change, and exit. Particular obligations depend on the activity, the information involved, the people affected, and the relevant jurisdictions.
The business use determines the legal questions
“We are buying software” can describe very different commitments. An internal scheduling tool, a customer-facing platform, a system that processes employee information, and an AI service embedded in a paid offering do different work. They also create different dependencies and expose different people to the consequences of failure.
The distinction becomes especially important when a tool moves beyond its original purpose. An employee may begin using AI to organize public information and later use the same account to analyze confidential customer records. A platform bought for one company may become the operating system for a group of affiliates or franchisees. The original commercial and legal assumptions may no longer fit.
For a provider, the analysis runs in both directions. What the organization is allowed to obtain from its suppliers must support what it offers its customers. A broad promise to provide uninterrupted service, retain records, or protect information needs a credible foundation in the delivery chain.
Legal involvement is most useful while those choices remain open. The aim is to connect the intended business use to the permissions, commitments, and dependencies that make it possible. A contract review conducted after the organization has committed its budget, announced a launch, and designed its operating model has fewer commercial options to work with.
Access to a platform is different from ownership of an asset
A subscription typically provides access on agreed terms. It may not give the customer ownership of the platform, a right to keep using it indefinitely, or permission to provide access to every person involved in its business. User categories, affiliates, contractors, territories, resale, and customer-facing uses can all matter.
Development and implementation work introduce another layer. The organization may pay for configuration, integrations, reports, or custom code while the provider retains underlying tools and reusable components. The commercial question is what the customer needs to own and what it needs a durable right to use, maintain, modify, or move.
Payment alone should not be treated as a complete answer to copyright ownership. Federal copyright law distinguishes authorship and ownership, works made for hire, and transfers of rights. A transfer of copyright ownership generally requires a signed writing, subject to the statutory exception for transfers by operation of law.1
Consider a hypothetical business that commissions a customer portal. The portal functions well, but only the original developer can maintain the integration on which it depends. The business may have obtained the deliverable it requested without securing the flexibility it expected. Clear rights in the relevant components can preserve the ability to change providers, support an acquisition, or expand the service without reopening the entire bargain.
The contract needs to describe a workable relationship
A technology relationship may be spread across an order form, master agreement, statement of work, service-level agreement, data-processing terms, security schedule, and online policies. Each document can appear reasonable in isolation while the combined arrangement leaves an important responsibility unresolved.
Implementation is a common pressure point. The provider may depend on accurate customer data, timely decisions, access to other systems, and cooperation from a separate consultant. The customer may assume the subscription price includes migration, integration, or a finished business result. A fixed launch date becomes difficult to evaluate when these assumptions differ.
Acceptance also has commercial significance. A system can meet a technical specification without being ready for the organization’s intended use. Conversely, an open-ended expectation of complete customer satisfaction can leave a provider responsible for decisions or work it does not control. The legal terms need to reflect a supportable allocation of scope and responsibility.
Changes to online terms or incorporated policies deserve attention for the same reason. A negotiated agreement may lose practical value if a different document can materially change data uses, product capabilities, or support during the relationship. The issue is how the documents work together and which commitments the parties can rely on as the service develops.
Data rights involve more than a statement of ownership
“You own your data” is a useful starting point, but it leaves important questions unanswered. Can the organization obtain a usable copy? Does that copy include attachments, history, relationships among records, and the information needed to explain earlier decisions? Can it move the information into a replacement system or provide it to another service provider?
The supplier may distinguish customer content from usage information, analytics, derived information, or improvements to its services. Those distinctions can determine who benefits from the relationship over time. A customer may retain its original records while the provider acquires broad rights to analyze patterns across them.
Broader use can create legitimate value. Shared analytics may improve fraud detection, product performance, or industry benchmarking. The tradeoff concerns the information involved, the purposes permitted, the people who can benefit, and whether the organization has authority to grant those rights. A commercially attractive use can still conflict with a customer commitment or restriction attached to the source material.
These choices are also relevant to an eventual sale or reorganization. A buyer may value the data but need to understand whether the acquired business can continue using it, disclose it during diligence, or migrate it after closing. Our article on data rights, reuse, and exit examines the gap between nominal ownership and practical control.
Privacy and confidentiality are connected but distinct
Privacy obligations concern information about people and the rules governing its collection, use, disclosure, and other handling. Confidentiality can protect a wider range of information, including pricing, business plans, source code, client materials, and negotiations. Information can raise one set of issues, both, or neither, depending on the circumstances.
An organization may have permission to use information for its own work without permission to disclose it for a vendor’s independent purposes. A confidentiality agreement, customer contract, professional obligation, privacy notice, or applicable statute may constrain that next use. A product setting or a supplier’s general security statement does not resolve all of those questions.
Where the California Consumer Privacy Act applies, for example, the regulations impose specific contractual requirements on service-provider and contractor relationships, including limits tied to defined purposes. That framework is an illustration of why the parties’ legal roles and actual uses matter; it does not apply to every organization or every record.2
For leadership, the business opportunity is greater confidence about which uses the organization can support. A well-understood data relationship can enable an improved service or a useful analysis. An assumed permission can turn the same project into a dispute about commitments the organization made elsewhere.
Security commitments need to match the delivery chain
A platform’s security depends on more than the vendor’s practices. Customer configuration, user access, integrations, implementation choices, subcontractors, and the handling of exported information can all affect the result. Contractual responsibility needs to account for the actual division of work.
An assessment report or certification can provide useful evidence within its scope. Its significance depends on what systems, services, period, and controls it covers. A badge alone does not establish that every part of a proposed service satisfies the customer’s requirements or that a particular loss will be reimbursed.
Incident terms bring these dependencies into focus. The parties may need different information at different times, and their obligations to customers or regulators may not align with their supplier’s commitments. An organization that promises rapid notice and detailed cooperation downstream needs to understand whether its upstream relationships support those promises.
The relevant legal work connects security representations, incident definitions, notification, cooperation, access to evidence, and responsibility for resulting costs. It also separates the existence of a response obligation from the availability of a financial remedy. A vendor’s duty to help investigate a problem and its duty to pay for the consequences are different questions.
AI reliability matters in the context of the decision
A model’s capabilities have to be evaluated against the work the organization expects it to perform. Generating a preliminary outline is different from communicating eligibility, recommending a treatment, screening applicants, or making a commitment to a customer. The consequence of an error can matter as much as how often one occurs.
NIST’s Generative AI Profile identifies the risk of plausible but false output, often called hallucination or confabulation.3 That possibility has a different business meaning in an internal brainstorming exercise than in a workflow on which others are expected to rely.
Human review can be useful, but the label leaves questions about expertise, time, access to underlying information, and authority to disagree. If the commercial model depends on reviewing more material than qualified people can meaningfully assess, the organization has a business-design issue as well as a technology issue.
The organization also needs to distinguish general capability claims from commitments about its particular use. Availability, speed, answer quality, and fitness for a business purpose are different measures. The supporting article on who bears the consequences of AI errors explores how those distinctions affect customers, providers, and the contracts between them.
AI outputs and inputs raise different intellectual-property questions
The right to use an AI tool does not settle the rights in every input or output. Material supplied to the tool may be subject to copyright, confidentiality, license restrictions, or other obligations. The vendor’s permission to process a file cannot supply rights the organization did not have authority to grant.
Outputs require a separate analysis. The U.S. Copyright Office’s 2025 report explains that copyright protects qualifying human expression, including in works containing AI-generated material, while purely AI-generated expression is not protected. Whether a person’s contribution is sufficient requires a case-specific analysis.4
A vendor’s contract can allocate rights between the parties without establishing that an output is copyrightable, exclusive, or free of third-party claims. These distinctions matter when a business intends to sell content, license software, promise exclusive deliverables, or treat a generated asset as a source of competitive advantage.
There may still be substantial value in AI-assisted work. The legal question is which part of that value the organization can use, protect, and promise to others. For a provider, that analysis should connect the tools used to produce a deliverable with the ownership and infringement commitments offered to the customer.
Governance determines who can accept the exposure
Technology decisions often cross organizational boundaries. IT understands the system, security evaluates controls, the business sponsor sees the opportunity, finance evaluates cost, and legal identifies obligations and available choices. Each contribution matters. None, standing alone, necessarily authorizes the organization to accept the full arrangement.
A policy can establish general rules while leaving consequential choices unsettled. Who can approve a new use of confidential information? Who can accept a contractual gap? Who can suspend a tool that has become important to customer delivery? An approval that answers only one of these questions can be mistaken for approval of all of them.
NIST describes its AI Risk Management Framework as voluntary guidance for managing AI risk.5 Such a framework can inform an organization’s approach, but the organization still needs to connect its own authority, resources, and legal obligations to the actual decisions in front of it.
Boards need enough information to oversee material exposures and matters within their authority. That does not make every software purchase a board decision. The appropriate involvement depends on the organization’s governing arrangements and the significance of the initiative. The companion AI governance article focuses on the decisions a policy cannot make on leadership’s behalf.
Existing legal duties follow the underlying activity
An AI label does not replace the legal analysis of what the organization is doing. Selling a service, evaluating an applicant, making a financial representation, handling health information, and issuing a credential involve different responsibilities. The same tool can raise different legal questions in each setting.
Employment selection is one example. Federal anti-discrimination rules govern covered employers’ use of tests and selection procedures; the analysis can involve discriminatory treatment, unlawful disparate impact, and disability-related requirements.6 Introducing software into the process makes its role in the decision important to that analysis.
Claims about a technology’s capabilities also matter. Section 5 of the FTC Act addresses unfair or deceptive practices within the Commission’s jurisdiction.7 A business describing an AI-enabled product needs to consider what it is representing and the basis for that representation, as it would with other consequential product claims.
Additional requirements can arise from state law, industry regulation, professional obligations, and activity outside the United States. A general assurance that a product is “compliant” leaves unanswered compliant with what, for whom, and in which use. Legal review gives that assurance a defined scope and identifies the responsibilities that remain with the organization.
Remedies and insurance determine how much risk remains
A service failure may cause costs well beyond the subscription fee: interruption, reconstruction, customer accommodations, replacement services, investigation, or lost opportunities. The ability to recover those costs depends on the claim, the agreement, applicable law, and practical recovery prospects.
Service credits, warranties, indemnities, liability caps, damages exclusions, and termination rights address different parts of that problem. An uptime credit may have little relationship to the cost of a wrong answer. An intellectual-property indemnity may not cover an inaccurate recommendation. A broad headline promise can be narrowed by definitions, exclusions, or the interaction among provisions.
For service providers, customer commitments and supplier remedies deserve attention together. The organization can face an obligation to a customer that is broader than anything it can recover upstream. That gap may be a conscious commercial decision, but it should be visible in pricing, service design, and the decision to proceed.
Insurance is another part of the analysis, with coverage depending on the policy, the facts, and the kind of claim. A certificate or general description of coverage does not establish that a particular AI, data, or service loss will be paid. Counsel and the insurance adviser can help leadership understand how contractual allocation, coverage, and the organization’s own capacity to absorb loss fit together.
Change, renewal, and exit affect the value of the investment
Technology relationships rarely stay fixed. Features change, pricing evolves, suppliers introduce new subcontractors, products are acquired, and organizations expand into new activities. A useful agreement gives the parties a workable basis for addressing change while recognizing the commitments already made.
Commercial dependence can increase quietly. A team builds workflows, trains staff, connects other systems, and accumulates records. By renewal, the cost of leaving may be much larger than it was when the subscription began. That can affect the organization’s choices even if it has a formal right to terminate.
Exit therefore concerns more than the date service ends. The organization may need continued access, usable exports, assistance, records of prior actions, rights in custom work, and enough time to establish a replacement. A right to receive information is less useful if the information arrives without the relationships or context needed to use it.
The same issues matter during an acquisition or restructuring. Assignment restrictions, affiliate-use limits, ownership questions, and transition dependencies can affect a transaction’s timing or expected value. Legal attention before the relationship becomes difficult to unwind can preserve options the business will later need.
Coordinated legal work supports a better business decision
The most useful legal assessment brings the opportunity and the obligations into the same discussion. It identifies what the organization can do, what it would promise, which exposures can be reduced or allocated, and what risk would remain. Leadership can then decide whether the expected benefit justifies the arrangement.
That work can lead to several reasonable outcomes: a revised commercial structure, a narrower use, a different allocation of responsibility, a staged commitment, or acceptance of a clearly understood limitation. Negotiating every provision to an ideal position is not always possible or proportionate. Understanding the consequences of the actual deal is the essential point.
Org Law advises organizations on software and technology transactions, AI contracting, data-processing agreements, and AI governance and use policies. A focused AI Contract & Use Review can connect a proposed use with provider terms, data flows, customer commitments, and internal authority.
For additional context, our published articles examine AI vendor contracts and, for tax-exempt organizations, the choices behind free or vendor-supported AI assistance. If a technology decision is creating uncertainty about rights, responsibility, or the organization’s next move, start a conversation.
Sources
- 17 U.S.C. §§ 201–204, U.S. Copyright Office. Copyright ownership and transfers. The discussion is not a determination that a particular commissioned work qualifies as a work made for hire.
- California Privacy Protection Agency, CCPA statute and regulations effective January 1, 2026. See regulations §§ 7050–7051 on service providers, contractors, and contractual requirements. Applicability requires a separate assessment.
- NIST AI 600-1, Generative Artificial Intelligence Profile (July 2024), § 2.2. Risk-management guidance addressing confabulation.
- U.S. Copyright Office, Copyright and Artificial Intelligence, Part 2: Copyrightability (January 2025), executive summary and § II.
- NIST, AI Risk Management Framework. Voluntary framework; the current NIST page notes that AI RMF 1.0 is undergoing revision.
- EEOC, Employment Tests and Selection Procedures. Agency explanation of existing employment-discrimination law, not a separate AI-specific mandate.
- Federal Trade Commission Act, FTC overview. Section 5 and the Commission’s jurisdiction.
