Forward deployed engineer data security: a checklist

The short answer: settle all of this before work starts, in the contract. Assurances are worth nothing. “We won’t use your data” has no force the moment there is a disagreement. The eight items below each need a matching clause in the contract or project charter. Where you cannot agree, do not proceed on trust.

1. Access scope and the identity used

• Why: once access is opened, control is gone. What someone can export depends on whether they thought of exporting it.
• What to agree: list the systems and fields in scope. Production data is read-only, granted per person, never through a shared account. Anything needing write access goes through a separate change process, with a stated expiry date on the authorisation.
• If it goes wrong: access outside the agreed scope is a breach. For a leak, the contract’s liability terms apply and you retain audit rights.

2. Whether data leaves your environment

• Why: the easiest way for an AI project to lose control is somebody exporting data to tune results. Once data is outside your network, your only control is the other party’s promise.
• What to agree: define what “stays inside the network” actually means — which steps may send data out, whether it must be de-identified first, and which external model services may be called. For sensitive systems, specify the working arrangement: the engineer works inside your network, under your accounts, and only de-identified samples leave.
• If it goes wrong: moving data outside the environment without written consent is a material breach, and grounds for immediate termination.

3. Whether data is used for training or reuse

• Why: this is the item buyers worry about most and can verify least after the fact. Separate model training (feeding your data to a model) from method reuse (taking the approach to the next client).
• What to agree: prohibit the use of client data for any model training, fine-tuning or improvement of third-party services. Where external models are used, require an enterprise endpoint that does not retain data or train on it — as a technical constraint, not a promise.
• If it goes wrong: the clause must be verifiable. Keep call configuration and logs, and accept audit.

4. Ownership of data and deliverables after the project

• Why: AI deliverables are wider than traditional software: code, prompts and configuration, fine-tuned models, evaluation sets, documentation. If ownership is unclear, you carry nothing into a second phase or a different supplier.
• What to agree: list them item by item — code, models including fine-tuned artefacts, configuration, evaluation sets and scripts, documentation — assigned to you by default. The supplier keeps rights to generic components and methods, never to your data, business rules or system detail.
• If it goes wrong: deliverables not handed over by the agreed date count as incomplete delivery, and the matching payment is withheld.

5. Handover design: runnable, measurable, changeable without them

• Why: deployment is roughly 20% of total cost, and the other 80% is everything that keeps it running. If monitoring, evaluation and integration configuration sit with the supplier, what you inherit when they leave is a black box.
• What to agree: four items on the handover list — production monitoring and logs (on your own platform, or with an agreed migration date), the evaluation suite (sets, scripts, thresholds and how to re-run after a model upgrade), integration logic and configuration, and a runbook covering fault diagnosis and rollback.
• If it goes wrong: the project is not finished until handover is finished, and at least one of your engineers can complete a release and a rollback unaided.

6. Audit trail

• Why: without records you cannot establish afterwards what happened. This requirement usually comes from security or compliance, and it is not something to retrofit later.
• What to agree: log every access — who, when, under which identity, which data, what operation. Retain logs for at least the number of months stated in the contract, retrievable by you at any time.
• If it goes wrong: no audit log means no demonstrable compliance.

7. Deletion and exit

• Why: a project ending does not put data back where it started. Copies sit on laptops, test environments and backups.
• What to agree: define what gets deleted (source data, derived data, caches, local copies, test environments), how, by when, and with written confirmation. Cover termination as well: on what grounds either side may end the engagement, and how many days each has to complete handover and deletion afterwards.
• If it goes wrong: deletion not confirmed on time is grounds to withhold final payment or require an audit.

8. Subcontracting and personnel

• Why: you negotiated with one team and a different one may arrive. Delivery quality depends heavily on individuals, so a change of people resets the risk.
• What to agree: whether subcontracting is permitted at all (in most projects it should be prohibited or require written consent); who is on the team and the rules for replacing them; confidentiality undertakings for everyone who enters, lasting beyond the contract term.
• If it goes wrong: subcontracting or replacing key people without consent is grounds to demand a replacement or to terminate.

Six clauses you can lift into a contract

1. The supplier’s personnel may access the client’s production data only under written authorisation, with individual read-only accounts and no shared logins; access logs are retained for at least 12 months and available to the client on request.
2. Without the client’s written consent, the supplier shall not move client data, its copies, de-identified data or test samples outside the client’s environment, nor use them for any form of model training, fine-tuning or improvement of third-party services.
3. Within 10 working days of project completion, the supplier shall hand over source code, prompts and configuration, fine-tuned model artefacts, evaluation sets and scripts, integration configuration and the runbook, and shall ensure the client can deploy and run the system independently in its own environment.
4. Production monitoring and logs shall be deployed on the client’s own platform; where the supplier’s platform is used, migration must be completed before departure and confirmed by the client before handover counts as complete.
5. Before departure the supplier shall complete knowledge transfer: at least one client engineer shall independently perform a release, an evaluation run and a rollback, with the record retained.
6. Within 30 days of completion or termination, the supplier shall delete all client data and its copies, including local copies, caches and test-environment data, and provide written confirmation of deletion.

When IT and the business disagree

• What the argument is really about: the business has already proved the value of a general-purpose tool and wants it connected to company data. IT’s first instinct is to stop it, and the business complains that IT “won’t allow AI”. IT’s concerns are legitimate: permissions dissolve once data can be exported, there is no audit record, and output quality cannot be verified.
• It is a question of who carries the risk: the business carries the risk of the project not happening; IT carries the risk of signing for an incident. Pressuring IT to “support innovation” only slows the approval down.
• Wording beats reassurance: translate each concern into a clause or a technical control — read-only accounts, per-person authorisation, log retention, de-identification, internal deployment — and answer them one by one.
• Bring IT into acceptance criteria and audit clauses: the earlier they help write them, the less likely they are to stop the work.
• Start from the smallest defensible boundary: one system, one category of data, one read-only account, one time limit. Small enough for IT to sign, and the project can start.

One boundary: what may be reused, and what may not

• Reusable: general methods and components with client information removed — connectors, field-mapping templates, evaluation script frameworks, prompt patterns.
• Not reusable: client data, client business rules and decision logic, system detail (schemas, interface inventories, internal codes) and organisational knowledge picked up along the way.
• A blunt test: if a supplier’s first client in an industry took ten person-months and its tenth still takes ten, there is nothing reusable. If what it reuses carries your business rules, that is over the line.

FAQ

Our data cannot leave the network. Can the project still happen? Yes, with a different working arrangement: the engineer works inside the network under your accounts, and only de-identified samples are analysed outside. That requires you to provide the development machine, test database and accounts. If neither data egress nor an internal environment is available, there is no workable technical route.

Is a non-disclosure agreement enough? No. An NDA covers disclosure. It does not cover use, training, handover or deletion. Those four need separate clauses, and each needs a way to verify it.

Doesn’t a detailed contract poison the relationship? The opposite. Detail is how you agree what happens when something goes wrong. The party that walks away because the clauses are specific is usually the party that did not intend to hand over the deliverables and the logs.

---

A data and compliance discussion that cannot be settled gets more expensive the longer it runs. These clauses are not there to guard against anyone; they are there so the system can still be read, changed and stopped two years from now. How we deliver describes the same commitments on site, and the FDE outsourcing service page covers the commercial shape. For the background, start with What is a forward deployed engineer? and FDE vs outsourcing. If you have a specific situation, talk to us first.