Every financial services firm we speak to in 2026 has an AI initiative somewhere on the roadmap. Most of them are technically feasible. A meaningful number are quietly undeployable, not because the model performs badly, but because nobody worked out how the firm would explain a single decision to a regulator eighteen months after it was made.
That constraint shapes AI work in regulated environments, and it is worth designing for on day one rather than discovering during a compliance review.
The Question Compliance Will Ask
Regulators rarely ask whether your model is accurate. They ask a narrower and harder question: for this specific decision, on this specific date, what information did the system have, what did it produce, and who reviewed it?
A traditional rules engine answers this trivially. The rules were version controlled, the inputs were logged, and the output is reproducible by rerunning the same code. A language model call answers it badly by default. The model version changed, the prompt was assembled at runtime from three sources, the temperature was nonzero, and the response was never stored because it streamed straight to the user.
None of that is unfixable. All of it is much harder to retrofit than to build in.
What an Auditable AI Call Actually Stores
When we add an AI feature to an existing .NET system in a regulated context, the model call is the small part. The record around it is the deliverable.
At minimum, every inference gets persisted with the exact model and version identifier, the fully resolved prompt as sent, the complete response as received, the confidence score where the provider exposes one, the identity of the user or process that triggered it, and the downstream action taken as a result.
public sealed record InferenceRecord(
Guid Id,string ModelIdentifier,string ResolvedPrompt,string RawResponse,string TriggeredBy,DateTimeOffset OccurredAt,string DownstreamAction);
Storing this is unglamorous. It is also the difference between a feature that survives its first audit and one that gets switched off pending review.
Confidence Thresholds Are a Business Decision
The most common design failure we see is a system that treats every model output as equally trustworthy. In a regulated workflow, the interesting engineering happens at the boundary: what does the system do when it is not sure?
That boundary belongs to the business, not to the development team. A firm classifying transactions for anti money laundering review will set that threshold very differently from a firm summarising internal research notes. The engineering job is to make the threshold explicit, configurable, and logged, so that when it changes, there is a record of who changed it and when.
Below the threshold, work routes to a human. Above it, the system proceeds and still records everything. The human review itself becomes another entry in the same audit trail.
Where This Fits in an Existing .NET Estate
Most financial services firms are not starting fresh. They have a .NET Framework or .NET 8 application, a SQL Server database holding a decade of records, and a set of batch processes nobody wants to disturb.
The integration pattern that works is additive rather than invasive. The AI component sits alongside the existing system as a separate service with its own storage for inference records, called from the existing application at a well defined point in the workflow. The legacy system keeps its behaviour. If the AI service is unavailable, the workflow falls back to the manual path it used before, rather than failing.
This also means the feature can be turned off in an afternoon if a regulator asks for it, which is a property worth having before you need it.
The Honest Timeline
A demo of document classification over a sample of your invoices takes about a week. A version of the same feature that stores every inference, routes low confidence cases to a reviewer, exposes an audit view, and survives a penetration test takes considerably longer, usually a few months for a system of real size.
The gap between those two numbers is where most AI projects in financial services stall. The demo gets approved enthusiastically, the production requirements arrive later, and the original estimate becomes a source of friction with everyone involved.
Naming that gap at the start of the project, rather than discovering it at the end, is the single most useful thing a technical partner can do on a regulated AI build.
Start With the Record
If you are scoping an AI feature inside a regulated system, design the audit record before you choose a model. The record tells you what you need to capture, which tells you where the model call belongs in the workflow, which tells you what the model actually needs to return.
Teams that start with the model call and add logging afterward almost always end up rebuilding the integration. Teams that start by asking how they will explain this decision in two years tend to build it once.
