Working inside someone else's security boundary

An FDE is a guest with production access. That position is unusual in software: most engineers have either access or no customer relationship, and most consultants have the relationship but no shell. The failure that follows from it is not malicious — it is a laptop with a customer extract on it, an API key pasted into a notebook, or a demo built on data that was fine on Tuesday and is a contractual problem on Friday.

Four questions that decide the architecture

Ask these in the first session, before drawing anything. Their answers change the design more than any framework choice.

1. Where may the data live? In your cloud, in theirs, on-premise only, or in a named region. The answer is often "on-premise" for a company that has said "we are cloud-first" in the same meeting.
2. Who is the processor and who is the controller? Formally, not conversationally. If your product processes the data, there is a processing agreement; if the FDE's laptop does, that is a finding waiting to happen.
3. What is not allowed to leave, ever? Some customers can name this instantly (customer records, health data, source documents). Some say "nothing" and then, in week three, say "except those".
4. What audit trail does their security team expect? Log retention, access review, and whether they want to see the logs themselves. Getting this wrong is discovered during an audit, months later, by someone who is not you.

The architecture that survives the answer

Three patterns cover most cases, and the order matters because each one is more expensive than the last.

Bring the model to the data. Run inference inside the customer's environment — their cloud account, their VPC, their on-premise cluster. Nothing leaves; you deploy weights or call a private endpoint. This is the default for regulated customers and it is the most work, mostly in plumbing rather than modelling.

Send derived data only. Extract, classify, or summarise locally, and send the small thing out. The engineering question is whether the derived artefact is genuinely de-identified, which is a stronger claim than "we removed names".

Send the data with a contract. Fine for low-sensitivity data and customers with a real processing agreement. The trap is scope creep: a deployment that starts on anonymised logs acquires a document field in week four without anyone re-opening the question.

Whichever you pick, pin it in the design note with the date and the person who approved it. Security decisions expire, and the person who approved this one will have moved on before you need to defend it.

Three habits that keep it legal after go-live

Never keep a customer extract on a laptop. The reason engineers do it is speed: a local copy makes iteration trivial. The reason it matters is that the copy outlives the project, the laptop, and often the company. If you need a sample, name it, restrict it, and delete it on a stated date — and say the date out loud in the review.

Treat credentials as a deployment artefact. Customer credentials belong in the customer's secret store with an owner, a rotation date, and a list of who can read them. An API key in a config file in a repo is the most common finding in a post-deployment review, and it is always "temporary".

Write the data flow down, once, in one page. Source → transformation → model call → storage → deletion. If a security reviewer cannot follow it in a minute, it is either wrong or not written.

The model-provider question

Two things changed the picture and both are now standard interview questions. First, prompts and outputs routinely pass through a third party, so "we send nothing" is a claim about your code, not about your vendor — and the customer will ask about the vendor. Second, models change underneath you: a provider deprecates a version, behaviour shifts, and a system that passed acceptance silently changes what it does with personal data.

The practical answer is unglamorous: pin versions, keep a small evaluation set that includes a data-handling check, and write a rollback line in the runbook. What "the model changed" does to a live deployment is a delivery risk, not a research problem.

What to say when the answer is no

Security teams say no for reasons that are often correct and occasionally stale. Two moves work better than arguing.

Ask what would have to be true for a yes — a specific control, a vendor certification, a narrower data scope — and write the answer down; half the time the requirement is cheaper than the workaround. And offer the smaller deployment: a read-only integration on a sample of records, with a written deletion date, is often approvable where a full pipeline is not. That is a genuine deployment of the first-week prototype kind, and it produces evidence about the data that a security review alone never will.

What not to do is route around the boundary. A shadow copy, an unregistered vendor account, or an "internal only" tool that quietly reaches the internet is the one class of mistake that ends a career rather than a project. The handover artefact described in the sunset clause is where the access list, the retention dates and the deletion proof are supposed to end up.