AI statement

Version 1.1 · Effective 23rd September 2026

Why we publish this

We build AI into a product that sits in the middle of how teams work together. That is a position of some trust, and the honest response to it is to say plainly what we do, what we won't do, and whose models we're running.

This statement covers Amble and how we build it. It's a statement of intent and an explanation of our decisions, but it's not a policy. Please see our privacy policy for that.

Our principles

People decide. AI proposes. Amble drafts, suggests, summarises, retrieves and routes. It does not make consequential decisions on anyone's behalf. Where an agent can take an action with real-world effect — sending a message externally, committing to a deadline, altering a shared record — that action is either approved by a person or reversible and logged.

We are trying to raise the team, not replace parts of it. The problem we exist to solve is that individually-adopted AI is quietly degrading collective work — context stops being shared, judgement stops being visible, and colleagues are left guessing what a machine did. Features that make one person faster at the cost of the team knowing less are features we don't ship.

Human creativity is the point, not the overhead. We build interfaces that make people's thinking more legible to each other. We are not interested in a product where the interesting work is done by a model and reviewed by a bored human.

You can always tell. AI-generated or AI-assisted output in Amble is marked as such. Where it matters, you can see which model produced it and what it drew on.

Your work is yours. We do not train models on customer content, and we don't let our providers do it either. This is a commitment, not an aspiration.

Autonomy is scoped and accountable. Agents operate within permissions their organisation sets. What they did, when, on whose behalf and with what inputs is recorded in an audit trail the customer can inspect.

We are honest about what models get wrong. They fabricate, they misread context, they are confidently incorrect. We design for that — surfacing sources, keeping humans in the loop on anything consequential, and not implying more certainty than the underlying system has.

How we implement these principles

1. We do not train models on Customer Content. Not our own models, not fine-tunes, not adapters.
2. Our model providers do not train on it either. We use enterprise endpoints, with contractual terms prohibiting training on inputs and outputs, and we will not adopt a provider that won't offer them.
3. Memory is tenant-scoped. The knowledge and context Amble accumulates belongs to the organisation it came from, is never pooled across customers, and can be inspected, exported and deleted. Embeddings and derived representations are treated as personal data and deleted alongside their source.
4. We do not sell data, and we do not share it with third parties for their own purposes.
5. Aggregate, non-identifying usage patterns — which features get used, where things break, how long things take — inform how we build. Your content does not.
6. Customers stay in control. You can export your data or delete it on request.

The models we use

We route requests to different models depending on the task. We think the honest thing is to tell you who they are.

Each of these providers hosts multiple models. The exact models we use can change based on what the best model for the task is at any given moment, but we only ever use models that conform to the principles above.

We keep this table current. Customers under contract are notified in advance of changes, and may object on reasonable grounds. Because we route across providers, the specific model handling a given request depends on the task — the product tells you which one when it matters.

Customers can opt to only use EU-located models (accepting that this may mean reduced capabilities in some areas). We are working to make this a setting you can enable yourself, but for now you need to get in touch with us to set this up.

Automated decision-making

We do not use Amble to make decisions about people that produce legal or similarly significant effects through solely automated means — hiring, firing, performance assessment, creditworthiness, or anything comparable. Our terms prohibit customers from configuring it that way. If you are considering a use case near that line, talk to us first.

Human oversight of agents

Amble can run multi-step work across people and AI. The controls around that:

• Organisations define what agents may access and what they may do
• Actions that reach outside the organisation, or that commit it to something, require human approval by default
• Every agent action is attributable — to a person, an organisation and a moment in time
• Anything an agent produces can be traced back to what it drew on
• A person can interrupt, override or unwind agent work

Testing and evaluation

Before shipping features that change how models behave, we evaluate them against our own test sets for accuracy, appropriate refusal, and failure modes that matter in professional work — fabricated facts, leaked context between workstreams, confident nonsense in a client deliverable.

We are a small and young company and we won't pretend to a testing regime we don't have. What we have, we'll describe accurately to any customer who asks.

Our own use of AI

We use AI tools in our own work — writing code, drafting, research, analysis. We apply the same standard we ask of our customers: a person is accountable for anything that goes out under our name, we don't put confidential customer material into tools that lack appropriate terms, and we don't use AI to make decisions about people.

Regulatory position

We build to UK GDPR and EU GDPR requirements as they apply to AI processing.

Under the EU AI Act, Amble is a general-purpose AI system deployed in a business collaboration context. We consider it outside the Act's high-risk categories, and we design to the transparency obligations that do apply — making AI involvement evident to the people affected by it. We do not intend to support high-risk uses, and our terms exclude them.

Telling us something's wrong

If Amble produces something harmful, discriminatory, or badly incorrect, tell us: dataprotection@supervenient.ai. We'd rather hear about it. Security vulnerabilities go to dev+security@supervenient.ai.

Changes

This statement will change as the product and the field do. The version and date at the top tell you what you're reading, and material changes are notified to customers.

Supervenient Limited · London, UK