Building AI When You Cannot See the Customer Data

Some of the highest-paying and hardest forward deployed work happens in environments where you cannot actually see the data you are building against. In regulated industries, classified settings, and heavily governed enterprises, the data is off-limits, and yet you are expected to build AI systems that work on it. This is one of the most demanding versions of the role and one of the least written about, which is unfortunate, because the ability to build effectively without full data access is exactly what separates the engineers who can work in the most valuable environments from those who can only operate where everything is open.

This piece is about how forward deployed engineers build AI systems when the data is restricted, why the constraint is more common than outsiders assume, and why mastering it opens the doors to the best-paid work in the field. It is a genuine engineering discipline rather than a workaround, and the Forward Deployed Engineering Program treats building under governance constraints as core to the role rather than an edge case.

Key Highlights

• In regulated, classified, and heavily governed environments, you often cannot see the customer's real data, yet you must still build AI that works on it.
• This constraint is common in exactly the sectors that pay the most, so the ability to work within it is a direct route to the highest-value engagements.
• Building blind forces a more rigorous approach: precise specification of the data you cannot see, and systems that are robust to the reality you cannot inspect.
• Working with representative samples, synthetic data, and the customer's own people as your eyes are the practical techniques that make it possible.
• Governance is not just an obstacle, it is a discipline that produces more robust systems and protects both you and the customer.

Why you would ever build against data you cannot see

It sounds almost paradoxical to build an AI system for data you are not allowed to look at, so it helps to understand why this situation arises so often. In many of the most valuable enterprise environments, the data is genuinely restricted for good reasons. It may be classified, subject to privacy regulation, commercially sensitive, or governed by rules that simply do not permit an external engineer to view it. Healthcare records, financial data, defence information, and personal data under strict privacy law all fall into this category.

The result is a real and common situation: the customer needs an AI system built for their data, but the people building it cannot see that data. This is not an exotic edge case, it is the normal condition of working in regulated industries, and those industries are among the biggest and best-paying customers for forward deployed AI work. Far from being a niche problem, building without full data access is a core competency for anyone who wants to work in the sectors where the role is most valuable. The engineers who can only work where the data is open have quietly excluded themselves from a large and lucrative part of the market, which is why this skill is worth developing deliberately rather than avoiding.

The constraint forces better engineering

The first thing to understand is that building without data access, uncomfortable as it is, tends to force a more rigorous and robust approach than building with full visibility, and reframing it this way changes how you approach it. When you can see all the data, it is easy to build something tuned to the specific quirks you observe, which can be brittle when the data shifts. When you cannot see the data, you are forced to build systems that are robust to a range of possible realities rather than fitted to one observed reality.

This discipline shows up everywhere in the work. You have to specify precisely what you assume about the data, because you cannot verify those assumptions by looking, which makes your assumptions explicit and testable rather than implicit and hidden. You have to build systems that handle variation and edge cases gracefully, because you cannot inspect the data to find them in advance. You have to design for observability, so that once the system runs on the real data you cannot see, its behaviour is nonetheless visible through the signals it produces. Each of these is simply good engineering, but the constraint of no data access enforces it where full visibility often lets you get away with less. Many forward deployed engineers find that working under data restrictions made them more rigorous engineers, because the constraint removed the option of sloppiness. It connects to the same discipline as technical scoping under uncertainty, where reasoning carefully about what you cannot see is the whole skill.

Specify the data precisely, since you cannot look

When you cannot see the data, the specification of the data becomes your most important artifact, because it is your only substitute for observation. The engineers who build well without data access invest heavily in understanding and documenting exactly what the data is, even though they cannot view it directly. This is a discipline of precise questioning rather than direct inspection.

You work with the customer to establish the schema, the ranges, the distributions, the edge cases, the quality issues, and the exceptions, building a detailed picture of the data through description rather than sight. This requires asking exactly the right questions, because the customer will not volunteer the details that matter unless you know to ask. What does this field actually contain, how often is it missing, what are the strange values that appear, what happens at the boundaries, how dirty is it really? The specification you build through this questioning is what you design against, and its quality determines the quality of what you build. This is discovery applied to data you cannot see, and it draws on the same customer discovery skills that ground the whole role, turned toward the specific challenge of understanding data through description rather than inspection.

Work with samples, synthetic data, and proxies

Practically, building without data access relies on a set of techniques for approximating the real data safely, and knowing them is what makes the constraint workable rather than paralysing. Rarely is the situation truly zero visibility. Usually there are ways to work with something that stands in for the real data without violating the restrictions.

Representative samples, where the customer provides a small, sanitised, or anonymised subset that captures the shape of the real data without exposing the sensitive whole, are one common approach. Synthetic data, generated to match the specified characteristics of the real data, lets you build and test against something realistic without touching the actual records. Proxy datasets, publicly available or less sensitive data with similar structure, can serve for early development. Each of these lets you develop and validate your approach against something data-shaped, so that when the system finally meets the real data it has not been built entirely blind. The skill is choosing the right approximation for the situation and understanding its limits, since a synthetic dataset that misses a crucial real-world quirk will let a flaw through. Used well, these techniques turn an impossible-sounding constraint into a workable engineering problem, and they are central to building agentic AI systems in environments where the real data stays out of reach.

Make the customer's people your eyes

The most powerful technique for building without data access is not technical at all, it is human: use the customer's own people, who can see the data, as your eyes and hands. You cannot look at the data, but they can, and a well-structured collaboration turns their access into your insight without you ever seeing the restricted information yourself.

