Tech Talks Daily

Could you explain why your AI bill rose and what the business got in return? I asked Jim Rowan, US Head of AI at Deloitte, because a total spend figure tells a finance team how much it paid, but gives it little help deciding which work to expand. In Deloitte's State of AI in the Enterprise survey, 71 percent tracked total AI interface and API spend, 51 percent tracked token volume, and 44 percent tracked the cost per unit. Jim suggests looking at what it costs to finish a task to an acceptable standard.
We talk about what surrounds the model: the tools it can call, the information it can retain, and the permissions it needs to work with company systems. Jim gives a simple example. An email connection can let an agent read messages, draft a reply or send on someone's behalf. Each step carries different consequences. Getting that decision right can take longer than choosing the model, especially when an agent needs access to a system the company has relied on for decades.
Jim also explains why he'd start with a company's existing approval limits before giving an agent authority to act. The same payment might require review at a small company and fall within routine approval limits at a larger one. Deloitte's survey puts that discussion in context: 40 percent reported allowing AI to execute decisions or actions without human approval to at least a moderate degree, while 23 percent reported unclear accountability for negative outcomes. Those are separate findings and tell us nothing about how much the groups overlap.
We finish with a question for anyone tempted to swap models after the next release. Does it do your work better, and is the improvement worth the cost of testing and switching? Deloitte's survey also found that 28 percent reported revenue gains from AI, up from 20 percent in the previous edition. That's encouraging, although reported revenue gains do not establish that a project paid for itself. I'd love to hear your experience. What do you measure to decide whether an AI workflow deserves a bigger budget?

If your business lost several systems at once, would the recovery order reflect what your customers need most?
In this episode of Tech Talks Daily, I speak with Mike Campbell, CEO of Fusion Risk Management, about operational resilience and the connections that can turn one disruption into a wider business problem. We discuss why application recovery, supplier continuity, employee knowledge and customer service need to be understood together when leaders decide what to restore first.
Mike shares an example involving an unnamed retailer whose existing IT recovery plans followed a logical technical sequence. During a demonstration using those plans, he says the business identified a different priority: restoring its online presence before concentrating resources on stores that had some manual alternatives. The lesson is about the assumptions inside the plan. This was a planning example, rather than evidence of a measured recovery during an actual outage.
What interested me was the distance between knowing which applications sit on a server and knowing which business activities depend on them. That connection affects how teams judge financial impact, customer consequences and the order in which work should happen. It also explains why operational resilience is a boardroom discussion, with choices about suppliers, investment and acceptable disruption sitting alongside technical decisions.
We consider the role of simulation and testing across different scenarios. Mike describes how Fusion's platform can help teams compare variations and identify recurring weaknesses. Those findings depend on the information and assumptions behind the model, and the conversation doesn't establish that a simulation can guarantee what will happen in a real incident. It does offer a useful way to question whether a single rehearsal has covered enough possibilities.
There is also a very practical communications example. If the usual email service becomes unavailable, teams need a way to coordinate that doesn't depend on the same failed services. Mike argues that deciding this while normal communications still work is much easier than trying to assemble an alternative during disruption.
Finally, we discuss people as potential single points of failure and the decisions involved in relying on one supplier. Resilience becomes something leaders consider when designing the business, supported by testing and an understanding of the consequences of different choices. Please share your thoughts with me. Which dependency would you examine first to find out whether your recovery plan matches the business your customers rely on?

What happens to your AI budget when one business question becomes a series of data queries across several systems?
In this episode of Tech Talks Daily, I speak with Rohit Choudhary, founder and CEO of Acceldata, about the work taking place behind an AI response. An agent may need to find information, call several tools, and repeat parts of that process before it can return an answer. Each step can consume resources, and the person asking the question may have little visibility into the infrastructure activity it creates.
Rohit uses the example of looking for jewelry without knowing which vault contains it. The analogy helps explain why an AI system can spend time and compute finding the right source before it does anything useful with the information. We discuss his view that repeated queries and tool calls are putting pressure on enterprise infrastructure budgets, particularly where data is spread across older systems and cloud platforms.
His banking example brings the problem into focus. Information can pass from mainframes through multiple processing stages before reaching the applications people use. Copies may represent different stages of transformation, and the data that is suitable for one business purpose may be unsuitable for another. An agent needs to use the appropriate source, while the organization needs to understand the reliability and cost of that decision. The banks are not named, and the example should be understood as Rohit's account of the patterns he sees.
We also discuss why data quality cannot be separated from governance. Different business teams have different requirements, but AI services can draw on information that crosses those boundaries. Rohit argues for controls that operate throughout the data pipeline, including access restrictions, quality checks, and reconciliation. The business question is whether a policy actually changes what a running system can do.
One of his clearest principles is that an agent acting for a person should follow that person's permissions when working with enterprise data. We talk about how common standards can coexist with decisions made by individual teams about where data should live and which infrastructure best serves a particular use case. The conversation does not offer a universal answer about who should own every cost, but it does make the case for consistent controls across separate budgets and responsibilities.
Rohit also describes Acceldata's X-Lake platform and its approach to bringing intelligence to distributed data. Alongside the architecture discussion, I ask how leaders can distinguish productive AI activity from repeated processing and experiments that never become useful services. He expects a period of experimentation followed by a closer assessment of which applications provide lasting value. Faster application development can widen access to information, but it also makes it easier to build something whose ongoing cost has not been fully considered.
Finally, we consider the consequences of using unreliable data. Rohit's credit and drug-trial examples are hypothetical illustrations of how errors can influence decisions. They reinforce a practical question for anyone expanding an AI service. Can you explain the information it used, the permissions it followed, and the resources it consumed?
I would love to hear how your organization is approaching this, so please share your thoughts. Are you measuring the full data and infrastructure cost of an AI answer, or mainly the model bill?

