Why Tonic.ai needs FDEs: sensitive customer data never leaves the customer's infrastructure

Tonic.ai’s documentation on the data it collects contains one short sentence: for self-hosted installations, customer data does not leave the customer’s environment. That sentence also explains why a company selling de-identification software hires Forward Deployed Engineers.

If the product cannot see the data, the vendor’s engineers have to go where the data lives. At Tonic, that means installing infrastructure, checking the quality of the output and writing part of the report sent to the customer.

For anyone working as an FDE, or hoping to, Tonic shows a kind of role that gets little attention. The work is not about building agents or polished demos. The customer needs someone to answer for one question: is this data actually safe now?

The data cannot travel, so the engineer must

Tonic describes Textual as a tool that removes PII from text and audio so the data can be used to train models and to run real-time agent workflows.

One of the company’s FDE postings, published on Remotive, states the business problem plainly. The whole industry has to find a way to get enterprise data to AI labs without exposing the people in that data.

The catch is where the software runs and where the data sits. Tonic’s documentation says most customers self-host Textual in their own VPC. The product page also recommends on-premises installation with Kubernetes or Docker, for “the highest level of data security and control”.

The consequence is that the vendor loses sight of the data. Tonic’s team cannot open logs on its own side to see which names the model missed. To know whether the product works correctly on real data, someone has to sit inside the customer’s security boundary. That person is the FDE.

The official posting on Tonic’s careers page points the same way. FDEs are embedded in the customer’s team to “deploy and operate” Tonic applications as part of an end-to-end solution, and travel to customers up to 25% of the time. The work is mostly remote, but sometimes it has to be done on site.

Two postings, two sides of one job

Read either posting alone and you see only half the role. Put them side by side and it becomes clear that an FDE at Tonic handles infrastructure and contract scope as well as the quality of every row of data.

Aspect	Official posting (tonic.ai)	Remotive posting
Core work	Deploying and operating Tonic applications within the customer’s team	Running each customer’s data through the de-identification pipeline
Deliverable	A working end-to-end solution	Verified output and the technical sections of the client report
Feedback loop	Reporting back to Product and Engineering on the core platform	Turning every one-off fix into documentation, runbooks and product improvements
Commercial side	Helping define parameters for Professional Services	Not mentioned
What the posting stresses	3-5 years of customer-facing technical work, up to 25% travel	Checking output against specific error types

The table shows two things. The official posting treats the FDE as the person who keeps a deployment alive and helps define the scope of services work, which shapes how the company sells and prices. The Remotive posting is far more concrete: the job is to deliver a verified result.

Three errors to check in every dataset

The Remotive posting lists exactly what an FDE must look for in the output: missed entities, wrong replacements, and identities that have been wrongly merged or split. An engineer new to de-identification may assume only the first one matters. The other two are harder.

Picture a customer that runs a customer-service call centre and sends a batch of call transcripts through the pipeline. Within a single call, the customer is referred to as “Nguyen Van Minh”, at another point as “anh Minh” (an informal Vietnamese honorific), and later as “Mr Nguyen”.

If the system replaces these three forms with three different fake names, one person has been split into three. A model trained on that data will learn the wrong structure of the conversation.

The opposite error is just as bad. Another call has two people named Minh, a customer and an agent. If both are replaced with the same fake name, two identities have been merged into one.

And if somewhere a name is spelled out letter by letter over the phone and the system fails to recognise it, that is a missed entity, and real PII is leaking.

None of these three errors shows up in an aggregate “precision” figure. So the first thing to do with a new dataset is to sample by document type and read the output by eye. Then log errors in exactly those three categories rather than folding them into one overall rate.

The client report is accountability, not paperwork

The most telling detail in the Remotive posting is that the FDE writes the technical sections of reports sent to customers. The handling of sensitive data is therefore a deliverable with someone accountable for it, not an internal step that runs and is forgotten.

The difference is obvious the moment you start writing. “The pipeline ran on the full dataset” is a sentence anyone can write.

“In the sample checked, identity-splitting errors were concentrated in transcripts with informal forms of address, and were fixed with additional rules” is a sentence only someone who has actually read the data can write.

Customers pay for the second kind of sentence.

When the data stays put in the customer’s environment, the vendor cannot point to its own systems to prove the work was done correctly. The technical section of the report is where the verification work becomes visible, so it deserves the same care as code.

Every one-off fix must become a reusable asset

Every FDE team knows the risk: each customer becomes its own fork, and the engineer becomes the only person who understands it. Tonic addresses this risk in the job description itself.

The Remotive posting requires every one-off fix to be turned into documentation, runbooks and product improvements. The official posting asks FDEs to work with Product and Engineering to inform the core platform.

Go back to the call-centre example. The rule that maps “anh Minh” and “Mr Nguyen” to the same identity should not live forever in one customer’s script. It should be written up as a runbook entry on conversational data, and if it recurs at a second customer, proposed to the product team.

That is why Tonic needs FDEs rather than just support engineers. Every day, FDEs see error patterns that a product team in an office never would, precisely because the data sits behind the customer’s VPC.

What skills can you build before you have the title?

The requirement of 3-5 years of customer-facing technical work shows Tonic is not hiring new graduates for this role. But the skills can be built before the title, and in interviews of this kind you should be able to demonstrate three.

The first is installing software in an environment you do not control: Kubernetes or Docker on a locked-down network, with no internet access and narrow permissions.

The second is evaluating the output of an entity-extraction system by error type, not stopping at a single aggregate number. The third is writing for customers, in concrete sentences backed by figures from the sample you checked.

When reading FDE postings at any data company, look for phrases such as “client report”, “runbook”, “self-host” or “customer VPC”. They signal a role weighted towards accountability for results rather than demos.

On your CV, replace “deployed system X” with “deployed inside customer infrastructure, checked output by error type, left a runbook other teams could reuse”.

Tonic’s About page says the company believes data privacy is a human right. Any website could print that sentence. At Tonic, the person who has to put it into practice, record by record, inside the customer’s infrastructure, is the FDE.