Security and data

Your documentation is competitive advantage. It shouldn't become someone else's training data.

FieldPal is built for organisations whose technical material is sensitive, licensed or regulated. You keep ownership of everything you put in, and nothing is shared across deployments.

How we handle your data

The commitments that matter

  • Full data ownership

    Customers retain complete control and ownership of everything uploaded to FieldPal. Your material stays yours.

  • Never shared across deployments

    No customer data is shared between deployments, and yours isn't used to improve anyone else's experience.

  • Built for regulated environments

    It is designed for sectors with strict compliance mandates and sensitive datasets, including aerospace, defence and highly specialised industrial operations.

  • Cyber Essentials certified

    Sightline AI Ltd holds Cyber Essentials certification, the UK government-backed scheme that checks the basic controls protecting against the most common cyber attacks.

  • Isolation you can choose

    Run on our managed service, or take a private segregated instance of your own. The choice is yours rather than a function of what we happen to offer.

Deployment

Cloud-hosted, or your own segregated instance

FieldPal is a service we run. Most customers use it that way and never think about infrastructure again. Where isolation matters more than convenience, you can have an instance of your own instead.

  • Managed cloud

    The default, and the right answer for most. We run it, patch it, monitor it and keep it current. Customer data is hosted in Microsoft Azure, primarily in Sweden Central, with a full audit trail and retention aligned to compliance requirements. Nothing is shared across customers.

  • Private segregated instance

    Your own isolated instance rather than a tenant within a shared one. Same product and same updates, but everything else kept separate, for organisations whose security posture, sector or contracts require the separation to be structural rather than logical.

  • Deploying into your own environment

    Some organisations need the software inside their own boundary entirely. That is a conversation to have properly rather than a checkbox: tell us the constraint you're working to and we'll tell you whether we can meet it.

  • The same commitments either way

    Whichever shape you choose, your data stays yours, is never shared across deployments, and isn't used to train models serving anyone else. The deployment model changes where it runs, not who owns it.

Side by side

Three shapes, one set of commitments

The default

Managed cloud

  • We run it, patch it and monitor it
  • Hosted in the EU
  • Full audit trail and aligned retention
  • Right for most customers

Structural separation

Private segregated instance

  • Your own instance, not a tenant in a shared one
  • Same product, same updates
  • Separate everything else
  • For sectors and contracts that require it

A conversation, not a checkbox

Inside your own boundary

  • The software within your own environment
  • Scoped against your actual constraint
  • We'll tell you if we can't meet it

Unchanged

Whichever you choose

You own your data Never shared across deployments Never used to train models serving anyone else
The deployment model changes where it runs. It doesn't change who owns what is in it.

Provenance

An answer you can't trace is an answer you can't use

In safety-critical and warranty-bearing work, where an answer came from matters as much as what it says. FieldPal grounds answers in your approved material and names the source, so the technician can verify it and an auditor can follow it.

The same applies to capture. Every record is timestamped and attributable. That produces a provable execution trail rather than a reconstruction written after the fact.

This is the difference between an assistant that is interesting and one you can put in front of a regulator.

Common requirements

Questions we expect from your security team

If yours aren't on this list, ask them anyway. Early answers beat surprises at contract stage.

  • Where is our data stored, and who can access it
  • Is our documentation ever used to train shared models
  • Can we deploy into our own environment rather than your cloud
  • How is access controlled across a distributed dealer or contractor network
  • What evidence can you produce if an auditor asks what a technician was told, and when
  • What happens to our data if we stop being a customer

Questions, answered

What security teams ask, with the answers

Where is our data stored, and who can access it?
On the managed cloud, in Microsoft Azure, primarily in Sweden Central, with a full audit trail and retention aligned to compliance requirements. Nothing is shared across customers. If isolation needs to be structural rather than logical, a private segregated instance or your own environment are both options.
Is our documentation ever used to train shared models?
No. Your material isn't used to improve anyone else’s experience, and is never used to train models serving other customers.
Can we deploy into our own environment rather than your cloud?
Yes, for organisations that need it. It needs a proper conversation rather than a tick box. Tell us the constraint you're working to and you'll get a yes or no on whether we can meet it.
What evidence can you produce if an auditor asks what a technician was told, and when?
Every answer is grounded in your approved material and points to the document it came from, and every record is timestamped and attributable. That is a provable execution trail rather than a reconstruction written after the fact.
What happens to our data if we stop being a customer?
On termination, your data is returned or deleted at your election, as set out in the data processing agreement. It doesn't become ours by virtue of the contract ending.

Bring your security questionnaire

Working through it at the start is cheaper for both of us than finding a blocker after a successful pilot.