Before You Sign an Enterprise AI Contract: A 7-Question Checklist for Corporate Boards

Corporate leaders, partner committees, and enterprise boards are approaching enterprise AI the way they approached software in 2015: pick a platform, sign a contract, plug it in. That worked for software solutions where there weren't many alternatives, and most niches had a single dominant solution. Unfortunately, this doesn't apply to production-level enterprise AI. The "platform" decision is really multiple decisions stitched together, and many of the AI contracts and solutions I see in the corporate market cover one or two of them while leaving the others on the buyer's desk.

And before anyone asks, "which tier should we buy?" the free, pro, team, and enterprise tiers from the big providers represent different assumptions about security, administration, support, data handling, and controls. The price tag tells you which set of assumptions you are paying for. Picking a tier is not picking a strategy. The seven questions below are the strategy. The tier follows from them.

Here is what every board, partner committee, and procurement lead should be putting in front of an AI vendor before signing. These belong on the desks of your vendor, CIO, compliance lead, and procurement team. The board's job is to make sure someone can answer all seven in plain English.

Why this matters in Cayman right now

The local context is not theoretical. Cayman's regulators and statutory bodies have made digital transformation, regulatory technology, and AI-enabled analytics priorities across recent strategic plans and procurements. Controls aligned with NIST (the US National Institute of Standards and Technology) and GDPR (the EU General Data Protection Regulation) increasingly appear as baseline expectations in public-sector (and increasingly private-sector) RFPs. The Cayman Islands Data Protection Act sits as the floor under all of it.

In other words, the regulators are already moving. Many of the boards approving the AI spend are not, and the gap is widening. The seven questions below are the simplest way I know to close it.

What this looks like in practice

A composite based on several recent conversations: regulated firm, mid-sized, document-heavy, mid-six-figure AI contract on the table. The product worked in the demo. It still works in the demo. But when we ran through the seven questions, the vendor could fully answer two. Three were partial. Two were "we'll add that on the roadmap." That contract is now being renegotiated.

Few firms have all seven perfect from day one. Question three (data handling and prompt injection) and question six (the audit trail) are the two that must be in place from go-live for any regulated industry in Cayman. The rest can be staged. The vendor that cannot answer all seven may still be a competent vendor, but you are buying a pilot rather than a production-ready enterprise system, and the contract should price it that way.

The 7 Questions

Underneath all seven questions are three outcomes a regulated firm should expect from any production AI it buys: regulatory-safe by design (privacy, audit, and accountability are designed in, not bolted on), switchable rather than locked in (you can leave, migrate, or change providers without rebuilding from scratch), and predictable cost and performance (no surprise bills, no silent behaviour changes). The seven questions are how you check.

1. "If this AI provider changes their pricing or falls behind, how hard is it to move?"

The plain version: are we locked into today's chosen model, or can we switch providers when a better one arrives next quarter?

AI model providers shift quickly. Capabilities, pricing, and policies move on a quarterly basis. A contract that hard-codes today's provider into your application is a contract you will be renegotiating very soon.

What a good answer sounds like: there is a switching layer between your business and any single AI provider. Think of it as the plug adapter that lets you swap the device without rewiring the building. You can move from one provider to another without rebuilding the application.

2. "Who owns the instructions, business logic, knowledge base, and anything tuned on our own data?"

The plain version. The custom instructions, workflows, internal knowledge, and any model trained on your information: are they your property, or the vendor's?

This is the question that catches firms out most. The instructions and configurations that make the AI sound like your firm and follow your policies are real intellectual property. So is any model fine-tuned on your client data. And there is a separate, equally important question: will the vendor (or their upstream model provider) use your prompts, your documents, or your client data to train their public models? For a law firm or fund administrator, the wrong answer here ends the conversation.

What a good answer sounds like: you own the configurations. You own anything tuned to your data. The vendor cannot use your data to train models that the rest of their customers benefit from. All three are written into the contract.

3. "How does the system handle a client's passport number, a Cayman TIN, or a prompt injection from an email?"

The plain version: what checks happen before the AI sees an input, before it returns an output, and before it does anything else?

This is where the Cayman Islands Data Protection Act, GDPR-style obligations, and the standard NIST controls actually live. Personal data redaction. Health and claims data redaction. Prompt-injection detection, where bad actors try to manipulate the AI through innocent-looking inputs. Secrets detection. SQL sanitisation.

What a good answer sounds like: validations applied in three places. Before the AI sees an input, before its output reaches the user, and before it takes any action that touches a real system. Applied consistently across every workflow. This is the one question I would refuse to sign without.

4. "What stops usage, errors, or automated actions from running beyond budget?"

The plain version: Are there spending limits, and what happens when something goes wrong?

AI usage is metered. There are well-publicised cases overseas of AI agents looping and generating five-figure cloud bills overnight. For a regulated firm, the bill is the smaller problem. The bigger one is an unconstrained AI taking an unauthorised action that creates client or regulatory exposure.

What a good answer sounds like: per-project and per-user budget caps. Automated stops. Alerts when usage spikes. And a hard limit on which actions the AI is allowed to take without a human approving them.

5. "Which systems can the AI touch, and with whose credentials?"

The plain version: when the AI sends an email, opens a file, or queries a database, whose login is it using, and what is it allowed to do?

An AI agent is only as safe as the smallest set of permissions you can give it. "Service accounts with full access to everything" (common in early AI deployments) is the same security mistake firms learned to stop making with humans a decade ago.

What a good answer sounds like: centralised identity and access, meaning the AI cannot act on your systems with unchecked admin credentials. The AI connects to tools through your existing identity systems, with role-based permissions and an audit trail of every action.

6. "When a client claims the AI told them something wrong, can you show me the conversation?"

The plain version: is there a recording?

For a regulated firm, the absence of an audit trail is the absence of compliance. Your accounting, custody, and claims systems already log every transaction. The AI sitting next to those systems should be held to the same standard.

What a good answer sounds like: full request, response, error, and latency logging for every AI interaction, using the same enterprise-grade logging discipline your IT team already applies to core systems. Retention that matches your regulator's expectations. Searchable, exportable, and subject to your existing audit rights.

7. "When the underlying AI model changes, what testing happens before it touches our clients?"

The plain version: model providers update their models regularly, sometimes with limited notice. How does the vendor catch a regression before your clients do?

A model that behaved well in last month's demo can quietly behave differently this month. Without a test suite, the regression test is your client noticing.

What a good answer sounds like: a regression test suite for AI answers, the same idea your IT team already uses for core systems. A library of historical cases the new model is tested against before it goes live. The ability to freeze a known-good version while the test runs.

Don't forget the rest of the schedule

The seven questions above do not replace normal procurement discipline. They sit beside it. Your usual schedule still applies, and matters more, not less, in an AI context: data residency and cross-border transfer, vendor lock-in and exit clauses with certified deletion, SLAs and incident response, third-party audit rights, security certifications (SOC 2, ISO 27001), subprocessors who will touch client data, and business-continuity arrangements for when the AI provider has an outage. The difference with AI is that all of these contractual concerns now sit on top of seven new technical realities. If you ignore the technical realities, the contract language will not save you.

The boards I respect most are asking, "How much more can we do with the same team?" That question reframes the entire procurement, and the seven above are how it gets answered.

If a vendor cannot tell you, in plain language, how they handle all seven, they are not selling you production AI. They are selling you a demo with an invoice attached.

If your firm is approaching an AI procurement and isn't sure which questions to put in front of the vendor, that is the first conversation we have at an AI Readiness Audit. caydev.com/consult