AI Agent Procurement: What Legal, IT and Finance Each Check

The AI agent procurement process works when Legal, IT and Finance all review the same short description of the agent's role, data, tools and limits, and each answers a fixed set of questions against it. It stalls when each function receives a different vendor deck and raises open-ended concerns one after another. Agree the shared description first, then run the three reviews in parallel.

Key takeaways

• Write one shared brief before any review starts, so Legal, IT and Finance judge the same facts.
• Legal checks what the provider may do with your data, who owns what, who is liable and how you exit.
• IT checks identity, permissions, logging, failure handling and who can pause the agent.
• Finance checks cost drivers, caps, hidden internal effort and how value will be observed.
• Record every conflict and its resolution in the contract or statement of work, not in email threads.

Why does AI agent procurement stall?

Most software purchases ask one question: does this tool do the job at an acceptable cost? An AI agent adds several more. It acts on behalf of the company, it holds credentials, it may remember what it has seen, and its behavior can change when a model underneath it changes. Each approving function sees a different slice of that, and none of them sees all of it.

The usual failure pattern is sequential review. The business sponsor sends a vendor proposal to Legal. Legal returns comments weeks later. IT then discovers the agent needs access that Legal assumed would not exist. Finance sees a usage-based fee only after the scope has already moved. Every handoff restarts the conversation, and the sponsor loses momentum.

The opposite failure is also common: a team under pressure skips a function. A pilot launches on a personal login, with a provider whose data terms nobody has read, and the cost shows up later as a surprise. Neither stalling nor skipping is a sign of a careless company. Both come from the absence of a shared starting document and a clear list of what each function owns.

What goes into the shared brief?

The brief is one or two pages, written by the business owner of the role, not by the vendor. It does not need to be elegant. It needs to be specific enough that three different reviewers reach the same understanding of what is being bought. If you have not yet written a role description, start there, and keep the vocabulary consistent with your AI agent statement of work so the brief can feed the contract later.

Use this order:

• Role: the one job the agent will do, in a sentence a new employee would understand.
• Data: which systems and document types it will read, and whether any contain personal, financial or confidential material.
• Tools and actions: what it can do beyond reading, such as drafting emails, updating records or sending messages.
• Approval boundaries: which actions need a named human to approve before they happen.
• Memory: what it retains between tasks, where that is stored and who can delete it.
• Success criterion: one observable result that tells you whether the agent is worth keeping.
• Owner: the person accountable for the agent after launch.

Once the brief exists, send it to all three functions on the same day with the same request: answer your list of questions, and flag anything the brief does not let you answer. Gaps in the brief are cheap to fix. Gaps found after contract signature are not.

What should Legal check?

Legal is usually asked to review a contract. For an agent, the more useful task is to review what the contract permits the provider, and the providers behind it, to do with your information and your name. These are the questions worth asking.

• Does the provider, or any model provider it relies on, train on or retain our data, and is the answer in the contract rather than only on a web page? The article on whether your AI provider trains on your company data covers how to get this in writing.
• Which party is controller and which is processor for any personal data the agent touches, and who are the subprocessors?
• Where is data stored and processed, and does that match our contractual and regulatory obligations?
• Who owns the agent's configuration, instructions, knowledge files and outputs?
• What happens to our data and configuration when the contract ends, and in what format do we get them back?
• If the agent sends a wrong message or takes a wrong action, what liability applies and is the cap acceptable for this use case?
• Does the use case touch rules on automated decisions, hiring, credit, health or customer communication, and does anyone need to be told that an AI is involved?
• What must the provider tell us after a security or data incident, and by when?

Two habits help Legal move faster. First, tie each question to a line in the brief, so the answer can be a specific clause or a specific requested change. Second, separate must-have terms from preferences. If everything is a blocker, the vendor cannot respond usefully and the sponsor cannot judge what is negotiable. For a framework to organize risk language across functions, the NIST AI Risk Management Framework is a neutral reference, and the EU AI Act overview is worth consulting if your use case involves people in the European Union.

What should IT check?

IT is protecting the company's systems and accounts from a new kind of actor. The central idea is that the agent should be treated like a staff member with a narrow role: its own identity, its own permissions, a record of what it did and a way to stop it. The questions below follow that idea, and the security review of an AI agent provider goes deeper on the provider side.

