AI tools for business workflows

Start from the task, not the model

The useful first question is not which tool to buy but which workflow to change. Choose something bounded and frequent, where the output can be checked quickly and a mistake is cheap to catch — drafting an internal summary, classifying incoming requests, extracting fields from a document. Avoid starting with the highest-consequence work, not because the technology cannot help there but because the cost of an unnoticed error is high and the learning is slower. Write down what success looks like for that task before anyone demonstrates anything: what the output has to contain, how long it should take, and who decides whether the result is acceptable.

• A bounded, frequent task rather than a general capability.
• A mistake that is cheap to catch while you are learning.
• Written success criteria before any demonstration.
• A named person who judges whether the output is acceptable.

What leaves your environment, and what happens to it

Data handling is the question that decides whether a tool can be used at all, and it should be answered before a pilot rather than during a security review. Establish whether the content submitted can be used to train models, whether that setting can be turned off contractually, how long inputs and outputs are retained, where they are stored, and who can access them. Confirm the distinction between a consumer product and an enterprise tier, because the defaults differ and the difference is usually about what happens to your data rather than which features exist. Then put the answers in the agreement rather than trusting the product page: a statement that prompts, uploads and outputs are excluded from training when the setting is enabled, the retention period for prompts, outputs, logs and backups, a deletion commitment with timing, and the list of subcontractors and storage locations. If the business handles regulated or personal data, that boundary needs to be written down before anyone pastes anything.

• Whether submitted content may be used for training, and how it is disabled.
• Retention period for prompts, outputs, logs and backups, in the contract.
• Consumer terms against an enterprise tier.
• An explicit list of data that must never be submitted.

Governance you can actually run

A policy nobody can follow is worse than none, because it creates the appearance of control. The recognised reference here is NIST's AI Risk Management Framework, published as AI RMF 1.0 on 26 January 2023 and deliberately voluntary, non-sector-specific and use-case agnostic. It organises the work into four continuing functions — Govern, Map, Measure and Manage — with a companion Playbook that lists suggested actions under each. Its trustworthy-AI characteristics are equally usable as a checklist: valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed. In a small or mid-sized business that becomes something modest and specific: one owner for AI use, a list of tools that are approved and a list that are not, a short acceptable-use statement staff have actually read, and a review that happens on a schedule rather than after an incident.

• One accountable owner for AI use in the business.
• An approved-tool list, and a statement of what is not approved.
• A short acceptable-use policy staff have read.
• A review on a calendar, not after something goes wrong.

The risk list is published, so diligence can be specific

Two public documents turn a vague security conversation into a checklist. NIST's Generative AI Profile, issued as NIST AI 600-1 on 26 July 2024, enumerates the risk areas a generative deployment should be assessed against: confabulation, data privacy, information integrity, information security, intellectual property, harmful bias, human-AI configuration, value chain, chemical, biological, radiological and nuclear information, dangerous content, environmental impact, and obscene content. NIST AI 100-2, the adversarial machine learning taxonomy published in January 2024, covers the attack side and the mitigations that go with it. OWASP's Top 10 for LLM Applications gives the control list: prompt injection, sensitive information disclosure, supply chain, data and model poisoning, improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses, misinformation, and unbounded consumption. Ask a vendor to map its controls to a named list and to show test evidence rather than a policy statement.

• Named risk documents, not a generic security questionnaire.
• A control mapping to OWASP's LLM list, with evidence.
• Who is accountable for each mapped control.
• How mitigation gaps are recorded and reviewed.

Vendor diligence beyond the feature

The questions that matter about an AI vendor are mostly ordinary supplier questions, with some new ones. Which subcontractors process the data, and are they disclosed? Is content used to improve models, and can that be switched off in the agreement? How is output retained, exported and deleted? What notice is given of a security incident, and to whom? Who is accountable if the output is wrong and a customer is affected? Two newer questions are worth adding. First, scope: European general-purpose AI obligations have applied since 2 August 2025 to providers of models trained above a published compute threshold, obliging them to keep technical documentation, run a copyright policy and publish a summary of training content — so it is reasonable to ask a vendor which of its models fall inside that regime and for that summary. Second, indemnity: some vendors publish an output indemnity, and Microsoft's Customer Copyright Commitment is the best-known example, but it is conditional on the customer having implemented the vendor's required guardrails and mitigations. Obtain the document, its scope and its exclusions rather than relying on the announcement.

• Subcontractors disclosed, with locations.
• Training use of content, and how it is disabled.
• Retention, export and deletion of inputs and outputs.
• The exact indemnity document, its scope and its conditions.

Human review and the record you keep

Decide where a person must review the output before it is used, and write it into the process rather than the policy. In practice the boundary follows consequence: internal drafts may need only a glance, while anything sent to a customer, used to make a decision about a person, or relied on for a legal or financial obligation should carry review by someone accountable for the outcome. Keep a record of what was produced by automation and who approved it. That record is what lets you answer a question six months later about why something was decided, and it is also how you learn whether the tool is helping.

• Named review points, tied to the consequence of being wrong.
• Customer-facing and decision-making output reviewed by a person.
• A record of what was automated and who approved it.
• A route for staff to flag output that looked wrong.

Piloting, then scaling on evidence

