Before the market
Start with the job, not the product
The National AI Centre’s first step comes before any product: be clear about the task, process or workflow that AI could improve, and be specific about the result you want. It aims for the simplest option that does the job, with complexity added only where the value earns it, and it notes that more control generally costs more money and effort, while a simple option is often enough.
Four routes
The four ways a business gets AI
The guidance sorts most business use of AI into four kinds and suggests starting with the first, moving on only for more control or capability.
| Type | What it is | Suited to, in the guidance’s view |
|---|---|---|
| 1. AI built into software | A feature inside software the business already uses, managed by that software’s provider; the AI is not bought separately. | Everyday tasks, quick setup and low risk. |
| 2. Standalone AI tools | Tools outside the business’s core systems, usually reached through a browser or an app, free or by subscription. | Trying AI out, low-risk tasks, or a few staff. |
| 3. AI integrations | AI linked to existing systems through integrations, connectors or APIs. | More capability without a fully custom build. |
| 4. Customised AI solutions | A solution an AI provider designs and builds for the business and its particular need. | Complex, higher-impact uses where control, data handling and accountability matter. |
Before you commit
Six checks before you subscribe, buy or build
The guidance lists six things to check whichever route is chosen. It warns that they matter even more when AI arrives inside familiar software through an update, because a team can miss the moment it should have checked.
- Cost and actual use. AI pricing can rise with use, so think about how often it will run, how many people need it, and whether the price moves with use, data volume or features.
- Terms of service and data use. Know what data the AI collects or uses, where it is stored and processed, whether it trains AI models, and who owns what the system produces.
- Fit with existing systems. Check that it works with current systems, whether it needs APIs or connectors, and whether it adds manual steps.
- Lock-in and flexibility. The more embedded AI becomes, the harder switching gets: consider exporting data, moving workflows, and what you would do if prices or terms changed.
- Support and reliability. Find out what support is included, how issues are reported and how fast they are answered, and how the vendor tells you about changes and outages.
- Risk and responsibility. Your business stays responsible whichever option it chooses, so work out what data the AI will draw on and where that data is kept, whether your data trains AI models, what could go wrong and how you would notice, who fixes problems, and how accountability is split between the business and its suppliers.
The supplier conversation
What a good answer looks like
The questions document is built in sections. Each gives questions for the supplier, what to look for in a good answer, and what to get in writing. It says there is no need to ask every question: focus on those closest to the task, especially where the risk or impact is higher.
| Section | A good answer shows |
|---|---|
| Managing risks and potential harms | The main risks explained plainly; a clear process for incidents, escalation and putting things right; risk controls that step up with business impact. |
| Transparency and explainability | Written limitations and known failure points; a practical explanation of outputs, not a “trust us”; ways for people to question and override what the system produces. |
| Accountability, roles and integration | A clear split of responsibilities; openness about subcontractors; integration and support that suit your own capability. |
| Data training, use and security | A clear account of where data flows and how it is used; the ability to limit or opt out of some uses; security that fits how sensitive the data is. |
| Testing, monitoring and performance | Evidence of testing rather than assurances; monitoring that fits how important the use is; clear handling of updates and change. |
| Human oversight and control | Clear points of human control for higher-impact uses; working override or stop controls; training that fits each role. |
| Fairness, inclusion and broader impacts | Evidence that fairness and impacts were considered; ways of monitoring and responding to issues; readiness to talk about limitations and trade-offs. |
| Exit, decommissioning and continuity | Clear processes for leaving and getting data back; reasonable timeframes for a transition or shutdown; continuity plans for critical systems. |
| Environmental sustainability (optional) | A system sized to fit the need rather than complex for its own sake, and a willingness to discuss environmental impact in practical terms. The document marks it optional but increasingly relevant. |
On paper
What to get in writing
Each section ends with what to capture. Among the items the document lists:
- timeframes for reporting incidents, and the escalation path;
- named contacts who are accountable;
- terms for who owns data, how long it is kept and how it is deleted;
- a clear statement on whether your data is used for training;
- who can override or shut down the system;
- exit and termination terms, with commitments on exporting and deleting data.
Each full list is in the National AI Centre’s questions document. The same habit runs through the Guidance for AI Adoption, whose first step under testing and monitoring is to ask the developer or supplier for proof that a system has been properly tested. Answers like these belong to the kind of record an AI register holds, practice 4 in the six essential practices; what the supplier says its AI can do also bears on claims about AI.
Back to the registerAll five guides, from accountability to licensees.