Bring your own AI keys, and govern how models are used

Why does a broker need AI governance rather than an AI feature?

Because a financial institution has to be able to answer where its data went, which provider processed it, under what terms, and who authorised that. "We use AI" is not an answer to any of those, and an institution that cannot answer them cannot approve the feature.

Most AI-in-product conversations stop at capability. The questions that actually decide whether it ships are procurement questions: whose contract with the provider, whose data processing terms, whose usage accounting, and whose decision if the provider changes its policy. Handing those to the tenant answers all four.

What does bring-your-own-key mean concretely?

The tenant supplies its own AI-provider credentials. Those credentials are protected at rest and used only for authorised provider requests under tenant policy, rather than the tenant inheriting a platform-level account with a third party it never evaluated.

The practical consequences are the ones a security review cares about. The tenant holds the contractual relationship with the provider, so its own data-processing terms apply. Usage is attributable to the tenant rather than pooled. And if the tenant's AI-governance policy permits one provider and not another, that is enforceable rather than just a stated intention.

Credential isolation at the platform layer is what makes this more than a naming convention: one tenant's provider credentials are not reachable from another tenant's context.

Who answers which question

Which arrangement applies to a deployment is a scoping decision, and AI configuration is administered from the broker console.

What can the model actually do?

Interpret intent and structure it. AI-native interpretation turns a plain-language description into a candidate rule set; deterministic schemas, instrument services, validation rules and risk policies decide whether that rule set can proceed.

The boundary is the whole of the governance story. A model cannot resolve an instrument that does not exist, widen a risk limit, bypass a validation rule, or place an order, not because it is instructed not to, but because there is no path from a model output to any of those. It proposes; the platform decides.

That is also why a model change is a lower-risk event here than it would be in a system where the model sits in the decision path. Swapping providers changes how well intent is interpreted. It does not change what is permitted.

What does the platform never use a model for?

Predicting prices, selecting instruments on a client's behalf, or expressing a market view. Those would be recommendations, and a recommendation is a regulated act rather than a product feature.

The defensible use is translation: closing the gap between a trader's description of a strategy and an executable specification. That is a genuine language problem and language models are genuinely good at it. Forecasting is a different bet, usually an unstated one, and this platform does not take it.

AI output requires review. A generated rule set is a draft that captures what the model understood, and its failure mode is being plausible rather than being obviously wrong. This is exactly why it is presented as explicit rules a human reads before anything is tested.

Where is this administered?

AI configuration sits in the broker console for tenant-level policy and credentials; AI management sits in the platform control plane for provider configuration above the tenant.

Splitting them is what allows a broker to govern its own AI usage without needing platform-operator access, and allows the platform to manage provider availability without reaching into a tenant's policy.