AI tools are getting easier to buy. Building an environment where they can deliver value is the harder part.
How many conversations about AI in your organisation start with a product name? Copilot. ChatGPT. Claude. Gemini. Maybe a new agent platform someone saw demonstrated last week.
It is understandable. The tools are visible, the demos are impressive, and another model is always promising better reasoning, faster answers, or lower costs.
But before choosing the next tool, ask a more important question: What is it going to connect to?
Because an AI assistant on its own can only take you so far. To be genuinely useful, it usually needs access to what makes your organisation different: your documents, customer information, policies, applications, workflows, and business data. And once you start connecting AI to those things, the conversation changes. You are no longer simply choosing an AI tool. You are making decisions about integration, access, infrastructure, security, governance and cost.
From what we see working with Australian organisations, this is often the point where the gap between an impressive AI pilot and a sustainable AI capability starts to appear.
The model is only one part of the stack
It is easy to think of an AI strategy as a choice between models or vendors.
In practice, several layers are involved.
At the top are the AI productivity tools people interact with every day, such as Microsoft 365 Copilot, Gemini, ChatGPT, or Claude.
Below that are the AI applications you build to address specific business problems: internal knowledge search, contract review, customer onboarding, claims processing, document workflows, or agents that work across several systems.
Then there is the AI platform hosting and serving the models.
And underneath it all is the infrastructure that makes those layers manageable: identity, access, observability, security, and cost controls.
That distinction matters because buying a tool does not automatically give you a functioning AI environment.
You can give employees access to an excellent assistant tomorrow. But if it cannot reach the information they need, its answers will remain generic.
Connect it to everything without thinking carefully about permissions and data classification, and you create a different problem.
Which leads to one of the most useful questions leaders can ask when assessing an AI tool:
Ask what it can see, not just what it can do
Most product demonstrations focus on capability. Can it summarise this document? Write this email? Analyse this spreadsheet? Build this report? Those are reasonable questions. But once AI moves into an organisation, what it can see becomes just as important as what it can do.
Imagine an assistant being asked:
- What did we agree with this customer last year?
- Summarise our current position on this policy.
- Which projects are running behind schedule?
- What were our support issues for this account?
- Draft a response using our previous proposals.
The quality of the answer depends heavily on the systems and information the AI can access. That makes integration fundamental to usefulness.
But it also makes integration fundamental to risk.
An assistant connected to poorly governed information can expose documents to people who should never have had access to them in the first place. A tool using personal API keys can create problems when credentials leak or employees leave. An application that sends data through services no one is monitoring can quickly become difficult to audit. The goal is therefore not to connect AI to as much as possible.
It is to connect it deliberately.
Integration is where AI becomes operational
As organisations move beyond standalone assistants, integrations multiply quickly. An AI application may need access to SharePoint, Salesforce, Jira, an internal database, a customer platform and several APIs. If every project team builds those connections differently, you can end up with dozens of one-off integrations that all need to be secured, monitored and maintained. That is why we think one principle is particularly important:
One pattern, not fifty.
Rather than allowing every AI initiative to invent its own approach, organisations should establish a repeatable integration pattern. That might include an API gateway as the front door for AI applications, managed identities rather than personal API keys, consistent authentication, request logging, rate limits, cost attribution and shared development standards. The specific technology will vary. The principle should not. When teams use the same integration pattern, new AI applications become easier to build — and much easier to govern.
MCP is worth paying attention to
One development that could make this integration problem easier is the Model Context Protocol, or MCP.
Traditionally, connecting multiple AI tools to multiple business systems creates a growing network of separate integrations. Each new model or application may require another connector. MCP is designed to simplify that relationship by creating a common way for AI clients and tools to connect. Instead of building a separate integration for every combination, a system can expose an MCP server that multiple compatible AI clients can use.
The attraction is not simply technical elegance. It is the possibility of reducing integration maintenance while creating a more consistent way to control and audit how AI reaches organisational systems. MCP will not remove the need for good architecture. You still need to decide what AI can access, who can use it and what happens when something goes wrong. But if you are evaluating AI platforms and integration approaches now, MCP support deserves a place in the conversation.
Don’t let the tool decide the architecture
There is another trap we see in AI adoption: allowing the first product chosen to dictate every decision that follows.
A team adopts an AI assistant. It works well. Then the organisation starts building applications around the same vendor because it feels easier. Before long, tool selection has quietly become architecture. Sometimes that is perfectly reasonable. If you are deeply invested in Microsoft, AWS, or Google, there can be genuine advantages to using the AI services already integrated into those environments.
But that should be a conscious decision, not an accidental one. For each workload, consider what actually matters.
- Where does the data live?
- How sensitive is it?
- What does the AI need to connect to?
- How much integration effort is involved?
- What controls are required?
- What happens if you want to change provider later?
- And what will the workload cost when usage increases?
Different workloads can produce different answers. You don’t need one AI tool, one model, or even one infrastructure choice for the entire organisation.
What you do need is a coherent set of rules for deciding.
Tool sprawl is an integration problem too
Most organisations do not struggle to find AI tools. They struggle to stop collecting them.
One team prefers ChatGPT. Another starts using Claude. Microsoft Copilot appears through an enterprise agreement. Developers are testing APIs. Someone adds an automation platform. Another business unit has quietly signed up for something else entirely. Individually, each decision can seem harmless. Collectively, they create a growing integration and governance problem.
Each tool may introduce new identities, new connectors, new contracts, new data flows and another place where usage and cost need to be monitored. This is why adding another AI product should not simply be a question of whether the tool is better.
Ask what gap it fills.
If your existing productivity assistant already performs 80% of the required work, is another enterprise-wide tool really necessary? For many organisations, a smaller number of well-integrated tools will create more value than a large portfolio of loosely governed ones.
Start with the environment you already have
If your AI landscape already feels scattered, you do not need to solve everything at once. Start by understanding what is already there. Inventory the AI tools currently in use — including the unofficial ones. Identify what data they access and how they authenticate. Look at where integrations are being built independently by different teams. Decide which tools should become part of your supported environment, and which should not.
Then establish the foundations that every future AI workload should inherit: identity, logging, observability, cost controls and an agreed integration pattern. Only then start scaling the next wave of applications. That may sound slower than buying another tool. In practice, it usually makes everything that follows faster.
Before the next AI purchase
The AI market will keep changing.
Models will improve. Vendors will add features. New agent platforms will appear. Pricing will move. Today’s market leader may not be tomorrow’s.
Trying to build an AI strategy around whichever model currently sits at the top of a benchmark is therefore a difficult game to win. A better approach is to build an environment that gives you choices.
So before you approve the next AI tool, move the conversation beyond the demo. Ask:
- What will it connect to?
- What will it be allowed to see?
- How will people authenticate?
- How will we monitor it?
- Can it fit our existing integration pattern?
- And if we replace it in two years, what will we have to rebuild?
Those questions are less exciting than watching an AI assistant complete a task in seconds.
But they are the questions that determine whether AI becomes another collection of disconnected tools, or a capability your organisation can actually build on.
Author: Lakshmi Srinivas Bodepu
Further Reading:
https://skillfield.com.au/blog/ai-adoption-treat-it-like-transformation-not-tool-deployment/
https://skillfield.com.au/blog/the-three-objectives-of-a-practical-ai-strategy/
https://skillfield.com.au/blog/ai-adoption-turning-strategy-into-execution/
https://skillfield.com.au/blog/how-to-develop-an-ai-strategy-a-practical-guide/
