When a financial institution decides to automate a regulated task, the sourcing question usually arrives as an either/or: an AI consultant or an AI developer, as if the two were the same purchase at two price points. They are not. A consultant sells a decision; a developer sells built software. In an unregulated setting the wrong choice costs time. In FINMA-regulated finance the parts each one leaves untouched (the diagnosis on the one side, the running process on the other) are precisely the parts that decide whether an automation survives its first review. The honest answer is usually not one or the other but both, in sequence.
Start with the consultant and what the role actually does: the diagnosis before any code. A consultant maps the workflow end to end, measures a baseline, names the control points and sign-offs, decides what to automate and, just as often, what to leave alone, and frames the compliance question. The deliverable is a decision and a plan, not software. A consultant alone is the right engagement when the institution still needs to know whether and what, not yet how: when the thinking is unfinished, and committing to a build would be committing to a guess.
A developer turns a clear specification into working software, and does it well and often quickly given a mapped process, a defined data source, an agreed success metric, and a compliance owner already sitting inside the institution. The deliverable is the build. A developer alone is the right and efficient engagement when that thinking is genuinely done. The failure is mistaking the situation: hiring a developer to write code against a specification that does not yet exist, and discovering months later that the missing part was never the code.
This is why regulated finance usually needs both. A single regulated automation is not a single skill. Most of it is process, data, and compliance, and only a minority is code. Diagnosis and build are two different disciplines, and the institutions that stall have usually bought one and assumed it covered the other: a polished build for a problem no one diagnosed, or a thoughtful assessment that never became a running process. The question is not consultant or developer in the abstract, but which parts of the arc you still need to own.
The workable shape is an ordered one. Assessment and roadmap come first (the consultant's work: the baseline, the scope, the decision about what to automate), then the build and the integration across systems that were never designed to speak to each other (the developer's work), then the measurement back against the baseline (the consultant's work again). Failure design, the rollback path, and the audit trail are not a late step; they run across the whole arc, because in a controlled process the failure design is the design.
What to look for is not a title but accountability across the sequence: either a single party answerable from diagnosis to measured result, or a clean, documented handover between consultant and developer with no gap where ownership falls through. And the condition that outlasts either of them is ownership: you hold the workflow, the code, and the documentation outright, and can run and audit the process without the people who built it, with the data-residency and access arrangements written down. A partner who can draw you that picture before a file changes hands has owned a regulated result before.
That ordered discipline, narrowing the work rather than widening it and letting a proven case earn the next, is how reporting across 39+ funds at IST Investmentstiftung was built: one measurable workflow at a time, each carried through diagnosis, build, integration, and measurement before the next was attempted. If you are weighing a consultant against a developer 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 sourcing question answers itself. It is the same discipline that runs through everything we build.