Michal Rachtan is the co-founder and CTO of Unit8, a Swiss data and AI consultancy founded in 2017 and backed by Sagard NewGen. Unit8 helps large regulated enterprises in sectors such as pharma and banking put technology from providers like OpenAI, Anthropic, and Palantir to work in their specific context. In this conversation, Michal explains how Unit8 uses AI internally, and how enterprises are approaching model choice and sovereignty. He also shares a candid view on why Unit8 still prices on time and materials even as AI compresses delivery hours, and what he looks for in a forward-deployed engineer. For senior leaders deciding how to deploy AI inside regulated institutions, his perspective from the consulting side of the table offers a practical counterweight to the technology-first narrative.
Here are our key takeaways from the interview:
- The Constraint Is Moving From Technology to Organizations: In Michal’s view, the pace of deploying technology is no longer the biggest bottleneck. Change management and the redefinition of roles inside regulated organizations take far longer than the technical work.
- Hours Are Compressing, Value Is Not: Integrations that once took months now take weeks, yet Unit8 continues to price on time and materials. Michal finds outcome-based pricing hard to scope early on, and notes that a vendor may not control every factor that drives the outcome.
- Enterprises Want Optionality More Than Open Source: Most clients are building architectures that let them switch between model providers, including open-source models served through hyperscalers. Central and private banks are the exception, often preferring to own the full stack on premises.
- Great Forward Deployed Engineers Combine Hard Skills With Curiosity: Strong engineering is non-negotiable, but the standouts are also curious, focused on customer value, and willing to challenge how a customer runs a process. Unit8 tests for this with an open-ended composition interview.
Let’s dive in.
Could you introduce Unit8 and how it positions itself in the market?
Michal: Unit8 was established in 2017, so we are now nine years in the market. We believe we occupy the space between big enterprise and the Silicon Valley technology providers. Picture a large regulated company in pharma or banking: they have disconnected data and disconnected processes, and they see a big promise in data and AI. Fulfilling that promise requires specialized talent, and that is the gap we fill.
We work with technology providers like OpenAI, Anthropic, Palantir, and others, and we help enterprises roll out that technology in their specific context. We do that by bringing our skills in technology advisory and consulting.
How is your team using AI internally across the business, from engineering to sales?
Michal: It is constantly evolving, because we keep discovering new places where we can deploy it. The most obvious is coding: producing code, building parts of the software, connecting to the data. A system integration that would have taken us a couple of months not long ago can now be delivered in a matter of weeks. Another area with a lot of innovation is process reimagination. In an enterprise, knowledge about how a process works is often poorly documented and sits with someone who has been at the company for ten years. We use AI to design structured interviews, transcribe them, and then ask the AI to reimagine the optimal process, including which parts need human vetting and which could be fully automated.
Beyond our core functions, all U8 departments have embraced AI, for instance, we use it in talent acquisition, where sifting through a large volume of CVs can be overwhelming and you can lose objectivity. AI can be more consistent when processing high volumes of data, and sometimes does that job better than we do. Algorithms don’t get tired; humans do. These are just a few examples, and we are still exploring how to further reimagine our internal processes.
AI is generating so much code that the bottleneck is shifting to PR reviews. Are you seeing that at Unit8, and how should teams respond?
Michal: Code review is definitely becoming one of the bottlenecks, and in some cases you could easily lose control of what is being deployed to production. One approach we use internally is to apply LLMs to PR reviews, so that the same kinds of tools we use to generate code are also used to review what is being shipped, rather than leaving the full burden with peers on the team.
That said, I see other bottlenecks that matter more. The pace of deploying technology is probably not the biggest constraint in our world. Our organizational capacity to absorb this innovation is becoming a much bigger one. Change management and shifts in roles inside a regulated organization take much more time than the technical deployment.
Given the caliber of your team, was change management an easy sell internally, or did some people still need a push?
Michal: The team was a bit divided. Parts of it adopted the new tools very quickly, while others had a harder time moving to fully agentic workflows where you delegate big parts of asset creation to LLMs. A couple of months back, I could still see some people using code completion tools. That is going away at this point, and we are moving to a fully agentic software development lifecycle in which inspecting code happens only on rare occasions. If you want to understand something, you use an LLM to interrogate the code base.
The change was gradual, and you always have a population that is more skeptical or slower to adopt. I think that is completely normal, because it is a process.
What helped motivate the slower adopters: training, financial incentives, or something else?
Michal: Some technology companies have set up internal leaderboards that promote token usage. What has worked really well for us is knowledge sharing. We try to evangelize examples from our projects that benefited from the increased pace of creation, and we do it deliberately. We hold an all-hands once a week, and one section is dedicated to sharing successful projects and learnings from the ground.
When you see how your work and your impact can be accelerated, you start to realize that the old ways of operating are probably not sustainable. In our environment, that has been the most convincing proof for driving change internally.
Beyond code generation, which tasks benefit most from AI, for example in data science and model building?
Michal: One recent example is time series forecasting. We maintain an open-source library called Darts, which is broadly used for all types of forecasting, including financial forecasting. We noticed that some of its users are not technical. The framework is powerful but takes time to adopt, and a finance department, for instance, may not have much engineering capacity. Those tools are now becoming really approachable, so a CFO office can start using more sophisticated approaches to improve its deliverables.
A big part of the data science work we deploy internally still relies on more classical machine learning methods, and this technology speeds up a good portion of it. We do not do a lot of LLM training. Most of the time we rely on frontier models. Occasionally we are asked to fine-tune smaller models, usually for a specific industry in a restricted context, and often for on-premises applications.
Open source is increasingly seen as a viable alternative to frontier models. Are you seeing enterprises shift in that direction?
Michal: In an enterprise context, I would say the move to open source is not broadly prevalent. What we see instead is a move toward architectures that let you switch between model providers. You can consume models from one lab or another, or open-source models usually deployed through a hyperscaler solution such as Bedrock or Azure AI Foundry. Our clients are leaving themselves the opportunity to consume from the best, which I think is smart, because every quarter the leaderboards shift slightly and locking yourself into one intelligence provider is perhaps not the best choice.
A few of our clients operate in more restrictive contexts, such as central banks and private banks, and their situation is different. They believe in owning the entire stack. They tend to prefer on-premises deployments, operate their own data centers, deploy GPUs themselves, and run their own LLMs.
Financial institutions have traditionally found it hard to compete with technology companies for top engineering talent. If sovereignty becomes a priority, will they be pushed to build that talent in house rather than rent it?
Michal: I think the talent gap is probably the most serious gap in those institutions. Sovereignty has a few elements. Control of the data is one, talent is another, and freedom of choice is a third, meaning that you still have options if part of your stack becomes unavailable because of licensing, changing agreements, or renewals that do not go the way you want.
Every institution has to decide which parts of the stack it really wants to own and control, and which parts it wants to rent or source from other providers. That is a very individual decision for each organization.
AI is compressing delivery time, and many consulting firms are exploring results-based pricing instead of hourly rates. How has Unit8 navigated this?
Michal: It is a topic we discuss a lot internally. We see strong compression of time. Work that would have taken a couple of months eighteen months ago now takes weeks, for example connecting a new system and building software that consumes from it. So the hours are compressing, but the value generated is not. We can solve the customer’s problem in less time, and the remaining time usually goes into more functionality or into helping the customer drive the internal change so that the solution sticks.
On pricing, we still find that time and materials is the most convenient and established way to charge for our services. It is also fair to our customers, because they keep us on their books for as long as we provide value, and if we do a good job it leads to new opportunities. Personally, I find outcome or value-based pricing difficult to put in place. Early on, you are exploring feasibility with the customer and there is a lot of uncertainty in any AI or data project. When the day comes to get paid, it is hard to quantify the result, because as a vendor you may not control every element of the outcome. It is interesting to watch how this landscape changes, and perhaps it will change with the market, but for now we stick to what we know.
Large consultancies are building technology arms, and frontier labs are building services arms. What do you think will separate the winners?
Michal: It is a very interesting dynamic. Firms like McKinsey and BCG are trying to build technology capabilities, while companies like OpenAI and Anthropic are building services arms. We are also seeing deeper specialization, with organizations building centers of expertise for particular industries, such as pharmaceutical experts for R&D or finance experts building workflows for the CFO office. We are doing something similar but coming from the opposite direction. We have a strong engineering culture, and over time we have added management consulting capabilities.
It is hard to say who will be more successful, and I think time will show. The deciding factor will probably be which organizational model delivers the biggest outcomes for customers. Technology is changing, and organizations have to reimagine how roles and processes change with it. In my view, combining technology capabilities with organizational change capabilities is a smart move, because it is very much needed in this AI transformation. Competition is increasing, and we will see who succeeds.
How is the forward deployed engineer role changing in the age of GenAI, what makes a great one, and how do you assess candidates?
Michal: A forward deployed engineer combines a few skill sets. The non-negotiable one is hard skills: strong engineers who can learn quickly and adapt their technical skill set to new realities. The other part is how you perceive value creation. The people who are most successful in this role are extremely curious and oriented toward creating value for the customer. They are not afraid to ask questions and even challenge customers, for example by asking why a process is performed a certain way, or whether it would be simpler to do it differently. That takes some drive and courage, since you are deployed closely with customers and spend a lot of time with other people.
On the technical side, we use classical techniques you would apply to any software engineer, though that may be changing as more work moves to LLMs and agents. For the soft skills, one of our interview stages is called the composition interview. We give candidates a roughly defined, deliberately blurry problem, and their challenge is to ask our recruiters and engineers the questions that lead them to an answer. We are testing whether they are curious, whether they collaborate well, and whether they can start solutioning and take assumptions along the way. It is a bit of an art, but we have an internal structure for it, and I think we have done quite well so far.
Does that make forward deployed engineers more senior than junior in general?
Michal: I would agree that experience helps a lot. At the same time, we sometimes see very young people who perform well beyond their age. They have a lot of drive right out of university or with one or two years of industry experience, and they can outperform some more seasoned colleagues. We always try to build mixed teams. The experienced people contribute learnings from years in the industry, and the younger people bring drive, ideas, and energy, which sometimes makes a huge difference in how we deliver outcomes to customers. In my view, the relationship between years of experience and the impact you can make is very nonlinear.
Rapid Fire Section
Open source or closed source?
Michal: Open source.
Terrestrial data centers or data centers in space?
Michal: I would really like to see data centers in space and how they operate. I am fascinated by the idea, and let’s see if it happens.
In the next five years, do GPU prices go up or down?
Michal: My guess is up.
To build a stellar technology team, do you need Polish directness or Swiss precision?
Michal: Polish directness, because of my background.
Fondue or pierogi?
Michal: Pierogi.