This means designing specific checks the customer's people can run against the real data and report back on, so that you get the information you need about the data's behaviour without accessing it directly. It means having them validate your assumptions against the real data, run your system against it and describe what happens, and investigate failures you cannot see for yourself. It also means building the customer's team into the development loop so tightly that their visibility compensates for your blindness. This is a collaborative form of engineering where your technical reasoning is paired with their data access, and the engineers who do it well get remarkably far into building a working system without ever violating the data restrictions. It depends on the trust and relationships you build inside the engagement, which is one more reason the first ninety days of relationship-building matter, because those relationships become your window into the data you cannot see.

Governance is a discipline, not just an obstacle

It is worth reframing the whole situation, because engineers often experience data governance as pure friction, and that framing makes the work harder than it needs to be. The restrictions that prevent you from seeing the data exist for genuine reasons: privacy, security, regulation, and the protection of people whose information is in that data. Treating governance as an enemy to be worked around, rather than a discipline to be respected, leads to worse outcomes and, in regulated industries, can lead to serious trouble.

The engineers who thrive in these environments internalise governance as part of the engineering rather than an obstacle to it. They build systems that respect the data restrictions by design, that keep sensitive data where it belongs, that produce auditable behaviour, and that give the customer confidence the AI is handling their data responsibly. This is not just compliance, it is a form of quality, because a system that handles sensitive data carefully is a better system than one that does not. In regulated industries, this respect for governance is often what wins the trust that makes the engagement possible at all, and it is a large part of why building under these constraints is such valuable, well-paid work. The engineers who see governance as a discipline they are good at, rather than a barrier they resent, are the ones who get to work in the most demanding and rewarding environments, which is exactly the kind of capability serious AI engineering preparation should build.

The validation problem when you cannot see the results

Building a system without seeing the data is one challenge, but knowing whether it actually works is another, and it is where building blind gets genuinely hard. Normally you validate a system by running it and inspecting the results. When you cannot see the data, you often cannot see the results either, which means you have to establish that the system works without the direct evidence you would usually rely on. This is the validation problem, and solving it is central to building without data access.

The answer is to design validation that the customer's people can perform on your behalf and report back on in ways that do not expose the sensitive data. You define specific, meaningful checks, correctness on known cases, behaviour on edge cases, error rates against a standard, and have the customer's team run them against the real data and tell you the results at a level of abstraction that protects the sensitive detail. You build in metrics and observability so the system reports on its own behaviour in ways you can see without seeing the underlying data. And you validate incrementally, confirming each piece works before building the next, so you are never far from evidence. This turns validation from something you do by looking into something you do by careful design and collaboration, and it is exactly the kind of rigour that building blind forces and that the Forward Deployed Engineering Program develops. Without it, you are not building AI, you are hoping, and hope is not an engineering strategy.

Why these environments pay the most

It is worth being explicit about the commercial logic, because it explains why this difficult skill is so worth acquiring. The environments where you cannot see the data, regulated industries, government, defence, healthcare, finance, are among the highest-paying customers for forward deployed AI work, and that is not a coincidence. They pay the most precisely because the work is hardest and the pool of engineers who can do it is smallest.

The difficulty compounds in these environments. The data restrictions make building harder. The regulatory requirements make the engineering more demanding. The security constraints limit your tools and access. The stakes are high, because these are exactly the sectors where getting AI wrong has serious consequences. All of this narrows the field of engineers who can operate there to those who have developed the specific discipline of building well under governance constraints, and scarcity drives compensation. An engineer who can build effective AI systems in a classified or heavily regulated environment, respecting every restriction while still delivering, is doing work that few others can, which is why these engagements command a premium. Developing the capability to work where the data is invisible is therefore not just a technical achievement, it is a direct route to the best-paid corner of the field, and it connects to the broader career economics of a role whose value comes from doing what others cannot.

The techniques at a glance

Bringing the practical methods together, here is how forward deployed engineers actually build when they cannot see the data.

No single technique solves the problem alone. Used together, they turn building against data you cannot see from an apparent impossibility into a demanding but tractable discipline, which is exactly what the most valuable forward deployed environments require. The engineers who master this combination are not doing anything magical, they are applying ordinary engineering rigour under an extraordinary constraint, and the constraint is precisely what makes the resulting skill scarce and well rewarded. That is the quiet lesson of building blind: the harder the constraint, the more valuable the engineer who can work within it.

The bottom line

Building AI when you cannot see the customer's data is one of the hardest and best-paid versions of forward deployed work, common in exactly the regulated, classified, and governed environments that pay the most. The constraint forces a more rigorous approach: precise specification of the data you cannot observe, and systems robust to a reality you cannot inspect. The practical techniques, representative samples, synthetic data, proxy datasets, and above all using the customer's own people as your eyes, turn an apparent impossibility into a workable engineering problem.

The deeper reframing is that governance is a discipline rather than an obstacle, and the engineers who respect it by design are the ones trusted to work in the most demanding environments. Mastering this constrained version of the craft opens the doors to the highest-value engagements, which is why it is worth developing deliberately rather than avoiding. Building that capability through the Forward Deployed Engineering Program, alongside applied agentic AI engineering, is how you make yourself effective exactly where the work is hardest and the demand is greatest.

The engineers who master building without data access are, in a real sense, proving that disciplined engineering can overcome even the hardest constraint, which is exactly the kind of capability the most demanding customers pay the most to secure.