Enterprise AI procurement: twelve questions before signature

Executive summary. This Lexbridge note focuses on the operational decisions behind the legal issue: what teams should identify, which controls deserve priority and what evidence should exist when the decision is later reviewed.

Define the intended use before negotiating

A model used for internal drafting creates a different risk profile from one embedded in customer decisions. Procurement should therefore begin with a documented use case, data types, user groups and expected outputs.

Ask what the provider does with data

Contract terms should address prompts, uploaded content, output retention, model training, abuse monitoring and support access. Marketing statements should not substitute for binding commitments where the data is sensitive or regulated.

Plan for model and service changes

AI services evolve quickly. Buyers should understand whether the provider can change models, safety systems, pricing, functionality or usage policies unilaterally and what notice, testing or termination rights apply.

Require enough documentation

The organisation may need technical and compliance information to satisfy customers, regulators or internal governance. Contracts should therefore provide reasonable access to security, model, incident and regulatory-support materials.

Design an exit route

Teams should know what happens to stored data, embeddings, fine-tuned artefacts, logs and integrations if the service is terminated. Exit planning is particularly important where the AI feature becomes embedded in a core product workflow.

Questions for the operating team

• Who owns the decision and who needs to approve an exception?
• What evidence should be retained through the normal workflow?
• Which customer, vendor or regulatory commitments depend on this issue?
• What change would trigger a new review?
• What is the practical fallback if the preferred position cannot be achieved?

Lexbridge perspective

The strongest legal position is one that the business can actually operate. That means linking the rule to ownership, systems, contracts and evidence rather than treating legal advice as a document that sits outside the workflow. For cross-border matters, the same operating model should make clear where local advice is needed and which team remains accountable for the overall decision.

Good legal design reduces the distance between the rule and the person who must act on it.