flyingpenguinSERVICES

Know where
the information goes.

For an AI app or staff assistant, we need to understand the whole route: what is processed, where it goes and who can access it. A London-routed API needs those checks too.

Illustration of the app, documents and hosting relationship
Illustration of a possible setup.

Map the whole route

The browser, sign-in service, app, document store, search index, model service, logs, backups and support access can each handle information. We name the proposed services and what passes between them.

That gives you something concrete to review before sharing business documents.

Check permissions where information is used

The app needs to restrict what a person can retrieve as well as what appears on a screen. We agree user roles, document groups and any separate customer workspaces, then include restricted requests in the test plan.

Source links should lead only to material the user is entitled to open.

Know what reaches the model

An API request can include a question and selected source passages. The chosen provider, model, processing route and current terms affect that arrangement.

An open-weight model on separately scoped hardware is another option to assess, with its own operating and licensing requirements.

Agree logs, recording and retention

The proposal identifies the information needed for operations, who can access it and how long it is retained. Avoid putting full prompts or private documents into logs without a stated need and handling arrangement.

Document removal needs a plan for relevant stores, indexes and backups.

Treat location as a whole-service question

A UK server or London API endpoint is not enough to describe every processing step. Routing, storage, indexing, support and backups need checking too. For a UK-only requirement, the selected services and failure behaviour must support it before we make that claim.

A London-only API needs a London-only model route

For the London Claude API service, we propose Bedrock In-Region in eu-west-2 with eligible models explicitly allowed. Geographic and global routing are excluded from that requirement.

The gateway, access checks and failure behaviour must also be tested; this public marketing website is separate from that processing route.

Check retention for the chosen model

AWS documents model-dependent retention controls. We verify the effective settings and terms for the models in scope, along with application logging and backups.

Optional prompt logging can create another copy even when the inference arrangement does not retain content. A change of model requires a fresh check.

Location and GDPR are different questions

We identify the contracting suppliers and processing roles, document access and retention, and agree the processing terms before production use. The ICO explains that overseas access by a separate organisation can be a restricted transfer too.

Any applicable transfer mechanism must be assessed for the actual arrangement. London inference does not remove the rest of your UK GDPR responsibilities.

Keep access and an exit route

Account ownership, management permissions, exports, key replacement and removal at the end of the service are agreed before launch. The service map on the homepage is an example for planning; it does not establish those settings for a customer deployment.

Let’s look at
your setup.

Tell me what you want the app to do, or what needs attention. We can work out the next step together.

Book a short callOr send me the outline