AI Gateway

The AI Gateway is a single, consistent way for ActiveManage and your application to send a request to a large language model and get an answer back. Which vendor actually answers is configuration, not code, so you can change provider without anything being rebuilt.

Supported providers

Anthropic, OpenAI, Google Gemini, GitHub Models, xAI and Amazon Bedrock. Images can be sent alongside a request where the chosen model accepts them, which is what makes reading a document or a screenshot possible without a separate integration.

Where it is configured

API keys are held in a configuration file on the server rather than in the Architect Panel. That is deliberate — they are credentials with real spending attached, and they belong with your other server-side secrets. Whoever administers your installation will need to set them.

It stores nothing

The gateway keeps no record of what was asked or answered. If you want a log — and there are good reasons to want one — that has to be built into whatever calls it. Decide this early: a model that produces something inappropriate is much easier to investigate if you kept the request.

If it is not configured

With no keys set, every request returns a plain "not configured" message rather than failing. An application offering an optional AI feature therefore degrades to not offering it — worth confirming your application handles that properly, because the message is returned as ordinary text and an application that does not check could display it to a customer as though it were an answer.

Worked Examples

• Support desk: draft a suggested reply for an agent to review and edit.
• Data cleansing: classify free-text enquiries into categories for routing.
• Content: generate a first-draft description that a person then approves.

ActiveManage does not choose a provider for you and does not automatically fall back from one to another.

The considerations, in order of importance

1. Where your data may go, and what may be done with it. This is usually the deciding factor. Check each provider's data residency and training-use terms against your own obligations before sending anything real.
2. Amazon Bedrock keeps traffic within an AWS account you control, which is frequently the simplest answer to a data governance question.
3. Capability and cost vary considerably and change often — check current documentation rather than relying on what was true when a decision was last made.

Setting it up

Obtain an API key from your chosen provider and give it to whoever administers your installation. Keys should be treated exactly as you treat database credentials — kept out of version control, restricted by file permissions, and rotated if ever exposed.

Confirm it works before relying on it

Exercise the feature that uses it and confirm you get a sensible answer rather than a "not configured" message.

Cost control

Every request costs money, and a feature that quietly calls a model on every page view can produce a surprising bill. Set spending limits at the provider, and be deliberate about how often requests are made.

Worked Examples

• Public sector or healthcare: Bedrock in a UK region, so data residency is answerable in one sentence.
• Startup prototyping: whichever provider you already have a key for; revisit before launch.
• High volume, simple classification: a smaller, cheaper model rather than the flagship.

Before wiring a model into a business process, three things are worth settling.

1. Know what you are sending

A request assembled from record data sends that data to a third party. Be clear about what personal or commercially sensitive information can end up in a request, whether your provider's terms permit it, whether it may be used for training, and what you tell your customers.

If your privacy notice does not mention it, it needs to — before you go live, not afterwards.

2. Do not trust what comes back

Model output is not reliable by construction. It can be confidently wrong, and it can contain anything at all — including text designed to manipulate whatever processes it next.

• Never display model output as raw formatted content without escaping it.
• Never use it to build a query, a command or a link without checking.
• Where the output drives a decision that matters, keep a person in the loop. Use it to draft, suggest and prioritise — not to decide unsupervised.

3. Expect it to be slow, and sometimes unavailable

A request can take many seconds. Do not put one anywhere that has to respond quickly. For anything customer-facing, either show a clear progress indicator or do the work in the background and present the result when it is ready. Providers also have outages and rate limits, so whatever uses the gateway should cope with no answer at all.

Worked Examples

• Good: suggest a category for an enquiry, with the agent able to override it.
• Good: summarise a long case history for a human reading it.
• Risky: automatically closing cases the model judges resolved.
• Avoid: making eligibility or pricing decisions with no human review.