12 Jun 2026 · 31m · Darko Todorovic · 17 quoted facts
Darko Todorovic argues that enterprise AI projects rarely fail because the technology is weak. They fail because organizations never define the problem, never set cost baselines and KPIs, and never prepare their people for working alongside AI. In his view, treating AI agents as junior coworkers rather than tools, and starting with the people who know the processes, matters more than choosing the most advanced model.
The central tension is between how well pilots perform and how badly they scale. Pilots succeed because the most senior, best-judging people run them. Rolled out to thousands of ordinary staff, results become uncontrollable. Pressure, fear of missing out and shifting technology make leaders either hesitate or overstate results. His answer is to assess organizational and data maturity first, invest in education, and expect a continuing evolution rather than a one-off project.
Todorovic says many firms adopt AI because rivals claim 200% or 400% efficiency gains, not because they have a defined problem. Without a clear target, there is nothing concrete to measure afterward.
Pilots usually use a well-chosen process and the organization's most senior people, who can spot a flawed AI output and correct it. Releasing the same agents to thousands of staff removes that safety net, and results often disappoint.
For well-defined processes such as issuing RFPs, a firm knows the time and cost per document. It can then compare the upfront build cost plus the per-unit running cost of the AI against that baseline. New revenue products are far harder to measure.
Teams can track token use per agent per person, and skilled teams spend fewer tokens for the same result. Because one successful department makes others want the same, costs could multiply, so budgets should include that scaling risk.
Todorovic says the latest model is not automatically the best choice, and the right model depends on the data and setup. He says results depend more on readiness and staff education than on the technology itself.
Todorovic says pilots use the best, most senior people, who can tell when an AI agent has made a mistake and fix it. When the agents go to thousands of ordinary employees, that control disappears and results usually fall short.
Todorovic says to compare the upfront build cost (capex, or capital spending) plus the cost of each AI run against the existing cost per unit of the process, such as one RFP (request for proposal). This works best when the process is already well defined and its cost is known.
No, according to Todorovic. He calls the assumption that the best model gives the best result flawed, and says you need the right model with the right data and setup for your specific problem.
Todorovic means treating an agent like a young associate: you set guardrails, give it tasks and check its work, while humans still make the judgment calls. As the technology improves and proves itself, you can give it more autonomy.
Todorovic says to assess both technology readiness (data and knowledge management) and organizational readiness for change. He also says to start with the people who deeply understand the processes, not the IT department, and to invest in education.
Stated by the speakers. Each quote matches the transcript, which shows what was said, not that it is true.
HTEC Group is described as a global engineering firm focused on AI-centric software and hardware development, operating from more than twenty engineering centers.
“global engineering firm focused on AI centric software and hardware development, working across financial services, medtech, automotive, telecom and enterprise software from more than twenty engineering centers”
Darko Todorovic is the Chief Technology Officer of HTEC Group.
“Today's guest is Darko Todorovic, Chief Technology Officer at HTEC Group”
Emerj offers a free PDF report titled "3 Ways to Discover AI Trends in Any Sector" at emerj.com/ait1.
“Three ways to discover AI trends in any sector at emerj.com slash A I T one.”
Darko Todorovic says organizations typically form an AI task force inside the CIO or CTO office to find processes to augment with AI.
“you have a task force that is formed inside of a C I O office or a C T O office.”
Darko Todorovic says organizations often adopt AI after seeing other companies report efficiency gains of 200% or 400%.
“they see that that organization implemented A I and they have efficiency of 200% or 400%, et cetera”
Darko Todorovic says proofs of concept succeed partly because they are staffed with the organization's most senior people, who have strong judgment.
“You chose the right process, you chose the most senior people in the organization, the best people that you have, that have already a decision making framework, good judgment.”
Darko Todorovic says digital transformation took about ten years, while the AI shift is condensed into roughly eighteen months.
“We we've seen that process, but that process was ten years long. Now everything is condensed in eighteen months.”
Darko Todorovic says AI investment should be assessed as an upfront non-recurring engineering (capex) cost plus a per-unit execution cost.
“One component is initial N R E investment, so basically capex, and then you have to see how much is execution of these agents or A I tools is going to cost you per each unit of measure.”
Darko Todorovic says a well-architected AI solution lets organizations monitor token consumption per agent and per person and see the monthly bill.
“you can monitor the token consumptions per agent per person. You can actually see what is the the bill at the end of the month”
Darko Todorovic says a sophisticated team can deliver the same AI solution while spending fewer tokens than a less skilled team.
“sophisticated team is going to give you the same solution for the less amount of spend, or less, uh, uh, smaller amount of tokens spent, which is really important.”
Darko Todorovic expects AI costs to fall over time and says serious adopters will not worry about cost in the first couple of years.
“serious organizations that see serious advantages of using A I are not going to be worried about the cost in the first couple of years, because the cost is going to go down over time.”
Darko Todorovic says ChatGPT's answers have improved markedly in comprehension compared with two years earlier.
“if you look at what Chat G P T gave you as an answer two years ago compared to what you're getting now, it's like really, really different comprehension”
Darko Todorovic says a successful AI agent in one department can lead other departments to demand it, potentially multiplying payments to foundation model companies tenfold.
“I'm giving to some of the foundational model companies, uh, x amount of money, and now I have to to give ten x.”
Darko Todorovic says AI readiness should be assessed on two dimensions, the first being technological and data readiness and the second being organizational readiness.
“One dimension is uh technological readiness and data readiness.”
Darko Todorovic says standard enterprise software such as HR, procurement and ERP systems made different organizations look alike because customization was costly.
“all of the standard processes like H R process, procurement processes, E R Ps, et cetera, were built in a way that when you implement them, every organization is looking like the other organization.”
Darko Todorovic attributes the growth of software-as-a-service businesses in the last decade to how hard it was to customize traditional enterprise software.
“That's why you had all of these S A S businesses exploding in the last decade.”
Darko Todorovic says a knowledge management layer on top of company data is important so multi-agent systems can share the same context.
“Knowledge management is really important if you want to have multi-agent systems that can share the same context”
Todorovic says the gap is mainly about change management and process redesign, not weak technology. Adding AI on top of old processes is the root mistake.
“we shouldn't start by implementing technology for the sake of technology”
Many firms adopt AI because competitors claim huge gains. Faster change and unproven vendor promises leave decision-makers overwhelmed.
“are now implementing A I, not for the right reasons”
Pilots are run by an organization's best people, so they look better than a wide rollout will. This is where most scaling failures occur.
“you chose the most senior people in the organization, the best people”
Efficiency projects are measurable when processes and unit costs are defined, while new-revenue projects are not. Pressure to show results can also tempt people to inflate them.
“you have the cost per unit defined in your organization”
Dashboards can show token use per agent and per person. Leaders should budget for falling prices but also for costs rising as AI spreads across departments.
“you can monitor the token consumptions per agent per person”
The most advanced model is not automatically best. AI could let firms build processes tailored to themselves, unlike one-size-fits-all software.
“thinking that the best models give you the best result is really flawed”
Leaders should check data and organizational readiness and treat agents as junior employees. They should begin with people who know the processes and invest in knowledge.
“start from the people that deeply understand the processes in the organization”
Welcome everyone to the Emergent AI in Business Podcast. Today's guest is Darko Todorovic, Chief Technology Officer at HTEC Group. HTEC is a global engineering firm focused on AI centric software and hardware development, working across financial services, medtech, automotive, telecom and enterprise software from more than twenty engineering centers. In this episode, Darko examines why enterprise A I investments frequently produce successful pilots, but stall when deployed at scale. A failure rooted not in technology, but in organizational readiness, talent gaps, and the absence of defined success metrics.
He walks through how leaders can establish cost per unit baselines, build R O I measurement frameworks, and treat A I agents as coworkers rather than tools. A mindset shift he argues is the critical precondition for scalable, measurable impact. Today's episode is sponsored by HTEC. In this episode, we cover how enterprise leaders can measure and prove A I R O I after deployment. To go deeper on this topic and learn how to identify real AI trends by tracking where venture funding is flowing, and by listening to how leading CEOs describe risk and competitive strategy, download our free PDF report.
Three ways to discover AI trends in any sector at emerj.com slash A I T one. That's M E R J dot com slash A I T one to download your copy. Now, the conversation with Darko. Darko, welcome to Emergent's A I in Business podcast studio. That's great. I'm excited to talk to you today. Um, I know that you've been inside engineering and delivery for quite some time, which means that you've been on the receiving end of what clients actually ask for, what they think they're measuring versus what they actually end up being able to show.
And it always feels as if the R O I conversation or question is very straightforward at the start of the project. We always have this this direct idea at the beginning. We're gonna do X and it's going to deliver Y. But then somewhere in between the commitment and the close up, our clarity kind of disappears and and we kind of lose track of what it is that we want from this. From your perspective, what is actually happening in that gap?
Well, that gap is, uh, is a multifaceted problem. Uh, at this point of time. First of all, the technology is not mature enough. You don't have the basic components that you can choose from. So, from the implementation side, it's always a question mark how to go about it. We know that we need data, but nevertheless, we we think that we have the right data, right sources, uh, that everything is one data lake, et cetera. At the end of the day, that is maybe not usable in the proper way by the AI agents.
So, on the technology level, on the technology layer, we need to make sure that we have the right setup for the problem that we are solving. Which brings us to the point is we shouldn't start by implementing technology for the sake of technology and just putting a sticker on top of the process that it's A I process. We should completely rethink all of the processes that we want to augment with A I and really see how we implement it with making sure that A I agents are not the tools anymore, but they are our coworkers in the process.
So, when you start from from there, it's there is a higher likelihood that the success of the implementation of the A I enabled process is going to be successful and that you can see the tangible R O I. Finding these processes is the first task that every organization is actually gets as a task. So you have a task force that is formed inside of a C I O office or a C T O office. It depends on the maturity of the company that we need to bring up our efficiency with implementation of the A I tools, and you are tasked to do that.
So, first, what they do, they find the process, they say, okay, this is going to be the process that we want to augment with A I. Then we are going to choose the the tools that we are going to use, the technologies, et cetera, and then we are going to implement the perfect process with the help of A I. And in demo, this uh works perfectly. Then we are going to deploy it to a customer or customers, depending on the on the maturity of the company and what the company actually does.
And once that happens, usually things go south. And and this actually is a function of not the uh technology, uh, the advancement of the technology that is implemented, not the function of the wrong process that was uh selected. It's the function of the changes that need to happen inside of the organization, but more importantly, within the people that are using that are on the receiving end of these A I agents to help them actually be more efficient in the processes they are delivering or they are working on on day to day.
So, in a nutshell, I think that having the organizations realize that this is a huge change management problem is very important at the beginning of any A I endeavor.
So would you say that problem comes in when organizations, if the technology works and um if it's been implemented correctly and they did look at the problems, uh, the business problem beforehand, they look did look at different options, and they still, they're still not able to prove what what actually delivered from it. It worked, but they can't prove what it delivered. Is that a a measurement problem? Are they measuring the wrong things? Is it a baseline problem, or is it a conversation that was never had before they they kicked off the project?
Yeah, I think that most of our organizations uh are now implementing A I, not for the right reasons, basically, because of the most in most of the occasions, because of the fear of the missing out. Because they see that that organization implemented A I and they have efficiency of 200% or 400%, et cetera. And then you say, and and this is normal, quite normal. What are we missing? What are we doing wrong?
If we don't have this kind of efficiency in the organization? More importantly, some of the organizations are asking themselves, uh, okay, this organization, based on the data, created more revenue for their company. They have new revenue streams that they opened up. But ultimately, if you don't have the people capable in the organization to understand the technology, limitations of the technology, and how it should be implemented inside of the process where you have coexistence of AI agents and humans, they are going to fail.
And this is the first thing that they need to realize that they need to have the right talent in the organization. They need to invest into education and into understanding how these tools can help them. The problem is also that they are bombarded with the different agentic platforms, different approaches, uh, uh, promises of wonderland. And then it's very hard for them to say no when somebody says, Hey, I'm going to help you achieve these results in three months.
I don't need a year and a half, but in three months, you'll have this, you'll have that. And what happens is that they actually burn themselves in a couple of occasions. So when the technology is mature, when there is actually a real potential case with a real R O I, they are reluctant more to make the decision. And we have seen this happening in digital transformation as well. This is not new for me or or for our company.
We we've seen that process, but that process was ten years long. Now everything is condensed in eighteen months. And then pure cognitive load on the decision makers to make decisions very fast, with little input, with little to no input, and where nobody can, for sure, tell them that this is going to be a successful program. It's very hard. And we have to be very empathetic with these people. That's why everybody is opting in for P O Cs.
But what they don't realize with the P O Cs is that the P O C can work really good. Why? You chose the right process, you chose the most senior people in the organization, the best people that you have, that have already a decision making framework, good judgment. They know when the A I agent is uh flawed, or the result of the outcome of the A I agent is flawed, they can correct it, et cetera. So they are experts in the room that can make decisions.
But then if you go out of the P O C and you go to the production, on the production level, if you have to release these agents to thousands of people in your organization, it's completely uncontrollable. And usually the results are not compelling. And this is where the most of the organizations that come to the P O C and the P O C is successful is actually failing on the scaling and implementation across the whole organization.
And I think that this is the critical point in which you have to understand your organization, how it needs to change, what is what is the new role of the people in the organization. And usually the new role is not to use the A I agent as a tool, but use the A I agent as a co-worker, as your, uh, junior assistant that is going to help you achieve something, but you have to make the judgment calls.
You have to be the human and the decision factor in the loop. So until organizations realize this, it's going to be very hard to have scalable solutions, really, to wonders in in the in the organization.
Yeah, it's almost as if, you know, we, we're still using humans, we're just using A I to to kind of shift or change those normal humans into superhumans. That's kind of the idea that you're giving me. Do you think the the, uh, the problem with being able to measure R O I and present it after deployment? From what you're saying, it sounds as if if there's a gap or if there's a reason why we struggled to prove R O I, it's because we did not have the correct people in the conversation at the start or the correct project managers from the start.
So they just hopped on the bandwagon because they had to and because there was pressure applied to them. But the reason why they can't show the R O Is because they don't really know where to go and find it.
Well, it it's very hard. It it also depends, uh, where you're implementing, uh, A I. Uh, if you implement uh to affect the bottom line, basically, you're looking for the efficiencies. And measuring R O I in very well defined processes in the organizations. It's easy if you have them first of all very well defined, and then on top of that you have the cost per unit defined in your organization. So if you have, for example, R F P documentation that you need to issue or you're issuing an R F P and then you get the offers, et cetera, and all of that processing.
So in that type of a scenario, you actually know how much time you are spending of each person and what is the cost of that particular R F P. And if you have thousands of those, then you know how much money you are spending per each. If you can automate parts of the processes or the whole process of the R F P as an organization, you can easily see what, what are the benefits, what are the efficiencies that you are getting.
The investment you have to look at from two two sides and in two components. One component is initial N R E investment, so basically capex, and then you have to see how much is execution of these agents or A I tools is going to cost you per each unit of measure. So if you have those two, you can easily say, hey, this is my investment, and this is what I'm getting out of that investment. This is the efficiency gain.
On the other side, people are still reluctant to go into new value generation investment with the A I. Except in the cases where organization is actually delivering A I products. So, uh, on that side, it's going to be even harder to see the R O I. Because if you're creating a new product line, or you're creating a new service based on the data that you have on your customers, or you want to upsell something. It's even in a manual world without A I, it's very hard to see what is the R O I on the investment that you're making.
So it's basically a gut feeling, it's, I don't know, uh, institutional knowledge in the organization, judgment calls, decisions, uh, investment committees, et cetera. Everybody is creating a model. So when you are creating a new value, you are creating a model based on a number of assumptions that you're putting into that model. We cannot expect from A I to do that for us. So in that case, we can only treat it as a tool, we cannot treat it as a solution to a problem.
Hey, I want a bigger R O I, a bigger revenue, or I want a new product, uh, that I want to sell to the market. So I I think it's very important for people to understand, and for the organizations to understand where these tools are going to be efficient. So, if we are talking about the measurement of the R O I, of course, you have to have a metric, you have to have the K P I that you want to achieve.
You have to show to to yourself, actually, that the investment that you did is worthwhile. Where is also the problem? The problem with the pressure is that you are going to be under pressure to even fabricate the results of the A I investment because you are responsible to do it. And then you're going to push for it to be successful. And sometimes, and not sometimes, but a lot of times, people are going to look at it as their own child or their own responsibility.
Or this is going to be looked as a failure and out of that fear, people are going to do things that are basically not aligned with the company goals. And this is happening as well. So the result of this is why is this happening? There are no standardized metrics, there are no standardized approaches, there are no standardized stacks of technology. Everything is changing so fast that it's really hard to make these type of decisions. So people that are awfully risk-averse are not going to make them, which I don't really know is it better or worse if making a instead of making a bad decision.
So I would experiment and do a bad decision if needed, but then the organization needs to be very supportive and to to provide a safety net for the people that are actually going down that path.
Uh, it makes a lot of sense, and I know our executive listeners, um, they they understand what you're saying, but they still like to do. I would call it, uh, tracking in real time. They would like to be able to track R O I, whatever R O I means for them, for this specific project in real time. How do they do that? Is this going to be done on a dashboard? Is it a process that they need to monitor?
Is it a governance structure or something else? How can we track in real time?
Well, it's good that we have A I, so it's very, very, very fast to make uh any kind of a dashboard. You can pull out the data very easily. If you architect the solution in a way that uh can provide you valuable data in each step of the process, you can monitor the token consumptions per agent per person. You can actually see what is the the bill at the end of the month, what kind of efficiencies, uh, you you can make in the utilization of the A I tools as well.
So if you have a sophisticated team, sophisticated team is going to give you the same solution for the less amount of spend, or less, uh, uh, smaller amount of tokens spent, which is really important. If you don't have a sophisticated team, they are going to make a solution that is uh costing more than it it is supposed. And but this is going to level up over time, and uh, uh, serious organizations that see serious advantages of using A I are not going to be worried about the cost in the first couple of years, because the cost is going to go down over time.
The sophistication of the tools is going to go up. So if you want the latest model, if you want the latest thing on the market, you're going to pay premium. But if you look at what Chat G P T gave you as an answer two years ago compared to what you're getting now, it's like really, really different comprehension, feeling like you are talking to a person, etc. So it's it's completely different, but that Chat G P T two years ago felt like wonder for everybody.
So we are quickly forgetting how surprised we were when we first started using the tool. And now, in two years from now, if you project yourself in two years from now and say, hey, this is the perfect tool that I have today, that tool is going to be very inexpensive to be used, but it's useful, it's to in today terms. So you have to, when you're calculating R O I, you have to calculate also how much you are going to spend in the future in that particular process.
There is also a a fear of exploding cost of tokens, and we need to calculate that in as a risk factor when we are building a model for our company. One thing which is really interesting also is that if you have successful, scalable A I agent on the whole company level in one of the departments, in one of the functions, for example, what's going to happen is that the rest of the organization is going to look at it and say, oh, I want that.
But you know, that cost, that implementation cost, and then cost of running the agents is going to explode, and you have to calculate that in as well into your budgets and everything that you do. So you're going to think, huh, okay, I'm giving to some of the foundational model companies, uh, x amount of money, and now I have to to give ten x. Ten x is actually too much for our business. So what we do about it, what we do about inference costs, et cetera.
These are already the questions that some organizations are asking themselves, but these are more mature organizations that see all of these efficiencies coming into play. But at the end of the day, the bottom line is the R O I is going to depend more on how you set up your organization and less and how you educate people and how much investment you make into the education of the people in your organization. How to use the tools in the proper way, how to use the A I in the in the proper way, then on the actual implementation and the technology behind.
Y you touched on the sophistication of A I in this answer, and I wanted I wanted to just quickly dive in there as well. For our executive listeners that need to sign off and budgets and need to sign off on A I projects, how important is the sophistication of the tool for R O I? Cause they obviously have budgets to take into consideration. Is it necessary for them to go ultra sophisticated or can they deliver acceptable R O I with mid level A I?
That's it. I I think it depends on the aspiration of the company and that individual. And if they were satisfied with mediocre results, uh, with their own team and people working on the process, they're going to be satisfied with mediocre results from A I. So that's not going to change. Like, decision makers are not going to change their way of thinking overnight. So it depends on how critical that process is for the company. And and if we go even deeper, you can see what separates successful companies from the less successful companies.
But even less successful companies have their own place in the market, and they're satisfied with that. So, at the end of the day, it depends on the aspirations and depends on how the uh the organization is set up more than than what they are going to be satisfied.
Okay, it makes sense. So, uh, so if they have tighter budgets and they cannot necessarily afford the sophisticated A I at this point, they can still expect some R O I with a mid-level tool. I just what you put in is what you get out. Is that the right assumption?
I I think that the readiness of the organization to implement A I is has to be looked through two dimensions. One dimension is uh technological readiness and data readiness. And there are perfectly good metrics that can actually give you these measurements. On the organizational side, we already talked about it. So you have to have the organizational readiness to change in a way that's different from any change that they had up until now. So, if you look from these two perspectives, you have to find the place where your organization is and be realistic about it.
And if you are not realistic about it, then you are going to expect more and get less. So it it's it's very hard to give you a definitive answer on this one because it depends on on many different factors that you have in your organization when you're making these decisions. And when you say sophisticated A I versus less sophisticated A I, it only depends on the use that you are going to deploy this A I solution.
So if you go with the latest model and you think that it's going to give you the best results, that's the wrong assumption out of the gate. You have to have the right model with the right data, with the right setup, to give you the results that you need, that are specific to your organization. The beauty of this A I revolution for the organization is that previously all of the organizations and all of the standard processes like H R process, procurement processes, E R Ps, et cetera, were built in a way that when you implement them, every organization is looking like the other organization.
Have that too. So all the customizations were painful, really painful, and you know that you can be more efficient, but the software solution in order for you to change it is really expensive, it takes time, you cannot do it, and it's very hard for you to to actually build something that is custom for you. That's why you had all of these S A S businesses exploding in the last decade. But the problem with that is that you are putting different organizations in the same bucket.
With A I, the ultimate promise is that I can build my process for myself in a very efficient and easy way, and it's going to be easy to implement it. That's the that's the promise, that's the the promise that A I is giving to the organizations. But when they start implementing, well, this is where the problems are arising. Because you need to change your organization, you need to change the way you're thinking, the technology that you're implementing, and thinking that the best models give you the best result is really flawed.
And you need to choose the right weapon for the problem that you're solving.
That makes 100% sense. The right tool, or the the right skill set with the wrong tool is not gonna give you anything. Darko, I'm gonna still, uh, just a few more minutes of your time as one last question. We need to leave our listeners with an action plan. We need to give them something to start with. Uh, we've now spoken about the implementation, we've spoken about what R R I could look like at the end and the conscious decisions that we make during the project.
But where do we start? For a senior leader who is about to greenlight an A I initiative and he wants to be able to show the work at the end of it, what needs to be in place before we even start with writing a single line of code?
Yeah, it depends again on the maturity of the organization. So we need to assess the maturity of the organization that is, oh, if I'm the decision maker, for example, I put myself in that position. I need to understand the maturity of the organization to implement and adopt A I tools. Uh, from the technology standpoint and from the organizational standpoint. On the technology standpoint, we need to look at the data, we need to look at the knowledge management layer on top of the data that we have.
Knowledge management is really important if you want to have multi-agent systems that can share the same context so that they can be efficient across the whole company, across the all of the processes that are interconnected and intertwined in each organization. And then from the organizational standpoint, we need to treat A I agents as employees that we are going to guardrail, that we are going to task to do something, that we are going to check if they did something right.
I mean, you have to look at them as a young associate at the beginning, and then over time, as the technology improves, as you realize that these agents can take more of autonomy by themselves, then you're going to be able, uh, to leverage the true power of A I. So you should look at this as a starting point in evolution of your organization, where A I and humans are going to coexist, or A I agents and humans are going to coexist, and not as a a project that starts and ends with the R O I.
So if you start with that kind of mindset, you're going to do the right decisions from the start and not build on technical debt. And this is really, really important. How to do that practically is again depending if you have on the organization. If your organization has I T department that uh is used to buying software off the shelf, that's not going to work. You need to start from the department, from the people that deeply understand the processes in the organization, and then teach them where I A I can help them.
So don't start with the technology, don't start with with the C I O office. In most of the cases, start from the people that deeply understand the processes in the organization and then teach them where A I can help them. Once you do that, you're going to realize what are the requirements, what you actually need, then go on the market and find what you need. If you are I T savvy organization or you have a development teams in the organization, et cetera, this is going to be even easier for you because you can task some of your development teams to actually do the research, help you out, uh, create P O Cs, build P O Cs, and do it internally.
Try to do as much as possible internally. But if you don't have that critical talent in the organization, if you don't have results after three months, you know that you need to go out. And when you go out, it's also important to find somebody who actually delivered solutions on scale, on production, somebody who understands even the economics of the tokens spent per process, per decision, and the outcome that you get from the A I. Everything from there is going to be evolution.
And and be prepared that this is not just one off that you are going to do. A I is completely changing the paradigm of how we are doing operations in the businesses and how the businesses of the future are going to look like. So if you are prepared for the evolution, then you're going to make the right decisions from the beginning. But invest in knowledge, knowledge, knowledge. That's the only thing that you can do at the beginning of the journey.
Feel like that's, uh, some very good tips that you've given our our listeners. Darko, I'm gonna wrap this up by just just repeating a few things that you said that will really stick with me. Um, I think when we started, you said one of the the biggest issues of not being able to show R O I is because we actually never, we were never sure what the project was about. We just jumped on the A I wagon because of fear of missing out, and we actually didn't have a business problem in mind or we didn't really specify what we're trying to solve with this.
So that's that's gonna be the first thing is make sure that when you start an A I project, that you actually know what you want to achieve, because then the R O I will also be easier to to just measure. And in terms of measurements, there's no standard metric. Figure out what R O I means for your organization or for that specific department that you're trying to implement and deploy it in. So that's also something to sit out.
And then lastly, what you said, where we start is by assessing the maturity of our organization before touching a large A I project, and that is gonna look different for every organization. Um, so there's really no one size fits all. Is that a good summary of our conversation?
Pretty much, yeah.
Very short one. Darko, it has been lovely having you in our studio. Thank you so much for wrapping up this series. Uh, I'm excited to to hear more about this and to be able to implement these little tips that you've given us. I'm sure they're very practical and our executive audience is going to to be able to use them industry wide.
I hope so as well. Thank you very much for having me on the podcast.
Wrapping up today's episode, I think there are three key takeaways from our conversation with Darko. First, most A I initiatives fail to scale because organizations launch them out of fear of missing out, rather than a well defined business problem. Establishing clear K P I s and cost baselines before implementation is the essential first step to proving R O I. Second, successful pilots typically rely on the most experienced people in the organization. Scaling A I across the entire workforce requires equipping all employees to work alongside A I agents as co workers who augment human judgment, not replace it.
And finally, organizational maturity and readiness, assessed across both technology infrastructure and change management capacity, is a stronger predictor of A I success than the sophistication of the model selected. In this episode, we cover how enterprise leaders can measure and prove A I R O I after deployment. To go deeper on this topic and learn how to identify real A I trends by tracking where venture funding is flowing, and by listening to how leading C E O s describe risk and competitive strategy, download our free P D F report.
Three ways to discover A I trends in any sector at emerj.com slash A I T one. That's M E R J dot com slash A I T one. On behalf of the team at Emerge, we'll see you on the next episode.