There is a moment in every institution's first serious AI initiative when the question turns from what to build to who should build it, and the instinct is almost always the same: hire someone. Put a senior AI person on the payroll, the reasoning goes, and the capability becomes yours. For a small number of institutions — those where AI is becoming the product itself, the thing clients pay for — that instinct is right, and the rest of this piece does not apply to them. But for the great majority of regulated financial institutions, where AI removes operational friction without changing the core offer, hiring for it first is the expensive default. On the three axes that actually decide the outcome — cost, breadth, and risk — an implementation partner usually outperforms an in-house hire, and it is worth being precise about why.
Start with cost, but read it as commitment rather than a number. A senior AI hire in Switzerland is a scarce, slow appointment and, once made, a standing fixed cost that continues whether the pipeline of AI work does or not — salary, benefits, tooling, and the management attention a specialist role demands, carried every month regardless of how much there is to build. An implementation partner's cost is scoped to the work: it rises when there is a workflow to automate and stops when the work is done and handed over. For an institution with a handful of processes worth automating rather than a permanent backlog, paying for a capability by the engagement rather than by the year is not merely cheaper — it matches the cost to the actual shape of the demand.
The second axis is breadth, and it is where the in-house instinct quietly fails. A single regulated automation is not a single skill. It needs a process mapped end to end, a data foundation audited and repaired, an integration built across systems that were never designed to talk to each other, the automation itself, and the audit-readiness that lets the result answer a FINMA request afterwards. That is rarely one person's skill set; most of the work, in fact, is process and data rather than model. A lone senior hire covers one slice of it well and improvises the rest, while a partner brings the mix — the process discipline, the data engineering, the integration, and the compliance-aware build — as a matter of course. Hiring one person to do the work of a team is how a promising initiative becomes a bottleneck.
The third axis is risk, and here two distinct exposures compound. The first is hiring risk: in a market this scarce, the wrong senior appointment is a long and costly correction, and you rarely know you have made it until months have passed. The second is key-person risk, which regulated finance punishes hardest of all — a process whose only author is a single employee is orphaned the day that person leaves, and an unowned, undocumented automation is a finding waiting to be written. A partner carries neither exposure in the same way: there is no single hire to get wrong, and the engagement is a standing commitment to monitor the automation, keep it current as the underlying systems change, and be answerable for it long after go-live.
None of this holds unconditionally, and the condition is the one institutions most often forget: ownership. The partner advantage survives only if you own the workflow, the code, and the documentation outright, and can run and audit the process without the partner in the room. A partner you cannot leave is simply a different dependency, and in some ways a worse one than an employee. So the real question is not partner-or-hire in the abstract but which route leaves you with an owned, audited process and no single point of failure — and a serious partner engineers for exactly that handover rather than against it, because a process you can run yourself is the proof that the work was done properly.
Read this way, the staffing decision resolves into something close to a rule. Where AI is genuinely core to what the institution sells, build the team and accept the cost and risk of doing so. Everywhere else — which is most of regulated finance — most institutions need no dedicated AI hire at the outset at all; the work is better bought by the engagement while the internal muscle is still forming. As AI use scales, the right first hire is usually not a builder but a technical generalist who owns the partner relationship and the vendor governance around it, and a dedicated internal team becomes worth its cost only at a scale most institutions never reach. The sequence matters: buy the capability, learn what you actually need from having used it, and only then hire against a requirement you can name.
The discipline underneath the decision is the familiar one: narrow the work rather than widening it, and let a proven case earn the next rather than committing to a standing team before the first process has paid back. That is how reporting across 39+ funds at a leading Zurich investment foundation was built — through an engagement scoped to one measurable workflow at a time, each earning the one after it, not by first assembling an in-house AI department and hoping it found the work. If you are weighing an in-house hire against a partner and want to decide it on evidence rather than instinct, an AI Audit is where it starts: it maps the workflow, the baseline, and the real scope, so the staffing question answers itself. It is the same discipline that runs through everything we build.