Data and security in AI systems

We build on the systems that are already there. That is not a pricing argument, it is the reason the answer to the data question can be short: your data stays where it sits today. In your mailbox, in your document folder, in the accounting package, in the database under your own application.

What we add is a program that reads and writes there. It fetches what that one step needs, does something with it, and puts the result back into the system everyone already looks at. A second copy of your data only comes into being if the route genuinely calls for one, and then we agree up front what goes into it and how long it stays.

Where possible the system runs in your own environment and your own accounts. The cloud account is in your name, the storage is your storage, the database is your database, and the mailbox anything leaves from is yours. We get access, we take nothing with us.

Sometimes that is not possible, because a component needs a server we run. That component then runs in an EU region and is named in the data processing agreement.

There is a practical side too. If it runs in your accounts, your administrators see it in their own logs, they can switch it off without calling us, and nothing has to change hands if the working relationship ever ends.

An AI system is ordinary code for the most part. At one or two points in the route sits a model call: a piece of text goes out, an answer comes back, the code does something with it. What goes out is the piece that step needs. One work order, not the folder. One email, not the inbox.

We do not train public models on your data. What a model provider itself does with traffic through its API is set out in its own terms, and we work that out per project: which provider, which region, which retention period. The outcome goes into the data processing agreement, with the parties we bring in named, so somebody who knows the subject can read it back.

What a model returns is treated as a proposal, not as a fact. Before the answer lands anywhere, the code checks whether it has the shape that was agreed: the fields that belong in it, an amount that is an amount, a date that exists. If the shape is wrong, the route stops and the case joins the pile somebody checks.

A system gets an identity of its own with us, not a shared administrator account and not the personal account of somebody who leaves next year. At the large cloud providers that is called a scoped IAM role, but the idea is older than the term: you write down which actions that one route performs, and that short list is exactly the access the identity gets.

In practice it reads as a short list. Read from this one folder. Write to this one table. Send from this one mailbox. Nothing beyond that, so not the rest of the drive and not every mailbox on the domain. If the system needs something extra later, that is a change somebody approves before the role gets any wider.

The keys live in the environment and never in the code, and they can be replaced without anything breaking. And because the system carries a name of its own, your own logs show a name next to every action, the system or a colleague.

We sign an NDA and a data processing agreement as standard, including on a first two-week project. It states who is responsible for what: you are the controller, we are the processor, and the parties we bring in are named.

Beyond that it sets out, per component, which data goes there, what it is there for, which region it sits in and how long it stays. The model provider is named as well, with the region and the retention period we worked out for that project. You can ask for a full export at any time, and that arrangement sits in the same agreement.