Self-hosted AI for financial analysis
A quarterly forecast that hasn't been announced. A due diligence data room ahead of an acquisition. An internal margin analysis that would move the stock if it leaked a day early. Financial teams increasingly want an LLM to help read these documents faster, summarize a forecast model, flag inconsistencies across a data room, draft the first pass of an analysis. The documents involved are, almost by definition, material non-public information, and that's a different bar than most business content clears.
Why this data is unusually sensitive
Material non-public information carries a specific kind of risk that a generic "confidential documents" label doesn't fully capture. A competitor seeing it early is one problem; a bigger one is that anyone who sees it early, including an AI vendor's infrastructure, systems, or staff, is now in possession of information that could be used to trade on before it's public. That's true whether the leak is a person acting in bad faith or simply a document sitting somewhere it shouldn't, retained by a third-party system longer than intended.
M&A due diligence compounds this. A data room during an acquisition often contains the target's own MNPI plus the acquirer's strategic thinking about the deal, in one place, at the exact moment secrecy matters most before signing. Running that data room through a general-purpose AI product means a document that a handful of named people are cleared to see now also passes through a shared third-party service with a much broader set of hands that could, in principle, touch it.
What running the model on your own infrastructure changes
The mechanics are the same as any self-hosted document workflow: an instruct model, possibly paired with retrieval over the data room's documents the way semantic search works for a general document store, running entirely on hardware assigned to your organization. Forecast models, board decks, and diligence documents go to your model and stay there. There's no vendor retention policy to evaluate against insider-trading exposure, no question of whether the AI provider's own staff or systems could be considered to have had access to information that matters for disclosure timing.
This doesn't replace the access controls and information-barrier practices finance and legal teams already use around MNPI, restricted lists, need-to-know distribution, deal-code names. It's the same discipline applied to a new tool: if a document wouldn't go in an email to someone outside the deal team, it shouldn't go into an AI product whose infrastructure and access model you don't control either.
Where this fits in a workflow
Useful, lower-risk starting points: summarizing a long forecast model into a two-page brief for a board update, checking a data room for internal inconsistencies between documents (a revenue figure in the deck that doesn't match the underlying financials), or drafting the first pass of a variance analysis that a human analyst then checks and owns. None of these require the model to make a judgment call, they speed up the reading and cross-referencing work that currently eats an analyst's day.
Keep the model's output as a draft an analyst reviews, not a number that goes straight into a report. LLMs are good at reading and summarizing text; they're not a substitute for the actual financial modeling and judgment that a forecast or valuation requires, and treating model output as authoritative on numbers it didn't independently verify is a good way to introduce an error that's hard to trace back.
Access boundaries need to mirror the deal team, not the company
A company-wide internal AI tool is the wrong place to run deal analysis, even a self-hosted one, if the deal team is a smaller set of people than everyone with access to that tool. Standing up a separate, isolated instance scoped to the deal team means the access boundary matches who's actually cleared to see the documents, rather than relying on everyone with access to a shared internal tool to exercise restraint about a deal they technically shouldn't know exists yet. When the deal closes or falls through, that instance and its documents should be wound down deliberately, not left running as one more thing an ex-deal-team member still has a login for.
Logging matters more here than in most internal AI use cases. Because MNPI carries insider-trading exposure, being able to show who queried which document and when, if that question ever comes up, is worth having in place before it's needed rather than reconstructed after the fact.
Where the hardware fits
A single Spark's 128GB of unified memory comfortably runs a large instruct model for document analysis, with room for a retrieval layer over a data room's documents on the same box. For an active deal, isolating that workload on its own dedicated instance, rather than a shared environment used for other internal AI work, keeps the access boundary as tight as the deal itself requires. At $0.79/hour in EU-Central, standing up a dedicated instance for the duration of a deal costs less than the analyst hours it saves in the first week.