How do private equity funds roll AI out across their portfolio companies?
Start with one portfolio company and one bottleneck that matters to the value-creation plan, prove the change there, then carry the method to the next company with its own owner and baseline.
The fund side and the company side need different things. The fund team needs a view of where AI can move the plan across the portfolio, and one consistent way to report it. Each company needs someone who picks the problem, builds the fix with its own people and reports the change in terms the board recognises. Few mid-market funds have a Head of AI on the team, and most do not need a permanent one yet. An AI Operating Partner can cover both sides for a defined period: the portfolio view for the fund, and hands-on delivery in the first companies.
What travels between companies is the method, the review points and the reusable components. Data, permissions and baselines stay with each company.
Do you build the solution, or only advise?
Both: Javier designs the workflow with your team and builds it himself, working with your technical people on the architecture and the code.
That is why the practice exists. Advice that stops at a roadmap leaves the hardest part, the build and the rollout, with the people who have the least time. The configure-price-quote application in the case below was built by Javier in around six weeks, covering architecture, development, QA and design. AI tools speed up the build. What runs in production is decided step by step: a model where it adds value, explicit rules where the result has to be exact.
Where you already have a strong engineering team, the role shifts to design, review and the decisions about what to buy, integrate or build.
What have you actually delivered?
The clearest example is commercial quotes at a PE-backed European SaaS business of around 300 people, where preparation went from around two days to two hours.
A quote moved between Sales, Sales Engineering and Finance through manual steps. Javier mapped the process with the three teams, agreed what to automate and where human review stays, then built the application. Pricing stays deterministic, with rules and review points agreed with Finance.
In the same business, quarterly business review preparation went from six hours to one, drawing on six sources, and the work per request for proposal fell from 25 hours to 10, across around 60 a year. Before that, the Sales Engineering function he built from zero lifted the win rate on complex deals from 14% to 27%.
How does an engagement work, and what do you need from your team?
Most engagements start with a short diagnostic of two to three weeks on one bottleneck, then move to delivery, either as a focused project or as an interim or fractional mandate.
From your side it takes a sponsor who can make decisions, the people who run the process for a few working sessions, and access to the systems involved. The process owners carry the most weight: an hour or two each during the diagnostic, then short reviews of what gets built. Nobody is asked to write requirements documents.
Scope, timing and fees are agreed after the first conversation, once the problem is clear.
Where do we start?
Start where time or money is lost in a process you run every week, with a team that wants the change and a result the board would recognise.
A broad AI audit across every function tends to produce a long list and little movement. One workflow, measured before and after, produces a result and a method the next team can reuse. In commercial teams that is often quotes, proposals, account preparation or follow-up. In operations it is reporting, document-heavy checks, or work that moves between systems by hand.
The first two weeks settle three things: where the loss is, what fixing it would be worth, and who will own it once it runs.
Where does the model run, and is our data safe?
The work runs on your systems and accounts, with model providers on business terms that do not train on your data, and the code, instructions and data stay with you.
Before anything is built, we agree which data the workflow may read, which actions it may take, which ones need a person to approve, and who notices when something goes wrong. For confidential or privileged material, that can mean keeping a step out of the model entirely, or using a model deployed in your own cloud tenancy. Your security and data owners are part of the design from the first week.
Can we check and explain what it does?
Yes, when it is designed for that from the start: steps that must be exact run on explicit rules you can read, and every model output that matters has a named reviewer and a source you can trace.
A black box nobody can validate puts you back where you started. So the design separates what a model does well, reading and drafting from messy inputs, from what has to be exact, like prices, figures and approvals. The quote application is the example: AI tools were used to build it, and the pricing logic it runs is deterministic.
What happens when you leave?
Your team keeps a working function: the configuration, the instructions, the measures and a named owner for each workflow, so a permanent hire inherits a working function instead of a blank page.
The handover is planned from the start. Training, documentation and usage reviews run alongside the build, and each workflow has an owner inside the company before it goes live. Support continues only where it is useful, at a cadence you choose.
How do you measure the value of AI?
Measure it the way the board already reads the business: time returned per team after review and maintenance, actual cost changes including running costs, and revenue effects tracked apart from activity.
The baseline comes first, measured on real work before anything changes. Hours saved count once you know what the team does with them. In a business that bills by the hour, saved time can mean less revenue unless pricing or capacity changes with it, so that question gets settled before the build.
What does an interim AI leader do in the first 90 days?
By day 90 an interim AI leader should have agreed priorities, named owners, a baseline for each priority and at least one improvement in daily use.
The first month goes on the diagnostic: where time and value are lost, what is already running, and what the team will trust. The second month builds the first improvement with the people who will run it. The third rolls it out, sets up the routine that keeps it alive (an AI champion in each team, a weekly forum, a monthly leadership review) and sequences what comes next. If a permanent hire is coming, they inherit that plan and a result.
How long does an AI pilot take to reach production?
A narrow workflow with a clear owner can be in daily use in six to ten weeks, and most pilots that take longer are waiting on decisions.
The build itself is rarely the slow part; the quote application took around six weeks. Pilots stall when nobody has agreed what a good output looks like, who owns the workflow, or which cases it should handle. The team then uses the tool for the easy cases and keeps the old way for the important ones, and the usage figures look the same either way. Settle the definition of good, the owner and the review points before building, and the timeline holds.
When do the EU AI Act high-risk obligations apply?
The standalone high-risk obligations under Annex III apply from 2 December 2027, and those for high-risk AI built into products covered by Annex I from 2 August 2028, after the final Digital Omnibus moved both dates back.
Some parts of the Act already apply. The prohibited practices and the AI literacy duty have applied since February 2025, and the penalty framework and the obligations on general-purpose model providers since August 2025. Most mid-market AI use is minimal risk. The useful work now is an inventory of the systems you run, a first classification and owners for the borderline cases. Binding classification and conformity assessment are for an EU AI Act lawyer and, where required, a notified body.