AI & ML Engineer - Automotive Application

ENGIBEX is a Belgian R&D engineering consultancy, founded fourteen years ago, with around 95 people. Most of us are engineers with a master, PhD or postdoc background, working on our clients' R&D projects in powertrain electrification, embedded software, mechanical design, simulation, test and validation.

We work in two modes. Most of our engineers work on site within a client team. In a smaller number of cases, including this one, we take a work package: ENGIBEX owns a topic end to end and is accountable for the result, not just for the headcount.

Whatever the mode, ENGIBEX is your employer. Your contract, your salary, your car and your career path sit with us, and they do not end with a project.

Le poste :

The project

Our client is an automotive R&D centre in Limburg, Belgium, specialised in hybrid transmissions. They design, develop and validate their own products, with their own test facilities.

They are not a software company, and that is precisely the point. Over the past years, AI has moved from a side experiment to something their engineering teams actively ask for: a way to read their test data faster, to find their own documentation, to compare one programme against the history of all the others. The requests now come in faster than one person can absorb.

ENGIBEX runs that AI portfolio as a long-term work package. We scope the topics with the client, build the tools, deploy them and maintain them.

The team and how we work

The first ENGIBEX AI engineer has been in place since mid 2026 and owns the existing tools. You will be the second.

The client's R&D organisation is built on pairs: two people per discipline, so that topics can be shared, covered during absences and swapped when interests change. This role creates the second seat on the AI side.

Concretely, that means:

• You and your colleague split the portfolio between you, based on interest and availability, and you can rotate topics over time.
• You report technically to the client's virtual engineering leader, on a daily basis.
• Your ENGIBEX business manager follows the project closely, with regular touch points, and formal project reviews with you and the client several times a year.
• You are not alone on an island: you have a peer on the same topics, an ENGIBEX technical network behind you, and the possibility to bring in additional ENGIBEX support when a topic needs it.

What you will work on

The scope grows with the demand. Today it covers three families of topics.

Anomaly detection on test-bench data

Transmissions are run through accelerated durability tests on dedicated test benches, instrumented with a large number of sensors. The goal is to detect a developing failure from the signals, early, while the test is still running.

A model already exists and works offline on historical data. The current challenge is the step that nobody in the market seems to have taken on this kind of application: moving it online, so that it monitors a running test in real time, surfaces anomalies on a dashboard, and eventually raises alerts, without ever interfering with the test itself.

That involves retraining on new transmission families, separating real anomalies from legitimate operational events, proving the accuracy to the test engineers who will rely on it, and then scaling it from one test bench to many.

Internal LLM assistant

The client runs an internal, retrieval-based assistant on their own technical documentation, used by several hundred engineers. It has no access to the internet and is fed entirely by internal documents.

The work here is a mix of product and engineering: retrieval quality, document indexing, access management and permissions, new use cases requested by teams, deployment hygiene, and the unglamorous but decisive part, getting more people to actually use it.

New AI tooling for the engineering teams

This is the part that keeps growing, and where you will have the most freedom. Examples currently on the table:

• Comparing the requirements of a new programme against the history of past programmes, inside their requirements management platform, so that engineers stop rediscovering what was already decided.
• Predicting physical quantities in real time, such as component temperatures, from test or simulation data, to support calibration work.
• Applications around their simulation activities.

You will not be handed a backlog of tickets. You scope the problem with the engineering teams, build the solution, deploy it, document it, and convince people to use it.

Technical environment

• Language: Python, for everything.
• Data: sensor time series acquired with Vector CANape, stored in MF4, read in Python.
• Compute: an internal simulation cluster on Red H