What makes a great AI team: the skills that matter

The instinct when building an AI team is to hire the strongest modeller available. It is the wrong first hire in most mid-market companies, and the reason is visible in where AI projects actually fail.

They fail at the data, at the handover to production, and at the point where a business user decides whether to trust the output. Almost never at the model.

The capability mix, weighted by where projects fail

Data engineering — the one to hire first

Every stalled AI project I have seen was stalled on data, not on modelling. The pilot worked on an extract someone cleaned by hand, and reproducing those hundred small judgement calls in a pipeline turned out to be the real project.

What this person does: builds pipelines that run without supervision, resolves entity identity across systems, instruments lineage so an output can be traced back, and makes the difference between “we have data” and “we can answer this question repeatably”.

If you can hire one person, hire this one.

Machine learning depth — less than you think, but not zero

Foundation models can be rented. What cannot be rented is the judgement to know which problems are suited to a model at all, how to evaluate one honestly, and when the answer is a rule rather than a model.

That last skill is undervalued. A senior practitioner who says “this is three if-statements, not a model” has saved more money than one who builds an elegant classifier for a problem that did not need one.

What to look for: evaluation methodology, awareness of failure modes, and the ability to explain why a model is wrong in a specific case.

MLOps and production engineering

The gap between a notebook and a system is where most pilots die. Versioning of model and data, a way back to the previous version, monitoring for input drift, logging every output for traceability.

None of it is glamorous and all of it determines whether the model survives contact with the business. Without it the failure mode is specific: the model runs, quality degrades slowly, nobody notices until a customer complains, and then nobody can reconstruct which version decided what.

Software engineering discipline

An AI system is a software system. Tests, code review, deployment automation, dependency management. Teams that treat AI as research and skip these produce systems that cannot be maintained by anyone except their author.

The non-technical skills that decide the outcome

These are usually listed as a footnote. In practice they decide more outcomes than the technical mix does.

Explaining a result to someone who will not check the maths. A model whose output cannot be justified in business language will not be used for anything consequential. The person who can say “it flagged this because these three factors, and here is where it is unreliable” is the reason a system gets adopted.

Knowing what the business actually decides. The most common failure of a technically strong team is building something correct that nobody needed. Someone has to be close enough to the business to catch that early — and willing to say that a requested project is not worth doing.

Saying no to the impressive version. There is almost always a smaller system that answers 80% of the question and can ship this quarter. Choosing it requires a kind of discipline that does not come naturally to a team hired for technical ambition.

Governance is now a capability, not a checkbox

For DACH companies this has moved from optional to structural.

Under the EU AI Act, high-risk systems require documented data governance, technical documentation, logging, and human oversight with a defined role. Under revDSG/nDSG and GDPR, automated decisions affecting individuals have to be explainable.

None of it can be produced retrospectively — provenance of training data and a record of what the system decided are exactly the artefacts you cannot reconstruct. That makes governance an engineering responsibility, held inside the team, rather than a review someone else does at the end.

The detail is in the EU AI Act is enforceable: what DACH CTOs should do now.

Building the team in a Swiss market

These profiles are scarce and slow to hire here. A realistic shape rather than an aspirational one:

• Internal and permanent: whoever holds the business knowledge — what the data means, which exceptions matter, which decision actually counts. This cannot be bought and should not be outsourced.
• External and flexible: the capabilities needed for a build rather than forever — MLOps setup, pipeline construction, evaluation methodology. Bring in people who have done it several times, and require that they leave a team able to run it.
• Hire first for data engineering, then MLOps, then modelling depth. That order matches where the work is.

An 18-month AI plan that depends on hiring three specialists in Switzerland is a plan with a hiring risk at the front of it. The mixed model exists because that risk is real.

What “good” looks like

A team that is working has some observable properties:

• It can state which decision each system improves, and who makes it
• Every production system has a named owner and a way to switch it off
• Output can be traced to its inputs without an archaeology exercise
• Someone in the team has recently argued against a project

The last one is the best single indicator. A team that has never declined anything is not exercising judgement.

Related reading

• Six AI adoption challenges Swiss companies hit
• AI architecture: why data governance decides the outcome
• MLOps & AI infrastructure

If you are assembling this capability, book a call. No obligation.