Tech Talks Daily

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 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?

What if many of the problems businesses blame on AI are actually problems with their data? It's a question I wanted to examine when I sat down with Steffen Hoellinger, Field CTO EMEA at Confluent, during Current 2026 in San Francisco. After a year dominated by conversations about AI agents, I'm increasingly interested in the less glamorous work companies need to get right before these technologies can deliver anything useful.
Steffen works with enterprises across Europe, helping them manage real-time data and develop AI applications. Our conversation begins with the difficulties businesses face when information is scattered across departments, applications, and different locations. He explains why simply moving data between systems is no longer enough, and how processing, filtering, and preparing information as it moves can help applications make better decisions.
We also discuss Confluent's Streamhouse announcement and the growing role of Apache Kafka and Flink. Steffen explains how these technologies help businesses process information closer to where it originates, rather than waiting for scheduled transfers and reports. For companies trying to put AI agents into production, he argues that having the right information available when it is needed can make an enormous difference.
One of my favorite moments comes when our conversation turns to where this technology is actually being used. Steffen shares an unexpected example from the America's Cup, where Kafka helped exchange information between a racing yacht and a separate support boat. We also talk about factories and retail stores that can continue operating independently when their connection to the cloud is interrupted.
From there, we examine the particular challenges facing European companies. Data sovereignty, privacy, regulation, and concerns about relying too heavily on public cloud infrastructure all influence technology decisions. Steffen explains why open standards and the ability to operate across different environments matter to businesses that cannot afford extended downtime.
Another subject I wanted to challenge him on was the amount of money being spent on AI models. Steffen argues that companies shouldn't assume an expensive large language model is the answer to every problem. Traditional machine learning, event processing, and simpler analytical techniques can often perform particular jobs faster and at a lower cost. He explains how businesses can combine those approaches, using AI models only where they offer additional value.
We also discuss his experience founding Airy, which Confluent acquired in 2025, and what he's learned about moving from a startup to working with some of the world's largest enterprises. That leads to a wider conversation about governance, accountability, and what happens when organizations begin using large numbers of AI agents across their operations.
Steffen makes an interesting point about business processes that have historically depended on people and software working together. Introducing AI agents will require companies to reconsider how those processes operate, while retaining clear human accountability for the decisions being made.
Towards the end of our conversation, I ask what European CIOs should prioritize over the next 12 months. His advice is to concentrate on the data companies already control, understand where it comes from, establish consistent schemas and governance, and avoid committing too early to a single AI platform.
It's a useful conversation for anyone trying to separate the excitement surrounding AI from the practical work required to make it useful inside a business.
As more organizations prepare to introduce AI agents into everyday operations, are we spending too much time choosing models and not enough time understanding the information those models depend on? Listen to our conversation and share your thoughts.

What happens when an AI agent makes a business decision using information that's already out of date? It's a question I wanted to put to Stephen Deasy, CTO of Confluent, when we met at Current 2026 in San Francisco. After attending more than 20 technology conferences this year, I've heard countless promises about what AI agents will eventually achieve. But there's a growing problem behind those ambitions. Businesses are still struggling to get accurate, current information out of the systems they already own.
Confluent has introduced Streamhouse, a data architecture designed to address that problem. Stephen explains why the company believes existing approaches can leave applications working with delayed or incomplete information, and how the new architecture brings streaming, processing, governance, and querying together. We also discuss Lightning Tables, one of Confluent's major announcements at the event, and what direct access to current Kafka data could mean for developers and their businesses.
I was particularly interested in what this means for companies that have already invested heavily in data warehouses and lakehouses. Stephen makes the distinction between analyzing past performance and running business operations using current information. He explains why Confluent sees these approaches working together, and why existing technology investments can provide the foundation for introducing Streamhouse.
We also discuss the experiences of Instacart and Citizens Bank. Stephen recalls how Instacart faced a sudden increase in demand during the pandemic, when accurate information about orders, inventory, and deliveries became especially important. He also describes how Citizens Bank improved loan fulfillment processes through real-time data streaming. Both examples help explain why the speed at which information moves between business systems can affect customers directly.
The conversation also covers IBM's relationship with Confluent, open technologies including Kafka and Flink, and the announcement that Tableflow is now generally available on Google Cloud. Stephen shares his thoughts on model evaluation, human oversight, and how companies should measure returns from their technology spending.
One of my final questions concerns the misconceptions surrounding Streamhouse. Stephen explains that the architecture brings together approaches many organizations have already been working toward, and that its value lies partly in making those capabilities easier to use together.
With so much money being invested in AI, are businesses paying enough attention to the information those systems depend on? Listen to our conversation and share your thoughts.

What should a business consider before moving AI inference onto infrastructure it owns?
In this episode of Tech Talks Daily, I speak with Paul Speciale, Chief Marketing Officer at Scality, about the decisions behind enterprise AI infrastructure. Following the launch of Scality AI Inference Factory, we discuss why organizations are assessing on-premises inference alongside cloud services, with attention to costs, model control and the location of sensitive data. Paul expects a hybrid approach, with different workloads running in the environments that suit their requirements.
The conversation begins with the work a GPU repeats when an AI session needs to process familiar context. Paul explains how saving and retrieving that information can reduce recomputation, and why storage and networking deserve attention alongside compute. We discuss where the economics change as usage grows and why owning the infrastructure also means taking responsibility for utilization, performance and the operating bill.
We then consider data placement across storage tiers. Paul argues that there is no single best location for every workload, with performance, cost and sovereignty requirements shaping the decision. I ask where automation should stop and human approval should begin. He describes automating health checks, forecasts and recommendations while retaining approval for consequential changes such as deleting data or changing policies.
Cyber resilience is another part of the discussion. Paul explains why an immutable copy needs to be supported by tested recovery, and why sovereignty rules should be checked through attempts to perform actions the system is meant to refuse. We close with the responsibilities infrastructure teams take on as they manage inference directly, from tracking time to first token and context reuse to deciding when a model should change. For leaders assessing their next AI deployment, the conversation offers practical questions about control and the evidence behind the business case. Which workloads would you consider running locally, and what would you want to prove before making that decision? Please share your thoughts with me.