When a financial institution asks how long an AI implementation takes, the honest first answer is another question: which implementation. "How long" sounds like one question and is really three, because the work behind a single automated factsheet and the work behind an owned reporting pipeline differ by an order of magnitude, and a timeline that fits one will mislead on the other. The regulated setting sharpens this further. A parallel run before cutover, a documented sign-off, a rollback path, and an audit trail are not optional extras you can compress away; they are the parts that let the result answer a FINMA question afterwards, and they add real weeks that an unregulated project never budgets for. What follows is three realistic timelines, each with the phases inside it, and the one stretch almost every project underestimates.
The quick win is a single, bounded workflow with a clean data source and one owner: a monthly reconciliation, a recurring report, one factsheet produced by hand today. Realistically it runs 2–4 weeks, and the time divides into four phases rather than one. The first few days map the process end to end and measure a baseline, so there is a number to beat and to prove against later. The build itself is often the shortest phase. Then comes the parallel run, where the automation produces its output alongside the existing manual process until the two reconcile, which is where a regulated project spends time an unregulated one skips. Cutover happens only once that reconciliation holds. Scope this honestly and the quick win earns trust for everything after it; scope it as a demo and it produces a figure no one dares rely on.
The mid-scale engagement spans several systems that were never designed to speak to each other: a reporting process that pulls from a portfolio system, a spreadsheet layer, and a document store, for instance. Realistically 8–12 weeks, and the shape of the time surprises people. Most of it is not the automation. It is the diagnosis across systems, the data repair (the same figure carried at two values in two places, a lineage no one can fully trace), and the integration work. The model, or the automation logic, is a minority of the effort. Rollout is staged rather than switched: one team, then the next, each on its own parallel run. The institutions that treat the data-and-integration phase as the real project, and the automation as the easy part, are the ones whose timeline holds.
The platform build is a different commitment: an owned, documented reporting pipeline that will run for years and stay audit-ready as the underlying systems change. Realistically 4–6 months, and the added time buys breadth, not polish. The phases widen to include governance (who signs off, who is notified when a figure is wrong, how the previous process is restored within the hour), and the documentation and handover that let your own people run and audit the result without the partner in the room. This is the engagement where ownership is the deliverable: you hold the workflow, the code, and the documentation outright. The months are not the price of slowness; they are the price of a result you can defend and keep.
Across all three, one stretch is almost always underestimated: the second-month dip. The first weeks run on novelty and the easy 80% of the workflow; then the hard 20% surfaces (the edge cases, the exceptions a person used to handle by judgment, the reconciliation that does not reconcile), enthusiasm cools, and progress appears to stall just when a budget expected momentum. It is not a sign the project is failing; it is the project meeting the part that was always the real work. The way to budget for it is structural, not motivational: do not schedule go-live at the trough, keep the old process running in parallel straight through it, hold a contingency window in the plan rather than pretending the curve is a straight line, and name the dip at kickoff so no one mistakes a normal phase for a crisis.
What actually moves a timeline is rarely the technology. It is the number of systems involved, the state of the data underneath them, the clarity of the process before anyone automates it, and the cadence of sign-off inside the institution. A clean single-source workflow with a decisive owner closes in weeks; the same nominal scope across three systems with contested data and a monthly approval meeting takes months. These are the levers you control, and they are mostly settled before a line of code is written. It is why a serious partner measures before it quotes a timeline at all: a date offered before the process is mapped and the data is seen is a guess dressed as a commitment.
The discipline underneath every realistic timeline is the same one: narrow the work rather than widening it, start with the single workflow whose baseline you can prove, and let the proven case earn the next. That is how reporting across 39+ funds at IST Investmentstiftung was built, one measurable workflow at a time; the bilingual factsheet engagement that anchored it went live in roughly two months, not through a sweeping transformation but through this sequence run once and then again. If you want a timeline grounded in your own systems rather than a generic promise, an AI Audit is where it starts: it maps the workflow, measures the baseline, and scopes the real work, so the date you plan around is one you can keep. It is the same discipline that runs through everything we build.