How to collaborate when client data cannot leave the environment

When client data cannot leave its environment, collaboration does not have to stop. The design principle changes: move the approved method to the data, keep execution under client control, and export only the minimum reviewed evidence needed to support the decision.

This pattern can support evaluation, engineering and investigation, but it requires more planning than copying a dataset into a partner’s tools. The parties must distinguish raw data access, derived evidence, code movement, privileged operations and decision records.

Translate “cannot leave” into precise boundaries

The phrase may combine several constraints: legal or contractual restrictions, data residency, security classification, trade secrets, customer commitments, model-provider terms or an internal risk decision. Each affects the architecture differently.

Create a data map before choosing tools. Identify the records, sensitive fields, source systems, permitted purposes, authorised roles, approved processing locations, retention periods and prohibited transfers. Include prompts, retrieved context, model inputs and outputs, tool responses and logs; AI workflows can reproduce source data in places teams do not initially classify as datasets.

The NIST Privacy Framework describes a data-processing ecosystem with complex relationships among organisations, developers, service providers and partners. Its emphasis on communicating requirements across those roles is important here: an environmental boundary works only if every participant understands what processing is allowed within it.

Choose an in-boundary collaboration pattern

Four patterns cover many engagements. They can be combined by task.

Pattern	What crosses the boundary	Who executes sensitive steps	Useful when
Guided execution	instructions, templates and review questions	client operator	access must remain entirely internal
Bring the method	approved code or container enters; reviewed results leave	client or controlled partner role	repeatable tests need specialist tooling
Supervised workspace	authorised person accesses a client-hosted environment	partner under client controls	interpretation requires limited record access
Privacy-preserving collaboration	protected inputs or computations and bounded outputs	distributed or trusted components	parties need joint analysis without pooling plaintext

Select the least permissive pattern that can answer the evaluation question. Do not use a sophisticated privacy-enhancing technology to avoid basic data minimisation, nor assume guided execution is sufficient when subtle failures require expert inspection.

Make the environment part of the method

An in-boundary workspace should have named owners, time-limited identities, least-privilege access, approved tools, controlled network egress, auditable execution and a defined evidence store. Separate administrative privileges from analysis roles. Disable convenience paths that bypass export review, such as unmanaged clipboard, personal storage or arbitrary package download, where the risk warrants it.

The UK National Cyber Security Centre’s supply-chain guidance warns that consultants’ remote access can become a staging path if their systems are compromised. Its secure communications principles also emphasise protection in transit, authorised access, secure audit and supply-chain assessment.

These controls should not make the work impossible. Pre-approve required libraries, create a reproducible build route and provide a client-side technical owner who can resolve environment constraints. Record deviations instead of allowing urgent workarounds to become invisible access paths.

Design a two-way evidence membrane

Collaboration needs information to cross the boundary in both directions. Treat each direction differently.

Inbound artefacts include test code, cases, prompts, schemas and documentation. Scan and review them, record versions, and prevent unapproved network calls or telemetry. Outbound artefacts include metrics, redacted traces, screenshots, issue descriptions and decision summaries. Review them for personal data, secrets, unique combinations, confidential business information and unsupported conclusions.

A useful export record says what left, for which purpose, who approved it, where it may be stored and when it must be deleted. Aggregation is not automatically anonymous, especially for rare failures. The client’s privacy and security owners should define the review proportional to risk.

Use privacy-enhancing technologies for a specific problem

Privacy-enhancing technologies can broaden collaboration options. The UK Information Commissioner’s Office describes approaches including trusted execution environments, secure multiparty computation, differential privacy, synthetic data, private set intersection and federated learning. Each changes what parties can learn and what risks remain.

Choose a technology by the computation and threat model. Private set intersection may answer whether two parties hold matching identifiers without revealing complete lists. Federated analysis may move code to several data locations and aggregate results. A trusted execution environment may reduce exposure to infrastructure operators. Differential privacy can bound information leakage from aggregate outputs at a cost to utility.

The ENISA report on data spaces notes that privacy risk mitigation in multi-party environments needs coordinated implementation and cannot be reduced to concatenating separate risk lists. Treat these methods as engineered controls with assumptions, not magic labels. Validate implementation, key management, output leakage and fitness for the intended inference.

Divide work without dividing understanding

When client staff run sensitive tests, external specialists still need enough context to design and interpret them. Use a layered evidence pack:

1. public or non-sensitive system description;
2. controlled schema and scenario description;
3. approved aggregate results and failure taxonomy;
4. restricted traces inspected only in the environment;
5. client-owned raw records available solely to authorised roles.

Pair the external method lead with an internal evidence custodian. The custodian verifies provenance, runs or witnesses sensitive steps, approves exports and records constraints. The method lead documents what can and cannot be concluded from the evidence provided. Neither should silently compensate for missing information with assumptions.

Plan for debugging without opening the boundary by exception. Create safe diagnostic views, pre-approved query templates and a process for escalating access when aggregated evidence is insufficient. A tightly redacted trace can remove the feature that explains a failure; a specialist should be able to request a controlled deeper inspection, with purpose, duration and reviewer recorded.

Where code enters the client environment, manage it as a supply-chain artefact. Pin dependencies, scan packages, document external calls, record the build and make removal possible. Where results leave, preserve the transformation from raw evidence to export so a client reviewer can reproduce the aggregation or redaction.

Agree how discovery will change the plan. If testing reveals that an apparently harmless output can reconstruct sensitive information, stop export and reassess. If data quality makes the intended evaluation invalid, report the constraint rather than substituting a convenient dataset and retaining the original conclusion.

Close access and preserve the right artefacts

Plan handback on day one. At completion, revoke temporary identities, remove imported credentials, reconcile code and environment changes, verify deletion obligations and retain only the artefacts required for audit, remediation or repeat evaluation.

The decision record should remain understandable without exporting the sensitive data itself. It can reference controlled evidence by identifier, describe methods, state findings and constraints, name the decision owner and define retest triggers. Future reviewers can request authorised access to the underlying records when necessary.

Before closure, ask a person who did not run the engagement to follow the evidence references inside the client environment. If the chain breaks because knowledge lives only with a temporary partner account, handback is incomplete.

Keeping data in place is not a complete privacy or security conclusion. It is an architecture for maintaining control while people and methods collaborate. Done well, it creates a clean division: sensitive evidence stays where the client can govern it, while enough validated information crosses the boundary to improve the work and support an accountable decision.