What should we check before switching on an AI feature in software we already use?

Check the new feature's data access, processing terms, permissions, output risks, cost and off switch before enabling it. Treat it as a change to an existing service, not as an automatically approved extra. Start with a restricted trial only when a named person understands what changes and can reverse it.

The familiar logo is the trap. Your team may have used a CRM for years without allowing it to send customer correspondence to an external model. An AI assistant could introduce that processing even though nobody buys a new application. Equally, a feature that only drafts text from a short, deliberately supplied input may be a relatively modest change. Evaluate the actual feature, not the badge.

The UK government's AI Cyber Security Code of Practice provides a useful, specific reference. Provision 3.1.1 calls for security risks to be addressed when a new setting or configuration option is implemented or updated. This is a voluntary code, not a blanket legal certification or a requirement to commission a large audit for every toggle.

Write down one allowed purpose, such as suggesting a reply that an employee checks before sending. Also write down what is excluded: searching unrelated client folders, making refunds or committing delivery dates. If the supplier cannot explain which category its feature falls into, leave it off while you obtain the answer.

Ask what information the feature receives, where it is processed and which organisations receive it. Include prompts, retrieved files, attachments, conversation histories, generated answers and diagnostic logs. A statement that the main application is hosted in the UK does not establish that its AI processing happens in the same place.

Obtain the feature-specific terms and current subprocessor information. Check whether inputs or outputs are used for model training, whether any opt-out applies to your exact subscription, and whether that setting covers every model provider involved. No training does not mean no retention, no support access or no international transfer. Those are separate questions with separate answers.

The ICO's guidance on AI and data protection addresses accountability, transparency, lawfulness, accuracy and fairness. Its current page warns that the guidance is under review following the Data (Use and Access) Act. Use it as a starting point and check the current requirements for your proposed processing rather than treating an older article as definitive legal advice.

For personal data, establish the purpose, appropriate lawful basis, necessary information and relevant contractual arrangements. Assess whether the change is likely to create high risk requiring a data protection impact assessment. A DPIA is not automatically required merely because the feature says AI. Sensitive employee records, systematic monitoring or consequential decisions demand more scrutiny than an internal draft based on public information.

Do not test uncertainty by uploading a real confidential file. Start with synthetic examples or material you are authorised to use. Client confidentiality obligations can restrict disclosure even where the file contains no personal data.

Separate reading from acting. A feature that summarises the currently open record is different from one that searches the entire workspace. Both differ from an assistant that can send messages, update deals, create purchase orders or invoke connected tools. Ask for the permission list and check the defaults before accepting them.

The same UK code gives another concrete checkpoint: provision 2.6 says permissions on connected systems should be limited to what functionality requires and risk assessed. Apply that principle to your trial. Give it the smallest relevant data set and keep sending, deletion, payment and publishing permissions disabled unless those actions have separately justified controls.

Check access as an ordinary employee, not only as an administrator. Can a salesperson retrieve confidential HR material? Can someone working for one client obtain another client's documents? A supplier's assurance that the feature respects permissions is useful, but a controlled test of your real configuration is stronger. Fix existing oversharing before making it easier to discover.

There is also a difference between an answer containing hostile instructions and an authorised action. A customer email telling an assistant to ignore its rules must not become permission to export records. Where a feature reads external emails or documents, ask how the supplier handles malicious instructions and which actions remain impossible without approval.

Compare the AI option with the ordinary functions you already own. A standard saved search, report, template or rules-based workflow in Microsoft 365, your CRM or your accounting package may solve the problem without introducing a generative assistant. That is not a less ambitious decision. It may be the more reliable one.

A free trial can still consume staff time and create exposure. Ask whether the feature is included, charged per user, metered by consumption or bundled into an upgrade. Confirm VAT treatment, usage limits, overage rules, renewal terms and whether switching it off also stops billing. Do not assume a trial button creates a spending cap.

Use a small test set drawn from the work you actually intend to permit. Include a straightforward request, a missing-information case, conflicting records, an unauthorised-data request and a misleading document. Define the acceptable behaviour before reviewing the output. An assistant should sometimes decline to answer or ask for clarification rather than manufacture a convincing response.

Record time spent checking, correcting and escalating, not just time spent generating. Here is illustrative arithmetic, not a supplier quotation or a claimed client result: if 100 tasks save three minutes each, the gross saving is five hours. If review and rework consume four hours, the net saving is one hour. At an assumed internal labour value of £30 an hour, that is £30 of capacity value before any subscription charge.

That capacity is not automatically £30 of cash saved. It becomes commercially useful only if the time can actually be redeployed or avoids a real expense. Conversely, a modest time saving may still be valuable if it improves consistency without creating disproportionate risk. Decide what outcome you are buying.

Do not infer reliability from five pleasing demonstrations. Keep a record of the test cases, failures and limitations. Set a clear stop condition for disclosure, unauthorised action or repeated material errors, even if the average speed looks attractive.

Name a business owner who can approve the allowed use and a person responsible for administration. In a small company these may be the same individual, but the responsibilities still need to be explicit. A junior employee accepting a feature prompt should not quietly approve new access to everyone else's records.

Before rollout, tell staff what the feature is for, which information they may use and which outputs require checking. Give them a quick route to report a wrong answer or unexpected access. If customer information is processed differently, review the relevant notices and commitments rather than assuming existing wording covers every change.

Write a short approval record containing the feature name, account or plan, purpose, approved users, data scope, supplier evidence, settings, test results, cost owner and review date. Keep copies or dated links to the terms you relied on. A screenshot of the switch is not enough if nobody knows what it authorised.

Test disabling before relying on it. Establish whether switching off stops future processing only, whether it revokes connector access and what happens to retained prompts, indexes and generated material. Deletion may need a separate request or administrator action. Confirm the manual fallback so a service interruption does not leave work stranded.

Supplier updates can change models, permissions or defaults. Review meaningful changes before expanding the approved use. For related access decisions, see who should control AI access to email, files and CRM data. The aim is a small, understandable approval process, not paperwork that everybody bypasses.

Leave the feature disabled if you cannot establish what data it processes, who receives it or how access is controlled. Do the same if its minimum permission level exceeds the proposed task, if confidential information would breach a client commitment, or if there is no workable way to check consequential outputs.

A supplier's size is not a substitute for those answers. Neither is an assertion that thousands of other businesses use the product. Your responsibilities follow your data, users and decisions. A perfectly legitimate feature can still be unsuitable for a particular workflow.

Do not begin with autonomous hiring decisions, health information analysis, payment approval or safety-critical instructions simply because the button is available. These uses need specialist scrutiny and safeguards that a basic trial checklist cannot provide. If you have no qualified reviewer, keep those decisions outside the pilot.

On the other hand, a restricted drafting feature using non-sensitive information, clear terms and human review may justify a straightforward internal approval rather than an expensive consultancy engagement. The right response is proportionate assessment, not a universal ban. You do not need custom AI development merely to test whether an existing feature saves useful time.

If the supplier evidence is adequate, permissions are narrow, testing is satisfactory and the owner can stop the feature, approve only that bounded use. Expand later on evidence. If those conditions are missing, improve the conditions or use the standard software functions instead. If you want an independent second opinion, bring the feature documentation and a description of the intended task to a conversation with us.