Run the pilot against the success criteria rather than against enthusiasm. Measure whether the output met the standard, how much time it actually saved once review is counted, who used it and who quietly stopped, and what had to be corrected. Then decide the licensing model for scale: per-seat suits a defined group, usage-based moves cost risk onto you and needs monitoring, and bundled inclusions inside software you already own are often the cheapest route to broader adoption. Expand only where the measured result justified it, and say so in writing, because the next decision will be made by somebody who was not in the pilot.

• Measure against the criteria set before the pilot began.
• Count the review time, not just the drafting time saved.
• Choose the licence model against expected usage, not list price.
• Write down what the pilot proved, for whoever decides next.

What to gather, and how HighGround helps

Bring the workflow you want to change and what a good output looks like, the data that workflow touches and any obligation attached to it, the tools already approved or already in use informally, and the person who will be accountable for the deployment. HighGround works as an advisor-assisted channel rather than a software directory, scoping a requirement around the task and the constraints that apply to it and sourcing through the AppDirect catalog. Fit cannot be judged responsibly without knowing what the tool would be asked to handle, so the data question comes before any shortlist. An inquiry places no order and commits you to nothing, and HighGround may receive compensation from a provider on a completed purchase.

• The workflow, and what an acceptable output has to contain.
• The data involved, and what must never be submitted.
• Tools already approved, and tools already in informal use.
• Who owns the decision, and who reviews the output.

A European risk tier now shapes what a vendor will tell you

The EU AI Act, Regulation (EU) 2024/1689, sorts systems by risk and then applies in sequence, which makes the dates the useful part of the exercise. Prohibitions and the definitions took effect on 2 February 2025, together with the AI literacy duty in Article 4, which requires providers and deployers to take measures to ensure a sufficient level of AI literacy among the staff operating the systems. Rules for general-purpose AI models and the Act's governance arrangements applied from 2 August 2025. The transparency obligations in Article 50 — telling people when they are interacting with certain AI systems, and marking certain synthetic or manipulated content — apply from 2 August 2026, the same date most of the Act's remaining rules begin to apply. High-risk obligations for Annex III systems are scheduled from 2 December 2027, and high-risk AI embedded in Annex I products from 2 August 2028.

• Prohibitions, definitions and the Article 4 literacy duty: 2 February 2025.
• General-purpose AI models and governance: 2 August 2025.
• Article 50 transparency, and most remaining rules: 2 August 2026.
• High-risk: Annex III from 2 December 2027, Annex I products from 2 August 2028.

A management system standard is not a safety certificate

ISO/IEC 42001:2023, published jointly by the International Organization for Standardization and the International Electrotechnical Commission in December 2023, specifies the requirements for an artificial intelligence management system: the governance, policy, roles and continual-improvement cycle an organisation runs around its AI. It is voluntary, and certification is carried out by an independent certification body rather than by the standards bodies themselves. Three things a buyer should keep apart. A conformance claim is a supplier stating that it follows the standard. A certification is an auditor assessing the organisation's management system against it. Product assurance is evidence about a particular model, application, control or accuracy level. A certified management system does not certify the safety, accuracy or lawfulness of every model and output that organisation ships, so it belongs in a supplier's evidence pack beside technical documentation, not in place of it.

• ISO/IEC 42001:2023 defines an AI management system, published December 2023.
• Certification is voluntary and issued by an independent body.
• Separate a conformance claim from a certification from product assurance.
• An organisation certificate does not certify a model or an output.

The model your workflow is built on can be retired

Versioning risk in an AI deployment is not hypothetical: providers deprecate models on a published timetable, name a shutdown date and expect the customer to migrate. OpenAI's deprecation policy, for example, sets minimum notice of at least six months before retirement for generally available models and at least three months for specialised variants of them, and exposes an optional shutdown date field on the models endpoint so a customer can monitor retirement programmatically. Pinning a workflow to a snapshot identifier removes silent drift between versions, but it does not remove the shutdown. That makes the procurement clause a migration plan: name the exact model or snapshot used in production, require deprecation notice through a specified channel, ask for the supported replacement and its migration documentation, and keep the prompts, system instructions, tool schemas and evaluation sets in your own hands so a change can be tested before it is accepted.

• A model becomes deprecated when the provider announces it, with a shutdown date.
• Minimum notice is vendor policy: OpenAI states six months, three for specialised variants.
• A snapshot identifier stops drift; it does not stop retirement.
• Keep prompts, tool schemas and evaluation sets under your own control.

What a zero-retention commitment covers, and what it does not

Retention is now a headline feature, so it is worth reading the definition rather than the claim. The enterprise position on the major platforms is that content submitted through the API is not used to train or improve models unless the customer opts in; OpenAI states that this has been its position since 1 March 2023, with a further tier that excludes customer content from the logs kept for abuse monitoring, subject to prior approval and additional requirements. The scope is where buyers get caught. Abuse-monitoring logs are the default retention, and OpenAI's documentation puts them at up to 30 days of API feature usage unless a longer period is required by law or needed to protect the service; application state is a separate category that exists because some features must persist data to complete a task. Ask the provider to define customer content, the covered endpoints, the abuse-monitoring exception, application-state retention, backups, support access, subprocessor locations and deletion timing.

• The first question is what counts as customer content, not whether training happens.
• No-training commitments are stated by tier and are worth checking by endpoint.
• Abuse-monitoring logs are the default retention unless a control is approved.
• Application state is a third category that persists data to complete a task.

PUT THE OPTIONS SIDE BY SIDE

Your comparison checklist

Common questions