If AI can help anyone create an application, who checks whether the result is secure enough to put into production?
In this episode of Tech Talks Daily, I speak with Frank Emery, VP of Product Management at Checkmarx, about the skills and security practices needed as AI becomes part of software development. We begin with developers entering the workforce alongside coding assistants and the experience they still need to build.
Frank argues that architecture, review and an understanding of what code actually does become increasingly valuable when generating that code takes less time.
We discuss what happens when output grows faster than teams can review it and vulnerabilities accumulate across repeated changes. I ask who should own the risk when AI-generated code passes through several tools and teams.
 Frank places responsibility with the organization releasing the product, supported by developers who validate their work, team leaders who maintain that discipline and application security teams that establish standards. He also explains why a feature behaving as expected does not establish that it is secure.
The conversation considers how much independence coding agents should have. Frank describes the importance of existing controls, the difference between routine changes and architectural decisions, and the need to separate code generation from security testing.
We then discuss layered checks across the development process, with quick feedback during generation, further checks around pull requests and deeper testing as an application develops. The aim is to make each check appropriate to the stage rather than applying every test at the earliest possible moment.
We close by considering continuous validation and the measures that can show whether a team is reducing risk. Discovery time, detection quality, remediation time and exposure all offer a more useful perspective than counting how much code has been produced.
For leaders adopting AI development tools, the conversation raises practical questions about speed, responsibility and the judgment needed to release dependable software. How is your organization reviewing AI-generated code, and what would help your teams build with greater confidence? Please share your thoughts with me.

What happens when an AI agent pursues an approved task in a way nobody expected, using access that reaches further than it needs?
On Tech Talks Daily, I'm joined by Jonathan Trayers, a director at Ekco, to discuss the security decisions behind agentic AI. The conversation focuses on what changes when a system can act with credentials, connect to business applications, and trigger workflows. A useful answer in a chat window and an automated action inside a company create different responsibilities.
Jonathan describes working with both deterministic workflows, where rules specify what should happen, and agentic steps, where AI interprets a situation before deciding what to do. Bringing those approaches together raises practical questions about boundaries. Which actions can the system take, what information can it access, and where should a person remain involved?
What interested me was his emphasis on limiting the impact of unexpected behavior. Predicting every failure is unrealistic, so he argues for reducing the area an agent can affect. The permissions attached to its identity help determine that boundary. An agent given broad access may be able to create problems across several systems, even when its original assignment sounds narrow and reasonable.
We discuss separate identities for agents and their connections, restricted permissions, continuing monitoring, and the ability to revoke access. Jonathan also describes governance as a series of practical decisions about the use case, the risks the business accepts, and the people responsible for approving the deployment. Prompts can express instructions, while controls around the systems an agent reaches need their own attention.
Testing is another part of that process. Jonathan recommends beginning in a controlled environment, observing the outcome, and then using supervised operation before handing over greater responsibility. His invoice example makes the point understandable. Processing an invoice and authorizing its payment involve different consequences, so the workflow should reflect that difference rather than giving one automated process every permission at once.
We also consider what this means for smaller businesses. Jonathan's concern is that companies with limited security resources may already have broad access arrangements, which can be carried into AI deployments. Company size alone does not determine exposure, but understanding accounts, permissions, software, and patching remains part of managing it. His argument is to apply those disciplines as AI adoption develops, rather than waiting for a new platform to solve every governance problem.
Accountability runs through the discussion. Jonathan argues that a business remains responsible for the way it deploys technology and approves access, alongside responsibilities held by vendors and model providers. The precise legal allocation will depend on the circumstances. The operational question for listeners is clearer: who owns the use case, who accepted its risks, and who can act when something changes?
For teams beginning this work, Jonathan recommends one valuable use case and a reusable implementation pattern. Define the boundaries, test the controls, retain human judgment where needed, and use the experience to inform the next deployment. The conversation offers a practical starting point for organizations trying to gain value from AI agents while keeping their access and actions understandable.
Please share your thoughts. How is your organization deciding what AI agents may do, and what would help you keep ownership, permissions, and oversight clear after deployment?