AI Procurement Governance: A Checklist for Buying Agentic Software

# AI Procurement Governance: A Checklist for Buying Agentic Software

Buying ordinary SaaS is partly a workflow and data decision. Buying agentic software is also an execution decision. The product may read documents, call tools, generate code, contact customers, or make changes in systems your team already depends on. Procurement should therefore ask about authority, not only features.

This does not require treating every AI product as a special emergency. It requires a repeatable way to distinguish a low-risk writing assistant from a tool that can move data or trigger business processes.

Recent model-security disclosures make the timing practical rather than theoretical. OpenAI published a summary of third-party cyber evaluations on August 4, 2026, emphasizing the role of independent assessment and the limits of individual evaluation results. [Its disclosure](https://openai.com/index/third-party-cyber-evaluations-involving-openai-models/) is not a vendor scorecard for your procurement decision. The durable lesson is to request evidence, scope, and operating controls instead of relying on a headline claim about safety.

Classify the purchase by authority

Start with what the product can do after it is connected. A tool that drafts a proposal from user-provided text is different from one that searches customer records, creates invoices, or opens pull requests.

Use four authority levels:

| Level | Product behavior | Procurement posture |
| --- | --- | --- |
| Assist | Produces suggestions a person copies elsewhere | Standard privacy and security review |
| Read | Retrieves company data or connected context | Data-access and retention review |
| Draft | Creates a change for later review | Access, provenance, and approval review |
| Act | Sends, modifies, deploys, purchases, or deletes | Full workflow, identity, audit, and exit review |

Classify the highest authority the product could exercise, not the first use case a sales demonstration shows. A “read-only” product with a broad OAuth grant may still be able to expose high-value data.

Ask for a system map, not a feature list

A vendor should be able to explain how a request moves through its system. Request a simple diagram that identifies the user, the model provider, retrieval stores, sub-processors, integrations, logs, and final action destination.

Then ask where data is stored, whether it is used to improve services, how tenants are separated, how deleted content is handled, and which data leaves your region. Request the current documentation or contractual terms, not a verbal assurance.

For integrations, ask whether the application uses delegated user access, a shared service account, or a vendor-managed credential. The answer changes revocation, auditing, and offboarding obligations.

Evaluate controls at the action boundary

The important question is not “Does the product have human-in-the-loop?” It is “Which action is paused, who approves it, and what information does the approver see?”

Good controls are specific:

• A user reviews the exact recipient and content before an external message is sent.
• A manager approves a production change outside the agent’s own conversation.
• A policy blocks access to unapproved tools and records the reason.
• A sensitive action uses a narrowly scoped, expiring credential.
• A change is reversible and has a named rollback owner.

Weak controls are vague: “The model is aligned,” “admins can monitor it,” or “users can override results.” Those statements may be true, but none explains how an unwanted business action is prevented.

Make data handling testable

Procurement questionnaires often ask whether data is encrypted. Keep that question, then go further.

Test a representative workflow with non-sensitive sample data. Confirm what appears in prompts, tool logs, support dashboards, exports, backups, and analytics. Ask whether administrators can redact a record, whether retention is configurable, and whether a legal hold changes deletion behavior.

If the product supports retrieval-augmented generation, inspect how documents are segmented and permission-filtered. A secure source system is not enough if the retrieval layer can return content a user should not see.

Price the operating work honestly

The subscription fee is only one part of the cost. Teams also pay for identity integration, access reviews, vendor management, staff training, incident response, workflow design, and ongoing evaluation.

Create a simple ownership table before approval:

| Responsibility | Named owner | Evidence |
| --- | --- | --- |
| Business outcome | Workflow sponsor | Success metric and stop condition |
| Data access | Data owner | Approved sources and classification |
| Technical control | Security or platform owner | Identity, logging, network policy |
| Quality review | Functional lead | Sampling plan and escalation path |
| Vendor relationship | Procurement owner | Terms, renewal, and exit plan |

If a row has no owner, the product is not ready for broad deployment.

Plan the exit before the pilot

Agentic products can accumulate prompts, task histories, tool configurations, and automations. Before onboarding, understand how to export useful artifacts, revoke all access, delete retained data, and replace essential workflows.

An exit plan should state the contract notice period, data export formats, credential revocation steps, retention commitments, and who verifies completion. It should also include a manual fallback for the business process. A tool that cannot be safely turned off is not merely sticky; it is operationally risky.

A lean approval workflow

For a low-authority product, use a short review: owner, data class, terms, test account, and renewal date. For read or draft authority, add integration review, logging requirements, and a limited pilot. For action authority, require a workflow design review, approval boundary, incident response path, and periodic recertification.

This proportional approach prevents two failure modes: blocking useful low-risk tools with an enterprise-sized process, and treating a high-authority automation like a note-taking app.

Procurement questions to take into the meeting

1. Which systems can the product read, write to, or invoke?
2. What credential model does each integration use?
3. What exact actions require human approval?
4. What logs can our administrators retrieve, and how long are they retained?
5. Which sub-processors and model providers handle our data?
6. How do we restrict tools, destinations, and data sources by team?
7. How do we revoke access and export or delete records at exit?

These questions turn AI procurement from a promise-based conversation into a manageable operating decision.

Treat evaluation as ongoing evidence

The initial review cannot prove that a product will remain suitable. Models, integrations, sub-processors, pricing models, and default settings can change after purchase. Add a renewal checkpoint that asks whether the product’s authority has expanded, whether the workflow still has a business owner, and whether incidents or quality reviews uncovered a different risk than expected.

For agentic features, collect small samples of real outcomes during a pilot. Look for false actions, missed exceptions, confusing handoffs, and cases in which users trusted a confident answer without checking the source. The goal is not to create a perfect benchmark. It is to find the operating limits that the original demo did not reveal.

When the evidence changes, adjust access before expanding usage. Narrowing a tool’s permissions, disabling an integration, or requiring an additional approval is a normal control response, not a failed purchase. A vendor relationship is healthiest when the business can make those choices without losing access to its own data or essential process knowledge.

Keep the pilot bounded

Choose one team, one data set, one integration, and one measurable outcome for the first deployment. Publish a stop condition before launch: a security concern, repeated quality failure, or inability to explain an automated action should pause expansion. A bounded pilot provides evidence for the next decision and prevents early enthusiasm from becoming a company-wide permission grant.

Sources

• [OpenAI: Third-party cyber evaluations involving OpenAI models](https://openai.com/index/third-party-cyber-evaluations-involving-openai-models/)