What Enterprise Buyers Look for in AI Governance

The Procurement Gauntlet

If you have ever sold software to a Fortune 500 company, you know the drill. The technical team loves your product. The engineering proof-of-concept went well. Everyone is excited. Then the deal enters procurement, and everything slows to a crawl.

Security questionnaires. Vendor risk assessments. Legal reviews. Compliance checklists. Data processing agreements. Each one takes weeks, sometimes months. And if you fail any single gate, the deal dies.

AI governance platforms face an especially intense version of this process. You are asking enterprise buyers to trust you with the most sensitive layer of their AI operations: the authorization and audit layer that sits between their AI agents and their production systems. If that layer fails, their agents either stop working or start doing unauthorized things. Neither outcome is acceptable.

We have been through this process with dozens of enterprise buyers. Here is what their procurement teams actually evaluate, in the order they evaluate it.

SOC 2 Type II: The Non-Negotiable

Every enterprise procurement process starts with SOC 2. Not SOC 2 Type I, which only proves you designed controls at a point in time. Type II, which proves those controls operated effectively over a sustained period, typically six to twelve months.

If you do not have SOC 2 Type II, most enterprise buyers will not proceed. It is the minimum threshold for serious consideration. The specific trust service criteria they look for include security, availability, confidentiality, and processing integrity. Privacy is sometimes included, especially for companies handling PII.

What procurement teams actually do with your SOC 2 report: they read the auditor's opinion letter, scan for any qualified opinions or exceptions, review the description of your system boundaries, and check the testing period. If the testing period ended more than twelve months ago, they will ask for a bridge letter or a more recent report.

Intended maintains a current SOC 2 Type II report and provides it under NDA to qualified enterprise prospects. Our control environment covers the Authority Engine, the audit subsystem, data encryption, access management, and incident response.

Data Processing Agreements

The DPA is where legal teams spend most of their time. For an AI governance platform, the DPA needs to address several specific concerns.

First, what data does the platform process? Intended processes intent metadata, which describes what an AI agent wants to do. This metadata may include references to resources, users, and systems in the customer's environment. The DPA must clearly define the categories of data processed and the purposes of processing.

Second, data sub-processors. Enterprise buyers want to know every third party that touches their data. Cloud hosting providers, logging services, monitoring tools, support platforms. Each sub-processor needs to be listed, and the DPA should include a mechanism for notifying customers of sub-processor changes.

Third, data deletion. When a customer churns, what happens to their data? The DPA should specify retention periods and deletion procedures. For audit data, this is especially important because customers may have regulatory requirements to retain audit records for specific periods.

Fourth, cross-border data transfers. If the platform operates in multiple regions, the DPA needs to address data transfer mechanisms. Standard contractual clauses, binding corporate rules, or adequacy decisions under GDPR.

SLA and Uptime Guarantees

AI governance platforms sit in the critical path of AI agent operations. If the governance layer goes down, one of two things happens: agents stop working entirely (fail-closed) or agents operate without governance (fail-open). Neither is acceptable for production workloads.

Enterprise buyers evaluate SLAs along several dimensions. Uptime commitment is the headline number. 99.9 percent is table stakes. 99.95 percent is expected for mission-critical infrastructure. 99.99 percent is rare but some buyers will push for it.

More important than the headline number are the details. How is uptime measured? What counts as downtime? Are scheduled maintenance windows excluded? What are the service credits for SLA breaches? Is there a cap on service credits?

Intended provides a 99.95 percent uptime SLA for our managed cloud offering, measured on a monthly basis across the Authority Engine API endpoints. Scheduled maintenance windows are excluded but limited to four hours per month and announced 72 hours in advance. Service credits start at 10 percent of monthly fees for uptime below 99.95 percent and scale up to 30 percent for uptime below 99.0 percent.

The more sophisticated buyers also ask about latency SLAs. For an authorization layer, latency matters. If every AI agent action requires a governance decision, and that decision takes 500 milliseconds, you have added half a second to every operation. Intended targets p99 latency under 100 milliseconds for standard policy evaluations.

Data Residency

Data residency requirements have become significantly more stringent in recent years. GDPR set the standard, but now nearly every major market has some form of data localization requirement. Enterprise buyers operating in multiple jurisdictions need their governance platform to support data residency at the deployment level.

The key questions procurement teams ask: Where are the compute resources located? Where is the data stored at rest? Where is the data processed? Can the customer choose their deployment region? Can different tenants within the same customer be deployed to different regions?

Intended supports deployment in US, EU, and APAC regions for our managed cloud offering. Single-tenant deployments can be placed in any AWS or GCP region. For customers with strict data residency requirements, we offer on-premise deployment options where all data remains within the customer's own infrastructure.

Support Tiers

Enterprise support expectations go well beyond a help center and a community Slack channel. Procurement teams evaluate support along several dimensions.

Response time SLAs by severity level. For critical issues affecting production, enterprise buyers expect a 15-minute response time with continuous work until resolution. For high-severity issues, one-hour response. For medium, four hours. For low, one business day.

Named support contacts. Enterprise buyers want to know who they are working with. A named technical account manager and a named support engineer. Not a rotating queue of tier-one agents reading from scripts.

Escalation paths. When standard support cannot resolve an issue, what happens? Enterprise buyers want documented escalation paths that go all the way to engineering leadership.

Support channels. Phone, email, and a dedicated Slack or Teams channel. Some buyers also want an on-site support option for critical deployments.

Intended offers three support tiers: Standard, which includes email support with next-business-day response; Professional, which includes priority email and Slack support with four-hour response for critical issues; and Enterprise, which includes all channels, 15-minute critical response, a named TAM, and quarterly business reviews.

Security Questionnaire Deep Cuts

Beyond the standard items, procurement security teams dig into specifics that reveal how seriously a vendor takes security. Here are the questions that separate prepared vendors from unprepared ones.

Encryption at rest and in transit. TLS 1.3 for data in transit is expected. AES-256 for data at rest. But the follow-up questions matter: who manages the encryption keys? Can the customer bring their own keys? Is there envelope encryption?

Penetration testing. When was the last pen test? Who conducted it? What was the scope? Were findings remediated? Can you share the executive summary under NDA?

Incident response. Do you have a documented incident response plan? When was it last tested? What is the notification timeline for security incidents affecting customer data?

Business continuity. What is your RPO and RTO? How is data backed up? Where are backups stored? When was the last disaster recovery test?

Vulnerability management. How do you handle CVEs in dependencies? What is your patching cadence? Do you have a vulnerability disclosure program?

What Actually Closes Enterprise Deals

After years of enterprise sales, we have learned that procurement is not the bottleneck most vendors think it is. The real bottleneck is preparation. If you have your SOC 2 report ready, your DPA template reviewed by competent counsel, your SLAs documented, your security questionnaire pre-filled, and your support tiers clearly defined, the procurement process moves at a reasonable pace.

The vendors who get stuck are the ones scrambling to create these artifacts during the procurement process. By the time you are in procurement, everything should already exist.

For Intended, this means we invest heavily in compliance infrastructure before we need it. Our SOC 2 program runs continuously, not in annual bursts. Our DPA is a living document that incorporates feedback from every enterprise deal. Our security questionnaire responses are maintained in a database that we update with every infrastructure change.

Enterprise buyers are not trying to block deals. They are trying to protect their organizations. Meet them where they are, with complete and accurate documentation, and the process works.