Loading

Choosing a Provider

Several providers are supported and each is configured with its own credentials and default model. The choice is less about benchmarks than about terms and location.

Where to find it

Architect Panel → Data:

  • AI Builder — the feature most sensitive to model quality

Architect Panel → Security:

  • Permissions — who can use the AI features at all

Ask the questions that are hard to reverse

  1. Where do requests go? Which country, and does that suit your obligations.
  2. What does the provider do with them? Retention, and whether inputs may be used for training.
  3. What contract are you under? A consumer plan and a business agreement differ enormously.

Model quality is easy to change later; the answers to these are the ones that matter to whoever signs off the arrangement.

Configure the default first

Because everything falls back to it, the default provider is the one most requests use. Get that decision right and the per-role overrides become tuning rather than a series of separate approvals.

Each provider carries its own credentials

Enabled, a delivery method, an API key and a default model. Use an organisational account, not somebody's personal one — this is a billed service and it should not stop working because a person left.

Keys are credentials with a bill attached

A leaked model API key is somebody else's usage charged to you, and it is not always noticed quickly. Treat them as you would any other credential: not in a repository, not in a ticket, and rotated on a schedule.

A local tool is an option

Where a provider offers a CLI, requests can go through a locally installed tool rather than a direct call. That suits environments where outbound calls from the server are restricted, and it changes who is making the call.

Match the model to the role

Not every feature needs the same capability. Generating extension source rewards a stronger model; assembling a query definition from field names is a smaller task. Per-role configuration exists so you can reflect that rather than paying for the best everywhere.

Review the choice periodically

This area moves quickly — models are superseded and prices change. A configuration set once and never revisited will be paying for something outdated within a year. An annual look is enough.

Have a view before somebody asks

"Which AI are you using and what happens to our data" is now a routine question in procurement and security reviews. Being able to name the provider, the terms and what each feature actually sends is much better than assembling the answer under time pressure.

Worked example

An organisation with public-sector clients chooses a provider on the strength of its business terms and processing location rather than its benchmarks, records the decision, and points the code editor at a stronger model from the same provider. When a client's security questionnaire asks, the answer is already written down.

Recommendations

  • Choose on terms and location before capability.
  • Get the default right — it carries most of the traffic.
  • Organisational accounts and rotated keys.
  • Write down the answer to what you use and what it sends.