Seats Without Signatures: Auditing AI Assistants Before the Next UK Renewal
Photo: Foreign, Commonwealth & Development Office, CC BY 2.0, via Wikimedia Commons
AI assistants have moved from novelty to line item. In many UK organisations, Copilot-style tools now sit inside productivity suites, contact-centre software, developer environments and finance systems. The renewal notice may arrive as a modest per-seat uplift, but it often lands with little evidence beyond enthusiasm from an initial pilot. That is not a reason to ban tools staff value. It is a reason to audit them seat by seat before procurement signs again.
Begin With the Notice, Not the Demonstration
The starting point should be the renewal notice and the contract behind it, not a fresh vendor demonstration. Procurement teams should establish the licensed seat count, the renewal date, any auto-renewal clause, the notice period and the true-up mechanism. They should also check whether the agreement bundles the assistant into a wider platform commitment, because that can make a dormant seat look cheaper than it is. The audit needs a paper trail: contract, invoice, usage report and a named business owner for each cohort of users.
Question One: Which Seats Are Actually Active?
Vendor dashboards are useful but rarely sufficient. A seat may show activity because a user opened the assistant once, or because a background process generated a prompt. UK IT teams should define active use in plain terms: for example, a minimum number of meaningful sessions per month, or use within a named workflow. Cross-check the vendor report against single sign-on logs, endpoint telemetry and service-desk tickets. Segment the estate by role, department and pilot cohort. The aim is not to punish light users but to separate genuine dependency from passive entitlement.
Question Two: What Work Would Not Happen Without It?
Cost control improves when the conversation moves from licence utilisation to business evidence. Managers should be asked which tasks the assistant supports, how often those tasks occur and what staff did before the tool was available. Anecdotes are acceptable at first, but they should be sampled and tested. Look for workflows where the assistant reduces drafting time, improves first-line response quality or helps smaller teams cover more ground. If the honest answer is that staff would simply revert to an existing tool with little disruption, that seat belongs in the review pile.
Question Three: Who Approved the Data Boundaries?
An AI assistant is only as safe as the permissions beneath it. Before renewal, security and information-governance teams should confirm what the tool can reach, how prompts and outputs are retained, whether data is used for model training and how sensitivity labels are enforced. In Microsoft 365 or Google Workspace estates, oversharing can be inherited from years of permissive site settings. A renewal is a sensible moment to test whether the assistant can surface content that the user should not see. If the answer is uncertain, the contract should not be renewed without remediation.
Question Four: What Does the Contract Say About Exit and Downshifting?
UK buyers should read the exit terms before they need them. Can the organisation reduce seats at renewal, or is there a minimum commitment? What notice is required to avoid auto-renewal? How quickly can the vendor delete tenant data, and will it provide an export? Are there termination assistance clauses or penalties for early exit? The audit should also test whether the assistant can be switched off without breaking core collaboration, email or document workflows. A tool that cannot be downshifted cleanly is a procurement risk, even if usage is currently strong.
Question Five: What Is the Fallback If Seats Are Cut?
Removing a seat is not the same as removing a dependency. Some staff will have built habits around the assistant, and a sudden withdrawal can create quiet productivity losses elsewhere. The fallback plan should identify alternative tools, template libraries, review steps or process changes for each cohort. It should also say who supports affected users and how requests for reinstatement will be handled. This is where IT and business leaders can avoid a false choice between paying for every seat and banning the tool outright.
Question Six: Who Owns the Decision After the Audit?
The final question is governance. Renewal should not default to the platform owner or the most enthusiastic pilot sponsor. A small panel drawn from IT, procurement, finance, security and the relevant business unit should review the evidence pack and record its decision. That decision may be to renew all seats, reduce the estate, move to a lower tier or run a time-boxed extension. What matters is that the rationale is documented and can be revisited at the next renewal.
A Practical Sequence for UK Teams
For a renewal due in 2026, start the audit at least 90 days before the notice deadline. Use the first 30 days to gather contracts and usage data, the next 30 to interview users and test data boundaries, and the final 30 to negotiate and secure approvals. Keep the evidence concise: seat count, active-use definition, business cases, risk findings and exit options. The output should be a decision, not a dashboard.
AI assistants can earn their place in a UK software estate, but they should not do so by inertia. A seat-level audit gives finance a defensible number, gives IT a clearer view of dependence and gives staff a fair hearing. The point is not to resist the tools. It is to pay for the ones that are doing real work.