• Does the agent have its own identity and accounts, or does it borrow a person's login?
• What is the narrowest set of permissions that lets it do the role, and who approves any expansion?
• Who holds the model API keys and integration credentials, the company or the provider? This matters for exit as much as for security.
• What is logged: inputs, tool calls, approvals, outputs? For how long, and can we export it?
• How does the design treat untrusted content such as inbound emails, web pages or uploaded files that may carry hidden instructions? The OWASP guidance on LLM applications describes prompt injection and the controls that reduce it.
• Are approval steps enforced by the system, or only requested in the agent's instructions? An instruction is not a control.
• What happens when a model version changes, an integration fails or a vendor service is unavailable: fallback, rollback, notice?
• Who responds to an incident, and how quickly can we pause the agent ourselves?

IT should also ask where the agent sits in the wider environment. A one-page map of systems, data flows and the agent's connections makes this review much shorter, and the guide to drawing your AI stack as a one-page architecture map shows one way to produce it. If the company has no dedicated IT function, the same questions still apply. Someone must own them, whether an operations lead or an outside adviser.

What should Finance check?

Finance is rarely worried about the headline fee. The concern is whether the total cost can be forecast, capped and compared to a result. Agents bring variable costs (model usage, integrations, volume of tasks) and fixed ones (setup, support, review time), and contracts split them in different ways.

• What drives cost: seats, usage, a recurring retainer, model consumption, integration fees? Which of these are passed through at cost and which are marked up?
• Is there a cap, an alert or an approval step when usage exceeds forecast?
• What sits outside the contract: internal time for review, data cleanup, training, change management and ongoing oversight? The article on the total cost of owning an AI agent lists these.
• What unit will we measure, such as cost per resolved request or per document processed, and who tracks it? The FinOps Foundation's material on unit economics is a helpful way to think about this.
• What are the term, renewal and exit conditions, and are there minimum commitments?
• Who is the accountable budget owner, and what outcome would lead us to stop or change course?

Finance can also help the sponsor avoid a quiet trap: a pilot that proves the agent works but never states what working is worth. If the success criterion in the brief is not observable, Finance cannot judge the investment, and the question returns at renewal time with less goodwill.

What does one request look like when all three reviews collide?

The following is an illustrative scenario, not a real case.

A distributor's operations lead wants an agent to read supplier delay emails, draft replies and update an internal tracker. She writes the brief and sends it to Legal, IT and Finance on the same day.

Legal finds that the draft terms allow the provider to retain prompts for service improvement, and asks for a written exclusion. IT notices the agent would run from the operations lead's own mailbox. It asks for a dedicated mailbox with read and draft rights, with sending gated behind a named approver. Finance sees usage-based fees with no ceiling and asks for a monthly cap and a usage report that matches the unit named in the brief.

None of these requests conflicts with another, and none requires restarting the evaluation, because each reviewer answered against the same description. The three changes are written into the statement of work as numbered requirements. Had the reviews run in sequence, each change would likely have reopened the others.

Here is how Be Human handles the same problem. A first engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion. That definition is the brief described above, so Legal, IT and Finance receive the same document. Managed operations then cover monitoring, recurring evaluations, integration maintenance, permission review and incident response, which gives each function something concrete to point to in the contract. Changes after launch pass through a controlled process rather than being made informally.

Frequently asked questions

Who should lead AI agent procurement? The business owner of the role should lead, because they can answer questions about purpose, data and success. Legal, IT and Finance each own their review but should not have to reconstruct the use case. If no one is clearly accountable, name a coordinator whose job is to keep the brief current and track open questions.

Do we need all three reviews for a small pilot? Yes, but proportionately. A pilot that touches no personal data, uses a dedicated account and has a spending cap can be reviewed quickly, but the questions still need answers. The risk of a small pilot is that it becomes a permanent system without ever having been reviewed.

Can we reuse our existing vendor assessment template? Partly. Standard sections on security, privacy and financial terms still apply. Add questions specific to agents: training on your data, agent identity, enforced approval steps, model changes, logging of actions and the right to pause the agent.

What if the vendor cannot answer a question? Treat silence as information. Ask for the answer in writing, and if the vendor still cannot provide it, either narrow the scope so the risk disappears or record it as an accepted risk with a named owner. Do not leave it unresolved and proceed.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.