Forward Deployed Engineer

Alinia’s Mission

At Alinia, we enable the safe deployment of AI business-critical operations in industries that rely on policy and value alignment and trust. We make safe LLM deployment more accessible and effective for enterprises in regulated industries.

The Role

At Alinia, Forward Deployed Engineers deliver a working solution for the regulated AI use case a client is struggling with, designed around their problem, their constraints and their architecture, and running in production.

Most of that work happens inside an architecture you did not design. Our detection has to fit alongside the client's model, their API gateway, their data pipeline and their approval process.

A large part of the role is understanding that landscape well enough to make good decisions in it: what to integrate where, what to measure, and what to tell them when the answer is not the one they were hoping for. For that you will need to understand the current system and problem well enough to know what to build and what reaches you is usually a symptom rather than a diagnosis.

In a large organisation the person living with the problem, the team that owns the system it sits in, and the people who set the rules it has to respect are rarely the same, and each holds a partial view. Reaching a useful answer means listening to all of them, reconciling what does not line up, and

forming your own view of what is actually happening.

So it is a hands-on engineering role with customer-facing work. You will be writing Python, reading other teams' API documentation closely, designing experiments and building evaluations and doing it alongside the client's engineers, who will not take your conclusions on trust, and their compliance

experts, who need to know what those conclusions mean for their obligations. You will move between both registers in the same meeting.

For most of the process (engagements) you are also the person the client associates with Alinia. What you say we can do becomes what they believe we can do, which is why being straightforward about limits matters as much as delivering. These relationships run for months.

What you will do

• Work with Alinia's engineering and research teams to design and deliver the integration each client needs, building and prototyping yourself where that is the fastest path, and turning the rest into work the team can pick up
• Be the bridge in both directions: translate a client's constraints into requirements our engineers can act on, and explain what the platform can and cannot do back to the client
• Understand and validate your understanding of the client’s stack
• Build reproductions, integrations, and evaluation harnesses in Python against our API and the client's stack
• Own technical delivery across multiple deployments from first prototype to stable production
• Codify working patterns into tools, playbooks, or building blocks that others can use
• Work directly with client engineers, technical teams and compliance SMEs
• Write up findings so they survive being forwarded to someone who was not in the room
• Bring what you learn back into the product, the gaps you hit in the field are the roadmap

What we look for

Non-negotiable

• Willingness to travel occasionally to customer sites as needed.
• You can debug something you did not build, with incomplete information, without guessing
• You measure before you conclude, and you can tell the difference between a finding and a hypothesis
• Write production-grade Python, and get to grips quickly with unfamiliar technical documentation, third-party APIs, cloud services, someone else's platform
• You are comfortable in front of a client: asking the question that exposes a misunderstanding, disagreeing with someone senior when the evidence says so, and sitting with an unresolved problem in the open rather than closing it prematurely
• You listen for the problem behind the request, and check your reading of it out loud before building anything
• You have built or deployed systems powered by LLMs or generative models and understand how model behaviour affects product experience
• Keep up with how the field is moving: new models, guardrail approaches and the tooling clients are already evaluating, so you can tell them what fits their case and what does not
• Work out where checks belong in agentic systems, where there is no single input and output: tool calls, retrieval steps, intermediate reasoning and the final answer are each a place something can go wrong
• Fluent in English and Spanish, a good part of our current field work happens in it.

The frameworks we encounter

You do not need all of these, and we do not expect anyone to arrive fluent in every one:

• Cloud platforms: GCP, AWS or Azure, and their managed AI services: Vertex AI, Bedrock, Azure OpenAI. Knowing where a model actually runs and what that implies for data residency comes up in almost every regulated engagement
• API gateways and service meshes: Apigee, Kong, AWS API Gateway. Control layers are frequently deployed as a gateway policy rather than in application code, so understanding request and response flows, and who owns them, matters
• Infrastructure as code: Terraform above all. In large organisations you rarely change anything by hand; you propose a change to someone else's module and wait
• Deployment and networking: containers, Kubernetes, VPC and private endpoints, and the difference between SaaS, VPC-hosted and on-premise from a client's security review perspective
• Identity and access: service accounts, OAuth, IAM roles, and the everyday reality of not having the permissions you need
• Data and orchestration: RAG pipelines, vector stores, document extraction, and the frameworks that string them together
• Observability: Cloud Logging, Datadog, Grafana. Much of the evidence you need during an engagement is already in someone's logs
• Agents and orchestration: LangGraph, CrewAI, MCP servers, tool-calling architectures, and tracing with Langfuse or LangSmith.

Also helps

• Background in security, DLP, compliance tooling or ML evaluation
• Having been the customer for this kind of product before

We are open on seniority. We would rather hire someone who fits the work than fill a level - tell us where you think you land.

How we work

• Small team, and the distance between the field and the product is short: engineering, research and go-to-market talk daily, and what you learn at a client on Monday can be a roadmap conversation the same week
• Work tracked in Jira and planned in the open, so what you are blocked on is visible to the people who can unblock it.
• Direct client contact from your first week.
• Engagements run for weeks or months rather than days, and you own yours end to end.