What should security review?
Security should review how credentials are stored, how tenants are isolated, what scope each integration requires, and how access is revoked. The revocation question matters most in practice: you should be able to cut access from your own systems without waiting for the vendor.
Ask specifically whether integration credentials are encrypted at rest and whether plaintext secrets can appear in logs or API responses. The answer should be unambiguous, and the mechanism should be described rather than asserted.
- Are integration credentials encrypted at rest, with keys held separately?
- How is one customer's data isolated from another's?
- Is access scoped per system and per property?
- Can we revoke access ourselves, immediately?
What should legal review?
Legal should focus on liability for actions taken, intellectual property in generated work, and data processing terms. The liability question is the one that is genuinely different from ordinary software: a system that publishes and spends raises the question of who is responsible when something goes wrong.
The defensible arrangement is that liability follows the approval. A human approved the action, the audit trail records who and when, and the vendor is responsible for the platform behaving as documented. Contracts that try to place responsibility for approved actions on the vendor tend not to survive scrutiny in either direction.
What should finance review?
Finance should establish how the bill behaves as usage changes, and get the answer in writing. Usage-based pricing is more predictable than it sounds when there is a hard stop, and considerably less predictable when there is overage billing.
Ask what drives the bill, what happens at the end of the allowance, whether unused allowance carries over, and whether spend limits are hard caps or alerts. On ftes.ai the model is a block of work metered in tokens with a hard stop at zero, which makes the worst case knowable in advance.
What should the exit terms cover?
Exit terms should cover the work product, the data, and the connected accounts. The most important of these is where the work product lives during the contract, not what gets exported at the end.
A Digital FTE that publishes into your content management system and writes into your ledger leaves you with the output automatically. One that keeps everything in its own environment leaves you with an export and a migration. Check this before signing, because it is not negotiable afterwards.
What is specific to autonomous systems?
Two procurement questions are specific to systems that act rather than advise. First, which actions can the system take without a human decision, by default and at the maximum autonomy level you might grant. Second, what is the hard limit on spend, and is it enforced by the platform or by a notification.
Get both in writing. They are the terms that determine the worst realistic outcome, and they are the ones that vendors describe loosely in conversation and precisely in documentation.
What does a reasonable evidence pack look like?
A reasonable vendor evidence pack contains the data processing terms, a description of the security controls actually enforced, the audit trail capability, the access model, and the commercial mechanics. It does not need to contain certifications to be credible, but it should be honest about which ones exist.
Treat a vendor who describes enforced controls precisely and says plainly which certifications they do not hold as more credible than one who implies compliance through vague badges. The first is checkable; the second is marketing.
What should the pilot clause and the success criteria say?
The pilot clause should say that the organization will run one function for two full cycles on the smallest plan that fits, with a recorded baseline taken before the first proposal, and that the decision to continue is the organization's alone, made from the comparison against that baseline. It should say what the comparison measures: outcomes in Targets, approval rate with send-back reasons, tokens consumed per role, and human hours on approval and setup, with the same quality metrics measured the same way before and after.
The success criteria should be written before the pilot, in the organization's own units, and should include what would count as failure: a cost per outcome above the baseline after two cycles, an approval rate that does not rise, or send-back reasons that point to a remit the vendor cannot support. Criteria written afterwards are rationalisations. On ftes.ai the plan can be changed or cancelled from the workspace at any time and there is no separate trial tier, so the pilot clause is mostly about the organization's own discipline: baseline first, two cycles, decision from the record.