Data protection and how we build

Every engagement is different, so treat what follows as how we normally work rather than a fixed process. The specifics, which systems, which providers, which controls, are agreed per project and written into the contract. Where we mention a particular tool or build it is an example of the approach, not a description of every project.

What we ask for, stage by stage

During an assessment we work mostly with people and documents rather than live systems. In practice that means:

• Interviews with your team. These are usually recorded or written up, and the notes and transcripts are data: they often contain names, client situations and commercially sensitive detail. They are stored in the project folder and covered by the same agreement as everything else.
• Documents you share with us, normally through a folder in a cloud drive: process notes, templates, example files, reports, sometimes real documents where that is the only way to understand the work.
• Access to systems where it helps, typically read-only or a sandbox or test environment rather than your live production data. Where live access is the only practical route, it is agreed in writing and limited to what the question requires.

What an assessment does not need is a full export of your client book, or write access to anything.

During a build the data in scope is named in the contract along with the systems, the people with access and the providers involved. Work usually runs against test or anonymised data first, and moves to live data only once the controls and the review steps are in place.

Your systems stay the source of truth

What we build sits on top of the systems you already run. It is not a second copy of your records. A typical build keeps only working data: the job in progress, what the system is proposing and a log of who approved what. The record of truth stays in your CRM, your finance system or wherever it lives today.

Who sees your data

• The Innate project team. The project lead and the developers named for your project, with individual logins and multi-factor authentication, reaching only what the project needs. Access is removed when someone leaves the project.
• Specialist contractors, when a project needs capacity or a particular skill. They are named to you before they start and work with synthetic or anonymised data wherever the task allows.
• Providers that run the software. Typically a model provider, hosting and a database. Which ones depends on the build, and the list for your project is written into the agreement, with notice before we add or change one.

Agreements

We sign a confidentiality agreement as standard, yours or ours. Where a project involves personal data you are the controller and we are the processor, and we put a data processing agreement in place before any of that data is shared. It names the systems in scope, the people and providers with access, where processing happens, how long we keep data, how it is deleted and your right to audit. We work under UK GDPR and the Data Protection Act 2018, and we are happy to give processor input for your own impact assessment.

Retention and deletion

• Assessment material, interview notes, transcripts and shared documents, lives in one project folder so there is a single place to clear out.
• Working data created by a build is kept for the period agreed in the contract, not indefinitely.
• When an engagement ends we remove our access, delete or return the project material, and confirm in writing what was deleted and when. Repositories, cloud folders, databases and any transcripts are all in scope.
• If you want something deleted earlier, you ask and we do it. You do not need a reason.

Model providers and API keys

• Builds call model providers through their business APIs, not consumer chat products. On those terms customer content is not used to train the provider's models by default, and retention is limited or zero depending on the provider and the settings we choose.
• We confirm those settings as part of the build rather than assuming them, and we can show you where they are set.
• If you prefer the keys to be yours, the system runs on your account and your billing, and you can revoke access at any time without involving us.
• Prompts and outputs can be logged for debugging. Where that log would contain personal data we either switch it off, redact it, or keep it for a short, agreed window.
• Where a workflow does not need personal data, we keep it out of the prompt entirely. That is usually cheaper and faster as well as safer.

How we control what the system produces

This is the part that matters most once something is live. An AI system will occasionally misread a figure or misunderstand a sentence, so the question is not whether that happens but what catches it. Depending on the build we use some combination of:

• Evals. A test set of real cases with known right answers, run every time the prompt, the model or the pipeline changes, so we can see whether a change made the system better or worse rather than guessing.
• Guardrails. Rules the system cannot cross: which fields it may write, which actions need approval, what it must refuse, what it must escalate.
• Confidence and uncertainty. Extracted values can carry a score, and low-confidence items are surfaced for review instead of being written through. Where two sources disagree, both are shown and a person chooses. Missing values are held rather than invented.
• Human approval at the point of consequence. Drafts are approved before sending, and anything that changes a record, commits to a price or moves money needs a person to confirm it.
• Logs. What the system saw, what it proposed, who approved it and when. Enough to answer "why did it do that?" weeks later.
• Testing before go-live. The developer, the project lead and someone from your team work through real scenarios, including the awkward ones, before anything touches production.
• A prompt playground. A place to try changes against the eval set, side by side with the current version, so prompts are versioned and compared rather than edited live and hoped for.
• Monitoring after launch. Error rates, rejected proposals and the cases people override, reviewed so the system improves with use.

Not every project needs all of this. A tool that drafts internal summaries does not warrant what a tool that writes to a client record does, and we would rather tell you which controls are worth paying for than apply the full list by default.

Starting without live data

A first piece of work can be done with interviews, a walk-through of your systems, your process documents and sanitised or made-up examples. At the end you get a written view of where AI would help, what it would take and what data a build would actually need. What access to grant, and whether to grant any, is then your decision.

If you are in the middle of changing a core system, and plenty of firms are, we would avoid building anything that depends on the platform you are leaving. In practice that means keeping the part that reads and understands your documents separate from the part that writes into a system, so only a thin layer is specific to any one platform. Work that is useful either way, such as making a legacy archive of scanned documents searchable, can usually run during a migration rather than after it.

If you are weighing up a project and want to go through any of this properly, including our standard agreements and the provider list for the build you have in mind, book a call with our team.

Written by the Innate AI team.