Most enterprises can’t say where their AI sends information, which model produced a given answer, or who approved the result before it was used. Not because anyone was careless, but because nobody was asked. A chatbot gets used for a contract summary. An assistant appears inside existing software. A pilot becomes the way a process runs. Each step is small. Together, they decide how AI operates inside the organisation, and the organisation wasn’t the one deciding.
The question behind the model.
Most AI conversations start with which model should we use? It’s a reasonable question, and it changes every few months.
The question that lasts is different: who decides how AI behaves here? In practice, that comes down to six decisions:
- Where it runs. Which environment processes your information, and what is allowed to leave it.
- What it can read. Which sources it draws on, and whether it respects who is allowed to see what.
- Which model answers. Who chooses it, and who decides when it changes.
- What it can do. Answer, draft, or take action in another system.
- When a person approves. Which results need review, and by whom.
- What is recorded. Whether you can reconstruct what ran, on which sources, and who signed off.
If the honest answer to any of these is “the provider” or “the default setting”, the enterprise has handed that decision away.
What a default can’t know.
Defaults are necessary. A product used by thousands of organisations has to ship with sensible settings. But a default can’t know your obligations, your access rules, or which outputs carry real consequences. It treats a draft email and a regulatory assessment the same way.
The goal isn’t a smarter answer. It’s a governed one: produced inside boundaries the enterprise set, from sources a reviewer can check, approved by the person accountable for it.
Control has to be engineered.
Control isn’t a toggle. It’s built into the system around the model:
- Knowledge organised with its sources and versions, so every answer can be traced.
- Permissions carried through every request, so AI never sees more than the user can.
- Boundaries that account for every outbound path: model requests, logs, error reports, monitoring, updates.
- Approvals placed where professional judgement belongs, and recorded when given.
- Evaluation against the organisation’s own examples, so a model change is tested before it reaches the work.
This doesn’t require every enterprise to build or train its own models. Most shouldn’t. It requires that the system around the model belongs to the enterprise, so models can be chosen and replaced on its terms.
Start with one workflow.
Control is built the same way trust is: in a defined scope, against real work. Choose one task that matters and the people who own it. Agree what a good result looks like. Agree the boundary. Build, test with the team, and expand only when quality and controls are both demonstrated.
The decision that comes first.
Models will keep improving, and the choice between them will keep changing. The decisions around them are the ones that last: where AI runs, what it can see, what it can do, and when a person must approve.
Your enterprise should decide how its AI operates. Not the model provider. Not an application’s default settings. Your organisation.