In part one we set out why we chose finance, a sector that holds the best-shaped work for AI of any industry we looked at along with the most legitimate reasons to refuse it. Every barrier we ran into turned out to be a governance problem before it was a model problem, and that has determined both what we built and who we hired.
We assembled the team accordingly, with AI engineers who have spent their careers on enterprise-grade governance, and finance people who have themselves done the work we are now automating.
The order we build in
We build AI applications for finance on top of a control plane that sits inside the customer’s own environment, so their data never leaves their tenant and we hold none of it. Three things follow from that architecture.
The first is that policy gets enforced before a model runs, which means a prompt carrying client PII is stopped at the gateway while stopping it still counts for something.
The second is that every decision lands in an audit trail the firm owns and can export, covering the actor, the model, the tool, the data class and whether the request was allowed or denied, which is the artefact a regulator or a board actually asks to see.
The third is that token cost is metered by user, team and model, so somebody inside the firm can answer the ROI question a CFO will eventually ask. Most firms cannot answer it today, because their AI spend arrives as a single undifferentiated invoice.
Without provable oversight an AI project in financial services never reaches production, however good the output looks in a demo.
Applications inherit all of it, so a credit document agent or a compliance monitoring workflow built on the plane arrives with policy, audit trail and cost attribution already attached, and nobody has to retrofit governance once the pilot has succeeded.
In most industries that would read as a feature list, but in this one it is the precondition, because without provable oversight an AI project in financial services never reaches production, however good the output looks in a demo.
Why we hired for domain as well as platform
We brought in a solutions engineer out of private credit at the point where most companies our size would have hired another platform engineer. Buyers in this sector commit once they feel understood, and feeling understood means that somebody on the call has read an indenture, sat through a compliance review and can describe what the work actually involves.
It is also the fastest way to avoid building the wrong thing, since a workflow that looks like plain document extraction from the outside usually turns on an exception the vendor never knew existed.
The test we hold ourselves to
Before we build anything we ask whether the firm could show a regulator exactly what the AI did, on what data, under whose authority and at what cost. Where the answer is yes, the project can go to production. Where the answer is no, that gap is itself the project, and it gets built first.
MisaLabs builds the enterprise AI control plane. Govern AI usage. Prove the ROI. In your environment.
Talk to us →