Most organisations recognise that AI matters. There is no shortage of ambition or ideas.
The harder question comes after the first promising result: how do we make this work across the business without repeatedly rebuilding what sits underneath it?
Giving people access to an AI tool, running a proof of concept or building an impressive demonstration can be a valuable start. Turning that promise into everyday operations requires trust, integration, governance, cost control and a foundation that supports the next use case.
We're seeing organisations grapple with disconnected pilots, repeated integration work, uncertain costs and sensitive information appearing in unapproved tools. Even when a use case succeeds, the path to broader adoption is not always clear.
The challenge is how to accelerate AI adoption while keeping control of it.
For boards, executives and technology teams, these are the six questions I believe matter.
1. Trust: Can we understand, check and take responsibility for AI's work?
People need confidence before they will rely on AI in their work.
That confidence comes from knowing what information AI can access, who has permission to use it, how its outputs can be checked and when a person needs to review or approve the result.
Leadership also needs clear accountability. If AI contributes to a decision or takes an action, can we trace what happened and identify who was responsible?
Identity, permissions, records of activity and human oversight all contribute to trust. Controls should reflect the task: drafting an internal summary carries different consequences from approving a payment or communicating advice to a customer.
With appropriate controls built into the foundation, organisations can give people more freedom to use AI confidently.
Governance should be the enabler, not the handbrake.
2. Integration: Can AI work safely with our systems, data and processes?
Much of an organisation's knowledge is spread across different places: customer information in one system, policies in another, project history in SharePoint and operational data in business applications.
Making that information useful requires organisational context: which documents belong to which customer or project, which decisions have already been made and who is responsible for the next step. AI needs access to that context through connections that preserve existing permissions and information boundaries.
Consider a project manager preparing a customer update. AI might need the original proposal, recent correspondence, delivery progress and outstanding issues. A useful update depends on bringing that context together, with someone reviewing and approving it before it goes to the customer.
An orchestration layer coordinates those steps between models, business systems and people, from retrieving information to routing the draft for approval. This is how AI moves beyond chat and becomes part of how work gets done.
3. Foundation: Are we building on shared foundations or rebuilding them every time?
The first AI project often involves significant groundwork: connecting data, configuring models, establishing permissions, setting up monitoring and working through security requirements.
Start with a worthwhile business problem, a clear owner and an outcome you can measure. Build the foundations needed to deliver it, with reuse in mind, so investment follows demonstrated value.
Shared connections, identity controls, model access, workflow capabilities and governance patterns form the harness around AI: the tools and controls that let a model work usefully and safely within the organisation. Each use case still needs configuration, testing and appropriate oversight, but it should not require the entire foundation to be built again.
Consider a team that uses AI to help staff find internal policies. Another team then wants help preparing customer proposals. If both separately build document connections, access controls and monitoring, the organisation pays again for common groundwork. Reusing those foundations lets the second team focus on what its process actually needs.
The first project should do more than solve its own problem. It should make the second easier to deliver.
4. Cost control: Can we see, predict and manage the total cost?
Model pricing is only one part of AI's economics. Integration, engineering, licences, security, testing, support and ongoing monitoring all contribute to the total.
Organisations need visibility into what a workflow costs to run, what drives that cost and how it changes as more people use it.
Managing those costs means choosing suitable models for different tasks, setting sensible usage limits and measuring spend against business outcomes. A more capable model may justify its expense for a complex task; a simpler one may be sufficient for routine processing.
Commercial terms matter too. Per-seat, usage-based and platform pricing create different economics as adoption grows.
The aim is to make deliberate choices, keep costs predictable and ensure wider adoption delivers worthwhile value.
5. Freedom: Can we change providers, or are we building in dependency?
Models, prices and business requirements will continue to change. Organisations need room to respond.
That starts with keeping business knowledge, system connections, permissions and workflows as independent as practical from any one model provider.
Changing models still requires testing: they differ in capability, behaviour and supported features. A flexible foundation should reduce the work involved and allow different models to serve different needs.
This reduces the risk of a vendor choice becoming an architectural dependency, where changing provider means rebuilding the systems and workflows around it.
Every platform introduces dependencies, including SmartSpace. Ask what knowledge and components you can take with you, what switching would involve and what it would cost.
The goal is not to predict what AI will look like next. It is to build in a way that assumes it will change.
6. Momentum: Are our pilots building capability or accumulating technical debt?
The number of pilots launched tells us little about the value an organisation gets from AI. A pilot can demonstrate potential while leaving behind another isolated application, duplicated connection or service to maintain. Without a plan for reuse, support or retirement, that complexity can become technical debt.
A better starting point is whether people are using the capability and whether their work is improving. Are they saving time, producing better outputs, reducing delays or serving customers more effectively?
Each capability needs someone responsible for adoption, performance and ongoing improvement. People also need support to learn how to use it well.
Alongside those outcomes, is delivery becoming easier? Can another team reuse what has been built? Are successful workflows reaching production sooner?
A pilot can teach us something valuable even if it does not proceed. The important thing is to carry that learning forward.
Momentum comes from useful outcomes, growing confidence and foundations that make the next worthwhile initiative easier.
The model is not your AI strategy
Model selection matters, but it is one part of a wider strategy.
Lasting value comes from connecting AI with your organisation's knowledge, systems, people and processes, supported by appropriate governance and clear business goals.
That is the capability organisations need to retain control over: how their knowledge is accessed, how work gets done and how they can adapt as technology changes.
Where SmartSpace fits
These questions have shaped my thinking as we've built SmartSpace: how do we help a team solve a useful problem today while making the next one easier to deliver?
SmartSpace provides a governed AI foundation inside your Azure environment, connecting your systems, data and organisational context with AI workflows and human approvals.
Workspaces give teams a place to ask questions, work with connected information and use workflows to complete tasks. Shared infrastructure brings together identity, permissions, governance, model access and connectivity, giving teams common foundations to build on.
Start with a problem worth solving. Prove its value. Use what you learn and build to make the next project easier.
The real test: is the tenth use case easier to deliver than the first?
If you're ready to find out, start with a scoped first use case built on foundations that carry forward.
