What spending limits should we put on an AI assistant that can buy things?

Start with £0 of independent purchasing authority. Let the assistant research options, compare approved suppliers and prepare a basket, while a person approves the purchase in your existing system. Increase authority only when a narrow, repeatable buying task has passed realistic tests and its limits are enforced outside the language model. There is no universal safe allowance for a UK small business.

A purchasing assistant introduces a different risk from a writing assistant. It can create an actual financial commitment, send a delivery address to a supplier, accept terms or start a subscription. A wrong answer is inconvenient; a wrong order can take money out of your account or disrupt a customer job. The purchasing boundary needs to cover those commitments, not simply the final card payment.

The National Cyber Security Centre's guidance on agentic AI recommends starting with tightly bounded, low-risk pilots, applying least privilege and maintaining human accountability. That is an argument for restricting what the assistant can do, not merely asking it to be careful. A prompt saying “never spend more than £100” is not a reliable financial control if the connected account can spend £10,000.

Before choosing a number, decide which tasks genuinely need AI. Reordering a fixed quantity of approved stationery below a fixed stock level may be better handled by ordinary purchasing rules. Microsoft Power Automate, an existing accounting-system approval route or a supplier's reorder facility may meet the need without giving a language model discretion over what to buy.

A useful policy combines limits per order, per day and per month with an overall pilot allowance. Include pending orders and reserved amounts, not just settled payments. Otherwise two purchases started together can each appear to fit within the same remaining budget. Enforce the shared budget centrally across assistants, staff accounts and purchasing channels that belong to the workflow.

Here is an illustrative policy, not a market benchmark or a recommendation for every business: an assistant may reorder approved stationery up to £40 per order, £100 per day and £300 per calendar month. The pilot stops once total committed spending reaches £300, even if the month has not ended. The order amount includes VAT, delivery and any fees. A £38 basket with £6 delivery does not fit a £40 ceiling.

These figures only make sense if your business can comfortably absorb an incorrect permitted order and the items are easy to return. An engineering firm buying safety-critical parts needs different restrictions from an office buying printer paper. Set the maximum loss you could accept from a single mistake, then check whether repeated mistakes could exceed that amount before someone notices.

Ban splitting a purchase into smaller orders to evade approval. Aggregate related purchases for the same job or purpose, and require review when repeated orders approach the cumulative limit. Define how refunds affect the allowance: do not immediately restore spending capacity on the strength of a promised refund that has not arrived. Currency conversion and supplier fees also need a buffer or a stop for review, rather than an optimistic estimate.

Money is only one dimension of permission. Specify approved supplier accounts, permitted product codes, delivery addresses and quantities. A £20 purchase of an unsuitable chemical or an unauthorised software subscription can create more trouble than a £100 order of familiar office supplies. For a first pilot, exclude new suppliers, gift cards, cash equivalents, bank transfers and purchases of regulated or safety-critical goods.

Keep supplier onboarding and changes to payment details with a separate person. An assistant should not be able to discover a supplier, approve that supplier, change its bank details and pay it within the same workflow. Verify a requested bank-detail change through a previously trusted contact route, not the phone number inside the change request. An apparently convincing invoice or email is not evidence of authority.

The UK context makes that separation worth taking seriously. UK Finance's Annual Fraud Report 2026 release recorded £576.4 million in authorised push payment fraud losses during 2025, including £75.6 million in business losses. Those figures describe payment fraud across the reporting population, not losses caused by AI purchasing assistants. They show why adding purchasing automation should not weaken established payment checks.

Subscriptions require their own rule. A £15 monthly fee is not just a £15 commitment if the minimum term is twelve months. Require human approval for recurring charges, free trials that convert to paid plans, financing, renewals and changes to contract terms. Check total contractual commitment, cancellation rights and data-sharing terms. A low card limit cannot prevent an assistant from accepting an expensive obligation through an account with invoice billing.

Use a business-owned purchasing identity with restricted permissions, not the owner's normal shopping login or a broadly privileged finance account. Where your existing provider supports them, restricted virtual cards, merchant controls and purchase-order approval limits can help. Verify what the provider actually enforces: a merchant-category restriction is not the same as an allowlist of specific suppliers or products.

The assistant should submit a structured purchase request to a separate control that checks supplier, item, quantity, price, budget and approval status. That control should reject missing or ambiguous fields. If it cannot retrieve the current budget or confirm the supplier, the result is “do not purchase”, not “use the last remembered balance”. The assistant must not have permission to edit its own limits or switch to an unrestricted payment method.

A meaningful human approval shows the actual basket, supplier identity, full delivered price, business purpose, delivery address and any recurring terms. Approve that specific request, with a short expiry, rather than giving a general “yes” to whatever the assistant buys next. If the supplier, amount or terms change after approval, stop and ask again. Keep the approver separate from the mechanism that requests an exception.

Protect against duplicate ordering when a checkout or API call times out. Check whether the original order exists before trying again, and use a stable request identifier where the purchasing platform supports it. A timeout means the outcome is unknown, not that the purchase failed. This distinction matters when automation can retry faster than a person can inspect the statement.

Test in a sandbox or with spending disabled before connecting real purchasing authority. Include an order just above the limit, several simultaneous orders, an unexpected delivery fee, a substituted product, a repeated request and a supplier page containing instructions to ignore your rules. External descriptions, emails and documents are material to evaluate, never permission to change the purchasing policy.

Check that the controls refuse every prohibited case even when the assistant recommends proceeding. Record the test inputs, expected outcome, actual outcome and responsible reviewer. Then run a limited live pilot with a named owner checking each order. Do not increase the allowance just because the assistant sounds confident or because a supplier demonstrates a successful checkout on a prepared example.

Keep records of requests, approvals, rejected attempts, order references and refunds. Alert the owner when the assistant reaches its allowance, encounters a new supplier or attempts a prohibited action. Avoid collecting unnecessary personal information in these records. UK data protection duties still apply when names, addresses or other personal data pass through the assistant and its suppliers.

A practical stop button must revoke purchasing access at the payment or integration layer. Asking the assistant to pause is not enough. Name a deputy who can disable the account while the owner is unavailable. After a suspected incorrect or fraudulent order, stop further purchases, contact the supplier and payment provider promptly, preserve relevant evidence and inspect outstanding orders. Re-enable only after the cause and control gap are understood. Do not assume that reimbursement or a refund is guaranteed.

Do not allow autonomous purchasing if you cannot identify the full financial commitment before checkout, enforce a shared budget or stop the workflow promptly. Keep human approval where a mistake could affect safety, regulated activity, a major customer commitment, staff employment or access to sensitive information. The size of your company does not make those consequences less serious.

It is also a poor fit when purchases are infrequent, highly negotiated or usually need judgement about alternatives. Automating three complicated purchases a month may save less time than reviewing its exceptions. An assistant that prepares a comparison and a draft purchase request can still be useful without being authorised to place the order. That is a valid finished solution, not a failed attempt at full autonomy.

For a supplier proposal, ask for a demonstration that exceeds the limit and is blocked by the purchasing system. Ask who can alter the policy, how simultaneous purchases are counted, how subscriptions are handled and what happens after a timeout. If the only safeguard is a paragraph in the assistant's instructions, the proposed system is not ready to control spending.

The sensible first decision is usually modest: one repeatable category, existing approved suppliers, clear order limits and human review. Measure time saved after counting checking and exception handling. Increase authority only where the evidence justifies the additional exposure. If you want help assessing that boundary, start by reviewing your current purchasing process and its controls, rather than buying an autonomous assistant first.