Production AI on a fund's stack is infrastructure, not a chatbot. It runs as a set of narrow, monitored services wired into your existing systems: the OMS, the data warehouse, the document store, the compliance log. It does specific jobs, returns structured output, and gets watched the same way you watch any other process that touches a position or a client. The demo you saw in a vendor pitch is the easy 10 percent. The other 90 percent is data plumbing, evaluation, and controls.
Where it actually lives
A working system sits behind your firewall or in your cloud tenant, next to the data it reads. It pulls from the same sources your analysts use: filings, broker research, internal memos, market data, portfolio and risk systems. It writes to a place a human reviews before anything acts. The model is one component. Around it sit a retrieval layer, a prompt and tool definition that is version-controlled like code, an evaluation harness, an audit trail, and access controls that respect who is allowed to see what.
The model itself is usually a hosted frontier model called through an API, or an open-weight model you run in your own environment when data residency requires it. The choice is an engineering decision driven by sensitivity, latency, and cost, and it is reversible. The plumbing around the model is the durable asset.
What it does well today
The reliable use cases are bounded and verifiable. They include:
- Document work. Reading credit agreements, LPAs, fund docs, and 10-Ks to extract specific terms, covenants, and changes across versions.
- Research synthesis. Summarizing a stack of broker notes or a data room into a structured brief with citations back to the source line.
- Diligence and monitoring. Flagging anomalies in filings, news, or portfolio company reporting against a defined checklist.
- Internal retrieval. Answering questions over your own memos, models, and prior IC materials so knowledge does not walk out the door.
What these share: a human can check the output against a source in seconds, and a wrong answer is caught before it costs anything.
What separates production from a pilot
A pilot impresses a room. Production survives a Monday morning when the data feed changed format overnight. The difference is in the parts nobody demos.
If you cannot measure when the system is wrong, you do not have a production system. You have a liability with a nice interface.
Three things make it real. First, evaluation: a fixed test set of real cases with known correct answers, run on every change, so you know accuracy before you ship and notice when it drifts. Second, observability: every input, output, and source logged and queryable, so when someone asks why the system said X, you can answer. Third, a human in the loop at the point of consequence, with the output structured so review is fast rather than a second full job.
What it is not
It is not making investment decisions on its own. It is not connected directly to execution. It is not a single model that does everything. Production systems are narrow and composable. You ship one that reads credit docs, prove it, then ship the next. Firms that try to build one system that does everything ship nothing.
How to start
Pick one task that is repetitive, document-heavy, and verifiable. Get the data access and the evaluation set in place first, because that is the work that takes time. Run the system in shadow mode next to the human doing the job until the numbers earn trust. Then expand. The teams that win treat AI as software that needs the same testing, logging, and review discipline as a risk model, because that is exactly what it is.
If you want to map which task on your desk is the right first one, book a discovery call.