Remote or in the office: what AI jobs really offer

Anyone looking for a position in machine learning or generative AI runs almost immediately into an abundance of flexible promises. Terms such as 'fully remote', 'hybrid freedom', and 'location-independent working' dominate the recruitment channels. This article is aimed specifically at candidates, data scientists, and software developers who want a realistic assessment of what Dutch and European employers actually facilitate today. The reality turns out to be considerably more nuanced than the recruitment copy suggests.

Between a formal job listing and the eventual employment contract there is often a substantial gap. Factors such as data processing legislation, access to secured cloud infrastructure, team dynamics, and hardware management place strict limits on the degree of physical absence. To understand how these ratios sit within the broader context of the sector, it helps to look at the analysis in the overview of the Dutch AI job market, which explores demand for specialists and regional differences in more depth.

The promise versus the reality in job listings

When an organization advertises a 'remote AI engineer' role, a first-round conversation regularly reveals that a strict geographical limit applies. Employers often use a model in which 'remote' simply means the employee may work from home within the borders of the Netherlands. This has primarily to do with payroll taxes, social insurance contributions, and employment law obligations. A developer who expects to program from Southern Europe or Southeast Asia on a Dutch contract almost always runs into tax objections.

We also see that the term 'hybrid' is subject to considerable inflation. Where it once stood for full autonomy for the specialist, it increasingly means a mandatory minimum of two to three fixed office days per week. This shift is often driven by management teams that want to keep a grip on complex development projects and integration work. Organizations struggling with internal alignment frequently fall back on physical presence to minimize communication noise.

For those who want to operate internationally without being tied to local office days, moving to foreign clients is sometimes the answer. How to set up such an arrangement practically and contractually is covered in the guide on working remotely and internationally from the Netherlands, which goes deeper into the differences between local employment and international contracts.

Data sovereignty and security as remote blockers

One of the biggest obstacles to fully remote work in AI roles is the nature of the data being handled. Machine learning models and LLM applications are trained on, or connected to, sensitive corporate or personal data. Under the GDPR and the European AI Act, security officers set strict frameworks for the environments in which data may be accessed. Working from an unsecured home location or over public networks immediately meets objections from compliance departments.

In sectors such as financial services, healthcare, and the public sector, it is not unusual for data files to be accessible only through walled-off virtual desktop interfaces (VDI) or even physical office workstations. Developers therefore face restrictions on their tooling. Latency on remote connections and strict zero-trust architectures can considerably slow the daily workflow of inspecting datasets or running local evaluation loops.

Employers with such security requirements therefore often demand that model development and data analysis take place within a controlled perimeter. In practice this leads to situations where experiments and data preparation have to happen in the office, while general programming work and documentation may be done remotely. The result is a forced hybrid structure that rests purely on compliance grounds.

Hardware, compute power, and local versus cloud development

The technical infrastructure a team has at its disposal largely determines how flexible a working arrangement can be. There is a clear operational difference between teams that rely entirely on cloud-based clusters (such as AWS Bedrock, GCP Vertex AI, or Azure ML) and teams working with their own on-premise hardware or local GPU workstations. In theory, cloud infrastructure makes remote work easy, but the reality of cost control and debugging regularly throws a spanner in the works.

When engineers have to fine-tune or quantize large models locally, heavy hardware is required. Not every company provides remote employees with workstations carrying multiple high-end GPUs for home use. Often the work runs over SSH connections to central compute clusters at the office or in a local data center. If those connections are unstable, or if physical intervention is needed on test setups (with edge AI or embedded systems, for example), physical proximity to the hardware is unavoidable.

Below is an overview of how various AI disciplines relate in practice to physical presence and remote options:

Junior versus senior: the imbalance in flexibility

A sharp dividing line is emerging between policy for entry-level professionals and policy for experienced staff. For juniors and trainees, employers almost without exception require that they spend the majority of the working week in the office. Transferring context about complex data architectures and instilling software engineering best practices simply goes less smoothly through a screen than at a desk.

Seniors and lead engineers, by contrast, regularly negotiate far-reaching remote terms. Because they are able to make technical decisions independently, align architectures, and review pipelines, companies accept greater physical distance from them. Yet this is exactly where the problem lies: a junior in the office without senior colleagues nearby learns slowly, which leads many organizations to introduce a mandatory shared office day for the entire team after all.

Candidates sometimes try to bridge this gap with formal qualifications to demonstrate their independence. How certificates are weighed during the selection procedure is analyzed further in the article on the real value of AI certifications and training, which makes clear that practical flight hours count for more than theory certificates.

Organizational dynamics: cross-functional collaboration

AI models rarely function in a vacuum. A model only delivers value when it integrates seamlessly into existing software, processes, and decision-making chains. That requires continuous alignment between data specialists, backend developers, product owners, domain experts, and compliance advisers. When these groups work in a fully distributed way, functional islands form quickly.

In practice, organizations with low AI maturity have the most difficulty with remote AI teams. Because the specifications of AI projects are often iterative and unpredictable, miscommunication about what a model can and cannot do arises quickly. Physical working sessions at a whiteboard are still the fastest way in many organizations to align expectations about model performance and business logic.

For organizations that want to understand how this team interaction can best be designed during a technology rollout, the deep dive on guiding teams through AI adoption offers practical tools for structuring cross-functional work processes.

The hidden costs and drawbacks of remote AI work

Although working from home offers advantages in travel time and focus, it brings specific drawbacks for AI professionals that are rarely highlighted. Isolating complex bugs in distributed training jobs or tracing data drift demands deep concentration, but also fast feedback loops with colleagues. Subtle observations about data anomalies regularly get lost through chat channels and video calls.

Another structural drawback is visibility within the organization. Because AI projects are often expensive and experimental in nature, results have to be defended and presented internally to management continuously. Engineers who work exclusively remotely lose touch with strategic course changes more quickly and risk being seen as purely executing staff rather than as steering sparring partners.

Finally, the mental load of asynchronous communication plays a role. When team members operate in different time zones or log in at varying hours, code reviews and pipeline approvals are delayed. A blockage in a training pipeline can last hours simply because a colleague who has to approve data access is not online yet.

How to see through the appearance during the job interview

To avoid signing for a job that turns out to be less flexible in practice than promised, it is essential to ask targeted, operational questions during the application process. General questions such as "What is your work-from-home policy?" usually produce rehearsed HR answers. You only get a realistic picture by zooming in on the technical day-to-day.

Ask, for example, how production incidents are resolved outside office hours, which tooling is used for remote debugging, and how data access is arranged for people working from home. If it turns out that retrieving production data for error analysis requires you to log in physically at a secured office location, you know immediately that 'fully remote' is an illusion in practice.

The checklist below shows concrete questions that reveal the actual working arrangement during a technical interview:

Conclusion: taking stock for your career

The conclusion is clear: the remote AI job does not exist in absolute terms. What companies offer is a spectrum ranging from heavily secured, office-bound R&D roles to flexible integration roles in which almost everything runs asynchronously and through the cloud. For candidates, the task is not to sail blindly on flexibility claims in advertisements, but to match the real requirements of the role to their own ambitions and preferences.

Anyone seeking rapid professional growth, especially early in a career, often benefits precisely from the proximity of experienced colleagues at a physical workplace. Those specialized in MLOps, API integrations, or architecture design, by contrast, can achieve a high degree of freedom with the right preparation and sharp contractual arrangements. Make sure you test the technical and contractual preconditions thoroughly in advance, so that daily practice matches the agreements made.