For many people, AI begins with ChatGPT.
They upload an annual report and ask for a summary. They upload a photograph of a manufacturing facility and ask what is visible. They ask for an illustration showing how a proposed investment would change the factory floor. It feels like one conversation with one intelligent system.
It isn’t.
This chapter uses ChatGPT as its reference point because it is the most widely recognised. The concepts apply equally to Claude, Gemini, and every other modern AI assistant. The name changes. The architecture does not.
ChatGPT is an application. Behind every conversation, it coordinates several specialised AI capabilities and presents them through a single interface so they appear to be one assistant. Understanding that distinction is the first step towards understanding what modern AI actually is and where governance over it actually sits.
The illusion of a single mind
When ChatGPT summarises a document, drafts an email, or writes computer code, it is using a Large Language Model (the GPT in ChatGPT). Language is its primary function. Text in, text out.
Reading an image is a different problem. Generating an image is a different problem again. Each requires a separate, specialised capability. The interface conceals this.
OpenAI, Anthropic and Google each make different choices about how their models allocate what is often called a token budget: the computational resources spent on each response. Some models devote more of that budget to internal reasoning before answering. Others favour speed. Increasingly, that budget also includes action rather than reasoning alone.
This architecture produces a failure mode that is easy to miss and genuinely consequential in practice.
The organisational chart problem
Consider an organisational chart. You ask the system whether the reporting lines are appropriate. The system correctly identifies a governance flaw: the Chief Risk Officer reports to the Chief Financial Officer instead of directly to the Chief Executive Officer. It articulates exactly why this compromises the independence of the risk function.
You ask a simple follow-up: redraw the chart with the correct structure.
The newly generated image quietly places the Chief Risk Officer right back under the Chief Financial Officer.
Nothing was forgotten. The language model’s understanding and the image generator’s output simply operate independently. The interface presented them as one continuous conversation. They were not.
Each AI capability has its own failure modes. The interface conceals this. The liability does not disappear because the interface is seamless.
How organisations actually adopt this technology
Most organisations follow a recognisable pattern as they move from basic AI use towards deeper integration. It is tempting to describe this as a three-stage progression. It is more accurate to describe it as three modes that most organisations run simultaneously, in different departments, with different levels of visibility into each.
Most organisations run all three at once.
The layer that changes everything
Everything described so far has one thing in common: someone else’s application. The next step is fundamentally different.
Instead of using ChatGPT, an organisation can build its own software and connect directly to the underlying language model through an API (Application Programming Interface). The surrounding application disappears. What remains is the raw model.
An employee clicks “Review Contract” inside an internal procurement system. Behind that click, the company’s software gathers the contract, sends it directly to the model, receives the analysis, and displays the result. The employee never opens ChatGPT. They may not know a language model was involved at all.
This has a direct consequence that is easy to miss. GPT‑5.5 is the name of the model itself, whether you reach it through ChatGPT or the API. What differs is everything around it.
The organisation that builds on the API access to the models assembles the capability needed, which needs to be governed separately.
The API is not where accountability begins. It is where the nature of it changes. When an organisation uses ChatGPT, the vendor made the design decisions. When an organisation builds on the API, it makes them.
Organisations have long built agentic systems by combining language models with software that retrieves information, calls external tools (running a script, querying a database, searching the web) and coordinates multi-step workflows. Frontier model providers are increasingly moving some of those capabilities into the “model” itself. With the launch of Claude Sonnet 5, Anthropic explicitly positioned the model as agentic, even though many of the underlying capabilities existed in earlier versions. The change is as much about where those capabilities are considered to reside as it is about the capabilities themselves. A provider’s token budget is therefore becoming a choice not only about how much a model thinks, but how much it is permitted to do. It also means benchmark scores are no longer apples to apples. Claude Sonnet 5, for instance, is not a “model” in the same sense that Llama is: a “model” that was allowed to take autonomous action to reach its answer is not being tested on the same basis as one that was not.
One further point worth stating clearly. The API pattern is not unique to cloud services. When a model runs locally (Ollama on a laptop running Qwen or Llama, for instance), it exposes a local API endpoint. The application talks to it in exactly the same way it would talk to OpenAI’s cloud API. What changes is where the model runs and who controls it, not how it is called. The accountability boundary is not about cloud versus local. It is the point where the application ends and the model begins, regardless of whether that model is in a data centre or on someone’s desk.
What leaving ChatGPT reveals
GPT‑5.5 is only one language model within a rapidly expanding ecosystem. Alongside proprietary frontier models are an increasing number of open-weight models covering almost every area of AI.
Language model families such as Qwen, Gemma, Liquid AI and Amazon Nova. Image generation models such as Krea 2 RAW, Krea 2 Turbo and Z.image. Hundreds of specialised models for speech, retrieval, ranking, robotics and scientific applications. All of them available to organisations and developers today.
Many of these models can be downloaded and run locally rather than accessed through a cloud service. Some are compact enough to operate on laptops and modern mobile phones. Others can exploit the graphics hardware found in an ordinary gaming PC, allowing sophisticated AI capabilities to run entirely within an organisation’s own environment.
This represents a fundamental change in the enterprise AI landscape. AI is no longer something delivered exclusively by a handful of cloud providers. It is becoming software that organisations can download, evaluate, adapt and deploy themselves.
Many open-weight models can also be specialised through fine-tuning: adapting a general-purpose model to a particular domain, workflow or visual style without building one from scratch, sometimes using hardware no more specialised than a gaming PC.
The governance consequence
The risk is not that employees use local models. It is that organisations often do not know which processes they have been introduced into, and have no way to find out after the fact.
In the last few years, smartphones have gained enough processing power to run many of these models completely offline. This is not a future risk. It is the current state.
The AI governance frameworks most organisations are building assume models are accessed through managed cloud infrastructure. That assumption is already wrong for a meaningful portion of the workforce. It will be wrong for more of it next year.
Your data loss prevention (DLP) tools cannot see a model that never touches the network. Your approved-vendor list does not apply to an app on a personal device. What needs to be governed extends further than your cloud perimeter.
What this means before the next chapter
Modern AI is not a single application, a single model or a single deployment model. It is an ecosystem of specialised models that can be combined, adapted and deployed in many different ways.
Every governance framework that treats the AI as a single accountable object is working on the wrong unit of analysis. The application layer is where design choices are made. The model layer is where probabilistic behaviour originates. The edge is where neither is visible.
A language model can only reason over the information it receives. How an enterprise application finds and delivers the right information to the model at the right moment is the subject of the next chapter.