Before You Connect an AI Tool to Your Business: 7 Contract Questions to Ask First

A new AI feature rarely arrives as a blank text box. It asks to connect to your inbox, calendar, CRM, support desk, shared drive, accounting platform, or payment processor. The permission screen may take a minute to approve. The business consequences can last much longer.

Before granting access, founders should ask a more useful question than “Is this AI good?” Ask: what will this vendor be allowed to see, change, send, or trigger in our business?

That question turns an AI purchase into a concrete contract review. It focuses the discussion on access, operational limits, data use, vendor changes, and what happens if the service misfires or a connection must be shut down.

This is not an argument against AI tools. Many are valuable. It is an argument for matching the agreement and the configuration to the access being granted.

1. What Exactly Will the Product Be Able to Do?

Start with the workflow, not the product label. Ask the vendor to describe the actions the product can take after implementation — not just the problem it is designed to solve.

For example, distinguish between a tool that prepares a customer-service response for an employee to review and a tool that sends the response from a company account. Distinguish between software that identifies potentially duplicate records and software that merges or deletes records. The contract and implementation documents should identify the specific use case, connected systems, and approved actions.

A useful written description can live in an order form, statement of work, product exhibit, or implementation plan. What matters is that it is incorporated into the deal and can be checked later.

2. Which Accounts and Permissions Are Truly Necessary?

Access should be tied to the task. A broad administrative permission may be convenient during a demo, but it may not be necessary for day-to-day use.

Ask for a list of the accounts, application-programming interfaces, permissions, and credentials the vendor’s product will use. Then decide whether the tool needs authority to read information, create records, edit records, transmit data, initiate a transaction, or invite other users. The agreement should not quietly assume broader access than the workflow requires.

Where available, consider role-based access, separate service accounts, least-privilege settings, staged testing, and an internal approval process before expanding permissions. Those are operational decisions, but they help give the contract’s stated limits practical effect.

3. What Information May the Vendor Use — and for What Purpose?

“Customer data” is often too broad to resolve the real issue. An AI product may receive material your team supplies directly, retrieve information through a connected system, create outputs, and generate technical or activity records while it operates.

The agreement should identify the relevant data flows and the vendor’s rights for each one. In particular, ask whether the vendor may use any category of information to operate the service, troubleshoot, improve its products, train a model, create aggregated information, disclose information to subprocessors, or retain it after the relationship ends.

Also check whether the vendor’s public privacy statement, data-processing addendum, online terms, and order form use consistent definitions. A favorable sentence in a sales email is not a substitute for a contractual commitment.

For covered developers of generative AI systems or services made available to Californians, California Civil Code section 3111 requires website documentation about specified training data. That obligation falls on the developer and does not replace a customer’s review of the vendor’s particular data terms. See Cal. Civ. Code § 3111 (AB 2013).

4. Can the Vendor Change the Product After You Sign?

Software changes during a subscription term. That is normal. But not every change is commercially neutral.

Review the vendor’s modification clause and incorporated online policies. The customer should receive meaningful notice before a change materially affects the agreed workflow, security posture, data handling, integration, or level of access. For a material change, the parties should address what the customer may do: test the change, decline a newly optional feature, disable an integration, or terminate the affected service if the change creates a material adverse effect.

This is especially important when an AI feature is added to an existing software product. A customer that purchased a reporting platform may not have intended to authorize a new tool to use company content beyond the original service purpose or to interact with connected accounts in new ways. Our guide on API dependencies and vendor terms covers the adjacent problem of building on services you do not control.

5. How Quickly Can We Stop the Connection?

Every deployment should have a practical off switch. The question is not only whether the customer has a termination right at the end of a contract term. It is whether the customer can promptly suspend the tool’s access if there is a security concern, an unexpected result, a configuration mistake, or a change in business needs.

Confirm who can disable the integration, revoke credentials, remove access, and pause recurring workflows. Ask what support is available if the customer needs help urgently. The vendor should also explain what happens to queued tasks, in-progress requests, and records created before a suspension.

The goal is a workable containment process, not a theoretical remedy after the damage is done.

6. What Must the Vendor Tell Us If Something Goes Wrong?

The agreement should separate ordinary product support from an incident that affects the customer’s systems, data, or operations. Review the incident-notice provision for timing, content, communication channels, and cooperation obligations.

For a material incident, the customer may need enough information to take its own protective steps: when the event was detected, what systems or information may be affected, what actions the vendor has taken, what actions the customer should consider, and when further updates will be provided. Contract language should be aligned with any security addendum and the customer’s internal response plan.

Logs and records matter here. Decide in advance whether the customer can obtain activity records showing significant actions performed through the integration, along with the relevant timestamps and account context. The appropriate level of recordkeeping depends on the use case, but a generic reference to “industry-standard practices” may not answer the operational question.

7. Does the Financial Risk Allocation Fit the Access We Are Granting?

A limitation-of-liability clause is a core commercial term. It should be read alongside the permissions and data flows, not in isolation.

Consider the realistic consequences if the product exposes confidential information, causes changes in a connected system, sends a communication improperly, or becomes unavailable during a critical workflow. Then compare those risks to the agreement’s cap, exclusions, indemnity provisions, insurance requirements, and disclaimers. There is no universal answer: the appropriate allocation depends on the particular service, the customer’s controls, pricing, leverage, and governing law.

Be attentive to exclusions drafted around “customer data,” “customer instructions,” or “customer use.” Those provisions may be appropriate in some circumstances, but they should not obscure the parties’ allocation when the issue involves the vendor’s service, security commitment, or conduct within the agreed integration and configuration.

A Simple Email to Send Before Signing

A founder does not need to resolve every issue in the first conversation. These questions are a practical starting point:

1. What systems will the product connect to, and what permissions are required for each?
2. What actions can it take in each system, and which actions require our approval?
3. What information can the service access, retain, share with subprocessors, or use to improve products?
4. Can the vendor add or materially change AI features, data practices, or integration permissions during the term?
5. How do we immediately suspend access, revoke credentials, and stop pending work?
6. What records of significant activity can we retrieve, and how long are they retained?
7. What is the notice and cooperation process for a security or operational incident, and how does the agreement allocate the resulting risk?

Clear answers to these questions make it easier to decide whether the product is ready for the requested access — and whether the agreement reflects the arrangement the business intends to make.

A Brief Legal Note — Current as of July 2026

AI-specific regulation is evolving, and this post is not a compliance checklist. Some laws address particular AI practices, disclosures, or data concerns. For example, Texas’s Responsible Artificial Intelligence Governance Act, effective January 1, 2026, includes AI-use prohibitions and provides for enforcement by the Texas attorney general, including a notice-and-cure process in specified circumstances. See Texas HB 149 (2025). The legal requirements relevant to a deployment will depend on the product, data, users, industry, and jurisdictions involved.

The NIST AI Risk Management Framework is voluntary, but it may be a helpful reference for discussing risk-management processes with a vendor. See the NIST AI Risk Management Framework.

How Accord & Shield Legal Can Help

Accord & Shield Legal assists businesses with reviewing, drafting, and negotiating SaaS and technology-vendor agreements. In an AI-enabled purchase, that work can include reviewing access and data terms, change-management provisions, incident-response commitments, and commercial risk allocation. The scope of any engagement depends on the agreement and the client’s proposed use. You can see the full scope of our contract services as well.

Disclaimer

Attorney Advertising. This post provides general information only, not legal advice. Reading it does not create an attorney-client relationship. A vendor agreement, proposed workflow, and applicable law must be evaluated in their specific context.