Enterprise AI Procurement: Questions to Ask Before Signing a Contract

AI procurement moves unusually fast because vendors ship visible capabilities every few weeks. A team sees an impressive agent, code assistant, or document feature and wants access before competitors gain ground. That urgency can produce a contract that answers the demo questions but not the operating questions: where does data go, what changes without notice, how are actions governed, what happens in an outage, and how expensive does success become at scale? Procurement should not slow useful experiments into irrelevance. It should make sure an experiment can become a dependable service if it works. The goal is a clear understanding of data, capability, service, pricing, security, accountability, and exit. A vendor relationship is not safe because a model is well known; it is safe because the specific product and configuration meet the organization's requirements. ## Ask about data flows in detail What inputs, outputs, metadata, logs, files, and tool results does the service retain? In which regions? For how long? Who can access them? Are they used for training, service improvement, abuse monitoring, or support? Can retention be configured? Can data be deleted on request? Do the answers differ across consumer, team, enterprise, and API offerings? Map connectors and agent features separately. A model that only sees a prompt has a different risk profile from one that can read cloud drives, email, calendars, code repositories, browsers, or production tools. Require a list of permissions, audit events, and admin controls for each integration. Do not let a broad OAuth approval hide behind a simple AI feature label. ## Ask how models and behavior change Can the organization select, pin, or monitor model versions? How are deprecations announced? What are the migration expectations? Does the vendor offer evaluation or compatibility guidance? A model update can change tone, structured output, tool-call behavior, latency, safety behavior, and cost. A contract should not leave a production workflow dependent on an opaque automatic change with no test window. Ask about rate limits, quotas, geographic availability, uptime targets, incident communications, and support response. Review the history of public status reporting. For critical workflows, design an application-level fallback and confirm that it meets the same data and security requirements. ## Evaluate security as a system Request evidence appropriate to the risk: independent audits, penetration testing approach, identity and access controls, encryption, vulnerability disclosure, incident response, subprocessor list, and isolation between customers. For agents, ask how tools are authorized, how sandboxing works, how outbound network access is controlled, and how audit trails are exposed. Verify the integration in a controlled pilot. Documentation can say a feature supports role-based access, but the real question is whether your identity groups, tenant boundaries, export restrictions, and logging behave correctly. Test revoking a user, disconnecting a connector, deleting data, and investigating a suspicious run. ## Model pricing under real use Do not compare only headline token prices or seat prices. Estimate input and output volume, context length, retrieval, embeddings, tool calls, storage, cached usage, premium models, concurrency, support tier, and overage behavior. Build scenarios for normal demand, growth, and an agent loop or abuse event. Calculate cost per successful task, including human review. Negotiate budget controls, usage reporting, invoice detail, and notice before material price changes where possible. Keep an internal meter so finance does not learn about a new usage pattern from a monthly bill. A vendor that is cheap for a pilot may be costly when every employee or customer uses it. ## Preserve an exit path Own prompts, evaluation datasets, source records, workflow definitions, audit logs, and application state. Use portable formats for outputs and tool schemas. Avoid embedding unrecoverable business logic inside a proprietary visual agent builder without exports. This does not mean avoiding every platform feature; it means documenting the cost and plan for replacement. Name an executive sponsor, technical owner, privacy owner, security owner, and business workflow owner. Establish a review cadence for new capabilities and material changes. The vendor relationship should remain accountable after the purchase order is signed. The AI market rewards speed, but contracts last longer than launch excitement. Ask direct questions, test the answers in a pilot, estimate the full cost, and retain the ability to change course. That discipline is what lets a company adopt powerful new capabilities without making a rushed procurement decision its next operational crisis. ===