A European customer-science and marketing-automation consultancy just posted a vacancy that reads like a love letter to a role that no longer needs a human body attached to it. The title says Data & AI Engineer. The body says something else: seventy percent of the responsibilities are "leadership and strategy," and the actual coding is delegated to teams the hire will "functionally lead." Read that list back, and you realize it is a job description for a very expensive routing layer.
What the role actually does
A customer-science consultancy lives and dies by a simple loop: a client comes in with a pile of transactional and behavioral data, the consultancy finds the patterns that matter, and they ship those patterns back as a model, a dashboard, or a campaign recommendation. The person in this posted role is not the one writing the gradient-boosting pipeline. They are the one deciding whether there should be a gradient-boosting pipeline, why it matters to the client's churn numbers, how it gets validated and governed, and what the roadmap looks like for the next four quarters.
That is a real job. It is also a job that is now almost entirely compressible into a well-orchestrated set of language-model calls with a structured knowledge base behind them.
What automates first: use-case identification
The role's first responsibility is "identify high-impact use cases and prioritize initiatives according to value." This is the softest target for automation in the entire job posting.
You build a system that ingests the client's data catalog — their tables, their column descriptions, their existing reports — and runs it through a series of structured prompts. The system prompt establishes the consultancy's playbook: look for churn-reduction opportunities, cross-sell signals, segmentation gaps, campaign-optimization targets. The model ranks candidate use cases by estimated business value (a function of reachable audience size and historical conversion rates) divided by implementation complexity (a function of data readiness and model type). Output: a prioritized backlog with one-paragraph justifications, delivered in the consultancy's house style.
This is a RAG pipeline with a scoring function. The knowledge base is the consultancy's past engagement deck — every use case they have ever pitched, every one that landed, every one that flopped. Feed those in as few-shot examples and the model will produce prioritization memos that read exactly like a senior consultant wrote them on a Tuesday afternoon.
What automates next: the interlocutor role
"Act as the reference interlocutor with Business, Technology, Risk, Operations, and Transformation."
This sounds like it requires a human. It requires a meeting scheduler and a summarization model.
The interlocutor role in a consultancy is mostly translation: the business team says "we want to know which customers are about to leave," the data team hears "build a binary classifier with a recall floor of 0.7 on the top decile," and the risk team hears "we need explainability documentation and a bias audit." A language model with access to the consultancy's methodology library does this translation in seconds. You set up a chat-integrated bot that accepts a question from any stakeholder group, routes it through the appropriate context window — business context for the business team, technical specs for the engineers, compliance framing for risk — and returns a formatted response with the right jargon density for each audience.
The "influence" the job description asks for is really the ability to say the same thing five different ways to five different audiences. That is literally what a well-prompted model does when you give it a persona and a tone directive.
What automates after that: governance and standards
"Establish AI governance frameworks that guarantee traceability, explainability, ethics, and regulatory compliance."
Governance is a checklist. It is a very important checklist, but it is a checklist. You have a model card template. You have a validation protocol. You have a bias-audit script. You have a documentation standard. The role's job is to make sure every model that goes to production has all of these attached.
An AI system does this by gating deployment. No model reaches the production endpoint without a completed model card, a passed validation suite, a signed bias audit, and a logged decision trail. The "governance framework" is a CI/CD pipeline with policy checks. The human's job was to define the policies and enforce them. The system enforces them automatically. The human's remaining job is to update the policies when the regulator publishes a new guideline — which happens twice a year and takes an afternoon.
The technical 30%
"Design and supervise analytical architectures on a major cloud platform. Technically guide Data Science teams in Machine Learning and Deep Learning developments. Review models."
This is the part that sounds hardest to automate. It is not.
Architecture review is a pattern-matching exercise. "Should this use the cloud vendor's managed ML service, its big-data platform, or its data warehouse?" is a question with a finite answer set conditioned on data volume, latency requirements, team skill mix, and budget. A model fine-tuned on cloud architecture decision trees and the consultancy's past project archive will produce the same recommendation a senior engineer produces, and it will produce it in the time it takes the human to open their email.
Model review is the most automatable task in the list. You run the model's code through a static analyzer for common ML pitfalls: data leakage in the train-test split, target encoding applied before splitting, deprecated library calls, missing feature importance logging, insufficient test-set size for the claimed confidence intervals. Then you run a language model over the code with a prompt that asks it to identify anything the static analyzer missed — unsupported architectural choices, hyperparameter ranges that don't match the problem structure, evaluation metrics that don't align with the business objective the use-case prioritizer defined earlier.
Where it breaks — the catch
Here is the honest part, because without it the rest is just a rant.
What does not automate cleanly is the moment a client stakeholder looks across a table and says, "I don't trust this." Not the model's output — the model itself. The idea of it. The moment when a human client needs another human to look them in the eye and say, "I have done this before, this will work, and if it doesn't, I will be here to fix it."
That moment is about accountability — the social kind, the kind you can't tokenize. A consultancy sells reassurance as much as it sells analysis. The client is not just buying a churn model; they are buying someone to blame if the churn model tells them to do something and it goes wrong. An AI system cannot be blamed in a way that satisfies a procurement committee. It cannot get on a plane. It cannot have a coffee with the client's CMO and quietly explain that the segmentation looks aggressive because the training window included a promotional period that distorted the signal.
That is the human's remaining job, and it is a real one. But it is five percent of the role, not seventy. The rest — the prioritization, the translation, the governance, the architecture review, the model review, the roadmap — is pipeline. And pipeline does not need a job title.
The verdict
This vacancy is a confession dressed as a hiring need. The company is asking for a person to do what a system can do, because the system doesn't have a professional profile and can't shake hands with the client's steering committee. Fair enough. But when the person they hire spends seventy percent of their week on work a pipeline could handle, they will know. And so will the person.
The question isn't whether AI can replace this role. The question is why the role still needs a full-time body when the work has already left the body behind.
